The new version of the network upgrade process has been separated from the EIP standardization process. The new process includes consideration for inclusion, Devnet phase, and mainnet phase.
Original title: “Introduction | Improving the Upgrade Process of the Ethereum Network”
Written by: Pooja Ranjan
Translation & Proofreading: Min Min & A Jian
The next upgrade (Berlin upgrade) is in sight, so we have to arrange a network upgrade process. After several brainstorming sessions, the EIPIP team made several suggestions on how to improve the network upgrade process. I hope that the information shared in this article will be useful to EIP authors and the entire community. Let’s take a look at what the new process looks like and why we need to adjust the network upgrade process that has been in use since the birth of the Ethereum blockchain.
What is a network upgrade?
The network upgrade is a way to add new features to the Ethereum protocol. Generally speaking, these upgrades are designed to bring scalability, better user experience and higher security to the network. Each new feature is described in detail in EIP (Ethereum Improvement Proposal). When all nodes in the network agree to activate new functions, a network upgrade occurs at a certain block height. Since Ethereum is decentralized, and no one can force others to upgrade nodes, if some participants in the network decide not to activate the upgrade program, they will stop communicating with the nodes that have activated the upgrade program, resulting in a fork in the network .
Why change the network upgrade process?
In the past, the network upgrade process was related to the EIP standardization process. The core EIP should be deployed on the mainnet along with standardized processes.
Old version network upgrade process
Consensus conflict
Ethereum is an open source community project. If you want to deploy the core proposal to the mainnet, you must first obtain the consent of the community and the core client (Ethereum node). Once the Ethereum core client developers and the community have accepted an EIP, this EIP 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 (Programmable Proof of Work ProgPow). This proposal was supported by some people, but it was also strongly opposed by many people. In the end, there was no consensus among the Ethereum clients.
Although this proposal did not include network upgrades, it did pass the EIP standardization process. This highlights the importance of separating EIP standardization from the network upgrade process .
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. In the past few years, due to the dramatic increase in the number of contributors to the Ethereum blockchain, the number of EIPs on how to improve the network has also doubled. This has increased complexity and has also sparked discussion on how to design a formal process for network upgrade EIP.
transparency
As the adoption rate of the Ethereum blockchain increases, many contributors have joined together to submit EIPs on network upgrades to strengthen the Ethereum network. Each client has to make great efforts to implement the improvements proposed in 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 documentation to increase the transparency of the upgrade process.
New network upgrade process
New network upgrade process
The current network upgrade process is the result of the EIPIP team after many brainstorming and continuous communication with Ethereum developers and the entire community.
The current network upgrade process has been formally separated from the EIP standardization process. However, the above figure also includes the EIP recommendation status at different stages. The EIP process is roughly divided into three stages to show the status of EIP before the next upgrade.
Consider including
Consider for Inclusion (CFI) refers to a proposal that 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 library for official announcement.
Devnet stage
At this stage, client developers will discuss the proposal and reach a consensus to advance the implementation of Devnet (Developer Test Network). This is designed for client developers and can be used by other community members. However, the testnet may be closed without prior notice, so it is not recommended to test dApps. The current Devnet is the YOLO testnet. The current version is YOLO 2.0, which contains a proposal that is expected to introduce the next network upgrade.
Approved by CFI : This bucket contains the EIP that is generally agreed by the client. After the PR that meets the rules is submitted, the core developer will consider it. Clients may start to implement these proposals independently at a convenient time.
CI devnet waiting room : Some (but not all) EIPs explicitly approved by the client or some tasks waiting for integration will be temporarily placed in the CI devent waiting room. This part may also include other types of proposals, but for some reasons, it is temporarily not considered for the next CI devnet version.
Deploy on CI devnet : The EIP currently deployed on devnet is listed here. The latest version of devnet (content included) may be implemented through the next upgrade.
Mainnet stage
- Test green light: Here is a list of EIPs suitable for deployment on the public testnet, as of the latest Ethereum core developer conference.
- Public test network : similar to the early network upgrade process. All EIPs that have been approved by core client developers and implemented and tested on devnet are now deployed on the public (PoW) testnet. If no major issues are found within a few weeks of running the testnet, it 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 main network is activated, the entire network upgrade process is complete. Although the network upgrade promotion team is preparing for the next upgrade.
Network upgrade process tracker
In the absence of good communication, managing upgrades on large decentralized networks can be a huge challenge. We can quickly check the EIP under consideration through the network upgrade process tracker, and track the progress of the client through the Eth1.0 specification library.
The discussion about the network upgrade process started a year ago. The first version of the EIP process on hard forks was well received by EIP authors and the community. This process was also discussed at the core developer meeting, but was shelved due to urgent needs. Nevertheless, after improvement, we now have a better version of the network upgrade process.
Welcome to 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 their suggestions for improvement.
Source link: medium.com
