Monad Architecture Explained

Monad is a high-performance Layer-1 blockchain featuring fast transactions, high throughput, and compatibility with the Ethereum Virtual Machine (EVM). Its core mission is to help scale dApps without sacrificing decentralization or security. Monad’s other distinctive features include parallel execution of multiple transactions simultaneously and an optimized consensus mechanism that reduces latency and improves finality. 

This article discusses the most important features of Monad’s architecture. For a more detailed overview, read the project’s official documentation.

Local Mempool

Most blockchains rely on a global mempool and peer-to-peer gossip protocols to propagate transactions. This way, all nodes know pending transactions so that any leader can include them in a block. However, it’s inefficient for high-performance blockchains due to three main issues:

1. Latency: Transactions may take many hops to reach the leader, increasing time-to-inclusion.
2. Bandwidth Waste: Gossip protocols involve excessive retransmissions.
3. Leader Schedule Ignorance: Even though the leader’s order is usually known in advance, gossiping sends transactions indiscriminately.

Monad’s Alternative: Local Mempools and Directed Forwarding

Monad eliminates the global mempool in favor of local mempools maintained by each validator. Instead of gossip, RPC nodes directly forward transactions to the next few scheduled leaders, improving efficiency and reducing latency.

Local Mempool Eviction Policies

Transactions are removed from a validator’s local mempool in three situations:

• After block finalization, transactions included in the block are pruned.
• Invalid transactions (due to nonce or balance issues) are periodically removed.
• If the mempool exceeds its soft size limit, older transactions are evicted.

Benefits of Monad’s Design

• Faster transaction inclusion is achieved by sending information directly to relevant leaders.
• Lower bandwidth usage by avoiding unnecessary gossip retransmissions.
• Scalability for high-throughput systems due to streamlined communication.

Open graph

Monad’s Transaction Lifecycle

A transaction in Monad follows the sequence of steps described below.

1. Submission: A user submits a transaction to an RPC node (the “owner node”).
2. Static Checks: The RPC node validates basic aspects of the transaction.
3. Consensus Checks: Further static and dynamic checks occur, including account balance and nonce validation.
4. Forwarding to Leaders: The transaction is sent to N upcoming leader validators (three in Testnet).
5. Leader Mempools: These leaders validate the transaction again and, if valid, add it to their local mempools.
6. Inclusion: When a leader’s turn arrives, it proposes a block using transactions from its local mempool.
7. Retry Mechanism: If a transaction isn’t included within N blocks, the owner node re-forwards it to the next N leaders, up to K times (three in Testnet).

Block Synchronization

Block synchronization (Blocksync) is a process that nodes use to retrieve missing blocks. Missing blocks are usually detected when a node sees a Quorum Certificate (QC) referencing a block it doesn’t have. Two situations can cause this.

1. After statesync, when a node is nearly synced with the network tip.
2. During normal consensus, if RaptorCast data isn’t fully received (e.g., due to packet loss or network issues).

Blocksync includes the following steps.

• A node requests headers for a range of num_blocks starting from a known block.
• It receives a verifiable chain of headers linking to the last known block.
• It then requests block bodies (in parallel, up to a set concurrency limit) using body_ids from those headers.
• Each body is verified against its corresponding header.

Open graph

Other Important Features

Monad closely mirrors Ethereum in its account and transaction structure.

• Accounts: Identical to Ethereum, using 20-byte ECDSA addresses. Supports both Externally-Owned Accounts (EOAs) and Contract Accounts.
• Transactions: Follow Ethereum standards (EIP-2718, RLP encoding), with optional support for access lists (EIP-2930).
• Block and Transaction Order: Both remain strictly linear. Parallelism is used only for performance, not for changing outcomes.
• Gas: This works like Ethereum’s gas model. Opcode costs are the same for the time being, and users specify gas limits and prices. Transactions are prioritized using a priority gas auction (PGA).
• Base Fee: Hardcoded to 50 gwei (similar to Ethereum’s EIP-1559), and is burned. The final fee mechanism is still under development.
• Gas Limit Enforcement: Due to Monad’s delayed execution, gas limits and base fees apply to the transaction’s gas limit, not the actual gas used.

Conclusion

Monad’s architecture is unique for its focus on high-performance, parallel execution while maintaining Ethereum compatibility. The innovations, including parallel execution, removal of global mempool, and optimized block synchronization and consensus mechanism, make Monad one of the most promising EVM-compatible Layer 1 blockchains today.

Stay tuned to all Monad-related updates and subscribe to Everstake’s in-house expert on X.

***