Add EIP-6269: Full EVM Equivalence

[pcaversaccio]

This meta EIP standardises the definition of "Full Ethereum Virtual Machine (EVM) Equivalence". Full EVM equivalence is the complete compliance with the latest version of the Ethereum Execution Client Specifications. This definition applies retroactively since the first release of the Ethereum Yellow Paper on 2 April 2014 (first version).

[eth-bot]

🛑 Auto merge failed. Please see logs for more details, and report this issue at the eip-review-bot repository.

[pcaversaccio]

May I ask - what's the preferred way to link the Ethereum Yellow Paper in the EIP? Currently, the CI throws error[markdown-rel-links]: non-relative link or image.

[lightclient]

The yellow paper is a deprecated resource, please refer to the execution-specs repository for the latest definitions of the EVM.

[pcaversaccio]

The yellow paper is a deprecated resource, please refer to the execution-specs repository for the latest definitions of the EVM.

thx - for my clarification since this EIP also refers to the past. When was the official switch date? I.e. until what date was the Yellow Paper the official resource to follow?

[pcaversaccio]

I addressed all the link issues by @Pandapip1 and also added more clarity on how this works backwards & added an additional test case.

[Pandapip1]

LGTM. Will need manual merge.

[SamWilsn]

The execution-specs and yellow paper haven't been added as permitted external resources. We'll have to follow the process in EIP-5757 if we want to allow them.

[pcaversaccio]

The execution-specs and yellow paper haven't been added as permitted external resources. We'll have to follow the process in EIP-5757 if we want to allow them.

My understanding is that the editors (not me) will need to approve the execution-specs and Yellow Paper as a permitted source, am I right? If I misunderstand the process please let me know how I can support this approval process best.

Excerpt from EIP-5757

Should the editors determine that an origin meets the requirements above, EIP-1 MUST be updated to include:

The name of the allowed origin;
The permitted markup and formatting required when referring to resources from the origin; and
A fully rendered example of what a link should look like.

[xinbenlv]

Notes from EIPIP meeting: Editors in consensus think this draft is not a fit to be standalone EIP and agree to close it unmerged.

[pcaversaccio]

For obvious reasons, I don't agree with the decision, but I do respect the decision. For that reason, I will also not propose a definition of Full Ethereum Equivalence. I would like to quickly highlight (even though it won't change the decision), why such a definition is really important. I break down in my tweet here, why the opcodes CREATE and CREATE2 of zkSync do not have the same behavior as on Ethereum. Any claim who would state that zkSync is fully EVM equivalent, would be wrong.

[xinbenlv]

@pcaversaccio that's a good point. While I don't think an EIP maybe best suitable for this use case, I do a agree it's important for people to understand if a VM (regardless of layer or zk), doens't share same behavior defined in Execution spec, shall not be "called" EVM compliant.

[github-actions]

The commit c38c853 (as a parent of e543661) contains errors.
Please inspect the Run Summary for details.

[pcaversaccio]

Right, but IMHO @xinbenlv having an "official" definition would have helped a lot (that's why I made this proposal). Right now, each project will (continue) define it in a way, that they can market their projects best. Also, if I publish this as a blog on FEM or somewhere else, it will not have the same impact. It is what is and I have to deal with that.

PS: It seems that the EIP title gets removed when a branch is deleted (which is done usually after merging or closing of PR). You should consider fixing this in the CI.

[xinbenlv]

Em... I have to say, you argument sounds convincing to me to turn netural. Let's see if this change other editors' or authors' minds so we could have a quorum to revisit.

[pcaversaccio]

In the meantime (while the other editors hopefully reflect on this EIP proposal again) I keep documenting here why this 'official' definition is needed. Yesterday, almost $2m of Ether got stuck on zkSync Era since their gas pricing is not EVM equivalent, see e.g. here:

• https://twitter.com/zksync/status/1644139364270878720
• https://twitter.com/pcaversaccio/status/1644023695596199945

However, they state here that they are an EVM-compatible ZK Rollup. They don't claim equivalence, of course! But people don't understand what equivalence, compatibility etc. really means. Any project that claims full EVM equivalence could simply refer to this EIP. Again, I'm not affiliated with any L1/L2 projects and completely impartial (Disclaimer: I just got a small amount of OP tokens via the recent retroPGF round from Optimism, which is however a recent event that not collide with the date when I opened this PR).

An EIP should also serve the community to clear up ambiguities about core terminology, and this what I want to achieve here.

[Sabnock01]

I also think it's worth mentioning re; zkSync that their bytecode specification disallows them from being EIP-1167 equivalent and is also grounds for their classification as non EVM-equivalent.

• https://twitter.com/pcaversaccio/status/1642448012193546240?s=20

[supernovahs]

I also feel there should be an official definition of Full EVM Equivalence.

[miohtama]

While it might sound good on paper, I am concerned this will ossify already old EVM technology development even more. Further, it does not matter how well we document this there will be always gotchas, tiny tiny differences that may cause problems and we might be creating a false expectation for people to do copy-paste code from one chain to another and expect to get away with it.

I would say there is

• No EVM equivalence, except for Ethereum mainnet
• • Even EVM is not equivalent with EVM, as gas costs etc. have been tweaked in 10+ hard forks since 2014
• Say there never will be EVM equivalence
• Projects are discouraged to say they are EVM compatible, by we giving them angry looks
• Always test your projects chain by chain, because there is and never will be a fully agreed definition of EVM compatible as there are always pitfalls and chains evolve
• EVM forks are already doing work to document differences - while they could do better work, I believe these practices will develop over time and there is no additional value created by trying to formalise the concept - better use this energy somewhere else like actually improving the existing documentation in different projects

[pcaversaccio]

Em... I have to say, you argument sounds convincing to me to turn netural. Let's see if this change other editors' or authors' minds so we could have a quorum to revisit.

@xinbenlv Any update on whether there is a quorum to revisit this EIP draft? Again, I wouldn't push this hard if I thought it was not a value-add for the entire ecosystem. Official definitions provide the necessary orientation that many people need in our space.

[pcaversaccio]

Another situation we are in right now is where such a definition is very helpful. There are numerous chains that do not support currently the latest EVM version shanghai with the opcode PUSH0. This means that, for example, the use of the latest Solidity version 0.8.20, which supports PUSH0, will likely fail with these chains (if it includes PUSH0 in the init code and gets executed at creation time, the deployment fails; if the runtime code has PUSH0 and is not executed as part of the deployment, the runtime code can revert on calls) and thus these chains can no longer be considered fully EVM-equivalent.

[pcaversaccio]

Let me follow up here on community support on this EIP (by @Sabnock01 and @devanoneth):

• https://twitter.com/devanoneth/status/1661720111827279872
• https://twitter.com/Sabnock66/status/1661465202850689027

@xinbenlv, @lightclient, @SamWilsn, @Pandapip1 I would appreciate if you could re-consider this EIP since it's really really relevant.

[xinbenlv]

Yes, given the context of zkEVM, I think it's worthy to reopen this discussion about defining what's considered "EVM compliance"

Also we shall discuss it to be whether an informational or meta EIP?

[kdenhartog]

Here's an alternative method you might want to consider @pcaversaccio. Have you thought about getting this term defined within the execution specs rather than as a separate EIP? Also, given the examples you're using here I think what you'd actually want is something more than just a definition on paper. Instead, it would be much more useful for developers to recognize this compatibility based on a test suite. This is very common at W3C and WHATWG and every web platform API is meant to also have a defined set of tests to be added to the test suite when it gets standardized. This could be very useful as a method to achieving code equivalence or making it much easier to distinguish where implementations actually differ. For example, here's a giant list of all the Web platform tests on how browsers differ currently.

[pcaversaccio]

Here's an alternative method you might want to consider @pcaversaccio. Have you thought about getting this term defined within the execution specs rather than as a separate EIP?

Thanks for sharing your thoughts @kdenhartog. The main reason why I think an EIP is the best place for such a definition is its canonical acceptance and the broader reach beyond tech-savvy people. It is very important to eliminate ambiguities across different groups of people (engineering, marketing, etc.) and an EIP is the best way to achieve this IMHO.

Also, given the examples you're using here I think what you'd actually want is something more than just a definition on paper. Instead, it would be much more useful for developers to recognize this compatibility based on a test suite. This is very common at W3C and WHATWG and every web platform API is meant to also have a defined set of tests to be added to the test suite when it gets standardized. This could be very useful as a method to achieving code equivalence or making it much easier to distinguish where implementations actually differ. For example, here's a giant list of all the Web platform tests on how browsers differ currently.

Good point - there are test suites here or here that are also used by other projects (e.g. Polygon) to test EVM equivalence, BUT, my definition is to be understood as formal in the sense that it does not assume that the test suite is always up to date and that the test suite always covers 100% of the execution specs. There is only one source of truth and that is the Ethereum execution specifications.

[gcolvin]

Late to this party, but this has become relevant to my paid work. The abstract states that

Full EVM equivalence is the complete compliance with the latest version of the Ethereum Execution Client Specifications.

For better and worse this already is the current definition, and doesn't need an EIP to say so. And the executable spec already contains code for all previous upgrades, so there is no need for an EIP to discuss that either.

What is more of a problem is less-than-full compliance. Vendors can already describe this in terms of the upgrade level they are up too, the EIPs they omit, the opcodes they don't implement, the extensions they make, and the versions of Solidity (if any) they can accept code from. If all of this becomes enough of problem for the industry, and people want to use the EIP process to deal with it, then they can form working group to create relevant ERCs.

For our project we would need only the computational subset of the EVM -- no introspection or message calls. We would extend the EVM with EIP-2315, as we can't wait on EOF to be able to generate machine code. We would add our own "pre-compiles" for communication with the rest of our system. And we would extend Vyper (with or without their help) to generate code for our custom EVM. I don't know if there are enough other projects doing similar things that it would be worth forming a working group to coordinate -- but right now our project has seed capital and hard deadlines.