Blockchain redesign for high performance

From: thepipeline_xyz

Monad is a blockchain that represents a fundamental, from-scratch redesign, while retaining full EVM L1 equivalence and RPC compatibility. It aims to address the need for performant blockchains by delivering significantly higher throughput and lower costs, making it a place where Ethereum applications can realize the vision of a world computer [00:01:21].

Monad from a Developer Perspective

Monad offers a fully EVM-equivalent L1 blockchain [00:01:50]. Developers familiar with EVM environments will find it feels largely the same, allowing them to port existing contracts and tap into existing EVM research and network effects [00:01:53]. Key features include:

• High Performance: Targeting 10,000 real Ethereum transactions per second [00:00:40].
• Single Block Times and Single Slot Finality: Provides quick finality for transactions [00:00:58].
• Full EVM RPC Compatibility: Wallets, indexers, and other tools work out-of-the-box [00:01:02].

Monad from a User Perspective

For users, Monad provides a high-performance, low-cost system [00:01:30]. Transaction costs are significantly reduced, for example, a Uniswap V2 transaction could cost hundreds of a cent [00:01:32]. It aims to maintain decentralization with hundreds of nodes participating in consensus globally, while keeping hardware requirements reasonable [00:01:36].

How Monad Achieves Performance

Monad’s approach involves a new software architecture designed to maximize commodity hardware utilization and saturate all subsequent bottlenecks [00:04:02].

Understanding Blockchain Bottlenecks

Traditional distributed systems and blockchains face four fundamental constraints [00:02:12]:

1. Network Bandwidth: Internet overhead for data transfer [00:02:24].
2. CPU Throughput: Speed of processor cores [00:02:28].
3. State Access: Speed of accessing the database and historical chain state [00:02:32].
4. State Growth: Managing current accounts and balances [00:02:38].

Previous approaches often took “shortcuts” [00:02:56]:

• High Bandwidth Requirements: Some blockchains demand 1 GB or 10 GB internet connections for nodes, increasing costs [00:03:08]. Monad targets 100 megabits per second [00:03:04].
• Centralized Node Placement: Placing all nodes physically close together to reduce latency, sacrificing global distribution [00:03:23].
• High RAM Requirements: Requiring large amounts of RAM makes nodes expensive, as RAM is the most costly component in a computer system [00:03:39].

Monad’s goals are to get the most out of commodity hardware, design software that saturates hardware through all bottlenecks, and preserve decentralization by maintaining reasonable RAM requirements and supporting a globally distributed network of hundreds of nodes [00:04:00].

New Software Architecture

Monad’s redesign keeps only the EVM bytecode instructions, rebuilding everything else from the ground up [00:04:32]:

• Fully rebuilt consensus [00:04:45].
• Fully rebuilt execution engine [00:04:47].
• Implemented parallel execution [00:04:49].
• Custom state database called Monad DB [00:04:51].

Asynchronous Execution

Most blockchains today use “interleaved execution,” where execution and consensus happen in tandem within a block time. For instance, in Ethereum, execution might only take 1% of the 12-second block time, with consensus consuming the majority due to global communication latency [00:05:20].

Monad’s asynchronous execution stems from the realization that if a state machine like the EVM is deterministic (meaning you know the transaction ordering and data), the execution results will always be the same [00:06:24]. This allows execution to be pulled out of the current block and run in parallel with the consensus of the next block [00:07:07].

• Nodes come to consensus on transaction ordering prior to execution [00:08:52].
• Two blocks are processed in parallel: ordering the current block while executing the previous block [00:07:15].
• This significantly expands the execution budget and gas budget, leading to higher throughput and lower fees [00:08:29].
• Finality is at consensus time because the deterministic nature of the EVM ensures that if the data and order are known, the outcome is fixed [00:09:48].

Parallel Execution

Parallel execution is a core innovation of Monad, turning a single lane of sequential execution into multiple lanes to utilize modern multi-core CPUs [00:10:17]. While transactions are still linearly ordered by consensus, they are executed in parallel [00:10:59].

Monad uses a technique called “optimistic parallel execution,” also known as software transactional memory (STM) or optimistic concurrency control (OCC) [00:11:13]:

1. Assume all transactions can run in parallel from a synced view of the world [00:11:28].
2. Generate a set of pending results [00:11:33].
3. Commit results serially. If a transaction’s pending result relied on a state that was changed by a previously committed transaction, that transaction is re-executed with the updated state [00:11:39].

The overhead of re-execution is minimal because the most time-consuming part of a transaction is typically retrieving state from the database, not the execution itself [00:13:23]. By caching state, re-execution is a light operation [00:13:46]. This model eliminates the need for developers to deal with complex access lists, reducing bandwidth overhead while still providing high performance [00:13:59].

Monad DB (Custom State Database)

Monad DB is a custom-built state database crucial for enabling parallel execution by allowing parallel state access [00:14:29]. If the system is constantly waiting for the database to retrieve dependencies, parallel execution becomes irrelevant [00:15:10]. Monad DB uses asynchronous IO to issue many requests to the database in parallel, feeding the execution engine as results return [00:15:25].

Modern hard drives (SSDs) offer high bandwidth and millions of IO operations per second, though lookup latency is higher than RAM [00:15:42]. The key is to saturate this memory bandwidth by constantly pulling data from state in parallel to prevent bottlenecks [00:16:07].

The Merkle Patricia Trie Problem

Ethereum stores its state in a Merkel Patricia Trie (MPT), which is a tree structure allowing for succinct verification of transactions and state [00:16:29]. This means one can verify if data under a root is as expected by checking the root hash, without downloading and re-executing entire blocks [00:17:21].

However, existing databases used by Ethereum clients (like LevelDB or PebbleDB) are typically B-trees or LSM-trees, not native MPTs [00:16:44]. This creates a “tree traversal within a tree traversal” problem: when logically traversing the MPT, the system has to perform multiple lookups in the underlying, different physical database structure to find the next node. This can incur 16 to 32 times more overhead per lookup [00:19:12].

Monad DB’s Solution

Monad DB is a complete rebuild of a database where the Merkle Patricia Trie is the native way data is stored on disk [00:19:42]. This removes the “tree in-direction” [00:19:50].

• Native MPT Structure: The MPT is stored directly on disk [00:20:52].
• Asynchronous IO (IO_Uring): Utilizes kernel technology like IO_Uring to spawn many parallel lookups [00:20:57].

This combination provides parallel state access alongside parallel execution, which is the “secret sauce” that makes high-performance parallel execution truly feasible [00:21:12].

These innovations result in significant performance gains and open up opportunities for application development on high-performance blockchains.