The Pipeline Knowledge Graph

Parallel execution methods

5 min read

From: thepipeline_xyz

Modern blockchain architectures, like Monad, are redesigning their systems from scratch to overcome the performance bottlenecks of traditional distributed systems, particularly focusing on optimizing how transactions are processed. This involves implementing sophisticated parallel execution methods and novel database designs [00:04:32].

Monad’s Approach to Performance

Monad aims to achieve high performance (10,000 transactions per second for real Ethereum historical transactions) [00:00:39], single block times, and single slot finality, all while maintaining full EVM RPC compatibility and supporting hundreds of decentralized nodes globally with reasonable hardware requirements [00:00:58], [00:01:02], [00:01:38], [00:01:41]. To do this, Monad implements a new software architecture, rebuilding its execution engine and introducing a custom state database called MonadDB [00:04:45], [00:04:51].

This approach is possible by addressing fundamental blockchain constraints such as network bandwidth, CPU throughput, state access, and state growth, without resorting to shortcuts like requiring extremely high internet connections or centralizing nodes [00:02:21], [00:03:00], [00:03:23]. The goal is to maximize the potential of commodity hardware while preserving decentralization [00:04:02], [00:04:10].

The core components enabling this performance are:

Asynchronous Execution

Most traditional blockchains operate with “interleaved execution,” where transaction execution and consensus occur in tandem within a single block time [00:05:20], [00:05:29]. For example, in Ethereum, execution might only take up 1% of the 12-second block time, with consensus consuming the majority due to network latency [00:05:35], [00:05:54].

Monad’s asynchronous execution stems from the realization that execution can be decoupled from consensus [00:06:24]. Because the EVM is a deterministic state machine, if the ordering and data of transactions are known, the execution results will always be the same [00:06:37]. This allows Monad to pull execution out of the current block and perform it in parallel with the consensus process of the next block [00:07:07], [00:07:13].

This means:

  • Nodes reach consensus on transaction ordering before execution [00:08:52].
  • Two blocks are processed in parallel: the previous block is executed while consensus is reached on the ordering and data of the current block [00:08:21], [00:08:57].
  • This approach significantly expands the execution budget and gas budget, leading to higher throughput and lower fees [00:08:29], [00:08:34].
  • Finality occurs at the consensus time, as the deterministic nature of the EVM ensures that full nodes can immediately update their state once consensus on ordering is achieved [00:09:48], [00:10:02].

Other blockchains, such as Solana, are also exploring similar asynchronous execution models [00:09:26], [00:09:30].

Parallel Execution

Parallel execution involves taking a single lane of sequential processing and turning it into multiple lanes to utilize modern computers’ multi-core processors [00:10:32], [00:10:37]. In traditional blockchains, transactions are linearly ordered and serially executed [00:10:46]. Monad aims to maintain this consensus-determined ordering but execute everything in parallel to achieve results much faster, then commit them in the original order [00:10:59].

Monad achieves this through “optimistic parallel execution,” also known as software transactional memory (STM) or optimistic concurrency control (OCC) [00:11:13]. The process works as follows:

  1. Initial Assumption: The system starts with a synced view of the world and assumes all transactions can be run in parallel [00:11:28].
  2. Generate Pending Results: Transactions are executed in parallel, generating a set of pending results [00:11:37].
  3. Serial Commitment and Re-execution: The system then walks through these pending results in their original serial order, attempting to commit them [00:11:39]. If a pending result is found to have relied on an outdated state due to a previously committed transaction, it is re-executed with the updated state [00:11:43], [00:11:55].
    • This algorithm ensures that a transaction never needs to be executed more than once [00:13:16].
    • The overhead of re-execution is low because the necessary state is already cached in memory, making execution cheap compared to disk access [00:13:46], [00:13:50].
    • This model eliminates the need for developers to deal with access lists, which simplifies development and reduces bandwidth overhead [00:13:59], [00:14:03].

MonadDB: Custom State Database

The effectiveness of parallel execution heavily relies on efficient state access. If the execution engine has to wait for the database to retrieve necessary data for each transaction, the benefits of parallelism are lost [00:15:10], [00:15:16]. MonadDB is a custom state database designed to enable parallel state access and keep the parallel execution engine saturated with data [00:14:58], [00:15:04].

Key features of MonadDB:

  • Asynchronous I/O: MonadDB utilizes asynchronous I/O (via kernel technology like IOUring) to issue multiple requests to the database in parallel [00:15:25], [00:20:06]. This ensures that the system is always pulling data out of state concurrently, preventing bottlenecks [00:16:09].
  • Native Merkle Patricia Trie Storage: Ethereum logically stores its state in a Merkle Patricia Trie (MPT), which is crucial for succinct verification of transactions and state [00:16:32], [00:17:21]. However, most existing Ethereum clients use off-the-shelf databases (like LevelDB or PebbleDB) that are not natively structured as MPTs [00:16:44], [00:16:50]. This leads to inefficient “tree traversal within a tree traversal” where logical MPT lookups require multiple physical lookups in the underlying database [00:19:10], [00:19:20].
  • MonadDB is a full rebuild of a database where the Merkle Patricia Trie is the actual way data is stored on disk [00:19:42], [00:19:47]. This eliminates the indirection, reducing the number of lookups per tree traversal by 16 to 32 times [00:19:50], [00:20:10].

This combination of asynchronous execution, optimistic parallel execution, and a custom-built state database (MonadDB) that natively understands Ethereum’s state structure allows Monad to achieve true parallel execution for high throughput by ensuring both parallel computation and parallel state access [00:21:12], [00:21:16].

Graph View

Backlinks