Pre-RFC: Phoenix backward compatibility promise

[sorpaas]

Assigned Number: 3-etc-compatibility-promise
Discussions: https://discord.gg/BdRSvJD

Phoenix is a planned hard fork on Ethereum Classic happening in June 2020. Recent Phoenix pre-RFC revealed several unresolved concerns of the hard fork. In particular, the hard fork contains a backward incompatible change that can result in broken on-chain smart contracts or even lost funds.

While after persuasion, supporters of Phoenix agreed to carry out an impact analysis on backward compatibility, they have so far refused to make the same backward compatibility promise as it was done on Ethereum mainnet. This effectively leaves all burdens of smart contract re-audit responsibility to dapp developers and Ethereum Classic users, in the event if the impact analysis missed some smart contracts, or if the impact analysis is not properly done.

Backward compatibility is an important aspect of Ethereum Classic's "Code is Law" and "Immutability" philosophy. As a result, given the potential problems of Phoenix hard fork, the responsible action for MultiGeth, and for Ethereum Classic's RFC process, is to commit a backward compatibility promise.

Specification

In the event that the hard fork goes live with an unexpected backward incompatibility issue, this RFC proposes to support another protocol upgrade to rescue those smart contracts broken by Phoenix hard fork.

[gitr0n1n]

This RFC does NOT have factual evidence. There was NEVER a promise by the ETH core devs to fix anything.

Per review:
It appears there was never a "promise" and one person thought there might be "internal consensus" in his opinion. But that was immediately disproven by objections. So not sure this RFC has merit in a factual sense.

https://gitter.im/ethereum/AllCoreDevs?at=5db2a08cfb4dab784a00daa8

[sorpaas]

Just for context -- people who argued for the "promise" in ETH core devs are Martin (Geth) and Hudson (EF), and against are mostly just me (Parity), Tim (EthCatHerders), and Micah. That was why this was at least considered an implicit "promise" during Istanbul.

[gitr0n1n]

After personal review, ETC precedence related to this RFC's topics:

• "the hard fork contains a backward incompatible change that can result in broken on-chain smart contracts or even lost funds."
  -- this occurred in ECIP-1015 and ECIP-1054. there is precedent to this type of upgrade.

• "supporters of Phoenix agreed to carry out an impact analysis on backward compatibility"
  -- no impact analysis was preformed for upgrade ECIP-1015 or ECIP-1054. There is no expectation of an impact analysis. If a team has committed to an impact analysis, it is outside of the scope of the core dev teams obligations and a courtesy to the requester.
  -- For specifics, I believe Multi-Geth's sorpaas was the requester and ETC Coop's Bob Summerwill obiliged the request. Again, there is no precedent that this impact analysis is a requirement for an upgrade to move forward.

• " As a result...the responsible action for MultiGeth...is to commit a backward compatibility promise."
  -- This is a promise informally proposed by Multi-Geth and accepted by Multi-Geth only at this point. They are free to commit their resources however they would like, ETC is permissionless. Again, there is no ECIP related to this commitment as far as I can see.

Note:
Opinions are my own, formed from researching the source documents. Please do your own research.