Principle of backward compatibility in Phoenix (new)

From Consensus Paper
Jump to navigation Jump to search
Principle of backward compatibility in Phoenix (new)
Consensus fork supplementary
TypePrinciple promise
ForkPhoenix (new)
Ethereum family

Phoenix (new) 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 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, this specification documents a principle promise of backward compatibility.

Specification[edit | edit source]

In the event that the hard fork goes live with an unexpected and uncontrollable backward incompatibility issue, emergency hard forks may be enacted to rescue those smart contracts broken by Phoenix hard fork. Below we list several potential methods to do this.

Disable EIP-1884[edit | edit source]

Based on Phoenix, do the following changes:

  • Disable EIP-1884 and EIP-2200.
  • Enable EIP-1283 with EIP-1706.
  • Enable 50-SELFBALANCE.

Reduce cost of LOG operation[edit | edit source]

Most contract breakage of Phoenix will be due to combination of LOG and SLOAD opcodes. Reducing LOG opcode gas cost may fix majority of the issues.

  • Reduce LOG_BASE_GAS, LOG_TOPIC_GAS and LOG_DATA_GAS to new specified values.