Core Devs Call: ECIP-1078 Phoenix Upgrade

[soc1c]

ref #217 #226 #227 #262

ref ECIP-1078 ECIP-1079 ECIP-1080

ETC Core Devs Call - ECIP-1078 Phoenix Finalization

When: Wednesday, February 05, 2019, 4pm UTC, 60 minutes max.

Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda

• Quick client teams check-in
  • Parity Tech
  • ETC Core
  • ChainSafe
  • Multi-Geth
• Aztlán needs to be fixed, options are:
  • patch ECIP-1061 with EIP-1884 ECIP-1061 "phoenix": aztlan as vanilla istanbul #280 - very unlikely
    • because ecip-1061 already released in parity and multi-geth
    • because ecip-1061 already activated on mordor testnet
  • replace ECIP-1061 with ECIP-1079 - unlikely
    • because ECIP-1061 already released in parity and multi-geth
    • because ECIP-1061 already activated on mordor testnet
  • update ECIP-1061 with ECIP-{1078,1080} - more likely
    • because ECIP-{1078,1080} can be distinct fork "Phoenix"
    • because ECIP-{1078,1080} can be activated on different testnet blocks but same mainnet block
• Phoenix (ECIP-1078) needs to be either accepted or updated (or rejected)
  • discuss included ECIP-1080 without gas repricing
  • discuss swap of EIP-2200 for EIP-1706 (1283 fix)
  • discuss a timeline for the protocol upgrade
    • Mordor Classic and Kotti Classic testnet (March?)
    • Ethereum Classic mainnet (June?)
• anything else related to Aztlán and Phoenix
• going through the pending ECIP PRs together

Please comment to add items to the agenda.

[ghost]

Stating in advance my opinion to activate both Aztlán and Phoenix on block 10_500_839 on Ethereum Classic PoW-mainnet (estimated on March 25th, 2020).

If it is concluded that there is no time to do both on the same block above, then I propose moving Aztlán back to draft to establish a new later block so both Aztlán and Phoenix can be done on the same block.

Rationale

1. It doesn't make sense to push to mainnet a fork with a flaw just because devs already integrated it into clients or because the ECIP process suddenly gains more importance than the mainnet.

2. It doesn't make sense to force a new hard fork just to fix a flaw that was pushed to mainnet as stated above. This is because hard forks are in themselves, security hazards as they expand the technical and social layer risk surfaces. It also goes against a tradition in ETC to go slow and don't break things and minimizing hard forks.

[bobsummerwill]

@soc1c Please could I suggest the following updates to "options":

1. Note that ECIP-1061 "phoenix": aztlan as vanilla istanbul is not just "very unlikely" but is actually Withdrawn and off the table. So is not something we would have as an option to discuss.

2. Note that ECIP-1079: Phoenix "redo" is not just "unlikely" but is also Withdrawn and off the table. PR is pending.

3. Note that ECIP-1078: Phoenix "fix" is "likely" and is in Last Call status. PR is pending. I was under the delusion that ECIPs needed to be in Last Call for two weeks, but as per ECIP-1000 that is not the case at all. IMHO we should propose activation dates BEFORE the call, so we have a timeline to say YES/NO to. A sensible timeline should be agreed by rough consensus of the client developers here on Github, not "on the fly" in the meeting and then get "blessed" on the call.

[bobsummerwill]

@soc1c PS. Please can you also make hyperlinks (as I have above) for linking to the ECIPs, rather than just listing them as numbers and people having to find those themselves. Much more handy to just do the hyperlinks as I have, so the agenda is the navigation itself.

[bobsummerwill]

@tokenhash If the core developers DO NOT feel that it is feasible to still hit the original ETC mainnet activation block then I don't think ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) can go back to draft. It has already activated in Mordor. Releases have already been made.

If the mis-specification had been discovered well ahead of the activation I think it would have been fine to take 1061 back to Draft, make the changes there, and then back to Last Call and then Accepted again. WIP on the clients would have been re-vectored to the new specification and everything would have been fine.

Instead we would need to move it to Withdrawn and make a new ECIP (effectively a new version of ECIP 1079: Phoenix (Azltan "redo").

We cannot do anything with ECIP 1061 anymore other than leave it as-is or Withdrawn it. That ship has sailed.

[bobsummerwill]

If we can still hit block 10_500_839 then we just leave Aztlan alone and active Phoenix on top of it.

If we cannot hit block 10_500_839 then we need to Withdraw Aztlan (which means deactivating it from ETC mainnet activation in the client releases, so it activated on the testnets but never on mainnet) and we need to make a new ECIP for the redo.

That new ECIP would be much the same as ECIP 1079: Phoenix (Azltan "redo") but would also need to account for the testnet transitions being messier than mainnet transition - because the testnets have Aztlan activated already, so just need "fix", where mainnet never got Aztlan, so needs "redo".

[bobsummerwill]

The easiest path by far is ECIP 1078: Phoenix (Aztlan "fix") so that everything is cleaned up and as per the original intention of 1061 which we came to consensus on in November (Instanbul - 1884 repricings), though the path we have followed is a little confusing on the outside.

1061 + 1078 (which includes 1080)

"Aztlan + Phoenix" colloquially.

[ghost]

@bobsummerwill,

Understood.

I would agree with those options (Aztlán + Phoenix or withdraw 1061 + complete redo).

Let's see what happens at the call.

[soc1c]

Proposed block numbers in #285 in case we decide for the 1078 way.

• 976_231 on Mordor Classic PoW-testnet (March 4th, 2020)
• 2_208_203 on Kotti Classic PoA-testnet (March 11th, 2020)
• 10_500_839 on Ethereum Classic PoW-mainnet (March 25th, 2020)

[GregTheGreek]

A few notes:

• It seems that Parity has removed the 1.7.0 binaries (I've heard due to a security issues, im still confirming). There is a tag for 1.7.1, although im uncertain of the status since the current build is failing the CI.
• I would suggest that for every week we are late to fork the fix ( ECIP-{1078,1080}) we should also delay the mainnet blocks by an equal amount of time. This is to ensure we still have the equivalent amount of time for testing.
• Besu should be ready soon - but we are unsure about getting a release from Hyperledger, I'm hoping I can get a RC version

[bobsummerwill]

@GregTheGreek In case you missed this in the flood of messages.

10_500_839 is actually tracking for late May, early June.

So we are not in a rush AT ALL now. Quite the opposite.

See https://github.com/ethereumclassic/ECIPs/pull/285/files

[bobsummerwill]

New blocks proposed for Phoenix:

• 976_231 on Mordor Classic PoW-testnet (~March 4th, 2020)
• 2_208_203 on Kotti Classic PoA-testnet (~March 11st, 2020)
• 10_500_839 on Ethereum Classic PoW-mainnet (~May/June, 2020)

[classiclab]

The proposed blockheight is much farther away than originally estimated. What is the cause?

[ghost]

It seems at least the mainnet block number is the same as in ECIP-1061 Aztlán: https://github.com/ethereumclassic/ECIPs/blob/master/_specs/ecip-1061.md

778_507 on Mordor Classic PoW-testnet (Feb 5th, 2020)
2_058_191 on Kotti Classic PoA-testnet (Feb 12th, 2020)
10_500_839 on Ethereum Classic PoW-mainnet (March 25th, 2020)

I think there must be some recalculation of the block times (from 13 seconds to 15, or something) that changed the time estimates.

I support taking it slowly (it's only 2 or 3 months differential) but having both forks aligned and well tested to minimize the most as possible any chance of split, bug, or incompatibility in the mainnet.

[bobsummerwill]

@classiclab The block number for Azlan was set on 20th December on a best estimate of a block targeting 25th March at that point:
https://github.com/ethereumclassic/ECIPs/pull/248/files

The proposed block number for Phoenix is the same, but yes, it is a lot further back than originally intended.

I asked @realcodywburns what his "Bridgette" bot estimated. Here was the answer:

Based on the last 50,000 blocks:

                9719915
          Current Block Height 
  13.118                       9.305

Average BlockTime Std. Div
2012058
Block range

              Mean Block 
               10424503
                  | 

|-----------------------------------------|
| |
10132109 12144167
Low Block number High Block
(1 stdv dwn) (1 stdv up)

Prime number near mean block: 10424507
Twin Prime near mean block: 10424567
A Quad Prime near that range: 10134401
Warning! This range is larger than one human day, Try back later when the range will be tighter.

He said:

"We could be up to 2 million blocks higher than that by then depending on the block times
Our 13 second block time can easily be 4 seconds for 30% of the blocks"

There is just a huge variance in block times. There has been massive shift in both price and hashrate since December.

The https://etcnodes.org/aztlan estimate, which is just based on a 13s block-time estimate sees it even further back.

[bobsummerwill]

@classiclab I did propose whether we might want to activate the Aztlan codebases in Phoenix as well at a block prior to 10_500_839 for ETC mainnet, but @soc1c strongly advised against re-ordering HFs in that way. Too much risk of introducing edge cases.

He said:

"no bob, we will not change the order of hardforks
that will cause unprecedented edge cases
let's have an 8 week last call period
so we know for sure if something goes south on the testnets we can still rescue the mainnet"

With the learning that this block will likely be so much later than expected, we have done from a position to having a tight deadline of 8.5 weeks to mainnet (https://etccooperative.org/etc-phoenix-hardfork/) of having plenty of time for testing Phoenix. The block has not changed. Just our expectations of the date of activation.

See #285 for proposed Phoenix activation time for Mordor, Kotti and ETC mainnet.

We can also start work proposals for inclusion in the following hard-fork in parallel with the extended testnet period for Aztlan+Phoenix. The most urgent of which relate to gas-limit, gas costs, gas refund mechanism, SELFDESTRUCT and general state bloat management. But also Kunming versioning and Keccak256 proposals.

Also, see https://github.com/ethereumclassic/ECIPs/pulls for the "working set".

Maybe also FlyClient, simple subroutines? Some Berlin opcodes?
https://eips.ethereum.org/EIPS/eip-2070

We don't need to wait until June to start working on plans for that.

[bobsummerwill]

@soc1c Agenda point.

Given that we are essentially down to a binary choice now between Accepting Phoenix or rejecting it (and the only reason I can see why that would make sense was on the basis that the timeline for 10_500_839 was too tight, but it isn't anymore), I think we will likely have some time available for OTHER BUSINESS, and I would propose that we work through the house-keeping of progressing the following ECIPs:

• ECIP-1063: Reject "Integrated decentralized oracles and smart contracts"
• ECIP-1051: Reject "Ethereum Classic Treasury system"
• ECIP-1057: Reject "Cold Staking"
• ECIP-1052: Reject "Smart-contract Security Auditing core"
• ECIP-1021: Move ERC-223 token standard to Last Call, on its path to Accepted and then Final

These have all been tagged as "need consensus confirmed on a call, but are trivial Status changes to clear out our "working set".

[classiclab]

I think the original blockheight of 10_500_839 is reasonable given the revised scope of the hard fork and the time needed for ample testing.

[bobsummerwill]

Glad you feel that way too, @classiclab.

It was a surprise that the block is now expected so much later than we estimated in December, but I think it is actually a blessing in disguise to have the additional time to test the Phoenix changes, which are new and different than ETH and need testing thoroughly. I don't know that we need an extra two months, but changing the ordering now would just introduce more risk.

And I said above, the extended period does NOT have to mean that all other progress is stalled for two months. As soon as there are Phoenix candidate releases for each of the clients - work can begin on other proposed future ECIPs.

If you have proposals not listed above, please do create ECIPs for them.

[bobsummerwill]

@soc1c @YazzyYaz @meowsbits @BelfordZ @sorpaas there are also a few further ECIP pull requests pending which look like they could be merged as Draft right now, or if they need human consensus, we could try to fit them in too ...

• ECIP-1085: Simple Subroutines for the EVM proposal
• Move ECIP-1078 ("fix") to Last Call. Move ECIP-1079 ("redo") to Withdrawn <-- this should happen before the meeting
• Withdraw ECIP-1081 Do Not Dox ECIP Editors
• ECIP-1084: Hard cap on the gaslimit for the ETC mainnet as an in-protocol consensus rule
• ECIP-1083: Remove Contract Size Limit <-- WIP needs changing to Draft and then LGTM
• ECIP-1082: Fork identifier (forkid) fork list specification

If we can whack through all of this with quick yes/nos then our working set of pull requests will be much more manageable. We would defer the ones about ECIP process itself to another call. We aren't going to have time for that, but we might have time to do the "paperwork" on the others.

• ECIP-0001: Process ECIP-0001, Replacement of ECIP-1000
• ECIP-1077: Meta Specification Establishing Fork ECIPs (Using Pull Request development pattern)
• ECIP-1000: propose only one meta ecip per hard fork . CC @shanejonas.
• ECIP-1000: ECIP Coordinators

[realcodywburns]

There has been massive shift in both price and hashrate since December.

This has little to do with the variance the issue is block difficult adjusts per block based on the randomness of the previous blocktime. We need a longer period to baseline the difficulty target in order to smooth out the curve

[bobsummerwill]

This is a protocol level issue, @realcodywburns? Does ETC suffer more than ETH from this variance in practice? Or do both chains suffer equally?

[soc1c]

Done #285

[YazzyYaz]

Meeting Notes:

• Soc1c: Greetings from Hardfork Coordinator. Discussions on Phoenix Upgrade.
• Bob: 1061 Aztlan Yingchun edition agreed on call in November. Was adopted as Istanbul Minus 1884. Wei implemented it in Multi-Geth, he discovered 2 flaws in specifications. 1884 has changes but was problematic due to SELF-BALANCE op-code. Second piece is interaction with EIP Netgas Metering and 1884, the two were activated together in Ethereum, but with us were activated without the changes in 1884. Phoenix activation fixes the specifications to what we thought we were getting originally in Aztlan. Activation on the same day on mainnet. Activation on testnets needs to be fixed. Aztlan on Mordor happened, so needs Phoenix to happen there. Kotti as well.
• Bob: ECIP-1078 are written by Bob but specified by Wei Tang. It’s an overlay for Aztlan fix. 1079 is an Aztlan redo since 1061 will be withdrawn and we will have a new and replacement hardfork of 1079 is a new hardfork ecip. ECIP-1078 and ECIP-1079 is essentially the same changes but different timelines. Factors to favor a redo over a fix. The timeline is the different.
• Bob: Redo is about “needing more time". Fix would be a better option. Another option is to do Phoenix before. Way too risky as told by others. ECIP-1080 is specification for SELF-BALANCE.
• Soc1c: everyone agrees we should fix Aztlan on same block. 1078 enables the SELF-Balance op-code in 1080. Anyone has any concern with phoenix hardfork as fix for aztlan?
• Isaac: Are current numbers canonical for block activation?
• Soc1c: No, there are PRs now open to move one for fix to be implemented and redo to withdrawn. This will be canonical after this call.
• Bob: Yes, the current PR: Pull Requests · ethereumclassic/ECIPs · GitHub. March 4 to Mordor activation, March 11 for Kotti, June 10 for Main net.
• Soc1c: comment on Gas Metering?
• Bob:1884 decision to remove the gas metering changes that break backward compatibility. Self-balance is second one added. Net metering is the third one.
• Soc1c: Very clear now.
• Bob: Code also already exists, if the activation of the changes are different than Ethereum, still the same code base and not on a different path.
• Soc1c: Anyone has any questions? or technical concerns?
• Silence
• Soc1c: I propose moving with Bob's proposal then with Phoenix hardfork to Last Call. Declare consensus moving 1078 to Last Call.
• Bob: Some ECIP suggestion to Reject because they’re long standing. ECIP-1051 is the one for treasury system. Anyone opposed to this rejection?
• Silence.
• Rejected
• Bob: ECIP-1057 Cold Staking move to Rejected. Anyone opposes it?
• Silence
• Move to rejected consensus
• Bob: ECIP-1052 Smart Contract Security Auditing to Rejected. Anyone opposes it?
• Silence
• Move to rejected consensus
• Bob: ECIP-1063 Decentralized Oracles to Rejected. Anyone opposes it?
• Silence
• Moved to rejected consensus
• ECIP-1085: Simple SubroutinePull Requests · ethereumclassic/ECIPs · GitHub
• Soc1c: No need to discuss Drafts on calls
• Yaz: ERC-223 to Last Call?
• Isaac: Is there an EIP doc on ERC-223? Do we adopt it in the repo or a separate repo?
• Soc1c: It should be moved to final.
• Isaac: Let’s discuss it more outside call.

[realcodywburns]

This is a protocol level issue, @realcodywburns? Does ETC suffer more than ETH from this variance in practice? Or do both chains suffer equally?

Both suffer equally. The difficulty adjustment was poorly designed

[bobsummerwill]

Right, @realcodywburns.

It is quicker than BTC at least. That slow adjustment was a nightmare at the HF points for Bitcoin. No doubt the BTC maximalists would call that a feature, not a bug :-)