From: thepipeline_xyz
The concept of a Parallel EVM has become a significant topic in the crypto ecosystem [00:00:24]. Despite growing interest and claims from various teams, there’s often a lack of clear, reliable information regarding its true impact and the necessary optimizations for achieving substantial performance gains [00:00:37]. Monad Labs, founded by Keone and James who previously worked together at Jump Trading and Jump Crypto, has been a pioneer in this field, having pushed the first parallel EVM algorithm over a year and a half ago [00:01:16].
Monad’s Optimistic Parallel Execution
Monad’s approach to parallel EVM is based on an optimistic parallel execution algorithm [00:01:34]. In this model, transactions within a block are linearly ordered, with the objective of reaching the final state as if they were executed sequentially, but in a shorter timeframe [00:01:39].
The algorithm functions as follows:
- Parallel Execution: A batch of transactions is run in parallel, generating pending results [00:02:02].
- Record Keeping: Each pending result includes a record of the inputs and outputs for its respective transaction [00:02:07].
- Ordered Commitment: These pending results are then committed in the original order of transactions [00:02:15].
- Conflict Resolution: If, during commitment, an input for a pending result is found to be invalidated, the associated transaction is re-scheduled for execution, and no further commitments occur until it’s re-executed [00:02:22].
This method, also known as optimistic concurrency control, is relatively simple and intuitive [00:02:36]. Re-execution due to conflicts is typically efficient, as necessary inputs are often already in the cache, requiring only a simple cache lookup [00:02:51].
The Bottleneck: State Access
Despite the apparent simplicity and elegance of parallel EVM, Monad’s early implementation revealed that it offered little improvement over serial execution [00:03:18]. The primary bottleneck was identified as state access [00:03:32].
Transactions rely on accessing accounts and storage slots, which are typically stored on SSDs in Ethereum [00:03:35]. The cost of reading from an SSD is significant [00:03:48]. Furthermore, the databases commonly used by Ethereum and other EVM compatible blockchains (like Pebble DB or RocksDB) do not natively support parallel access [00:03:56]. This means that even with multiple virtual machines running in parallel, all read requests still bottleneck at the database, effectively resulting in single-file execution [00:04:05].
“The actual bottleneck is State access… The databases that Ethereum and other blockchains that EVM compatible use to store that state do not support parallel access.” [00:03:32]
Monad’s Solution: Custom State Database
Recognizing state access as the true bottleneck, Monad focused on building a custom state database [00:04:26]. Standard general-purpose databases like RocksDB or LMDB are not optimized for the specific access patterns of blockchain state [00:13:34].
James, Monad’s CTO and the architect behind their database, highlights that the most expensive parts of blockchain operations are cryptography, hashing, and state access [00:09:06]. Simple smart contract logic is relatively cheap to execute [00:09:26]. A single read from an SSD can take 80-100 microseconds or more, orders of magnitude longer than executing a simple smart contract [00:10:23]. Multiple sequential reads for sender accounts, destination accounts, proxy accounts, or storage slots (like ERC-20 balances) quickly add up [00:10:47].
A “shortcut” would be to simply throw more RAM at the problem, requiring very expensive hardware [00:11:37]. However, modern SSDs are incredibly performant, offering hundreds of thousands of I/O operations per second for an affordable price [00:12:08]. The issue lies in inefficient software utilization of this hardware [00:12:37].
Monad’s custom database is designed specifically for blockchain state access, avoiding common pitfalls like embedding one data structure inside another on disk, which creates expensive, multi-traversal operations [00:12:51]. By customizing the data structure to the exact use case, Monad can extract significantly more performance from the hardware [00:14:17]. For instance, Monad’s database may only require one or two requests to look up an account, compared to potentially 20 requests for other data structures not in cache [00:16:46]. This deep optimization ensures that commodity hardware can achieve high performance [00:21:05].
Separation of Execution and Consensus
Another key optimization by Monad is the separation of execution and consensus [00:17:18]. Unlike traditional models where execution must complete before consensus can proceed, Monad relaxes this synchronization [00:17:47]. This allows execution and consensus to run in parallel, providing more time for both processes [00:17:55].
In Ethereum, with 12-second block times, the actual budget for execution is only about 100 milliseconds, roughly 1% of the total block time [00:19:17]. This severely limits the gas limit and the amount of work that can be done per block [00:19:38]. By moving execution out of the prerequisite path for consensus and running it in parallel to the next round of consensus, Monad unlocks a massive budget for execution [00:19:47]. This approach doesn’t restrict leaders who wish to execute transactions before proposing a block; it simply offers a greater budget for everyone else to run them in parallel [00:20:00].
”No Shortcuts” Philosophy
Monad’s development ethos is encapsulated by the tagline “no shortcuts” [00:20:35]. This means:
- Commodity Hardware Focus: Instead of relying on expensive, high-end hardware, Monad builds systems that perform optimally on commodity hardware, making network participation more accessible and cost-effective [00:21:05].
- Deep Optimization: Drawing from their background in high-frequency trading (HFT), where shaving off nanoseconds means winning opportunities, Monad applies hyper-optimization techniques to every component [00:06:06]. This includes micro-optimizations, such as optimizing the translation lookaside buffer (TLB) for virtual-to-physical address translation, even if it yields only small percentage gains [00:30:11].
- Quantitative and Scientific Approach: Development is driven by rigorous measurement, experimentation, and a deep understanding of hardware behavior, even down to assembly instructions [00:30:42]. Assumptions, like the intuitive idea that access lists are always better, are rigorously tested and often found to be incorrect [00:32:01].
- Iterative Development: Teams must be willing to write, rewrite, and discard code as part of the engineering process to achieve optimal performance [00:34:39].
This meticulous, ground-up approach takes significant time and investment [00:23:45].
EVM Compatibility and Developer Experience
Monad is committed to full EVM compatibility down to the bytecode level, ensuring that everything functions exactly the same as on Ethereum [00:36:24]. This stands in contrast to some chains that claim EVM compatibility but have “hiccups” or differences in contract execution or RPC, creating obstacles for developers [00:36:31].
Monad believes that the EVM itself is a robust standard, and differences between VMs like SVM or WASM are often minor, not providing intrinsic special capabilities [00:37:31]. The focus should be on consistent tooling and developer experience [00:39:05]. When developers don’t have to worry about compatibility issues, they can focus more on business logic and building for the end-user [00:39:47].
Users, on the other hand, primarily value responsiveness and low latency [00:40:00]. While throughput is important for supporting many users, it might not directly impact an individual user in all applications [00:41:34]. Monad aims to balance throughput and latency to provide the best user experience [00:41:53].
The Need for Standard Benchmarks
A significant challenge in the crypto ecosystem is the lack of standardized benchmarks, making it difficult to assess true performance gains and verify claims [00:44:54]. Monad advocates for open, reproducible benchmarks [00:46:27].
Monad internally uses replaying Ethereum history as its primary benchmark [00:45:08]. This provides context to TPS (Transactions Per Second) claims, as “TPS” can mean vastly different things (e.g., simple token transfers vs. complex Uniswap or borrowing protocol transactions) [00:45:31]. An unoptimized client can achieve 50k TPS for basic token transfers from early Ethereum history, making high TPS numbers for simple operations less impressive [00:45:57].
Monad plans to build a publicly available GitHub repository where users can download and replicate benchmarks for their chain and others [00:46:27]. This promotes rigor in the industry, allowing for informed scientific and engineering decisions, and fosters collaboration by enabling others to identify and incorporate optimizations [00:48:13]. It also helps expose “cheating” in benchmarks, such as jacking up RAM requirements, which are not scalable or decentralized [00:50:27].
Contribution to the Ethereum Ecosystem
Monad’s mission is not to “kill Ethereum” but to meaningfully contribute to and expand the EVM ecosystem [00:53:09]. The Ethereum research community increasingly recognizes the value of Monad’s unique approach: rebuilding the execution stack from the ground up, researching custom databases, and implementing asynchronous execution and parallel execution [00:53:38].
Monad benefits from the rich tooling, applications, and applied cryptography research within the existing EVM context [00:54:26]. By exploring new, orthogonal directions and pushing the boundaries of what’s possible, Monad aims to advance the space forward. Potential future changes and optimizations developed by Monad could even be incorporated back into Ethereum, further enriching an already diverse and powerful crypto ecosystem [00:54:50].
“Monad has benefited a lot from all of the work that has come before and we’re exploring in a new orthogonal direction that we think will ultimately help push the space forward.” [00:54:36]
Future Applications
The high performance capabilities offered by Monad are expected to enable entirely new applications in the crypto space, such as fully on-chain limit order books [00:28:30]. To support such demanding applications, the blockchain needs to handle sub-cent fees for order submissions and cancellations, and support thousands of orders per second [00:28:41]. This level of infrastructure is crucial for traditional financial institutions to engage with decentralized finance, leveraging features like self-custody and composability at scale [00:27:31].
Ultimately, Monad’s work underscores that true performance gains in parallel EVM and blockchain technology require not just theoretical algorithms but a comprehensive suite of highly focused, ground-up optimizations, particularly at the state database level, coupled with rigorous engineering principles and a commitment to open, standardized benchmarks.