mirror of https://github.com/status-im/EIPs.git
EIP-1872: Ethereum Network Upgrade Windows (#1872)
This commit is contained in:
Danno Ferrin
Nick Savers
parent
4e169dcb6e
commit
e86ff4d817
|
|
@ -0,0 +1,217 @@
|
|||
---
|
||||
eip: 1872
|
||||
title: Ethereum Network Upgrade Windows
|
||||
author: Danno Ferrin (@shemnon)
|
||||
discussions-to: https://ethereum-magicians.org/t/eip-ethereum-network-upgrade-windows/
|
||||
status: Draft
|
||||
type: Meta
|
||||
created: 2018-03-25
|
||||
---
|
||||
|
||||
## Simple Summary
|
||||
|
||||
A proposal to define a limited number of annual time windows in which network
|
||||
upgrades (aka hard forks) should be performed within. Policies for scheduling
|
||||
network upgrades outside these windows are also described.
|
||||
|
||||
## Abstract
|
||||
|
||||
Four different weeks, spaced roughly evenly throughout the year, are targeted
|
||||
for network upgrades to be launched. Regular network upgrades should announce
|
||||
their intention to launch in a particular window early in their process and
|
||||
choose a block number four to six weeks prior to that window. If a network
|
||||
upgrade is cancelled then it would be rescheduled for the next window. Not all
|
||||
windows will be used. Priority upgrades outside the roadmap may be scheduled in
|
||||
the third week of any month, but such use is discouraged. Critical upgrades are
|
||||
scheduled as needed.
|
||||
|
||||
## Motivation
|
||||
|
||||
The aim of this EIP is to provide some level of regularity and predictability to
|
||||
the Ethereum network upgrade/hard fork process. This will allow service
|
||||
providers such as exchanges and node operators a predictable framework to
|
||||
schedule activities around. This also provides a framework to regularize the
|
||||
delivery of network upgrades.
|
||||
|
||||
## Specification
|
||||
|
||||
Scheduling is defined for three categories of network upgrades. First are
|
||||
`Roadmap` network upgrades that include deliberate protocol improvements. Next
|
||||
are `Priority` network updates, where there are technical reasons that
|
||||
necessitate a prompt protocol change but these reasons do not present a systemic
|
||||
risk to the protocol or the ecosystem. Finally, `Critical` network upgrades are
|
||||
to address issues that present a systemic risk to the protocol or the ecosystem.
|
||||
|
||||
### Roadmap Network Upgrades
|
||||
|
||||
Roadmap network upgrades are network upgrades that are deliberate and measured
|
||||
to improve the protocol and ecosystem. Historical examples are Homestead,
|
||||
Byzantium, and Constantinople.
|
||||
|
||||
Roadmap network upgrades should be scheduled in one of four windows: the week
|
||||
with the third Wednesday in January, April, July, and October. When initiating a
|
||||
network upgrade or early in the planning process a particular window should be
|
||||
targeted.
|
||||
|
||||
> **Note to reviewers:** The months and week chosen are to provide an initial
|
||||
> recommendation and are easily modifiable prior to final call. They thread the
|
||||
> needle between many third quarter and fourth quarter holidays.
|
||||
|
||||
Implementors are expected to have software for a Roadmap network upgrade ready
|
||||
two to four weeks prior to the upgrade. Hence a block number for the network
|
||||
upgrade should be chosen four to six weeks prior to the network upgrade window.
|
||||
Scheduling details such as whether this choice is made prior to or after testnet
|
||||
deployment are out of scope of this EIP.
|
||||
|
||||
Depending on the release cadence of Roadmap network upgrades some windows will
|
||||
not be used. For example if a six month release cadence is chosen a roadmap
|
||||
upgrade would not occur in adjacent upgrade windows. Hence for a six month
|
||||
cadence if a roadmap upgrade occurred in April then the July window would not be
|
||||
used for network upgrades.
|
||||
|
||||
If a planned roadmap upgrade needs to be rescheduled then strong consideration
|
||||
should be given to rescheduling the upgrade for the next window in three months
|
||||
time. For the case of a six month cadence this may cause releases to be in
|
||||
adjacent release windows. For a three month cadence the next network upgrade
|
||||
would be merged with the current upgrade or the next network upgrade would be
|
||||
delayed.
|
||||
|
||||
To be compatible with the scheduled release windows the cadence of the Roadmap
|
||||
Network Upgrades should be a multiple of three months. Whether it is three, six,
|
||||
nine, or more month cadence is out of scope of this EIP.
|
||||
|
||||
### Priority Network Upgrades
|
||||
|
||||
Priority network upgrades are reserved for upgrades that require more urgency
|
||||
than a roadmap network upgrade yet do not present a systemic risk to the network
|
||||
or the ecosystem. To date there have been no examples of a priority upgrade.
|
||||
Possible examples may include roadmap upgrades that need to occur in multiple
|
||||
upgrades or for security risks that have a existing mitigation in place that
|
||||
would be better served by a network upgrade. Another possible reason may be to
|
||||
defuse the difficulty bomb due to postponed roadmap upgrades.
|
||||
|
||||
Priority network upgrades are best launched in unused roadmap launch windows,
|
||||
namely the third week of January, April, July, and October. If necessary they
|
||||
may be launched in the third week of any month, but strong consideration and
|
||||
preference should be given to unused roadmap launch windows.
|
||||
|
||||
Priority network upgrades should be announced and a block chosen far enough in
|
||||
advance so major clients implementors can release software with the needed block
|
||||
number in a timely fashion. These releases should occur at least a week before
|
||||
the launch window. Hence priority launch windows should be chosen two to four
|
||||
weeks in advance.
|
||||
|
||||
### Critical Network Upgrades
|
||||
|
||||
Critical network upgrades are network upgrades that are designed to address
|
||||
systemic risks to the protocol or to the ecosystem. Historical examples include
|
||||
Dao Fork, Tangerine Whistle, and Spurious Dragon.
|
||||
|
||||
This EIP provides neither guidance nor restrictions to the development and
|
||||
deployment of these emergency hard forks. These upgrades are typically launched
|
||||
promptly after a solution to the systemic risk is agreed upon between the client
|
||||
implementors.
|
||||
|
||||
It is recommended that such upgrades perform the minimum amount of changes
|
||||
needed to address the issues that caused the need for the Critical network
|
||||
upgrade and that other changes be integrated into subsequent Priority and
|
||||
Roadmap network upgrades.
|
||||
|
||||
### Network Upgrade Block Number Choice
|
||||
|
||||
When choosing an activation block the number can be used to communicate the role
|
||||
of a particular network in the Ethereum Ecosystem. Networks that serve as a
|
||||
value store or are otherwise production grade have different stability concerns
|
||||
than networks that serve as technology demonstration or are explicitly
|
||||
designated for testing.
|
||||
|
||||
To date all Mainnet activation blocks have ended in three or more zeros,
|
||||
including Critical Network Upgrades. Ropsten and Kovan initially started with
|
||||
three zeros but switched to palindromic numbers. Rinkeby has always had
|
||||
palindromic activation blocks. Goerli has yet to perform a network upgrade.
|
||||
|
||||
To continue this pattern network upgrade activation block numbers for mainnet
|
||||
deployments and production grade networks should chose a number whose base 10
|
||||
representation ends with three or more zeros.
|
||||
|
||||
For testnet and testing or development grades network operators are encouraged
|
||||
to choose a block activation number that is a palindrome in base 10.
|
||||
|
||||
Block numbers for Roadmap and Priority network upgrades should be chosen so that
|
||||
it is forecast to occur relatively close to Wednesday at 12:00 UTC+0 during the
|
||||
launch window. This should result in an actual block production occurring
|
||||
sometime between Monday and Friday of the chosen week.
|
||||
|
||||
## Rationale
|
||||
|
||||
The rationale for defining launch windows is to give business running Ethereum
|
||||
infrastructure a predictable schedule for when upgrades may or may not occur.
|
||||
Knowing when a upgrade is not going to occur gives the businesses a clear time
|
||||
frame within which to perform internal upgrades free from external changes. It
|
||||
also provides a timetable for developers and IT professionals to schedule time
|
||||
off against.
|
||||
|
||||
## Backwards Compatibility
|
||||
|
||||
Except for the specific launch windows the previous network upgrades would have
|
||||
complied with these policies. Homestead, Byzantium, and Constantinople would
|
||||
have been Roadmap Network Upgrades. There were no Priority Network Upgrades,
|
||||
although Spurious Dragon would have been a good candidate. Dao Fork was a
|
||||
Critical Network Upgrade in response to TheDao. Tangerine Whistle and Spurious
|
||||
Dragon were critical upgrades in response to the Shanghai Spam Attacks.
|
||||
Constantinople Fix (as it is termed in the reference tests) was in response to
|
||||
the EIP-1283 security issues.
|
||||
|
||||
If this policy were in place prior to Constantinople then the initial 2018
|
||||
launch would likely have been bumped to the next window after the Ropsten
|
||||
testnet consensus failures. The EIP-1283 issues likely would have resulted in an
|
||||
out of window upgrade because of the impact of the difficulty bomb.
|
||||
|
||||
<!-- ## Test Cases -->
|
||||
<!-- no test cases are relevant for this EIP -->
|
||||
|
||||
## Implementation
|
||||
|
||||
The windows in this EIP are expected to start after the Istanbul Network
|
||||
upgrade, which is the next planned Roadmap upgrade. Istanbul is currently slated
|
||||
for mainnet launch on 2019-10-16, which is compatible with the schedule in this
|
||||
EIP.
|
||||
|
||||
The Roadmap Upgrade windows starting with Istanbul would be as follows:
|
||||
|
||||
| Block Target | Launch Week Range |
|
||||
| ------------ | ------------------------ |
|
||||
| 2019-10-16 | 2019-10-14 to 2019-10-18 |
|
||||
| 2020-01-15 | 2020-01-13 to 2020-01-17 |
|
||||
| 2020-04-15 | 2020-04-13 to 2020-04-17 |
|
||||
| 2020-07-15 | 2020-07-13 to 2020-07-17 |
|
||||
| 2020-10-21 | 2020-10-19 to 2020-10-23 |
|
||||
| 2021-01-20 | 2021-01-18 to 2021-01-22 |
|
||||
| 2021-04-21 | 2021-04-19 to 2021-04-23 |
|
||||
| 2021-07-21 | 2021-07-19 to 2021-07-23 |
|
||||
| 2021-10-20 | 2021-10-18 to 2021-10-22 |
|
||||
| 2022-01-19 | 2022-01-17 to 2022-01-21 |
|
||||
| 2022-04-20 | 2022-04-18 to 2022-04-22 |
|
||||
| 2022-07-20 | 2022-07-18 to 2022-07-22 |
|
||||
| 2022-10-19 | 2022-10-17 to 2022-10-21 |
|
||||
|
||||
The Priority windows through next year, excluding Roadmap windows, are as
|
||||
follows:
|
||||
|
||||
| Block Target | Launch Week Range |
|
||||
| ------------ | ------------------------ |
|
||||
| 2019-11-20 | 2019-11-18 to 2019-11-22 |
|
||||
| 2019-12-18 | 2019-12-16 to 2019-12-20 |
|
||||
| 2020-02-19 | 2020-02-17 to 2020-02-21 |
|
||||
| 2020-03-18 | 2020-03-16 to 2020-03-20 |
|
||||
| 2020-05-20 | 2020-05-18 to 2020-05-22 |
|
||||
| 2020-06-17 | 2020-06-15 to 2020-06-19 |
|
||||
| 2020-08-19 | 2020-08-18 to 2020-08-21 |
|
||||
| 2020-09-16 | 2020-09-14 to 2020-09-18 |
|
||||
| 2020-11-18 | 2020-11-16 to 2020-11-20 |
|
||||
| 2020-12-16 | 2020-12-14 to 2020-12-18 |
|
||||
|
||||
## Copyright
|
||||
|
||||
Copyright and related rights waived via
|
||||
[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
Loading…
Reference in New Issue