以太坊可能的未来TheVerge！区块链最强大的功能之一就是任何人都可以在自己的电脑上运行一个节点，并验证区块链的正确性。即使9596个运行链共识（PoW、PoS）的节点都立即同意更改规则，并开始根据新规则生产区块，每个运行完全验证节点的人都会拒绝接受链。不属于这种阴谋集团的造币者会自动汇聚到一条继续遵循旧规则的链上，并继续构建这条链，而完全通过验证的用户将遵循这条链。
这是区块链与中心化系统的关键区别。然而，要使这一特性成立，运行一个完全验证的节点需要对足够多的人来说确实可行。这既适用于造势者（因为如果造势者不验证链，他们就没有为执行协议规则做出贡献），也适用于普通用户。如今，在消费类笔记本电脑（包括写这篇文章时使用的笔记本电脑）上运行节点是可能的，但要做到这一点却很困难。TheVerge就是要改变这种状况，让完全验证链的计算成本变得低廉，让每个手机钱包、浏览器钱包甚至智能手表都会默认进行验证。
TheVerge2023路线图
最初，Verge指的是将以太坊状态存储转移到Verkle树一种允许更紧凑证明的树形结构，可实现以太坊区块的无状态验证。节点可以验证一个以太坊区块，而无需在其硬盘上存储任何以太坊状态（账户余额、合约代码、存储空间......），代价是花费几百KB的证明数据和几百毫秒的额外时间来验证一个证明。如今，Verge代表了一个更大的愿景，专注于实现以太坊链的最大资源效率验证，其中不仅包括无状态验证技术，还包括使用SNARK验证所有以太坊执行。
除了对SNARK验证整条链的长期关注之外，另一个新问题与Verkle树是否是最佳技术有关。Verkle树容易受到量子计算机的攻击，因此，如果我们将目前的KECCAKMerklePatricia树中的Verkle树，我们以后还得再次替换树。Merkle树的自替代方法是直接跳过使用Merkle分支的STARK，将其放入二叉树。从历史上看，由于开销和技术复杂性，这种方法一直被认为是不可行的。不过最近，我们看到Starkware在一台笔记本电脑上使用ckcleSTARKs每秒证明了170万个Poseidon哈希，而且由于GKB等技术的出现，更多传统哈希值的证明时间也在迅速缩短。因此，在过去的一年里，Verge变得更加开放，它有几种可能性。
TheVerge：关键目标
无状态客户机：完全验证客户机和标记节点所需的存储空间不应超过几GB。
(长期）在智能手表上完全验证链（共识和执行）。下载一些数据，验证SNARK，完成。
在本章中
无状态客户机：Verkle还是STARKs
EVM执行的有效性证明
共识的有效性证明
如今，以太坊客户端需要存储数百千兆字节的状态数据来验证区块，而且这一数量每年都在增加。原始状态数据每年增加约30GB，单个客户端必须在上面存储一些额外的数据，才能有效地更新三元组。
这就减少了能够运行完全验证以太坊节点的用户数量：尽管足以存储所有以太坊状态甚至多年历史的大硬盘随处可见，但人们默认购买的电脑往往只有几百千兆字节的存储空间。状态大小也给首次建立节点的过程带来了巨大的摩擦：节点需要下载整个状态，这可能需要数小时或数天的时间。这会产生各种连锁反应。例如，它大大增加了节点制作者升级其节点设置的难度。从技术上讲，可以在不停机的情况下完成升级启动一个新客户端，等待它同步，后关闭旧客户端并传输密钥但在实际操作中，这在技术上非常复杂。
无状态验证是一种允许节点在不掌握整个状态的情况下验证区块的技术。取而代之的是，每个区块都附带一个见证，其中包括：(i)该区块将访问的状态中特定位置的值、代码、余额、存储；(ii)证明这些值正确的加密证明。
实际上，实现无状态验证需要改变以太坊的状态树结构。这是因为当前的MerklePatricia树对于实施任何加密证明方案都是极端不友好的，尤其是在最坏的情况下。无论是原始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字节。
我们可以计算出最坏的情况如下：
30000000gas/2400(冷账户阅读成本)*（5*488+24000)=330000000字节
分支成本略有降低（用5*480代替8*480），因为当分支较多时，其顶端部分会重复出现。但即便如此，在一个时隙内要下载的数据量也是完全不现实的。如果我们尝试用STARK来封装它，就会遇到两个问题：(i)KECCAK对STARK相对不友好；(ii)330MB的数据意味着我们必须证明对KECCAKround函数的500万次调用，这对于除了最强大的消费级硬件之外的所有硬件来说，都可能证明不了，即使我们能让STARK证明KECCAK的效率更高。
如果我们直接用二叉树代替十六进制树，并对代码进行额外的Merkle化处理，那么最坏的情况大致会变成30000000/2400*32*(32-14+8)=10400000字节（14是对2^14分支的冗余位进行的减法，而8则是进入代码块中叶的证明的长度）。需要注意的是，这需要改变gas成本，对访问每个单独的代码块收费；EIP-4762就是这么做的。10.4MB的容量要好得多，但对于许多节点来说，在一个时隙内下载的数据还是太多了。因此，我们需要引入更强大的技术。在这方面，有两种领先的解决方案：Verkle树和STARKed二进制哈希树。
Verkle树使用基于椭圆曲线的矢量承诺来进行更短的证明。解锁的关键在于，无论树的宽度如何，每个父子关系对应的证明部分都只有32字节。证明树宽度的唯一限制是，如果证明树过宽，证明的计算效率就会降低。为以太坊提出的实现方案宽度为256。
因此，证明中单个分支的大小变为32-1og256(N)=4*log2(N)字节。因此，理论上的最大证明大小大致为30000000/2400*32*(32-14+8)/8=130000字节（由于状态块的分布不均匀，实际计算结果略有不同，但作为第一近似值是可以的）。
另外需要注意的是，在上述所有示例中，这种最坏情况并不是最坏情况：更坏的情况是攻击者故意挖掘两个地址，使其在树中具有较长的共同前缀，并从其中一个地址读取数据，这可能会将最坏情况下的分支长度再延长2倍。但即使有这样的情况，Verkle树的最坏证明长度为2.6MB，与目前最坏情况下的校验数据基本吻合。
我们还利用这一注意事项做了另一件事：我们让访问相邻存储空间的成本变得非常低廉：要么是相同合同的许多代码块，要么是相邻的存储槽。EIP-4762提供了邻接的定义，对邻接访问只收取200gas费。在相邻访问的情况下，最坏情况下的证明大小变为30000000/200*32-4800800字节，这仍大致在公差范围内。如果为了安全起见，我们希望减少这个值，可以稍微增加相邻访问的费用。
这项技术的原理不言自明：你只需做一棵二叉树，获取最大10.4MB的证明，证明块中的值，后用证明的STARK代替证明。这样，证明本身就只包含被证明的数据，再加上来自实际STARK的100-300kB固定开销。
这里的主要挑战是验证时间。我们可以进行与上述基本相同的计算，只不过我们计算的不是字节数，而是哈希值。一个10.4MB的区块意味着330000个哈希值。如果再加上攻击者挖掘地址树中具有较长公共前缀的可能性，那么最坏情况下的哈希值将达到约660000哈希值。因此，如果我们能证明每秒的哈希值为200,000，那就没问题了。
在使用Poseidon哈希函数的消费类笔记本电脑上，这些数字已经达到，而Poseidon哈希函数是专门为STARK友好性而设计的。但是，Poseidon系统还相对不成熟，因此很多人还不信任它的安全性。因此，有两条现实的前进道路：
快速对Poseidon进行大量安全分析，并对其足够熟悉，以便在L1进行部署
使用更保守的哈希函数，如SHA256或BLAKE
如果要证明保守的哈希函数，Starkware的STARK圈在撰写本文时只能在消费类笔记本电脑上每秒证明10-30k哈希值。不过，STARK技术正在迅速改进。即使在今天，基于GKR的技术也显示出将这一速度提高到100-2O0k范围。
以上就是The Verge是什么？以太坊可能的未来The Verge的全部内容，望能这篇The Verge是什么？以太坊可能的未来The Verge可以帮助您解决问题，能够解决大家的实际问题是非常好学习网一直努力的方向和目标。