以太坊新提案Beam Chain：未来共识层的变革

编者按：今天下午，在曼谷的 Devcon 活动现场，以太坊的核心开发者 Justin Drake 带来了以太坊历史上“最雄心勃勃”的共识层改革提案——Beam Chain。这项新提案采用了一系列 ZK 技术，旨在取代“过时”的以太坊 Beacon Chain。Justin 表示，新的共识层的开发可能会持续到 2030 年。不过，市场对这一消息似乎反应平淡，发布会期间以太坊价格急剧下滑，大家不禁开始怀疑，基金会是不是又找到了一个卖币的新理由？

以下是演讲的全部内容：

今年我花了很多时间在一个叫做“Beam Chain”的项目上。Beam Chain 是一个全新的共识层设计方案，结合了我们研究路线图上最新的前沿思想，旨在安全、快速地将现有的 Beacon Chain 过渡到这个新设计，向以太坊的理想状态更进一步。

图源：Uncommons 大松

在详细分享之前，有两个免责声明：第一，这只是一个提案，只有在大家达成共识后才会推进。第二，不会发行新的代币，也不会有新的网络，我们将继续使用相同的 ticker，Vitalik 对此非常明确。

接下来的时间里，我想尝试将一个看似疯狂的想法，变成一个合理的提案——彻底重构共识层。

关于 Beam Chain 的大框架愿景，首先，我想强调的是它专注于共识层，而不涉及数据层中的 blobs 和执行层中的 EVM。因为 blobs 和 EVM 直接被应用程序使用，保持前向兼容性是必要的，因此在这两层上变动的机会相对有限。而共识层不直接被应用程序消费，给我们在这个方面提供了更多的灵活性。

为何要推出 Beam Chain？

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

答案主要是因为 Beacon Chain 已经显得有些“过时”。

五年前的“规格”已经确定，而这五年来发生了许多变化，特别是我们对新视角的理解比五年前更为深入。五年前我们在 PoW 问题上比较幼稚，但自那时起，市场迅速发展壮大，我们也更清晰地认识到可以帮助减轻 MEV 负外部性的机制。 从技术角度看，SNARKs 是一项超级强大的技术。过去五年，SNARKs 取得了惊人的进步，速度提升了好几个数量级。与此同时，zkVMs 的出现让任何程序员都能轻松使用这项技术，无需深入理解密码学或 SNARKs 的复杂性。💪

随着时间的推移，我们逐渐认识到在 Beacon Chain 上的那些错误和累积的技术债务，这些债务顽固不化，还会随着时间推移不断增加。🌀现在，或许我们有机会清理这些债务，建议把共识层的尖端技术整合进 Beam Chain。

Beam Chain 有哪些变化？

接下来，我会具体介绍共识层路线图中包含的内容。总共有九个项目，分为三个类别：区块生产、质押、密码学。

区块生产方面，涉及到 MEV。当前区块构建者和中继者层面存在大量中心化问题。我们希望引入「包含列表」，以显著提升抗审查能力。一旦包含列表抗审查性增强，我们就能明确分离验证者与区块生产流程，这被称为 提议者-构建者分离（PBS），其中还包括一些执行函数的概念。

在区块生产类别中，最后一个项目是缩短时隙。我们希望在保持当前 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」。这个Fork提供了通过一次性升级实现共识层飞跃的绝佳机会。可以把Beam Fork看作是一个批处理机会，多个升级可以合并到一个分叉中，既有技术优势，也有治理好处。

这种批处理机会可以称作「固化加速主义」⚡️。听起来有点矛盾，但基本思路是希望以太坊尽快进入维护模式。我们知道，有一些重要项目需要对以太坊进行根本性的重构，而如果拖延这些变革，以太坊稳定状态的到来就会越来越遥远。

Beam Chain 使用了什么技术？🔧

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

在ZK时代，SNARKs技术将大规模使用。我们已经在Beam Chain的整个共识层中应用了SNARKs，这时zkVMs（零知识虚拟机）变得极其重要。

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

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

• RISC-V的崛起 🚀
  近年来，RISC-V 已然成为 zkVMs 的行业标杆。作为一种指令集，它可以将高级代码转化为 RISC-V 指令。目前，已有七家公司推出了 RISC-V zkVMs，像 RISC Zero 和 SP1 这样的名字你肯定听过。

• 技术的广泛适用性 🔍
  值得一提的是，这项技术在执行层的应用与 Beam Chain 的故事有所不同，但它的潜力让人兴奋。它意味着我们能够显著提升 gas 上限，进一步增强以太坊作为 L1 的垂直扩展能力，尽管这又是另一个话题了。

• SNARKs与可聚合签名 ✍️
  在 Beam Chain 中，SNARKs 还有一个重要用途——可聚合签名。我们的目标是实现抗量子的可聚合签名，提议使用哈希函数。哈希函数因其抗量子性，成为构建密码学的基石。

• 基于哈希的方案 🔗
  我们将采用基于哈希的签名，由验证者与证明者共同生成。同时，还将引入基于哈希的 SNARKs，能够将成千上万的签名压缩为一个证明。结合这两者，我们可以构建出一个抗量子、可聚合的方案，适用于以太坊。值得注意的是，这个聚合方案具备无限递归聚合的能力，可以将聚合结果不断再聚合，这在 BLS 签名中是无法实现的，灵活性更高。

• 性能的飞跃 ⚡
  我今天分享这个提案，是因为最近几个月 SNARK 哈希函数性能大幅提升。对于知情人士来说，我们现在已经能够在普通笔记本上进行验证。

• 基准测试的惊人结果 💻
  这项基准测试是在 MacBook Pro 的 CPU 上完成的，验证速度达到了每秒 200 万次哈希，简直是令人瞠目结舌。这意味着基于哈希的提案在 Beam Chain 上有着巨大的性能潜力。

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

• 网络库和框架的优势 🛠️
  例如，网络库 libp2p 、序列化库 Simple Serialize 等都可以直接利用。Pyspec 框架也是我们编写正式规范和单元测试的重要工具。

• Protocol Guild的再利用 🔁
  此外，Protocol Guild 等基础设施也能被复用，这些在 Beacon Chain 初期并不具备，但现在可以免费使用。

• 共识客户端的现状 🤝
  如今，多个团队支持 Beacon Chain 的开发，而当初我们并没有共识客户端团队。现在已有五个共识客户端团队可直接投入使用，无需重新组建，真是大大方便了！ 此外，咱们还有专门的团队来负责合并的运维工作，比如 Panda Ops 团队提供的 DevOps 支持，还有安全和激励团队等应用研究小组，这些都是可以直接利用的资源哦。

接下来，我想聊聊未来的展望。预计从 2025 年开始，我们会进入一套规范化流程。这将由一小群研究人员推动，可能会花费整整一年。到了 2026 年，开发流程会正式启动，客户端团队开始编写生产级代码，随后在 2027 年进行彻底的测试，确保安全性和生产部署的稳定性。

图源：Uncommons 大松

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

让我兴奋的是，如果大家对 Beam Chain 的新方向达成共识，这将是一个绝佳的机会，为共识客户端注入新鲜血液。

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

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