Written by: Decentralised.Co
Compiled by: TechFlow
Transaction scalability has always been a hot topic. Over the past few weeks, we have been exploring how Monads can help scale TPS.
Here is a detailed explanation of how Monads work, written by Saurabh Deshpande .
TPS is a metric we care a lot about. We want our chains to support higher TPS because they can support more users and applications. The chart below shows the TPS numbers for Ethereum and L2. No chain has ever broken the 100 TPS mark. Note that TPS is a general term used to measure scale. TPS is inaccurate because not all transactions are the same, they vary in complexity. But for simplicity, we use TPS as a measure of scale.
If we want to increase TPS, what should we do?
The first approach is to build an entirely new system, like Solana has done. It sacrifices EVM compatibility for speed. It uses multi-threaded execution instead of single-threaded execution (think multi-core CPU vs. single-core CPU), parallelizes transactions, and uses a different consensus mechanism.
The second approach is to use off-chain execution and use a centralized collator to scale Ethereum.
A third approach is to break down the EVM into separate components and optimize them for scalability.
Monad, a new EVM-compatible L1 that recently raised $225 million, is building the EVM from scratch rather than using it directly. It has chosen this third approach to increase scalability.
We discussed several significant changes brought about by Monads.
Parallel execution
The Ethereum Virtual Machine (EVM) executes transactions sequentially. Before one transaction is executed, the next transaction must wait. Think of it this way. Imagine a platform in a motorcycle assembly shop. Multiple trucks deliver motorcycle parts (each truck has all the parts needed to assemble 50 motorcycles). The assembly shop performs four different functions: unloading, sorting, assembly, and loading.
In the current EVM setup, there is only one platform, and the same location is used for loading and unloading. Therefore, motorcycle parts are unloaded, sorted, assembled, and loaded onto the same truck while the truck is parked. While the sorting team is working, the other teams are waiting. Therefore, if their work is viewed as different slots, each team only works in one of the four slots once. This leads to significant inefficiencies, highlighting the need for a more streamlined approach.
Now, imagine a dock with four different loading and unloading areas. Even if the unloading team can only work with one truck at a time, they don't need to wait for the next three slots. They can just move on to the next truck.
The same is true for the sorting, assembly and loading teams. Once unloading is complete, the truck moves to the loading area to wait for the loading team to load the assembled motorcycles. Therefore, a warehouse with only one platform and loading/unloading area performs all operations sequentially, while a warehouse with 4 platforms and different loading/unloading areas parallelizes them.
Think of Monad as the infrastructure equivalent of a warehouse with multiple truck platforms. But it's not that simple. The complexity increases when the trucks have dependencies. For example, what happens if a truck doesn't have all the parts to assemble 50 motorcycles? Transactions may not always be independent. So when Monad executes them in parallel, it has to handle transactions that depend on each other.
How does it handle this? It implements a method called optimistic parallel execution. The protocol can only execute independent transactions in parallel. For example, consider 4 transactions where Joel has a balance of 1 ETH:
Joel sends 0.2 ether to Saurabh
Sid mints an NFT
Joel sends 0.1 ether to Sid
Shlok Buy PEPE
All of these transactions are executed in parallel, with pending results submitted one by one. If the output of a pending result conflicts with the original input of any transaction, the transaction is re-executed. Transactions 2 and 4 have no pending results that conflict with the input of other transactions because they are independent of each other. But transactions 1 and 4 are not independent.
Note that since all 4 transactions start from the same state, the focus is on Joel's balance of 1 ETH. After Joel sends 0.2 ETH, his balance is 0.8 ETH. After Joel sends 0.1 ETH to Sid, his balance is 0.9 ETH. The results are submitted one by one, ensuring that the output does not conflict with any input. After submitting the pending result of 1, Joel's new balance is 0.8 ETH.
This output conflicts with the input of transaction 3. So now transaction 3 is re-executed with an input of 0.8 ETH. After executing transaction 3, Joel's balance is 0.7 ETH.
MonadDb
At this point, an obvious question is how do we know we don't have to re-execute most of the transactions. The answer lies in the fact that re-execution is not the bottleneck. The bottleneck is accessing Ethereum's memory. It turns out that the way Ethereum stores state in the database makes it difficult (time consuming and therefore expensive) to access state. This is where another improvement from Monads comes in: MonadDb. The way Monads build databases reduces the overhead associated with read operations.
When a transaction has to be re-executed, all inputs are already in cache memory, which is much easier to access than the entire state.
Solana has 50k TPS on its testnet, but only has about 1k TPS on mainnet right now. Monad claims to have achieved 10k real TPS on its internal testnet. While this is not always representative of real-world performance, we can’t wait to see how Monad performs in real-world applications.
