無盡的擴容之路：探討共識層ZK化對於以太坊的意義作者：Zoe | Puzzle Ventures (Email: zoey@puzzle.ventures | Twitter: @zoezts)

TL; DR

從眾多公鏈展開競爭以來，到以太坊路線圖中的Danksharding，再到op/zk等二層解決方案，我們一直不間斷在討論區塊鏈的擴展性——大量用戶和資金進來了怎麼辦？通過接下來一系列的文章，我想向大家展示一個未來的圖景，該圖景由數據的獲取、鏈下計算、鏈上驗證三部分構成。

Trustless Data Access + Off-chain Computation + On-chain Verification

“證明共識” 是這個藍圖中重要的一部分。本文探討了在以太坊PoS的基礎上，用零知識證明共識的意義，包括：

1. 對於EVM去中心化的重要性。

2. 去中心化數據訪問對於web3擴容的重要性。

證明以太坊主網的全共識是一項複雜的任務，但是如果我們能夠實現共識層的zk化，將會在確保安全信任的基礎上助力以太坊的擴容，同時增強整個以太坊生態的穩健性，降低參與成本，讓更多人融入其中。

一、為什麼證明共識層很重要? | Why does proving consensus matter?

1. 以太坊的⾓度 | Perspective from Ethereum

2. 以太坊⽣態各層協議的⾓度 | Perspective of Protocol Stacks on Ethereum

二、區塊鏈數據來⾃何處？不同數據源的信任假設 | Where is Blockchain Data? Trust Assumptions for Different Data Sources

三、⽤零知識證明共識層之路 | The Path to Prove Consensus Using ZK

1.以太坊2.0中共識形成的核⼼步驟 | Key Steps in Consensus Formation in Ethereum 2.0

2. 證明共識層的ZK技術棧 | Tech Stacks to Prove Consensus

3. 終極⽬標: 多樣性的Level 1 zkEVM | The End Game: Diversified Level 1 zkEVM

四、未來展望 | What is the Future?

五、參考 | Reference

一、為什麼證明共識層很重要? | Why does proving consensus matter?

利用zk來驗證以太坊L1的共識層在兩個大方向上有意義。首先，它可以彌補當前節點多樣性的缺陷，增強以太坊本身的去中心化和安全性。其次，它為以太坊生態各層協議面對更多用戶提供了可用性和安全性的基礎，包括跨鏈安全、無需信任的數據訪問、去中心化預言機、和擴容等方面。

1. 以太坊的角度 | Perspective from Ethereum

對於以太坊來說，要實現其去中心化和穩健性 (robustness)，它需要一個客戶端多樣性的環境。意味著更多的人參與其中，尤其是普通用戶，運行基於不同代碼環境的客戶端。然而，要求每個用戶都運行全節點是不現實的，因為這需要大量的資源，沒有幾個人能夠承擔至少 16 GB+ RAM 和 Fast SSD with 2+TB，而這些要求還在不斷增長。

目前的目標是實現輕節點 (light node)，既能提供與全節點相同的信任度（信任最小化），又能在內存、存儲和帶寬要求上具有更低的成本。然而，目前輕節點並不參與共識過程，或者說只受到部分的共識機制保護 (Sync Committee)。

這一目標在以太坊的路線圖中被稱為"The Verge"。

Goal:verifyingblocks should be super easy - download N bytes of data, perform a few basic computations, verify a SNARK and you’re done— The Verge on Ethereum’s Roadmap

"The Verge"旨在彌合客戶端差距，關鍵步驟是如何實現去信任的輕節點，安全程度應等同於今天的全節點，填補“the client gap”，從而讓更多人積極參與網絡的去中心化和穩健性。

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

https://www.ethernodes.org/network-types

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

https://clientdiversity.org/

2. 以太坊生態各層協議的角度 | Perspective of Protocol Stacks on Ethereum

從第一性原理出發，我們需要解決鏈上數據訪問與鏈下計算驗證的結合問題。

目前鏈上數據的使用相對初級，不夠充分。在很多情況下，協議調整所需的數據過於復雜，無法進行鏈上計算，而以去信任方式獲取數據的成本又過高，需要大量歷史數據訪問和頻繁的數字計算等。

對於個人用戶和項目來說，我們的理想情況是實現去中心化的、端到端的無需信任假設數據傳遞和讀寫，以此為基礎，面向未來更多的用戶，應實現盡量低的計算成本，兼顧安全性、可用性和經濟性。

具體包括以下幾個方面：

1. 去中心化和無需信任的預言機(Oracle)：目前的協議使用中心化預言機來避免直接在鏈上對大量歷史數據的訪問，增加了不必要的信任成本，並降低了可組合性。

2. 數據和資產敏感相關協議的數據讀寫：例如，DeFi協議在運行過程中需要進行一些參數動態調整，但是否能夠無需信任地訪問歷史數據並進行更複雜的計算，如基於最近的市場波動調整AMM費用，設計鏈上衍生品交易價格模型和動態波動，引入機器學習方法進行資產管理，根據市場情況調整借貸利息等。

3. 跨鏈安全：目前基於zk技術的輕節點方案在安全性 (security)、資金效率 (capital efficiency)、狀態保留程度 (statefulness)和傳遞信息多樣性方面都更優秀。當前Succinct的Telepathy跨鏈方案和Polehedra在LayerZero上面做的跨鏈方案，都是基於Sync Committee做的輕節點區塊頭zk驗證。然而，Sync Committee並非以太坊PoS共識層本身，存在一定的信任假設，未來還有餘地可以做的更加完備。

目前，由於經濟成本、技術限制和用戶體驗等方面的考慮，開發者在利用鏈上數據時通常依賴於中心化的RPC服務器，例如 Alchemy、Infura 和 Ankr等。

二、區塊鏈數據來自何處？不同數據源的信任假設 | Where is Blockchain Data? Trust Assumptions for Different Data Sources

區塊鏈中的計算數據有兩種來源：鏈上數據 (on-chain data) 和鏈下數據 (off-chain data)。對應鏈上和鏈下兩種去向，進行計算。比如前文提到的調整DeFi協議參數的需求。

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

Data Access, computation, proof and verification

鏈上和鏈下數據的讀寫和計算有兩個顯著特點：

1. 為了實現去中心化和安全，最好能夠驗證我們所獲取的數據，即“不要相信，要驗證 (Don’t Trust, Verify)”。

2. 往往涉及許多複雜和昂貴的計算過程。

如果沒有找到合適的技術解決方案，以上兩點便會影響區塊鏈的可用性。

我們可以通過一個簡單的例子來說明不同數據獲取方式。假設你想查看自己的賬戶餘額，你會怎麼做？

一種最安全的方式是自己運行一個全節點，檢查本地存儲的以太坊狀態，並從中獲取賬戶餘額。

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

全節點Benchmark。同步模式 (sync mode) 和客戶端選擇會影響所需的空間要求。參考: https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/; https://docs.google.com/presentation/d/1ZxEp6Go5XqTZxQFYTYYnzyd97JKbcXlA6O2s4RI9jr4/mobilepresent?pli=1& ;slide=id.g252bbdac496_0_109)

然而，自己運行全節點的成本很高，還需要自己維護。為了省事，很多人可能會直接向中心化的節點運營商請求數據。雖然這樣做沒有什麼問題，類似於Web2中的操作，而且我們也從未見過這些供應商有過任何惡意行為，但是這也意味著我們必須相信一個中心化的服務商，這增加了整體的安全假設。

為了解決這個問題，我們可以考慮兩個解決方案：一是降低運行節點的成本，二是尋找一種驗證第三方數據可信度的方法。

那不如就只存儲必要的數據。為了更高效地訪問數據，降低信任成本，並獨立驗證數據，一些機構開發了輕客戶端 (light clients)，如Rust-based Helio（由a16z開發）、Lodestar、Nimbus和基於JavaScript的Kevlar等。輕客戶端不存儲所有的區塊數據，而只下載和存儲區塊頭——一個區塊全部信息的“總結”。輕客戶端能夠獨立驗證接收到的數據信息，因此當從第三方數據提供商獲取數據後，你不再需要完全信任該提供商的數據。

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

https://medium.com/coinmonks/ethereum-data-transaction-trie-simplified-795483ff3929

輕節點的主要特點包括：

  • 理想情況下，輕節點可以在手機或嵌入式設備上運行。
  • 理想情況下，它們可以與全節點具有相同的功能和安全保障。
  • 但是輕節點不參與共識過程，或者說只受到部分的共識機制保護，即同步委員會 (Sync Committee)。

Sync Committee是輕節點的信任假設。

在The Merge之前，從2020年12月開始，Beacon Chain進行了一個名為Altair的硬分叉，其核心目的是為輕節點提供共識支持。和PoS全共識不同，組成這一組驗證者 (512個) 的是一個較小的數據集，相隔更長的時間段 (256個epoch，約27小時) 進行隨機抽取。

Light clients such asHeliosandSuccinctare taking steps toward solving the problem, but a light client is far from a fully verifying node: a light client merely verifies the signatures of a random subset of validators called thesync committee, and does not verify that the chain actually follows the protocol rules. To bring us to a world where users can actually verify that the chain follows the rules, we would have to do something different.

How will Ethereum's multi-client philosophy interact with ZK-EVMs?, by Vitalik Buterin*

這就是為什麼我們要驗證以太坊的全部共識層，以期迎來一個更加安全、可用性更強、擁有更多樣化協議、以及大規模採用的未來，目前來看最好的解決方案零知識(zero-knowledge) 技術。

三、用零知識證明共識層之路 | The Path to Prove Consensus Using ZK

要構建一個無需信任假設的環境，必須解決輕節點可信度、去中心化數據訪問、和鏈下計算驗證這些問題，在這些方面零知識證明是目前最被認可的核心技術，其中涉及到但不限於zkEVM、zkWASM、其他zkVM、zk Co-processor等底層解決方案。

證明共識層是其中重要一環。

PoS算法非常複雜，以ZK方式實現它們需要大量的工程工作和架構考慮，我們先將其組件進行拆分。

1. 以太坊2.0中共識形成的核心步驟 | Key Steps in Consensus Formation in Ethereum 2.0

（1）驗證者 (validator) 相關算法

其中包括以下步驟

  • 成為驗證者：驗證者候選人需向存款合約發送32ETH，並等待至少16小時至幾天或幾週的時間，以使信標鏈（Beacon Chain）處理並激活成為正式驗證者。 (可參考FAQ - Why does it take so long for a validator to be activated)
  • 行使驗證職責：涉及隨機數和區塊證明算法。
  • 退出驗證者角色：退出驗證者的方式可以是自願退出或者因違規而被處罰 (slashed)。驗證者可以隨時主動發起“退出”，每個epoch對於退出的驗證者數量有限制。如果有過多的驗證者同時嘗試退出，他們將被放入一個隊列中，在排到之前，他們仍然需要履行驗證職責。成功退出後，經過1/8個eek，驗證者將能夠提取質押資金。

（2）隨機數相關算法

  • 每個epoch包含32個區塊(slot)，提前2個Epoch進行隨機分組，將所有驗證者分成32個委員會(committee)，在當前epoch行使職責，分別對每個區塊的共識負責。
  • 每個委員會中有兩種角色，一個提議者(Proposer)，其餘為區塊構建者(Builders)，也被隨機選出。這樣將交易排序和區塊構建兩個過程分離開來(詳見proposer/builder separation - PBS)。

（3）區塊證明 (Block Attestation) 和BLS簽名相關算法

  • 簽名部分是共識層最核心的部分。
  • 每個slot的驗證委員會給投票 (使用BLS簽名)，需要獲得2/3的通過率才能構建區塊。
  • 在以太坊PoS共識層中，BLS簽名使用BLS12–381橢圓曲線，pairing-friendly, 適合聚合所有簽名，減少證明時間和大小。
  • 在工作量證明中，區塊可能會發生重組 (re-org)。在合併之後，引入了執行層上的 ”最終化(finalized) 區塊和安全頭 (safe head)” 的概念。要創建一個衝突的區塊 (conflicting block);攻擊者需要銷毀至少總質押以太幣的1/3；很大程度上，PoS比PoW更可靠。

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

2023年6月底，《Puzzle Ventures 晚自習》中間介紹到了Hyper Oracle的zkPoS (用zk的方法去驗證以太坊全共識層)。詳情請見 zkPoS: End-to-End Trustless

（4）其他：如弱主觀性檢查點 (weak subjectivity checkpoints)

無需信任的PoS共識證明面臨的其中一個挑戰是若主觀性checkpoint的選擇，涉及到社會層面的共識 (social consensus based on social information)。這些檢查點是回退限制 (revert limits)，因為位於弱主觀性檢查點之前的區塊無法更改。詳見：https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/

檢查點 (checkpoints) 也是共識層zk化當中一個需要考慮的點。

2. 證明共識層的ZK技術棧 | Tech Stacks to Prove Consensus

在證明共識層中，證明簽名或其他計算本身是非常昂貴的，但相較之下驗證零知識證明卻十分便宜。

在選擇使用零知識證明共識層的方法時，協議需要考慮以下因素：

  • 你要證明什麼？
  • 證明之後的應用場景是什麼？
  • 如何提高證明的效率？

以Hyper Oracle為例，對於證明BLS簽名，選擇了Halo2，他們選擇了Halo2而不是Succinct Labs使用的Circom，出於以下幾個原因：

  • Circom和Halo2都可以生成BLS簽名（BLS12–381橢圓曲線）的零知識證明。
  • Hyper Oracle並不只是乾zkPoS這一件事，其核心產品是可編程的鏈上零知識預言機 (Programmable Onchain zkOracle)。其中直接面向用戶的有zkGraph、zkIndexing和zkAutomation，並且還利用zkWASM虛擬機去驗證鏈下計算。儘管Circom對於工程師來說更易上手，但兼容性較差，無法確保所有功能的邏輯都能使用
  • Circom-pairing會被編譯成為R1CS, 與zkWASM和其他電路的Plonkish約束系統不兼容，而Halo2 Pairing電路能夠非常容易地整合進zkWASM電路；相比之下，R1CS對於批處理證明(Proof Batching ) 也並不理想。
  • 從效率的角度，Halo2-pairing生成的BLS電路更小，證明時長更短，對硬件要求更低，gas fee也更低。

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

https://mirror.xyz/hyperoracleblog.eth/lAE9erAz5eIlQZ346PG6tfh7Q6xy59bmA_kFNr-l6dE

用零知識來證明共識層的另一個關鍵點在於遞歸證明 (recursive proof) —— 即證明之證明 (proofs of proofs)，把之前發生的事情打包成一個證明。

如果沒有遞歸證明，最終會輸出O(block height)大小的證明，即每個區塊證明 (block attestation) 和相對應的zkp 。通過遞歸證明，除了初始狀態和最終狀態外，對於任意數量的區塊，我們只需要O(1)大小的證明。

無盡的擴容之路：探討共識層ZK化對於以太坊的意義

Verify Proof N and Step N+1 to get Proof N+1, i.e. you know N+1 pieces of knowledge, instead of verify all N Steps separately.

回到最初的目標，我們的解決方案應該針對有計算和內存限制的“輕客戶端”。即使每個證明可以在固定的時間內進行驗證，如果區塊和證明的數量累加，驗證時間將變得非常長。

3. 終極目標: 多樣性的Level 1 zkEVM | The End Game: Diversified Level 1 zkEVM

以太坊的目標不僅僅是證明共識層，還希望通過zkEVM實現整個Layer 1虛擬機的零知識化，並最終實現多樣化的zkEVM，以增強以太坊的去中心化和魯棒性( robustness)。

針對這些問題，以太坊當前的解決方案和路線圖如下：

“輕量化light” —— 更小的內存、存儲和帶寬要求

  • 目前通過輕節點 (light node) 實現僅存儲和驗證區塊頭 (block header) 的方式。
  • 未來的發展還需要在verkle tree和stateless clients方面做進一步的努力，涉及改進主網數據結構。

“安全去信任 trustless” —— 實現與全節點相同的最小信任 (trust-minimization)

  • 目前已經實現基礎的輕節點共識層，即同步委員會 (Sync Committees)，但這只是一個過渡方案。
  • 使用SNARK來驗證以太坊Layer 1，包括驗證執行層的Verkle Proof、驗證共識層、以及將整個虛擬機進行SNARK化。
  • Level 1 zkEVM用於實現整個以太坊Layer 1虛擬機的零知識化，且實現zkEVM的多樣化。

可能的風險

在理想情況下，當進入zk時代時，我們需要多種開源的zkEVM —— 不同的客戶端具有不同的zkEVM實現，每個客戶端在接受一個區塊之前會等待與其自身實現兼容的證明。

然而，多種證明系統可能會面臨一些問題，因為每種證明系統都需要一個點對點網絡，一個只支持某一種證明系統的客戶端只能等待相應類型的證明，才能被其驗證器(verifier) 所識別。其中可能出現的兩個主要挑戰包括“延遲挑戰(latency challenge)”和“數據低效(data inefficiency)”，前者主要源於生成證明很慢，在生成針對不同證明系統的證明時，有一段時間差留給作惡者創建臨時分叉；後者因為你要生成多種類型的zk證明，就得保存原始簽名，雖然理論上zkSNARK本身的優勢是可以刪除原始簽名等數據，這裡就出現了一些矛盾需要優化和解決。

四、未來展望 | What is the Future?

要讓web3迎來更多用戶、提供更流暢的體驗、創造更高的可用性和保障應用的安全性，我們必須為去中心化數據訪問、鏈下計算、鏈上驗證做好基礎設施建設。

證明共識層是其中一個重要組成部分，除了以太坊PSE和前面提到的zkEVM layer2之外，還有一些協議正在通過零知識證明共識來實現自己的應用端目標，包括Hyper Oracle (Programmable zkOracle Network) 計劃使用零知識證明以太坊PoS的全部共識層來獲取數據；Succinct Labs的Telepathy是一個輕節點橋(Light Node Bridge) ，通過驗證Sync Committee共識，提交state validity proof來達到跨鏈通訊的比目的；Polyhedra 原本也是輕節點橋，但現在也聲明利用devirgo實現了全節點全共識的zk證明。

除了跨鏈安全、去中心化預言機之外，這種鏈下計算+鏈上驗證的方式，也可能參與到樂觀rollup中fraud proof當中，與OP L2相互融合；或在基於意圖的架構(intent-based architecture) 中，針對更複雜的意圖結構提供鏈上證明等等。

這裡我們談論的是不僅限於以太坊的鏈下生態系統 (off-chain ecosystem surrounding Ethereum)，還涉及到以太坊以外的更廣闊市場。

這個話題仍然有很多值得深入研究的部分，比方說上週8月24日a16z才發表了一篇認為“無狀態區塊鏈(stateless blockchain) 無法到達”的文章，再比如說弱主觀性檢查點(weak subjectivity checkpoints)、Sync Committee安全性在數學上到底如何是否夠用等問題，歡迎感興趣的同行聯繫(zoey@puzzle.ventures)，跟作者繼續討論這個話題。

再次感謝各位同僚的指教和反饋，Alex @ IOBC (@looksrare_eth), Fan Zhang @ Yale University (@0xFanZhang), Roy @ Aki Protocol (@aki_protocol), Zhixiong Pan @ ChainFeeds (@nake13), Suning Yao @ Hyper Oracle (@msfew_eth), Qi Zhou @ EthStorage (@qc_qizhou), Sinka @ Delphinus (@DelphinusLab), Shumo @ Manta (@shumochu)

參考資料| Reference

Annotated Ethereum Roadmap

https://notes.ethereum.org/@domothy/roadmap#Annotated-Ethereum-Roadmap

Altair Hard Fork - The Beacon Chain

https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/fork.md

How will Ethereum's multi-client philosophy interact with ZK-EVMs?,Vitalik Buterin

https://vitalik.eth.limo/general/2023/03/31/zkmulticlient.html

State of research: increasing censorship resistance of transactions under proposer/builder separation (PBS),Francesco (Ethereum foundation)

https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ

How The Merge Impacts Ethereum’s Application Layer,by Tim Beiko

https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer

Ethereum Developer Docs - Nodes and Clients,Ethereum Foundation

https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/

Building Helios: Fully trustless access to Ethereum,a16z

https://a16zcrypto.com/posts/article/building-helios-ethereum-light-client/

How I Learned to Stop Worrying and Love the Sync Committee,Uma Roy, Succinct Labs

https://blog.succinct.xyz/blog/sync-committee

zkPoS: End-to-End Trustless,msfew & Shuyang, Hyper Oracle

https://mirror.xyz/hyperoracleblog.eth/lAE9erAz5eIlQZ346PG6tfh7Q6xy59bmA_kFNr-l6dE

Proof of Consensus for Ethereum,Succinct Labs

https://github.com/succinctlabs/eth-proof-of-consensus

zkLightClient on LayerZero,Polyhedra

https://docs.zkbridge.com/zklightclient-overview/zklightclient-on-layerzero

Intent-Based Architectures and Their Risks,Quintus Kilbourn,Georgios Konstantopoulos, Paradigm

https://www.paradigm.xyz/2023/06/intents#conclusion

RFP: OP Stack Zero Knowledge Proof,Optimism

https://github.com/ethereum-optimism/ecosystem-contributions/issues/61

免責聲明：本研究報告為作者結合公開信息整理分析的獨立觀點，僅供參考和交流，不構成財務、投資或任何其他建議。