以太坊治理反思：為什麼大家對 EIP-3074 事件感到不滿？

WEEX 唯客博客， 作者： imToken   本文闡述了我對近期 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 被突然接受的情況讓大家感到意外。實際上， EIP s 網站上標註的 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 事件作為一個實例，暴露了治理中的弱點，為我們提供了學習和改進的機會，確保未來能更好地應對類似挑戰，促進以太坊持續健康發展。 WEEX唯客交易所官網：weex.com