Phoenix (new)

From Consensus Paper
Jump to navigation Jump to search
Consensus upgrade
TypeHard fork
StatusPlanned, Contentious[1]
RFCsMultiGeth RFC
Ethereum family

Phoenix EVM and Protocol Upgrades (ECIP-1088, RFC-2) is a planned hard fork on Ethereum Classic, in replacement of Aztlán EVM and Protocol Upgrades (Yingchun Edition) (ECIP-1061) and Phoenix EVM and Protocol Upgrades ("Aztlán fix") (ECIP-1078).[2]

Specification[edit | edit source]

Enable the following EIPs:

  • EIP-152: Add Blake2 compression function F precompile
  • EIP-1108: Reduce alt_bn128 precompile gas costs
  • EIP-1344: Add ChainID opcode
  • EIP-1884: Repricing for trie-size-dependent opcodes
  • EIP-2028: Calldata gas cost reduction
  • EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

Supplementary[edit | edit source]

Hard fork[edit | edit source]

The hard fork is planned on June 10th, 2020 (at block 10,500,839).

For testnet activation, it's activated on Mordor testnet at block 999,983, and is planned to be activated on Kotti testnet at block 2,200,013.

Review[edit | edit source]

Backward compatibility impact analysis[edit | edit source]

  • ConsiderationThere is formal request for an impact analysis in the RFC process as in RFC-2.[3]

Given that EIP-1884 broke a number of on-chain real smart contracts for Ethereum mainnet, it may also break contracts on Ethereum Classic. Analysis on the impact of backward compatibility was properly done for Ethereum[4]. However, the same analysis has not yet been done on Ethereum Classic.

Public awareness of backward incompatibility[edit | edit source]

  • Unaddressed issueThis concern is not yet fully addressed. The public outreach project still have a lot of backfill and is still work-in-progress.

Discussions with Phoenix supporters also revealed that there has not been public awareness program planned for the breakage of backward compatibility.[5] As a result, the burden is left on Ethereum Classic users and dapp developers.

Promise to backward compatibility support for dapp developers[edit | edit source]

  • ConsiderationThe promise for ETC is formalized in RFC process as in RFC-3.[6] In the transcript of the ETH dialog, this promise was offered by the ETH network as an informal one, with several main Ethereum participants agreed, yet some others offered objections.

When applying EIP-1884, Ethereum made an implicit promise that if something terribly wrong happened in regards of backward compatibility, core developers will be open to adopt protocol changes to fix them.[7] So far, supporters of Phoenix have not agreed to make the same promise.

EIP-1884 is calibrated for Ethereum mainnet[edit | edit source]

  • Unaddressed issueThis concern is not yet fully addressed. The issue is formally documented as in RFC-2.

The rationale section of EIP-1884[8] provides analysis of why the specification is necessary. However, the gas cost increase is calibrated for Ethereum mainnet. It is currently unclear whether the same value will apply on Ethereum Classic.

Calldata gas cost reduction leads to larger blocks[edit | edit source]

  • ConsiderationThis is a consideration with pros and cons.

EIP-2028 reduces the calldata gas cost significantly. This has benefits in layer two applications. In the mean time, it means users can post transactions of larger size with reduced cost and leads to block size increase, which Ethereum Classic has less tolerance of.

CHAINID opcode backward compatibility[edit | edit source]

  • Unaddressed issueThis concern is not yet fully addressed.

EIP-1344 introduces the CHAINID opcode. Once introduced, changing the chain ID of Ethereum Classic will be hard because of backward compatibility issues, as smart contracts will be depending on the current retrievable chain ID and making assumptions. In the scenario of a social chain split of Ethereum Classic, it can put both sides in danger as no side will be willing to be the side changing the chain ID.

BN128 precompile gas cost reduction needs additional assessments[edit | edit source]

  • Unaddressed issueThis concern is not yet fully addressed.

EIP-1108 reduces precompile gas costs of operations on the alt_bn128 curve. The cost reduction is based on the performance of Geth and Parity client, which are the two main clients used in Ethereum mainnet. Both Geth and Parity use highly optimized fixed-size implementation of the curve. However, in Ethereum Classic, supporters of Phoenix advocate for an additional node implementation, Besu. At the time of the writing, Besu still uses Java's builtin big integer structure for curve implementation[9], whose performance characteristic is not yet clear. If Phoenix hard fork does not properly take consideration of the network conditions of Besu client, it may result in DoS attack vectors of the network.

References[edit | edit source]