From: thepipeline_xyz
The discussion around Parallel EVM and blockchain optimizations has become a significant narrative in the crypto space, with many teams claiming to work on their own iterations [00:00:24]. However, there’s often a lack of reliable information regarding the true impact of Parallel EVM and other essential optimizations needed to achieve significant performance gains [00:00:37].
Optimistic Parallel Execution
Monad Labs developed its optimistic parallel execution algorithm over a year and a half ago [00:01:16]. In Monad, transactions are linearly ordered within a block, aiming to reach the final state as if transactions were run sequentially, but completing the work in a shorter time [00:01:39].
The algorithm functions as follows:
- Multiple transactions are run in parallel, generating pending results [00:02:02].
- Each pending result records the inputs and outputs for that transaction [00:02:07].
- These pending results are committed in the original order of transactions [00:02:15].
- If a pending result encounters an invalidated input, the work is rescheduled, and commitment pauses until re-execution [00:02:20].
This re-execution due to conflicts is typically inexpensive because needed inputs are almost always in cache, allowing for a simple cache lookup [00:02:47].
The True Bottleneck: State Access
Despite implementing optimistic parallel execution, Monad found that it yielded little improvement compared to serial execution [00:03:11]. The primary bottleneck identified was state access [00:03:30]. Transactions depend on accounts and slots within those accounts, and this state is stored on an SSD in Ethereum [00:03:35]. The cost of reading from an SSD is significant [00:03:48]. Furthermore, the databases used by Ethereum and other EVM-compatible blockchains do not support parallel access [00:03:58]. This means that even with multiple virtual machines running in parallel, they still bottleneck on database reads, effectively resulting in single-file execution [00:04:05].
This revelation highlighted that parallelization in blockchain technologies alone doesn’t guarantee significant performance gains; the core issue lies in optimizing state access, particularly at the database level [00:04:47].
“Paralyzing computation by itself doesn’t really gain that much.” [00:09:44]
Monad’s Approach to Optimization
Monad’s inspiration to build a more performant blockchain stemmed from experience in high-frequency trading (HFT) at Jump Trading [00:05:04]. The HFT environment, being super latency-competitive, involved constantly improving systems to shave off milliseconds [00:06:00]. This background provided a perfect fit for tackling the need for a more performant blockchain, especially for the EVM, which had not been optimized to the same degree as HFT systems [00:06:40].
Custom State Database
The crucial component enabling parallel EVM and blockchain optimizations to yield true performance gains is a custom database [00:08:31]. Standard databases like PebbleDB or RocksDB are general-purpose [00:13:34].
The most expensive parts of blockchain operations are cryptography functions (e.g., elliptical curve cryptography, hashing) and state access [00:09:06]. Even complex smart contract logic is relatively cheap to execute compared to reading from disk [00:09:26]. A single read from an SSD can have a latency of 80-100 microseconds, which is orders of magnitude longer than executing a simple smart contract [00:10:23].
Blockchain clients using standard databases can suffer from poor performance because they often embed one data structure inside another on disk, leading to expensive, multi-traversal operations for each request [00:12:47]. General-purpose data structures are designed to be performant on average, but not for specific, highly optimized tasks [00:13:48].
Monad’s custom database is designed to extract maximum performance from modern SSDs, which are capable of 500,000 I/O operations per second (IOPS) [00:15:39]. By customizing the data structure to the specific way the data is used and stored in a blockchain, Monad can achieve significantly better performance [00:14:16]. This means making a tenth or a twentieth of the requests to hardware compared to other clients [00:16:32].
Separation of Execution and Consensus
Another key optimization is separating execution and consensus [00:17:18]. If execution is not required to complete before consensus, both can run in parallel, providing more time for each process [00:17:47]. This is not a restriction but a relaxation of synchronization [00:18:14].
In Ethereum, with 12-second block times, the budget for execution is roughly 100 milliseconds, or about 1% of the total block time [00:19:14]. This severely limits the gas limit and the amount of work that can be done [00:19:38]. Moving execution out of being a prerequisite for consensus and running it in parallel to the next consensus round massively unlocks execution potential [00:19:47].
The “No Shortcuts” Philosophy
Monad’s “no shortcuts” philosophy emphasizes deeply understanding and optimizing every aspect of the system [00:20:35]. A common shortcut is to simply “throw a bunch of hardware” at the problem, such as requiring large amounts of RAM [00:21:09]. While this can increase performance, it makes it harder and more expensive for regular people to participate in the network, hindering decentralization [00:21:17].
Monad aims to run on commodity hardware, like a $200 modern SSD, which is capable of immense performance if properly leveraged [00:21:05]. Many small optimizations, such as optimizing translation look-aside buffers or examining assembly instructions, cumulatively add up to significant speed-ups [00:30:09].
“You have to do the work, right? You have to do the fundamental sort of engineering and the fundamental science and make informed decisions.” [00:33:32]
This involves extensive quantitative experimentation, measuring everything, and making no assumptions. For example, the common assumption that access lists are beneficial for parallel execution might not be true; internal work suggests they could even be strictly worse [00:31:20].
Benchmarking and Standardization
Accurate information on performance gains in blockchain is difficult to obtain due to a lack of standard benchmarks [00:44:03]. Anyone can claim any TPS (transactions per second) number without being held accountable [00:44:56].
Challenges in Metrics (TPS)
The term “TPS” itself can be misleading [00:45:31]. It’s crucial to define what kind of transactions are being measured [00:45:48]. An unoptimized client can already achieve 50k TPS for simple token transfers, making a claim of 200k TPS for such transfers less impressive without context [00:45:55]. This highlights the Differences in blockchain transaction metrics.
Monad’s Proposed Solution
Monad has internally used replaying recent Ethereum history as its benchmark [00:45:08]. Their plan is to release a publicly available GitHub repository where users can download and replicate benchmarks for Monad and other chains [00:46:24].
This open approach to benchmarking fosters progress in the technology by allowing others to:
- Verify claims and identify areas for improvement [00:46:52].
- Understand specific configurations that yield better performance [00:47:01].
- Prevent “cheating” benchmarks by using excessive, non-commodity hardware like 256GB of RAM, which is two orders of magnitude more expensive than equivalent SSD storage [00:50:24].
This standardization will bring more rigor to the industry, moving away from intuition-based marketing claims toward scientific and engineering practices [00:48:48].
User Experience and EVM Compatibility
Users generally value latency and responsiveness [00:40:00]. While throughput is important for supporting a large number of users, individual user experience often prioritizes how quickly a transaction confirms or a page loads [00:40:51]. There is often a trade-off between throughput and latency in computer science, and Monad aims to strike the best balance for user experience [00:41:40].
Monad is EVM compatible down to the bytecode level [00:36:21]. This ensures that everything functions identically to Ethereum, allowing direct deployment of contracts and consistency in RPCs [00:36:25]. The choice of VM (EVM vs. SVM, WASM, etc.) makes minor differences in performance [00:37:12]. The EVM is a powerful bytecode standard with rich tooling and applied cryptography research [00:54:20]. Full compatibility prioritizes developer experience, allowing them to focus on business logic rather than worrying about system differences [00:39:38].
Monad contributes to the EVM ecosystem by exploring new, orthogonal directions like rebuilding the execution stack from the ground up, researching custom databases, and implementing asynchronous execution [00:54:39]. These Technical challenges and solutions in blockchain performance push the boundaries of what’s possible, potentially leading to future incorporations into Ethereum [00:54:50] and driving the future of high performance and scalable blockchains. The journey of Monad and the performance and scalability of EVM chains illustrates the challenges and opportunities in blockchain scalability and the comparison of different database structures for blockchain efficiency in achieving higher performance.