From 290682df42b79d5e154fbeea3c29d6599fa9942c Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 3 Feb 2020 22:41:35 -0800 Subject: [PATCH 1/6] Added ToC and Hardfork Sections 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 | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 1c833757c3d47..250cabfb89a20 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -13,6 +13,26 @@ updated: 2015-12-07, 2016-02-01, 2018-03-21, 2018-05-29, 2018-10-17, 2019-05-19, EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions. +## Table of Contents + +- EIP Submissions + - [EIP Design Rational](#eip-rationale) + - [EIP Types](#eip-types) + - [EIP Work Flow](#eip-work-flow) + - EIP Format and Style Guide + - [Requirements](#what-belongs-in-a-successful-eip) + - Format + - [Template](#eip-formats-and-templates) + - [Header](#eip-header-preamble) + - [Auxiliary Files](#auxiliary-files) + - EIP Best Practices + - [Transfering Ownership](#transferring-eip-ownership) + - [EIP Editors](#eip-editors) + - [Hardfork Meta](#hardfork-meta) + - [Ethereum Hardforks](#ethereum-hardforks) + - [EIP Centric Model](#eip-centric-model) + - [History](History) + ## EIP Rationale We intend EIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. @@ -266,6 +286,12 @@ 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 + +### Ethereum Hardforks + +### EIP Centric Model + ## History This document was derived heavily from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors. From 791ea004723842b84e4ae59c4d37829e8ac43707 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 3 Feb 2020 22:46:19 -0800 Subject: [PATCH 2/6] Typo --- EIPS/eip-1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 250cabfb89a20..19955ddb0fe7d 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -31,7 +31,7 @@ EIP stands for Ethereum Improvement Proposal. An EIP is a design document provid - [Hardfork Meta](#hardfork-meta) - [Ethereum Hardforks](#ethereum-hardforks) - [EIP Centric Model](#eip-centric-model) - - [History](History) + - [History](#history) ## EIP Rationale From c56e992586b027e45bca0770b545f3407a838a00 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 3 Feb 2020 23:53:09 -0800 Subject: [PATCH 3/6] Added Section including Hardforks and the EIP Centric Forking Model. --- EIPS/eip-1.md | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 19955ddb0fe7d..6159a7d3f681a 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -288,10 +288,77 @@ The editors don't pass judgment on EIPs. We merely do the administrative & edito ## Hardfork Meta +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. + +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. + +This EIP should contain: + - the desired codename of the hard fork, + - activation block number once decided + - a timeline section + - an EIPs to include section + - the Requires header should point to the previous hard fork meta EIP. + +The draft shall be updated with summaries of the decisions around the hard fork. + +##### 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 +- Projected date for mainnet upgrade (the activation block number / projected date for this block) + +#### EIP Inclusion Process +Anyone that wishes to propose a Core EIP for the hard fork should make a PR against the Meta EIP representing the hard fork. For an EIP to be considered it must follow the EIP centric model defined later in this document and must be published in at least `DRAFT` status. It enters the Proposed EIPs section, along with at least one person who is the champion for that EIP. + +EIPs can move along this process by participating in discussions on the “All Core Devs Meetings”: +- If accepted for a hard fork, the EIP should be moved to the Accepted EIPs section. +- Once the EIPs in the Accepted EIPs section have successfully launched on a testnet roll out, they are moved to the Included EIPs section. + +The Meta EIP representing the hard fork should move in to the Accepted state once the changes are frozen (i.e. all referenced EIPs are in the Accepted state) and in to the Final state once the hard fork has been activated. + ### Ethereum Hardforks + - Genesis Block *block 1* + - [Homestead](https://eips.ethereum.org/EIPS/eip-606) *block 1_150_000* + - [Spurious Dragon](https://eips.ethereum.org/EIPS/eip-607) *block 2_675_000* + - [Byzantium](https://eips.ethereum.org/EIPS/eip-609) *block 4_370_000* + - [Constantinople](https://eips.ethereum.org/EIPS/eip-1013) *block 7_280_000 + - [Istanbul](https://eips.ethereum.org/EIPS/eip-1679) *block 9_069_000 + - [Muir Glacier](https://eips.ethereum.org/EIPS/eip-2387) *block 9_200_000 ### EIP Centric Model +The EIP centric forking model defines the approval process for any EIP to be included in a hardfork or network upgrade. + +The pipeline for Core EIPs is as follows. + +`[ 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. + +#### 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. + +[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. + +The requirements for **Eligible for Inclusion** is that the AllCoreDevs, representing the major clients and ecosystem stakeholders etc: + + - Are positive towards the EIP, + - Would accept (well written) PRs to include the EIP into the codebase. + - So that it could be toggled on for testing… + - …but not with an actual block number for activation + +*Motivation* +Development of clear specifications and pull requests to existing Ethereum Clients is a large investment of time and resources. The state of **Eligible for Inclusion** is a signal from the Ethereum Core Developers to an EIP Author validiating the idea behind an EIP and confirms investing their time further development is worthwhile. + +References +- Original EIP Centric Forking Model Proposal by @holiman - https://notes.ethereum.org/@holiman/S1ELAYY7S?type=view + ## History This document was derived heavily from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors. From d77e124ecc7d40d6a3e08959240ff88fda9c9d31 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 3 Feb 2020 23:54:36 -0800 Subject: [PATCH 4/6] Formating --- EIPS/eip-1.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 6159a7d3f681a..c129a174a6bc6 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -326,9 +326,9 @@ The Meta EIP representing the hard fork should move in to the Accepted state onc - [Homestead](https://eips.ethereum.org/EIPS/eip-606) *block 1_150_000* - [Spurious Dragon](https://eips.ethereum.org/EIPS/eip-607) *block 2_675_000* - [Byzantium](https://eips.ethereum.org/EIPS/eip-609) *block 4_370_000* - - [Constantinople](https://eips.ethereum.org/EIPS/eip-1013) *block 7_280_000 - - [Istanbul](https://eips.ethereum.org/EIPS/eip-1679) *block 9_069_000 - - [Muir Glacier](https://eips.ethereum.org/EIPS/eip-2387) *block 9_200_000 + - [Constantinople](https://eips.ethereum.org/EIPS/eip-1013) *block 7_280_000* + - [Istanbul](https://eips.ethereum.org/EIPS/eip-1679) *block 9_069_000* + - [Muir Glacier](https://eips.ethereum.org/EIPS/eip-2387) *block 9_200_000* ### EIP Centric Model From 27f99dc82575fdef589c4e5819dfeadb54cba1a2 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 10 Feb 2020 08:27:58 -0800 Subject: [PATCH 5/6] Updates based on Feedback --- EIPS/eip-1.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index c129a174a6bc6..f3608117735cc 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -309,7 +309,7 @@ The draft shall be updated with summaries of the decisions around the hard fork. ##### 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 +- Projected date for testnet network upgrades - Projected date for mainnet upgrade (the activation block number / projected date for this block) #### EIP Inclusion Process @@ -336,15 +336,15 @@ The EIP centric forking model defines the approval process for any EIP to be inc The pipeline for Core EIPs is as follows. -`[ DRAFT ] -> [ ELLIGLE FOR INCLUSION ] -> [ IMPLEMENTATION ] -> [ TESTING ] -> [ ACCEPTED ] -> [ DEPLOYED ]` +`[ DRAFT ] -> [ ELLIGLE FOR INCLUSION ] -> [ IMPLEMENTATION ] -> [ TESTING ] -> [ ACCEPTED ] -> [ LAST_CALL ] -> [ 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. #### 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. +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. -[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. The requirements for **Eligible for Inclusion** is that the AllCoreDevs, representing the major clients and ecosystem stakeholders etc: From cbe1cf316ee2f9a2bc9cc565474ba7a42e407aab Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 10 Feb 2020 08:36:59 -0800 Subject: [PATCH 6/6] Updated to Network Upgrades --- EIPS/eip-1.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index f3608117735cc..330046e52d6eb 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -28,8 +28,8 @@ EIP stands for Ethereum Improvement Proposal. An EIP is a design document provid - EIP Best Practices - [Transfering Ownership](#transferring-eip-ownership) - [EIP Editors](#eip-editors) - - [Hardfork Meta](#hardfork-meta) - - [Ethereum Hardforks](#ethereum-hardforks) + - [Network Upgrade Meta](#network-upgrade-meta) + - [Ethereum Network Upgrades](#ethereum-network-upgrades) - [EIP Centric Model](#eip-centric-model) - [History](#history) @@ -286,7 +286,7 @@ 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 +## Network Upgrade Meta 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. @@ -321,7 +321,7 @@ EIPs can move along this process by participating in discussions on the “All C The Meta EIP representing the hard fork should move in to the Accepted state once the changes are frozen (i.e. all referenced EIPs are in the Accepted state) and in to the Final state once the hard fork has been activated. -### Ethereum Hardforks +### Ethereum Network Upgrades - Genesis Block *block 1* - [Homestead](https://eips.ethereum.org/EIPS/eip-606) *block 1_150_000* - [Spurious Dragon](https://eips.ethereum.org/EIPS/eip-607) *block 2_675_000*