From: thepipeline_xyz
Monad Labs, founded by Keone and James, formerly of Jump Trading and Jump Crypto, is focused on improving the performance and scalability of EVM chains. Monad aims to address the lack of reliable information about parallel EVM and other essential optimizations needed for true performance gains in blockchain technology [00:00:37].
Monad’s Approach to Parallel EVM and Optimizations
Monad Labs pushed the first parallel EVM algorithm over a year and a half ago [00:01:16]. Their optimistic parallel execution algorithm aims to complete transactions in a shorter period while maintaining linear ordering within the block [00:01:42]. The algorithm involves running transactions in parallel to generate pending results, which are then committed in the original order [00:02:02]. If an input is invalidated during commitment, the transaction is re-executed, typically a “cheap” process due to cached inputs [00:02:22].
However, Monad found that parallel execution alone offered little improvement over serial execution [00:03:18]. The primary bottleneck was identified as state access, where transaction dependencies on accounts and slots are stored on SSDs [00:03:30]. Existing databases used by Ethereum and other EVM-compatible blockchains do not support parallel access, leading to a single-file execution bottleneck even with multiple virtual machines running [00:04:02]. This realization led Monad to pursue other optimizations, particularly at the state database level [00:04:26].
The Custom State Database
The most expensive parts of blockchain operations include cryptography functions, hashing, and state access [00:09:06]. The actual business logic in most smart contracts is relatively cheap compared to these operations [00:09:26]. A single read from an SSD can take 80 to 100 microseconds or more, which is orders of magnitude longer than executing a simple smart contract [00:10:23]. Multiple sequential reads, common in transactions, can lead to significant delays [00:11:14].
Standard general-purpose databases like Pebble DB, RocksDB, LMDB, and MDBX are not optimized for blockchain state access [00:13:34]. They often involve embedding one data structure inside another on disk, leading to expensive, multi-traversal requests [00:12:53]. In contrast, Monad’s custom database is designed specifically for how blockchain data is stored and accessed, extracting maximum performance from hardware like modern SSDs [00:14:16]. For example, a modern SSD can perform 500,000 I/O operations per second [00:15:43], but general-purpose databases often make 10-20 requests for a single lookup, whereas Monad’s approach might only require one or two [00:16:51].
Separation of Execution and Consensus
Another key optimization by Monad is the separation of execution and consensus [00:17:18]. By not requiring execution to complete before consensus, these processes can run in parallel, providing more time for both [00:17:50]. In Ethereum, for example, within a 12-second block time, only about 100 milliseconds are allocated for execution, limiting the gas limit and amount of work that can be done [00:19:14]. Moving execution out of being a prerequisite for consensus (e.g., running it in parallel to the next consensus round) provides a massive unlock for execution capacity [00:19:47]. This approach doesn’t restrict leaders from executing transactions before proposing a block but allows greater flexibility and budget for others to run them in parallel [00:20:00].
”No Shortcuts” Philosophy
Monad’s “no shortcuts” philosophy emphasizes building performant systems from the ground up rather than relying on superficial fixes [00:20:58]. A common shortcut is to “throw a bunch of hardware” at the problem, such as requiring very large amounts of RAM [00:21:09]. While this might increase performance in the short term, 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, while still extracting maximum performance [00:21:51]. This approach, heavily influenced by their background in high-frequency trading (HFT), involves hyper-optimization at a granular level, including analyzing assembly instructions and optimizing low-level hardware interactions [00:30:51].
Monad’s development process is characterized by extensive experimentation and quantitative design [00:23:37]. They avoid assumptions, even seemingly intuitive ones (e.g., that access lists are always beneficial for parallel execution), by rigorously measuring and testing hypotheses [00:32:44]. This dedication often involves writing and discarding code, prioritizing robust, well-understood solutions over quick fixes [00:34:39].
EVM Compatibility and VM Differences
Monad is committed to full EVM compatibility down to the bytecode level [00:36:24]. This ensures that everything functions exactly the same as in Ethereum, avoiding “hiccups” or differences that can complicate contract deployment or RPC interactions [00:36:28].
There’s a common misconception that the Virtual Machine (VM) itself (e.g., SVM, WASM vs. EVM) makes a huge difference in performance [00:37:26]. However, James notes that the differences between VMs like EVM and Java VM (which is decades old) are minor and don’t intrinsically grant special capabilities [00:37:47]. Full EVM compatibility is primarily about tooling, developer experience, and seamless portability [00:39:04]. When developers don’t have to worry about subtle differences, they can focus more on business logic and building for the consumer [00:39:47].
Ultimately, users value responsiveness and low latency [00:40:00]. While there’s a trade-off between throughput and latency in computer science, Monad aims to balance these to provide the best user experience [00:41:40].
Standardized Benchmarks and Industry Progress
The crypto industry lacks standardized benchmarks, allowing anyone to make performance claims without accountability [00:44:54]. Claims of “200k TPS” often lack context about the type of transactions (e.g., simple token transfers vs. complex Uniswap or borrowing protocol interactions), making them potentially misleading [00:45:31].
Monad uses replaying recent Ethereum history as its internal benchmark [00:46:20]. They plan to release a public GitHub repository where others can download and replicate benchmarks for Monad and other chains [00:46:27]. This initiative aims to improve the overall engineering and scientific rigor of the industry, moving away from intuition and marketing towards validated hypotheses [00:48:48].
A significant “shortcut” that can “cheat” benchmarks is using excessively large amounts of RAM [00:50:24]. While RAM is faster, it is two orders of magnitude more expensive than SSDs (e.g., 2 terabytes of RAM costs 200 for a 2TB high-quality NVMe SSD) [00:50:50]. Jacking up RAM requirements doesn’t scale, isn’t decentralized, and would lead to increasing node requirements over time [00:51:29].
Monad’s Contribution to the Ethereum Ecosystem
Monad’s goal is not to “kill Ethereum” but to meaningfully contribute to and expand the EVM ecosystem [00:53:11]. The Ethereum research community increasingly recognizes the value of Monad’s unique approach: rebuilding the execution stack from the ground up, researching a custom database, and implementing optimizations like parallel execution and asynchronous execution [00:53:38].
Ethereum has established a powerful bytecode standard with rich tooling, applications, and applied cryptography research within the EVM context [00:54:20]. Monad leverages this existing work and explores new, orthogonal directions that aim to push the entire space forward [00:54:42]. Monad hopes their advancements could even be incorporated into Ethereum itself, further pushing the boundaries of what’s possible [00:54:50]. This exemplifies a collaborative approach to the future of blockchain cooperation and multichain ecosystems.