Ethereum Network Upgrade Windows

EIPS/eip-1872.md

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