Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions EIPS/eip-6269.md
Original file line number Diff line number Diff line change
@@ -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
Comment thread
pcaversaccio marked this conversation as resolved.
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).
Comment thread
pcaversaccio marked this conversation as resolved.

## 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).