作者：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 為治理出錯時提供了一個寶貴的案例研究，我希望我能夠從中吸取一些有用的教訓，以便我們能夠在未來改進以太坊治理。