以太坊的未来之路：The Verge 计划

区块链**大的特性之一，就是**人都可以运行节点，验证链的真实性。即使大部分节点突然串通一气，修改规则，诚实验证的节点也会拒绝接受这条篡改后的链，并自动汇聚到遵循旧规则的链上，继续构建它。

推广

币安交易所

新用户注册充值交易，享空投奖励 **交易比特币享7天价格保护 立即下载APP 扫描二维码下载官方应用，开启交易之旅 全球**交易平台 安全可信赖 500 交易对 99.9% 稳定性 投资需谨慎 | 广告

这是区块链与**化系统的根本区别。但要保证这一特性，就需要让足够多的人能够轻松运行完整验证的节点。目前，在普通电脑上运行节点是可行的，但并不容易。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

我们要解决什么问题？

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

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

它是如何工作的？

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

实际上，实现无状态验证需要改变以太坊的状态树结构。这是因为当前的 Merkle Patricia 树对于实施**加密证明方案都是极端不友好的，尤其是在最坏的情况下。无论是 "原始 "Merblk 分枝，还是"包装"成 STARK 的可能性，都是如此。主要困难源于 MPT 的一些弱点：

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

2.代码未被 Merkle 化。这意味着要证明账户代码的**访问权限，都需要提供整个代码，最多为 24000 字节。

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

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

分支成本略有**（用 5* 480 代替 8* 480），因为当分支较多时，其顶端部分会重复出现。但即便如此，在一个时隙内要下载的数据量也是**不现实的。如果我们尝试用 STARK 来封装它，就会遇到两个问题：(i) KECCAK 对 STARK 相对不友好；(ii) 330 MB 的数据意味着我们必须证明对 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 - 1 og 256(N) = 4* log 2(N)字节。因此，理论上的**证明大小大致为 30000000 / 2400 * 32* ( 32 -14 8) / 8 = 130000 字节（由于状态块的分布不均匀，实际计算结果略有不同， 但作为**近似值是可以的）。

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

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

STARKed 二进制哈希树

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

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

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

快速对 Poseidon 进行大量安全分析，并对其足够熟悉，以便在L1进行部署

使用更 "保守 "的哈希函数，如 SHA 256 或 BLAKE

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

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

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

内存池：当交易被广播时，P2P网络中的节点需要在重新广播之前验证交易是否有效。如今验证包括验证签名，还包括检查余额是否充足和前缀是否正确。在未来（例如，使用原生账户抽象，如 EIP-7701 ，这可能会涉及运行一些 EVM 代码，这些代码会进行一些状态访问。如果节点是无状态的，则交易需要附带证明状态对象的证明。

包含列表：这是一个提议的功能，允许（可能规模较小且不复杂的）权益证明验证者强制下一个区块包含交易，而不管（可能规模较大且复杂的）区块构建者的意愿。这将削弱有权势者通过延迟交易来操纵区块链的能力。不过，这需要验证者有办法验证包含列表中交易的有效性。

轻客户端：如果我们希望用户通过wallet访问链（如 Metamask、Rainbow、Rabby 等），要做到这一点，他们需要运行轻型客户端（如 Helios).Helios 核心模块为用户提供经过验证的状态根。而为了获得**无信任的体验，用户需要为他们所做的每个 RPC 调用提供证明（例如，对于以太网调用请求（用户需要证明在调用过程中访问的所有状态）。

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

与现有研究有哪些联系：

Verkle trees

John Kuszmaul 关于 Verkle tree 的原始论文

Starkware

Poseidon 2 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 。这将使 BLAKE 3 即使在今天也（勉强）够用。

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

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

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

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

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

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

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

EVM 执行的有效性证明

我们要解决什么问题？

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

要达到这一点，需要对（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 的计算，并且不存在漏洞。提高安全性的两种主要技术是多验证器和形式验证。多验证器指的是有多个独立编写的有效性证明实现，就像有多个客户端一样，如果一个区块被这些实现中的一个足够大的子集证明，客户端就会接受该区块。形式验证涉及使用通常用于证明数学定理的工具，如 Lean 4 ，以证明有效性证明只接受正确执行底层 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 更友好的方法替换状态树外，我们

本文 巴适财经 原创，转载保留链接！网址：/article/1127762.html