原文：https://notes.ethereum.org/@vbuterin/enshrined_zk_evm
譯者：登鏈社區[1] 翻譯小組
建立在以太坊之上的Layer2 EVM 協議，包括Optimistic Rollups 和ZK Rollups，都依賴EVM 驗證。然而，這需要它們信任龐大的程式碼庫，如果程式碼庫中存在漏洞，這些虛擬機器就有被駭客攻擊的風險。此外，即便是想要與L1 EVM 完全等效的ZK-EVM，也需要某種形式的治理機制，以便將L1 EVM 的變更複製到其自身的EVM 實作中。
這種情況並不理想，因為這些項目在複製已存在於以太坊協議中的功能，而以太坊治理已經負責升級和修復錯誤的地方：ZK-EVM 基本上所做的是驗證Layer1 以太坊區塊的工作！此外，在未來幾年中，我們預計輕客戶端[2] 會變得越來越強大，很快就會使用ZK-SNARKs 完全驗證L1 EVM 執行。到那時，以太坊網路將有效地擁有內建的ZK-EVM 。因此，一個問題就出現了：為什麼不讓ZK-EVM原生地用於rollup？
本文將介紹幾個可以實施的封裝ZK-EVM的版本，並詳細介紹權衡和設計挑戰，以及不採取特定方向的原因。實施協議特性的優勢應該與留給生態系統並保持基礎協議簡單性的好處進行權衡。
封裝ZK-EVM 想要獲得哪些關鍵特性？
基本功能：驗證以太坊區塊。協議特性（暫未確定是否為操作碼、預編譯或其他機制）應接受（至少）一個預狀態根、一個區塊和一個後狀態根作為輸入，並驗證後狀態根實際上是在預狀態根上執行區塊的結果。
與以太坊多客戶端概念的兼容性[3]，這意味著我們希望避免使用單一的證明系統，而是允許不同的客戶使用不同的證明系統。這反過來又意味著幾點：
-
資料可用性要求：對於透過封裝的ZK-EVM 進行的任何EVM 執行，我們希望能保證底層資料可用性[4] ，這樣使用不同證明系統的證明者可以重新證明執行，並且依賴該證明系統的客戶端可以驗證新產生的證明。
-
證明存放在EVM 和區塊資料結構之外：ZK-EVM 功能不會將SNARK 直接作為EVM 輸入，因為不同客戶端期望不同類型的SNARK。相反，它可能類似於blob 驗證：交易可以包括（預狀態、區塊主體、後狀態）需要證明的聲明，一個操作碼或預編譯可以存取這些聲明的內容，客戶端共識規則將分別檢查資料可用性和區塊中所作每個聲明的證明的存在。
可審計性：如果任何執行被證明，我們希望底層資料可用，以便使用者和開發者可以檢查。實際上，這又增加了一個資料可用性要求很重要的原因。
可升級性：如果發現某個特定的ZK-EVM 方案有漏洞，我們希望能夠迅速修復，而不需要硬分叉。這又增加了證明存放在EVM 和區塊資料結構之外的重要性。
支援almost – EVMs：L2 的吸引力之一是在執行層面進行創新，並對EVM 進行擴展。如果給定L2 的虛擬機器與EVM 僅略有不同，那麼當L2 與EVM 相同的部分仍然可以使用原生的協定內ZK-EVM 時，這將是很好的，只有對於與EVM 不同的部分才會依賴他們自己的程式碼。這可以透過設計ZK-EVM 功能的方式來完成，使其允許呼叫者指定位元域（bitfield）、操作碼或位址列表，由外部提供的表來處理而不是由EVM 本身。我們還可以在有限的範圍內使gas 成本可自訂。
開放與封閉的多客戶端系統
多客戶端理念可能是上述清單中最有主張的要求。有放棄它並專注於一個ZK-SNARK 方案的選擇，這將簡化設計，但代價是成為以太坊更大的理念轉向（因為它實際上是放棄以太坊長期以來的多客戶端理念），並引入更大的風險。在長期的未來，例如形式驗證技術變得更加完善時，可能更好的做法是走這條路線，但目前看來風險似乎太大。
另一種選擇是封閉的多客戶端系統，在協定中已知一組固定的證明系統。例如，我們可能決定使用三個ZK-EVM：PSE ZK-EVM[5] ，Polygon ZK-EVM[6] 和 Kakarot[7]。一個區塊需要這三個中的兩個的證明才能被視為有效。這比單一證明系統要好，但它使系統更少適應性，因為使用者必須維護每個證明系統的驗證器，必然會對納入新證明系統的政治治理程序等產生影響。
這促使我傾向於開放的多客戶端系統，其中證明被放置在“區塊之外”並由客戶端單獨驗證。個體用戶將使用他們想要的客戶端來驗證區塊，只要有一個證明者為該證明系統創建證明就可以。證明系統透過說服使用者運行它們來獲得影響力，而不是透過說服協議治理流程。然而，這種方法的複雜性成本更高，正如我們將看到的那樣。
我們希望ZK-EVM 實現具備哪些關鍵特性？
除了正確功能和安全性的基本保證外， 最重要的特性是速度。雖然可以設計一個非同步的協議內ZK-EVM 功能，僅在經過N 個插槽之後才返回每個聲明的答案，但如果我們能夠可靠的保證可以在幾秒鐘內生成證明，那麼問題就會變得容易的多，因此每個塊鐘發生的任何事情都是獨立的。
雖然今天為以太坊區塊生成證明需要很多分鐘甚至小時，但我們知道沒有理論上的理由阻止大規模並行化：我們總是可以組裝足夠多的GPU 來分別證明區塊執行的不同部分，然後使用遞歸SNARKs 將證明合併在一起。此外，透過FPGA 和ASIC 的硬體加速可以幫助優化證明。然而，要實現這一點是一個重大的工程挑戰，不應低估。
協議內的ZK-EVM 功能具體是什麼樣的？
類似於 EIP-4844 blob 交易[8]，我們引入了一種包含ZK-EVM 聲明的新交易類型：
與EIP-4844 類似，傳播於記憶體池中的物件將是交易的修改版本：
後者可以轉換為前者，但反之則不然。我們也擴展了區塊side car 物件（在EIP-4844[9] 中引入）以包含區塊中所做聲明的證明清單。
請注意，在實際操作中，我們很可能希望將sidecar 分為兩個獨立的sidecars，一個用於blob，另一個用於證明，並為每種類型的證明設立一個獨立的子網（另外還有一個子網路用於blobs）。
在共識層上，我們增加了一個驗證規則：只有當客戶端看到區塊中每個聲明的有效證明後，才能接受該區塊。證明必須是一個ZK-SNARK，證明了transaction_and_witness_blobs 的串聯是（Block, Witness）對的序列化，以及使用Witness（i）在pre_state_root 上執行區塊是有效的，並且（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 的proof 版本。 Polygon ZK-EVM 的證明節點看到了這一情況，計算並重新發布了具有Polygon ZK-EVM proof 的物件。
這增加了最早接受區塊的誠實節點和最後接受相同區塊的最新誠實節點之間的總最大延遲，從δ 到2δ+Tprove（這裡假設Tprove < 5s）。
然而，好消息是， 如果我們採用單一槽最終確定性，我們幾乎可以肯定地將這種額外延遲與SSF 中固有的多輪共識延遲一起”管道化”處理。例如，在這個4 子槽提案[10] 中，”頭投票”步驟可能只需要檢查基本區塊的有效性，但”凍結並確認”步驟需要存在一個證明。
擴充：支援almost-EVMs
ZK-EVM 功能的一個理想目標是支援almost-EVMs：他是具有一些額外特性的EVM 。這可能包括新的預編譯器、新的操作碼、有選項可以用EVM 或完全不同的VM（例如Arbitrum Stylus[11] 中的情況）方式來編寫合約，甚至具有同步交叉通信的多個並行EVM。
一些修改可以以簡單方式支援：我們可以定義一種語言，讓ZKEVMClaimTransaction 傳遞修改後的EVM 規則的完整描述。這可以應用於：
自訂gas 成本表（使用者不允許減少gas fee，但可以增加）
停用特定操作碼
設定區塊編號（這將意味著根據硬分叉而有不同的規則）
設定啟動專門用於L2 但不用於L1 的一整套EVM 變更的標誌，或其他簡單的變更
為了允許使用者透過引入新的預編譯器（或操作碼）以更開放地引入新功能，我們可以在以下位置添加預編譯的輸入/輸出腳本，其作為ZKEVMClaimNetworkTransaction 中blob 的一部分包含在：
EVM 執行將進行修改。一個數組inputs 將被初始化為空。當第i 次呼叫used_precompile_addresses 中的位址時，我們向inputs 新增InputsRecord(callee_address, gas, input_calldata)，並將呼叫的RETURNDATA 設為outputs[i]。最後，我們檢查used_precompile_addresses 總共被呼叫了len(outputs)次，以及inputs_commitments 是否與對inputs 的SSZ 序列化產生的blob 承諾的結果相符。暴露inputs_commitments 的目的是為了方便外部SNARK 證明輸入與輸出之間的關係。
請注意輸入（儲存在雜湊中）和輸出（以位元組形式儲存）之間的不對稱性。這是因為執行需要能夠由只看到輸入並理解EVM 的客戶端完成。 EVM 執行已經為它們產生了輸入，因此它們只需要檢查生成的輸入是否與聲稱的輸入匹配，這只需要進行雜湊檢查。然而，輸出必須完整提供給它們，因此必須具有數據可用性。
另一個有用的特性可能是允許”特權交易” ，可以從任意發送方帳戶進行呼叫。這些交易可以在兩個其他交易之間運行，或者在另一個（可能也是特權的）交易中調用預編譯器時運行。這可以用於允許非EVM 機制回調到EVM。
此設計可以修改以支援新的或修改後的操作碼，除了新的或修改過的預編譯器。即使只有預編譯器，這種設計也非常強大。例如：
透過將used_precompile_addresses 設定為包含在狀態中具有某些標誌的常規帳戶地址列表，並產生一個SNARK 證明以證明其正確構造，你可以支援像Arbitrum Stylus[12]風格的特性，其中合約可以在EVM 或WASM（或其他VM）中編寫其程式碼。特權交易可用於允許WASM 帳戶回調到EVM。
透過新增外部檢查來驗證多個EVM 執行的輸入/輸出記錄和特權交易以正確方式匹配，你可以證明一種多個EVM 的平行系統，這些系統透過同步通道進行通訊。
Type 4 的ZK-EVM[13]可以透過多個實現來運行：一種將Solidity 或其他更高級別的語言直接轉換為SNARK 友好的VM 的實現，並另一種將其編譯為EVM 程式碼並在內建的ZK-EVM中執行。第二種（不可避免地更慢）實現只能在出現故障證明者發送交易斷言存在漏洞的情況下運行，並在提供一個兩處處理不同的交易時，則收取賞金。
可以透過使所有呼叫返回零並將呼叫映射到添加到區塊末尾的特權交易來實現純非同步VM。
擴展：支持有狀態的證明者
上述設計的一個挑戰是它完全是無狀態的，這使得它數據效率低。使用理想的資料壓縮，與僅使用無狀態壓縮相比，一個ERC20 發送在使用有狀態壓縮時，空間效率最高可提高3 倍。
除此之外，有狀態的EVM 不需要提供見證資料。在兩種情況下，原則都是相同的：要求資料可用是一種浪費，因為我們已經知道該資料是可用的，因為它是在先前的EVM 執行中輸入或產生的。
如果我們想讓ZK-EVM 功能有狀態，則有兩種選擇：
要求σpre 為空，或是一個的預先聲明的鍵和值資料可用列表，或是先前執行σpost的某個列表
在（σpre，σpost，Proof）元組中添加一個與區塊生成的receipt R 的blob 承諾。在ZKEVMClaimTransaction 中可以引用任何先前生成或使用的blob 承諾，包括代表區塊、見證、receipt，甚至常規的EIP-4844 blob 交易，或許還有一些時間限制，可以在其執行期間訪問（可能透過一系列指令：「在區塊+見證資料的位置j 插入承諾i 的位元組N…N+k-1」）
(1) 基本上是說：與其無狀態EVM 驗證納入其中（封裝），不過將EVM 子鏈納入其中（封裝）。 （2）本質上是創建了一個最小的內建有狀態壓縮演算法，該演算法使用先前使用或產生的blobs 作為字典。這兩種方式都會為證明節點增加負擔，並且只有證明節點才能儲存更多資訊；在情況（2）中，比情況（1）更容易使該負擔有時間限制。
封閉式多證明系統和鏈下資料的論點
封閉式多證明系統，其中具有M-of-N 結構的固定數量的證明系統，避免了上述許多複雜性。封閉式多證明者係統特別是不需要擔心確保資料在鏈上的問題。此外，封閉式多證明者係統將允許ZK-EVM 證明鏈下執行；這使其與EVM Plasma 解決方案[14]相容。
然而， 封閉式多證明者係統增加了治理複雜性並消除了可審計性，這些是需要權衡帶來這些好處的高成本。
如果ZK-EVM 作為協議功能，那麼Layer2 專案的持續作用是什麼？
目前由Layer2 團隊實現的EVM 驗證功能將由協議處理，但 Layer2 專案仍將負責許多重要功能：
快速預確認：單一槽最終性可能會使Layer1 槽（slot）變慢，而Layer2 項目已經為其用戶提供了由Layer2 自身安全性支持的「預確認」，延遲遠低於一個槽。這項服務將持續純粹由Layer2 負責。
MEV 緩解策略：這可能包括加密記憶體池、基於聲譽的序列選擇以及Layer1 不願意實施的其他功能。
對EVM 的擴展：Layer2 專案可以包含對EVM 的重要擴展，為其用戶提供巨大價值。這包括alomost-EVM 和諸如Arbitrum Stylus[15]的WASM 支援以及SNARK-friendly Cairo（https://www.cairo-lang.org/）語言等完全不同的方法。
面向用戶和開發者的便利性：Layer2 團隊致力於吸引用戶和專案進入其生態系統並使其感到受歡迎；他們透過在其網路內捕獲MEV 和擁堵費用來獲得補償。這種關係將繼續存在。
