Pre-RFC: Phoenix hard fork (Ethereum Classic)

[sorpaas]

Assigned Number: 2-etc-phoenix
Discussions: https://discord.gg/BdRSvJD

The preliminary review period ends on 6 March, 2020. After that point, we will turn this pre-RFC into an RFC document. You can still submit additional justifications after that period.

Specification

The following EIPs are to be enabled after FORK_BLOCK: EIP-152, EIP-1108, EIP-1344, EIP-1884, EIP-2028, EIP-2200.

Implementation

• MultiGeth: Add Phoenix hard fork support for Kotti and Mordor multi-geth#137
• OpenEthereum: ethcore/res: enable ecip-1088 phoenix upgrade for kotti and mordor testnets openethereum/parity-ethereum#11529

Request for Justifications

This section asks developers who wish to apply this change to Ethereum Classic network to provide justifications for the following questions. See this description for more information on what RFJs are about.

• Has there been sufficient analysis done, like in Ethereum, to figure out what particular contracts might have been broken by EIP-1884?
• The actual gas cost changes in EIP-1884 are based on analysis on Ethereum mainnet. Has there been sufficient analysis done to see whether the situation in Ethereum Classic is the same?
• Has there been any concrete public awareness program planned, like in Ethereum, to warn users about breakage of backward compatibility, and ask them to upgrade their smart contracts if required?
• In Ethereum, although pushed back by some developers (especially if it's as a "promise"), there was an informal rough consensus that if contracts are broken, we may change protocol rules again to un-fix those particular contracts. That informal rough consensus played a minor rule in making sure EIP-1884 wasn't contentious. Has there been any similar rough consensus / promise in Ethereum Classic?

To provide justifications of those questions, please add comments to this issue.

[sorpaas]

I got a private reply from @bobsummerwill of ETC Coop providing the following justifications:

The answer to all of the questions is "No - we have not done analysis, public awareness campaigns and we do not have consensus that we would update protocol rules to unfix".
We do not have a ready supply of researchers and analysts to do such work.

We can proceed this RFC just with that (combined with a "use it at your own risk" warning, of course), but I'll wait a few days to see if that justification is contentious in the ETC community. There also seems to be some efforts to contact ETH developers for some proper analysis, so let's also wait for that and see if it works.

There is no such thing as an RFJ (request for justifications) step in the Ethereum Classic Improvement Proposal (ECIP) process, which is roughly modeled after the RFC, BIP, and EIP systems, as per ECIP-1000.

In fact, the ECIP process is the analogue process to RFC/BIP/EIP, therefore once an ECIP goes through the status steps and moved to "accepted" it means it has already been discussed and approved by rough consensus, and it is the final specification, if there are no unforeseen problems, for client developers to follow if they voluntarily wish to do so. Then, when and if deployed in the mainnet it is moved to "final".

This means, the only process in ETC are the status steps and its proper activities and discussions as described in ECIP-1000, there are NO other rules or steps to follow, therefore this RFC/RFJ arbitrarily proposed here by you is redundant, unnecessary, and disruptive to the proper ECIP process.

Consequently, nobody has to answer your questions here @sorpaas.

That you made many mistakes when proposing, championing, processing, and implementing ECIP-1061/1072, even knowing they had flaws, is your own responsibility. Now ETC has tested and corrected all the mistakes caused by your disruptive behavior and created ECIP-1088 for the Phoenix upgrade.

As you continue to harass the ETC ecosystem with these actions and present a hazard to the network, I kindly request you discontinue support for ETC in Multi-Geth and stop trying to disrupt the ETC ecosystem with your imaginary process steps, malicious actions, and fictitious requirements.

In other words, go away and never come back to ETC.

[sorpaas]

Thanks @tokenhash for providing the justifications! I think you and @bobsummerwill have really explained a lot on how ETC treats network security. Those are enough justifications for now, and it also means we indeed need an "use it at your own risk" disclaimer for ETC.

For the record, I have never "championed" ECIP-1061/1072. In fact, I have been openly raising issues of ECIP-1061 since November 2019. Yes, I am the (co-)author of ECIP-1061 (along with all the alternative options for ETC Istanbul hard fork), and this makes it even more ironic that it was decided to rush it and ignore objections even from the (co-)author of the specification you're trying to adopt.

implementing ECIP-1061/1072, even knowing they had flaws, is your own responsibility

I think this clears @meowsbits point (openethereum/parity-ethereum#11529 (comment)) -- MultiGeth/OpenEthereum were indeed blamed for implementing the specification last time. This is what makes Request for Justifications necessary.

[sorpaas]

Added preliminary review period for this pre-RFC. It currently ends on 6 March, 2020, but may be extended, upon developers' request. You can still submit justifications after the preliminary review period ends.

[sorpaas]

Pokemachamp00 provided the following justifications:

The good new that at the current ETC ecosystem level, we don't have a lot of smart major smart contract dApps yet.

[gitr0n1n]

4. "In Ethereum, although pushed back by some developers (especially if it's as a "promise"), there was an informal rough consensus that if contracts are broken, we may change protocol rules again to un-fix those particular contracts. That informal rough consensus played a minor rule in making sure EIP-1884 wasn't contentious. Has there been any similar rough consensus / promise in Ethereum Classic?"

It does NOT appear that any development team has formally championed this proposal in the ECIP process. Therefore the Ethereum Classic core dev participants likely do not have this proposal on their radar. I recommend the Multi-Geth team, specifically sorpaas, create an ECIP to formally propose his "promise" and see if he can obtain consensus for the proposal.

It appears Multi-Geth has publicly committed their own devleopment resources to this cause and that should be noted for any dapp developers that have issues with broken contracts.

Note:
Opinions are my own, formed from researching the source documents. Please do your own research.

[gitr0n1n]

3. "Has there been any concrete public awareness program planned, like in Ethereum, to warn users about breakage of backward compatibility, and ask them to upgrade their smart contracts if required?"

A few of us are currently updating the news/press sections of EthereumClassic.org. Currently, public outreach for the project is severely dated with most recent articles from ~2017. So we have a lot to backfill and plenty of new content to write. We will add relevant articles as the new website rolls out, but its currently a work in progress. Since Phoenix will be the next upgrade to discuss, any relevant topics for that update will be shared with the public via the website news section outlet.

We hope the Multi-Geth team will formalize their technical understanding of the issues and draft some technical copy to warn users about breakage of backward compatibility, and ask them to upgrade their smart contracts.

The EthereumClassic.org website commits to sharing/posting content that is factually accurate, directly relates to the ETC protocol, and is submitted via the article submission process.

Note:
Opinions are my own, formed from researching the source documents. Please do your own research.

[gitr0n1n]

1. "Has there been sufficient analysis done, like in Ethereum, to figure out what particular contracts might have been broken by EIP-1884?"

There is no precedent on Ethereum Classic to preform this type of analysis for its upgrades. This analysis was not performed for ECIP-1015 or ECIP-1054.

If a core team commits to performing this analysis, it is optional and voluntary.

Note:
Opinions are my own, formed from researching the source documents. Please do your own research.

[gitr0n1n]

2. "The actual gas cost changes in EIP-1884 are based on analysis on Ethereum mainnet. Has there been sufficient analysis done to see whether the situation in Ethereum Classic is the same?"

Good question, I haven't stumbled over this discussion yet. Do you have any formal discussion to cite regarding this topic for ETC or ETH? I see merit to defaulting to ETH logic for security sake since the update has been running for 3 months. But I need to familiarize myself with that logic to have an informed opinion on these gas numbers.

As the team bringing up this issue and participants in the ETC development process, perhaps Multi-Geth would like to tackle this analysis?

Note:
Opinions are my own, formed from researching the source documents. Please do your own research.