Shedding light on the Ethereum Network Upgrade Process

The network upgrades process, phases & tracker explained.

Pooja Ranjan
Nov 18, 2020 · 5 min read

(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?

Why change the process?

Network upgrade process (old)

Consensus conflict

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

Transparency

The contemporary network upgrade process

The current 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

Devnet Phase

  • 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

  • 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

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

Ethereum Cat Herders

Ethereum community-led project management