Monad

Solid stats: 10,000 TPS. 1 second block time. 1 second finality.

Building is a piece of cake. Full EVM Bytecode Compatibility: Applications built for Ethereum can be deployed on Monad with no code changes. Full Ethereum RPC Compatibility: User-facing infrastructure (e.g. MetaMask) can be used seamlessly.

The core to high performance. 2 main fundamental architectures employed by Monad to allow for high performance: (1) Parallel Execution (2) Superscalar Pipelining

The blockchain landscape has constantly been evolving, and we have seen numerous contestants attempting to improve Ethereum’s architecture. Teams provide more sophisticated technology to attract more builders to create better protocols, aiming to gain more users. Despite all the competition, Ethereum has remained the dominant blockchain, with the ecosystem's most total value locked (TVL).

Due to the scalability issues faced by Ethereum (i.e. network congestion, high gas fees etc.), many teams have come forth to build their solutions, contributing to the competitive blockchain landscape. Some of the more prominent contestants to Ethereum include:

• Ethereum virtual machine (EVM) layer 1 (L1s), including Tron, BSC, Avalanche, as well as non-EVM L1s including Solana, Aptos, Sui and many more
• Layer 2s (L2s), with Arbitrum and Optimism currently leading the race, alongside more optimistic (i.e. Base, Mantle etc.) and zero-knowledge (ZK) L2s (i.e. zkSync, Starknet etc.) being built

Blockchains strive for EVM compatibility, which allows applications built on Ethereum to port over while maintaining a familiar user experience easily. This is important for teams as it is a gateway to access the mammoth TVL available in Ethereum.

The key to Monad’s high performance lies in its parallel execution, a complementary concept of superscalar pipelining. Pipelining breaks down an instruction set into successive steps, which can then be executed concurrently (in parallel). Let’s understand pipelining through the example below, where the task of laundry has been split into 4 successive steps: (1) Wash (2) Dry (3) Fold (4) Store. As a result, the steps can now be carried out in parallel. When the first basket of clothes are placed into the dryer after washing, the washer becomes available for basket 2.

Now that we have understood parallel execution and superscalar pipelining, we can move on to learn more about Monad’s consensus and execution mechanisms.

There are 4 key areas to Monad’s consensus, here’s a brief introduction before diving deep into each:

• (a) MonadBFT: Consensus mechanism
• (b) Shared Mempool: Block propagation through hashes
• (c) Deferred Execution: Decoupling execution and consensus
• (d) Carriage Cost and Reserve Balance: Prevent spam from deferred execution

3.1 MonadBFT

Definitions

• Byzantine Nodes: Malicious nodes
• Quorum Certificate (QC): 2f + 1 validators (majority) votes for ‘yes’
• Timeout Certificate (TC): 2f + 1 validators (majority) signed timeout messages

Default Assumptions

• Total Number of Nodes: 3f + 1
• Maximum Number of Byzantine Nodes: f
• Non-Byzantine Nodes Required: 2f + 1

Flow

Let’s understand the MonadBFT mechanism with a specific example.

(1) round k

• Leader Alice will send out a new block (k) and a QC from the previous round k - 1
• Validator nodes will review the block (k) for adherence to protocol rules → Vote
• Signed votes will be sent to the leader in the next round k + 1

(2) round k + 1

• Leader Bob will propose block (k + 1) and the QC from round k

• Validator nodes will review the block (k + 1) for adherence to protocol rules

• Validator nodes see the QC for round k in block (k + 1)

• But Alice’s block (k) might not be finalized yet

• This is because the leader Bob might be malicious and have sent block (k + 1) to less than 2f + 1 validators

• Validator votes → Signed votes will be sent to the leader in the next round k + 2

(3) round k + 2

• Leader Charlie will propose block (k + 2) and the QC from round k + 1
• At this point, upon QC from round k + 1, validators can affirm that block (k) has been finalized

In summary, a block takes 2 rounds to be finalized. The first is a consensus on the transactions within the block. The second is a validation of the consensus. The graphic below depicts the flow:

3.2 Shared Mempool

As of this stage, Ethereum's block propagation is still a significant bottleneck. When block leaders propose blocks of large sizes, propagating these blocks to the validator network for consensus requires extremely high bandwidth from validator nodes, resulting in slower block propagation.

With MonadBFT, instead of propagating the entire block for consensus from the validator network, it propagates blocks using its hash. If only a hash is available, how will nodes know the block details which they are voting on for consensus? Let’s take a more detailed look.

User transactions that are submitted (but not yet executed) go to the RPC node. The pending transactions are then forwarded to validators’ local mempool. Individual validators might each have a certain set of transactions that are included in the block. Validators need to know all transactions included in the block to know the exact block they are voting on. This can be achieved through:

1. Erasure-coding Transactions: Individual validators can share their respective pieces of transactions with each other
2. Broadcast Tree: This is an efficient communication method for validators to share the various pieces of transactions

With the above 2 mechanisms, validators participating in the consensus can reconstruct the entire block referred to by the hash given by the block leader.

Let’s take a look at the potential improvement that can result from block propagation using hashes:

• Traditional Block Propagation: If a block has 10,000 transactions, with each transaction having a size of 500 bytes, the total block size will be 5MB. This size can be even bigger should the transactions be more complex, and thus having a bigger size
• Monad’s Block Propagation: Hashes are only 32 bytes in size. Instead of having to propagate all 5MB worth of data, straining the various stakeholders (validator notes, block leader, network), block propagation becomes orders of magnitude lighter and more efficient

P.S.: Erasure-coding has not been implemented yet as of this stage of development.

🍪’s thoughts: Despite all the benefits mentioned, particularly with regards to efficiency, it remains to be seen whether the architecture might result in possible attack vectors (perhaps through broadcast tree) or inaccuracies in consensus.

3.3 Deferred Execution

Before we begin looking into deferred execution, here are some definitions:

• Consensus: Nodes agree on official ordering of transactions

• Execution: Transaction executed and state is updated

• Gas Usage: Different types of transactions (differing levels of complexity) use different amounts of gas

• Gas Limit: Total amount of gas that can be consumed for each block

• Block Time: Will be set based on the gas limit

• Time Budget: Gas limit allocation

Currently on Ethereum, execution has to be completed before consensus.

The gas limit on Ethereum has to account for:

• (1) Execution by block proposer
• (2) Execution by validator nodes
• (3) Consensus of validator nodes

As a result, the time budget for execution becomes extremely limited, given that there needs to be sufficient time for both executions and consensus. This puts a cap on the number of transactions that can be executed in one block, limiting the scalability of Ethereum when there is high network volume / large amount of complex transactions.

Gas Limit Distribution

With Monad, execution occurs after consensus, as explained in the above section 3.1 MonadBFT. This means that during consensus, nodes will agree on the official ordering of transactions. Still, neither the leader nor validator nodes will be required to execute the transactions at this point. This also goes to say that when the leader proposes an ordering and validator nodes vote on the ordering, both stakeholders do not yet know the result of the transactions (whether they can be executed (e.g. sufficient gas) or will be reverted).

The key concept in such an architecture is: The true state is determined upon official ordering of transactions. Monad leverages on this, which is why in MonadBFT, nodes are able to come to consensus on ordering of transactions in round k, and concurrently execute transactions from round k - 1.

In this scenario, the entire gas limit of a block will be dedicated to execution, allowing Monad to increase the number of transactions that can be executed in each block, achieving its high throughput.

However, there is a potential issue associated with deferred execution.

As mentioned, execution is carried out after consensus. This results in a situation where nodes participating in consensus do not have an up-to-date view of the state (the nodes don’t know whether the transactions can be executed). In such a case, certain users may be spamming the network, attempting to get their transactions to be included in the consensus, causing other transactions to be pushed out. To have a better understanding, you can refer to the bakery analogy below:

Deferred Execution: Potential Problems

3.4 Carriage Cost and Reserve Balance

Monad has implemented carriage cost and reserve balance to tackle the potential of spam and denial-of-service attacks.

1. Carriage Cost: For a transaction to be included into a mempool and subsequently included into a block for consensus, users will be charged a carriage cost (can be thought of as a deposit). This serves as a cost to deter users from spamming the network.

   

2. Reserve Balance: Carriage costs are deducted from the reserve balance of each account. Upon successful execution of transactions, carriage costs will be returned to users (with a delay). It is targeted that the reserve balance will be ~200x that of the carriage cost. This is to allow honest users to submit multiple transactions concurrently / subsequently. This is necessary to maintain composability of transactions for DeFi applications, where transactions need to be executed one after another.

🍪’s thoughts: Just a random thought, but, what are the chances of carriage cost being outsourced. It becomes a sort of ‘service’ where instead of each account having a reserve balance, there is a smart contract that holds balance for all other accounts. Something of a similar mental model could be paymasters in ERC-4337. The main idea here is to maintain capital efficiency by not requiring users to have idle assets sitting in the reserve balance.

One key architectural difference that allows Monad to achieve high performance is its parallel execution. In this section, we will briefly examine the mechanism and necessary component to achieve this: MonadDb.

4.1 Parallel Execution

With parallel execution, multiple cores and threads are utilized to execute transactions in parallel, while still committing the results in the original order. This means that the end result obtained from parallel execution (e.g. account balances) will be the same as the sequential execution.

An analogy we can think of would be the drive-through to Shake Shack

• Serial Execution: There’s only 1 lane available for drive-through. Drivers 2 and 3 will have to wait for driver 1 to finish ordering and collect his order before they are able to start their order.
• Parallel Execution: With parallel execution, there are now more than 1 lane available in the drive-through. All 3 drivers can order concurrently, and will still be able to get their respective order. This is the exact same outcome as serial execution, except that the speed at which customers receive their burgers will be increased.

Specifically, optimistic execution is utilized in the context of Monad. This means that the network can start executing transactions before earlier transactions in the block have been completed. The results from optimistic execution will be akin to those from serial execution of transactions.

Nonetheless, with optimistic execution, there may sometimes be incorrect execution. This is especially the case when the transactions executed in parallel include duplicate accounts. The graphic below depicts how an incorrect execution might happen.

Optimistic Execution: The Problem of Incorrect Execution

Returning to the Shake Shack drive-through analogy above, imagine if all 3 cars waiting in line originally wanted a cheeseburger. However, there is only 1 cheeseburger left. The following graphic depicts what would have happened if serial execution had been utilized.

Cars 2 and 3 won’t be able to make an order for cheeseburgers as the system has already been updated after car 1 makes and receives their order. Should it have been a parallel execution, with all 3 cars ordering concurrently, the system will register all orders. However, due to the lack of cheeseburgers, the 2 other customers who didn’t manage to receive their order will have to re-order.

Thus, Monad needs to be able to capture such instances of incorrect execution and re-execute it with correct data. This is done by checking for the condition shown in the graphic below:

4.2 MonadDb

One critical architecture that allows optimistic execution is MonadDb, Monad’s custom database for storing blockchain state. Asynchronous I/O, a form of input/output processing that allows for concurrent execution while communication is in progress, makes optimistic execution possible. MonadDb fully utilizes the latest kernel support to achieve asynchronous I/O.

Assuming there are 2 transactions, A and B:

• Execution of transaction A begins when the input is entered

• Execution of transaction B can begin even without output from A

• This is feasible due to asynchronous I/O

5.1 Performance

The table below compares the TPS, block time, and block finality of Ethereum and Monad. As shown, Monad features a much higher TPS alongside with 1 second block time and finality.

With these metrics, Monad tackles the scalability issues plaguing Ethereum. This allows more users to be accommodated on the Monad network and maintains low fees as far as possible.

5.2 Portability

Monad features high portability due to the following architecture:

• Full EVM Bytecode Compatibility
• Full Ethereum RPC Compatibility

With bytecode equivalent to Ethereum (all Ethereum opcodes is supported), applications built on Ethereum can be ported to Monad without requiring any code changes. Developers will be able to port their existing work, develop with ease given the familiarity and users will be able to access their desired applications (presuming that the protocol ports over). In addition, infrastructure e.g. MetaMask, Etherscan and others can be used seamlessly on Monad.

Monad represents a significant leap forward in blockchain technology. Combining high performance and EVM compatibility opens doors for developers and users alike, ensuring a seamless experience. With parallel execution, the potential of blockchain scalability paints an exciting landscape of protocols that can be built.

That said, there are still aspects that will likely undergo more iterations to become even more efficient. One example would be the carriage cost and reserve balance, where it takes time to study transaction data before being able to analyze what might be a suitable amount to charge for carriage cost and how much the reserve balance should contain to sufficiently counter against denial of service attacks.