EIP-233: Formal process of hard forks

Metadata

Status: StagnantMetaCreated: 2017-03-23

Authors

Alex Beregszaszi (@axic)

Links

GitHub page Discussion on Ethereum Magicians

Abstract

To describe the formal process of preparing and activating hard forks.

Motivation

Today discussions about hard forks happen at various forums and sometimes in ad-hoc ways.

Specification

A Meta EIP should be created and merged as a Draft as soon as a new hard fork is planned.

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:

Hard deadline to accept proposals for this hard fork
Soft deadline for major client implementations
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. The EIP must be published as at least Draft. It enters the Proposed EIPs section, along with at least one person who is a point of contact for wanting to include the EIP.

EIPs can move states by discussion done on the "All Core Devs Meetings":

If accepted for a hard fork, the EIP should be moved to the Accepted EIPs section. If the EIP has major client implementations and no security issues by the timeline date, it is scheduled for inclusion.
If rejected from a hard fork, the EIP should be moved to the Rejected 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.

Template

A template for the Istanbul Hardfork Meta 1679 is included below (source file on GitHub):

Rationale

A meta EIP for coordinating the hard fork should help in visibility and traceability of the scope of changes as well as provide a simple name and/or number for referring to the proposed fork.

Copyright