波宝官网app|ZK-EVM五种类型：与以太坊「完全、部分、几乎等效」差在哪？ | 动区动趋-最具影响力的区块链新闻媒体

本文探讨 ZK-EVM 的五种型别，每种型别都有独特的架构、优点和缺点，以及可能的解决方案，无论是区块链开发者，还是对区块链技术感兴趣的读者都值得一读，由作者 cookies 撰文。 （前情提要：ZK加上AI，新专案Noya如何最大化流动性挖矿收益？ ） （背景补充：Polygon zkEVM 是什么？一文盘点链上生态、潜力项目… ）

本文目录

• 型别 1 ：完全等同于以太坊
  • 优点
  • 缺点
• 型别 2 ：完全等同于 EVM
  • 优点
  • 缺点
  • 项目
• 型别 2.5 ：部分等同于 EVM
  • 优点
  • 缺点
• 型别 3 ：几乎等同于 EVM
  • 优点
  • 缺点
  • 项目
• 型别 4 ：高阶语言等同
  • 优点
  • 缺点
  • 项目

本文详细探讨了 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」：

• 以太坊区块链的 hash 演算法；
• 用于保护以太坊上的资料；
• 确保资讯被转换为hash。

型别 2 与验证历史区块的 Merkle 证明以验证有关历史交易、收据 / 状态的应用程式不相容。这是因为如果 hash演算法发生变化（不再是 Keccak），证明将会失效。

我们可以将 Keccak 看作是一种语言，它使用 Merkle 证明（字母）如果 ZK-EVM 将 Keccak 替换为另一种 hash演算法（例如 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。