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

原文作者：cookies原文编译：深潮 TechFlow

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

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

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

1.类型 1：完全等同于以太坊；

2.类型 2：完全等同于 EVM；

3.类型 2.5：部分等同于 EVM；

4.类型 3：几乎等同于 EVM；

5.类型 4：其中的高级语言等同。

类型 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 字节码上。

项目

zkSync

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

查看更多

—-

编译者/作者：深潮TechFlow

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。