What Exactly Is Parallel Execution?

source: https://www.monad.xyz

Parallel Execution is becoming a popular buzzword in the crypto world, but it wasn't always that way. When the initial Monad team started working more than 1.5 years ago to optimize EVM performance, executing transactions in parallel was a simple,

but important concept for scaling.​ One of the interesting aspects of Solana's speed and scalability is — parallel processing. With Ethereum Mainnet processing only ~14 TPS, but having the largest user base, developer network, TVL metrics, and research team, optimizing the Ethereum stack is an obvious, albeit challenging, project.

There is a rapid increase in interest in the concept of parallel execution, but there is still a lack of good explanation of the topic, as well as where the real obstacles and challenges lie. It's great to see top researchers and engineers raving about the performance improvements Monad brings to EVMs, but for the average user, like me, it's hard to know what's real and what's not. Heck, it's even hard to understand what they're talking about.

If you can understand that, this article is for you. I sat down and chatted with Keone Hon, CEO of Monad Labs, and discussed this topic at length. I learned WHAT Monad was building, WHY they took the “hard road”, and what the long-term impact was. If you want to understand what Monad is doing, without delving into the deep technicalities, just wait and I'll walk you through it.

Let's start with our favorite analogy in Monad — a race car. Imagine you are trying to physically build the fastest race car engine. I'm not qualified to do this, and you probably aren't either, but it's a great example to understand what we're working on.


Would you take a 2015 chassis and use a Ford Focus engine? Probably not, because you know it won't go fast. Instead, you might choose to rebuild the machine from scratch, identifying inefficiencies and eliminating bottlenecks until you get to the optimal product.

Over a year and a half ago, when Keone Hon and James Hunsaker, the Godfathers of the Parallel EVM™, left Jump Trading to start working on Monad, this is what they did. A rather radical idea at the time, they aimed to optimize the Ethereum VM so that it could support applications on a global scale, running tens of thousands of transactions per second, supporting millions (if not billions) of users, with applications ranging from personal finance to next-generation social applications, central limit order books, and everything in between.


Ethereum VM is a powerful standard, and has the widest reach across smart contract developers. EVM applications have the most capital on the chain, and the EVM chain owns approximately 96% of all TVL in crypto. BUT, if crypto is truly going to be mass adopted, we need more performant machines to process transactions on a global scale.

At 14 TPS, Ethereum mainnet can process more than 1.2 million transactions per day. These numbers pale in comparison to traditional systems like Visa, which processed an average of 660 million transactions per day in 2022. During the research phase, Monad Godfathers tested various optimizations and algorithmic improvements for the EVM. However, it soon became clear that parallel execution alone would only increase performance nominally. Because the real obstacle is state access.

Status refers to the data stored in the system including transactions, accounts, and resulting hashes. With each transaction, the state mutates. Valid updates depend on their state dependencies, and the validity of all previous transactions on the network. For example, you are trying to create an NFT by interacting with a creation contract. The success of your minting, and the NFT yield you receive, depends on all previously minted NFTs, and all those that have been recorded on-chain, to date.

Although the number of EVM environments for execution continues to grow, most new and existing implementations reuse go-ethereum (Geth), a tried and true commodity implementation Ethereum client. The result: most EVM chains experience bottlenecks at the state access layer. State access is the SINGLE biggest obstacle because Geth State DB does not support Asynchronous IO. When executing transactions in parallel, requests block each other; this is the main obstacle.


Now that Monad's work on Parallel EVM has become a popular concept, other teams are starting to work on their own implementations. There's a lot of excitement about this, and it's a great thing, but in the end, all these implementations will come to the same conclusion as Monad did 1.5 years ago; the biggest obstacle is state access.

This left Monad's initial team facing a crossroads: An easier way is to store all state in memory (RAM). BUT, the downside is, this increases the RAM requirements to run a node, potentially to 100 gigabytes or more (Solana requires more than 200 GB). RAM is expensive and this impacts network decentralization. The ability for anyone to run a node on commodity hardware has always been a core pillar of Ethereum's decentralized ethos, and this option eliminates that possibility.

THE HARD WAY, but a more scalable option, is to build a custom state backend. This new dedicated database will enable efficient SSD storage, with optimized access to state by adding support for Asynchronous IO. With the goal of significantly improving performance, this was an important path, and fortunately, it was the path chosen by the Monad team. It is worth mentioning that not just anyone is experienced and knowledgeable enough to solve this problem. But with decades of combined experience in optimizing frequency trading systems

The core of Monad is a customized Monad DB; it has support for Asynchronous IO — allowing multiple VMS to run in parallel to access state efficiently. From there, Monad made more improvements to optimize performance. Monads have: Parallel execution Asynchronous IO High performance consensus mechanism And of course, core improvements in the fully customizable Monad Database


YOU NEED ALL OF THIS TO BASICALLY OPTIMIZE EVM AT SCALE. There are no shortcuts, and no second best options here — without experiencing such huge trade-offs, the initial goals and missions are pointless.

Users running Monad nodes will get the best of both worlds: a blockchain that delivers state efficiently, and without using a lot of RAM. I can't stress enough; it's not easy to do, and as we've heard Keone say time and time again — THERE ARE NO SHORTCUTS. Parallel execution is cool, but fundamental optimizations are actually useful in scaling.

If you've made it this far, you now know the high-level value proposition of EVM Monad's optimized and compatible L1 smart contract platform. This has been going on for over 2 years, and not just any engineering team is working on this issue. This is a crypto-native team, but also a team with context and practices that optimize traditional financial systems. This is a team that understands the critical elements for scaling crypto, and the risks to the industry if we can't support applications on a global scale.

If you enjoyed this article, follow The Pipeline for more news, alphas, and updates on all things Monad. And don't forget to leave a comment below; I'd like to hear your opinion. See you in community chat, and of course, gmonad.