Monad Beginner's Guide: Quickly Understanding Parallel EVM and Performance Enhancement
TechFlow Selected TechFlow Selected
Monad Beginner's Guide: Quickly Understanding Parallel EVM and Performance Enhancement
Re-execution is not the bottleneck; the bottleneck is accessing Ethereum's memory.
Navigating Web3 tides with focused insightsAuthor: Decentralised.Co
Translation: TechFlow
Transaction scalability has always been a hot topic. Over the past few weeks, we've been exploring how Monad can help scale TPS.
Below is a detailed explanation of how Monad works, written by Saurabh Deshpande.
TPS is a metric we care deeply about. We want our blockchain to support higher TPS because it enables more users and applications. The chart below shows TPS figures for Ethereum and various L2s. No chain has ever broken the 100 TPS mark. Note that TPS is a general term used to measure scale. It's imprecise because not all transactions are equal—they differ in complexity. But for simplicity, we use TPS as a proxy for measuring scale.
So what can we do if we want to increase TPS?
-
The first approach is to build an entirely new system, like Solana did. It sacrifices EVM compatibility for speed. It uses multi-threaded execution instead of single-threaded (think multi-core CPU vs single-core), enabling transaction parallelization, along with a different consensus mechanism.
-
The second approach is off-chain execution, scaling Ethereum using centralized sequencers.
-
The third approach is to break down the EVM into separate components and optimize each for scalability.
Monad is a new EVM-compatible L1 that recently raised $225 million. Instead of reusing the existing EVM, it’s rebuilding it from scratch. It has chosen this third approach to achieve greater scalability.
Let’s examine several key innovations introduced by Monad.
Parallel Execution
The Ethereum Virtual Machine (EVM) executes transactions sequentially. The next transaction must wait until the current one finishes. Think of it this way: imagine a platform in a motorcycle assembly workshop. Multiple trucks deliver motorcycle parts (each carrying all parts needed to assemble 50 motorcycles). The workshop performs four distinct functions: unloading, sorting, assembling, and loading.
In the current EVM setup, there’s only one platform, and loading/unloading happen at the same spot. So when a truck arrives, parts are unloaded, sorted, assembled, and loaded back onto the same truck—all in sequence. While the sorting team works, the others wait. If we view their tasks as time slots, each team operates only once every four slots. This creates significant inefficiency, highlighting the need for a smoother workflow.
Now, imagine four separate platforms, each with dedicated loading and unloading zones. Even though the unloading team can only work with one truck at a time, they don’t have to wait through the next three steps. Once unloading is done, they can immediately move to the next truck.
The same applies to sorting, assembly, and loading teams. Once unloading is complete, the truck moves to the loading area to await final shipment. Thus, the warehouse with one platform performs operations sequentially, while the one with four platforms achieves parallelization.
Think of Monad as infrastructure—like a warehouse with multiple truck platforms. But it’s not that simple. Complexity increases when trucks depend on each other. What if a truck doesn’t have all the parts needed to assemble 50 motorcycles? Transactions aren’t always independent. So when Monad executes them in parallel, it must handle interdependent transactions.
How does it manage this? It uses a method called optimistic parallel execution. The protocol can only parallelize independent transactions. Consider four transactions where Joel has a balance of 1 ETH:
-
Joel sends 0.2 ETH to Saurabh
-
Sid mints an NFT
-
Joel sends 0.1 ETH to Sid
-
Shlok buys PEPE
All four transactions are executed in parallel, with provisional results committed one by one. If the output of a pending result conflicts with any transaction’s original input, that transaction is re-executed. Transactions 2 and 4 have no conflicts because they’re independent. But transactions 1 and 3 are not independent.
Note that all four transactions start from the same state—Joel’s balance is 1 ETH. After sending 0.2 ETH, his balance becomes 0.8 ETH. Then he sends 0.1 ETH to Sid, bringing his balance to 0.9 ETH. Results are committed sequentially to ensure outputs don’t conflict with inputs. After committing transaction 1’s result, Joel’s new balance is 0.8 ETH.
This output conflicts with transaction 3’s input. So transaction 3 is re-executed with the updated input of 0.8 ETH. After re-execution, Joel’s balance becomes 0.7 ETH.
MonadDb
At this point, an obvious question arises: how do we know we won't have to re-execute most transactions? The answer is that re-execution itself isn’t the bottleneck. The real bottleneck is accessing Ethereum’s memory. It turns out that Ethereum’s method of storing state in databases makes state access slow (and therefore expensive). This is where Monad introduces another improvement: MonadDb. Monad’s database architecture reduces the overhead associated with read operations.
When a transaction needs to be re-executed, all its inputs are already in a cache memory, which is much faster to access than the full state.
Solana achieved 50k TPS on its testnet but now runs at around 1k TPS on mainnet. Monad claims to have achieved 10k actual TPS on its internal testnet. While testnet performance doesn’t always reflect real-world conditions, we’re eager to see how Monad performs in practice.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@Decentralisedco
