從Type1到Type4，各類型ZK-EVM間差異何在？

2023-09-25 16:09:19

原文作者 | 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 應該能夠：

ZK-EVM 類型之間的區別

在 ZK-EVM 領域，區別主要來自以太坊/EVM 等效性水平、ZK 不友好元素對證明生成成本和速度的影響，以及電路實現的復雜性（如 VM 構建或狀態樹）。

讓我們分析這些差異，特別是將 Type 1 與 Type 2/Type 2.5 區分开來。我們還將涉及到與每種類型最相關的使用案例。

在比較各種類型時，通常使用下面的圖表：

對於那些不在 ZK-EVM 領域全職工作的人來說，這張表可能看起來一頭霧水，所以讓我們將這些術語翻譯成通俗易懂的話再看看：

這個圖表更清晰地展示了每種類型的實際情況，但它仍然可能有些晦澀難懂，接下來讓我們通過分別解釋每種 Type，全面探索 ZK-EVM 領域。

Vitalik Buterin ：

“Type 1 ZK-EVM 是我們最終需要的，使以太坊第 1 層本身更具可擴展性。”

Type 1 表示不更改以太坊系統的任何部分，以便更輕松地生成證明。對以太坊的不改變意味着安全性上的不妥協，因為大多數密碼學原語（例如哈希函數）、开發者基礎設施（例如調試器）或鏈基礎設施（例如執行客戶端）已經經過了 9 年的實战測試。

Type 1 ZK-EVM 不會替換任何東西：哈希、狀態樹、事務樹、預編譯或任何其他共識邏輯，一切都與主網的 EVM 完全相同。

Type 2 通過去除一些不利於 ZK 的部分，使得證明生成更快、電路开發更容易。然而，由於這一點的後果，它可能會使得 ZK-rollup 的其他部分（例如節點軟件）的开發更加復雜。這些復雜性可能是由於已經確立的最佳實踐和測試工具與實施的更改（例如改變的狀態樹）不兼容所導致的。

注意：等效於以太坊和等效於 EVM 並不相同。雖然等效於以太坊意味着沒有改變以太坊的任何部分，也就是說與所有以太坊 dApp 完全兼容，但是等效於 EVM 允許改變數據結構（例如塊結構或狀態樹）。

盡管這些調整可能看起來很小，但它們會影響以太坊的兼容性。改變數據結構可能導致以太坊 dApp 與 Type 2 ZK-EVM 不兼容，特別是在驗證關於過去交易、收據或狀態的 Merkle 證明時（例如跨鏈橋）。

對以太坊進行的修改旨在簡化开發並提高證明生成速度。目標是修剪依賴於不友好的零知識密碼學的以太坊部分。用更專業的術語來說，由於非本地域（例如哈希函數）而需要大量門電路（加法和乘法操作）的部分；大量的多標量乘法和/或快速傅裏葉變換（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 ZK-EVM 增加了在 EVM 中使用 ZK 技術難以證明的特定操作的 gas 成本。

鑑於以太坊每個區塊的 gas 限制（30 M gas），增加每個操作碼的 gas 成本會導致每個區塊的操作碼減少。因此，一個區塊中可以包含較少復雜的操作碼。較簡單的操作碼使電路變得更小，並且生成證明的速度更快。

難以進行 ZK 證明的部分包括：

Keccak 操作碼和一些依賴於 Keccak 的其他操作碼。
預編譯：對 EVM 可訪問的函數。其中一些提供復雜或數學上復雜的任務，例如密碼學函數（例如 blake 2 f 或 sha 256）。它們不在 EVM 內執行，而是作為在執行客戶端中硬編碼的函數，並使用對特殊地址的 CALL 向 EVM 公开。
內存訪問：例如，增加內存插槽大小（例如，以太坊使用字節對齊的內存，而 Polygon zkEVM 使用 32 字節的內存插槽）。為了使這種更改成為可能，必須更改某些操作碼（例如 MLOAD）的內部邏輯。
存儲（即如上所述更改哈希函數或狀態樹）。

改變 gas 成本可能會降低开發人員工具的兼容性並破壞某些 dApp。例如，經常執行 gas 成本增加的操作碼的智能合約可能會超過區塊 gas 限制並且無法執行。