以太坊核心治理详解

以太坊基金会的 Nixo Rokish 在 ETHBoulder 上发表的演讲，解释了以太坊的核心协议治理、硬分叉是如何协调的、关于谁控制以太坊的常见误解，以及如何参与治理过程。

本文字稿是 EthBoulder 发布的原视频文字稿 (opens in a new tab)的无障碍副本。为了提高可读性，进行了少量编辑。

简介 (0:12)

感谢到场的六位朋友。好的。今天我来和大家谈谈以太坊核心治理。我叫 Nixo。我在以太坊基金会（EF）领导协议支持团队。在我们所有的职责中，其中一项就是让治理过程变得更清晰，让其他参与这些事务的人更容易理解，因为以太坊的参与者远不止核心开发者。

这是本次演讲的大纲。我们将讨论什么是核心治理。我们将讨论一些误解，以及以太坊治理目前的运作方式。我们还会探讨它与其他去中心化治理系统的比较、为什么构建者应该关注，以及参与治理的可行途径。

那么，什么是核心协议治理？我运行着一个节点。这意味着我有一台硬件设备，也就是我家里的一台计算机，我在上面运行以太坊软件。当我设置这个以太坊软件时，我必须选择运行该软件的客户端。以太坊的独特之处在于它有多个客户端，以实现客户端多样性。这样做的意义在于，如果一个客户端宕机，或者某个客户端出现漏洞，整个网络不会随之瘫痪。其他区块链也有不同的客户端。然而，以太坊是唯一一个其架构设置能够真正保护我们免受漏洞影响的区块链。比如你去看 Solana，Solana 也有另一个客户端，我想大概叫 GTO，但它的采用率只有 20–21%。因此，如果占多数的客户端宕机，整条链就会瘫痪。我们已经看到过其他网络出现宕机的情况。这也是为什么以太坊是最具弹性、最安全的区块链。

那么问题来了，当你必须与这么多不同的客户端进行协调时，你如何将变更引入以太坊？首先，我们要区分硬分叉和软分叉。软分叉不需要像硬分叉那样的协调。以太坊主要通过硬分叉来运作。硬分叉基本上是指所有客户端都构建一个新版本的以太坊，并决定在某个预先配置的时间启动这个新版本。它仍然是以太坊，但拥有了新功能。它具有不同的特性。所有像我这样在家里运行节点的节点运营商，或者专业的运营商，都必须接受这个新版本的以太坊。他们必须升级或更新他们的节点，以包含这个新软件。

那么他们如何决定哪些功能会被纳入这些硬分叉呢？他们必须就优先级达成一致，以分配他们的时间和资源，因为他们可分配的时间和资源是有限的。他们会优先考虑安全漏洞或安全补丁、用户体验（UX）等问题——如果有其他区块链与我们竞争，我们需要变得比它们更有竞争力。因此，他们考虑的因素之一是，任何引入的功能都必须与未来潜在的路线图项目向前兼容。

去年发生了一件非常有争议的事情。你可能听说过。它叫做 EOF，即 EVM 对象格式（EVM Object Format）。这是一组原定要进入弗萨卡（Fusaka）硬分叉的功能——佩克特拉（Pectra）、弗萨卡，我想两者都有——但它被拆分了。它被踢出该分叉的众多触发因素之一，是因为 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 要来了。它将抢走以太坊的饭碗。因此，人们在思考以太坊能做些什么来加速。其中一件事就是让我们提高这个 Gas 指标。当时以太坊基金会和客户端开发者有点像在说：“我们还有其他事情要操心。不过还是谢谢了。”但是 Eric Connor 和 Mariano Conti 这两个人站出来说：“不行，我们要提高 gas 上限。”gas 上限是一个由验证者控制的参数。因此，他们可以直接开始与验证者、专业运营商交谈，并说：“嘿，提高你们的 gas 上限吧。”

在某个时候，采用率达到了足够的程度，以至于以太坊基金会和客户端开发者觉得：“哦，我们必须关注这件事了。我们必须确保他们所做的是安全的，并且他们最终提高到的数值对网络来说是安全的。”因此，他们不得不重新分配资源。奈瑟曼德提出了这个测试框架。以太坊基金会在柏林做了大量工作。所有的客户端开发者都在对此进行基准测试。所以我很喜欢这个例子，因为它迫使以太坊基金会去决定优先处理什么。

我很喜欢我在这里截图的这条愚蠢的推文，因为这就像是一些不知名的新闻媒体把 Eric Connor 和 Mariano Conti 称为核心开发者。他们不是核心开发者。Eric Connor 是一名质押者和社区成员。Mariano Conti 是一名前 MakerDAO 应用开发者。但他们就是被称为核心开发者，因为以太坊的开发确实超出了传统软件运作方式的范畴，所以他们看到一个核心参数被修改，就觉得：“哦，这些肯定是核心开发者。”他们并不是。所以这只是一个社区成员介入并表示我们希望看到这种改变，并促成其发生的例子。

这一切都是暗箱操作、内部人士、元老（OG）——我稍微能理解为什么会有这种误解，因为当你来到这些治理会议时，会议里有一百个人。看起来他们对正在发生的事情都非常适应。而你却一头雾水。你完全不知道这些决定是如何做出的。你会想：“轮到我说话了吗？”感觉就像大家都在听同样的 10 个人来做这些决定。

唯才是举与参与统计 (10:18)

但事实是，以太坊的开发比我在大多数软件开发中见过的更倾向于唯才是举（meritocracy）。这张截图上的所有人——这是我决定截图的某次随机 ACD（核心开发者）会议中的三分之一——这些人中没有一个是被任命来这里的。每个人都只是碰巧出席的人。他们是在这个协议上投入了大量时间的开发者。他们是被大家公认为在这个领域有才华、能持续做出正确决定的开发者，这里面没有人是被指派来的。

我加入以太坊基金会才一年多一点。我获取了这些统计数据。它们只能追溯到 2025 年 3 月。所以不到一年。所有核心开发者（All Core Dev）会议——也就是治理会议——的平均出席人数是 98 人。所以平均每次会议有 98 人参加。从那以后，单次会议的最多出席人数是 153 人。我想那一天我们正在决定佩克特拉主网的日期。仅在过去一年中，独立出席总人数就达到了 567 人。我非常喜欢这个指标，因为它确实表明，并不是每次都是同样的 100 个人参加这些会议。这些应用开发者、研究人员，或者某个人听说了正在讨论的某个功能，他们就会出席表达反对或支持，然后他们就不会再参加下一次会议了。

治理流程是如何运作的 (11:52)

这张幻灯片有点枯燥，但我认为过一遍很重要——这就是以太坊治理目前的运作方式。当讨论其中一个分叉时，首先发生的事情是，人们在这个分配的时间窗口内可以提交他们的主打提案（headliner proposal）。主打提案是我们希望大家在这个分叉中集中关注的主要功能。提交主打提案的人可以是社区成员、研究人员、核心开发者——实际上任何人都可以。然后时间窗口结束，在治理会议上，我们会讨论其中哪些是有意义的。人们陈述自己的理由，进行辩论，然后就即将到来的分叉应该选择哪一个达成共识。

之后，他们会选择次要功能。也就是那些不需要成为推动分叉的主要功能的较小事项。在整个这段时间里，我们有针对特定功能的开发网。开发网就像一个测试网——一个供开发者测试这些功能并确保它们真正在以太坊上运行的私有测试网络。然后在某个时候会进行功能冻结。我们已经讨论了主要功能，讨论了次要功能，运行了这些通常是分叉主打功能的特定功能开发网。这是一个带星号的功能冻结，因为在那个时候我们已经决定不再向这个分叉添加任何新功能。我们将把所有功能放在一起运行，确保一切正常，确保不会出现任何故障。但是，如果某些事情开始拖慢进度，如果分叉被推迟，如果它太复杂，在这个阶段仍然有功能可能会被剔除。

因此，在经历了若干个开发网之后——可能是两个，也可能是 10 个——客户端在某个时候一致认为这已经稳定了。我们信任目前的进展。我们处于一个良好的状态。让我们开始考虑将其发布到以太坊主网上。他们发布客户端版本，然后有一个 30 天的期限，以太坊基金会安全团队会发布漏洞赏金。他们会承包安全审计。在这 30 天结束时，我们将分叉发布到测试网上。这些是你可能听说过的测试网——比如 Holesky。应用开发者可以在分叉上线之前在这里测试他们的东西。这些测试网通常每个至少运行 14 天，以确保一切正常。我们预计不会出现任何大问题，因为它之前已经经过了特定功能开发网和通用开发网的测试，但从历史上看，它确实曾导致其中一些测试网崩溃。因此，这可以说是发现并消除所有这些漏洞的最后机会。

然后，一旦无需许可的测试网稳定下来，就会选定主网日期。之后，会有一个 30 天的缓冲期。这个 30 天的缓冲期之所以存在，是因为二层网络（L2）和协议提出了这个要求，以便为分叉做好准备。所以这至少需要 30 天，然后分叉就会发生。

会议结构与协调 (15:01)

在这整个期间，会进行一些主要的系列会议。这些都是在 YouTube 上直播的公开会议。主要的是 ACDE 和 ACDC。E 代表执行层——也就是交易、智能合约部署、内存池管理等内容。ACDC 是共识层——也就是验证者管理、罚没等验证者事务。这些会议在每周四交替进行。所以每个星期四都有一个 ACD 会议，其中一个是 ACDE，下一个就是 ACDC，以此类推。

ACDE 和 ACDC 会议侧重于我们目前正在进行的分叉以及我们正在为未来规划的分叉。ACDT 会议则更加深入细节。这是客户端在讨论他们无法解决的漏洞，或者关于他们目前正在处理的分叉需要解决的实施细节。所以现在即将发生的下一个分叉是格拉姆斯特丹。因此，这些 ACDT 会议主要讨论 ePBS 和区块级访问列表，这些都是将要进入格拉姆斯特丹的内容。这些都是高度技术性的会议。

然后还有分组会议（breakout calls）。分组会议是社区成员、研究人员、开发者在说：“嘿，我有一个功能，我想在之后的第二个分叉中加入以太坊。”因此，他们会举办这些每周、每月或每两个月一次的会议，在会上他们会详细讨论实施细节，更改和迭代规范，并总体上解决人们提出的所有问题、所有已知的未知因素，以确保它处于最佳状态，能够被纳入之后的第二个分叉中。这些会议可以由协调人决定随时安排。

不断演进的流程 (15:29)

所以我想让大家深刻认识到的一点是，这个流程绝不是一成不变的。我刚才向你们描述的这个流程实施还不到一年。以太坊已经运行了 10 年。但它在不断变化，而它不断变化的原因是没有人说了算。这个流程在某种程度上不断演进，以找出最有效的运作方式。虽然我说是有效，但以太坊治理的名声却是非常停滞、很难通过提案、令人困惑——这是因为当你有 100 到 500 人在做决定时，老实说，这套机制居然还能运转，我已经印象非常深刻了。

因此，Tim 在 2025 年 4 月发表了一篇名为“重构所有核心开发者（Reconfiguring All Core Devs）”的帖子，这最终成为了目前运作方式的提案。原因在于，在此之前，我们对于以太坊应该关注什么有一种连贯的叙事。比如合并，这是一项巨大的工程。每个人都非常兴奋。大多数人都非常兴奋。矿工们则不然。然后在合并之后，有了提款功能。所以，我们不希望人们把他们的 ETH 锁定在合约中，也不希望出现那种认为他们永远无法从中取出 ETH 的恐慌（FUD）。因此，我们必须尽快发布该功能。然后是 Proto-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)。就是这些。