撰文：cookies
編譯：深潮TechFlow
你真的了解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;
· 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。
聲明：本內容為作者獨立觀點，不代表0x财经 立場，且不構成投資建議，請謹慎對待，如需報導或加入交流群，請聯繫微信：VOICE-V。
來源：深潮TechFlow
