From: thepipeline_xyz
Monad features a fully custom state database called Monad DB, which is crucial for its high-performance capabilities [04:51:30]. This database is a fundamental component that enables Monad’s parallel execution and overall efficiency [04:51:30].
The Problem: Traditional State Storage in EVM Blockchains
Traditional blockchain designs often face fundamental constraints including network bandwidth, CPU throughput, state access, and state growth [02:21:26]. When it comes to state access, a significant bottleneck arises from how Ethereum-like blockchains store their historical state [02:33:04].
Merkle Patricia Trie and Off-the-Shelf Databases
Ethereum stores its state in a Merkel Patricia Trie (MPT), a tree structure designed to allow for succinct verification of transactions and state [00:26:50], [01:32:46]. This means you can check the root of something to determine if all data under that root is as expected [01:26:22]. For example, to verify if a transaction is included, with an MPT you don’t need to download and re-execute the entire block [01:37:05].
However, most Ethereum clients like Go Ethereum and Aragon use off-the-shelf databases (e.g., B-trees or LSM trees) to store this MPT [01:47:30]. These standard databases are not natively built as a Merkle Patricia Trie [01:48:47]. This creates an inefficiency: when logically traversing the MPT, the system performs a “tree traversal within a tree traversal” because it has to look up nodes in the non-MPT backend database [01:50:52], resulting in 16 to 32 times more overhead per lookup [01:50:52].
Furthermore, execution is incredibly cheap, but the time-consuming part is calling up the state for a transaction from the database, which involves going to the hard disk, reading into RAM, and then executing [01:27:08]. If the computer is waiting for the database to pull dependencies every time a transaction is executed, parallel execution becomes irrelevant [01:15:07].
What Monad DB Is
Monad DB is a complete rebuild of a database where the Merkle Patricia Trie is the actual way data is stored on disk [01:41:40], [01:44:48]. This design natively structures the Merkle Patricia Trie on disk, removing the “tree in direction” problem present in other implementations [01:49:18], [01:50:52].
Key Technologies
- Native MPT Structure: Monad DB makes Ethereum state native to how Ethereum works logically, directly storing the Merkle Patricia Trie on disk [01:47:50], [02:02:16].
- Asynchronous IO: It utilizes a kernel technology called
IO_Uringto enable asynchronous I/O [02:07:34], [02:09:07]. This allows Monad DB to issue many requests to the database in parallel and immediately execute transactions as the results come back [01:25:01].
Impact of Monad DB
Monad DB serves as the “secret sauce” that allows parallel execution to truly work [02:18:55]. Its impact is seen in several areas:
- Saturates Parallel Execution: By enabling parallel state access, Monad DB ensures that the parallel execution engine is continuously fed with the necessary data, preventing bottlenecks where the system would otherwise wait for database lookups [01:15:07], [01:59:44].
- Reduced Lookups: The native MPT structure drastically reduces the number of database lookups per tree traversal (16 to 32 times less) compared to off-the-shelf databases [02:10:20].
- Efficient State Access: The combination of native MPT storage and asynchronous I/O makes state access very efficient, keeping the compute saturated [02:14:46].
- High Performance: This efficiency contributes to Monad’s ability to achieve high throughput, handling 10,000 real Ethereum transactions per second [00:39:10].