Shedding light on the Ethereum Network Upgrade Process
The network upgrades process, phases & tracker explained.
(Extending thanks to James Hancock, Hudson Jameson, Micah Zoltu & Tim Beiko for improvement suggestions.)
With the next upgrade (Berlin) on the horizon, the network upgrade process is in execution. As a result of several brainstorming meetings, the EIPIP group recommended some changes to improve the network upgrade process. My hope with this blog is to share information that can be useful for EIP authors and the community in general. Let’s understand what is the new process and the need for shifting from the existing one which was one of the constantly evolving processes since the inception of the Ethereum blockchain.
What is a network upgrade?
Network upgrades are the way by which new features get added to the Ethereum protocol. Typically, these upgrades aim to bring scalability, UX, and security improvements to the network. Each new feature is thoroughly described in the Ethereum Improvement Proposals (EIP). A network upgrade occurs when, at a certain block height, all nodes on the network agree to activate these new features. Because Ethereum is decentralized and no one can force people to update their nodes, if part of the network decides to not activate the upgrade, it will stop communicating with the nodes that did, leading to a fork in the network.
Why change the process?
Historically, the network upgrade process was entwined with the EIP standardization process. A Core EIP was groomed to be deployed on the main network along with the process of standardization.
Consensus conflict
Ethereum is an open-source community project. For a core proposal to be deployed on the main network, it must be accepted by the community and the core clients (Ethereum nodes). Once an EIP is Accepted by the Ethereum core client developers and the community, then it is scheduled for the upcoming network upgrade.
While Ethereum developers were engaged in preparation for the Istanbul upgrade, a conflict emerged on a core proposal EIP-1057: ProgPoW, a Programmatic Proof-of-Work. This proposal was supported by some, but also faced significant pushback from others. As a result, consensus could not be achieved among the Ethereum clients.
Though the proposal could not move forward with the network upgrade, it did with the EIP standardization and that emphasized the need for decoupling the EIP standardization and network upgrade process.
Significant increase in Core proposals
The earlier process worked fine while the total proposals submitted were smaller in number. The significant increase in contributors to the Ethereum blockchain in the past few years multiplied the number of proposals to be considered for network improvement. The growth led to increased complexity which opened a discussion to design a formal process for the selection of EIPs for a network upgrade.
Transparency
With the increased adoption of the Ethereum chain, multiple contributors aligned to strengthen the network by submitting the Ethereum Improvement Proposal for the network upgrade. A huge amount of effort is put in by every client to implement the changes that are proposed in an EIP. Considering man-hours required for the implementation of every single proposal, not all EIPs (that were proposed) can go in the upcoming upgrade. Ignorance of the process sometimes causes confusion. Therefore updated documentation must be used to increase the transparency of the process.
The contemporary network upgrade process
The existing network upgrade process is a result of numerous brainstorming meetings of the EIPIP group and consistent interaction with Ethereum developers & the community at large.
The present network upgrade process is formally separated from the EIP standardization process. However, the above image also includes the recommended status of EIP at different stages. The process is loosely divided into three phases to indicate the readiness of the proposals for a future upgrade.
Consider For Inclusion
Consider for Inclusion (CFI) applied is the first stage to signal that a proposal is aspiring for the upcoming network upgrade. It is recommended that the author or champion of the proposal create an issue at the Eth1.0-spec repository to announce.
Devnet Phase
In this phase, client developers discuss the proposal to get a consensus to proceed with the implementation of the developers’ testnet (Devnet). It is spun for the client developers and could be used by the community. But, because it can be nuked without any prior information, this testnet is not recommended for testing dapps. The current devnet is the YOLO testnet and an active version is YOLO v2 that contains some of the proposals for the upcoming upgrade.
- CFI approved: This bucket contains the EIPs that obtain rough consensus by clients, and with the submission of well-formed PR, it will be considered by the Core Developers. Clients may independently start implementing the proposals at their convenience.
- CI devnet waiting room: EIPs which received the approval of some clients but not all, or some work is still pending for it to be integrated are listed in the CI devnet waiting room. This may also contain proposals that were included in one version of events but because for some reason is not considered for the next version of the CI devnet.
- CI devnet active: This lists EIPs that are currently deployed on the devnet. The latest version of the devnet will be considered for the upcoming upgrade.
Mainnet Phase
- Public Testnet: This is similar to the earlier network upgrade process. All EIPs which are agreed upon by the core client developers, implemented and tested on the devnet are now deployed on the public (PoW) testnet. If no breaking changes are observed while running on this testnet for a few weeks, it is ready to be deployed on the mainnet.
- Mainnet: Ethereum core developers set a block# and estimate a date when these proposals can be finally activated on the Ethereum main network.
With the activation on the mainnet, the process for one network upgrade is completed; while the network upgrades facilitator group is in work for a subsequent upgrade.
Network Upgrade Process Tracker
Managing an upgrade in the biggest decentralized network may become a challenge in absence of proper communication. A Network Upgrade Process Tracker is created for quick reference of EIPs that are under consideration. Clients’ progress can also be tracked in the Eth1.0 spec repository.
The discussion for the network upgrade process improvement set off over a year ago. The first version of the EIPs for hardfork proposal when introduced received good feedback from EIP editors and was well received by the community. It was also discussed in the All Core Dev meeting but was shelved due to the pressing needs of the time. Nevertheless, with refinements now we have a robust network upgrade process in place.
Share your feedback on the current Ethereum Network Upgrade Process at Fellowship of Ethereum Magician.
(Note: Based on the suggestion of the EIPIP meeting 30, the current process has been updated.)
