From: thepipeline_xyz
The concept of the Parallel EVM has gained significant attention in the crypto space, with many teams claiming to work on their own iterations [00:24:00]. Monad Labs, where Keone and James, formerly of Jump Trading and Jump Crypto, now serve as CEO and CTO respectively, pushed the first parallel EVM algorithm over 1.5 years ago [01:16:11].
Monad’s Optimistic Parallel Execution Algorithm
Monad’s approach involves transactions that are linearly ordered within a block, aiming to reach the end state efficiently [01:42:00]. Their “optimistic parallel execution algorithm” works as follows:
- A batch of transactions runs in parallel, generating pending results [02:02:00].
- Each pending result records inputs and outputs [02:07:00].
- These results are committed in the original transaction order [02:15:00].
- If an input for a pending result is invalidated during commitment, that transaction is re-executed [02:22:00].
- Re-execution is typically cheap because inputs are often in cache [02:51:00].
Despite this algorithm, Monad found that parallel execution alone did not significantly improve performance compared to serial execution [03:17:00].
The True Bottleneck: State Access and Databases
The primary bottleneck for performance gains in blockchains is state access [03:32:00]. Transactions depend on accounts and slots within accounts, which are stored on SSDs in Ethereum [03:35:00]. The cost of reading from an SSD is significant, typically 80-100 microseconds or more per read [10:25:00].
Existing databases used by Ethereum and other EVM-compatible blockchains, such as Pebble DB or Rock DB, do not support parallel access [03:54:00]. This means that even with multiple virtual machines running in parallel, they still bottleneck on database reads, effectively leading to single-file execution [04:05:00].
“When many virtual machines are running in parallel and going and making reads to the database, they all still bottleneck and it it effectively is kind of like a single file execution.” [04:05:00]
The computationally expensive parts of blockchain operations are cryptography functions (elliptic curve, hashing) and state access [09:08:00]. Complex business logic in smart contracts is relatively cheap [09:26:00]. Therefore, simply parallelizing computation alone doesn’t yield much gain [09:44:00].
Monad’s Custom Database
Monad’s solution to the state access bottleneck is a custom-built database [08:31:00]. Standard general-purpose databases like LMDB, MDBX, RocksDB, or LevelDB are not optimized for the specific access patterns of a blockchain [13:34:00]. In high-frequency trading (HFT), standard libraries are rarely used; instead, customized data structures are built to extract maximum performance from hardware [13:55:00].
Monad applies this HFT technique, knowing exactly how data will be used and stored, to build a highly optimized database [14:16:00]. A modern $200 SSD can perform 500,000 I/O operations per second (IOPS), but existing blockchain clients often fail to leverage this, making numerous requests for basic lookups [15:39:00]. Monad’s database may make one or two requests to look up an account, compared to 20 or more for other data structures not in cache [16:46:00]. This “super optimization” extracts every last bit of performance from the hardware [17:01:00].
Other Key Optimizations: Separation of Execution and Consensus
Another significant optimization Monad employs is the separation of execution and consensus [17:15:00].
- By not requiring execution to complete before consensus, both can run in parallel, providing more time for each [17:47:00].
- This relaxation in synchronization is handled by a deterministic algorithm to ensure communication and prevent “cheating” [18:22:00].
- In Ethereum’s 12-second block times, the budget for execution is only about 100 milliseconds (1% of the block time) [19:14:00].
- Moving execution out of being a prerequisite for consensus, and running it in parallel with the next consensus round, is a massive unlock for execution capacity [19:47:00].
The “No Shortcuts” Philosophy
Monad’s tagline, “no shortcuts,” reflects their commitment to deep optimization [20:35:00].
- A shortcut would be to simply throw more hardware (e.g., massive amounts of RAM) at the problem [21:09:00]. While this can improve performance, it makes network participation harder and more expensive, impacting decentralization [21:17:00].
- Instead, Monad aims to run on commodity hardware, like a $200 SSD, and extract maximum performance from it [21:03:00].
- This approach involves meticulous, quantitative engineering, including analyzing assembly instructions and running extensive experiments with different databases [30:53:00].
- Optimizations of even 5% add up significantly (e.g., 10 5% optimizations yield a 50% speedup) [30:31:00].
- The team emphasizes making informed decisions based on measurement and experimentation, not just intuition or common assumptions (e.g., questioning whether access lists are truly beneficial) [34:19:00].
- This rigorous process involves writing and discarding a lot of code, as is common in high-performance engineering [34:36:00].
Benchmarking Performance Optimizations
Currently, there are no standardized benchmarks in crypto, allowing for unsubstantiated claims [44:54:00].
- Monad internally uses replaying recent Ethereum history as their benchmark [46:20:00].
- The term “TPS” (Transactions Per Second) lacks context without specifying transaction type (e.g., token transfers vs. complex Uniswap transactions) [45:31:00]. A non-optimized client can do 50k TPS of simple token transfers [45:57:00].
- Monad plans to release a publicly available GitHub repository with benchmarks that can be replicated, encouraging open, standardized benchmarking for the industry [46:24:00].
- This will allow for fair comparisons and contribute to raising the standard of engineering in the blockchain space [48:40:00].
[!WARNING] A common “shortcut” for artificially boosting benchmarks is to use large amounts of RAM [50:24:00]. However, RAM is two orders of magnitude more expensive than SSDs (200 for 2 terabytes of high-quality NVMe SSD) [50:32:00]. This approach doesn’t scale or promote decentralization, as nodes would require ever-increasing RAM over time [51:29:00].
EVM Compatibility and Contribution to Ethereum
Monad is EVM compatible down to the bytecode level, ensuring that everything functions exactly the same as Ethereum [36:21:00].
- The choice of VM (e.g., EVM, SVM, WASM) is not a significant factor in performance, as differences between them are minor [37:12:00]. The Ethereum VM is considered “fine” and capable [38:41:00].
- Full Ethereum compatibility is crucial for tooling, developer experience, and seamless porting of contracts, allowing developers to focus on business logic [39:04:00].
Users primarily value latency and responsiveness [40:00:00]. While throughput depends on the application, a high throughput is necessary to support a large user base [40:55:00]. Monad aims to build a blockchain that balances both throughput and latency to provide the best user experience [41:40:00].
Monad meaningfully contributes to the Ethereum ecosystem by exploring a new, orthogonal direction: rebuilding the execution stack from the ground up, researching custom databases, and implementing advanced optimizations like parallel execution and asynchronous execution [53:38:00]. This work pushes the boundaries of what is possible, and any changes or innovations developed by Monad could potentially be incorporated into Ethereum itself, contributing to the broader space [54:50:00].
For instance, Monad envisions supporting a fully on-chain limit order book that requires sub-cent fees for orders and thousands of orders per second, enabling a level of interaction previously seen in traditional finance but not yet realized in DeFi [28:33:00]. This exemplifies the kind of performance needs in decentralized finance that Monad is designed to address.