原文：https://notes.ethereum.org/@vbuterin/enshrined_zk_evm
譯者：登鏈社區(qū)^[1] 翻譯小組

建立在以太坊之上的 Layer2 EVM 協(xié)議，包括 Optimistic Rollups 和 ZK Rollups，都依賴于 EVM 驗證。然而，這需要它們信任龐大的代碼庫，如果代碼庫中存在漏洞，這些虛擬機就有被黑客攻擊的風險。此外，即便是想要與 L1 EVM 完全等效的 ZK-EVM，也需要某種形式的治理機制，以便將 L1 EVM 的更改復(fù)制到其自身的 EVM 實現(xiàn)中。

這種情況并不理想，因為這些項目在復(fù)制已存在于以太坊協(xié)議中的功能，并且以太坊治理已經(jīng)負責升級和修復(fù)錯誤的地方：ZK-EVM 基本上做的是驗證 Layer1 以太坊區(qū)塊的工作！此外，在未來幾年中，我們預(yù)計 輕客戶端^[2] 會變得越來越強大，很快就會 使用 ZK-SNARKs 完全驗證 L1 EVM 執(zhí)行 。到那時， 以太坊網(wǎng)絡(luò)將有效地擁有內(nèi)置的 ZK-EVM 。因此，一個問題就出現(xiàn)了：為什么不讓ZK-EVM原生地用于rollup呢？

本文將介紹幾個可以實施的封裝 ZK-EVM的版本 ，并詳細介紹權(quán)衡和設(shè)計挑戰(zhàn)，以及不采取特定方向的原因。實施協(xié)議特性的優(yōu)勢應(yīng)該與留給生態(tài)系統(tǒng)并保持基礎(chǔ)協(xié)議簡單性的好處進行權(quán)衡。

封裝 ZK-EVM 想要獲得哪些關(guān)鍵特性？

基本功能：驗證以太坊區(qū)塊 。協(xié)議特性（暫未確定是否為操作碼、預(yù)編譯或其他機制）應(yīng)接受（至少）一個預(yù)狀態(tài)根、一個區(qū)塊和一個后狀態(tài)根作為輸入，并驗證后狀態(tài)根實際上是在預(yù)狀態(tài)根上執(zhí)行區(qū)塊的結(jié)果。

與以太坊多客戶端理念的兼容性^[3]，這意味著我們希望避免使用單一的證明系統(tǒng)，而是允許不同的客戶使用不同的證明系統(tǒng)。這反過來又意味著幾點：

• 數(shù)據(jù)可用性要求：對于通過封裝的 ZK-EVM 進行的任何 EVM 執(zhí)行，我們希望能 保證底層數(shù)據(jù)可用性^[4] ，這樣使用不同證明系統(tǒng)的證明者可以重新證明執(zhí)行，并且依賴該證明系統(tǒng)的客戶端可以驗證新生成的證明。

• 證明存放在 EVM 和區(qū)塊數(shù)據(jù)結(jié)構(gòu)之外：ZK-EVM 功能不會將 SNARK 直接作為 EVM 輸入，因為不同客戶端期望不同類型的 SNARK。相反，它可能 類似于 blob 驗證 ：交易可以包括（預(yù)狀態(tài)、區(qū)塊主體、后狀態(tài)）需要證明的聲明，一個操作碼或預(yù)編譯可以訪問這些聲明的內(nèi)容，客戶端共識規(guī)則將分別檢查數(shù)據(jù)可用性和區(qū)塊中所作每個聲明的證明的存在。

可審計性：如果任何執(zhí)行被證明，我們希望底層數(shù)據(jù)可用，以便用戶和開發(fā)者可以檢查。實際上，這又增加了一個數(shù)據(jù)可用性要求很重要的原因。

可升級性：如果發(fā)現(xiàn)某個特定的 ZK-EVM 方案存在漏洞，我們希望能夠迅速修復(fù)，而 不需要硬分叉 。這又增加了 證明存放在 EVM 和區(qū)塊數(shù)據(jù)結(jié)構(gòu)之外的重要性 。

支持almost - EVMs：L2 的吸引力之一是在執(zhí)行層面進行創(chuàng)新 ，并對 EVM 進行擴展 。如果給定 L2 的虛擬機與 EVM 僅略有不同，那么當 L2 與 EVM 相同的部分仍然可以使用原生的協(xié)議內(nèi) ZK-EVM 時，這將是很好的，只有對于與 EVM 不同的部分才會依賴他們自己的代碼。這可以通過設(shè)計 ZK-EVM 功能的方式來完成，使其允許調(diào)用者指定位域（bitfield）、操作碼或地址列表，由外部提供的表來處理而不是由 EVM 本身。我們還可以在有限的范圍內(nèi)使 gas 成本可定制。

開放與封閉的多客戶端系統(tǒng)

多客戶端理念可能是上述列表中最有主張的要求 。有放棄它并專注于一個 ZK-SNARK 方案的選擇，這將簡化設(shè)計，但代價是成為以太坊更大的理念轉(zhuǎn)向（因為它實際上是放棄以太坊長期以來的多客戶端理念），并引入更大的風險。在長期的未來，例如形式驗證技術(shù)變得更加完善時，可能更好的做法是走這條路線，但目前看來風險似乎太大。

另一種選擇是 封閉的多客戶端系統(tǒng) ，在協(xié)議中已知一組固定的證明系統(tǒng)。例如，我們可能決定使用三個 ZK-EVM：PSE ZK-EVM^[5] ，Polygon ZK-EVM^[6] 和 Kakarot^[7]。一個區(qū)塊需要來自這三個中的兩個的證明才能被視為有效。這比單一證明系統(tǒng)要好，但它使系統(tǒng)更少適應(yīng)性，因為用戶必須維護每個證明系統(tǒng)的驗證器，必然會對納入新證明系統(tǒng)的政治治理程序等產(chǎn)生影響。

這促使 我傾向于開放的多客戶端系統(tǒng) ，其中證明被放置在「區(qū)塊之外」并由客戶端單獨驗證。個體用戶將使用他們想要的客戶端來驗證區(qū)塊，只要有一個證明者為該證明系統(tǒng)創(chuàng)建證明就可以。證明系統(tǒng)通過說服用戶運行它們來獲得影響力，而不是通過說服協(xié)議治理流程。然而，這種方法的復(fù)雜性成本更高，正如我們將看到的那樣。

我們希望 ZK-EVM 實現(xiàn)具備哪些關(guān)鍵特性？

除了正確功能和安全性的基本保證外， 最重要的特性是速度 。雖然可以設(shè)計一個異步的協(xié)議內(nèi) ZK-EVM 功能，僅在經(jīng)過 N 個槽之后才返回每個聲明的答案，但如果我們能夠可靠的保證可以在幾秒鐘內(nèi)生成證明，那么問題就會變得容易的多，因此每個塊鐘發(fā)生的任何事情都是獨立的。

雖然今天為以太坊區(qū)塊生成證明需要很多分鐘甚至小時，但我們知道沒有理論上的理由阻止大規(guī)模并行化：我們總是可以組裝足夠多的 GPU 來分別證明區(qū)塊執(zhí)行的不同部分 ，然后使用遞歸 SNARKs 將證明合并在一起。此外，通過 FPGA 和 ASIC 的硬件加速可以幫助優(yōu)化證明。然而，要實現(xiàn)這一點是一個重大的工程挑戰(zhàn)，不應(yīng)低估。

協(xié)議內(nèi)的 ZK-EVM 功能具體是什么樣的？

類似于 EIP-4844 blob 交易^[8]，我們引入了一種包含 ZK-EVM 聲明的新交易類型：

與 EIP-4844 類似，傳播于內(nèi)存池中的對象將是交易的修改版本：

后者可以轉(zhuǎn)換為前者，但反之則不然。我們還擴展了區(qū)塊 side car 對象（在 EIP-4844^[9] 中引入）以包含區(qū)塊中所做聲明的證明列表。

請注意，在實際操作中，我們很可能希望將 sidecar 分為兩個獨立的 sidecars，一個用于 blob，另一個用于證明，并為每種類型的證明設(shè)立一個獨立的子網(wǎng)（另外還有一個子網(wǎng)用于 blobs）。

在共識層上，我們添加了一個驗證規(guī)則 ：只有當客戶端看到區(qū)塊中每個聲明的有效證明后，才能接受該區(qū)塊。證明必須是一個 ZK-SNARK，證明了 transaction_and_witness_blobs 的串聯(lián)是（Block, Witness）對的序列化，以及使用 Witness（i）在 pre_state_root 上執(zhí)行區(qū)塊是有效的，并且（ii）輸出了正確的 post_state_root。潛在地，客戶端可以選擇等待多種類型證明的 M-of-N。

在這里要提及的一個哲學觀點是，區(qū)塊執(zhí)行本身可以被視為簡單地是需要與 ZKEVMClaimTransaction 對象中提供的三元組一起檢查的 (σ_pre,σ_post,Proof) 三元組之一。因此，用戶的 ZK-EVM 實現(xiàn)可以替換他們的執(zhí)行客戶端；執(zhí)行客戶端仍將由（i）證明者和區(qū)塊構(gòu)建者使用，以及（ii）關(guān)心本地使用索引和存儲數(shù)據(jù)的節(jié)點使用。

驗證和重新證明

假設(shè)有兩個以太坊客戶端，其中一個使用 PSE ZK-EVM，另一個使用 Polygon ZK-EVM。假設(shè)到目前為止，這兩個實現(xiàn)都已經(jīng)進化到可以在 5 秒內(nèi)證明以太坊區(qū)塊執(zhí)行的程度，并且對于每種證明系統(tǒng)，都有足夠多的獨立志愿者運行硬件來生成證明。

不幸的是，由于個體證明系統(tǒng)沒有被納入，因此它們無法在協(xié)議中獲得激勵；然而，我們預(yù)計與研究和開發(fā)相比，運行證明者的成本將較低， 因此我們可以簡單地通過用于公共產(chǎn)品資助的通用機構(gòu)來資助證明者 。

假設(shè)有人發(fā)布了 ZKEvmClaimNetworkTransaction，但只發(fā)布了 PSE ZK-EVM 的 proof 版本。Polygon ZK-EVM 的證明節(jié)點看到了這一情況，計算并重新發(fā)布了具有 Polygon ZK-EVM proof 的對象。

這增加了最早接受區(qū)塊的誠實節(jié)點和最后接受同一區(qū)塊的最新誠實節(jié)點之間的總最大延遲，從 δ 到 2δ+T_prove（在這里假設(shè) T_prove

然而，好消息是， 如果我們采用單個槽最終確定性，我們幾乎可以肯定地將這種額外延遲與 SSF 中固有的多輪共識延遲一起"管道化"處理。 例如，在這個 4 子槽提案^[10] 中，"頭投票"步驟可能只需要檢查基本區(qū)塊的有效性，但"凍結(jié)并確認"步驟需要存在一個證明。

擴展：支持 almost-EVMs

ZK-EVM 功能的一個理想目標是 支持almost-EVMs：他是是具有一些額外特性的 EVM 。這可能包括新的預(yù)編譯器、新的操作碼、有選項可以用 EVM 或完全不同的 VM（例如 Arbitrum Stylus^[11] 中的情況）方式來編寫合約，甚至具有同步交叉通信的多個并行 EVM。

一些修改可以以簡單方式支持：我們可以定義一種語言，允許 ZKEVMClaimTransaction 傳遞修改后的 EVM 規(guī)則的完整描述。這可以應(yīng)用于：

自定義 gas 成本表（用戶不允許減少 gas fee，但可以增加）

禁用特定操作碼

設(shè)置區(qū)塊編號（這將意味著根據(jù)硬分叉而有不同的規(guī)則）

設(shè)置激活專門用于 L2 但不用于 L1 的一整套 EVM 變更的標志，或者其他簡單的變更

為了允許用戶通過引入新的預(yù)編譯器（或操作碼）以更加開放地引入新功能，我們可以在以下位置添加預(yù)編譯的輸入/輸出腳本，其作為 ZKEVMClaimNetworkTransaction 中 blob 的一部分包含在：

EVM 執(zhí)行將進行修改。一個數(shù)組 inputs 將被初始化為空。第 i 次調(diào)用 used_precompile_addresses 中的地址時，我們向 inputs 添加 InputsRecord(callee_address, gas, input_calldata)，并將調(diào)用的 RETURNDATA 設(shè)置為 outputs[i]。最后，我們檢查 used_precompile_addresses 總共被調(diào)用了 len(outputs)次，以及 inputs_commitments 是否與對 inputs 的 SSZ 序列化產(chǎn)生的 blob 承諾的結(jié)果相匹配。暴露 inputs_commitments 的目的是為了便于外部 SNARK 證明輸入與輸出之間的關(guān)系。

請注意輸入（存儲在哈希中）和輸出（以字節(jié)形式存儲）之間的不對稱性。這是因為執(zhí)行需要能夠由只看到輸入并理解 EVM 的客戶端完成。EVM 執(zhí)行已經(jīng)為它們生成了輸入，因此它們只需要檢查生成的輸入是否與聲稱的輸入匹配，這只需要進行哈希檢查。然而，輸出必須完整提供給它們，因此必須具有數(shù)據(jù)可用性。

另一個有用的特性可能是 允許"特權(quán)交易" ，可以從任意發(fā)送方帳戶進行調(diào)用。這些交易可以在兩個其他交易之間運行，或者在另一個（可能也是特權(quán)的）交易中調(diào)用預(yù)編譯器時運行。這可以用于允許非 EVM 機制回調(diào)到 EVM。

此設(shè)計可以修改以支持新的或修改后的操作碼 ，除了新的或修改后的預(yù)編譯器。即使只有預(yù)編譯器，這種設(shè)計也非常強大。例如：

通過將 used_precompile_addresses 設(shè)置為包含在狀態(tài)中具有某些標志的常規(guī)帳戶地址列表，并生成一個 SNARK 證明以證明其正確構(gòu)造，你可以支持像 Arbitrum Stylus^[12]風格的特性，其中合約可以在 EVM 或 WASM（或其他 VM）中編寫其代碼。特權(quán)交易可用于允許 WASM 帳戶回調(diào)到 EVM。

通過添加外部檢查來驗證多個 EVM 執(zhí)行的輸入/輸出記錄和特權(quán)交易以正確方式匹配，你可以證明一種多個 EVM 的并行系統(tǒng)，這些系統(tǒng)通過同步通道進行通信。

Type 4 的 ZK-EVM^[13]可以通過多個實現(xiàn)來運行：一種將 Solidity 或其他更高級別的語言直接轉(zhuǎn)換為 SNARK 友好的 VM 的實現(xiàn)，并另一種將其編譯為 EVM 代碼并在內(nèi)置的 ZK-EVM中執(zhí)行。第二種（不可避免地更慢）實現(xiàn)只能在出現(xiàn)故障證明者發(fā)送交易斷言存在漏洞的情況下運行，并在提供一個兩處處理不同的交易時，則收取賞金。

可以通過使所有調(diào)用返回零并將調(diào)用映射到添加到區(qū)塊末尾的特權(quán)交易來實現(xiàn)純異步 VM。

擴展：支持有狀態(tài)的證明者

上述設(shè)計的一個挑戰(zhàn)是它完全是無狀態(tài)的，這使得它數(shù)據(jù)效率低下。使用理想的數(shù)據(jù)壓縮，與僅使用無狀態(tài)壓縮相比，一個 ERC20 發(fā)送在使用有狀態(tài)壓縮時，空間效率最高可提高 3 倍。

除此之外，有狀態(tài)的 EVM 不需要提供見證數(shù)據(jù)。在兩種情況下，原則都是相同的：要求數(shù)據(jù)可用是一種浪費，因為我們已經(jīng)知道該數(shù)據(jù)是可用的，因為它是在先前的 EVM 執(zhí)行中輸入或生成的。

如果我們想使 ZK-EVM 功能有狀態(tài)，則有兩種選擇：

要求 σ_pre 為空 ，或者是一個的預(yù)先聲明的鍵和值數(shù)據(jù)可用列表，或者是先前執(zhí)行 σ_post的某個列表

向（σ_pre，σ_post，Proof）元組添加一個與區(qū)塊生成的 receipt R 的 blob 承諾。 在 ZKEVMClaimTransaction 中可以引用任何先前生成或使用的 blob 承諾，包括代表區(qū)塊、見證、receipt，甚至常規(guī)的 EIP-4844 blob 交易，或許還有一些時間限制，可以在其執(zhí)行期間訪問（可能通過一系列指令：「在區(qū)塊+見證數(shù)據(jù)的位置 j 插入承諾 i 的字節(jié) N...N+k-1」）

(1) 基本是說：與其無狀態(tài) EVM 驗證納入其中（封裝），不過將 EVM 子鏈納入其中（封裝）。（2）本質(zhì)上是創(chuàng)建了一個最小的內(nèi)置有狀態(tài)壓縮算法，該算法使用先前使用或生成的 blobs 作為字典。這兩種方式都會給證明節(jié)點增加負擔，并且只有證明節(jié)點才能存儲更多信息；在情況（2）中，比情況（1）更容易使該負擔有時間限制。

封閉式多證明系統(tǒng)和鏈下數(shù)據(jù)的論據(jù)

封閉式多證明系統(tǒng)，其中具有 M-of-N 結(jié)構(gòu)的固定數(shù)量的證明系統(tǒng)，避免了上述許多復(fù)雜性。 封閉式多證明者系統(tǒng)特別是不需要擔心確保數(shù)據(jù)在鏈上的問題。此外，封閉式多證明者系統(tǒng)將允許 ZK-EVM 證明鏈下執(zhí)行；這使其與 EVM Plasma 解決方案^[14]兼容。

然而， 封閉式多證明者系統(tǒng)增加了治理復(fù)雜性并消除了可審計性 ，這些是需要權(quán)衡帶來這些好處的高成本。

如果 ZK-EVM 作為協(xié)議功能，那Layer2 項目的持續(xù)作用是什么？

當前由 Layer2 團隊實現(xiàn)的 EVM 驗證功能將由協(xié)議處理，但 Layer2 項目仍將負責許多重要功能：

快速預(yù)確認 ：單個槽最終性可能會使 Layer1 槽（slot）變慢，而 Layer2 項目已經(jīng)為其用戶提供了由 Layer2 自身安全性支持的「預(yù)確認」，延遲遠低于一個槽。這項服務(wù)將繼續(xù)純粹由 Layer2 負責。

MEV 緩解策略 ：這可能包括加密內(nèi)存池、基于聲譽的序列選擇以及 Layer1 不愿意實施的其他功能。

對 EVM 的擴展 ：Layer2 項目可以包含對 EVM 的重要擴展，為其用戶提供巨大價值。這包括alomost-EVM 和諸如 Arbitrum Stylus^[15]的 WASM 支持以及 SNARK-friendly Cairo（https://www.cairo-lang.org/）語言等完全不同的方法。

面向用戶和開發(fā)者的便利性 ：Layer2 團隊致力于吸引用戶和項目進入其生態(tài)系統(tǒng)并使其感到受歡迎；他們通過在其網(wǎng)絡(luò)內(nèi)捕獲 MEV 和擁堵費用來獲得補償。這種關(guān)系將繼續(xù)存在。