大量使用者和資金進來了怎麼辦？ 作者展示一個未來圖景，該圖景由數據的獲取、鏈下計算、鏈上驗證三部分構成。 “證明共識” 是這個藍圖中重要的一部分，如果能夠實現共識層的 zk 化，將會在確保安全信任的基礎上助力乙太坊的擴容，增強整個乙太坊生態的穩健性。
作者：Zoe，Puzzle Ventures （Email： zoey@puzzle.ventures | Twitter: @zoezts)
封面：Photo by Shubham’s Web3 on Unsplash
（本文 5959 字，預計閱讀時間 10 分鐘）
TL; DR
一、為什麼證明共識層很重要？ | 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: verifying blocks 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”，從而讓更多人積极參與網络的去中心化和穩健性。
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 協議參數的需求。
鏈上和鏈下數據的讀寫和計算有兩個顯著特點：
1. 為了實現去中心化和安全，最好能夠驗證我們所獲取的數據，即 “不要相信，要驗證（Don't Trust， Verify）”。
2. 往往涉及許多複雜和昂貴的計算過程。
如果沒有找到合適的技術解決方案，以上兩點便會影響區塊鏈的可用性。
我們可以通過一個簡單的例子來說明不同數據獲取方式。 假設你想查看自己的賬戶餘額，你會怎麼做？
一種最安全的方式是自己運行一個全節點，檢查本地存儲的乙太坊狀態，並從中獲取賬戶餘額。
然而，自己運行全節點的成本很高，還需要自己維護。 為了省事，很多人可能會直接向中心化的節點運營商請求數據。 雖然這樣做沒有什麼問題，類似於 Web2 中的操作，而且我們也從未見過這些供應商有過任何惡意行為，但是這也意味著我們必須相信一個中心化的服務商，這增加了整體的安全假設。
為了解決這個問題，我們可以考慮兩個解決方案：一是降低運行節點的成本，二是尋找一種驗證第三方數據可信度的方法。
那不如就只存儲必要的數據。 為了更高效地訪問數據，降低信任成本，並獨立驗證數據，一些機構開發了輕用戶端（light clients），如 Rust-based Helio（由 a16z 開發）、Lodestar、Nimbus 和基於 JavaScript 的 Kevlar 等。 輕用戶端不存儲所有的區塊數據，而只下載和存儲區塊頭——一個區塊全部資訊的 “總結”。 輕客戶端能夠獨立驗證接收到的數據資訊，因此當從第三方數據供應商獲取數據后，你不再需要完全信任該提供商的數據。
輕節點的主要特點包括：
- 理想情況下，輕節點可以在手機或嵌入式設備上運行。
- 理想情況下，它們可以與全節點具有相同的功能和安全保障。
- 但是輕節點不參與共識過程，或者說只受到部分的共識機制保護，即同步委員會（Sync Committee）。
Sync Committee 是輕節點的信任假設。
在 The Merge 之前，從 2020 年 12 月開始，Beacon Chain 進行了一個名為 Altair 的硬分叉，其核心目的是為輕節點提供共識支援。 和 PoS 全共識不同，組成這一組驗證者（512 個）的是一個較小的數據集，相隔更長的時間段（256 個 epoch，約 27 小時）進行隨機抽取。
Light clients such as Helios and Succinct are 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 the sync 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 更可靠。
（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 也更低。
用零知識來證明共識層的另一個關鍵點在於遞歸證明（recursive proof）—— 即證明之證明（proofs of proofs），把之前發生的事情打包成一個證明。
如果沒有遞歸證明，最終會輸出 O（block height）大小的證明，即每個區塊證明（block attestation）和相對應的 zkp 。 通過遞歸證明，除了初始狀態和最終狀態外，對於任意數量的區塊，我們只需要 O（1）大小的證明。
回到最初的目標，我們的解決方案應該針對有計算和記憶體限制的「輕用戶端」。。 即使每個證明可以在固定的時間內進行驗證，如果區塊和證明的數量累加，驗證時間將變得非常長。
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
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。本文内容仅用于信息分享，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
