Added Table of Contents to EIP-1 and a section for Hardforks and the EIP-Centric Model #2508
Conversation
EIP-1 Is fairly large and unwieldy. It is useful as the source of truth for the EIP process and governance. This Adds a Table of Context to make navigating easier.
EIPS/eip-1.md
Outdated
| - [Transfering Ownership](#transferring-eip-ownership) | ||
| - [EIP Editors](#eip-editors) | ||
| - [Hardfork Meta](#hardfork-meta) | ||
| - [Ethereum Hardforks](#ethereum-hardforks) |
There was a problem hiding this comment.
Do we want to call them network upgrades?
There was a problem hiding this comment.
Yeah my opinion is to call them network upgrades.
There was a problem hiding this comment.
Upgrade implies the new version is better and the old version is worse. Who decides which is better? That is centralization.
There was a problem hiding this comment.
Not sure I agree. IMO "upgrade" stands for "newer", rather than "better". Lots of examples in traditional software of people "not upgrading because the newer version is worse".
OTOH, "hard fork" implies that there will be a fork, which, for non contentious upgrades, isn't the case. I would phrase the general case as "a network upgrade, which can result in a hard fork if a subset of the community doesn't update their software".
FWIW, "network upgrade" is what is currently used in communications from the EF, see Muir Glacier, Istanbul, Constantinople. Last use of "hard fork" was for Byzantium.
There was a problem hiding this comment.
I'm neutral on this. Technically it is a hard fork, but I can also see that the community has preconceptions about what a hardfork means and it certainly isn't what most people think. To be a hardfork that results in a network split there is a lot of requirements. Contentious hardforks should be called network splits. As far as to call them Network Upgrades vs Hardforks I am open too either.
EIPS/eip-1.md
Outdated
| @@ -266,6 +286,79 @@ Many EIPs are written and maintained by developers with write access to the Ethe | |||
|
|
|||
| The editors don't pass judgment on EIPs. We merely do the administrative & editorial part. | |||
|
|
|||
| ## Hardfork Meta | |||
There was a problem hiding this comment.
I've read this section multiple times, and I think it could be more focused on explaining what the Hardfork Meta EIP is (as it does starting at ### Specification) rather than a general overview of hardforks/upgrades.
TL;DR, explaining that the way we track which EIP goes into upgrades is by the Hardfork Meta EIP, and perhaps linking a few. The discussion about upgrades vs. hardforks feels like it should be another section, and I'm not 100% sure it should be part of EIP-1. See my comment below :-)
There was a problem hiding this comment.
I wrote this section afterwards because I realized without some context it is difficult to understand the section is needed. This is an opportunity to have a source of truth for the community to reference. I don't think it needs to be in great detail, but some information is good to have to keep a 1one-stop place for understanding the EIP process and Ethereum Governance.
Otherwise, someone who is new would google right after, "What is a hardfork?" and learn who knows what from who knows where. Better to give them some grounding before they go off to learn deeper.
| Any changes to clients that effect consensus of the Ethereum Network results in a hardfork (See the `CORE` category of EIPs). There is then a "fork" in the blockchain where one chain follows the updated ruleset. A contentious fork is when a network split occurs because two communities form to continue supporting both the old and the new client codebases simultaneously. A split is not the typical case, as historically most upgrades have been adopted by the network wholly. | ||
|
|
||
| Non-contentious forks, or a Network Upgrades, are part of the standard upgrade process. Core EIPs follow the EIP flow defined previously in EIP-1, are implemented into the client code with a block activation number, and released as a software upgrade to the clients. Node operators upgrade their clients, and at the specified block height, the network upgrade is deployed. |
There was a problem hiding this comment.
I would suggest swapping the order here, because it starts from the exceptional case and then explains the general one.
As mentioned in my previous comment, I think this probably makes the most sense as a standalone section. IMO the gist of it should be:
- For upgrades to happen on Ethereum, all nodes have to run the new software
- Therefore, we bundle consensus changes into upgrades, which follow the Core EIP flow
- At the activation block, the new ruleset comes into effect
- If the community decided not to upgrade, either willingly (for contentious upgrades) or unknowingly (poor comms, not aware of upgrade, etc.), they will be separated from the rest of the network.
- Hence, upgrades can only happen if a significant part of the community runs the updated software. This is the case most of the time, but there is always the possibility of this not happening so we should be mindful of community consensus around changes when proposing upgrades.
There was a problem hiding this comment.
We should just put this instead 👍
|
|
||
| Non-contentious forks, or a Network Upgrades, are part of the standard upgrade process. Core EIPs follow the EIP flow defined previously in EIP-1, are implemented into the client code with a block activation number, and released as a software upgrade to the clients. Node operators upgrade their clients, and at the specified block height, the network upgrade is deployed. | ||
|
|
||
| The following is the specification and definition of the Hard Fork process for Ethereum, governed by the AllCoreDevs Community Calls. |
There was a problem hiding this comment.
IIRC there was some controversy on EthMagcians about whether the process is governed by AllCoreDevs call or by the EIPs repo.
There was a problem hiding this comment.
@fulldecent I think you were the one suggesting it was governed by the repo.
There was a problem hiding this comment.
For CoreEIPs the process is governed by the ACD Call. To get into EFI an EIP needs to be brought up on the ACDs call. To get into a Hardfork you need to first get into EFI. Thus, anything that goes through EFI is explicitly governed by the ACDs Call.
| The following is the specification and definition of the Hard Fork process for Ethereum, governed by the AllCoreDevs Community Calls. | ||
|
|
||
| #### Specification | ||
| A Meta EIP should be created and merged as a Draft in preparation for the hardfork. |
There was a problem hiding this comment.
It could be good to specify when this happens. My guess would be either when a date is tentatively decided or when a single EIP is Accepted. Thoughts?
There was a problem hiding this comment.
I left it out because I don't think we have consensus on when that is yet. There isn't an entirely obvious answer either so it will take some discussion. We should add this to the list of things to clarify and watch what happens with London.
| #### Specification | ||
| A Meta EIP should be created and merged as a Draft in preparation for the hardfork. | ||
|
|
||
| This EIP should contain: |
There was a problem hiding this comment.
Do we have a HF Meta EIP template? Could be a good idea.
There was a problem hiding this comment.
We do, it is rather large, so I am not sure the best way to link it. Perhaps creating a templates folder and putting them in there? Then we could just link to them. Currently, it is sitting in Alex's EIP.
EIPS/eip-1.md
Outdated
| ##### Timeline | ||
| Once a timeline with key dates is agreed upon for other crucial dates. The basic outline of a hardfork timeline should include: | ||
|
|
||
| - Projected date for testnet network upgrade |
|
|
||
| `[ DRAFT ] -> [ ELLIGLE FOR INCLUSION ] -> [ IMPLEMENTATION ] -> [ TESTING ] -> [ ACCEPTED ] -> [ DEPLOYED ]` | ||
|
|
||
| Note that this process is included within the EIP Flow, and so `LAST_CALL` is still observed as part of the higher-order process of EIP finalization. |
There was a problem hiding this comment.
This is a bit unclear. Should we just add LAST_CALL after [ ACCEPTED ] on line 339?
There was a problem hiding this comment.
There is some nuance about where this information is tracked, but I am getting ahead of myself as that is relevant when we have a "staff editing section" in the EIP. Updated with LAST CALL. 👍
EIPS/eip-1.md
Outdated
|
|
||
| #### Eligible for Inclusion | ||
|
|
||
| The first stage, **EFI** (**Eligible for Inclusion**), is where the Core Developers vet the concept of an EIP and give a “green light” sufficient for EIP authors to move forward with development. |
There was a problem hiding this comment.
| The first stage, **EFI** (**Eligible for Inclusion**), is where the Core Developers vet the concept of an EIP and give a “green light” sufficient for EIP authors to move forward with development. | |
| The first stage, **Eligible for Inclusion** (**EFI**), signals that Core Developers are favorable towards the concept of an EIP, and give the EIP authors a "green light" to move forward with development, meaning that if the EIP implementation does not uncover technical issues or community objections, it could be included in a future upgrade. |
There was a problem hiding this comment.
Updated with the suggested text. The thing I would like to be added somehow is one of the big reason this step is important is that the Authors of the EIP get a signal from the CoreDevs to continue working on an idea. There is a lot of work an author needs to do to get an EIP ready and a little validation that his work is not in Vain from the beginning is helpful for them.
EIPS/eip-1.md
Outdated
|
|
||
| The first stage, **EFI** (**Eligible for Inclusion**), is where the Core Developers vet the concept of an EIP and give a “green light” sufficient for EIP authors to move forward with development. | ||
|
|
||
| [EIP 2378](https://eips.ethereum.org/EIPS/eip-2378) is a meta-registry documenting all EIPs marked as **Eligible For Inclusion** by the All Core Devs. Typically to reach this stage, an EIP must be discussed in brief on an AllCoreDevs Call and motioned by rough consenses and added to the registry. Any additions are required to provide a link to the meeting notes when this discussion and decision took place. |
There was a problem hiding this comment.
| [EIP 2378](https://eips.ethereum.org/EIPS/eip-2378) is a meta-registry documenting all EIPs marked as **Eligible For Inclusion** by the All Core Devs. Typically to reach this stage, an EIP must be discussed in brief on an AllCoreDevs Call and motioned by rough consenses and added to the registry. Any additions are required to provide a link to the meeting notes when this discussion and decision took place. | |
| [EIP 2378](https://eips.ethereum.org/EIPS/eip-2378) is a registry documenting all EIPs marked as **Eligible For Inclusion** by the core developers. Typically, to reach this stage, an EIP must be discussed in brief on an AllCoreDevs call, motioned by rough consensus and added to the registry. Any additions are required to provide a link to the meeting notes when this discussion and decision took place. |
| - [Hardfork Meta](#hardfork-meta) | ||
| - [Ethereum Hardforks](#ethereum-hardforks) | ||
| - [Network Upgrade Meta](#network-upgrade-meta) | ||
| - [Ethereum Network Upgrades](#ethereum-network-upgrades) |
There was a problem hiding this comment.
Can we call this list network updates and still put the DAO Hardfork. It should go somewhere but I am not sure where exactly. There have been three types of "Hardforks"
- Upgrades
- Homestead block 1_150_000
- Spurious Dragon block 2_675_000
- Byzantium block 4_370_000
- Constantinople block 7_280_000
- Istanbul block 9_069_000
- Muir Glacier block 9_200_000
- Network Split
- The DAO Hardfork 1,920,000
- Security Patches/Emergency
- Tangerine Whistle 2,463,000
All of them need to be accounted for when creating a client. Petersburg only affects Ropten if I remember correctly.
|
Any updates on this? |
|
Bumping @MadeofTin |
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
I'm going to close this EIP as we have since moved all hardfork coordination stuff out of the EIP repository and into https://github.com/ethereum/eth1.0-specs/. If @MadeofTin wants to reopen this we can, though given recent conversations that seems incredibly unlikely. |
EIP-1 is rather large, but it is useful to have it as a single source of truth for the EIP process and Governance. I created a Table of Contents to make it easier to navigate to the portion that is most relevant to the reader.
I also included:
Much of the content was taken from.
This is part of an effort to unify the definition of the EIP process into one location.