Monad — Maximalist Blockchain

The biggest problem of the blockchain universe is finding a scalable galaxy.

The Ethereum Galaxy divides the workload into its planets. Ethereum L1, the sun of the galaxy, communicates with all of its planets (L2 networks), and there is constantly heavy space shuttle traffic in the galaxy.
Since there are not enough shuttles (block size), those who have money settle in front of the shuttles and take care of their business. The pressure on the Sun is reduced with the jobs divided into planets. With solutions to relieve shuttle traffic (Protodanksharding, Sharding and other EIPs), people will have a peaceful life.

There is a planet of gigantic size in the Solana Galaxy. In the past, the ozone layer of this planet, which could not support its population, was often pierced and all the work of the people of this galaxy stopped (the network stopped). With the industrial revolution on the planet (QUIC, Stake-Weight QoS, Localised Fee Markets) people prospered. But the galaxy still has a long way to go.

Both of these galaxies have a ledger. The Ethereum Galaxy is very crowded and uses a registry called EVM. The EVM used in the Ethereum galaxy keeps records (transactions) one by one in order due to its structure. The Solana Galaxy, on the other hand, has an e-BFP registry called SVM. SVM processes and writes non-overlapping records (transactions) in parallel.

Most of the universe’s population is much more skilled at using the EVM registry.

In the midst of all this chaos, a new galaxy is born, called MONAD.

Monad is a galaxy that uses the EVM registry (virtual machine). It will consist of a single, gigantic planet like Solana. It is claimed that 10,000 records per second (TPS) can be kept on Monad. Monad is a galaxy that takes EVM and improves it, enabling it to record in parallel like SVM.

Now let’s get out of the Galaxy-Universe analogy and start using engineering terms. The real adventure begins now.

Each blockchain enters our lives with an innovation that defines itself. These innovations are Subnets for Avalanche, Proof of History for Solana, Sharding for Near…

For Monad, it’s Deferred Execution. The separation of Execution from Consensus.

1) Deferred Execution

• Execution is the processing of incoming transactions to the network and outputting a hash. It refers to the change of global state.
• Consensus is the approval of these state changes by the nodes.

Firstly, let’s look at how a transaction and block are confirmed on Ethereum.

1. Users send a transaction to Ethereum nodes through clients (wallets/RPCs).
2. The nodes receive these transactions and send them to the node that is the Leader for that block. The leader sorts the incoming transactions, executes them one by one and creates a Merkle Tree. Finally, it calculates the hash value of the block.
3. Then it distributes this block among validator nodes. Validator nodes first execute the transactions one by one and create a Merkle Tree.
4. Then they compare the root of the tree sent by the leader with the root they created.

If these roots overlap and the block hash value is correct, the voting phase starts.

In this case, everyone executes. The amount of communication in the network is very high. This causes a delay. Execution slows down consensus.

Monad is redistributing the cards. It adds a new philosophy and engineering.

It is wrong to spread Execution and Consensus in the same time interval, Monad defends this.

1. The Leader Node on Monad first sorts the transactions.
2. Then it calculates the hash values in the order of the transactions and sends them to other nodes.
3. Other nodes calculate the hashes of the transactions they keep in their mempools and check the order from the leader.

If there is no transaction that is not in their mempool, they proceed to the voting phase.

Execution is not done. Only the order and existence of transactions were checked. Because if the order of transactions is clear, there is no need to rush for execution. The state change will be accurate and deterministic.

Each node will start executing the operations in block “N” on its own computer in block “N+1”.

But we don’t have a merkle root? How do we know if the transactions are invalid?

This does not prevent what we call State Machine Replication. We set a threshold. The merkle root of block “N” will take place after “D” blocks (the number “D” is set to 10 for the beginning), i.e. in block “N+D” and the state change will be guaranteed.

If the nodes make a wrong or incorrect execution, they will start execution again from “D” block back.

I think you understand the difference between Ethereum and Monad well.

Ethereum keeps and provides the state machine replication event very strictly.

Monad, on the other hand, takes a flexible and optimistic attitude to increase the number of transaction inputs and the speed of the network.

2) MonadBFT

2.1) Pipelining

Pipelining refers to dividing a process into multiple stages to make it more efficient, and having each stage work on different pieces of work simultaneously.

By dividing a processor’s instruction execution process into several stages, each stage can start working on a new instruction without waiting for the previous one to complete.

I gave a good kitchen example for pipelining in my Solana article. Let’s go with the laundry example here.

Ethereum is the first part of the visual, Monad is the second part.

2.2) Consensus

MonadBFT is a HotStuff Consensus with pipelining. HotStuff Consensus briefly takes place in 3 stages:

1. The Leader Node presents a proposal to the validators. Validator nodes send a prepare message to the leader node. It is confirmed that all nodes are active and listening to the leader.
2. Validator nodes cast their pre-commit votes on the Leader’s proposal. If a certain majority is reached, the final round starts.
3. Validator nodes cast their votes for final approval (commit) of the Leader’s proposal. If the required majority is reached, the voting ends and the proposal is accepted as correct.

MonadBFT works differently from this. In two phases, since we do not execute, it takes place with optimistic answers. It works hypothetically.

If it works correctly, linear communication is applied, if something goes wrong, quadratic communication is applied. I will explain.

MonadBFT is a BFT Consensus as the name suggests. Assume that the nodes in the network have equal stake distributions.

• If “66+1%” of the nodes give valid approval to the incoming block, the block is approved. This number must be exceeded to take over the network.
• If “33+1%” of the nodes in the network cannot capture the network, the consensus and the network stops (we have seen this a lot in Solana :) ).

Thanks to pipelining in consensus, there are two confirmation/rejection messages called Quorum Certificate (QC) or Timeout Certificate (TC).

If QC is sent, the block is approved, if TC is sent, there is a problem.

• The leader who sorts block “N” distributes its block to the validator nodes together with the certificate of block “N-1” (QC valid or TC invalid, we will discuss this in detail).
• The validators check the received transactions in turn and if the transactions are correct, they send their valid votes to the leader of the “N+1” block. The leader of the “N+1” block collects the votes from “66+1%” of the validators using “threshold signatures” and creates a QC. The communication is linear. The leader sends data directly to the validators and the validators send data directly to the next leader.
• Otherwise, i.e. if the validators do not receive a block from the leader, they start talking among themselves. They send each other a “timeout” message and the last QC they have. If any validator receives “66+1%” number of “timeout” messages, it generates a TC and sends it to the leader of the next block.
• For the result of block “N” to be final, the QC of block “N+1” must be received with block “N+2”. Otherwise, validators cannot be sure that the QC for block “N” is correct.

2.3) BLS Multi-Signatures

Certificates (QCs and TCs) can be implemented in a simple way as a vector of ECDSA signatures on the secp256k1 curve. These certificates are open and easy to create and verify. However, the size of the certificate is directly proportional to the number of signatures. Since the certificate is included in almost every consensus message except the vote message, this is a factor limiting scaling.

To solve the scaling problem, a matching-based BLS signature on the BLS12–381 curve can be used. Signatures can be merged into a single signature in such a way that they are appended to each other. Verification of the single valid merged signature validates the signatures of all voting validators.

The BLS signature is much slower than the ECDSA signature. For performance reasons BLS Multi-Signatures are only used for combinable message types (for block votes and certificates QC and TC).

Monad will work with Proof-of-Stake. Delegation system is available. It will offer a very efficient use with Single Slot Finality.

2.4) Shared Mempool

Monad will have a Mempool like Ethereum. Transactions will be stored here with their hash values.

The leader node will send hash values to validator nodes to verify the order of transactions, not the transactions themselves. Thus, the amount of data that validators need to download during communication will be very small, reducing the bandwidth requirement.

3) Parallel Execution

Monad performs parallel execution. Transactions coming to the network can pass through the network at the same time if they do not change the state of the same account.

Let’s consider 2 transactions in the same block;

• One transaction reads the state of account A and transfers money to account A.
• The other transaction reads the state of account A and transfers money from account A.

In this case, the inputs and outputs of the transactions are compared. The transactions are executed optimistically and the result of the first transaction is compared with the initial state of the second transaction.

If the compared states are different from each other (if the result and initial values are the same, the transaction order is correct), the execution is incorrect. Operations are executed until the correct order is found. The processes are considered to be “merge”. This is Optimistic Execution.

Transactions are executed if there is enough free processing power and space in the validators’ processors. If this space is never free, a long chain of transactions may accumulate. For this reason, Monad scheduling for failed transactions. With the Static Code Analyzer in the Node Clients, an estimated execution time interval is determined for failed transactions.

4) MonadDB

We have sequenced our operations, reached consensus and executed. What about the database? Where do we store this data?

MonadDB is designed for the storage of network data. MonadDB implements the Patricia Trie data structure locally in both permanent (disc) and temporary storage (RAM, memory).

Monad executes multiple processes in parallel. When a process needs to read state written to disc, instead of waiting for that process to complete, it must initiate the read and start working on another process in the meantime.

Therefore, asynchronous i/o (async i/o) is required for the database.

In short, “async i/o” means that the processor can execute many tasks in parallel. This is where the pipelining concept comes from. Instead of executing an input/output operation and waiting for its result, the processor can simultaneously execute and output other operations that do not conflict with this operation.

As you can see in the image, Disk and Network are very slow compared to Memory and CPU. However, SSD drives have the ability to perform operations simultaneously/parallel. Thus, the CPU can start, execute and output several processes at the same time.

5) Carriage Cost and Reserve Balance

Monad separates execution and consensus and performs them in parallel, allocating additional time for execution. So far we agree.

However, the fact that validator nodes do not have the current state can cause a problem where transactions that have spent the entire gas token of their account are incorrectly included, which can lead to a Denial-of-Service attack. To avoid such problems, Monad applies a “Carriage Cost” for the transaction carried in a block over the network and maintains a “Reserve Balance” for each account, which is updated at consensus time.

The carriage cost is a minimal charge that reflects the cost of using network resources and is intended to prevent spam.

For each address, nodes maintain two types of balances:

• Reserve Balance, which is used to pay the Carriage Cost and,
• A gas amount used to pay for Execution.

Carriage Cost is deducted from Reserve Balanced when Consensus is realized. When Execution takes place, the gas cost is paid (double charging).

After a delay of D blocks (10 seconds), the Carriage Cost is paid back to the Reserve Balance.

The Reserve Balance is a vault that exists to ensure that paid transactions are included in blocks. If users plan to send a large number of transactions through the same EOA, they can change the target Reserve Balance value by interacting with a smart contract.

Changes to the Reserve Balance are treated as execution, i.e. changes to the Reserve Balance are only seen after the delay time (D Block) has elapsed. This system allows users to seamlessly submit a large number of transactions with a default target Reserve Balance set to a large multiple (200 times) of the Carriage Cost.

We have come to the end of a preview of an entire galaxy being built. We have theoretically seen who pays what, how decisions are made, and how fast things work.

The only thing we can do from now on is to follow the developments and wait for the network to become active.

Thank you for coming this far. See you in the next articles.

Twitter: @blockofchain

References: https://docs.monad.xyz/