ECIP-1054: Support for ETH Byzantium EVM and Protocol Upgrades

[soc1c]

Atlantis Hardfork Meta

Enable the outstanding Ethereum Foundation Spurious Dragon and Byzantium network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Atlantis to enable maximum compatibility across these networks.

[soc1c]

This reflects the current state, not the desired state. In general, this section is used to point out a reference implementation which can be used by other client developer teams.

[meowsbits]

IMO this should just be removed then; a spec should not be a roster of supposed current implementations unless the implementation(s) is part of the spec.

[zmitton]

This is exactly what I want to see happen.

• short
• to the point
• specifies All-client -support directly in the proposal
• Its ambitious, yet has a specific and realistic timeline

LGTM. Let's begin the discussion with other dev teams

[YazzyYaz]

Enable the outstanding Ethereum Foundation _Spurious Dragon_ and _Byzantium_ network protocol upgrades

Isn't Spurious Dragon also in ETC at the moment?

[soc1c]

Isn't Spurious Dragon also in ETC at the moment?

No, EIP-161 and 170 are missing which could cause complications and incompatibilities. After discussing with @sorpaas I decided it makes sense to include them in Atlantis.

[meowsbits]

@soc1c Can you say a little more about that discussion (re/ EIP161,170) -- just for FYI for readers and to document the reasoning?

[meowsbits]

IMO t-minus 6 months from now is a rather long time... and I'm usually the skeptical one trying to push these dates back for safety 😹 ...

These changes are really important for ETC and it's current and potential developers; and for the sake of the chain's relevance to ETH-facing contract developers, they should happen ASAP. As in the doc, Parity-Ethereum, Mantis, and Multi-Geth are ready for liftoff essentially now.

8_400_000 on ETC Mainnet would put the drop about 100 days from now.

(My block time calculations for reference, where 13 is assumed average block time seconds:)

>>> 100*24*60*60/13

  100 × 24 × 60 × (60 / 13)

   = 664615

>>> 7727254 + ans

  7727254 + ans

8391870

[soc1c]

Six months is the minimum possible time to prepare for the hardfork. On the testnets it's already in four months and Geth Classic (any of them) does not even have it implemented yet. We don't have the developer power that Ethereum Foundation has and the ETH network uses a nine months hardfork cycle.

So to be honest with you, six months was the most optimistic timeline I could propose. But happy to hear other opinions. However, I am highly sceptical that we can fork earlier than I proposed.

[soc1c]

EIP-{161/170} are proposed to enable maximum Byzantium compatibility and to avoid unwanted surprises in the behaviour of any implemented Byzantium proposal. Also, as @sorpaas pointed out, this will simplify testing massively.

[soc1c]

Any further comments @etclabscore/developers ?

[meowsbits]

Alright, that's OK with me. Better safe.

Do we have any points of contact for maintainers for either of the Geth Classics who would be willing to a) commit to the work, and b) give a timeframe on that work?

Or maybe, better, the ECIP should not specify or even mention clients at all; that's the job of metadata around the ECIP organizing and encouraging client participation; there could, after all, be any number of "unofficial" clients that can't be counted on or accounted for, and a client list is not a true "specification," it's an informal team roster at best.

[zmitton]

I'm all for coordinating as much as humanly possible. Something like the joint call last week, but to discuss the upgrade.

[soc1c]

Again, please don't confuse governance with writing a spec. I want feedback here and now whether this proposal makes sense and is sound from a technical perspective.

Things that are not relevant right now: block numbers, client implementation status, etc. That's something we track in the proposal, but it's not part of the technical specification.

So if there is nothing else, I would like to move on. :)

[zmitton]

EIP-161 seems to introduce quite a bit of tech debt and does not significantly affect ETH compatibility:

• should we consider leaving it out of atlantis?
  • if so, would it be worthwhile to traverse the tree in search for a definitive number of empty accounts (my initial investigation seemed to find over 90% of accounts were empty)?
  • if implemented, do we also need to run a script which creates transactions to touch all the empty accounts on-by-one (and in turn deletes them)?
    • does the EF have such a script we can borrow
    • I assume someone must pay the gas for this, correct?

CC: @sorpaas @soc1c

(note that if we dont include 161, it will affect EIP-1052 but it should be a trivial fix )

[Matthalp-zz]

An alternative to EIP-161 is to split this into two (hard fork phases):

1. Stop saving empty accounts in the state trie
2. Remove the existing saved empty accounts

The two phases are needed because (1) locks in which empty accounts have been saved as (2) would require a priori knowledge that is very unlikely to know in absolute.

[soc1c]

Atlantis finalization call ethereumclassic/ECIPs#78