Vitalik：以太坊 The Verge 阶段的关键目标
分享到朋友或朋友圈
作者：以太坊创始人Vitalik；编译：邓通，金色财经
按：本文为以太坊创始人Vitalik近期发表的“以太坊协议的未来发展”系列文章的第四部分“Possible futures of the Ethereum protocol, part 4: The Verge”。第三部分见“Vitalik：以太坊The Scourge阶段的关键目标”，第二部分见“Vitalik：The Surge阶段以太坊协议应该怎么发展”，第一部分见“以太坊PoS还有哪些可以改进”。以下为第四部分全文：
特别感谢 Justin Drake、Hsiao-wei Wang、Guillaume Ballet、Ignacio、Josh Rudolf、Lev Soukhanov、Ryan Sean Adams 和 Uma Roy 的反馈和审查。
区块链最强大的功能之一是任何人都可以在自己的计算机上运行节点并验证链是否正确。即使运行链上共识（PoW、PoS……）的95%的节点都立即同意改变规则，并开始按照新规则生产区块，每个运行完全验证节点的人都会拒绝接受这条链。 不属于此类集团的利益相关者将自动汇聚并继续构建一条继续遵循旧规则的链，并且完全验证的用户将遵循该链。
这是区块链和中心化系统之间的关键区别。然而，为了保持这一特性，运行完全验证的节点需要对临界数量的人来说实际上是可行的。这既适用于质押者（就好像质押者没有验证链，他们实际上并没有为执行协议规则做出贡献），也适用于普通用户。如今，可以在消费类笔记本电脑（包括用于撰写本文的笔记本电脑）上运行节点，但这样做很困难。 The Verge 旨在改变这一现状，让完全验证链的计算成本变得如此低廉，以至于每个移动钱包、浏览器钱包，甚至智能手表都默认这样做。
The Verge，2023 年路线图。
最初，“Verge”指的是将以太坊状态存储转移到 Verkle 树的想法 - 这种树结构允许更紧凑的证明，从而实现以太坊区块的无状态验证。节点可以在其硬盘上没有任何以太坊状态（账户余额、合约代码、存储……）的情况下验证以太坊区块，但代价是花费几百千字节的证明数据和几百毫秒的额外时间来验证证明。如今，Verge 代表了一个更大的愿景，专注于实现以太坊链的最大资源效率验证，其中不仅包括无状态验证技术，还包括使用 SNARK 验证所有以太坊执行。
除了长期关注 SNARK 验证整个链之外，另一个新问题与 Verkle 树是否是最好的技术有关。 Verkle 树很容易受到量子计算机的攻击，因此，如果我们用 Verkle 树替换当前的 KECCAK Merkle Patricia 树，我们稍后将不得不再次替换这些树。 Merkle 树的自然替代方案是直接跳到在二叉树中使用 STARK Merkle 分支。从历史上看，由于开销和技术复杂性，这被认为是不可行的。然而，最近，我们看到 Starkware 在带有 Circle STARK 的笔记本电脑上证明了每秒 170 万次 Poseidon 哈希值，并且由于 GKR 等技术，更多“传统”哈希值的证明时间也在迅速缩短。
因此，在过去的一年里，Verge 变得更加开放，并且存在多种可能性。
The Verge：关键目标
无状态客户端：完全验证客户端和质押节点不需要超过几 GB 的存储空间。
（长期）在智能手表上全面验证链（共识和执行）。下载一些数据，验证 SNARK，完成。
在本文中重点介绍以下内容：
无状态验证：Verkle 或 STARKs
EVM执行的有效性证明
共识的有效性证明
无状态验证：Verkle 或 STARKs
我们要解决什么问题？
如今，以太坊客户端需要存储数百GB的状态数据才能验证区块，并且这个数量每年都在持续增加。原始状态数据每年增加约 30 GB，个人客户端除了能够有效更新 trie 之外还必须存储一些额外的数据。
这减少了可以运行完全验证以太坊节点的用户数量：尽管硬盘驱动器足够大，可以存储所有以太坊状态甚至多年的历史记录，但人们默认购买的计算机往往只有几百个千兆字节的存储空间。状态大小还会给首次设置节点的过程带来很大的麻烦：节点需要下载整个状态，这可能需要数小时或数天的时间。这会产生各种连锁反应。例如，这使得质押者升级其质押设置变得更加困难。从技术上讲，可以在不停机的情况下完成此操作 - 启动新客户端，等待其同步，然后关闭旧客户端并传输密钥 —— 但实际上，这在技术上很复杂。
它是什么以及它是如何工作的？
无状态验证是一种允许节点在不拥有完整状态的情况下验证区块的技术。相反，每个区块都带有一个见证人，其中包括（i）该区块将访问的状态中特定位置的值（例如代码、余额、存储），以及（ii）这些值的加密证明是正确的。
实际实现无状态验证需要改变以太坊状态树结构。这是因为当前的 Merkle Patricia 树对于实现任何密码证明方案都极其不友好，尤其是在最坏的情况下。对于“原始”Merkle 分支以及将 Merkle 分支“包装”在 STARK 中的可能性都是如此。主要困难源于 MPT 的两个弱点：
它是一棵六叉树（即每个节点有 16 个子节点）。这意味着平均而言，大小为 N 的树中的证明有 32*(16-1)*log16(N) = 120*log2(N) 字节，或者在 232 项树中大约有 3840 字节。对于二叉树，只需要 32*(2-1)*log2(N) = 32*log2(N) 字节，即大约 1024 字节。
该代码未默克尔化。这意味着提供帐户代码的任何访问权限都需要提供完整的代码，最大长度为 24000 字节。
我们可以计算最坏的情况如下：
30,000,000 Gas / 2,400（“冷”账户读取成本）* (5 * 480 24,000) = 330,000,000 字节
分支成本略有下降（5*480 而不是 8*480），因为当分支数量很多时，分支的顶部会重复。但即便如此，在一个插槽内下载的数据量也是完全不切实际的。如果我们尝试将其包装在 STARK 中，我们会遇到两个问题：(i) KECCAK 相对 STARK 不友好，(ii) 330 MB 的数据意味着我们必须证明对 KECCAK 轮函数的 500 万次调用，这是一种方式即使我们可以使 STARK 证明 KECCAK 更加高效，但除了最强大的消费类硬件之外，还有很多东西无法在所有硬件上进行证明。
如果我们只是用二叉树替换六叉树，再加上 Merkelize 代码，那么最坏的情况大约会变成 30,000,000 / 2,400 * 32 * (32 - 14 8) = 10,400,000 字节 ~214 个分支，其中 8 是长度进入一片叶子的证明）。请注意，这需要改变Gas成本，以对访问每个单独的代码块进行收费； EIP-4762 就是这样做的。 10.4 MB 就好多了，但对于许多节点来说，在一个插槽内下载的数据仍然太多。所以我们需要引入一些更强大的技术。为此，有两种主要的解决方案：Verkle 树和 Starked 二叉哈希树。
Verkle 树
Verkle 树使用基于椭圆曲线的向量承诺来做出更短的证明。关键在于，无论树的宽度如何，每个父子关系对应的证明片段只有 32 个字节。树宽度的唯一限制是，如果树太宽，证明的计算效率就会降低。以太坊的建议实现宽度为 256。
因此，证明中单个分支的大小变为 32*log256(N) = 4*log2(N) 字节。理论上的最大证明大小变为大约 30,000,000/2,400*32*(32-14 8)/8 = 1,300,000 字节（由于状态块分布不均匀，数学计算在实践中略有不同，但这作为第一个很好）。
作为额外的警告，请注意，在上述所有示例中，这种“最坏情况”并不是最坏情况：更糟糕的情况是攻击者故意“挖掘”两个地址以在树中具有很长的公共前缀，并且从其中一个读取，这可以将最坏情况的分支长度再延长约 2 倍。但即使有这样的警告，Verkle 树也能让我们获得约 2.6 MB 的最坏情况证明，这大致与今天的最坏情况呼叫数据相匹配。
我们还利用这个警告来做另一件事：我们使访问“相邻”存储变得非常便宜：同一合约的许多代码块，或相邻的存储槽。 EIP-4762提供了邻接的定义，邻接访问仅收取200 Gas费用。对于相邻访问，最坏情况的证明大小变为 30,000,000/200*32 = 4,800,800 字节，这仍然大致在容差范围内。如果为了安全我们希望降低这个值，我们可以稍微增加相邻的访问成本。
已加星标的二元哈希树
这里的技术是非常不言自明的：你做一个二叉树，采用你需要证明一个块中的值的 max-10.4-MB 证明，并用该证明的 STARK 替换该证明。这让我们发现证明本身仅包含被证明的数据，加上实际 STARK 的约 100-300 kB 固定开销。
这里的主要挑战是证明时间。我们可以进行与上面基本相同的计算，只不过我们不计算字节，而是计算哈希值。 10.4 MB 的块意味着 330,000 个哈希值。如果我们添加攻击者“挖掘”树中具有长公共前缀的地址的可能性，那么真正最坏的情况将变为大约 660,000 个哈希值。因此，如果我们能够证明每秒约 200,000 个哈希值，那就没问题。
这些数字已经在具有 Poseidon 哈希函数的消费笔记本电脑上达到了，该函数是专门为 STARK 友好性而设计的。然而，波塞冬相对不成熟，因此许多人还不信任它的安全性。因此，有两条现实的前进道路：
快速对 Poseidon 进行大量安全分析，并熟悉它以将其部署在 L1
使用更“保守”的哈希函数，例如 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 分支的另一个优点是它们是可更新的：给定一个以区块 B 为根的状态对象 X 的证明，如果您收到一个带有其见证人的子区块 B2，您可以更新该证明以使其以区块 B2 为根。 Verkle 证明本身也是可更新的。
与现有研究有哪些联系？
Verkle树：https://vitalik.eth.limo/general/2021/06/18/verkle.html
John Kuszmaul 的原始 Verkle 树论文：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/
还需要做什么，需要权衡什么？
剩下要做的主要工作是：
对EIP-4762后果的更多分析（无状态gas成本变化）
更多工作完成和测试过渡程序，这是任何无状态 EIP 复杂性的很大一部分
对 Poseidon、Ajtai 和其他“STARK 友好”哈希函数的更多安全分析
进一步开发用于“保守”（或“传统”）哈希函数的超高效 STARK 协议，例如基于 Binius 或 GKR 的想法。
我们很快就会做出选择以下三个选项中的哪一个的决策点：(i) Verkle 树，(ii) STARK 友好的哈希函数，以及 (iii) 保守哈希函数。它们的属性可以大致总结如下表：
除了这些“标题数字”之外，还有一些其他重要的考虑因素：
如今，Verkle树代码已经相当成熟。使用 Verkle 之外的任何东西实际上都会延迟部署，很可能是通过硬分叉。这可能没问题，特别是如果我们无论如何都需要额外的时间来进行哈希函数分析或证明者实现，并且如果我们有其他重要功能希望尽早包含在以太坊中。
使用哈希更新状态根比使用 Verkle 树更快。这意味着基于哈希的方法可以缩短全节点的同步时间。
Verkle 树具有有趣的见证更新属性 - Verkle 树见证是可更新的。此属性对于内存池、包含列表和其他用例很有用，它还可能有助于提高实现效率：如果更新状态对象，您可以更新倒数第二个级别的见证人，甚至无需读取最后一个级别。
Verkle 树更难通过 SNARK 证明。如果我们想将证明大小一直减少到几千字节，Verkle 证明会带来一些困难。这是因为 Verkle 证明的验证引入了大量的 256 位操作，这要求证明系统要么具有大量开销，要么本身具有自定义的内部结构，其中包含用于 Verkle 证明的 256 位部分。
如果我们希望Verkle见证的可更新性以一种量子安全且相当高效的方式进行，另一种可能的途径是基于网格的Merkle树。
如果证明系统在最坏的情况下不够有效，我们可以使用另一个“帽子里的兔子”来弥补这种不足，那就是多维Gas：对(i) calldata、（ii）计算、（iii）状态访问以及可能的其他不同资源有单独的Gas限制。多维Gas增加了复杂性，但作为交换，它更严格地限制了平均情况和最坏情况之间的比率。对于多维Gas，要证明的理论最大分支数可能会从30,000,000 / 2400 = 12,500减少到3000。 这将使BLAKE3（勉强）即使在今天也足够了，没有进一步的证明改进。
多维Gas允许区块的资源限制更接近地复制底层硬件的资源限制。
另一个“突然出现的兔子”是延迟状态根计算直到块之后的槽的提议。这将为我们提供整整 12 秒的时间来计算状态根，这意味着即使在最极端的情况下，只有约 60,000 次哈希/秒的证明时间就足够了，这再次将我们置于 BLAKE3 勉强够用的范围内。
这种方法的缺点是，它会增加轻客户端延迟一个时间段，尽管该技术有更聪明的版本可以将这种延迟减少到仅证明生成延迟。例如，只要任何节点生成证明，就可以在网络上广播该证明，而不是等待下一个块。
它如何与路线图的其他部分交互？
解决无状态问题大大增加了单独质押的便利性。如果能够降低单独质押最低余额的技术（例如 Orbit SSF 或应用层策略（例如小队质押））变得可用，那么这将变得更有价值。
如果同时引入 EOF，多维Gas会变得更容易。这是因为用于执行的多维 Gas 的一个关键复杂性是处理不传递父调用的完整 Gas 的子调用，而 EOF 通过简单地使此类子调用非法（并且本机帐户抽象将提供一个 in -当前部分Gas子调用主要用例的协议替代方案）。
另一项重要的协同作用是无状态验证和历史过期之间的协同作用。如今，客户必须存储近 TB 的历史数据；这个数据比国家数据大几倍。即使客户端是无国籍的，除非我们也能减轻客户端存储历史的责任，否则客户端几乎无存储的梦想也无法实现。这方面的第一步是 EIP-4444，这也意味着将历史数据存储在 torrent 或 Portal 网络中。
EVM执行的有效性证明
我们要解决什么问题？
以太坊区块验证的长期目标很明确：您应该能够通过以下方式验证以太坊区块：(i) 下载该区块，甚至可能仅下载该区块的一小部分并进行数据可用性采样，以及 (ii) 验证一小部分证明该块是有效的。这将是一个资源消耗极少的操作，可以在移动客户端、浏览器钱包内甚至（没有数据可用性部分）在另一个链中完成。
要达到这一点，需要拥有 (i) 共识层（即权益证明）和 (ii) 执行层（即 EVM）的 SNARK 或 STARK 证明。前者本身就是一个挑战，应该在进一步改进共识层的过程中解决（例如，单槽最终确定性）。后者需要 EVM 执行的证明。
它是什么以及它是如何工作的？
正式地，在以太坊规范中，EVM 被定义为状态转换函数：你有一些前状态 S、一个区块 B，并且你正在计算一个后状态 S' = STF(S, B)。如果用户使用的是轻客户端，他们就没有S和S'，甚至没有完整的B；相反，它们有一个前状态根 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，还有很多工作要做。
与现有研究有哪些联系？
EC 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 计算，并且其中没有错误。提高安全性的两种主要技术是多重证明者和形式验证。多证明者意味着拥有多个独立编写的有效性证明实现，就像有多个客户端一样，并且如果这些实现的足够大的子集证明了某个块，则让客户端接受该块。形式验证涉及使用常用于证明数学定理的工具（例如 Lean4）来证明有效性证明仅接受以 Python 编写的底层 EVM 规范的正确执行的输入。
足够快的证明时间意味着任何以太坊区块都可以在不到 4 秒的时间内得到证明。今天，我们距离这个目标仍然很远，尽管我们比两年前的想象要近得多。为了实现这一目标，我们需要在三个方面推进：
并行化——当今最快的 EVM 证明者可以在约 15 秒内证明平均以太坊区块。它通过在数百个 GPU 之间进行并行化，然后最后将它们的工作聚合在一起来实现这一点。理论上，我们确切地知道如何制作一个可以在 O(log(N)) 时间内证明计算的 EVM 证明器：让一个 GPU 执行每个步骤，然后执行“聚合树”：
实施这一点存在挑战。即使在最坏的情况下（即非常大的交易占用整个块）也能工作，计算的分割不能是按交易进行的；它必须是每个操作码（EVM 或底层 VM（如 RISC-V））。使这变得不完全微不足道的一个关键实现挑战是需要确保VM的“内存”在证明的不同部分之间是一致的。然而，如果我们可以进行这种递归证明，那么我们知道至少证明者延迟问题得到了解决，即使在任何其他轴上没有任何改进。
证明系统优化 —— Orion、Binius、GKR 等新的证明系统可能会导致通用计算的证明时间再次大幅减少。
EVM 的 Gas 消耗了其他变化 —— EVM 中的许多东西都可以优化，使其对证明者更加友好，尤其是在最坏的情况下。如果攻击者能够构建一个会占用证明者十分钟时间的区块，那么仅仅在 4 秒内证明一个平均以太坊区块是不够的。所需的 EVM 更改主要可以分为两类：
Gas 成本变化 —— 如果一个操作需要很长时间来证明，那么即使计算速度相对较快，它也应该具有较高的 Gas 成本。 EIP-7667 是一个提议的 EIP，用于处理这方面最严重的问题：它显著增加了作为相对便宜的操作码和预编译公开的（传统）哈希函数的 Gas 成本。为了补偿这些 Gas 成本的增加，我们可以降低证明相对便宜的 EVM 操作码的 Gas 成本，从而保持平均吞吐量相同。
数据结构替换 —— 除了用更适合 STARK 的替代方案替换状态树之外，我们还需要替换交易列表、收据树和其他证明成本高昂的结构。 Ethan Kissling 的 EIP 将交易和收据结构移至 SSZ ([1] [2] [3])，这是朝这个方向迈出的一步。
除此之外，上一节中提到的两个“从帽子里出来的兔子”（多维Gas和延迟状态根）也可以在这里提供帮助。然而，值得注意的是，与无状态验证不同，无状态验证意味着我们有足够的技术来完成我们今天所需要的事情，即使使用这些技术，完整的 ZK-EVM 验证也将需要更多的工作 —— 只是需要更少的工作工作。
上面没有提到的一件事是证明硬件：使用 GPU、FPGA 和 ASIC 更快地生成证明。 Fabric Cryptography、Cysic 和 Accseal 是这三家公司的推动者。这对于第 2 层来说非常有价值，但它不太可能成为第 1 层的决定性考虑因素，因为人们强烈希望保持第 1 层高度去中心化，这意味着证明生成必须在相当大的子集的能力范围内。以太坊用户，不应该遇到单一公司硬件的瓶颈。第 2 层可以做出更激进的权衡。
这些领域还有更多工作要做：
并行证明需要证明系统，其中证明的不同部分可以“共享内存”（例如查找表）。我们知道做到这一点的技术，但它们需要实施。
我们需要更多的分析来找出理想的 Gas 成本变化集，以最大限度地减少最坏情况下的证明时间。
我们需要在证明系统上做更多的工作
这里可能的权衡包括：
安全性与证明者时间：使用哈希函数的积极选择、具有更复杂性或更积极的安全假设的证明系统或其他设计选择，可能会减少证明者时间。
去中心化与证明者时间：社区需要就其目标证明者硬件的“规范”达成一致。要求证明者是大规模实体可以吗？我们是否希望高端消费笔记本电脑能够在 4 秒内证明以太坊区块？介于两者之间的东西吗？
破坏向后兼容性的程度：其他领域的不足可以通过进行更积极的 Gas 成本更改来弥补，但这更有可能不成比例地增加某些应用程序的成本，并迫使开发人员重写和重新部署代码，以便保持经济可行性。同样，“帽子里的兔子”也有其自身的复杂性和缺点。
它如何与路线图的其他部分交互？
在第 1 层实现 EVM 有效性证明所需的核心技术与其他两个领域大量共享：
第 2 层的有效性证明（即“ZK rollups”）
“STARK 二进制哈希证明”无状态方法
在第 1 层成功实施有效性证明可以实现最终的轻松单独质押：即使是最弱的计算机（包括手机或智能手表）也能够进行质押。这进一步增加了解决单独质押其他限制的价值（例如最低 32 ETH）。
此外，L1 的 EVM 有效性证明可以显著提高 L1 的 Gas 限制。
共识的有效性证明
我们要解决什么问题？
如果我们希望能够用 SNARK 完全验证以太坊区块，那么 EVM 执行并不是我们需要证明的唯一部分。我们还需要证明共识：系统中处理存款、取款、签名、验证者余额更新以及以太坊权益证明部分的其他元素的部分。
共识比 EVM 简单得多，但它面临的挑战是我们没有第 2 层 EVM 汇总，这也是大多数工作无论如何都要完成的原因。因此，任何证明以太坊共识的实现都需要“从头开始”完成，尽管证明系统本身是可以构建在其之上的共享工作。
它是什么以及它是如何工作的？
信标链被定义为状态转换函数，就像 EVM 一样。状态转移函数由三个因素决定：
ECADD（用于验证 BLS 签名）
配对（用于验证 BLS 签名）
SHA256 哈希（用于读取和更新状态）
在每个区块中，我们需要为每个验证器证明 1-16 个 BLS12-381 ECADD（可能不止一个，因为签名可以包含在多个聚合中）。这可以通过子集预计算技术来补偿，因此我们可以说每个验证器都是一个 BLS12-381 ECADD。如今，每个时段都有约 30,000 名验证者签名。将来，对于单时隙最终确定性，这可能会向任一方向发生变化（请参阅此处的说明）：如果我们采取“强力”路线，则每个时隙可能会增加到 100 万个验证器。同时，使用 Orbit SSF，它将保持在 32,768，甚至减少到 8,1。
BLS 聚合的工作原理。验证聚合签名仅需要每个参与者的 ECADD，而不是 ECMUL。但 30,000 个 ECADD 仍然有很多需要证明的地方。
对于配对，当前每个插槽最多有 128 个证明，这意味着需要验证 128 个配对。通过 EIP-7549 和进一步的更改，这可能会减少到每个插槽 16 个。配对数量很少，但成本极高：每一对的运行（或证明）时间比 ECADD 长数千倍。
证明 BLS12-381 操作的一个主要挑战是没有方便的曲线，其曲线阶数等于 BLS12-381 字段大小，这给任何证明系统增加了相当大的开销。另一方面，为以太坊提出的 Verkle 树是用 Bandersnatch 曲线构建的，这使得 BLS12-381 本身成为 SNARK 系统中用来证明 Verkle 分支的自然曲线。一个相当简单的实现每秒可以提供约 100 个 G1 添加；几乎肯定需要像 GKR 这样的聪明技术才能足够快地证明。
对于 SHA256 哈希值，目前最糟糕的情况是纪元转换块，其中整个验证器短平衡树和大量验证器余额都会更新。验证器短平衡树每个验证器只有一个字节，因此约 1 MB 的数据会被重新散列。这相当于 32,768 次 SHA256 调用。如果一千个验证者的余额高于或低于阈值，则需要更新验证者记录中的有效余额，这对应于一千个 Merkle 分支，因此可能还有一万个哈希值。混洗机制需要每个验证器 90 位（因此需要 11 MB 数据），但这可以在一个 epoch 过程中的任何时间进行计算。对于单时隙最终性，这些数字可能会根据细节再次增加或减少。洗牌变得不必要，尽管轨道可能会在某种程度上恢复对洗牌的需要。
另一个挑战是需要读取所有验证器状态（包括公钥）才能验证块。对于 100 万个验证器，加上 Merkle 分支，仅读取公钥就需要 4800 万字节。这需要每个时期数百万个哈希值。如果我们今天必须证明权益证明验证，那么一种现实的方法是某种形式的增量可验证计算：在证明系统中存储一个单独的数据结构，该数据结构针对高效查找进行了优化，并提供对此结构的更新。
总而言之，存在很多挑战。
要最有效地解决这些挑战很可能需要对信标链进行深入的重新设计，这可能与切换到单时隙最终性同时发生。此次重新设计的特点可能包括：
哈希函数更改：今天，使用“完整”SHA256 哈希函数，因此由于填充，每个调用对应于两个底层压缩函数调用。至少，我们可以通过切换到 SHA256 压缩功能来获得 2 倍的增益。如果我们改用 Poseidon，我们可以获得大约 100 倍的增益，这可以完全解决我们所有的问题（至少对于哈希）：每秒 170 万个哈希（54 MB），甚至可以“读取一百万个验证器记录” ” “几秒钟内就可以证明。
如果是 Orbit，则直接存储打乱的验证者记录：如果您选择一定数量的验证者（例如 8,192 或 32,768）作为给定槽的委员会，则将它们直接放入彼此相邻的状态，以便最小哈希量为需要将所有验证器公钥读入证明中。这也将使所有余额更新能够有效地完成。
签名聚合：任何高性能签名聚合方案实际上都会涉及某种递归证明，其中签名子集的中间证明将由网络中的各个节点进行。这自然地将证明负载分散到网络中的许多节点上，从而使“最终证明者”的工作量小得多。
其他签名方案：对于Lamport Merkle签名，我们需要256 32个哈希来验证签名；乘以 32,768 个签名者得到 9,437,184 个哈希值。对签名方案的优化可以通过一个小的常数因子进一步改善这一点。如果我们使用波塞冬，这在单个槽内证明的范围内。但实际上，通过递归聚合方案，这会变得更快。
与现有研究有哪些联系？
简洁，以太坊共识证明（仅限同步委员会）：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
还需要做什么，需要权衡什么？
实际上，我们需要数年时间才能得到以太坊共识的有效性证明。这与我们需要实现单槽最终性、轨道、签名算法的更改以及潜在的安全分析所需的时间线大致相同，以便有足够的信心使用像 Poseidon 这样的“激进”哈希函数。因此，解决这些其他问题是最有意义的，并且在做这些工作时要牢记 STARK 友好性。
主要的权衡很可能是在操作顺序上，在改革以太坊共识层的更渐进的方法和更激进的“一次进行许多改变”的方法之间。对于 EVM，增量方法很有意义，因为它可以最大限度地减少对向后兼容性的破坏。对于共识层来说，向后兼容性问题较小，并且更“全面”地重新思考信标链如何构建的各种细节，以最好地优化 SNARK 友好性是有好处的。
它如何与路线图的其他部分交互？
STARK 友好性需要成为以太坊权益证明共识的长期重新设计的主要关注点，最显著的是单槽最终性、Orbit、签名方案的更改和签名聚合。
