Boosting Blockchain Throughput: Parallel EVM Execution with Asynchronous Storage for Reddio (2503.04595v2)

Abstract: The increasing adoption of blockchain technology has led to a growing demand for higher transaction throughput. Traditional blockchain platforms, such as Ethereum, execute transactions sequentially within each block, limiting scalability. Parallel execution has been proposed to enhance performance, but existing approaches either impose strict dependency annotations, rely on conservative static analysis, or suffer from high contention due to inefficient state management. Moreover, even when transaction execution is parallelized at the upper layer, storage operations remain a bottleneck due to sequential state access and I/O amplification. In this paper, we propose Reddio, a batch-based parallel transaction execution framework with asynchronous storage. Reddio processes transactions in parallel while addressing the storage bottleneck through three key techniques: (i) direct state reading, which enables efficient state access without traversing the Merkle Patricia Trie (MPT); (ii) asynchronous parallel node loading, which preloads trie nodes concurrently with execution to reduce I/O overhead; and (iii) pipelined workflow, which decouples execution, state reading, and storage updates into overlapping phases to maximize hardware utilization.

• The paper introduces Reddio, a framework using batch-based parallel execution and asynchronous storage to overcome blockchain throughput limitations.
• Reddio utilizes an asynchronous state database with direct state reading and asynchronous node retrieval to mitigate I/O bottlenecks during execution.
• A pipelined state management workflow and a correctness proof ensuring deterministic serializability are presented as core components of Reddio.

The paper introduces Reddio, a parallel transaction execution framework incorporating asynchronous storage to enhance blockchain throughput. Reddio aims to overcome the limitations of traditional blockchain platforms like Ethereum, where sequential transaction execution restricts scalability. The framework addresses both computational and storage bottlenecks by employing a batch-based parallel execution model coupled with an asynchronous state database.

The key contributions of Reddio can be summarized as follows:

• Batch-based Parallel Execution: Transactions are grouped into batches and executed in parallel, which enables efficient scheduling and minimizes state conflicts. This approach ensures better workload distribution and reduces synchronization overhead compared to per-transaction parallel execution.
• Asynchronous State Database: Reddio decouples transaction execution from storage operations, allowing state updates to be processed asynchronously. This design mitigates I/O bottlenecks and enhances overall system efficiency.
• Direct State Reading: The EVM (Ethereum Virtual Machine) can retrieve state values directly from a key-value database instead of traversing the MPT (Merkle Patricia Trie), which significantly reduces read latency and minimizes I/O amplification.
• Asynchronous Node Retrieval: Necessary trie nodes are retrieved asynchronously in parallel with transaction execution. By leveraging concurrent database reads, Reddio ensures that storage access does not become a performance bottleneck.
• Pipelined State Management: Reddio introduces a pipelined workflow where transaction execution, state retrieval, and storage updates operate in overlapping phases. This eliminates serialization bottlenecks and maximizes hardware parallelism.

The paper discusses the challenges associated with existing parallel execution frameworks, such as the need for explicit read/write set annotations or the reliance on conservative static analysis, which can limit opportunities for parallel execution. Optimistic concurrency control (OCC) strategies are also discussed, with a focus on the trade-offs between computational parallelism and the potential for excessive abort-and-retry cycles.

The architecture of Reddio involves a coordinator that manages transaction execution batch by batch. In each batch, transactions are selected and assigned to worker threads for parallel execution. After each batch, the coordinator resolves dependencies and merges execution outcomes into a new global state database, ensuring deterministic serializability.

The paper introduces \cref{def:deterministic_serializability} which defines deterministic serializability as a schedule for a batch of transactions $\langle T_1, \ldots, T_m \rangle$, where its effect is equivalent to that of the serialized execution and conforms to the transactions' commitment order, $\langle T_1, \ldots, T_m \rangle$.

The paper also introduces \cref{def:conflict}, which defines a conflict between two transactions $T_i$ and $T_j$ ($i < j$) as a conflict that occurs if $T_i$ writes to a state item that $T_j$ subsequently reads.

The asynchronous state database in Reddio employs direct state reading, asynchronous node retrieval, and a pipelined workflow to address I/O bottlenecks. Direct state reading allows the EVM to access state values directly from a key-value database, bypassing intermediate node retrievals. Asynchronous node retrieval involves buffering state updates in a state cache, while dedicated threads load the required nodes asynchronously in parallel with execution. The pipelined workflow overlaps hashing and storage with transaction execution, with modified nodes rehashed and persisted asynchronously.

A method for determining the commit point for each node in the account trie is also presented. This method takes into account the number of remaining transactions to be executed, the average number of accounts updated by each transaction, and the probability that a given state update modifies a node. The commit point is estimated as the point at which the likelihood of further modifications is sufficiently low.

The recovery mechanism in Reddio involves extending the record format in the state database to include the block height at which the state update occurred. During replay from a specific block, all state values with a height greater than the block height are discarded, ensuring that execution retrieves the correct state values from the account trie and storage trie.

The paper includes a correctness proof, showing that Reddio meets the deterministic serializability criteria. The proof involves demonstrating that if an execution reads a stale value of a state item, the execution will eventually be aborted, and the incorrect results will be reverted.