EIPs/EIPS/eip-1872.md

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