arXiv CSopen access

The Blockchain Execution Dilemma: Optimizing Revenue XOR Fair Ordering

The Blockchain Execution Dilemma: Optimizing Revenue XOR Fair Ordering Artjom Pugatsov∗ , Can Umut Ileri†∗ , Jérémie Decouchant∗ ∗ Delft University of Technology, † IOTA Foundation

arXiv:2604.23266v1 [cs.DC] 25 Apr 2026

[email protected], [email protected], [email protected]

Abstract—The successive generations of consensus algorithms have progressively shifted the performance bottleneck of blockchains to the execution layer. While recent works address this by parallelizing transaction execution, they often overlook the critical role of transaction sequencing. Historically, transaction ordering was left to validator discretion, a practice prone to Maximal Extractable Value (MEV) attacks, or rigid fair-ordering protocols that limit validator revenue. In this work, we address the tension between validator revenue and order fairness using a dynamic optimization framework. We introduce a blockchainindependent model for transaction sequencing in a continuous setting where block executions can overlap. Within this framework, we propose an anytime genetic algorithm that utilizes gas prices, object sets, and predicted execution times to optimize schedules. We evaluate our approach with real-world datasets from Sui and Ethereum, and demonstrate that our algorithm increases validator profit by approximately 15% and accelerates congestion relief by up to 58%. Furthermore, we quantify the impact of fair-ordering constraints, showing they can reduce validator revenue by 50% to 60% during periods of high congestion. We provide the first evidence that enforcing strict fair ordering effectively nullifies the advantages of advanced sequencing. Index Terms—Blockchain, Execution layer, Sequencing, Byzantine Fault Tolerance

I. I NTRODUCTION Historically, blockchain systems have been constrained by significant performance limitations. For instance, Bitcoin and Ethereum have estimated maximum throughputs of only 7 and 40 transactions per second (TPS), respectively [1, 2]. As blockchain applications have expanded beyond processing payments into high-demand sectors like decentralized finance (DeFi) and the Internet of Things (IoT), the need for architectures capable of supporting substantially higher throughput has become critical. Early blockchain designs followed a monolithic architecture, which hindered optimization efforts since modifications to a single component inevitably impacted the entire system. This limitation motivated the emergence of socalled lazy blockchain architectures [3–5], which decouple the monolithic structure into distinct stages: transaction dissemination, consensus, verification, and execution. By allowing these steps to be optimized independently and processed concurrently, the system’s overall performance is determined by its most restrictive component. While initial research focused primarily on consensus [6], the advent of high-throughput Directed Acyclic Graph (DAG)-based algorithms [7–10] has shifted the performance bottleneck to the execution layer. There are two approaches for optimizing the execution stage. First, vertical optimization aims at optimizing individual

transaction execution. It is highly dependent on the types of transactions, making it less generalizable. An example of such an approach is the analysis of smart contract programming languages [11, 12]. In this work we focus on horizontal optimization, a second approach that focuses on the ability to execute multiple transactions in parallel. The general method consists in distributing transactions across multiple independent executors based on their interdependence [13–19]. With this approach, state-of-the-art execution engines reportedly reach 170 kTPS [19]. The key property that enables efficient horizontal parallelization is transaction independence. Independent transactions can be executed concurrently across distributed workers, necessitating only a final state merge. In the object model [20–22], since transactions consist of read and write operations on specific state objects, two transactions are considered independent if their operations on common objects are read-only. Traditional blockchains, such as Bitcoin and Ethereum, grant validators the discretion to determine transaction execution order within a block. This design serves as an indirect congestion control mechanism: by prioritizing transactions with higher gas prices, validators can filter spam and manage imbalances between consensus throughput and available execution resources [23]. However, this discretionary power lacks transparency and has enabled validators to arbitrarily reorder transactions to extract additional value, a phenomenon known as Maximal Extractable Value (MEV) [24]. As a reaction to MEV, fair ordering protocols have been designed, primarily for the dissemination and consensus layers [25–27]. These protocols aim to enforce a transaction ordering based on arrival times. Currently, these two paradigms represent opposite ends of a spectrum: one characterized by unconditional, nontransparent validator control, and the other by a rigid ordering that disregards validator incentives. In this work, we explore a middle ground between these two extremes, building upon the transaction sequencing framework introduced by Sui [28, 29]. In this model, transactions are initially ordered and then selectively deferred to subsequent blocks based on resource usage in case of congestion. Currently, Sui first orders transactions by gas price and then evaluates them sequentially. A transaction is deferred if the cumulative estimated execution time for its required objects exceeds a protocol-defined capacity. Notably, execution time estimates and object conflicts are utilized only during this deferral phase. We expand on Sui’s approach by integrating execution

time estimates and object-conflict data directly into the initial ordering step. Furthermore, we extend this framework into a continuous execution model where the processing of successive blocks can overlap. We achieve this by employing an anytime genetic algorithm that dynamically adjusts to varying congestion levels. As a summary, we make the following contributions: • We formalize the transaction sequencing problem in a continuous execution scenario. This model states the ordering constraints and optimization goals of sequencing. We also show how to extend this model to account for fair ordering constraints. • We propose a genetic sequencing algorithm that optimizes an execution schedule based on transaction execution time estimates and object conflict information. Our algorithm can optionally maintain a fair transaction order determined during consensus. To increase execution concurrency, only nonindependent transactions are always scheduled and executed in the order indicated by consensus, while others can be reordered. • We implement our genetic sequencing algorithm1 , and compare its performance with the ones of several sequencing heuristics on real-life Sui data and synthetic Ethereum-based data by simulating sequencing and execution steps. We repeat all experiments under realistic perturbations of the predicted execution times. Evaluating our approach with real-world Sui and Ethereum data, we find that it increases validator profit by approximately 15% compared to the baseline and clears congestion 50% to 60% faster. We also extend our approach to support fair ordering and quantifying the profit-fairness trade-off. We find that adding fair ordering reduces the profit by around 50%, which shows that further research is required to efficiently support fair ordering.

Sequencing extension Transaction

information Execution times Touched objects

Execution time prediction

Dissemination

Gas prices

Consensus

Sequencing

Execution

Users

Fair ordering policy

Fair ordering extension

Fig. 1: Modular architecture of a lazy blockchain. The sequencing step bridges consensus and execution by scheduling transactions for execution workers. Our sequencing algorithm computes a schedule based on transaction gas prices, object sets, and predicted execution times, with the flexibility to incorporate an optional fair ordering policy.

schedule, the actual execution is managed by the execution layer and the final execution may differ from the estimated one due to evolving execution times and interactions between conflicting transactions. B. Heuristic Ordering Sui’s current transaction ordering mechanism employs a linear ordering heuristic based on the gas price for shared objects. This approach builds a schedule in a greedy manner, one transaction at a time. However, with this approach, a highly congestive transaction can be sequenced first, which might lead to subsequent executor downtime when the following transactions conflict with it. Figure 2 illustrates an example that involves four workers. Greedily scheduling transaction 1 (bottom left), which conflicts with transactions 2 to 5, prevents scheduling any of the other transactions and leads to more deferred transactions, possibly suboptimal gas revenue and increased downtime compared to an alternative sequencing (bottom right) that would schedule transactions 2 to 5 and defer transaction 1. Using another ordering criterion, instead of gas price, in a greedy strategy would possibly lead to similar scenarios where a highly congestive transaction is scheduled first. Instead, we propose to account for estimated execution times and transaction conflicts when sequencing transactions.

II. BACKGROUND A. Sequencing Layer Figure 1 illustrates the modular architecture of a lazy blockchain. We focus on the sequencing layer, which receives as input blocks2 of transactions produced by the consensus layer. The sequencing layer schedules transactions across execution workers and manages congestion control. It might defer transactions that do not fit in the given execution time window. We assume that transaction execution time estimates are available. Such estimates are derived from transaction properties and can be generated as early as the dissemination phase. Specific estimation mechanisms are outside the scope of this work. Furthermore, we consider an optional fair ordering constraint. In this case, the sequencing layer has to schedule transactions following the transactions’ causal ordering. While the sequencing layer creates an estimated

C. Sequencing Objective We look at sequencing as a combinatorial problem that aims to determine a schedule for transactions that optimizes for a performance metric. For example, if the goal is to schedule all the given transactions in the shortest amount of time, one would minimize the makespan. Alternatively, if the goal is to reach the highest possible throughput, then one would aim to maximize the number of transactions that fit into a given timeframe. In this work, we focus on maximizing the sum of the transaction fees of scheduled transactions. We define the fee of a transaction as its execution time multiplied by its

1 Our code is publicly available online at https://github.com/Artjom-Pugatsov/ genetic-sequencing. 2We use the term "block" to refer to a unit of transactions that are sequenced and executed together. This terminology remains block-agnostic, recognizing that a single commit in DAG-based architectures may encompass multiple vertices.

2

adds an additional step to the processing of the block, it increases latency. When congestion is low, there is no need to increase the latency, as even a simple sequence would Transactions by gas price: Conflicts between transactions: lead to all the transactions being scheduled. An adjustable tx2 sequencer would be able to scale the time dedicated to ordering tx1 tx2 tx3 transactions. tx3 tx1 Furthermore, sequencing needs to support continuity. In tx4 tx4 this model, execution does not wait for a block to be fully tx5 processed before moving on to the next block. When a worker tx5 Gas price finishes with all the assigned transactions from block N , it moves immediately onto block N + 1 without waiting for other workers. So the sequencer needs to account for some workers Heuristic sequencing Alternative sequencing becoming free before others. As illustrated in Figure 3, this adjustability and continuity allow for parallelization between different blockchain layers. Sequenced: Sequenced: The diagram shows how the processing of blocks in one layer might affect the processing of blocks in another layer. Worker 1: tx1 \ Worker 1: tx2 Worker 2: Worker 2: It highlights how a blockchain could react to an increase in tx3 Worker 3: congestion by reducing the time for dissemination of the current Worker 3: tx4 Worker 4: Worker 4: block b3 and increasing the time for sequencing of that block. tx5 This will lead to increased latency for future blocks, while Deferred: Deferred: increasing the resources used for sequencing. Furthermore, tx2 tx1 the figure demonstrates the realization of continuity through tx3 overlapping execution of blocks b2 and b3. The sequencing tx4 phase is terminated early to immediately provide the execution tx5 layer with a sequenced block, preventing worker idling. As we try to keep this work independent from concrete Fig. 2: Greedy sequencing of transactions based on gas price implementations of other blockchain layers, we do not design (left) compared to a feasible alternative (right). The size a mechanism for sequencing control between layers. Instead, of transactions corresponds to transaction execution time. these requirements manifest in the design choices of our orderThe greedy algorithm can be sub-optimal and defer many ing algorithm. It needs to be anytime to satisfy requirements transactions. (i) and (ii) and it needs to account for continuity to satisfy requirement (iii).

Transaction data

E. Scheduling Estimation

gas price. Optimizing for transaction fees ensures that the less congestive transactions are prioritized, while still allowing the more congestive transactions to be scheduled, as long as their gas price is sufficiently high. This approach also guarantees maximum profit for the validators, which incentivizes further participation in the blockchain.

While this work focuses on optimizing the ordering step of sequencing, a practical evaluation of ordering requires an estimation of the resulting schedule with final performance dependent on the execution timeline. To bridge this gap, we introduce the concept of a scheduling function, which is a function that estimates the start time and assigned worker for a set of transactions when given an ordering of transactions. Although our approach is in principle agnostic to the realization of the scheduling function, in practice and for the purpose of schedule evaluation we provide a concrete scheduling algorithm to serve as a benchmark for evaluating our results. Since scheduling combinatorial optimization problems are typically NP-hard, we instead rely on a deterministic polynomial-time scheduling algorithm. Our goal is to have a scheduling algorithm that is fast and produces high quality schedules. We rely on a greedy scheduler which schedules the transactions greedily one by one and defers transactions to the next block if they cannot be scheduled at the end of a worker’s queue without possibly leading to a conflict with a transaction scheduled on another worker. This is a continuation of the

D. Sequencing Requirements To be practical, the sequencing step should satisfy three main requirements: (i) it should not introduce a performance bottleneck; (ii) it should be adjustable; and (iii) it should be continuous. The primary goal of sequencing is to improve the performance of execution. Thus, the sequencer must not interfere with execution and must be able to run in parallel with it. We assume execution is distributed across multiple workers that may finish execution of a block at different times. Therefore, an executor’s availability time is not fixed, and the sequencer should be able to terminate the optimization process early and produce a good quality sequence at any time. The need for adjustability is further highlighted by the inherent overhead that sequencing introduces. Since sequencing

3

Dissemination:

Consensus:

Sequencing:

Execution:

b1

b2

b1

b3

b2

b1

b4

b5

b3

b4

b2

b1

greedy approach is to not only schedule the transactions at the end of schedules within executors, but to also check if the workers have any gaps in which the transaction can be scheduled [30]. This approach is a direct improvement over scheduling transactions after all the previously scheduled ones. The downside of this approach is that it substantially increases the complexity of the algorithm. Before it was sufficient to track only the latest times at which each worker and object are occupied. Now each insertion first has to be compared against a list of gaps within the schedule. To make the scanning for gaps operation more efficient, we implement this approach using a B-Tree data structure to keep the gaps ordered by their duration and only scan the gaps starting from the smallest gap that could fit the transaction and stopping at the first found gap. This approach is different from the original proposal for gap-filling scheduling. Although it may sometimes produce different schedules, we determined that this implementation has the same average schedule quality as the original implementation, while showing a slight performance improvement with a larger number of transactions. From here on, we consider the greedy gap-filling scheduler as the scheduling function for our problem.

b5

b3

b4

b2

b3

Congestion

Worker is free early

Fig. 3: Processing of blocks b1 to b5 by the different blockchain layers. Note the increased sequencing time for b3, which is triggered by congestion detected during the execution of b1. Furthermore, the sequencing of b3 was terminated early to satisfy continuous execution requirement, since a worker becomes free after executing b2 while other workers are still executing b3. Algorithm 1: Greedy scheduler input : Lall , d, m output : Assignment A, where A[tx] = (t, wid ) or None

III. C ONTINUOUS T RANSACTION S EQUENCING Table I summarizes the notation used throughout this paper. The symbols are grouped by the context in which they are introduced: single-shot sequencing and continuous sequencing.

A←∅ 2 for tx in Lall do 3 W rkF reeAt ← ∅ 4 for w in 0, 1, ..., m − 1 do 5 W rkF reeAt[w] ← find_earliest(A, w, tx) 1

6 7 8 9 10 11

A. Assumptions We make three important assumptions: (i) the read and write sets of transactions are available; (ii) the transaction execution times are available; and (iii) the system is congested (otherwise there is no need to produce an optimized schedule). The first assumption is very easy to satisfy. In the pessimistic execution model, the object of transactions set is known in advance [21, 22]. Each transaction has to explicitly declare its read and write sets. However, even in models where there is no requirement to declare this set, there are static analysis tools that can accurately determine this set [31, 32]. The second assumption is much more difficult to ensure. It is impossible to precisely know the execution path of a transaction and thus its execution time. Even if the transaction is pre-executed, its execution time might depend on its position in the block. Despite this, there has been significant work done on trying to predict the execution time both through historical analysis and simulation, which showed good accuracy [33]. In the experiments we introduce this inaccuracy in predictions and evaluate its impact on the performance of sequencing. The third assumption is also crucial, as the model aims to maximize the system’s utilization of resources. If the incoming transactions cause no congestion, then there is no point in adding another transaction processing step, as any order of transactions would trivially lead to maximum utilization.

wrk ← choose_worker(W rkF reeAt) if wrk == None then A[tx] ← None else A[tx] ← (W rkF reeAt[wrk], wrk) return A

approach proposed by Sui and extended to the case with a fixed number of workers, whereas the original Sui implementation did not assume a concrete number of workers, imagining a system with an unlimited degree of parallelization and focusing only on object availability. The pseudocode of Sui’s approach, extended with a restriction for a concrete number of workers, is shown in Algorithm 1. The introduction of a finite worker pool necessitates a selection strategy to decide which worker will be assigned which transaction. We settled on the Earliest Start Time strategy where transactions are scheduled on the worker with the earliest availability time since it showed the highest throughput during empirical testing. A straightforward improvement over the aforementioned

4

TABLE I: Summary of notation. Symbol

worker id wi on which the transaction has been scheduled. Transactions that are mapped to None are deferred to the following block. Constraints. Any schedule ΠLall produced by σ must be subject to several constraints. First, a scheduled transaction txi must be scheduled at a positive time (si ≥ 0) and adhere to the deadline (si + ti ≤ d). It also must be assigned to a valid worker id wi ∈ {0, 1, · · · , m − 1}. Finally, the execution must be conflict-free: if txj is scheduled on the same worker as txi (wi = wj ) or if the transactions conflict i.e., ((Wi ∩ (Rj ∪ Wj )) ̸= ∅) ∨ ((Wj ∩ (Ri ∪ Wi )) ̸= ∅) then their executions must not overlap (sj + tj ≤ si ∨ si + ti ≤ sj ). Objective. Our goal is to find an ordering Lall of transactions Tall , such that for a given σ we maximize P : X P := ti · gi

Description

Single-shot sequencing d ∈ R+ m ∈ N+ Tall = {tx1 , . . . , txn } txi = (Oi , ti , gi ) Oi = (Ri , Wi ) Ri ⊆ I Wi ⊆ I ti ∈ R+ gi ∈ R+ Lall = [tx1 , . . . , txn ] σ : (Lall , d, m) → ΠLall
ΠLall : txi → Either None, (si , wi ) + si ∈ R wi ∈ N+ ∪ {0} Tsched ⊆ Tall P ∈ R+

Execution deadline Number of workers All transactions Transaction Object accesses Read set Write set Execution time Gas price Transaction ordering Scheduling function Schedule Start time Assigned worker Scheduled transactions Validator profit

(Oi ,ti ,gi )∈Tsched

where Tsched is the set of scheduled transactions:

Continuous sequencing di ∈ R+ mi ∈ N+ Tiinc θ ∈ N+ Tiall Tisched ⊆ Tiall δi ∈ R + Ciw ∈ R+ dinew ∈ R+ Otchj = Rj ∪ Wj αki ∈ R+ Sik ⊆ Tisched

Tsched := {txi ∈ Tall | ΠLall (txi ) ̸= None} Execution deadline at block i Number of workers at block i Incoming transactions at block i Max deferral rounds All transactions considered at block i Scheduled transactions at block i Max slack time at block i Latest finish time of worker w at block i Extended deadline at block i Touched objects of txj Latest scheduled time for object k at block i Transactions touching object k at block i

C. Continuous execution The above mentioned formulation handles sequencing of transactions one block at a time. But as opposed to consensus, which operates in discrete intervals, transaction execution is a continuous process. There is no need to wait for all the transactions of a previous block to be executed before executing non-conflicting transactions from the next block. To allow for transaction execution continuity, we extend our problem formulation in several ways. We label parameters based on the block number for which we generate the sequence: Tiinc , di , mi are the set of transactions, execution deadline and the number of workers at block i. Tiinc denotes the set of new transactions that just came in during the new round. The full set of transactions that will be scheduled in round i is denoted Tiall . We also define θ, which determines the maximum number of rounds for which a transaction can be deferred before it is canceled. We cancel transactions that have been deferred for too many rounds, and add the rest to the transaction set of the block:

Fair ordering Lf air = [tx1 , · · · , txn ] Gf air = (Tall , E)

Total order over transactions Transaction dependency graph

B. Single-shot scheduling

Input. Let the execution deadline d ∈ R+ be the maximum amount of time a worker can be active for a given block. We consider a system that relies on m ∈ N+ workers to execute / T(i−θ)inc } transactions in parallel. We are given a scheduling function σ Tiall = Tiinc ∪ {txj | ΠLi−1 (txj ) = None ∧ txj ∈ that takes as input an ordered list Lall = [tx1 , tx2 , . . . , txn ] We extend the deadline by the difference between the time of n transactions and schedules all or part of them on the m the earliest worker is free and the deadline at the previous workers over a time period d, producing a schedule ΠLall . block: let δi be the maximum slack time at the end of round i: A set of all transactions Tall = {tx1 , · · · , txn } consists of δi = max (dinew − Ciw ) transactions txi represented as a tuple (Oi , ti , gi ). The tuple w∈[0,1,..mi −1] Oi = (Ri , Wi ) of object ids that txi accesses consists of a set w Ri of object ids that it reads from and a set Wi of object ids where Ci is the latest execution end time for worker w at + that it writes to. Variable ti ∈ R is the execution time of txi , round i: and gi ∈ R+ is the gas price of a unit of execution time paid Ciw = max{sj + tj | ΠLi (txj ) = (sj , w) , txj ∈ Tisched } by the transaction. A scheduling function σ : (Lall , d, m) → ΠLall is set in ad- We define the extended deadline to be: vance and represents a scheduler. It takes Lall , d and m as input
dinew = di + min(δi−1 , di−1 ) and produces a schedule ΠLall : txi → Either None, (si , wi ) . The tuple (si , wi ) corresponds to the start time si and the We limit the maximum additional execution time per round

5

by the execution time of the previous round, to disallow propagation of multiple rounds. To ensure that transactions can not be scheduled before the executor is fully done with transactions from a previous block we introduce a constraint: if a transaction txj from block i is scheduled at ΠLi (txj ) = (sj , wj ) , then

Algorithm 2: Order-fair greedy scheduler input : Lall , d, m output : Assignment A, where A[tx] = (t, wid ) or None Def ← ∅ A←∅ 3 for tx in Lall do 4 earliest_start ← latest_conflict_ends(tx, A) 5 if does_conflict_with_any(tx, Def ) then 6 A[tx] ← None 7 Def ← Def ∪ {tx} 8 continue 1 2

w

j sj ≥ δi−1 − (di−1 − Ci−1 )

Finally, we have to make sure that transactions do not access objects before all the transactions that read from or write to the overlapping objects of the previous block have finished: let Otchj = Rj ∪ Wj for a given txj ∈ Ti , then αki−1 is the latest time at which a transaction touching object k has been scheduled in round i − 1:
αki−1 = max sj + tj

9 10 11

txj ∈Sik

12 13

with Sik the set of transactions that touch the object k in round i: Sik = {txj ∈ Tisched | k ∈ Otchj }

14 15 16

Then a transaction can only be scheduled after the latest time that an object has been freed in the previous round, so if a transaction txj from block i is scheduled at ΠLi (txj ) = (sj , wj ) , then:

17 18

sj ≥ δi−1 − (di−1 − max (αki−1 )) k∈Otchj

W rkF reeAt ← ∅ for w in 0, 1, · · · , m − 1 do W rkF reeAt[w] ←find_earliest(A, w, tx) wrk ← choose_worker(W rkF reeAt) if wrk == None then A[tx] ← None else A[tx] ← (W rkF reeAt[wrk], wrk) Def ← Def ∪ {tx} return A

Π(txj ) = (sj , wj ), then the earlier transaction must also be scheduled before it, i.e., Π(txi ) = (si , wi ) and si + ti ≤ sj .. The scheduling algorithm must also be adapted to satisfy the fair ordering constraint. To preserve a simple and greedy design, we assume that the transactions passed to the scheduler are first totally ordered in a way that respects the causal order derived from Lall . As a result, the set of candidate schedules available to the scheduler is restricted. Specifically, this set consists of all possible traversals of the dependency graph Gf air constructed from Lf air . More specifically, the scheduling algorithm is modified in the following ways. First, if a transaction is deferred, all conflicting transactions that are ordered after the deferred one are also deferred. Second, each transaction can only be scheduled after all conflicting transactions that were ordered before it. The pseudocode with the highlighted changes is shown in Algorithm 2. Note that the inner workings of the find_earliest function have to be changed to return a time greater than the end time of any previously scheduled conflicting transaction.

This approach globally aligns the start times for the new block with the worker that is free the earliest in the previous schedule, while shifting other executors by how late their execution is compared to the earliest executor. The main benefit of this approach is that it enables the continuity of execution without major changes to the problem structure. The model remains the same, barring the required addition of new hard-coded transactions that represent objects and workers not being free at the start of the round. This allows us to handle sequencing of each block as an independent combinatorial problem and additionally enables varying system parameters, such as d, m or σ, dynamically based on the demand. D. Fair ordering Applying the sequencing step requires completely reordering transactions. A strictly opposite approach would be to instead focus on maintaining an order of transactions closely aligned with the order in which they have been submitted to the mempool, called fair ordering [26, 27]. We extend our model to include this constraint in order to measure its impact on the performance. We make two changes to the model. First, Tall is replaced by Lf air = [tx1 , tx2 , · · · , txn ] which corresponds to the total order over transactions produced by fair ordering. Additionally, the scheduling function must respect the causal order established by this order within Lf air , meaning that for every two conflicting transactions txi , txj where i < j: if the transaction positioned later in the order is scheduled, i.e.,

IV. G ENETIC A LGORITHM FOR O RDERING If we were to leave out a concrete scheduling function, instead reformulating the goal as determining the scheduling function that leads to an optimal result, the problem would lend itself perfectly to being solved by a constraint solver in the form of a scheduling problem. We opted against this approach as it would be too inefficient, as also found by Chahoki et al. [34], and would diminish the benefit of sequencing by introducing a new bottleneck.

6

Algorithm 3: Basis of genetic sequencing input : budget, pop_size, Tall , σ, d, m, output : Lall

Sequencing Block of transactions

Random initial Heuristic sequences + sequence

Final sequence

Linit ← highest_gas_price_order(Tall ) ; // seeding Pinit ← random_sequences(Tall , pop_size) ∪ {Linit } 3 Peval ← eval(Pinit , σ, d, m) 4 budget ← budget − (pop_size + 1) 5 while budget > 0 do 6 Pkids ← generate_kids(Peval , pop_size) ; // OX 7 Pkids ← mutate(Pkids ) ; // insertion 8 for kid ∈ Pkids do 9 Peval ← Peval ∪ {eval(kid, σ, d, m)} 10 budget ← budget − 1 1

Choose best Leave n best

2

Population Add

Best sequences

Mutated children

Crossover

Mutate

Children

11

Fig. 4: High level overview of the genetic algorithm for sequencing the transactions.

12

13

Peval ← order_by_profit(Peval ) Peval ← limit_population(Peval , pop_size); // elitism return Peval [0]

Instead, we focus on transaction ordering under a deterministic scheduling algorithm. This approach allows for the possibility of imperfect information. Sequencing only has access to the execution time estimates. In practice, these values will differ from the predicted ones, and the actual schedule will differ from the predicted one [33]. The most straightforward way of sequencing is to use a heuristic to order transactions. Since the proposed problem has major similarities to a multidimensional extension of the knapsack problem [35], the most natural heuristic is to order the transactions according to their gas price. We also considered other heuristics: (i) random order; (ii) given order of transactions, which corresponds to the order in which the transactions appear in the historic data, when applicable; and (iii) lowest execution time.

Seeding. An initial solution is added to the starting population. This solution is made heuristically by ordering transactions based on their gas price [37]. OX. To generate a child from two parent solution sequences, a slice is taken from one sequence (random location and random length) and is inserted into another sequence at the same spot. Then the resulting sequence is scanned, and if a transaction appears twice, its second appearance is removed [38]. Insertion mutation. To mutate a sequence, a random transaction is removed and inserted into a different position [39]. Elitism. A (µ+λ) survival strategy is employed. This means that each iteration parents (µ) and children (λ) are combined and among them a new population is formed by choosing the sequences with the highest fitness [40]. A. Genetic ordering Seeding and elitism help to ensure faster convergence. To With a determined scheduling function, the problem lends slightly offset this, we found it beneficial to set the mutation itself well to being solved through the application of a genetic probability to a high value above 60 percent. The result is that algorithm. Each candidate solution is encoded as a permutation the genetic algorithm acts similarly to a local search procedure, of the available transactions, where the position of a transaction with a higher degree of exploration within the earlier iterations. corresponds to the order in which the scheduler processes them. Initially, an explicit local search procedure was also tested. The application of the scheduling function and the calculation It provided little benefit to the solution quality compared to of profit correspond to the fitness function. The high level extending the budget for the genetic algorithm, while requiring idea is to start from a population of random sequences and a lot of sequence evaluations. then continuously optimize the population by generating new sequences through crossover and mutation, retaining only the B. Adding fair ordering to the genetic algorithm fittest half. This approach is illustrated in Figure 4. Since in practice the gas price heuristic was found to produce high quality solutions, we initialize our algorithm from a heuristic baseline, rather than from a random sequence. Thus, the goal is to locally refine the initial solution rather than searching for a global optimum. The pseudocode is shown in Algorithm 3. The techniques used include: seeding, elitism, order crossover (OX) and insertion mutation, which have been shown to be effective for scheduling problems [36].

When adapting the genetic algorithm to maintain a fair order established by the consensus layer, we have to ensure that the transaction encoding represents a valid total order that respects the causal relations specified by Lf air . We apply the following changes. First, we change the initial seed Linit to correspond to the sequence achieved through traversal of Gf air by prioritizing transactions with a higher gas price. Then, we generate the rest of the initial parents Pinit by traversing Gf air uniformly at random. We modify the crossover operation so that it iterates over the parents and

7

selects the first transaction whose dependencies are satisfied. TABLE II: Derivation of model parameters from real-world The process continues until a valid total order consistent with data. Gf air is generated. We also modify the mutation operator as Parameter Sui Dataset Ethereum Dataset follows. First, for a randomly selected transaction, determine its Execution Time Transaction Effects Transaction Receipt maximal neighborhood of non-conflicting transactions within Gas Price Transaction Data Transaction Receipt the current total order by identifying the closest conflicting Touched Objects Shared Objects N/A (Account-based) transactions before and after it. Then, relocate the selected transaction to a uniformly at random chosen position within this neighborhood. • Touched objects (Oi ) - set of objects/accounts touched by the transactions. V. P ERFORMANCE E VALUATION • Execution time (ti ) - amount of computation the transacIn the performance evaluation, we do not report the runtime tion takes. of the algorithms, and instead focus on execution performance. • Gas price (gi ) - price that the party submitting the In our experiments, the scheduling algorithms are allowed to transaction is paying per execution unit of the transaction. run until the next block is generated and interrupted if needed. Other parameters that are independent of transaction data The genetic algorithm is an anytime algorithm, so result quality are: depends on the allotted time. We do not estimate the possible • Transactions per block (|Tinc |) - the number of transacreal-world execution time. Instead, we report it in terms of tions submitted for one block. iterations of the estimated sequencer. The runtime of the genetic • Maximum execution time (d) - the maximum execution sequencer is proportional to the number of total evaluations of time that a single worker can work for per one block. the estimated sequencer. The number of evaluations is equal • Maximum number of deferrals (θ) - the maximum number to the number of kids per epoch multiplied by the number of blocks for which a transaction can be deferred before of epochs. Additionally, the evaluations of children within a it gets canceled. single epoch can be done in parallel. To measure the impact • Number of executors (m) - the number of executors that of the allotted execution time on performance, we do two runs can execute the transactions in parallel. of the genetic sequencer with the population of 100: for 10 These parameters control how congested the blockchain and 50 epochs, corresponding to 1000 and 5000 iterations of is. We varied them across experiments to simulate different the heuristic sequencer, respectively. This allows us to quantify possible scenarios. the benefit of additional computation time. Additionally, all the transactions were initially ordered We focus on two scenarios with different solution quality metrics: sustained congestion and a single spike in congestion. according to their original positions within the blockchains to In the sustained congestion scenario, we have congestion for better capture temporal fluctuations in gas price trends, demand, the whole duration of sequencing and measure solution quality and potential conflicts between contemporaneous transactions as the sum of gas prices paid by the scheduled transactions. In that may access overlapping sets of objects. To construct the single spike scenario we have congestion for a period of ten a continuous sequence of blocks, we partition the ordered blocks and determine the solution quality by how quickly the transaction sequence into consecutive groups according to a sequencers managed to clear congestion. We define congestion predefined block size. We map platform-specific parameters to the general model clearance as the index of the first block after the spike period as summarized in Table II. The execution time was derived that contains no deferred transactions. from transaction effects for Sui and transaction receipt for A. Dataset and parameters Ethereum. The gas price was taken from the transaction data The performance of the proposed sequencing approach for Sui and from the receipt for Ethereum. Touched objects were is highly dependent on the structure and parameters of the determined from changed and unchanged objects specified in transactions to be scheduled. To obtain measurements that are transaction effects for Sui and were not collected for Ethereum more representative of the expected real-world performance, due to them not being explicitly listed in the available data we base our datasets on two widely used blockchain systems and requiring high-overhead trace analysis of transactions. We note that Ethereum uses a base fee system to determine that support smart contracts: Sui and Ethereum. We took transactions that were executed within a single day on both the minimum gas price. Therefore, to better compare transacchains and streamed them to different sequencers. For Ethereum, tions across different time periods, we normalize the reported we took the transactions from block 23359822 up to block gas used value by this base fee. To do this, we divide the gas 23369821, and for Sui we used transactions from epoch 840. price by the base fee for a given block made during different Both represent recent active network conditions and span a time periods. sufficient transaction volume to capture realistic congestion Since the results heavily depend on the data used, we want dynamics. to first demonstrate the structure of the data and examine the In order to do sequencing, we need to extract or generate distribution of values, as well as show their correlation with the following parameters for the transactions: each other. Figure 5 demonstrates the distribution of values for

8

the Sui dataset, and Figure 6 shows the distribution of values for C. Sustained congestion the ETH dataset. From the datasets, we can see that the only two For all the following tests, we set the number of executors to significantly correlated parameters are the number of touched 4 and the maximum number of deferrals to 5. The number of objects and the execution time of transactions (r = 0.45), transactions was set to 150 and the execution deadline was set while neither execution time nor number of touched objects is to provide around 50-60% inclusion rate for the GP sequencer significantly correlated with gas price. at 62500 units. The simulation was run for 200 blocks and the As we mentioned before, we did not use actual data on results show the cumulative total gas price normalized against which accounts were touched by which Ethereum transaction, the worst-performing (lowest) sequencer at each block. The but we resampled Sui’s dataset. To construct the Ethereum- data is shown from block 20 onward to remove the initial based dataset, we projected Sui’s data on object conflicts over fluctuations and only demonstrate the long-term average result. Ethereum’s execution and gas price records. Specifically, we The results for the Sui data are shown in Figure 8. All of picked a random point in the Sui dataset and appended this the heuristic approaches except for the GP one show similar information to the Ethereum stream one transaction at a time, performance. The GP sequencer shows a 20% improvement preserving the order in which both datasets were scheduled on over median of non-GP heuristics and the genetic sequencers the blockchain. This approach introduces a key limitation: it exhibit an additional 20% improvement. The GE50 shows a removes the correlation between the number of touched objects slight improvement (around 5%) over GE10, indicating that, at and the execution time. For this reason, we consider Ethereum’s a population of 100, increasing the number of epochs beyond dataset to be synthetic and refer to it as "Ethereum-based". 10 yields limited gains in efficiency. As shown in Figure 7, we measured to what degree For the Ethereum-based dataset, all of the parameters were transactions overlap depending on the order in which they the same, except for execution time, which was set to 1250000 were submitted. The average Jaccard similarity follows a power- to provide the same 50-60% inclusion rate. The results for law decay as a function of transaction distance, with a sharp the Ethereum dataset shown in Figure 9, display smaller initial drop and a heavy tail. This confirms the significance improvements compared to the Sui dataset. GE10 had only of temporal locality and also shows the presence of several a slight improvement over GP, while GE50 had the same frequently touched global objects. proportional improvement, as it did for Sui. We believe that the The prevalence of temporal locality implies that a realistic main reason for this is the difference in gas price distribution. dataset must consist of locally dependent transactions. It cannot The gas prices for Sui have low variance as can be seen in be represented by independent sampling which would lead to Figure 5, while Ethereum’s gas prices are much more varied as a much lower degree of transaction conflicts. Furthermore, the seen in Figure 6. This means that most of the profit is received heavy tail indicates the existence of heavily congested shared by scheduling high-paying transactions. Since the first epochs objects and reaffirms the need for congestion control. of the genetic algorithm focus on global search with random initialization of transaction ordering, the algorithm is much less likely to find better sequences. This is because sequencing B. Sequencing baselines a high-paying transaction late will have a more severe negative We evaluated five different sequencers that rely on heuristics. impact on profit. This is also suggested by Sui sequencer having All of them, except for the one labeled as "Sui", additionally a much better performance in the Ethereum-based dataset than use the gap-filling modification. The sequencers are as follows: it did in the Sui dataset, since it prioritizes gas price. Due to 1) Sui - sequencer that orders transactions by descending elitism, the later epochs focus much more on local search, as the transaction set gets filled with similar transactions. gas price and does not use gap-filling. 2) Gas Price (GP) - sequencer that orders transactions by D. Spike in transactions descending gas price and does use gap-filling. To determine how well the proposed genetic sequencing 3) Lowest Execution Time (LET) - sequencer that orders algorithm works in the scenarios where congestion is not transactions by ascending execution time. sustained, but happens in sporadic bursts, we conducted an 4) Given - sequencer that orders transactions according experiment where initially each block contains a low amount of to the order in which they have been executed on the transactions, then a high number of transactions for some time blockchain. after which it goes back to the initial flow of transactions. We 5) Random - sequencer that shuffles the order of transackept the number of executors at 4 and the execution deadline at tions. 62500 units for Sui dataset. The maximum number of deferrals We evaluated our genetic sequencer with two sets of was set to 200, so that no transactions would get canceled. The parameters to demonstrate the impact of search depth on results showing the absolute number of deferred transactions solution efficiency. for each block for Sui are shown in Figure 10. Here we see 1) Genetic 100/50 (GE50) - genetic sequencer with popula- greater variation in the results of heuristic schedulers. The lack tion of 100 that runs for 50 epochs. of gap filling prevented the Sui sequencer from recovering from 2) Genetic 100/10 (GE10) - genetic sequencer with popula- the congestion. The Given and GP sequencers achieved similar tion of 100 that runs for 10 epochs. results, recovering by block 130. LET and Random sequencers

9

r = 0.02

Gas Price

500000

r = 0.09

10000 slope = 0.00

10000 slope = 0.03

1000

1000

400000 300000 200000 100000

0 10

10

1

0 00 0 10

10

00 0

00

10000

10 10

0

10 10

1

00 10

0 00

00

1000

10

0 00 10

10

= 0.09 100 rslope = 0.30

= 0.46 100000 rslope = 0.47

00

1000

10

10000

= 0.46 100 rslope = 0.45

150000 125000 100000

10

10

75000 50000 25000

1

Execution Time

0

1

00 00 10

00

0

00

0

10

Gas Price

10

00 10

10

0

1

00

Touched Objects

10

10

350000 300000 250000 200000 150000 100000 50000 0

= 0.02 100000 rslope = 0.05

00

Execution Time

10

00 0

00

0

Touched Objects

Fig. 5: Log-scaled distribution and density plots for gas price, execution time, and total number of touched objects per transaction for SUI data. The units of these metrics are defined by the specific blockchain. Includes a least-squares regression fit (slope is indicated) and Pearson correlation (r) for each pair of variables. Plots on the diagonal report the counts for each metric, other plots report the value of a metric depending on another one (e.g., number of touched objects depending on gas price).

recovered around block 90 with LET sequencer showing a more rapid reduction of congestion, but then decreasing more slowly. Both of the genetic sequencers cleared congestion the fastest, with GE50 doing it by block 60 and GE10 by block 70. For the Ethereum-based dataset the parameters were the same, with the only difference of execution deadline being, once again, set to 1250000 units. The results are shown in Figure 11. For the Ethereum-based dataset the congestion was less severe and generally cleared much sooner than in the case of Sui. Besides that, the trend of how quickly sequencers

10

manage to resolve congestion mirrors the Sui results with the exception of Random sequencer performing on par with Given and GP sequencers. This is likely because gas prices do not play a role in this scenario. E. Fair ordering To determine the impact of fair ordering on performance, we conducted the sustained-congestion experiment under the fair ordering constraints. The results for the Sui dataset can be seen in Figure 12 and for the Ethereum-based one in Figure 13. For both cases the fair variants of GP and GE10

400000 350000

100

Gas Price

300000

r = -0.03 slope = -0.03

250000 200000

10

150000 100000 50000

1.0 0 1.0

1e6

120000

r = -0.03 slope = -0.03

Execution Time

0.1 0

10 0

10

1

1e6

0

1

0

100000

1.00

80000 60000 40000

0.10

20000

0

0.1

10

0

10

1

0

Gas Price

1e6

Execution Time

Cumulative Gas Usage (Normalized)

Fig. 6: Log-scaled distribution and density plots for gas price and execution time for Ethereum data. Includes a least-squares regression fit (slope is indicated) and Pearson correlation (r) for each pair of variables.

Avg. Jaccard Similarity

0.065 0.060 0.055 0.050 0.045 0.040 0.035 0

25

50

75

100

125

150

175

Distance between transactions

200

1.4 1.3 1.2 1.1 1.0

25

Sui Gas Price Given

Fig. 7: Average Jaccard similarity (computed over object sets) of transactions based on the distance between them when ordered by execution timestamp. Sample of 50000 random transactions from the full dataset.

50

75

100

125

Block Index

150

Lowest Execution Time Random

175

200

Genetic 100/10 Genetic 100/50

Fig. 8: Total normalized validator profit under sustained congestion of 100 transactions per block for 200 blocks starting at block 20 for Sui dataset.

produce the same results, suggesting that the fair ordering constraint does not leave sufficient room for reordering causally independent transactions, rendering the genetic algorithm ineffective. Additionally, this experiment highlights that under the sustained congestion, the addition of a fair ordering constraint reduces the profit by 50-60%. We attribute this cost to the high rate of transaction interdependence in the dataset, as can be seen in Figure 7.

F. Robustness to execution time estimation errors The most unrealistic assumption that our model hinges on is assuming a perfect prediction of execution time. To check how well the sequencing performs under less accurate prediction of execution time, we repeated the experiments with perturbed transaction execution times. We used the transaction execution times from the data as the predicted execution times

11

Deferred Transactions per Block

Cumulative Gas Usage (Normalized)

1.8 1.6 1.4 1.2 1.0

25

50

Sui Gas Price Given

75

100

125

Block Index

150

Lowest Execution Time Random

175

Cumulative Gas Usage (Normalized)

Deferred Transactions per Block

100

Sui Gas Price Given

75

100

125

Block Index

150

Lowest Execution Time Random

175

0

0

25

50

75

100

125

Block Index

150

Lowest Execution Time Random

175

200

Genetic 100/10 Genetic 100/50

Fig. 11: Total absolute number of transactions deferred under a spike of transactions from block 20 to block 29. With blocks 0-19 having 30 transactions, blocks 20 to 29 having 100 transactions and blocks 30 to 199 having 30 transactions for Ethereum dataset.

200

50

100

Sui Gas Price Given

300

25

200

Genetic 100/10 Genetic 100/50

400

0

300

200

Fig. 9: Total normalized validator profit under sustained congestion of 100 transactions per block for 200 blocks starting at block 20 for Ethereum dataset.

0

400

200

Genetic 100/10 Genetic 100/50

2.2 2.0 1.8 1.6 1.4 1.2 1.0

25

50

Gas Price Fair

Fig. 10: Total absolute number of transactions deferred under a spike of transactions from block 20 to block 29. With blocks 0-19 having 30 transactions, blocks 20 to 29 having 100 transactions and blocks 30 to 199 having 30 transactions for Sui dataset.

75

100

125

Block Index Genetic 100/50

150

175

200

Genetic Fair 100/10

Fig. 12: Total normalized validator profit under sustained congestion of 100 transactions per block for 200 blocks starting at block 20 for Sui dataset. Sequencers include two sequencers with fair ordering constraints and the GE50, the most efficient non-fair sequencer.

for sequencing and when transactions were actually scheduled, scenarios were tested with the addition of perturbation for both we replaced the execution times with their perturbed versions. datasets. The sustained congestion for Sui seen in Figure 14 To generate the perturbed versions of execution times, we and congestion spike for Sui and Ethereum seen in Figures 16 applied a multiplicative scaling factor drawn from a log-normal and 17 showed no statistically significant difference in speed of distribution. For each execution time we sampled a normal congestion clearance compared to the non-perturbed case. The distribution X ∼ N (µ, σ 2 ) and computed eX as a scaling sustained congestion for Ethereum seen in Figure 15 shows factor. We set σ = 0.347 and µ = 0 to get a 2-sigma range that the genetic sequencers performed worse compared to their of around [0.5, 2]. We multiplied the original execution time performance in the analogous experiment without perturbations, by the resulting multiplier. This range was chosen to reflect with only GE50 showing a very slight improvement over GP. realistic prediction errors observed in prior work on execution time estimation for blockchain transactions by de Lima Cabral G. Throughput, latency and full summary et al. [33] as it provides an average absolute error percentage Maximizing throughput and minimizing latency have not of around 28%. been the objectives of this work. Instead of targeting throughput, Both the sustained congestion and the spike in congestion we decided to focus on maximizing validator revenue. This

12

Cumulative Gas Usage (Normalized)

Cumulative Gas Usage (Normalized)

2.75 2.50 2.25 2.00 1.75 1.50 1.25 1.00

25

50

75

Gas Price Fair

100

125

Block Index

150

Genetic 100/50

175

200

2.00 1.75 1.50 1.25 1.00

1.30 1.25 1.20 1.15 1.10 1.05

Sui Gas Price Given

50

75

100

125

Block Index

150

Lowest Execution Time Random

175

50

75

100

125

Block Index

150

Lowest Execution Time Random

175

200

Genetic 100/10 Genetic 100/50

Fig. 15: Total normalized validator profit under sustained congestion of 100 transactions per block for 200 blocks starting at block 20 for Ethereum dataset with perturbed transaction execution times

1.35

25

25

Sui Gas Price Given

Deferred Transactions per Block

Cumulative Gas Usage (Normalized)

2.25

Genetic Fair 100/10

Fig. 13: Total normalized validator profit under sustained congestion of 100 transactions per block for 200 blocks starting at block 20 for Ethereum dataset. Sequencers include two sequencers with fair ordering constraints, Gas Price Fair and Genetic Fair 100/10, and GE50, the most efficient non-fair sequencer.

1.00

2.50

350 300 250 200 150 100 50 0

0

200

Sui Gas Price Given

Genetic 100/10 Genetic 100/50

25

50

75

100

125

Block Index

150

Lowest Execution Time Random

175

200

Genetic 100/10 Genetic 100/50

Fig. 14: Total normalized validator profit under sustained congestion of 100 transactions per block for 200 blocks starting at block 20 for Sui dataset with perturbed transaction execution times

Fig. 16: Total absolute number of transactions deferred under a spike of transactions from block 20 to block 29. With blocks 0-19 having 30 transactions, blocks 20 to 29 having 100 transactions and blocks 30 to 199 having 30 transactions for Sui dataset with perturbed transaction execution times.

more closely aligns with the way transactions are currently ordered on most blockchains. As we do not make any assumptions about the hardware on which sequencing and execution will be run or about the inner workings of the blockchain, we define both throughput and latency as normalized by the time d representing maximum execution time on a single worker. It is equal to 62500 units of execution for the Sui dataset and 1250000 units for the Ethereum-based dataset. Throughput is the average number of transactions executed within this time. We measure latency as the time it takes from transaction sequencing until it has been executed in the units of d. Since our experiments simulated only the sequencing and execution steps,

we assume no additional significant overhead at dissemination and consensus steps and we do not account for the existing latency that they introduce. Additionally, since the simulation has no mechanisms to dynamically vary the time dedicated to sequencing, we assume that in each case sequencing takes time until a worker becomes available. Latency values below 1 indicate early execution due to worker availability. Values between 1 and 2 indicate normal execution, and values above 2 indicate that the transaction has been deferred. Canceled transactions are unaccounted for, meaning that the reported latency does not capture the full cost of congestion for affected users. Results of the experiments are given in Tables III and IV. The

13

Deferred Transactions per Block

a consistent total order among blocks of transactions and to ensure that, without controlling the majority of the network’s hash rate, it would eventually become impossible to undo 300 previous blocks. The order of transactions within a block was then fully determined by the miner that created it. As Bitcoin 200 transactions could only be of two types, Bitcoin transfers between multiple parties and block rewards [41], the ordering of 100 transactions within the block made no difference. Bitcoin uses the Unspent Transaction Output (UTXO) model, in which each 0 transaction consumes previously created outputs and produces 0 25 50 75 100 125 150 175 200 new ones. In this model, since each transaction defines its inputs Block Index and outputs independently, the order of transactions within the Sui Lowest Execution Time Genetic 100/10 block does not play a role, only their inclusion. In practice, Gas Price Random Genetic 100/50 Bitcoin transactions are included and ordered according to Given ancestor-feerate sorting, accounting for dependent transactions Fig. 17: Total absolute number of transactions deferred under through Child-Pays-for-Parent (CPFP) [42]. a spike of transactions from block 20 to block 29. With blocks Ethereum employed the same transaction ordering approach 0-19 having 30 transactions, blocks 20 to 29 having 100 as Bitcoin. However, Ethereum uses an account-based model, transactions and blocks 30 to 199 having 30 transactions for as opposed to UTXO on Bitcoin. In this model transactions Ethereum dataset with perturbed transaction execution times. read and write to shared accounts. This means that the output of a transaction is dependent on the state induced by the previous transaction in the same block. This is further amplified by genetic sequencer consistently achieves the highest validator Ethereum’s use of smart contracts [23] which can execute profit under sustained congestion. It outperforms the GP base- arbitrary logic. This means that different orderings of transacline by 16% for the Sui dataset and 4% for the Ethereum-based tions within a block may lead to different final system state. dataset. For the congestion spike scenario, the genetic sequencer The initial conventional strategy for sequencing transactions clears congestion significantly faster than the baseline, reducing within a block was to order them greedily according to their gas the post-spike recovery time from 60 to 25 blocks on the Sui price, as employed by the most popular Ethereum client, Geth, dataset and from 20 to 8 blocks on the ETH-based dataset, which was used by around 76% of the network’s validators with results being consistent even under perturbation. LET in 2017 [43, 44]. However, as Daian et al. [24] showed does achieve the highest throughput but at a significant cost in their work, strategic rearrangement of transactions by a to validator profit while the genetic sequencer consistently validator and the inclusion of its own transactions could produce improves on the baseline throughput. The latency is broadly significant additional validator profit. Such phenomenon was comparable across non-fair sequencers, though these figures called Miner Extractable Value (MEV). After this issue became should be interpreted cautiously, as the assumption of equal widely known, an entire system of blockspace actions, called sequencing time is unrealistic. In practice the genetic algorithm MEV-boosting, appeared. Transaction order within blocks was will require more computation time than the heuristic baselines. now optimized by separate builder actors in exchange for Fair ordering imposed a profit penalty of approximately 50% a share of the extracted value. MEV-boosting has rapidly and failed to clear congestion on the Sui dataset. gained popularity, with around 90% of blocks being created through MEV-boost by the end of 2022 [45]. The rapid VI. R ELATED W ORK adoption is explained by the fact that MEV revenue aligns To contextualize our contributions, we look at four bodies closely with validator interests, increasing the median validator of related work. First, we examine how transaction sequencing block reward by approximately 250–400%. [46, 47] and thus is done in practice on widely used blockchains, ranging from serving as a further incentive to the builders for participation. full validator reordering freedom to protocol level congestion Nevertheless, the adoption of such a system has significantly control. We then examine the research on fair ordering that undermined transparency and decentralization. MEV was often disregards congestion control for the sake of transparency and extracted by submitting transactions privately to builders or by manipulation-resistance. After that, we examine prior efforts to specifying inclusion requirements called search bundles, such model transaction sequencing as a discrete combinatorial prob- as positioning of transactions [48]. lem. An overview comparing different sequencing approaches Sui is a DAG-based blockchain that differentiates between is given in Table V. Finally, we briefly overview work that owned and shared objects, with owned objects using UTXOfocuses on optimizing transaction execution. like ordering and shared objects using account-like ordering. Transactions touching only owned objects avoid the overhead of A. Sequencing on popular blockchains total ordering, only requiring partial order established by their In Bitcoin, transaction sequencing within a block did not play owner and confirmed by validators. There is still a requirement a major role. The main focus of Bitcoin was initially to maintain to agree on which transaction to accept if there are conflicting 400

14

transactions signed by the owner, which can be done through by modeling block construction as a mixed-integer program certification or consensus. Transactions touching shared objects with validator profit as the objective. In contrast to our work, still require global sequencing relative to one another [49]. they focus on the scheduling layer and assume a predefined Sui’s sequencing is also responsible for congestion control. dependency set, and implicitly enforce an ordering constraint The initial sequencing of transactions is based exclusively analogous to our fair ordering extension. They also propose on gas price. After that the estimated execution time and a sophisticated heuristic for transaction scheduling, which information about touched objects are used to determine which performs the same as a simple greedy gas price heuristic. This transactions to defer to a later commit. The sequencer keeps mirrors our own finding that the genetic algorithm provides no track of the queue per object and processes transactions one by improvement over the gas-price baseline when fair ordering is one. Transactions that do not fit within the execution budget enforced. of objects are deferred [28, 29]. Another work that has major parallels to ours is Conthereum Solana is another popular blockchain that also emphasizes by Chahoki et al. [34], though it diverges in several critical high throughput [50]. Its sequencer went through multiple aspects. In both Conthereum and our work, transaction sequencmajor changes over time. Initially, the sequencer had multiple ing is modeled in a parallel execution setting as a job shop independent transaction queues on each of the threads. Within scheduling problem with full freedom to reorder transactions. one thread the transactions were ordered by gas price, but In their analysis they require that all transactions be scheduled independence of threads meant that there was no global order, and optimize for the makespan within a single block. and transactions were sequenced non-deterministically. A later Our work further differs from both Karmegam et al. and version of the sequencer (update v1.18) first put the transactions Chahoki et al. in two respects. First, we extend the problem to into a max-heap and only then distributed them between threads. a continuous execution setting where execution of successive However, the Solana protocol does not specify how sequencing blocks can overlap. Second, in our experiments we account must occur. This led to the emergence of an alternative Solana for perturbations between expected and actual execution time validator client Jito that uses MEV-boost [51]. This illustrates by applying realistic execution time perturbations. that when transaction sequencing is not specified at the protocol level, economic incentives can often lead validators toward D. Execution Most of the works in this area focus on improving the opaque, profit-maximizing sequencing techniques. execution layer. Pilotfish [13] is a distributed execution engine B. Fair ordering that consists of a cluster of executors where nodes use the The lack of transaction ordering transparency and the use given transaction order and parallelize execution of consecutive of MEV-boosting have motivated research into fair transaction independent transactions by dynamically assigning them to ordering [52]. The main goal of fair transaction ordering is to workers. It focuses on generalizing the transaction execution ensure that the transaction order aligns as closely as possible in a crash-recovery setting while minimizing the message overwith the real-world time at which the transactions have been head. HTFabric and Fabric++ [54, 55], which are extensions of submitted. There are currently two primary approaches to Hyperledger Fabric, go further by reordering transactions during establishing a fair order: ordering linearizability and batch order execution to increase parallelism. In practice, their approach fairness. In ordering linearizability, first defined in Pompe [27], prioritizes independent transactions. Although this improves validators submit timestamps corresponding to when each throughput, it creates a bias against more interdependent transaction was received, and transactions are then ordered transactions. based on the median of collected timestamps. In batch order While these works have primarily relied on explicitly fairness systems, such as Themis [26], each validator submits declared sets of touched objects, other work has parallelized an ordering of transactions. The final ordering is then achieved execution without requiring such declarations in advancey. by combining validators’ individual orderings. Anjana et al. [56] apply software transactional memory (STM) Fair ordering ensures fairness at the protocol level and to maximize parallelism at the cost of redundant computation by helps mitigate MEV-boosting. However, it generates a very speculatively executing transactions in parallel and rolling back rigid transaction order, provides no mechanism for congestion in case of conflicts. Block-STM [19] refines this by updating the estimated dependency sets after each rollback, reducing control, and does not take into account validator incentives. unnecessary re-executions. C. Combinatorial optimization for sequencing VII. D ISCUSSION Under a deterministic scheduling algorithm, transaction sequencing is equivalent to determining block building. If all transactions must be executed sequentially and if we assume that the execution time of transactions is independent of their position in the sequence, the problem is equivalent to the knapsack problem, meaning that it is NP-hard [35]. A concurrent and independently motivated work by Karmegam et al. [53] takes a similar approach to our work

The performance of the sequencing step was evaluated under existing transaction data. This means that the submitted transactions did not account for the degree of congestion that they might cause when specifying a gas price, as evidenced by the lack of correlation between gas price and number of touched objects as seen in Figures 5 and 6. With the introduction of this step, transactions may start to account for this and

15

adjust their gas prices accordingly. Moreover, in this work we considered only a static gas fee as specified by the user submitting the transaction. Recent work has explored multidimensional and dynamic pricing mechanisms better suited for parallel execution environments [57, 58]. Further research into how our sequencing approach interacts with such pricing models would be valuable. In this work, we relied on the definition of fair ordering that first imposes a total order on the transactions, from which we derived a causal order. Another approach for achieving total order is batch order fairness [26]. This approach might lead to the creation of dependency cycles and would allow us to choose how they are resolved. This might lead to better performance if there are many cycles, but in practice, under realistic assumptions where the majority of nodes try their best to order transactions according to their real-world timestamps, such cycles are exceedingly rare and are unlikely to lead to a major improvement. In this work, we propose a genetic algorithm for sequencing transactions. This represents one approach; there are other methods, such as GRASP or simulated annealing. The primary objective of this work was to demonstrate the value of the sequencing step. Our results show that even a straightforward approach can lead to a significant improvement. VIII. C ONCLUSION

[3]

[4]

[5]

[6]

[7] [8]

[9]

[10]

In this work, we have formalized a blockchain-independent model for evaluating the impact of transaction ordering on validator profit and congestion clearance speed. We then extended this model to account for continuity of execution. We proposed a genetic ordering algorithm that takes into account transaction execution time estimates and object conflict information. Our results demonstrate that this approach outperforms the heuristic baseline, increasing validator profit by approximately 15%, and improves congestion control in a high congestion scenario. We have also shown that the performance of this approach does not degrade significantly under realistic execution time estimation errors for the purpose of congestion control. Performance also does not degrade significantly in terms of profit maximization when gas prices exhibit little variation. We also integrated a fair ordering constraint and found that under such an assumption, sequencing provides no benefit. Moreover, we found that by introducing fair ordering, validators lose around 50 to 60% of their profit under sustained congestion.

[11]

[12]

[13] [14]

[15]

R EFERENCES [1]

[2]

W. Li and M. He. “Comparative Analysis of Bitcoin, Ethereum, and Libra”. In: 2020 IEEE 11th International Conference on Software Engineering and Service Science (ICSESS). 2020, pp. 545–550. K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena, E. Shi, E. Gün Sirer, D. Song, and R. Wattenhofer. “On Scaling Decentralized Blockchains”. In: Financial Cryptography and Data Security. Berlin, Heidelberg: Springer Berlin Heidelberg, 2016, pp. 106–125.

16

[16] [17]

G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman. “Narwhal and tusk: a dag-based mempool and efficient bft consensus”. In: Proceedings of the Seventeenth European Conference on Computer Systems. 2022, pp. 34–50. Y. Gao, Y. Lu, Z. Lu, Q. Tang, J. Xu, and Z. Zhang. “Dumbong: Fast asynchronous bft consensus with throughput-oblivious latency”. In: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 2022, pp. 1187– 1201. A. Spiegelman, N. Giridharan, A. Sonnino, and L. KokorisKogias. “Bullshark: Dag bft protocols made practical”. In: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 2022, pp. 2705–2718. Y. Hao, Y. Li, X. Dong, L. Fang, and P. Chen. “Performance Analysis of Consensus Algorithm in Private Blockchain”. In: 2018 IEEE Intelligent Vehicles Symposium (IV). 2018, pp. 280– 285. I. Keidar, E. Kokoris-Kogias, O. Naor, and A. Spiegelman. “All you need is dag”. In: Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing. 2021, pp. 165–175. G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman. “Narwhal and Tusk: a DAG-based mempool and efficient BFT consensus”. In: Proceedings of the Seventeenth European Conference on Computer Systems. EuroSys ’22. Rennes, France: Association for Computing Machinery, 2022, pp. 34–50. URL: https://doi.org/10.1145/3492321.3519594. K. Babel, A. Chursin, G. Danezis, A. Kichidis, L. KokorisKogias, A. Koshy, A. Sonnino, and M. Tian. “Mysticeti: Reaching the Latency Limits with Uncertified DAGs.” In: NDSS. 2025. N. Polyanskii, S. Müller, and I. Vorobyev. “Starfish: A high throughput BFT protocol on uncertified DAG with linear amortized communication complexity”. In: IACR Cryptol. ePrint Arch. 2025 (2025), p. 567. URL: https://api.semanticscholar. org/CorpusID:277637515. L. García-Bañuelos, A. Ponomarev, M. Dumas, and I. Weber. “Optimized execution of business processes on blockchain”. In: Business Process Management: 15th International Conference, BPM 2017, Barcelona, Spain, September 10–15, 2017, Proceedings 15. Springer. 2017, pp. 130–146. E. Albert, P. Gordillo, A. Hernández-Cerezo, A. Rubio, and M. A. Schett. “Super-optimization of smart contracts”. In: ACM Transactions on Software Engineering and Methodology (TOSEM) 31.4 (2022), pp. 1–29. Q. Kniep, L. Kokoris-Kogias, A. Sonnino, I. Zablotchi, and N. Zhang. Pilotfish: Distributed Execution for Scalable Blockchains. 2025. arXiv: 2401.16292 [cs.DC]. M. J. Amiri, D. Agrawal, and A. E. Abbadi. “ParBlockchain: Leveraging Transaction Parallelism in Permissioned Blockchain Systems”. In: CoRR abs/1902.01457 (2019). arXiv: 1902 . 01457. P. Ruan, D. Loghin, Q.-T. Ta, M. Zhang, G. Chen, and B. C. Ooi. “A Transactional Perspective on Execute-order-validate Blockchains”. In: Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. SIGMOD ’20. Portland, OR, USA: Association for Computing Machinery, 2020, pp. 543–557. URL: https://doi.org/10.1145/3318464. 3389693. C. Cachin et al. “Architecture of the hyperledger blockchain fabric”. In: Workshop on distributed cryptocurrencies and consensus ledgers. Vol. 310. 4. Chicago, IL. 2016, pp. 1–4. T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen. “Adding Concurrency to Smart Contracts”. In: Proceedings of the ACM Symposium on Principles of Distributed Computing. PODC ’17. Washington, DC, USA: Association for Computing Machinery, 2017, pp. 303–312. URL: https://doi.org/10.1145/ 3087801.3087835.

[18] [19]

[20]

[21]

[22] [23] [24]

[25]

[26]

[27]

[28] [29] [30]

[31]

[32]

[33]

[34]

S. Das, V. Krishnan, and L. Ren. Efficient Cross-Shard Transaction Execution in Sharded Blockchains. 2021. arXiv: 2007.14521 [cs.CR]. R. Gelashvili, A. Spiegelman, Z. Xiang, G. Danezis, Z. Li, D. Malkhi, Y. Xia, and R. Zhou. “Block-stm: Scaling blockchain execution by turning ordering curse to a performance blessing”. In: Proceedings of the 28th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming. 2023, pp. 232–244. F. Ezard, C. U. Ileri, and J. Decouchant. “NEMO: Faster Parallel Execution for Highly Contended Blockchain Workloads”. In: 2025 7th Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS). IEEE. 2025, pp. 1–5. S. Blackshear, A. Chursin, G. Danezis, A. Kichidis, L. KokorisKogias, X. Li, M. Logan, A. Menon, T. Nowacki, A. Sonnino, B. Williams, and L. Zhang. Sui Lutris: A Blockchain Combining Broadcast and Consensus. 2024. arXiv: 2310.18042 [cs.DC]. S. Foundation. Sealevel - Parallel Processing Thousands of Smart Contracts. Sept. 2019. V. Buterin. Ethereum White Paper: A Next Generation Smart Contract & Decentralized Application Platform. 2013. URL: https://github.com/ethereum/wiki/wiki/White-Paper. P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Breidenbach, and A. Juels. “Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability”. In: 2020 IEEE symposium on security and privacy (SP). IEEE. 2020, pp. 910–927. B. Nasrulin, G. Ishmaev, J. Decouchant, and J. Pouwelse. “Lo: An accountable mempool for mev resistance”. In: Proceedings of the 24th international middleware conference. 2023, pp. 98– 110. M. Kelkar, S. Deb, S. Long, A. Juels, and S. Kannan. “Themis: Fast, strong order-fairness in byzantine consensus”. In: Proceedings of the 2023 acm sigsac conference on computer and communications security. 2023, pp. 475–489. Y. Zhang, S. Setty, Q. Chen, L. Zhou, and L. Alvisi. “Byzantine ordered consensus without byzantine oligarchy”. In: 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 2020, pp. 633–649. S. Foundation. Streamlining Transactions with Sui’s Shared Object Congestion Control. Sui Blog. Sept. 2024. URL: https: //blog.sui.io/shared-object-congestion-control/. S. Foundation. Object-Based Local Fee Markets. Sui Documentation. 2024. URL: https://docs.sui.io/guides/developer/ objects/local-fee-markets. C. U. Ileri, A. Cullen, O. Saa, R. Overko, and L. Vigneri. “Enhanced Transaction Sequencing for Modular Distributed Ledgers”. In: 2025 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). IEEE. 2025, pp. 1–3. S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev, E. Marchenko, and Y. Alexandrov. “Smartcheck: Static analysis of ethereum smart contracts”. In: Proceedings of the 1st international workshop on emerging trends in software engineering for blockchain. 2018, pp. 9–16. A. Z. Chahoki and M. Roveri. “Static analysis for detecting transaction conflicts in ethereum smart contracts”. In: arXiv preprint arXiv:2507.04357 (2025). arXiv: 2507.04357 [cs.DC]. D. R. de Lima Cabral, P. Antonino, and A. C. A. Sampaio. “Demystification and near-perfect estimation of minimum gas limit and gas used for Ethereum smart contracts”. In: Journal of Cloud Computing 14.1 (2025), p. 29. A. Z. Chahoki, M. Herlihy, and M. Roveri. “Conthereum: Concurrent ethereum optimized transaction scheduling for multi-core execution”. In: 2025 7th Conference on Blockchain

17

[35]

[36]

[37]

[38] [39] [40] [41] [42]

[43] [44]

[45] [46] [47]

[48] [49] [50] [51] [52] [53]

Research & Applications for Innovative Networks and Services (BRAINS). IEEE. 2025, pp. 1–10. S. Dos Santos, C. Chukwuocha, S. Kamali, and R. K. Thulasiram. “An Efficient Miner Strategy for Selecting Cryptocurrency Transactions”. In: 2019 IEEE International Conference on Blockchain (Blockchain). 2019, pp. 116–123. R. Cheng, M. Gen, and Y. Tsujimura. “A tutorial survey of job-shop scheduling problems using genetic algorithms—I. representation”. In: Computers & Industrial Engineering 30.4 (1996), pp. 983–997. URL: https://www.sciencedirect.com/ science/article/pii/0360835296000472. B. A. Julstrom. “Seeding the population: improved performance in a genetic algorithm for the rectilinear Steiner problem”. In: Proceedings of the 1994 ACM Symposium on Applied Computing. SAC ’94. Phoenix, Arizona, USA: Association for Computing Machinery, 1994, pp. 222–226. URL: https : //doi.org/10.1145/326619.326728. L. Davis et al. “Applying adaptive algorithms to epistatic domains.” In: IJCAI. Vol. 85. 1985, pp. 162–164. K. Jebari, M. Madiafi, et al. “Selection methods for genetic algorithms”. In: International Journal of Emerging Sciences 3.4 (2013), pp. 333–344. K. A. D. Jong. “An Analysis Of The Behavior Of A Class Of Genetic Adaptive Systems”. In: 1975. URL: https://api. semanticscholar.org/CorpusID:57626488. S. Nakamoto. Bitcoin whitepaper. 2008. URL: https://bitcoin. org/bitcoin.pdf. J. Messias, M. Alzayat, B. Chandrasekaran, K. P. Gummadi, P. Loiseau, and A. Mislove. “Selfish & opaque transaction ordering in the Bitcoin blockchain: the case for chain neutrality”. In: Proceedings of the 21st ACM Internet Measurement Conference. 2021, pp. 320–335. S. K. Kim, Z. Ma, S. Murali, J. Mason, A. Miller, and M. Bailey. “Measuring ethereum network peers”. In: Proceedings of the Internet Measurement Conference 2018. 2018, pp. 91–104. go-ethereum contributors. go-ethereum miner/worker.go (commit 290e851). 2017. URL: https : / / github . com / ethereum / go - ethereum / blob / 290e851f57f5d27a1d5f0f7ad784c836e017c337 / miner / worker.go. B. Öz, D. Sui, T. Thiery, and F. Matthes. “Who wins ethereum block building auctions and why?” In: (2024). arXiv: 2407. 13931 [cs.DC]. Nero.eth. Is it worth using MEV-Boost? June 2024. URL: https: //ethresear.ch/t/is-it-worth-using-mev-boost/19753. D. Mancino, A. Leporati, M. Viviani, and G. Denaro. “A Role and Reward Analysis in Off-Chain Mechanisms for Executing MEV Strategies in Ethereum Proof-of-Stake”. In: Distrib. Ledger Technol. 4.3 (Aug. 2025). URL: https://doi.org/ 10.1145/3672405. Flashbots. Understanding Bundles. 2025. URL: https://docs. flashbots.net/flashbots- mev- share/searchers/understandingbundles. R. Overko. “A Study on Shared Objects in Sui Smart Contracts”. In: 2024 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). 2024, pp. 1–7. A. Yakovenko. Solana: A new architecture for a high performance blockchain v0. 8.13. 2018. URL: https://solana.com/ solana-whitepaper.pdf. Lostin. The Truth about Solana Local Fee Markets. Jan. 2025. URL: https://www.helius.dev/blog/solana-local-fee-markets. M. Kelkar, S. Deb, and S. Kannan. “Order-fair consensus in the permissionless setting”. In: Proceedings of the 9th ACM on ASIA Public-Key Cryptography Workshop. 2022, pp. 3–14. A. Karmegam, L. Kiffer, and A. F. Anta. Exploiting Multi-Core Parallelism in Blockchain Validation and Construction. 2026. arXiv: 2602.03444 [cs.DC].

[54]

J. Song, J. Jeong, J. Lee, I. Na, and M.-S. Kim. “HTFabric: A Fast Re-ordering and Parallel Re-execution Method for a High-Throughput Blockchain”. In: Proceedings of the 33rd ACM International Conference on Information and Knowledge Management. CIKM ’24. Boise, ID, USA: Association for Computing Machinery, 2024, pp. 2118–2127. URL: https://doi. org/10.1145/3627673.3679606. [55] A. Sharma, F. M. Schuhknecht, D. Agrawal, and J. Dittrich. “Blurring the Lines between Blockchains and Database Systems: the Case of Hyperledger Fabric”. In: Proceedings of the 2019 International Conference on Management of Data. SIGMOD ’19. Amsterdam, Netherlands: Association for Computing

18

Machinery, 2019, pp. 105–122. URL: https://doi.org/10.1145/ 3299869.3319883. [56] P. S. Anjana, S. Kumari, S. Peri, S. Rathor, and A. Somani. An Efficient Framework for Optimistic Concurrent Execution of Smart Contracts. 2019. arXiv: 1809.01326 [cs.DC]. [57] B. Acilan, A. Constantinescu, L. Heimbach, and R. Wattenhofer. “Transaction fee market design for parallel execution”. In: (2025). arXiv: 2502.11964 [cs.DC]. [58] S. Wadhwa, A. Yaish, F. Zhang, and K. Nayak. Perils of Parallelism: Transaction Fee Mechanisms under Execution Uncertainty. 2026. URL: https://eprint.iacr.org/2026/649.

TABLE III: Results of experiments with continued congestion. Throughput is measured as the number of transactions that are scheduled in a block. The normalized amount of gas used represents the perceived revenue, which we aim to maximize. Latency is measured as a multiple of the number of blocks from the start of sequencing to the end of execution. Sequencer No Perturbation Sui Gas Price Given Lowest Execution Time Random Fair Highest gas price Genetic 100/10 Genetic 100/50 Fair Genetic 100/10 With Perturbations Sui Gas Price Given Lowest Execution Time Random Fair Highest gas price Genetic 100/10 Genetic 100/50 Fair Genetic 100/10 No Perturbation Sui Gas Price Given Lowest Execution Time Random Fair Highest gas price Genetic 100/10 Genetic 100/50 Fair Genetic 100/10 With Perturbations Sui Gas Price Given Lowest Execution Time Random Fair Highest gas price Genetic 100/10 Genetic 100/50 Fair Genetic 100/10

Throughput ↑ Sui

Norm. Gas Used ↑

Latency ↓

70.32 ± 1.18 86.60 ± 1.31 76.58 ± 1.23 101.58 ± 0.80 77.29 ± 1.32 52.95 ± 0.96 95.59 ± 1.16 99.89 ± 1.12 52.96 ± 0.95

1.41 ± 0.03 1.76 ± 0.03 1.49 ± 0.02 1.49 ± 0.01 1.53 ± 0.02 1.00 ± 0.02 1.97 ± 0.03 2.04 ± 0.03 1.00 ± 0.02

1.27 ± 0.02 1.20 ± 0.02 1.02 ± 0.02 0.90 ± 0.01 2.04 ± 0.02 2.76 ± 0.10 1.56 ± 0.02 1.45 ± 0.02 2.60 ± 0.11

74.51 ± 1.10 88.80 ± 1.20 81.69 ± 1.13 109.81 ± 0.91 83.53 ± 1.24 59.53 ± 0.97 93.36 ± 1.17 96.69 ± 1.23 59.54 ± 0.97 ETH-based

1.42 ± 0.04 1.71 ± 0.04 1.50 ± 0.03 1.40 ± 0.02 1.58 ± 0.03 1.00 ± 0.01 1.86 ± 0.04 1.90 ± 0.04 1.00 ± 0.01

1.10 ± 0.02 1.10 ± 0.02 0.93 ± 0.02 1.10 ± 0.01 1.83 ± 0.02 2.03 ± 0.07 1.53 ± 0.02 1.54 ± 0.02 2.03 ± 0.07

68.99 ± 1.22 90.08 ± 1.52 90.89 ± 1.90 125.83 ± 1.07 89.02 ± 1.66 62.67 ± 1.57 93.50 ± 1.45 97.47 ± 1.55 62.75 ± 1.57

2.14 ± 0.15 2.39 ± 0.16 1.47 ± 0.07 1.61 ± 0.07 1.61 ± 0.07 1.00 ± 0.05 2.43 ± 0.15 2.49 ± 0.16 1.00 ± 0.05

1.35 ± 0.02 1.17 ± 0.02 1.07 ± 0.01 1.05 ± 0.01 2.17 ± 0.02 3.09 ± 0.09 1.26 ± 0.02 1.23 ± 0.02 2.99 ± 0.09

74.67 ± 1.22 96.60 ± 1.55 96.66 ± 1.69 129.37 ± 0.90 96.56 ± 1.53 68.92 ± 1.45 96.95 ± 1.45 100.05 ± 1.49 68.95 ± 1.45

2.01 ± 0.27 2.19 ± 0.27 1.36 ± 0.18 1.31 ± 0.13 1.41 ± 0.16 1.00 ± 0.16 2.19 ± 0.27 2.23 ± 0.27 1.00 ± 0.16

1.28 ± 0.02 1.10 ± 0.02 1.08 ± 0.02 1.03 ± 0.01 2.03 ± 0.02 2.79 ± 0.08 1.27 ± 0.02 1.28 ± 0.02 2.78 ± 0.07

19

TABLE IV: Results of experiments with a spike in the number of transactions. Throughput is measured as the number of transactions that are scheduled in a block. Number of blocks to recover from congestion represents the count of consecutive blocks after congestion ends until a block is produced with no deferred transactions. Latency is measured as a multiple of the number of blocks from the start of sequencing to the end of execution. Sequencer No Perturbation Sui Gas Price Given Lowest Execution Time Random Fair Highest gas price Genetic 100/10 Genetic 100/50 Fair Genetic 100/10 With Perturbations Sui Gas Price Given Lowest Execution Time Random Fair Highest gas price Genetic 100/10 Genetic 100/50 Fair Genetic 100/10 No Perturbation Sui Gas Price Given Lowest Execution Time Random Fair Highest gas price Genetic 100/10 Genetic 100/50 Fair Genetic 100/10 With Perturbations Sui Gas Price Given Lowest Execution Time Random Fair Highest gas price Genetic 100/10 Genetic 100/50 Fair Genetic 100/10

Throughput ↑

# Blocks to recover from congestion ↓ Sui

Latency ↓

32.39 ± 0.57 33.48 ± 0.74 33.49 ± 0.69 33.49 ± 0.84 33.49 ± 0.76 27.95 ± 0.74 33.50 ± 0.80 33.50 ± 0.88 27.95 ± 0.74

Did not recover 60 57 162 66 Did not recover 32 25 Did not recover

3.82 ± 0.30 2.20 ± 0.19 2.38 ± 0.27 1.34 ± 0.08 2.52 ± 0.18 21.68 ± 0.84 1.40 ± 0.09 1.19 ± 0.07 21.26 ± 0.86

32.63 ± 0.65 33.48 ± 0.76 33.49 ± 0.70 33.50 ± 0.91 33.50 ± 0.81 26.64 ± 0.78 33.50 ± 0.91 33.50 ± 0.84 26.64 ± 0.78

Did not recover 59 62 126 88 Did not recover 28 25 Did not recover ETH-based

3.94 ± 0.27 2.13 ± 0.18 2.09 ± 0.21 1.23 ± 0.06 2.32 ± 0.15 28.16 ± 1.17 1.29 ± 0.06 1.24 ± 0.06 28.08 ± 1.18

33.49 ± 0.64 33.50 ± 0.80 33.50 ± 0.79 33.50 ± 0.96 33.50 ± 0.83 33.50 ± 0.84 33.50 ± 0.89 33.50 ± 0.97 33.50 ± 0.84

62 20 20 23 21 81 10 8 81

2.80 ± 0.31 1.28 ± 0.11 1.35 ± 0.12 0.86 ± 0.04 1.35 ± 0.10 3.64 ± 0.33 1.00 ± 0.06 0.98 ± 0.04 3.49 ± 0.33

33.50 ± 0.62 33.50 ± 0.88 33.50 ± 0.84 33.50 ± 0.97 33.50 ± 0.83 33.39 ± 0.96 33.50 ± 0.91 33.50 ± 0.99 33.39 ± 0.96

72 15 15 18 14 82 9 5 82

3.14 ± 0.34 1.19 ± 0.11 1.27 ± 0.13 0.89 ± 0.03 1.21 ± 0.07 4.96 ± 0.38 1.01 ± 0.05 0.95 ± 0.03 4.98 ± 0.38

20

TABLE V: Comparison of different transaction sequencing approaches. Gives an overview of the criteria used for transaction ordering and evaluates to which extent the resulting orderings are deterministic, are resistant to manipulation, specifically preventing validators from arbitrarily reordering transactions to their own advantage, and are aligned with validator incentives. System

Ordering Criteria

Determinism

Manipulation Resistance

Validator Alignment

Bitcoin

CPFP

High

Moderate

High

Eth (pre-MEV)

Gas price

High

Low

Moderate

Eth (MEV-Boost)

Builder bid

Low

Low

Very High

Sui

Gas price

High

High

Moderate

Solana (<v1.18)

Priority fee (per-thread)

Low

Low

Low

Solana (>v1.18)

Priority fee (global heap) / Builder bid

Moderate

Moderate

High

Fair Ordering

Arrival timestamps

Very High

Very High

Low

Proposed and Conthereum

Gas price + execution time + touched objects

High

High

High

21