In light of the recent zkEVM announcements of various projects and the ongoing discussion & confusion on how EVM Equivalence is defined, I propose to create an informational EIP that defines properly EVM Equivalence and Ethereum Stack Compatibility.
This discussion thread is intended to collect the community’s opinions that will be used to draft an initial EIP.
I will start with my (maybe controversial) opinion on how to define EVM Equivalence and Ethereum Stack Compatibility:
EVM Equivalence is complete compliance with the Ethereum yellow paper. Period.
Ethereum Stack Compatibility = EVM Equivalence + JSON-RPC Compatibility + Node Architecture Compatibility + Design Pattern Compatibility
- Design Pattern Compatibility = Consensus/Execution Client Separation + (… what else should we put here?)
Now it’s your turn - please share your thoughts on my idea about creating an information EIP as well as your thoughts on defining EVM Equivalence and / or Ethereum Stack Compatibility.
I find 2 issues with this definition:
- The yellow paper is not updated at the same time of Ethereum hard-fork activations, so Ethereum can become non EVM-equivalent for some time.
- Even if we define EVM-equivalence in relation with the EIPs that are activated, EVM-equivalent blockchains may activate Ethereum EIPs later than Ethereum, which makes them suddenly non-equivalent.
I prefer EVM-equivalence to be a property of the evolution of a blockchain: it is EVM equivalent if it follows all activated EIPs of Ethereum, even if this is delayed.
Most smart contract blockchains are EVM-Stack equivalent and EVM-equivalent with the exception of exact opcode gas costs. I don’t need exact gas costs to consider a blockchain or rollup Ethereum compatible.
Therefore EVM-equivalence definition is not useful.
Whether equal gas costs are required for EVM equivalence is an important thing to clarify. Defining it as “compliance with yellow paper” or even “compliance with activated EIPs” seems to imply that gas costs should be the same. I think we should explicitly exclude gas costs from the basic definition of “EVM equivalence”, and when desired make it explicit such as “EVM equivalence down to gas costs” or so.
If we’re being truly precise, the cost of an operation is a part of its semantics. The behavior of a contract can definitely change with different opcode pricing, and we’ve seen this happen on Ethereum itself with hard forks. However, that same precedent shows that Ethereum itself doesn’t consider pricing a “core” part of EVM semantics. We should expect smart contract developers to know by now to design their contracts in a way that their semantics are independent of pricing, although I don’t know if we can say that this is always feasible.
Moreover, if we want to truly explore the scalability design space we have to consider that some chains will have entirely different cost models, and this has to be reflected in opcode pricing. For example, there is no reason to think a zkEVM should be priced the same as e.g. geth, given that it runs on a completely different “substrate”.
Just as an example (a test contract) where “We should expect smart contract developers to know by now to design their contracts in a way that their semantics are independent of pricing” does not hold: seaport/ExcessReturnDataRecipient.sol. If memory expansion costs change (even though it hasn’t changed since the release of the Yellow Paper) there will be a problem.
Generally, with the release of Huff language and further low-level initiatives, I feel that the smart contract semantics will be dependent to a certain extent at least on the specific pricing (whether this is good or not is another question). So if we take the EVM running on Ethereum as the benchmark and the semantics can depend on the pricing, we should probably include the gas costs into the definition of EVM Equivalence.
For the scalability design space, where gas costs are not the same by design, we could define it as EVM Adherence.
Gas costs have to be able to change, as if they are too far off they are become an attack vector. And whether they are an attack vector depends, as @frangio puts it, on the “substrate”. Some systems systems might not need gas at all.