你真的了解ZK-EVM吗？

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

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

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

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

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

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

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

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

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

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

类型 1 | 优点

完美兼容性：

· 能够验证以太坊区块；

· 帮助使以太坊 L1 更具可扩展性；

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

类型 1 | 缺点

完美兼容性：

· 以太坊最初不是为 ZK 功能设计的；

· 以太坊的许多组件需要大量计算来生成 ZK 证明（ZKP）；

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

问题的解决方案：

· 大规模并行化证明者 ；

· ZK-SNARK ASIC.

类型 2 | 完全等同于 EVM

架构：

· 数据结构（区块结构和状态树）与以太坊有显著区别；

· 与现有应用程序完全兼容；

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

类型 2 | 优点

· 提供比类型 1 更快的证明时间；

· 数据结构不直接被 EVM 访问；

· 在以太坊上运行的应用程序：很可能可以在类型 2 上运行；

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

类型 2 | 缺点

在了解缺点之前，先了解什么是“Keccak” ：

· 以太坊区块链的哈希算法；

· 用于保护以太坊上的数据；

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

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

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

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

类型 2 的项目

· Scroll;

关于【ZK-EVM 的五种类型：特性、优缺点及应用实例一览】的延伸阅读

• Movement的公链新解：“将 Move 引入 EVM”如何重塑以太坊与 Move？

  LFG Labs推出基于Move语言的以太坊L2，旨在将Move系智能合约的安全性和高性能与EVM系的流动性和用户群结合。Movement SDK提供了模块化的MoveVM虚拟机、编译器和自定义适配器，解决了Move生态系统的破碎化问题。M1和M2公链架构集成了以太坊虚拟机，允许开发者在M2上启动并引入EVM系的DApp。M2使用零知识证明提高隐私和安全性，同时支持EVM和Move语言编写的智能合约。顶级VC机构已开始布局，为新的场景用例和生态增长奠定基础。

• 比特币与以太坊——根植于基本原则的文化之战

  比特币和以太坊是推动加密货币和区块链技术发展的双重力量，但基于不同信念而相互对立。加密货币世界还有其他选择，如门罗币和Solana。跨链连接是解决不同加密货币互操作性的方式，但也存在安全和中心化风险。比特币和以太坊可能通过引入去中心化的EVM侧链来共存。

· Polygon Hermez.

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

类型 2.5 | 部分等同于 EVM

架构：

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

· 预编译；

· Keccak 操作码；

· 调用合约的模式；

· 访问内存；

· 存储。

类型 2.5 | 优点

· 显著提高最坏情况下的证明时间；

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

类型 2.5 | 缺点

· 开发工具的兼容性降低；

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

类型 3 | 几乎等同于 EVM

架构：

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

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

类型 3 | 优点

· 缩短验证时间 ；

· 让 EVM 更容易开发；

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

类型 3 | 缺点

· 更多的不兼容性；

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

类型 3 | 项目

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

类型 4 | 高级语言等同

架构：

· 接受用高级语言（如 Solidity、Vyper）编写的智能合约代码；

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

类型 4 | 优点

· 非常快的证明时间；

· 降低开销（成本、时间和计算工作量）；

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

类型 4 | 缺点

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

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

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

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

类型 4 | 项目

· zkSync

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

免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：cookies，如有侵权请联系删除。转载或引用请注明文章出处！

标签：EVMZK-SNARK