From: thepipeline_xyz
Monad is an EVM L1 equivalent blockchain that represents a fundamental redesign of existing blockchain architectures. It aims to provide a high-performance system while maintaining full EVM compatibility and decentralization [00:22:00]. This is achieved through its unique approach to asynchronous execution, parallel execution, and a custom state database called MonadDB [00:48:47].
Monad: A High-Performance EVM L1
From a developer’s perspective, Monad feels familiar to anyone who has developed on an EVM, offering full EVM L1 equivalence and RPC compatibility [00:30:00][00:35:00][00:01:02]. It allows developers to tap into a high-performance system capable of 10,000 real Ethereum transactions per second [00:39:00][00:45:00][00:52:00], with single block times and single slot finality [00:58:00].
For users, Monad provides a high-performance, low-cost system where Ethereum applications can thrive [00:01:26][00:01:30]. Transaction costs are significantly reduced (e.g., hundreds of a cent for a Uniswap V2 transaction) [00:01:33], and decentralization is maintained through hundreds of globally distributed nodes with reasonable hardware requirements [00:01:36][00:01:39].
Addressing Blockchain Bottlenecks
Traditional distributed systems and blockchains face four fundamental constraints:
- Network Bandwidth: Internet overhead [00:02:24].
- CPU Throughput: Speed of computer cores [00:02:28].
- State Access: Accessing the blockchain’s historical state from the database [00:02:33].
- State Growth: Managing current accounts and their balances [00:02:38].
Many blockchains try to overcome these by increasing bandwidth requirements (e.g., 1 GB or 10 GB connections vs. Monad’s 100 MB/s target) [00:03:00][00:03:04], co-locating nodes to reduce latency [00:03:24], or significantly increasing RAM requirements, which makes nodes very expensive [00:03:39][00:03:42].
Monad’s goal is to maximize performance from commodity hardware by designing software that saturates hardware through these bottlenecks while preserving decentralization, meaning reasonable RAM requirements and a globally distributed network of hundreds of nodes [00:04:02][00:04:11][00:04:14]. This is achieved through a new software architecture that fully redesigns consensus and the execution engine [00:04:20][00:04:32].
Asynchronous Execution
Most blockchains today use “interleaved execution,” where execution and consensus occur in tandem within a single block time [00:05:17][00:05:29]. For example, in Ethereum’s 12-second block time, execution might only take 1% of the time, while consensus takes significantly longer due to global network latency [00:05:35][00:05:54].
Asynchronous execution stems from the realization that execution can be decoupled from consensus [00:06:24][00:06:28]. Since the EVM is a deterministic state machine, knowing the transaction ordering and data allows one to predict the outcome without immediate execution [00:06:37][00:06:43].
Monad leverages this by executing the previous block in parallel with ordering the current block [00:07:10][00:07:13][00:07:17].This separation means consensus and execution operate on different sides of the block time, allowing execution to utilize the entire block time [00:07:32][00:08:11][00:08:14].
“We are executing the previous block while coming to consensus on the ordering and the data in the current block.” [00:08:21]
This approach significantly expands the execution budget and, consequently, the gas budget, leading to higher throughput and lower fees [00:08:29][00:08:32][00:08:36]. Nodes come to consensus on transaction ordering before execution [00:08:52]. Even though blocks are executed later, finality is achieved at consensus time because the deterministic nature of the EVM ensures that the outcome is known once the data and order are agreed upon [00:09:48][00:09:55]. Many other blockchains, including Solana, are exploring similar asynchronous execution models [00:09:26][00:09:30].
Parallel Execution
Parallel execution is about utilizing the multiple cores found in modern computers to process transactions concurrently, effectively turning “one lane into multiple lanes” [00:10:32][00:10:37]. While transactions are typically linearly ordered and serially executed in most blockchains [00:10:46], Monad aims to maintain this consensus-given ordering but execute everything in parallel, committing the results in the original order [00:10:59][00:11:06].
Monad employs an optimistic parallel execution algorithm, also known as Software Transactional Memory or Optimistic Concurrency Control (OCC) [00:11:13][00:11:17][00:11:21]. The process works as follows:
- Assume everything can run in parallel and start with a synced view of the world [00:11:28].
- Generate pending results from parallel execution [00:11:33].
- Walk through the pending results in order, attempting to commit them [00:11:39].
- If a pending result relied on a previous one that changed, re-execute it with the new state [00:11:43][00:11:45].
This algorithm ensures that a transaction never has to be re-executed more than once [00:13:16][00:13:20]. The overhead of re-execution is low because the system has already cached the necessary state, making execution itself very cheap compared to calling up state from the database [00:13:23][00:13:29][00:13:41][00:13:46]. A significant benefit of this model is that developers do not need to deal with access lists, which can add bandwidth overhead [00:13:59][00:14:03][00:14:06].
MonadDB: Enabling Parallel State Access
MonadDB is a custom state database that is crucial for making parallel execution truly effective [00:14:29][00:14:32]. It feeds the parallel execution engine by allowing parallel state access [00:14:58][00:15:01][00:15:04]. Without parallel state access, the system would bottleneck waiting for the database to pull out dependencies for each transaction, negating the benefits of parallel execution [00:15:07][00:15:19]. Therefore, asynchronous I/O is essential to issue multiple requests to the database in parallel and quickly execute as results return [00:15:25][00:15:27][00:15:32].
Modern SSDs offer high bandwidth and millions of I/O operations per second, making it critical to saturate this memory bandwidth by pulling data out of state in parallel [00:15:42][00:15:53][00:16:07][00:16:09].
Ethereum stores its state in a Merkel Patricia Trie (MPT), which is fundamental for succinct verification of transactions and state – allowing efficient checking of data integrity via a root hash [00:16:32][00:17:15][00:17:21][00:17:26]. However, most existing Ethereum clients use off-the-shelf databases (like B-trees or LSM trees) to store this MPT [00:16:44][00:16:50][00:17:00]. This creates an inefficiency: when transversing the logical MPT, the system performs a “tree traversal within a tree traversal” in the backend database, resulting in 16 to 32 times more overhead for each lookup [00:19:18][00:19:20][00:19:36][00:19:39].
MonadDB is a complete rebuild of a database where the Merkle Patricia Trie is the actual way data is stored on disk [00:19:42][00:19:45][00:19:47]. This removes the indirection, leading to 16 to 32 times fewer lookups per tree traversal [00:19:50][00:19:53][00:20:10][00:20:13]. Combined with asynchronous I/O using IOU ring kernel technology, MonadDB enables parallel state access [00:20:19][00:20:20][00:20:58][00:21:00][00:21:14]. This is the “secret sauce” that allows Monad to fully saturate its parallel execution engine by ensuring that compute is not bottlenecked waiting for data [00:20:28][00:20:30][00:20:36][00:21:19][00:21:20].
The combination of asynchronous execution, parallel execution, and MonadDB’s parallel state access is key to Monad’s ability to achieve high performance and scalability while preserving decentralization and EVM compatibility [00:04:02][00:04:11][00:04:14].