From: thepipeline_xyz
Monad DB is a fully custom state database, forming a crucial part of Monad’s redesigned software architecture. It is designed to address the bottlenecks of traditional blockchain systems, particularly concerning state access and growth, thereby enabling high-performance features like parallel execution [04:51:00].
Challenges in Traditional Blockchain Databases
Traditional blockchains, including Ethereum, store state using a logical structure called a Merkle Patricia Trie (MPT) [16:32:00]. This data structure is central to Ethereum’s design philosophy, allowing for succinct verification of transactions and state. It enables users to check the root of something and verify that all data under that root is as expected [17:19:00]. Without an MPT, verifying a transaction would require downloading the entire block, re-executing it transaction by transaction, and then checking if the transaction is included [17:36:00].
However, existing blockchain clients, such as Geth (Go Ethereum), LevelDB, or PebbleDB, typically use off-the-shelf databases like B-trees or LSM trees as their backend storage [16:48:00]. These traditional database structures are not inherently Merkle Patricia Tries. This creates a “tree traversal within a tree traversal” problem [19:20:00]. When a node logically traverses the Merkle Patricia Trie, it translates into multiple lookups within the underlying non-MPT physical database, leading to 16 to 32 times more overhead per lookup [19:36:00].
Furthermore, accessing state from a database, especially from hard disk drives (HDDs) or Solid State Drives (SSDs), is significantly slower than CPU execution itself [13:25:00]. If the computer is constantly waiting for data to be pulled from the database for each transaction, the benefits of parallel execution are nullified [15:16:00].
Architecture of Monad DB
Monad DB is a full redesign of a database where the Merkle Patricia Trie is the native way data is stored on disk [19:42:00]. This means that even if one were to store text or numbers in Monad DB, it would inherently be structured as a Merkle Patricia Trie [20:00:00].
Key architectural features include:
- Native Merkle Patricia Trie Structure: By directly structuring the Merkle Patricia Trie on disk, Monad DB eliminates the “tree in-direction” problem, vastly reducing the number of lookups required per traversal compared to traditional databases [19:50:00]. This results in 16 to 32 times fewer lookups [20:10:00].
- Asynchronous I/O: Monad DB utilizes kernel technology called
IO_uringto perform asynchronous I/O operations [20:58:00]. This allows the system to issue a multitude of requests to the database in parallel without waiting for each one to complete [15:25:00]. As requests return, they are immediately fed into the execution engine [15:32:00].
Role in Optimizing Blockchain Efficiency
The primary role of Monad DB is to ensure the parallel execution engine is continuously saturated with data [15:01:00].
By providing parallel state access, Monad DB prevents the database from becoming a bottleneck:
- Feeds Parallel Execution: It allows dependencies for many transactions to be pulled from the database simultaneously [15:07:00].
- Saturates Memory Bandwidth: The design emphasizes saturating the memory bandwidth of modern hard drives, ensuring that data is always being pulled in parallel, preventing other parts of the system from being bottlenecked [16:09:00]. Modern SSDs, costing around $200, can offer about a million I/O operations per second, making it crucial to utilize their capabilities fully [15:42:00].
This combination of native MPT structuring and asynchronous I/O capability is the “secret sauce” that makes parallel execution truly effective on Monad, as it ensures that the compute resources are constantly fed with the necessary state data efficiently [21:19:00].