轉發原標題“3074 傳奇之後對乙太坊治理的反思”

摘要：本文是 ZeroDev 首席執行官 Derek Chiang 針對 V 提出的 EIP-7702 提案以平衡 ERC-4337 和 EIP-3074 之間的矛盾而發表的聲明。它從AA生態系統中的項目創始人的角度撰寫，客觀地突出了乙太坊當前的治理模式及其痛點。Derek 簡明扼要地指出：

乙太坊的治理衝突之一在於研究人員確定的路線圖與Geth等客戶開發團隊的觀點之間存在差異。Vitalik 扮演著類似於 CTO 的角色，最終成為決定性因素。

在肯定了 Vitalik 的角色之後，Derek 概述了乙太坊應該對其治理模型進行的改進，為乙太坊和比特幣社區提供了寶貴的見解。

發短信：

如果您之前不熟悉圍繞乙太坊帳戶抽象 （AA） 的事件，這裡有一個簡短的回顧： 幾周前，EIP-3074 提案獲得了乙太坊核心開發人員的批准，被包含在下一個硬分叉“Pectra”中。該提案為乙太坊虛擬機 （EVM） 引入了兩個新的操作碼，允許乙太坊外部擁有的帳戶 （EOA） 擁有幾乎原生的AA體驗。從那時起，ERC-4337 社區的許多成員，尤其是其支援者，都強烈反對 EIP-3074，理由是擔心潛在的安全風險及其與乙太坊的 AA 路線圖不相容。在乙太坊之前的路線圖中，ERC-4337 和 7560（也稱為“nativeAA”）等類似提案是核心。5 月初，Vitalik 提議將 EIP-7702 作為 EIP-3074 的替代品，在 4337 和 3074 之間取得平衡——為 EOA 使用者提供 AA 體驗，同時在一定程度上保持與 ERC-4337 的相容性，以及與“最終 AA 解決方案”7560 的相容性。目前，乙太坊的核心開發人員正在考慮 EIP-7702 的影響，初步討論和社區情緒表明 EIP-7702 可能會取代前面提到的 EIP-3074。我對這個結果非常滿意：EOA使用者很快將能夠體驗ERC-4337生態系統中的各種產品，並享受AA的大部分好處。然而，我不禁覺得，正如最近幾周許多人所指出的那樣，本來可以有更好的方法來實現這些結果。我相信，通過更好的治理過程，我們可以節省大量精力並更快地實現預期的結果。在這篇文章中，我想：

• 確定治理過程中出了什麼問題
• 提出乙太坊治理的思維模型
• 提出改進建議，避免日後發生類似治理事故

EIP-3074事件的結論與思考

上面提到的故事讓很多人不高興，原因有幾個： EIP-3074花了幾年時間才獲得批准。在 3074 最終獲得批准后，乙太坊的核心開發者面臨 4337 社區的強烈反對。另一方面，ERC-4337 的作者多次向乙太坊核心團隊表達了他們對 EIP-3074 的擔憂，但無濟於事。現在乙太坊計劃取消對 3074 的批准，並用另一個 EIP （7702） 取而代之。在上面提到的過程中，任何一點本質上都沒有錯：

• 關於EIP的討論需要幾年時間是正常的。
• 批准的 EIP 之後被拒絕是正常的。
• 如果發現新問題，可以在批准后撤銷對彈性公網IP的批准。

然而，事情本來可以更順利。讓我們想像一下，如果事情發展成這樣：在討論 3074 期間，4337 社區積極與乙太坊的核心開發人員接觸。如果這個前提成立，那麼只有兩種可能的結果：

• 在考慮了 4337 社區的反饋后，3074 提案獲得批准（並可能進行修改）。在這種情況下，4337 社區將接受 3074，乙太坊的核心團隊不需要撤銷 3074。
• 或者，3074 從未獲得批准，但 4337 社區和乙太坊的核心團隊共同提出了一個讓每個人都滿意的解決方案，類似於 7702。每個人的聲音都被聽到了，沒有戲劇性的逆轉。這本來是理想的，那麼為什麼沒有發生呢？

哪裡出了問題？

回顧整個過程，事件雙方都在互相指責。乙太坊核心開發人員（以及 EIP-3074 的作者）認為這是“4337 支援者”的錯，因為他們沒有積极參與所有核心開發人員 （ACD） 的討論過程。在這個過程中，EIP需要經過長時間的審議，並最終被Geth等乙太坊客戶端開發團隊接受和實施。一些人認為，在EIP-3074審議期間，“4337支援者”本可以參與並表達他們的觀點，而不是在它已經獲得批准後批評它。畢竟，整個 ACD 流程是透明的，會議對所有人開放，像 Tim Beiko 這樣的人每次 ACD 會議後都會不斷發佈摘要推文。那麼，如果「4337支援者」如此關心這個話題，為什麼不積極及時地參加相關會議呢？

另一方面，4337 的核心成員表示他們一直在參加 ACD 會議，並盡可能地反對 3074，但乙太坊核心開發者不聽。至於 4337 社區成員，許多人感到措手不及——許多人認為 3074 已經死了，有些人甚至不知道 3074 可能會獲得批准。許多人指出，ACD會議的整個過程是不透明的，對那些在乙太坊社區中“認真”但無法即時跟上ACD更新的人來說並不友好。一些人還認為，ACD 應該積極尋求利益相關者的反饋（這裡指的是 4337 社區）。

但是，我相信雙方都沒有一針見血。這背後有更深層次的問題，除非我們解決或至少承認這個問題，否則我們將繼續陷入治理事故，然後是雙方相互矛盾的指責，最終毫無意義。

治理事故的根本原因：路線圖

與普遍的看法相反，治理事故的根本原因在於 ACD 不是乙太坊協定更新的唯一治理機構;它已被另一個治理機構所取代。這裏的問題是，儘管在乙太坊核心問題（如AA和可擴充性）上比ACD具有更大的影響力，但這個其他治理機構卻很少得到承認。在本文中，我將這種類型的權力稱為“路線圖”。正如我將在下面指出的那樣，整個“3074-4337-7702”治理失敗事件是以太坊現有路線圖權力淩駕於 ACD 權力之上的案例。如果我們談論治理，當我們注意到一種無形的力量壓倒了有形的力量時，我們應該非常關注，因為無形的東西往往難以解釋，也不容易被許多人注意到，所以它們必須暴露出來。

什麼是路線圖？

乙太坊社區的任何人都一定經常聽到「路線圖」一詞，無論是在「ETH2.0路線圖」中，還是在與此事件相關的「AA路線圖」中。

為了說明我的觀點，讓我們想像一個場景，在ACD會議上，核心開發人員正在討論如何擴展乙太坊：

• 核心開發者 Bob：我支援 EIP-1234，它建議將區塊速度提高 10 倍，區塊大小增加 10 倍，並降低費用 100 倍。
• 其他核心開發人員：...你瘋了嗎？

讓我們考慮一下。為什麼乙太坊核心團隊會拒絕 Bob 的提議？他只是提出了一種看似合理的擴容方式，Solana、Aptos、Sui 等許多公鏈都做到了這一點，實現了高 TPS。原因是這個虛構的 EIP-1234 與乙太坊的“以匯總為中心”的擴容路線圖相矛盾。該路線圖強調，對於去中心化，普通用戶必須能夠以低成本運行節點。因此，虛構的 EIP-1234 不太可能被接受，因為它會顯著增加運行乙太坊節點的成本。我想用這個例子來說明，參與 ACD 治理過程並決定協定更新的核心開發人員是由更高級別的力量指導的，我稱之為“路線圖”。目前，圍繞乙太坊的路線圖，有“擴容路線圖”、“AA路線圖”、“MEV路線圖”等。它們共同構成了乙太坊的整體路線圖，核心開發人員必須在此基礎上做出決策。

當核心開發人員的觀點與路線圖不一致時

由於路線圖不是乙太坊治理過程的正式部分，因此通常無法保證核心團隊會遵守它。此外，沒有正式的“批准”路線圖的程式，因此並非所有路線圖都具有相同級別的“正統”。乙太坊路線圖背後的研究人員必須努力向核心開發人員和社區推廣他們的路線圖，以獲得乙太坊核心開發團隊的“正統”和支援。關於 AA 和帳戶抽象，Vitalik 本人一再宣導以 4337 為中心的 AA 路線圖，但總的來說，主要是 4337 背後的團隊，尤其是 Yoav 和 Dror，他們在論壇和 ACD 會議上宣導以 4337 為中心的 AA 路線圖。

然而，儘管做出了這些努力，一些乙太坊核心開發人員仍然強烈反對以 4337 為中心的 AA 路線圖。他們認為 7560（未來由乙太坊用戶端實現的原生 4337 版本）過於複雜，不是“AA 殘局”的唯一可行解決方案。最終，ACD 決定批准 3074 提案，儘管 4337 團隊反對，他們認為 3074 會破壞整個 AA 生態系統。在 3074 獲得批准后，整個 4337 社區反應強烈，迫使乙太坊核心開發人員重新參與關於 3074 的討論。討論隨後陷入僵局，4337 和 3074 的作者無法說服對方。Vitalik 在最後一刻提議 EIP-7702 作為 3074 的替代方案，它明確適應了以 4337 為中心的“AA 殘局”，從而解決了衝突並使最終結果與 AA 路線圖保持一致。

Vitalik 的角色：乙太坊事實上的首席技術官

儘管 Vitalik 自稱是一名研究人員，但上面的故事清楚地表明 Vitalik 擁有與其他研究人員不同的治理權力。那麼，問題來了：Vitalik在乙太坊治理中扮演什麼角色？就我個人而言，我認為將 Vitalik 視為一家非常大的公司事實上的首席技術官可能並不合適（順便說一句，假設乙太坊是一家沒有 CEO 的“公司”以符合現實）。如果你曾經在一家擁有50多名員工的科技公司工作過，你就會知道CTO不可能參與每一個技術決策。隨著公司的發展，各種技術解決方案的決策過程不可避免地變得分散——通常，公司產品/業務的每個領域都有一個專門的團隊，該團隊通常擁有決定解決方案細節的自主權。此外，首席技術官可能不是所有（或任何）主題的頂級專家。公司內部可能有一些工程師在特定領域比 CTO 更好，因此在討論解決方案的技術細節時，通常由個別工程師做出最終決定。然而，首席技術官設定了公司的技術願景。願景的執行留給開發人員。雖然這不是一個完美的類比，但我相信它合理地概括了 Vitalik 在乙太坊生態系統中的作用。Vitalik 不會參與每一個技術決策——他可能做不到。他也不是每個領域的頂級專家。但他在為所有關鍵的乙太坊解決方案（擴展、AA、POS）制定路線圖方面具有壓倒性的影響力，這不僅是因為他的技術專長，還因為他是路線圖是否符合乙太坊願景（他的願景）的最終判斷者。

每一個成功的產品都始於一個願景

如果將 Vitalik 視為乙太坊的首席技術官還不夠有爭議，那麼最有爭議的部分是：我們應該接受 Vitalik 作為首席技術官。作為一家初創公司的創始人，我相信每個成功的產品都必須有一個連貫的長期願景——是的，乙太坊也是一個“產品”，因為它為真正的用戶解決了真正的問題。一個連貫的願景必須由少數人制定，例如初創公司的創始人，通常只有一個創始人。乙太坊的美妙之處在於，儘管是一個極其複雜的系統，擁有如此多的元件，但所有這些元件無縫地組合在一起，形成了一台運行良好的去中心化計算機，每天結算價值數十億美元的交易。我們之所以能走到這一步，不是通過某些委員會的設計方案，而是因為Vitalik憑藉他的遠見卓識和洞察力，積極發揮了領導作用，使我們能夠構建今天連貫而優雅的乙太坊。乙太坊是Vitalik在2015年提出的想法，現在仍然如此。當然，這並不是要削弱其他研究人員和工程師的貢獻——他們今天為乙太坊的大部分成就做出了貢獻。然而，這並不矛盾，因為乙太坊是Vitalik願景的實現，比其他任何人的願景都要大。老實說，你能抱怨這個嗎？當你被乙太坊生態系統的開放性、抗審查性和創新速度所吸引時，你有沒有抱怨過它源於 Vitalik 的願景？也許你沒有抱怨，因為你沒有這樣想過——但現在你這樣做了，你介意這個問題嗎？

如何解決權力下放問題？

但你可能會問，去中心化呢？如果一個人對乙太坊擁有如此壓倒性的權力，我們怎麼能說它是去中心化的呢？要回答這個問題，我們必須重溫 Vitalik 關於去中心化含義的經典文章。本文的主要見解是，去中心化有三種類型：

• 架構去中心化：在系統停止運行之前，有多少節點會發生故障？
• 邏輯去中心化：系統的各個子系統能否獨立開發，同時仍然緊密地協同工作？
• 政治權力下放：最終，有多少個人或組織控制著這個系統？

根據這些定義，乙太坊在架構上顯然是去中心化的，人們可以說它在邏輯上是去中心化的，因為它的元件缺乏強耦合（例如，在共識層和執行層之間）。至於政治去中心化，好消息是沒有個人或組織可以關閉乙太坊，即使是 Vitalik。然而，有些人可能會爭辯說，乙太坊的政治去中心化水準並不像想像的那麼高，因為Vitalik在塑造乙太坊的願景和路線圖方面發揮著重要作用。

然而，我相信，如果我們想讓乙太坊繼續創新，我們必須接受Vitalik作為事實上的首席技術官，即使這意味著犧牲一些政治去中心化。如果乙太坊變得像比特幣一樣“停滯不前”，比特幣是一個幾乎不可變的區塊鏈，那麼 Vitalik 還不如退休。但在我們到達最後一步之前，至關重要的是要有一個受到各方尊重的權威，一個值得信賴的人來做出技術決策，不僅基於所提出的技術解決方案的優越性，而且基於這些決策是否符合乙太坊的願景。

如果沒有像 Vitalik 這樣的人，可能只有兩種結果，圍繞 EIP-3074 的故事生動地說明瞭這一點：

乙太坊治理過程可能會陷入無休止的僵局，衝突各方不願妥協，沒有人取得進展，正如 Vitalik 干預之前 3074 辯論的僵局所證明的那樣。

或者乙太坊可能成為一個設計不連貫的“弗蘭肯斯坦”，3074 和 4337 可能不會相互屈服，最終導致 AA 生態系統完全破裂為兩個不相容的平行空間。

社區的作用

經過上述考慮，我們幾乎勾勒出一個完整的乙太坊治理思維，但到目前為止，我們的討論中有一個明顯的遺漏——社區。如果 Vitalik 定義了乙太坊的願景，研究人員定義了路線圖，核心開發人員實施了路線圖，那麼社區扮演什麼角色？當然，這不僅僅是閑著，對吧？幸運的是，社區起著最關鍵的作用。原因是，在有願景之前，有價值觀。我們作為一個社區走到一起，因為我們團結在某些價值觀周圍，而Vitalik的願景最終必須與這些價值觀保持一致，以保持社區的支援。乙太坊社區的每個人都認為，擁有一台每個人都可以訪問的去中心化計算機，不受審查，並且信任中立，這對世界是有益的。我們每天都在通過我們在乙太坊上所做的工作來維護和肯定這些價值觀，從而使 Vitalik、研究人員和核心開發人員提出的願景、路線圖和代碼合法化。

乙太坊治理的VVRC模型

因此，這是乙太坊治理的完整思維方式，縮寫為 VVRC：

• V==價值觀==社區;
• V==願景==維塔利克;
• R==路線圖==研究人員;
• C==Client==核心開發人員;

它們共同扮演以下角色：

• 社區圍繞特定的價值觀團結起來。
• Vitalik闡述了與這些價值觀一致的願景。
• 研究人員根據願景制定了路線圖。
• 核心開發人員根據路線圖實現用戶端。

當然，現實比任何簡單的模型所能捕捉到的要複雜得多。核心乙太坊開發人員是唯一可以通過更改客戶端代碼來真正對任何提案進行“投票”的人。Vitalik 和其他研究人員擔任顧問，有時他們的意見不被核心開發人員接受，這正是 EIP-3074 獲得批准的原因。儘管如此，我相信 VVRC 模型合理地捕捉了乙太坊治理在正常情況下的運行模式，我們需要“調試”這個過程，以防止像 EIP-3074 這樣的事故再次發生。

如何改進乙太坊的治理模型

現在我們已經對乙太坊治理流程的運作方式有了瞭解，以下是一些改進治理流程的想法：

必須提高正在審查的 EIP 的討論進度的可見性。整個社區不應該對 EIP 的接受感到“驚訝”，像 EIP-3074 這樣的意外批准不應該再次發生。EIP網站的當前「狀態」並不反映其在ACD流程中的狀態。這就是為什麼它仍然說 EIP-3074 “正在審查中”，儘管核心開發人員已經投票批准了它，但沒有跡象表明它從一開始就被考慮過批准。理想情況下，當EIP即將被接受時，乙太坊基金會應該在社交媒體上發佈明確的公告，以提高社區內的認識。

有時，核心開發者可能會低估特定 EIP 對下游專案和用戶的影響，例如 3074 和 4337 社區。由於ACD會議時間有限，需要跨時區協調，通常只有「相關人員」才能在會議上發言。儘管如此，偶爾為社區成員分配一些發言時間，以評論某些 EIP 提案在獲得批准后對下游項目的影響是有意義的。如果研究人員認為他們的意見沒有被核心開發人員接受，就像 4337 的情況一樣，他們可以邀請社區成員來加強他們的論點。

對於核心開發人員和研究人員來說，相互承認，儘管權力不同，但他們都是乙太坊治理機構的一部分，這一點至關重要。核心開發人員有權更改和更新乙太坊用戶端，這是對協定本身進行更改和“投票”的唯一途徑。研究人員通常對路線圖的更改和解釋有更多的公眾支援，這要歸功於他們積極討論和撰寫他們的想法。

當這兩種力量發生衝突時，核心開發人員可能會傾向於直接推翻研究人員的意見，就像 4337 團隊的情況一樣。然而，這種推翻可能導致衝突，因為當兩種力量發生衝突時會出現不穩定，正如EIP-3074批准后的戲劇性事件所證明的那樣。

同樣，當面臨阻力時，研究人員可能會傾向於放棄與核心開發人員的合作。在我看來，這也是創建 RIP 進程的原因之一，也是為什麼原生 AA （7560） 現在主要被提升為 RIP 而不是 EIP。

雖然在 L2 上試驗對 L1 有爭議的協定更新確實有其好處，但我們不能將 RIP 視為參與 EIP 治理過程的替代品。研究人員必須繼續與核心開發人員合作，直到雙方的價值觀與路線圖完全一致。

結論

3074/7702 事件揭示了乙太坊治理的真實運作——除了核心開發者的 EIP/ACD 流程驅動的顯性治理能力外，還有研究人員推動的路線圖驅動的隱性治理能力。當這些力量錯位時，我們會看到僵局和刺激，而另一股力量——維塔利克——可能需要以某種方式進行干預以破壞平衡。

接下來，我們提出Vitalik代表了一種獨特的的力量，即乙太坊的“願景”，它構成了任何路線圖合法性的基礎。我們將 Vitalik 比作一家大公司的首席技術官，並承認他作為偽首席技術官的角色對於乙太坊保持其創新步伐是必要的，防止乙太坊淪為“弗蘭肯斯坦”——就像一個拼湊在一起的怪物。

最後，我們介紹了VVRC模型，描述了乙太坊治理模型：價值觀（社區）⇒願景（Vitalik）⇒路線圖（研究人員）⇒客戶（核心開發人員）。然後，我們提出了各種方法來“調試”該模型的“故障”。

乙太坊治理是一台「機器製造機器」——要讓乙太坊正常運行，我們必須正確治理它。

免責聲明：

1. 本文轉載自 [極客 Web3]。 轉發原標題「3074 傳奇之後對乙太坊治理的反思」。所有版權歸原作者[Derek Chiang，ZeroDev首席執行官]所有。如果對本次轉載有異議，請聯繫 Gate Learn 團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者的觀點和意見，不構成任何投資建議。
3. 本文的其他語言翻譯由 Gate Learn 團隊完成。除非另有說明，否則禁止複製、分發或剽竊翻譯的文章。