By Sheheryar Parvaz

Paradigm's CTO directly investing in speeding up the EVM. Monad developing novel databases to deal with state growth. MegaETH working close to the metal for millisecond block times. Novel architectures to enable concurrency control for ultimately a non-concurrent architecture and workload. Hundreds of millions dollars worth of man-hours, entire lifetimes, massive termsheets, poured into making the EVM fast.

All completely wasted. Making progreess in entirely the wrong direction for bringing more users to this industry, optimizing entirely for the wrong things. The marketing wizards have played us for fools. The VM was never the problem.

was the vm ever the bottleneck?

Within the blockchain trilemma, the most impenetrable by far has been scaling. How do we provide more transactions per second (throughput), have them respond quicker (latency), and perform them more cheaply (cost)? All of these are major concerns for achieving UX that isn't awful, yet all are major issues plaguing today's Ethereum. But what's the reason these targets are so hard to optimize?

In any decentralized system, all validators need to agree on which transactions to include and in which order. The lower bound for this task, known as log-replication, is provably two phases of consensus. In other words, validators need to broadcast to all other validators at least two phases of messages. This extra communication raises latency and provides an upper bound on total transaction throughput. Solana uses a clever combination of multi-layered fan-out and forward error correction codes to limit the fan-out per validator, though at a small centralization cost and still having a bound on throughput. Ethereum instead uses a gossip protocol, which trades off latency for a larger validator set; epochs now take minutes to confirm and finalize.

These constraints impose an inherent limit to the number of transactions that the network can process per second, and a lower bound on the time for any transaction to be executed and finalized. On Ethereum, this takes on the order of minutes. These constraints are real: Bitcoin has been hesitant to raise the block size, and Ethereum has had to consider raising the gas limit several times. For a user, a transaction is not considered done until enough validators agree on it, which takes on the order of several minutes.

How fast is a transaction executed once it's included, though? If transactions take time to execute, they'll affect cost, throughput, latency, right? Barely. For a computer, executing code is trivial. A message to another validator might take on the order of milliseconds; modern processors will do millions of operations during that time. Even barring Ethereum's inefficient state model, the latency for a state root calculation is far outweighed by the multi-minute epoch delays.

You'll argue that Solana has put effort into optimizing the VM and making it parallelizable. And you'd be right, because they've designed a novel block propagation protocol and consensus, which optimizes their protocol to the point where the VM does become the bottleneck.

But for Ethereum? Consensus. Bandwidth. Those are the real bottlenecks. Until you have highly optimized streaming, this is worthless. So, what's the right direction? Data availability providers and danksharding are a good start. They raise the overall bandwidth of the network! Optimizing the EVM? Nope.

is the ethereum virtual machine even good?

"But we should still optimize the EVM so we're ready for when SSF and other optimizations land!" or "Optimizing the EVM still helps speed up rollups!" you say. But at that point, would the EVM even be a good fit? We've got zk-SNARKs and the choice to use any environment. Is the EVM really the best choice, despite Solidity being incredibly obscure and clunky to use?

If so, why are basically all other chains, like Sui, Aptos, Cosmos, Polkadot, Avalanche, completely avoiding the EVM? In practice, there is nothing inherent to the EVM that makes it more qualified for being the virtual machine. The only reason many L2s use it is so the comparatively few Solidity devs feel comfortable switching to some fancy new chain. Ultimately, what does an execution environment need to provide?

The bare minimum we need to have is transaction execution, i.e. revert on failure and isolation, sandboxed execution, due to validators running untrusted code. Turns out, these are not unique to blockchain. In fact, nearly every field of software engineering benefits from these incredibly powerful primitives, and these problems have been solved repeatedly. Several databases in the web2 world also now offer wasm-based transactions in the database. These don't have the consensus bottleneck, which creates a significant incentive to be highly performant as well. All modern browsers have a wasm engine, which creates a strong incentive for sandboxed execution.

So, if the EVM is not unique regarding transactionality and sandboxing, what makes it so good? Exactly--Nothing! It had the first mover's advantage and provides synchronous composability between contracts, but beyond that, there is nothing inherently unique to it.

On the contrary, modern instruction sets like wasm and eBPF (used by Solana) are incredibly standard, highly optimized (is within ~1.5x of native performance), have fantastic tooling, and are used in various highly-adversarial contexts such as the Linux kernel! The EVM, however, is incredibly difficult to parallelize (at most 2x speedup, due to data dependencies on real workloads), has poor tooling (even Foundry is largely frustrating to use), lacks fast implementations (has anyone in this domain even heard of JIT?), and leaves us stuck with the storage model's limitations (compare it to NOMT).

So, what's the point of investing so much time to the EVM? Mostly, burning investor money and laypeople's attention, and making you think the token price is going to rise.

wait, does ethereum even need a virtual machine?

We can go as far as arguing that even the Ethereum Foundation doesn't believe in the EVM, given the emphasis on Layer 2 protocols which have no reason to use the EVM. Ultimately, the Layer 1 would just be an attestation layer, at which point the execution environment has little to no use other than acting as a shitty intermediary.

Given the recent advances in zk-SNARKs, do we even need a virtual machine at the Layer 1? SNARKs can be designed in various ways. They can be specialized to the EVM of course, but the design constraints are different and in practice they are better off using RISC-like ISAs.

Ethereum itself has little reason to continue developing the EVM, given its focus on scaling through Layer 2 solutions. So if the Ethereum Foundation is not interested in the EVM, why are other protocols building on top of it? Does this make sense to you? Surely, we haven't all been this misled, right?

so, where are we headed?

The future lies in making the developer experience incredibly smooth to encourage a variety of applications. Instead of requiring developers to learn a new, obscure, esoteric language, we should encourage them to use what they already know. Instead of introducing new concepts like gas, they should think in terms of compute units that are intuitive. Instead of oddly segmented, new types of memory, they should use volatile and persistent memory as they always have. All we need is transactionality and sandboxing. Implementing transactions in a sandboxed JVM would have, unironically, brought more developers to the space!

The solution is simple. Build a virtual machine that works well. Then, provide verifiability for it. That is all users and developers want. Developers want a place to build.