原文標題：What might an “enshrined ZK-EVM” look like
作者：Vitalik，以太坊創始人；來源：ethereum官網；翻譯：0xjs@金色財經
以太坊之上的2 層EVM 協定（包括樂觀rollup和ZK rollup）依賴EVM 驗證。然而，這要求他們信任大型程式碼庫，如果該程式碼庫中存在錯誤，這些虛擬機器就有被駭客攻擊的風險。此外，這意味著即使ZK-EVM 想要與L1 EVM 保持完全相同，也需要某種形式的治理，將對L1 EVM 的變更複製到自己的EVM 實作中。
這種情況不是最理想的，因為這些項目正在複製以太坊協議中已經存在的功能，而以太坊治理已經負責進行升級和修復錯誤：ZK-EVM 基本上完成與驗證1 層以太坊區塊相同的工作！此外，在接下來的幾年裡，我們預計輕客戶端會變得越來越強大，並且很快就會達到使用ZK-SNARK 來完全驗證L1 EVM 執行的程度。屆時，以太坊網路將有效地擁有內建的ZK-EVM。那麼問題來了：為什麼不讓ZK-EVM原生地用於rollup呢？
這篇文章將描述可以實現的「封裝ZK-EVM（enshrined ZK-EVM）」的幾個版本，並討論權衡和設計挑戰，以及不朝特定方向發展的原因。應權衡實現協議功能的好處與將事情交給生態系統並保持基本協議簡單的好處。
我們希望從ZK-EVM中獲得哪些關鍵屬性？
-
基本功能：驗證以太坊區塊。協議功能（到目前為止，無論是操作碼、預編譯還是其他機制，都處於開放狀態）應該（至少）接受前狀態根、區塊和後狀態根作為輸入，並驗證後狀態根實際上是在前狀態根之上執行區塊的結果。
-
與以太坊的多客戶端理念相容。這意味著我們希望避免採用單一的證明系統，而是讓不同的客戶端使用不同的證明系統。這又暗示了幾點：
資料可用性要求：對於使用ZK-EVM 進行驗證的任何EVM 執行，我們希望確保底層資料可用，以便使用不同證明系統的證明者可以重新證明執行，並且客戶端依賴於該證明系統可以驗證那些新產生的證明。
證明存在於EVM 和區塊資料結構之外：ZK-EVM 功能實際上不會將SNARK 作為EVM 輸入，因為不同的客戶端會期望不同類型的SNARK。相反，它的工作方式可能類似於blob 驗證：交易可能包括需要證明的（前狀態、區塊體、後狀態）語句，操作碼或預編譯可以存取這些語句的內容，並且客戶端共識規則將分別檢查數據可用性以及區塊中提出的每個聲明的證據是否存在。
-
可審計性。如果任何執行得到驗證，我們希望底層資料可用，以便如果出現任何問題，使用者和開發人員可以檢查它。實際上，這又增加了數據可用性要求如此重要的一個原因。
-
可升級性。如果發現某個特定的ZK-EVM 方案有錯誤，我們希望能夠快速修復它。這意味著不需要硬分叉來修復。這又增加了EVM 和區塊資料結構之外的證明如此重要的另一個原因。
-
支援almost-EVM（準EVM）。 L2 的部分吸引力在於能夠在執行層進行創新，並對EVM 進行擴展。如果給定的L2 的VM 與EVM 只有一點點不同，那麼如果L2 仍然可以使用原生協定內ZK-EVM 來處理與EVM 相同的部分，並且只依賴自己那部分不同的程式碼，那就太好了。這可以透過設計ZK-EVM 功能來實現，讓呼叫者可以指定由外部提供的表而不是EVM 本身處理的位元欄位或操作碼清單或位址。我們也可以在一定程度上允許Gas成本進行客製化。
“開放”vs“封閉”多客戶端系統
「多客戶端理念」可能是此清單中最固執己見的要求。可以選擇放棄它並專注於一種ZK-SNARK 方案，這將簡化設計，但代價是成為以太坊更大的“哲學支點”（因為這實際上是放棄以太坊的長期堅持的多客戶理念）並以引入更大的風險為代價。在長遠的未來，如果形式化驗證技術變得更好，走這條路可能會更好，但目前風險似乎太大了。
另一種選擇是封閉的多客戶端系統，其中協議內有一組固定的證明系統。例如，我們可能決定使用三個ZK-EVM：PSE ZK-EVM、Polygon ZK-EVM和Kakarot。一個區塊需要提供這三個中兩個的證明才有效。這比單一證明系統更好，但它使系統的適應性較差，因為使用者必須為現有的每個證明系統維護驗證者，合併新證明系統將不可避免地存在政治治理過程等。
這激發了我對開放式多客戶端系統的偏好，其中證據被放置在「區塊之外」並由客戶端單獨驗證。個人用戶可以使用他們想要驗證區塊的任何客戶端，只要至少有一個證明者為該證明系統創建證明，他們就能夠這樣做。證明系統將透過說服用戶運行它們來獲得影響力，而不是透過說服協議治理流程。然而，正如我們將看到的，這種方法確實具有更高的複雜性成本。
我們希望ZK-EVM實現具有哪些關鍵屬性？
除了正確的功能和安全性的基本保證之外，最重要的屬性是速度。可以設計一個非同步的協議內ZK-EVM 功能，僅在延遲N 個slot後才返回每個聲明的答案，如果我們能夠保證可以在幾秒鐘內可靠地生成證明，問題就變的簡單，這樣每個區塊中發生的任何事情都是自給自足的。
雖然今天產生以太坊區塊的證明需要花費幾分鐘或幾小時，但我們知道沒有任何理論上的原因阻止大規模並行化：我們總是可以組合足夠的GPU來分別證明區塊執行的不同部分，然後使用遞歸SNARK 來證明區塊執行的不同部分。將證據放在一起。此外，透過FPGA 和ASIC 進行硬體加速有助於進一步優化證明。然而，實際上達到這一點是一項不容低估的重大工程挑戰。
以太坊主網協議內ZK-EVM功能具體是什麼樣的？
與EIP-4844 blob交易類似，我們引入了一種包含ZK-EVM 聲明的新交易類型：
與EIP-4844 一樣，在記憶體池中傳遞的物件將是交易的修改版本：
後者可以轉化為前者，但反之則不行。我們還擴展了區塊sidecar 物件（在EIP-4844中引入）以包含區塊中聲明的證明清單。
請注意，在實踐中，我們很可能希望將sidecar 分成兩個單獨的sidecar，一個用於blob，一個用於證明，並為每種類型的證明擁有一個單獨的子網（加上用於blob 的附加子網路）。
在共識層上，我們增加了一條驗證規則，即只有當客戶端看到區塊中每個聲明的有效證明後，才會接受該區塊。證明必須是ZK-SNARK，它證明串聯transaction_and_witness_blobs是一對(Block, Witness)的序列化，並且在使用Witness在pre_state_root之上執行區塊(i)是有效的，並且(ii) 輸出正確的post_state_root。客戶可能會選擇等待M-of-N 種多種類型的證明。
這裡的一個哲學註釋是區塊執行本身可以被簡單地視為三元組，它需要與ZKEVMClaimTransaction物件中提供的三元組一起檢查。因此，用戶的ZK-EVM 實作可以取代他們的執行客戶端；執行客戶端仍將由（i）證明者和區塊建構者以及（ii）關心索引和儲存資料以供本地使用的節點使用。
驗證和再證明
假設有兩個以太坊客戶端，其中一個使用PSE ZK-EVM，另一個使用Polygon ZK-EVM。假設此時，兩種實現都已發展到可以在5 秒內證明以太坊區塊執行的程度，並且對於每個證明系統，存在足夠多的獨立志願者運行硬體來產生證明。
不幸的是，由於個人證明系統沒有被納入其中，因此它們無法在協議中得到激勵；然而，我們預計運行證明者的成本與研發成本相比較低，因此我們可以簡單地使用通用機構的公共物品資金來資助證明者。
假設有人發布了ZKEvmClaimNetworkTransaction，但他們只發布了PSE ZK-EVM版本的證明。 Polygon ZK-EVM 的證明者節點看到這一點，並使用Polygon ZK-EVM 計算並重新發布該物件的證明。
這增加了最早接受區塊的誠實節點和最新接受相同區塊的誠實節點之間的總最大延遲，從δ增加到 2δ+Tprove（假設Tprove<5s）。
然而，好消息是，如果我們採用單slot最終確定性，我們幾乎肯定可以將這種額外的延遲與SSF 固有的多輪共識延遲一起「管道化」。例如，在這個4 sub-slot提案中，「head vote」步驟可能只需要檢查基本區塊有效性，但「凍結並確認」步驟將需要存在證明。
擴充：支援“almost-EVM”
ZK-EVM 功能的一個理想目標是支援「almost-EVM」：內建一些額外功能的EVM。這可能包括新的預編譯、新的操作碼、在EVM 或EVM 中編寫合約的選項。完全不同的VM（例如Arbitrum Stylus），甚至具有同步交叉通訊的多個平行EVM。
可以透過簡單的方式支援一些修改：我們可以定義一種語言，允許ZKEVMClaimTransaction傳遞修改後的EVM 規則的完整描述。可以這樣做：
-
自訂天Gas成本表（不允許使用者降低Gas成本，但可以增加Gas成本）
-
停用某些操作碼
-
設定區塊號（根據硬分叉，這意味著不同的規則）
-
設定一個標誌來啟動一整套EVM 變更（這些變更已針對L2 使用量進行標準化，但不適用於L1 使用）或其他更簡單的更改
為了允許使用者透過引入新的預編譯（或操作碼）以更開放的方式新增功能，我們可以新增預編譯輸入/輸出記錄作為blob 的一部分包含在ZKEVMClaimNetworkTransaction：
EVM 執行將修改如下。數組inputs將被初始化為空。 used_precompile_addresses第i 次呼叫in 中的位址時，我們將一個物件附加到輸入InputsRecord(callee_address, gas, input_calldata)，並將呼叫的RETURNDATA設定為outputs[i]。最後，我們檢查used_precompile_addresses是否總共被呼叫了len(outputs)次，並且inputs_commitments是否與inputs SSZ序列化產生的blob 承諾結果相符。暴露inputs_commitments的目的是為了方便外部SNARK證明輸入和輸出之間的關係。
請注意輸入（儲存在雜湊中）和輸出（儲存在必須可用的位元組中）之間的不對稱性。這是因為執行需要由僅看到輸入並理解EVM 的客戶端來執行。 EVM 執行已經為它們產生了輸入，因此它們只需要檢查生成的輸入是否與聲明的輸入匹配，這只需要雜湊檢查。然而，輸出必須完整地提供給他們，因此數據必須可用。
另一個有用的功能可能是允許從任意寄件者帳戶進行呼叫的「特權交易」(privileged transactions)。這些交易可以在兩個其他交易之間運行，也可以在呼叫預編譯時的另一個（也可能是特權）交易期間運行。這可用於允許非EVM 機制自call back EVM。
除了新的或修改的預編譯之外，還可以修改此設計以支援新的或修改的操作碼。即使只有預編譯，這個設計也相當強大。例如：
-
透過設定used_precompile_addresses來包含在狀態的帳戶物件中設定了一些標誌的常規帳戶地址列表，並製作SNARK 來證明其構造正確，你可以支援Arbitrum Stylus風格的功能，其中合約可以擁有其程式碼用EVM 或WASM（或其他VM）編寫。特權交易可用於允許WASM 帳戶回呼EVM。
-
透過新增外部檢查來確保多個EVM 執行的輸入/輸出記錄和特權交易以正確的方式匹配，你可以證明多個EVM 的平行系統透過同步通道相互通訊。
-
類型4 ZK-EVM可以透過多種實作來運作：一種將Solidity 或另一種高階語言直接轉換為SNARK 友善的VM，另一種將其編譯為EVM 程式碼並在所包含的ZK-EVM 中執行。第二種（不可避免地較慢）實現只能在錯誤證明者發送斷言存在錯誤的交易的情況下運行，如果他們可以提供兩者不同對待的交易，則收集賞金。
-
純非同步虛擬機可以透過使所有呼叫返回零並將呼叫映射到添加到區塊末尾的特權交易來實現。
擴展：支持有狀態證明者
上述設計的一個挑戰是它是完全無狀態的，這使得它的資料效率低。透過理想的資料壓縮，有狀態壓縮的ERC20 發送空間效率比無狀態壓縮高出3 倍。
除此之外，有狀態EVM 不需要提供見證資料。在這兩種情況下，原理是相同的：當我們已經知道資料可用時，要求資料可用是一種浪費，因為它是由EVM 的先前執行輸入或產生的。
如果我們想要讓ZK-EVM 功能成為有狀態的，那麼我們有兩個選擇：
1.要求σpre要么為空，要么是預先聲明的鍵和值的數據可用列表，要么是一些以前執行的σpost。
2.將Blob 承諾加入到R收據，它由區塊（σpre，σpost，R）元組產生。任何先前生成或使用的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封裝入主網協定功能，那麼「2 層專案」的持續作用是什麼？
目前2 層團隊自己實現的EVM 驗證功能將由協定處理，但2 層專案仍將負責許多重要功能：
-
快速預確認：單slot最終確定性可能會使1 層slot變慢，而2 層項目已經在向用戶提供“預確認”，由2 層自身的安全性支持，延遲遠低於1 個slot。該服務將繼續純粹是2 層的職責。
-
MEV緩解策略：這可能包括加密記憶體池、基於信譽的排序器選擇以及1 層不願意實現的其他功能。
-
EVM 的擴展：2 層專案可以包含對EVM 的大量擴展，為使用者提供重要價值。這包括「almost-EVM」和完全不同的方法，例如Arbitrum Stylus的WASM 支援和SNARK 友善的Cairo語言。
-
面向用戶和開發人員的便利：2 層團隊做了很多工作，吸引用戶和專案加入其生態系統，並讓他們感到受歡迎；他們透過獲取網路內的MEV 和擁塞費來獲得補償。這種關係將會持續下去。
