Monad for Developers

Monad is an Ethereum-compatible Layer-1 blockchain with 10,000 tps of throughput, 400ms block frequency, and 800ms finality. Monad’s implementation of the Ethereum Virtual Machine complies with the Fusaka fork. The Monad client has been simulated with historical Ethereum transactions and produces identical merkle roots. Monad also offers full Ethereum RPC compatibility so that users can interact with Monad using familiar tools like Etherscan or MetaMask. Monad accomplishes these performance improvements, while preserving backward compatibility, through the introduction of several major innovations:

• MonadBFT, a frontier BFT consensus mechanism solving the tail-forking problem
• RaptorCast for efficient block transmission
• Asynchronous Execution for pipelining consensus and execution to raise the time budget for execution
• Parallel Execution and JIT Compilation for efficient transaction execution
• MonadDb for efficient storage of Ethereum state

Although Monad features parallel execution and pipelining, it’s important to note that blocks in Monad are linear, and transactions are linearly ordered within each block. The first Monad client is built by Category Labs and is written from scratch in C++ and Rust. The code is open-source under GPL-3.0 here:

• monad-bft
• monad

​

Transactions

​

Smart contracts

​

Consensus

​

Execution

The execution phase for each block begins after consensus is reached on that block, allowing the node to proceed with consensus on subsequent blocks.

​

Parallel Execution

Transactions are linearly ordered; the job of execution is to arrive at the state that results from executing that list of transactions serially. The naive approach is just to execute the transactions one after another. Can we do better? Yes we can! Monad implements parallel execution:

• An executor is a virtual machine for executing transactions. Monad runs many executors in parallel.
• An executor takes a transaction and produces a result. A result is a list of inputs to and outputs of the transactions, where inputs are (ContractAddress, Slot, Value) tuples that were SLOADed in the course of execution, and outputs are (ContractAddress, Slot, Value) tuples that were SSTOREd as a result of the transaction.
• Results are initially produced in a pending state; they are then committed in the original order of the transactions. When a result is committed, its outputs update the current state. When it is a result’s turn to be committed, Monad checks that its inputs still match the current state; if they don’t, Monad reschedules the transaction. As a result of this concurrency control, Monad’s execution is guaranteed to produce the same result as if transactions were run serially.
• When transactions are rescheduled, many or all of the required inputs are cached, so re-execution is generally relatively inexpensive. Note that upon re-execution, a transaction may produce a different set of Inputs than the previous execution did;

​

MonadDb: high-performance state backend

All active state is stored in MonadDb, a storage backend for solid-state drives (SSDs) that is optimized for storing merkle trie data. Updates are batched so that the merkle root can be updated efficiently. MonadDb implements in-memory caching and uses asio for efficient asynchronous reads and writes. Nodes should have 32 GB of RAM for optimal performance.

​

Comparison to Ethereum: User’s Perspective

​

Tooling and Infrastructure

Many leading Ethereum developer tools support Monad testnet. See Tooling and Infrastructure for a list of supported providers by category.

​

Next Steps

Monad’s public testnet is live. Head to Network Information to get started. Now that you are familiar with Monad’s architecture and features, head to Deployment Summary for Developers for everything you need to know to deploy.