原文作者 | Lisa Akselrod
編譯 | Odaily 星球日報 0xAyA
編者按：作者根據 Vitalik 此前撰寫的 ZK-EVM 介紹文章進行整理，並詳細介紹了各類 ZK-EVM 和它們之間的差異。
大約一年前，一群 ZK-EVM 宣佈即將推出測試網。這些舉措激起了以太坊社區的好奇心，並引發了人們對以太坊等效和 EVM 等效等術語背後的細微差別的討論。
為了明確起見，Vitalik 撰寫了一篇重要的文章，題為《不同類型的 ZK-EVMs》，將各種 ZK-EVM 分類為四種類型，並解釋了它們的區別。
其核心思想是：Type 1 （例如 Taiko）與以太坊完全等效，而 Type 4 （例如 zkSync）在高效的證明生成方面表現出色。所有其他類型，Type 2、Type 2.5 和 Type 3 ，介於這兩者之間（例如 Polygon zkEVM、Scroll、Linea）。
大多數 ZK-EVM 最初都是 Type 2.5 和 Type 3 ，並透露了一些朝 Type 1 或 Type 2 發展的意圖，儘管這些項目沒有為此提供具體的時間表或承諾。
本文主要關注 Type 1 和 Type 2/Type 2.5 之間的差異，並描述了破壞以太坊等效性可能帶來的後果。我們還將簡要介紹其他類型。
ZK-EVM 的主要目標是擴展以太坊，即提高以太坊的吞吐量，同時保留其其他特性（安全性、開發者體驗等）。在理想情況下，ZK-EVM 應該能夠：
根據黃皮書中以太坊虛擬機規範，證明未經修改的原生字節碼的執行情況（覆蓋 100% 的以太坊操作碼）。
以低成本快速生成證明。
允許 100% 重用為以太坊開發的工具和基礎設施。
允許將任何以太坊 dApp“按原樣”重新部署在 ZK-EVM 上（“原樣”意味著不需要任何更改，毫不妥協）。
ZK-EVM 類型之間的區別
在 ZK-EVM 領域，區別主要來自以太坊/EVM 等效性水平、ZK 不友好元素對證明生成成本和速度的影響，以及電路實現的複雜性（如 VM 構建或狀態樹）。
讓我們分析這些差異，特別是將 Type 1 與 Type 2/Type 2.5 區分開來。我們還將涉及到與每種類型最相關的使用案例。
在比較各種類型時，通常使用下面的圖表：
對於那些不在 ZK-EVM 領域全職工作的人來說，這張表可能看起來一頭霧水，所以讓我們將這些術語翻譯成通俗易懂的話再看看：
這個圖表更清晰地展示了每種類型的實際情況，但它仍然可能有些晦澀難懂，接下來讓我們通過分別解釋每種 Type，全面探索 ZK-EVM 領域。
Type 1 ：等效於以太坊
“Type 1 ZK-EVM 是我們最終需要的，使以太坊第 1 層本身更具可擴展性。”
Type 1 表示不更改以太坊系統的任何部分，以便更輕鬆地生成證明。對以太坊的不改變意味著安全性上的不妥協，因為大多數密碼學原語（例如哈希函數）、開發者基礎設施（例如調試器）或鏈基礎設施（例如執行客戶端）已經經過了 9 年的實戰測試。
Type 1 ZK-EVM 不會替換任何東西：哈希、狀態樹、事務樹、預編譯或任何其他共識邏輯，一切都與主網的 EVM 完全相同。
Type 1 是唯一能夠驗證以太坊鏈本身的類型——從整個區塊到交易執行、智能合約和賬戶邏輯。
Type 2 ：等效於 EVM
Type 2 通過去除一些不利於 ZK 的部分，使得證明生成更快、電路開發更容易。然而，由於這一點的後果，它可能會使得 ZK-rollup 的其他部分（例如節點軟件）的開發更加複雜。這些複雜性可能是由於已經確立的最佳實踐和測試工具與實施的更改（例如改變的狀態樹）不兼容所導致的。
注意：等效於以太坊和等效於 EVM 並不相同。雖然等效於以太坊意味著沒有改變以太坊的任何部分，也就是說與所有以太坊 dApp 完全兼容，但是等效於 EVM 允許改變數據結構（例如塊結構或狀態樹）。
儘管這些調整可能看起來很小，但它們會影響以太坊的兼容性。改變數據結構可能導致以太坊 dApp 與 Type 2 ZK-EVM 不兼容，特別是在驗證關於過去交易、收據或狀態的 Merkle 證明時（例如跨鏈橋）。
刪除 ZK 不友好的元素
對以太坊進行的修改旨在簡化開發並提高證明生成速度。目標是修剪依賴於不友好的零知識密碼學的以太坊部分。用更專業的術語來說，由於非本地域（例如哈希函數）而需要大量門電路（加法和乘法操作）的部分；大量的多標量乘法和/或快速傅里葉變換（FFT）；或者只是需要大量操作的部分。
Type 2 ZK-EVM 可能修改的不友好的零知識元素的具體示例：
哈希函數：雖然以太坊使用 Keccak 哈希函數，但許多 ZK-EVM 使用 Poseidon 哈希函數，它需要的門電路數量顯著較少。例如，讓我們估計每種類型的哈希函數可以每秒計算多少個（即證明生成速度的比較）。
Poseidon 哈希函數在證明生成方面具有顯著的速度優勢。
然而，需要注意的是，相對於廣泛社區認可的已建立的密碼學原語，較新的密碼學原語並不那麼受青睞。儘管 Poseidon 可能提供速度，但 Keccak 經過實戰檢驗的特性使其更具魯棒性和安全，因為它被廣泛採用。
這就是為什麼 Keccak 儘管更古老且被更廣泛的社區採用（在其他行業，例如安全系統或智能設備中的傳感器），但可以被認為比 Poseidon 更更經得起考驗，畢竟 Poseidon 是在 ZK 社區內創建和使用的新哈希函數。
用於數據存儲的狀態樹：例如，雖然以太坊使用Merkle Patricia 樹（使用 Keccak 哈希），但一些 Type 2 ZK-EVM 選擇稀疏 Merkle 樹（使用 Poseidon 哈希）。更改狀態樹可能會導致一些不兼容性。例如，以太坊的 Merkle 樹具有不同的節點類型，並使用 RLP 對數據進行編碼，這在 ZK 中是一件困難的事情。
塊結構： 塊包含大量信息。然而，在探索L2時，我們只關心 execution_payload_header（即塊哈希）。在下圖中，有 execution_payload_header 中包含的所有數據的結構（塊哈希）。
請注意：更改這些組件任意之一都會破壞以太坊等效性。
Type 2.5 ：等效於 EVM，考慮 gas 成本
Type 2.5 ZK-EVM 增加了在 EVM 中使用 ZK 技術難以證明的特定操作的 gas 成本。
鑑於以太坊每個區塊的 gas 限制（30 M gas），增加每個操作碼的 gas 成本會導致每個區塊的操作碼減少。因此，一個區塊中可以包含較少複雜的操作碼。較簡單的操作碼使電路變得更小，並且生成證明的速度更快。
gas 是工作量的度量單位。
操作碼的價格是以 gas 計算的。
操作碼指定了機器語言指令中的操作。
一個程序是操作碼的靜態列表。程序執行是執行跟蹤。
執行跟蹤是程序執行的特定有序操作碼列表。
難以進行 ZK 證明的部分包括：
Keccak 操作碼和一些依賴於 Keccak 的其他操作碼。
預編譯：對 EVM 可訪問的函數。其中一些提供複雜或數學上覆雜的任務，例如密碼學函數（例如 blake 2 f 或 sha 256）。它們不在 EVM 內執行，而是作為在執行客戶端中硬編碼的函數，並使用對特殊地址的 CALL 向 EVM 公開。
內存訪問：例如，增加內存插槽大小（例如，以太坊使用字節對齊的內存，而 Polygon zkEVM 使用 32 字節的內存插槽）。為了使這種更改成為可能，必須更改某些操作碼（例如 MLOAD）的內部邏輯。
存儲（即如上所述更改哈希函數或狀態樹）。
改變 gas 成本可能會降低開發人員工具的兼容性並破壞某些 dApp。例如，經常執行 gas 成本增加的操作碼的智能合約可能會超過區塊 gas 限制並且無法執行。
Type 3 ：幾乎等效於 EVM
Type 3 ZK-EVM 省略了不適用於 ZK 的預編譯，並可能調整內存和存儲訪問。
依賴已刪除的預編譯的 dApp 需要進行重寫。在不常見的情況下，Type 3 ZK-EVM 和原始 EVM 處理邊緣情況的方式的差異可能需要對 dApp 進行調整。
Type 4 （相當於高級語言）
Type 4 離 EVM 已經很遠了。
用高級語言（例如 Solidity，Zinc）編寫的智能合約源代碼被編譯為中間表現形式，生成適用於 ZK 友好的虛擬機的操作碼。
這種方法避免了為每個 EVM 執行步驟生成 ZK 證明，從而大大減少了證明工作。
即使合約可以編譯，如果 dApp 使用 EVM 手寫字節碼，也需要進一步的工作。
Type 4 ZK-EVM 還需要自己的開發人員工具（（僅適用於操作碼級別），例如調試器和跟蹤器。
在證明執行軌跡的 ZK 電路中，每個步驟都實現了約束，每個步驟的成本是所有操作碼的總和。因此，Type 4 ZK-EVM 旨在使用盡可能少的複雜操作碼來優化效率。
值得一提的是，自定義操作碼（不在以太坊中涵蓋的操作碼）使得可以通過默認情況下在以太坊上無法實現的新功能。例如，通過帳戶抽象功能進行多次調用執行，或使用像 Argent 這樣的開箱即用解決方案啟動智能合約錢包。
總結
不同的 ZK-EVM 類型優先考慮不同的目標和特徵。Type 1 側重於以太坊等效性，而 Type 4 優先考慮高效的證明生成。其他類型介於這些極端之間，許多 Type 2 和 3 ZK-EVM 協議已宣佈他們打算轉向以太坊等效。
這四種類型的分類可能不是 ZK 彙總的最終狀態，將來可能會進行進一步的修改。例如，一些 ZK-EVM 可能會成為混合型，Type 1/2 可能會開發 Type 4 解決方案（具有儘可能高的效率）併為 dApp 提供兩種選擇，而 Type 3 和 4 ZK-EVM 可能會添加以太坊等效選項。
