摘要：昨天，Vitalik在他的博客中更新了一篇名為《Whatmightan“enshrinedZK-EVM”looklike?因此，我們可以直接快速的從文章標題了解Vitalik這篇文章的意圖：探討將零知識證明（ZK）版本的以太坊虛擬機（EVM）作為核心或官方部分，整合到以太坊協議中的可能性。...
昨天，Vitalik 在他的博客中更新了一篇名為《What might an “enshrined ZK-EVM” look like?》的文章，系統性的闡述了以太坊集成ZK-EVM的可行性、方法和預期效果等內容。
EVM的未來發展往往關聯到多種與基礎設施相關的敘事或方向變化，值得我們進行閱讀和研究。
但考慮到該文章涉及太多技術細節，中文媒體和社區中大部分的材料都只是對該文章進行簡單的翻譯，很容易讓人摸不清文章的來龍去脈和觀點。
因此，深潮對該文章進行了解讀，試圖以更通俗的方式來還原Vitalik的寫作思路和觀點，為各位讀者提供參考。
標題的單詞暗示：將ZK-EVM奉為正統
如果僅看直接翻譯的文章，你很看get到英文語境下的某種暗示或自然表達。
在Vitalik這篇文章的標題中，出現了一個不怎么常用的英文單詞 --- ”enshrined“。
簡單查閱GPT或英文詞典你就可以看到：
"Enshrined" 這個詞在英文中原本的意思是“奉為神圣”，常用于形容將某物或某人的地位、重要性或價值提升到極高的水平，好比將其放置在一個神圣或受保護的位置上。
在法律或宗教文本中，"enshrine" 通常指的是將某些原則、權利或信仰正式地并且以尊重的方式記錄或保留下來。
而在技術或軟件領域，"enshrined" 通常意味著將某項技術、功能或原則正式地并且重要地集成到系統、框架或協議中。這通常意味著該技術或功能被認為是基礎性的、核心的，或者至關重要的，因此被正式地并且持久地納入系統。
因此，我們可以直接快速的從文章標題了解Vitalik這篇文章的意圖：
探討將零知識證明（ZK）版本的以太坊虛擬機（EVM）作為核心或官方部分，整合到以太坊協議中的可能性。
這也就是說，以太坊或許之后不只是將ZK-EVM作為一個附加組件來看待。
ZK-EVM的過去：L2形式的“外掛組件”，非原生
對不熟悉以太坊EVM和相關L2解決方案的讀者來說，Vitalik 探討將ZK-EVM作為以太坊主網的正式部分，很容易讓人想到另一個問題：
在以前，ZK-EVM和以太坊是什么關系？以前ZK-EVM不是以太坊的“正式部分”嗎？
讓我們做一個非常輕度且快速的科普：
- 以太坊虛擬機（EVM）：以太坊網絡的核心，負責執行智能合約代碼。所有在以太坊上運行的智能合約都是通過EVM來執行的。
- 零知識證明（ZK）：一種加密技術，允許一方（證明者）向另一方（驗證者）證明某個陳述是真實的，而無需透露除了這個陳述之外的任何信息。這種技術在加密貨幣和區塊鏈領域中被用來增強交易的隱私性和安全性。
- ZK-EVM的作用：結合了EVM的功能和零知識證明的隱私保護特性。它允許在保持交易數據私密的同時，驗證交易的有效性。這意味著可以在不公開交易具體內容的情況下，證明交易是符合智能合約和區塊鏈規則的。
- ZK-EVM與以太坊主網的關系：ZK-EVM可以作為一種解決方案，它在保持以太坊虛擬機兼容性的同時，引入了零知識證明，使得執行的交易可以保持私密。在早期，ZK-EVM更多的是作為第二層（Layer 2）解決方案出現，即它建立在以太坊主網之上，為主網提供額外的隱私保護和擴展性功能。
因此，現在的ZK-EVM大多以L2的形式出現，而不是直接在以太坊L1的設計中存在。通俗來說，是外掛組件。
比較知名的ZK-EVM解決方案大家都知道了，例如Starknet、zkSync、Polygon Hermez以及Scroll等。
有了以上背景知識儲備后，再去理解Vitalik的博客就變得容易了很多。
為什么要在以太坊里內置原生ZK-EVM？
順著上文邏輯，你可能會問：ZK-EVM的L2方案做的好好的，為什么Vitalik試圖討論將ZK-EVM直接納入以太坊的核心設計中？
Vitalik非常言簡意賅的給出了回答：
- 對大型代碼庫的依賴:當前的Layer 2解決方案，如Optimistic Rollups和ZK Rollups，依賴于EVM驗證。這意味著它們必須信任一個龐大的代碼庫。如果代碼庫中存在漏洞，這些虛擬機（VMs）可能面臨被黑客攻擊的風險。
- 治理問題: 即使是希望與L1 EVM保持完全等效的ZK-EVMs，也需要某種形式的治理機制，以便將L1 EVM中的更改復制到它們自己的EVM實現中。這增加了復雜性和潛在的不一致性風險。
- 功能重復:Layer 2項目復制了以太坊協議中已經存在的功能。以太坊治理已經負責進行升級和修復漏洞。ZK-EVM在本質上執行的工作與驗證L1以太坊區塊的工作相同。
- 未來的輕客戶端發展: 隨著輕客戶端變得越來越強大，并很快能夠使用ZK-SNARKs來完全驗證L1 EVM執行，以太坊網絡將有效地擁有一個內置的ZK-EVM。這提出了一個問題：為什么不為rollups也提供這種原生的ZK-EVM呢？
通過探討這些問題，Vitalik闡明了將ZK-EVM納入以太坊核心設計的動機--- 主要是為了解決依賴外部代碼庫的風險、簡化治理過程、減少功能重復，并利用以太坊網絡本身具備的能力。
內置ZK-EVM，應該長什么樣？
那么以太坊如果要內置ZK-EVM，應該具備怎樣的功能和特性？Vitalik進一步給出了思路：
- 基本功能：ZK-EVM的核心功能是驗證以太坊區塊。這意味著它應該能夠接受一個前狀態根（pre-state root）、一個區塊和一個后狀態根（post-state root）作為輸入，并驗證后狀態根確實是執行該區塊后的結果。
- 與以太坊多客戶端哲學的兼容性：ZK-EVM應該避免只采用單一的證明系統，而是允許不同的客戶端使用不同的證明系統。這涉及到數據可用性的要求，以及證明應該獨立于EVM和區塊數據結構之外的考慮。
- 審計性：如果任何執行被證明，那么底層數據應該是可用的，以便在出現問題時用戶和開發者可以檢查。
- 可升級性：如果發現特定的ZK-EVM方案存在漏洞，應該能夠快速修復，而不需要進行硬分叉。
- 支持幾乎相同的EVM（almost-EVMs）：ZK-EVM應該支持在執行層面的創新和對EVM的擴展。如果一個給定的L2的VM只是稍微不同于EVM，那么它仍然可以使用原生的協議內ZK-EVM來處理與EVM相同的部分，并僅依賴于它們自己的代碼來處理不同的部分。
注意，這個almost-EVMs可能有讀者不了解，實際上Vitalik之前也提到過類似觀點，他認為有些ZK-EVM解決方案在執行時不應嚴格要求和EVM一模一樣，而是可以變得“有些接近”于原始的EVM。
在Vitalik提出的ZK-EVM框架中，對almost-EVMs的支持意味著ZK-EVM可以更靈活地適應各種不同的需求和場景。這使得ZK-EVM不僅能夠服務于完全遵循標準EVM規范的應用，也能夠支持那些需要或希望進行輕微調整的系統。
內置ZK-EVM，在不同以太坊客戶端上怎么跑？
順著思路繼續看Vitalik的原文，在這里很容易犯迷糊：怎么又突然講到客戶端的事情了？
回顧上文，你會發現Vitalik的闡述邏輯非常清晰：
“我想讓ZK-EVM變成以太坊內置組件 --- 為什么要這么干？---這么干應該滿足哪些功能？”
因此，下一個討論點實際上變成了：這么干，具體落地時在不同的客戶端上怎么運行？
Vitalik給出了2個方向，即在開放的多客戶端系統運行，或者在封閉的多客戶端系統運行。
- 開放式系統：更符合以太坊的去中心化和創新精神，允許社區根據需要開發和采用新的證明技術。
- 封閉式系統：可能更易于管理和維護，但可能限制了系統的長期適應性和創新潛力。
此外，后文中Vitalik也談到了做ZK-EVM更看重速度的重要性，如果ZK-EVM能夠快速生成證明，它將更加適合集成到以太坊主協議中，因為它能夠更好地滿足網絡的性能需求和用戶的體驗期望。
然而，實現這一目標需要克服重大的技術和工程挑戰。Vitalik在這部分內容中明確了這些挑戰，并提出了可能的解決方案和方法。
ZK-EVM具體在以太坊上怎么實現？
Vitalik也給出了ZK-EVM可能的實現方式。
他提出了一種新的交易類型——ZK-EVM聲明交易（ZKEVMClaimTransaction），以及如何在以太坊網絡中處理和驗證這些交易。
由于這部分過于技術，建議沒有基礎的讀者可以直接跳過技術細節。我們直接來看他的設計思路和大意：
- 引入的容器類型，用于在網絡中傳遞ZK-EVM相關的聲明。
- 在共識層，提出了一條新規則，即只有當客戶端看到每個聲明的有效證明后，才接受區塊。
- 用戶在ZK-EVM證明中，可以替換他們的執行客戶端，但執行客戶端仍然被用于生成證明和構建區塊，以及節點存儲和索引數據。
- 不同的ZK-EVM實現可能有不同的證明方法，但他們都可以互相驗證和接受證明。
此外，Vitalik 在這部分內容中討論了對“almost-EVMs”（幾乎等同于以太坊虛擬機的系統）的支持，這是ZK-EVM功能的一個期望目標。
這些系統內置了一些額外的特性，可能包括新的預編譯合約、操作碼、合約編寫選項（比如可以選擇在標準EVM或完全不同的虛擬機中編寫，例如Arbitrum Stylus），甚至是支持同步交叉通信的多個并行EVM。
同時，Vitalik Buterin 討論了ZK-EVM內如何支持帶狀態（stateful）的驗證者，以及為什么這樣做是有益的：
為什么支持狀態驗證者？
- 數據效率：狀態驗證者可以提高數據的壓縮效率。一個完全無狀態的系統需要所有數據在每次交易時都可用，這可能導致數據重復和浪費。狀態驗證者可以存儲之前的狀態信息，減少必須傳輸和處理的數據量。
- 減少數據冗余：如果某個數據片段已經由前一個區塊或交易提供，那么在隨后的證明中就沒有必要再次提供它，因為它已經是“已知”的。
- 系統性能：帶狀態的系統允許更有效的計算和驗證，因為它們可以利用已知的信息，而不是每次都從零開始。
至于如何支持，原文中涉及太多的技術細節，在此難以做深入解讀，我們只需要明白：
"支持狀態驗證者" 意味著在ZK-EVM中引入一個機制，使得系統能夠記住和利用之前的狀態，而不是在每次操作時都完全無狀態。這樣可以提高系統的整體性能，減少所需的數據傳輸，同時允許更高效的計算。這是對ZK-EVM設計的一個擴展，目的是提高其在真實世界應用中的可行性和效率。
內置了ZK-EVM，其他做類似事情的L2怎么辦？
在文章的最后，Vitalik稍微跳出了嚴肅的技術討論，轉而思考另外一個問題，即如果ZK-EVM變成了以太坊L1內置的功能，其他那些做ZK的L2，它們的角色會有什么變化？
在Vitalik的設想中，如果真要這么做，L2后續更多的可能要承擔”輔助位“的角色，在以下幾個方面發揮補充作用：
- 快速預確認：單時隙最終性（single-slot finality）可能會使Layer 1的處理速度變慢，而Layer 2項目可以提供快速的預確認服務，這些服務由Layer 2自身的安全機制支持，延遲時間遠低于一個時隙。這些服務將繼續是Layer 2獨有的職責。
- 最小可提取價值（MEV）緩解策略：這可能包括加密的內存池、基于聲譽的排序器選擇和Layer 1不愿實施的其他功能。Layer 2可以實施這些策略來減少MEV對用戶交易的影響。
- 對EVM的擴展：Layer 2項目可以引入對EVM的重大擴展，為其用戶提供顯著的價值。這包括支持“幾乎是EVM”（almost-EVMs）的版本，或完全不同的方法，例如支持WASM的Arbitrum Stylus和對SNARK友好的Cairo語言。
- 面向用戶和開發者的便利性：Layer 2團隊通過吸引用戶和項目加入他們的生態系統并讓他們感到受歡迎來完成大量工作；他們通過捕獲網絡內的MEV和擁堵費用來獲得報酬。即使ZK-EVM被集成到以太坊協議中，這種模式也將繼續存在。
注意，目前這些都只是Vitalik個人的想法，還沒有正式付諸實踐。
但從這篇博客來看，Vitalik對以太坊自己做ZK-EVM的初衷、方法、功能和額外影響等都考慮的非常清楚，顯然也不是臨時起意。
從EVM，到性能更好的EVM，再到兼顧ZK的EVM，Vitalik作為以太坊的設計者，在讓他的作品以遞進的方式變得更加完善；
當然，在這個過程中他從未排斥過其他的L2解決方案的思路，但似乎也從未放棄以原生的方式將以太坊變得更好。
至于這個ZK-EVM的原生思路是否真的會通過，還要等到這些博客中的思路變成具體的提案才能見分分曉。
不過可以確定地是，當技術革新將至，整個生態也必將風起云涌。
