本文介紹了以太坊上二層EVM協議的現況與挑戰。文章提出了一種內建ZK-EVM的可能性，並討論了其實現的關鍵屬性和具體形式。文章強調了內建ZK-EVM的重要性，並討論了多客戶端系統的開放與封閉以及驗證和重新證明的問題。最終，文章希望透過內建ZK-EVM實現來加快以太坊區塊的執行速度。
文章討論了內建ZK-EVM的重要屬性，包括基本功能、與多個以太坊客戶端的兼容性、資料可用性要求、審計性和可升級性。它還討論了內建ZK-EVM在協議中的具體形式，並探討了驗證和重新證明的可能性。最終，文章提出了加快以太坊區塊執行速度的希望。
撰文：Vitalik Buterin
編譯：1912212.eth， 前瞻新聞
以太坊上面的二層EVM協議，包括optimistic rollups和ZK rollups，都依賴EVM驗證。然而，這要求他們信任龐大的程式碼庫，如果該程式碼庫中存在錯誤，這些VM就會被駭客攻擊的另外，這意味著即使是希望與L1 EVM 完全對應的ZK-EVM 也需要某種形式的治理，以將L1 EVM 的變更複製到他們自己的EVM 實踐中。
情況並不理想，因為這些正在複製以太坊協議中已經存在的功能，而以太坊治理項目已經負責進行升級和修復錯誤：ZK-EVM 基本上與驗證第一層以太坊塊的工作相同此外，在未來幾年，我們預期的輕客戶端將變得越來越強大，很快就會達到使用ZK-SNARKs 來完全第一驗證層EVM 執行的程度。到那時，以太坊網路將有效建構內建的ZK-EVM。因此，問題出現了：為什麼不讓ZK-EVM本身也適用於rollups？
本文將介紹幾種可以實現的「內建ZK-EVM」版本，並討論權衡和設計挑戰，以及不採用方向特定的原因。實施協議特性的好處應該與將事情轉移生態系統並保持基礎協議簡單的好處是進行權衡。
我們希望從內建ZK-EVM 中獲得哪些關鍵特性？
基本功能：驗證以太坊區塊。協定功能（目前尚不明確是操作碼、預編譯或其他機制）應接受至少一個前狀態根、一個區塊和一個後狀態根輸入作為，並驗證後狀態根實際上是執行區塊後的結果。與以太坊的多個客戶端相容。這意味著我們希望避免只採用一個論證系統，而是讓不同的客戶端使用不同的論證系統。這又引出以下幾點： 資料可用性要求：對於任何使用內建ZK-EVM進行證明的EVM執行，我們希望保證基礎資料的可用性，以便使用不同證明系統的證明者可以重新證明執行，並允許依賴該證明系統的客戶端驗證新產生的證明。證明存在於EVM 和區塊資料結構之外：內建ZK-EVM 功能不會將SNARK 作為EVM 內的輸入，因為不同的客戶端會需要不同類型的SNARK。相反，它可能類似於blob 驗證：交易可以包括（前狀態、區塊主體、後狀態）需要說明的聲明，一個操作碼或預編譯可以存取這些聲明的內容，客戶端意見規則將分別檢查每個聲明的數據可用性和存在說明。可審計性。如果任何執行得到證明，我們希望基礎資料是可用的，以便在出現問題時，使用者和開發人員可以檢查它。實際上，這增加了為什麼資料可用性要求如此重要的另一個原因。可升級性。如果某個ZK-EVM 方案發現有bug，我們希望能夠快速修復它。這意味著不需要硬分叉來修復。這增加了為什麼證明存在於EVM 和區塊資料結構之外的原因。支援幾乎所有的EVM。 L2的吸引力之一是在執行層進行創新，並擴展EVM。如果給定的L2的VM與EVM唯一一點點不同，那麼如果L2仍然可以在與EVM相同的部分使用本機協定內ZK-EVM，並在不同的部分僅依賴自己的程式碼，那將是一件好事。這可以透過設計ZK-EVM功能來實現，該功能允許呼叫者指定位元字段或操作碼列表或位址，這些位元字段、操作碼列表或地址由外部提供的表而不是EVM 本身處理。我們也可以在一定的程式中使Gas 成本開放編輯。
「開放」與「封閉」的多客戶端系統
「多客戶端理念」可能是這個清單中最具特色的要求。可以選擇放棄它，專注於ZK-SNARK 方案，這將簡化設計，但代價是成為以太坊更大的“哲學轉折點”（因為這實際上是放棄了以太坊長達的多客戶端理念），並帶來更大的風險。如果未來形態驗證技術變得更好的時候，選擇一條路可能會更好，但現在看來風險似乎有點了。
另一種選擇是封閉的多客戶端系統，在協定中已知有一組固定的證明系統。例如，我們可能會決定使用三個ZK-EVM：PSE ZK-EVM、Polygon ZK-EVM 和Kakarot。這需要這三個中的兩個提供的證明才有效。這比單一的證明系統要好，但它使系統的功耗降低，使用者必須為每個存在的證明系統維護驗證器，並且簡單地會有政治治理過程來納入新的論證系統等。
這促使我更喜歡開放的多客戶端系統，在這個系統中，證明被放置在「區塊外部」，並由客戶端單獨驗證。個人用戶可以使用他們想要的任何客戶端來驗證區塊，至少有一個論證者為該論證系統創建論證就可以。論證系統將透過說服使用者運作他們來獲得影響力，而不是透過說服協議治理過程。但是，這種方法確實有較高的複雜性成本，正如我們將看到的那樣。
我們希望從ZK-EVM 實作中獲得哪些關鍵屬性？
除了基本的功能正確性和安全性保證之外，最主要的屬性是速度。雖然我們可以設計在協議內的ZK-EVM重要特性，它是異步的，在N個插槽的延遲後只返回每個聲明的答案，但如果我們能夠可靠地保證在幾套別墅內生成一個證明，那麼無論每個區塊中發生的什麼都是自包含的，問題就會變得容易分裂。
雖然今天為以太坊區塊生成證明需要很多分鐘或小時，但我們知道沒有理論上的原因阻止大規模大規模化：我們總是可以將足夠的GPU 組合起來，分別證明一個區塊執行的各個部分，然後使用梯度SNARK 論證並在一起。此外，透過FPGA 和ASIC 的硬體加速可以幫助進一步優化論證。然而，真正實現這一步卻是不容小覷的浩大工程挑戰。
協議內ZK-EVM 特性的具體形式可以學習嗎？
與EIP-4844 blob 交易類似，我們引入了新的包含ZK-EVM 聲明的交易類型：
需要注意的是，在實踐中，我們可能希望將側載拆分為兩個單獨的側載，一個用於blob，一個用於證明，並為多種類型的證明（以及blob 的附加子網） ）設定一個單獨的子網路。
在共識層，我們加入了驗證規則，即只有當客戶端看到區塊中每個聲明的有效證明時，才接受該區塊。證明必須是一個ZK-SNARK，證明transaction_and_witness_blobs 的三星是(Block, Witness)的序列化，並且在見證上使用pre_state_root 對執行該區塊
(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
然而，好消息是，如果我們採用單一時隙的最終性，我們幾乎可以肯定地將這個額外的延遲與SSF 中固有的多輪喚醒延遲一起「同步」進行。例如，在這4 個子時隙的提示中，「頭部投票」步驟可能只需要檢查基本部分的有效性，但「凍結並正確」步驟則需要存在一個證明。
擴充：支援“almost-EVMs”
ZK-EVM 功能的可取目標是支援「almost-EVMs」：具有額外功能的EVM。這可能包括新的預編譯、新的操作碼、可以與EVM 或完全不同的VM 相容（例如在Arbitrum Stylus 中） ，甚至具有同步交叉通訊的多個EVM。
修改一些可以以簡單的方式支援：我們可以定義一種語言，允許ZKEVMClaimTransaction 提交後的EVM 規則的完整描述。這可以用於以下情況：
自訂的Gas 成本表（使用者不允許減少Gas 成本，但他們可以增加它們） 取消某些操作碼設定區塊號（這將意味著根據硬分叉有不同的規則） 使用標誌，啟動已經為L2 標準化，但不適用於L1 使用的整套EVM 更改，或其他更簡單的更改
為了允許使用者以更開放的方式新增功能，例如透過引入新的預編譯（或操作碼），我們可以在ZKEVMlaimNetworkTransaction 的blob 部分中新增一個包含預編譯輸入/輸出記錄的方式：
類別PrecompileInputOutputTranscript(Container):used_precompile_addresses: 列表[Address]input_commitments：列表[VersionedHash]輸出：列表[Bytes]
EVM執行將被如下。一個名為inputs的陣列將被初始化為空。每當被呼叫used_precompile_addresses修改中的位址時，我們會向inputs新增一個InputsRecord(callee_address, Gas, input_calldata)對象，並呼叫的RETURNDATA設定為輸出[i]最後，我們檢查used_precompile_addresses總共被呼叫了len(outputs)次，以及inputs_commitments是否與產生的blob對inputs的SSZ序列化的承諾的結果相符。公開inputs_commitments的目的是為了讓外部SNARK能夠證明inputs和outputs之間的關係。
請注意輸入和輸出之間的不便宜性，輸入儲存在雜湊中，而輸出儲存在必須提供的位元組中。這是因為執行需要由看到僅輸入並理解EVM 的客戶端執行。 EVM 執行已經為它們產生了，它們只需要檢查生成的輸入是否與聲明的輸入匹配，只需要進行雜湊檢查。但是，必須完全為它們提供輸出，因此必須具備資料可用性。
另一個有用的功能可能是允許「特權交易」從任意發送方帳戶進行呼叫。這些交易可以在兩個交易之間運行，或者在另一個（可能也是特權）交易中，同時調用預編譯。可以用於允許非EVM呼叫回EVM機制。
該設計可以修改以支援新的或修改的操作碼，除了新的或修改的預編譯。即使只有預編譯，設計也非常強大。例如：
透過設定used_precompile_addresses以包含在狀態中的其帳戶物件中設定了某個標誌的一組常規帳戶地址的列表，並產生證明其正確建構的SNARK可以，支援像Arbitrum Stylus一樣的功能，其中合約可以在EVM或WASM（或其他VM）中編寫了其程式碼。特權交易可用於允許WASM 帳戶回呼EVM。
透過新增外部檢查，確保多個EVM 執行的輸入/輸出記錄和特權交易以正確的方式匹配，可以證明透過同步通道相互通訊的多個EVM 的毛系統。
類型為4 的ZK-EVM 可以透過具有多種實現來相容：一個將Solidity 或另一種更高層級的語言直接轉換為SNARK 友善VM 的實現，另一個將其編譯為EVM 程式碼並在規定的ZK – EVM 中執行的實作。第二個（先比較慢的）實作只能在故障證明者請求交易要求有錯誤的情況下運行，如果他們能夠提供兩種處理不同的交易，則可以收集賞金。
透過使所有呼叫返回零放置呼叫映射到新增至區塊消耗的佔用交易，可以實現純非同步VM。
擴展：支持狀態證明者
其次設計的挑戰是它完全是無狀態的，這使得它在數據效率上表現不佳。使用理想的資料壓縮，相對於僅使用無狀態壓縮，有狀態壓縮可以使ERC20在空間利用上更有效率，最多可以提高3倍。
除此之外，有狀態的EVM 不需要提供證人資料。在這兩種情況下，原則是相同的：當我們已經知道資料可用時，因為它是由EVM 的先前執行輸入或產生的資料時，要求資料可用是一種浪費。
如果我們希望使ZK-EVM具有狀態功能，則有兩種選擇：
要求σpre或為空，或資料可用的預先聲明的鍵和值列表，或是某個先前執行的σpost。
為由區塊產生的收據R增加一個blob承諾到(σpre, σpost, Proof)元組。 ZKEVMClaimTransaction中可以引用並在其執行過程中存取任何先前生成或使用的blob承諾，包括表示區塊、證人、收據或甚至恆定EIP-4844 blob 事務的承諾（可能有一些時間限制，可以透過一系列指令進行引用：「在區塊+ 證人資料的位置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負責。 MEV 緩解策略：這可能包括加密的記憶體礦池、基於聲望的順序選擇等功能，而這些是L1 不易實施的。針對EVM 的擴展：第二層項目可以引入針對EVM 的重要擴展，方便用戶提供顯著的價值。其中包括「幾乎完全EVM」和不同的方法，例如Arbitrum Stylus 的WASM 支援和SNARK 程式語言的Cairo 語言。面向用戶和開發者的便利性：第二層團隊在吸引用戶和專案進入其生態系統，並讓他們感到受歡迎方面做了很多努力；透過他們在其網路內部捕獲MEV並擁有塞費來獲得報酬。種關係將繼續存在下去。
資訊來源：0x資訊編譯自網際網路。版權歸作者Vitalik Buterin所有，未經許可，不得轉載