Monad Getting Started Guide: Quickly Understand Parallel EVM and Performance Improvement

Transaction scalability has always been a hot topic. Over the past few weeks, we’ve been exploring how monads can help scale TPS.

The following is a detailed explanation of how Monads work, written by Saurabh Deshpande.

Detailed explanation of how Monad works

TPS is an indicator that we are very concerned about. We want our chains to be able 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 breached 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.

What should we do if we want to increase TPS?

• The first approach is to build a completely new system, like Solana did. It sacrifices EVM compatibility compared to 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 scale Ethereum with a centralized sequencer.

• The third approach is to decompose the EVM into separate components and optimize them for scalability.

Monad is a new EVM-compatible L1 that recently raised $225 million that is building EVM from the ground up, rather than using it directly. It chose this third approach to increase scalability.

We discussed several major changes brought 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. Consider 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. So while the truck is parked, motorcycle parts are unloaded, sorted, assembled and loaded on the same truck. While the classification team is working, other teams are waiting. Therefore, if you think of their work as separate slots, each team only works once in four slots. This results in significant inefficiencies, highlighting the need for a more streamlined approach.

Now, imagine a platform 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 be transferred directly to the next truck.

The same goes for the sorting, assembly and loading teams. Once unloading is complete, the truck moves to the loading bay to wait for the loading team to load the assembled motorcycles. Therefore, a warehouse with only one platform and load/unload areas performs all operations sequentially, while a warehouse with 4 platforms and different load/unload areas performs parallelization.

Think of Monads as infrastructure, equivalent to a warehouse with multiple truck platforms. But it's not simple. The complexity increases when trucks are relied upon. For example, what happens if one truck doesn't have all the parts to assemble 50 motorcycles? Transactions may not always be independent. Therefore, the Monad must handle transactions that depend on each other when it executes them in parallel.

How to deal with it? It implements a method called optimistic parallel execution. The protocol can only execute independent transactions in parallel. For example, consider 4 transactions where Joel's balance is 1 ETH:

• Joel sends 0.2 Ether to Saurabh

• Sid Minting An NFT

• Joel sends 0.1 ether to Sid

• Shlok Purchase PEPE

All These transactions are executed in parallel, and pending results are submitted one by one. If the output of the 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 inputs from other transactions because they are independent of each other. But transactions 1 and 4 are not independent.

Please note that since all 4 transactions start from the same state, the focus is on Joel's balance of 1 ETH. After Joel sent 0.2 ETH, the balance was 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 the 3rd transaction. So now 3 is re-executed with an input of 0.8 ETH. After executing 3, Joel's balance is 0.7 ETH.

MonadDb

At this point, the obvious question is how do we know that we don't have to re-execute most of the transactions. The answer is that re-execution is not the bottleneck. The bottleneck is accessing Ethereum’s memory. It turns out that the way Ethereum stores state in a database makes accessing state difficult (time consuming and therefore expensive). This is another improvement of Monad: MonadDb. The way Monads structure databases reduces the overhead associated with read operations.

When the transaction must be re-executed, all inputs are already in cache memory, which is easier to access than the overall state.

Solana had 50k TPS on its testnet, but now only has about 1k TPS on the mainnet. Monad claims to have achieved 10k real-world TPS on its internal testnet. While this doesn't always represent real-world performance, we can't wait to see how Monad performs in real-world applications.

The above is the detailed content of Monad Getting Started Guide: Quickly Understand Parallel EVM and Performance Improvement. For more information, please follow other related articles on the PHP Chinese website!