站在巨人的肩膀上,以太坊 EIP 能找到的最好資源是 RFC 與 W3C 流程。

原文標題:《觀點 | 一種 EIP 流程改進思路》
撰文:Alex Beregszaszi
翻譯 & 校對:閔敏 & 阿劍

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

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

現行流程

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

  1. 規範(Specification)
  2. 全網推行(硬分叉計劃)

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

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

  1. 引入 「Review (審覈)」 狀態
  2. 將 「Accepted (已同意)」 重命名爲 「Ready (已就緒)」
  3. 引入 「Abandoned (已棄用)」 狀態
  4. 移除 「Deferred (已棄用)」 狀態

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

引入 「Abandoned」 狀態是爲了清理很多被放棄的草案。顯然,過去未使用的 「Withdrawn」 狀態已經被移除。

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

還有人提議移除其它關於硬分叉的狀態,例如,「Accepted」 和 「Rejected」。

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

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

觀點 | 一種 EIP 流程改進思路

當時,我自己假設 EIP 可以從 「Last Call(最後一次徵求意見)」 狀態轉向 「Abandoned」 狀態,雖然文檔裏面沒有這麼寫。

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

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

觀點 | 一種 EIP 流程改進思路

這裏要特別說明的是,「核心」 EIP 直到最近才引入 「Last Call」 狀態。

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

觀點 | 一種 EIP 流程改進思路

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

觀點 | 一種 EIP 流程改進思路

該提議的目的是引入 「Review」 狀態,並移除所有協調硬分叉的嘗試。這樣可以統一 「核心」 EIP 和 「非核心」 EIP 的流程。但是,爲了方便起見,我略去了協調硬分叉的部分。

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

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

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

硬分叉

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

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

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

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

最後,EIP-233 的構想再次延伸,延伸出了在計劃和協調過程中追蹤硬分叉的流程。幸運的是,以後這將由 ETH 1.0 規範來處理。

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

我建議的流程

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

觀點 | 一種 EIP 流程改進思路

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

Idea (構想)

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

Draft (草案)

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

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

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

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

Candidate (候選)/Review (審覈)

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

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

這個階段至少應持續 45 天,以便收集反饋。

Proposed (提議)/Last Call (最後一次徵求意見)

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

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

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

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

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

Final (敲定)

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

Withdrawn (撤銷)

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

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

  • withdrawn by author:作者在任意階段做出了撤銷決定
  • withdrawn due to inactivity:作者在一段特定的時間(180 天)內沒有任何活動。

Living (生效)/Active (激活)

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

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

Archived (存檔)

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

Obsolete (淘汰)

這不是一個狀態,而是從 RFC 那裏借鑑的淘汰流程。該流程會引入兩個字段:

  • obsoleted-by:包含一個將當前 EIP 淘汰的 EIP 編號
  • obsoletes:包含一組被當前 EIP 淘汰的 EIP 編號

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

只有被引用 EIP 的 「obsoleted-by」 字段指向當前 EIP 時,當前 EIP 才能帶有 obsoletes 字段。

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

Errata (勘誤)

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

按理來說,任意能幫助闡明規範的修改都可以接受,只要它不至於使原提案面目全非,因爲小的修改可以在 Errata 部分做出解釋。如果需要重大修改,必須淘汰相應的 EIP,並重新創建一個 EIP 。

Remark

以下 frontmatter 字段被移除,因爲它們未經詳細說明 和 / 或 使用:

  • replace (已由淘汰流程取代)
  • superseded-by(已由淘汰流程取代)
  • resolution

需要這些字段的話,可以再添加回來。

以下狀態被移除:

  • Abandoned (重命名爲 「Withdrawn」)
  • Rejected
  • Accepted
  • Superseded (已由淘汰流程取代)

工具

然而,EIP 面臨的最大挑戰是需要人力。

最近,舊版本的格式校驗器 eip_validator 已經換成了更好的版本 eipv。另外,我們已經啓動了一個機器人來檢查過時 PR 的問題。

雖然有了工具的輔助,編輯和審校依然需要投入大量的人力。如果我們想要讓 EIP 流程變得更加流暢,就要使用機器人來代替真人完成大部分工作。我已經創建了一個新的議題來討論 EIP 庫需要引入哪些機器人。

有志願者想要一起實現機器人嗎 : ) : )

來源鏈接:hackmd.io