DCIPs/EIPS/eip-233.md

119 lines
3.6 KiB
Markdown

---
eip: 233
title: Formal process of hard forks
author: Alex Beregszaszi (@axic)
discussions-to: https://ethereum-magicians.org/t/eip-233-formal-process-of-hard-forks/1387
type: Meta
status: Stagnant
created: 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](https://github.com/ethereum/pm/)":
- 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](./eip-1679.md) is included below ([source file on GitHub](./eip-1679.md)):
```
{% 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.
## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).