本文主要討論了以太坊最近的EIP-3074事件，涉及了以太坊治理中的複雜性和問題。作者認為除了正式的治理流程外，路線圖也對以太坊有巨大影響。當這兩種力量不協調時，可能導致決策僵局或突然轉變。 Vitalik的角色在這些情況下至關重要，他能夠協調各方，統一專案方向。文章提出了簡化的以太坊治理模式VVRC，強調社群的價值觀、Vitalik的願景、研究團隊的路線圖和核心開發者的實施之間的關係。建議透過提高EIP透明性、增強社群參與和加強溝通來改善以太坊治理效率。
譯文：3074 事件後對以太坊治理的反思
作者：德瑞克
譯者：黛西
本文闡述了我對近期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為核心的擴散內容路線圖背道而馳。一條路線圖去強調，為了維護區塊鏈的中心化特性，一般使用者能夠輕鬆運行節點至關重要。因此，鮑勃的提議導致大幅提高了運行節點的負荷，而路線圖不符，自然被排除在外側。
透過這個例子，我想展示的是，參與以太坊核心開發者大會會議、負責協議更新的核心開發者們，實際上遵循著一個更高的指導原則，即我所說的路線圖。這裡有各各種路線圖，如擴容路線圖、帳戶抽象路線圖、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作為本體上的CTO角色，在某種程度上減少了政治去中心化。在以太坊尚未成熟到像比特幣那樣穩定不變之前，需要有這樣一位廣受尊敬的權威人士，他不僅基於技術優劣做出決策，還要確保這些決策符合以太坊的長願景。
沒有Vitalik這樣的角色，以太坊可能會面臨兩個場景，這次EIP-3074事件就是一個活生生的例子：
決策僵局：各方不願妥協，專案停滯不前，就像EIP-3074 的爭論直到Vitalik 介入才打破僵局。
設計混亂：系統可能變成不協調的拼湊體，就像差點發生的EIP-3074 與EIP-4337 平行不相容的情況。
因此，在以太坊目前快速演進的階段，Vitalik的領導對於維持一個既去中心化又不失方向感的生態系統至關重要。
社區的重要性
到這裡，我們已經基本建構起對以太坊治理的全面理解框架，但前面討論中還有一個關鍵部分沒有提及──社群的角色。
如果Vitalik 設定了願景，研究人員據此規劃路線圖，核心開發者隨後實施，那麼社區裡的人會扮演什麼角色呢？肯定不是無足輕重吧？
事實上，社區扮演著最核心的角色。因為在願景塑造之前，存在著更基礎的東西──價值觀。我們因某些價值觀而聚集成社區，這些價值觀是維塔利克願景的基石，必須與之相匹配，否則社區將不存在。
可能是成長背景的影響時刻，或是過去經歷的、以太社區中的每一個人的啟示，都在某個人意識到建立了一個人可及、無法被審查、真正去中心化的計算機對世界我們每天在以太坊上的工作，都是針對這些價值觀的和實踐，正是透過這些行動，我們賦予了Vitalik、核心開發者們所提出的願景、路線圖及代碼以生命和正當性。
以太坊治理簡化模型：VVRC 框架
想像以太坊的治理就像一個提出設計的機器，我們將其簡化為四個關鍵部分：價值觀（Values）、願景（Vision）、路線圖（Roadmaps）和客戶端（Clients），即VVRC模型。
價值觀：一切源自於以太坊社群共同的一套基本原則與信念
願景（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 事件作為一個實例，暴露了治理中的弱點，為我們提供了學習和改進的機會，確保未來能更好地應對類似的挑戰，促進以太坊持續健康發展。
資訊來源：0x資訊編譯自網際網路。版權歸作者imToken所有，未經許可，不得轉載
