EVM Equivalence v.s. EVM Compatibility

There’s no question that the EVM (Ethereum Virtual Machine) is currently the de-facto runtime for the execution of smart contracts. This may change in a few years, but there is no doubt that today almost every successful decentralized application (DApp) targets the EVM. From every large DeFi project like Uniswap, or Aave, to DAOs such as MolochDAO, and the most expensive NFTs minted on-chain, EVM is the gold standard.

So how did the EVM become the de-facto runtime of smart contracts? Well, there are a few reasons. Firstly, Ethereum was the first blockchain network to practically introduce support for the execution of on-chain smart contracts. To implement these smart contracts, the Ethereum team released a new programming language, Solidity, that compiled directly into EVM bytecode. Thus, in the dawn of blockchain history, if someone wanted to implement a new smart contract, he needed to learn Solidity, as it was the only suitable way to target the EVM runtime that the Ethereum network ran.

As Ethereum started gaining traction, a lot of different tools appeared to ease and speed up the implementation and deployment of smart contracts over Ethereum (and thus the EVM). You are probably aware of names like Truffle, Ganache, Infura, OpenZeppelin, Hardhat, etc. As more and more applications were making the Ethereum mainnet, more innovation went into these tools and the Ethereum/EVM ecosystem.

That brings us to today. We’ve now reached a point where the most successful decentralized applications are deployed in Ethereum and target the EVM, with an exponentially larger user base than what we saw in the early days of Ethereum. A lot of investment has gone into the development and audit of these DApps and tools. Even more, the gross of smart contract development talent out there is proficient in Solidity, Vyper, and architectural designs for the EVM. This is how EVM has become the de-facto runtime for smart contracts, and why we shouldn’t expect that to change any time soon. Even more, this is why new blockchain platforms tend to support the EVM in some way if they want to attract all these users, talent, and innovation to their ecosystems.

EVM in Layer 2 solutions

But today I am not here to talk about EVM support in other blockchain platforms, but rather EVM support in Layer 2 solutions. As many of my loyal readers may already know, L2 solutions are trying to improve the scalability and costs of Ethereum. There are different flavors of L2 solutions, but ones that are gaining a lot of traction these days are Optimistic Rollup projects.

L2 solutions based on Optimistic Rollups work as follows: transactions made on Layer 1 Ethereum are rolled up all at once, then executed all at one on the L2 network, thus increasing scalability dramatically, making transactions much faster and cheaper. A requirement for Rollups to work is to have some kind of Ethereum-compatible independent blockchain, with a reduced number of nodes or with additional features for high performance that is responsible for handling signature verification, contract execution, etc. This makes the independent blockchain able to verify the validity of the transactions that are afterwards bundled for their commitment in the main Ethereum chain. L2 rollups are responsible for verification and contract execution, while the L1 exclusively stores immutable transaction data. Optimistic Rollups use fraud-proofs to ensure that all transactions are legitimate. If someone notices a fraudulent transaction from an aggregator, the Rollup can be challenged by sending a fraud-proof to run the transaction’s computation and verify its validity (or at least this was the case in every project until quite recently, as we’ll soon see).

Something that some readers may have missed from my aforementioned description of Optimistic L2 solutions is the “Ethereum compatibility” part. Many may think that this part is the most straightforward one, but unfortunately this is not the case. Enter the battle of EVM compatibility vs. EVM equivalence.

EVM Compatibility

Traditionally, L2 solutions have been built with EVM compatibility. What does this mean? It means that the L1 contracts for the L2 solution responsible for committing the bundle of rolled up transactions, verifying their integrity, and processing fraud proofs does not implement the EVM itself. Instead, it implements a compatible subset small enough to be able to identify inconsistent state changes inside of the transactions within the Rollup, when fraud proofs are submitted (i.e. able to execute the state change of a transaction as if it was the actual EVM). This subset is also integrated in the L2 chain to perform the state changes in L2 before the rollup.

EVM compatibility has a lot of advantages and made a lot of sense in early implementations of L2 solutions. It allowed projects to move fast and build a production-ready Rollup infrastructure without having to solve the “long-infamous problem” of implementing the EVM in a smart contract (or EVM-in-EVM problem). EVM compatibility reduces the amount of gas required for the fraud-proof verifier contract and its execution (not having to implement the full EVM means less code), and is good enough for the EVM code used by almost every application.

Unfortunately, “almost every application” is not “every application”, and the smart contracts used by the most complex DApps (like Uniswap) also happen to be the ones with a larger use base, and they cannot use Optimistic Rollups out-of-the-box with EVM compatibility due to the complexity of their code. With the current EVM compatibility followed by several L2 solutions, it would be intractable to verify a fraud-proof for a Uniswap transaction. With this approach, for projects like Uniswap settling for mere compatibility means that they are forced to modify, or even completely reimplement, lower-level code that Ethereum’s supporting infrastructure also relies on.

To make matters worse, this adaptation required for smart contracts using Rollups also applies for many of the tools implemented for Ethereum and EVM-like compilers, IDE, smart contract libraries, etc. This translates into the L2 platforms and their developers not being able to benefit from all the innovation of the Ethereum ecosystem. Fortunately, there is an alternative to EVM compatibility, known as EVM equivalence.

EVM Equivalence

EVM equivalence means that the L2 solutions and all of its modules (Ethereum-compatible sidechain, fraud verification mechanism, etc.) are completely compliant with the Ethereum yellow paper, i.e. the formal definition of the protocol. With this, any bytecode that can be run in L1 can also be run in its L2 counterpart. This integrates the full Ethereum stack in the L2 system, so that every Ethereum contract, every toolchain, and even every node implementation compatible with L1 is also compatible with L2.

The advantages are straightforward: it prevents all the compatibility limitations of not having a full EVM in L2. But how is this equivalence achieved?

EVM Equivalence: The Optimism case

Optimism has recently announced that they are moving from EVM compatibility to EVM equivalence, achieving this milestone by separating block generation and execution. Optimism’s client includes a function which accepts user transactions, generates L1 blocks that are aggregated in the Rollup, and generates an L2 block with exactly the same format as L1 blocks to make the execution of L2 blocks equivalent to L1 blocks. The idea is quite straightforward, being the crux of how to implement the EVM interpreter that enforces no frauds in Rollups on-chain.

Optimism has decided that instead of trying to solve the EVM-in-EVM problem, it will implement a VM with a much smaller, simpler instruction set, and run the EVM within this VM during fraud proofs. This is achieved by integrating an EVM interpreter in their Geth clients instead of having to rely on a dedicated smart contract.

“We allow Geth itself to run inside a dispute-friendly environment. Since Geth is EVM-equivalent, so is that environment. This allows us to bypass re-implementing the EVM on-chain, and future-proofs the system against future upgrades to the EVM.”

(source: https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306).

Now you may be wondering, “wait, no on-chain contract verifying fraud proofs?”… yep. Optimism chooses to remove fraud proofs from their system. Instead of having to verify state inconsistencies on-chain, Optimism will run the EVM interpreter within its modified Geth client so no frauds are allowed in execution, ensuring that committed Rollups can’t include frauds.

This approach has clear advantages in the performance and stability of the fraud scheme, as it is run on every client that is running the protocol. It also reduces the cost of verifying fraud proofs on-chain (as there is no explicit fraud proof verification on-chain anymore).

So what is wrong with this approach then? Well, first the fact that this is a solution only compatible with Optimism’s modified geth client. When fraud proofs were verified in an on-chain contract, anyone was allowed to submit a proof from any Ethereum client, even if they were not running the Optimism protocol. This is not the case anymore, as Optimism clients are the only ones configured to detect these frauds. Even worse is the fact that we are delegating all the trust to the Optimism team. Yes Optimism’s code is open source and everyone can audit it. But choosing this path still makes the process far less immutable than an on-chain contract would.

EVM Equivalence: The Metis case

Are there other ways of achieving EVM equivalence? Metis was originally a hard-fork of Optimism, so the project was following the same EVM compatibility approach in the past. With the upcoming change of Optimism to EVM equivalence, Metis has also decided to move into this new EVM-equivalent world. However, in this case, Metis approach does not directly follow Optimism’s.

As described in the aforementioned post, the reason why Metis decided to explore a new approach for EVM equivalence is the lack of decentralization it sees in the new fraud scheme from Optimism. Metis is instead exploring a merged approach with EVM equivalence and the use of fraud proofs. If you recall from my description of Metis in this post, it uses multiple sequencers instead of a single one. Sequencers need to deposit some tokens to be entitled to create a Rollup, and they are chosen randomly to perform this task. By changing the format of their proof to use a similar approach to Optimism’s, they support equivalence in their rollups by decentralizing the aggregation.

Another key part of Metis protocols are Rangers, who are responsible for challenging sequencers. Rangers seek frauds in the committed rollups on-chain. They are the ones interpreting the EVM code inside of the rollups to determine if fraud has occurred. In their new design, Metis proposes adding a consensus layer to Rangers in order for them to collectively challenge sequencers. When a challenge is initiated and corroborated by other verifier entities via Layer 1 consensus, the problematic sequencer is slashed, penalized, and taken offline. Another sequencer will be selected from the sequencer pool with the correct state to start. The chain will be reorganized accordingly by dropping the problematic blocks. This process will happen fairly fast because of the distributed nature of Metis’ chain storage within the peer network. With this approach, the bulk of the work towards EVM equivalence lies in defining the rollup format and the fraud verification.

The main advantage of this approach is that the process of fraud detection is delegated to third parties independent from sequencers and with a stake in the system, preventing central points of failure and censorship. Having an L1 contract on-chain still orchestrating all of this fraud verification process may still be a bit larger than not having any L1 mechanism, but the fact that all of the complex execution for fraud verification is performed by Rangers and verifiers ensures that the execution of code in L1 is minimal.

EVM Equivalence: The Filecoin case

To wrap up the discussion, let’s see an example of how even independent chains which are not immediate Ethereum L2 solutions (or competitors) also target EVM equivalence. The Filecoin team recently announced the implementation of FVM (the Filecoin Virtual Machine). FVM will mainly target WASM as its native contract runtime, but in the same way L2 solutions target EVM equivalence, the FVM is targeting the support of any VM as part of its runtime to enable migration, execution, and interoperability with other chains. Unsurprisingly, Filecoin is targeting EVM equivalence as its first foreign VM to be supported in the network. In this case, FVM will provide a complete implementation of EVM as a foreign VM embedded in its runtime.

I can’t wait to see what the DApp space comes up with once they can leverage Filecoin storage capacity from their EVM-compatible smart contracts. Is the time of Data DAOs coming? (let’s leave it here for now, expect a upcoming publication dedicated to the FVM and the kind of use case it may unleash).

Write once, deploy everywhere

Solidity and the EVM have become the de-facto standard for the execution of code in the blockchain space. Even if WASM ends up becoming the universal runtime targeted by decentralized systems and bundled in many blockchain clients, we should still expect EVM to be around for a while, even if its bytecode is targeted for WASM runtimes (as in the FVM).

The interoperability of projects is not only the ability to pass messages between chains, but also the ability to use state from other networks, and trigger state changes in foreign chains; for this to be possible, we need standards between all of these technologies. L2 solutions are currently actively working on solving this interoperability problem, and they are paving the way for new chains and projects to come. EVM equivalence seems to be the way to go for execution compatibility (at least for now), but there is still a lot of work to do around data representation (have you heard about IPLD?) and the transport layer (definitely libp2p!) of blockchain networks…not to mention ensuring that EVM equivalence and the highest levels of decentralization, immutability, and security remain in place.