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

Scan Download

详解ZK-EVM的五种类型:架构、优缺点及解决方案

Collect
Share

原文作者: cookies

原文编译:深潮 TechFlow

本文详细探讨了 ZK-EVM 的五种类型,每种类型都有其独特的架构、优点和缺点,以及可能的解决方案。

此外文章还列举了一些实际的项目例子,以便读者更好地理解这些类型在实际应用中的表现。无论你是区块链开发者,还是对区块链技术感兴趣的读者,这篇文章都将为你提供深入且简洁的洞见。

让我们探讨一下 ZK-EVM 的类型,以及它的优缺点。

1.类型 1 :完全等同于以太坊;

2.类型 2 :完全等同于 EVM;

3.类型 2.5 :部分等同于 EVM;

4.类型 3 :几乎等同于 EVM;

5.类型 4 :其中的高级语言等同。 详解ZK-EVM的五种类型:架构、优缺点及解决方案

类型 1 :完全等同于以太坊

架构:完全同于以太坊且不改变以太坊系统的任何部分。

优点

完美兼容性:

  • 能够验证以太坊区块;

  • 帮助使以太坊 L1 更具可扩展性;

  • 适用于 Rollups,因为它们可以重复使用大量基础设施。

缺点

完美兼容性:

  • 以太坊最初不是为 ZK 功能设计的;

  • 以太坊的许多组件需要大量计算来生成 ZK 证明(ZKP);

  • 以太坊区块的证明需要很多小时才能生成 。

问题的解决方案:

  • 大规模并行化证明者 ;

  • ZK-SNARK ASIC.

类型 2 :完全等同于 EVM

架构:

  • 数据结构(区块结构和状态树)与以太坊有显著区别;

  • 与现有应用程序完全兼容;

  • 对以太坊进行了微小修改,以便更容易开发和更快生成证明。

优点

  • 提供比类型 1 更快的证明时间;

  • 数据结构不直接被 EVM 访问;

  • 在以太坊上运行的应用程序:很可能可以在类型 2 上运行;

  • 支持现有的 EVM 调试工具和其他开发基础设施。

缺点

在了解缺点之前,先了解什么是「Keccak」:

  • 以太坊区块链的哈希算法;

  • 用于保护以太坊上的数据;

  • 确保信息被转换为哈希。

类型 2 与验证历史区块的 Merkle 证明以验证有关历史交易、收据 / 状态的应用程序不兼容。这是因为如果哈希算法发生变化(不再是 Keccak),证明将会失效。

我们可以将 Keccak 看作是一种语言,它使用 Merkle 证明(字母)如果 ZK-EVM 将 Keccak 替换为另一种哈希算法(例如 Poseidon),Merkle 证明将变得陌生,应用程序将无法读取和验证它们的声明。

对缺点的潜在解决方案:以太坊可以添加未来可扩展的历史访问预编译。

项目

  • Scroll ;

  • Polygon Hermez.

然而,这些项目尚未实现更复杂的预编译,因此,它们可以被认为是不完整的类型 2 。

类型 2.5 :部分等同于 EVM

架构:

增加难以进行 ZK 证明的特定 EVM 操作的 Gas 成本;

  • 预编译;

  • Keccak 操作码;

  • 调用合约的模式;

  • 访问内存;

  • 存储。

优点

  • 显著提高最坏情况下的证明时间;

  • 比对 EVM 堆栈进行更深层次的更改更安全。

缺点

  • 开发工具的兼容性降低;

  • 一些应用程序将无法工作。

类型 3 :几乎等同于 EVM

架构:

  • 在 ZK-EVM 实现中,删除了一些异常难以实现的功能,通常是预编译;

  • ZK-EVM 在处理合约代码、内存或堆栈方面存在轻微差异。

优点

  • 缩短验证时间 ;

  • 让 EVM 更容易开发;

  • 目标是对不太兼容的应用程序只需要最少的重写。

缺点

  • 更多的不兼容性;

  • 在类型 3 中删除的使用预编译的应用程序将需要重新编写。

项目

目前,Scroll 和 Polygon 被认为是类型 3 ,然而,ZK-EVM 团队不应满足于成为类型 3 ,类型 3 是 ZK-EVM 添加预编译以提高兼容性并转向类型 2.5 的过渡阶段。

类型 4 :高级语言等同

架构:

  • 接受用高级语言(如 Solidity、Vyper)编写的智能合约代码;

  • 编译为设计为 ZK-SNARK 友好的语言。

优点

  • 非常快的证明时间;

  • 降低开销(成本、时间和计算工作量);

  • 降低成为证明者的门槛:提高去中心化程度。

缺点

  • 在类型 4 系统中,合约的地址可能与 EVM 中的地址不同,因为地址取决于确切的字节码;

  • 这意味着如果类型 4 的 ZK-EVM 没有字节码,它们将无法创建地址;

  • 在上述情况下,类型 4 将与依赖反事实合约的应用不兼容;

  • 许多调试基础设施无法移植,因为它们运行在 EVM 字节码上。

详解ZK-EVM的五种类型:架构、优缺点及解决方案

项目

  • zkSync

最后,我们可以将上述的几种类型放在一起做一个比较,帮助大家一目了然的理解不同的 zkEVM。

详解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