詳解ZK-EVM的五種類型：架構、優缺點及解決方案

原文作者：s 原文編譯：深潮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 證明將變得陌生，應用程序將無法讀取和驗證它們的聲明。

對缺點的潛在解決方案：以太坊可以添加未來可擴展的歷史訪問預編譯。

項目

• 滾動；
• 多邊形赫爾墨斯。

然而，這些項目尚未實現更複雜的預編譯，因此，它們可以被認為是不完整的類型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同步

最後，我們可以將上述的幾種類型放在一起做一個比較，幫助大家一目了然的理解不同的zkEVM。