原文來源：Vitalik Buterin，ethereum.org
編譯：Luccy，BlockBeats
編按：
12 月13 日，以太坊聯合創始人Vitalik Buterin 發文深入探討了「ZK-EVM」（Zero-Knowledge Ethereum Virtual Machine）的可能實現形式，並對不同版本ZK-EVM 的設計進行探討。
Vitalik 提出的ZK-EVM 概念，旨在減少Layer-2 項目對Ethereum 協議功能的重複實現，並提高其在驗證Layer-1 Ethereum 區塊時的效率。文章指出，目前的Layer-2 EVM 協議（如Optimistic Rollups 和ZK Rollups）需要依賴EVM 的驗證機制，但這同時意味著他們必須信任龐大的程式碼庫。一旦程式碼庫中存在漏洞，這些虛擬機器可能面臨被攻擊的風險。
此外，他還提到了對「almost-EVM」的支持，即允許L2 的VM 在與EVM 只有微小差異的情況下，仍能使用協議內的ZK-EVM，同時也為EVM 的部分定制化提供了靈活性。
以太坊上的Layer-2 EVM 協議，包括op rollup 和ZK rollup，依賴EVM 驗證。然而，這要求它們信任一個龐大的程式碼庫，如果該程式碼庫存在漏洞，這些虛擬機器面臨被駭客攻擊的風險。此外，即使是希望與L1 EVM 完全等同的ZK-EVM，也需要一定形式的治理，以將L1 EVM 的變更複製到它們自己的EVM 實作中。
這種情況並不理想，因為這些項目正在複製以太坊協議中已經存在的功能，而以太坊治理已經負責升級和修復錯誤：ZK-EVM 基本上執行與驗證L1 以太坊區塊相同的工作！此外，未來幾年內，我們預計輕客戶端將變得越來越強大，很快就會使用ZK-SNARKs 完全驗證L1 以太坊執行。此時，以太坊網路將有效地擁有一個內建的ZK-EVM。因此，問題出現了：為什麼不將該ZK-EVM 在地化提供給rollup 項目？
本文將描述幾個可能實現的「被奉為圭臬的ZK-EVM」版本，並探討權衡和設計挑戰，以及不選擇特定方向的原因。這些實現協議特性的優勢應該與留給生態系統的好處和保持基礎協議簡單的利益相權衡。
我們對被奉為圭臬的ZK-EVM 有哪些關鍵屬性的期望？
基本功能：驗證以太坊區塊。此協議特性（目前仍未確定是操作碼、預編譯或其他機制）應至少接受預狀態根、區塊和後狀態根作為輸入，並驗證後狀態根是否確實是在預狀態根的基礎上執行區塊的結果。
與以太坊多客戶端理念的兼容性。這意味著我們希望避免奉行單一的證明系統，而是讓不同的客戶端使用不同的證明系統。這反過來又意味著一些要點：
• 資料可用性要求：對於使用被奉為圭臬的ZK-EVM 證明的任何EVM 執行，我們希望能夠保證底層資料是可用的，以便使用不同證明系統的證明者可以重新證明執行，依賴該證明系統的客戶端可以驗證這些新產生的證明。
• 證明存在於EVM 和區塊資料結構之外： ZK-EVM 特性不會直接將SNARK 作為EVM 內輸入，因為不同的客戶端期望不同類型的SNARK。相反，它可能類似於blob 驗證：交易可以包含需要證明的（預狀態、區塊主體、後狀態）語句，操作碼或預編譯可以訪問這些語句的內容，客戶端共識規則將分別檢查每個在區塊中提出的聲明的數據可用性和證明的存在。
可審計性：如果任何執行都得到證明，我們希望底層資料是可用的，以便在發生任何問題時，使用者和開發者可以檢查。在實踐中，這增加了數據可用性要求重要性的另一個原因。
可升級性：如果發現特定的ZK-EVM 方案有漏洞，我們希望能夠快速修復。這意味著不需要硬分叉來進行修復。這增加了證明存在於EVM 和區塊資料結構之外的重要性的另一個原因。
支援almost-EVM 的網路：L2 的吸引力之一在於創新執行層的能力，並對EVM 進行擴展。如果某個給定的L2 的虛擬機器（VM）與EVM 僅有細微差異，那麼如果L2 仍然可以使用與EVM 相同的原生協議內ZK-EVM，僅對與EVM 相同的部分依賴其自身程式碼，對於不同的部分則依賴他們自己的程式碼，那將是很好的。這可以透過設計ZK-EVM 特性的方式來實現，該特性允許呼叫者指定由外部提供的表處理的一些操作碼、位址或位元域，而不是由EVM 本身處理。我們還可以在有限的範圍內使燃氣成本開放客製化。
「開放」與「封閉」的多客戶端系統
「多客戶端理念」可能是這個清單中最有主張的要求。有放棄這一理念的選擇，專注於研究一個ZK-SNARK 方案，這將簡化設計，但代價是對以太坊的一個更大的「哲學轉變」（因為實際上這將是對以太坊長期多客戶端理念的放棄）和引入更大的風險。在長期未來，例如形式化驗證技術變得更好的情況下，可能會更好地選擇這條道路，但目前來看，風險似乎太大。
另一種選擇是封閉的多客戶端系統，在協議內已知一組固定的證明系統。例如，我們可能決定使用三個ZK-EVMs：PSE ZK-EVM、Polygon ZK-EVM 和Kakarot。一個區塊需要攜帶這三個中的兩個的證明才能被視為有效。這比單一的證明系統要好，但它使系統變得不太適應性，因為使用者必須為每個已知的證明系統維護驗證器，必然會存在政治性的治理過程來納入新的證明系統等等。
這促使我更傾向於採用開放的多客戶端系統，其中證明被放置在「區塊之外」，並由客戶端分別驗證。個別用戶可以使用他們想要的客戶端來驗證區塊，只要至少有一個產生該證明系統證明的證明者。證明系統將透過說服用戶運行它們而獲得影響力，而不是透過說服協議治理過程。然而，這種方法確實具有更多的複雜性成本，我們將會看到。
我們希望ZK-EVM 實現具備哪些關鍵特性？
除了基本的正確功能和安全性保證之外，最重要的特性是速度。雖然可以設計一個協議內的ZK-EVM 特性，其是異步的，僅在經過N 個時隙的延遲後為每個聲明返回一個答案，但如果我們可以可靠地保證在幾秒鐘內生成證明，那麼每個區塊中發生的一切都是自包含的問題將變得更容易。
儘管今天產生以太坊區塊的證明需要很多分鐘或小時，但我們知道沒有理論上的阻止大規模並行化的原因：我們總是可以組合足夠多的GPU，分別證明區塊執行的不同部分，然後使用遞歸SNARKs 將這些證明組合在一起。此外，透過FPGAs 和ASICs 的硬體加速可能有助於進一步優化證明。然而，實際達到這一點是一個重要的工程挑戰，不應該被低估。
協議內的ZK-EVM 特性可能具體是什麼樣子？
類似於EIP-4844 Blob 交易，我們引入了一種包含ZK-EVM 聲明的新交易類型：
與EIP-4844 類似，在記憶體池中傳遞的物件將是交易的修改版本：
後者可以轉換為前者，但反之則不行。我們還擴展了區塊邊車物件（在EIP-4844 中引入）以包含在區塊中所做聲明的證明清單。
請注意，在實際操作中，我們可能會希望將邊車分成兩個獨立的邊車，一個用於blob，一個用於證明，並為每種證明類型設置一個單獨的子網（還有一個額外的子網路用於blob）。
在共識層上，我們添加了一個驗證規則，即僅當客戶端看到了區塊中每個聲明的有效證明後，該區塊才會被接受。證明必須是ZK-SNARK 證明聲明，即transaction_and_witness_blobs 的串聯是（Block，Witness）對的序列化，執行區塊在pre_state_root 上使用Witness (i) 是有效的，並且(ii) 輸出正確的post_state_root。潛在地，客戶端可以選擇等待多種證明類型的M-of-N。
這裡有一個哲學性的注記，即區塊執行本身可以被視為僅是需要與ZKEVMClaimTransaction 物件中提供的（σpre,σpost，Proof）三元組之一一起檢查的。因此，使用者的ZK-EVM 實作可以取代其執行客戶端；執行客戶端仍將被（i）證明者和區塊建構者使用，以及（ii）關心索引和儲存資料供本地使用的節點使用。
驗證和重新證明
假設有兩個以太坊客戶端，其中一個使用PSE ZK-EVM，另一個使用Polygon ZK-EVM。假設到達這一點時，兩個實作都已發展到可以在5 秒內證明以太坊區塊執行的程度，並且對於每個證明系統，存在足夠多獨立的志願者運行硬體以產生證明。
不幸的是，由於個別證明系統未被正式確立，它們無法在協議中獲得激勵；然而，我們預計運行證明節點的成本將較低，相比於研究和開發的成本，因此我們可以簡單地通過通用機構為公共物品資助來資助證明節點。
假設有人發布了一個ZKEvmClaimNetworkTransaction，除非他們只發布了PSE ZK-EVM 版本的證明。Polygon ZK-EVM 的證明節點看到這一情況，計算並重新發布該對象，附帶Polygon ZK-EVM 的證明。
這將最早的誠實節點接受區塊和最晚的誠實節點接受相同區塊之間的總最大延遲從δ增加到2δ+Tprove（這裡假設Tprove<5 秒）。
然而，好消息是，如果我們採用單槽確定性，我們幾乎肯定可以將這種額外延遲與SSF 固有的多輪共識延遲一起「管線」處理。例如，在這個4 子槽提案中，「頭部投票」步驟可能只需要檢查基本的區塊有效性，但「凍結和確認」步驟將需要存在一個證明。
擴充：支援「almost-EVM」
ZK-EVM 功能的一個可取目標是支援「almost-EVM」：具有一些額外功能的EVMs。這可能包括新的預編譯，新的操作碼，允許合約以EVM 或完全不同的VM（例如，在Arbitrum Stylus 中）編寫，甚至具有同步交叉通訊的多個平行EVMs。
一些修改可以以簡單的方式進行支援：我們可以定義一種語言，讓ZKEVMClaimTransaction 傳遞修改後的EVM 規則的完整描述。這可以用於：
自訂gas 成本表（使用者不得減少gas 成本，但可以增加）
停用某些操作碼
設定區塊編號（這將意味著根據硬分叉而有不同的規則）
設定一個啟動已為L2 使用而非L1 使用標準化的整套EVM 更改的標誌，或其他更簡單的更改
為了以更開放的方式允許使用者透過引入新的預編譯（或操作碼）添加新功能，我們可以在ZKEVMClaimNetworkTransaction 的blob 的一部分中添加一個包含預編譯輸入/輸出轉錄的內容：
EVM 執行將被修改如下。數組inputs 將被初始化為空。每次呼叫used_precompile_addresses 中的位址時，我們將InputsRecord（callee_address、gas、input_calldata）物件附加到inputs，並將呼叫的RETURNDATA 設為outputs[i]。最後，我們檢查used_precompile_addresses 總共被呼叫了len(outputs) 次，並且inputs_commitments 匹配產生的blob commitments 到inputs 的SSZ 序列化的結果。暴露inputs_commitments 的目的是為了方便外部SNARK 證明輸入和輸出之間的關係。
請注意輸入和輸出之間的不對稱性，其中輸入被儲存在散列中，而輸出被儲存在必須提供的位元組中。這是因為執行需要由僅看到輸入並理解EVM 的客戶端完成。EVM 執行已經為它們產生了輸入，因此它們只需檢查生成的輸入是否與聲明的輸入匹配，這只需要進行雜湊檢查。但是，輸出必須以完整形式提供給它們，因此必須是資料可用的。
另一個有用的功能可能是允許「特權事務」，即從任意寄件者帳戶發起呼叫的事務。這些事務可以在兩個其他事務之間運行，或者在另一個（可能也是特權的）事務中調用預編譯時運行。這可以用於允許非EVM 機制呼叫回EVM。
這個設計可以修改以支援新的或修改過的操作碼，除了新的或修改過的預編譯。即使只有預編譯，這個設計也非常強大。例如：
透過設定used_precompile_addresses，包括在狀態中其帳戶物件中設定了某些標誌的常規帳戶地址列表，並製作一個SNARK 來證明它被正確構建，您可以支援Arbitrum Stylus 風格的功能，其中合約的程式碼可以用EVM 或WASM（或其他VM）編寫。特權交易可用於允許WASM 帳戶回調到EVM。
透過新增一個外部檢查，確保多個EVM 執行的輸入/輸出轉錄和特權事務以正確的方式匹配，您可以證明一個透過同步通道相互通訊的多個EVM 的平行系統。
第四類型的ZK-EVM 可以透過擁有多個實現來運作：一個將Solidity 或其他高級語言直接轉換為SNARK 友好的VM 的實現，另一個將其編譯為EVM 代碼並在被奉為圭臬的ZK-EVM中執行。第二個（不可避免地較慢的）實現僅在錯誤證明者發送聲明存在錯誤的交易的情況下運行，如果他們能夠提供兩者不同處理的交易，則可以獲得獎勵。
一個純粹非同步的VM 可以透過讓所有呼叫傳回零，並將呼叫對應到新增到區塊末尾的特權交易來實現。
擴展：支持有狀態的證明者
上述設計的一個挑戰是它完全是無狀態的，這使得它在數據利用上效率較低。透過支援有狀態的壓縮，使用理想的資料壓縮，ERC20 發送可以比僅使用無狀態壓縮時更節省空間，最多可節省3 倍的空間。
此外，有狀態的EVM 不需要提供見證資料。在兩種情況下，原則是相同的：要求資料可用是一種浪費，因為我們已經知道該資料是可用的，因為它是由EVM 的先前執行輸入或產生的。
如果我們想要讓ZK-EVM 功能成為有狀態的，那麼我們有兩個選擇：
1. 要求σpre 要麼為空，要麼是一個預先聲明的鍵值對的資料可用列表，或者是某個先前執行的σpost。
2. 將一個由區塊產生的收據R 的blob 承諾加入(σpre,σpost,Proof) 元組中。任何先前生成或使用的blob 承諾，包括那些表示區塊、見證、收據甚至是常規的EIP-4844 blob 交易的承諾，可能帶有一些時間限制，都可以在ZKEVMClaimTransaction 中被引用，並在其執行過程中被存取（可能透過一系列指令實現：「在區塊+見證資料的位置j 處插入承諾i 的位元組N…N+k−1」）。
(1) 基本上是在說：與其將無狀態的EVM 驗證固化，我們將固化EVM 子鏈。（2）本質上是創建一個內建的最小有狀態壓縮演算法，它使用先前使用或產生的blob 作為字典。這兩者都給證明節點，只是證明節點，增加了儲存更多資訊的負擔；在情況（2）中，比情況（1）更容易將這種負擔限制在一定時間內。
封閉式多證明係統和鏈下資料的爭論
封閉式多證明者係統在M-of-N 結構中固定了一定數量的證明系統，避免了上述許多複雜性。特別是，封閉式多證明者係統不需要擔心確保資料上鍊的問題。此外，封閉式多證明者係統將允許ZK-EVM 證明鏈下執行；這使其與EVM Plasma 解決方案相容。
然而，封閉式多證明者係統增加了治理複雜性並且降低了可審查性，這些是需要權衡的高成本與這些好處之間的。
如果我們將ZK-EVM 確立為協議功能，那麼「L2 項目」將會有哪些持續的角色？
協議將處理目前L2 團隊自行實作的EVM 驗證功能，但L2 項目仍將負責許多重要的功能：
快速預確認：單槽終局性可能會使L1 槽變慢，而L2 項目已經在為其用戶提供由L2 自身安全支持的「預確認」，延遲遠低於一個槽。這項服務將繼續是純粹的L2 責任。
MEV 緩解策略：這可能包括加密記憶體池、基於聲望的順序選擇以及L1 不願意實施的其他功能。
對EVM 的擴展： L2 項目可以整合對EVM 的實質擴展，為其使用者提供重要價值。這既包括「幾乎-EVMs」，也包括像Arbitrum Stylus 的WASM 支援和SNARK 友好的Cairo 語言等根本不同的方法。
面向用戶和開發者的便利性： L2 團隊在吸引用戶和項目進入其生態系統並使其感到受歡迎方面做了大量工作；他們透過在其網路內獲取MEV 和擁塞費用來獲得補償。這種關係將繼續存在。
（以上內容獲合作夥伴 MarsBit 授權節錄及轉載，原文連結 | 出處：BlockBeats）
聲明：文章僅代表作者個人觀點意見，不代表區塊客觀點和立場，所有內容及觀點僅供參考，不構成投資建議。投資者應自行決策與交易，對投資者交易形成的直接間接損失作者及區塊客將不承擔任何責任。
〈Vitalik Buterin 新文：未來的「ZK-EVM」會是什麼樣子？〉這篇文章最早發佈於《區塊客》。
