From: thepipeline_xyz
The primary bottleneck preventing the Ethereum Virtual Machine (EVM) from scaling is state access [03:33:00], [30:05:00]. This refers to the process of reading and writing data stored on the blockchain’s state database, which typically resides on Solid-State Drives (SSDs) [03:45:00].
The Problem with State Access
Even with advancements like parallel execution in blockchain technology (often referred to as the parallel EVM), significant performance gains are not achieved if the underlying state access remains inefficient [03:18:00]. The actual bottleneck lies in how the state is accessed and managed [03:30:00].
Key issues contributing to this bottleneck include:
- High Latency of SSD Reads A single read from an SSD can have a latency of 80 to 100 microseconds or more [10:25:00]. This is orders of magnitude longer than the time it takes to execute a simple smart contract [10:41:00], [10:44:00].
- Sequential Reads and Cumulative Time A single transaction often requires multiple sequential reads from the database, such as reading the sender’s account, destination account, proxy accounts, and storage slots for ERC-20 balances or Uniswap data [10:50:00], [11:02:00], [11:07:00]. When these reads are sequential, their cumulative time significantly prolongs transaction execution [11:16:00], [11:28:00], [11:30:00].
- Lack of Parallel Access Support Databases currently used by Ethereum and other EVM-compatible blockchains to store state do not inherently support parallel access [03:58:00], [04:02:00]. This means that even if multiple virtual machines are running in parallel, they still bottleneck when making reads to the database, effectively resulting in single-file execution [04:05:00], [04:08:00], [04:13:00].
- Inefficient General-Purpose Databases Many blockchain clients utilize general-purpose databases like PebbleDB, RocksDB, LevelDB (LSM trees), LMDB, or MDBX (B+ tree databases) [08:53:00], [13:14:00], [13:21:00], [13:24:00]. These databases are not optimized for the specific data access patterns of blockchains [13:34:00], [13:50:00].
- Nested Data Structures Ethereum’s database design embeds one data structure inside another, meaning every request involves traversing two data structures, which is an expensive operation [12:53:00], [13:03:00], [13:07:00].
- Over-reliance on RAM A “shortcut” to mitigate state access latency is to simply require large amounts of RAM [11:37:00], [50:21:00]. However, this is significantly more expensive (RAM is two orders of magnitude costlier than SSDs for the same storage capacity) [50:32:00], does not scale well over time as state grows [51:00:00], and compromises decentralization by increasing hardware requirements for participants [51:29:00].
Monad’s Approach to State Access Optimization
Monad Labs identified state access as the primary bottleneck over a year and a half ago, after finding that optimistic parallel execution alone yielded minimal performance improvement [03:11:00], [04:17:00]. Their solution was to develop a custom state database tailored specifically for blockchain use cases [08:31:00], [09:03:00].
This approach is inspired by their background in High-Frequency Trading (HFT), where building highly performant systems from the ground up, avoiding standard libraries, and optimizing at the lowest levels (e.g., assembly instructions) is critical for shaving off latency [05:25:00], [06:06:00], [13:55:00], [30:53:00].
Key aspects of Monad’s solution:
- Custom Database for Optimized Access Monad’s database is designed knowing exactly how data is stored and accessed, allowing for significant optimization over general-purpose databases [14:17:00], [14:20:00], [14:30:00]. This means performing fewer requests to the underlying hardware (e.g., 1-2 requests to look up an account in Monad’s database versus potentially 20 requests in other data structures when not cached) [16:46:00], [16:54:00].
- Leveraging Modern SSD Capabilities Modern SSDs are highly performant, capable of 500,000 I/O operations per second (IOPS) [12:09:00], [15:10:00], [15:16:00], [15:46:00]. Monad’s custom database is built to fully extract this capability from commodity hardware, rather than just throwing more RAM at the problem [12:02:00], [21:05:00], [21:11:00], [21:13:00], [21:16:00].
- Holistic Optimization Approach Monad’s performance optimization is not just about parallel execution or the database, but a combination of many specific, highly focused optimizations that add up to significant speedups [04:47:00], [04:49:00], [15:19:00], [30:11:00], [31:10:00], [33:15:00]. This includes micro-optimizations like translating virtual to physical addresses for TLB (Translation Lookaside Buffer) [30:18:00], [30:20:00].
By taking this “no shortcuts” approach, Monad aims to build a blockchain that can handle the scale required for broader adoption, supporting scenarios like fully on-chain limit order books with sub-cent fees and thousands of orders per second [28:33:00], [28:41:00], [28:47:00]. This also ties into the need for performant blockchains and high throughput blockchains to bridge the gap between traditional finance volumes and DeFi [27:31:00], [27:51:00].