Monad is a new layer-1 smart contract platform that recently raised $225 million in funding from venture capital firm Paradigm.

Although Monad has not launched yet, it is expected to be live on its public testnet in late 2024, with mainnet deployment planned for early 2025.

Monad is a parallel Ethereum Virtual Machine (EVM) project, and like similar projects such as Aurora (built on the Near Protocol) or Sei, it attempts to parallelize the execution of EVM instructions so the network can process multiple transactions concurrently. This makes it possible to handle a larger volume of transactions, increases throughput and reduces costs.

Parallelization involves breaking down transaction execution into smaller, independent tasks that can be processed simultaneously. Monad introduces four optimizations to improve its consensus, execution and data storage: MonadBFT, deferred execution, parallel execution and MonadDb.

MonadBFT

MonadBFT is a pipelined two-phase Byzantine-fault-tolerant algorithm designed to enhance blockchain scalability and efficiency. It’s a derivative of the HotStuff algorithm optimized to operate under partially synchronous conditions.

This optimization is important, as most real-world networks do not exhibit perfectly synchronous behavior due to variable message delivery times caused by network congestion, latency and other factors. By accommodating these partially synchronous conditions, MonadBFT ensures decent performance and reliability in practical deployments.

The HotStuff algorithm is a consensus protocol designed for blockchain systems to achieve Byzantine fault tolerance (BFT), which is a computer system’s ability to continue operating even if some of its nodes act maliciously or are faulty.

It achieves this robustness through a series of communication rounds among nodes to agree on the next block in the chain. HotStuff requires three communication rounds to reach a consensus, which can become a bottleneck for scalability and efficiency. MonadBFT improves HotStuff by reducing the communication rounds required for consensus from three to two.

The consensus mechanism works in phases. A leader node proposes blocks, and validators review them. In each round, the leader sends out a new block with either a quorum certificate (QC) or timeout certificate (TC) for the previous round. A QC is proof that a block has been approved by a majority of validators, indicating that they agree on the block’s validity.

A TC, on the other hand, indicates that the required number of validators did not reach a consensus within a given timeframe. This acts as a fallback mechanism to prevent the system from stalling.

Validators vote on the new block proposed by the leader. If a sufficient number of validators (two-thirds) approve, the block is finalized in subsequent rounds, and QCs are issued.

If validators do not receive a valid block in time, they send signed timeout messages, which can be aggregated into a TC. This TC is then sent directly to the next leader. A block is finalized when validators see two consecutive certified blocks.

This two-phase commit rule ensures rapid block finalization while maintaining network security and fault tolerance. As in all asynchronous BFT settings, two-thirds of Monad’s validator nodes must be non-adversarial and have an equal voting stake weight to maintain security.

Deferred execution

Deferred execution decouples transaction execution from consensus. Unlike traditional blockchains such as Ethereum, where nodes must execute transactions before establishing consensus, the MonadBFT consensus focuses solely on the order of transactions.

On Ethereum, nodes need to reach a consensus on both the list of transactions in the block and the Merkle tree root for the state post-transaction execution. This means the consensus leader needs to execute the transactions prior to submitting the block, and the validating nodes all need to redo this execution before casting their vote.

Block times can, therefore, become quite long, and the complexity of the computation the network can handle is reduced. MonadBFT’s consensus mechanism determines only the order of transactions and allows execution to occur independently after consensus is reached.

To ensure that execution is performed correctly, Monad delays agreement on the Merkle root of the state by D blocks. D is a systemwide parameter currently expected to be 10.

This design mitigates risks associated with a malicious node that does not execute transactions correctly. Once the network reaches a consensus on block N with a two-thirds majority vote, it thereby also agrees on the state represented by the Merkle tree in block N-D.

If any node discovers an error while executing block N-D, it votes against the proposal for block N. This triggers a rollback to the final state of block N-D-1, followed by the re-execution of transactions from block N-D. A node can verify and correct its execution results against other nodes in the network by checking its own Merkle root. Light nodes can query full nodes for Merkle proofs of state variable values.

Parallel execution

Popular parallel execution blockchains are either deterministic or optimistic.

Monad employs optimistic execution to achieve parallel transaction processing. This method is somewhat analogous to the speculative execution employed by central processing units (CPUs), where processors predict the path of branch instructions and execute them ahead of time.

Monad’s execution engine begins processing new transactions even before the execution of previous transactions is finalized, increasing overall throughput.

However, this strategy, called optimistic concurrency control, can lead to errors when subsequent transactions are interdependent. If a conflict is detected (e.g., when two transactions attempt to modify the same account balance), the affected transactions are re-executed to correct discrepancies.

In the worst case, a transaction must be executed twice, but in aggregate, this only adds 1.5% overhead. Monad also employs a static code analyzer to predict dependencies between transactions ahead of time. This static analysis allows Monad to identify potential conflicts before execution and, although it does not prevent all conflicts, helps to optimize the initial transaction scheduling for more efficient, optimistic parallel execution.

Sei also employs optimistic parallelization, assuming that transactions will not conflict, but it pursues a distinct approach to handling conflicts. During the parallelization process, Sei tracks which parts of the state each transaction modifies. If it detects that two transactions conflict, which means they attempt to modify the same part of the state, the system temporarily halts execution and reprocesses the conflicting transactions sequentially, similar to Monad.

However, Monad’s use of a static-code analyzer allows for more efficient transaction scheduling, thus reducing the possibility of conflict, whereas Sei simply addresses conflicts as they arise during execution.

Optimistic execution also eliminates the need for complex scheduling and dependency analysis algorithms, which are required for deterministic methodologies. In a deterministic approach employed by Sui and Solana, transactions must declare which parts of the state they will access before execution.

This upfront declaration allows the system to schedule transactions in a way that avoids conflicts during execution. The primary advantage of this method is predictability: Since dependencies are known beforehand, the system can ensure that transactions do not interfere with each other, resulting in consistent and reliable outcomes.

However, this predictability comes at a cost. Analyzing dependencies and scheduling transactions requires sophisticated algorithms, which must account for all potential interactions between transactions and introduce computational overhead, resulting in higher hardware requirements.

The need for real-time analysis and scheduling also adds to the complexity, as the system must continuously monitor and adjust the execution order to prevent conflicts.

Additionally, a deterministic approach may face challenges in scaling efficiently. As the number of transactions increases, the complexity of dependency analysis grows exponentially.

MonadDB

MonadDB is a custom database designed specifically to optimize the implementation of parallel execution. In traditional blockchains such as Ethereum, input/output (I/O) access becomes a significant bottleneck, primarily because these systems rely on synchronous I/O operations.

Processes must wait for each read or write operation to complete before moving on to the next, which severely limits throughput and overall performance. To overcome this limitation, MonadDB employs asynchronous disk operations, which allow the system to initiate multiple read and write operations simultaneously without waiting for each to complete. This enhances the overall speed of transaction processing, especially when combined with parallel execution.

Conclusion

Monad represents a significant advancement in blockchain technology. It employs innovative techniques such as optimistic execution, deferred execution and a custom database, MonadDB, to enhance scalability and efficiency.

Its optimistic parallelization method, akin to speculative execution in CPUs, allows for high throughput by processing transactions concurrently and re-executing conflicting transactions only when necessary.

Combined with static code analysis, this method optimizes transaction scheduling and reduces the likelihood of conflicts. Compared to other parallel EVM projects like Sei and deterministic systems like Sui and Solana, Monad’s approach balances efficiency and complexity, providing a robust solution for high transaction volumes.

The introduction of MonadBFT, a pipelined two-phase Byzantine-fault-tolerant algorithm, further ensures rapid block finalization and network security.

As Monad prepares for its public testnet in late 2024 and mainnet deployment in early 2025, it positions itself as a formidable player in the next generation of scalable blockchain platforms.