作者：Vitalik；翻譯：金色財經0x25
一種未被充分討論但非常重要的以太坊維護其安全性和去中心化的方式是其多客戶端理念。以太坊有意沒有默認每個人都運行“參考客戶端”：相反，有一個協作管理的規範（是用非常易讀但非常慢的Python編寫的）並且有多個團隊實現規範（也稱為“客戶端”），這些客戶端客戶端由用戶實際運行。
每個以太坊節點運行一個共識客戶端和一個執行客戶端。截至今天，沒有共識或執行客戶端佔網絡的2/3 以上。如果在其類別中份額低於1/3 的客戶端出現錯誤，則網絡將照常運行。如果在其類別中佔有1/3 到2/3 份額的客戶端（例如Prysm、Lighthouse 或Geth）出現錯誤，鏈將繼續添加區塊，但它會停止最終確定區塊，從而為開發人員提供時間進行干預。
以太坊驗證方式的一個未被充分討論但非常重要的即將到來的重大轉變是ZK-EVM的興起。證明EVM 執行的SNARK已經開發多年，該技術正被稱為ZK rollups的2 層協議積極使用。其中一些ZK Rollups已經在主網激活，很快就會有更多。但從長遠來看，ZK-EVM 不僅僅用於Rollup；我們也想使用它們來驗證1 層的執行情況。
一旦發生這種情況，ZK-EVM 實際上成為第三種類型的以太坊客戶端，對網絡安全的重要性與當今的執行客戶端和共識客戶端一樣重要。這自然會提出一個問題：ZK-EVM 將如何與多客戶端交互？困難的部分之一已經完成：我們已經有多個正在積極開發的ZK-EVM 實現。但其他困難的部分仍然存在：我們如何真正為ZK 證明以太坊區塊的正確性創建一個“多客戶端”生態系統？這個問題提出了一些有趣的技術挑戰——當然還有權衡是否值得的迫在眉睫的問題。
以太坊多客戶端理念的最初動機是什麼？
以太坊的多客戶端哲學是一種去中心化，就像一般的去中心化一樣，人們可以關注架構去中心化的技術收益或政治去中心化的社會收益。最終，多客戶理念受到雙方的推動並為雙方服務。
技術去中心化
技術去中心化的主要好處很簡單：它降低了一個軟件中的一個錯誤導致整個網絡災難性崩潰的風險。例證這種風險的歷史情況是2010 年的比特幣溢出漏洞。當時，比特幣客戶端代碼沒有檢查交易輸出的總和是否溢出（通過總和超過最大整數迴繞到零)，所以有人做了一筆交易，給了自己數十億枚比特幣。該漏洞在數小時內被發現，並迅速修復並在整個網絡中快速部署，但如果當時有一個成熟的生態系統，這些代幣就會被交易所、橋和其他構造所接受，攻擊者可能已經帶走了很多錢。如果有五個不同的比特幣客戶，他們不太可能都有相同的錯誤，因此會立即出現分叉，而分叉中有錯誤的一方可能會輸掉。
使用多客戶端方法來最小化災難性錯誤的風險需要權衡：相反，你會遇到共識失敗錯誤。也就是說，如果你有兩個客戶端，則存在客戶端對某些協議規則有細微不同解釋的風險，雖然兩種解釋都是合理的並且不允許偷錢，但分歧會導致鏈分叉成兩個。這種類型的嚴重分叉在以太坊的歷史上發生過一次（還有其他更小的分叉，其中運行舊版本代碼的網絡的很小一部分被分叉了）。單一客戶端方法的捍衛者將共識失敗作為不具有多個實現的原因：如果只有一個客戶端，則該客戶端不會不同意自己。他們關於客戶數量如何轉化為風險的模型可能如下所示：
我當然不同意這種分析。我不同意的地方在於(i) 2010 年風格的災難性錯誤也很重要，並且(ii)你實際上永遠不會只有一個客戶端。後一點在2013 年的比特幣分叉中表現得最為明顯：由於兩個不同版本的比特幣客戶端之間存在分歧而發生了鏈分叉，其中一個版本意外地限制了可以使用的對像數量，但未記錄在案。在單個區塊中進行修改。因此，理論上一個客戶端在實踐中通常是兩個客戶端，理論上五個客戶端在實踐中可能是六個或七個客戶端。所以我們應該面對冒險並走在風險曲線的右側，並且至少有幾個不同的客戶端。
政治去中心化
壟斷的客戶端的開發人員處於擁有大量政治權力的位置。如果客戶端開發人員提出更改，而用戶不同意，理論上他們可以拒絕下載更新版本，或者在沒有它的情況下創建一個分叉，但實際上用戶通常很難做到這一點。如果不愉快的協議更改與必要的安全更新捆綁在一起怎麼辦？如果主要團隊威脅說如果他們不按他們的方式行事就退出怎麼辦？或者，更溫和地說，如果壟斷的客戶端團隊最終成為唯一擁有最強大協議專業知識的群體，而使生態系統的其他部分處於不利地位，無法判斷客戶端團隊提出的技術論點，從而使客戶端團隊面臨有很大的空間來推動他們自己的特定目標和價值觀，這可能與更廣泛的社區不匹配？
對協議政治的擔憂，特別是在2013-14 比特幣OP_RETURN 戰爭的背景下，一些參與者公開支持分叉鏈的特定用途，是以太坊早期採用多客戶端哲學的重要促成因素，這旨在讓一小部分人更難做出此類決定。以太坊生態系統特有的擔憂——即避免權力集中在以太坊基金會內部——為這一方向提供了進一步的支持。 2018 年，基金會決定有意不實施以太坊PoS 協議（即現在所謂的“共識客戶端”），將該任務完全留給外部團隊。
未來ZK-EVM將如何進入1層？
如今，ZK-EVM 用於Rollup。這通過允許僅在鏈下發生幾次昂貴的EVM 執行來增加擴展性，而其他人只需驗證鏈上發布的SNARKs即可證明EVM 執行計算是否正確。它還允許一些數據（特別是簽名）不包含在鏈上，從而節省gas 成本。這給了我們很多可擴展性的好處，可擴展計算與ZK-EVM 和可擴展數據與數據可用性採樣的結合可以讓我們擴展得更遠。
然而，今天的以太坊網絡也有一個不同的問題，一個再多的layer 2 擴容也無法自行解決的問題：layer 1 難以驗證，以至於沒有多少用戶運行自己的節點。相反，大多數用戶只是信任第三方提供商。 Helios和Succinct等輕客戶端正在採取措施解決該問題，但輕客戶端遠非完全驗證節點：輕客戶端僅驗證稱為同步委員會的隨機驗證者子集的簽名，而不會驗證該鏈實際上遵循協議規則。為了讓我們進入一個用戶可以實際驗證鍊是否遵守規則的世界，我們必須做一些不同的事情。
選項1：限制1層，強制幾乎所有活動移動到2層
隨著時間的推移，我們可以將1層每個區塊的gas 目標從1500 萬減少到100 萬，足以讓一個區塊包含一個SNARK 和一些存款和取款操作，但其他的不多，從而強制幾乎所有用戶活動移動到2層協議。這樣的設計仍然可以支持在每個區塊中提交許多Rollup：我們可以使用由定制構建者運行的鏈下聚合協議來從多個2層協議收集SNARK，並將它們組合成一個SNARK。在這樣的世界中，1層的唯一功能是成為2層協議的交換所，驗證它們的證據並偶爾促進它們之間的大額資金轉移。
這種方法可能有效，但它有幾個重要的弱點：
它實際上是向後不兼容的，因為許多現有的基於L1 的應用程序在經濟上變得不可行。高達數百或數千美元的用戶資金可能會陷入困境，因為費用變得如此之高，以至於超過了清空這些賬戶的成本。這可以通過讓用戶簽署消息以選擇協議內大規模遷移到他們選擇的L2 來解決（參見此處的一些早期實施想法），但這增加了過渡的複雜性，這需要1層的某種SNARK真正足夠便宜。當涉及到SELFDESTRUCT 操作碼之類的東西時，我通常喜歡打破向後兼容性，但在這種情況下，權衡似乎不太有利。
它可能仍然無法使驗證變得足夠便宜。理想情況下，以太坊協議應該不僅在筆記本電腦上而且在手機、瀏覽器擴展程序甚至其他鏈中都應該易於驗證。第一次同步鏈的時候，或者長時間離線後，應該也很容易。筆記本電腦節點可以在大約20 毫秒內驗證100 萬gas，但即使這樣也意味著在離線一天后需要54 秒進行同步（假設單slot最終確定性將slot時間增加到32 秒），而對於手機或瀏覽器擴展，則需要每個區塊幾百毫秒，並且可能仍然是不可忽略的電池消耗。這些數字是可控的，但並不理想。
即使在L2 優先的生態系統中，L1 至少在某種程度上可以負擔得起也是有好處的。如果用戶在註意到新的狀態數據不再可用時可以提取資金，Validiums可以從更強大的安全模型中受益。如果經濟上可行的跨L2 直接轉移的最小規模較小，套利將變得更加有效，尤其是對於較小的代幣。
因此，嘗試找到一種使用ZK-SNARKs 來驗證1層本身的方法似乎更合理。
選項2：SNARK驗證第1 層
類型1（完全等效於以太坊）ZK-EVM可用於驗證（1 層）以太坊區塊的EVM 執行。我們可以編寫更多的SNARK 代碼來驗證區塊的共識方面。這將是一個具有挑戰性的工程問題：今天，ZK-EVM 需要幾分鐘到幾小時來驗證以太坊區塊，並且實時生成證明需要一個或多個（i）改進以太坊本身以刪除對SNARK 不友好的組件，（ii） ) 要么通過專門的硬件獲得巨大的效率提升，要么(iii) 通過更多的並行化改進架構。然而，沒有根本的技術原因不能做到這一點——所以我希望，即使需要很多年，它也會完成。
這是我們看到與多客戶端範式交集的地方：如果我們使用ZK-EVM 來驗證1 層，我們使用哪個ZK-EVM？
我看到三個選項：
1、單一ZK-EVM：放棄多客戶端範式，並選擇我們用來驗證區塊的單一ZK-EVM。
2、Closed multi ZK-EVM：就一組特定的多個ZK-EVM 達成一致並達成共識，並有一個共識層協議規則，即一個區塊需要來自該集合中超過一半的ZK-EVM 的證明才能被認為是有效的.
3、Open multi ZK-EVM：不同的客戶端有不同的ZK-EVM 實現，每個客戶端在接受一個區塊為有效之前等待與自己的實現兼容的證明。
對我來說，（3）似乎是理想的，至少直到並且除非我們的技術改進到我們可以正式證明所有ZK-EVM 實現彼此等效的程度，此時我們可以選擇最重要的一個高效的。 (1) 會犧牲多客戶端範式的好處，並且(2) 會關閉開發新客戶端的可能性並導致更加中心化的生態系統。 (3) 有挑戰，但這些挑戰似乎比其他兩個選項的挑戰要小，至少目前是這樣。
實施(3) 不會太難：每個類型的證明可能都有一個p2p 子網絡，使用一種類型證明的客戶端將監聽相應的子網絡並等待直到他們收到證明他們的證明驗證者認為有效。
(3) 的兩個主要挑戰可能如下：
延遲挑戰：惡意攻擊者可能會延遲發布一個區塊，以及對一個客戶端有效的證明。生成對其他客戶有效的證明實際上需要很長時間（即使例如15 秒）。這段時間足夠長，可能會創建一個臨時分叉併中斷幾個插槽的鏈。
數據效率低下：ZK-SNARKs 的一個好處是可以從區塊中刪除僅與驗證相關的數據（有時稱為“見證數據”）。例如，一旦你驗證了一個簽名，你就不需要將簽名保存在一個區塊中，你可以只存儲一個表示簽名有效的bit，以及區塊中確認所有簽名有效的單個證明。但是，如果我們希望能夠為一個區塊生成多種類型的證明，則需要實際發布原始簽名。
在設計單slot最終確定性協議時要小心，可以解決延遲挑戰。單slot最終確定性協議可能需要每個slot超過兩輪的共識，因此可能需要第一輪包含區塊，並且只需要節點在第三輪（或最後一輪）簽署之前驗證證明。這確保了在發佈區塊的截止日期和預計證明可用的時間之間始終有一個重要的時間窗口可用。
數據效率問題必須通過單獨的協議來聚合與驗證相關的數據來解決。對於簽名，我們可以使用ERC-4337 已經支持的BLS聚合。另一大類與驗證相關的數據是用於隱私的ZK-SNARKs 。幸運的是，這些往往有自己的聚合協議。
還值得一提的是，SNARK 驗證1 層有一個重要的好處：鏈上EVM 執行不再需要由每個節點驗證這一事實使得可以大大增加發生的EVM 執行量。這可以通過大幅增加1 層gas限製或引入enshrined rollups或兩者兼而有之。
結論
使一個開放的多客戶端ZK-EVM 生態系統運行良好需要大量的工作。但真正的好消息是，這項工作的大部分正在發生或無論如何都會發生：
我們已經有多個強大的ZK-EVM實現。這些實現還不是類型1（完全等同於以太坊），但其中許多正在積極朝著這個方向發展。
在Helios和Succinct等輕客戶端上的工作最終可能會變成對以太坊鏈的PoS 共識端進行更全面的SNARK 驗證。
客戶端可能會開始嘗試使用ZK-EVM 來證明自己的以太坊區塊執行，特別是當我們有無狀態客戶端並且沒有技術需要直接重新執行每個區塊來維護狀態時。我們可能會從客戶端通過重新執行它們來驗證以太坊區塊，過渡到大多數客戶端通過檢查SNARK 證明來驗證以太坊區塊。
● ERC-4337 和PBS 生態系統可能會很快開始使用BLS 和證明聚合等聚合技術，以節省gas 成本。在BLS 聚合上，工作已經開始。
有了這些技術，未來看起來非常美好。以太坊區塊會比今天更小，任何人都可以在他們的筆記本電腦甚至他們的手機或瀏覽器擴展程序中運行一個完全驗證的節點，這一切都會發生，同時保留以太坊多客戶端理念的好處。
從長遠來看，當然任何事情都有可能發生。也許AI 會加強形式驗證，使其可以輕鬆證明ZK-EVM 實現等效並識別導致它們之間差異的所有錯誤。這樣的項目甚至可能是現在就開始著手的實用項目。如果這種基於形式驗證的方法取得成功，則需要建立不同的機制以確保該議的政治去中心化持續進行；也許到那時，協議將被視為“完整的”，不變性規範將更加強大。但即使這是更長遠的未來，開放的多客戶端ZK-EVM 世界似乎也是天然的下一步，無論如何都有可能發生。
從短期來看，這仍然是一段漫長的旅程。 ZK-EVM就在這裡，但ZK-EVM 在1 層真正可行將需要它們成為類型1，並使證明足夠快以使其可以實時發生。有了足夠的並行化，這是可行的，但要實現這一點仍然需要做很多工作。共識變化，如提高KECCAK、SHA256 和其他哈希函數預編譯的gas 成本，也將是未來圖像的重要組成部分。也就是說，過渡的第一步可能比我們預期的要早：一旦我們切換到Verkle樹和無狀態客戶端，客戶端就可以開始逐漸使用ZK-EVM，並且到“開放的多ZK-EVM”世界的過渡可以自行發生。
特別感謝Justin Drake 的反饋和審閱