原文作者：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。
