An EIP process improvement idea: borrowing from RFC and W3C processes

以太坊爱好者

特邀专栏作者

2020-09-21 13:46 (UTC+8)

This article is about 3728 words, reading the full article takes about 6 minutes

Mainly inspired by RFCs and W3C processes.

AI Summary

Expand

Mainly inspired by RFCs and W3C processes.

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

Ethereum enthusiasts (ID: ethfans)

, Author: Alex Beregszaszi, translation & proofreading: Min Min & A Jian, reprinted with authorization by Odaily.

One sentence summary: First, I will give a general introduction to the EIP process and its adjustments in 2019. Then, I'll propose a new EIP process, largely inspired by the RFC and W3C processes.

Since 2016, I have been involved in EIPs (Ethereum Improvement Proposals). I started out as a contributor, and later participated in the "AllCoreDev process" and took on editorial tasks.
current process

There are two distinct processes in the current EIP library:

Specification

Entire network implementation (hard fork plan)
EIP-1 and EIP 233 define parts of both processes. Later, EIP-2378 expanded on this basis.
In 2019, several changes were proposed, 4 of which were relevant to the status of the proposal:
Introduce "Review" status

Rename "Accepted" to "Ready"

Introduce "Abandoned" status

Remove "Deferred" status

The motivation for introducing the first two changes is similar, but slightly different. The "Review" state is a new stage where proposals are not urgently implemented, although there are clear proposals open to broader review. The "Ready" status is just a small incremental change, and the tone is softer than "Accepted", but the hard fork process in EIP-1 is still retained.

The "Abandoned" status was introduced to clean up many abandoned drafts. Apparently, the previously unused "Withdrawn" state has been removed.

Due to changes in EIP-233 and EIP-2378, the "Deferred" status has become obsolete and has been removed.

There are also proposals to remove other hard fork states such as "Accepted" and "Rejected".

Note that I will not explain in detail what each state means in the diagram below. Please read EIP-1 for each corner case. However, the 'Proposed Process' below provides a reasonable explanation. "

In June 2019, we discussed in depth the complexities of the EIP process. If each state is considered, the entire EIP flow (before the "Deferred" state is removed) is shown in the following diagram:

At that time, I assumed that the EIP could change from the "Last Call (last time for comments)" state to the "Abandoned" state, although it was not written in the document.

What I didn't mention is that there are two EIPs with different processes, and not all combinations of the above are valid.

The flow of the “core” EIP is as follows:

It should be noted here that the "core" EIP did not introduce the "Last Call" state until recently.

The process for a "non-core" EIP is as follows:

In May 2020, I proposed a simpler process:

We have already discussed this point. But like many proposals that are going through the EIP process, this one didn't move forward.

hard fork

Also controversial is whether the two states "Withdrawn" and "Abandoned" should be merged. This has been clearly explained in recent issues.

On the conference call, it was also suggested that the word "Living" be used instead of "Active". The former may not be the best choice, but it sounds better than the latter.

hard fork

I am in favor of separating the two processes of hard fork management and canonical management. Now it seems that many people think so. This makes the process much easier and smoother.

According to new news from the all-core developers meeting, there now appears to be an ETH 1.0 specification repository dedicated to tracking and managing proposals, and testing them on the so-called "YOLO" temporary testnet.

I think that even if the last remaining hard fork process is removed from the EIP library, the original idea of EIP-233 is still reasonable: to record the existing hard fork in the meta document (put it in the same file as the EIP describing the specification change. together)

However, people took a step further from the original idea of EIP-233, and the rule became to create a meta document as soon as possible to clarify the name of the hard fork, because different clients use different names. But after the naming mechanism was agreed upon, this problem is no longer a problem.

Finally, the idea of EIP-233 is extended again, extending the process of tracking hard forks in the planning and coordination process. Fortunately, going forward this will be handled by the ETH 1.0 specification.

After a hard fork occurs, all data is recorded in "hard fork metas". The hard ford metas have proven to be a very useful resource.

my suggested process

To stand on the shoulders of giants, the best resources we have found are the RFC process and the W3C process. Although the specifications involved in these two processes are generally much larger than the EIP, I think we can learn from them.

Here, I'm borrowing some of my personal favorite terms from the W3C process. However, there are other options given in the figure above, both existing terms or proposed terms. I personally prefer the term "Candidate".

Idea

Before any proposal is submitted, there should be a deliberate phase before submitting a pull request (pull request) that creates a draft. We can discuss and critique ideas on Ethereum Magicians, ethresear.ch, and channels on Gitter or Discord.

Draft

Assuming that an idea attracts interest, we should create a draft for it based on the EIP template. As long as this draft meets the basic grammatical requirements, we should merge it.

Question: Opinions vary on how much authority editors should have to review proposals, and there is no clear answer. If we have a good process for removing unsuccessful EIPs, then merging drafts earlier is certainly the right thing to do.

At this stage, the draft is expected to be discussed by a small group of interested participants.

There is no time limit for the "Draft" status, but it is recommended not to exceed a reasonable time frame (a few months).

Candidate (candidate)/Review (review)

This stage should be entered once the draft is stable enough that no further major revisions are expected.

At this stage, more participants provide feedback. At this point, participants have reason to believe that the specification will not suddenly change significantly, so they are more likely to invest time in reviewing and discussing it.

This phase should last at least 45 days to allow feedback to be collected.

Proposed (proposed) / Last Call (last call for comments)

This phase should be entered once participants feel that the specification is sufficiently stable that no further changes will be made.

At this stage, the specification will be pushed to more participants for comments. After that, the specification is finalized and cannot be changed. [except "errata (kan)", see below for details]

This phase should last at least 14 days.

If minor adjustments are required, it can be done without changing the current state, otherwise it must fall back to the "Candidate" state.

Special requirement: The review-end-date field must be included in frontmatter.

Final

If the specification in the "Proposed" state is successfully passed, it will be finalized.

Withdrawn
Except for "Final" and "Living", all other states may become this state.

Special requirements: The following situations may lead to the "Withdrawn" state, but must have a reason field:

withdrawn by author: The author made a withdrawal decision at any stage

withdrawn due to inactivity: The author has had no activity for a specified period of time (180 days).

Living/Active

Those EIP-1 as registry and other special EIPs will be marked with this status, because they will never be finalized.

Any new registration documents must go through the full EIP process before becoming "Living" status.

Archived

Although this is not a state, in this way, EIPs that have been revoked for a long time can be removed to avoid filling up the EIP library. Click here for details.
Obsolete

This is not a state, but a phase-out process borrowed from the RFC. This process introduces two fields:

obsoleted-by: Contains an EIP number that obsoletes the current EIP

obsoletes: Contains a set of EIP numbers that are obsoleted by the current EIP

The current EIP can only use the obsoleted-by field when it is in Final or Withdrawn state.

The current EIP can only have the obsoletes field if the "obsoleted-by" field of the referenced EIP points to the current EIP.

This means that the authors of the EIP as the eliminated party and the eliminated party must reach a consensus. This may change in the future given the proposal for a better elimination process.

Remark

Errata (errata)

Minor typographical errors may be corrected by the editor, by convention.
Arguably, any modification that helps clarify the specification is acceptable as long as it doesn't change the original proposal beyond recognition, since minor modifications can be explained in the Errata section. If a major modification is required, the corresponding EIP must be retired and a new one must be created.
resolution

The following frontmatter fields were removed because they were not specified and/or used:

replace (replaced by the elimination process)