摘要
从众多公链展开竞争以来，到以太坊路线图中的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
利用zk来验证以太坊L1的共识层在两个大方向上有意义。首先，它可以弥补当前节点多样性的缺陷，增强以太坊本身的去中心化和安全性。其次，它为以太坊生态各层协议面对更多用户提供了可用性和安全性的基础，包括跨链安全、无需信任的数据访问、去中心化预言机、和扩容等方面。
1. 以太坊的角度 | Perspective from Ethereum
对于以太坊来说，要实现其去中心化和稳健性 (robustness)，它需要一个客户端多样性的环境。意味着更多的人参与其中，尤其是普通用户，运行基于不同代码环境的客户端。然而，要求每个用户都运行全节点是不现实的，因为这需要大量的资源，没有几个人能够承担至少 16 GB+ RAM 和 Fast SSD with 2+TB，而这些要求还在不断增长。
目前的目标是实现轻节点 (light node)，既能提供与全节点相同的信任度（信任最小化），又能在内存、存储和带宽要求上具有更低的成本。然而，目前轻节点并不参与共识过程，或者说只受到部分的共识机制保护 (Sync Committee)。
这一目标在以太坊的路线图中被称为"The Verge"。
"The Verge"旨在弥合客户端差距，关键步骤是如何实现去信任的轻节点，安全程度应等同于今天的全节点，填补 “the client gap”，从而让更多人积极参与网络的去中心化和稳健性。
https://www.ethernodes.org/network-types
https://clientdiversity.org/
从第一性原理出发，我们需要解决链上数据访问与链下计算验证的结合问题。
目前链上数据的使用相对初级，不够充分。在很多情况下，协议调整所需的数据过于复杂，无法进行链上计算，而以去信任方式获取数据的成本又过高，需要大量历史数据访问和频繁的数字计算等。
对于个人用户和项目来说，我们的理想情况是实现去中心化的、端到端的无需信任假设数据传递和读写，以此为基础，面向未来更多的用户，应实现尽量低的计算成本，兼顾安全性、可用性和经济性。
具体包括以下几个方面：
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等。
区块链中的计算数据有两种来源：链上数据 (on-chain data) 和链下数据 (off-chain data)。对应链上和链下两种去向，进行计算。比如前文提到的调整DeFi协议参数的需求。
Data Access, computation, proof and verification
链上和链下数据的读写和计算有两个显著特点：
1. 为了实现去中心化和安全，最好能够验证我们所获取的数据，即“不要相信，要验证 (Don’t Trust, Verify)”。
2. 往往涉及许多复杂和昂贵的计算过程。
如果没有找到合适的技术解决方案，以上两点便会影响区块链的可用性。
我们可以通过一个简单的例子来说明不同数据获取方式。假设你想查看自己的账户余额，你会怎么做？
一种最安全的方式是自己运行一个全节点，检查本地存储的以太坊状态，并从中获取账户余额。
全节点Benchmark。同步模式 (sync mode) 和客户端选择会影响所需的空间要求。
然而，自己运行全节点的成本很高，还需要自己维护。为了省事，很多人可能会直接向中心化的节点运营商请求数据。虽然这样做没有什么问题，类似于Web2中的操作，而且我们也从未见过这些供应商有过任何恶意行为，但是这也意味着我们必须相信一个中心化的服务商，这增加了整体的安全假设。
为了解决这个问题，我们可以考虑两个解决方案：一是降低运行节点的成本，二是寻找一种验证第三方数据可信度的方法。
那不如就只存储必要的数据。为了更高效地访问数据，降低信任成本，并独立验证数据，一些机构开发了轻客户端 (light clients)，如Rust-based Helio（由a16z开发）、Lodestar、Nimbus和基于JavaScript的Kevlar等。轻客户端不存储所有的区块数据，而只下载和存储区块头——一个区块全部信息的“总结”。轻客户端能够独立验证接收到的数据信息，因此当从第三方数据提供商获取数据后，你不再需要完全信任该提供商的数据。
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小时) 进行随机抽取。
这就是为什么我们要验证以太坊的全部共识层，以期迎来一个更加安全、可用性更强、拥有更多样化协议、以及大规模采用的未来，目前来看最好的解决方案零知识 (zero-knowledge) 技术。
要构建一个无需信任假设的环境，必须解决轻节点可信度、去中心化数据访问、和链下计算验证这些问题，在这些方面零知识证明是目前最被认可的核心技术，其中涉及到但不限于zkEVM、zkWASM、其他zkVM、zk Co-processor等底层解决方案。
证明共识层是其中重要一环。
PoS算法非常复杂，以ZK方式实现它们需要大量的工程工作和架构考虑，我们先将其组件进行拆分。
其中包括以下步骤
成为验证者：验证者候选人需向存款合约发送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更可靠。
https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer
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化当中一个需要考虑的点。
在证明共识层中，证明签名或其他计算本身是非常昂贵的，但相较之下验证零知识证明却十分便宜。
在选择使用零知识证明共识层的方法时，协议需要考虑以下因素：
你要证明什么？
证明之后的应用场景是什么？
如何提高证明的效率？
以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也更低。
https://mirror.xyz/hyperoracleblog.eth/lAE9erAz5eIlQZ346PG6tfh7Q6xy59bmA_kFNr-l6dE
用零知识来证明共识层的另一个关键点在于递归证明 (recursive proof) —— 即证明之证明 (proofs of proofs)，把之前发生的事情打包成一个证明。
如果没有递归证明，最终会输出O(block height)大小的证明，即每个区块证明 (block attestation) 和相对应的zkp 。通过递归证明，除了初始状态和最终状态外，对于任意数量的区块，我们只需要O(1)大小的证明。
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.
回到最初的目标，我们的解决方案应该针对有计算和内存限制的“轻客户端”。即使每个证明可以在固定的时间内进行验证，如果区块和证明的数量累加，验证时间将变得非常长。
以太坊的目标不仅仅是证明共识层，还希望通过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本身的优势是可以删除原始签名等数据，这里就出现了一些矛盾需要优化和解决。
要让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 Roadmaphttps://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
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
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
白话区块链
神译局
Gryphsis Academy
新浪科技
元宇宙之心
金色早8点
Web3小律
MarsBit
ForesightNews
吴说区块链
TokenInsight
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。