Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Added Table of Contents to EIP-1 and a section for Hardforks and the EIP-Centric Model #2508

Closed
wants to merge 6 commits into from
Closed

Added Table of Contents to EIP-1 and a section for Hardforks and the EIP-Centric Model #2508

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
290682d
Added ToC and Hardfork Sections
MadeofTin Feb 4, 2020
791ea00
Typo
MadeofTin Feb 4, 2020
c56e992
Added Section including Hardforks and the EIP Centric Forking Model.
MadeofTin Feb 4, 2020
d77e124
Formating
MadeofTin Feb 4, 2020
27f99dc
Updates based on Feedback
MadeofTin Feb 10, 2020
cbe1cf3
Updated to Network Upgrades
MadeofTin Feb 10, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 93 additions & 0 deletions EIPS/eip-1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
- [Network Upgrade Meta](#network-upgrade-meta)
- [Ethereum Network Upgrades](#ethereum-network-upgrades)
Copy link
Contributor Author

@MadeofTin MadeofTin Feb 10, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- [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.
Expand Down Expand Up @@ -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.

## 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.

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.
Comment on lines +291 to +293
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should just put this instead 👍


The following is the specification and definition of the Hard Fork process for Ethereum, governed by the AllCoreDevs Community Calls.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC there was some controversy on EthMagcians about whether the process is governed by AllCoreDevs call or by the EIPs repo.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fulldecent I think you were the one suggesting it was governed by the repo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


#### Specification
A Meta EIP should be created and merged as a Draft in preparation for the hardfork.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

@MadeofTin MadeofTin Feb 10, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


This EIP should contain:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a HF Meta EIP template? Could be a good idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- 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 upgrades
- 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 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*
- [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 ] -> [ 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit unclear. Should we just add LAST_CALL after [ ACCEPTED ] on line 339?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 👍


#### Eligible for Inclusion

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 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:

- 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.
Expand Down