跳至主要內容

以太坊核心治理詳解

Nixo 詳細介紹了以太坊核心協定治理的實際運作方式,包括客戶端多樣性與硬分叉、ACD 會議流程、常見的誤解、開發網,以及參與治理的可行途徑。

Date published: 2024年9月15日

來自以太坊基金會的 Nixo Rokish 在 ETHBoulder 上的演講,解釋了以太坊的核心協定治理、硬分叉如何協調、關於誰控制以太坊的常見誤解,以及如何參與治理流程。

本逐字稿是 EthBoulder 發布的原始影片逐字稿 (opens in a new tab)的無障礙副本。為提高可讀性,已進行了輕微編輯。

簡介 (0:12)

感謝到場的六位朋友。好的。今天我要和大家談談以太坊核心治理。我是 Nixo。我在以太坊基金會 (EF) 領導協定支援團隊。在我們所有的任務中,其中一項就是讓治理流程變得更清晰、更容易讓其他參與這些事務的人理解,因為以太坊包含的遠不止其核心開發者。

這是本次演講的大綱。我們將討論什麼是核心治理。我們將討論常見的誤解,以及以太坊治理目前的運作方式。我們將探討它與其他去中心化治理系統的比較、為什麼建構者應該關心,以及參與的可行途徑。

那麼,什麼是核心協定治理?我運行一個節點。這意味著我有一台硬體設備,也就是我家裡的一台電腦,我在上面運行以太坊軟體。當我設定這個以太坊軟體時,我必須選擇要運行該軟體的客戶端。以太坊的獨特之處在於它擁有多個客戶端以實現客戶端多樣性。這樣做的目的是,如果一個客戶端當機,或者某個客戶端出現錯誤,整個網路不會因此癱瘓。其他區塊鏈也有其他客戶端。然而,以太坊是唯一一個其設定方式能真正保護我們免受錯誤影響的區塊鏈。因此,如果你看看像 Solana 這樣的網路,Solana 有另一個客戶端,我想它叫做 GTO,但它的採用率只有 20–21%。所以,如果佔多數的客戶端當機,這條鏈就會癱瘓。我們已經看到其他網路發生過當機的情況。這也是為什麼以太坊是最具韌性、最安全的區塊鏈。

因此,問題變成了:當你必須與這麼多不同的客戶端協調時,你如何將變更引入以太坊?首先,我們將區分硬分叉和軟分叉。軟分叉不需要像硬分叉那樣的協調。以太坊主要透過硬分叉運作。硬分叉基本上就是所有客戶端都建構一個新版本的以太坊,並決定在某個預先設定的時間啟動這個新版本的以太坊。它仍然是以太坊,但它有了新功能。它有不同的功能。而所有像我這樣在家運行節點的節點營運者或專業營運者,都必須接受這個新版本的以太坊。他們必須升級或更新他們的節點,以包含這個新軟體。

那麼,他們如何決定哪些功能要納入這些硬分叉中呢?他們必須就優先事項達成共識,以分配他們的時間和資源,因為他們可分配的時間和資源是有限的。他們會優先考慮安全漏洞或安全修補程式、使用者體驗 (UX) 等問題——如果有另一個區塊鏈正在與我們競爭,我們需要變得具有競爭力。因此,他們考慮的其中一件事是,任何加入的功能都必須與未來潛在的路線圖項目向前相容。

去年發生了一件非常有爭議的事情。你可能聽說過。它被稱為 EOF。也就是 EVM 物件格式 (EVM Object Format)。這是一組原定要納入富薩卡硬分叉的功能——佩克特拉、富薩卡,我想兩者都有——但它被拆分了。它被踢出該分叉的眾多觸發因素之一,是因為 Vitalik 發布了一篇關於以太坊採用 RISC-V 潛力的文章。許多讀到這篇文章的人看了之後覺得,好吧,如果我們採用 RISC-V,我們在 EOF 中看到的功能在 RISC-V 中是原生的。那麼我們為什麼要增加協定的複雜性呢?我們為什麼要把所有這些客戶端開發者資源投入到這件事上?如果我們最終轉向 RISC-V,這將變得毫無意義。

所以這可以說是壓垮 EOF 的最後一根稻草,它最終被踢出了分叉。他們必須考慮的另一件事是,它必須用六種不同的語言編寫並進行嚴格測試,因為這些客戶端是用六種不同的語言編寫的。所以這對他們來說是一個非常龐大的測試矩陣。正因為如此,每一個微小的設計選擇都會受到爭論,而且沒有任何權威機構可以解決分歧。因此,這引出了一個問題:誰來決定——這正是治理的核心。

常見誤解 (5:23)

這就帶我們來到了常見的誤解,我們將探討其中一些。第一個誤解是 Vitalik 決定什麼會被納入以太坊協定。其延伸誤解是以太坊基金會控制了一切。第三個誤解是這一切都是暗箱操作——由內部人士、元老級人物 (OG) 做出這些決定。

所以第一個:Vitalik 決定一切。我只是挑選了由 Vitalik 撰寫的一小部分停滯的 EIP。這意味著 Vitalik 坐下來,寫了一份提案,他說我希望將這些東西納入以太坊,但沒有人同意——這些東西就一直擱置在那裡。他無法將這些納入協定中。因此,並非他提出的所有內容都會自動被採納。

另一個延伸誤解是以太坊基金會控制了一切。我將舉一個具體的例子,我認為這個例子反駁了這一點。在 2024 年,有很多關於 Gas 限制的討論。原因是 2022 年在合併期間,我們將 Gas 限制提高到了 3000 萬。這是一個區塊中允許的最大計算量。然後我們有一段時間沒有去動它,因為它並不是一個真正的瓶頸,人們並沒有說:「這就是我不轉向以太坊的原因」或「這限制了我目前對以太坊的使用案例」。

在 2023 年底、2024 年初,有一種說法是 Solana 要來了。它將搶走以太坊的飯碗。因此,人們開始思考以太坊可以做些什麼來加速發展。其中一件事就是讓我們提高這個燃料指標。當時以太坊基金會和客戶端開發者有點像是在說:「我們還有其他事情要擔心。不過還是謝謝。」但是 Eric Connor 和 Mariano Conti 這兩個人站出來說:「不,我們要提高 Gas 限制。」Gas 限制是一個由驗證者控制的參數。因此,他們可以直接開始與驗證者、專業營運者交談,並說:「嘿,提高你們的 Gas 限制。」

到了某個時候,採用率已經足夠高,以至於以太坊基金會和客戶端開發者覺得:「哦,我們必須關注這件事。我們必須確保他們正在做的事情是安全的,並且他們最終提高到的數值對網路來說是安全的。」因此,他們必須重新分配資源。Nethermind 提出了這個測試框架。以太坊基金會在柏林做了大量工作。所有的客戶端開發者都在對此進行基準測試。所以我喜歡這個例子,因為它迫使以太坊基金會決定什麼才是優先事項。

我很喜歡我在這裡截圖的這條愚蠢的推文,因為它就像某個不知名的新聞媒體稱 Eric Connor 和 Mariano Conti 為核心開發者。他們不是核心開發者。Eric Connor 是一名質押者和社群成員。Mariano Conti 是一名前 MakerDAO 應用程式開發者。但他們卻被稱為核心開發者,因為以太坊的開發確實超出了傳統軟體運作方式的範疇,所以他們看到一個核心參數被修改,就覺得:「哦,這些一定是核心開發者。」他們並不是。所以這只是一個社群成員站出來說我們希望看到這種改變並促成其發生的例子。

這一切都是暗箱操作、內部人士、元老級人物——我稍微能理解為什麼這是一個誤解,因為你基本上來到這些治理會議,會議裡有一百個人。看起來他們都對正在發生的事情感到非常自在。而你卻一頭霧水。你完全不知道這些決定是如何做出的。你會想:「輪到我說話了嗎?」感覺就像人們都在聽同樣的 10 個人來做這些決定。

菁英領導與參與統計 (10:18)

但事實上,以太坊的開發比我在大多數軟體開發中見過的更像是一個菁英領導體制。這張截圖上的所有人——這是我決定截圖的某次隨機 ACD 會議中的三分之一——這些人都不是被指派來這裡的。每個人都只是剛好出席的人。他們是花了很多時間在這個協定上的開發者。他們是人們公認在這個領域才華橫溢、始終能做出正確決定的開發者,而且這裡沒有任何人是被指派來的。

我加入以太坊基金會才一年多一點。我抓取了這些統計數據。它們只能追溯到 2025 年 3 月。所以不到一年。所有核心開發者 (All Core Dev) 會議——也就是治理會議——的平均出席人數是 98 人。所以平均有 98 人參加這些會議。從那時起,單次會議的最高出席人數是 153 人。我想那一天我們正在決定佩克特拉主網的日期。而僅在過去一年中,總共的不重複出席人數就達到了 567 人。我非常喜歡這個指標,因為它確實表明並非每次都是同樣的 100 個人參加這些會議。這些應用程式開發者、研究人員,或者有人聽說正在討論某個功能,他們就會出現表達反對或支持,然後他們就不會再參加下一次會議了。

治理流程如何運作 (11:52)

所以這是一張有點枯燥的投影片,但我認為有必要過一遍——這就是以太坊治理目前的運作方式。因此,當討論其中一個分叉時,發生的第一件事是,人們在這個分配的時間窗口內可以提交他們的主打提案。主打提案是我們希望人們為這個分叉凝聚共識的主要功能。這可以是社群成員、研究人員、核心開發者——任何人都可以提交這些主打提案。然後時間窗口結束,在治理會議上,我們會討論哪些提案是有意義的。人們提出他們的理由,人們進行辯論,然後就我們應該為即將到來的分叉選擇哪一個達成共識。

接下來,他們會選擇次要功能。也就是那些不需要成為推動分叉的主要功能的較小項目。在這整個期間,我們有針對特定功能的開發網。開發網就像一個測試網——一個供開發者測試這些功能並確保它們真正在以太坊上運作的私人測試網路。然後在某個時間點會進行功能凍結。所以我們已經討論了主要功能,討論了次要功能,我們已經運行了這些通常是分叉主打功能的特定功能開發網。這是一個帶有星號的功能凍結,因為在那個時候我們已經決定不會再為這個分叉添加任何功能。我們將把所有功能放在一起運行,確保一切正常,確保不會出現任何問題。但是,如果某些事情開始拖慢進度,如果分叉被延遲,如果它太複雜,在那個時候仍然可以將某些功能剔除。

因此,在經歷了幾個開發網之後——可能是兩個,也可能是 10 個——客戶端在某個時候都決定這是穩定的。我們信任目前的情況。我們處於一個良好的狀態。讓我們開始考慮將其發布到以太坊主網上。他們發布客戶端版本,然後有一個 30 天的期限,以太坊基金會安全團隊會發布錯誤懸賞。他們會簽約進行安全審計。然後在那 30 天結束時,我們將分叉啟動到測試網上。這些是你可能聽說過的測試網——比如 Holesky。應用程式開發者可以在分叉上線之前在這裡測試他們的東西。這些測試網通常每個至少運行 14 天,只是為了確保一切正常。我們不預期會出現任何大問題,因為它之前已經經歷了特定功能的開發網和通用開發網,但從歷史上看,它確實曾破壞過其中一些測試網。所以這可以說是尋找並消滅所有這些錯誤的最後機會。

然後,一旦無需許可的測試網穩定下來,就會選擇主網日期。接下來,會有一個 30 天的緩衝期。這個 30 天的緩衝期之所以存在,是因為 L2 和協定要求這樣做,以便為分叉做好準備。所以這至少需要 30 天,然後分叉就會發生。

會議結構與協調 (15:01)

在這整個期間,會有一些主要的系列會議在進行。這些都是在 YouTube 上直播的公開會議。主要的是 ACDE 和 ACDC。E 代表執行層——也就是交易、智能合約部署、記憶體池管理等事務。ACDC 是共識層——也就是驗證者管理、罰沒等驗證者事務。這些會議在每週四交替進行。所以每個星期四都有一個 ACD 會議,其中一個是 ACDE,然後下一個是 ACDC,以此類推。

ACDE 和 ACDC 會議的重點是我們目前正在進行的分叉以及我們為未來規劃的分叉。ACDT 會議則更深入細節。它們是客戶端在討論他們無法解決的錯誤,或者關於他們目前正在進行的分叉需要解決的實作細節。所以現在即將發生的下一個分叉是格蘭斯特丹。因此,這些 ACDT 會議主要討論 ePBS 和區塊級存取清單,這些都是將納入格蘭斯特丹的內容。這些都是高度技術性的會議。

然後還有分組會議。分組會議是社群成員、研究人員、開發者說:「嘿,我有一個功能,我想在兩個分叉之後將其納入以太坊。」因此,他們會舉辦這些每週、每月或每兩個月一次的會議,在會議中他們會討論實作細節,更改和迭代規格,並總體上解決人們提出的所有問題、所有已知的未知數,以確保它處於最佳狀態,以便在兩個分叉之後被納入。這些會議可以由主持人決定隨時安排。

不斷演進的流程 (15:29)

所以我想讓大家深刻體會的一點是,這個流程絕不是靜態的。我剛才向你們描述的這個流程實施還不到一年。以太坊已經上線 10 年了。但它不斷在改變,而不斷改變的原因是因為沒有人負責。這個流程可以說是為了找出最有效的運作方式而演進的。雖然我說有效率,但以太坊治理的名聲卻是非常停滯、很難通過提案、令人困惑——這是因為當你有 100 到 500 人在做決定時,老實說,這套系統還能運作就已經讓我印象深刻了。

因此,Tim 在 2025 年 4 月發表了一篇名為「重新配置所有核心開發者」的文章,這最終成為了目前運作方式的提案。原因是,在此之前,我們對於以太坊應該關注什麼有一種凝聚共識的論述。有合併這個巨大的工程。每個人都非常興奮。大多數人都非常興奮。礦工則不然。然後在合併之後,有了提款功能。所以,我們不希望人們將他們的以太幣鎖定在合約中,並產生這種恐懼、不確定和懷疑 (FUD),認為他們永遠無法從中取出以太幣。因此,我們必須盡快推出這個功能。然後是原始 Danksharding,接著佩克特拉來了,佩克特拉有點像是不同且不相關的 EIP 的混合體,並沒有一個真正凝聚共識的論述。它變得如此龐大,因為人們只是因為缺乏凝聚力而把東西塞進去,以至於它不得不被分成兩個不同的分叉,因為測試團隊覺得:「範圍太大了。我們無法測試所有這些東西。」

因此,Tim 這樣做的動機是,好吧,我們需要想個辦法讓這些分叉盡可能保持專注和凝聚力。而主打提案就是對此的答案。這樣做的目的是以一種優先考慮讓每個人都知道分叉是關於什麼的方式來發布,這樣他們就不必塞進 25 個不同的 EIP。

所以頂部的另一張截圖是 Tim 提議為這些 EIP 的納入階段下定義。我想藉此說明的一點是,有時你會聽到人們說這個流程太官僚了。但實際發生的情況是,人們進入這個治理流程,他們會問:「我該如何讓一個 EIP 被納入?」而那些在那裡待了 10 年的人會說:「你就是直接去做。」人們就會覺得:「這太糟糕了。」因此,這些定義的作用是描述正在發生的事情,讓外人更容易參與這個流程,因為如果你剛來到這裡,你會想:「我有一個 EIP,我不關心以太坊治理,我只想讓這個 EIP 被納入」——你需要一個準則,你需要一個清單,你需要一個非常清晰的逐步指南來了解如何讓這個 EIP 被納入。因此,這些事情大多是為了描述流程是如何運作的,而不是制定人們必須遵守的官僚規則,從而讓人們難以將 EIP 納入。

第三件事是 Forkcast 上隨時間推移的提交紀錄。Forkcast 是我團隊的產品,由我團隊中的 Wolfram Mark 在去年年中我們團隊以目前形式成立時創建的。它已經成為人們用來與分叉互動、查看分叉中包含什麼內容以及它如何影響他們的權威資源。所有這些東西都不到兩年的歷史。所以我只是想強調,這個流程變化很大。它一點也不靜態。它不是某種僵化的官僚機構,讓你難以涉足。

類似的治理系統 (20:21)

所以我只想快速談談我所能看到的最類似於以太坊治理的去中心化治理系統。我想在這裡表達的觀點是,這是可持續的——儘管 100 到 500 人能夠做出決定令人驚訝,但它在現實世界中是可持續的。我們確實看到了這種模式成功運作的例子。

IETF 是網際網路工程任務組 (Internet Engineering Task Force)。它是一個由志工運作的標準機構,創建了 TCP/IP、HTTP。正是這個組織,讓我們今天能夠擁有自由的網際網路。Linux 核心——它是 Linux 作業系統的核心。那是驅動網際網路伺服器、Android 手機、超級電腦的開源軟體。不同之處在於,他們有一種以 Linus Torvalds 為首的仁慈獨裁者模式。但即便如此,他們仍有超過 17,000 名貢獻者,這令人難以置信。

這與以下事物不相似:其他具有鏈上代幣投票的區塊鏈。以太坊特別避免任何形式的投票機制,因為在我看來,這會導致被把持的途徑,並且在某種程度上消除了建立菁英領導體制的誘因,在這種體制下,人們只信任寫出最好程式碼的人。然後還有 L2。他們有多重簽名。他們有安全委員會。這些更像是被指派的職位來做出這些決定。這有其權衡之處。它更加中心化。不過它的行動速度更快。

為什麼建構者應該關心 (22:38)

那麼,為什麼建構者要關心治理呢?因為建構者正是以太坊為之創建的對象。以太坊不是為核心開發者創建的。它不是為驗證者創建的。有時候這些人會對此感到困惑。以太坊核心開發者和驗證者服務於以太坊,而以太坊服務於建構者和使用者。

每個人都曾在使用 AI 時有過這樣的經歷:你過於深入細節,它試圖修復這個小問題,卻未能退一步縱觀專案的整體目的。核心開發者有時也會這樣,他們試圖完善核心開發流程。在這種情況下,建構者的介入非常關鍵,因為核心開發非常耗時,以至於他們大多數時候並沒有同時在以太坊之上進行建構。他們非常投入於核心開發。這佔據了他們所有的時間。因此,應用程式建構者真的必須努力站出來說:「嘿,我們需要這個。這對以太坊至關重要。」只是為了確保有這樣的視角,並且他們不會被侷限於只為核心開發者工作。

如何參與 (24:40)

那麼,你該如何參與或讓你的功能被納入呢?這算是一般的建議,但我認為這是最好的建議。大聲說出你的痛點。上 Twitter,寫部落格文章,找出解決你痛點的方案。推測可能對你有幫助的事情。如果你發現其他人也有同樣的痛點,通常你可以找到一個現有的 EIP 來解決這個痛點,或者找人幫你寫一個能解決該問題的 EIP。

我喜歡開源軟體的一點是,通常資金充裕的公司會分配他們的開發時間和資源來維護他們正在使用的開源工具。最終會變成一群不同的公司合作維護這個東西,這在以太坊中也可以是這樣的運作方式。因此,如果你發現了一個痛點,你可以找到一個有類似痛點的 Base 開發者,而 Base 是一個資金充裕的組織,所以他們可能會願意分配一些資源來發布一個功能,或者引導一個功能通過以太坊硬分叉。

我就留給你們一些資源。Forkcast.org——你可以在那裡查看分叉中包含什麼內容,以及它如何影響某些利害關係人。所以,如果你是一名應用程式開發者,那裡有一個專門為應用程式開發者準備的區塊。如果你是一名錢包開發者、共識層客戶端開發者,那裡也有關於這些如何影響你的區塊。YouTube 是所有這些會議影片上傳的地方。它們也嵌入在 forkcast.org/calls 頁面中,那裡有摘要、發言者標註,所以更容易瀏覽這些會議。EIP 目錄、Ethereum Magicians 論壇,你可以在那裡與其他人討論潛在的解決方案或你想寫的 EIP。很快我的團隊就會有一個協定支援網站。它看起來棒極了。目前還沒準備好分享。我的電子郵件也在那裡——nixo@ethereum.org (opens email client)。就這樣。

這個頁面對您有幫助嗎?