-
Notifications
You must be signed in to change notification settings - Fork 8
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #10 from etclabscore/s1-ecip-byzantium
ECIP-1054: Support for ETH Byzantium EVM and Protocol Upgrades
- Loading branch information
Showing
1 changed file
with
92 additions
and
0 deletions.
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,92 @@ | ||
| ### ECIP-1054: Atlantis EVM and Protocol Upgrades | ||
|
|
||
| ECIP: 1054 | ||
| Title: Atlantis EVM and Protocol Upgrades | ||
| Status: Draft | ||
| Type: Standards Track | ||
| Author: Isaac Ardis <[email protected]> | ||
| Created: 2019-02-11 | ||
|
|
||
| ### Simple Summary | ||
|
|
||
| Enable the outstanding Ethereum Foundation _Spurious Dragon_ and _Byzantium_ network protocol upgrades on the Ethereum | ||
| Classic network in a hard-fork code-named _Atlantis_ to enable maximum compatibility across these networks. | ||
|
|
||
| ### Abstract | ||
|
|
||
| Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the | ||
| _Spurious Dragon_ and _Byzantium_ hardforks. The proposed changes for Ethereum Classic's _Atlantis_ upgrade include: | ||
|
|
||
| - Spurious Dragon state-trie clearing. | ||
| - Spurious Dragon contract-code size limit. | ||
| - Byzantium EVM opcodes, namely `REVERT`, `RETURNDATASIZE`, `RETURNDATACOPY`, and `STATICCALL`. | ||
| - Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve `alt_bn128`, | ||
| optimal ate pairing check on the elliptic curve `alt_bn128`, and BIGINT modular exponentiation. | ||
| - Replacing the intermediate state root field in transaction receipts with the contract return status. | ||
| - Change difficulty adjustment to target mean block time including uncle. | ||
|
|
||
| This document proposes the following blocks at which to implement these changes in the Classic networks: | ||
|
|
||
| - `1_039_000` on Kotti Classic PoA-testnet (early August 2019) | ||
| - `4_723_000` on Morden Classic PoW-testnet (early August 2019) | ||
| - `8_750_000` on Ethereum Classic PoW-mainnet (mid-September 2019) | ||
|
|
||
| For more information on the opcodes and their respective EIPs and implementations, please see the _Specification_ | ||
| section of this document. | ||
|
|
||
| ### Motivation | ||
|
|
||
| To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes and precompiled contracts shall be added | ||
| to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. | ||
| Adoption of the _receipt status_ feature provides a helpful method for decentralized-application developers to access | ||
| the successful or failed state of a contract. This would establish a higher level of interoperability between Foundation | ||
| and Classic EVMs, and make a more extensive array of tooling available for the ETC network (e.g., Solidity version, | ||
| contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment | ||
| algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable | ||
| issuance rate that cannot be manipulated upward by manipulating the uncle rate. | ||
|
|
||
| ### Specification | ||
|
|
||
| Technical specifications for each EIP can be found at those documents respectively: | ||
|
|
||
| - [EIP 100](https://eips.ethereum.org/EIPS/eip-100) (Change difficulty adjustment to target mean block time including uncles) | ||
| - [EIP 140](https://eips.ethereum.org/EIPS/eip-140) (`REVERT` instruction in the Ethereum Virtual Machine) | ||
| - [EIP 161](https://eips.ethereum.org/EIPS/eip-161) (State-trie clearing) | ||
| - [EIP 170](https://eips.ethereum.org/EIPS/eip-170) (Contract-code size limit) | ||
| - [EIP 196](https://eips.ethereum.org/EIPS/eip-196) (Precompiled contracts for addition and scalar multiplication on the elliptic curve `alt_bn128`) | ||
| - [EIP 197](https://eips.ethereum.org/EIPS/eip-197) (Precompiled contracts for optimal ate pairing check on the elliptic curve `alt_bn128`) | ||
| - [EIP 198](https://eips.ethereum.org/EIPS/eip-198) (Precompiled contract for BIGINT modular exponentiation) | ||
| - [EIP 211](https://eips.ethereum.org/EIPS/eip-211) (New opcodes `RETURNDATASIZE` and `RETURNDATACOPY`) | ||
| - [EIP 214](https://eips.ethereum.org/EIPS/eip-214) (New opcode `STATICCALL`) | ||
| - [EIP 658](https://eips.ethereum.org/EIPS/eip-658) (Embedding transaction status code in receipts) | ||
|
|
||
| ### Rationale | ||
|
|
||
| __Atomicity__: This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ | ||
| protocol upgrade, which would be expected to include various further EVM upgrades. This allows for dedicated testing of | ||
| the proposed changes in light of multiple delays of the Constantinople fork | ||
| ([a postmortem of the latest delay](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d)). | ||
|
|
||
| __Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is essential for | ||
| developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden, | ||
| Görli and Kotti). | ||
|
|
||
| __Immutability__: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing | ||
| contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of | ||
| them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes and precompiled | ||
| contracts to the EVM increases its functionality and should be considered a feature upgrade rather than a modification. | ||
|
|
||
| ### Implementation | ||
|
|
||
| Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible. | ||
|
|
||
| The following clients with Ethereum Classic support implement the _Spurious Dragon_ and _Byzantium_ features currently: | ||
|
|
||
| - Geth Classic: partial support for EIP-658 receipt status code change | ||
| - Parity Ethereum: all features due to Ethereum Foundation compatibility | ||
| - Multi Geth: all features due to Ethereum Foundation compatibility | ||
| - Mantis: all features due to Ethereum Foundation compatibility | ||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |