原文作者 -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 可能會添加以太坊等效選項。
