mt logoMyToken
Market cap:
0%
FGI:
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

V神最担心的“zkEVM多客户端问题”,终于有解决方案了

Collect
Share

本文来自 cryptoslate ,原文作者:Liam 'Akiba' Wright

Odaily 星球日报译者 | Moni

 

V神最担心的“zkEVM多客户端问题”,终于有解决方案了

3 月 31 日,以太坊联合 创始人 “V 神” Vitalik Buterin 在其官方博客上发布文章《以太坊的多客户端理念将如何与 ZK-EVM 交互?》(How will Ethereum's multi-client philosophy interact with ZK-EVMs?),分享了他对以太坊生态系统“未被充分讨论但非常重要”的方面的思考,其中深入探讨了为 ZK-EVM 创建多客户端生态系统的 技术 挑战、生态系统权衡和潜在解决方案。

接下来,让我们来解读这篇文章的关键要点。

Zk-EVM 的多客户端问题

Vitalik Buterin 相信 ZK-EVM 将在未来发展成为以太坊 Layer 1 安全 和验证过程的重要组成部分,零知识 (ZK) 技术也能让开发人员在不透露任何额外信息的情况下证明交易或消息的真实性。

这意味着,交易一方可以说服另一方其发出的消息是真实有效的,而无需透露消息有效性以外的任何知识。然而,根据 Vitalik Buterin 的分析,零知识证明技术的隐私保护性质可能会破坏更广泛的 EVM 格局,因为以太坊客户端在实施协议规则方面存在细微差别。

现阶段,ZK Rollups 中的二层协议已成功使用零知识证明技术,并通过将多个交易捆绑到一个证明中来帮助扩展以太坊区块链。然而,随着 ZK-EVM 发展到验证主网上的交易执行,Vitalik Buterin 认为“ZK-EVM 实际上成为了第三种以太坊客户端,与当前其他执行客户端和共识客户端一样,对以太坊网络的安全至关重要。”

不过,一旦将 ZK-EVM 视为第三种类型的以太坊客户端,Vitalik Buterin 提出了以下这样一个问题:

“实际上,我们该如何为基于零知识证明以太坊区块的正确性创建一个“多客户端”生态系统?”

随着以太坊生态系统的不断扩展,Vitalik Buterin 希望保持“多客户端理念”的优势,同时利用 ZK-EVM 的功能来提高以太坊网络的可扩展性、安全性和去中心化性。

根据 Vitalik Buterin 的说法,将零知识证明技术用于多个客户端的主要技术挑战与延迟和数据效率低下有关。此外,由于对协议规则或 ZK-EVM 实现的特定解释,各个不同以太坊客户端处理零知识证明的方式也不一样。

那么,这些问题该如何解决呢?Vitalik Buterin 给出了解决方案——

ZK-EVM 多客户端解决方案

尽管以太坊生态存在上述这些挑战,但 Vitalik Buterin 认为创建一个开放的多客户端 ZK-EVM 生态系统是完全可行的,并且有利于以太坊的安全性和去中心化,下图是以太坊生态系统的共识层和执行层中使用各种不同客户端的可视化表示。

V神最担心的“zkEVM多客户端问题”,终于有解决方案了

资料来源:vitalik.eth.limo

Vitalik Buterin 相信,拥有多个客户端可以降低一次实施中出现单个灾难性错误的风险,从而提高网络的安全性和去中心化程度,而这种错误可能会导致整个以太坊网络崩溃。此外,多客户理念也有助于防止权力集中在一个开发团队或组织内,继而更好地实现网络去中心化。

针对上述提及的 ZK-EVm 多客户端问题,Vitalik Buterin 提出了三种可能的解决方案:

1、单一的 ZK-EVM:放弃多客户端范式,选择用来验证区块的单一 ZK-EVM。

2、封闭的多个 ZK-EVM:就一组特定的多个 ZK-EVM 达成一致并达成共识,并有一个共识层协议规则,即一个区块需要来自该集合中超过一半的 ZK-EVM 的证明才能被认为是有效的.

3、开放的多个 ZK-EVM:不同的客户端有不同的 ZK-EVM 实现,每个客户端在接受一个区块为有效之前等待与自己的实现兼容的证明。”

在 ZK-EVM 的背景下,Vitalik Buterin 支持第三种,也就是开放的多个客户端 ZK-EVM 生态系统的解决方案,他认为不同的客户端有不同的 ZK-EVM 实现,每个客户端在接受一个区块为有效之前等待与自己兼容的证明。

“对我来说,第三种解决方案似乎是理想的,至少直到并且除非我们的技术改进到可以正式证明所有 ZK-EVM 实现彼此等效的程度......”

不仅如此,一旦技术改进到 ZK-EVM 实现有些标准化的程度,Vitalik Buterin 认为解决方案将是选择最有效的选项,而他还觉得“第三种解决方案的挑战似乎小于其他两个选项的挑战,至少目前如此。”不过,Vitalik Buterin 提出开放的多个 ZK-EVM 可能会面临两大挑战:

  • 延迟挑战:恶意攻击者可能会延迟发布一个区块,以及对一个客户端有效的证明。生成对其他客户端有效的证明实际上需要很长时间(即使例如 15 秒)。这段时间足够长,可能会创建一个临时 分叉 并中断几个插槽的链。

  • 数据效率低下:ZK-SNARKs 的一个好处是可以从区块中删除仅与验证相关的数据(有时称为“见证数据”)。例如,一旦你验证了一个签名,就不需要将签名保存在一个区块中,你可以只存储一个表示签名有效的位,以及区块中确认所有签名的单个证明。但是,如果希望能够为一个区块生成多种类型的证明,则需要实际发布原始签名。

 

未来 ZK-EVM 将如何进入 Layer 1 ?

选项 1 :限制 Layer 1 ,强制几乎所有活动移动到 Layer 2

随着时间的推移,Vitalik Buterin 建议可以将第 1 层每个区块的 gas 目标从 1500 万减少到 100 万,足以让一个区块包含一个 SNARK 和一些存款和取款操作,但其他的不多,从而强制几乎所有用户活动移动到 Layer 2 协议。

选项 2 :SNARK-验证 Layer 1

Vitalik Buterin 表示可以编写更多的 SNARK 代码来验证区块共识,但这将是一个具有挑战性的工程问题:现阶段,ZK-EVM 需要几分钟到几小时来验证以太坊区块,如果采用该方案则需要:(i)改进以太坊本身以删除对 SNARK 不友好的组件(ii)通过专门的硬件获得巨大的效率提升么 (iii) 通过更多的并行化改进架构。

总结

Vitalik Buterin 总结称,推动一个开放的多客户端 ZK-EVM 生态系统运行良好需要大量的工作。但好消息是,实现这个目标的大部分工作正在发生、或是未来 无论如何 都会发生,因为:

1、以太坊已经有多个强大的 ZK-EVM 实现。

2、在 Helios 和 Succinct 等轻客户端上的工作最终可能会变成对以太坊链的 PoS 共识端进行更全面的 SNARK 验证。

3、客户端可能会开始尝试使用 ZK-EVM 来证明自己的以太坊区块执行,特别是当无状态客户端并且没有技术需要直接重新执行每个区块来维护状态的时候,可能会从客户端通过重新执行它们来验证以太坊区块,再过渡到大多数客户端通过检查 SNARK 证明来验证以太坊区块。

4、ERC-4337 和 PBS 生态系统可能会很快开始使用 BLS 和证明聚合等技术,这样可以节省大量 gas 成本。

值得一提的是,Vitalik Buterin 还对 最近 人工智能技术的快速发展大加赞扬,他觉得人工智能的进步可以“加速”证明 ZK-EVM 实现的发展。“从长远来看,当然任何事情都有可能发生。也许 AI 会加强形式验证,使其可以轻松证明 ZK-EVM 实现等效并识别导致彼此之间差异的所有错误。”

Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content