Why improve the upgrade process of the Ethereum network?

The next upgrade (Berlin) is around the corner, and for this we need to arrange a network upgrade process. After several brainstorming sessions, the EIPIP team came up with several suggestions on how to improve the network upgrade process. I hope that the information shared in this post will be useful to EIP authors and the entire community. Let's understand what the new process is like and why we need to adjust the network upgrade process that has been used since the birth of the Ethereum blockchain.

What is a network upgrade?

Network upgrades are how new features are added to the Ethereum protocol. Generally speaking, these upgrades are designed to bring scalability, better user experience, and increased security to the network. Each new feature is described in detail in an EIP (Ethereum Improvement Proposal). When all nodes in the network agree to activate the new feature, a network upgrade occurs at a specific block height. Since Ethereum is decentralized and no one can force others to upgrade their nodes, if some participants in the network decide not to activate the upgrade, they will stop communicating with the nodes that have activated the upgrade, resulting in a fork in the network.

Why change the network upgrade process?

In the past, the network upgrade process was interrelated with the EIP standardization process. The core EIP must be deployed on the main network together with the standardization process.

-Old version network upgrade process-

Consensus Conflict

Ethereum is an open source community project. To deploy a core proposal to the mainnet, you must first obtain the consent of the community and the core client (Ethereum node). Once an EIP is accepted by both the Ethereum core client developers and the community, it will be included in the next network upgrade.

When Ethereum developers were preparing for the Istanbul upgrade, the community did not reach a consensus on EIP 1057 (ProgPow). This proposal was supported by some people, but also strongly opposed by many people. In the end, no consensus was reached among Ethereum clients.

Although this proposal was not included in the network upgrade, it did go through the EIP standardization process. This highlights the importance of separating the EIP standardization and network upgrade processes.

The number of core EIPs has increased dramatically

In the early days, the network upgrade process worked well and the total number of EIPs was relatively small. Over the past few years, as the number of contributors to the Ethereum blockchain has grown dramatically, the number of EIPs on how to improve the network has also increased exponentially. This has added complexity and sparked discussions on how to design a formal process for network upgrade EIPs.

transparency

As adoption of the Ethereum blockchain increases, many contributors come together to submit EIPs for network upgrades to strengthen the Ethereum network. Each client has to make great efforts to implement the improvements proposed in the EIP. Considering the man-hours required to implement each EIP, not all EIPs can be included in the next upgrade. Not understanding the process can cause confusion. Therefore, we must update the document to increase transparency of the upgrade process.

New version network upgrade process

-New version network upgrade process-

The current network upgrade process is the result of multiple brainstorming sessions by the EIPIP team and continuous communication with Ethereum developers and the entire community.

The current network upgrade process has been officially separated from the EIP standardization process. However, the above diagram also includes the recommended status of EIPs at different stages. The EIP process is roughly divided into three stages to show the status of the EIP before the next upgrade.

Consider incorporating

Consider for Inclusion (CFI) means that a proposal is expected to be included in the first phase of the next network upgrade. Some people suggest that the author or supporter of the proposal create an issue in the Eth1.0 specification repository for official announcement.

Devnet Phase

During this phase, client developers discuss proposals and reach consensus to move forward with the implementation of the Devnet (Developer Testnet). This is designed for client developers and can also be used by other community members. However, this testnet may be shut down without prior notice, so it is not recommended to use it to test dApps. The current Devnet is the YOLO testnet. The current version is YOLO 2.0, which includes proposals that are expected to be introduced in the next network upgrade.

• CFI approved: This bucket contains EIPs that have received a rough consensus from clients. After a PR that meets the rules is submitted, it will be considered by core developers. Clients may start implementing these proposals independently when it is convenient.

• CI devnet waiting room: EIPs that have been explicitly approved by some (but not all) clients, or some work waiting for integration will be temporarily placed in the CI devnet waiting room. This part may also include other types of proposals, but for some reason, they are not considered for the next CI devnet version.

• Deployed on CI devnet: This lists the EIPs currently deployed on devnet. The latest version of devnet (what it contains) may be implemented in the next upgrade.

Mainnet Phase

• Testing Green Light: This is a list of EIPs suitable for deployment on public testnets, as of the latest Ethereum core developer meeting.

• Public Testnet: Similar to the early network upgrade process. All EIPs that have been agreed to by core client developers and implemented and tested on the devnet are now deployed on the public (PoW) testnet. If no major issues are found within a few weeks of running on the testnet, they can be deployed to the mainnet.

• Mainnet: Ethereum core developers will set a block number and estimate the date when these proposals will finally be activated on the Ethereum mainnet.

After the mainnet is activated, the entire network upgrade process is completed. Although the network upgrade promotion team is preparing for the next upgrade.

Network Upgrade Process Tracker

Managing upgrades on a large decentralized network can be challenging without good communication. We can quickly check the EIPs under consideration through the Network Upgrade Tracker and track the client's progress through the Eth1.0 specification repository.

Discussions on the network upgrade process began a year ago. The first version of the EIP process for hard forks was well received by the EIP author and the community. This process was also discussed at the core developer meeting, but was shelved due to urgent needs. Nevertheless, after improvements, we now have a better version of the network upgrade process.

Welcome to the Fellowship of Ethereum Magician to share your opinions and suggestions on the current Ethereum network upgrade process.

Thanks to James Hancock, Hudson Jameson, Micah Zoltu, and Tim Beiko for suggestions for improvements.