Ethereum Improvement Proposal and Upgrade Process Improvement Proposal

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

, Author: Tim Beiko, translation & proofreading: Peter Chen & A Jian, reprinted by Odaily with authorization.

Summary

This post is a rough transcript of a conversation Danno Ferrin and I had at DevconV (the 6th Ethereum Developers Conference). The article discusses some EIP process improvement suggestions put forward by the community in the past year, and incorporates them into a unified framework to guide us on how to upgrade Ethereum more smoothly. We call it the "railway station model".

• secondary title

• Summary

• Based on several proposals from the community over the past year, we propose a new method for coordinating upgrades on the Ethereum network. Specifically, we believe that:

• Upgrades should happen twice a year to provide clear predictability to the community;

Upgrades should only contain Ethereum Improvement Proposals (EIPs) that are ready to be released, and any improvements that are still under discussion should be put into the next upgrade and not delay the current upgrade;

Ethereum improvement proposals should be developed by working groups in an independent manner and should only be considered for inclusion in upgrades when completed;

Ethereum improvement proposals and working groups should have a champion or representative to contact the community and answer the community's questions about the relevant EIP.

Let's briefly talk about the upgrade history of Ethereum. The first few network upgrades, including Frontiers, Homeland, Byzantium, and Constantinople, were a bit like a family vacation in the 1950s, where Mom and Dad would unpack the car and we would hop in the backseat and maybe bring Our favorite toys, anyway they will get us safely to our destination.

This is a simple analogy for upgrades in the past, but for these upgrades, the core developers wrote most of the Ethereum improvement proposals, and the Ethereum community was small enough that they could communicate with the community in an organized and planned way, making The fork and upgrade went smoothly.

…. But there are times when they are too busy! On the few occasions when we had to rush to fight a fire. On those occasions, we are basically all soldiers. Whether it's a cyberattack during Devcon 2 in Shanghai, an Ethereum fork caused by The DAO, or a weakness discovered at the last minute before the Constantinople upgrade, the community always comes together to fix bugs, solve problems and let Users upgrade their nodes in time.

image description

-A waterfall the color of ethereum-

Until now Istanbul upgrade. When we started planning the upgrade, we had a good grasp of our workflow and decided to plan the upgrade process more thoroughly. We have set a time node for each stage of the upgrade process, and have made detailed plans from the Ethereum improvement proposal to the final mainnet upgrade. Before we knew it, we were in a kind of Ethereum waterfall model!

However, how many of these planned time nodes are actually completed on time? There is only one, and that is at the beginning.

Many things went wrong during execution. One of the more important reasons is that the Ethereum community has grown a lot since the last upgrade, and when it came time to start reviewing the Istanbul upgrade proposal, the core developers had to package together over 30 Ethereum improvement proposals Read, not just a handful of proposals to comment on!

image description

When we got the list of final improvement proposals for Ethereum Istanbul, it was already in the middle of summer. According to the original plan, we should have finished the client implementation by this time. When this happened, a lot of people realized that the development process was far behind expectations, and a lot of suggestions have been made about how we can make the Berlin upgrade after Istanbul run more smoothly. We will now discuss some of these proposals and then incorporate them into what we call the "railway station model".

image description

secondary title

Ethereum 1.X will try to change the EIP development process

During the Istanbul upgrade, the first person to try to solve the development process problem was Alexey Akhunov. He wrote a blog post (Editor's note: see the hyperlink at the end of the article for the Chinese translation) describing how we can use ReTestEth to increase the number of members contributing to improvements to the Ethereum protocol by forming a working group, while reducing the burden on existing core developers. burden. In the "pre-1.x" improvement process, the submitted Ethereum improvement proposal will be mainly implemented by the client developers of Geth, Parity and Aleth, in which case the Ethereum improvement proposal will be improved collaboratively by these teams. Once clients have agreed on the final specification of an Ethereum improvement proposal, reference tests can be generated. Aleth is the only client that can generate tests, so in order to generate these tests, all Ethereum improvement proposals need to be implemented in Aleth. EF's testing team will then run these tests and write conformance tests that all clients will run.

-Pictures on the slideshow are taken from Alexey's original post-

There are several bottlenecks in this process: the main client implementation team, Aleth generating reference tests, and the conformance tests written by EF's test team. In order to improve work efficiency, Alexey proposed the idea of ​​setting up a working group. These working groups will be made up of a subset of people who share a desire to improve Ethereum. They can start from the early stages of an Ethereum improvement proposal and help refine it so that it is more or less close to or reaching a final version. This way, client developers will see mature Ethereum improvement proposals, possibly at least an initial implementation, and most related open questions already answered.

In addition to this, retesth, a new testing tool developed by the EF testing team, will enable the working group to generate the required EIP reference tests for any client (currently Geth, Aleth, and Hyperledger Besu). Therefore, this working group framework will not only decentralize the refinement process of Ethereum improvement proposals, but also reduce testing bottlenecks and pressures.

eEIP Advocate

During the preparations for the Istanbul upgrade, it was not uncommon for all core developers to have conference calls where no one talked about specific Ethereum improvement proposals. Interdependence or competing proposals can significantly slow down the progress of the entire upgrade process.

image description

-Thanks to MP and Boris for their assistance in organizing a workshop to discuss these matters-

The role of champions is to make them a point of contact for EIPs. They serve as discussion coordinators for EIPs, ensuring that the upgrade process moves forward smoothly and that the right people are engaged in reasonable discussions. They are not responsible for all the work and do not necessarily have to implement it themselves, but they should be key figures in the implementation of Ethereum improvement proposals and commit to fully communicating the upgrade process with members within the community.

secondary title

EIP-centric fork

Another idea, recently proposed by Martin Holst Swende of the EF team, is to tweak the Ethereum network upgrade process to be more EIP-centric. Instead of focusing on upgrades and trying to ensure that all Ethereum improvement proposals are in lock step at each stage of the upgrade, it is better to focus on making each EIP mature and only plan upgrades for mature, releasable EIPs.

If anyone wants to take an Ethereum Improvement Proposal from draft stage to successful mainnet activation, here's how they do it within this framework (quote from the original proposal, with some minor edits for readability):

Step 1: Get affirmation from ACD

Assuming that the Ethereum Improvement Proposal exists (step 0), ALCORIEDEV (forum) will initially decide whether the Ethereum Improvement Proposal is "preliminarily accepted". "Preliminary acceptance" (or "positive") means that major clients and ecosystem stakeholders have a positive attitude towards the Ethereum improvement proposal, are willing to accept (well-written) PRs to integrate the EIP into the code base and Start testing... but this stage will not specify the actual block height of the activation.

This "preliminary acceptance" status is also a useful signaling mechanism for organizations funding protocol upgrades like EF, ConsenSys, or even MolochDAO. Funding can be split into several phases (i.e. pre- and post-"initial acceptance") to ensure that the majority of funds are spent on initiatives that facilitate mainnet launch.

Step 2: Execute

Once the ACD has given a clear direction, developers and other Ethereum improvement proposal authors can work on implementing it and releasing updates for clients.

This milestone is complete if the implemented functionality is merged into the main client.

Step 3: Test Case

Since the feature can now be "activated" in the client, it is now possible to generate cross-client tests for this feature, the test cases should contain happy-path tests and quirk/edgecase tests, this step should be given to not only the in-depth People who understand and understand EVM (Ethereum Virtual Machine) will execute it together in order to minimize the possibility of errors.

At this stage, a security review should also be conducted, and the review project should be fed back to the Ethereum improvement proposal in the name of "security considerations". The focus of the review should also be on finding marginal problems and problems that are easily overlooked. The completion of this phase is marked by the approval of the testing team.

Step 4: ACD Final Acceptance

“So, let’s activate this Ethereum Improvement Proposal (at block height X) on testnet one month later, and activate this Ethereum Improvement Proposal on mainnet (at block height Y) two months later.” All clients will include the upgrade in the next release, and it's also practical to defer Ethereum improvement proposals via command line flags for a week from now.

If multiple Ethereum Improvement Proposals reach step 4 at the same time, ACD can decide to launch two or three Ethereum Improvement Proposals at the same time, unless there is a concern that the Ethereum Improvement Proposals may have internal dependencies/couplings (which may lead to unnecessary test interference).

image description

-Thank you James Hancock for drawing such a clear picture! -

Using this framework will allow each Ethereum improvement proposal to move at its own pace, thus reducing the time and scope of debate during the upgrade process, while also reducing the pressure on the testing team because the process is more predictable than before. The team doesn't have to scramble to focus on testing before the deadline.

secondary title

• Ethereum Improvement Proposal 1872

• Another proposal to smooth the upgrade process of the Ethereum network is Proposition 1872, proposed by Danno Ferrin. As more companies rely on Ethereum as a core part of their infrastructure, we should work on making network upgrades more predictable.

• The proposal proposes that ethereum adopt a default schedule for network upgrades, similar to Microsoft’s regular patch Tuesday releases. That way, people running ethereum nodes know when they have a high probability of monitoring for potential upgrades. In short, this proposal suggests that we do this:

• Make mainnet upgrades happen by default on the third Wednesday of the month, preferably in January, April, July, or October to avoid most major US and European holidays.

If the upgrade does not roll out as scheduled, it is postponed until the third Wednesday of the following month (as happened during the Constantinople upgrade)

Whenever and wherever a problem occurs, solve it immediately

This EIP will not limit our ability to deal with unexpected situations, but only emphasizes the default periodicity, such as fixed upgrades every 6 months, to reduce market concerns about upgrade uncertainties, and at the same time reduce core developers. Communication time during the upgrade process.

It also provides a "middle ground" between our current approach and the "one Ethereum Improvement Proposal, one upgrade" approach (i.e. EIP-centric fork approach).

secondary title

train station model

Combining parts of the above recommendations, we have arrived at a process that is closer to the way train stations operate than our current "closer to the way airports operate" process.

Currently, our upgrades are similar to how buying a plane ticket works: the date and time are fixed, and we try to get everyone on the plane no matter what, even if there is a delay by checking their bags.

We believe that moving to a model where people show up at a train station with luggage in hand, ready to go, and leave on the next available train will help make network upgrades much smoother than they currently are.

Specifically, the train station model mainly has four parts.

First, each Ethereum improvement proposal should proceed independently. Working groups can push proposals forward, and only when an Ethereum Improvement Proposal is in a ready-to-go state will we schedule a network upgrade for it.

Second, Ethereum improvement proposals and working groups need champions. These champions should serve as representatives and default points of contact for Ethereum improvement proposals. They are responsible for communicating the proposal to the community on AllCoreDevs or other forums, and they may or may not be the actual implementers of the EIP.

Third, publish what is done. When the network is going to be upgraded, put all the EIPs that are ready to be released into the upgrade. No escalation will be scheduled for any proposals still under discussion. Similarly, if a proposal has problems at the last minute, we will move it to the next upgrade instead of postponing the whole upgrade.