論Vitalik 及各種路線圖對以太坊治理流程的影響

撰文：Derek Chiang，CEO of ZeroDev

編譯：Faust，極客web3

摘要：本文是ZeroDev 的CEO Derek Chiang 在V 神提出EIP-7702 以平衡ERC-4337 和EIP-3074 矛盾後，對此事發表的看法。這篇文章以一個AA 生態內計畫創始人的切身體驗，客觀的指出了以太坊目前的治理模式及其痛點，一針見血的指出：

以太坊各種治理矛盾之一在於研究員確定的路線圖，與Geth 等客戶端開發團隊的看法存在分歧，而Vitalik 以類似於CTO 的身份成為了最終一錘定音的角色。

Derek 在對Vitalik 的角色給予肯定評價後，指出了以太坊應該在治理模式上做出哪些改進，這對以太坊社群和比特幣社群都具有很好的參考意義。

正文：如果你之前並不了解以太坊AA（帳戶抽象）的相關事件，這裡有一個簡短回顧：

幾週前，EIP-3074 提案獲得了以太坊核心開發人員的批准，將納入下一次硬分叉「Pectra」。該提案將為EVM 帶來兩個新的操作碼，讓以太坊EOA 帳戶獲得近乎原生的AA 體驗。

從那時起，ERC-4337 社群中的許多人，尤其是4337 的提出者一直在強烈反對EIP-3074，理由是擔心該提案會帶來許多安全隱患，而且與以太坊的AA 路線圖不相容。在以太坊先前的路線圖中，明確指出以ERC-4337 及相似提案7560（又稱「nativeAA」）為中心。

5 月初，Vitalik 提出了EIP-7702 作為EIP-3074 的替代品，在4337 和3074 之間達成了平衡——既能為EOA 用戶帶來AA 的體驗，但在某種程度上與ERC-4337 更加相容，並且與“AA 最終方案”7560 相容。

目前，以太坊核心開發人員正在考慮EIP-7702 的事宜，目前的初步討論結果和社區情緒表明，EIP-7702 很有可能取代上文中提到的EIP-3074。

就我個人而言，我對這個結果非常滿意：EOA 使用者很快就能體驗到ERC-4337 生態內的各種產品，享受AA 帶來的大部分好處。但是，我不禁覺得，我們可以有更好的方式來實現上述結果，過去幾週內許多人都指出了這一點。我覺得，如果有更好的治理流程，我們本來可以節省大量的精力，並且更快達到預期效果。

在這篇文章中，我想：

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

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

• 提出改進建議，以避免未來出現類似的治理事故

EIP-3074 事件的總結與反思

前文提到的故事讓很多人不高興，原因如下：

EIP-3074 花了數年時間才獲得批准。在3074 最終獲得批准後，以太坊核心開發人員才受到來自4337 社群的強烈反對。

另一方面，ERC-4337 的作者多次向以太坊核心團隊表達自己對EIP-3074 的擔憂，但無濟於事。現在以太坊正計劃取消批准3074，並用另一個EIP（7702）取代它。

上述流程中任何一點，本質上都沒有錯：

• 關於一個EIP 的討論可能需要幾年時間，這是正常的。

• EIP 在獲得批准後遭到拒絕是正常的。

• 如果發現新問題，可以在EIP 被批准後撤銷批准。

然而，事情本來可以更順利的解決。讓我們想像一下，如果事情這樣發展：

在討論3074 時，4337 社群積極與以太坊核心開發人員互動。如果這個前提假設成立，接下來只有兩種結果：

• 在考慮了4337 社群回饋後，3074 提案得到批准（並可能被修改），在這種情況下，4337 社群會接受3074，而以太坊核心團隊也不必撤銷3074。

• 亦或是，3074 從未被批准，但4337 社區和以太坊核心團隊共同提出了讓所有人都滿意的提案，就像7702 一樣。

每個人的聲音都能被聽到，而且沒有戲劇性的逆轉。這本來會很好——那麼事實為何不是這樣呢？

什麼地方出錯？

回顧整個過程，事件雙方都在互相指責對方。

以太坊核心開發人員（以及EIP-3074 的作者）認為這是「4337 支持者」的錯誤，因為他們沒有積極參與全體核心開發人員(ACD) 討論流程，在此流程中，EIP 需要經過長時間的審議，最終才會被Geth 等以太坊客戶端開發團隊接受並實現。

有人認為，在3074 提案被審議期間，「4337 支持者」完全可以參與進來，並表達他們的看法，而不是等到3074 已經獲得批准後才馬後砲。畢竟，ACD 整個流程都有據可查，會議對所有人開放，而且像TimBeiko 在每次ACD 會議後都會積極發布總結性的推文。那麼，如果4337 支持者如此關心這個主題，為什麼他們不積極且及時參與相關會議？

另一方面，4337 的核心成員指出，他們一直在參加ACD 會議，並盡可能反對3074，但以太坊核心開發人員不聽。至於4337 社區成員，他們大多感到突如其來——很多人都以為3074 已經涼透了，甚至不知道3074 正大概率被批准。

許多人指出，ACD 會議的整個過程很不透明，對那些在以太坊社區裡「認真做事」，但無法及時跟進ACD 更新進度的人而言並不友好。有些人也認為，ACD 應該主動積極的向利害關係人（這裡指4337 社群）徵詢回饋。

然而，我認為雙方都沒有切中要害。這背後還有更深層的問題，除非我們解決或至少承認這個問題，否則我們將持續的陷入治理事故，然後矛盾雙方互相指責對方，但這毫無意義。

治理事故的根本原因：路線圖

與一般看法相反，治理事故的根源在於，ACD 並不是以太坊協議更新的唯一治理權來源，它被另一個治理權來源所取代。而這裡的問題就在於，儘管另一種治理權力在以太坊核心問題（如AA 和擴展性）上的影響力比ACD 還大，但它卻很少被承認。

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

正如我下面要指出的，整個「3074-4337-7702」治理故障事件，是以太坊既有路線圖的權力壓倒ACD 權力的一個案例。如果我們談論的是治理，當我們注意到有一種無形力量壓倒了有形力量，我們應該對此極其擔心，因為無形的東西往往很難解釋並無法被太多人注意到，因此必須將其揭露。

什麼是路線圖？

以太坊社區中的任何人都一定經常看到“路線圖”一詞，例如在“以匯總為中心的路線圖”，“ETH2.0 路線圖”中，或者和此次事件相關的“AA 路線圖」。

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

• 某核心開發人員Bob：我支持EIP-1234，該提案建議我們將出塊速度加快10 倍，將區塊大小增加10 倍，將費用降低100 倍。

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

讓我們想一想。為什麼以太坊核心團隊會拒絕Bob 說的話？他只是提出了一種看起來非常合理的擴容方式，Solana 和Aptos、Sui 等許多公鏈都這麼做了，並且取得了很高的TPS。

原因是，這個虛構的EIP-1234 違背了以太坊的「以rollup 為中心」的擴容路線圖，該路線圖指出，對於去中心化而言，普通用戶能否低成本的運行節點至關重要，因此虛構的EIP-1234 不可能被接受，因為它會大幅增加運行以太坊節點的成本。

我想用這個例子來說明，參與ACD 治理流程並決定協議更新的核心開發人員，受到一種更高級力量的指導，我稱之為「路線圖」。目前圍繞著以太坊的路線圖，有「擴容路線圖」、「AA 路線圖」、「MEV 路線圖」等等，它們共同構成了以太坊的整體路線圖，核心開發人員必須以此為基礎做出決策。

當核心開發人員的觀點與路線圖不一致

由於路線圖不是以太坊治理流程中的正式組成部分，因此往往無法保證核心團隊會遵守路線圖。而且，並沒有「批准」路線圖的正式流程，所以並不是所有路線圖都具有同等的「正統性」。以太坊路線圖背後的研究人員必須努力向核心開發者和社區宣傳他們的路線圖，以獲得「正統性」，從而獲得以太坊核心開發團隊的支持。

就AA 和帳戶抽象而言，Vitalik 本人曾多次推動以4337 為中心的AA 路線圖，但總體而言，主要是4337 背後的團隊，尤其是Yoav 和Dror，在論壇和ACD 會議上倡導以4337為中心的AA 路線圖。

然而，儘管做出了這些努力，一些以太坊核心開發者仍然強烈反對以4337 為中心的AA 路線圖。他們認為7560（以太坊用戶端未來要實施的4337 原生版本）過於複雜，並不是「AA 終局」的唯一可行方案。最終，ACD 決定批准3074 提案，儘管這遭到了4337 團隊反對，後者認為3074 會使得整個AA 生態系統割裂開。

3074 獲得批准後，整個4337 社群都做出了強烈反應，迫使以太坊核心開發人員重新參與3074 的討論。討論隨後陷入僵局，4337 的作者和3074 的作者都無法說服對方，Vitalik 在最後一刻提出EIP-7702 作為3074 的替代方案，該方案明確兼容以4337 為中心的“AA 終局”，從而化解衝突並使得最終結果和AA 路線圖能夠貼合。

Vitalik 的角色：以太坊實質上的CTO

儘管Vitalik 以研究員的身份自居，但上述故事清楚地表明，Vitalik 擁有與其他研究員截然不同的治理權力。因此，問題來了：Vitalik 在以太坊治理中扮演什麼角色？

就我個人而言，我認為將Vitalik 視為一家非常非常大的公司的CTO可能並無不妥（順便說一下，為了貼合實際情況，假設以太坊這個“公司”沒有CEO）

如果你曾經在一家擁有超過50 名員工的科技公司工作過，你就會知道CTO 不可能參與每項技術決策。當公司規模達到一定程度後，各項技術方案的決策流程必然變得分散－通常公司產品/ 業務的每個領域都有一個專屬團隊，而該團隊通常可以自由地決定方案細節。

此外，CTO 也不一定在所有（或任何）主題上都是頂尖專家。公司中可能有一些工程師在特定領域比CTO 更優秀，因此，在技術細節的方案討論上，往往是各個工程師做出最終決定。

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

雖然這不是一個完美的類比，但我認為它合理地概括了Vitalik 在以太坊生態中的角色。 Vitalik 不會參與每一項技術決策——他也不可能參與。他也不是每個領域的頂尖專家。但他對制定以太坊所有關鍵方案（擴容、AA、POS…）的路線圖有著壓倒性的影響力，這不只是因為他的技術專長，還因為他是「路線圖是否符合以太坊願景（他的願景）」的最終判斷者。

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

如果我認為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==願景==Vitalik；

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

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

它們一起發揮瞭如下作用：

• 社區凝聚在某些特定的價值觀周圍。

• Vitalik 表達了與這些價值觀一致的願景。

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

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

當然，現實比任何簡單模型所能捕捉到的要複雜得多。事實上，以太坊核心開發人員是唯一能夠透過對客戶端程式碼的改動，對任意提案真正「投票」的人。 Vitalik 和其他研究員只起到顧問的作用，有時他們的意見不被核心開發者接受，而這正是EIP-3074 獲得批准的原因。

話雖如此，我認為VVRC 模型合理地捕捉了以太坊的治理模式在通常情況下的運作方式，而我們需要「調試」該過程，使其不會再出現EIP-3074 那樣的事故。

如何改善以太坊的治理模型

現在我們已經對以太坊治理流程如何運作有一個心理模型，這裡有幾個改善治理流程的想法。

• 必須提高正在審議的EIP 的討論進度可見度。整個社區不應該對EIP 被接受感到「意外」，像3074 這種讓人感到意外的提案批准方式不該再出現。

目前EIP 網站上的EIP「狀態」並不反映其在ACD 流程中的狀態。這就是為什麼它仍然說3074 處於「被審核」狀態，儘管核心開發人員已經投票批准了它，甚至沒有跡象表明它從一開始就被考慮批准。

理想情況下，當EIP 即將被接受時，以太坊基金會要在社群媒體上大聲明確地宣布該結果，以提高社群的認知度。

• 有時核心開發人員可能會低估特定EIP 對下游專案和使用者的影響，3074 和4337 社群就是這種情況。由於ACD 會議時間有限，且必須跨時區協調，會議往往只有「相關人員」才能發言。

話雖如此，偶爾為社區成員分配一些發言時間，對某些EIP 提案通過後對下游的影響發表評論，也是有意義的。

如果研究員覺得他們的意見沒有被核心開發人員接受，就像4337 的情況一樣，他們可以請社群成員參與以強化他們的主張。

• 至關重要的是，核心開發人員和研究人員必須相互承認，儘管實力不同，但他們都是以太坊治理權力的一部分。核心開發人員對以太坊客戶端的改動與更新權，是唯一能透過對協議本身進行變更，而給予「投票」的權力。研究人員對路線圖的變更和解釋權通常有更多的公眾支持，這要歸功於研究員積極談論和撰寫他們的構想。

當這兩大勢力發生衝突時，核心開發人員可能傾向於直接推翻研究人員的意見，例如核心開發人員推翻了4337 團隊的反對意見。然而，這種推翻可能會導致衝突，因為兩大勢力發生衝突時會變得不穩定，3074 獲得批准後發生的戲劇性事件表明了這一點。

同樣，當面臨阻力時，研究員可能會傾向於放棄與核心開發人員的合作，在我看來，這也是創建RIP 流程的原因之一，也是為什麼原生AA(7560) 現在主要作為RIP 而不是EIP 進行推廣的原因。

雖然在L2 上試驗那些對L1 來說有爭議的協議更新確實有好處，但我們不能將RIP 視為參與EIP 治理流程的替代品。研究人員必須繼續與核心開發人員合作，直到雙方的價值觀都完全符合路線圖。

結論

3074/7702 事件揭示了以太坊治理的真正運作方式——除了核心開發人員推動的EIP/ACD 流程的顯性治理權力之外，還有由研究員推動的路線圖的隱性治理權力。當這些權力錯置時，我們會看到僵局和鞭策，而可能需要另一種力量——Vitalik——以某種方式打破平衡。

然後，我們提出Vitalik 代表著一種獨特的力量，即以太坊的「願景」，這是任何路線圖正統性的基礎。我們將Vitalik 與一家大公司的CTO 進行比較，並承認他作為偽CTO 的角色對於以太坊保持創新步伐是必要的，這可以防止以太坊退化為“弗蘭肯斯坦”式的縫合怪。

最後，我們提出了一個描述以太坊治理模型的VVRC 模型：價值觀（社群）⇒願景（Vitalik）⇒路線圖（研究員）⇒客戶（核心開發人員）。然後，我們提出了各種方法來修復此模型的“錯誤”。

以太坊治理是「製造機器的機器」──要讓以太坊正確運作，我們必須合理的治理。因此，3074 為治理事故供了一個寶貴的案例，我希望以太坊社群能夠從中吸取一些有用的教訓，以便改善未來的以太坊治理流程。

【免責聲明】市場有風險，投資需謹慎。本文不構成投資建議，使用者應考慮本文的任何意見、觀點或結論是否符合其特定狀況。據此投資，責任自負。

OKEX下載，歐易下載，OKX下載

okex交易平台app下載