以太坊 AllCoreDevs 協調流程與核心開發者治理機制深度分析

摘要

以太坊的核心開發者群體是以太坊治理系統中最具技術影響力但同時也是最缺乏透明度的參與者之一。AllCoreDevs 電話會議（AllCoreDevs Call）作為以太坊協議開發的核心協調機制，匯集了來自不同組織的開發者，共同決定以太坊網路的最关键技术演进方向。然而，這個機制的運作方式、決策邏輯和權力結構長期以來缺乏系統性的公開文檔。

本文深入分析 AllCoreDevs 的協調流程、核心開發者的角色與激勵結構、以及 EIP 從構想到實施的完整生命週期，同時對階層式治理（On-chain vs Off-chain）的長期可行性進行批判性分析。我們旨在為讀者提供一個全面且批判性的視角，理解以太坊「事實上的」治理機制是如何運作的。

一、AllCoreDevs 協調機制概述

1.1 什麼是 AllCoreDevs

AllCoreDevs 是以太坊核心客戶端開發者的核心協調論壇。這個非正式的協調機制匯集了負責維護以太坊主要客戶端軟體的開發者，包括 Geth、Nethermind、Reth、Besu 等團隊的成員。

歷史背景：

AllCoreDevs 的起源可以追溯到以太坊項目早期。2015 年以太坊主網上線後不久，核心開發者就意識到需要一個定期的協調機制來確保各客戶端實現之間的兼容性。早期的協調主要通過 GitHub Issues、論壇帖子和非正式的直接溝通進行。

隨著網路的成長和複雜性的增加，AllCoreDevs 電話會議逐漸成為一個更正式的協調機制。目前，這個論壇每兩週舉行一次，參與者包括來自多個組織的開發者和研究者。

參與者構成：

AllCoreDevs 的典型參與者包括：

核心客戶端團隊：
- Geth 團隊（Go-Ethereum）
- Nethermind 團隊
- Reth 團隊
- Besu 團隊（Hyperledger）

客戶端貢獻者：
- Erigon 團隊
- Teku 團隊
- Lighthouse 團隊（Sigma Prime）

研究機構：
- 以太坊基金會研究團隊
- 外部研究者（如 Flashbots、Privatix 等）

其他相關方：
- Layer 2 項目代表
- 大型質押運營商
- 錢包和工具開發者

決策範圍：

AllCoreDevs 討論和決策的範圍涵蓋：

1. 協議升級內容：哪些 EIP 應該包含在即將到來的網路升級中
2. 技術規範：客戶端實現的技術細節和兼容性要求
3. 時間表：網路升級的目標日期和回退機制
4. 緊急響應：網路出現問題時的協調響應

1.2 AllCoreDevs 電話會議的運作機制

會議結構：

AllCoreDevs 電話會議遵循一個相對固定的結構：

標準議程：
1. 開場和上次會議紀錄確認
2. 網路狀態更新
3. 進行中的升級狀態回顧
4. 即將到來的升級討論
5. EIP 狀態更新
6. 開放討論環節
7. 行動項目確認

共識形成機制：

AllCoreDevs 決策的核心原則是「工程共識」（Engineering Consensus）。這不同於民主投票或代幣投票，而是一種基於技術理由的專業判斷。

共識形成的階段：
1. 提案介紹：作者或 champion 介紹提案的動機和技術設計
2. 技術辯論：開發者提出技術疑慮、替代方案和實現挑戰
3. 問題識別：識別需要解決的未解決問題或依賴項
4. 方向確認：形成對前進方向的非正式共識
5. 行動項目：分配後續工作的責任人和截止日期

非正式共識的特徵：

AllCoreDevs 的共識是一種「非正式」的共識，這意味著：

• 沒有正式的投票機制
• 沒有少數服從多數的原則
• 決定基於「沒有強烈反對」
• 反對者需要提出具體的技術理由

這種設計的優點是避免了「多數暴政」，缺點是可能被解讀為「沉默即同意」的變體。

1.3 從 AllCoreDevs 到網路升級

AllCoreDevs 的決策需要轉化為網路的實際升級。這個過程涉及多個步驟。

升級規劃階段：

步驟 1：概念化
- 研究者提出新的改進想法
- 在 ethresear.ch 或研究論壇進行初步討論
- 評估技術可行性和優先級

步驟 2：EIP 起草
- 將概念轉化為正式的 EIP 文件
- 定義技術規範
- 確定與其他 EIP 的依賴關係

步驟 3：開發者評估
- 在 AllCoreDevs 會議中討論
- 各客戶端團隊評估實現複雜度
- 識別測試需求

步驟 4：納入升級
- AllCoreDevs 決定將 EIP 納入特定升級
- 分配「升級冠名」（如 Cancun、Prague 等）
- 設定初步的目標區塊高度

升級實施階段：

步驟 1：客戶端實現
- 各團隊根據 EIP 規範實現功能
- 保持客戶端之間的兼容性
- 持續的跨團隊測試

步驟 2：測試網部署
- 在公共測試網（如 Sepolia、Goerli）上部署
- 發現並修復 bug
- 驗證跨客戶端的兼容性

步驟 3：主網激活
- 設定最終的區塊高度
- 協調各客戶端的激活時間
- 監控升級過程

步驟 4：後續監控
- 監控網路穩定性
- 處理升級後的問題
- 文檔和經驗總結

二、核心開發者的角色與激勵結構

2.1 核心開發者的定義

「核心開發者」是一個有時被模糊使用的術語。在以太坊生態系統中，核心開發者通常指：

核心開發者的範圍：
狹義定義：
- 負責維護以太坊主要客戶端軟體的開發者
- 參與 EIP 規範制定和實現的技術專家

廣義定義：
- 參與以太坊核心協議研究的任何人
- 為客戶端代碼庫做出重大貢獻的開發者
- 參與 AllCoreDevs 協調過程的技術人員

主要客戶端團隊：

Geth 的市場主導地位一直是社區關注的焦點。這種客戶端集中度帶來了潛在的單點故障風險。

2.2 核心開發者的激勵結構

理解核心開發者的激勵結構對於理解以太坊治理至關重要。

經濟激勵：

核心開發者的經濟來源：
1. 以太坊基金會資助
   - 研究者獎學金
   - 開發者獎助金
   - 會議和活動資助

2. 私人公司僱傭
   - ConsenSys（Geth 團隊）
   - Nethermind
   - Sigma Prime（Lighthouse）
   - Paradigm（Reth）

3. 生態系統資助
   - Protocol Labs
   - Ethereum Community Fund
   - 各種 DAO 資助項目

4. 個人代幣持有
   - 許多核心開發者持有 ETH
   - 部分人參與了早期的 ICO
   - 這可能影響其對某些提案的態度

聲譽激勵：

除了經濟激勵，核心開發者還受到強烈的聲譽激勵：

聲譽激勵的來源：
1. 同行認可
   - 在技術社區的聲譽
   - 解決困難問題的能力展示
   - 技術領導力的建立

2. 歷史地位
   - 成為「區塊鏈歷史」的一部分
   - 與中本聰、Vitalik 等名字聯繫在一起
   - 「建造者」的身份認同

3. 網路效應
   - 建立的專業網路
   - 開源社區的貢獻記錄
   - 演講和會議邀請

意識形態激勵：

許多核心開發者受到強烈的意識形態驅動：

意識形態動機：
1. 建造「更好的互聯網」
   - 去中心化作為核心價值
   - 反對大型科技公司的權力集中
   - 技術自主權的理念

2. 密碼朋克精神
   - 密碼學作為解放工具
   - 隱私保護的信念
   - 抗審查的承諾

3. 社區使命
   - 服務於以太坊社區
   - 保護用戶利益
   - 實現「開放金融」的願景

2.3 激勵結構的潛在問題

激勵結構的複雜性帶來了多個潛在問題。

利益衝突：

可能的利益衝突：
1. 代幣持有與協議決策
   - 開發者可能因為持有 ETH 而支持某些提案
   - 這可能與網路的最佳利益不一致

2. 公司利益與生態利益
   - 僱主公司可能有自己的產品路線圖
   - 開發者可能在公司利益和生態利益之間面臨選擇

3. 資助來源的影響
   - 資助組織可能對研究方向有影響
   - 長期依賴單一資助者可能造成問題

職業生涯考量：

職業生涯的考量：
1. 「破壞性創新」的風險
   - 開發者可能不願意提出可能「顛覆」現有工作的提案
   - 這可能阻礙真正的創新

2. 專業技能的專一性
   - 在以太坊生態系統中的專業技能可能難以轉移
   - 這可能使開發者對協議變化過於保守

3. 「專家」地位的維護
   - 長期擔任「專家」可能阻礙對新想法的開放態度
   - 這可能導致對變化的抵抗

協調失敗的風險：

協調失敗的風險：
1. 碎片化的注意力
   - 開發者同時關注多個項目
   - 可能導致決策延遲

2. 組織邊界的障礙
   - 不同公司的開發者可能有不同的優先級
   - 跨組織協調需要額外的努力

3. 「公地悲劇」
   - 核心開發是一種「公共物品」
   - 沒有足夠的激勵促使個人投入過多

三、EIP 從構想到實施的完整生命週期

3.1 EIP 的提出階段

EIP（Ethereum Improvement Proposal）是以太坊改進的正式提案機制。理解 EIP 的生命週期對於理解以太坊治理至關重要。

想法的形成：

EIP 可以由任何人提出，這是以太坊「開放貢獻」精神的體現。然而，從一個模糊的想法到一個正式的 EIP 需要經歷多個步驟。

想法形成的來源：
1. 研究論壇（ethresear.ch）
   - 密碼學研究者發布新想法
   - 經濟學研究者提出激勵設計改進
   - 安全性研究者識別需要修復的漏洞

2. 核心開發者討論
   - 在 AllCoreDevs 會議中提出的想法
   - GitHub Issues 中的討論
   - 非正式溝通中形成的想法

3. 社區需求
   - DeFi 協議開發者的功能需求
   - 錢包和工具開發者的 API 需求
   - 質押者和節點運營商的需求

4. 外部研究者
   - 大學研究人員
   - 其他區塊鏈項目的經驗借鑒
   - 密碼學社區的新進展

EIP 的起草：

一旦一個想法獲得了足夠的關注和興趣，就可以開始起草正式的 EIP。

EIP 的基本結構（根據 EIP-1）：
1. 前導元數據
   - EIP 編號（如尚無編號則標記為「待定」）
   - 標題
   - 作者列表（姓名和聯繫方式）
   - 討論論壇（如 Ethereum Magicians）

2. 摘要
   - 用 1-3 句話描述提案的核心內容
   - 應該讓非技術讀者也能理解

3. 動機
   - 為什麼需要這個改進？
   - 當前系統存在什麼問題？
   - 這個提案如何解決這些問題？

4. 技術規範
   - 提案的詳細技術描述
   - 必須足夠精確以便實現
   - 應該包括所有必要的細節

5. 向後兼容性
   - 與現有系統的兼容性考慮
   - 如果不兼容，需要說明原因

6. 測試用例
   - 驗證提案正確性的測試用例
   - 邊界條件和錯誤情況

7. 實現參考
   - 可選的參考實現
   - 有助於加快採用

EIP 的類型：

EIP 可以分為多種類型，每種類型有不同的流程：

3.2 EIP 的審查和採用階段

「Champion」制度：

每個 EIP 都需要一個「Champion」——一個負責推動 EIP 通過整個流程的人。Champion 的職責包括：

Champion 的職責：
1. 協調開發者討論
   - 確保所有相關方都有機會發表意見
   - 記錄和回應反對意見

2. 推進提案
   - 確保提案按時進入下一階段
   - 識別和解決阻礙

3. 維護文檔
   - 更新 EIP 狀態
   - 記錄討論和決策

標準追蹤 EIP 的審查階段：

標準追蹤 EIP 的生命週期：
1. 草稿（Draft）
   - 提案正在積極開發中
   - 格式和內容可能發生重大變化
   - 可以隨時更新

2. 審查（Review）
   - 提案已完成初步開發
   - 開放給社區審查和反饋
   - 需要明确標記「最後呼籲」的開始日期

3. 最後呼籲（Last Call）
   - 提案進入最終審查階段
   - 通常持續至少 2 週
   - 這個階段的最後機會提出實質性反對意見

4. 最終（Final）
   - 提案已獲批准
   - 成為以太坊標準的一部分
   - 狀態變更為「最終」通常不可逆

其他可能狀態：
- 延期（Deferred）：暫時擱置
- 撤回（Withdrawn）：作者主動撤回
- 替代（Replaced）：被另一個 EIP 替代

Core EIP 的特殊考慮：

Core EIP 涉及共識變更，需要特別的考慮：

Core EIP 的特殊性：
1. 協調成本高
   - 需要所有客戶端團隊實現
   - 協調測試網和主網激活

2. 不可逆的後果
   - 一旦激活就無法回滾（除非硬分叉）
   - 需要更嚴格的審查

3. 社區共識要求
   - 需要更廣泛的社區支持
   - 特別是有爭議的提案

4. 時間表敏感性
   - 需要與網路升級協調
   - 延遲可能影響整個升級計劃

3.3 從 EIP 到網路升級

升級的概念：

網路升級（Network Upgrade）是一組 EIP 的集合，這些 EIP 會在同一時間點激活。

著名網路升級的歷史：
1. Frontier（2015）
   - 以太坊主網啟動
   - 首批礦工和用戶加入

2. Homestead（2016）
   - 第一個 planned upgrade
   - 改進合約 gas 成本

3. Metropolis（2017）
   - 分兩個階段：Byzantium 和 Constantinople
   - 引入大量 EIP

4. Istanbul（2019）
   - 多個性能和安全改進

5. Muir Glacier（2020）
   - 難度炸彈延遲

6. Berlin（2021）
   - gas 成本優化

7. London（2021）
   - EIP-1559 費用市場改革

8. Arrow Glacier（2021）
   - 難度炸彈延遲

9. Gray Glacier（2022）
   - 難度炸彈延遲

10. Paris（2022）
    - 從 PoW 到 PoS 的Merge

11. Shanghai/Capella（2023）
    - 質押提款啟用

12. Cancun/Dencun（2024）
    - EIP-4844 Proto-Danksharding

升級的規劃流程：

升級規劃的步驟：
1. 升級命名
   - 傳統上使用迪士尼角色名稱（如 Cancun, Prague）
   - 命名是象徵性的，沒有實質意義

2. EIP 選擇
   - AllCoreDevs 決定哪些 EIP 納入升級
   - 考慮因素包括：
     * 技術成熟度
     * 開發者準備情況
     * 社區支持
     * 依賴關係

3. 順序規劃
   - 決定 EIP 的激活順序
   - 處理相互依賴的 EIP

4. 測試時間表
   - 設定測試網激活時間
   - 設定主網激活的目標區塊高度

5. 激活協調
   - 協調各客戶端的激活
   - 準備回退計劃

升級激活的技術機制：

升級激活機制：
1. 區塊高度觸發
   - 大多數升級基於區塊高度激活
   - 需要客戶端團隊預先實現激活邏輯

2. 時代觸發（TTD）
   - The Merge 使用終端總難度（Terminal Total Difficulty）
   - 當網路累積的難度超過閾值時觸發

3. 時間戳觸發
   - 某些升級使用 Unix 時間戳
   - 提供更精確的時間控制

4. 客戶端投票
   - 一種仍在實驗中的機制
   - 驗證者可以投票表示準備好了

四、階層式治理的批判性分析

4.1 鏈上治理 vs 鏈下治理

以太坊的治理可以分為兩個主要層面：鏈上治理和鏈下治理。

鏈下治理：

鏈下治理是指在區塊鏈之外進行的決策過程。

鏈下治理的主要形式：
1. AllCoreDevs 協調
   - 核心技術決策
   - 客戶端實現協調

2. 研究論壇討論
   - ethresear.ch
   - Ethereum Magicians Forum

3. 社交媒體和 Discord
   - 快速的信息交流
   - 社區反饋收集

4. 以太坊基金會決策
   - 研究資助方向
   - 資源分配

5. DAO 投票
   - 應用層決策
   - 某些 L2 項目的治理

鏈上治理：

鏈上治理是指直接在區塊鏈上執行的決策機制。

鏈上治理的主要形式：
1. 代幣投票
   - DAO 項目的治理代幣投票
   - 決定協議參數變更

2. 委託投票
   - 代幣持有者委託投票權
   - 提高參與效率

3. 質押者投票
   - 以太坊驗證者對某些決策投票
   - 尚未大規模實施

4. 智能合約執行
   - 自動執行治理決策
   - 無需人為干預

兩種治理的比較：

4.2 當前治理模式的批判性分析

權力集中問題：

批評 1：核心開發者的權力集中
- 缺乏問責機制
- 開發者的「仁慈獨裁」性質
- 對不同意的聲音可能缺乏包容

批評 2：資金來源的影響
- 以太坊基金會的影響力過大
- 私人公司的利益可能影響決策
- 研究方向的商業化傾向

批評 3：技術精英主義
- 「專業知識」成為決策的門檻
- 普通用戶難以有效參與
- 形成了「開發者-用戶」的階層

參與度問題：

批評 1：投票率過低
- 大多數 DAO 的投票率不到 5%
- 少數大持有者控制決策

批評 2：「冷漠的大多數」問題
- 大多數代幣持有者不參與治理
- 治理權力實際上集中在少數活躍者手中

批評 3：時間和專業知識的門檻
- 理解複雜技術提案需要專業知識
- 參與治理需要投入大量時間
- 這形成了系統性的參與障礙

激勵錯位問題：

批評 1：「現狀偏好」
- 改變現狀需要更多的努力
- 這導致系統傾向於維持現狀

批評 2：短期主義
- 開發者需要展示成果
- 這可能導致忽視長期後果

批評 3：代幣持有者 vs 用戶
- 代幣持有者關心代幣價格
- 用戶關心使用體驗
- 兩者的利益可能不一致

4.3 階層式治理的長期可行性分析

支持階層式治理的論據：

支持論據 1：效率論
- 專業分工提高效率
- 避免「民主決策」的僵局
- 能夠快速響應技術變化

支持論據 2：能力論
- 技術決策需要專業知識
- 「外行投票」可能導致糟糕的技術決策
- 專家治理確保決策質量

支持論據 3：責任論
- 核心開發者對聲譽負責
- 失敗的決策會損害其職業生涯
- 這提供了問責機制

反對階層式治理的論據：

反對論據 1：合法性問題
- 缺乏正式的授權
- 「事實上的權力」不等於「正當的權力」
- 這與區塊鏈的「去中心化」敘事矛盾

反對論據 2：捕獲風險
- 權力可能被利益集團捕獲
- 核心開發者可能成為特定利益的代言人
- 缺乏防止腐敗的機制

反對論據 3：失敗模式不明
- 當治理失敗時會發生什麼？
- 沒有明確的「政府」來接管
- 這可能導致「無法治理」的狀態

長期可行性的評估：

評估維度：
1. 適應能力
   - 當前機制能否適應環境變化？
   - 歷史表明有一定的適應能力
   - 但重大危機可能暴露脆弱性

2. 包容性
   - 新參與者能否進入治理核心？
   - 開放源碼文化提供了一定程度的包容性
   - 但「老玩家」仍佔優勢

3. 問責機制
   - 當權力被濫用時如何問責？
   - 目前主要依靠社會制裁
   - 缺乏正式的法律或制度問責

4. 可持續性
   - 當前激勵結構是否可持續？
   - 依賴於核心開發者的意識形態奉獻
   - 這可能在長期內減弱

五、以太坊基金會的角色演變

5.1 以太坊基金會的歷史地位

以太坊基金會在以太坊的早期發展中扮演了核心角色。

以太坊基金會的角色（2014-2020）：
1. 研究和開發
   - 資助核心協議研究
   - 維護 Geth 客戶端（通過 ConsenSys）
   - 開發工具和文檔

2. 協調職能
   - 組織開發者會議（Devcon）
   - 協調客戶端團隊
   - 維護 EIP 流程

3. 資金提供
   - 為生態系統項目提供資助
   - 獎學金和教育
   - 會議和活動

4. 「公關」職能
   - 作為以太坊的「公眾面孔」
   - 媒體關係
   - 監管接觸

5.2 從「中心化」到「去中心化」的轉變

近年來，以太坊基金會的角色經歷了顯著的轉變。

轉變的驅動因素：
1. 意識形態轉變
   - 社群越來越強調「真正的去中心化」
   - 對單一組織控制網路的擔憂
   - 基金會的「最小化」成為目標

2. 資源重新分配
   - 基金會的 ETH 儲備減少
   - 更多的資金來自生態系統
   - 開發者開始依賴其他資助來源

3. 專業化分工
   - 不同的組織專注於不同的任務
   - Layer 2 項目承擔更多責任
   - 新的協調機制興起

轉變的表現：
1. 資助減少
   - 基金會大幅減少了直接資助
   - 鼓勵其他資助機制的發展

2. 決策分散
   - 更多決策由 AllCoreDevs 等團體做出
   - 基金會在技術決策中退居幕後

3. 研究開放
   - 更多研究在開放論壇進行
   - 減少對單一研究團隊的依賴

5.3 當前和未來的協調模式

當前的協調模式：
1. 多組織協調
   - 以太坊基金會
   - 客戶端團隊
   - 研究組織（Flashbots, EigenLayer 等）
   - Layer 2 項目

2. 開放參與
   - 任何人都可以參加 AllCoreDevs
   - 開放的論壇討論
   - 透明的決策過程（儘管不完整）

3. 漸進授權
   - 基金會逐漸將決策權轉移給社區
   - 新的資助機制興起（Gitcoin Grants 等）
   - DAO 承擔更多職能

未來可能的發展：
1. 更正式的治理機制
   - 可能引入更正式的投票機制
   - 平衡效率與合法性

2. 國際化
   - 更強的國際協調
   - 應對不同司法管轄區的監管

3. 技術變革的影響
   - 新技術可能改變治理形式
   - ZK 電路可能影響透明度

六、改進建議與未來方向

6.1 提高透明度的建議

建議 1：公開決策記錄
- 所有 AllCoreDevs 會議記錄應該公開
- 決策的理由應該記錄在案
- 重大分歧應該有正式記錄

建議 2：利益衝突披露
- 開發者應該披露相關的代幣持有
- 公司僱傭關係應該透明
- 資助來源應該公開

建議 3：績效評估
- 建立對治理機構的定期評估
- 追蹤關鍵指標
- 識別需要改進的領域

6.2 提高參與度的建議

建議 1：降低技術門檻
- 開發更多教育資源
- 簡化提案的技術語言
- 提供翻譯服務

建議 2：委託機制
- 允許沒有時間參與的代幣持有者委託投票
- 建立專業「代表」池
- 提高投票效率

建議 3：漸進參與
- 為新參與者提供「見習期」
- 降低首次貢獻的門檻
- 建立導師制度

6.3 改進激勵結構的建議

建議 1：長期激勵
- 為核心開發者提供長期激勵
- 減少對短期「快速成功」的依賴
- 建立聲譽系統

建議 2：多元資助
- 減少對單一資助來源的依賴
- 發展去中心化的資助機制
- 鼓勵生態系統的自給自足

建議 3：防止捕獲
- 建立利益衝突的處理機制
- 定期輪換關鍵角色
- 多元化決策群體

結論

AllCoreDevs 和核心開發者群體是以太坊治理系統中最重要但最缺乏透明度的組成部分。理解這個「事實上的」治理機制對於理解以太坊如何做出技術決策至關重要。

本文的分析表明：

第一，AllCoreDevs 的決策機制是一種基於「工程共識」的非正式協調過程。這種機制在效率上有優勢，但缺乏正式的问責機制。

第二，核心開發者的激勵結構是複雜的，包括經濟激勵、聲譽激勵和意識形態激勵。這種複雜性帶來了多個潛在的問題，包括利益衝突和激勵錯位。

第三，EIP 從構想到實施的生命週期是一個漫長的過程，涉及多個階段和多個利益相關者。這個過程的複雜性既是質量的保障，也是速度的障礙。

第四，階層式治理的長期可行性仍然是一個開放的問題。雖然這種模式在過去證明了相對有效，但隨著以太坊生態系統的擴大，其局限性可能會變得更加明顯。

展望未來，以太坊治理可能會沿著以下方向發展：

1. 提高透明度：更公開的決策過程和更清晰的責任歸屬
2. 提高參與度：降低參與門檻，激勵更廣泛的社區參與
3. 正式化：將非正式的協調機制逐步正式化
4. 國際化：更好地協調全球多元的參與者

最終，以太坊治理的成功將取決於它能否在保持創新活力的同時，建立起能夠處理衝突、保護利益相關者並適應不斷變化環境的有效機制。這個問題沒有簡單的答案，需要社區持續的探索和實驗。

參考文獻

1. Buterin, V. (2016). "Governance, Part 2: Plutocracy Is Still Bad". Ethereum Blog.
2. Buterin, V. (2018). "A Theory of Ethereum Governance". Ethereum Medium.
3. Ethereum Foundation. (2024). "Ethereum Improvement Proposal 1 (EIP-1): EIP Purpose and Guidelines".
4. Ethereum Foundation. (2024). "AllCoreDevs Meeting Notes Archive".
5. Del Castillo, M. (2019). "The Hidden Power Behind Ethereum's Core Developers". CoinDesk.
6. Ziman, S. (2021). "The Myth of the Benevolent Dictator". Ethereum Foundation Blog.
7. Dannen, C. (2017). "Introducing Ethereum and Solidity". Apress.
8. Antonopoulos, A. M. & Wood, G. (2018). "Mastering Ethereum". O'Reilly Media.
9. Raman, K. (2020). "Ethereum's Governance System". Ethereum Foundation Research.
10. Max-Resnick, J. (2022). "Understanding Ethereum's Upgrade Process". Ethereum Foundation Blog.
11. Beedham, M. (2021). "Ethereum's Core Developers: Who They Are and What They Do". The Block.
12. Varrall, G. (2020). "The Role of Ethereum Foundation in Network Governance". CoinDesk.
13. Schueffel, P. (2021). "Decentralized Governance Mechanisms in Blockchain Projects". Journal of Business Research.
14. Fuchs, D. (2022). "Power and Governance in Ethereum". Stanford Journal of Blockchain Law & Policy.
15. Zhao, W. (2023). "The Evolution of Ethereum's Governance Model". MIT Technology Review.