ZKP是安全跨链的必由之路吗？

2022年起，随着Multichain、Succinct与Celer等众多跨链项目推出ZKP跨链测试网，基于ZKP的轻客户端跨链成为行业热点。ZKP跨链本质属于原生验证这一大类，可以实现去信任化的源链共识验证，帮助DAPP构建最安全的多链（或者说是全链）生态系统。之所以说是最安全，是因为相对于目前通过信任第三方实现的跨链通信的跨链方案，ZKP跨链不引入任何信任假设，用户只需要信任源链共识和目标链共识。从这个维度上看，ZKP跨链是最安全的跨链方式。但ZKP跨链方案技术极其复杂，门槛相对较高。

一、使用ZKP构建轻客户端的原生验证是实现去信任化跨链的最好方式

跨链可操作协议从验证方式上通常可以分为三类，外部验证、原生验证和本地验证。这三类互操作协议都有自身的局限性，难以兼顾去信任化、可拓展性和通用性。

1. 外部验证

外部验证是指引入一组可信的外部节点负责跨链消息的验证，其前提是用户必须信任这一组外部节点构成的中继网络。基于MPC、Oracle systems、PoS/PoA、多签和TEE等实现的跨链方案都属于这个范畴。外部验证跨链互操作协议建立在对第三方的中继节点或预言机的信任基础上，无法实现去信任化的消息中继跨链，但中继者和预言机在有些情况下也难以被完全信任。该类型的跨链实现方案是目前市场的主流，包含了Multichain，Wormhole，Axelar，LayerZero等知名项目。

2. 本地验证

本地验证也称为P2P验证，指交易对手直接进行验证，其核心是基于哈希时间锁的原子交换。在交易过程中，交易双方分别验证对方的行为，只要有一方作恶，双方都会面临损失，因此他们的利益是一致的。在实践当中，为了撮合交易，会有一个流动性提供者充当交易对手。Connext和Hop都可以算是这个分类中的典型。但是这类方案只适合资产跨链，并不适用于通用消息跨链，通用性弱。

3. 原生验证

原生验证是指在目标链部署源链轻节点，由目标链的轻节点对源链消息进行验证，原生验证无信任假设，理论上用户只需要信任源链共识和目标链共识，并且确保源链和目标链不发生回滚（链上轻节点一般会设置一定的区块冗余，防止源链和目标链回滚）。原生验证的典型项目有Rainbow Bridge，近两年基于ZK的跨链方案也属于这一范畴，典型的ZKP跨链项目包括zkRouter、Succinct Labs、Nil;Foundation等。

三类跨链互操作协议验证方式的综合比较见表1所示。

多链生态的繁荣催生了对跨链的需求。Multichain(anyCall)、Layerzero、Wormhole等众多优秀的跨链项目先后诞生，这些跨链项目更加重视是通用性和可拓展性，也需要可信的中继网络。

但2021年到2022年，跨链项目Ronin Network、Horizon、BNB Chain、Wormhole、Nomad等都受到了黑客攻击，都有巨量资产被盗。多链生态用户和跨链赛道参与者发现，去信任化跨链尽管可拓展性弱，但其去信任化特性对用户来说是更加安全的选择。因此，原生验证就成为实现去信任化跨链的最好途径。

但通常意义上的原生跨链互操作协议在目标链验证源链共识需要消耗大量Gas，原因是目标链轻客户端需要获取大量源链数据才能生成关于共识的信息。而将ZKP用于原生验证，通过生成简洁的ZKP证明，使得目标链轻客户端只需要获取ZKP就可以验证目标链交易，因此使用ZKP构建轻客户端的原生验证方式就成为一个更好的方案。

二、通过共识传递实现去信任跨链

Polkadot与Cosmos等公链生态共识天然支持生态内跨链，但对于非同一生态的公链，例如Ethereum，Solana等异构链却无法利用其跨链优势。包括Multichain，Layerzero，Wormhole等在内的主流第三方跨链桥都需要信任中继网络。而使用ZKP构造的跨链方案则不需要信任第三方，其直接向目标链传递源链的ZKP共识证明，目标链轻客户端只需要验证源链的共识证明，即可实现共识跨链。

但是不同链共识生成原理和生成方式千差万别，验证共识需要的数据也不同。ZKP跨链的难点在于如何生成源链共识ZKP，而源链共识的ZKP又是基于源链共识数据产生的，因此源链ZKP的生成也需要基于源链共识进行。不同源链共识生成的ZKP的电路也需要进行定制化设置。

不同公链共识生成的过程千差万别，生成ZKP的过程也不同。下面以Ethereum POS为例说明这个过程。

Ethereum设计了一套复杂的验证者选择机制来生成共识。Ethereum在Altair升级中增加了一个关键功能，这个功能是专门为支持轻客户端同步区块状态而设计的同步委员会 (sync committee)。Ethereum使用RANDAO算法随机选择512个验证者组成同步委员会，同步委员会的信息保存在信标链Beacon Chain中，每隔256个Epoch（一个Epoch约6.4分钟）更新一次。同步委员会的作用是不断签署区块头，在2/3同步委员会成员签名后，以太坊状态转换会被确认。

信标链Beacon Chain采用 BLS12-381 算法，作为验证者参与 POS 共识的方式。信标链区块中多个验证者的 BLS 签名可以进一步聚合为单个签名，从而有效减轻了原有数个签名的数据通信与链上存储压力。同时验证者也只需验证单个签名即可更高效地进行区块验证。

因为同步委员会作为共识机制的组成部分，轻客户端可以在不需要访问整个验证者集的情况下获取被验证过的共识状态。目标链轻客户端为了验证源链共识状态，会下载部分数据并进行验证与计算，包括：

（1）Merkle路径证明。验证对当前区块签名的委员会（sync_cmts）是在已验证区块头中指定的下一届委员会。

（2）聚合委员会公钥。根据当前区块同步委员会实际签名情况可以计算聚合委员会公钥。

（3）同步委员会的签名。使用聚合委员会公钥，验证新区块中的委员会签名。

上述验证方法是原生验证的通用方案，但是在链上直接验证源链共识涉及到大量的链上数据验证与计算，Gas消耗高。而使用ZKP技术，在链下完成源链数据的计算与验证，并生成简洁的源链共识传递到目标链可以大大降低链上Gas消耗，这也是为什么基于ZKP的链上轻客户端可以廉价验证源链共识。基于ZKP的跨链协议将聚合公钥验证BLS签名的过程放在链下，并生成ZKP证明，目标链客户端只需要验证一个零知识证明就可以验证源链共识。具体代码如图1所示。

图1 共识验证伪代码
资料来源：zkPoS: End-to-End Trustless — 图1 共识验证伪代码资料来源：zkPoS: End-to-End Trustless

从上述ZKP轻客户端同步共识的过程可以发现，其链下证明生成过程与源链共识机制和轻客户端的支持情况紧密相关。这也是为什么要实现链上轻客户端较为困难，而且每次Ethereum升级的时候轻客户端都需要检查是否需要更新同步代码的原因。

三、ZKP跨链项目对比

ZKP跨链的流程大同小异，进行个例分析时，笔者更加重视每个跨链项目的独特性。ZKP跨链的基本原理可以看上一篇博客（https://www.theblockbeats.info/news/35560）。

1. zkRouter（Multichain）

zkRouter是由Multichain开发的ZKP跨链项目，根据其白皮书描述，其愿景是要把zkRouter发展成其MBI（多链互操作协议）的一部分，作为底层信任机制服务于其多链互操作协议。这一部分内容在上一篇文章中已经有很多解释，这里强调几个要点。

从目前公开的信息来看，Goerli测试网与Fantom测试网的zkRouter跨链桥将在近期上线。zkRouter 协议主要包含初始设置、共识证明生成、验证共识证明和互操作合约调用四个步骤。如图2所示。

图2 zkRouter跨链过程
资料来源：zkRouter: Trustless, General Cross-Chain Infrastructure — 图2 zkRouter跨链过程资料来源：zkRouter: Trustless, General Cross-Chain Infrastructure

(1) 初始设置（Setup）

目标链轻客户端要完成对源链ZKP证明的验证，就必须有上一个源链区块的共识状态。区块链的共识状态具有连续性，即当前的区块共识结果是基于上一个区块共识结果的更新，因此目标链轻客户端必须先获取源链当前的共识状态，然后才能验证后续区块共识的正确性。

目标链的轻客户端在一开始需要初始initial_data，这个数据包括初始的区块高度、区块头hash等。该初始设置只需要设置一次，后续随着跨链行为发生，该数据会自动被更新。

(2) 共识证明生成（Proof Gen）

该步骤发生在具体的跨链过程中。当源链产生新的区块后，目标链需要同步新的信息，这些新的信息包括了前一区块的状态、出块节点选择、签名节点的合法性等内容。对于非即时最终性的共识机制，还需要设置一定的冗余区块数，以避免分叉带来的损失。然后中继者通过链下ZKP技术计算生成链下ZKP，同步到目标链。

(3) 验证共识证明（ProofVerify）

当简洁ZKP被中继者提交到目标链后，就需要对该ZKP进行验证了，这部分工作由链上轻客户端完成。验证通过后返回验证结果，并在目标链更新源链的共识状态信息。

(4) 互操作合约调用（InterOperCall）

当目标链轻客户端通过对源链共识（包含源链交易）的验证后，参与者就可以发起跨链合约互操作调用完成跨链交互了。具体的细节可以参考其白皮书。

zkRouter 的核心优势是实现了高TPS跨链。根据描述，zkRouter的 TPS上限是公链TPS，测试网显示其数据可以达到100TXS。

Goerli测试网源链地址：https://goerli.etherscan.io/txs?a=0x91d1d54572ef662419d9e552a013321b5713e3ad

Fantom测试网目标链地址：https://testnet.ftmscan.com/address/0x91d1D54572Ef662419d9E552A013321b5713E3AD#tokentxns

对zkRouter的具体方案，可进一步参考其白皮书具体描述。

2. Hyper Oracle（Hyper Oracle）

Hyper Oracle把自己定义为去信任的预言机网络。与其他ZKP跨链项目的区别在于，Hyper Oracle强调的是整个共识的传递。Hyper Oracle的愿景是实现端到端的无信任，需要实现轻客户端验证以太坊PoS的整个共识。

而在以太坊POS的实现中，同步委员会的共识已经是整个共识的一部分了，为什么还要强调传递整个共识呢?

3. Brevis（Celer）

Brevis对自己的定义是全链计算和验证平台，本质上也是一种跨链通信方案，也是通过生成ZKP共识证明实现去信任的跨链通信。Brevis包括了三个组件，分别为zkFabric、zkQueryNet和zkAggregatorRollup。从目前情况来看，其覆盖的范围包括了EVM和NON-EVM链，

zkFabric的主要功能是收集区块头，并在通过 ZKP 轻客户端电路证明其有效性后，生成共识证明，相当于ZK跨链角色当中的中继者和证明者。当然在这个系统中，中继的目的地是zkAggregatorRollup。

zkAggregator Rollup是由轻量级 ZKP 虚拟机提供支持的 ZK rollup 区块链，它汇总了来自 zkQueryNet 和 zkFabric 的不同证明和输入信息。根据Celer的描述，zkAggregatorRollup VM runtime 具有以下功能：

（1）递归验证由 zkQueryNet 和 zkFabric 生成的证明；

（2）存储来自 zkFabric 并已被 ZKP 验证的区块头；

（3）存储查询请求和 ZKP验证结果。

zkQueryNet是一个提供 ZKP 查询引擎的开放市场，可直接接受来自链上智能合约的数据查询，并通过 ZKP查询引擎电路生成查询结果和相应的 ZKP 查询证明。这个结果也会保存在Query Result中（Query Result属于zkAggregatorRollup 模块）。

具体如图3所示。

图3 Brevis系统组成
资料来源：Brevis: A ZK Omnichain Data Attestation Platform — 图3 Brevis系统组成资料来源：Brevis: A ZK Omnichain Data Attestation Platform

Brevis相对于其他zk跨链项目最大的特点是模块化，这种结构化的设计增强了Brevis的可拓展性，通过对不同功能的封装，Brevis可以实现统一的接口，在方便DAPP调用的同时，也利于后续拓展更多的公链。

4. Telepathy（Succinct）

Telepathy是由Succinct团队开发的协议，目标是使用户可以在无许可、去信任的情况下实现互操作性。通过Telepathy，DAPP可以安全地将消息从源链发送到任意目标链。该定义符合传统的跨链消息定义模型。

Telepathy跨链通信模型主要有五个步骤，具体如图4所示。

(1) 多链DAPP合约发起一个多链互操作指令。

(2) Telepathy Broadcaster接受到这个指令后，约在12分钟后，Ethereum主链形成最终性的共识。

(3) Telepathy Operator使用Etereum共识生成ZKP共识证明。

(4) Telepathy Relayer将共识证明传递到目标链合约。

(5) 目标链轻客户端合约验证ZKP共识证明。

这种通用的消息跨链模型非常适合多链链间消息通信，并且知名跨链项目Across已经宣布使用Telepathy构建Avalanche 与BNB Chain 之间的跨链桥。

图4 跨链消息传递模型
资料来源：Telepathy官方简介 — 图4 跨链消息传递模型资料来源：Telepathy官方简介

5. Nil.foundation

Nil与Brevis的定位类似，目标是成为多链证明市场，DAPP可以根据自己的需求请求Nil生成证明数据。这里不做过多赘述。

此外上篇文章提到的zkLLVM也是Nil的核心产品之一。该产品定位于帮助开发者使用高级语言编译ZKP，极大地降低了开发者的准入门槛。通过这个工具，开发者可以使用自己熟悉的语言专注于电路设计，而不是陷入特定领域语言DSL学习。

四、总结与展望

目前众多团队都在致力于ZK跨链桥的开发。由于ZKP的生成和源链共识紧密相关，而不同链达成共识的方式、使用的签名算法都不相同，在实践当中，各种方案的效率与特点也不尽相同，具体如表2所示。

虽然这些项目都是基于SNARK技术构建的零知识证明系统，但是实现算法、算法优化程度、使用的硬件都难以统一，因此上述ZKP的生成速度仅为参考，更多详细的数据需要进行更严谨的基准测试。

目前大部分ZK跨链桥都支持NON-EVM，在这一点上各项目区别不大。而在未来ZK跨链互操作协议的主要竞争点将在于算法优化、多链部署与合约安全上。

链下生成ZKP需要大内存高性能服务器，这意味着高昂的设备成本，而优化的算法可以节省算力。

近两个月很多跨链协议都有所动作，基本上都是围绕ZKP跨链开展，普遍上线测试网跨链，上线主网的不多。另外很多跨链协议普遍都是链接一两条链，并未实现多链互通，因此未来跨链桥支持的链越多就越有竞争优势。

ZK跨链项目普遍没有经历大规模的市场检验，合约的安全性将决定这些项目是否能在这个市场存活。目前这个问题被大多数人所忽略，而未来安全会成为ZKP项目的最大风险项。

跨链协议是区块链安全事故的重灾区，这引发了几乎所有从业人员对跨链协议的担忧，更为严峻的是，目前主流的跨链协议几乎都属于外部验证这一大类，无法实现去信任化，存在严重的安全风险。一旦中继者联合作恶，多链生态参与者将面临无法估量的损失。而ZKP跨链作为原生验证的一类，不仅具有去信任化，通用性等原生验证跨链独有的优势，Gas消耗也比直接在目标链验证原始源链数据的方式低，最近跨链项目方频繁地推出ZKP跨链测试网说明他们也敏锐地发现了这一点。但ZKP跨链协议发展仍处于早期，ZKP跨链协议是否能够给用户带来更加安全的跨链体验，还有待我们进一步跟踪和观察。