From: thepipeline_xyz
Building a performant Ethereum Virtual Machine (EVM) implementation requires careful consideration of the underlying database. While standard databases like Pebble DB or Rocks DB are commonly used, their general-purpose nature often leads to significant performance bottlenecks, highlighting the importance of a custom state database like Monad Database [00:00:02], [00:00:17].
Blockchain Performance Bottlenecks
The most expensive operations in blockchain execution are cryptography functions (such as elliptic curve cryptography and hashing) and state access [00:00:22], [00:00:35]. In contrast, even complex business logic within most smart contracts is relatively cheap to execute compared to typical desktop or phone applications [00:00:41], [00:00:51]. There isn’t a significant amount of computation in modern blockchains, so parallelizing computation alone does not yield substantial performance gains [00:00:55], [00:01:00].
Profiling code reveals that the majority of time is spent on database operations [00:01:30], [00:01:35]:
- SSD Latency: A single read from an SSD can have a latency of 80 to 100 microseconds or more, depending on the model and generation [00:01:38], [00:01:40], [00:01:45]. This is orders of magnitude longer than executing a simple smart contract [00:01:56].
- Sequential Reads: A single transaction often requires multiple sequential reads from the database. For example:
- Reading the sender’s account to check their balance [00:02:07].
- Reading the destination account [00:02:11].
- Reading proxy accounts [00:02:13].
- Reading storage slots for ERC-20 token balances or Uniswap data [00:02:17], [00:02:21], [00:02:23], [00:02:25].
- Cumulative Latency: When these reads are summed up, assuming data is not cached in main memory, the total time to execute even a single transaction becomes significant [00:02:30], [00:02:39], [00:02:41].
Limitations of Standard Databases
Throwing more RAM at the problem to cache everything and avoid disk reads is one option, but it requires expensive hardware [00:02:53], [00:02:56]. Modern SSDs offer amazing performance (e.g., 500,000 I/O operations per second for some hosts) [00:03:22], [00:06:53], [00:06:58]. However, when blockchain clients use general-purpose databases, this raw performance is often wasted, resulting in poor overall performance [00:03:43], [00:03:51].
Common issues with standard databases in a blockchain context include:
- Nested Data Structures: Embedding one data structure inside another that resides on disk leads to expensive operations, as every request traverses two data structures [00:04:06], [00:04:09], [00:04:14].
- General Purpose Design: Databases like B+ tree databases (e.g., LMDB, MDBX) or LSM trees (e.g., RocksDB, LevelDB) are general-purpose [00:04:30], [00:04:37], [00:04:40], [00:04:42]. They are designed for average performance across various applications, not for specific, high-performance use cases like blockchain [00:04:50], [00:05:02], [00:05:05].
- Excessive Requests: Standard blockchain clients using these databases can make an excessive number of requests (e.g., 20 requests) to look up something basic, severely hindering performance [00:07:39], [00:07:42], [00:08:09], [00:08:11].
The Monad Database Approach
The approach taken with Monad Database is akin to techniques used in High-Frequency Trading (HFT), where standard libraries and data structures are avoided in favor of highly customized solutions [00:05:10], [00:05:14], [00:05:17]. By customizing the data structure to the specific trading model, significantly better performance can be extracted from the hardware [00:05:20], [00:05:23].
Monad Database applies this principle to EVM:
- Customization: By knowing exactly how the data needs to be used and stored, Monad Database is implemented in a way that is optimized for blockchain state access [00:05:32], [00:05:36], [00:05:40], [00:05:42].
- Efficiency: This super-optimization extracts every last bit of performance from the hardware [00:08:14], [00:08:16]. For instance, Monad DB might require only one or two requests to look up an account, compared to twenty requests by other data structures that are not in cache [00:07:59], [00:08:02], [00:08:06].
- Hardware Leverage: A modern SSD is packed with immense capability, and a custom database ensures this capability is fully leveraged, rather than being wasted by unoptimized general-purpose algorithms [00:06:28], [00:06:31], [00:06:34], [00:07:04], [00:07:33].
[00:07:10] You can’t throw um you know one thing you study in computer science is like complexity right and an algorithm which is has better computational complexity but is actually more poorly implemented will still perform better so you can’t um you can’t just let that you know you can’t just forget about your your optimizations and be like okay the hardware is going to take care of it you know you’re just wasting basically the capability that’s there.
By designing a database specifically for the demands of an EVM, Monad Database aims to unlock superior performance that general-purpose solutions cannot achieve.