Title: RFC__Post_Merge_Network_Upgrade_Naming_Schemes
Category: Magicians

Author: timbeiko
Date: 2022-12-01T20:06:46.265Z

Happy birthday, beacon chain  : ! Two years after your launch, you’re now successfully serving as the consensus layer for the entire Ethereum network  !

The Merge moved us from “eth1” & “eth2” to a single, unified Ethereum network, but there are still process bits outside the network that need to be harmonized. One of these is naming!
On the execution layer, we’ve been using devcon cities to name upgrades (with a shoutout to EthCC for paris). On the consensus layer, star names are used.
There is value in keeping separate names to identify the specific EL & CL specs corresponding to a specific upgrade, but for end users having a single upgrade with two names is confusing. Luckily, the first time this happened we had “The Merge” we could use in announcements rather than “The Paris/Bellatrix Fork”. But now, we’re looking at “Shanghai/Capella” and “Cancun/???” coming, which are both terrible monikers for upgrades.
I would therefore like to propose moving to a new naming scheme which uses a single term to describe the high-level upgrade (like “The Merge” did) and has related terms to describe the individual EL & CL specs (like Shanghai/Capella). I think a good theme for this is “structures with sub-components”.
For example, you can imagine a naming scheme being “Planets and their stars”, where the planets refer to the high level upgrade (like “The Merge”) and EL and CL releases are each identified with a star name corresponding to this planet. Another theme could be “genus & species” (e.g. the Cavia upgrade with the Aperea EL & Porcellus CL releases)… there are many possibilities here!
Feedback welcome on both the high-level idea and specific suggestions of themes

Author: ajsutton
Date: 2022-12-01T20:42:14.344Z

Adding another layer of name seems like it will just add confusion. I’d suggest we just have a single naming scheme for all upgrades. When both execution and consensus layers upgrade at the same time we just use the same name for both (so the next hard fork would just be Shanghai which is what most people outside of consensus core devs are calling it anyway) - when they’re separate they just take the next name in line.

Author: timbeiko
Date: 2022-12-01T20:59:39.570Z

I’m happy with that if it works for client & testing teams! The one risk I could see is that something, somewhere expects the EL & CL names for an upgrade to be distinct and breaks   if that’s not a concern, then single names work for me just as well 
Also agreed switching after Shanghai would be ideal given the community is already aware of this name.

Author: axic
Date: 2022-12-01T21:23:17.036Z

Out of curiosity, what is the reason the current scheme is not sufficient (for the short/medium term)? We still have Shanghai, Cancun, Prague, Osaka, Bogota to go on the EL side, and unlimited options on the CL side.

Author: timbeiko
Date: 2022-12-01T21:27:28.392Z

The dual names are confusing. We could alternate between cities and stars though! Or even move to one or the other.

Author: ethjoe
Date: 2022-12-01T21:29:47.487Z

By moving on from the current system, we can pay homage to Ethereum’s history, while working toward something unique that can be long-standing, and that meets the goal of representing both layers as “parts of a whole”.
On the first note, the original Ethereum roadmap included the four stages: Frontier, Homestead, Metropolis and Serenity.
Frontier and Homestead were delivered, as was Metropolis, albeit in three stages (Byzantium, Constantinople, Istanbul). The final stages of that original vision included a complete proof-of-stake and sharding. Relatedly, EIP-4844 marks the start of sharding, after Shanghai closes out the PoS upgrade and withdrawals. This makes for a great opportunity to finally close that original chapter.
I’d first propose that the name of Serenity be applied to the EIP-4844 upgrade, marking an end to the celestial naming scheme that’s touched both the original roadmap and the current CL forks, before moving forward to a greener future.
For the future naming scheme proposal, an initial idea was to choose something that reflected the CL/EL, while having a parent-name that solidifies the relationship between two parts of one whole. For example, if one upgrade package was dubbed “Purple”, upgrades within it would consist of two sides, with one layer designated as “Blue” and the other “Red”.
There were a number of potential ideas discussed here (stars, sister cities, rivers), some of which I’ll include below. But these days, one of Ethereum’s unique powers is its ability to continue to develop independently of any original plans and roadmaps, founders, or a few OGs. This natural growth (combined with “garden” mantras that have taken root and the PoS narrative meshing well with a greener/cleaner system) led to exploration of botanical or ecological schemes.
Specifically, I’d propose to make use of families of trees and species within those families to accomplish many of the goals set out above (reflecting on life, ecology, evolution, strength…). There are enough unique families and varieties to apply to upgrades for years or decades to come. Examples, like Fir and Cedar as two sides of a package dubbed “Pinaceae” would do well to convey this natural relationship in a unique way. There’s enough diversity to (a) move in alphabetical order and/or to (b) skip specific species if/when there’s something too odd to include a name, or to (c) include more than two names for upgrades that require multiple steps. Some even come with their own (controversy-free) emojis   !  And on ordering, Latin names can be used as something more neutral if/when English names are less of a fit.
Tl;dr suggestion: After Shanghai, sharding begins with the Serenity upgrade, which pays homage to Ethereum’s history (past and present) and closes an important chapter before moving forward. Going into the future thereafter with something that reflects biodiversity, evolution and connectedness, like tree-species and families, encompasses Ethereum’s natural growth (merkle trees anyone?), uniqueness, diversity, and the green future created by the work put into bringing the Beacon Chain and Merge to life.
–
JS
Initial ideations:
A. Binary Star systems.


Package: System


EL: Star A


CL: Star B


Reasoning against: Celestial names have been used for the CL and by many Cosmos and other chains. We can do more to be original and aligned here.
B. Major Rivers/Cities


Package: Major River (e.g. Nile, Rhine, or Tigris)


EL: City A (e.g. Cairo, Bonn, Baghdad)


CL: City B (e.g. Giza, Cologne, Mosul)


Reasoning against: While this version (suggested by Peri) is my favorite alternative to the above, this suggestion also gets caught in our current city-scheme that’s been used for the better part of a decade. There’s been pushback against flags and nationalism related to upgrades as well.
C. Planets & Largest Moons


Package: Planet (e.g. Mars)


EL: Moon A (e.g. Phobos)


CL: Moon B (e.g. Deimos)


Discussed and suggested by Tim above, this is solid and unique with many options, but continues the celestial track.
Thanks to Tim, Pari, Peter and others for their input!!

Author: axic
Date: 2022-12-01T21:30:56.273Z

Right. I assume it may only confusing when they are rolled out together? Independent updates would not be confusing, but will we get independent updates?

Author: timbeiko
Date: 2022-12-01T21:34:06.248Z

axic:

Independent updates would not be confusing, but will we get independent updates?


Yeah my assumption is coupled will likely be the default, but perhaps that’s wrong. For non emergency updates it seems simpler to bundle testing, releases, etc.

Author: protolambda
Date: 2022-12-01T22:37:03.899Z

We can keep eth conference cities for EL and stars for CL, but just combine them for the short upgrade names where necessary.
Suggestions:
Lontair (Londen + Altair)
Paritrix (Paris + Bellatrix)
Shapella (Shanghai + Capella)
Canubhe (Cancun + Dubhe)
Practra (Prague + Electra)
Dubhe would be my strong preference for star name after Capella: it’s the traditional/formal name for Alpha Ursae Majoris, also known as the “Big Dipper” and “Great Bear”: the ideal name to close a bear market with.
Electra would then be a great follow-up star name: Electra is a star in the Taurus constellation (bull after bear  ).

Author: vgururao
Date: 2022-12-02T03:45:19.182Z

Since consensus layer is the common ground, and execution is like built environment on top of it, perhaps a natural feature of the city…so Shanghai might go with river Huangpu.
Or if the star is common ground natural object, the constellation becomes like the city. So Capella would go with Auriga.
Another option would be to link cities to stars using astrology somehow.

Author: abcoathup
Date: 2022-12-02T07:41:52.757Z

I wanted emojis as a short reference to the name for the memeability, on that basis I thought about animals or the zodiac.
@protolambda’s name blending feels like a winning concept.
It allows the continued Devcon city names (or notable Ethereum cities) for EL upgrades and alphabetical star names for CL upgrades, and nicely links them.
We also can use it now and don’t have to wait for the upgrade after Shapella.
We can use an emoji which fits either the name or the main feature(s) of the upgrade.
 Shapella (Shanghai + Capella)
 Canubhe (Cancun + Duhbe)
 Practra (Prague + Electra)

Author: spalladino
Date: 2022-12-04T22:17:42.987Z

How about gods names from the Greco-Roman pantheon, using the Greek and Roman name for EL and CL? The god’s attribute can be the high-level friendly name. So the Dyonisius/Bacchus update would be affectionately called the Wine one, the Jupiter/Zeus Thunder, and so forth.

Author: abcoathup
Date: 2022-12-07T02:24:05.672Z

spalladino:

Greco-Roman pantheon


I like the idea of tying the EL and CL upgrade names together, but I think we should leave the gods to the gods.  My concern is offending believers and the strong European cultural focus.
EL upgrades continuing to use Devcon (and other prominent Ethereum cities) city names would be representative of Ethereum culture & history, though we need to avoid flags/nationalism.

Author: mkalinin
Date: 2022-12-09T09:35:03.487Z

I like this proposal the most. We should decide a name of which layer to use as the name for the whole thing in the case of two-layer HF. And then keep the same notation as we use to day for spec docs, e.g. Capella for CL, Shanghai for Engine API specs.
Using a mixed name is a good one but I don’t like it because everyone will have to keep three names in mind when talking about two-layer HF.
Note that we will run out of Devcon city names in case of >1 HF per year. Devcons to be happening in locations defined by EL’s HF names is one of potential solutions to this problem.

Author: LukaszRozmej
Date: 2022-12-15T14:45:15.499Z

For D I like Deneb more: Deneb - Wikipedia

Author: mcdee
Date: 2022-12-16T08:26:50.240Z

timbeiko:

I would therefore like to propose moving to a new naming scheme which uses a single term to describe the high-level upgrade (like “The Merge” did) and has related terms to describe the individual EL & CL specs (like Shanghai/Capella). I think a good theme for this is “structures with sub-components”.


Please can we just stick with what we have for the execution and consensus layers?  We already have a history of past names and a plan for future names, so any change will cause disruption and add to the technical debt of the ecosystem.
Naming things is hard, because we don’t know what the future brings so cannot pick something that will work well with future changes (Ethereum is a good example of this).  But consistency brings its own benefits, and reduces the mental load when coming in to the Ethereum space.  Taking the consensus layer as an example, we are now on a path “A,B,C,…” for each hard fork, which makes it very easy for someone coming in to the space to know the ordering of the hard forks.  Execution layer requires a bit of tribal knowledge, but that is now a given and not going to change so the best we can do is not to increase their burden but having multiple systems that happen at different points in time.
As for having a user-facing name for the upgrades, I maintain that the best solution here is to talk about the execution layer name and not the consensus layer.  Anything that is consensus layer-specific is likely to only matter to validators, and they are generally speaking more aware of the difference between the layers and understanding of what is activated when (the BLS to execution change operations are a good example of this).  If we consider users to be those that may generate execution layer transactions, or benefit from execution layer transactions, then the thing they care about is upgrades in the execution layer so that it is what we should be talking about.

Author: merikarhu
Date: 2022-12-16T12:45:26.397Z

Kindly birthday note beacon chain, and the community!
conversations? of a posthumous naming scheme layer. Examples; Hawking,
Name is identity, whether we imagine a planet, city or else. In my mind, I compare updates/upgrades to historical artworks. “Pink. Election” draws pictures of our Consciousness. However; the term and the story behind delegate curiosity via different tenses.
Happy Holidays!
Enzo

Author: abcoathup
Date: 2022-12-18T23:25:06.154Z

A vote for Deneb
https://twitter.com/sproulm_/status/1604430081325436930
Caneb (Cancun + Deneb)

Author: sbacha
Date: 2022-12-22T04:40:25.729Z

Please do not do this this is barely decipherable and will make it difficult for non english speakers.

Author: abcoathup
Date: 2022-12-26T23:24:14.532Z

Associating an emoji per release would hopefully make it easier to identify upgrades, regardless of language.
The Merge (Paris + Bellatrix) 
Shapella (Shanghai + Capella)  ( for withdrOWLs)

Author: Pandapip1
Date: 2022-12-27T15:15:20.886Z

How about instead we create an inline-able image, to differentiate between actual use of an emoji and using it to reference Ethereum upgrades?

Author: abcoathup
Date: 2022-12-27T22:04:54.656Z

Using an emoji then allows for ascii text and other image types to represent the concept.
Lodestar & Nimbus display owls (ascii text) at Capella transition.


github.com/ChainSafe/lodestar








Display owl on capella fork


unstable ← dapplion/owl



          opened 06:01PM - 26 Nov 22 UTC




            dapplion
          



+32
-0






**Motivation**

We need motivation

**Description**

Credit https://twitte…r.com/Renethftw/status/1595451793349255170








github.com/status-im/nimbus-eth2








display owl on Capella transition


unstable ← dev/etan/vl-capella



          opened 10:15PM - 20 Dec 22 UTC




            etan-status
          



+160
-36






Trigger ANSI art on upgrade to Capella, similar to the merge. Future extension c…ould log blinking art when user successfully managed to get BLS to Execution change included into a block for a validator.

Art created by http://beatscribe.com/ (beatscribe#1008 on Discord)

Author: abcoathup
Date: 2022-12-30T20:58:58.717Z

Given that @protolambda is letting go of Duhbe (due to some people having difficulty spelling), it looks like Deneb might be the default winner for the D-starname.
https://twitter.com/protolambda/status/1608870312090955777
 Caneb (Cancun + Deneb)

Author: Pandapip1
Date: 2023-01-04T12:49:55.458Z

Could we perhaps make our own images and get them standardized in unicode? This is partially a joke, and partially a serious proposition.
Alternatively, maybe we can get the Ethereum logo standardized in unicode, and then we can add new ZWJ emoji sequences that, say, combine the Ethereum logo and the owl/swan.
https://www.unicode.org/emoji/proposals.html

Author: timbeiko
Date: 2023-01-13T17:17:06.067Z

protolambda:

We can keep eth conference cities for EL and stars for CL, but just combine them for the short upgrade names where necessary.


It feels like we’ve naturally converged towards this proposal, with people using Shapella (and now Dencun) more and more. Another property that’s nice for this is you can tell by looking at the name whether it’s a CL/EL-only upgrade (star or city) vs. a CL+EL upgrade (combined name).

Author: EvanVanNessEth
Date: 2023-01-14T04:32:28.208Z

3 names is bad.   i would prefer to choose EL or CL names and use that as the overall release name.
also given how few people know star names, i don’t agree with @timbeiko that it’s really that obvious whether shapella is a combined name or a CL name

Author: abcoathup
Date: 2023-01-15T23:00:27.579Z

timbeiko:

(and now Dencun)


EL (first) + CL name would make it: Caneb (Cancun + Deneb).
Though using CL first would make them alphabetical.

Author: Pandapip1
Date: 2023-01-16T14:55:33.344Z

abcoathup:

Though using CL first would make them alphabetical.


What happens after more than 26 hardforks?

Author: abcoathup
Date: 2023-01-17T04:17:04.095Z

Pandapip1:

What happens after more than 26 hardforks?


Start back at A for CL upgrades (every 10 or so years).
Luckily there are a few star names to choose from, so unlikely to run out in the next century.

Author: Pandapip1
Date: 2023-01-17T14:15:11.040Z

Why don’t we start using https://semver.org/ for Ethereum upgrade names, with a mnemonic like https://www.r-project.org/ uses?
Example: Ethereum X.1.0 “Shanghai Capella”
(I’m not sure what the X would be)
Things like gas repricings and the DAO fork would be patches, things like adding opcodes and new transaction types would be minor versions, and things like the merge (since it removed the original functionality of the DIFFICULTY opcode) and any SELFDESTRUCT changes would be major versions.

Author: timbeiko
Date: 2023-01-17T15:08:29.973Z

Pandapip1:

Why don’t we start using https://semver.org/ for Ethereum upgrade names, with a mnemonic like https://www.r-project.org/ uses?


Please no - first, it’s no fun! Fun is a big part of Ethereum - this forum is literally called EthMagicians !
Second, too much confusion with “Ethereum 1.x”, “Ethereum 2.0”, etc. That said, once we’ve cycled through all of the A-Z stars, and have caught up to devcon(nect) cities + all major conferences, I’m fine letting that go. Ethereum should be boring infrastructure by then

Author: sbacha
Date: 2023-02-06T11:57:43.831Z

What about using byte words?


github.com


BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md
# Bytewords: Encoding binary data as English words

## BCR-2020-012

**© 2020 Blockchain Commons**

Authors: Wolf McNally, Christopher Allen<br/>
Date: June 20, 2020<br/>
Revised: October 4, 2020

### Introduction

Schemes like [BIP39] and [SLIP39] (see Appendix) encode a binary string as a series of human-readable words. This proposal specifies a scheme "Bytewords" with similar ends but:

* Encodes a [CBOR] structure tagged with the data type [URTYPES], and is therefore self-describing.
* Uses a dictionary of exactly 256 English words with a uniform word size of 4 letters.
* Only two letters of each word (the first and last) are required to uniquely identify each byte value, making a minimal Bytewords encoding as efficient as hexadecimal (2 characters per byte) and yet less error prone.
* Additionally, words can be uniquely identified by their first three letters or last three letters.
* Representing each byte as a single word simplifies encoder and decoder architecture.
* Minimizing the number of letters for each word simplifies transfer to permanent media such as stamped metal.




  This file has been truncated. show original






Encodes a [CBOR] structure tagged with the data type [URTYPES], and is therefore self-describing.
Uses a dictionary of exactly 256 English words with a uniform word size of 4 letters.
Only two letters of each word (the first and last) are required to uniquely identify each byte value, making a minimal Bytewords encoding as efficient as hexadecimal (2 characters per byte) and yet less error prone.
Additionally, words can be uniquely identified by their first three letters or last three letters.

Author: abcoathup
Date: 2023-03-10T08:02:35.808Z

Discussion for E-star name for next Consensus Layer upgrade