原标题：《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、签名方案变更和签名聚合。