It means cat's elbow and is a tiny village in germany
I like Alexandria
For some practical reasons I also prefer:
- Single word name, so not
StPetersburgnorConstantinopleFix. - The name that does not use the same first letter as previous / next upgrades.
:)
taking into account that Constantinople and Byzantium were the names of the same city which is Istanbul nowadays it would keep it meaningful
(obviously any name would do - I would keep Alexandria for the big Eth 2.0 Lighthouse release)
@chfast I guess that is ultimately up to each client and the nets it wants to support. A client that wants to support Ropsten would support transitioning from Byzantium > Constantinople > Petersburg
For mainnet, I guess we all agree that at no point in time, there will be a transaction executed under the Constantinople rules. My understanding is that geth plans to configure Constantinople and Petersburg to activate on the same blocknumber for the mainnet. But that seems like an implementation detail of geth. At the end of the day, what matters is that no transaction on mainnet would be executed under these rules.
<Frank> @5chdn Not necessarily. It turns out there is a county of Szilagyi https://en.wikipedia.org/wiki/Szilágy_County so we could actually go for Zilah, the capital.
Which Eth Magicians topic is the “live” and correct one for the future hardfork process. EEP-5 (https://ethereum-magicians.org/t/eep-5-ethereum-hardfork-process-request-for-collaboration/2305/4) or EIP-233 (https://ethereum-magicians.org/t/eip-233-formal-process-of-hard-forks/1387/5)?
Protocol updates could follow the practice of "release candidate" within the semantic numbering scheme. And these clever release names, this is over-arching for the upgrade initiative and sticks once it stabilizes on mainnet. Constantinople is what you are attempting to get mainnet to.
So what you attempted to release was ethereum-8.0.0-rc1, released to the testnets and prepared for mainnet. An issue was found, therefore rc1 was aborted. The main network remains at ethereum-7.x.x. Now you proceed with ethereum-8.0.0-rc2, first on ropsten, etc, and then attempt to release to mainnet.
The "release candidate" approach allows you to keep attempting to get from 7.x.x to 8.0.0, by incrementing the x in 8.0.0-rcx. It allows you to not have to worry about the name, which is marketing and communication to the wider community. Once a stable rc-x happens on mainnet, well, IMO that is what becomes "Constantinople". LMK what you think @chfast and @cburgdorf.
I’m in favor of the “Constantinople has EIP-1283” approach and that a fork to remove EIP-1283 is a differnt fork, that should get a new name and probably a new EIP. The standard I would think should apply is that once an AllCoreDevs decision has been made to deploy a fork to a testnet that then contents and semantics of the fork are frozen and immutable, much like a transaction that has been published on a blockchain. You can change it later to fix things, but it’s a different change. #ForkPetersburg
Semantic versioning I don’t think is a good idea because software is much easier to publish, ship, and interchange. Ethereum network upgrades happen once or twice a year. Client software gets released tens to hundreds of times a year.
Little late to the party..
@jpitts I believe what you are proposing is more or less what I also proposed before. I would rephrase it as: What is currently live on Rinkeby, Ropsten, Kovan, Görli and xDAI is further on referred to as ConstantinopleRC1 and the next fork that is planned to go live on mainnet Feb 27th will be referred to as Constantinople.
But I'm under the impression @5chdn (and others) feels kinda strongly that we can not reuse the name Constantinople for that upcoming fork and should continue to use this name for the rules that are currently live on these other nets.
The one thing about using an entirely new name such as
Petersburg is that it might cause confusion in the wider ecosystem.
So, I'm personally on board to rename what is currently live to
ConstantinopleRC1 or FallenConstantinople or whatever else to let us set free the name Constantinople for the 2nd attempt. However, I'm lacking the experience of e.g. @5chdn so I might be underestimating other troubles that such move may cause.
I do not feel strongly either way.
The community is going to get very confused if the name changes too much and IMO a name advance is only for major increments, i.e. forking changes on mainnet. But devs and operators perhaps need specific, numbered versioning in order to reason about what is added, removed, what is actually deployed.
In this case of deploying Constantinople, if the content of EIPs or set of EIPs changes, then this would be reflected in the rcx. Client software targets these, with their own versioning preserved. Each testnet with a failed release would have a specific 8.0.0-rcx running, and clearly known what protocol is deployed there.
My concern with recycling Constantinople and not using a distinct name is that end users will only do cursory web searches and be 'OMG! My chain the Constantinople fork and that is the one with the security issue!’ and saying we renamed the broken one won’t change the number of press articles already written. So
ConstantinopleFixed or ConstantinopleV2 would help with deliniating rather than trying to back in time and double spending a code name.
You do have a good point; lacking more clarity in the current situation, now and in the near future "Constantinople" can be misunderstood. Later on, if versions are employed and communicated in articles users may be better informed about this (e.g. Constantinpole 8.0.0-rc1 presents problems for some contracts, but 8.0.0-rc2 which became 8.0.0 addressed that).
The big problem with any form of renaming of already deployed fork is that it affects the contents of genesis configs which specify which block that fork starts at by name. RC numbering has a similar problem in that once you deploy RC1 to Ropsten you have to continue to support HardForkRC1 as an alias for HardFork even if, as is usual, there are no changes. It’s quite confusing to have multiple names for the exact same thing.
It's really very easy.
Constantinople:
- EIP-145
- EIP-1014
- EIP-1052
- EIP-1234
- EIP-1283
St. Petersfork:
- disable EIP-1283
Constantinople + St. Petersfork
- EIP-145
- EIP-1014
- EIP-1052
- EIP-1234
It's fine if media reports about Constaninople, but we all need to acknowledge as engineers that it's more than Constantinople, even though, in the sum, it's less.
We don't need to rename the entire thing and go on TV Shows talking about Peter's fork or whatever. But we need some internal label to distinguish the differences.
Good notion to wrap the new set of changes in a HF Meta EIP, so the idea is to create a new one for each "attempt"? I def. think the history of an attempt or candidate on the testnets should be documented. In the scheme I have in mind, any increment of x.x.x-rcx would mean that it represents a new attempt to get mainnet to 8.0.0, and is a fork, perhaps deployed to testnets but not deployed on mainnet.
In this numbering scheme I would also position the St. Petersfork as a 7.x.x PATCH https://semver.org, if depicted at all. This is because the change would not advance the target network to 8.0.0.
I don’t think semver is a good model becaue every hard fork would be a major change that is not backwards compatible. We may as well just use a single number. The closest would be that the numbers would be <hard fork>.<soft fork> and Eth doesn’t do many soft forks. If we have to touch the difficulty bomb it’s automatically a hard fork.
I am submitting another vulnerability now.