We have decided to remain neutral in Phoenix hard fork on Ethereum Classic, meaning we don't object the fork. However, we do not think the current form of Phoenix is a good hard fork, for the following reasons:
- The current parameters in Phoenix are calibrated for Ethereum, not Ethereum Classic. The network condition is different in average block gas limit, merkle trie size, etc. This can lead to a number of issues and operations being too expensive or too cheap to carry out. This issue is present in Phoenix's EIP-1108, EIP-1884 and EIP-2028.1
- It leads to future backward compatibility issues due to CHAINID opcode in EIP-1344. 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.2
- It has current backward compatibility issues due to EIP-1884. This is the first time we knowingly break backward compatibility, and is in direct contradition of what has been done in EIP-1283 of Atlantis (Constantinople and Petersburg). This breaks Ethereum Classic's promise of "unstoppable contracts" and "code is law".3
- From the above issues, the specification is clearly lacking reviews. The hard fork date was artificially set to be the same as rejected Aztlan hard fork, to create the illusion that there was not a "cancelled hard fork" in Ethereum Classic. I'm not judging ETC Labs and ETC Coop's decision on this, but just pointing out that the timeline did not look like to have been set to consider with enough respect of technical details.
Again, this does not mean we object the hard fork, but it's important for people to be aware what we're getting into with Phoenix. For more information of those issues, see the summary at Consensus Paper. https://consensus.corepaper.org/wiki/Phoenix_(new)
And for more discussions, go to https://discord.io/ethereumclassic
Can Multi-geth consumers expect to have Phoenix mainnet release even if you disagree with it?
Yes. As said above, we're neutral of Phoenix hard fork and do not object it. We just don't really think it's a good one.
[1]: See review BN128 precompile gas cost reduction needs additional assessments, EIP-1884 is calibrated for Ethereum mainnet, and Calldata gas cost reduction leads to larger blocks.
[2]: See review CHAINID opcode backward compatibility.
[3]: See review Backward compatibility impact analysis, Public awareness of backward incompatibility, and Promise to backward compatibility support for dapp developers.