深入探討 Vitalik 及各種路線圖對以太坊治理的影響

原文標題： 《 Reflecti on s on E the reum Governance Following the 3074 Saga》

作者： Derek Chiang ， ZeroDev 創始人

編譯： Faust ，極客 web3

摘要：本文是 ZeroDev 的 CEO Derek Chiang 在 V 神提出 EIP -7702 以平衡 ERC -4337 和 EIP -3074 矛盾後，對此事發表的看法。該文以一個 AA 生態內項目創始人的切身體驗，客觀的指出了以太坊目前的治理模式及其痛點，一針見血的指出：

以太坊各種治理矛盾之一在於研究員確定的路線圖，與 Geth 等客戶端開發團隊的看法存在分歧，而 Vitalik 以類似於 CTO 的身份成為了最終一錘定音的角色。

Derek 在對 Vitalik 的作用給出肯定評價後，指出了以太坊應該在治理模型上做出哪些改進，這對於以太坊社區和比特幣社區都具有很好的參考意義。

正文：如果你此前並不了解以太坊 AA （帳戶抽象）的相關事件，這裡有一個簡短回顧：

幾週前， EIP -3074 提案獲得了以太坊核心開發人員的批准，將納入下一次硬分叉「 Pectra 」。該提案將為 EVM 帶來兩個新的操作碼，讓以太坊 EOA 帳戶獲得近乎原生的 AA 體驗。

從那時起，ERC -4337 社區中的許多人，尤其是 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 在獲得批准後遭到拒絕是正常的。

· 如果發現新問題，可以在 EIP 被批准後撤銷批准。

然而，事情本來可以更順利的解決。讓我們想像一下，如果事情這樣發展：

在討論 3074 時，4337 社區積極與以太坊核心開發人員互動。如果這個前提假設成立，接下來只有兩種結果：

· 在考慮了 4337 社區反饋後，3074 提案得到批准（並可能被修改），在這種情況下，4337 社區會接受 3074，而以太坊核心團隊也不必撤銷 3074。

· 亦或是，3074 從未被批准，但 4337 社區和以太坊核心團隊共同提出了讓所有人都滿意的提案，就像 7702 一樣。

每個人的聲音都能被聽到，而且沒有戲劇性的逆轉。這本來會很好------那麼事實為何不是這樣呢？

什麼地方出了錯？

回顧整個過程，事件雙方都在互相指責對方。

以太坊核心開發人員（以及 EIP -3074 的作者）認為這是「4337 支持者」的錯誤，因為他們沒有積極參與全體核心開發人員 ( ACD ) 討論流程，在此流程中，EIP 需要經過長時間的審議，最終才會被 Geth 等以太坊客戶端開發團隊接受並實現。

有人認為，在 3074 提案被審議期間，「4337 支持者」完全可以參與進來，並表達他們的看法，而不是等到 3074 已經獲得批准後才馬後炮。畢竟， ACD 整個流程都有據可查，會議對所有人開放，而且像 TimBeiko 在每次 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 違背了以太坊的「以 rollup 為中心」的擴容路線圖，該路線圖指出，對於去中心化而言，普通用戶能否低成本的運行節點至關重要，因此虛構的 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 的角色：以太坊實質上的 CTO

儘管 Vitalik 以研究員的身份自居，但上述故事清楚地表明，Vitalik 擁有與其他研究員截然不同的治理權力。因此，問題來了：Vitalik 在以太坊治理中扮演什麼角色？

就我個人而言，我認為將 Vitalik 視為一家非常非常大的公司的 CTO 可能並無不妥（順便說一下，為了貼合實際情況，假設以太坊這個「公司」沒有 CEO ）

如果你曾經在一家擁有超過 50 名員工的科技公司工作過，你就會知道 CTO 不可能參與每一項技術決策。當公司規模達到一定程度後，各項技術方案的決策流程必然變得分散------通常公司產品 / 業務的每個領域都有一個專屬團隊，而該團隊通常可以自由地決定方案細節。

此外， CTO 也不一定在所有（或任何）話題上都是頂尖專家。公司中可能有一些工程師在特定領域比 CTO 更優秀，因此，在技術細節的方案討論上，往往是各個工程師做出最終決定。

然而， CTO 制定了公司的技術願景。願景的執行則留給開發人員。

雖然這不是一個完美的類比，但我認為它合理地概括了 Vitalik 在以太坊生態中的角色。 Vitalik 不會參與每一項技術決策------他也不可能參與。他也不是每個領域的頂尖專家。但他對制定以太坊所有關鍵方案（擴容、 AA 、 POS ……）的路線圖有著壓倒性的影響力，這不只是因為他的技術專長，還因為他是「路線圖是否符合以太坊願景（他的願景）」的最終判斷者。

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

如果我認為 Vitalik 是以太坊的 CTO 還不夠引起爭議的話，那麼最具爭議的部分來了：我們應該擁抱 Vitalik 擔任 CTO。

作為一名創業公司的創始人，我認為每一款成功的產品背後都必須有一個連貫的長期願景------沒錯，以太坊也是一款「產品」，因為它能為真正的用戶解決真正的問題。而連貫的願景必須由少數人制定，比如創業公司的創始人，而且通常只有一位創始人。

以太坊的美妙之處在於，儘管它是一個非常複雜的系統，有如此多的組件，但各個組件卻完美地組合在一起，形成了一台運轉良好的去中心化計算機，每天結算著價值數十億美元的交易活動。

我們之所以能走到今天，並不是通過某些委員會的方案設計，正是因為 Vitalik 憑藉他的遠見卓識發揮了積極的領導作用，我們才能夠打造出今天連貫而美麗的以太坊。以太坊是 Vitalik 在 2015 年提出的創意，至今依然如此。

當然，這並不是要貶低其他研究人員和工程師的貢獻，他們為以太坊今天的成就做出了大部分貢獻。然而，這並不矛盾，因為以太坊是 Vitalik 願景的實現，比任何其他人的願景都要大幾個數量級。

說實話，你能對此抱怨嗎？當你被以太坊生態系統的開放性、抗審查性和創新速度所吸引時，你是否抱怨過它始於 Vitalik 的願景？也許你沒有抱怨，因為你沒有這樣想過------但現在你有了，但你真的介意這個問題嗎？

去中心化怎麼解決？

但是，你會說，去中心化又如何呢？如果一個人對以太坊擁有如此壓倒性的權力，我們怎麼能說它是去中心化的呢？

要回答這個問題，我們必須回顧這篇關於去中心化含義的經典文章，作者是 Vitalik 。文章的關鍵見解是去中心化有三種類型：

· 架構去中心化：有多少個節點故障後系統會停止運轉？

· 邏輯上的去中心化：系統的各個子系統能否在讓系統整體正常運轉的同時獨立發展？還是必須緊密協調？

· 政治分權：最終有多少人或組織控制這個系統？

根據這些定義，以太坊顯然在架構上是去中心化的，而且可以說它在邏輯上也是去中心化的，因為它的各個組件之間缺乏強耦合（例如共識層與執行層）。

就政治去中心化而言，好消息是沒有任何個人或組織能夠關閉以太坊，甚至 Vitalik 也不行。然而，有人可能會認為，以太坊的政治去中心化程度並不像人們想象的那麼高，因為 Vitalik 在制定以太坊願景和路線圖方面發揮了重要作用。

然而，我認為，如果我們希望以太坊繼續創新，就必須接受 Vitalik 擔任事實上的 CTO ，即使這意味著犧牲一些政治上的去中心化。

如果以太坊真的像比特幣一樣「僵化」成幾乎不可改變的區塊鏈，那麼 Vitalik 可能直接退休。但在我們達到那最終一步前，至關重要的是要有一個各方都尊重的權威，這個權威值得信賴，能夠對技術決策做出判斷，不僅基於提出的技術方案是否優越，還基於這些決策是否符合以太坊的願景。

如果沒有 Vitalik 這樣的人物，那麼就只可能出現兩種結果，圍繞 3074 的故事生動地說明了這兩種結果：

· 以太坊治理流程可能會陷入無休止的僵局，矛盾雙方都不願意妥協，也沒有任何人能夠取得進展，正如 3074 辯論在 Vitalik 介入之前陷入僵局所表明的那樣。

· 或者，以太坊可能會變成一個設計不連貫的「弗蘭肯斯坦」 （譯者注：科幻小說《科學怪人》中描繪的一個怪物，由科學家在不同死人屍體上各取一部分拼湊成了一個「人」）。前面提到的 3074 和 4337 可能互不相讓，最後讓 AA 生態徹底割裂出兩個不兼容的平行空間。

社區的作用

經過了上述思考，我們快要勾勒出一個完整的以太坊治理思維模型了，但到目前為止，我們的討論中有一個明顯的遺漏------社區。

如果 Vitalik 定義了以太坊的願景，研究員們定義了路線圖，核心開發人員又實施了路線圖，那麼社區又扮演了什麼角色呢？肯定不是什麼都不做吧？

幸運的是，社區實際上扮演著最重要的角色。原因是，在有願景之前，就有價值觀。我們聚集在一起成為一個社區，因為我們團結在某些價值觀周圍，而 Vitalik 的願景最終必須與這些價值觀保持一致，否則它就會失去社區的支持。

以太坊社區的所有人都認為，擁有一台所有人都可以訪問、不受審查、可信中立的去中心化計算機對世界有益。我們每天通過在以太坊上所做的工作，來維護和肯定上述價值觀，並通過這樣做為 Vitalik 、研究員和核心開發人員制定的願景、路線圖和代碼提供正統性。

以太坊治理的 VVRC 模型

因此，這裡是以太坊治理的完整思維模型，價值觀⇒願景⇒路線圖⇒客戶端，簡稱 VVRC：

· V ==價值觀==社區；

· V ==願景== V italik；

· R ==路線圖==研究人員；

· C ==客戶端==核心開發人員；

它們一起發揮了如下作用：

· 社區凝聚在某些特定的價值觀周圍。

· Vitalik 表達了與這些價值觀一致的願景。

· 研究人員根據願景制定路線圖。

· 核心開發人員根據路線圖實現客戶端。

當然，現實比任何簡單模型所能捕捉到的要複雜得多。事實上，以太坊核心開發人員是唯一能夠通過對客戶端代碼的改動，對任意提案真正「投票」的人。Vitalik 和其他研究員只起到顧問的作用，有時他們的意見不被核心開發者接受，而這正是 EIP -3074 獲得批准的原因。

話雖如此，我認為 VVRC 模型合理地捕捉了以太坊的治理模式在通常情況下的運轉方式，而我們需要「調試」該過程，使其不會再出現 EIP -3074 那樣的事故。

如何改善以太坊的治理模型

現在我們已經對以太坊治理流程如何運作有一個心理模型，這裡有幾個改進治理流程的想法。

必須提高正在被審議的 EIP 的討論進度可見性。整個社區不應該對 EIP 被接受感到「意外」，像 3074 這種讓人感到意外的提案批准方式不該再出現。

目前 EIP 網站上的 EIP 「狀態」並不反映其在 ACD 流程中的狀態。這就是為什麼它仍然說 3074 處於「被審核」狀態，儘管核心開發人員已經投票批准了它，甚至沒有跡象表明它從一開始就被考慮批准。

理想情況下，當 EIP 即將被接受時，以太坊基金會要在社交媒體上大聲明確地宣布該結果，以提高社區的認知度。

有時核心開發人員可能會低估特定 EIP 對下游項目和用戶的影響，3074 和 4337 社區就是這種情況。由於 ACD 會議時間有限，並且必須跨時區協調，會議往往只有「相關人員」才能發言。

話雖如此，偶爾為社區成員分配一些發言時間，對某些 EIP 提案通過後對下游的影響發表評論，也是有意義的。

如果研究員覺得他們的意見沒有被核心開發人員接受，就像 4337 的情況一樣，他們可以請社區成員參與進來以強化他們的主張。

至關重要的是，核心開發人員和研究人員必須相互承認，儘管實力不同，但他們都是以太坊治理權力的一部分。核心開發人員對以太坊客戶端的改動與更新權，是唯一能通過對協議本身進行變更，而給出「投票」的權力。研究人員對路線圖的變更和解釋權通常有更多的公眾支持，這要歸功於研究員積極談論和撰寫他們的構想。

當這兩大勢力發生衝突時，核心開發人員可能會傾向於直接推翻研究人員的意見，例如核心開發人員推翻了 4337 團隊的反對意見。然而，這種推翻可能會導致衝突，因為兩大勢力發生衝突時會變得不穩定，3074 獲得批准後發生的戲劇性事件表明了這點。

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

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

結論

3074/7702 事件揭示了以太坊治理的真正運作方式------除了核心開發人員推動的 EIP / ACD 流程的顯性治理權力之外，還有由研究員推動的路線圖的隱性治理權力。當這些權力錯位時，我們會看到僵局和鞭策，而可能需要另一種力量------ Vitalik ------來以某種方式打破平衡。

然後，我們提出 Vitalik 代表著一種獨特的力量，即以太坊的「願景」，這是任何路線圖正統性的基礎。我們將 Vitalik 與一家大公司的 CTO 進行比較，並承認他作為伪 CTO 的角色對於以太坊保持創新步伐是必要的，這可以防止以太坊退化為「弗蘭肯斯坦」式的的縫合怪。

最後，我們提出了一個描述以太坊治理模型的 VVRC 模型：價值觀（社區）⇒願景（Vitalik）⇒路線圖（研究人員）⇒客戶端（核心開發人員）。然後，我們提出了各種方法來修復此模型的「錯誤」。

以太坊治理是「製造機器的機器」------要讓以太坊正確運作，我們必須合理的治理。因此，3074 為治理事故供了寶貴的案例，我希望以太坊社區能夠從中吸取一些有用的教訓，以便改善未來的以太坊治理流程。