一種EIP流程改進思路：從RFC和W3C流程借鑒

編者按：本文來自以太坊愛好者（ID：ethfans）編者按：本文來自

以太坊愛好者（ID：ethfans）

以太坊愛好者（ID：ethfans）

編者按：本文來自

以太坊愛好者（ID：ethfans）

• 以太坊愛好者（ID：ethfans）

• 編者按：本文來自

以太坊愛好者（ID：ethfans）

以太坊愛好者（ID：ethfans）

• ，作者：Alex Beregszaszi，翻譯&校對：閔敏& 阿劍，Odaily經授權轉載。

• 一句話總結：首先，我會總的介紹一下EIP 流程及其在2019 年的調整。然後，我會提出新的EIP 流程，其靈感主要源於RFC 和W3C 流程。

• 自2016 年以來，我一直在參與EIP （以太坊改進提案）。我最初是一名貢獻者，之後參與「AllCoreDev 流程」 並承擔編輯任務。

• 現行流程

當前的EIP 庫中包含兩種迥異流程：

規範（Specification）

全網推行（硬分叉計劃）

EIP-1 和EIP 233 定義了這兩種流程的部分內容。之後，EIP-2378 又在此基礎上進行了擴展。

在2019 年，有人提議了幾處修改，其中與提案狀態相關的有4 處：

引入「Review （審核）」 狀態

將「Accepted （已同意）」 重命名為「Ready （已就緒）」

引入「Abandoned （已棄用）」 狀態

移除「Deferred （已棄用）」 狀態

引入前兩個變更的動機相似，但是略有不同。 「Review」 狀態是一個全新的階段，在這個階段，提案並不急著實施，雖然已經有清晰的提案、可以接受更廣泛的審查。 「Ready」 狀態只是一個小小的增量變化，語氣相比「Accepted」 更加柔和，但是仍保留EIP-1 中的硬分叉流程。

由於EIP-233 和EIP-2378 發生了更改，「Deferred」 狀態已漸漸變得不合時宜，已經被移除。

「核心」 EIP 的流程如下所示：

請注意，我不會詳細解釋下圖中每個狀態的含義。請閱讀EIP-1 以了解每個極端情況。不過，下文的'提議流程' 會給出合理的解釋。 」

「非核心」 EIP 的流程如下所示：

2019 年6 月，我們就已經深入討論過EIP 流程的複雜性。如果考慮到每個狀態，則整個EIP 流程（在「Deferred」 狀態被移除之前）如下圖所示：

我沒有提到的是，有兩種流程不同的EIP，而且並非以上所有組合都是有效的。

硬分叉

「核心」 EIP 的流程如下所示：

「非核心」 EIP 的流程如下所示：

硬分叉

2020 年5 月，我提議了一個更加簡單的流程：

關於這點，我們已經進行過討論。但是就像很多在走EIP 流程的提案一樣，這個提議並未得到推進。

硬分叉

引起爭論的還有是否應該將「Withdrawn」 和「Abandoned」 這兩個狀態合併的問題。在最近的議題中，這一點已經有了明確的解釋。

在電話會議上，還有人建議用「Living （生效）」 一詞來代替「Active （激活）」 。前者或許不是最佳選擇，但是聽起來優於後者。

硬分叉

我贊成將硬分叉管理和規範管理這兩個過程分開。現在看來，似乎有很多人都這麼認為。這樣可以讓流程變得更加簡單流暢。

根據全體核心開發者會議上的新消息，現在似乎有一個ETH 1.0 規範庫專門追踪和管理提案，並在所謂的「YOLO」 臨時測試網上進行測試。

我認為，即使將最後殘餘的硬分叉流程從EIP 庫中移除，EIP-233 最初的構想依然是合理的：將已有的硬分叉記錄到元文檔中（跟描述規範變更的EIP 放在一起）

然而，人們在EIP-233 的最初構想上邁開了一步，規則變成了盡快創建元文檔以明確硬分叉的名稱，因為不同的客戶端使用不同的名稱。但是在命名機制得到一致認可後，這個問題就不再是問題了。

硬分叉發生後，所有數據都記錄在「hard fork metas」 中。事實證明，hard ford metas 是一種非常有用的資源。

Draft （草案）

我建議的流程

要想站在巨人的肩膀上，我們所能找到的最好資源是RFC 流程和W3C 流程。儘管這兩個流程所涉及的規範通常比EIP 大得多，但是我認為我們可以向它們取經。

這裡，我從W3C 流程借用了一些我個人比較喜歡的術語。不過，上圖還給出了其它選擇，都是現有術語或提議術語。我個人更傾向於「Candidate （候選）」 這個術語。

Idea （構想）

任何提案在提交以前，都應該有一個深思熟慮的階段，再提交創建草案的pull request （拉取請求）。我們可以在Ethereum Magicians、ethresear.ch，以及Gitter 或Discord 上的頻道討論和評議構想。

Draft （草案）

假設某個構想引起了人們的興趣，我們就應該基於EIP 模版為其創建草案。只要這個草案符合基本的語法要求，我們就應該將其合併。

問題：關於編輯應有多大的審核提案的權限，人們的觀點各不相同，目前還沒有明確的答案。如果我們有一個良好的流程來移除不成功的EIP，那麼早一點合併草案無疑是正確的做法。

在這一階段，預期會有一小群感興趣的參與者對草案進行討論。

「Draft」 狀態沒有時間限制，但是建議不要超過合理的時間範圍（幾個月）。

Candidate （候選）/Review （審核）

一旦草案足夠穩定，預期不會再進行重大修改，就應該進入這一階段。

在這個階段，會有更多參與者提供反饋。這時，參與者有理由相信這個規範不會突然發生重大變化，因此他們更有可能投入時間來進行審核和討論。

Proposed （提議）/Last Call （最後一次徵求意見）

Final （敲定）

一旦參與者認為這個規範已經非常穩定，不會再進行修改，就應該進入這一階段。

• 在這個階段，這個規範會被推給更多參與者來徵求意見。之後，這個規範就得到最終確定，無法再進行修改。 【「errata （kan）」 除外，詳見下文】

• 這個階段應該持續至少14 天。

如果需要進細微調整，可以在不改變當前狀態的情況下進行，否則必須回退到「Candidate」 狀態。

特殊要求：frontmatter 中必須帶有review-end-date 字段。

如果「Proposed」 狀態的規范成功通過，就會最終敲定下來。

Living （生效）/Active （激活）

Withdrawn （撤銷）

除了「Final」 和「Living」 之外，其它所有狀態都有可能變成這個狀態。

特殊要求：以下幾種情況可能會導致「Withdrawn」 狀態，但是必須帶有reason 字段：

• withdrawn due to inactivity：作者在一段特定的時間（180 天）內沒有任何活動。

• Obsolete （淘汰）

Living （生效）/Active （激活）

那些作為註冊表的EIP-1 以及其它特殊的EIP 都會被標記為這個狀態，因為它們永遠也不會被敲定。

任何新的註冊文件必須經歷完整的EIP 流程，然後才會變成「Living」 狀態。

Archived （存檔）

雖然這不是一個狀態，但是通過這種方法，可以將撤銷了很久的EIP 移除，以免堆滿EIP 庫。點擊此處，了解詳情。

Obsolete （淘汰）

Remark

這不是一個狀態，而是從RFC 那裡借鑒的淘汰流程。該流程會引入兩個字段：

• obsoleted-by：包含一個將當前EIP 淘汰的EIP 編號

• obsoletes：包含一組被當前EIP 淘汰的EIP 編號

• resolution

只有在處於Final 或Withdrawn 狀態時，當前EIP 才能使用obsoleted-by 字段。

這就意味著，作為淘汰方和被淘汰方EIP 的作者必須達成共識。鑑於有人提議了一個更好的淘汰流程，這一點未來可能會發生變化。

• superseded-by（已由淘汰流程取代）

• Rejected

• Accepted

• 按照慣例，小的打字錯誤可由編輯修改。

工具

replace （已由淘汰流程取代）

Superseded （已由淘汰流程取代）

工具

superseded-by（已由淘汰流程取代）