來源：布嚕說
本文闡述了我對近期EIP-3047 事件的思考，並感謝Vitalik 和Yoav 對內容的審查。
如果你不清楚這事件，這裡簡單回顧一下：
不久前，EIP-3074 提案獲得核心開發者的綠燈，計畫在以太坊下次硬分叉Pectra 中實施。這個提案目的是讓一般以太坊帳戶（EOA）使用者也能享受到帳戶抽象化（Account Abstraction，常見簡稱AA）的許多便利。
但隨後，ERC-4337 社區，特別是該提案的起草者們，對EIP-3074 提案表達了強烈反對，理由主要是EIP-3047 可能加劇中心化風險，且與以太坊帳戶抽象路線圖不一致，該路線圖的核心是EIP-4337 及其近親EIP-7560（也稱為原生抽象帳戶）。
上週，Vitalik 提出了EIP-7702 作為EIP-3074 的替代方案。它同樣旨在為EOA 用戶帶去帳戶抽象的好處，不過設計上更契合當前的EIP-4337 標準，並能平滑過渡到最終形態—— EIP-7560。
譯者註：ERC-4337 和ERC-7560 都是以太坊生態系統中與帳戶抽象相關的提案，旨在改善使用者帳戶管理和互動方式，提升使用者體驗和安全性。
ERC-4337 允許用戶透過代理合約（Proxy Contract）來管理他們的帳戶，減少了用戶DApp 互動時的複雜性和風險。 ERC-7560 則旨在將ERC-4337 等提案中的理念直接融入以太坊的基礎層，使得所有帳戶自然具備帳戶抽象的能力，從而提供更深層的整合和優化。
ERC-4337 是向ERC-7560 過渡的一個重要步驟，兩者共同構成了以太坊帳戶抽象路線圖的核心。
目前，核心開發者團隊正對EIP-7702 進行討論，一些早期跡象和社群回饋表明，EIP-7702 很可能將在Pectra 硬分叉中取代EIP-3074。
對此結果，我個人感到十分滿意：EOA 用戶即將藉助為ERC-4337 打造的工具和基礎設施，享受到帳戶抽象帶來的多數益處。
然而，達成這目標的過程卻讓我難以釋懷，感覺遠非最佳路徑，這也是近期許多人的共同感受。我深信，若有更完善的流程，我們本來可減少紛擾，更快達成共識。
在這篇文章中，我打算：
-
剖析過程中存在的問題
-
提出理解以太坊治理的思維框架
-
探討如何改進，避免未來重蹈此次覆轍
為什麼大家感到不滿？
整個事件讓很多人感到不滿，原因有幾點：
-
漫長的審批之路：EIP-3074 耗時數年才終獲綠燈。
-
回饋滯後：核心開發者僅在3074 通過後，才廣泛聽取來自ERC-4337 社群的反對聲音。
-
預警未果：4337 提案的作者雖多次向核心開發者提出對3074 的憂慮，卻收效甚微。
-
改弦更張：如今，我們面臨撤銷EIP-3074 並以EIP-7702 取而代之的局面。
客觀而言，上述每個環節單獨看並無不妥：
-
長時間的討論合情合理。
-
批准後遭遇反對亦屬正常現象。
-
若有新問題浮現，調整甚至取消原決策，同樣符合邏輯。
然而，我們或許都認同，這個過程本來可以更順暢。想像一下，如果事情這樣發展：
在核心開發者討論EIP-3074 期間，ERC-4337 社群積極參與其中。這樣一來，只有兩種可能的結果：
-
要麼EIP-3074 在考慮了EIP-4337 社群回饋後被批准（可能有所修改），那麼EIP-4337 社群就會支持EIP-3074，也就無需推翻3074 的決定。
-
或者，EIP-3074 從未獲得批准，但EIP-4337 社群與核心開發者協作，共同推進一個大家都滿意的提案，就像EIP-7702 一樣。
每個人的聲音都被聽到，也沒有戲劇性的反轉。這本應是個理想的結局──但為何未能實現呢？
問題出在哪？
回溯整個過程，爭論雙方都有所指責。
核心開發者（包括EIP-3074 的作者）覺得，如果EIP-4337 團隊更積極參與以太坊核心開發者大會（All Core Devs，常見簡稱ACD）流程來，問題就不會發生。
在這個流程裡，提案需要長時間討論，最終由客戶端團隊接受並融入協議。他們認為，EIP-4337 團隊本可以在任何時候介入，提出他們的擔憂，而不是等到EIP-3074 已被批准後。畢竟，以太坊核心開發者大會流程公開透明，會議對外開放，像Tim Beiko 等人還會在每次會議後推文總結。如果EIP-4337 團隊真的這麼關心，為何不投入時間參與？
相反，帳戶抽象團隊（即EIP-4337 的作者）強調，他們其實有參加以太坊核心開發者大會，並抓住每個機會反對EIP-3074，只是沒有被核心開發者採納。而EIP-4337 社群的成員普遍感到意外，許多人以為EIP-3074 已被放棄，甚至不知道EIP-3074 還在考慮中。
此外，也有意見指出以太坊核心開發者大會流程太過複雜，對於有全職工作、無法跟上每一步更新的人來說難以參與。也有人認為，主動徵求關鍵利害關係人（如EIP-4337 社群）的意見應該是以太坊核心開發者大會的責任。
在我看來，兩邊都沒完全抓住問題的核心。有一個更深層的問題在起作用，除非我們解決它，或至少正視它，否則我們將反覆遇到治理失效，並陷入無意義的互相指責中。
癥結所在
治理失敗的真正癥結，在於大家普遍誤解了以太坊核心開發者大會。以太坊核心開發者大會其實並非是協議更新唯一的決策力量，在這個案例中，另一種治理力量實際上凌駕於以太坊核心開發者大會之上，發揮了決定性作用。
問題在於，這種至關重要的治理力量雖然在以太坊的重大事務上，例如帳戶抽象和擴展性問題上影響力巨大，但卻很少被正式認可。
我在這裡將這種力量稱作「路線圖」。
簡而言之，整個3074 轉至7702 的風波，就是「路線圖」力量壓過了以太坊核心開發者大會決策力量的典型案例。
從治理的角度看，當一種看不見的力量蓋過了一種看得見的力量，我們就應該警覺起來，因為看不見意味著不受監督，因此必須揭露並審視這一隱形力量。
什麼是路線圖？
在以太坊圈子裡，路線圖這個詞想必耳熟能詳，比如，以Rollup 為核心的路線圖、ETH 2.0路線圖，或是這次討論焦點的帳戶抽象路線圖。
想像一下，在一個以太坊核心開發者會議上，大家正在討論如何擴大網路規模：
核心開發者Bob 提議：我支持EIP-1234，它主張將區塊時間加快10 倍，區塊容量增加10 倍，交易費降低100 倍。
其他開發者回答：你認真的嗎？
想一想，為什麼Bob 的提議會被迅速否決？他的確提出了一個有效的擴容方案，Solana 等其他公鏈就這麼操作的，效果顯著。
原因在於，Bob 的提議與以太坊堅持的以Rollup 為核心的擴容路線圖背道而馳。這條路線圖強調，為了維護區塊鏈的去中心化特性，一般用戶能夠輕鬆運行節點至關重要。因此，Bob 的提議因大幅提高了運行節點的難度，與路線圖不符，自然被排除在外。
透過這個例子，我想展示的是，參與以太坊核心開發者大會會議、負責協議更新的核心開發者們，實際上遵循著一個更高的指導原則，即我所說的路線圖。這裡有各種路線圖，如擴容路線圖、帳戶抽象路線圖、MEV 路線圖等，它們共同構成了以太坊的整體路線圖，是核心開發者做決策的依據。
當核心開發者與路線圖不一致時
因為路線圖不屬於正式治理的一部分，核心開發者不一定總是能與之保持一致。特別是，由於沒有「批准路線圖」這樣一個官方流程，因此並非所有路線圖都享有相同的認可。這就需要路線圖背後的策劃者積極向核心開發者和廣大社區推廣，以贏得認可，進而獲取核心開發者的認同和支持。
以帳戶抽象為例，Vitalik 多次推崇以EIP-4337 為中心的路線圖，但實際上主要是EIP-4337 團隊，特別是Yoav 和Dror，他們在會議、線上論壇及以太坊核心開發者大會中積極倡導這一路線圖。
然而，即便如此，部分核心開發者仍對以EIP-4337 為中心的路線圖持反對意見，他們認為EIP-7560（即EIP-4337 的原生版本，未來客戶端需實現）過於複雜，不是實現帳戶抽象最終形態的唯一方法。最終，儘管EIP-4337 團隊反對EIP-3074 會因引入另一套較為中心化的帳戶抽象技術堆疊而分裂抽象帳戶生態，以太坊核心開發者大會還是批准了EIP-3074。
但在EIP-3074 獲得批准後，整個EIP-4337 社群的強烈反對促使核心開發者重新審視EIP-3074。雙方爭執不下，直至Vitalik 在關鍵時刻提出EIP-7702 作為EIP-3074 的替代方案，它明確支持以EIP-4337 為中心的帳戶抽象方案，這才推動局勢朝著遵循帳戶抽象路線圖的方向發展。
Vitalik 的角色
儘管Vitalik 自視為研究員，但從這次事件可以看出，他在以太坊的治理中發揮著與眾不同的獨特作用。這引出了一個問題：Vitalik 在以太坊的治理中究竟扮演著怎樣的角色呢？
我們可以把Vitalik 想像成大型公司的CTO。
如果你曾在有一定規模的科技公司工作過，例如超過50 人的，你會明白CTO 不可能參與每一個技術決策。隨著公司規模的成長，技術決策自然分散開來，各產品領域的子團隊一般都能自主決定其具體實施細節。
而且，CTO 也不一定是所有領域的頂尖專家。公司裡可能有在某些方面比CTO 更厲害的工程師。所以在技術爭論中，往往是工程師們做出最後的決定。
不過，CTO 負責制定公司的技術願景，而具體的執行則交給開發者。
雖然這個比喻不完美，但它相當準確地描繪了Vitalik 在以太坊生態系統中的角色。
Vitalik 不會參與到每一個技術決策中去——他不可能這麼做，他也不是所有領域的頂尖高手。但他對以太坊所有關鍵面向（如擴容、帳戶抽象、權益證明等）的路線圖有著巨大的影響，這不僅是因為他的技術知識，更是因為他能最終判斷一個路線圖是否與以太坊的願景——也就是他自己的願景——相符。
每個成功產品背後的驅動力是願景
身為一個創業者，我認為每一個成功的產品，背後都有著清晰的願景。而這樣的願景往往需要少數人，通常是創始團隊，甚至常常只有一位關鍵創辦人來確立。
以太坊的魅力在於，這樣一個結構複雜、涉及多層次的系統，竟能協同運作，成為每日流轉巨額價值的去中心化電腦。這不是靠委員會式的決策達成的，而是得益於Vitalik 以其願景的引領，我們才擁有了今天這樣協調且高效的以太坊。從2015 年的構想到今天，以太坊一直是Vitalik 智慧的體現。
這並不是貶低其他研究者和工程師的貢獻，他們為以太坊的發展立下了汗馬功勞。但同時，不可否認，以太坊是Vitalik 願景的極致展現，遠遠超越了任何其他個人的影響。
誠實地問自己，當你因以太坊的開放性、抗審查性以及創新活力而加入時，你是否在意過這一切起源於Vitalik 的最初構想？
或許之前沒細想，但明白了這一點後，你真的介意嗎？
以太坊因一個清晰的願景而生，也在持續實現這個願景的過程中不斷成長，而這正是其魅力所在。
那去中心化呢？
你或許會問，如果一個人對以太坊有如此重大的影響力，我們怎麼能說它是去中心化的呢？
為解答這個問題，我們可以參考Vitalik 所寫的一篇經典文章，它闡述了去中心化的多重意義。文章的關鍵點是，去中心化包含三個面向：
-
架構上的去中心化：多少節點失效，系統才會停止運作？
-
邏輯上的去中心化：系統各部分能否獨立演化而不影響整體功能？
-
政治上的去中心化：多少人或實體控制這個系統？
以太坊在架構和邏輯上無疑是去中心化的，因為它能在眾多節點間分佈，並且不同組件（如共識機制和執行層）可以相對獨立發展。
至於政治去中心化，好消息是沒有任何單一實體能關閉以太坊，包括Vitalik。但不可否認，Vitalik 在設定以太坊願景和路線圖中的重要地位意味著在政治去中心化上可能存在妥協。
我的看法是，為了讓以太坊持續創新，我們應該接受Vitalik 作為實質上的CTO 角色，即便這在某種程度上減少了政治去中心化。在以太坊尚未成熟到像Bitcoin 那樣穩定不變之前，需要有這樣一位廣受尊敬的權威人士，他不僅基於技術優劣作出決策，還要確保這些決策符合以太坊的長遠願景。
沒有Vitalik 這樣的角色，以太坊可能會面臨兩種情景，這次EIP-3074 事件就是一個活生生的例子：
-
決策僵局：各方不願妥協，專案停滯不前，就像EIP-3074 的辯論直到Vitalik 介入才打破僵局。
-
設計混亂：系統可能變成不協調的拼湊體，就像差點發生的EIP-3074 與EIP-4337 平行不相容的情況。
因此，在以太坊仍在快速演進的階段，Vitalik 的領導對於維持一個既去中心化又不失方向感的生態系統至關重要。
社區的重要性
到此，我們幾乎建構了對以太坊治理的全面理解框架，但至今討論中還有一個關鍵部分沒有提及──社群的角色。
如果Vitalik 設定願景，研究者據此規劃路線圖，核心開發者隨後實施，那麼社區在其中扮演什麼角色呢？肯定不是無足輕重吧？
事實上，社區扮演著最核心的角色。因為在願景成型之前，存在著更基礎的東西──價值觀。我們因共享某些價值觀而聚集成社區，這些價值觀是Vitalik 願景的基石，必須與之相匹配，否則社區將不復存在。
可能是成長背景的影響，或是過往經驗的啟發，以太坊社群中的每一個人，都在某個時刻意識到建立一台人人可及、無法被審查、真正去中心化的電腦對世界的價值。我們每天在以太坊上的工作，都是對這些價值觀的實踐和肯定，正是透過這些行動，我們賦予了Vitalik、研究者和核心開發者們所提出的願景、路線圖及代碼以生命和正當性。
以太坊治理簡化模型：VVRC 框架
想像以太坊的治理像一台精心設計的機器，我們將其簡化為四個關鍵部分：價值觀（Values）、願景（Vision）、路線圖（Roadmaps）和客戶端（Clients），簡稱VVRC 模型。
-
價值觀（Values）：一切始於以太坊社群共享的一套基本原則與信念
-
願景（Vision）：Vitalik 作為創辦人，基於社區的價值觀，描繪出以太坊未來發展的願景。
-
路線圖（Roadmaps）：有了清晰的願景，研究團隊就會著手製定實現這些夢想的具體步驟。他們設計出一步步邁向目標的技術路徑。
-
客戶端（Clients）：最後，核心開發者團隊依據路線圖，編寫程式碼並維護客戶端軟體，確保所有技術規劃能夠變成現實，讓使用者和開發者能夠實際使用。
這個流程聽起來很流暢，但現實中會更複雜。例如，核心開發者實際上握有最終的決策權，因為他們負責實際的軟體實作。 Vitalik 和其他研究員更多的是提供建議，有時他們的提議可能不會被採納，正如EIP-3074 事件所示。
總的來說，VVRC 模型幫助我們理解以太坊如何在理想狀況下推進治理，同時也提醒我們需要不斷調整和完善這個過程，避免再次出現類似EIP-3074 的問題。
如何改善以太坊治理
為優化以太坊治理結構，確保避免重蹈EIP-3074/ EIP-7702 事件覆轍，這裡提出幾點改善建議：
-
提升EIP 透明性：確保考慮中的EIP 對社群更加公開透明，避免類似EIP-3074 突然被接受的情況讓大家感到意外。實際上，EIPs 網站上標註的EIP 狀態並未同步以太坊核心開發者大會的審議進度，因此即使核心開發者已同意EIP-3074，其狀態仍顯示為「審核中。建議可以透過以太坊基金會的社群媒體平台，提前通知社群即將被採納的EIP。
-
增強社群參與：為社群成員設定特定時段在以太坊核心開發者大會會議中討論EIP 對下游計畫的影響，這樣可以防止像EIP-3074 對EIP-4337 社群造成的意外影響。同時，若研究者發現其回饋未獲核心開發者重視，如同EIP-4337 團隊所遭遇的困境，可邀請社群成員加入討論以增強自身立場。
-
相互理解，持續溝通：核心開發者和研究人員必須相互理解，他們都是治理的關鍵力量，只是重點不同。核心開發者透過實施客戶端擁有「執行權」，相當於擁有「投票權」。而研究人員透過積極分享和討論他們的路線圖，獲得了更廣泛的社區支持，形成了「路線圖影響力」。
當雙方意見不合時宜時，核心開發者可能傾向於直接推翻研究人員的想法，就像他們對EIP-4337 團隊所做的那樣。但這樣做容易引發反彈，因為雙方衝突時權力平衡會被打破，EIP-3074 通過後引發的混亂就是例證。
反之，研究人員遇到阻力時，可能選擇不再與核心開發者合作，這也是RIP（Rollup Improvement Proposal）流程誕生和原生帳戶抽象化（EIP-7560）主要作為RIP 推進而不是EIP 的原因之一。
雖然RIP 幫助L2 實驗那些L1 難以直接採納的協議更新是有益的，但它不能取代參與EIP 治理過程。研究者必須堅持與核心開發者溝通，直到路線圖獲得一致認同。
透過上述這些措施，可以提升治理的透明度、增強社區參與度，並促進核心開發者與研究人員間的有效合作，減少未來可能出現的治理問題。
總結
以太坊的EIP-3074/EIP-7702 事件揭示了其治理結構的複雜性：除了正式的治理流程（由核心開發者根據EIP 和以太坊核心開發者大會提案推動）外，研究者提出的非正式路線圖也擁有巨大影響力。當這兩股力量不協調時，可能會導致決策僵局或突然轉向，此時，Vitalik 的角色尤為關鍵，他能憑藉其對以太坊願景的把握來協調各方，類似於一個項目的精神領袖。
我們將以太坊的治理簡化為一個模型：社群的價值觀→ Vitalik 的願景→ 研究團隊的路線圖→ 核心開發者的實施（VVRC 模型）。這個鏈條顯示了決策如何從廣泛的理念逐步細化為具體的技術實現。
為了改善治理效率，需要針對實際操作中偏離此理想模型的問題進行修正。畢竟，良好的以太坊治理是推動專案前進的核心機制。 EIP-3074 事件作為一個實例，暴露了治理中的弱點，為我們提供了學習和改進的機會，確保未來能更好地應對類似挑戰，促進以太坊持續健康發展。
