以太坊协议的未来发展（第四部分）：The Verge

原文标题：《Possible futures of the Ethereum protocol, part 4: The Verge》

撰文：Vitalik Buterin

编译：Tia，Techub News

区块链最强大的功能之一是允许任何人都可以在计算机上运行节点并验证该链是否正确。即使 95% 的节点都同意更改规则并开始根据新规则生成区块，运行全节点的每个诚实个体都有会拒绝接受该链。不属于此类阴谋集团的权益持有者会自动汇聚在一起并继续构建一条遵循旧规则的链，并且完全验证的用户将遵循该链。

这是区块链和中心化系统之间的一个关键区别。然而，如果要保持这一特性，运行一个全节点需要足够简单，这样才能确保大多数人有机会运行节点。这既适用于质押者（如果质押者没有验证链，他们实际上并没有为执行协议规则做出贡献），也适用于普通用户。如今，在笔记本电脑上运行节点已成为可能，真正做到还是很困难。The Verge 希望改变这一点，让链的完整验证成本变得更低，以至于每个手机钱包、浏览器钱包，甚至智能手表都可以成为验证节点。

The Verge，2023 年路线图

最初，「Verge」指的是将以太坊状态存储移至 Verkle tree– Verkle tree 是一种更紧凑证明的树形结构，可实现以太坊区块的无状态验证。节点可以在硬盘上不拥有任何以太坊状态（账户余额、合约代码、存储……）的情况下验证以太坊区块，但需要花费几百千字节的证明数据和几百毫秒的额外时间来验证证明。而如今 Verge 愿景已经变得更为宏大，Verge 希望实现以太坊链的最大资源效率验证，其中不仅包括无状态验证技术，还包括使用 SNARK 验证所有以太坊执行。

除了需要长期关注对整个链进行的 SNARK 验证之外，还需要考虑另一个问题，即Verkle tree 是否是最好的技术。Verkle tree 容易受到量子计算机的攻击，因此如果我们用 Verkle tree 替换当前的KECCAKMerkle Patricia 树，我们以后将不得不再次替换树。Merkle 树的自然替代方案是直接使用二叉树中 Merkle 分支的STARK。从历史上看，由于开销和技术复杂性，这被认为是不可行的。然而，最近我们看到 Starkware 在笔记本电脑上使用圆形 STARK每秒证明 170 万个 Poseidon 哈希值，而且由于GKR等技术，从中可以感觉到，更「传统」哈希值的证明时间也在迅速改善。

在过去的一年里，Verge 正变得更加开放，并且展现出了丰富的可能性。

The Verge：关键目标

• 无状态客户端：完全验证客户端和质押节点不需要超过几 GB 的存储空间

• 未来，能够实现在智能手表进行链的验证（共识和执行）。即只要下载一些数据，验证 SNARK，就可以完成。

无状态验证：Verkle 或 STARK

我们要解决什么问题？

如今，以太坊客户端需要存储数百 GB 的状态数据才能验证区块，而且这一数量每年都在增加。原始状态数据每年增加约 30 GB，各个客户端必须在其上存储一些额外数据才能有效地更新 trie。

这减少了可以运行完全验证的以太坊节点的用户数量：尽管只要有足够大的硬盘就可以随时存储多年的所有以太坊状态甚至历史记录，但人们默认购买的计算机往往只有几百 GB 的存储空间。状态大小也给首次设置节点的过程带来了很大的阻力：节点需要下载整个状态，这可能需要数小时或数天的时间。这会产生各种连锁反应。例如，它使质押者升级其质押设置变得更加困难。从技术上讲，可以在不停机的情况下做到这一点 – 启动一个新客户端，等待它同步，然后关闭旧客户端并传输密钥 – 但在实践中这一技术很复杂。

无状态验证是什么以及它是如何运行的？

无状态验证是一种允许节点在不掌握完整状态的情况下验证区块的技术。相反，每个区块都带有一个见证，其中包括 (i)区块将访问的状态中特定位置的值（例如代码、余额、存储），以及 (ii)这些值正确的加密证明。

实际上，实现无状态验证需要更改以太坊状态树结构。这是因为当前的 Merkle Patricia 树对于实现任何加密证明方案都极其不友好，尤其是在最坏的情况下。对于「原始」Merkle 分支以及将 Merkle 分支「包装」在 STARK 中的可能性都是如此。关键困难源于 MPT 的两个弱点：

1. 它是十六叉树（即每个节点有 16 个子节点）。这意味着平均而言，大小为 N 的树中的证明有32 * (16 - 1) * log16(N) = 120 * log2(N)字节，或者在 2 (32)项树中大约有 3840 字节。使用二叉树，您只需要32 * (2 - 1) * log2(N) = 32 * log2(N)字节，或者大约 1024 字节。

2. 代码未经过默克尔化。这意味着证明任何账户代码的访问都需要提供整个代码，最多 24000 字节。

我们可以计算的最坏情况如下：

30,000,000 gas / 2,400 ("cold" account read cost) * (5 * 480 + 24,000) = 330,000,000字节

分支成本略有下降（5 * 480而不是8 * 480），因为当分支数量较多时，分支的顶部会重复。但即便如此，这也意味着在一个 slot 内下载的数据量完全不切实际。如果我们尝试将其包装在 STARK 中，我们会遇到两个问题：（i）KECCAK 相对不利于 STARK，（ii）330 MB 的数据意味着我们必须证明对 KECCAK 轮函数的 500 万次调用，这在除最强大的消费级硬件之外的所有硬件上都太多了，即使我们可以让 STARK 证明的 KECCAK 更加高效。

如果我们只是用二叉树替换十六叉树，并且我们另外对代码进行默克尔化，那么最坏的情况大约是 14 个字节（14 是 ~2 (14 个)30,000,000 / 2,400 * 32 * (32 - 14 + 8) = 10,400,000分支的冗余位的减法，8 是块中叶子节点的证明长度）。请注意，这需要改变 gas 成本，以收取访问每个单独的代码块的费用；EIP-4762就是这样做的。10.4 MB 要好得多，但对于许多节点来说，在一个 slot 内下载的数据仍然太多。所以我们需要引入一些更强大的技术。为此，有两种领先的解决方案：Verkle tree和STARKed 二叉哈希树。

Verkle trees

Verkle tree 使用基于椭圆曲线的向量承诺来做出更短的证明。关键在于，无论树的宽度是多少，与每个父子关系相对应的证明部分只有 32 个字节。树宽度的唯一限制是，如果树太宽，证明的计算效率就会降低。以太坊提出的实现宽度为 256。

因此，证明中单个分支的大小为32 * log256(N) = 4 * log2(N)字节。因此，理论上的最大证明大小大约为30,000,000 / 2,400 * 32 * (32 - 14 + 8) / 8 = 1,300,000字节（由于状态块分布不均匀，实际计算结果略有不同，但作为初步近似值，这没问题）。

另外需要注意的是，在上述所有示例中，这种「最坏情况」并不完全是最糟糕的情况：更糟糕的情况是攻击者故意「挖掘」两个地址，使树中有一个较长的公共前缀，并从其中一个地址读取，这可以将最坏情况分支长度再延长约 2 倍。但即使有了这个警告，Verkle tree 也能让我们获得约 2.6 MB 的最坏情况证明，这与当今最坏情况的 calldata 大致相当。

我们还利用这个警告来做另一件事：我们让访问「相邻」存储变得非常便宜：要么是同一合约的许多代码块，要么是相邻的存储槽。EIP-4762提供了相邻的定义，并且相邻访问仅收取 200 gas。对于相邻访问，最坏情况下的证明大小变为30,000,000 / 200 * 32 = 4,800,800字节，这仍然大致在容差范围内。如果我们希望出于安全考虑降低此值，我们可以稍微增加相邻访问成本。

STARK 型二叉哈希树

这里的技术非常不言自明：你创建一个二叉树，取出证明区块中值所需的最大 10.4 MB 证明，并用该证明的 STARK 替换该证明。这样，证明本身就只包含要证明的数据，加上实际 STARK 的约 100-300 kB 固定开销。

这里的主要挑战是验证时间。我们可以进行与上述基本相同的计算，只是我们计算哈希值而不是字节数。10.4 MB 的区块意味着 330,000 个哈希值。如果我们加上攻击者「挖掘」树中具有较长公共前缀的地址的可能性，那么真正的最坏情况就是大约 660,000 个哈希值。因此，如果我们每秒可以验证约 200,000 个哈希值，那就没问题了。

这些数字已经在使用 Poseidon 哈希函数的消费级笔记本电脑上达到 ，该函数专为 STARK 友好性而设计。然而，Poseidon 相对不成熟，因此许多人还不相信它的安全性。因此，有两条现实的前进道路：

1. 快速对 Poseidon 进行大量安全分析，并熟悉如何在 L1 上部署它

2. 使用更「保守」的哈希函数，例如 SHA256 或 BLAKE

在撰写本文时，Starkware 的圆形 STARK 证明器在证明保守哈希函数的情况下，在消费级笔记本电脑上每秒只能证明约 10-30k 个哈希值。然而，STARK 技术正在迅速改进。即使在今天，基于 GKR 的技术也有望将其提高到约 100-200k 的范围。

除了验证区块之外的见证人的用例

除了验证区块之外，还有另外三个更高效的无状态验证关键用例：

• 内存池：当交易被广播时，p2p 网络中的节点需要在重新广播之前验证交易是否有效。目前，验证涉及验证签名，还涉及检查余额是否足够以及随机数是否正确。在未来（例如使用本机帐户抽象，如EIP-7701），这可能涉及运行一些 EVM 代码，这些代码会进行一些状态访问。如果节点是无状态的，则交易将需要附带证明状态对象的证明。

• 包含列表：这是一项拟议功能，允许（可能规模较小且不太复杂的）权益证明验证者强制下一个区块包含交易，而不管（可能规模较大且比较复杂的）区块构建者的意愿如何。这将降低强大参与者通过延迟交易来操纵区块链的能力。但是，这要求验证者有办法验证包含列表中交易的有效性。

• 轻客户端：如果我们希望用户通过钱包（例如 Metamask、Rainbow、Rabby……）访问区块链而不信任中心化参与者，他们需要运行轻客户端（例如Helios）。核心 Helios 模块为用户提供经过验证的状态根。但是，为了获得完全无需信任的体验，用户需要为他们进行的每个 RPC 调用提供证明（例如，对于eth_call 请求，用户需要提供调用期间访问的所有状态的证明）

所有这些用例都有一个共同点，那就是它们需要相当多的证明，但每个证明都很小。因此，STARK 证明实际上对它们来说没有意义；相反，直接使用 Merkle 分支是最现实的。Merkle 分支的另一个优点是它们是可更新的：给定一个状态对象 X 的证明，根植于区块 B，如果您收到一个带有其见证的子区块 B2，您可以更新该证明以使其根植于区块 B2。Verkle 证明本身也是可更新的。

与现有研究有哪些联系？

• Verkle树：https ://vitalik.eth.limo/general/2021/06/18/verkle.html

• John Kuszmaul 的原始 Verkle tree 论文：https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

• Starkware 证明数据：https://x.com/StarkWareLtd/status/1807776563188162562

• Poseidon2 论文：https://eprint.iacr.org/2023/323

• Ajtai（基于格硬度的替代快速哈希函数）：https://www.wisdom.weizmann.ac.il/~oded/COL/cfh.pdf

• Verkle.info：https://verkle.info/

还剩下什么要做？有哪些需要权衡？

剩下要做的主要工作是：

1. 对 EIP-4762（无国籍 gas 成本变化）后果的更多分析

2. 完成和测试过渡程序需要做更多工作，这是无国籍 EIP 复杂性的很大一部分

3. 对 Poseidon、Ajtai 和其他「STARK 友好型」哈希函数的更多安全性分析

4. 针对「保守」（或「传统」）哈希函数的超高效 STARK 协议的更多开发，例如基于Binius或GKR的想法。

我们很快就会有一个决策点，选择以下三个选项：（i）Verkle tree，（ii）STARK 友好哈希函数，以及（iii）保守哈希函数。它们的属性可以粗略地总结在下表中：

除了这些「总体数字」之外，还有其他一些重要考虑因素：

• 如今，Verkle tree 代码已经相当成熟。使用除 Verkle 之外的任何代码实际上都会延迟部署，很可能是一次硬分叉。这没关系，特别是如果我们无论如何都需要额外的时间来进行哈希函数分析或证明器实现，并且如果我们有其他重要功能希望更早地包含在以太坊中。

• 使用哈希更新状态根比使用 Verkle tree 更快。这意味着基于哈希的方法可以缩短全节点的同步时间。

• Verkle tree 具有有趣的见证更新属性– Verkle tree 见证是可更新的。此属性对于内存池、包含列表和其他用例非常有用，并且还可能有助于提高实现效率：如果状态对象已更新，您甚至可以在不读取最后一级的情况下更新倒数第二级的见证。

• Verkle tree 更难通过 SNARK 证明。如果我们想将证明大小一直减少到几千字节，Verkle 证明会带来一些困难。这是因为 Verkle 证明的验证引入了大量 256 位操作，这要求证明系统要么有大量开销，要么本身具有自定义内部构造，其中 256 位部分用于 Verkle 证明。这对无状态性本身来说不是问题，但会在以后带来更多困难。

如果我们希望以量子安全且合理高效的方式实现 Verkle 见证可更新性，另一种可能的途径是基于 lattice 的 Merkle 树。

如果证明系统在最坏情况下效率不够高，我们可以使用另一个「出其不意」的办法来弥补这种不足，那就是多维gas：对（i）调用数据、（ii）计算、（iii）状态访问以及可能的其他不同资源设置单独的 gas 限制。多维 gas 增加了复杂性，但作为交换，它更严格地限制了平均情况和最坏情况之间的比率。使用多维 gas ，理论上需要证明的最大分支数可能会从30,000,000 / 2400 = 12,5003000 减少到 3000。这样的话，即使是如今的 BLAKE3 也足够了，无需对 proof 进行进一步改进。

另一个「出乎意料」的提议是将状态根计算延迟到区块之后的slot。这将给我们整整 12 秒的时间来计算状态根，这意味着即使在最极端的情况下，也只有 ~60,000 哈希/秒的证明时间就足够了，这再次使我们处于 BLAKE3 的范围内，这才勉强够用。

这种方法的缺点是它会增加轻客户端延迟，不过这种技术还有更巧妙的版本，可以将延迟减少到证明生成延迟。例如，只要任何节点生成证明，就可以在网络上广播，而不必等待下一个区块。

它如何与路线图的其他部分互动？

解决无状态问题极大地提高了 solo 质押的便利性。如果能够降低 solo 质押最低余额的技术（例如 Orbit SSF 或小队质押等应用层策略）可用，这将变得更有价值。

如果同时引入 EOF，多维 gas 会变得更加容易。这是因为执行多维 gas 的一个关键复杂性在于处理不传递父调用的全部 gas 的子调用，而 EOF 只需使此类子调用非法即可使这个问题变得微不足道（并且本机帐户抽象将为当前部分 gas 子调用的主要用例提供协议内替代方案）。

另一个重要的协同作用是无状态验证和历史过期之间的协同作用。如今，客户端必须存储近 1TB 的历史数据；这些数据比状态大几倍。即使客户端是无状态的，除非我们能够减轻客户端存储历史的责任，否则几乎无存储客户端的梦想也无法实现。这方面的第一步是EIP-4444，它还意味着将历史数据存储在 torrent 或 Portal 网络中。

EVM 执行的有效性证明

我们要解决什么问题？

以太坊区块验证的长期目标很明确：您应该能够通过以下方式验证以太坊区块：（i）下载区块，或者甚至仅下载区块的一小部分（使用数据可用性采样）；（ii）验证小型 proof。这将是一项资源消耗极低的操作，可以在移动客户端、浏览器钱包内甚至（没有数据可用性部分）在另一条链中完成。

要达到这一点，需要有 (i)共识层（即权益证明）和 (ii)执行层（即 EVM）的 SNARK 或 STARK 证明。前者本身就是一个挑战，应该在进一步改进共识层（例如，single slot 最终性）的过程中加以解决。后者需要 EVM 执行的证明。

EVM 执行有效性证明是什么以及它是如何工作的？

在以太坊规范中，EVM 被定义为状态转换函数：你有一些预状态S，一个区块B，并且你正在计算一个后状态S' = STF(S, B)。如果用户正在使用轻客户端，他们没有S和S'甚至B全部；相反，他们有一个前状态根R，一个后状态根R'和一个区块哈希H。需要证明的完整陈述大致如下：

• 公共输入：前状态根R、后状态根R'、区块哈希H

• 私有输入：区块主体B，区块访问的状态中的对象Q，执行区块之后的相同对象Q'，状态证明（例如 Merkle 分支）P

• 声明 1：是包含以下部分状态的P有效证明 ：QR

• 声明 2：如果在 上运行 STFQ，则 (i) 执行仅访问内部的对象Q，(ii) 该块有效，并且 (iii) 结果是Q'

• 声明 3Q'：如果你使用和中的信息重新计算新的状态根，P你将得到R'

如果存在这种情况，您可以拥有一个完全验证以太坊 EVM 执行情况的轻量级客户端。这已经使客户端的资源占用非常低。要获得真正完全验证以太坊客户端，您还需要对共识端进行同样的操作。

EVM 计算的有效性证明实现已经存在，并被 layer2 大量使用。然而，要使 EVM 有效性证明适用于 L1，还有很多工作要做。

与现有研究有哪些联系？

• EF PSE ZK-EVM（现已停用，因为有更好的选择）：https://github.com/privacy-scaling-explorations/zkevm-circuits

• Zeth 的工作原理是将 EVM 编译到 RISC-0 ZK-VM 中：https://github.com/risc0/zeth

• ZK-EVM 形式化验证项目：https://verified-zkevm.org/

还剩下什么要做？有哪些需要权衡？

目前，EVM 的有效性证明在两个方面存在不足：安全性和证明时间。

安全的有效性证明涉及确保 SNARK 确实验证了 EVM 计算，并且其中没有错误。提高安全性的两种主要技术是multi-provers和形式验证。multi-provers 意味着拥有多个独立编写的有效性证明实现，就像有多个客户端一样，并且如果这些实现中足够大的子集证明了某个块，则客户端会接受该块。形式验证涉及使用常用于证明数学定理的工具（例如Lean4）来证明有效性证明仅接受正确执行底层 EVM 规范的输入（例如，用 python 编写的EVMK 语义或以太坊执行层规范 EELS）。

足够快的证明时间意味着任何以太坊区块都可以在不到 4 秒的时间内完成证明。今天，我们距离这个目标还很远，尽管我们比两年前想象的要近得多。为了实现这一目标，我们需要在三个方向上取得进展：

• 并行化– 目前最快的 EVM 证明器可以在约 15 秒内对一个普通的以太坊区块完成证明。它通过在数百个 GPU 之间并行化，然后在最后将它们的工作聚合在一起来实现这一点。从理论上讲，我们确切地知道如何制作一个可以在 O(log(N)) 时间内证明计算的 EVM 证明器：让一个 GPU 执行每个步骤，然后创建一个「聚合树」：

• 实现这一点存在挑战。即使在最坏的情况下，即一笔非常大的交易占据了整个区块，计算的拆分也不能是按交易进行的；它必须是按操作码进行的（EVM 或像 RISC-V 这样的底层 VM）。一个关键的实现挑战使得这一点并不完全简单，那就是需要确保 VM 的「内存」在证明的不同部分之间是一致的。然而，如果我们可以做出这种递归证明，那么我们知道，至少证明延迟问题已经得到解决，即使没有对任何其他轴进行任何改进。

• 证明系统优化——Orion、Binius、GKR等新的证明系统可能会再次大幅减少通用计算的证明时间。

• EVM gas 成本其他变化– EVM 中的许多内容可以进行优化，以更加方便证明者，尤其是在最坏的情况下。如果攻击者可以构建一个区块，让证明者的时间阻塞十分钟，那么能够在 4 秒内证明一个普通的以太坊区块是不够的。所需的 EVM 更改大致可分为两类：

  • gas 成本变化– 如果一个操作需要很长时间才能证明，那么即使计算速度相对较快，其 gas 成本也应该很高。EIP-7667是针对这方面最严重的违规者提出的一项 EIP：它显著增加了（传统）哈希函数的 gas 成本，这些哈希函数以相对便宜的操作码和预编译的形式公开。为了补偿这些 gas 成本的增加，我们可以降低证明成本相对较低的 EVM 操作码的 gas 成本，从而保持平均吞吐量不变。

  • 数据结构替换– 除了用更适合 STARK 的替代方案替换状态树之外，我们还需要替换交易列表、收据树和其他证明成本高昂的结构。Etan Kissling 的 EIP 将交易和收据结构移至 SSZ（[1][2][3]）是朝这个方向迈出的一步。

除此之外，上一节中提到的两只「帽子里变出来的兔子」（多维 gas和延迟状态根）也可以在这里提供帮助。然而，值得注意的是，与无状态验证不同，使用帽子里变出来的兔子意味着我们有足够的技术来完成我们今天需要做的事情，即使使用这些技术，完整的 ZK-EVM 验证也会需要更多的工作（它只需要更少的工作）。

上面没有提到的一件事是证明器硬件：使用 GPU、FPGA 和 ASIC 来更快地生成证明。FabricCryptography、Cysic和Accseal是三家正在推动这一进程的公司。这对于 layer2 来说将非常有价值，但它不太可能成为 layer1 的决定性考虑因素，因为人们强烈希望保持 layer1 的高度去中心化，这意味着证明生成必须在相当大一部分以太坊用户的能力范围内，而不应受到单个公司硬件的限制。 layer2 可以做出更积极的权衡。

以下每个领域仍有许多工作要做：

• 并行化证明需要证明系统，其中证明的不同部分可以「共享内存」（例如查找表）。我们知道实现这一点的技术，但它们需要实现。

• 我们需要进行更多分析来找出理想的 gas 成本变化，以最大限度地减少最坏情况的验证时间。

• 我们需要在证明系统方面做更多的工作

这里可能的权衡包括：

• 安全性与证明时间：可以通过选择更积极的哈希函数、更复杂或更积极的安全假设的证明系统或其他设计选择来缩短证明时间。

• 去中心化与证明时间：社区需要就其所针对的证明硬件的「规格」达成一致。要求证明者是大型实体可以吗？我们是否希望高端消费笔记本电脑能够在 4 秒内证明以太坊区块？介于两者之间？

• 破坏向后兼容性的程度：其他领域的不足可以通过进行更激进的 gas 成本变更来弥补，但这更有可能不成比例地增加某些应用程序的成本，并迫使开发人员重写和重新部署代码以保持经济可行性。同样，「帽子里的兔子」也有其自身的复杂性和缺点。

它如何与路线图的其他部分互动？

实现 layer1 的 EVM 有效性证明所需的核心技术与其他两个领域高度共享：

• layer2 的有效性证明（即「ZK rollups」）

• 「STARK 二进制哈希证明」 无国籍方法

在 layer1 成功实施有效性证明可实现极致轻松的solo 质押：即使是最弱的计算机（包括手机或智能手表）也能够进行质押。这进一步增加了解决solo 质押的其他限制（例如最低 32 ETH）的价值。

此外，L1 的 EVM 有效性证明可以显著提高 L1 的 gas 限制。

共识的有效性证明

我们要解决什么问题？

如果我们希望使用 SNARK 完全验证以太坊区块，那么 EVM 执行并不是我们需要证明的唯一部分。我们还需要证明共识：系统中处理存款、取款、签名、验证者余额更新以及以太坊权益证明部分的其他元素的部分。

该共识比 EVM 简单得多，但它面临的挑战是，我们没有 layer2 EVM rollup，这也是大部分工作无论如何都要完成的原因。因此，任何证明以太坊共识的实现都需要「从头开始」，尽管证明系统本身是可以在此基础上构建的共享工作。

它是什么以及它是如何工作的？

信标链被定义为一个状态转换函数，就像 EVM 一样。状态转换函数由三件事主导：

• ECADD（用于验证 BLS 签名）

• 配对（用于验证 BLS 签名）

• SHA256 哈希（用于读取和更新状态）

在每个区块中，我们需要为每个验证者证明 1-16 个 BLS12-381ECADD（可能不止一个，因为签名可以包含在多个聚合中）。这可以通过子集预计算技术来补偿，因此总的来说，我们可以说每个验证者有一个 BLS12-381 ECADD。今天，每个 slot 中有大约 30,000 个验证者签名。在未来，随着单 slot 的终结，这可能会朝任何一个方向改变（请参阅此处的说明）：如果我们采取「蛮力」路线，这可能会增加到每个 slot 100 万个验证者。同时，使用 Orbit SSF，它将保持在 32,768，甚至减少到 8,192。

BLS 聚合的工作原理。验证聚合签名仅需要每个参与者进行一次 ECADD，而不是 ECMUL。但 30,000 次 ECADD 仍有大量工作需要证明。

对于配对，目前每个 slot 最多有 128 个证明，这意味着需要验证 128 个配对。随着EIP-7549和进一步的变更，这个数字可能会减少到每个 slot 16 个。配对数量很少，但成本极高：每个配对的运行时间（或证明时间）是 ECADD 的数千倍。

证明 BLS12-381 操作的一个主要挑战是，没有方便的曲线，其曲线阶数等于 BLS12-381 字段大小，这会给任何证明系统增加相当大的开销。另一方面，为以太坊提出的 Verkle tree 是用Bandersnatch 曲线构建的，这使得 BLS12-381 本身成为 SNARK 系统中用来证明 Verkle 分支的自然曲线。一个相当简单的实现可以证明每秒约 100 个 G1 加法；几乎肯定需要像 GKR 这样的巧妙技术来使证明足够快。

对于SHA256 哈希值，目前最糟糕的情况是 epoch 转换块，其中整个验证器短余额树和大量验证器余额都会更新。验证器短余额树每个验证器占一个字节，因此大约有 1 MB 的数据被重新哈希。这相当于 32,768 次 SHA256 调用。如果一千个验证器的余额高于或低于需要更新验证器记录中的有效余额的阈值，这相当于一千个 Merkle 分支，因此可能还需要一万个哈希值。改组机制需要每个验证器 90 位（因此需要 11 MB 数据），但这可以在一个 epoch 的过程中随时计算。在single slot 最终性的情况下，这些数字可能会根据细节再次增加或减少。改组变得没有必要，尽管 Orbit 可能会在一定程度上重新需要改组。

另一个挑战是需要读取所有验证器状态（包括公钥）才能验证区块。仅读取公钥就需要 4800 万字节（100 万个验证器，加上 Merkle 分支）。这需要每个时期数百万个哈希值。如果我们今天必须证明权益证明的验证，那么一种现实的方法将是某种形式的增量可验证计算：在证明系统内存储一个单独的数据结构，该结构针对高效查找进行了优化，并证明对该结构的更新。

总而言之，有很多挑战。

要最有效地解决这些挑战，可能需要对信标链进行深度重新设计，这可能与切换到 single slot 最终性同时发生。此重新设计的特点可能包括：

• 哈希函数更改：今天，使用「完整」SHA256 哈希函数，因此由于填充，每次调用都对应两个底层压缩函数调用。至少，通过切换到 SHA256 压缩函数，我们可以获得 2 倍的收益。如果我们切换到 Poseidon，我们可以获得潜在的约 100 倍的收益，这可以完全解决我们所有的问题（至少对于哈希而言）：以每秒 170 万个哈希（54 MB）的速度，即使一百万个验证器记录也可以在几秒钟内「读入」证明中。

• 如果是 Orbit，则直接存储打乱的验证者记录：如果您选择一定数量的验证者（例如 8,192 或 32,768）作为给定 slot 的委员会，则将它们直接放入彼此相邻的状态中，这样就需要最少量的哈希来将所有验证者公钥读入证明。这还将允许高效地完成所有余额更新。

• 签名聚合：任何高性能签名聚合方案实际上都会涉及某种递归证明，其中签名子集的中间证明将由网络中的各个节点进行。这自然会将证明负载分摊到网络中的许多节点上，从而使「最终证明者」的工作量大大减少。

• 其他签名方案：对于 Lamport+Merkle 签名，我们需要 256 + 32 个哈希值来验证签名；乘以 32,768 个签名者可得到 9,437,184 个哈希值。对签名方案的优化可以通过一个小的常数因子进一步改善这一点。如果我们使用 Poseidon，这在单个 slot 内即可证明。但实际上，使用递归聚合方案可以更快地完成这一过程。

与现有研究有哪些联系？

• 简洁的以太坊共识证明（仅同步委员会）：https ://github.com/succinctlabs/eth-proof-of-consensus

• 简洁，SP1 内的 Helios：https://github.com/succinctlabs/sp1-helios

• 简洁的 BLS12-381 预编译：https://blog.succinct.xyz/succinctshipsprecompiles/

• 基于 Halo2 的 BLS 聚合签名验证：https://ethresear.ch/t/zkpos-with-halo2-pairing-for-verifying-aggregate-bls-signatures/14671

还剩下什么要做？有哪些需要权衡？

实际上，我们需要数年时间才能证明以太坊共识的有效性。这大致与我们需要实现 single slot 最终性、Orbit、签名算法更改以及潜在安全分析的时间相同，这些安全分析需要足够自信地使用像 Poseidon 这样的「激进」哈希函数。因此，解决这些其他问题是最有意义的，并且在进行这些工作时要牢记 STARK 友好性。

主要的权衡可能在于操作顺序，即在改革以太坊共识层的更渐进方法和更激进的「一次进行许多更改」方法之间。对于 EVM，渐进方法是有意义的，因为它最大限度地减少了对向后兼容性的破坏。对于共识层，向后兼容性问题较小，并且更「全面」地重新思考信标链构建的各种细节是有好处的，从而最大限度地优化 SNARK 友好性。

它如何与路线图的其他部分互动？

在以太坊权益证明共识的长期重新设计中，STARK 友好性需要成为主要关注点，最值得注意的是 single slot 最终性、Orbit、签名方案的更改以及签名聚合。