Introduction

Gmonad, and welcome to another ValiDAO deep dive! Today we're exploring the technical side of Monad. While details are still sparse, we've done our best to gather all relevant information and present what's known in one article.

If you've been on crypto twitter in the past year, you've no doubt come across the Mondalak. But you may be wondering: whence cometh the hype? What's Monad all about? Is Monad only popular because they have an insanely cute mascot? Let's find out!

In short, Monad is a highly performant Layer 1 blockchain, boasting full EVM bytecode compatibility and countless other chain-level optimizations that makes it a very fast chain.

These optimizations are primarily centered around custom and parallelized execution, a new consensus algorithm, and a custom state database known as MonadDB. Through these optimizations, Monad claims (and we believe them) to achieve 10,000 TPS and single-slot finality, all while maintaining relatively low hardware requirements for validato

Parallel Execution

Currently, most EVM implementations—such as those on Ethereum and its Layer 2 solutions—execute tasks serially, forcing the network to verify one process at a time. Rather than this sequential style of execution, parallel execution refers to the utilization of multiple threads and processors to run numerous actions concurrently.

Monad utilizes optimistic parallel execution, assuming that transactions can be executed concurrently without prior awareness of potential input/output conflicts. But how does it work?

This process consists of a few steps:

1. Executing multiple transactions simultaneously.

2. Checking for conflicts after execution.

3. Reverting any detected conflicting transactions.

4. Re-executing conflicting transactions in a sequential manner.

Similar to Ethereum, transactions within a block maintain a linear order, with Monad executing these transactions in parallel with the same security guarantees of sequential ordering.

Transactions begin from a common state point, generating pending results that document inputs and outputs. These results are committed according to the original transaction definitions, where the system then examines transactions and their pending results in a sequential manner. If these inputs and outputs influence other transactions and their pending results, re-execution takes place, which occurs only when inputs are altered as a result of outputs from another parallel transaction.

To better explain this point, let’s use an example involving two chefs. Cook A is making a salad (Transaction A), and Cook B is making a soup (Transaction B), where Cook B’s task depends on Cook A because they want to use some of the chopped vegetables for the soup. Cook A begins chopping the vegetables, but suddenly decides to change the vegetable type midway (maybe because they were given new instructions). Now, the vegetables Cook B was going to use are different. Since Cook B’s soup depends on the chopped vegetables from Cook A, this change means Cook B has to re-evaluate and re-execute part of their task, adjusting the soup to fit the new ingredients.

This style of consensus involving the re-execution of transactions is efficient because the dependencies and inputs for the transaction are cached from the parallel execution. This means that each transaction may be executed twice: once in parallel and potentially a second time in a serial manner.

Monad's approach differs from Solana's parallel execution method, with the key difference being that Solana utilizes access lists to predetermine which transactions can be executed concurrently. It requires transactions to specify the parts of the state they will interact with, creating access lists for each transaction. Afterward, transactions with non-overlapping access lists can be executed in parallel, while those with conflicts are processed sequentially. In Monad’s case, all transactions can be executed in parallel with re-execution for incompatible transactions sequentially.

MonadDB

MonadDB addresses a critical bottleneck in blockchain execution: that being state access. Traditional blockchain systems struggle with efficient state management, particularly when retrieving smart contract data stored on disk. This issue significantly affects transaction processing speed and overall system performance, severely limiting the performance of most current blockchains.

The process of state access in blockchains involves retrieving residual contract data, such as token balances for swap operations. Retrieving this information in the database can be very time-consuming, often taking between 10 to 20 microseconds per access. Merely parallelizing computation without optimizing state access results in minimal improvements; the challenge lies in concurrently optimizing both computation and state retrieval.

To address these limitations, Monad developed MonadDB, a custom-built key-value store optimized for Ethereum Merkle tree data and efficient state management. MonadDB leverages modern hardware capabilities, including solid-state drives (SSDs) and multi-core processors, to maximize performance. It utilizes the full bandwidth of SSDs and supports asynchronous input/output (I/O), employing technologies such as io_uring on Linux for enhanced operational efficiency.

Unlike traditional high-level key-value stores such as LevelDB or RocksDB, MonadDB is specifically designed for blockchain-related data structures and access patterns. This specialization enables more efficient parallel execution by reducing state access latency. MonadDB significantly minimizes the time required for state retrieval, massively improving on the typical 10-20 microsecond range in traditional systems.

While Monad takes a highly specialized design approach, MonadDB's architecture emphasizes a balance between performance and decentralization. It optimizes efficiency without necessitating extreme hardware specifications, targeting 32GB of RAM, which is significantly lower than the requirements of some other high-performance blockchains. This strategy stands in contrast to blockchains that heavily depend on increased RAM to alleviate state access bottlenecks.

The database maintains full compatibility with Ethereum's state structure, enabling the efficient replay of Ethereum's block history, ensured by executing Ethereum test suites and replaying historical data.

Additionally, MonadDB complements Monad's parallel execution model, facilitating faster validation of transaction inputs and outputs during processing. This synergy between efficient state access and optimistic execution supports Monad's objective of achieving over 10,000 transactions per second.

Developing MonadDB presented significant challenges due to the specialized nature of key-value store development. Furthermore, MonadDB's granular state access allows the system to distinguish between different components of a contract's state. For instance, in an ERC20 token contract, transactions that affect various user balances do not conflict. Monad’s approach with this level of granularity facilitates more efficient parallelization of transactions.

Conflict detection occurs after attempts at parallel execution, during which the system checks which specific parts of the state were accessed or modified. Conflicting transactions are then identified and re-executed sequentially, encouraging more efficient state access, as accessing the same state minimizes costly disk reads.

MonadBFT

MonadBFT is Monad's proprietary Byzantine Fault Tolerant consensus mechanism, built upon a modified version of the HotStuff consensus algorithm. Its primary objective is to achieve 1-second block times and single-slot finality, with an emphasis on transaction ordering rather than execution. MonadBFT integrates innovations from various BFT research papers, including the Distributed Asynchronous Multi-leader Fault Tolerant (DAMFT) consensus.

The algorithm utilizes various optimizations to enhance consensus efficiency.

1. Pipelining: This technique enables the overlapping of various consensus stages, thereby enhancing process efficiency.

2. Deferred Execution: This approach separates block proposals from full state computation. The leader is not required to include the new Merkle root, allowing for more time to streamline execution and consensus processes.

3. The team has significantly enhanced the distribution mechanism by optimizing the gossip layer and peer-to-peer network. This optimization focuses on the efficient broadcasting of proposals, potentially utilizing advanced tree structures.

4. Probabilistic Assembly: This approach reduces data transmission, thereby enhancing efficiency.

5. Data Compression: The algorithm employs compression techniques to minimize the volume of data transmitted, including optimistic and probabilistic compression.

These optimizations offer several advantages:

1. Increased Execution Budget: This feature allows for additional time for transaction execution within each consensus round.

2. Improved Resource Utilization: Enhanced efficiency in the use of computational resources during block production.

3. Reduced Network Overhead: Decreased data transmission is required for achieving consensus.

4. Potential for Increased Throughput: The optimizations are designed to collectively support higher transaction volumes.

MonadBFT's design philosophy centers on utilizing the latest research in Byzantine Fault Tolerance (BFT) consensus, prioritizing performance while ensuring security.

Unlike Cosmos-based chains which typically impose an upper limit of validators to ~100, MoandBFT has no restriction on the number of active validators. Initially, Monad plans to launch with approximately 150 validators, which will grow over time, fostering a more decentralized network while maintaining high performance.

MonadBFT employs a priority gas auction method to prioritize transactions based on their fee levels, arranging them from highest to lowest. This approach facilitates faster block times and achieves single-slot finality, enabling Monad's objective of efficient transaction processing and high throughput.

Simply put, MonadBFT’s design choices include a highly optimized gossip layer and peer-to-peer network, efficient proposal broadcasting using optimized tree structures, and the implementation of probabilistic assembly and data compression techniques. These choices lead to reduced data transmission and enhanced efficiency, which contributes to the performant nature of Monad.

Conclusion

Monad is actively rewriting and optimizing key components of blockchain networks to create a new, efficient, and scalable Layer 1 blockchain. The platform leverages an optimistic parallel execution model and a custom state database, MonadDB, to enhance transaction processing. Its consensus mechanism, MonadBFT, ensures rapid block times and single-slot finality. Monad’s goal is to achieve a throughput of 10,000 transactions per second while maintaining full compatibility with the Ethereum Virtual Machine (EVM). This approach aims to attract liquidity, developers, and users from EVM-compatible chains by offering superior speed and high throughput.