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