Published:: February 13, 2024

Last updated:: April 28, 2024

Monad Technical Architecture Characteristics

Monad is designed to combat the inefficiencies of Layer 2’s and stay true to the ethos of Monad as a Layer 1. To accomplish this, the network offers numerous advantages. These include:

High transaction throughput: Monad is able to process 10,000 transactions per second (TPS), a number that substantially outperforms most existing blockchain iterations. High transaction throughput is critical for applications that require rapid transaction processing.
Parallel execution: By implementing parallel execution, Monad is able to process multiple transactions concurrently, dramatically enhancing network efficiency, while minimizing latency compared to traditional execution methods that are sequential in nature.
Instant finality: MonadBFT pipelined consensus allows transactions to achieve instant block finality, ensuring faster and more reliable transaction settlement.
Ethereum compatibility: Monad’s EVM-compatibility allows Ethereum developers to port their applications to Monad, while also providing familiarity with Ethereum interface and tooling systems.
Optimized for scalability: Monad’s state-of-the-art parallel execution and superscalar pipelined consensus architecture is specifically built to address scalability bottlenecks, allowing the platform to support an ever-growing number of transactions and users.
Lower operational costs: The hyper-efficiency of the Monad platform ensures significantly lower transaction fees compared to most blockchain systems, ensuring the network is cheap, easy-to-use, and economically viable for users and developers alike.

As of this writing, Monad is the only blockchain in the industry that has combined EVM compatibility with parallel execution. (Image Credit: Keone Hon via Monad Twitter)

Ethereum Performance Bottlenecks and Monad EVM Compatibility

In today’s Ethereum landscape, the Ethereum blockchain is susceptible to several performance challenges related to its execution limitations (of 1.25M gas per second), including:

Inadequate storage access patterns
Single-threaded execution (as opposed to multi-threaded)
Extremely limited execution budget, considering consensus cannot be realized without execution
Issues related to state growth and its effect on future state access costs

Monad is built to tackle these constraints via algorithmic improvements and architectural modifications by pioneering numerous innovations that have the potential to become standardized on Ethereum in the not-too-distant future.

Monad is designed to address bottlenecks related to state storage, transaction processing, and distributed consensus through pipelining and optimizations in four significant areas (MonadBFT, Deferred Execution, Parallel Execution, and MonadDb). This design enables enhanced EVM performance by fundamentally advancing the decentralization/scalability tradeoff.

Moreover, many networks within the current blockchain landscape exhibit extreme scalability but lack Ethereum-compatibility, meaning their development environments do not allow Ethereum developers to easily port their applications to their chain. To combat this, Monad addresses numerous existing bottlenecks for developers (by implementing full EVM bytecode compatibility) and users (via Ethereum RPC API compatibility).

Through this design, Ethereum’s far-reaching multifaceted landscape of tooling systems and applied cryptography is able to seamlessly plug into Monad’s developer stack in various ways via:

Applications allows for full compatibility with applications built on Ethereum and vice versa
Developer tooling provisions connectivity to various Ethereum developer tooling systems such as Hardhat, Apeworx, and Foundry
Wallets enables cross-system functionality with most Ethereum wallet types including MetaMask and others
Analytics/indexing allows for full integration with various analytics and indexing tools such as Etherscan and Dune Analytics

Monad makes use of superscalar pipelining to create stages of work that are then executed in parallel, dramatically increasing transaction throughput on the platform. The above diagram compares pipelining to doing laundry, illustrating that more work can be completed over a shorter period of time using the model. (Image Credit: What’s Different About Monad? via Monad documentation)

An Overview of Superscalar Pipelining and Asynchronous I/O

In addition to the numerous additional innovations, Monad makes use of superscaling pipelining and asynchronous I/O to help the platform maintain its hyper-scalability.

Superscaling pipelining is a process that compliments the multi-threaded and multi-cored parallel execution framework that allows transactions to be executed in a parallelized manner by completing tasks in sequential stages (while still committing the results in the originally intended order).

With superscalar pipelining, stages of computation are initiated before the stages that initially commenced beforehand are completed, therefore exponentially improving the performance of the entire system. Pipelining is typically used in computer processors to dramatically improve throughout by executing a set of time-based instructions sequentially.

Asynchronous I/O is an input-output processing mechanism that enables a CPU to continue executing simultaneously while communication is in progress. Typically, disk and network orders are exponentially slower than the CPU.

Therefore, instead of initiating an input/output operation and awaiting the result, the CPU is able to initiate the input/output operation immediately when it knows that specific data is needed, while at the same time, executing additional instructions that are not dependent on the result of the input/output operation.

Ingeniously, Monad implements pipelining in four main ways to exponentially improve the scalability and transaction throughput of the network. These include pipelining at the consensus level, during transaction execution, between the execution and consensus phases, and at the state access level. (Image Credit: Monad Twitter post via Monad Twitter)

The Interconnected Aspects of Monad Consensus

Monad consensus makes use of four interconnected components that we’ll describe in greater detail throughout this larger section. These are:

Monad BFT Consensus - a byzantine fault tolerant (BFT) consensus mechanism that achieves agreement for arbitrary payload via partially synchronous conditions to maintain BFT tolerance.
Deferred Execution - implementing a major optimization to the mechanism of realizing consensus by removing execution out of the hot path of consensus.
Shared Mempool - implementing a substantial optimization related to consensus payload that allows the protocol to refer to transactions by hash, while also ensuring that transactions are propagated via the mempool beforehand.
Carriage Cost and Reserve Balance - implementing a behavioral modification to transaction pricing that is needed to defend against spam given that consensus is completed via a delayed view of execution.

Introduction to Monad BFT Consensus

Monad BFT achieves transaction agreement via partially synchronous conditions while under the influence of Byzantine actors. The consensus itself is a derivative of HotStuff consensus that implements 2 rounds similarly to iterations such as Joltean, DiemBFT, and Fast HotStuff instead of 3 via a process that implements quadratic communication complexity in the event of leader timeout.

MonadBFT is a two-phase pipelined BFT algorithm leveraging optimistic responsiveness and linear communication overhead and quadratic communication in the event of a timeout. Similarly to most BFT algorithms, communication is processed in phases.

At the start of each phase the leader sends a signed message to voters when they sign responses to the following leader. Pipelining enables the quorum certificate (QC) or timeout certificate (TC) for a specific block to piggyback on the proposal for that block.

When a quorum certificate is displayed in this instance, it means the network’s validators agreed to append the block, while a timeout certificate means the consensus round timed out and had to be restarted.

Byzantine Fault Tolerance (BFT) is a well-known consensus mechanism used in many blockchain systems. MonadBFT eliminates many of the challenges that earlier BFT-focused networks were susceptible to. (Image Credit: Zetrix via Zetrix documentation)

Monad BFT Consensus Overview

MonadBFT utilizes a pipelined consensus mechanism that makes use of time-base consensus rounds (or epochs) to process transactions and append blocks on-chain. Similarly to most BFT frameworks, on Monad, 2/3rd’s of validator nodes must be non-adversarial (accepted as legitimate and non-malicious) and have an equal voting stake weight. On Monad, the consensus process is conducted as follows:

1. In each consensus round, the leader broadcasts a new block as well as a timeout certificate or quorum certificate from the previous round.

2. Next, each validator reviews that block to determine if it should be added to the chain. Once in agreement, the validators send a signed YES vote to the leader of the next round. The leader then creates a quorum certificate (essentially a confirmation that all validators agree to add the block) by aggregating YES votes (via threshold signatures) from at least 2/3’s of the system’s validators. Communication is linear in this case, whereby the leader sends blocks to validators, while validators send votes directly to the next leader.

Conversely, if the validator does not receive a block within a predetermined amount of time, it broadcasts a signed timeout message to its peers which includes the most significant quorum certificate the validator observed. If a validator collects timeout messages from honest validators within the network (a minimum of 2/3rds must be honest), it amasses these (via a threshold signature yet again) into a timeout certificate (TC) and sends them directly to the next leader.

3. Finally, each network validator finalizes the block proposed in the initial consensus round (round 1) upon receipt of the quorum certificate (QC) from the following consensus round (round 2) via communication from the leader in the upcoming consensus round (round 3). In particular:

The leader of round 1 (Abby) sends a new block to each validator.
If 2/3rd’s of validators vote YES by sending their votes to the leader of round 2 (George), then the block in round 2 will include a quorum certificate for round 1. Nonetheless, observing the quorum certificate from round 1 during this instance is not sufficient for Beth to know that the block in round 1 has been propagated, since (as an example) the leader of round 2 (George) could have been malicious and only sent the block to Beth. The only thing Beth can do is vote on the block from round 2 by sending her votes to the leader of round 3 (James).
If 2/3rd’s of validators vote YES on the block from round 2, then the leader of round 3 (James) sends a quorum certificate for round 2 and a block proposal for round 3. As soon as Beth receives this block, it is clear that the block from round 1 (Abby’s block) is finalized.
In the event that the leader of round 2 (George) acted maliciously, by sending an invalid block proposal in round 2, or by sending it to less than 2/3rds (a 2/3rds majority of honest validators is required to progress to the next consensus stage) of network validators. Then at least the maximum number of byzantine nodes +1 validators will timeout, therefore triggering the other non-byzantine (non malicious) validators to timeout, leading to at least one of the validators to produce a timeout certificate (TC) for round 2. Next the leader of round 3 (James) will publish the timeout certificate for round 2 in his proposal (this will be required because no quorum certificate will be available for round 2).
This commitment procedure is known as a 2-chain commit rule, because as soon as a validator observes 2 adjacent certified blocks — block 1 and block 2 — they are able to commit block 1 and all of its ancestors.

To generate a BLS signature it is necessary to multiply the message’s hash by the private key. (Image Credit: Boneh–Lynn–Shacham signatures via Golden)

To provide security guarantees and increase scalability, Monad makes use of a combination of Boneh-Lynn-Sachum (BLS) signatures and Elliptic Curve Digital Signature Algorithm (ECDSA) signatures.

While certificates (i.e., quorum certificates and timeout certificates) can be leveraged as a vector of ECDSA signatures via the secp256k1 curve because they are explicit and simple to construct and verify, the size of the certificate is linear in proportion to the number of signers. This obfuscates the limit to scaling because the certificate is included in most consensus messages except vote messages.

To address this issue, Monad makes use of BLS multi-signatures by pairing them with the BLS12-381 curve (a type of BLS signature elliptic curve representation). This allows the signatures to be incrementally aggregated into a single signature. Verifying the single valid aggregated signature proves that the stakes connected to the public keys have correctly signed the message.

Because the BLS signature is measurably slower than the ECDSA signature, MonadBFT harnesses a blended signature scheme whereby the BLS signature is used only within aggregatable message types (generally votes and timeouts), while message integrity and legitimacy is provided by ECDSA signatures.

Deferred Execution

The Monad blockchain is designed as a network that decouples consensus from execution. Deferred execution is a process that makes use of pipelined consensus execution in stages.

Recall that consensus is the process where Monad nodes come to agreement on the official ordering of transactions on the network. On the other hand, execution is the process of actually executing those transactions to update the system’s state.

On Monad specifically, nodes come to agreement on the network’s official ordering of transactions prior to the leader or validating nodes actually executing those transactions on the network.

The end result is that the leader proposes specific transaction ordering without knowing the result of the state root, while the validating nodes vote on block validity without being sure if all the transactions within the block will be executed without reverting back to its initial state. This design is one of the foundational components that makes Monad hyper-scalable.

On Ethereum, execution is a prerequisite to consensus, meaning that when nodes come to consensus on a block they agree on the list of transactions within the block and the merkle root that encapsulates the new version of state after executing that specific list of transactions.

This means that the leader is required to execute the transactions in the proposed block before the proposal is submitted, while the validating nodes are required to execute those transactions before responding with a vote on whether the block will be denied or accepted.

In summary, transaction execution on Ethereum is extremely inefficient because the time budget for execution is particularly limited because both processes must be completed prior to a block being finalized, while also leaving adequate time for several rounds of cross-globe consensus communication to be completed.

Moreover, since execution will block consensus, the gas limit must be quite conservative to guarantee that computation is completed amongst all nodes within the budget in the event of a catastrophic scenario.

Shared Mempool

Monad stores pending transactions within an independent mempool in each validator before they are included in a finalized block. This process works by sharing transactions with other validator mempools by erasure-encoding the transaction and then communicating over a broadcast tree to increase efficiency.

MonadBFT is an effective framework to realize agreement pertaining to an arbitrary payload. Nonetheless, the block propagation bottleneck is still significant; as an example, a block with 10,000 transactions and 500 byte transactions is typically 5MB, meaning that blocks of this size will restrain validators because of high bandwidth. To address this issue, block proposals reference transactions independently through hashes to save significant network bandwidth because hashes are only 32 bytes apiece.

Carriage Cost and Reserve Balance

Deferred execution allows the execution and consensus on the network to occur in parallel, exponentially expanding the time budget for execution. At times throughout this process, consensus nodes don't have an up-to-date view of state and the possibility exists that they could mistakenly include transactions from accounts that have used up all their gas, resulting in a denial-of-service attack vector.

To eliminate this possibility, Monad introduces a cost for a transaction to be sent over the network within a block (i.e., the carriage cost), implementing a reserve balance account for each account that is updated during consensus and charges carriage costs against the reserve balance. On Monad, for each address, nodes maintain two balance types:

the reserve balance is used to pay the carriage cost
the execution balance is used to pay for costs associated with transaction execution

With this model, the carriage cost is charged to the reserve balance at the time the transaction is included within a block (during consensus). Alternatively, the carriage cost is subtracted from the execution balance at execution time (as a double charge) and then repaid to the reserve balance after the block delay period passes (after 10 seconds).

The reserve balance is representative of a budget for “in-flight” orders (i.e., transactions in the process of being finalized) and exists to guarantee that only transactions that have been paid for are included in blocks. The target reserve balance is based on a per-account parameter, with the default typically being a large multiple (200x) of the carriage cost, enabling users to potentially submit a substantial number of inflight orders without encountering issues.

It is also possible to increase the reserve balance via an on-chain transaction. This would be relevant to Market Makers and the like who may be submitting a substantial number of orders per block.

Monad Blockchain Execution

For the Monad protocol to realize hyper-efficient transaction execution, the network utilizes two main components:

Parallel Execution - an execution framework built on parallelization (or parallel processing)
MonadDb - a database that allows blockchain state to be stored and optimized

Parallel Execution

As a key defining feature, Monad leverages parallel execution to process transactions on the network in a concurrent manner to exponentially improve network throughput and scalability. This model is unlike the sequential approach typically used in most traditional blockchain systems.

At a foundational level, Monad employs optimistic execution, meaning the protocol commences transaction execution prior to earlier transactions in the block actually being completed. At times, this can result in incorrect execution.

This can mean that the wrong transaction can be executed prior to the one that was initially sent; therefore, theoretically having the capacity to update account balances incorrectly.

In order to prevent the commitment of incorrect results, optimistic execution solves this issue by tracking the inputs and outputs of each transaction and rescheduling conflicts before committing the results to the block. If the inputs to a transaction differ from the outputs of a proceeding transaction in the block, it's clear that the second transaction used incorrect data during execution and needs to be executed again using the correct data output from the preceding transaction.

While re-execution is sometimes required, reloading of the associated transaction data is not. In practice the vast majority of time spent on execution is spent on database reads to load this transaction data, thus when a transaction is re-executed the overhead of re-execution is minimal adding around 1.5% extra overhead to every transaction needing re-execution. [1]

It is therefore useful to think of optimistic execution as a 2-phase execution process where in the first phase transaction data is loaded into memory (and sometimes correctly executed), and the second phase correct execution is guaranteed. While in the worst case every transaction may be executed twice, this only adds 1.5% of overhead to execution while circumventing the need for complex scheduling and dependency analysis algorithms that other execution methodologies struggle to cope with in a bounded time interval.

Furthermore, Monad’s execution engine is designed to fully utilize system resources while making intelligent decisions on re-executions when possible. While Monad will always prioritize completed operations, in cases where multiple options exist, it will schedule re-executions in their natural block ordering.

E.g., imagine you have two TXs with pending database operations: Tx2, Tx3. There are 3 situations:

Tx2 returns, a thread becomes available, Tx3 returns → Tx2 executes first.
Tx3 returns, a thread becomes available, Tx2 returns → Tx3 executes first. After Tx2 executes, Tx3 may need to be rescheduled.
Tx2 and Tx3 return before a thread becomes available, then one becomes available → In this case we execute them in their block order, so Tx2 before Tx3 even if Tx3 technically returned first.

[1] https://x.com/keoneHD/status/1744091485471948869?s=20

MonadDb

MonadDb is a custom database for storing blockchain state that dramatically helps increase the scalability of the chain’s transaction execution system.

The majority of Ethereum clients (two distinct pieces of software that form a node) leverage key-value databases in the form of either B-Tree or LSM-Tree data structures. That said, Ethereum makes use of the Merkle Patricia Trie (MPT) data structure for storing state. This combination results in an inferior solution whereby one data structure is rooted into another data structure of a separate type. Contrastingly, Monad harnesses a Patricia Trie data structure natively, both on-disk and in-memory.

Monad executes multiple transactions in a parallelized manner. Therefore, when one transaction is required to read state from disk, another transaction should not have to wait for that process to be completed. Instead, the transaction should initiate the read and begin working on another transaction at the same time. To solve this problem, the database should utilize an asynchronous input/output (async i/o) model.

The Ethereum client key-value databases we touched on above lack proper async i/o support. Oppositely, MonadDb leverages the latest kernel support for async i/o, avoiding the challenge of relying on the creation of a large number of kernel threads to manage pending i/o requests to perform the required computation asynchronously.