From: thepipeline_xyz
Monad Labs, with Keone as CEO and James as CTO, is at the forefront of parallel EVM development and essential optimizations to achieve true Performance gains in blockchain performance [00:00:24].
Monad’s Optimistic Parallel Execution Algorithm
Monad Labs developed and implemented their optimistic parallel execution algorithm over one and a half years ago [00:01:16]. In Monad, transactions are linearly ordered within a block, aiming to reach the end state as if they were run one after another, but completing the work faster [00:01:39].
The algorithm functions by running multiple transactions in parallel, generating pending results [00:02:02]. Each pending result records the inputs and outputs for its transaction [00:02:07]. These results are then committed in the original transaction order [00:02:15]. If a pending result’s input has been invalidated during this process, the work is rescheduled, and further commitments are paused until that transaction is re-executed [00:02:21]. This re-execution is typically inexpensive because needed inputs are usually cached [00:02:47].
Despite this algorithm, Monad found that parallel execution alone did not yield significant improvement compared to serial execution [00:03:18].
The True Bottleneck: State Access
The primary bottleneck in blockchain performance is state access [00:03:30]. Transactions depend on accounts and their slots, with this state stored on an SSD in Ethereum [00:03:35]. The cost of reading from an SSD is substantial [00:03:47]. Existing databases used by Ethereum and other EVM-compatible blockchains do not support parallel access [00:03:56]. This means that even with multiple virtual machines running in parallel, they still bottleneck on database reads, effectively leading to single-file execution [00:04:05].
The most expensive parts of blockchain operations include cryptography functions (elliptical curve cryptography, hashing) and state access [00:09:06]. Complex smart contract business logic is relatively cheap to execute compared to typical desktop or phone programs [00:09:21]. Therefore, parallelizing computation by itself offers limited benefit [00:09:44].
A single read from an SSD can have a latency of 80 to 100 microseconds or more [00:10:23]. This is orders of magnitude longer than it takes to execute a simple smart contract [00:10:41]. Transactions typically involve multiple reads (sender account, destination account, proxy accounts, storage slots like ERC20 balances), which, if sequential, accumulate into significant execution times [00:10:47].
Monad’s Custom Database
Monad’s inspiration to build a custom database stemmed from identifying state access as the bottleneck and the realization that existing general-purpose databases like PebbleDB or RocksDB are not optimized for blockchain use cases [00:04:20], [00:08:45].
Standard databases often embed one data structure inside another on disk, making every request traverse two data structures, which is expensive [00:12:51]. While different database types exist (B+ tree databases like LMDB/MDBX, LSM trees like RocksDB/LevelDB), their general-purpose design means they are optimized for average performance, not the specific access patterns of a blockchain [00:13:14].
Monad’s custom database is designed specifically for how blockchain data is stored and accessed, a technique borrowed from high-frequency trading (HFT) where customized data structures lead to significantly better hardware performance [00:14:16]. Modern SSDs are highly performant (e.g., 500,000 I/O operations per second for a $200 SSD) [00:12:09], [00:15:39], but general database implementations fail to leverage this capability [00:16:16]. Some blockchain clients use these databases in a way that requires numerous requests for basic lookups (e.g., 20 requests for a non-cached lookup, vs. 1-2 for Monad’s database), wasting hardware potential [00:16:24].
Separation of Execution and Consensus
Another key optimization is the separation of execution and consensus [00:17:15]. By not requiring execution to complete before consensus, both processes can run in parallel, providing more time for each [00:17:47]. This relaxation of synchronization allows for a greater budget for execution [00:19:43]. For example, in Ethereum, with 12-second block times, the execution budget is only about 100 milliseconds (1% of the block time), severely limiting the gas limit and work capacity [00:19:14]. Running execution in parallel to the next round of consensus is a massive unlock for execution throughput [00:19:47].
”No Shortcuts” Philosophy
Monad’s “no shortcuts” approach emphasizes deep, quantitative understanding and engineering over quick fixes [00:23:37]. Shortcuts, such as simply throwing large amounts of hardware (e.g., RAM) at the problem, make it harder and more expensive for regular people to participate in the network, hindering decentralization [00:21:09]. While Monad aims to run on commodity hardware (like a $200 SSD), it focuses on maximizing performance within those constraints, rather than requiring expensive, large-RAM servers [00:21:03], [00:51:00].
This philosophy is rooted in their background in high-frequency trading, where systems were optimized down to tens or hundreds of nanoseconds [00:22:24]. This involves looking at code compilation, assembly instructions, and making countless micro-optimizations that accumulate to significant speed-ups [00:30:09].
Monad’s approach involves:
- Challenging Intuitions: Assumptions, like access lists being universally beneficial for parallel execution or state preloading, are rigorously tested and often found to be incorrect [00:31:44].
- Measurement and Experimentation: Every decision is informed by data and extensive experimentation, including writing and discarding code that doesn’t meet performance goals [00:33:32].
- Avoiding Local Maximums: Continuously seeking ways to relax constraints and explore new architectural approaches to find even faster solutions [00:33:45].
The need for performant blockchain was evident to Monad’s founders during their time at Jump Crypto, working on Solana DeFi projects in 2021 [00:06:40]. They recognized that existing EVM implementations were highly inefficient and lacked the level of optimization seen in high-performance trading systems [00:06:50].
Benchmarking for True Performance Gains
Currently, there are no standardized benchmarks in crypto, allowing various projects to make unsubstantiated claims about TPS (Transactions Per Second) [00:44:54]. TPS numbers without context (e.g., token transfers vs. complex Uniswap transactions) can be misleading [00:45:31].
Monad has internally used recent Ethereum history as its benchmark [00:46:20]. Their plan is to release a publicly available GitHub repository where others can download and replicate benchmarks on their chain and other projects [00:46:24]. This promotes transparency and allows the industry to hold projects accountable [00:46:52].
Standardized benchmarks would help:
- Validate Claims: Prevent “cheating” by, for example, running benchmarks on systems with excessive RAM, which is far more expensive than SSDs and not scalable for decentralization [00:50:27].
- Foster Innovation: Allow projects to understand why others perform better and incorporate those ideas, raising the engineering standard of the industry [00:48:16].
- Promote Rigor: Move away from intuition-based marketing and towards more rigorous, scientific, and quantitative engineering practices [00:48:58].
Monad’s Contribution to the Ethereum Ecosystem
Monad Labs aims to contribute to the performance and scalability of the EVM ecosystem rather than replace Ethereum [00:53:09]. There is growing recognition within the Ethereum research community that Monad’s unique approach of rebuilding the execution stack from the ground up, researching a custom database, and implementing parallel execution and asynchronous execution, are valuable explorations [00:53:38]. These are areas where existing Ethereum client teams, focused on other orthogonal problems, haven’t had the resources to delve [00:54:06].
Ethereum has established the EVM as a powerful bytecode standard with rich tooling and applications, and Monad benefits greatly from this prior work [00:54:20]. Monad’s research and optimizations could potentially be incorporated into Ethereum, pushing the space forward and contributing to the future of high performance and scalable blockchains [00:54:46].
Monad’s full EVM compatibility down to the bytecode level means everything functions identically to Ethereum, providing a seamless developer experience without the need for complex changes when porting contracts or using RPCs [00:36:21]. This is crucial for developer experience, allowing them to focus on business logic rather than compatibility differences [00:39:47].
Ultimately, users value latency and responsiveness [00:39:57]. While throughput depends on the application, having high throughput is essential for supporting a large user base [00:41:34]. Monad aims to balance throughput and latency to provide the best user experience [00:41:44].