Vitalik 新文：以太坊协议可能的未来 The Verge

实际上，我们需要数年时间才能获得以太坊共识的有效性证明。

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

撰文：Vitalik Buterin

编译：Mensh，ChainCatcher

 

特别感谢 Justin Drake、Hsia-wei Wanp、Guillaume Ballet、Icinacio、Rosh Rudolf、Lev Soukhanoy Ryan Sean Adams 和 Uma Roy 的反馈和审阅。

区块链最强大的功能之一就是任何人都可以在自己的电脑上运行一个节点，并验证区块链的正确性。即使 9596 个运行链共识（PoW、PoS）的节点都立即同意更改规则，并开始根据新规则生产区块，每个运行完全验证节点的人都会拒绝接受链。不属于这种阴谋集团的造币者会自动汇聚到一条继续遵循旧规则的链上，并继续构建这条链，而完全通过验证的用户将遵循这条链。

这是区块链与中心化系统的关键区别。然而，要使这一特性成立，运行一个完全验证的节点需要对足够多的人来说确实可行。这既适用于造势者（因为如果造势者不验证链，他们就没有为执行协议规则做出贡献），也适用于普通用户。如今，在消费类笔记本电脑（包括写这篇文章时使用的笔记本电脑）上运行节点是可能的，但要做到这一点却很困难。The Verge 就是要改变这种状况，让完全验证链的计算成本变得低廉，让每个手机钱包、浏览器钱包甚至智能手表都会默认进行验证。

The Verge 2023 路线图

最初，「Verge」指的是将以太坊状态存储转移到 Verkle 树——一种允许更紧凑证明的树形结构，可实现以太坊区块的无状态验证。节点可以验证一个以太坊区块，而无需在其硬盘上存储任何以太坊状态（账户余额、合约代码、存储空间......），代价是花费几百 KB 的证明数据和几百毫秒的额外时间来验证一个证明。如今，Verge 代表了一个更大的愿景，专注于实现以太坊链的最大资源效率验证，其中不仅包括无状态验证技术，还包括使用 SNARK 验证所有以太坊执行。

除了对 SNARK 验证整条链的长期关注之外，另一个新问题与 Verkle 树是否是最佳技术有关。Verkle 树容易受到量子计算机的攻击，因此，如果我们将目前的 KECCAK Merkle Patricia 树中的 Verkle 树，我们以后还得再次替换树。Merkle 树的自替代方法是直接跳过使用 Merkle 分支的 STARK，将其放入二叉树。从历史上看，由于开销和技术复杂性，这种方法一直被认为是不可行的。不过最近，我们看到 Starkware 在一台笔记本电脑上使用 ckcle STARKs 每秒证明了 170 万个 Poseidon 哈希，而且由于 GKB 等技术的出现，更多「传统」哈希值的证明时间也在迅速缩短。因此，在过去的一年里，「Verge」变得更加开放，它有几种可能性。

The Verge：关键目标

• 无状态客户机：完全验证客户机和标记节点所需的存储空间不应超过几 GB。
• ( 长期）在智能手表上完全验证链（共识和执行）。下载一些数据，验证 SNARK，完成。

在本章中

• 无状态客户机：Verkle 还是 STARKs
• EVM 执行的有效性证明
• 共识的有效性证明

无状态验证：Verkle 还是 STARKs

我们要解决什么问题？

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

这就减少了能够运行完全验证以太坊节点的用户数量：尽管足以存储所有以太坊状态甚至多年历史的大硬盘随处可见，但人们默认购买的电脑往往只有几百千兆字节的存储空间。状态大小也给首次建立节点的过程带来了巨大的摩擦：节点需要下载整个状态，这可能需要数小时或数天的时间。这会产生各种连锁反应。例如，它大大增加了节点制作者升级其节点设置的难度。从技术上讲，可以在不停机的情况下完成升级——启动一个新客户端，等待它同步，后关闭旧客户端并传输密钥——但在实际操作中，这在技术上非常复杂。

它如何工作？

无状态验证是一种允许节点在不掌握整个状态的情况下验证区块的技术。取而代之的是，每个区块都附带一个见证，其中包括：(i) 该区块将访问的状态中特定位置的值、代码、余额、存储； (ii) 证明这些值正确的加密证明。

实际上，实现无状态验证需要改变以太坊的状态树结构。这是因为当前的 Merkle Patricia 树对于实施任何加密证明方案都是极端不友好的，尤其是在最坏的情况下。无论是「原始」Merblk 分枝，还是「包装」成 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.代码未被 Merkle 化。这意味着要证明账户代码的任何访问权限，都需要提供整个代码，最多为 24000 字节。

 

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

30000000 gas / 2400 ( 冷账户阅读成本 ) * （5 * 488 + 24000) = 330000000 字节

分支成本略有降低（用 5*480 代替 8*480），因为当分支较多时，其顶端部分会重复出现。但即便如此，在一个时隙内要下载的数据量也是完全不现实的。如果我们尝试用 STARK 来封装它，就会遇到两个问题：(i) KECCAK 对 STARK 相对不友好；(ii) 330MB 的数据意味着我们必须证明对 KECCAK round 函数的 500 万次调用，这对于除了最强大的消费级硬件之外的所有硬件来说，都可能证明不了，即使我们能让 STARK 证明 KECCAK 的效率更高。

如果我们直接用二叉树代替十六进制树，并对代码进行额外的 Merkle 化处理，那么最坏的情况大致会变成 30000000/2400*32*(32-14+8) = 10400000 字节（14 是对 2^14 分支的冗余位进行的减法，而 8 则是进入代码块中叶的证明的长度）。需要注意的是，这需要改变 gas 成本，对访问每个单独的代码块收费；EIP-4762 就是这么做的。10.4 MB 的容量要好得多，但对于许多节点来说，在一个时隙内下载的数据还是太多了 。因此，我们需要引入更强大的技术。在这方面，有两种领先的解决方案：Verkle 树和 STARKed 二进制哈希树。

Verkle 树

Verkle 树使用基于椭圆曲线的矢量承诺来进行更短的证明。解锁的关键在于，无论树的宽度如何，每个父子关系对应的证明部分都只有 32 字节。证明树宽度的唯一限制是，如果证明树过宽 ，证明的计算效率就会降低。为以太坊提出的实现方案宽度为 256。

因此，证明中单个分支的大小变为 32 - 1og256(N) = 4* log2(N) 字节。因此，理论上的最大证明大小大致为 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 字节（由于状态块的分布不均匀，实际计算结果略有不同， 但作为第一近似值是可以的）。

另外需要注意的是，在上述所有示例中，这种「最坏情况」并不是最坏情况：更坏的情况是攻击者故意「挖掘」两个地址，使其在树中具有较长的共同前缀，并从其中一个地址读取数据，这可能会将最坏情况下的分支长度再延长 2 倍。但即使有这样的情况，Verkle 树的最坏证明长度为 2.6MB，与目前最坏情况下的校验数据基本吻合。

我们还利用这一注意事项做了另一件事：我们让访问「相邻」存储空间的成本变得非常低廉：要么是相同合同的许多代码块，要么是相邻的存储槽。EIP - 4762 提供了邻接的定义，对邻接访问只收取 200 gas 费。在相邻访问的情况下，最坏情况下的证明大小变为 30000000 / 200*32 - 4800800 字节，这仍大致在公差范围内。如果为了安全起见，我们希望减少这个值，可以稍微增加相邻访问的费用。

STARKed 二进制哈希树

这项技术的原理不言自明：你只需做一棵二叉树，获取最大 10.4 MB 的证明，证明块中的值，后用证明的 STARK 代替证明。这样，证明本身就只包含被证明的数据，再加上来自实际 STARK 的 100-300kB 固定开销。

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

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

1. 快速对 Poseidon 进行大量安全分析，并对其足够熟悉，以便在 L1 进行部署
2. 使用更「保守」的哈希函数，如 SHA256 或 BLAKE

如果要证明保守的哈希函数，Starkware 的 STARK 圈在撰写本文时只能在消费类笔记本电脑上每秒证明 10-30k 哈希值。不过，STARK 技术正在迅速改进。即使在今天，基于 GKR 的技术也显示出将这一速度提高到 100-2O0k 范围。

除验证区块外的见证使用案例

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

• 内存池：当交易被广播时，P2P 网络中的节点需要在重新广播之前验证交易是否有效。如今验证包括验证签名，还包括检查余额是否充足和前缀是否正确。在未来（例如，使用原生账户抽象，如 EIP-7701，这可能会涉及运行一些 EVM 代码，这些代码会进行一些状态访问。如果节点是无状态的，则交易需要附带证明状态对象的证明。
• 包含列表：这是一个提议的功能，允许（可能规模较小且不复杂的）权益证明验证者强制下一个区块包含交易，而不管（可能规模较大且复杂的）区块构建者的意愿。这将削弱有权势者通过延迟交易来操纵区块链的能力。不过，这需要验证者有办法验证包含列表中交易的有效性。
• 轻客户端：如果我们希望用户通过钱包访问链（如 Metamask、Rainbow、Rabby 等），要做到这一点，他们需要运行轻型客户端（如 Helios).Helios 核心模块为用户提供经过验证的状态根。而为了获得完全无信任的体验，用户需要为他们所做的每个 RPC 调用提供证明（例如，对于以太网调用请求（用户需要证明在调用过程中访问的所有状态）。

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

与现有研究有哪些联系：

• Verkle trees
• John Kuszmaul 关于 Verkle tree 的原始论文
• Starkware
• Poseidon2 paper
• Ajtai ( 基于晶格硬度的替代快速哈希函数 )
• Verkle.info

还能做些什么？

剩下的主要工作是

1.关于 EIP-4762 后果的更多分析（无状态 gas 成本变化）

2.完成和测试过渡程序的更多工作，这是任何无国籍环境实施方案复杂性的主要部分

3.对 Poseidon、Ajtai 和其他「STARK-friendly」哈希函数的更多安全分析

4.为「保守」（或「传统」）哈希进一步开发超高效 STARK 协议功能，例如基于 Binius 或 GKR 的观点。

此外，我们很快就会决定从以下三个选项中选择一个：(i) Verkle 树，(ii) STARK 友好哈希函数以及 (iii) 保守哈希函数。它们的特性可大致归纳在下表中：

除了这些「标题数字」，还有其他一些重要的考虑因素：

• 如今，Verkle 树代码已经相当成熟。除了 Verkle 之外，使用其他任何代码都会推迟部署，很可能会推迟一个硬分叉。这也没有关系，尤其是如果我们需要额外的时间来进行哈希函数分析或验证器实现，或者我们有其他重要的功能想要更早地纳入以太坊。
• 使用哈希值更新状态根比使用 Verkle 树更快。这意味着基于哈希值的方法可以降低全节点的同步时间。
• Verkle 树具有有趣的见证更新属性——Verkle 树见证是可更新的。这个属性对 mempool、包含列表和其他用例都很有用，而且还可能有助于提高实现效率：如果更新了状态对象，就可以更新倒数第二层的见证，而无需读取最后一层的内容。
• Verkle 树更难进行 SNARK 证明。如果我们想把证明大小一直减小到几千字节，Verkle 证明就会带来一些困难。这是因为 Verkle 证明的验证引入了大量 256 位操作，这就要求证明系统要么有大量开销，要么本身有一个定制的内部结构，其中包含 256 位的 Verkle 证明部分。这对无状态本身不是问题，但会带来更多困难。

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

如果在最坏的情况下，证明系统的效率不够高，那么我们还可以利用多维 gas 这意料之外的工具来弥补这种不足：为 (i) calldata；(ii) 计算；(iii) 状态访问以及可能的其他不同资源设定单独的 gas 限制。多维 gas 增加了复杂性，但作为交换，它更严格地限制了平均情况和最坏情况之间的比率。有了多维 gas，理论上需要证明的最大分支数可能会从 12500 减少到例如 3000。这将使 BLAKE3 即使在今天也（勉强）够用。

多维 gas 允许区块的资源限制更接近于底层硬件的资源限制

另一个意料之外的工具是将状态根计算延迟到区块之后的时隙。这样，我们就有整整 12 秒的时间来计算状态根，这意味着即使在最极端的情况下，每秒也只有 60000 哈希数的证明时间是足够的，这再次让我们认为 BLAKE3 只能勉强满足要求。

这种方法的缺点是会增加一个时隙的轻客户端延迟，不过也有更巧妙的技术可以将这种延迟减少到仅为证明生成延迟。例如，证明可以在任何节点生成后立即在网络上广播，而不 是等待下一个区块。

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

解决无状态问题大大提高了单人定点的难度。如果有技术能降低单人定点的最低平衡，如 Orbit SSF 或应用层策略，如小队定点，这将变得更可行。

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

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

EVM 执行的有效性证明

我们要解决什么问题？

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

要达到这一点，需要对（i）共识层（即股权证明）和（ii）执行层（即 EVM）进行 SNARK 或 STARK 证明。前者本身就是一个挑战，应该在进一步不断改进共识层的过程中加以解决（例如，针对单槽终局性）。后者需要 EVM 执行证明。

它是什么，如何运作？

从形式上看，在以太坊规范中，EVM 被定义为一个状态转换函数：你有一些前状态 S，一个区块 B，你正在计算一个后状态 S' = STF(S，B)。如果用户使用的是轻客户端，他们并不完整地拥有 S 和 S'，甚至 E；相反，他们拥有一个前状态根 R，一个后状态根 R'和一个区块哈希值 H。

• 公共输入：前状态根 R, 后状态根 R' , 块哈希 H
• 私人输入：程序块主体 B、程序块 Q 访问的状态中的对象、执行程序块 Q'后的相同对象、状态证明（如 Merkle 分支）P
• 主张 1：P 是一个有效的证明，证明 Q 包含 R 所代表的状态的某些部分
• 主张 2：如果在 Q 上运行 STF，(i) 执行过程只访问 Q 内部的对象，(ii) 数据块是有效的，(iii) 结果是 Q'
• 主张 3：如果利用 Q' 和 P 的信息重新计算新的状态根，就会得到 R'

如果存在这种情况，就可以拥有一个完全验证以太坊 EVM 执行的轻型客户端。这使得客户端的资源已经相当低。要实现真正的完全验证以太坊客户端，还需要在共识方面做同样的工作。

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

与现有研究有哪些联系？

• EFPSE ZK-EVM（由于存在更好的选择，现已停用）
• Zeth，其工作原理是将 EVM 编译到 RISC-0 ZK-VM 中
• ZK-EVM 形式化验证项目

还能做些什么？

如今，电子记账系统的有效性证明在两个方面存在不足：安全性和验证时间。

一个安全的有效性证明需要保证 SNARK 确实验证了 EVM 的计算，并且不存在漏洞。提高安全性的两种主要技术是多验证器和形式验证。多验证器指的是有多个独立编写的有效性证明实现，就像有多个客户端一样，如果一个区块被这些实现中的一个足够大的子集证明，客户端就会接受该区块。形式验证涉及使用通常用于证明数学定理的工具，如 Lean4，以证明有效性证明只接受正确执行底层 EVM 规范（例如 EVM K 语义或用 python 编写的以太坊执行层规范 (EELS)）。

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

• 并行化——目前最快的 EVM 校验器平均可在 15 秒内证明一个以太坊区块。它是通过在数百个 GPU 之间进行并行化，后在最后将它们的工作汇总在一起来实现这一点的。从理论上讲，我们完全知道如何制造一个能在 O(log(N)) 时间内证明计算的 EVM 验证器：让一个 GPU 完成每一步，后做一个「聚合树」：

实现这一点存在挑战。即使是在最坏的情况下，即一个非常大的事务占用了整个区块，计算的分割也不能按次进行，而必须按操作码（EVM 或 RISC-V 等底层虚拟机的操作码）进行。要确保虚拟机的「内存」在证明的不同部分之间保持一致，是实施过程中的一个关键挑战。不过，如果我们能实现这种递归证明，那么我们知道，即使在其他方面没有任何改进，至少证明者的延迟问题已经解决了。

• 证明系统优化 -- 新的证明系统，如 Orion、Binius、GRK 以及其他更多信息，很可能会导致又一次大大缩短了通用计算的验证时间。
• EVM gas 成本的其他变化——EVM 中的许多东西都可以优化，使其更有利于证明者，尤其是在最坏的情况下。如果攻击者可以构建一个阻塞证明者十分钟时间的区块，那么仅能在 4 秒内证明一个普通的以太坊区块是不够的。所需的 EVM 更改可大致分为以下几类：
• gas 成本的变化——如果一个操作需要很长时间才能证明，那么即使它的计算速度相对较快，也应该有很高的 gas 成本。EIP-7667 是为处理这方面最严重的问题而提出的一个 EIP：它大大增加了（传统）哈希函数的 gas 成本，因为这些函数的操作码和预编译相对便宜。为了弥补这些 gas 成本的增加，我们可以降低证明成本相对较低的 EVM 操作码的 gas 成本，从而保持平均吞吐量不变。
• 数据结构替换——除了用对 STARK 更友好的方法替换状态树外，我们还需要替换事务列表、收据树和其他证明成本高昂的结构。Etan Kissling 将事务和收据结构移至 SSZ 的 EIP 就是朝着这个方向迈出的一步。

除此之外，上一节提到的两个工具（多维 gas 和延迟状态根）也能在这方面提供帮助。不过，值得注意的是，与无状态验证不同的是，使用这两个工具意味着我们已经拥有了足够的技术来完成我们目前所需的工作，而即使使用了这些技术，完整的 ZK-EVM 验证也需要更多的工作——只是需要的工作更少而已。

上文没有提到的一点是证明器硬件：使用 GPU、FPGA 和 ASIC 更快地生成证明。Fabric Cryptography、Cysic 和 Accseal 是三家在这方面取得进展的公司。这对 L2 来说非常有价值，但不太可能成为 L1 的决定性考虑因素，因为人们强烈希望 L1 保持高度去中心化，这意味着证明生成必须在以太坊用户的合理范围内，而不应受到单个公司硬件的瓶颈限制。L2 可以做出更积极的权衡。

在这些领域中，还有更多的工作要做：

• 并行化证明要求证明系统的不同部分可以「共享内存」（如查找表）。我们知道这样做的技术，但需要加以实现。
• 我们需要进行更多的分析，以找出理想的 gas 成本变化集，从而最大限度地减少最坏情况下的验证时间。
• 我们需要在证明系统方面做更多的工作

可能的代价是：

• 安全性与验证器时间：如果选择更激进的哈希函数、更复杂的证明系统或更激进的安全假设或其他设计方案，就有可能缩短验证器时间。
• 去中心化与证明器时间：社区需要就所针对的证明器硬件的「规格」达成一致。要求证明者是大规模实体可以吗？我们希望高端消费笔记本电脑能在 4 秒内证明一个以太坊区块吗？介于两者之间？
• 打破向后兼容性的程度：其他方面的不足可以通过更积极的 gas 成本变化来弥补，但这更有可能不成比例地增加某些应用程序的成本，迫使开发人员重写和重新部署代码，以保持经济可行性。同样，这两个工具也有其自身的复杂性和弊端。

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

实现 L1 EVM 有效性证明所需的核心技术在很大程度上与其他两个领域共享：

• L2 的有效性证明（即「ZK rollup」）
• 无状态的「STARK 二进制哈希证明」方法

在 L1 成功实现有效性证明，就能最终实现轻松的单人质押：即使是最弱的计算机（包括手 机或智能手表）也能质押。这进一步提高了解决单人质押的其他限制（如 32ETH 最低限额）的价值。

此外，L1 的 EVM 有效性证明可以大大提高 L1 的 gas 限值。

共识的有效性证明

我们要解决什么问题？

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

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

它是什么，如何工作？

信标链被定义为状态转换函数,就像 EVM 一样。状态转换函数主要由三部分组成：

• ECADD（用于验证 BLS 签名）
• 配对（用于验证 BLS 签名）
• SHA256 哈希值（用于读取和更新状态）

在每个区块中，我们需要为每个验证器证明 1-16 个 BLS12-381 ECADD（可能不止一个，因为签名可能包含在多个集合中）。这可以通过子集预计算技术来弥补，因此我们可以说每个验证者只需证明一个 BLS12-381 ECADD。目前，每个插槽有 30000 个验证器签名。未来，随着单时隙终局性的实现，这种情况可能会向两个方向发生变化：如果我们采取「蛮力」路线，每个时隙的验证者数量可能会增加到 100 万。与此同时，如果采用 Orbit SSF，验证器数量将保持在 32768 个，甚至减少到 8192 个。

BLS 聚合如何工作：验证总签名只需要每个参与者一个 ECADD，而不是一个 ECMUL。但是 30000 个 ECADD 仍然是一个很大的证明量。

就配对而言，目前每个插槽最多有 128 个证明，这意味着需要验证 128 个配对。通过 ElP-7549 和进一步的修改，每个插槽可以减少到 16 个。配对的数量很少，但成本极高：每个配对的运行（或证明）时间比 ECADD 长数千倍。

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

对于 SHA256 哈希值来说，目前最糟糕的情况是纪元转换块，整个验证器短平衡树和大量验证器平衡都会被更新。每个验证器的短平衡树只有一个字节，因此有 1 MB 的数据会被重新取哈希。这相当于 32768 次 SHA256 调用。如果有一千个验证者的余额高于或低于一个阈值，需要更新验证者记录中的有效余额，这相当于一千个 Merkle 分支，因此可能需要一万次哈希值。洗牌机制需要每个验证器 90 比特（因此需要 11 MB 的数据），但这可以在一个纪元的任何时间计算。在单槽终结的情况下，这些数字可能会根据具体情况有所增减。洗牌变得没有必要，尽管 Orbit 可能会在一定程度上恢复这种需要。

另一个挑战是需要重新获取所有验证器状态，包括公钥，才能验证一个区块。对于 100 万个验证器来说，仅读取公钥就需要 4800 万字节，再加上 Merkle 分支。这就需要每个纪元数以百万计的哈希值。如果我们必须证明 PoS 的有效性，一种现实的方法是某种形式的增量可验证计算：在证明系统内存储一个单独的数据结构，该数据结构经过优化，可以高效查找，并证明对该结构的更新。

总之，挑战很多。要最有效地应对这些挑战，很可能需要对信标链进行深入的重新设计，而这可能与转向单槽终结同时进行。这种重新设计的特点可能包括：

• 哈希函数的变化：现在使用的是「完整」的 SHA256 哈希函数，因此由于填充的原因，每次调用都要对应两次底层压缩函数调用。如果改用 SHA256 压缩函数，我们至少可以获得 2 倍的收益。如果改用 Poseidon，我们可能会获得 100 倍的增益，从而彻底解决我们的所有问题（至少在哈希值方面）：在每秒 170 万哈希值（54MB），即使是一百万条验证记录也能在几秒钟内「读取」到证明中。
• 如果是 Orbit，则直接存储洗牌后的验证器记录：如果选择一定数量的验证器（如 8192 或 32768 个）作为给定插槽的委员会，则将它们直接放入彼此旁边的状态中，这样只需最少的哈希就能将所有验证器的公钥读入证明中。这样还可以高效地完成所有平衡更新。
• 签名聚合：任何高性能签名聚合方案都会涉及某种递归证明，网络中的不同节点会对签名子集进行中间证明。这就自然而然地将证明工作分担给了网络中的多个节点，从而大大减少了「最终证明者」的工作量。
• 其他签名方案：对于 Lamport+ Merkle 签名 ，我们需要 256 + 32 个哈希值来验证签名；乘以 32768 个签名者，就得到 9437184 个哈希值。对签名方案进行优化后，可以通过一个很小的常数因子进一步改善这一结果。如果我们使用 Poseidon，这在单个插槽内就能证明。但实际上，使用递归聚合方案会更快。

与现有研究有哪些联系？

• 简洁的以太坊共识证明（仅限同步委员会）
• 简洁 SP1 内的 Helios
• 简明 BLS12-381 预编译
• 基于 Halo2 的 BLS 集合签名验证

还有哪些工作要做，如何取舍：

实际上，我们需要数年时间才能获得以太坊共识的有效性证明。这与我们实现单槽终局性、Orbit、修改签名算法以及安全分析所需的时间大致相同，而安全分析需要足够的信心才能使用像 Poseidon 这样「激进」的哈希函数。因此，最明智的做法是解决这些其他问题，并在解决这些问题的同时考虑到 STARK 的友好性。

主要的权衡很可能是在操作顺序上，在改革以太坊共识层的更渐进的方法和更激进的「一次改变许多」的方法之间。对于 EVM 来说，渐进式方法是合理的，因为它能最大限度地减少对向后兼容性的干扰。对共识层来说，向后兼容性的影响较小，而且对信标链构建方式的各种细节进行更「全面」的重新思考，以最佳方式优化 SNARK 友好性也有好处。

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

在对以太坊 PoS 进行长期重新设计时，STARK 友好性必须成为首要考虑因素，尤其是单槽终局性、Orbit、签名方案变更和签名聚合。