forked from DecentralizedClimateFoundation/DCIPs
217 lines
10 KiB
Markdown
217 lines
10 KiB
Markdown
---
|
|
eip: 1872
|
|
title: Ethereum Network Upgrade Windows
|
|
author: Danno Ferrin (@shemnon)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-1872-ethereum-network-upgrade-windows/2993
|
|
status: Stagnant
|
|
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](../LICENSE.md).
|