Understanding Monad

Hey there,

Transaction scalability has been the talk of the town. We have been exploring how Monad helps scale TPS over the past few weeks.

The note below is a breakdown of how Monad works written by @desh_saurabh. Consider signing up at Decentralised.co if you enjoy reading data-driven explainers on all things Web3. See you on the other side!

TPS is a metric we obsess over. We want our chains to support a higher TPS as they could support more users and applications. The chart below shows the TPS numbers for Ethereum and L2s. Not one chain has ever broken above the 100 TPS mark. Note that TPS is a general catch-all term for measuring scale. TPS is inaccurate because not all transactions are equal, as they differ in complexity. But we use TPS as a measure of scale for simplicity.

What do we do if we want to increase the TPS?

1. One approach is to build a completely new system, like Solana did. It sacrifices EVM compatibility in favour of speed. It uses multi-threaded execution instead of single-threaded (think of a multi-core CPU vs. a single-core CPU), parallelises transactions, and uses a different consensus mechanism.
2. The second approach is to use off-chain execution and scale Ethereum with centralised sequencers.
3. The third is to break down the EVM into separate components and optimise them to improve scalability.

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

We discuss a few significant changes that Monad brings to the table.

Parallel Execution

Ethereum Virtual Machine (EVM) executes transactions serially. Until one transaction is executed, the next transaction has to wait. Think of it this way. Say there’s a platform in a motorcycle assembly warehouse. Multiple trucks drop motorcycle parts (in a way that each truck has all the parts necessary to create 50 motorcycles). The assembly warehouse performs four different functions with dedicated teams – unloading, sorting, assembling, and loading.

With the current EVM setup, there’s only one platform, and the same spot is used for loading and unloading. So when the truck is parked, motorcycle components are unloaded, sorted, assembled, and loaded on the same truck. While the sorting team is working, every other team is just waiting. So, if you think of their jobs as different slots, each team works only once in four slots. This leads to significant inefficiencies, highlighting the need for a more streamlined approach.

Now, imagine there are four platforms with different loading and unloading areas. Even if the unloading team can work with only one truck at a time, they don’t need to wait for the next three slots. They can move right to the next truck.

The same goes for the sorting, assembling, and loading teams. Once the truckload is unloaded, the truck moves to the loading area and waits for the loading team to load assembled motorcycles. So, the warehouse with only one platform and loading/unloading area executes everything sequentially, and the one with 4 platforms and different loading/unloading areas is parallelising.

Consider Monad as infrastructure equivalent to the warehouse with multiple truck platforms–but not as simple. The complexity increases when trucks are dependent. For example, what if one truck doesn’t have all the parts to make 50 motorcycles? Transactions may not always be independent. So, when Monad executes them in parallel, it has to deal with transactions dependent on each other.

How? It performs something called as optimistic parallel execution. The protocol can only execute independent transactions in parallel. For example, consider 4 transactions with Joel’s balance as 1 ETH –

1. Joel sends 0.2 ETH to Saurabh.
2. Sid mints an NFT.
3. Joel sends 0.1 ETH to Sid.
4. Shlok buys PEPE.

All these transactions are executed parallelly with pending results that are committed one by one. Transactions are re-executed if pending result outputs conflict with any transaction’s original inputs. Transactions 2 and 4 don’t have pending results conflicting with inputs of other transactions since they are independent of each other. But 1 and 3 are not independent.

Note that since all 4 transactions start from the same state, the one that is concerned here is Joel’s balance of 1 ETH. The output of Joel sending 0.2 ETH results in 0.8 ETH. After Joel sends 0.1 ETH to Sid, his balance is 0.9 ETH. The results are committed one by one, ensuring that outputs do not conflict with any of the inputs. After the pending result of 1 is committed, Joel’s new balance is 0.8 ETH.

This output conflicts with the input of 3. So now 3 is re-executed with an input of 0.8 ETH. After 3 is executed, Joel’s balance is 0.7 ETH.

MonadDb

At this point, an obvious question is how do we know we won’t have to re-execute the majority 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 its state in the database makes it difficult (time-consuming and thus expensive) to access the state. This is where Monad’s other improvement comes into the picture – MonadDb. Monad has built its database in a manner that reduces overhead associated with read operations.

When a transaction has to be re-executed, all the inputs are already in the cache memory, which is significantly easier to access compared to the overall state.

Solana has 50k TPS on its testnet but does ~1k on mainnet now. Monad claims to have achieved 10k real TPS on its internal testnet. Although this is not always indicative of real-world performance, we are eager to see how Monad works in the wild.

Statement:

1. This article originally titled “Understanding Monad” is reproduced from [chaincatcher]. All copyrights belong to the original author [Decentralised.Co]. If you have any objection to the reprint, please contact the Gate Learn team, the team will handle it as soon as possible.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.