On April 9th of this year, the Layer1 blockchain Monad Labs announced the completion of a $225 million financing round. This round was led by Paradigm, with participation from other well-known investment institutions, including Electric Capital, SevenX Ventures, IOSG Ventures, and Greenoaks, etc. Along with the $19 million seed round announced in February 2023, the project has raised a total of $244 million, with a valuation of $3 billion.
Putting aside the founders’ backgrounds (two of the three founders come from the Jump Trading team), what makes this project stand out?
What Problem Does Monad Solve?
Monad is an Ethereum EVM-compatible L1, mainly competing with Solana and Sui, materially advances the efficient frontier in the tradeoff between decentralization and scalability. In the test environment this March, Monad achieved a TPS (transactions per second) of over 10,000, significantly higher than existing blockchain projects, especially EVM compatible chains.
Reference: https://www.coingecko.com/research/publications/fastest-blockchains
What is the Technical Principle of Monad?
In general, Monad enhances TPS through executing transactions in parallel. We know， the other Ethereum Virtual Machine (EVM) projects executes transactions linearly, meaning transaction 2 must wait for transaction 1 to complete before it can proceed. However, under Monad’s transaction mechanism, transactions 1 and 2 can execute in parallel, thereby reducing waiting time and increasing transaction speed. However, if so, the first problem Monad needs to solve is:
How to output correct transaction results when there are interdependent transactions between transaction 1 and transaction 2?
Optimistic Concurrency Control
Monad uses optimistic execution. This means that Monad will start executing transactions before earlier transactions in the block have completed. Sometimes this results in incorrect execution, and in the worst case, there may be long “chains” of transactions which depend on each other in the block, which will result in a significant number of failures.
Consider two transactions (in this order in the block):
- Transaction 1 reads and updates the balance of account A (for example, it receives a transfer from account B).
- Transaction 2 also reads and updates the balance of account A (for example, it makes a transfer to account C).
If these transactions are run in parallel and transaction 2 starts running before transaction 1 has completed, then the balance it reads for account A may be different than if they were run sequentially. This could result in incorrect execution.
The way optimistic execution solves this is by tracking the inputs used while executing transaction 2 and comparing them to the outputs of transaction 1. If they differ, it will be detected that transaction 2 used incorrect data while executing and it needs to be executed again with the correct data.
While Monad executes transactions in parallel, the updated state for each transaction is “merged” sequentially in order to check the condition mentioned above.
Besides，Monad has a static code analyzer that tries to make dependency predictions before scheduling transaction executions, so Monad can avoid wasted incorrect executions and chain resources. In a good case Monad can predict many dependencies ahead of time; in the worst case Monad falls back to the naïve implementation. And for other opportunities to avoid re-executing transaction, Monad still explores it.
Next challenge, how does monad address the asynchronous i/o issues required for parallel execution and interaction with Ethereum database?
Monad Database
MonadDb implements a Patricia Trie data structure natively, which is used by Ethereum, in both disk and memory to ensure data consistency. At the same time, MonadDb fully utilizes the latest kernel support for async i/o (on Linux this is io_uring). This avoids needing to spawn a large number of kernel threads to handle pending i/o requests in an attempt to perform work asynchronously. Simply put, Monad builds a database that caches all inputs in memory while processing asynchronous requests, thereby improving access speed and reducing the number of state accesses and cost when interacting with Ethereum database.
Back to the execution speed, how does Monad improve consensus efficiency to enhance transaction speed?
MonadBFT
MonadBFT is a high-performance consensus mechanism for achieving agreement about the transaction ordering under partially synchronous conditions in the presence of Byzantine actors. It is a derivative of HotStuff with the improvement proposed in Jolteon/DiemBFT/Fast-HotStuff which is the reduction from three rounds to two rounds by utilizing quadratic communication complexity in the event of leader timeout.
Monad also improves performance by decoupling execution and consensus and by deferring execution. The core idea is that if execution conditions are relaxed and allow execution to complete before reaching consensus, execution and consensus can run in parallel, thus providing additional time for both.
Summary
Among projects supporting EVM, Monad has an outstanding advantage in TPS and has also made innovations in asynchronous transaction processing. However, the parallel mentioned by Monad differs from that of Polkadot or Paralism; Monad’s parallel refers to parallel transactions, but the chain structure is still based on a serial chain. This inevitably limits the TPS due to the constraints of the serial chain’s capacity and performance. Ultimately, we need to solve the issue of asynchronicity of smart contracts in parallel, and we are pleased to see more and more attempts for it.
And another thing we may forget, Solana achieved 50k TPS on its testnet, but the mainnet TPS currently hovers around 1k. So, although Monad has achieved 10K+ TPS on its internal testnet, how it performs on the mainnet remains to be seen.
Reference: https://docs.monad.xyz/