Vitalik：ZK-EVM如何改變以太坊驗證方式並成為第三種客戶端？

轉自：《 Vitalik：以太坊的多客戶端理念將如何與ZK-EVM 交互｜萬物研究院翻譯》

編譯：Ken0928.eth，萬物研究院

TL;DR

Vitalik在其2023年4月1日的文章《以太坊的多客戶端理念將如何與ZK-EVM 交互？ 》中討論了以太坊多客戶端理念的現狀和發展趨勢，並就ZK-EVM的興起如何影響以太坊區塊鏈驗證方式進行分析。目前，以太坊多客戶端的理念由架構去中心化的技術效益和政治去中心化的社會效益兩者驅動，並為兩者服務。未來，隨著零知識證明技術的發展，第一類ZK-EVM 或將基於SNARK證明來改善Layer1的驗證方式，並逐漸引導以太坊向著“開放的多客戶端ZK-EVM 生態系統”發展。

1 引言

多客戶端理念是一種未被充分討論但非常重要的、以太坊維護其安全性和去中心化的方式。以太坊有意沒有一個默認的“參考客戶端”，相反，僅有一個協作管理的規範（目前的共識規範由可讀但運行速度較慢的Python編寫）並且有多個團隊實現這一規範（也稱為“客戶端” ），這些客戶端是用戶目前實際建立並運行以太坊節點的方式。

圖：以太坊客戶端類型及部署比例

每個以太坊節點運行一個共識客戶端和一個執行客戶端。截至今天，沒有共識或執行客戶端佔網絡的2/3 以上。如果在其類別中份額低於1/3 的客戶端出現錯誤，則網絡將照常運行。如果在其類別中佔有1/3 到2/3 份額的客戶端（例如Prysm、Lighthouse 或Geth）出現錯誤，鏈將繼續添加區塊，但它會停止敲定區塊（finalizing block），從而為開發人員提供時間進行干預。

ZK-EVM的興起如何影響以太坊鏈驗證方式是一個未被充分討論但非常重要的、並即將要到來的重大事項。基於SNARK證明的EVM執行已經開發多年，該技術正被基於ZK-rollups的Layer2協議積極使用。其中一些ZK-Rollup今天在主網上很活躍，並且很快就會有更多。但從長遠來看，ZK-EVM 不期望僅僅被用於Rollup，我們也想用其來驗證Layer1的執行情況（另請參閱：Verge）。

這時，ZK-EVM 實際上成為第三種類型的以太坊客戶端，對網絡安全的重要性與執行客戶端和共識客戶端一樣重要。那麼ZK-EVM 將如何與多客戶端理念交互？困難的部分之一已經完成：以太坊已經有多個正在積極開發的ZK-EVM。但其他困難的部分仍然存在：我們如何為zk創建一個“多客戶端”生態系統來驗證以太坊區塊的正確性？這個問題帶來了一些有趣的技術挑戰，但眼前的問題是這樣的權衡是否值得。

2 以太坊多客戶端理念的最初動機是什麼？

以太坊的多客戶端理念是一種去中心化，就像一般的去中心化一樣，人們可以關注架構去中心化的技術效益，也可以關注政治去中心化的社會效益。最終，多客戶端的理念是由兩者驅動的，並為兩者服務。

2.1 技術去中心化的論據

技術去中心化的主要好處很簡單：它降低了一個軟件中的一個錯誤導致整個網絡災難性崩潰的風險。這種風險在2010 年的比特幣溢出漏洞事件中真實發生過。當時，比特幣客戶端代碼沒有檢查交易輸出的總和是否溢出（通過總和超過最大整數2^64−1迴繞到零)，所以有人利用這一漏洞做了一筆交易，給了自己數十億比特幣。該漏洞在數小時內被發現，並迅速在網絡中完成了修復和部署工作，但如果當時有一個成熟的生態系統，這些比特幣就會被交易所、跨鏈橋和其他途徑所接受，攻擊者可能早已卷巨款而逃。但如果有五個不同的比特幣客戶端，他們不太可能都有相同的錯誤，因此一旦發生這類事故，整個網絡會立即出現共識分歧，而分歧中有錯誤的一方可能會輸掉。

使用多客戶端方法來最小化災難性錯誤的風險仍然需要權衡：這種情況下用戶會遇到共識失效（consensus failure）的bug。比如，如果您有兩個客戶端，則客戶端對某些協議的規則有細微編碼差異的風險，雖然兩種方式都是符合規則的，但分歧會導致區塊鏈硬分叉。在以太坊的歷史上發生過一次（還有其他更小的分叉，其中運行舊版本代碼網絡的一部分被分叉）這類嚴重的分叉。單一客戶端機制的捍衛者指出，共識失效是不採用多客戶端實現的原因：如果只有一個客戶端，則該客戶端必然會為自己辯護。他們關於客戶數量如何轉化為風險的模型可能如下所示：

圖：共識失效風險與客戶端類型數的關係

但Vitalik本人並不認同單一客戶端機制，首先(i) 2010 年比特幣的災難性錯誤非常重要， (ii)並且實際上永遠不會只有一個客戶端。後一點在2013 年的比特幣分叉中表現得最為明顯：由於兩個不同版本的比特幣客戶端之間存在分歧而發生了分叉，其中一個版本在單個塊中可以修改的對像數量上有一個偶然的、未被記錄的限制。因此，理論上一個客戶端在事實上通常是兩個客戶端，理論上五個客戶端事實上可能是六個或七個客戶端- 所以我們應該走在風險曲線的右側，並且至少有幾個不同的客戶端。

2.2 政治去中心化的論據

壟斷客戶端開發人員處於擁有大量政治權力的位置。如果客戶端開發人員提出更改，而用戶不同意，理論上他們可以拒絕下載更新版本，或者在沒有其的情況下創建一個分叉鏈，但實際上用戶通常很難做到這一點。如果不當的協議更改與必要的安全更新捆綁在一起怎麼辦？如果主要團隊威脅說如果他們不按他們的方式行事就退出怎麼辦？或者，如果壟斷客戶端的團隊最終成為唯一擁有最強大協議專業知識的群體，而使生態系統中其他人處於不利地位，無法有效判斷客戶端團隊提出的技術方案，從而使客戶端團隊有很大的空間來推動其特定的目標和價值觀，而這與更廣泛的社區並不匹配。

在2013-2014 比特幣OP_RETURN 戰爭的背景下，一些參與者公開支持歧視區塊鏈的一些特別用途。這激發了以太坊對協議政治的擔憂，也是以太坊早期採用多客戶端理念的重要促成因素，這旨在讓小群體更難做出此類決定。以太坊生態系統特有的擔憂——即避免權力集中在以太坊基金會內部——為這一方向提供了進一步的支持。 2018 年，基金會決定有意不實施以太坊PoS 協議（即現在所謂的“共識客戶端”），而將該任務完全留給外部團隊開發。

3 未來ZK-EVM 將如何進入L1？

如今，ZK-EVM 正在積極地被用於Rollup。這通過允許昂貴的EVM 執行僅在鏈下發生幾次來增加擴展性，而其他人只需驗證鏈上發布的SNARKs即可證明EVM 執行結果的正確性。它還允許一些數據（特別是簽名）不包含在鏈上，從而節省gas 成本。這給了我們很多可擴展性的好處，可擴展計算與ZK-EVM 和可擴展數據與數據可用性採樣的結合可以讓擴展走得更遠。

然而，今天的以太坊網絡也有一個不同的問題，一個再多的L2 擴容也無法自行解決的問題：L1 難以驗證，以至於沒有多少用戶真正運行自己的節點。相反，大多數用戶只是信任第三方工具提供商。 Helios和Succinct等輕客戶端正在採取措施解決該問題，但輕客戶端遠非全驗證節點：輕客戶端僅驗證稱為同步委員會（sync committee）的隨機驗證器子集的簽名，而不會驗證該鍊是否實際上在遵循協議規則。為了讓我們進入一個用戶可以實際驗證鍊是否遵守規則的世界，我們必須做一些不同的事情。

3.1 選項1：限制L1，將幾乎所有活動強制移動到L2

隨著時間的推移，我們可以將L1每個區塊的gas 目標從1500 萬減少到100 萬，足以讓一個區塊包含一個SNARK 和一些存款和取款操作，但其他的不多，從而使幾乎所有的用戶活動強制移動到L2協議中。這樣的設計仍然可以支持在每個塊中提交許多Rollup：我們可以使用由定制構建器（customized builders）運行的鏈下聚合協議來從多個L2協議收集多個SNARK證明，並將它們組合成單個SNARK證明。這時，L1的唯一功能是成為L2協議的清算中心，驗證它們的ZKP並偶爾促成它們之間的大額資金轉移。

圖：選項一的可能技術解決方案圖解

這種方法可能有效，但它有幾個重要的弱點：

• 缺乏向後兼容性，因為許多現有的基於L1 的應用程序在經濟上變得不可行。高達數百或數千美元的用戶資金可能會陷入困境，因為費用變高後甚至會超過清空這些賬戶的成本。這可以通過讓用戶簽署消息以選擇協議內大規模遷移到他們選擇的L2 來解決（參見此處的一些早期實施想法）但這增加了過渡的複雜性，而且要讓它的成本真正足夠低，無論如何都需要在L1進行某種SNARK。當涉及到SELFDESTRUCT這樣的操作碼時，Vitalik本人通常支持打破向後兼容性，但在這種情況下，折衷似乎不那麼有利。
• 可能仍然無法使驗證成本足夠低。理想情況下，以太坊協議應該不僅在筆記本電腦上而且在手機、瀏覽器擴展程序甚至其他鏈中都應該易於驗證。第一次同步鏈，或者長時間離線後同步，應該也很容易。筆記本電腦節點可以在大約20 毫秒內驗證100 萬gas，但即使這樣也意味著在離線一天后需要54 秒進行同步（假設單slot敲定將slot時間增加到32 秒），而對於手機或瀏覽器擴展，則每個塊需要幾百毫秒，並且會造成不可忽視的電池損耗。這些數字是可控的，但仍不理想。
• 即使在L2 優先的生態系統中， L1 至少在某種程度上可以負擔得起也是有好處的。如果用戶在註意到新的狀態數據不再可用時可以提取資金，Validiums可以從更強大的安全模型中受益。如果的L2跨鏈transfer操作的最小規模進一步變小在經濟上可行，套利（尤其是小幣種套利）將變得更加有效。

因此，嘗試找到一種使用ZK-SNARKs 來驗證L1的方法似乎更合理。

3.2 選項2：基於SNARK證明的L1驗證

第一類（完全等效於以太坊）ZK-EVM可用於驗證L1的EVM 執行。我們可以編寫更多的SNARK 代碼來驗證區塊的共識方面。這將是一個具有挑戰性的工程問題：今天，ZK-EVM 需要幾分鐘到幾小時來驗證以太坊區塊，並且實時生成zk證明需要（i）改進以太坊本身以刪除對SNARK 不友好的組件，（ii）或者通過專門的硬件獲得巨大的效率提升，(iii)或者通過更多的並行化來改進架構。然而，沒有根本的技術原因去阻止三者的實現——所以Vitalik本人希望即使需要很多年，它也最終會完成。

這是ZKEVM與多客戶端交集的地方：如果我們使用ZK-EVM 來驗證L1，要使用哪個ZK-EVM？

1. 單一的客戶端ZK-EVM 機制：放棄多客戶端範式，並選擇我們用來驗證區塊的單一ZK-EVM。
2. 封閉的多客戶端ZK-EVM 生態系統：就一組特定的多個ZK-EVM 達成一致並達成共識，並有一個共識層協議規則，即一個區塊需要來自該集合中超過一半的ZK-EVM的證明才能被認為是有效的.
3. 開放的多客戶端ZK-EVM 生態系統：不同的客戶端有不同的ZK-EVM 實現，每個客戶端在接受一個塊為有效之前等待與自己的實現兼容的證明。

對Vitalik本人來說，（3）似乎是理想的，至少在我們可以形式化證明所有ZK-EVM 能實現彼此等效並完成技術改進之前，我們可以選擇一個最高效的。 (1) 會犧牲多客戶端範式的好處，並且(2) 會關閉開發新客戶端的可能性並導致更加集中的生態系統。 (3) 有挑戰，但至少目前這些挑戰似乎比其他兩個選項的挑戰要小。

實施(3) 不會太難：每個ZK-EVM類型的證明可能都有一個P2P子網絡，使用一種ZK-EVM類型證明的客戶端將監聽相應的子網絡並等待直到他們得知驗證者認為其證明有效。

(3) 的兩個主要挑戰可能如下：

• 延遲挑戰：惡意攻擊者可能會延遲發布一個塊，以及對一個客戶端有效的證明。生成對其他客戶端有效的證明實際上需要很長時間（即使是15 秒）。這段時間足夠長去創建一個臨時分叉鏈併中斷主鏈的幾個slot。
• 數據效率低下： ZK-SNARKs 的一個好處是可以從塊中刪除僅與驗證相關的數據（有時稱為“見證數據（witness data）”）。例如，一旦你驗證了一個簽名，你就不需要將簽名保存在一個塊中，你可以只存儲一個表示簽名有效的bit，並在塊中存儲一個證明，以確認所有有效簽名都存在。但是，如果我們希望能夠為一個塊生成多種ZK-EVM類型的證明，則需要實際發布原始簽名。

延遲挑戰可以通過在設計單slot敲定協議時更加謹慎來解決。單slot敲定協議可能需要每個slot進行超過兩輪的共識，因此可能需要第一輪包含區塊，並且只需要節點在第三輪（或最後一輪）簽名之前驗證證明。這確保了在發佈區塊截止時間和預計證明可用時間之間始終有一個重要的時間窗口可用。

數據效率問題必須通過單獨的協議來聚合與驗證相關的數據來解決。對於簽名，我們可以使用ERC-4337 已經支持的BLS聚合。另一類驗證相關的數據是用於隱私的ZK-SNARKs，當然這些數據往往有自己的聚合協議。

值得一提的是，基於SNARK證明的L1驗證有一個重要的好處：鏈上EVM 執行不再需要由每個節點驗證，這使得大大增加EVM的執行數量成為可能。這可以通過大幅提高L1 的gas limit，或通過引入受保護的rollup來完成，或兩者兼而有之。

4 結論

使一個開放的多客戶端ZK-EVM 生態系統運行良好需要大量的工作。但值得慶幸的是，這項工作的大部分正在發生或無論如何都會發生：

• 我們已經有多個強大的ZK-EVM實現。這些實現還不是第一類ZK-EVM（完全等同於以太坊），但其中許多正在積極朝著這個方向發展。
• 在Helios和Succinct等輕客戶端上的工作最終可能會變成對以太坊鏈的PoS 共識端進行更全面的SNARK 驗證。
• 客戶端可能會開始嘗試使用ZK-EVM 來證明自己的以太坊區塊執行，特別是當我們有無狀態態客戶端並且沒有技術需要去直接重新執行每個區塊來維護狀態時。我們可能會從客戶端通過重新執行來驗證以太坊區塊，到大多數客戶端通過檢查SNARK證明來驗證以太坊區塊，這將是一個緩慢而漸進的過渡。
• ERC-4337 和PBS 生態系統可能會很快開始使用BLS 和證明聚合等聚合技術，以節省gas 成本，並且目前BLS 聚合的工作已經開始。

有了這些技術，未來看起來非常美好。以太坊區塊會比今天更小，任何人都可以在他們的筆記本電腦甚至他們的手機或瀏覽器擴展程序中運行一個全驗證節點，這一切都會發生，同時保留以太坊多客戶端理念的優點。

從長遠來看，一切皆有可能。也許AI 會增強形式化驗證程度，使其可以輕鬆證明ZK-EVM 實現的等效並識別導致它們之間差異的所有錯誤，這甚至可能是現在就要開始著手開發的項目。如果這種基於形式化驗證的協議能夠成功，則需要建立不同的機制以確保該協議的政治去中心化持續進行；也許到那時，協議將被視為“完整的”，不可變型規範將更加強大。但即使這是更長遠的未來，開放的多客戶端ZK-EVM 生態系統似乎是一個必經之路，無論如何都有可能發生。

從短期來看，這仍然是一段漫長的旅程。 ZK-EVM就在這裡，但ZK-EVM 在L1真正可行將需要它們首先改進為第一類ZK-EVM，並使證明產生足夠快以使其可以實時發生。有了足夠的並行化（這是可行的，但要實現這一點仍然需要做很多工作），共識變化（如提高KECCAK、SHA256 和其他哈希函數預編譯的gas 成本）也將是以太坊藍圖的重要組成部分。也就是說，過渡的第一步可能比我們預期的要早：一旦我們切換到Verkle 樹和無狀態客戶端，客戶端就可以開始逐漸使用ZK-EVM，並且可以自行過渡到“開放的客戶端ZK-EVM 生態系統”。