Phoenix Hard-fork to occur at the same block as Aztlan - to "fix it"

_specs/ecip-1078.md

@@ -0,0 +1,107 @@
+---
+lang: en
+ecip: 1078
+title: Phoenix EVM and Protocol Upgrades
+author: Bob Summerwill (@bobsummerwill)
+status: Draft
+type: Meta
+created: 2020-01-19
+license: Apache-2.0
+discussions-to: https://github.com/ethereumclassic/ECIPs/issues/262
+---
+
+### Simple Summary
+
+This ECIP describes a hard-fork which would occur at the same block as
+[ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition)](https://ecips.ethereumclassic.org/ECIPs/ecip-1061) 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](https://github.com/ethereumclassic/ECIPs/issues/177) 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](https://github.com/sorpaas)'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](https://specs.corepaper.org/49-aztlanfix).
+
+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:
+
+- `778_507` on Mordor Classic PoW-testnet (Feb 5th, 2020)
+- `2_058_191` on Kotti Classic PoA-testnet (Feb 12th, 2020)
+- `10_500_839` on Ethereum Classic PoW-mainnet (March 25th, 2020)
+
+After HARD_FORK_BLOCK, apply the following changes:
+
+- Disable [EIP-2200](https://eips.ethereum.org/EIPS/eip-2200)
+- Enable [EIP-1283](https://eips.ethereum.org/EIPS/eip-1283) with [EIP-1706](https://eips.ethereum.org/EIPS/eip-1706) instead.
+- Enable [ECIP-1080](https://github.com/ethereumclassic/ECIPs/issues/266)
+
+
+### Rationale
+
+[ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition)](https://ecips.ethereumclassic.org/ECIPs/ecip-1061) 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](https://eips.ethereum.org/EIPS/eip-1884) for
+the original rationale for the gas-repricings for ETH.
+
+These changes are sensible, but they [broke 680 deployed Aragon smart contracts](https://www.coindesk.com/ethereums-istanbul-upgrade-will-break-680-smart-contracts-on-aragon) 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](https://ecips.ethereumclassic.org/ECIPs/ecip-1015), which has ETC's equivalent to [ETH Tangerine Whistle](https://eips.ethereum.org/EIPS/eip-608),
+with both chains implementing [EIP 150: Gas cost changes for IO-heavy operations](https://eips.ethereum.org/EIPS/eip-150).
+
+
+### 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](https://eips.ethereum.org/EIPS/eip-1706), but it is a very simple change, analogous to [EIP-2200](https://eips.ethereum.org/EIPS/eip-2200), which all the
+codebases have already implemented.
+
+Similarly [ECIP-1080](https://github.com/ethereumclassic/ECIPs/issues/266) 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](https://www.apache.org/licenses/LICENSE-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.
+