编者按：今日下午，在曼谷 Devcon 活动主会场，以太坊核心开发者 Justin Drake 公布了以太坊过去数年来「**野心」的共识层变提案——Beam Chain，引入了一系列 ZK 技术以替代「老旧」的以太坊 Beacon Cahin。会上 Justin 表示，新的共识层开发或许将持续到 2030 年。然而，市场似乎并不买账，在发布会进行的同时，以太坊价格急速下跌。大家似乎都在想：基金会是不是又多了一个卖币的借口？

以下为演讲全文：

今年我投入大量时间的项目叫做「Beam Chain」。Beam Chain 是一个共识层的重新设计方案，结合了研究路线图中**、**进的想法，目标是以安全且快速的方式从当前的 Beacon Chain 过渡到这一设计，而这将更接近以太坊的**形态。

在我分享更多内容之前，有两个免责声明：**，这是一个提案，仅是我的提议，只有在大家达成共识的情况下才会推进。第二，没有新的**，没有新的网络，我们会继续使用相同的 ticker，Vitalik 对此非常明确。

接下来的演讲中，我将尝试将一个看似疯狂的想法解释为一个合理的提案——即**重新设计共识层。

首先，我想讲一讲 Beam Chain 的大框架愿景。Beam Chain 的范围专注于共识层，不包括数据层中的 blobs 和执行层中的 EVM，因为 blobs 和 EVM 被应用程序直接使用，需要保持前向兼容性，因此更改这两层的机会相对有限。而共识层不直接被应用程序消费，这使得我们可以在这方面有更大的调整空间。

为什么要做 Beam Chain？

那么，为什么我要现在提出这个共识层的大规模重构呢？

原因主要在于 Beacon Chain 已经有些「老旧」了。

五年前「规格」已经冻结，而在这五年里发生了很多变化，特别是我们对新视角的理解比五年前更加深入。五年前我们在 PoW 问题上相对幼稚，但自那时起，市场快速发展壮大，我们也更好地了解了可以帮助减轻 MEV 负外部性的机制。

其次，从工程角度来看，我们现在拥有一种非常强大的技术，叫做 SNARKs。在过去的五年里，SNARKs 技术取得了大量突破，速度提升了数个量级。同时，我们也看到了 zkVMs 的诞生，zkVMs 是一项了不起的技术，它允许全球**程序员在不需要精通密码学或深入理解 SNARKs 的情况下，利用这一强大技术。

此外，随着时间推移，我们现在也清楚地知道在 Beacon Chain 上所犯的错误，以及累积起来的技术债务。这些债务非常顽固，并且会随时间增加。

现在，或许我们有机会**这些技术债务。因此，我建议将共识层路线图中**进的技术整合到 Beam Chain 中。

Beam Chain 包括哪些改变？

接下来，我会花点时间介绍共识层路线图中具体包含的内容。基本上有九个不同的项目，我将它们分为三个类别：区块生产、质押和密码学。

首先是区块生产，这涉及到 MEV。目前在区块构建者和中继者层面存在大量**化问题。我们希望引入「包含列表」（inclusion list），以显著提升抗审查能力。一旦包含列表具备抗审查性，我们就能够将验证者与区块生产流程明确分离。这被称为提议者-构建者分离（PBS），并包括一些执行函数（execution functions）等想法。

区块生产类别中的**一个项目是更快的时隙，也许我们可以在保持当前 12 秒时隙不变的情况下进一步缩短时隙，并确保即使是通过家庭网络连接，即便在网络延迟较高的澳大利亚，用户仍然可以作为验证者参与其中，享受**的权益。

第二类是质押。研究人员基本上已经达成共识，认为当前的发行曲线存在缺陷，有机会通过调整来改善以太坊的健康状况和长期发展。质押类别中的第二个项目是将成为验证者所需的 ETH 从当前的 32 ETH 大幅**至仅需 1 ETH。

最近出现了一些关于「Orbit」的想法。此外，还有一个被讨论多年的想法是单一时隙**性，这可以显著加速以太坊的**性过程。

**一类是密码学，包含两个重要项目。**个项目是实时对整个共识层进行 SNARK 验证，并使用合理的硬件支持。

**，我们能否让保障以太坊的密码学在未来几十年乃至几百年内都可持续发展，并实现抗量子攻击呢？

在这里我使用不同的颜色来区分路线图中的项目是否可以轻松或逐步完成，或者是否很难实现。左上角的四个绿色项目是我认为可以并且应该在 Beacon Chain 上逐步实现的项目，而当这些较小的项目完成后，剩下的就是一些重大项目（红色部分），我认为这些项目**通过一个更**的方式来处理。

以「更改通知」为例，为了在合理的硬件上实现对 Beacon Chain 的实时证明，我们需要更改哈希函数、签名方式，以及状态序列化和**化的方式。这将是对 Beacon Chain 的一个重大改变，因此也许我们有机会在做出这些调整时，同时进行其他改进。

类似的情况也适用于底部两个红色框的「更快的时隙」和「更快的**性」。五年前设计 Beacon Chain 时，我们的**是安全性，而不是性能。然而现在我们发现有一些设计既能保持我们所需的安全性，同时也能改善性能，抓住一些容易实现的性能改进。

这张 PPT 展示了从我刚才提到的共识层路线图到 Vitalik 更广泛路线图之间的映射关系。我们的一些项目属于 Merge 阶段，有些属于 Scourge 阶段，还有一部分属于 Verge 和 Scourge 阶段。

这张 PPT 的核心目的是传达 Beam Chain 并不是改变整个路线图，而是识别其中的一个特定子集，加速推进它，并赋予它一个独特的意义。

图源：Aaros

共识层路线图中的「更快的时隙」是新的，因为关于更快时隙的讨论是在 2024 年开始的，而 Vitalik 的路线图**一次更新是在 2023 年。

除了能够加速这些重要项目外，我们还可以清理一些之前提到的技术债务。如果我们实现单一来源的**性，就不再需要 epochs，可以直接使用 slots。此外，当前的押金合约有点复杂，是合并时**下来的产物；而像同步委员会这样的基础设施，在实现对 Beacon Chain 的实时 SNARK 化后将不再需要。这是一个能够一次性清理的机会。

如果你对 Beacon Chain 设计中的某些问题感兴趣，去年我做了一个完整的演讲，讨论了我们在设计 Beacon Chain 时犯的 20 多个错误。

这张图展示了我们自创世以来对共识层的升级全貌。在左下角可以看到，创世发生在 2020 年，从那以后我们每年都进行了新的分叉，每次分**们都会对共识层进行逐步的改进。

2021 年我们增加了同步委员会，2022 年进行了合并，2023 年增加了提款功能和原生动态分片，2025 年我们将增加**有效余额。

预计未来几年我们会继续进行这些逐步的分叉，抓住路线图左上角标记为绿色的低难度项目。

逐渐我们会遇到瓶颈，一旦所有低难度项目都完成，剩下的都是难以逐步实现的重大项目，这时就需要进行「Beam Fork」。Beam Fork 提供了一个通过一次性升级实现共识层**的机会。可以将 Beam Fork 视为一个批处理机会，多个升级合并到一个分叉中，既有技术上的优势，也有治理上的好处。

可以把这种批处理的机会称为「固化加速主义」。这听起来像个矛盾，但基本的想法是希望以太坊尽快进入维护模式，目前存在这样的紧张关系。我们知道有一些重要的项目需要对以太坊进行根本性的重构，而拖延这些变革越久，以太坊进入稳定状态的时间就越远。

Beam Chain 使用了哪些技术？

接下来是第二部分，我会介绍一些将在 Beam Chain 中使用的技术。可以把这看作是以太坊共识机制的不同时代：最初是工作量证明（POW）时代，然后进入权益证明（POS）时代，现在我们可能进入一个零知识证明（ZK）时代。

在 ZK 时代，我们将大量使用 SNARKs 技术。一个我们已经在使用 SNARKs 的地方就是为整个 Beam Chain——整个共识层——提供零知识验证，这时 zkVMs（零知识虚拟机）变得非常有用。

想象一下，我们可以在不同的**编程语言中实现 Beam Chain，例如用 Rust 和 Go，然后将这些**语言编译成 zkVMs 可以理解的字节码，从而实现 SNARK 验证，而无需担心底层细节。

需要强调的一点是，**需要进行 SNARK 验证的部分是状态转换函数（State Transition Function），这是成为共识客户端的核心。本质上，状态转换函数是客户端构建中很小的一部分，周边的基础设施（如网络、同步、缓存优化或区块选择规则）都不需要进行 SNARK 验证。

过去几年，RISC-V 已经成为这些 zkVMs 的行业标准。RISC-V 是一种指令集，基本上可以将**代码编译为 RISC-V 指令。现在已经有七家公司提供了 RISC-V zkVMs，比如你可能听说过的 RISC Zero 和 SP1 等。

需要注意的是，这项强大的技术也可以用于执行层，这与 Beam Chain 的故事有所不同，但它非常令人兴奋，因为它意味着我们可以大幅提高 gas 上限，增强以太坊作为 L1 的垂直扩展性，不过这是另一个话题。

在 Beam Chain 中另一个大量使用 SNARKs 的地方是可聚合签名。我们希望拥有抗量子的可聚合签名，这里的提案是使用哈希函数。哈希函数具备抗量子安全性，可以作为构建密码学的基本模块。

我们将使用基于哈希的签名，由验证者和证明者生成，并且还将引入基于哈希的 SNARKs，可以将成千上万的签名压缩为一个证明。通过这两者结合，我们可以构建一个基于哈希的抗量子、可聚合的方案，可用于以太坊。一个有趣的细节是，这个聚合方案具有**递归聚合的能力，也就是说可以将聚合的结果继续再聚合，这是目前 BLS 签名无法实现的，灵活性更强。

我今天提出这个提案的原因是，最近几个月里 SNARK 哈希函数性能取得了巨大进步。对于了解情况的人来说，我们现在已经能在笔记本上进行验证。

这项基准测试是在一台 MacBook Pro 的 CPU 上完成的，现在可以每秒验证 200 万次哈希，这个速度非常惊人，这意味着这个基于哈希的提案在 Beam Chain 上有着极大的性能潜力。

除了我们将使用的 zkVM 和 SNARKs，我还想强调，我们在很大程度上将复用现有的基础设施。

例如，网络库 lib**、序列化库 Simple Serialize 等都可以直接复用。Pyspec 框架也是如此，这是我们用来编写正式规范和单元测试的 Python 规范框架。

此外，还可以复用 Protocol Guild 等基础设施，这些在 Beacon Chain 初期并不存在，但现在可以免费复用。

同样地，现在也有了多个团队支持 Beacon Chain 的开发，当时我们并没有共识客户端的团队。而现在的五个共识客户端团队可以直接投入使用，无需重新组建。

此外，我们还有专门的团队负责合并的运维，例如 Panda Ops 团队提供的 DevOps 支持、安全团队和激励团队等应用研究小组，这些都是可以直接利用的资源。

**一部分，我想谈谈下一步和未来的展望。一个可能的结果是，从 2025 年开始，我们将进入规范化流程。这将由一小群研究人员进行，可能需要整个一年时间。2026 年，开发流程将启动，客户端团队开始编写生产级代码，接着在 2027 年进入非常**的测试流程，以确保安全性和生产部署的稳定性。

作为研究人员，我接下来的任务是开始编写可执行规范，我称之为「可执行路线图」。我们的想法是将路线图中的「像素」、各类研究和学术论文中的数十万字内容，以及研究人员头脑中的各种想法结合在一起，提取其核心精华，形成一个可执行的规范文件。**，这将是一个非常精简的文档，大约是 1000 行 Python 代码。

对我来说，令人振奋的一点是，如果大家对 Beam Chain 的新方向达成大致共识，这将是一个**的机会，为共识客户端注入新鲜血液。

目前，我们的共识客户端团队遍布北美、欧洲和大洋洲。今天，我很高兴地宣布，已经有新的团队愿意开发 Beam 客户端。其中一个团队位于印度，叫做 Zine，他们正在使用 Zig 语言编写一个 Beam 客户端。还有一个位于南美洲的 Lambda Class 团队，也表达了开发 Beam 客户端的兴趣。

如果你也有兴趣参与，我们需要大量**的人才，包括规范和网络专家、协调员、密码学专家和客户端开发者。请通过这个邮箱联系我们，加入我们，共同开启这场新的冒险。非常感谢！