ECIP 1078: Phoenix EVM and Protocol Upgrades ("Aztlán fix")
| Author | Bob Summerwill |
|---|---|
| Discussions-To | https://github.com/ethereumclassic/ECIPs/issues/262 |
| Status | Rejected |
| Type | Meta |
| Created | 2020-01-19 |
Simple Summary
This ECIP describes a hard-fork which would occur at the same mainnet block as ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) to “fix” two issues with ECIP-1061 where the written specification did not match the original intent.
Abstract
The network participants who took part in the ETC Core Developers call on 27th November 2019 were under the impression at the time that the scope we agreed (“Instanbul without the backward-compatibility breaking parts of EIP-1884”) - ECIP-1061 / ECIP-1072 - would move the ETC protocol to a place where it was 100% compatible with the ETH mainnet.
Wei Tang’s implementation of ECIP-1061 shortly afterwards revealed two flaws in the specification, together with recommendations on how to address those shortcomings.
This ECIP codifies those recommendations.
Both hard-forks would be activated at the same block and the combination of both sets of changes would result in protocol changes which met the original intent.
Specification
This document proposes the following blocks at which to implement these changes in the Classic networks:
976_231on Mordor Classic PoW-testnet (approx March 4th, 2020)2_208_203on Kotti Classic PoA-testnet (approx March 11st, 2020)10_500_839on Ethereum Classic PoW-mainnet (approx June 10th, 2020)
At HARD_FORK_BLOCK, apply the following changes:
Rationale
ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) as defined is “broken” and it would be inadvisable to activate on the ETC mainnet in its current state.
See EIP 1884: Repricing for trie-size-dependent opcodes for the original rationale for the gas-repricings for ETH.
These changes are sensible, but they broke 680 deployed Aragon smart contracts along with various other deployed smart contacts by applying the repricings retroactively and unconditionally.
The new SELFBALANCE opcode does not break backwards compatibility. For compatibility with ETH it is both necessary and desirable.
Short of imminent and catatrophic danger to the ETC network, making retroactive changes which break backwards compatibility is counter to ETC values and philosophy.
Gas-repricings to balance EVM gas prices with real world resource usage is entirely rational and is happening on the ETC protocol too, but will be done in a backwards-compatible ways wherever possible. Unconditional retroactive (“emergency”) repricings would only happen when the network has been halted or has been rendered unusable.
An example of such a situation occurred following the Shanghai attacks on ETH and ETC networks:
ECIP 1015: Long-term gas cost changes for IO-heavy operations to mitigate transaction spam attacks, which has ETC’s equivalent to ETH Tangerine Whistle, with both chains implementing EIP 150: Gas cost changes for IO-heavy operations.
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 Istanbul features currently:
- Parity Ethereum
- Multi-Geth
- Hyperledger Besu
The author is unaware if any of these clients have implemented EIP-1706, but it is a very simple change, analogous to EIP-2200, which all the codebases have already implemented.
Similarly ECIP-1080 has not been implemented in any of these codebases, but is just a “remix” of code which they have already implemented.
Copyright
This proposal is licensed under the Apache License, Version 2.0, based on specifications developed by Wei Tang within the Core Paper project (https://corepaper.org/).
Core Paper Copyright 2019-2020 Wei Tang.
Bob Summerwill, the author of this proposal attests that his is the sole author of this specific document based on Wei Tang’s work and that he is able to contribute this work to the ECIP process under the Apache 2.0 licence. He further attests that he neither holds nor is aware of any patents, trademarks, copyright issues or other IP hinderances associated with this work.