Vitalik Buterin谈以太坊未来：无状态验证的突破

区块链的魅力💥之一就是谁都能在自家电脑上跑个节点，验证这条链的真实性。即便有9596个节点（无论是PoW、PoS）齐心协力改规则，开始按照新规出块，仍然会有每个验证者拒绝接受这种“阴谋”。那些不参与的矿工会自然而然聚集在遵循老规矩的链上，继续他们的构建，而那些认真验证的用户则会跟随这条链。

这就是区块链和中心化系统的不同之处。不过，要让这个特性发挥作用，运行完全验证节点得对足够多的人来说是可行的。这不仅适用于矿工（如果他们不验证链，就没法执行协议规则），也适用于普通用户。现在，虽然在一般笔记本电脑上（我写这篇时也在用）运行节点是可能的，但其实蛮麻烦的。The Verge 旨在改变这种现状，让完全验证链的计算成本变得超级低，让每个手机钱包、浏览器钱包甚至智能手表都能轻松验证。

最初的"verge"概念是将以太坊的状态存储转移到一种叫做Verkle树的结构，这种树能让证明变得更紧凑，达到无状态验证以太坊区块的目的。📦 节点可以验证以太坊区块，而无需在硬盘上存储任何状态信息（比如账户余额、合约代码、存储空间等），只需花费几百KB的证明数据和额外几百毫秒的时间来进行验证。如今，"verge"的愿景更为宏大，专注于提升以太坊链的资源效率，不仅包含无状态验证技术，还将SNARK用于所有以太坊执行的验证。

🔍 除了对SNARK验证整条链的长期关注外，Verkle树是否是最佳技术也成了一个新问题。因为Verkle树对量子计算机的攻击较为脆弱，所以如果我们把它放入当前的KECCAK Merkle Patricia树中，未来可能还得更换树。Merkle树的自替代方法是直接跳过使用Merkle分支的STARK，将其放入二叉树。👀 过去因开销和技术复杂性，这种方法一直被认为不可行。不过最近，Starkware在一台笔记本上证明了每秒170万个Poseidon哈希，随着GKB等技术的出现，传统哈希值的证明时间也在迅速缩短。因此，"verge"在过去一年变得更加开放，展现出多种可能性。

关键目标

• 💾 无状态客户机：完全验证客户机和标记节点所需的存储空间不应超过几GB。

• ⌚️ (长期）在智能手表上完全验证链（共识和执行）。下载一些数据，验证SNARK，完成。

在本章中

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

无状态验证：Verkle还是STARKs

我们要解决什么问题？

如今，以太坊客户端需要存储数百千兆字节的状态数据来验证区块，而这一数字每年都在增加。🗃️ 原始状态数据每年增加约30GB，单个客户端还得存储额外的数据，以有效更新三元组。 减少了完全验证以太坊节点的用户数量。虽然市场上有很多大硬盘可以存储所有以太坊的状态和历史数据，但大多数人买的电脑存储空间只有几百GB。状态大小让首次建立节点的过程变得极其繁琐，节点需要下载整个状态，可能耗时数小时甚至数天。这引发了连锁反应，比如，节点维护者升级其节点设置的难度激增。尽管技术上可以不停机升级——启动新客户端，等待同步，然后关闭旧客户端并传输密钥——但实际上操作起来非常复杂。

无状态验证是啥？

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

为了实现无状态验证，需要对以太坊的状态树结构进行改动。因为当前的Merkle Patricia树在实施任何加密证明方案时极其不友好，尤其在最坏情况下。不论是“原始”的Merkle分支，还是“包装”成STARK的方案，都是如此。主要问题出在MPT的几个弱点上：

1. 树的结构：这是一棵六叉树（每个节点有16个子节点）。这意味着，在大小为N的树中，一个证明平均需要32*(16-1)log16(N) = 120log2(N)字节，对于2^32项的树大约需要3840字节。而二叉树只需32*(2-1)log2(N) = 32log2(N)字节，大约1024字节。

2. 代码未Merkle化：要证明账户代码的访问，必须提供整个代码，最多需要24000字节。

最坏情况下的计算如下：

30000000 gas / 2400（冷账户读取成本）(5 * 488 + 24000) = 330000000 字节 分支成本小幅下降（用 5480 替代 8*480），因为当分支数量增多时，顶端部分会重复出现。不过，在一个时隙内下载的数据量仍然不太现实。若尝试用 STARK 封装，可能会遇到两个难题：(i) KECCAK 对 STARK 不太友好；(ii) 330MB 数据意味着必须证明对 KECCAK round 函数的 500 万次调用，这对大部分硬件来说都是个挑战，除了那些最强劲的消费级设备，可能连 STARK 的高效性都证明不了。

如果我们用二叉树替代十六进制树，并额外进行 Merkle 化处理，最坏情况大概变成 30000000/240032(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 字节（由于状态块的分布不均，实际计算结果会略有不同，但作为初步估算是可以的）。

需要强调的是，这种“最坏情况”并不是真正的最坏情况：更糟的情况是攻击者故意“挖掘”两个地址，在树中形成较长的共同前缀，并从其中一个地址读取数据，这可能将最坏情况下的分支长度再翻倍。即便如此，Verkle 树的最坏证明长度仍为 2.6MB，跟目前最坏情况下的校验数据基本持平。

• 相邻存储空间成本：我们搞了一点小花样，把访问“相邻”存储空间的费用压得超低！要么用同一合同的一堆代码块，要么就是相邻的存储槽。EIP-4762 定义了邻接，邻接访问费用只需200 gas。在这种情况下，最坏的证明大小变成了30000000 / 200*32 - 4800800字节，这个数字依然在公差范围内。为了更稳妥，如果想减少这个值，可以考虑稍微提高邻接访问的费用。

• STARKed 二进制哈希树：这玩意儿的原理简单得让人想笑：构建一棵二叉树，搞定最大10.4MB的证明，证明块里的值，然后用STARK的证明替代传统证明。这样一来，证明本身只包含被证明的数据，还加上来自实际STARK的100-300kB的固定开销。

  主要挑战在于验证时间。咱们可以照样进行计算，不过这回计算的是哈希值而不是字节数。10.4MB的区块意味着要处理330000个哈希值。如果再考虑攻击者“挖掘”地址树中有长公共前缀的可能，最坏情况下哈希值会达到660000个。因此，只要我们能证明每秒处理200,000个哈希值，那就没啥问题了。

  使用Poseidon哈希函数的消费类笔记本电脑上，这些数字已经达标。Poseidon可是专为STARK友好性设计的哦。不过，它还挺年轻，很多人对它的安全性持怀疑态度。因此我们有两条路可以走：

  1. 对Poseidon进行快速的安全分析，直到大家对其熟悉到可以在L1上部署。

  2. 用更“保守”的哈希函数，比如SHA256或BLAKE。

  如果要证明保守的哈希函数，Starkware的STARK圈在撰写时只能在消费类笔记本上每秒证明10-30k个哈希值。不过，STARK技术在飞速进步。就算是现在，基于GKR的技术已经显示出能把速度提升到100-200k的范围。

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

• 内存池：当交易被传播时，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论文
• Ajtai（基于晶格硬度的替代快速哈希函数）
• Verkle.info

还能做些什么？

剩下的主要工作包括：

1. 对EIP-4762后果的深入分析（无状态gas成本变化）
2. 更多关于过渡程序的完成和测试，这是任何无国籍环境实施方案复杂性的主要部分
3. 对Poseidon、Ajtai和其他“STARK-friendly”哈希函数进行更深入的安全分析 超高效 STARK 协议功能开发的保守哈希，像是 Binius 或 GKR 的观点，正在不断推进。

接下来，我们将从以下三种选项中做出选择：

1. Verkle 树
2. STARK 友好哈希函数
3. 保守哈希函数

这些选项的特点可以在下表中大致归纳：

除了这些选项，还有一些关键因素需要考虑：

• Verkle 树的成熟度：现如今，Verkle 树的代码已经相当稳定。若选择其他代码，可能会推迟部署进程，甚至影响硬分叉的时间。这其实也不算坏事，特别是在我们需要更多时间进行哈希函数的分析或验证器的实现时，或者有其他重要功能希望尽早融入以太坊。

• 状态根更新速度：使用哈希值更新状态根的速度要快于使用 Verkle 树。这意味着，基于哈希值的方法可以有效缩短全节点的同步时间。

• Verkle 树的见证更新特性：Verkle 树的见证是可更新的，这一特性对 mempool、包含列表和其他应用场景都极具价值，可能还会提升实施效率：状态对象更新后，能够更新倒数第二层的见证，而无需读取最后一层的内容。

• SNARK 证明的复杂性：进行 Verkle 证明时，挑战在于如何将证明大小控制在几千字节内。Verkle 证明的验证过程涉及大量 256 位操作，这对证明系统造成了较高的开销，或者需要一个定制结构以适应 256 位的 Verkle 证明部分。尽管这对无状态来说不是问题，但却增添了不少复杂性。

• 基于 lattice 的 Merkle 树：若我们希望以量子安全的方式实现 Verkle 见证的可更新性，基于 lattice 的 Merkle 树或许是值得考虑的另一条路径。

• 多维 gas 的潜力：在证明系统效率不足时，多维 gas 作为意料之外的工具可以帮助弥补：为 (i) calldata；(ii) 计算；(iii) 状态访问等不同资源设定独立的 gas 限制。尽管增加了复杂性，但它能更严格地控制平均情况与最坏情况之间的比率。借助多维 gas，理论上需要证明的最大分支数可能从 12500 降至约 3000。这意味着，即使在今天，BLAKE3 也能勉强应对。

多维 gas 让区块的资源限制更接近底层硬件的限制。

• 状态根计算的延迟 🕒
  意外的工具是将状态根计算推迟到区块之后的时隙，这给了我们整整12秒来计算状态根。即便在最极端的情况下，每秒60000哈希的证明时间也是绰绰有余的。这让人怀疑，BLAKE3能否真正满足需求。

• 方法的缺点 ⚠️
  不过，这种方法会增加一个时隙的轻客户端延迟。但更聪明的技术可以把这种延迟缩减到仅仅是证明生成的延迟。比如，证明可以在节点生成后立刻在网络上广播，而不必等下一个区块。

• 与路线图的互动 🤔
  解决无状态问题显著提升了单人定点的难度。如果能降低单人定点的最低平衡，比如通过Orbit SSF或小队定点策略，就会变得更可行。

• 引入EOF的好处 🌟
  如果同时引入EOF，多维gas分析将变得更简单。多维gas的复杂度主要来自处理不传递父调用全部gas的子调用。EOF只需将这些子调用设为非法，就能轻松解决这个问题（同时，本机账户抽象为部分gas的主要使用情况提供协议内替代方案）。

• 无状态验证与历史过期的协同作用 🔗
  无状态验证和历史过期之间存在重要协同作用。现阶段，客户端需存储近1TB的历史数据，这些数据是状态数据的数倍。即使客户机是无状态的，若无法解除其存储历史数据的责任，几乎无存储客户机的梦想就无法实现。EIP-4444是迈出的第一步，意味着将历史数据存储在torrents或门户网站Portal Network中。

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

• 达成目标的挑战 🔧
  为实现这一目标，需要对（i）共识层（股权证明）和（ii）执行层（EVM）进行SNARK或STARK证明。前者本身就是一个挑战，需在不断改进共识层的过程中解决（例如，针对单槽终局性）。后者则需要EVM执行证明。 它是啥，咋运作的呢？

EVM定义：在以太坊的标准中，EVM 被视作一个状态转换函数。想象一下，你有一个前状态 S 和一个区块 B，接着你就能计算出后状态 S'，公式是 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 秒内被确认。今天，我们离这个理想状态还有一段距离，虽然相较于两年前，我们已经取得了不小的进展。为了实现这个目标，需要在以下三个方向上加速发展：

1. 并行化🚀——现阶段最快的 EVM 校验器平均需要 15 秒来验证一个以太坊区块。这是通过将计算任务分配给数百个 GPU，并在最后将结果汇总来实现的。理论上，我们知道如何构建一个能在 O(log(N)) 时间内进行计算证明的 EVM 验证器：让每个 GPU 完成一个步骤，最后形成一个“聚合树”。

   实现这个目标并不简单。即使在极端情况下，一个较大的事务占用整个区块，计算也不能按次进行，而是必须依赖操作码（如 EVM 或 RISC-V）。确保虚拟机的“内存”在各部分证明之间保持一致是实施中的关键挑战。如果能实现这种递归证明，我们就能解决证明者的延迟问题，即使其他方面没有改进。

2. 证明系统优化⚙️——新型证明系统，如 Orion、Binius、GRK 等，可能会显著缩短通用计算的验证时间。

3. EVM gas 成本的变化🔥——EVM 中的许多内容可以优化，以便更有利于证明者，尤其是在最坏情况下。如果攻击者能构建一个阻塞证明者十分钟的区块，那么要在 4 秒内验证一个普通以太坊区块显然是不够的。所需的 EVM 改动大致可分为以下几类：

   • gas 成本变化💰——如果某个操作需要较长时间才能证明，那么即便其计算速度较快，gas 成本也应设定得较高。EIP-7667 针对这一问题提出了较高的（传统）哈希函数的 gas 成本，因为这些函数的操作码和预编译相对便宜。为了抵消这些 gas 成本的增加，我们可以降低其他证明成本较低的 EVM 操作码的 gas 成本，保持平均吞吐量不变。

   • 数据结构替换🔄——除了替换为对 STARK 更友好的状态树外，还需更换事务列表、收据树及其他高成本结构。Etan Kissling 将事务和收据结构迁移至 SSZ 的 EIP，正是向这个方向迈出的一步。 在这个领域，多维 gas 和延迟状态根这两个工具可谓是得力助手。🤖 不过，跟无状态验证相比，使用这两个工具意味着我们已经具备了足够的技术来满足当下的需求。尽管如此，完整的 ZK-EVM 验证仍然需要更多努力——只是所需工作量会少一点而已。

提到一个没被广泛讨论的点：证明器硬件的运用。借助 GPU、FPGA 和 ASIC，可以更快地生成证明。像 Fabric Cryptography、Cysic 和 Accseal 这样的公司在这方面已经取得了不小的进展。这对 L2 来说非常重要，但对于 L1 而言，可能不会成为决定性因素，因为大家希望 L1 保持高去中心化，这就要求证明生成必须在以太坊用户的可接受范围内，而不能依赖单一公司的硬件瓶颈。相对而言，L2 可以做出更灵活的权衡。

在这些领域中，我们还有很多工作要做：

1. 并行化证明：需要让证明系统的不同部分可以共享内存（比如查找表）。我们掌握了相关技术，但还需进一步实施。

2. 优化 gas 成本：需要更多分析，以找出理想的 gas 成本变化集，从而最大限度地减少最坏情况下的验证时间。

3. 加强证明系统：在证明系统方面的工作也亟待加强。

可能面临的代价包括：

• 安全性与验证器时间：选择更激进的哈希函数、复杂的证明系统或其他设计方案，可能会缩短验证器所需时间。

• 去中心化与证明器时间：社区需对证明器硬件的“规格”达成一致。是否可以要求证明者是大规模实体？我们希望高端笔记本能在 4 秒内证明一个以太坊区块吗？还是要在两者之间找到平衡？

• 向后兼容性问题：通过更积极的 gas 成本变化弥补其他方面的不足，可能会不成比例地增加某些应用的成本，迫使开发者重写和重新部署代码以维持经济可行性。而这两个工具自身也有其复杂性和缺陷。

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

实现 L1 EVM 有效性证明所需的核心技术与其他两个领域有很大重叠：

• L2 的有效性证明（也就是“ZK rollup”）

• 无状态的“STARK 二进制哈希证明”方法 在 L1 成功实现有效性证明后，单人质押变得轻而易举：即便是最基础的计算设备，比如手机或智能手表，都能轻松进行质押。这种进展进一步提升了单人质押时解决其他限制（如32ETH的最低质押额度）的重要性。

🔧 L1 的 EVM 有效性证明 大幅提升了 L1 的 gas 限值。

共识的有效性证明

我们要解决什么问题？

为了用 SNARK 完全验证以太坊区块，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 字节，意味着有 1 MB 的数据需要重新计算哈希，相当于 32768 次 SHA256 调用。如果一千个验证者的余额变动，需要更新其记录的有效余额，这就涉及一千个 Merkle 分支，可能需要一万次哈希计算。洗牌机制要求每个验证器 90 比特（总共 11 MB 数据），但这可以在任意时间计算。在单槽终结的情况下，这些数字会有所波动。虽然洗牌看似多余，但 Orbit 可能会在一定程度上恢复这需求。

另一个挑战是，验证一个区块时需要重新获取所有验证器状态，包括公钥。对于 100 万个验证器，仅读取公钥就得 4800 万字节，加上 Merkle 分支，这意味着每个纪元得进行数以百万计的哈希计算。若想证明 PoS 的有效性，现实的办法或许是某种形式的增量可验证计算：在证明系统内存储一个独立的数据结构，经过优化以便高效查找和证明结构的更新。

挑战可不少。要高效应对这些挑战，可能得对信标链进行彻底重构，这可能与转向单槽终结同步进行。这种重构可能包括：

• 哈希函数的改变：目前使用的是 "完整" 的 SHA256 哈希函数，由于填充原因，每次调用都得对应两次底层压缩函数调用。如果换成 SHA256 压缩函数，至少能获得 2 倍的收益。若改用 Poseidon，可能获得 100 倍的增益，从而在哈希值方面彻底解决问题：一秒可处理 170 万哈希值（54MB），即便有一百万条验证记录，几秒钟内也能「读取」到证明中。

• 直接存储洗牌后的验证器记录：当选定一定数量的验证器（如8192或32768个）作为特定插槽的委员会时，这些验证器将被直接放置在彼此的状态旁边。这样做的好处是，只需最少的哈希，就能将所有验证器的公钥读入证明中，同时高效地完成所有平衡更新。

• 签名聚合：任何高性能的签名聚合方案通常涉及某种形式的递归证明。在网络中，不同的节点会对签名子集进行中间证明，这样自然就将证明工作分担给了多个节点，显著降低了“最终证明者”的工作负担。

• 其他签名方案：以Lamport + Merkle签名为例，我们需要256 + 32个哈希值来验证签名；如果有32768个签名者，那就需要9437184个哈希值。通过对签名方案进行优化，可以借助一个小的常数因子来改善这一结果。使用Poseidon可以在单个插槽内完成证明，但实际上，采用递归聚合方案会更为高效。

与现有研究的关联：

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

未来的工作与取舍：

实际上，我们需要数年的时间来确保以太坊共识的有效性。这与实现单槽终局性、Orbit、修改签名算法和进行安全分析所需的时间相当，而安全分析需要对“激进”哈希函数如Poseidon有充分的信心。因此，明智的做法是解决这些问题，并在此过程中考虑STARK的友好性。

主要的权衡可能在于操作顺序，即在改革以太坊共识层时采用更渐进的方法或更激进的“一次改变许多”的策略。对于EVM，渐进式方法是明智的，因为它能最大限度地减少对向后兼容性的干扰。而对共识层而言，向后兼容性的影响较小，因此对信标链构建方式的各个细节进行“全面”的重新思考，以最佳方式优化SNARK友好性也是有益的。

与路线图的其他部分互动：

在对以太坊PoS进行长期重新设计时，STARK友好性必须成为首要考虑的因素，尤其是在单槽终局性、Orbit、签名方案变更和签名聚合方面。 抱歉，我无法直接访问外部链接。不过，你可以直接提供原文的内容，我会帮你洗稿！