Vitalik：以太坊的多客戶端理念將如何與 ZK-EVM 互動？

原文標題：How willEthereum'smulti-client philosophy interact with ZK-EVM?

原文作者：Vitalik Buterin

編譯：倩雯，ChainCatcher

以太坊以多客戶 端 理念 維持其安全性和去中心化， 這一點十分重要，但未曾被深入討論。以太坊並未設計人人都可以都默認運行的"參考客戶端"，而是設定一個用戶協作管理的規範 （最近用可讀性很強但速度很慢的Python中寫成），並有多個團隊對該規範（即"客戶端"）進行實現，這就是用戶實際運行的東西。

每個以太坊節點都運行一個共識客戶端和一個執行客戶端。截至目前，沒有一個共識或執行客戶端占網絡的2/3以上。如果一個在其類別中份額低於1/3的客戶端 出現 錯誤，網絡將 繼續 正常 運行 。如果一個在其類別中占有1/3和2/3份額的客戶端（ 比如 ， Prysm，Lighthouse或Geth） 出現 錯誤，鏈將繼續增加區塊，但它將停止最終確定區塊， 讓 開發人員 有 時間來干預。

在驗證以太坊證的方式中，一個未被充分討論、但即將到來的重大轉變就是ZK-EVM 的崛起。證明EVM執行的SNARK已經被開發多年，該技術正被稱為ZK rollup的L2協議積極採用。其中一些ZK rollup活躍在主網上，更多即將到來。但從長遠來看，ZK-EVM將不僅僅用於rollup，我們還想用它來驗證第一層的執行情況。

這樣一來 ， ZK-EVM就會成為 事實上的 第三種以太坊客戶端， 同目前 的執行客戶端和共識客戶端一樣 ， 對網絡的安全 至關 重要。這自然會引發一個問題：ZK-EVM將如何與多客戶理念互動？其中一個難點已被解決：我們已有多個ZK-EVM的實現，並且正在積極開發。但其他困難的部分仍然存在：我們將如何真正將"多客戶"生態系統用於ZK證明以太坊區塊的正確性？這個問題帶來了一些有趣的技術挑戰------當然還有一個亟待解決的問題，即這些取捨是否值得。

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

以太坊的多客戶理念是一種去中心化，就像一般的去中心化，人們既可以關注架構去中心化的技術好處，也可以關注政治去中心化的社會好處。最終，多客戶理念由這兩者促成，並為這兩者服務。

技術 去中心化

技術去中心化的主要好處很簡單：它減少了軟件中的一個錯誤導致整個網絡全然崩潰的風險。體現這種風險的歷史情況是2010年比特幣的溢出漏洞。當時，比特幣客戶端代碼沒有檢查交易輸出的總和是否溢出（通過加總超過264-1的最大整數而環繞到零），因此有人進行了溢出交易，給自己帶來了數十億的比特幣。這個錯誤在幾個小時內就被發現了，修復程序被匆匆部署到整個網絡，如果當時有一個成熟的生態系統，這些代幣就會被交易所、橋和其他機構所接受，攻擊者就會卷款而逃。但如果當時有五個不同的比特幣客戶端，它們都出現相同漏洞的可能性很小，那麼會立即發生分裂，而分裂中存在漏洞的一方可能會輸。

使用多客戶端來減少災難性漏洞的風險是有代價的：你 有可能 會得到共識失敗的 漏洞 ：如果存在兩個客戶端，它們對某些協議規則的解釋存在微妙不同，那麼雖然兩種解釋都十分合理，防止資金盜用的發生，但這種分歧會導致鏈分裂成兩半。這種類型的嚴重分裂在以太坊歷史上發生過一次（也發生過其他更小的分裂）。

單客戶端方法的捍衛者會援引共識失敗，認為不需要進行多種實現：如果只有一個客戶端，該客戶端就不會與自己產生分歧。他們關於客戶端數量會引發風險的模型可能如下所示：

當然，我不同意這種分析，因為（1）也要考慮2010年時端災難性漏洞，當時的情況也很嚴重；（2）只有一個客戶 端的情況實際上從未存在 。這一點在2013年的比特幣分叉事件中表現得最為明顯：由於兩個不同版本的比特幣客戶端之間存在分歧，其中一個版本對單個區塊中可修改的對象數量有意外的、無記錄的限制，導致了鏈的分裂。因此，理論上的"一個客戶端"在實踐中往往是兩個客戶端，理論上的五個客戶端在實踐中可能是六個或七個客戶端------所以我們不如選擇風險曲線（上圖）的右邊，至少擁有幾個不同的客戶端。

政治 去中心化

處於壟斷地位的客戶端開發者具有很大的政治權力。如果客戶端開發者提出一個改變，而用戶不同意，理論上他們可以拒絕下載更新的版本，或者創建一個沒有這個版本的分叉，但實際上用戶往往很難做到這一點。如果這種令人不快的協議變化與必要的安全更新捆綁在一起呢？如果主要團隊威脅要退出呢？或者更普通的情況是，如果處於壟斷地位的客戶端團隊是唯一在協議知識方面最專業的團體呢？這樣一來，生態系統的其他成員難以判斷客戶團隊提出的技術論點是否恰當，客戶端團隊擁有很大的空間來推行他們自己的目標和價值觀，而這些目標和價值觀可能與社區更廣泛的追求不一致，那該怎麼辦？

對協議政治的關注，特別來自於 2013-14年的比特幣OP_RETURN戰爭，當時一些參與者公開支持歧視鏈的某些特定用途，這是以太坊早期採用多客戶理念的一個重要因素，就是為了避免這種情況再次發生。對以太坊生態系統的關注------即避免權力集中在以太坊基金會本身------也為這一方向提供進一步的支持。2018年，團隊就決定不讓基金會實施以太坊PoS協議（即現在的"共識客戶端"），而是把這個任務完全留給外部團隊。

ZK-EVM 未來將如何在第一層出現？

目前，ZK-EVM被用在rollup上：讓成本高昂的EVM執行在鏈外進行幾次，而其他人只需驗證鏈上證明EVM執行計算正確的SNARK，從而進行擴容。它還允許一些數據（特別是簽名）不被包含在鏈上，以節省手續費。這給我們帶來了很多擴容方面的好處，而將可擴容計算與ZK-EVM和數據可用性採樣結合，可以帶來極大程度的擴容。

然而，今天的以太坊網絡也面臨不同的問題，任何第2層擴容方案都無法解決：第1層很難驗證，以至於沒有多少用戶運行自己的節點。相反，大多數用戶只信任第三方供應商。輕型客戶端，如 Helios和 Succinct正在採取措施解決該問題，但輕型客戶端遠不是完全的驗證節點：輕型客戶端只是驗證一個隨機的驗證者（稱為"同步委員會"）子集的簽名，而不驗證鏈是否真正遵循了協議規則。為了實現用戶可以真正驗證鏈是否遵循規則，我們必須做出改變。

方案1：收縮第1層，迫使幾乎所有的活動轉移到第2層

我們可以逐步將每區塊的第一層gas目標從1500萬減少到100萬，足以讓一個區塊包含一個SNARK和一些存款和取款操作，但不能進行太多的其他操作，從而迫使幾乎所有用戶活動轉移到第二層協議。這樣的設計仍然可以支持在每個區塊中提交許多rollup：我們可以使用由定制化構建者運行的鏈外聚合協議，把來自多個第二層協議的SNARK聚集並合併成一個SNARK。這樣一來 ， 第一層的唯一功能是成為第二層協議的交換中心，驗證 第二層的 證明，偶爾促進它們之間的大額資金轉移。

這種方法可以發揮作用，但它有幾個重要的弱點：

1 . 它事實上 無法 向後兼容的 。也就是說，許多現有基於L1的應用程序在經濟上會變得不可行。由於費用變得高昂，甚至超過了清空這些賬戶的成本，用戶的資金可能會被冻结，多達數百或數千美元。讓用戶簽署信息加入協議內大規模到L2的遷移，可以解決這一問題，但這增加了過渡的複雜性。並且，如果想實現真正的低成本，必須在第一層實現某種SNARK。當涉及到像SELFDESTRU這樣的東西時，我一般贊同打破向後兼容，但在這種情況下，我不建議捨棄向後兼容。

2.驗證 的成本並不會因此大幅度降低 。 理想情況下，以太坊協議應該很容易驗證，不僅在筆記本電腦上，而且在手機、瀏覽器插件，甚至在其他鏈內。首次同步鏈、或者在長時間離線後同步鏈，也應該是很容易的。一個筆記本節點可以在大約20毫秒內驗證100萬gas，但即使是這樣，也意味著離線一天後需要54秒來進行同步（假設單個槽位的終結性時間增加到32秒），而對於手機或瀏覽器插件來說，每個區塊需要幾百毫秒，可能仍會帶來不可忽視的電池消耗。這些數字雖然可控，但並不符合我們的理想期望。

3.即使在 L2 優先的生態系統中，L1 也能以成本不高的方式獲益 。 Validiums可以從更強大的安全模型中受益，如果用戶發現新的狀態數據不再可用，他們就可以撤回資金。如果經濟可行的跨L2直接轉移所需的最小規模較小，套利就會更加有效，特別是對於較小的代幣而言。

因此，使用ZK-SNARK來驗證第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）封閉式多ZK-EVM：就一組特定的多ZK-EVM達成共識，並在共識層協議中規定，一個區塊需要來自該組中一半以上的ZK-EVM的證明才能被視為有效。

3）開放式多ZK-EVM：不同的客戶端有不同的ZK-EVM實現，每個客戶端要先等到與自己的實現兼容的證明，才會接受一個區塊為有效。

對我來說，方案3比較理想，這種情況不會改變，直到我們的技術改進到可以正式證明所有的ZK-EVM實現都是等價，可以隨意選擇最有效方案的時候。

方案1會犧牲多客戶模式的好處，方案2會關閉開發新客戶的可能性，導致生態系統更中心化。方案3具有挑戰，但這些挑戰似乎比其他兩個選項的挑戰小，至少目前是這樣。

實現方案3並不難：我們可以為每種型別的證明建立一個p2p子網絡，使用一種型別的證明的客戶將在相應的子網絡上進行監聽，並等待收到被驗證器識別為有效的證明。

方案3 的兩個主要挑戰可能是以下幾點：

1）延遲：惡意攻擊者可能會延遲發布區塊和對客戶端有效的證明，這會需要很長的時間（即甚至是15秒）來生成對其他客戶有效的證明，這一時間足以創造臨時分叉，並在幾個時間槽內對鏈干擾。

2）數據效率低下：ZK-SNARK的好處之一是，只與驗證有關的數據（有時稱為"見證數據"）可以從區塊中刪除。例如，一旦你驗證了一個簽名，你就不需要在區塊中保留這個簽名，你可以只存儲一個比特，說這個簽名是有效的，同時在區塊中存儲一個證明，確認所有有效簽名的存在。但如果我們希望為一個區塊生成多種型別的證明，那麼原始簽名就需要實際被公布出來。

延遲可以通過謹慎設計單槽確定性協議來解決。單槽確定性協議可能需要每槽兩輪以上的共識，因此可以要求第一輪包括區塊，只要求節點在第三輪（或最後一輪）簽字前驗證證明。這可以確保在發布區塊的最後期限和預計證明可用的時間之間總是留有重要的時間窗口。

要解決數據效率問題，就必須有單獨的協議來聚合驗證相關的數據。對於簽名，我們可以使用 BLS聚合，ERC-4337已支持該功能。另一大類與驗證有關的數據是ZK-SNARK，用來保護隱私。這些數據通常會有自己的聚合協議。

還值得一提的是，SNARK-驗證第1層有一個重要的好處：鏈上EVM的執行不再需要由每個節點來驗證，這就有可能實現EVM的執行量的大幅上漲，可以通過大大增加第1層的gas限制來實現，或引入隱含的rollup，（enshrined rollup），或者兩者都進行採用。

結論

實現多客戶ZK-EVM生態系統的良好运作並非易事。但好消息是，這些工作中的大部分正在發生或將發生：

• 我們已擁有多個強大的ZK-EVM實現，它們還不算是1型EVM（完全等同於以太坊），但其中許多正在積極向這個方向發展。

• 在輕型客戶端（如Helios和 Succinct）上的工作最終可能會變成對以太坊鏈PoS共識進行更全面的SNARK驗證。

• 客戶端可能會開始嘗試使用ZK-EVM自行證明以太坊區塊的執行，尤其是我們能實現無狀態客戶、在技術上不需要直接重新執行每個區塊來維持狀態時。我們可能會進行緩慢的過渡：從客戶端通過重新執行區塊來驗證以太坊區塊，到大多數客戶端通過檢查SNARK證明來驗證以太坊區塊。

• ERC-4337和PBS生態系統可能很快就開始使用BLS和證明聚合等聚合技術，以節省手續成本。關於BLS的聚集，相關工作也已開始。

隨著這些技術的到位，未來一片向好。以太坊區塊將比現在更小，任何人都可以在他們的筆記本電腦甚至手機或在瀏覽器插件中運行一個完全驗證的節點，而這一切都將需要保留以太坊的多客戶理念。

在更久的未來，一切都可能發生。也許人工智能會大幅提升形式化驗證的性能，使其能夠輕鬆證明ZK-EVM實現的等價，並識別出導致它們之間差異的所有漏洞。甚至我們現在就應著手開始這個項目。如果這種基於形式驗證的方法能夠成功，就需要建立不同的機制，確保協議持續的政治權力去中心化；也許到那時，協議會被認為是"完整的"，不可更改性規範會更健全。但是，即使是在很久之後，開放的多客戶ZK-EVM也是一個終會到來的世界。

短期來看，這一切道阻且長。ZK-EVM已經出現，但要實現ZK-EVM在第1層真正可行，需要它成為1型ZK-EVM，並實現快速、實時的證明。擁有足夠的並行，就可以做到這一點，但仍需大量工作。提高KECCAK、SHA256和其他哈希函數預編譯的手續成本這樣的共識變化也將是未來藍圖的重要部分。過渡的第一步可能會比我們預期的更快發生：一旦我們轉換到沃克爾樹和無狀態客戶端，客戶端可能會開始逐漸使用ZK-EVM，向"開放、多ZK-EVM"世界的過渡可能會自動發生。