From: thepipeline_xyz
Monad is a blockchain project often heard about online as a “parallel EVM,” but it encompasses more than just that concept [00:00:15]. It represents a full scratch redesign that visually resembles Ethereum, offering a complete EVM L1 equivalent blockchain [00:00:22].
Monad: A User Perspective
From a user’s perspective, Monad is a platform where Ethereum applications can find a home and realize the vision of a “world computer” [00:01:18]. It aims to be a high-performance, low-cost system, with transactions like a Uniswap V2 transaction costing hundreds of a cent [00:01:30]. Monad also strives to maintain decentralization, involving hundreds of nodes globally participating in consensus while keeping reasonable hardware requirements [00:01:36].
Monad: A Developer Perspective
For developers, Monad functions as a fully EVM-equivalent L1 blockchain [00:01:50]. This means developers can easily port over existing contracts and leverage the established EVM research and network effect [00:01:53]. The experience of developing on Monad is designed to feel the same as developing on an EVM, but with the benefit of a high-performance system [00:00:33].
Key features for developers include:
- High performance, targeting 10,000 real historical Ethereum transactions per second, not just transfers [00:00:39].
- Single block times and single slot finality [00:00:58].
- Full EVM RPC compatibility, ensuring that existing wallets, indexers, and other tools work out-of-the-box [00:01:02].
How Monad Achieves Its Performance
Monad’s capabilities stem from a fundamental redesign of its software architecture [00:04:20]. The project focuses on getting the most out of commodity hardware by designing software that saturates hardware through various bottlenecks, while preserving decentralization through reasonable RAM requirements and a globally distributed network of hundreds of nodes [00:04:02].
The core components of this new architecture include:
- A fully rebuilt consensus mechanism [00:04:45].
- A fully rebuilt execution engine [00:04:47].
- Implemented parallel execution [00:04:49].
- A custom state database called Monad DB [00:04:51].
Asynchronous Execution
Most blockchains today use “interleaved execution,” where execution and consensus are performed in tandem within a block time [00:05:20]. For example, in Ethereum’s 12-second block time, execution might take only 1% of the time, with consensus taking significantly longer due to global node communication [00:05:35].
Asynchronous execution in Monad stems from the realization that execution can be pulled out of consensus [00:06:24]. Since the EVM is a deterministic state machine and the ordering and data of transactions are known, the results will always be the same [00:06:37]. This allows Monad to:
- Order the current block while simultaneously executing the previous block [00:07:20].
- Come to consensus on data and its order, then execute it [00:07:40].
- Work on two blocks in parallel [00:08:57].
This approach greatly expands the execution budget, which translates to a higher gas budget, leading to higher throughput and lower fees [00:08:29]. Despite the delayed execution, finality occurs at consensus time because the deterministic nature of the EVM ensures the outcome is known once the order and data are agreed upon [00:09:48].
Parallel Execution
Monad’s parallel execution takes a single processing lane and turns it into multiple lanes, utilizing modern computers’ multiple cores [00:10:32]. Traditionally, transactions are linearly ordered and serially executed [00:10:46]. Monad aims to maintain the order provided by consensus but execute everything in parallel to get results much quicker [00:11:00].
This is achieved through “optimistic parallel execution,” also known as software transactional memory or optimistic concurrency control [00:11:13]. The process is:
- Assume everything can be run in parallel, starting from a synced view of the world [00:11:28].
- Generate a batch of pending results [00:11:37].
- Commit these pending results in order [00:11:39].
- If a pending result relied on a previous one that caused a conflict (e.g., changed the starting state), re-execute it with the new state [00:11:43].
Although re-execution might seem inefficient, it is cheap because the state is already cached, and the most time-consuming part of a transaction is pulling state from the database, not the execution itself [00:13:23]. Crucially, due to the serial commitment process, a transaction is never executed more than once [00:13:17]. This model also eliminates the need for developers to deal with access lists, which simplifies development and reduces bandwidth overhead [00:13:59].
Monad DB
Monad DB is a custom-built state database that makes Ethereum state native to how Ethereum works logically [00:14:43]. Its primary role is to feed and saturate the parallel execution engine by enabling parallel state access [00:14:58]. Without asynchronous I/O and parallel state access, the system would bottleneck waiting for database lookups, even with parallel execution [00:15:16].
Modern SSDs offer high bandwidth (e.g., a million I/O operations per second for about $200), though lookups still take milliseconds compared to nanoseconds for RAM [00:15:42]. The key is to saturate this memory bandwidth by constantly pulling things out of state in parallel [00:16:07].
Ethereum stores its state in a Merkel Patricia Trie (MPT), which is a tree structure [00:16:29]. The MPT is philosophically central to Ethereum as it allows for succinct verification of transactions and state. This means one can check the root of the tree to verify all data beneath it, unlike other blockchains that might require downloading and re-executing an entire block to verify a transaction [00:17:15].
The challenge is that no existing databases are natively built as MPTs; they typically use B-trees or LSM trees [00:16:47]. This creates an inefficiency: when traversing the logical MPT in Ethereum, the system has to perform multiple lookups (16 to 32 times more overhead) within a different underlying database structure [00:19:10].
Monad DB addresses this by being a full rebuild of a database where the Merkel Patricia Trie is the actual way data is stored on disk [00:19:42]. This removes the “tree indirection” and allows for 16 to 32 times fewer lookups per tree traversal [00:19:50]. Combined with asynchronous I/O (using kernel technology like IOU ring), Monad DB can issue many parallel lookups simultaneously, feeding data back into the parallel execution engine [00:20:19]. This parallel state access, alongside parallel execution, is the “secret sauce” that makes Monad’s high performance possible [00:21:12].