​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 所示 。

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

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

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

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

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

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

图 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

( 1) 初始设置（ Setup ）

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

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

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

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

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

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

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

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

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

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

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 官方简介

5. Nil.foundation

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

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

四 、 总结与展望

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

表 2 基于 ZKP 的主要 跨链协议比较

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

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

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

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

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

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