From: thepipeline_xyz
Monad Labs, founded by Keone and James who previously worked together at Jump Trading and Jump Crypto, is focused on achieving true performance gains in the crypto space [00:06:00] [00:13:00]. While the parallel EVM has become a significant narrative, Monad Labs emphasizes that this alone is not sufficient for optimal performance [00:24:00] [00:40:00] [08:05:00]. The real key lies in deeper, more fundamental optimizations, particularly at the state database level [04:47:00] [04:51:00].
The Bottleneck of State Access
Monad pushed the first parallel EVM algorithm over 1.5 years ago, known as optimistic parallel execution [01:16:00] [01:34:00]. In this approach, transactions are linearly ordered within a block and run in parallel, generating pending results with input/output records [01:39:00] [02:02:00]. These results are committed in original order, and if an input is invalidated, the work is rescheduled [02:15:00] [02:22:00]. Re-execution due to conflicts is typically cheap as inputs are often cached [02:47:00] [02:55:00].
However, Monad Labs found that parallel execution alone yielded minimal improvement [03:11:00] [03:18:00]. The core reason for this bottleneck is state access [03:30:00]. Each transaction has dependencies on accounts and slots stored on an SSD [03:35:00]. The cost of reading from an SSD is significant, and standard databases used by Ethereum and other EVM-compatible blockchains do not support parallel access [03:45:00] [03:57:00]. This means multiple virtual machines running in parallel still bottleneck at the database, effectively resulting in single-file execution [04:05:00] [04:15:00]. The most expensive parts of a blockchain are cryptography functions, hashing, and state access [09:06:00]. Paralyzing computation by itself doesn’t offer much gain [09:44:00].
A single read from an SSD can take 80-100 microseconds or more, which is orders of magnitude longer than executing a simple smart contract [10:23:00] [10:41:00]. Sequential reads for sender accounts, destination accounts, proxy accounts, and storage slots (like ERC-20 balances or Uniswap data) add up to significant transaction execution times [10:52:00] [11:14:12].
Limitations of Standard Databases
Standard databases like Pebble DB, RocksDB (an LSM tree), LMDB, and MDBX (B+ tree databases) are general-purpose databases [13:13:00] [13:21:00]. They are designed for average performance rather than specialized, high-performance tasks [13:48:00]. Many blockchain clients using these databases exhibit terrible performance, despite the impressive capabilities of modern SSDs (e.g., 500,000 I/O operations per second for a $200 SSD) [12:09:00] [12:25:00] [13:37:00] [15:39:00]. A primary issue with these general-purpose databases in blockchain contexts is that they often involve embedding one data structure inside another on disk, making every request traverse two data structures, which is an expensive operation [12:51:00] [13:05:00]. Additionally, they often make many requests for basic lookups [16:27:00].
Monad DB: A Custom Solution
Recognizing these limitations, Monad Labs began developing its own custom database, the Monad database [04:28:00] [14:29:00]. This approach was inspired by their high-frequency trading (HFT) background at Jump Trading, where custom data structures were essential for shaving off latency and building performant systems [05:16:00] [06:06:00] [13:55:00]. In HFT, standard libraries are avoided because they are not optimized for specific trading models, whereas customized data structures can extract significantly better performance from hardware [13:59:00] [14:08:00].
The Monad database is designed with a precise understanding of how data will be used and stored within the blockchain [14:17:00] [14:24:00]. This custom-tailored design means that Monad DB can perform lookups with significantly fewer requests to the hardware (e.g., one or two requests to look up an account compared to 20 for other data structures not in cache) [16:43:00] [16:51:00]. This “super optimization” extracts every last bit of performance from the hardware [16:59:00] [17:01:00].
The “No Shortcuts” Philosophy
The tagline “no shortcuts” embodies Monad’s development philosophy [20:35:00]. This means a commitment to running on commodity hardware while extracting maximum performance, rather than simply “throwing hardware at it” by requiring expensive, very large RAM boxes [11:37:00] [21:03:00] [21:11:00]. While some projects aim for Raspberry Pi compatibility, Monad targets the capabilities of a modern $200 SSD [21:48:00] [21:51:00] [21:55:00].
The development process involves deep understanding, extensive experimentation, and a quantitative approach [23:37:00] [23:39:00]. This includes micro-optimizations, such as optimizing translation lookaside buffers for a 5% gain [30:09:00] [30:15:00] [30:31:00]. They analyze assembly instructions and continuously measure performance, avoiding assumptions that sound intuitive but may not be optimal (e.g., the potential counterproductiveness of access lists for performance) [30:53:00] [31:01:00] [31:20:00] [32:01:00]. This rigorous, iterative process often involves writing and discarding code, which takes significant time [23:45:00] [24:23:00] [34:36:00].
A common “shortcut” for scaling is to simply increase RAM requirements [50:21:00]. However, RAM is two orders of magnitude more expensive than SSDs (200 for a 2 terabyte NVMe SSD) [50:32:00] [50:53:00]. This approach doesn’t scale well and undermines decentralization by making it harder for regular people to participate in the network due to high hardware costs [17:17:00] [21:17:00] [21:24:00] [51:29:00].
Benchmarking and Transparency
To provide accurate information and move beyond marketing hype, Monad Labs stresses the importance of standardized benchmarks for blockchain performance [44:09:00] [44:54:00] [45:00:00]. Internally, they use replaying recent Ethereum history as their benchmark [45:08:00] [46:20:00]. They aim to release a publicly available GitHub repository where others can download and replicate benchmarks from Monad and other chains [46:24:00] [46:27:00]. This transparency and rigor, similar to scientific papers that allow for replication, would improve the engineering standards of the industry [49:00:00] [49:10:00] [49:32:00].
Benchmarking must provide context for TPS (transactions per second) numbers, differentiating between simple token transfers (where even unoptimized clients can achieve 50k TPS) and complex operations like Uniswap or borrowing protocol transactions [45:31:00] [45:55:00].
Impact on EVM Scaling
Monad’s work contributes meaningfully to Ethereum by exploring a new, orthogonal direction: rebuilding the execution stack from the ground up, researching custom databases, and implementing parallel and asynchronous execution [53:40:00] [53:45:00] [53:50:00]. The EVM is a powerful bytecode standard with rich tooling, and Monad leverages this existing foundation while pushing the boundaries of what’s possible [54:24:00] [54:36:00]. These deep, focused optimizations aim to address the fundamental scaling challenges of the EVM, allowing for greater throughput and lower latency for users [33:03:00] [40:00:00] [40:51:00].