Source-linked AI summary
Analyzing Solana's Blocks and Transactions
Yaron Hay, Dvir David Biton, Roy Friedman
TL;DR
Transaction access patterns and conflicts matter because they constrain serializable parallelism, while transaction execution and validation are performance bottlenecks. The paper analyzes one million recent Solana blocks and their transactions, programs, fees, and conflict graphs. It reports that most blocks have few conflicts but that coloring-based ordering could reduce execution time compared with arbitrary ordering.
Problem
Transaction types, object-access patterns, and inter-transaction conflicts matter for performance, but conflicts constrain the parallel execution that must preserve deterministic serializability.
Source: §1 · p. 1Method
The authors analyze one million recent Solana blocks, measuring transactions, fees, programs, and conflicts derived from declared readsets and writesets.
Source: §1 · p. 2Results
Most blocks exhibit few conflicts, while coloring-based ordering could improve block execution time by 1.2–3 times and up to 10 times in extreme cases versus arbitrary order.
Source: Summary of Findings · p. 2Takeaways & Limitations
The findings suggest that identifying transactions and objects responsible for conflicts can inform targeted optimizations, including redesigning smart-contract logic to reduce contention.
Source: §1 · pp. 1–2
Abstract
from arXiv · showhide
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 and code are available in open source.
1 Introduction
Understanding Solana transaction behavior and conflicts matters because conflicts constrain serializable parallelism and transaction execution is a performance bottleneck. The paper analyzes one million recent Solana blocks and reports low conflicts in most blocks, alongside long conflict chains and potential gains from coloring-based ordering.
1 Introduction
- The study analyzes one million recent Solana blocks, examining transaction execution times, fees, programs, and conflicts derived from declared readsets and writesets.Solana mandates pre-declaration of readsets and writesets, which simplifies detecting potential within-block conflicts.Source: §1 · p. 2
Summary of Findings
- Most Solana blocks exhibit few conflicts, but long conflict chains still emerge despite Solana’s conflict-reduction mechanism.Conflicting transactions tend to form near-cliques, especially in large blocks.Source: Summary of Findings · p. 2
- Fees do not correlate with block size, while individual transaction execution time appears inversely proportional to total block size.The fee finding is noted with reference to Section 6.2.Source: Summary of Findings · p. 2
- User-defined non-standard programs are widely invoked, and popular programs tend to generate most conflicts.Each transaction invokes more than one but fewer than three programs on average; multiple programs are invoked by many transactions.Source: Summary of Findings · p. 2
2 Related Work
Prior work has examined blockchain transaction conflicts and parallelism, including analyses of Ethereum and Sui. This paper extends that line of study with a larger Solana dataset and additional measurements, while distinguishing real transaction behavior from synthetic workload evaluations.
2 Related Work
- Prior analyses studied Ethereum and Solana parallelization using 1,000 blocks from each of three historical periods, while this work analyzes many more blocks and measures execution units, fees, and chromatic numbers.The earlier comparison reported longer conflict chains in Solana than Ethereum; the present study argues coloring-based ordering could reduce Solana block execution time.Source: §2 · p. 3
- Coloring the conflict graph and ordering transactions by color can yield gains proportional to the ratio of chromatic number to longest simple path, an effect the authors also find for Solana.Most systems instead require conflicting transactions to commit in block order.Source: §2 · p. 3
- Several concurrency-control studies use synthetic workloads, while the Diablo benchmark does not capture realistic access patterns or transaction conflicts.Off-chain execution approaches are orthogonal to this paper’s focus on on-chain behavior and performance.Source: §2 · pp. 3–4
3 Preliminaries
The paper represents within-block transaction conflicts as an undirected graph built from transactions’ read and write sets. It examines graph properties that characterize conflict structure and constrain parallel execution under serializability requirements.
3 Preliminaries
- Two transactions conflict when they access a common object and at least one writes it; each such pair becomes an undirected edge in the block’s conflict graph.Transactions may access blockchain objects for reading or writing, and Solana transactions should pre-declare both sets.Source: §3 · p. 4
- Parallel execution must preserve deterministic serializability; conflicting transactions may be kept from concurrent execution or handled with optimistic concurrency control that can require aborts and re-execution.The paper focuses on graph properties that constrain transaction parallelism under serializability requirements.Source: §3 · pp. 4–5
- Density measures the proportion of possible edges present, while diameter, maximum degree, and mean degree characterize graph connectivity and node connectivity.Low density means few conflicts; a large gap between mean and maximum degree suggests a star-like graph dominated by a few hubs.Source: §3 · p. 5
- The chromatic number is the minimum colors needed for adjacent transactions to differ and indicates maximal attainable parallel speedup; the clique number is a lower bound on it.The longest simple path captures maximum latency under naïve parallelization, while the largest connected component upper-bounds that path; repeated random traversals provide a practical lower bound for the NP-hard path computation.Source: §3 · pp. 5–6
4 Solana
Solana uses an account model and on-chain programs, with transactions declaring their read and write sets in advance. Leaders execute transactions in parallel under concurrency control, while validators must preserve the block’s logical serialization order.
4 Solana
- Solana’s account model and parallelism-oriented architecture tend to reduce conflicts among transactions in the same block.Concurrency control can delay conflicting transactions, lowering the chance that they finish in the same slot and enter the same block.Source: §4 · pp. 6–7
- Solana uses accounts for data and programs, and transactions invoke one or more program instructions while declaring readsets and writesets in advance.Programs are stateless and often written in Rust; account data may need deserialization before use.Source: §4 · p. 6
- Slots target 400 ms, and one validator leads four consecutive slots; transactions are forwarded to the current or closely scheduled leader rather than broadcast to all validators.Solana is described as migrating from PoH and Tower BFT to Alpenglow, whose details are omitted.Source: §4 · pp. 6–7
- During a slot, the leader executes unordered transactions in parallel under strict serializability, then passes the block to consensus; validators execute in parallel but preserve block order as the logical serialization order.A slot may be skipped if its leader fails to produce a block.Source: §4 · pp. 6–7
5 Methodology
The study analyzes one million Solana block traces collected through the standard RPC interface. It derives transaction access sets from declared account permissions, builds conflict graphs, and computes block and transaction metrics using extended ChainGrapher infrastructure.
5.1 Solana Full Node
- 1M blocks from #390M to #391M were collected through a rented Solana node using the standard RPC interface.The getBlock RPC method retrieves traces for all transactions in a block with transactionDetails set to full.Source: §5.1 · p. 7, §5.2 · p. 7
5.2 Solana Transactions Fields
- Solana transaction traces provide runtime compute units, total cost units, failure status, fees, account keys, and invoked-program instructions.Cost units include execution and other processing overheads; account keys carry writable flags.Source: §5.2 · p. 7
5.3 Read Sets, Write Sets and Conflicts
- Read and write sets are inferred from account-key writable flags, and transactions conflict when they share an account that at least one marks writable.Because writable accounts may be read and written, the analysis cannot distinguish true read-write from write-write conflicts.Source: §5.3 · p. 8
5.4 ChainGrapher
- ChainGrapher was extended to parse Solana traces, while graph coloring is estimated with DSatur and longest paths with a Monte Carlo search.Exact minimum graph coloring is NP-hard; the path search samples simple paths from starting nodes in connected components, skipping components smaller than the current best estimate.Source: §5.4 · p. 8
6 Findings Analysis
Across one million blocks, transaction compute use tends to fall as block size rises, while fees do not track block size. Conflict graphs are generally sparse but can contain large near-cliques, and coloring-based ordering may improve execution performance; the analysis also examines program use and data reads.
6.1 Block size
- Most blocks contain around 1,000 transactions, with a long tail beyond 2,000 and a largest observed block of 8,000 transactions.Only 1,498 of the million downloaded blocks were skipped due to consensus protocol failures.Source: §6.1 · p. 9
6.2 Execution Time Units and Fee Distribution
- Transaction execution units seem inversely proportional to block size, but fees are not proportional to block size.The paper notes that fees comprise a base fee and a priority fee unrelated to execution time, and that a smarter selection algorithm could improve block creators’ profit.Source: §6.2 · p. 9
6.3 Conflict Graph Properties
- Conflict graphs are usually low-density, yet some exceed 10% density and one exceeds 35%; high assortativity and clustering suggest conflicts concentrate in near-cliques or singletons.Degree and diameter patterns support the near-clique interpretation, while the estimated chromatic numbers closely match clique numbers, suggesting near-minimal DSatur colorings.Source: Conflict Graph Density · p. 9, Assortativity and Cluster Coefficient · p. 10, Figure 2 · p. 10
- The longest-path estimate and largest connected component provide lower and upper bounds, respectively, on serialization-chain length, with some values relatively large.The analysis treats such chains as a possible worst-case serialization time for validators following block order.Source: Longest Simple Path and Largest… · p. 11
- Coloring-based ordering can improve performance by a factor of 1.5-3 in most cases and 6-10 in extreme cases.The ratio compares bounds based on longest paths or largest connected components with estimated chromatic number; the two approaches provide lower and upper bounds.Source: Longest Path to Chromatic Number Ratio · p. 11, Figure 4 · p. 13
6.4 Distribution of Programs
- The program analysis tracks non-standard-program transactions, distinct non-standard programs per block, programs per transaction, and read locks on data accounts.Vote and ComputeBudget are the most-used standard programs; the top user-related programs are System, Tokenkeg, and Associated Token.Source: §6.4 · pp. 12–14, Figure 5 · p. 14
7 Discussion
The discussion draws on an analysis of 1M Solana blocks spanning transaction execution times, fees, invoked programs, readsets, writesets, and conflict graphs. It highlights fee-aware transaction packing, conflict-graph structure, and potential execution-time gains from transaction ordering.
7 Discussion
- The analysis covers 1M Solana blocks, focusing on execution times, fees, invoked programs, readsets, writesets, and resulting conflict-graph properties.Source: §7 · pp. 14–15
- A block creator can make more money by packaging many fast-executing transactions than a few slow ones, while greedily taking the highest-paying transactions may be suboptimal under block size and execution-time limits.Solana transaction fees include a priority-fee component unrelated to transaction size or execution time.Source: §7 · p. 15
- Non-standard user-defined programs are widely used and tend to create most conflicts; transactions invoke 1–3 programs on average and access 2–10 pure-read objects.Transactions in smaller blocks tend to invoke more programs.Source: §7 · p. 15
- Ordering transactions within a block according to a minimal coloring of the conflict graph is likely to reduce block execution time by 20% to a factor of 10 in extreme cases or when long chains are deliberately formed.The DSatur greedy graph algorithm seems to produce near minimal colorings for Solana conflict graphs [10].Source: §7 · p. 15
- Solana conflict graphs contain many singleton transactions and near-cliques, with longer conflict chains than Ethereum and Sui's hub-and-spoke-like graphs.The paper attributes the large number of singleton nodes to Solana's approach to selecting transactions for a block.Source: §7 · p. 15
- These differences suggest no single representative synthetic workload can model all blockchains; a parameterized TPC-like benchmark is left as future work.Source: §7 · p. 15