From: thepipeline_xyz
Monad is a blockchain designed as a “from scratch” redesign of the Ethereum Virtual Machine (EVM) architecture, offering a high performance system while maintaining full EVM compatibility [00:22:37] [00:30:30]. It aims to achieve 10,000 real Ethereum transactions per second and provide single block times with single-slot finality [00:39:00] [00:59:00]. From a user perspective, Monad provides a low-cost system (hundreds of a cent for a Uniswap V2 transaction) and strives for decentralization with hundreds of globally distributed nodes maintaining reasonable hardware requirements [01:26:00] [01:30:00] [01:36:00] [01:43:00].
Addressing Blockchain Bottlenecks
Traditional distributed systems and blockchains face four fundamental constraints [02:12:00]:
- Network Bandwidth: Internet overhead [02:24:00]. Some blockchains achieve performance by requiring high bandwidth (1 GB or 10 GB connections), unlike Monad which targets 100 megabits per second for consumer full nodes [03:00:00] [03:08:00].
- CPU Throughput: Speed of processor cores [02:28:00].
- State Access: Speed of retrieving data from the database and historical state [02:32:00].
- State Growth: Managing current accounts and their balances [02:38:00].
Many existing blockchains take shortcuts like increasing bandwidth requirements, placing nodes close together, or upping RAM requirements, which make nodes expensive and less decentralized [02:56:00] [03:08:00] [03:22:00] [03:38:00]. Monad’s goal is to maximize performance from commodity hardware by designing software that saturates hardware through these bottlenecks while preserving decentralization [04:00:00] [04:10:00].
Monad’s New Software Architecture
Monad’s approach involves a full new architectural redesign, retaining only the EVM bytecode [04:32:00] [04:37:00]. Key components include:
- A fully rebuilt consensus mechanism [04:45:00].
- A fully rebuilt execution engine [04:46:00].
- Implemented parallel execution [04:49:00].
- A custom state database called Monad DB [04:51:00].
Asynchronous Execution
Most blockchains today use “interleaved execution,” where execution and consensus are performed in tandem within the same block time [05:16:00] [05:21:00]. For example, in Ethereum’s 12-second block time, execution might take 1% of the time, while consensus takes significantly longer due to global node communication [05:35:00] [05:54:00].
Asynchronous execution stems from the realization that execution can be pulled out of consensus. Because the EVM is a deterministic state machine, knowing the transaction ordering and data means the execution results will always be the same [06:24:00] [06:37:00]. Monad leverages this by performing execution of the previous block in parallel with ordering (consensus) of the current block [07:07:00] [07:13:00] [07:21:00].
This separation means:
- Consensus and execution are on different sides of the timeline [07:37:00].
- The execution budget can be greatly expanded to take up the entire block time, leading to higher throughput and lower fees [08:11:00] [08:29:00].
- Nodes come to consensus on transaction ordering prior to execution [08:51:00].
- Finality is at consensus time, as a full node can immediately run transactions locally once consensus is reached [09:48:00] [10:02:00].
Many blockchains, including current proposals in Solana, are moving towards this model [09:26:00] [09:34:00].
Parallel Execution
Parallel execution is the concept of taking a single lane of sequential processing and turning it into multiple lanes to fully utilize modern multi-core CPUs [10:17:00] [10:32:00]. Currently, transactions are typically linearly ordered and serially executed [10:46:00]. Monad aims to maintain this ordering provided by consensus but execute everything in parallel to get results much quicker [10:59:00].
Monad uses an optimistic parallel execution algorithm, also known as Software Transactional Memory (STM) or Optimistic Concurrency Control (OCC) [11:13:00] [11:17:00]:
- Start with a synced view of the world [11:28:00].
- Assume everything can be run in parallel and generate a batch of pending results [11:30:00] [11:37:00].
- Walk through the pending results in order, attempting to commit them [11:39:00].
- If a pending result relied on a previous one that changed, re-execute it with the new state [11:43:00] [11:55:00].
A key aspect of this algorithm is that, due to serial commitment, a transaction never needs to be re-executed more than once [13:16:00]. The overhead of re-execution is low because the most time-consuming part (calling up state from the database) is mitigated by caching [13:23:00] [13:46:00]. This model also eliminates the need for developers to deal with access lists, reducing bandwidth overhead and simplifying the development interface [13:59:00] [14:03:00] [14:14:00].
Monad DB: Enabling Parallel State Access
Monad DB is a custom state database crucial for saturating the parallel execution engine by allowing parallel state access [14:27:00] [14:58:00]. If the computer has to wait for state dependencies to be pulled from the database for each transaction, parallel execution is bottlenecked [15:07:00]. Monad DB provides O, allowing multiple requests to the database in parallel, ensuring immediate execution as data returns [15:25:00].
Modern hard drives (SSDs) offer high bandwidth and millions of I/O operations per second, making it crucial to saturate this memory bandwidth by constantly pulling data from state in parallel [15:42:00] [16:09:00].
Merkel Patricia Trie and Monad DB’s Innovation
Ethereum stores its state in a Merkel Patricia Trie (MPT), a tree structure that enables succinct verification of transactions and state [16:25:00] [16:32:00] [17:19:00]. This allows checking the root hash to verify data integrity without downloading and re-executing an entire block [17:26:00] [17:36:00].
However, most EVM clients (like Go Ethereum) use off-the-shelf databases (e.g., B-trees or LSM trees) in the backend to store this MPT. These databases are not natively structured as MPTs [16:44:00] [16:50:00] [16:56:00]. This leads to a “tree traversal within a tree traversal” where logical MPT traversals result in multiple inefficient lookups in the underlying non-MPT database (16 to 32 times more overhead) [19:10:00] [19:17:00] [19:20:00] [19:35:00].
Monad DB is a full rebuild of a database where the Merkel Patricia Trie is the actual way data is stored on disk [19:42:00] [19:47:00]. This removes the “tree in direction” and significantly reduces lookups per tree traversal (16 to 32 times less) [19:50:00] [20:10:00]. Combined with O (using kernel technology like IOU_ring to spawn parallel lookups), Monad DB ensures that parallel state access keeps the parallel execution engine saturated and compute efficient [20:19:00] [20:25:00] [20:52:00] [20:57:00] [21:12:00].
In summary, Monad’s unique combination of asynchronous execution, optimistic parallel execution, and a custom-built, MPT-native database (Monad DB) forms its “secret sauce” for achieving high throughput and performance optimization in a decentralized, EVM-compatible environment [21:19:00].