DCIPs/eip-233.md at 58b766a9239b34a0ac2934744f6d5124a1ba7c54

3.6 KiB

Raw Blame History

eip	title	author	discussions-to	type	status	created
233	Formal process of hard forks	Alex Beregszaszi (@axic)	https://ethereum-magicians.org/t/eip-233-formal-process-of-hard-forks/1387	Meta	Stagnant	2017-03-23

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

{% raw %}
---
eip: 1679
title: "Hardfork Meta: Istanbul"
author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn)
type: Meta
status: Draft
created: 2019-01-04
requires: 1716
---

## Abstract

This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul.

## Specification

- Codename: Istanbul
- Activation: TBD

### Included EIPs

- TBD

### Accepted EIPs

- TBD

### Rejected EIPs

- TBD

### Proposed EIPs

- TBD

## Timeline

* 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul"
* 2019-07-19 (Fri) soft deadline for major client implementations
* 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet)
* 2019-10-16 (Wed) projected date for mainnet upgrade ("Istanbul")

## References

- TBD (e.g. link to Core Dev notes or other references)

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

{% endraw %}

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.

3.6 KiB Raw Blame History