Add EIP-6269: Full EVM Equivalence

EIPS/eip-6269.md

@@ -0,0 +1,69 @@
+---
+eip: 6269
+title: Full EVM Equivalence
+description: Canonicalise the definition of Full EVM Equivalence
+author: Pascal Caversaccio (@pcaversaccio)
+discussions-to: https://ethereum-magicians.org/t/evm-equivalence-eip-6269-and-ethereum-stack-compatibility-definition/10044
+status: Draft
+type: Informational
+created: 2023-01-06
+requires: 5757
+---
+
+## Abstract
+
+This 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](https://github.com/ethereum/execution-specs/tree/79db92bd4c49bdf5f559fdebea5a9a3a2bf3fb83). This definition applies retroactively since the first release of the [Ethereum Yellow Paper](https://github.com/ethereum/yellowpaper/blob/1016c0603062b76388e3c3c19786cd5f9ca9ac61/paper.pdf) on 2 April 2014 ([first version](https://github.com/ethereum/yellowpaper/blob/0d0d23301d077bbdab5cafae6ab06001e282fae2/Paper.tex)).
+
+## Motivation
+
+In light of the recent zkEVM announcements by various projects and the ongoing discussion, confusion, and ambiguity about how **full** EVM equivalence is defined, we define a canonical definition to foster a common understanding of the term "Full EVM Equivalence".
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+Any protocol, network, smart contract system, or similar that claims at time `t` full EVM equivalence **MUST** fully (=100%) comply with the latest [Ethereum Execution Client Specifications](https://github.com/ethereum/execution-specs/tree/79db92bd4c49bdf5f559fdebea5a9a3a2bf3fb83) version at time `t`. For any time `t` before 6 September 2022 (Bellatrix hard fork date), the **REQUIRED** reference source is the [Ethereum Yellow Paper](https://github.com/ethereum/yellowpaper/blob/1016c0603062b76388e3c3c19786cd5f9ca9ac61/paper.pdf). The first public version of the Ethereum Yellow Paper is available at commit [`0d0d23301d077bbdab5cafae6ab06001e282fae2`](https://github.com/ethereum/yellowpaper/blob/0d0d23301d077bbdab5cafae6ab06001e282fae2/Paper.tex).
+
+## Rationale
+
+A proper equivalence definition requires a common, publicly available reference that specifies the formal specification of the equivalence benchmark. The [Ethereum Execution Client Specifications](https://github.com/ethereum/execution-specs/tree/79db92bd4c49bdf5f559fdebea5a9a3a2bf3fb83) formulates the formal specification of the Ethereum protocol, which is publicly available and serves as a common reference for all protocols, networks, smart contract systems, or the like that aim to build similar implementations.
+
+Prior to the Bellatrix hard fork on 6 September 2022, the [Ethereum Yellow Paper](https://github.com/ethereum/yellowpaper/blob/1016c0603062b76388e3c3c19786cd5f9ca9ac61/paper.pdf) was considered more complete and is therefore chosen as the main reference point.
+
+## Backwards Compatibility
+
+This proposal is fully backward compatible up to the the first release of the [Ethereum Yellow Paper](https://github.com/ethereum/yellowpaper/blob/1016c0603062b76388e3c3c19786cd5f9ca9ac61/paper.pdf) on 2 April 2014.
+
+## Test Cases
+
+### Example 1 ✅
+
+_Assumption:_ A protocol `X` follows at time "`t` >= 6 September 2022" all the specifications stated in the Ethereum Execution Client Specifications at time `t`.
+
+> Protocol `X` is fully EVM equivalent at time `t`.
+
+### Example 2 ❌
+
+_Assumption:_ A protocol `X` follows at time "`t` >= 6 September 2022" all the specifications stated in the Ethereum Execution Client Specifications at time `t` _except_ using the similar pricing for zero and non-zero byte of data.
+
+> Protocol `X` is **not** fully EVM equivalent at time `t`.
+
+### Example 3 ❌
+
+_Assumption:_ A protocol `X` follows at time "`t` >= 6 September 2022" all the specifications stated in the Ethereum Execution Client Specifications at time `t` _except_ that the opcode `SELFDESTRUCT` does not destroy any storage.
+
+> Protocol `X` is **not** fully EVM equivalent at time `t`.
+
+### Example 4 ✅
+
+_Assumption:_ A protocol `X` followed at time "`t` < 6 September 2022" all the specifications stated in the Ethereum Yellow Paper at time `t`. Due to a protocol change at time `t + T`, the protocol additionally supports a transient opcode.
+
+> Protocol `X` was fully EVM equivalent at time `t`. Protocol `X` is **not** fully EVM equivalent at time `t + T`.
+
+## Security Considerations
+
+There are no security considerations directly related to the definition of "Full EVM Equivalence".
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).