The Verge：使以太坊可验证和可持续

可验证性之路

Web3 的核心优势是可验证性 – 用户可以验证系统的实际操作方式。这个特性解释了为什么许多来自加密行业内外的人会将 Web3 描绘为迈向更透明和可验证的互联网的一步。

与 Facebook 或 Instagram 等 Web2 平台不同，这些平台的算法和规则即便在文档中也保持模糊，加密协议则设计为完全可审计。即使它们被共享，你仍然无法验证平台是否按照规定运行。这与加密的对立面正好相反，在加密中，每个协议都设计得尽可能可审计——或者至少是被期望如此。

今天，我们将探讨“边缘”（The Verge），这是 Vitalik 最近发布的 关于以太坊未来的六部分系列 中的一个部分，以分析以太坊在未来实现可验证性、可持续性和可扩展性方面所采取的步骤。在“边缘”这一标题下，我们将讨论如何使区块链架构更具可验证性，这些变化对协议层带来的创新，以及它们如何为用户提供更安全的生态系统。让我们开始吧！

“可验证性”是什么意思？

Web2 应用程序诸如“黑盒” – 用户只能看到输入和由此产生的输出，无法了解应用程序的实际工作方式。相反，加密货币协议通常会将其源代码公开，或至少有计划如此。这种透明性具有两个目的: 它允许用户选择直接与协议的代码进行交互，同时帮助他们确切了解系统如何运作以及哪些规则对其进行治理。

“去中心化你能去中心化的部分，其余部分则要可验证。”

可验证性确保系统负责，并且在许多情况下，保证协议按照预期运行。这一原则突出了最小化中心化的重要性，因为中心化往往导致模糊、不负责任的结构，用户无法验证操作。相反，我们应当尽可能地去中心化，并在上游不可行的情况下使剩下的元素可验证和可负责。

以太坊社区似乎与这一观点一致，因为 路线图 包含一个阶段（称为“边缘”），目标是让以太坊更具可验证性。然而，在深入探讨边缘之前，我们需要了解哪些区块链的部分应当被验证，以及从用户的角度来看哪些部分至关重要。

区块链本质上充当全球时钟。在一个由大约 10,000 台计算机组成的分布式网络中，从发起节点到达所有其他节点的一个交易传播可能需要相当长的时间。因此，网络中的各个节点无法确定交易的确切顺序——某一个交易是早于还是晚于另一个，因为它们只具有自己的主观视角。

由于交易的顺序非常重要，区块链网络使用称为“共识算法”的专业方法来确保节点保持同步，并以相同的顺序处理交易序列。尽管节点无法全局确定交易顺序，但共识机制使所有节点能够就同一序列达成一致，从而使整个网络作为一个单一的、连贯的计算机运行。

在共识层之外，每个区块链中还存在执行层。执行层由用户想要执行的交易构成。

一旦通过共识成功对交易进行排序，必须将每个交易应用于现行状态的执行层。如果你在想：“状态是什么？”你可能见过将区块链与数据库比较——或者更具体地说，与银行的数据库相比，因为区块链像银行一样维护每个人的余额记录。

如果你在称为“S” 的状态中有 $100 并想要发送 $10给其他人，你在下一个状态“S+1”中的余额将为 $90。将交易应用于状态来移动的过程被称为 STF（状态转移函数）。

在比特币中，STF 主要仅限于余额变更，使其比较简单。然而，与比特币不同，以太坊的 STF 更加复杂，因为以太坊是一个完全可编程的区块链，执行层能够运行代码。

在区块链中，有三个基本组件你需要或者能够进行验证：

1. 状态: 你可能想在区块链上读取一段数据，但因为你没有运行 全节点，而无法访问状态。因此，你通过像 Alchemy 或 Infura 这样的 RPC（远程过程调用）提供者请求数据。然而，你必须验证数据没有被 RPC 提供者篡改。
2. 执行: 如前所述，区块链利用 STF。你必须验证状态转移是否正确执行——不是逐个交易，而是逐个区块的基础上。
3. 共识: 第三方实体，如 RPC，可以提供还未包含在区块链中的有效区块。因此，你必须验证这些区块是否通过共识被接受并添加到区块链中。

如果这听起来令人困惑或不清楚，请不要担心。我们将详细介绍这些方面。让我们从如何验证区块链的 状态 开始！

如何验证区块链状态？

以太坊的“状态”指的是在任何时刻存储在区块链上的数据集。这包括账户余额（合约账户和外部拥有的账户或 EOA）、智能合约代码、合约存储等。以太坊被称为基于状态的机器，因为在以太坊虚拟机（EVM）中处理的交易会改变先前的状态并产生新的状态。

每个以太坊区块包含一个值，摘要了该区块之后网络的当前状态: stateRoot。这个值是整个以太坊状态的紧凑表示，常常是一个 64 个字符的哈希。

随着每个新交易修改状态，记录在后续区块中的 stateRoot 也随之更新。为了计算这个值，以太坊的验证者使用名为凯拉克（Keccak）哈希散列函数和称为 Merkle 树 的数据结构的组合，以组织和汇总状态的不同部分。

哈希函数是一种单向函数，将输入转换为固定长度的输出。在以太坊中，像 Keccak 这样的哈希函数被用于生成数据摘要，充当输入的某种指纹。哈希函数具有四个基本特性：

1. 确定性: 相同的输入总是会产生相同的输出。
2. 固定输出长度: 无论输入的长度如何，输出的长度始终固定。
3. 单向属性: 从输出推导原始输入在实际操作中几乎是不可能的。
4. 唯一性: 即使输入的微小改变也会产生完全不同的输出。因此，特定输入映射到几乎唯一的输出。

基于这些特性，以太坊验证者能够对每个区块执行 STF（状态转移函数）——执行区块中的所有交易并将其应用于状态，然后验证区块中指示的状态是否与经过 STF 得到的状态匹配。这个过程确保区块提议者的行为是诚实的，使其成为验证者的关键责任之一。

然而，以太坊的验证者并不会直接哈希整个状态以寻找其摘要。由于哈希函数的单向性，直接哈希状态将消除可验证性，因为唯一重现哈希的方法是拥有整个状态。

由于以太坊的状态大小为 TB（太字节），在手机或个人计算机等日常设备上存储整个状态是不切实际的。因此，以太坊使用 Merkle 树结构来计算 stateRoot，尽可能保持对状态的可验证性。

Merkle 树 是一种加密数据结构，用于安全和高效地验证数据的完整性和正确性。Merkle 树基于哈希函数构建，并以分层方式组织一组数据集的哈希，使得能够验证这些数据的完整性和正确性。这个树结构由三种类型的节点组成：

1. 叶子节点: 这些节点包含单个数据块的哈希，并位于树的底层。每个叶子节点代表 Merkle 树中一个特定数据的哈希。
2. 分支节点: 这些节点包含其子节点的组合哈希。例如，在一个二叉 Merkle 树（N=2）中，两个子节点的哈希连接并再次哈希以生成一个上层分支节点的哈希。
3. 根节点: 根节点位于 Merkle 树的最上层，代表整个树的加密摘要。这个节点用于验证树中所有数据的完整性和正确性。

如果你想知道如何构建这样的树，只需两步简单步骤：

• 叶子节点创建: 每一段数据都通过哈希函数处理，结果哈希形成叶子节点。这些节点位于树的最底层，代表数据的加密摘要。

• 组合与哈希: 将叶子节点的哈希成组（例如，成对），然后组合并进行哈希。这一过程创建了下一个层级的分支节点。对于每个分支节点重复相同的过程，直到只剩下一个哈希。

在树顶获得的最终哈希称为 Merkle 根。Merkle 根表示整个树的加密摘要，允许安全地验证数据的完整性。

我们如何使用 Merkle 根来验证以太坊的状态？

Merkle 证明使 验证者 能够通过提供从目标数据（叶子节点）到存储在区块头中的 Merkle 根 的一系列哈希值，来高效地验证特定数据块的真实性。这条由中间哈希链构成的路径使验证者能够确认数据的真实性，而无须哈希整个状态。

从特定数据点开始，验证者将该数据与 Merkle 证明中提供的每个“兄弟”哈希组合，并逐步向上计算哈希。该过程会一直持续，直到产生一个单一的哈希。如果计算出的哈希与存储的 Merkle 根匹配，则数据被视为有效；否则，验证者可以确定该数据与声称的状态不对应。

示例：使用 Merkle 证明验证数据点

假设我们从 RPC 收到了数据 #4，并想使用 Merkle 证明验证其真实性。为此，RPC 会提供一组沿着路径到达 Merkle 根所需的哈希值。对于数据 #4，这些兄弟哈希包括哈希 #3、哈希 #12 和哈希 #5678。

1. 从数据 4 开始: 首先，我们将数据 #4 哈希，以获得哈希 #4。
2. 与兄弟哈希组合: 然后我们将哈希 #4 与哈希 #3（其在叶子层的兄弟）组合并进行哈希以产生哈希 #34。
3. 向上移动: 接下来，我们将哈希 #34 与哈希 #12（其在下一个层级的兄弟）组合并哈希，以获得哈希 #1234。
4. 最后一步: 最后，我们将哈希 #1234 与哈希 #5678（最后提供的兄弟）组合并哈希。生成的哈希应与存储在区块头中的 Merkle 根（哈希 #12345678）匹配。

如果计算出的 Merkle 根与区块中的状态根匹配，则我们确认数据 #4 在该状态中确实有效。如果没有，我们知道该数据不属于声称的状态，表明可能存在篡改。如你所见，在不提供所有数据的哈希或不要求验证者重新构建整个 Merkle 树的情况下，证明者可以仅用三个哈希证明数据 #4 在状态中存在，并未在传递过程中被更改。这是 Merkle 证明被认为高效的主要原因。

尽管 Merkle 树在像以太坊这样的庞大区块链系统中显著有效地提供安全高效的数据验证，但它们真的足够高效吗？为了解答这个问题，我们必须分析 Merkle 树的表现和规模如何影响证明者与验证者的关系。

影响 Merkle 树性能的两个关键因素：⌛

1. 分支因子: 每个分支的子节点数量。
2. 总数据大小: 在树中表示的数据集的大小。

分支因子的影响：

让我们用一个例子更好地理解它的影响。分支因子决定了每个节点生成多少个分支。

• 小分支因子（例如，二叉 Merkle 树）: 如果使用二叉 Merkle 树（分支因子为 2），则证明大小非常小，这使得验证过程对于验证者更有效。由于每个节点只具有两个分支，验证者仅需处理每层一个兄弟哈希。这加快了验证速度，减少了计算负担。然而，减少的分支因子会增加树的高度，在构建树的过程中需要更多的哈希操作，这对验证者构成了负担。

• 较大分支因子（例如，4）: 较大的分支因子（例如，4）会降低树的高度，创建一个更短而宽的结构。因此，全节点的构建树速度更快，因为所需的哈希操作较少。然而，对于验证者来说，这会增加他们在每层必须处理的兄弟哈希数量，从而导致较大的证明大小。每次验证步骤都需要更多哈希，意味着验证者的计算和带宽成本也更高，实际上将负担从验证者转移到验证者身上。

总数据大小的影响：

随着以太坊区块链的增长，每个新交易、合约或用户交互都会增加数据集，Merkle 树也必须扩展。这种增长不仅增加了树的大小，还影响了证明大小和验证时间。

• 全节点必须定期处理和更新不断增长的数据集，以保持 Merkle 树。
• 验证者反过来，必须在数据集增长时验证更长且更复杂的证明，这需要更多时间和带宽。数据集的增长增加了对全节点和验证者的需求，使得高效扩展网络变得更加困难。

总之，虽然 Merkle 树提供了一定程度的效率，但它们未能成为以太坊持续增长的数据集的最佳解决方案。因此，在 边缘 阶段，以太坊的目标是用更高效的结构替代 Merkle 树，即 Verkle 树。Verkle 树有潜力提供较小的证明大小，同时保持同样的安全级别，使得验证过程对证明者和验证者都更可持续、更具可扩展性。

第二章：以太坊可验证性的革命——边缘

边缘 作为以太坊路线图中的一个里程碑，旨在改善可验证性，加强区块链的去中心化结构，并增强网络安全。以太坊网络的主要目标之一是使任何人都能轻松运行验证者来验证链，创造一个每个人都可以参与而无需中心化的结构。这种验证过程的可获得性是区块链与中心化系统之间的一个关键特征。虽然集中系统不提供验证能力，但区块链的 correctness 完全掌握在用户手中。然而，要维持这种保障，必须让每个人都能方便地运行验证者，否则目前的系统仍然存在存储和计算能力要求的局限性。

在过渡到 权益证明 理论的 合并 后，以太坊验证者有两个主要责任：

1. 确保共识: 支持概率性和确定性共识协议的正常运行，并应用分叉选择算法。
2. 检查区块准确性: 在执行区块中的交易后，验证结果状态树的根是否与提议者声明的状态根匹配。

为了履行第二个责任，验证者必须在区块之前访问状态。这使他们能够执行区块的交易，推导出后续状态。然而，这一要求给验证者施加了沉重的负担，因为它们需要处理大量存储需求。虽然以太坊旨在具备可行性，并且存储成本在全球范围内一直在下降，但问题更不在于成本，而在于验证者对专门硬件的依赖。边缘旨在通过创建基础设施来解决这一挑战，即使在有限存储的设备（如手机、浏览器钱包甚至智能手表）上也能执行完全验证，从而使验证者能够在这些设备上运行。

可验证性的第一步：状态

过渡到 Verkle 树 是这一过程的关键部分。最初，边缘 的重点是用 Verkle 树替代以太坊的 Merkle 树结构。采用 Verkle 树的主要原因是 Merkle 树对以太坊的可验证性构成了重大障碍。虽然 Merkle 树及其证明在正常场景中能够有效工作，但在 最坏情况场景 中，性能急剧下降。

根据 Vitalik 的计算，平均证明大小约为 4 KB，这听起来还算可控。然而在最坏情况下，证明的大小可能激增至 330 MB。是的，你没看错——330 MB。

以太坊的 Merkle 树在最坏情况场景中的极端低效源于两个主要原因：

1. 采用六叉树: 以太坊目前使用的 Merkle 树具有 16 的分支因子。这意味着验证单个节点需要提供分支中剩余的 15 个哈希。鉴于以太坊状态的规模以及分支的数量，这在最坏情况下造成了相当大的负担。

2. 代码的非 Merkle 化: 与将合约代码纳入树结构相反，以太坊仅哈希该代码，并使用生成的值作为节点。考虑到合约的最大大小为 24 KB，这种方法在达到完整可验证性方面造成了重大障碍。

证明大小与分支因子成正比。减少分支因子会减小证明大小。为了解决这些问题并改善最坏情况，以太坊可以从六叉树切换到 二叉 Merkle 树 并开始对合议代码进行 Merkle 化。如果以太坊的分支因子从 16 降低到 2，并且合约代码也进行 Merkle 化，那么最大证明大小可能会缩小到 10 MB。尽管这是一项显著改进，但值得注意的是，这一成本仅适用于验证 一段数据。即使是一个简单的交易涉及多段数据，也会需要更大的证明。考虑到每个区块的交易数量和以太坊持续增长的状态，尽管这种解决方案更好，但仍然不完全可行。

基于这些原因，以太坊社区提出了两种不同的解决方案来应对这一问题：

1. Verkle 树
2. STARK 证明 + 二叉 Merkle 树

Verkle 树与向量承诺

Verkle 树，如其名所示，是一种类似于 Merkle 树 的树结构。尽管如此，它们在验证过程中的效率显著提高。在 Merkle 树 中，如果一个分支包含 16 个数据块，而我们想要验证其中一个，则必须同时提供其他 15 个数据的哈希链。这显著增加了验证的计算负担并导致证明大小增大。

与此相反， Verkle 树 利用一种称为 “基于椭圆曲线的向量承诺” 的特殊结构，更具体地说是一种 内积论证（IPA） 的向量承诺。向量实际上是按特定顺序组织的一组数据元素。以太坊的状态可以视为一个向量：一个按照特定顺序存储多种数据的结构，每个元素都是关键的。这种状态涉及多个数据组件，例如地址、合约代码和存储信息，这些元素的顺序在访问和验证中发挥着至关重要的作用。

向量承诺 是一种用于证明和验证数据集中数据元素的加密方法。这些方法允许同时验证数据集中每个元素的存在性和顺序。例如，Merkle 证明，在 Merkle 树中使用，也可以视为一种 向量承诺。尽管 Merkle 树需要提供所有相关哈希链以验证一个元素，但该结构本质上证明了向量的所有元素以特定顺序连接在一起。

与 Merkle 树不同，Verkle 树采用 基于椭圆曲线的向量承诺，提供两个关键优势：

• 基于椭圆曲线的向量承诺不需要提供数据验证之外的元素详情。在具有 16 的分支因子的 Merkle 树中，验证单个分支必须提供其他 15 个哈希。鉴于以太坊状态的庞大，涉及许多分支，这造成了显著的低效。但基于椭圆曲线的向量承诺消除了这种复杂性，使得验证所需的数据和计算量更少。
• 通过多重证明，由椭圆曲线向量承诺生成的证明可以压缩为统一大小的单一证据。以太坊的状态不仅庞大，而且在不断增长，意味着需要验证的分支数量随着时间增加。但是，通过 Verkle 树，我们可以使用 Dankrad Feist 的文章 中详细说明的方法，将每个分支的证明“压缩”成一个小型固定大小的证明。这允许验证者只用一个小证明来验证整个树，而不是逐个验证每个分支。这也意味着 Verkle 树的验证不受以太坊状态增长的影响。

这些椭圆曲线向量承诺的功能大大减少了进行验证所需的数据量，使 Verkle 树即使在最坏情况下也能生成小而恒定大小的证明。这最小化了数据开销和验证时间，提高了以太坊等大规模网络的效率。因此，在 Verkle 树中采用椭圆曲线向量承诺使得管理和处理以太坊不断扩张的状态变得更容易和高效。

像所有创新一样，Verkle 树有其局限性。其中一个主要缺点是它们依赖于椭圆曲线密码学，而椭圆曲线密码学脆弱 于 量子计算机。量子计算机具有比传统方法更强大的计算能力，构成了对基于椭圆曲线的密码协议的重大威胁。量子算法可能会破坏或削弱这些密码系统，给 Verkle 树的长期安全性带来担忧。

出于这个原因，尽管 Verkle 树为无状态带来了有前景的解决方案，但它们并不是最终的修正。然而，像 Dankrad Feist 这样的人强调，虽然在将量子抗性密码学集成到以太坊中时需要谨慎考虑，但需要注意的是，目前在以太坊用来处理 blob 的 KZG 承诺 也不是抗量子安全的。因此，Verkle 树可以作为一种临时解决方案，为网络提供额外的时间来开发更强的替代方案。

STARK 证明 + 二叉 Merkle 树

Verkle 树 提供了比 Merkle 树更小的证明大小和更高效的验证过程，使得更容易管理以太坊日日增长的状态。得益于 基于椭圆曲线的向量承诺，可以生成大型证明，并且所需的数据量显著降低。但是，尽管 Verkle 树的优势令人印象深刻，但它们对量子计算机的脆弱性使其仅为一种临时解决方案。以太坊社区将 Verkle 树视为一种短期工具，争取时间，而长期关注则是转向 抗量子解决方案。这就是 STARK 证明 和 二叉 Merkle 树 如何成为建立未来更坚固可验证性基础设施的强大替代方案。

在以太坊的状态验证过程中，通过使用 二叉 Merkle 树，可以减少 Merkle 树的 分支因子（从 16 降低到 2）。这一变化是减少证明大小并提高验证过程效率的关键步骤。然而，就算在最坏出现情况下，证明的大小仍然可以达到 10 MB，这也是相当可观的。这就是 STARK 证明 派上用场的地方，把这些大型二叉 Merkle 证明压缩到仅 100-300 kB。

这一优化在操作需要受限设备的验证者时尤为重要，特别要考虑到全球平均移动下载和上传速度大约为 7.625 MB/s 和 1.5 MB/s。用户可以在不需要存取完整状态的情况下，使用小块便携证明来验证交易，验证者可以在不存储完整状态的情况下执行区块验证任务。

这种双重优势方法分别减少了验证者的带宽和存储要求，同时加快了验证速度，这三项关键改进直接支持以太坊的可扩展性愿景。

STARK 证明面临的主要挑战：

1. 证明者侧的高计算负担: 生成 STARK 证明的过程计算密集，尤其是在提供阶段，可能会增加运作成本。
2. 在小数据证明中的低效性: 虽然 STARK 证明在处理大数据集时表现出色，但在证明较小数量的数据时效率不高，这可能会妨碍其在某些场合的应用。在涉及较小步骤或数据集的程序中，STARK 的相对贼大证明规模可能使其不太切实际或成本过高。

量子安全代价高昂：证明者侧的计算负担

一个区块的 Merkle 证明可以包含约 330,000 个哈希，在最坏情况下，这个数字可能上升到 660,000。在这种情况下，一个 STARK 证明需要处理约 200,000 个 哈希每秒。

这正是 zk 友好型哈希函数如 Poseidon 发挥作用的地方，专门针对 STARK 证明进行了优化，以减轻这个负担。Poseidon 被设计得比传统哈希算法（如 SHA256 和 Keccak）更无缝地与 ZK 证明配合使用。其兼容性主要源于传统哈希算法的操作方式：以二进制数据（0 和 1）处理输入，而 ZK 证明则是在质数域中工作，这两者根本不同。这些情况类似于计算机以二进制形式操作，而日常生活中人类使用十进制系统。将基于比特的数据翻译成适合 ZK 的格式会涉及大量计算开销。Poseidon 通过 以 质数 来运作，从而极大缩减与 ZK 证明的集成。

不过，由于 Poseidon 是一种相对较新的哈希函数，它需要进行更广泛的安全分析，以建立与传统哈希函数（如 SHA256 和 Keccak）相同的信心。为此，以太坊基金会开展了 Poseidon 加密分析计划，邀请专家严格测试和分析 Poseidon 的安全性，以确保它能够抵御对抗性检验，并成为密码应用的坚固标准。另一方面，旧的函数如 SHA256 和 Keccak 已经经过广泛测试，且拥有可靠的安全记录，但并不符合 ZK 的友好要求，使得在 STARK 证明中运用时存在性能降低问题。

例如，使用这些传统哈希函数的 STARK 证明当前仅能处理 10,000 到 30,000 个哈希。幸运的是，STARK 技术的发展表明，这一吞吐量可能很快会增加到 100,000 到 200,000 个哈希，从而显著改善其效率。

STARK 在小数据证明中的低效性

虽然 STARK 证明在处理大数据集的可扩展性与透明性上表现优广，但在处理小规模且数量众多的数据元素时展现出局限性。在这些场合中，被证明的数据往往比较小，但所需的多个证明仍然存在。例子包括：

1. 后 AA 交易验证: 通过账户抽象（AA），钱包能指向合约代码，绕过或定制诸如 nonce 和签名验证等当前在以太坊必不可少的步骤。然而，这种灵活性要求查验合约代码或其他相关数据在状态中，以此验证交易的有效性。
2. 轻客户端 RPC 调用 :轻客户端从网络查询状态数据（例如，在 eth_call 请求中），并不运行全节点。为了确保该状态的正确性，证明必须支持查询的数据，并确认这些数据与网络的当前状态相匹配。
3. 包含列表 :较小的验证者可以使用包含列表机制确保交易在下一个区块中被纳入，限制强大区块生产者的影响。然而，验证这些交易的纳入有效性需要验证其正确性。

在这样的用例中，STARK 证明提供的优势非常微小。STARK 强调可扩展性（其名称中的“S”便是如此），在处理大数据集时表现优良，而在小数据场景中却捉襟见肘。相比之下， SNARKs（同样名称中的“S”便强调了其简洁性）更注重减少证明大小，因而在带宽或存储限制的环境中更具开展优势。

STARK 证明通常是 40-50 KB 大小，大致是 SNARK 证明（仅 288 字节）的 175 倍。这种大小差异增加了验证时间及网络费用。STARK 更大的证明的主要原因在于其依赖于透明度与多项承诺以确保可扩展性，这在小数据场景中引入了性能盈余。在该情况下，更快且空间更高效的方法如 Merkle 证明 可能更具实用性。Merkle 证明提供了较低的计算费用和快速的更新，使其在这些情况下更为合适。

尽管如此，STARK 证明依然在以太坊的无状态未来中因其 量子安全性 而至关重要。

如表中所示，以太坊共有四种潜在路径可供选择：

• Verkle 树
  1. Verkle 树 得到以太坊社区的广泛支持，定期召开双周会议以促成其发展。由于持续的工作与测试，Verkle 树在当今其他替代方案中显得尤为显著和成熟。此外，其 加法同态 的属性消除了如 Merkle 树那样每次更新状态根时需重新计算每个分支的烦扰，因此更为高效。与其他的解决方案相比，Verkle 树强调简洁，遵循像“保持简单”或“简单才是最好的”这样的工程原则。这一简洁性为与以太坊的集成与安全分析提供了方便。
  2. 但需要注意的是，Verkle 树不是抗量子安全的，因此它们无法成为长期解决方案。如果将此技术集成到以太坊中，在未来需要抗量子解决方案时，可能会需要做更换。即便 Vitalik 也认为 Verkle 树是一个临时措施，以争取更多时间让 STARK 及其他技术成熟。此外，与简单的哈希函数相比，Verkle 树所采用的 基于椭圆曲线的向量承诺 同时也施加了更高的计算负担。与基于哈希的方法相比，Verkle 树会牺牲提高全节点的同步速度。而且，显著的依赖 256 位操作使 Verkle 树在现代证明系统中不那么易于使用 SNARK。这也使未来简化证明大小的努力变得更复杂。

然而，重要的是，因其对哈希的非依赖性，Verkle 树由于可验证性相比 Merkle 树显著更高。

• STARKs + 保守哈希函数

  1. 将 STARKs 结合建立良好的保守哈希函数如 SHA256 或 BLAKE，提供了一个强大的解决方案，有力提高以太坊的安全基础架构。这些哈希函数在学术界和实际领域都已广泛使用和全面测试。此外，它们的抗量子能力增强了以太坊抵御未来量子计算机威胁的能力。在安全需重的情境中，这一组合提供了可靠基础。
  2. 然而，在 STARK 系统使用保守哈希函数引入了显著的性能限制。这些哈希函数所需的计算能力产生了高 证明者延迟 ，证明生成需超出 10 秒。尤其在像区块验证对较低延迟的高度要求的场景中，这成为主要的不利因素。虽然包括 多维气体提案 等努力试图将最坏情况与平均情况延迟对齐，但结果有限。此外，虽然基于哈希的方法能够加速同步时间，但效率可能与 STARK 追求更广泛的可扩展性目标不太一致。传统哈希函数的计算时间长，降低了实际效率，并限制了其应用。

• STARKs + 相对新型哈希函数

  1. 将 STARKs 与 新一代 STARK 友好型哈希函数（例如 Poseidon）结合显著提升了此技术的性能。这些哈希函数为与 STARKs 系统接合而设计，能极大减少 证明者延迟。与传统哈希函数不同，它们能在 1-2秒 内生成证明。它们的效率和较低的计算开销提升了 STARK 的可扩展性必然，因此能有效处理大数据集，该样的功能让它们在需要高性能的应用中极具吸引力。
  2. 但需要注意的是，这些哈希函数的相对新颖性需要更广泛的安全分析和测试。安全面临风险，因为未经过充分检测的若考虑将在以太坊等关键生态系统中实施。此外，因为这些哈希函数尚未受到广泛采用，所需的测试和验证过程可能延迟以太坊的可验证性目标。全面确保安全性的时间可能使此选项在短期内不太具吸引力，这将推迟以太坊的可扩展性和可验证性的抱负。

• 基于格的 Merkle 树

  1. 基于格的 Merkle 树 提供了一种前瞻性解决方案，结合量子安全与 Verkle 树的更新效率。这些结构解决了 Verkle 树和 STARKs 的弱点，被视为一个有前景的长期选项。凭借其基于格的设计，它们提供了抗量子计算威胁的强大能力，与以太坊未来保障其生态系统的目标一致。此外，通过保持 Verkle 树的可更新性优势，它们旨在提高安全性而不降低效率。
  2. 然而，对基于格的 Merkle 树的研究仍处于初步阶段，且大多是理论上。这对其实际实施和性能存在了显著不确定性。将此类解决方案整合到以太坊中需要广泛的研究和开发，以及严格的测试，以验证其潜在的好处。这些不确定性和结构上的复杂性使得在短期内，基于格的 Merkle 树并不是以太坊可行的选择，这可能推迟网络的可验证性目标的进展。

那么执行呢：EVM 执行的有效性证明？

到目前为止，我们讨论的都围绕着消除验证者存储前一状态的需求，验证者用这些状态转移到下一个状态。目标是创造一个更去中心化的环境，以便验证者能够履行职责，而不必维护 TB 级的状态数据。即使是我们提到的解决方案，验证者也不需要存储整个状态，因为他们可以通过包含在区块中的见证接收执行所需的所有数据。然而，为了转移到下一个状态并在区块顶部验证状态根，验证者仍必须自己执行 STF。这个要求又对以太坊的无许可性质和去中心化 posed新挑战。最初，The Verge 被设想为一个里程碑，专注于将以太坊的状态树从 Merkle Trees 转换为 Verkle Trees 以提高状态可验证性。然而，随着时间的推移，它发展成一个更广泛的倡议，旨在增强 状态转移和共识 的可验证性。在状态、执行和共识三者完全可验证的世界中，以太坊验证者可以在几乎所有具有互联网连接的设备上运行，这些设备可以被归类为 轻客户端。这将使以太坊更接近实现其“真正去中心化”的愿景。

问题定义是什么？

如前所述，验证者每 12 秒执行一个称为 STF (State Transition Function) 的函数。此函数以先前的状态和区块作为输入，并生成下一个状态作为输出。每当提议新块时，验证者必须执行此函数，并验证表示区块上状态的哈希（通常称为 状态根）是否正确。

成为验证者的高系统要求主要源于需要高效执行此过程。

如果你想将一台 智能冰箱——是的，甚至是冰箱——通过一些安装的软件变成以太坊验证者，你将面临 两个主要障碍：

1. 你的冰箱很可能没有足够快的互联网，这意味着即使有我们讨论过的状态可验证性解决方案，它也无法下载执行所需的数据和证明。
2. 即使它能接access到必要的 STF 数据，它也没有执行整个过程或构建新状态树所需的计算能力。

为了缓解轻客户端未能访问 先前状态 或最后一个完整区块所带来的问题，The Verge 提出提议者应执行 执行，然后将证明附加到区块上。这个证明将包括从 先前状态根 到 下一个状态根 的转换，以及区块的哈希。专注于这点，轻客户端可以仅凭 三个 32 字节 哈希来验证状态转移，而不需要 zk-proof。

然而，由于这个证明是通过哈希工作的，因此说它只验证 状态转移 是不正确的。相反，附加到区块上的证明必须“同时验证多个事物”：

先前区块中的状态根 = S，下一个区块中的状态根 = S + 1，区块哈希 = H

1. 区块本身必须是有效的，以及它内部的 状态证明——无论是 Verkle 证明还是 STARKs——必须准确验证随区块附带的数据。简而言之：区块及随附状态证明的有效性验证。
2. 当使用与 H 对应的区块中包含的数据执行 STF 时，状态中应该改变的数据必须被正确更新。简而言之：状态转移的有效性验证。
3. 当用正确更新的数据重新构建一个新状态树时，其根值必须与 S + 1 匹配。简而言之：树构建过程的有效性验证。

在我们先前提到的 Prover-Verifier 类比 中，可以公正地说，两个参与者之间通常存在 计算平衡。虽然执行 STF 以使其可验证且验证多个事物的能力为 Verifier 提供了显著优势，但这也表明，为了确保执行的正确性，生成这样的证明对 Prover 来说相对具有挑战性。以太坊当前的速度，必须在 4 秒 内对以太坊区块进行证明。然而，即使是我们今天拥有的最快的 EVM Prover 也只能平均在大约 15 秒 内证明一个块。[1]

也就是说，我们可以选择 三条不同路径 来克服这个重大挑战：

1. 证明与聚合中的并行化：ZK 证明的一个重要优势是其 聚合能力。将多个证明合并为一个紧凑的证明提供了处理时间上的显著效率。这不仅减少了网络的负担，还加速了去中心化过程中的验证过程。对于像以太坊这样的庞大网络，能够以更高效的方式生成每个区块的证明。

在证明生成过程中，每个执行过程的小步骤（例如计算步骤或数据访问）都可以单独进行证明，而这些证明随后可以汇总为一个结构。在正确的机制下，这种方法使区块的证明通过许多不同的 sources (例如数百个 GPU) 快速去中心化地生成。这不仅推动了性能的提高，而且通过吸引更广泛的参与者群体有助于达成去中心化目标。

2. 使用优化过的证明系统：新一代证明系统有潜力使以太坊的计算过程更快、更高效。诸如 Orion、 Binius 和 GKR 等先进系统能显著减少泛用计算的 prover 时间。这些系统旨在克服当前技术的局限，提高处理速度，同时消耗更少的资源。对于一个关注可扩展性和效率的网络如以太坊，这些优化提供了显著的优势。然而，充分实现这些新系统需要在生态系统内进行全面的测试和兼容性努力。
3. Gas 费用变化：在历史上，以太坊虚拟机(EVM)中的操作的 gas 成本通常基于其 计算成本 来确定。然而，今天，另一个指标愈发重要：prover 复杂性。虽然一些操作相对容易进行证明，但其他操作则结构更复杂，核实的时间也较长。根据计算难度和操作证明的难易度调整 gas 成本，对提升网络的安全性和效率至关重要。

这种方法可以缩小 最坏情况 和 平均情况 之间的差距，从而实现更一致的性能。例如，证明较困难的操作可以有更高的 gas 成本，而验证较易的操作则可以降低成本。此外，用 STARK 友好的 替代品 替换以太坊的数据结构（例如 状态树 或 交易列表），可能会进一步加速证明过程。这些更改将帮助以太坊实现其可扩展性和安全目标，同时使其 可验证性愿景 更加现实。

以太坊启用 执行证明 的努力代表了实现其可验证性目标的重大机会。然而，实现这一目标不仅需要技术创新，还需要在社区内部进行更多的工程努力和关键决策。在Layer1使执行过程可验证必须平衡访问广泛用户基础并保持去中心化，与现有基础设施对齐。确立这一平衡增加了在执行过程中使用的操作证明方法的复杂性，凸显了如 并行证明生成 的技术进步的必要性。此外，这些技术的基础设施要求（例如， 查找表）必须被实施和投入使用，这仍然需要大量的研究和开发。

另一方面，专门电路（例如，ASIC、FPGA、GPU）专为某些任务设计，具有加速证明生成过程的巨大潜力。这些解决方案提供的效率远高于传统硬件，可以加速执行过程。然而，以太坊在Layer1的 去中心化目标 不允许此类硬件仅对少数特定的参与者可用。因此，这些解决方案预计应用会更加广泛于 Layer 2 系统。然而，社区必须对此类硬件生成证明的要求达成共识。一个关键的设计问题出现：生成证明是否应该在如高端笔记本电脑等消费级硬件上工作，或者需要工业基础设施？答案直接影响以太坊的整体架构——允许在 Layer 2 解决方案中进行激进优化，同时对 Layer 1 需求更为保守的方法。

最后，执行证明的实施直接关系到以太坊的其他路线图目标。引入 有效性证明 不仅将支持 无状态性 等概念，还将通过使 solo staking 等领域更易于接触来增强以太坊的去中心化。目标是使最低规范设备上的 staking 成为可能。此外，基于计算难度和可证明性重构 EVM 中的 gas 成本可能会缩小 平均情况 和 最坏情况 之间的差距。然而，这样的变化可能会破坏与当前系统的向后兼容性，迫使开发者重写他们的代码。正因如此，执行证明的实施不仅是一个技术挑战——它是一段旅程，必须设计以维护以太坊的长期价值。

达成真正全面可验证性的最后一步：共识

以太坊的 共识机制 力求在保持去中心化和可访问性与实现可验证性目标之间建立独特的平衡。在这个框架中，概率性和确定性共识方法提供了不同的优势和挑战。

概率性共识 建立在一个传播通信模型上。在这个模型中，而不是直接与代表网络的所有节点进行通信，一个节点会与 64 或 128 个随机选定的节点共享信息。节点的链选择基于这些有限信息，这引入了错误的可能性。然而，随着区块链的发展，这些选择预计将会以 0% 错误率汇聚到正确的链上。

概率结构的一个优点是每个节点不会将其链视图作为单独的消息广播，从而减少通信开销。因此，这种结构能够与更多 无许可、去中心化且系统要求较低的节点一起运行。相比之下，确定性共识 通过一对多 通信模型 进行。在这里，一个节点将其链视图作为投票发送给所有其他节点。这种方法生成更高的消息强度，随着节点数量的增加，系统可能会最终达到其限制。然而，确定性共识的最大优势在于可获得具体的投票，这使你可以准确知道哪个节点投票支持哪个分叉。这保证了快速而明确的链最终性，确保区块的顺序不可以被更改并且是可验证的。

为了提供 可验证的共识机制，同时保持去中心化和无许可证结构，以太坊在时隙和纪元之间取得了平衡。时隙代表 12 秒的间隔，是验证者负责生产一个块的基本单位。尽管在时隙级别使用的概率共识允许运行链更灵活和去中心化，但在确定排序和可验证性方面有其局限性。

纪元包括 32 个时隙，引入了确定性共识。在这个级别上，验证者投票最终确定链的顺序，确保确定性，使链可检测。然而，尽管这种确定性结构通过具体投票在纪元级别提供了可验证性，但由于概率结构，它无法在纪元本身内提供完整的可验证性。为了填补这个空白并加强纪元内的概率结构，以太坊开发了一个名为同步委员会（Sync Committee）的解决方案。

Altair 的轻客户端协议：同步委员会

同步委员会 是随着 Altair 升级而引入的一种机制，旨在克服以太坊的概率共识的局限性，并改善轻客户端链的可验证性。该委员会由 512 个随机选定的验证者组成，他们服务 256 个纪元（约 27 小时）。这些验证者生成代表链头的签名，使轻客户端无须下载历史链数据就能验证链的有效性。同步委员会的操作可以总结为：

1. 委员会的成立：从网络中所有验证者中随机选择 512 个验证者。为了保持去中心化和防止过于依赖特定群体，该选择会定期刷新。
2. 签名生成：委员会成员生成一个代表链最新状态的签名。这个签名是由成员共同创建的 BLS 签名，用于验证链的有效性。
3. 轻客户端验证：轻客户端只需检查来自同步委员会的签名就能够验证链的正确性。这让他们能够安全地跟踪链而不必下载过去的链数据。

然而，同步委员会在某些方面受到批评。特别是，该协议 缺乏惩罚验证者恶意行为的机制，即使被选中的验证者故意违反该协议。因此，许多人认为同步委员会存在安全风险，并且不完全归类其为 轻客户端协议。然而，同步委员会的安全性已被 数学证明，更多详细信息可以在 这篇关于同步委员会惩罚的文章 中找到。

协议中缺乏惩罚机制并不是设计选择，而是源于概率共识的本质。概率共识并未对验证者所观察的信息提供绝对保证。即使大多数验证者报告特定的分叉为较重，仍可能存在个别验证者观察到不同的分叉为较重。这种不确定性使得证明恶意意图变得困难，因此也就无法惩罚不当行为。

在这种背景下，将同步委员会描述为不安全并不准确，而是更恰当地指其为一种无效的解决方案。这个问题并不来自于同步委员会的机械设计或运作，而是来自于概率共识的固有性质。由于概率共识无法提供关于节点观察的确定性保证，因此同步委员会是可以在这种模型内设计出的最佳解决方案之一。然而，这并没有消除概率共识在保证链最终性方面的局限性。问题出在机制，而是在以太坊当前的共识结构中。

由于这些限制，以太坊生态系统内正在进行努力以重新设计共识机制并实施解决方案，以便缩短确定性最终性期。提案如 Orbit-SSF 和 3SF 力求从根本上重塑以太坊的共识结构，创建一个更有效的系统来替代概率共识。这些方法不仅寻求缩短链的最终时间，还希望提供更高效和可验证的网络结构。以太坊社区继续积极发展并为未来实施这些提案做准备。

共识的 Snarkification

The Verge 力求通过 zk-proof 技术增强以太坊当前和未来的共识机制，使其更具可验证性，而不是完全取代它们。这种方法旨在在现代化以太坊的共识过程中，同时保持去中心化和安全性的核心原则。用 zk 技术优化链的所有历史和当前共识过程在实现以太坊长期可扩展性和效率目标方面发挥着至关重要的作用。以太坊共识层使用的基本操作在这一技术转型中至关重要。让我们详细了解这些操作及其面临的挑战。

• ECADDs：
  • 目的：该操作用于聚合验证者的公钥，对于确保链的准确性和效率至关重要。由于 BLS 签名的可聚合特性，多个签名可以合并成一个单一结构，从而减少了通信开销，使链上的验证过程更有效。确保大型验证者组之间的同步更有效则使这个操作非常关键。
  • 挑战：正如之前提到的，以太坊验证者在纪元期间就链的顺序进行投票。如今，以太坊是一个大约有 110 万验证者 的网络。如果所有验证者试图同时传播他们的投票，会对网络造成显著压力。为此，以太坊允许验证者在一个纪元内按时隙投票，每个时隙只有 1/32 的验证者进行投票。虽然这种机制减少了网络通信开销并使共识更为高效，但考虑到如今的验证者数量，大约有 34,000 验证者 在每个时隙投票。这意味着每个时隙约有 34,000 ECADD 操作。
• 配对（Pairings）：
  • 目的：配对操作用于验证 BLS 签名，确保链上纪元的有效性。此操作允许批量验证签名。然而，因为不 zk 友好，使用 zk-proof 技术进行证明的成本极高。这为创造与零知识科技的集成验证过程带来了重大挑战。
  • 挑战：以太坊中的配对操作每个时隙最多仅限于 128 个证明（聚合签名），与 ECADD 比起来，导致配对操作较少。然而，这些操作缺乏 zk 友好的特性这一问题构成重大挑战。使用 zk 证明一项配对操作的成本是证明一项 ECADD 操作的数千倍[2]。这使得适应配对操作以符合零知识技术成为以太坊共识验证过程中的最大障碍之一。
• SHA256 哈希：
  • 目的：SHA256 哈希函数用于读取和更新链的状态，确保链数据的完整性。然而，它们不具备 zk 友好性，从而导致基于 zk 的验证过程中效率低下，这对以太坊未来实现可验证性目标构成了重大障碍。
  • 挑战：SHA256 哈希函数常用于读取和更新链的状态。然而，其 zk 不友好性与以太坊基于 zk 的验证目标存在冲突。例如，在两个纪元之间，每个验证者运行以太坊的 共识层 STF，根据在纪元中验证者的表现来更新状态，涉及奖励和惩罚。此过程重度依赖 SHA256 哈希函数，极大地提高了基于 zk 的系统的成本。这为将以太坊的共识机制与 zk 技术相一致造成了重大障碍。

当前共识层中使用的 ECADD、配对和 SHA256 操作在以太坊实现可验证性目标的过程中发挥了关键作用。但它们的 zk 不友好性为实现这些目标带来了重大挑战。ECADD 操作由于验证者投票的高密度创建了高昂的负担，而配对操作尽管数量较少，却在 zk 证明的情况下证明的成本数千倍。这些问题凸显了需要全面转变，以使以太坊现有基础设施与零知识技术相一致。

解决方案 “Beam Chain”：重新构思以太坊的共识层

2024 年 11 月 12 日，在 Devcon 的演讲中，Justin Drake 提出了一个名为 “Beam Chain” 的提案，旨在从根本上、全面地转变以太坊的共识层。Beacon Chain 在以太坊网络中已近五年。然而，在此期间，Beacon Chain 并未经历重大结构变化。与此对比，技术进步迅速发展，远远超过 Beacon Chain 的静态本质。

在他的演讲中，Justin Drake 强调，以太坊在过去五年里在 MEV 理解、SNARK 技术突破 和 技术错误的反思意识 等关键领域学习到了显著的教训。这些新学习所告知的设计被分为三个主要支柱： 区块生产、质押 和 密码学。下面的视觉总结了这些设计和提案的路线图：

• 绿色和灰色框 代表 渐进式发展，可以每年逐一实施。这些 types 的改进，如同之前的升级，可以分步集成，而不干扰以太坊现有架构。
• 红色框 则标志着 高协同、大规模 和 基础性变化，必须统一实施。根据 Drake 的说法，这些变化旨在以一次重大飞跃提升以太坊的能力和可验证性。

在本节中，我们详细研究了 The Verge 的 共识、状态 和 执行 步骤，而这个过程突出的问题之一是以太坊 Beacon Chain 中对 SHA256 哈希函数 的使用。虽然 SHA256在确保网络安全和处理交易方面的重要作用，但其缺乏 zk 友好性对实现以太坊的可验证性目标构成了重大障碍。其高计算成本和与 zk 技术的不兼容性，使其成为以太坊未来发展的一个关键问题。

Justin Drake 在他的 Devcon 演讲中提出了一项设想，计划用 zk 友好的哈希函数例如 Poseidon 替代 Beacon Chain 中的 SHA256。这一提案旨在使以太坊的共识层现代化，提高其可验证性、效率，并与 zk proof 技术对齐。

在这种背景下，我们看到以太坊不仅面临与 zk 不友好的哈希函数的挑战，还需重新评估其共识层中所使用的数字签名，以确保长期安全性。随着量子计算的发展，目前使用的数字签名算法 ECDSA 将面临重大威胁。正如 NIST 发布的指南中所述，ECDSA 的 112 位安全水平变种将于 2030 年停用，2035 年全面禁止。这使得以太坊和类似网络在未来朝着更具抗议的替代品转型的必要性变得十分紧迫，如 量子安全签名。

此时，基于哈希的签名 显现出作为量子抗性解决方案的潜力，有可能在支持网络的安全性和可验证性目标中扮演关键角色。处理这一需求也消除了将 Beacon Chain 变得可验证的第二大障碍： BLS 签名。以太坊确保量子安全所能采取的重要步骤之一是采纳后量子解决方案，像 基于哈希的网站签名 和 基于哈希的 SNARKs。

如 Justin Drake 在 Devcon 演讲中所强调的，哈希函数本身因依赖反向映像抵抗力而对量子计算机具有内在抗性，使其成为现代密码学的基本构建块之一。这一属性确保即便是量子计算机也无法有效逆向工程出某一哈希的原始输入，从而维持其安全性。基于哈希的签名方案允许验证者和见证者完全依赖于哈希函数生成签名，确保后量子安全的同时也在整个网络中提供更高水平的可验证性——尤其是在使用 SNARK 友好的哈希函数时。这种方法不仅提高了网络的安全性，还增强了以太坊长期安全基础设施的稳定性和适应性。

该系统依赖于将 基于哈希的签名 和 基于哈希的 SNARKs（类似 STARK 的证明）结合在一起，创建 可聚合签名方案。可聚合签名将数千个签名压缩成一个结构，将大小缩减到仅仅几百千字节的证明。这一压缩显著减少了网络的数据负担，同时大幅度加快了验证过程。例如，为以太坊的一个单时隙产生的数千个验证者签名可以通过一个聚合签名表示，从而节省存储空间和计算能力。

然而，该方案的最显著特性是它的 无限递归聚合。即，一个签名组可以在另一个签名组的基础上进一步组合，这个过程可以在链上继续进行。基于这一机制，并考虑未来技术的进步，可以合理地说，这开启了用 BLS 目前无法实现的可能性。

最后的想法与结论

以太坊实现可验证性的道路代表了区块链技术的根本转变。The Verge 的倡议通过 Verkle Trees 进行状态验证和 STARK 证明进行可扩展性转换，解决了核心的低效问题。

最雄心勃勃的提案之一是 Beam Chain，这是对以太坊共识层的全面重新设计。通过克服 Beacon Chain 的局限并纳入 zk 友好的替代品，这一方法旨在提升以太坊的可扩展性，同时保持其 去中心化 和 可接入性 的核心原则。然而，过渡也凸显了以太坊在平衡计算需求与维护无许可证且包容性网络目标方面面临的挑战。

随着 NIST 计划到 2035 年逐步淘汰当前的椭圆曲线密码学，以太坊必须采用诸如基于哈希签名和 Poseidon 之类的量子抗性解决方案。这些解决方案本身也会存在效率的权衡。

以太坊路线图中 STARKs 的使用进一步强调了可扩展性和可验证性。尽管它们在提供透明和量子抗性的证明方面表现优异，但其集成引入了与 prover 端计算成本 和 小规模数据效率 相关的挑战。必须解决这些障碍，才能完全实现以太坊无状态性和高效块验证的愿景，确保网络在需求日益增加的情况下保持强大。

尽管有这些进步，主要的挑战依然存在。以太坊必须导航诸如 zk 友好性、共识可扩展性以及集成 量子抗性密码学 的复杂性问题。此外，现有基础设施的向后兼容性亦构成实际障碍，这需要仔细的工程解决方案，以防止对开发人员和用户造成干扰。

以太坊的独特之处不仅在于其技术创新，还在于其 迭代方法 解决区块链中一些最难的问题。未来的改进——无论是通过 Beam Chain、Verkle Trees 还是 STARK 证明 ——依赖于开发者、研究者和更广泛社区的合作努力。这些进展并非旨在实现一夜之间的完美，而是为了创建一个 透明、去中心化 和 可验证 的互联网基础。

以太坊的演变突显了它在塑造 Web3 时代的关键角色。通过以切实可行的解决方案应对当今面对的挑战，以太坊向实现 可验证性、抗量子性 和 可扩展性 的未来迈进了一步，使其成为常态，而非例外。

• 原文链接： research.2077.xyz/the-ve...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～