Poor 12356 is penalised for 12345 
2 Likes
I somewhat agree… !
One reason to not pick the mainnet block at the same time as testnets is to not set expectations in the community too early. IMO what we did for London, to wait and make sure the testnet deployment went smoothly, was the right approach.
The reason for this is that the things which have the highest likelihood of breaking are the “large initiatives”, and they are also the ones we would be most likely to delay the fork for. For example, if we had found an issue with EIP-1559 on the testnets, it probably would have been worth delaying London by 1 month to fix it.
OTOH, if we find an issue in a “small EIP”, then maybe it’s not worth delaying the fork. It’s also worth pointing out that in some cases, removing an EIP can be more work than fixing a bug, because we need to test for non-inclusion, to not end up with consensus issues like we saw on OE in Berlin.
1 Like
I think this is where we disagree. If we had very regular hardforks, I would rather delay EIP-1559 for 6 months to the next hardfork and keep on the reliable schedule than slip the schedule by a month to get EIP-1559 included 5 months earlier. For a smaller venture (e.g., brand new blockchain, startup company, etc.) I would argue the opposite, but for something the size and scope of Ethereum with the number of involved stakeholders I think that reliable schedule is more important than timeliness of specific features.
1 Like
Fair enough! I think delaying makes sense for the larger initiatives, and it’s kind of what we’ve done historically. Also, I don’t think we’ll get “perfect” 6 month schedules, so I’m fine with a rough “2 forks per year” commitment, but if I’m the minority here, I’m happy to try a very strict schedule.
Also, FWIW, this can be thought of as a gradual process to make things more predictable: our current process → “loose 2 forks per year, with some margin of error for big things” → “strict forks every 6 months”.
2 Likes
This doesn’t seem like a good idea. This would mean that for two months there is no testnet that can be used as a sort of “staging environment” for a mainnet deployment.
There’s probably a deeper underlying problem here: that right now, there doesn’t seem to be a clear difference of purpose for each testnet. (Maybe there is! But if it is, it seems to me that it’s not clearly communicated)
Maybe this schedule could be a first step towards better differentiating each testnet. For example, one of them could have the fork scheduled for (T - 1 week). This would be the most stable of the testnets. This would also mean that there’d be two weeks per year where a reliable testnet doesn’t exist, but that seems like a decent compromise.
(This is just a first idea. This surely needs more thought.)
@fvictorio to be sure I understand your point: you are saying it is bad that testnets for “so early” before a fork because then they are not the same as mainnet and it makes it hard to test an application in “mainnet conditions” on a testnet?
If so, I think this is a hard dillema. There are three things we are usually working for when forking testnets:
- “Testing all code paths”, i.e. making sure the changes are entirely tested. For this, we typically use Ropsten because it is PoW, like mainnet.
- Cross-client consensus issues, i.e. making sure all clients agree to each other. Here, again, Ropsten or Goerli can work (but not Rinkeby/Kovan, given that only Geth/OE are validators).
- Replicating mainnet activity. This is probably the most important part, but also the one we want to do last because we may be able to catch issues with (1) + (2) before. Historically, we’ve used Goerli for this.
So, on one hand, the more time we have on testnets, especially those with lots of applications deployed, the higher the chance we catch bugs (i.e. like the Ropsten one from yesterday, which came a few weeks after the fork). OTOH, this means the testnets aren’t “staging environments” for application developers.
Another thing that’s worth noting is that we need ~1 month to properly choose a mainnet block, get it implemented in client, and sharing those client versions with the community, and there is a desire from core devs to pick a mainnet block after seeing testnets fork successfully.
I’m not sure what the “least worst” option is here, open to ideas!
2 Likes
Based on that, I’d say that a good start would be to consider Ropsten and Goerli the “less stable” (in the sense that they’ll fork earlier) and Rinkeby/Kovan the “most stable” (whose forks are closer to the mainnet fork). Since Rinkeby/Kovan aren’t that good as a testing ground for the protocol-level stuff, they would be better used as an app-level staging ground.
I understand though that there’s an inherent conflict here: the core devs would get better data if more contracts are deployed and used, but app devs will prefer more stability. I still think is worth it to fork them at different blocks based on that “intended usage”.
As a data point for this: when the testnets were forked, some features of Hardhat stopped working until we released the version with support for London. In the meantime, users moved to other testnets instead (I don’t remember right now which one was the last one to be forked). If all of them would’ve been forked at the same time, or at a very close point in time but two months before mainnet, where it’s probable that tooling isn’t ready yet, there would’ve not been a workaround.
If this makes sense, the next step would be to clearly communicate it. At the very least, the testnets section of ethereum.org and this very upvoted SE question should be updated. (That’s probably out of the scope of this discussion, I’m mentioning it here just for completeness)
Yeah, I think that’s fair. For Berlin + London, Kovan has actually forked after mainnet. It is being deprecated, but it may be worth considering doing so for Rinkeby. I can definitely bring this up on AllCoreDevs (although with the merge coming, it may not be directly applicable…! Still TBD.).
Agreed, once we reach some sort of consensus we should update them. Thanks for highlighting!
1 Like
On Naming Upgrades
On ACD118, the topic of the next upgrades came up, along with their naming. There are a few different things to decide on this front:
City Name vs. Two-Words for Ice Age
The first point was whether we should stick to our city name terminology or use a two-word name for the December upgrade, which will have to update the Ice Age (assuming The Merge is not ready), and may contain additional EIPs. @axic shared some thoughts on Github about this:
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”.
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.
The counter argument is that following the devcon names provides more predictability for people looking at the “Ethereum roadmap” (e.g. we know Shanghai is in December, and it is followed by Cancun, etc.).
If you have a preference, please share it here.
- City names (Shanghai = December, Cancun = X, etc.)
- Two word name for Ice Age ( Arrow Glacier = Difficulty Bomb, Shanghai = EIP X, Y, Z)
0
voters
“The Merge” as a special name
Should we use a city name for “The Merge”, or should we use a city name (e.g. Cancun)?
- The Merge
- City Name (Cancun, Prague, etc.)
0
voters
Time-based vs. Content-based Updates
Another question that was discussed on the call is whether we should try and adhere to strict schedules in our network upgrades (as argued by @MicahZoltu here), or whether we should aim to define what the “big initiative” in a upgrade is, roughly schedule it, but be flexible to ensure that this large feature is delivered (as argued by me here).
- Strict Time-Based Upgrades
- “Large Initiative”-Based Upgrades
0
voters
I generally like the thinking, but I don’t know that it’s going to be net positive for where Ethereum is right now.
These kind of rigid structures is what makes big entrenched companies unable to change, and what ultimately leads to their demise albeit slowly. The key word here is entrenched.
I think Ethereum’s agility is a feature for now, not a hinderance. Hence I too kinda lean towards the semi flexible “attempting to do two hard forks per year”.
Is this always ideal for all stakeholders? no. But agility being the magic power that it is comes with a cost, and I don’t think we are at a stage yet where we’ve become the entrenched mammoth nobody can touch. We need some flexibility for the time being while the product is not feature complete.
I’d like to propose another option for the post-merge releases. 
In Eth2 R&D, we’ve chosen star names theme as the release naming convention.
Quoting the proposer Edson Ayllon:
Ethereum 1 upgrades are named after cities. I’d like to continue the theme of physical locations, but do so with a different kind of physical locations. I’m thinking star names. Then, we can move onto galaxies for Eth3.
IMHO it was a wise and poetic proposal. 
I suppose that after the merge, we may have protocol upgrades that:
- Only change the execution layer.
- Only change the consensus layer.
- Change both execution and consensus layer software.
We can start to think about how to merge the two organisms for these cases in community communication.
The Merge
IMHO since this release is likely to only include the merge-related features, “The Merge” seems okay to be a special case as it has been recognized broadly. Or, we can consider naming it to a star name starting with the alphabet “B”.
2 Likes
Thanks for sharing!
Happy to stick to star names for post-merge updates. I suspect it will be more likely that both sides (consensus + execution) get updated at the same time (for simplicity, amount of changes we can do in a year, etc.) so the star names can just represent these updates.
If people are happy with this, then we can probably have either Shanghai/Arrow Glacier, then The Merge, and then “B-Star”, which would be the first post-merge upgrade (e.g. with cleanups/enabling withdrawals/activating some EIPs if Shanghai doesn’t happen, etc.).
My 2 wei:
I would prefer we stick to devcon names only until the “The Merge” hard fork at which point we switch to star names only. If a fork has no features and is executed just to delay the bomb, I’m fine to go with a 2-word name since we did set the precedence with Muir Glacier.
I feel rather strongly that the official name of “The Merge” should not be “The Merge”. I don’t care how people refer to it, but I think the official name should be a “B-star” star name and we follow that new convention for all future forks.
It wasn’t called “Launch Fork” when Ethereum initially launched!
1 Like
My 3 wei:
Alternatively, if we stick with a city, I propose Budapest which started as the twin cities Buda and Pest merged together.
1 Like
I would vote for
- Merge - “The Merge”
- Difficulty bomb only - 2 word name (eg. Arctic Glacier)
Other proposals for different upgrades are
- Only change the execution layer - next Devcon city name (Shanghai)
- Only change the consensus layer - next Star name (eg Baham)
- Change both execution and consensus layer software - (Baham Shanghai or Shanghai Baham).
I think following an agreed-upon convention will help the rest of the community to follow what to expect with the upcoming upgrade.
I like the combination a lot (option 3). I think devcon city names will run out especially if Coronavirus continues to be a thing. But what I do like in the overall theme here, is a notion of execution layer having names that are down here on earth and consensus layer being a higher up abstraction having names up high in space. I think it’s important that one can almost deduct immediately by the name of the hard fork which layer it is intended for. A self branding mechanism.
2 Likes
Can’t deny the possibility but we have got at least 4 names (at least next four execution layer upgrades are covered, approx. next 2 years) - Shanghai, Cancun, Prague, Osaka.
We never know after that we move to Eth3 with Galaxies name 
100%
I’m suggesting Toronto, partly out of Canadian pride. It makes sense as the city where the ETH whitepaper was written. I think its a shame that ETH’s Canadian roots aren’t mentioned. It makes sense that the city at the start marks the largest milestone.
In the alternative I’d suggest Ottawa. It was the city chosen as the capital when the two colonies merged into the Province of Canada and is located in the same province as where ETH was proposed.
PS: Also everyone likes Canada so Canadian cities cause the least controversy.
For the merge specifically, I’d support Virgil.
At the concrete level, I think it’s a pretty clear, and important.
I don’t feel we should shy away from that, and in retrospect I’d be proud of a community that stands up for it’s values.
As a defensible abstract-symbolic reason detached from the political, Virgil guided Dante through hell to Paradise. The transition from Froniter to Serenity speaks similarly.
My other suggestions of lesser conviction follow:
The Argo.
Argo is a constellation, though a two-word name is a departure from Beacon Chain naming convention thus far. It sounds similar enough to ‘The Merge’, though the symbolic meaning is a reference to a great journey, or rather, the ship that carries the journey.
Budapest.
For the reasons presented by others, though as much as I love devcon city names, I suppose a question is whether “Metropolis continues into Serenity”. Execution changes feel ‘concrete’ as cities do. People have connections to cities, and the message of “cities around the world” as a theme is a vehicle for propagation of (early Ethereum) values.
I’ve also been calling the big event The Merge for a long while now and agree with @MariusVanDerWijden that we might as well keep calling it that.
The actual Network Upgrade should have an official name. I think it should be a city at the confluence of two rivers. I suggest Geneva.
I’m happiest with stars after that.