Contention of Phoenix (new)

During the final review period of the hard fork, Phoenix (new) has received several criticism, resulting in some Ethereum Classic users strongly opposing it. This document is to record the issue and present arguments from both sides of the contention. The primary goal is to try and see if the issues of this contentious hard fork can be resolved. If not, we hope this can act as a guide for users to decide which side they want to be on.

Contention of Phoenix (new)
Consensus fork supplementary
ForkPhoenix (new)
Ethereum family

OpenEthereum and MultiGeth support both sides of the hard fork. The flag for running pro-Phoenix-fork side remains the same as before. For non-fork side, OpenEthereum supports it through the --chain classic-oppose-phoenix-fork flag, and MultiGeth supports it through flag --oppose-phoenix-fork.

Pro-Phoenix side

The main argument from pro-Phoenix hard fork side is that the hard fork has received "rough consensus", and as a result, any divergence of the hard fork can result in chain splits, which is bad for Ethereum Classic community.

  •   Argument Phoenix hard fork has received "rough consensus".[1]
    •   Objection The hard fork should be marked as contested. Some core developers have clearly expressed the understanding that some groups do not agree with the way everything has been handled.[2]
    •   Objection Even according to ECIP guidelines[3], rough consensus requires that a specification not have any "unaddressed substantiated objections". With several unaddressed issues and potential design flaws, Phoenix does not satisfy the criteria.
  •   Argument Non-fork side is "coordinated social attack". Opposing the hard fork can result in chain split.

Non-fork side

The non-fork side mainly argues that Phoenix hard fork breaks Ethereum Classic principles of immutability and code-is-law, and has several unaddressed issues which may cripple the chain in the future.

  •   Argument Phoenix hard fork breaks immutability and code-is-law principle of Ethereum Classic.
    •   Argument From analysis by Contract Library, due to EIP-1884, Phoenix will break around ~100 ETC of smart contracts with probability, and ~0.003 ETC of smart contracts with certainty.[4]
      •   Argument Those contracts broken by Phoenix are not dapp developers' fault. Platforms we use to develop smart contracts (mainly Solidity) have been inevitably making assumptions about gas costs for a long time, including many default and frequently used functions. To many extends, those contracts broken by Phoenix were indeed following the best practices of dapp development at the time it was deployed.[5]
      •   Objection Compensations can be manually given to contract owners from Community Fund to resolve this issue.[6]
      •   Objection In the past, we already have potentially broke backward compatibility, in Homestead, ECIP-1015 and ECIP-1054.
        •   Objection Backward compatibility should be maintained with best efforts. It was not known whether any contracts have actually been broken in past hard forks. However, in Phoenix, we do know it.
        •   Objection Making mistakes in the past and accidentally breaking principles does not entitle to do it again in the future.
    •   Argument Phoenix leads to future backward compatibility issues because of the CHAINID opcode.
      •   Argument This will make the chain difficult to ever change chain ID again. This is a potential vulnerability because in the situation of chain split, both chains will not want to be the one changing the chain ID, leading to much longer period of replay attack.
      •   Argument This will make the chain difficult to have multiple chain IDs. In a hypothetical situation, if both Phoenix side and non-fork side exists after the hard fork, then the non-fork side will have an enormous political advantage in terms of two chains sharing the network and replay attacks. Non-fork side can support multiple chain IDs, so it can fixes its problem immediately, while also maintain backward compatibility (transactions using old chain ID will still be valid). However, Phoenix side will not only be hesitant to change chain ID (because it breaks backward compatibility), but also, when it changes chain ID, the change will have logistic hazards in that transactions before the "cut point" will not be valid.
  •   Argument Several other unaddressed security issues are still left unaddressed in Phoenix hard fork.
    •   Argument Many of the parameters of Phoenix are inherited from Istanbul, the Ethereum hard fork. The parameters are calibrated for Ethereum, and there is little analysis to see whether they fit Ethereum Classic. Analysis of EIP-1108, EIP-1884 and EIP-2028 all use data directly from Ethereum blockchain.[7]
    •   Argument Phoenix will increase block size, and add up to storage requirements. This can lead to increased difficulty in running full nodes.[8][9]
    •   Argument The impact of gas cost reduction of BN128 precompile is still left unaddressed. Unhandled, it can lead to DoS attack vector.[10]