Analyzing Solana’s Blocks and Transactions Yaron Hay , Dvir David Biton , and Roy Friedman
arXiv:2609.35171v1 [cs.DC] 28 Sep 2026
Technion - Israel Institute of Technology
Abstract. Solana is one of the most popular blockchains, and is arguably the most widely used blockchain for smart contracts, also known as dApps. Understanding the types of smart contracts that are being executed by Solana and their interplay is therefore highly beneficial both for designers of modern blockchains and developers of smart contracts. To that end, in this paper we analyze a million recent Solana blocks. We report statistics about the size of blocks (number of transactions per block), execution time units for individual transactions and fees, and invoked Solana programs. Further, based on the declared readset and writeset of each transaction, as mandated by Solana, we analyze the conflicts and corresponding conflict graphs arising within each block. These latter statistics are important to understand the potential for parallelism in the network, which is one of the main claimed benefits of Solana. The data [53] and code [20] are available in open source.
1
Introduction
Many modern blockchains support smart contract execution, which enables extending their utility beyond simple asset transfers, and turn them into general purpose decentralized applications execution engines. A key distinction between blockchains and traditional distributed databases is that blockchain replicas do not mutually trust one another. As a result, each replica. commonly referred to as a miner or validator, must independently execute and verify every transaction. While blockchain performance was historically constrained by inefficient consensus protocols, modern consensus mechanisms are capable of ordering hundreds of thousands of transactions per second [5,6,11,15,16,24,48,50,54]. Consequently, transaction execution and validation have emerged as the primary performance bottlenecks [27]. Understanding the types of transactions executed on a blockchain, their object access patterns, and the resulting inter-transaction conflicts is key to optimizing performance. For example, being able to predict which objects will be accessed allows for pre-warming, which can reduce execution latency. Parallel execution is another established technique for improving performance [2,17,23,26,29] [33,36,37,42,45,52]. However, to ensure correctness, concurrent execution of transactions within a block must be deterministically serializable [37,44]; that is, all validators must observe executions equivalent to the same logical sequential order. Consequently, the degree of achievable parallelism is inherently constrained by transaction conflicts. Identifying transaction types or objects responsible for
a significant share of these conflicts can therefore inform targeted optimizations, such as redesigning smart contract logic to reduce contention. In addition, understanding how the distribution of transactions’ execution times can help with resources planning at validator nodes. Understanding the fee distribution can potentially help users optimize their code structure and improve their pricing strategies, as well as expose anomalies. In this work, we analyze transactions from the Solana blockchain [22]. Solana is a highly popular blockchain in terms of transactions volume and marketcap, and arguably the most widely used platform for smart contracts. Solana avoids sharding, and instead relies on a parallelization engine to expedite local execution [52]. In order to facilitate this, Solana also mandates pre-declaration of readsets and writesets, which simplifies the task of detecting potential conflicts between transactions within the same block. Hence, we have downloaded and analyzed one million recent Solana blocks (at the time of writing), and report our findings below. Summary of Findings – While the execution time of individual transactions seems to be inversely proportional to the total block size, transactions’ fees do not correlate to the block size1 . – Most Solana blocks exhibit a low number of conflicts. This is likely due to its unique mechanism for choosing each block’s transactions (as explained in the paper). – While Solana is effective in reducing conflicts, it incurs long conflict chains, This echoes results reported in [4]. – Conflicting transactions tend to form a near clique among each other, and in particular, in large blocks, most of them belong to the same very large (near) clique structure. – The coloring based approach of [29,40] to parallelizing transaction execution can potentially improve block execution time by a factor of 1.2-3 times (up to 10 in extreme cases) compared to the current arbitrary block order. – The number of transactions that invoke non-standard programs is nonnegligible, meaning that many transactions invoke user defined smart contracts. – The are multiple non-standard programs that are invoked by multiple transactions, indicating that some of these user defined smart contracts are fairly popular. Further, this number grows with the conflict rate, indicating that most conflicts are generated by such programs. – On average, each transaction invokes more than one program, but less than three. – Each transaction accesses between 2-10 true data items (not programs) for read only purposes. 1
See explanation in Section 6.2.
2
2
Related Work
The work of [9] investigates conflict graphs arising from transactions bundled within the same Ethereum block and examines how these conflicts affect the potential performance gains achievable through transaction parallelism, and a similar analysis for Sui was given in [8]. Several of the metrics considered in this paper overlap with those studied in [8,9,30], though not all. Additionally, [43] shows that the proportion of conflicting Ethereum transactions increased between 2016 and 2017, substantially limiting the effectiveness of optimistic concurrency control. Further analyses of other aspects of the Ethereum network can be found in, for example, [7,19,35,38,41,55]. Further, the work of [4] has analyzed both Ethereum and Solana blocks in terms of their parallelization potential. Specifically, for each of these two blockchains, they have downloaded 1,000 blocks from each of three historical periods: ”old”, ”mid”, and ”recent”. They have explored various statistics, and in particular the length of the longest chains of conflicting transactions within a block. They have discovred that Ethereum blocks frequently achieve high independence, i.e., over 50% in more than 50% of blocks, while Solana blocks contain longer conflict chains, comprising ≈59% of the block size compared to ≈18% in Ethereum. In this work, we have downloaded a significantly larger number of blocks. Also, we have also measured the execution time units and gas distribution of transactions, as well as the chromatic number of the undirected conflict graphs, which indicates the maximal potential speedup that can be obtained from parallelism [29]. The difference between the long conflict chains in Solana and the coloring numbers we have found indicates that replacing the reliance on the arbitrary block order with a minimal coloring driven order can substantially reduce the total block execution time in Solana. Prior work has studied transaction parallelism in blockchains [2,37] and in Byzantine fault-tolerant state machine replication systems more generally [21,33]. Many modern blockchains employ parallel execution, for example [26,36,45,49,52]. Most approaches require transactions to declare their read and write sets in advance, while some use optimistic ordered execution instead [26]. In these systems, conflicting transactions must commit in the order in which they appear in the block. In contrast, [29] shows that coloring the conflict graph and ordering transactions by color can yield significant performance gains, proportional to the ratio between the graph’s chromatic number and its longest simple path. We find that this effect also holds for Solana. Several studies evaluating deterministic concurrency control mechanisms for blockchains rely on synthetic workloads, such as randomized peer-to-peer balance transfers [2], randomized multi-input multi-output transfer transactions [26], and synthetic smart contracts [17]. Deterministic databases [1,34,39] are closely related to blockchain systems; however, they typically do not target Byzantine fault tolerance, operate with a small number of replicas, and focus primarily on traditional database benchmarks such as TPC-C [13], TPC-E [14], and YCSB [12]. The Diablo benchmark [27] can be used to stress-test the raw performance of 3
Fig. 1: An example of a conflict graph derived from a block’s transactions based on the transactions’ writesets and readsets.
blockchains, but it does not capture realistic access patterns or transaction conflicts. Additional works, such as [28,37], adopt a database-oriented perspective to design scalable blockchain systems. These studies evaluate the performance of their prototypes using artificial benchmarks and experimental settings. We further note that blockchain performance can be improved by offloading smart contract execution to off-chain components [3,51]. However, such approaches are orthogonal to our goal of understanding on-chain transaction behavior and leveraging this understanding to improve on-chain performance.
3
Preliminaries
A block B consists of a set T of n transactions. Each transaction tx ∈ T is an atomic execution of a smart contract invocation or a simple transfer, which accesses some of the blockchain’s objects; transactions may access such objects for both reading and writing purposes. In Solana, transactions should pre-declare their readsets and writesets. Conflicts and Conflict Graphs For any transaction tx ∈ T , we define its read set as the set of objects accessed for reading during its execution, and its write set as the set of objects it write to. Following standard database terminology, two transactions tx1 ∈ T and tx2 ∈ T are said to conflict if they both access a common object and at least one of them performs a write. For a block B, we construct the conflict graph by adding an undirected edge between every pair of conflicting transactions. This is illustrated in Figure 1. Conflicts are fundamental in parallel blockchains, which provide replicated state machine semantics with atomic transaction execution [44]. Consequently, 4
parallel execution must preserve deterministic serializability [25,29]. One common approach is to disallow concurrent execution of conflicting transactions. Alternatively, optimistic concurrency control can be used, but it may require transaction aborts and re-execution, which are difficult to realize deterministically [26]. Graph Properties Graphs admit a wide range of structural characterizations. In this work, we analyze key properties of the conflict graphs generated by Solana blocks, with particular focus on those that fundamentally constrain transaction parallelism under serializability requirements [25]. Density: The ratio of the number of edges to the maximum possible number of edges in an undirected graph. Recall that edges represent conflicts. Hence, low density means few conflicts, while high density indicates many conflicts. Diameter: The longest of the shortest paths between each pair of nodes in the graph. Max degree: As its name suggests, the maximum degree among all nodes in the cluster. Together with diameter, can predict other graph properties. For example, a very small diameter with a high max degree is indicative of a star shaped graph. Mean degree: The mean degree of a graph is the average degree across all its nodes. A large gap between the mean and max degree suggests a star-like structure, where few high degree hubs dominate an otherwise sparse graph. Cluster coefficient: This measure captures the degree to which nodes in a graph tend to cluster together. For our purposes, suppose transaction tx1 conflicts with tx2 , and tx2 conflicts with tx3 . A high clustering coefficient would indicate that tx1 is also likely to conflict with tx3 . Assortativity: The tendency of nodes with similar properties to connect to one another. In this context, degree assortativity captures the extent to which the likelihood of two transactions conflicting is positively correlated with their graph properties, such as node degree and neighborhood. Chromatic number: The minimum number of colors required to color the nodes of a graph so that no two adjacent nodes share the same color. As shown in [29], the chromatic number of the conflict graph indicates the maximal attainable speedup from parallelism while preserving deterministic serializability. Clique number: The size of the largest complete subgraph (clique), in which every pair of nodes is connected by an edge. This quantity provides a lower bound on the chromatic number. Longest simple path: The length of the longest path in the graph that does not revisit any node. As shown in [29], this metric captures the maximum latency required to execute all transactions under naı̈ve parallelization strategies. Because computing the longest simple path is NP-hard, we obtain a practical lower bound by performing multiple random traversals and recording the longest path observed [18]. 5
Largest connected component: The size of the largest subset of nodes such that there exists a path between any two nodes in this subset. This serves as an upper bound for the longest simple path.
4
Solana
Solana is a decentralized platform that facilitates P2P transactions while supporting the execution of on-chain programs. Solana differs from other modern blockchains by using the account model as well as having an architecture that embraces parallelism, which tends to reduce the number of conflicts between transactions placed within the same block. Account Model Everything in Solana is addressed as an account, whether it is data or programs. Each account is idenfified through a unique account address. An account maintains the following fields: – lamports - the amount of lamports (Solana’s smallest currency unit) the account holds. – data - the account data. – owner - the id of the program that owns the account. – executable - a biary that indicates if this a a program or data item. When the account is a program, its data field either contains the code or the address of the code. Otherwise, it contains the accounts data, which is a stream of bytes that needs to be deserialized in order to be used. Programs Smart contracts are called programs, which are compiled through LLVM into Solana Bytecode Format (sBPF) files or native. Programs are stateless and are often written in Rust. Transactions include invocations of one or more instructions from such programs, and must declare their readset and writeset in advance. Blocks and Slots As in many blockchains, transactions in Solana are divided into blocks. Time is divided into slots, with a target duration of 400ms, during which a single validator is designated as the leader. The same validator serves as the leader for consecutive 4 slots. Issued transactions are forwarded directly to the current or closely scheduled leader rather than being disseminated to all validators (no mempool). Such transactions are held by the leader until it manages to execute them, unless it is too close to the end of its 4 slots turn as a leader, in which case they are sent to the next scheduled leader. During each slot, the leader attempts to execute unordered transactions in parallel, while ensuring strict serializability through concurrency control. Each transaction that terminates its local execution is then inserted into the evolving block that corresponds to the current slot. At the end of the slot, the block is passed to the consensus protocol to be decided on. If a leader fails to produce a block within their slot, that slot is skipped, and the network moves to the 6
next leader. Validators that receive a block from the leader (after the consensus protocol) execute the block’s transactions in parallel, but must ensure that the logical serialization order obeys the order in which the transactions appear in the block. Interestingly, the above mechanism tends to reduce the number of conflicts within a Solana block. This is because concurrency control often delays the execution of some concurrent conflicting transactions. This lowers the chances that multiple conflicting transactions would finish executing within the same slot and be inserted into the same block. Consensus Solana is in the process of migrating from its previous Proof of History (PoH) [47] and Tower BFT consensus protocol [46] to the Alpenglow protocol [32]. For brevity and since the details are not important for the rest of this work, we skip them here.
5
Methodology
5.1
Solana Full Node
We have rented access time to a Solana node to collect block traces, including their respective transactions, while utilizing the Solana standard RPC interface. Specifically, we have collected transaction traces of 1M blocks, between #390M and #391M, out of a total of 400 million blocks at the time of writing. 5.2
Solana Transactions Fields
Using the getBlock RPC method, we can obtain a trace for all transactions in the given block at once. This method allows specifying how detailed the transaction information should be by using the transactionDetails=’’full’’ field in the the request body. In particular, it includes the following fields: computeUnitsConsumed: Compute unit used at runtime of the transaction. costUnits: Total compute units used by the transaction including execution and all other overheads: signature verifications, accound loadings, write locks, etc. err: Indicates if the transaction was recorded as failed (hard failure). fee: Fee charged for the transaction. accountKeys: List of account the transaction will access. Each account includes a writeable flag, indicating whether the transaction can write to the account data. instructions: List of programs to be invoked: each instruction contains a pointer to the program that is to be invoked, a parameter, and a subset of accounts that the program may access. 7
5.3
Read Sets, Write Sets and Conflicts
To obtain the write set of a Solana transaction, we analyze the list of account keys in the transaction according to the writable flag. The read set is extracted as the collection of all account keys with writable=’false’, and the write consists of all with writable=’true’. Two transactions are considered conflicting if they both specify at least one common account key and at least one transaction sets writable=’true’ for it. Note that Solana considers the writable=’true’ flag as a requirement for an exclusive lock on the corresponding data account; thus, transactions may read and write when specifying writable=’true’. We are unable to distinguish between true read-write conflicts and true write-write conflicts. Let us note that the declared objects are indeed accessed by the transactions that declare them, as these declarations are derived from the execution performed by the block producer. 5.4
ChainGrapher
We extended the ChainGrapher infrastructure [20] to support parsing of Solana traces. The tool supports the collection, retrieval, and processing of execution traces. It is implemented in Python 3.12, and uses networkx 3.4.2 for conflict graph processing and httpx to interact with the Solana node. Execution traces are compressed and stored in HDF5 format using h5py. Additional Python libraries, including pandas, numpy, and matplotlib, are used for metric computation and visualization. Of the metrics collected and presented below, the following require non-trivial data processing steps: Graph Coloring: To estimate the chromatic number of the conflict graphs, we apply the DSatur greedy coloring algorithm [10], since computing an exact minimum graph coloring is NP-hard [31]. Longest Path Estimation: We approximate the length of the longest path using a Monte Carlo approach. We iterate on connected components by size, randomly choosing a set of nodes as starting points. From each starting node, we iteratively build a simple path by uniformly selecting an unvisited neighbor at each step, terminating when no unvisited neighbors remain. Connected components with fewer nodes than the current best estimate of the longest path are skipped. This approach is known to yield accurate longestpath estimates for random graphs [18].
6
Findings Analysis
Since the number of transactions in a block can significantly influence most of the metrics we examine, we group blocks into buckets based on their size. In each graph, we plot one line per bucket: the solid line shows the median across blocks in that bucket, while the shaded region represents the the top and bottom 5% of observed values. The legend labels each line by the minimum block size (#txs) within its corresponding bucket. 8
6.1
Block size
Figure 2a plots the distribution of block sizes, i.e., the number of transactions per block, in a log-scale histogram. Most blocks have around 1,000 transactions, with a long tail reaching 2,000 transactions and more; the largest block size observed is 8,000. Rarely, blocks have a size of 0; in addition, some slots have been completely skipped (yielding empty blocks). Out of the 1M blocks we have downloaded, only 1, 498 were skipped due to consensus protocol failures. 6.2
Execution Time Units and Fee Distribution
Figure 2b plots the average transaction fee in a block. Note that most transactions have a similar overall fee, except for rare high-spike occasions when the conflict rate is abnormally high compared to all other blocks we have downloaded. Figures 2c and 2d plot the average number of compute units (CUs) each transaction consume. While the former only considers compute units that are directly accumulated during runtime, the latter includes also all other overheads related to transaction processing apart from execution (see section 5.2). Note the similarities between these two graphs. The execution time units of transactions seem to be inversely proportional to the block size, which is reasonable assuming one aims at obtaining a roughly equal block execution time. Surprisingly, the transactions fees are not proportional to the block size. This seems to suggest that a block creator could make more money by packaging many short transactions than a smaller number of longer transactions. Note that in Solana, a transaction fee consists of a base fee, equal to 5,000 lamports multiplied by the number of signatures used to validate the transaction, plus a priority fee. The priority fee is not related to the transaction’s execution time. Also, Solana imposes limits on block execution time and compute resources. As transactions’ selection only takes into account absolute fees, a block creator may prefer to include a small number of long transactions that offer slightly higher individual fees, rather than many shorter transactions that each offers a slightly lower fee. Here, a smarter algorithm could improve the creator’s profit. Lastly, we look at the average rate of hard failures in Figure 2e. Hard failures are transaction that have been executed correctly but encountered a logical error; therefore, they are recorded in blocks rather than omitted. 6.3
Conflict Graph Properties
Conflict Graph Density Figure 2f exhibits the density distribution of the conflict graphs corresponding to the collected blocks. As can be seen, the density is quite low, especially compared to what has been reported for Ethereum [4,9,43] and Sui [8], and in correspondence to the findings reported in [4]. This low density is the result of the block creation in Solana, as reported in Section 4. Yet, some graphs reach above 10% density, and one had even more than 35%. 9
(a) Block Size Distribution
(b) Average Transaction Fee
(c) Exec. Compute Units per Tx
(d) Overall Compute Units per Tx
(e) Mean Hard Failures
(f) Density Distribution
Fig. 2: Analysis of Block and Transaction Metrics.
Assortativity and Cluster Coefficient Assortativity and cluster coeficient are reported in Figure 4d and Figure 4e. The relatively high numbers of these measures indicate that conflicting transactions tend to concentrate is near clique structures or singletons (transactions with no conflicts). 10
Degree and Diameter Figure 3a and Figure 3b show the average and max degrees of the conflict graphs, while Figure 3c shows the respective diameters. The fact that the average degree is not too far from the max degree, especially when there are so many singleton nodes (non-conflicting transactions), supports the assumption that conflicting transactions form near clique structures. The low diameter also corresponds to such findings.
Chromatic Number and Clique Number Figure 3d exhibits the greedy algorithm’s estimations for the chromatic numbers of the graphs, which is an upper bound on the true chromatic number. Figure 3e shows the corresponding clique numbers, which serve as lower bounds for the true chromatic number. The fact that these graphs are almost identical indicates that the DSatur greedy algorithm indeed finds near minimal colorings. We remind the reader that the size of the block divided by chromatic number is a good indication for the maximal potential speedup due to parallelism. As can be seen, in most cases parallelism is expected to significantly improve performance. However, in the denser and larger graphs, the chromatic number is very large, indicating that a significant portion of the graph forms a single clique, or a near clique, structure. This may indicate a burst of inter-related activities.
Longest Simple Path and Largest Connected Component Figure 3f shows the longest path estimation as computed by the Monte Carlo based approach, which serves as a lower bound on this figure. Figure 4a exhibits the size of the largest connected component, which is an upper bound on it. Here, too, the results are not far off. Recall that this measure serves as a worse case serialization time, which could impede performance when validators must follow a logical serialization order that corresponds to the order in which transactions appear in the block. The relatively large number in some of the data points echo the findings of [4], which reported serialization chains as long as 59% of the block size.
Longest Path to Chromatic Number Ratio Figure 4b exhibits the ratio between the longest shortest path and the estimated chromic number, which serves as a lower bound for this metric. Figure 4c exhibits the ratio between the largest connected component and the estimated chromic number, which serves as an upper bound. Recall that this metric indicates the additional speedup that parallel execution of transactions while obeying a serialization order derived from minimal coloring can have in comparison to an arbitrary derived block order [29]. We can see that in most cases the coloring approach can improve performance by a factor of 1.5-3, which in extreme cases the improvement can even reach a factor of 6-10. 11
(a) Average Degree
(b) Max Degree
(c) Diameter
(d) Greedy Chromatic Est.
(e) Clique Number
(f) Longest Path Est.
Fig. 3: Comprehensive analysis of graph metrics - part I.
6.4
Distribution of Programs
Finally, we analyze how transactions interact with blockchain programs. We collected 18 publicly known program addresses, including core native programs, SPL programs, loader programs and ecosystem programs, and singled them out. 12
(a) Largest Conn. Comp.
(b) Lower bound ratio
(c) Upper bound ratio
(d) Assortativity
(e) Cluster Coefficient
Fig. 4: Comprehensive analysis of graph metrics - part II.
For the purpose of this discussion, we refer to these 18 specific 18 as “standard programs” and the rest as “non-standard”. Figure 5a plots the number of transactions that include at least one instruction involving a non-standard program, and fig. 5b counts how many different nonstandard programs are involved in 13
(a) #TX Invoking nonstandard Prog.
(b) Distinct Non-std Programs/Block
(c) Programs per Transaction
(d) Pure Reads (Data Accounts) per Tx
Fig. 5: Analysis of Program Usage and Data Reads.
a single block. Figure 5c plots the number of programs each transaction uses, and fig. 5d counts the number of read locks a transaction acquires for pure data accounts (and ignoring program accounts which are also included in the read declarations). Empirical evidence shows that the two most used standard programs are Vote1111111111....11 and ComputeBudget111111111....111; however, they are “kernel”-like programs, rather than user related operations. The top three most used user-related programs are 111111111111.....11111 (system including transfers), TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA, ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL Additional graphs, as well as the raw data containing per-block metrics, have been made available online [53,20].
7
Discussion
In this paper, we have downloaded and analyzed 1M Solana blocks. Our analysis focused on transactions execution times, transactions fees, number and types 14
of programs being invoked by each transaction and block, as well as readsets, writesets, and the corresponding conflicts and resulting conflict graph properties. An interesting conclusion we derive from analyzing the individual transactions execution time vs. fees is that in Solana, a block creator can make more money by packaging many fast executing transaction than a few slow ones. We remind the reader that in Solana the transaction fee includes a priority fee part, which is unrelated to its size or execution time. However, since blocks have a maximum execution time and size, greedily taking the highest paying transactions could result in a suboptimal overall profit for the block, as discussed in Section 6.2. Solana uses programs (smart contracts) to manage its own infrastructure. Still, we have noticed wide usage of user defined (“non-standard”) programs, and that some of these programs are quite popular, and they tend to create most conflicts. On average, each transaction invokes between 1-3 programs, and transactions in smaller blocks tend to invoke more programs. This is reasonable since this probably means that their execution time is longer, so fewer of them can fit inside a single block. Further, transactions tend to access between 2-10 pure read objects (that are not programs). Despite Solana’s successful efforts to reduce the number of conflicts in each blocks, compared e.g., to Ethereum [9] and Sui [8], long conflict chains still emerge, as has also been reported in [4]. Further, our findings suggest that ordering the transactions inside the block in an order that corresponds to a minimal coloring of the conflict graph [29] is likely to reduce the block execution time by anywhere from 20% and up to a factor of 10 is extreme cases, or if the order is deliberately manipulated to form long chains. Interestingly, we also found the DSatur greedy graph algorithm [10] seems to produce near minimal colorings for Solana conflict graphs. Previous work [8,9,30] have explored somewhat similar metrics related to the Ethereum and Sui blockchains. When considering the emerging structures inside the corresponding conflicts graphs, it appears that in Solana there is a relatively high number of transactions that do not conflict with each other. Further, in Solana, conflicting transactions tend to form near cliques, whereas in Ethereum and Sui we often see a hub-and-spoke like structures. This also means that in Solana conflict chains tend to be longer than in Ethereum and Sui, corresponding also to the findings of [4]. Further, in Solana, there is a relatively very large number of singleton nodes, i.e., transactions with no conflicts, which results from its unique approach to selecting transactions to be inserted in a created block. The difference between the characteristics of transactions and blocks in Solana, as we found in this work, compared to previous findings for Ethereum and Sui suggest that it is not possible to design a single representative synthetic workload that would represent all blockchains. Perhaps, the best one can hope for is a parameterized TPC-like benchmark, whose development is left as an interesting future work. Acknowledgements: We would like to thank the anonymous reviewers for their helpful comments and insights that helped improve this paper.
15
References 1. Abadi, D.J., Faleiro, J.M.: An Overview of Deterministic Database Systems. Communications of the ACM 61(9), 78–88 (sep 2018) 2. Amiri, M.J., Agrawal, D., El Abbadi, A.: ParBlockchain: Leveraging Transaction Parallelism in Permissioned Blockchain Systems. In: Proc. of the 39th IEEE International Conference on Distributed Computing Systems (ICDCS). pp. 1337–1347 (2019) 3. Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., De Caro, A., Enyeart, D., Ferris, C., Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C., Nguyen, B., Sethi, M., Singh, G., Smith, K., Sorniotti, A., Stathakopoulou, C., Vukolić, M., Cocco, S.W., Yellick, J.: Hyperledger Fabric: a Distributed Operating System for Permissioned Blockchains. In: Proc. of the 13th ACM EuroSys Conference (EuroSys) (2018) 4. Anjana, P.S., Ravi, S.: Empirical Analysis of Transaction Conflicts in Ethereum and Solana for Parallel Execution (2025), arXiv #2505.05358, https://arxiv. org/abs/2505.05358 5. Arun, B., Li, Z., Suri-Payer, F., Das, S., Spiegelman, A.: Shoal++: High Throughput DAG BFT Can Be Fast and Robust! In: Proc. of the 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI). pp. 813–826 (Apr 2025) 6. Babel, K., Chursin, A., Danezis, G., Kichidis, A., Kokoris-Kogias, L., Koshy, A., Sonnino, A., Tian, M.: Mysticeti: Reaching the Limits of Latency with Uncertified DAGs. arXiv 2310.14821 (2024), https://arxiv.org/abs/2310.14821 7. Behfar, S.K., Crowcroft, J.: Analysis of Information Propagation in Ethereum Network Using Combined Graph Attention Network and Reinforcement Learning to Optimize Network Efficiency and Scalability (2023) 8. Biton, D., Friedman, R.: An Analysis of Sui’s Transactions and Conflicts. In: Proc. of the 30th IEEE Pacific Rim International Symposium on Dependable Computing (PRDC) (2025) 9. Biton, D., Friedman, R., Hay, Y.: Ethereum Conflicts Graphed. In: Proc. of the IEEE International Conference on Blockchain and Cryptocurrency (ICBC) (2025) 10. Brélaz, D.: New Methods to Color the Vertices of a Graph. Communications of ACM 22(4), 251—-256 (Apr 1979) 11. Buchnik, Y., Friedman, R.: FireLedger: A High Throughput Blockchain Consensus Protocol. Proc. VLDB Endow. 13(9), 1525–1539 (jun 2020) 12. Cooper, B.F., Silberstein, A., Tam, E., Ramakrishnan, R., Sears, R.: Benchmarking Cloud Serving Systems with YCSB. In: Proc. of the ACM Symposium on Cloud Computing (SoCC). p. 143–154 (2010) 13. Council, T.P.P.: TPC-C: On-Line Transaction Processing Benchmark (1992), https://www.tpc.org/tpcc/default5.asp 14. Council, T.P.P.: TPC-E: On-Line Transaction Processing Benchmark (2007), https://www.tpc.org/tpce/default5.asp 15. Crain, T., Natoli, C., Gramoli, V.: Red Belly: A Secure, Fair and Scalable Open Blockchain. In: Proc. of the IEEE Symposium on Security and Privacy (SP). pp. 466–483 (2021) 16. Danezis, G., Kokoris-Kogias, L., Sonnino, A., Spiegelman, A.: Narwhal and Tusk: a DAG-based mempool and efficient BFT consensus. In: Proc. of the 17th ACM European Conference on Computer Systems (EuroSys). p. 34–50 (2022)
16
17. Dickerson, T., Gazzillo, P., Herlihy, M., Koskinen, E.: Adding Concurrency to Smart Contracts. In: Proc. of the ACM Symposium on Principles of Distributed Computing (PODC). pp. 303–312 (2017) 18. Diskin, S., Krivelevich, M.: On the Performance of the Depth First Search Algorithm in Supercritical Random Graphs. arXiv 2111.07345 (2022) 19. Do, T.Q., Ta, M.T.: Performance Analysis of Ethereum Smart Contracts: A Study on Gas Cost and Block Size Impact. In: Proc. of the IEEE Statistical Signal Processing Workshop (SSP). pp. 591–595 (2023) 20. Dvir David Biton, Yaron Hay: Chaingrapher [solana] (2026), https://github. com/dbiton/ChainGrapher/tree/solana 21. Escobar, I.A., Alchieri, E., Dotti, F.L., Pedone, F.: Boosting Concurrency in Parallel State Machine Replication. In: Proc. of the 20th ACM/IFIP International Middleware Conference. p. 228–240 (2019) 22. Foundation, S.L..S.: Solana, https://solana.com 23. Foundation, S.: All About Parallelization, https://blog.sui.io/ parallelization-explained 24. Gao, Y., Lu, Y., Lu, Z., Tang, Q., Xu, J., Zhang, Z.: Dumbo-NG: Fast Asynchronous BFT Consensus with Throughput-Oblivious Latency. In: Proc. of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS). pp. 1187–1201 (2022) 25. Garcia-Molina, H., Ullman, J., Widom, J.: Database Systems: The Complete Book, 2nd Edition. Pearson (2008) 26. Gelashvili, R., Spiegelman, A., Xiang, Z., Danezis, G., Li, Z., Malkhi, D., Xia, Y., Zhou, R.: Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. In: Proc. of the 28th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (PPoPP). p. 232–244 (2023) 27. Gramoli, V., Guerraoui, R., Lebedev, A., Natoli, C., Voron, G.: Diablo: A Benchmark Suite for Blockchains. In: Proc. of the ACM European Conference on Computer Systems (EuroSys). p. 540–556 (2023) 28. Gupta, S., Rahnama, S., Hellings, J., Sadoghi, M.: ResilientDB: Global Scale Resilient Blockchain Fabric. Proc. VLDB Endow. 13(6), 868–883 (mar 2020) 29. Hay, Y., Friedman, R.: Batch-Schedule-Execute: On Optimizing Concurrent Deterministic Scheduling for Blockchains. In: Proc. of IEEE International Symposium on Reliable Distributed Systems (SRDS) (Oct 2024) 30. Karmegam, A., Kiffer, L., Anta, A.F.: Exploiting Multi-Core Parallelism in Blockchain Validation and Construction. arXiv 2602.03444 (2026), https:// arxiv.org/abs/2602.03444 31. Karp, R.M.: Reducibility Among Combinatorial Problems, pp. 85–103. Springer (1972) 32. Kniep, Q., Sliwinski, K., Wattenhofer, R.: Alpenglow: A New Consensus for Solana (2025), https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana 33. Kotla, R., Dahlin, M.: High throughput Byzantine fault tolerance. In: Proc. of the IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). pp. 575–584 (2004) 34. Lu, Y., Yu, X., Cao, L., Madden, S.: Aria: A Fast and Practical Deterministic OLTP Database. Proc. VLDB Endow. 13(12), 2047–2060 (jul 2020) 35. Mancino, D., Leporati, A., Viviani, M., Denaro, G.: A Role and Reward Analysis in Off-chain Mechanisms for Executing MEV Strategies in Ethereum Proof-of-Stake. ACM Distributed Ledger Technology (Jun 2024) 36. Monad-Labs: Parallel Execution, https://docs.monad.xyz/ technical-discussion/execution/parallel-execution
17
37. Nathan, S., Govindarajan, C., Saraf, A., Sethi, M., Jayachandran, P.: Blockchain Meets Database: Design and Implementation of a Blockchain Relational Database. Proc. of the VLDB Endowment 12(11), 1539–1552 (Jul 2019) 38. Ocheja, P., Cortes-Goicoechea, M., Mohandas-Daryanani, T., Flanagan, B., Ogata, H., Munoz, J.L., Bautista-Gomez, L.: An Analytical Study of Large Blocks on Ethereum. In: Proc. of the ACM Blockchain and Internet of Things Conference (BIOTC). p. 120–127 (2024) 39. Qin, D., Brown, A.D., Goel, A.: Caracal: Contention Management with Deterministic Concurrency Control. In: Proc. of the ACM Symposium on Operating Systems Principles (SOSP). p. 180–194 (2021) 40. Ravish, A., Hay, Y., Manaswini, P., Jain, R., Friedman, R., Peri, S.: Efficient Scheduling of Smart Contract Transactions via Conflict Graph Coloring. In: Proc. of the IEEE 30th Pacific Rim International Symposium on Dependable Computing (PRDC) (2025) 41. Rouhani, S., Deters, R.: Performance Analysis of Ethereum Transactions in Private Blockchain. In: Proc. of IEEE ICSESS. pp. 70–74 (2017) 42. Saraph, V., Herlihy, M.: An Empirical Study of Speculative Concurrency in Ethereum Smart Contracts. In: International Conference on Blockchain Economics, Security and Protocols (Tokenomics 2019). Proc. of Tokenomics (2019) 43. Saraph, V., Herlihy, M.: An Empirical Study of Speculative Concurrency in Ethereum Smart Contracts. In: International Conference on Blockchain Economics, Security and Protocols (Tokenomics). vol. 71. Schloss Dagstuhl – Leibniz-Zentrum für Informatik (2020) 44. Schneider, F.B.: Implementing Fault-tolerant Services Using the State Machine Approach: A Tutorial. ACM Comput. Surv. 22(4), 299–319 (Dec 1990) 45. Sei: Sei v2 - The First Parallelized EVM Blockchain, https://blog.sei.io/ sei-v2-the-first-parallelized-evm/ 46. Solana-Foundation: Tower BFT: Solana’s High Performance Implementation of PBFT (2019), https://solana.com/news/ tower-bft--solana-s-high-performance-implementation-of-pbft 47. Solana-Foundation: Proof of History: How Solana Brings Time to Crypto (2021), https://solana.com/news/proof-of-history 48. Spiegelman, A., Giridharan, N., Sonnino, A., Kokoris-Kogias, L.: Bullshark: DAG BFT Protocols Made Practical. In: Proc. of the ACM SIGSAC Conference on Computer and Communications Security (CCS). p. 2705–2718 (2022) 49. Sui: Sui: Deliver the Benefits of Web3 with the Ease of Web2, https://sui.io/ 50. Tonkikh, A., Arun, B., Xiang, Z., Li, Z., Spiegelman, A.: Raptr: Prefix Consensus for Robust High-Performance BFT (2025), arXiv #2504.18649, https://arxiv. org/abs/2504.18649 51. Xu, C., Zhang, C., Xu, J., Pei, J.: SlimChain: Scaling Blockchain Transactions Through Off-Chain Storage and Parallel Processing. Proc. VLDB Endow. 14(11), 2314–2326 (Jul 2021) 52. Yakovenko, A.: Sealevel — Parallel Processing Thousands of Smart Contracts, https://medium.com/solana-labs/ sealevel-parallel-processing-thousands-of-smart-contracts-d814b378192 53. Yaron Hay: Solana Statistics (2026), https://huggingface.co/datasets/ yaronhb/SolanaStatistics 54. Yin, M., Malkhi, D., Reiter, M.K., Gueta, G.G., Abraham, I.: HotStuff: BFT Consensus with Linearity and Responsiveness. In: ACM Symposium on Principles of Distributed Computing (PODC). p. 347–356 (2019)
18
55. Zheng, P., Zheng, Z., ning Dai, H.: XBlock-ETH: Extracting and Exploring Blockchain Data From Ethereum. arXiv 1911.00169 (2019)
19