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]

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

Principle of backward compatibility in Phoenix (new): Phoenix hard fork breaks backward compatibility. This documents several potential solutions in case the issue goes out of hand.

Contention of Phoenix (new): Arguments for and against the potentially contentious hard fork.

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.

Backward compatibility impact analysis [ edit | edit source ]

Consideration There 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 issue This 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 ]

Consideration The 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 issue This 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 ]

Consideration This 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 issue This 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 issue This concern is not yet fully addressed.