-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP-6269: Full EVM Equivalence #6269
Closed
+69
−0
Closed
Changes from 5 commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
2e8601d
📝 Informational EIP on full EVM equivalence
pcaversaccio 47050e5
♻️ remove quotation marks
pcaversaccio bfd99f3
Assign number 6269 and fix external link issue
Pandapip1 da87c92
Replace yellow paper with execution specs
Pandapip1 08d9bed
Update EIPS/eip-6269.md
pcaversaccio ab9b87c
adjust links & wording
pcaversaccio d3aa0ad
amendments
pcaversaccio 61785fd
wording
pcaversaccio c38c853
change type to informational
pcaversaccio File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,58 @@ | ||
| --- | ||
| 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-and-ethereum-stack-compatibility-definition-future-informational-eip/10044 | ||
| status: Draft | ||
| type: Meta | ||
| created: 2023-01-06 | ||
| --- | ||
|
|
||
| ## Abstract | ||
|
|
||
| This EIP standardises the definition of "Full Ethereum Virtual Machine (EVM) Equivalence". Full EVM equivalence is **complete** compliance with the latest version of the [Execution Layer Specification](https://github.com/ethereum/execution-specs/tree/24de2192e02bba11e61746aa9dee04d4e7a8b62e). This definition applies retroactively from the first release of the Ethereum Yellow Paper in April 2014. | ||
pcaversaccio marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## 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 | ||
|
|
||
| Any protocol, network, smart contract system, or similar that claims at time `t` full EVM equivalence MUST fully (=100%) comply with the latest [Execution Layer Specification](https://github.com/ethereum/execution-specs/tree/24de2192e02bba11e61746aa9dee04d4e7a8b62e) version at time `t`. | ||
|
|
||
| ## Rationale | ||
|
|
||
| A proper equivalence definition requires a common, publicly available reference that specifies the formal specification of the equivalence. The [Execution Layer Specification](https://github.com/ethereum/execution-specs/tree/24de2192e02bba11e61746aa9dee04d4e7a8b62e) 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. | ||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| This proposal is fully backward compatible until the first release of the Ethereum Yellow Paper in April 2014. | ||
|
|
||
| ## Test Cases | ||
|
|
||
| ### Example 1 ✅ | ||
|
|
||
| _Assumption:_ A protocol `X` follows at time `t` all the specifications stated in the Ethereum Yellow Paper at time `t`. | ||
|
|
||
| > Protocol `X` is fully EVM equivalent. | ||
|
|
||
| ### Example 2 ❌ | ||
|
|
||
| _Assumption:_ A protocol `X` follows at time `t` all the specifications stated in the Ethereum Yellow Paper at time `t` _except_ using the similar pricing for zero and non-zero byte of data. | ||
|
|
||
| > Protocol `X` is **not** fully EVM equivalent. | ||
|
|
||
| ### Example 3 ❌ | ||
|
|
||
| _Assumption:_ A protocol `X` follows at time `t` all the specifications stated in the Ethereum Yellow Paper at time `t` _except_ that the opcode `SELFDESTRUCT` does not destroy any storage. | ||
|
|
||
| > Protocol `X` is **not** fully EVM equivalent. | ||
|
|
||
| ## 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). | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be type informational
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My original draft was of type informational, @Pandapip1 suggested the meta type #6269 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think that is the correct type. Meta is used for processes around Ethereum which require consensus like the EIP process, hard forks, testnets, etc. This EIP is unenforceable (but still useful from an informational standpoint) and so I think this is the correct type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the question is about whether it can be ignored or not - imho it should not be ignored (otherwise my initiative is somehow useless). And if I understand correctly, an informational EIP can be ignored whilst a meta EIP cannot be ignored. Not sure what's the approach here to find a consensus but I want to clearly define a very important semantics that cannot be simply ignored by the community...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not enforceable, but it's nonetheless not an EIP that can be ignored. Defining something, IMO, is Meta, while describing an aspect of something is Informational.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please review the EIPs that are classified as "Meta" and then review the EIPs that are classified as "Informational". This EIP is an Informational EIP because it does not affect anything related to Ethereum "process" (again, see definition of meta type in EIP-1). It is providing a definition for a term to the community, not proposing any new feature or process change, and is advisable to follow, but is not enforceable.