Interpretation of parallel EVM L1 public chain Monad: What optimizations enable TPS to reach 10,000

Author: Rachit Srivastava, Avail builder; Translation: Golden Finance xiaozou

Monad is an EVM-compatible L1 chain, but with some major rethinking around the core pillars of Ethereum. Therefore, Monad is capable of processing up to 10,000 transactions per second. Recently Monad released their devnet.

It applies the following two concepts: Pipelining and asynchronous I/O. Pipelining is a technique for achieving parallelism by dividing a task into a series of smaller tasks that can be processed in parallel. Asynchronous I/O is a form of input/output processing that allows the CPU to perform concurrent execution while communication is in progress.

So what is different about MonadBFT? MonadBFT is a pipelined two-stage BFT algorithm with an optimistic response form, using linear communication overhead in the general case and quadratic communication overhead in the timeout case.

Below we assume that all nodes have the same interests.

--MonadBFT requires 2/3 of the nodes to reach consensus.

--Leader sends a new block along with "QC" or "TC" (Threshold signature is a cryptographic technique that distributes the ability to generate digital signatures to multiple parties. No one party can represent For the entire group to sign, a subset ("threshold") of parties must collaborate to generate the signature.)

--The validator verifies the block and sends a Yes or No response to the leader. The Leader derives the QC (Quorum Certificate) by aggregating Yes and No votes (via threshold signature).

--If verification fails, the verifier will broadcast a signed timeout message to all nodes. This message includes the highest QC observed by the validator. If these timeout requests accumulated by any validator exceed 2/3 of the number of validators, a TC (Timeout Certificate) will be generated and sent to the next leader.

--Each validator can finalize the block proposed in the k-th round after receiving the k+1 round of QC.

--If it is assumed that the leader acts maliciously in round k+1, in round k+2, at least one validator will generate TC for round k+1, and in round k+2 The leader will check and generate TC for this round.

Delayed execution

In Ethereum, execution is a prerequisite for consensus, so when nodes agree on a block, they agree on the list of transactions in the block Consensus, that is, consensus on the Merkle root that summarizes all states after executing this list of transactions. Therefore, the leader must execute all transactions in the proposed block before sharing the proposal, and validating nodes must execute these transactions before voting to respond.

As can be seen from the above, after the transaction sequence is formally determined, the true status is completely determined. Revealing the true state requires execution, but the true state is already determined. This is the basis of Monad optimization. Monad takes advantage of this insight and eliminates the requirement for node execution before consensus is reached. The node agreement only concerns formal transaction ordering. Each node independently executes the transactions in block N and begins to reach consensus on block N+1.

Ethereum's approach uses consensus to implement state machine replication in a very strict way: after the nodes reach consensus, we know that an absolute majority of nodes agree on the formal ordering and the state produced by that ordering. Monads relaxed this strictness somewhat.

--The finality of Monad is a single slot (1 second)

--The finality of the execution result of the transaction (success or failure? What is the balance afterwards?) is usually The delay will be less than 1 second on the full node.

--Anyone who wants to securely query transaction results without running a full node can run a light client to query full node balances using Merkle proofs. In this case, the query will be delayed by the latency of the Merkle root.

Carrying Cost

There is a fee for conducting network transactions in blocks on the network. This fee is separate from the execution costs. The reserve balance is used to cover carrying costs. The execution balance is used to pay for trade executions.

Parallel execution

Monad uses optimistic execution. This means that the Monad will start executing transactions before an earlier batch of transactions in the block is completed. Sometimes (but not always) this results in execution errors.

If all transactions depend on the previous transaction, optimistic execution will solve this problem by tracking the input data used when executing transaction 2 and comparing it with the output data of transaction 1.

If the two data are inconsistent and we detect that transaction 2 used wrong data when executing, we need to execute it again using the correct data. When a Monad executes transactions in parallel, the status updates for each transaction are "merged" sequentially.

MonadDb

MonadDb is a custom database used to store blockchain state. Most Ethereum clients use key-value databases, which are deployed as B-Tree (such as LMDB) or LSM-Tree (such as LevelDB and RocksDB) data structures.

MonadDb deploys Patricia Trie data structures on disk and in memory. Monad executes multiple transactions in parallel. When a transaction needs to read state from disk, instead of waiting for the operation to complete, it should initiate a read operation and start processing another transaction in the meantime.