Introduction

Ethereum is known as the most popular blockchain for several reasons. It's not only a hub for blockchain research, Dapps, and communities, but it also possesses the highest Total Value Locked (TVL), which highlights its significant role in the blockchain world. However, Ethereum faces major challenges, namely low throughput, high gas fees, and long finality times, leading to bad experiences for both users and developers.

Consequently, many projects have raced in search of new blockchain solutions. These platforms offer unique approaches to addressing some of the challenges faced by Ethereum. Yet, these alternatives encounter a new challenge: the absence of EVM compatibility, which results in a trade-off between scalability and user experience. EVM compatibility is crucial, as it allows the ecosystem to continue utilizing the familiar and widely adopted tools designed for Ethereum's architecture. The absence of EVM compatibility in new Layer 1 blockchains leads to the development of entirely new tools, causing developers and users to adapt to a completely different environment. Additionally, EVM compatibility also eases the transition for existing Dapps built on Ethereum, allowing them to migrate to new chains without rebuilding from scratch.

Monad: A Layer 1 Blockchain with High Throughput, Low Finality Time, and Fully EVM Compatible

Monad is a fully EVM-compatible Layer 1 blockchain with high throughput and low finality time. Monad achieves this improvement by optimizing in four major areas:

• MonadBFT

• Deferred Execution

• Parallel Execution

• MonadDB

These improvements allow Monad to process up to 10,000 transactions per second and achieve finality within one slot. Let’s dive into each of these four improvements one by one.

MonadBFT

If you're familiar with Tendermint or HotStuff, you'll grasp MonadBFT with ease. If not, no worries—I'll explain it step by step. Tendermint, primarily used in the Cosmos ecosystem, requires three phases to commit a block at a specific height: propose, pre-vote, and pre-commit. Initially, a leader proposes a block and broadcasts it to other validators. Subsequently, validators perform two rounds of voting by exchanging messages before reaching a consensus and committing to the proposed block, leading to O(n²)

communication overhead. In Tendermint, nodes must complete (commit) the current block before proceeding to the next.

MonadBFT, on the other hand, takes a 2 round leader-centric fan-out-fan-in style approach. Differing from Tendermint, MonadBFT follows a leader to all, to (next) leader commit sequence. When a leader proposes block k and distributes it to all validators, each validator sends their vote directly back to the leader of the subsequent block k+1. This leader uses the received votes to create the QC for the block k (commit phase 1), then proposes the new block k+1, and broadcasts it along with the QC to the validators at which point each validator can safely commit to block k (commit phase 2). MonadBFT is a pipelined structure piggybacking the votes for round k+1 onto round k, reducing latency and the number of communication steps. Monad BFT can be visualized as follows:

1. Alice sends a block proposal for block k to all of the validators.

2. Each validator checks the validity of the block (signatures, etc). If the block is valid, the validator sends a signed YES vote to the next leader, Bob.

3. Bob aggregates the YES votes on block k into a Quorum Certificate (QC). This QC on k is packaged with the new block proposal (k+1).

4. Again, validators evaluate and send YES votes to the next leader, Charlie.

5. Charlie aggregates YES votes on block k+1 to form QC(k+1). Again, this is packaged with the new block proposal.

6. Upon receiving QC(k+1), any validator can enshrine block k in the chain history. This is because even in the event that Charlie was Byzantine and only sent Proposal k+2 to this one validator, possession of QC(k+1) makes him confident that in a timeout scenario the other nodes would time out while pointing to k or a descendant of k as the last known checkpoint.

MonadBFT introduces a pipelined approach that significantly enhances the consensus process. The above figure shows the overlap in the processing of blocks, where the stages of consensus for a given block are executed in parallel with other blocks in subsequent rounds. This pipelining ensures that while one block is in the pre-vote stage (the first voting stage), another can simultaneously be in the pre-commit (the second voting stage) or commit stages. A validator commits a block at round k when the block's QC has passed two stages of voting and gets included in the round k+2 block. By doing so, MonadBFT can optimize its consensus efficiency and minimize unnecessary communication overhead between subsequence blocks.

Deferred Execution

The core concept of Deferred Execution in Monad is to decouple the consensus from execution. By doing so, nodes can quickly agree on the order of transactions without waiting for transaction execution to complete before agreeing on the order of transactions. Here's how it works:

1. Decoupling Consensus from Execution: In traditional blockchains like Ethereum, consensus and execution are coupled, meaning that transactions are executed first to determine the state and correctness before reaching consensus on a block. In contrast, Monad allows nodes to agree on the transaction order without the need to execute the transactions. By doing so, Monad can pipeline the execution of one block while simultaneously reaching consensus on the next. This enables a much more efficient use of resources, as execution is no longer a bottleneck for the consensus process.

2. Deterministic State: Monad relies on the principle that once the transaction order is decided, the outcome of the state is deterministic. Therefore, nodes can independently execute transactions after consensus is reached on the order.

3. Delayed State Commitment: To ensure that all nodes execute transactions correctly and to prevent malicious behavior, Monad introduces a delay in the commitment of the state root. Blocks include a Merkle root that is delayed by a certain number of blocks (denoted as D), meaning that for non-full nodes the state of block N-D is officially considered valid when the network reaches a consensus on block N. This provides incentive for network participants to run a full node which increases the security of the network. Furthermore, the delayed Merkel root also limits the largest number of blocks a consensus participating full node can fall behind, ensuring a healthy network.

Deferred Execution thus allows Monad to significantly improve scalability and speed by enabling consensus to proceed without waiting for transaction execution independently.

Parallel Execution

Parallel execution in Monad is a key feature that significantly improves transaction processing efficiency. Monad achieves this parallelism through Optimistic Execution which inherently has two phases.

1. Optimistic Execution: Monad utilizes optimistic execution, meaning it processes transactions optimistically to determine the dependencies. Here, Monad starts processing transactions without waiting for the previous ones in the block to finish while tracking the inputs and outputs of each transaction. Executing transactions in this way reveals the  dependencies between transactions, allowing for efficient re-execution

2. Re-Execute Dependencies: By tracking inputs and outputs of each transaction, Monad’s execution engine can determine the dependencies of each transaction empirically in a manner that efficiently short circuits the need for complex scheduling algorithms. In the case of a long sequence of dependent transactions, optimistic parallel executions can lead to a significant number of re-executions; however, the beauty of optimistic execution is that it forces the system to pre-fetch all the memory dependencies into the cache, meaning re-executions are extremely cheap.

This parallel execution strategy allows Monad to optimize transaction throughput while maintaining the integrity and deterministic nature of transaction execution and avoiding complex scheduling problems. This strategy simultaneously maintains the standard EVM developer experience, avoiding the requirement of providing access lists when submitting transactions.

MonadDB

Ethereum uses a data structure called Merkle Patricia Tree (MPT), the combination of a Merkle tree and a Patricia tree, to store its states to make it efficient to retrieve data from the tree while ensuring tamper resistance. However, when Ethereum clients store this data locally, they typically use databases like LevelDB or RocksDB. These are just conventional key-value stores, which organize data in a simpler, table-like format. They don't natively understand the tree structure of the MPT.

Thus, Monad introduced its own database called MonadDB, which is optimized to be natively compatible with the Patricia Trie data structure and suitable for the Monad architecture. Since Monad employs parallel executions, it is necessary to be able to read the state from the disk in an asynchronous manner (in parallel) without waiting for the other operation to complete. The above-mentioned database doesn’t properly support this property. By utilizing the latest advancements in async I/O, MonadDb avoids the bottlenecks that can occur when a system waits for one transaction to complete before moving on to the next, allowing asynchronous operations.

Conclusion

Monad is a Layer 1 blockchain designed to be fully EVM-compatible with high throughput and a low latency chain. Its consensus mechanism, MonadBFT, enables high transaction throughput and low finality times. Deferred Execution decouples the execution from the consensus logic, allowing both to run simultaneously. With optimistic parallel ExecutionMonad avoids the need for complex scheduling algorithms and onerous access lists while optimizing resource use. MonadDB, Monad's custom database, is optimized for Ethereum's data structures and facilitates parallel operations. All of these features make Monad one of the interesting blockchain solutions that you should keep an eye on.

References

[1] https://docs.monad.xyz/

[2] https://arxiv.org/pdf/1803.05069.pdf

[3] https://medium.com/ontologynetwork/hotstuff-the-consensus-protocol-behind-facebooks-librabft-a5503680b151