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