MonadDb: the database is part of the consensus budget

Most of the time in an EVM call is not the arithmetic. It is finding the word of state the call wants, proving that word sits in the Merkle tree, and writing the new word back. A client that does this through a general-purpose database pays a tax on every read: extra copies, a layout that is not the tree, and a lock that assumes one thread. Monad’s answer is MonadDb, a store built for that tree and for many readers at once.

Why it sits under the executor

Optimistic parallel execution issues many reads before it knows which transactions will survive. If those reads queue behind one another, the parallelism was theatre. MonadDb is the component that makes the concurrent reads cheap enough that the replay path, not the disk, is the limiting factor. Asynchronous execution makes the same demand one level up: execution is still flushing the last block while consensus has moved on, so the store cannot be a single lock held across both.

For people who do not run a validator, the consequence is indirect and practical. Indexers that reconstruct state by replaying every receipt from genesis will feel the block rate first. At 300 milliseconds, a naive poller that asks for “the latest block” on a one-second timer is already three blocks behind and does not know it. Historical state, the kind a trader wants when they ask what a pool looked like at a given slot, is an indexer problem. The chain will give you the current root quickly. It will not file your notebooks.

If the database is slow, the parallel executor is a diagram.

What not to infer

MonadDb does not make an archive query free, and it does not remove the need for a receipt. A dapp that reads state through the standard eth_call path gets the concurrency the node has. A dapp that scrapes logs in a single thread gets the concurrency it wrote. The database is part of the chain’s budget. It is not part of yours until your client uses it.

Store the tree in the shape of the proof

Account state on an EVM chain is a Merkle Patricia trie. A call does not want “the next row”. It wants a scattered word, and a proof that the word sits where the state root says it sits. A stock database stores bytes in an order chosen for general files, then the client reconstructs the proof. MonadDb is the store built the other way round: the layout follows the trie, and many readers can be in it at once. Those readers are required by the executor. Optimistic parallelism issues state reads before it knows which transactions will survive the conflict check. If the reads queue, the diagram of parallel execution was a drawing.

More than one version is in the building

While execution is speculative, the store is holding work that a replay may throw away. That is a database problem, not a slogan. Versions have to be cheap to keep and cheap to drop, or the node takes a lock and becomes serial at the exact moment the scheduler tried not to be. Application code does not see those versions. An eth_call is answered from committed state. It is not answered from the speculative fork, and it is not answered from three slots ago unless the node you asked has kept the history. “The chain is fast” and “this RPC has the history I wanted” are separate sentences.