交易所注册链接， ～40%折扣 insight加密货币套利会员群
按：本文为以太坊创始人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 旨在改变这一现状，让完全验证链的计算成本变得如此低廉，以至于每个移动钱包、浏览器钱包，甚至智能手表都默认这样做。
最初，“Verge”指的是将以太坊状态存储转移到 Verkle 树的想法 - 这种树结构允许更紧凑的证明，从而实现以太坊区块的无状态验证。节点可以在其硬盘上没有任何以太坊状态（账户余额、合约代码、存储……）的情况下验证以太坊区块，但代价是花费几百千字节的证明数据和几百毫秒的额外时间来验证证明。如今，Verge 代表了一个更大的愿景，专注于实现以太坊链的最大资源效率验证，其中不仅包括无状态验证技术，还包括使用 SNARK 验证所有以太坊执行。
除了长期关注 SNARK 验证整个链之外，另一个新问题与 Verkle 树是否是最好的技术有关。 Verkle 树很容易受到量子计算机的攻击，因此，如果我们用 Verkle 树替换当前的 KECCAK Merkle Patricia 树，我们稍后将不得不再次替换这些树。 Merkle 树的自然替代方案是直接跳到在二叉树中使用 STARK Merkle 分支。从历史上看，由于开销和技术复杂性，这被认为是不可行的。然而，最近，我们看到 Starkware 在带有 Circle STARK 的笔记本电脑上证明了每秒 170 万次 Poseidon 哈希值，并且由于 GKR 等技术，更多“传统”哈希值的证明时间也在迅速缩短。
因此，在过去的一年里，Verge 变得更加开放，并且存在多种可能性。
在本文中重点介绍以下内容：
如今，以太坊客户端需要存储数百GB的状态数据才能验证区块，并且这个数量每年都在持续增加。原始状态数据每年增加约 30 GB，个人客户端除了能够有效更新 trie 之外还必须存储一些额外的数据。
这减少了可以运行完全验证以太坊节点的用户数量：尽管硬盘驱动器足够大，可以存储所有以太坊状态甚至多年的历史记录，但人们默认购买的计算机往往只有几百个千兆字节的存储空间。状态大小还会给首次设置节点的过程带来很大的麻烦：节点需要下载整个状态，这可能需要数小时或数天的时间。这会产生各种连锁反应。例如，这使得质押者升级其质押设置变得更加困难。从技术上讲，可以在不停机的情况下完成此操作 - 启动新客户端，等待其同步，然后关闭旧客户端并传输密钥 —— 但实际上，这在技术上很复杂。
无状态验证是一种允许节点在不拥有完整状态的情况下验证区块的技术。相反，每个区块都带有一个见证人，其中包括（i）该区块将访问的状态中特定位置的值（例如代码、余额、存储），以及（ii）这些值的加密证明是正确的。
实际实现无状态验证需要改变以太坊状态树结构。这是因为当前的 Merkle Patricia 树对于实现任何密码证明方案都极其不友好，尤其是在最坏的情况下。对于“原始”Merkle 分支以及将 Merkle 分支“包装”在 STARK 中的可能性都是如此。主要困难源于 MPT 的两个弱点：
我们可以计算最坏的情况如下：
30,000,000 Gas / 2,400（“冷”账户读取成本）* (5 * 480 + 24,000) = 330,000,000 字节
分支成本略有下降（5480 而不是 8480），因为当分支数量很多时，分支的顶部会重复。但即便如此，在一个插槽内下载的数据量也是完全不切实际的。如果我们尝试将其包装在 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 树使用基于椭圆曲线的向量承诺来做出更短的证明。关键在于，无论树的宽度如何，每个父子关系对应的证明片段只有 32 个字节。树宽度的唯一限制是，如果树太宽，证明的计算效率就会降低。以太坊的建议实现宽度为 256。
因此，证明中单个分支的大小变为 32log256(N) = 4log2(N) 字节。理论上的最大证明大小变为大约 30,000,000/2,40032(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 友好性而设计的。然而，波塞冬相对不成熟，因此许多人还不信任它的安全性。因此，有两条现实的前进道路：
在撰写本文时，Starkware 的 STARK 证明者如果要证明保守的哈希函数，则只能在消费笔记本电脑上每秒证明约 10-30k 哈希值。然而，STARK技术正在迅速进步。即使在今天，基于 GKR 的技术也显示出有望将其提高到约 100-200k 范围的潜力。
除了验证块之外，还有其他三个关键用例可以实现更高效的无状态验证：
所有这些用例的一个共同点是它们需要相当大量的证明，但每个证明都很小。因此，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/
剩下要做的主要工作是：
我们很快就会做出选择以下三个选项中的哪一个的决策点：(i) Verkle 树，(ii) STARK 友好的哈希函数，以及 (iii) 保守哈希函数。它们的属性可以大致总结如下表：
除了这些“标题数字”之外，还有一些其他重要的考虑因素：
如果我们希望Verkle见证的可更新性以一种量子安全且相当高效的方式进行，另一种可能的途径是基于网格的Merkle树。
如果证明系统在最坏的情况下不够有效，我们可以使用另一个“帽子里的兔子”来弥补这种不足，那就是多维Gas：对(i) calldata、（ii）计算、（iii）状态访问以及可能的其他不同资源有单独的Gas限制。多维Gas增加了复杂性，但作为交换，它更严格地限制了平均情况和最坏情况之间的比率。对于多维Gas，要证明的理论最大分支数可能会从30,000,000 / 2400 = 12,500减少到3000。 这将使BLAKE3（勉强）即使在今天也足够了，没有进一步的证明改进。
另一个“突然出现的兔子”是延迟状态根计算直到块之后的槽的提议。这将为我们提供整整 12 秒的时间来计算状态根，这意味着即使在最极端的情况下，只有约 60,000 次哈希/秒的证明时间就足够了，这再次将我们置于 BLAKE3 勉强够用的范围内。
这种方法的缺点是，它会增加轻客户端延迟一个时间段，尽管该技术有更聪明的版本可以将这种延迟减少到仅证明生成延迟。例如，只要任何节点生成证明，就可以在网络上广播该证明，而不是等待下一个块。
解决无状态问题大大增加了单独质押的便利性。如果能够降低单独质押最低余额的技术（例如 Orbit SSF 或应用层策略（例如小队质押））变得可用，那么这将变得更有价值。
如果同时引入 EOF，多维Gas会变得更容易。这是因为用于执行的多维 Gas 的一个关键复杂性是处理不传递父调用的完整 Gas 的子调用，而 EOF 通过简单地使此类子调用非法（并且本机帐户抽象将提供一个 in -当前部分Gas子调用主要用例的协议替代方案）。
另一项重要的协同作用是无状态验证和历史过期之间的协同作用。如今，客户必须存储近 TB 的历史数据；这个数据比国家数据大几倍。即使客户端是无国籍的，除非我们也能减轻客户端存储历史的责任，否则客户端几乎无存储的梦想也无法实现。这方面的第一步是 EIP-4444，这也意味着将历史数据存储在 torrent 或 Portal 网络中。
以太坊区块验证的长期目标很明确：您应该能够通过以下方式验证以太坊区块：(i) 下载该区块，甚至可能仅下载该区块的一小部分并进行数据可用性采样，以及 (ii) 验证一小部分证明该块是有效的。这将是一个资源消耗极少的操作，可以在移动客户端、浏览器钱包内甚至（没有数据可用性部分）在另一个链中完成。
要达到这一点，需要拥有 (i) 共识层（即权益证明）和 (ii) 执行层（即 EVM）的 SNARK 或 STARK 证明。前者本身就是一个挑战，应该在进一步改进共识层的过程中解决（例如，单槽最终确定性）。后者需要 EVM 执行的证明。
正式地，在以太坊规范中，EVM 被定义为状态转换函数：你有一些前状态 S、一个区块 B，并且你正在计算一个后状态 S' = STF(S, B)。如果用户使用的是轻客户端，他们就没有S和S'，甚至没有完整的B；相反，它们有一个前状态根 R、一个后状态根 R' 和一个块哈希 H。需要证明的完整语句大约为：
如果存在，您就可以拥有一个可以完全验证以太坊 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 或底层 VM（如 RISC-V））。使这变得不完全微不足道的一个关键实现挑战是需要确保VM的“内存”在证明的不同部分之间是一致的。然而，如果我们可以进行这种递归证明，那么我们知道至少证明者延迟问题得到了解决，即使在任何其他轴上没有任何改进。
除此之外，上一节中提到的两个“从帽子里出来的兔子”（多维Gas和延迟状态根）也可以在这里提供帮助。然而，值得注意的是，与无状态验证不同，无状态验证意味着我们有足够的技术来完成我们今天所需要的事情，即使使用这些技术，完整的 ZK-EVM 验证也将需要更多的工作 —— 只是需要更少的工作工作。
上面没有提到的一件事是证明硬件：使用 GPU、FPGA 和 ASIC 更快地生成证明。 Fabric Cryptography、Cysic 和 Accseal 是这三家公司的推动者。这对于第 2 层来说非常有价值，但它不太可能成为第 1 层的决定性考虑因素，因为人们强烈希望保持第 1 层高度去中心化，这意味着证明生成必须在相当大的子集的能力范围内。以太坊用户，不应该遇到单一公司硬件的瓶颈。第 2 层可以做出更激进的权衡。
这些领域还有更多工作要做：
这里可能的权衡包括：
在第 1 层实现 EVM 有效性证明所需的核心技术与其他两个领域大量共享：
在第 1 层成功实施有效性证明可以实现最终的轻松单独质押：即使是最弱的计算机（包括手机或智能手表）也能够进行质押。这进一步增加了解决单独质押其他限制的价值（例如最低 32 ETH）。
此外，L1 的 EVM 有效性证明可以显著提高 L1 的 Gas 限制。
如果我们希望能够用 SNARK 完全验证以太坊区块，那么 EVM 执行并不是我们需要证明的唯一部分。我们还需要证明共识：系统中处理存款、取款、签名、验证者余额更新以及以太坊权益证明部分的其他元素的部分。
共识比 EVM 简单得多，但它面临的挑战是我们没有第 2 层 EVM 汇总，这也是大多数工作无论如何都要完成的原因。因此，任何证明以太坊共识的实现都需要“从头开始”完成，尽管证明系统本身是可以构建在其之上的共享工作。
信标链被定义为状态转换函数，就像 EVM 一样。状态转移函数由三个因素决定：
在每个区块中，我们需要为每个验证器证明 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 万字节。这需要每个时期数百万个哈希值。如果我们今天必须证明权益证明验证，那么一种现实的方法是某种形式的增量可验证计算：在证明系统中存储一个单独的数据结构，该数据结构针对高效查找进行了优化，并提供对此结构的更新。
总而言之，存在很多挑战。
要最有效地解决这些挑战很可能需要对信标链进行深入的重新设计，这可能与切换到单时隙最终性同时发生。此次重新设计的特点可能包括：
简洁，以太坊共识证明（仅限同步委员会）：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、签名方案的更改和签名聚合。