How Monad Works: A Deep Dive into Its Innovative Architecture

Monad is a cutting-edge blockchain platform designed to deliver high performance without compromising decentralization. It is engineered to support seamless redeployment of EVM-equivalent bytecode and advanced features like the Cancun fork, making it fully compatible with Ethereum’s opcode and gas mapping standards. With block times of 500 ms and finality achieved within 1 second, Monad’s design focuses on efficiency, scalability, and a globally distributed validator network.

Read More: What is Monad Airdrop?

Key Takeaways:

• EVM Compatibility and Fast Finality: Monad supports EVM bytecode redeployment and Ethereum-standard opcodes while delivering blocks every 500 ms and finalizing within 1 second.
• Innovative Consensus and Execution: Its MonadBFT consensus mechanism, asynchronous execution, and optimistic parallel execution model enable high throughput with modest hardware.
• Efficient Data Transmission and State Management: The RaptorCast protocol and MonadDb optimize network bandwidth and state access, ensuring rapid data recovery and reduced storage overhead.

Network Parameters and Summary

Monad operates on an architecture that mirrors Ethereum in many respects—such as opcode-to-gas mapping and RPC conformance—yet it brings several enhancements to the table. The network supports redeployment of EVM bytecode without recompilation, features Cancun fork enhancements (TSTORE, TLOAD, MCOPY), and maintains a high block gas limit on its testnet. With blocks generated every 500 ms and finality confirmed at block N+2, the system is built to handle high transaction volumes as it scales from an initial set of approximately 55 globally distributed validators to a larger pool.

Frugality and Decentralization

At the heart of Monad is the goal to achieve high performance with efficient algorithms that remain accessible and decentralized. The platform is optimized to run on nodes with relatively modest hardware requirements—for instance, a machine with 32 GB of RAM, dual 2 TB SSDs, 100 Mbps bandwidth, and a 16-core 4.5 GHz processor can be assembled for roughly $1500. This approach ensures that high-performance computing isn’t limited to a select few, but is distributed across a diverse, global validator set.

Node Architecture

Every Monad node is composed of three main components:

• monad-bft: Handles the consensus process.
• monad-execution: Manages transaction execution and state transitions.
• monad-rpc: Deals with user read/write operations.

Validators, numbering between 100 and 200, actively participate in the consensus, while non-voting full nodes monitor network traffic and execute every transaction to maintain full state replication.

Consensus Mechanism: MonadBFT

MonadBFT is the backbone of the platform’s consensus process. Featuring linear communication complexity, it scales efficiently even as the number of validators grows. In the ideal “happy path” scenario, a leader broadcasts a block proposal to all nodes, which then send attestations to the next leader. These attestations are aggregated into a Quorum Certificate (QC) using BLS signatures, enabling a streamlined “fan out, fan in” approach that guarantees quick and reliable finalization of blocks.

RaptorCast: Efficient Block Propagation

To manage the significant data volume generated by high transaction throughput, Monad employs the RaptorCast protocol. This innovative system uses erasure coding to split large blocks into smaller chunks. Each chunk is transmitted via a two-level broadcast tree—first received by one validator and then disseminated to others—ensuring that even with limited upload capacity on the leader’s side, all validators can reconstruct the original block efficiently.

Transaction Lifecycle

Transactions on Monad follow a well-defined process:

• Submission: Users send transactions to an RPC node.
• Propagation: The RPC node forwards the pending transaction to the next three scheduled leaders.
• Inclusion: Leaders add transactions to their mempools and include them in block proposals based on criteria like fee-per-gas-unit.
• Finalization: Once a block is proposed and validated by the network, consensus is reached, and the block is finalized through the MonadBFT process.

This targeted forwarding strategy minimizes network congestion while ensuring timely transaction processing.

Leader Election and Epochs

During each epoch—lasting roughly a day—leaders are selected via a deterministic pseudorandom function based on validators’ stake weights. Initially, leader roles are permissioned on the testnet, but staking mechanisms will soon enable a fully decentralized leader election process. Validator stake weights are fixed one epoch in advance, ensuring fairness and predictability in the leader schedule.

Asynchronous Execution

Monad separates consensus from execution by employing asynchronous execution. In this model, consensus is reached before executing transactions, allowing the system to “pipeline” these processes. Validators check the validity of transactions (signature, nonce, data cost) but postpone full execution until after block finalization. This decoupling frees up significant execution time, enhancing overall throughput.

Delayed Merkle Root for State Verification

Due to asynchronous execution, block proposals in Monad do not immediately include the Merkle root of the state trie. Instead, a delayed Merkle root from a few blocks back (currently set at a delay of three blocks) is included. This mechanism provides a safety net, ensuring that if discrepancies arise from computation errors, nodes can detect them by comparing against their local state after a predetermined delay.

Speculative Execution

To further optimize performance, nodes engage in speculative execution. Although only blocks finalized two blocks ago are officially executed, nodes pre-execute pending transactions from newer blocks. This speculative approach allows nodes to maintain a nearly up-to-date state, which in turn aids in faster transaction simulation and smoother user experiences.

Optimistic Parallel Execution

Optimistic parallel execution is a key innovation in Monad’s transaction processing. Transactions are executed concurrently to generate “pending results” that record storage slot reads and writes. These results are later committed serially, ensuring consistency as though the transactions had been processed one after another. This method allows most transactions to be executed at most twice, even when conflicts occur, thereby maximizing efficiency without compromising accuracy.

MonadDb: Optimized State Management

MonadDb is Monad’s custom database designed to store the state in a native Merkle trie. By eliminating an extra layer of indirection present in traditional databases, MonadDb minimizes I/O operations and accelerates Merkle root computation. Its support for asynchronous I/O and parallel state lookups synergizes perfectly with optimistic parallel execution, significantly reducing the bottleneck usually associated with state access.

Bootstrapping a Node: Statesync and Blocksync

Given the high throughput and long transaction history, new nodes typically initialize their state by syncing with peers rather than replaying every block from genesis. Monad employs statesync, where a node requests the latest state snapshot from its peers, and blocksync, which fills in any gaps by retrieving missed blocks. This process ensures that new nodes can quickly join the network with an up-to-date view of the state.

FAQs

Q1: What makes Monad’s consensus mechanism unique?
A1: MonadBFT is distinguished by its linear communication complexity and pipelined “fan out, fan in” approach, which allow for fast, scalable consensus even with a large number of validators.

Q2: How does Monad ensure efficient block propagation?
A2: Through the RaptorCast protocol, Monad uses erasure coding to split blocks into smaller chunks, reducing the upload burden on the leader and ensuring reliable transmission across the network.

Q3: What role does MonadDb play in the system?
A3: MonadDb optimizes state storage by maintaining a native Merkle trie, which speeds up state lookups, reduces I/O operations, and complements the platform’s optimistic parallel execution model.