Viewpoint | Departure at the End: Ethereum EIP and Upgrade Process Improvement Proposals

This article is a rough transcript of a conversation between Danno Ferrin and me at DevconV (the 6th Ethereum Developer Conference). The article discusses some EIP process improvement suggestions made by the community over the past year, and incorporates them into a unified framework to guide us how to make Ethereum upgrade smoothly. We call it the "train station model".

Summary

Based on several suggestions made by the community over the past year, we have proposed a new method to coordinate the upgrade of the Ethereum network. Specifically, we believe:

• Upgrades should be performed twice a year to provide clear predictability to the community;
• The upgrade should only include the Ethereum Improvement Proposal (EIP) that is ready to be released, and any improvements that are still under discussion should be carried over to the next upgrade without delaying the current upgrade;
• Ethereum improvement proposals should be developed independently by the working group and should only be considered for inclusion when completed;
• The Ethereum improvement proposal and working group should have an advocate or representative to contact the community and answer the community's questions about the relevant EIP.

If you want to discuss this proposal in more depth, head to this post on the EthMagicians forum.

• Viewpoint: The blockchain situation is always erratic, because its origin has a great relationship with the hacker culture
• Beijing News: Virtual currency speculation shows signs of rise
• DeFI: What should the future of open finance look like?

Let's talk briefly about the upgrade history of Ethereum. The first few network upgrades, including Frontier, Homestead, Byzantium, and Constantinople, are a bit like family vacations in the 1950s. Mom and Dad will take care of the luggage in the car, we will jump into the back seat, and maybe bring Our favorite toys, in short they will send us safely to their destination. This is a simple analogy of past upgrades, but for these upgrades, the core developers wrote most of the Ethereum improvement proposals, and the Ethereum community is small enough that they can communicate with the community in an organized and planned manner, making The fork and upgrade went smoothly.

…. But there are times when they are too busy! A few times, we had to rush to fight the fire. On those occasions, we are basically soldiers. Whether it's a cyber attack event in 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 can always work together to fix bugs and solve problems while letting Users upgrade their nodes in a timely manner.

-An Ethereum-colored waterfall-

Until now Istanbul has been upgraded. When we started planning the upgrade, we had a good grasp of our workflow and decided to plan the upgrade process more thoroughly. We set a time node for each stage of the upgrade process, from the proposal of the Ethereum improvement proposal to the final mainnet upgrade. We were in an Ethereum waterfall model until we realized it!

As we know, the waterfall model is not suitable for software development. However, we still use it for the Istanbul upgrade process. We originally planned to start in January, spend several months to review the Ethereum improvement proposal, and set mid-May as the final acceptance period for the Ethereum improvement proposal, and then spend two months to complete the deployment of the new client, which is estimated to be over It's not until mid-July. After doing all of the above, it is expected that the testnet upgrade will be completed in mid-August and the mainnet upgrade will be completed in mid-October, which means that it will be completed two weeks before the Ethereum Developer Conference.

However, how many of these planned time nodes are actually completed on time? There was only one, which was just the beginning.

Many things went wrong in the process of implementation. One of the more important reasons is that the Ethereum community has grown a lot since the last upgrade. By the time the review of the Istanbul upgrade proposal began, core developers had to package more than 30 Ethereum improvement proposals together. Read, not just a few proposals for comment!

This slows down the entire process significantly. The large number is only one aspect, the point is that they are in completely different development stages (some Ethereum improvement proposals have not been merged into the code base, and some other Ethereum improvement proposals have been run on the testnet), and some are interdependent or Competing Ethereum improvement proposals.

-Because we want to use a specific font in the slideshow, we can't list all the Istanbul EIPs in one page …-

When we got the list of Ethereum Istanbul's final improvement proposals, it was already mid-summer. According to the original plan, at this time we should finish the client implementation. When this happened, many people realized that the development process was far less than expected, and there have been many suggestions on how we can make the Berlin upgrade after Istanbul run more smoothly. We will now discuss some of these suggestions and then incorporate them into what we call the "train station model."

-"Berlin" will have fine weather and beautiful scenery-

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 was Alexey Akhunov. He wrote a blog post (Editor's note: Chinese translation see hyperlink at the end of the article), describing how we can increase the number of members who contribute to the improvement of the Ethereum protocol by forming working groups and using ReTestEth, while reducing existing core developers Burden. In the "pre-1.x" improvement process, the submitted Ethereum improvement proposals will be mainly implemented by client developers of Geth, Parity, and Aleth. In this case, the Ethereum improvement proposals will be collaboratively improved by these teams. Once the customer agrees on the final specification of the Ethereum improvement proposal, a reference test can be generated. Aleth is the only client that can generate tests, so in order to generate these tests, all Ethereum improvement proposals must be implemented in Aleth. EF's test team will then run these tests and write conformance tests that all clients will run.

-The picture on the slide is from the original post of Alexey-

There are several bottlenecks in this process: the main client implementation team, Aleth generates reference tests, and the conformance tests written by EF's test team. In order to improve the efficiency of work, Alexey proposed the idea of ​​setting up a working group. These working groups will consist of a group of people who have a desire to improve Ethereum together. They can start with the early stages of the Ethereum improvement proposal and help refine it to more or less approach or reach the final version. In this way, the client developer will see the mature Ethereum improvement proposal, at least there may be a preliminary implementation, and most relevant open-ended questions have also been answered.

In addition, the new testing tool, retesth, 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 make the process of improving the Ethereum improvement proposal more decentralized, but also reduce testing bottlenecks and pressure.

eEIP Advocates

During the preparation process for the Istanbul upgrade, it was a common phenomenon that no one talked about a specific Ethereum improvement proposal when all the core developers held a conference call. This not only slowed down the development progress of the Ethereum improvement proposal, but also needed to discuss some When relying on or competing for proposals, the progress of the entire upgrade process will be significantly reduced.

A simple way to solve this problem was proposed by Alex Beregszaszi at the Ethereum 1.x Berlin conference, which requires that an advocate be elected in the discussion of the Ethereum improvement proposal.

-Thanks to MP and Boris for assisting in organizing a seminar on these matters-

The role of the advocate is to make it a contact node related to the Ethereum improvement proposal. As the discussion coordinator of the Ethereum improvement proposal, they are responsible for ensuring that the upgrade process moves forward smoothly and that the right people are involved in the reasonable discussion. They are not responsible for all the work and do not necessarily have to do it themselves, but they should be the key figures in the implementation of the Ethereum improvement proposal, and are committed to fully communicating with members in the community to upgrade the process.

EIP-centric fork

Another idea, recently proposed by Martin Holst Swende of the EF team, is to adjust the Ethereum network upgrade process to make it more EIP-centric. Rather than focusing on upgrading and striving to ensure that all Ethereum improvement proposals are in step at all stages of the upgrade, it is better to focus on maturing each EIP, and only upgrade the mature, publishable EIP plan. If anyone wants to make the Ethereum improvement proposal from the draft stage until it is successfully activated on the mainnet, here is how they implemented it in this framework (quoting the original proposal, making some small changes for readability):

Step 1: Get ACD Affirmation Assuming that an Ethereum improvement proposal exists (step 0), ALCORIEDEV (forum) will initially decide whether the Ethereum improvement proposal is "preliminarily accepted". "Preliminary acceptance" (or "affirmation") means that the major clients and ecosystem stakeholders have a positive attitude towards the Ethereum improvement proposal and are willing to accept (well-written) PRs to integrate EIP into the code base and Starting the test … but this stage does not specify the actual block height to activate.

This "preliminary acceptance" status is also a useful signaling mechanism for organizations such as EF, ConsenSys, and even MolochDAO to fund agreement upgrades. Funding can be divided into several stages (before and after "initial acceptance") to ensure that most of the funds are spent on programs that promote the launch of the mainnet.

Step 2: Execution Once ACD has given a clear direction, developers and other Ethereum improvement proposal authors can proceed to implement and release updates for the client. This milestone is complete if the implemented functionality is incorporated into the main client. Step 3: Test case Because this feature can now be "activated" in the client, cross-client tests can now be generated for this feature. The test case should include a happy-path test and a quirk / edgecase test. This step should be passed to not only People who have an in-depth understanding of this EIP and also have an understanding of EVM (Ethereum Virtual Machine) perform it together to minimize the possibility of errors. At this stage, a security review should also be conducted. 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 edge issues and issues that are easily overlooked. The completion of this phase is marked by the approval of the test team. Step 4: ACD's final acceptance At this point, ACD can again discuss and evaluate the implementation, side effects, and test cases of the Ethereum improvement proposal. If all goes well, ACD can directly decide when to activate the Ethereum improvement proposal. "So, let's activate this Ethereum improvement proposal on the testnet one month later (at the height of block X), and two months later to activate this Ethereum improvement proposal on the mainnet (at the height of block Y)." All clients will include upgrades in the next version. Within a week from now, they can also depart from the actual situation and postpone Ethereum improvement proposals through command line flags. If multiple Ethereum improvement proposals arrive at step 4 at the same time, ACD may decide to launch two or three Ethereum improvement proposals at the same time, unless someone is concerned that the Ethereum improvement proposal may have internal dependencies / couplings (which may cause unnecessary Test interference).

To visualize this new process, James Hancock drew a graph showing how an Ethereum improvement proposal will go through each of the phases mentioned above until it is activated on the mainnet.

-Thank you James Hancock for such a clear and clear picture! -Using this framework will allow each Ethereum improvement proposal to be promoted at its own pace, so it can reduce the time of debate and the scope of discussions during the upgrade process, and also reduce the stress on the test team, because this process is more predictable than the original, The test team doesn't have to focus on testing before the deadline.

1872 Ethereum Improvement Proposal

Another proposal to smooth the Ethereum network upgrade process is proposal 1872, which was proposed by Danno Ferrin. As more and more companies rely on Ethereum as a core part of their infrastructure, we should work to make network upgrades more predictable. This proposal suggests that Ethereum adopt a default network upgrade schedule, similar to Microsoft's practice of fixing patches on Tuesday. This way, people running Ethereum nodes know when they are most likely to monitor potential upgrades. In short, this proposal suggests that we do this:

• Let the mainnet upgrade happen on the third Wednesday of the month by default, preferably in January, April, July, or October, to avoid most major US and European holidays.
• If the upgrade does not roll out as scheduled, postpone it until the third Wednesday of the following month (as happened during the Constantinople upgrade)
• The goal is to upgrade the mainnet every 6 months from now on
• Solve problems whenever and wherever they occur

This EIP will not limit our processing capacity in the event of an unexpected situation, but rather emphasizes the default periodicity, such as a fixed upgrade once every 6 months, in order to reduce market concerns about upgrade uncertainty and reduce core developers' Communication time during the upgrade. It also provides a "middle ground" between our current approach and the "One Ethereum Improvement Proposal, One Upgrade" approach (ie, an EIP-centric fork approach).

Railway station model

Combining the various parts of the above recommendations, we came up with a process that is closer to the way the railway station operates than to our current "closer to the way the airport operates" process.

At present, our upgrade is similar to the way tickets are purchased: the date and time are fixed, no matter what, we will try to get everyone on the plane, even if it is delayed for them to check their luggage.

We believe that if we shift to a model where people show up at the train station with their luggage in hand, prepare to leave, and then leave by the next train, it will help make the network upgrade smoother than it is now.

Specifically, the train station model has four main parts. First, each Ethereum improvement proposal should be conducted independently. The working group can move the proposal forward, and we will only arrange a network upgrade for an Ethereum improvement proposal when it is ready for use.

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

Third, publish whatever you complete. When the network is about to be upgraded, put all EIPs that are ready to be released into the upgrade. Any proposals that are still under discussion will not be upgraded. Similarly, if there is a problem with the proposal at the last minute, we will move it to the next upgrade instead of delaying the entire upgrade.

The fourth and final upgrade takes place twice a year. By setting upgrade goals every 6 months, we can reduce uncertainty and latency for teams working on Ethereum improvement proposals. This way, if something isn't included in a particular upgrade, it will appear in the next upgrade a few months later. Although the upgrade date was selected in advance, the specific upgrade block of the testnet was determined 8-10 weeks before the mainnet upgrade date, and the specific upgrade block of the mainnet was determined 4-6 weeks before the upgrade date.

.……right here! We hope that this approach will provide Ethereum with a more efficient, predictable and faster network upgrade. Special thanks to Alexey Akhunov, Alex Beregssaszi, María Paula Fernández, Boris Mann, Martin Holst Swende, James Hancock, and everyone else who has suggested ways to improve the Ethereum upgrade.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!