The Ethereum Virtual Machine (EVM) achieved a dominant position in the last few years despite many proponents of alternative languages for smart contracts. Solidity is today the most widespread smart contracting language, and many alternative chains are adopting the EVM one after the other.

The most notable examples include Near, Sei and EOS. Even Solana, which has found a decent level of developer adoption, hosts a layer-2 blockchain called Neon EVM. Upcoming chains like Monad and Fhenix, as well as most upcoming L2 protocols, also push for full EVM compatibility.

But instead of trying to do the same thing months later, many of these projects want to take the EVM one step further in terms of performance and usage.

Why is the EVM so dominant?

For non-developers it might be difficult to understand why the EVM has reached such dominance. Ethereum has been traditionally expensive compared to newer alternatives, and the EVM was a significant contributor to its inefficiency, which is why new projects mostly adopted WebAssembly for their execution environment.

It is largely a question of community support, tooling and momentum.

Smart contract development requires many secondary tools that can make or break the developer experience. A tool like Hardhat makes it easy to deploy contracts and simulate their execution. A library like Ethers also makes it easy to interact with smart contracts from servers and dApp frontends. Finally, there are so many ready-made smart contracts and open-source websites that spinning up a new dApp can be done in just a week or less for a skilled developer.

Other chains are unlikely to have similarly mature frameworks, and the language itself has little to do with it. Indeed the EVM supports a much lesser known language called Vyper.

Any new upstart has a huge barrier of entry as they need to re-implement many years of development by a large community. Hence, new projects wishing to innovate in the execution layer are starting to choose to improve the EVM, instead.

Parallel EVMs for stable throughput

Many of the projects that support the EVM are re-implementing it from scratch, which gives them an opportunity to significantly optimize it.

One major category includes parallelized EVMs, which take a page out of Solana’s book to improve the execution speed of the virtual machine.

Sei, Monad and Neon are the three main names in parallel EVMs, and they mostly attempt to achieve the same thing: a “multi-threaded” EVM. In a nutshell, the incoming transactions are all spread into multiple execution threads, and if these transactions don’t affect each other, then they can be smoothly added into the finalized block.

Like with multi-threading in regular computers, the performance benefits of this approach depend on how the specific applications make use of them, and it’s somewhat of a situational scaling. 

A good example of where the parallelization approach might lose efficiency is during highly anticipated token launches, NFTs or other events that tend to clog up chains. Since all the transactions involving this event are inter-connected, then it’s difficult to make them parallel.

Furthermore, some smart contract designs (like the upcoming Uniswap V4 single contract DEX) would be particularly ill-suited for parallel EVMs. Since every single pool is located in the same contract, then all swaps could be considered to interfere with each other and lose the benefits of parallel execution.

Ultra-fast designs for peak output and latency

EOS, one of the older Ethereum competitors, is going for a different approach based on utilizing the entirety of the hardware available.

When it launched in 2018, EOS was in many ways ahead in terms of performance (despite a few initial hiccups), but was severely lacking in terms of developer experience.

With its EOS EVM, the project is now looking to leverage the EOS architecture to make an ultra-fast EVM. Recent stress tests saw that it could pack over 2000 transactions in a single block, all while producing two blocks per second. This would easily place it as the most performant EVM blockchain on the market, both in terms of throughput as well as transaction finality speed.

Unlike with parallel EVMs, existing contracts can be used as-is while taking full advantage of the speed — EOS EVM is nearly identical to Ethereum’s machine. The network continues to get gradual but impactful updates, which should unlock better performance for Solidity contracts.

As some teams work on improving the EVM, Arbitrum is trying to integrate WebAssembly seamlessly with EVM contracts, citing its 10x overall performance gains and 100x more efficiency when using RAM.

Regardless of which language will be used for smart contracts, one thing is clear: the EVM itself is in need of an update.