Hype or Reality? A Look at Parallel EVMs
“It is the best of times for scaling EVMs; it’s the worst of times for sticking to the bigger block thesis. It is the age of decentralization; it is the age of memecoins. It is the epoch of seeking meaning; it is the epoch of financial nihilism…“ (Loosely inspired by Charles Dickens)
Without a doubt, the EVM stands as the most popular virtual machine with Ethereum facilitating roughly 60% of all DeFi transactions, and having network effects that are hard to compete with. Nevertheless, as the thesis of induced demand suggested, with every new L2 added, there’s eventually a point where all blockspace is saturated.
All it takes is yet another hyped memecoin launch. Maybe it is the best of times to re-think how transactions ought to be processed in blockchains. Although sequential processing has worked fine, it’s far from up to the task of even competing with existing financial systems in scale.
Parallel processing is the latest approach to increasing blockchain throughputs while alleviating some of the pains of having all transactions compete for inclusion in blocks.
To discuss how parallel processing scales EVMs and whether the hype was justified, Subsquid Labs invited speakers from Monad, Canto, and NEON EVM for an X Space. You can listen to the recording here or read on for a holistic overview of parallel EVMs' potential and limitations.
Why Parallelization?
Parallelization is nothing new. The idea can be traced back to 1837 and found its first technical implementation in the 1950s. The concept is simple: allowing computers to utilize multiple processing elements at the same time to solve an operation, dividing large, complex tasks into smaller, more manageable chunks.
Initially confined to high-performance computing systems, parallel computing has become the dominant paradigm in computer architecture.
“You can’t even buy a single-threaded computer today. Even a Raspberry Pi is parallel-processing.” - Zen Monad
By extension, parallel EVMs are simply protocols that run the Ethereum Virtual Machine in parallel. Note, though, that not all L2s are parallel EVMs because they run their own separate state.
Parallelization in blockchains
When you submit a transaction on an EVM chain, the process works roughly like this:
- Sign transaction
- The transaction is submitted to mempool
- Block proposer picks it up, includes, and proposes a block
- Validators then oversee the transactions, validate the content, and add it to a block
- EVM executes blocks one by one to ensure compatibility
Unfortunately, whenever network activity reaches peaks, users have to compete for inclusion in blocks, driving up fees and leading to congestion. However, processing transactions one by one is necessary for this design to avoid any conflicts and maintain adherence to consensus.
But it doesn’t have to be like that.
Take Solana, the first blockchain to build around parallelization. Surely, the founder's background in hardware will have had a major influence on their network architecture. Coming from an industry where everything is processed in parallel can do this to a person.
Deterministic vs optimistic parallel execution
Deterministic
Solana is an example of a blockchain that relies on deterministic parallel execution. This means that each transaction has to declare all memory dependencies upfront and which parts of the state it wants to access. This ensures that there are no conflicts, enabling the network to sort and identify independent transactions, rescheduling the ones with dependencies.
Parallel processing in Solana is further aided by Sealevel, its custom smart contract runtime, which guarantees that validators can process multiple transactions to the extent of the validator core’s capacity. This means Solana scales with hardware.
“With NEON EVM, we’re tapping into the parallelization of Solana by running the EVM as a smart contract on the underlying blockchain. Requests made can be run in parallel, speeding up processing significantly.” - Miro (NEON EVM)
Optimistic
Although deterministic execution is optimized and efficient, it puts high overhead on systems and developers. That’s why many other chains have opted to start parallelizing their transactions optimistically.
Doing so means assuming that all transactions are independent and only re-executing them if any conflicts arise. Canto’s speaker Abhi shared that they’ve chosen to implement optimistic processing as part of a natural evolution based on how they saw their thesis of most computation happening off-chain play out irl. Currently, they acknowledge that much focus is on putting as much as possible onchain, and with their implementation of parallel processing, they’ll be able to facilitate that.
There are, of course, potential challenges with processing all transactions under the assumption that they are independent.
As mentioned above, Solana solves potential conflicts by rescheduling transactions. Miro furthermore advised devs to split state as much as possible across accounts to reduce potential conflicts.
In Monad, devs are relying on optimistic concurrency control to optimize the system. As Zen explained, transactions run in parallel but are not committed immediately. Instead, inputs and outputs are compared and if there are inputs that change because of a prior output, that’ll be addressed. If there are no dependencies, transactions are committed. “Re-executing transactions is super cheap because the most expensive interaction is calling the state, however, you’ve already loaded that data before, so you don’t have to repeatedly do that.”
This brings up an interesting point that’s often overlooked: the real speeding up of throughput does not happen by processing transactions in parallel alone.
“The real bottleneck of TPS is not block size but it is the execution of transactions, and more specifically, the question is how fast can you access storage slots the transaction requires? The biggest win in scaling will come from parallelizing access instead of doing random access 1000 times as is the current design.” - Dmitry Subsquid
That’s why Monad has spent nearly a year figuring out how to build a custom DB that can support parallel execution. Leveraging advanced Linux kernel features, Monad’s DB enables async disk operations, where the system can start processing the next transaction while still waiting to read the state from a prior transaction.
“We realized that we had to build a database that served the data necessary while also maintaining a Merkle tree. It took us nearly a year to get to this point where we can run sequentially dependent steps in parallel and offset the time they occur.” - Zen, Monad
Similarly, Canto has split its upgrade into three smaller updates. The first two steps introduce optimistic execution and parallel processing, and the last step is dedicated to optimizing state access.
Now, with all of this talk about state access and running things in parallel, you might wonder:
Doesn’t that sound like sharding?
The crucial difference between parallelization and sharding is how they treat the blockchain state. Sharding splits state to allow parallel things to happen while it remains intact when using parallelization.
That’s also the reason why Miro states he’s “quite pessimistic when it comes to sharding because you always have to calculate in time for shards to sync,” and Zen has an even stronger opinion:
“Sharding sucks.”
The synchronization lag hampers composability, making it impossible to build certain DeFi apps on top. What’s more, sharding does not solve the issue of, as Dmitry calls it, “noisy neighbors where there is one super successful contract that clogs the entire network.”
Sounds like parallelizing EVMs could be a big step in the right direction. But why EVM anyway?
On choosing EVM
Anyone following closely what Mikko tweets must come to the conclusion that the EVM is a flawed system. And still, all of our speakers have picked it as their Virtual Machine. Maybe VMs are like romantic partners: you shouldn’t ask too much of them, nor expect them to be perfect.
“We were following the trend when we chose to run EVM. There are already many devs using Solidity and all the tools needed to make it easier. Plus, there are still 5- 6 times more devs in the Ethereum ecosystem than building on Solana. That’s why we decided to bring the benefits of both together” - Miro, Neon EVM
Abhi from Canto added that there aren’t many devs in general in Web3, and by picking EVM protocol teams allow others to build on top of existing battle-tested tools. It’s also a high tail risk to create a new language from scratch, often requiring lots of money to gain basic levels of adoption.
Zen compared EVM to Javascript, explaining that there are better languages out there, but everyone is using it because of the tooling and the ease of access to people who can answer questions about it on stack overflow.
The EVM’s stronghold is further established by research around it, and its existing network effects and community. Parallelized EVMs then just take this already well-established technology and make it more scalable and accessible.
But how far are we really on that mission?
Status Quo of Parallel EVMs
Solana has struggled with congestion and other networks that include parallelization, such as SEI, haven’t really taken off. Monad by definition, is very immature as it’s not even in testnet yet, and Canto hasn’t moved all to parallel execution either.
For now, it seems parallel EVMs are more hype than reality. But innovation moves fast in crypto. In five years, everyone on the space hoped that we’d stop talking about parallel EVM and talk about apps enabled by it instead. They foresee that parallelization will just become the way we do things.
After all, why shouldn’t we adopt what’s already common practice in computing to speed up our blockchains?