-
Notifications
You must be signed in to change notification settings - Fork 326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
December Network Upgrade #356
Comments
Note: on ACD117, the Geth team mentioned that for them focusing on the merge right after London would be best, which implied a "difficulty bomb only" upgrade for December, but we never made that explicit. |
On the topic of naming: there was a time we used two-word names, and then somehow we ended up on the city-name track (starting with Byzantium). In this city-name era, the only two-word update is Muir Glacier, which is both a non-feature update and somewhat a "unplanned update". Two questions:
I am slightly leaning towards keeping the city names for every feature update (including the merge), as long as there is a single feature apart from the difficulty bomb. And keeping everything else with a different name. In case there will be only a difficulty bomb change, I suggest we look for another retreating glacier perhaps in so far unrepresented regions, such as Africa or Oceania: Arrow Glacier or Tasman Glacier sounds like an interesting one. See also 1, 2, 3, 4. |
On ACD 118, we agreed to focus on the merge for now, at least until we have testnets up and running, before deciding whether to have another "feature fork" before the merge. We did not agree on a naming convention for Shanghai vs. Glacier themed forks for features vs. Ice Age changes. |
Opened a thread about this on Ethereum Magicians as well: https://ethereum-magicians.org/t/ethereum-roadmapping-improvements/6653/12?u=timbeiko |
We agreed on ACD120 to only have a difficulty bomb pushback (and possibly other trivial changes) in December. Some of the rationale is shared in https://hackmd.io/@timbeiko/london-retro#Roadmap-for-next-6-months |
TL;DR: we need to make the following decisions in the next 1-2 ACD calls:
Longer post, more context:
With EIP-3554 pushing back the difficulty bomb, we will need to have a network upgrade in December.
In the most optimistic of scenarios, this upgrade could be the merge, but given the amount of open items on the mainnet readiness checklist, we cannot be certain of this.
If we assume we have a non-merge upgrade, we need to decide whether we want to include anything else aside from another difficulty bomb delay (and whether to keep the name "Shanghai" if we only delay the difficulty bomb, or use another "glacier-themed" name :-) ).
If we only delay the difficulty bomb, the upgrade is drastically simpler to test and implement: it is a single constant change, and will not require to be deployed on testnets prior to mainnet. This means that we could choose the appropriate delay in October, release clients in November, and upgrade in December.
Alternatively, if we decide to include any "feature EIP", then testing and testnet deployements will be needed. Working backwards, and following the London schedule, it means we would need to follow this timeline:
This timeline would be slightly shorter than London. It is also worth noting that working on a network upgrade would likely delay some of the progress on the merge given that client teams will need to split their focus. For reference, the EIPs that have been loosely discussed for Shanghai so far are: EIP-2537, EIP-3540, EIP-2935, EIP-3074 and EIP-3651.
Given that the next ACD calls are on July 23 and August 6, unless we have a list of EIPs chosen on the August 6th call, then we will default to not including any non-difficulty-bomb EIPs in the December upgrade.
The text was updated successfully, but these errors were encountered: