Feedback on the EIP draft:
Do you intent to capture the meaning of the whole EL, or just the EVM? From this magicians post I see you also mention “Ethereum Stack compatibility”, but the EIP completely ignores that.
The Ethereum Execution Layer as defined in the execution specs encompasses more than just the EVM. It includes the EVM as one of its main features.
The transaction-types are not strictly part of the EVM. In go-ethereum for example the transaction-types are abstracted into a generic
Message before being applied to the EVM, and no tx-typing can be introspected by the EVM.
Yet, the equivalence of tx-encoding and signing with L1 mainnet is still a requirement for a significant part of existing ethereum tooling to work out of the box on alternative networks, something some ZK rollups that claim EVM-equivalence don’t support. This is worth highlighting in the EIP.
Another part that’s not technically “EVM” but definitely part of the EL specs is the state-trie-format: L1 uses an account model backed by a Merkle-Patricia-Trie. Is this part of EVM equivalence? Probably not, but by just pointing at the EL specs it appears as if it is. And many ZK-rollups choose an alternative ZK-friendly state format anyway. And mainnet L1 may change it in the next few years to Verkle trees.
And although event-logs are part of the EVM, tx-receipts are not; they are part of the EL storage format and only referenced in the block-header. Are these included in EVM equivalence?
And then comes the execution-layer RPC APIs, which are an expectation around the EL and specified too: GitHub - ethereum/execution-apis: Collection of APIs provided by Ethereum execution layer clients Are these part of EVM equivalence? I would say no, but also worth calling out, as again A LOT of tooling depends on these, and this includes EVM-traces!
I would define “EVM equivalence” as conformance to the processing of a single abstracted transaction onto an abstracted accounts-state and conforming to all mainnet L1 EVM features: EVM-context (memory, callstack, stack, gas, etc.), instructions and precompiles.
And a mention of the origin of the term “EVM equivalence” would be appropriate: it’s was not the ZK-EVMs who first popularized the meaning. Optimism has posted about the difference with “EVM compatibility” and “EVM equivalence” as early as in Sept 17 2021: The Future of Optimistic Ethereum | by Optimism | Optimism PBC Blog | Medium and described it as “By precisely enforcing the Ethereum Yellow Paper” (which at the time of the post was more of a canonical source for EVM spec, this was pre-Merge and pre-EL-specs readiness). And Optimism then introduced it in more detail on Oct 26 2021: Introducing EVM Equivalence. Or, Ethereum All the Way Down: How We… | by Optimism | Optimism PBC Blog | Medium and followed up with an upgrade end 2021 dedicated to these described changes.
L2 users expect tx-typing & state format & receipts & RPCs to also be there, so I support the definition of something like “Ethereum Stack Compatibility”, although it definitely needs more detail. Does this include consensus part of the stack with proof-of-stake? That too has formatted blocks, state, APIs, etc.
And FWIW, Optimism is nearing its launch of Bedrock, which will go far beyond EVM-equivalance to fully include all of these non-EVM Ethereum features, by using the Engine API and almost using Geth as-is, with the exception of minor additions to function as a rollup at all (deposit-tx type, payment for L1-data usage, and ability to reproduce exact blocks from inputs only with engine API). And with multi-client support planned as well (already have an Erigon prototype). By using this API and Geth and other clients with so few modifications, you could maybe even call it “ethereum stack equivalence” instead of just “ethereum stack compatibility”