以太坊的未来:从 Beacon Chain 到 Beam Chain

探讨以太坊未来发展的可能性,围绕 Beam Chain 提案的技术细节和对以太坊共识层重大改进的分析。

引言

在 2024 年,围绕以太坊发生了许多重要事件。今年初,以太坊通过 Dencun 升级引入了 blobs。此更新显著降低了现有 rollup 的交易成本,为 rollup 生态系统的快速扩展奠定了基础。

Dencun 升级后 OP 链的费用减少

(Dencun 升级后 OP 链的费用减少 | 来源: Optimism X)

然而,随着生态系统内的 dapps 迁移到高度可扩展的 rollup 和替代的 Layer 1 (L1) 网络,以太坊本身的用户活动开始下降。此外,随着 rollup 停止向以太坊提交高额费用,社区开始对此产生担忧。

此外,2024 年也是专注于可扩展性的 L1 如 Solana 和 Sui 展现出显著实力的一年。这些网络产生的巨大 TPS(每秒交易数)使得 rollup 上的活动显得相对较小。

在这种背景下,出现了一些批评声音,比如“以太坊的 rollup 中心路线图存在缺陷”或“以太坊的发展速度太慢以至于无法成功。”以太坊真的走在正确的道路上吗?到 2025 年甚至 2030 年的时候,以太坊将会是什么样子?

本系列将根据两个主题深入探讨以太坊的路线图部分,分析其未来的技术细节。第一个主题是 Beam Chain

Beam Chain 提案是什么,为什么它很重要?

如果要选择今年以太坊社区内讨论最热烈的话题,可能就是以太坊研究员 Justin Drake 在 Devcon 上公布的 Beam Chain。这一公告引起了广泛的关注和讨论。让我们分析一下这个提案意味着什么。

Beam Chain 提案的核心思想是完全重设计以太坊的共识层。Justin Drake 提出了以下三个理由,说明当前的共识层 Beacon Chain 需要重设计:

  • 通过过去的经验更好地理解 MEV

  • SNARK 技术的快速进步(例如,zkVM 的开发速度惊人,超过 10 倍的提升)

  • 消除 Beacon Chain 中存在的“技术债务”

目前,以太坊的共识层路线图包括以下元素:
块生产 质押 加密
P0 抵制审查(FOCIL) 更智能的发行(例如,质押上限) 链式零知识证明化(例如,Poseidon + zkVM)
P1 隔离验证者(执行拍卖) 较小的验证者(1 ETH 轨道质押) 量子安全(例如,基于哈希的签名)
P2 更快的插槽(4 秒) 更快的最终性(3 插槽 FFG) 强随机性(例如,MinRoot VDF)

其中,四个标记为粗体的领域代表了超越简单修改 Beacon Chain 的根本性变化。例如,链式零知识证明化是指将共识层的状态处理转换为 ZK 技术,这需要从哈希函数到默克尔化/序列化状态的方法进行根本性改变。

此外,更快的插槽和更快的最终性是为在保持安全性的同时实现性能提升而提出的新设计——这一点在最初的设计中并未优先考虑。实施这些需要在共识层进行广泛的变更。

Beam Chain 提议通过一次硬分叉实现这些变更。总结如下:

  1. 实施以太坊的共识层路线图需要完全重设计共识层。

  2. 为此,路线图上的重大变更将被捆绑成一个名为 Beam Chain 的硬分叉。

  3. 它包括四个元素:更快的区块时间、更快的最终性、链式零知识证明化和量子抵抗。

接下来,让我们探讨每个方面的实施方式及其带来的技术影响。

Beam Chain 设计的技术细节

更快的插槽 & 更快的最终性

目前,以太坊的插槽时间为 12 秒,块连接到插槽后需要 2-3 个Epoch(大约 15 分钟)才能达到最终性。改善这些时间将对以太坊用户、应用程序以及基于以太坊构建的 rollup 产生积极影响。

更短的最终性(Orbit SSF)

这个在以太坊研究者中被称为 SSF(单插槽最终性) 的主题,旨在将以太坊块达到最终性的时间从大约 15 分钟缩短到 12 秒以内,为用户提供更快的确认。要理解单插槽最终性,我们必须理解以太坊当前的共识算法 Gasper。

Gasper 的一个关键设计原则是确保在设定时间后,某个插槽中提议的块达到一定的经济安全,同时最小化每个验证者的通信负载。为此,以太坊将所有验证者划分为分布在 32 个插槽上的委员会。每个插槽可以包含最多 64 个委员会,目标是每个委员会由 128 个验证者组成(尽管如果活动验证者的总数超过这一数字,此数量可以增加)。

每个委员会中的验证者独立验证块并对其投票,使用 BLS 签名。BLS 签名机制允许将多个签名聚合成一个,这意味着委员会内的指定节点收集这些签名,并将其编译成一个单一的紧凑数据包。通过广播这个聚合签名,下一块提议者可以以最小的数据确认块已经被妥善验证。 

(以太坊验证者之间的 BLS 签名聚合 | 来源: eth2book)

总之,以太坊的 Gasper 通过以下机制实现了可扩展性和经济安全:

  • 验证者在 6.4 分钟内分布在插槽的委员会中,消除了所有验证者之间直接通信的需求。

  • 聚合签名过程确保验证者对块的投票可以使用少量数据进行验证。

然而,由于 Gasper 是以Epoch为基础工作的,因此在插槽达到最终性之前,必须验证Epoch之间的“连通性”。在 Gasper 中,必须经过至少两个Epoch(64 个插槽)才能达到与以太坊完整经济安全等价的最终性。

 这导致了以下图示表示:

Gasper 的经济最终性

(Gasper 的经济最终性 | 来源: Orbit SSF)

这引入了各种挑战并降低了用户体验。例如:

  • 从 CEX(中心化交易所)提取资金到以太坊,或反向操作时,确认时间可能约为 10 分钟,这显得相对过长。

  • 以太坊的 rollups 和 dApps 面临 L1 块可能无法最终确认并可能失效的风险。如果不采取适当的对策,可能会导致问题。

例如,在 2024 年 3 月,Polygon zkEVM 由于对以太坊重组的处理不当,经历了超过两天的链停顿。

减少最终确认时间并非不可能,正如 Tendermint 等共识算法所示,这些算法已经应用于多个协议。然而,采用 Tendermint 机制的挑战在于节点之间频繁的 P2P 通信,这带来了可扩展性的限制。

在 Tendermint 中,如果节点数量为 N,其消息复杂性为 O(N^3)。这意味着随着节点数量的增加,节点之间的通信频率呈指数级增长,从而限制了可扩展性。因此,像以太坊这样有很多验证者的协议,不能直接按原样采用 Tendermint。

为了将 Tendermint 风格的共识应用到 Ethereum,需要做更多的工作来解决这些问题。

Orbit SSF 提案概述

Orbit SSF 的目标是修改 Gasper 的委员会机制,以减少插槽最终确认的时间,同时保持高经济安全性。

提案是将 32 个插槽的Epoch大小减少为一个插槽(约 12 秒)。然而,如前所述,这将增加验证者通信的资源使用,对以太坊的去中心化产生负面影响。

为此,Orbit SSF 提出了以下想法:

增加每个以太坊验证者的最大质押金额,可以用更少的验证者实现相同水平的经济安全。

Orbit SSF 提议引入一个单一的“超级委员会”,而不是每个插槽有多个委员会。质押金额较高的验证者将几乎总是按比例包含在委员会中,从而确保即使委员会较少,经济安全水平也维持不变。

下一个以太坊升级 Pectra 包含 EIP-7251,提议将验证者的最大质押金额(MaxEB)从 32 ETH 提高到 2048 ETH。这一提案对以太坊节点基础设施运营商具有吸引力,但也是 Orbit SSF 的前提条件。

然而,如果质押金额大的验证者几乎总是被包含在委员会中,小型独立验证者的奖励可能会减少,这可能会损害以太坊的去中心化。为了防止这种情况,Orbit SSF 调整奖励,以便 APR 随着质押金额线性增加,同时确保较大的验证者更频繁地被包含在委员会中。

Orbit SSF 中的委员会奖励和被包含的概率

(Orbit SSF 中的委员会奖励和被包含的概率 | 来源: Orbit SSF)

此外,Orbit SSF 转向“基于委员会的最终确认”。在 Gasper 中,委员会只能在经过两个或多个Epoch后对最终确认做出贡献,但 Orbit SSF 允许每个插槽分配的委员会实时参与最终确认。它旨在使委员会成为最终确认的更积极贡献者,更快地实现可扩展性。

(使用 Cap-and-slow-rotate 的 Orbit SSF 中的最终确认 | 来源: Orbit SSF)

这里的关键在于委员会成员的组成。Orbit SSF 提出了一个“慢旋转”机制,其中大额质押验证者在委员会中几乎是数学上固定的,而小型验证者则被轮换进出。这允许代表经济安全阈值的 F 的值设置得很高,同时保持验证者之间的通信开销最小,并确保最终确认时间保持低。

例如,设置 n = 3 和一个显著大的 F 将使以太坊在大约三个插槽内实现最终确认,从而实现 Justin Drake 的 3-slot FFG 的愿景。

然而,将 F 提高到以太坊整个验证者集的水平并不容易。这可能会降低对以太坊进行 51% 攻击的成本。因此,Orbit SSF 今后面临的主要挑战是确定如何在不牺牲太多去中心化的情况下,技术上提高 F 的水平,以确保以太坊的安全性保持强大。

较短的插槽时间(4 秒插槽)即使实现了 SSF(或 3-slot 最终确认),Ethereum 用户仍将面临最小交易确认时间为 12 秒。这给用户带来了两个主要缺点:

  1. 与其他 L1(如 Solana 和 Sui)相比,延迟较长

  2. 更高的 MEV 脆弱性(随着区块时间缩短,MEV 降低,使以太坊用户更容易遭受 MEV)

此外,12 秒的区块时间对 rollups 尤其不利,尤其是基础 rollups。例如,Taiko 通过将每个 L2 块发布到 L1 来实现基础 rollup。结果,Taiko 的区块时间可能增加到至少 12 秒,有时超过 24 秒。

为了解决这个问题,提出了两个解决方案:

a. 将以太坊的区块时间减少到 4 或 8 秒

b. 使用预确认

降低以太坊的区块时间

降低以太坊的区块时间是一个活跃的讨论主题。它已正式化为 EIP-7782,提议将插槽时间从 12 秒减少到 8 秒,从而将以太坊的可扩展性提高 33%。然而,8 秒的插槽时间可能对用户体验或基础 rollups 并不理想。实现更短的插槽时间似乎更可取。

也就是说,较短的区块时间可能导致验证者集的中心化增加。由于物理限制,地理上距离较远的验证者面临更长的通信时间,而 4 秒的插槽时间在某些情况下可能使通信变得不可行。

Ethereum 主网的区块传播时间统计数据提供了有关 4 秒区块时间可行性的见解。下图显示了区块传播时间的分布。

(消息到达时间的 CDF | 来源: Gossipsub 消息传播延迟)

大约 98% 的区块在 4 秒内传播,而约 2% 的区块传播时间更长。根据这些数据,4 秒区块时间可能是可行的。然而,区块时间不仅仅包括通信——还包括执行和投票。考虑到这些因素,4 秒区块时间中只有大约 2 秒可用于通信。在这些情况下,实现 4 秒的区块时间是具有挑战性的。

为了解决这个问题,必须减少传输数据的大小,最大化客户端 P2P 组件的性能,或使物理通信更加高效。

使用预确认

在此期间,预确认可以改善用户体验。预确认允许区块生成实体向用户承诺:“你的交易将被包含在下一个区块中”,比插槽时间更快地向用户交付结果。

预确认的优势在于 L1 验证者可以在不需要分叉或客户端修改的情况下使用它。例如,Commit-Boost 是一种软件,使以太坊验证者能够安全地产生和传播预确认。

Commit-Boost 作为 MEV-Boost 的可选侧车,允许验证者安全地生成和传播“承诺”。根据使用案例,这些承诺可以采取不同形式:

承诺 使用案例
“你的交易不会被审查,将被包含在下一个区块中。” 包含列表
“该 rollup 的批量提交交易将被包含在下一个 L1 区块中。” Blob 预确认
“你的交易将在下一个区块中,执行结果是 X。” 预确认

使用第三种类型的预确认架构,即使在较长的区块时间下,用户感知的延迟也可以显著减少。当验证者收到用户的交易时,他们可以执行交易并将结果返回给用户。由于这个结果是基于验证者的承诺而不是区块创建,用户可以在毫秒内收到它。

然而,Commit-Boost 的有效性取决于验证者的采用。如果只有少数验证者使用它,对用户体验的影响将微不足道。不过,Commit-Boost 已获得以太坊社区的强力支持,并有潜力成为像 MEV-Boost 一样广泛使用的中间件。它得到了知名验证者运营商如 Rocket Pool、Renzo、SSV、Luganodes、Nethermind、Puffer、A41 和 Figment 的背书。此外,它还获得了 EF、Lido 和 Eigenlayer 的补助,并得到区块构建者 Titan 的强力支持。

尽管如此,如前所述,预确认更可能被用作像 MEV-Boost 一样的链外侧车,而不是直接集成到协议中。

Beam Chain 在更快插槽中的角色

正如 Justin Drake 在演示中讨论的,Beam Chain 的目标是减少区块时间。因此,研究和实现可能会集中在将插槽时间降低到 4 秒,而不牺牲去中心化。这可能通过以太坊的完全 snarkification 来解决,后文将对此进行解释。

链的 snarkification 和量子抗性

Justin 在他的演示中表示,Beam Chain 的目标是使用 ZK 技术对共识客户端进行 snarkification。这是什么意思,如何实现它,为什么这是必要的?

链的 snarkification

目前,以太坊信标链通过让验证者“重新执行”每个区块来实现共识,以验证结果状态根是否正确。这个重新执行过程引入了低效,并成为降低验证者硬件要求的障碍。

Beam Chain 旨在用 ZK 技术替代这种重新执行过程,通过“验证”来显著降低验证者的硬件要求,使任何人都可以从任何地方运行以太坊节点。为此,Beam Chain 和以太坊将利用 ZK SNARKs。

以太坊协议中的 ZK

ZK SNARKs 具有以下两个特性:

  1. 它们允许在不需要重新执行计算的情况下验证某个计算已被执行

  2. 证明大小相比于原始数据是紧凑的

这个想法是将 ZK 应用于以太坊中用于共识的计算和数据,生成遵循指令逻辑的证明。这意味着验证者可以通过验证 ZK 证明来实现共识,而不是重新执行整个区块并存储更新状态。验证 ZK 证明在数据大小和可扩展性方面远比重新执行高效。

因此,以太坊验证者的硬件要求可以大幅降低。例如,Vitalik 在《The Verge》一篇文章中表示,目标是使验证者即使在资源受限的环境(例如智能手表)中也能运行。

需要做什么?

第一步是对状态转换函数进行 snarkification。状态转换函数通常具有以下形式:

f(S,B)=S'

这里:

  • S:区块链的预状态

  • B:给定的区块

  • S’:执行该区块后的区块链后状态

  • f:状态转换函数

所有区块链都基于确定性状态转换函数,以太坊也不例外。以太坊在其共识层和执行层有不同的状态转换函数。对这两个函数进行 snarkification 将使使用 ZK 验证整个以太坊系统成为可能,从而使完全轻量级的验证者得以实现。

在 Beam Chain 中,目标是对共识层的状态转换函数进行 snarkification。目前,在以太坊共识层中的状态转换函数在每个插槽中执行,并执行以下操作:

  • 在接收到区块后更新插槽和区块头信息

  • 验证提出区块的验证者的签名

  • 验证区块内的交易

  • 每当一个时代过渡时,处理提款、削减、区块最终确认和其他信息

每当验证者从另一位验证者那里收到一个区块时,都会执行该功能。如果这个功能被 snarkified,验证者就不再需要直接执行状态转换函数。相反,他们可以验证一个证明,显示该函数已被正确执行。

在这种情况下,谁生成 ZK 证明?通常,人们可能会假设提出该区块的者也负责生成 ZK 证明。然而,重要的是要注意,并非所有验证者都能生成 ZK 证明。

Beam Chain 旨在实现的性能是能够在标准笔记本电脑上在 3 秒内生成 ZK 证明。但是,即使达到这一目标,在智能手表或智能手机等设备上运行的验证者可能也没有足够的资源来生成 ZK 证明。

在这里,网络可以依靠利他主义。每个区块只需一个关于共识层状态转换的 ZK 证明,并且不一定由区块提出者生成。换句话说,只要网络中的至少一个实体为每个区块生成一个 ZK 证明,就可以确保 Beam Chain 的区块正确生成。

未来:完全 snarkification 的以太坊

这一改变本身可能不会显著改善验证者的性能。共识层的状态转换函数涉及的操作相对轻便,与执行层的状态转换函数相比。然而,主要瓶颈不在于执行状态转换函数所需的资源,而在于网络带宽。当它们交换的数据(区块)的大小增加时,验证者会很难在分配的时间内达成共识。这是以太坊在过去三年中保持 30M gas 限制的一个原因。

如果这个变化与执行层的 snarkification 一起实现,验证者只需交换比整个区块小得多的数据。这是因为 SNARK 证明比原始数据小得多。完全 snarkified 的以太坊验证者交换的数据更少,从而减少了相比于当前系统的网络要求。

总结一下,以下是以太坊全 SNARK 化对验证者的优势。

  1. 验证者只需验证证明,而无需重新执行计算,从而降低计算需求

  2. 验证者交换证明数据而不是完整区块数据,减少网络带宽需求

因此,以太坊的生态系统可能会发生巨大变化。例如:

  • 诸如“以太坊节点应用程序”之类的东西将允许验证者在移动设备上运行。

  • 任何满足最低质押要求的人都可以运行一个以太坊节点,显著降低成为验证者的门槛。

这将使验证者的参与变得更加可及和去中心化。

量子抗性签名

仅通过对状态转移函数进行 SNARK 化是否足够将 Beam Chain 作为共识层?

在后量子世界中,以太坊将面临什么问题?

Beam Chain 还计划 SNARK 化另一个领域:签名生成。以太坊的共识层目前使用验证者签名作为证明数据来确认区块并在发生分叉时确定正确链条。

以太坊目前为此目的使用 BLS 签名,如前所述,其具有聚合特性,能够将多个签名合并为一个。这种聚合显著提高了以太坊共识过程的效率。然而,这种签名机制存在一个根本问题:它容易受到量子计算机的攻击。

以太坊的 Beacon 链中使用的 BLS 签名基于椭圆曲线。基于椭圆曲线的签名机制的安全性依赖于离散对数问题(DLP),量子计算机的卓越计算能力可能会破坏这一点。这使得基于椭圆曲线的签名本质上对量子计算机脆弱。

量子计算正在迅速发展,谷歌最近在诸如 Willow 这样的量子计算芯片方面的进展证明了这一点。谷歌声称,Willow 能够在 5 分钟内完成超级计算机需花费 10^25 年才能完成的计算。虽然这尚未从根本上威胁到椭圆曲线的安全性,但如果这种速度持续增长,区块链系统将在几年内面临风险。

(过渡到后量子加密标准 | 来源: NIST IR 8547)

美国国家标准与技术研究院(NIST)已经开始努力标准化量子抗性签名算法,以应对由于量子计算机而预期的现有系统崩溃。

以太坊也对此问题非常重视。在 Beam Chain 中,目标是实现量子抗性签名算法。

有几种类型的量子抗性签名,但 Justin 的 Beam Chain 介绍中专门提到了基于哈希的签名算法。与椭圆曲线不同,基于哈希的签名不依赖于数学机制,因此量子计算机更难以攻破。因此,基于哈希的签名被视为量子抗性,Beam Chain 旨在采用这种签名。

挑战与 ZK 的作用

主要挑战在于,基于哈希的签名缺乏 BLS 签名中存在的聚合特性。以太坊在共识中依赖签名聚合来提高效率。没有聚合,以太坊将无法容纳大量验证者集。

ZK 可以用来解决这个问题。它涉及利用证明聚合,这是一种将多个 ZK 证明组合成单个证明的技术。机制如下:

(证明聚合的示意图 | 来源: Figment Capital)

  1. 验证者使用量子抗性算法签署一个区块。

  2. 签名被发送到聚合器或聚合委员会。

  3. 聚合器生成一个 ZK 证明,验证签名的正确性。

  4. 随着新签名的接收,聚合器使用证明聚合技术将新证明与现有证明结合。

这种方法使以太坊能够实现与 BLS 签名聚合相同的效率,同时在共识层获得量子抗性。

ZK 在 Beam Chain 中的角色

总结一下,Beam Chain 与 ZK 将带来以下优势:

  1. 使验证者能够执行证明验证而不是重新执行共识层的状态转移函数,从而有助于减轻验证者的要求。

  2. 作为量子抗性签名的聚合算法的基础,提高共识层的效率。

zkVM 作为 Beam Chain 中 ZK 的基础

Beam Chain 中 ZK 的基础证明系统将是 zkVM。基于 Risc-V 的 zkVM 允许任何语言的程序进行证明,提供更大的灵活性。

(Beam 状态转移将被编译为 Risc-V 并在 zkVM 中证明 | 来源: Justin Drake 的 Beam Chain 公告)

这与以太坊现有客户端生态系统完美契合,该生态系统用多种语言开发,保留了以太坊的多样性和容错性。在未来的 Beam Chain 中,各种客户端将在多种编程语言中编写状态转移函数,将其编译为 Risc-V,并允许在任何基于 Risc-V 的 zkVM 中进行证明。因此,zkVM 是 Beam Chain 的自然选择。

结论

如果 Beam Chain 成功实现,以太坊将可能具有以下特性:

  1. 用户将在 4 秒内体验到交易确认,最终确认在 12 秒内完成。

  2. 验证者将通过 ZK 证明在共识层验证状态转移。如果执行层也被 SNARK 化,验证者将只需最少量数据即可参与共识。

  3. 验证者签名将是量子抗的

  4. 防止量子计算机破坏以太坊的共识。

目前,Beam Chain 尚未被正式认可为以太坊的路线图的一部分。实现它将需要进行广泛的研究、开发和长时间的测试。然而,如果以太坊继续进行 Beam Chain 分叉,所带来的用户体验的改善可能是变革性的。

这就是我们通过 Beam Chain 对以太坊未来五年可能演变的探索的总结。在下一篇文章中,我们将从用户体验和审查抵抗的两个方面审视 2025 年的以太坊。

附录:Beam Chain 常见问题解答

(Q):Justin Drake 的提案是在私下讨论的。这难道与以太坊的核心价值“开放”相冲突吗?

(A):不,并没有。Beam Chain 提案只是建议将以太坊现有路线图中的某些部分一次性实施。是否会落实还需要社区讨论。上述讨论的所有主题都有相关的 EIP 或在 Ethresear.ch 上的帖子。这或多或少表明,Beam Chain 并不是提出一个新的、以前未披露的以太坊方向的提案。此外,有关以太坊路线图的讨论是在每两周举行的核心开发者会议上公开进行的,任何人都可以参加。如果有人对路线图有不同意见或有新想法,他们可以在这些会议上表达意见或者以 EIP 或在 Ethresear.ch 上提交新提案。

总之,Justin 的 Beam Chain 提案并不是关于改变路线图,而是将路线图的部分内容归类为一个单一的名称或标签。

(Q):实施 Beam Chain 的 5 年时间是不是太长了?

(A):五年可能感觉很长,但需要考虑两个因素:

  1. 以太坊是建立在多客户端架构上的。
  2. 以太坊拥有任何区块链上最多的验证者。

(共识客户端多样性 | 来源: 以太坊客户端多样性 )

以太坊的共识机制遵循基于 BFT 的协议,如果超过三分之一的验证者与其他人行为不同,则无法确认区块。如果以太坊仅由一两个客户端构建,则这些客户端中的任何 bug 都可能会干扰区块生产。因此,以太坊一直旨在实现多客户端架构,采用多种编程语言进行开发。这种多样性在以太坊当前的客户端生态系统中显而易见。

如图所示,以太坊的共识层目前至少运行着四个客户端。要用 Beam Chain 替换 Beacon Chain,所有四个客户端团队必须协同开发。考虑到这一点以及以太坊的大量验证者,Beam Chain 的开发过程必须优先考虑稳定性,不能加速到几个月或 1-2 年的时间框架。

我是 AI 翻译官,为大家转译优秀英文文章,如有翻译不通的地方,在这里修改,还请包涵~

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
2077 Research
2077 Research
https://research.2077.xyz