作者：derek，ZeroDev CEO 來源：ZeroDev官網 翻譯：善歐巴，比特鏈視界

錯過 AA 提案風波？這裡為你快速回顧：

• 幾周前，核心開發人員批准了 EIP-3074 提案，該提案將為 EOA 用戶帶來 AA 的許多好處，並進入以太坊的下一個硬分叉「Pectra」。

• 從那時起，ERC-4337 社區中的許多人，尤其是 4337 作者本身，一直強烈反對3074，理由是中心化問題以及它與以太坊的AA 路線圖不兼容，該路線圖以 4337 及其表親 7560 為中心（又名「本地 AA」）。

• 上周，Vitalik 提出EIP-7702作為 3074 的替代品。它主要實現了相同的目標——為 EOA 用戶帶來 AA 的許多好處——但在某種程度上與今天的 4337 更兼容，並且向前兼容「AA 殘局」 」 那是 7560。

• 目前，核心開發人員正在審議 EIP-7702，但初步討論和社區情緒表明 EIP-7702 很可能會取代 Pectra 中的 EIP-3074。

就我個人而言，我對結果非常滿意：EOA 用戶很快就能夠使用為 ERC-4337 構建的工具和基礎設施享受 AA 的大部分好處。

然而，我不禁感到，我們實現這一成果 的方式 遠非最佳，這是許多人在過去幾周表達的觀點。我覺得通過更好的流程，我們可以共同節省大量的精力和頭痛，並更快地達到預期的結果。

在這篇博文中，我想：

• 確定流程中出了什麼問題。

• 提出一個思考以太坊治理的心理模型。

• 提出改進建議，以避免將來出現類似的治理失敗。

為什麼這個過程讓人不高興

整個事件讓很多人感到不高興，原因如下：

• 3074花了數年時間才獲得批准。

• 直到3074 最終獲得批准 後 ，核心開發人員才遭到 4337 社區的大量抵制。

• 另一方面，4337 的 作者本人也多次向核心開發者表達了他們對 3074 的擔憂，但沒有結果。

• 現在我們正在 取消批准 3074 並將其替換為另一個 EIP (7702)。

現在，上述任何內容本質上都沒有問題：

• 討論花費數年時間是可以接受的。

• EIP 在獲得批准後收到推遲是可以接受的。

• EIP 獲得批准後，如果發現新問題，可以取消批准。

然而，我們可能會同意事情本來 可以 進展得更順利。想像一下如果事情是這樣的：

• 4337 社區在核心開發者討論 3074 時積極參與其中。現在，只有以下兩種結果之一是可能的：

• 要麼在考慮 4337 社區反饋後 批准（並可能修改）3074 ，在這種情況下，4337 社區將支持 3074，我們不會撤銷 3074。

• 或者，3074 從未獲得批准，但 4337 社區和核心開發人員共同努力制定了一個每個人都滿意的提案，就像 7702 那樣。

每個人的聲音都會被聽到，並且沒有戲劇性的逆轉。那就太好了——那為什麼沒有發生呢？

什麼地方出了錯？

回顧整個過程，辯論雙方都互相指責。

核心開發人員（以及 EIP-3074 的作者）認為，這是「4337 人」的錯，他們沒有積極參與所有核心開發人員（ACD）流程，EIP 在發布之前經過了很長時間的審議。最終被客戶團隊接受，從而實現到協議中。

有人認為，在審議期間的任何時候，「4337 人」都可以進來表達他們的擔憂，而不是等到3074 人已經獲得批准 之後。 畢竟，ACD 流程有詳細記錄，會議向所有人開放，並且有像Tim Beiko這樣的人在每次 ACD 會議後積極在推特上發布摘要。那麼，如果 4337 人如此關心這個問題，為什麼他們不花時間參與呢？

另一方面，AA 團隊（4337 位作者）指出，他們一直在參加 ACD 會議，並利用一切可能的機會推遲 3074，但核心開發人員沒有聽。至於4337社區，他們大多感到措手不及——大多數人都以為3074已經死了，甚至不知道3074正在被積極考慮納入。

許多人還認為 ACD 流程過於不透明，對於那些有「實際工作」且無力跟上所有 ACD 更新的人們的參與並不友好。一些人還認為，積極尋求相關利益相關者（在本例中為 4337 社區）的反饋應該是 ACD 的責任。

然而，我認為雙方都沒有達到目標。 工作中存在一個更深層次的問題，在我們解決或至少承認這個問題之前，我們將不斷遇到治理失敗，然後是徒勞的指責。

根本原因

治理失敗的真正原因是，與普遍的看法相反，ACD 並不是協議更新的唯一治理權力，在這種情況下，它被另一個治理權力所覆蓋。

問題在於，其他治理權力很少被承認，儘管事實上它對以太坊最重要的事務（例如 AA 和擴容）的影響力比 ACD 更大。

在本文中，我將這種力量稱為「路線圖」。

正如我將要論證的那樣，整個 3074/7702 傳奇只不過是路線圖的力量壓倒 ACD 的力量的一個例子。如果我們談論治理，那麼每當我們注意到無形的力量壓倒有形的力量時，我們都應該非常擔心，因為無形的東西是不負責任的，因此必須將其公之於眾。

什麼是路線圖？

以太坊社區中的任何人都一定經常遇到「路線圖」這個術語，例如在「以 Rollup 為中心的路線圖」、「ETH 2.0 路線圖」或在這場辯論中的「 AA 路線圖」。

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

• Core Dev Bob：我支持 EIP 1234，它建議我們將區塊時間加快 10 倍，將區塊大小增加 10 倍，並降低費用 100 倍。

• 其他核心開發人員：……你瘋了嗎？

讓我們想一下。為什麼核心開發人員直接否決了鮑勃所說的話？他剛剛提出了一種非常合法的擴展形式。Solana 和許多其他 L1 都這樣做，從而產生了巨大的擴展效果。

當然，原因是這個虛構的 EIP 違背了以太坊自己的「以 Rollup 為中心」的擴展路線圖，該路線圖除其他外表明，讓普通用戶能夠運行節點對於區塊鏈去中心化至關重要，因此想像中的 EIP 是不可能的，因為它會大大增加運行節點的障礙。

我想用這個例子來說明的是，參與 ACD 流程並決定協議更新的核心開發人員受到我稱之為 路線圖 的更高力量的指導。有擴展路線圖、AA 路線圖、MEV 路線圖，凡是你能想到的——它們共同構成了核心開發人員決策的 以太坊路線圖。

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

由於路線圖不是治理的正式組成部分，因此無法保證核心開發人員與路線圖保持一致。特別是，由於沒有「批准」路線圖的正式流程，因此並非所有路線圖都被認為具有同等的合法性。路線圖背後的研究人員需要努力向核心開發人員和更大的社區宣傳他們的路線圖，以獲得合法性，從而獲得核心開發人員的支持。

就 AA 而言，Vitalik 本人曾多次推動以 4337 為中心的 AA 路線圖，但 總體而言，主要是 4337 團隊，尤其是 Yoav 和 Dror，他們在會議、在線論壇、和 ACD 會議。

然而，儘管做出了這些努力，一些核心開發者還是強烈反對以 4337 為中心的 AA 路線圖。他們認為 7560（客戶端最終必須實現的 4337 的本機版本）過於複雜，並不是「AA 殘局」的唯一可行候選者。最終，ACD 決定批准 3074，儘管 4337 團隊反對，因為它會通過創建替代性且分散性較低的AA 技術堆棧來分割 AA 生態系統。

然而，3074 獲得批准後，整個 4337 社區做出了強烈反應，迫使核心開發人員重新參與到 3074 的爭論中。隨後爭論陷入僵局，4337 作者和 3074 作者都無法說服對方，直到 Vitalik在最後一刻介入，提出 EIP-7702 作為 3074 的替代方案，明確兼容以 4337 為中心的「AA 殘局」 」，從而將衝突推向有利於 AA 路線圖的方向。

Vitalik的角色

儘管 Vitalik 將自己定位為一名研究員，但這個傳奇故事清楚地表明，Vitalik 帶來了與其他研究人員截然不同的治理權力。那麼這就引出了一個問題——Vitalik 在以太坊治理中扮演什麼角色？

就我個人而言，我發現將 Vitalik 視為一家非常非常大的公司的首席技術官很有幫助。

（順便說一下，出於這個類比的目的，這家公司沒有執行長。）

如果您曾在任何一家員工超過 50 人的科技公司工作過，您就會知道 CTO 不可能參與每項技術決策。在一定規模上，技術決策 必然會 變得分散——公司產品的每個領域通常都有一個子團隊，並且子團隊基本上可以自由地就具體實施細節做出自己的決策。

此外，首席技術官也不一定是每個（或任何）主題的最重要的專家。公司中很可能存在在特定領域比 CTO 更好的工程師。因此，在技術爭論中，做出最終決定的往往是工程師。

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

雖然這不是一個完美的類比，但我認為它合理地體現了 Vitalik 在生態系統中的作用。Vitalik 並不參與所有技術決策——他不可能參與其中。他也不是每個領域的頂級專家。但他在制定以太坊所有關鍵方面的路線圖（擴容、AA、權益證明……）方面具有壓倒性的影響力，不僅因為他的技術專長，還因為他是路線圖是否可行的最終評判者。與以太坊的願景一致—— 他的願景 。

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

如果我對 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 == 願景 == 維塔利克

• R == 路線圖 == 研究人員

• C == 客戶端 == 核心開發人員

他們一起工作是這樣的：

• 社區圍繞某些 價值觀聚集在一起。

• Vitalik 闡述了與這些價值觀一致的 願景 。

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

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

當然，現實比任何簡單模型所能捕捉到的都要混亂得多。例如，現實中的核心開發人員是唯一可以通過實現客戶端對任何決策進行「投票」的人。Vitalik 和其他研究人員僅起到諮詢作用，有時他們的意見不會被核心開發人員接受，這就是 3074 獲得批准的原因。

也就是說，我認為 VVRC 模型合理地捕捉了以太坊治理在良好情況下的工作方式，並且由我們來「調試」該過程，以便它不會像 3074 那樣失敗。

我們如何改善以太坊治理

現在我們已經有了以太坊治理應該 如何運作的心智模型，這裡有一些改進治理流程的想法，以便我們可以避免我們在 3074/7702 中經歷的那種鞭打。

• 那些正在積極考慮納入的生態產業園必須有更多的知名度。整個社區永遠不應該對 EIP 被接受感到「驚訝」，3074 就是這種情況。

• 與您的預期相反，EIP 站點上 EIP 的「狀態」並不反映其在 ACD 流程中的狀態。這就是為什麼它仍然說 3074 正在「審查」中，儘管核心開發人員已經投票批准了它，而且幾乎沒有跡象表明它曾經被考慮納入其中。

• 理想情況下，當 EIP 即將被接受時，EF 會在社交媒體上大聲而清晰地發布信息，以提高社區意識。

• 有時核心開發人員可能會低估特定EIP對下遊項目和用戶的影響，3074和4337社區就是這種情況。由於 ACD 會議時間有限且必須跨時區協調，因此強調只有「相關人員」才能在會議上發言是可以理解的。也就是說，每隔一段時間分配一些時間讓社區成員對某些 EIP 提案的下遊影響發表評論 可能是 有意義的。

• 如果研究人員認為核心開發人員沒有接受他們的意見（就像 4337 團隊的情況一樣），他們可以讓社區成員參與進來以強化他們的觀點。

• 至關重要的是，核心開發人員和研究人員之間必須相互認識到他們都是治理權力，儘管實力不同。核心開發者的「客戶端權力」是唯一能夠通過實現客戶端來真正「投票」的權力。由於研究人員積極談論和撰寫他們的路線圖，研究人員的「路線圖力量」通常會獲得更多公眾支持。

• 當兩種權力發生衝突時，核心開發人員很容易簡單地推翻研究人員的意見，例如當核心開發人員推翻 4337 團隊的反對意見時。然而，這樣的凌駕可能會導致權力衝突，因為權力在衝突時是不穩定的，正如3074獲得批准後接下來的戲劇性事件所示。

• 同樣，當面臨阻力時，研究人員很容易放棄與核心開發人員的接觸，在我看來，這是創建RIP 流程的原因之一，也是為什麼原生 AA (7560) 現在主要作為 RIP 而非 RIP 來推動的原因之一。一個EIP。 雖然幫助 L2 嘗試協議更新確實有好處，但我們不能將 RIP 視為參與 EIP 治理流程的替代品。研究人員必須繼續與核心開發人員合作，直到他們完全符合路線圖。

結論

3074/7702 的傳奇揭示了以太坊治理的 真正運作 方式——除了由核心開發人員驅動的 EIP/ACD 流程的顯性治理權力之外，還有由研究人員驅動的路線圖的隱性治理權力。當這些力量失去平衡時，我們就會看到僵局和鞭打，可能需要另一種力量——維塔利克——來扭轉平衡。

然後我們證明Vitalik 代表了一種獨特的力量，即以太坊的「願景」，這是任何路線圖合法性的基礎。我們將 Vitalik 與一家大公司的 CTO 進行比較，並承認他作為偽 CTO 的角色對於以太坊保持創新步伐是必要的，同時又不會退化為設計不連貫的弗蘭肯斯坦系統。

最後，我們提出了一個將以太坊治理視為VVRC 的思維模型：價值觀（社區）⇒ 願景（Vitalik）⇒ 路線圖（研究人員）⇒ 客戶（核心開發人員）。然後，我們建議各種方法來修復有時會導致流程在實踐中偏離此模型的「錯誤」。

以太坊治理是「構建機器的機器」——為了讓以太坊正確，我們必須讓治理正確。因此，3074 為治理出錯時提供了一個寶貴的案例研究，我希望我能夠從中吸取一些有用的教訓，以便我們能夠在未來改進以太坊治理。