作者：hiweiwei.eth
多链生态的蓬勃发展，使得跨链协议变得不可或缺。但是由于跨链桥抵押了大量资产，再加上跨链协议逻辑较一般的 Swap 更为复杂，因此跨链协议遭到黑客攻击的可能性也就越来越高。截止 2022 年底，因跨链桥安全问题导致的损失就达到 20 亿美金以上，其中损失上亿美元的的跨链桥就有 Ronin Network、Horizon、BNB Chain、Wormhole、Nomad 等。
跨链桥主要解决的是跨链互操作问题。以往大量跨链桥安全事件说明，现行的跨链互操作方案还有极大的优化空间。近期 Multichain 就推出了基于零知识证明的去信任跨链解决方案 zkRouter。
Multichain 是跨链领域的龙头项目，其 21 年底就获得了 Binance 领投的 6000 万美金投资，目前占跨链市场份额第一。之前 Uniswap 跨链治理投票闹的沸沸扬扬，但是稳定币 DEX 王者–Curve 早就使用 Multichain 的 anyCall 完成了多链 LP 激励分配。表 1 给出了当前主要跨链项目相关数据对比。
表 1 当前主要跨链项目相关数据对比
（数据来源:https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148）
本文将重点分析 Multichain 基于 ZKP 推出的最新去信任产品 zkRouter，同时对市场上其他优秀 ZK 跨链项目作一对照。
一、ZKP 成为解决去信任化跨链的最佳方案
区块链的主权区域特征导致链上合约难以获取准确链外信息，而不得不依赖于第三方进行资产和消息的中继跨链，维护不同链上合约间资产的安全和信息传递的可信可靠。这与预言机的作用是类似的。这意味着跨链之间的交易需要建立在对第三方的中继跨链或预言机的信任基础上，而中继跨链和预言机在一些时候却又是难以被完全信任的。因此，如何通过去信任的手段获取链外信息，变成了一个重要的研究课题。
无论是通过中继网络，预言机或者链实现跨链中继，都可以做到部分甚至完全去中心化，但却做不到去信任化。目前市场上通过主流跨链桥构建的应用，其安全都托管给了第三方，用户需要信任跨链中继网络从而采信其传递的源链状态，而无法对其安全进行验证，而这阻碍了真正的跨链生态的出现。从某种意义上说，跨链桥最重要的特征应该是实现完全的去信任化。如果能够以一种去信任的方式构建跨链服务，由链上轻客户端独立进行验证从而直接采信源链信息，这将极大推动多链生态的进一步发展，以及原生多链应用的大规模涌现。
ZKP 技术的出现，以及由 ZKP 技术构造的跨链桥，将成为实现去信任跨链的最佳方案。
二、基于 ZKP 实现的跨链去信任化
一个优秀的跨链协议首先一定是安全的，其次是生态丰富，最后才是跨链费用低、速度快。由此，优秀的跨链协议应该具有去信任程度高、去中心化程度高、可拓展性好、跨链速度快和成本低等特性。这个观点大部分人都比较认可，笔者认为这个观点可能存在一些问题。如果一个跨链协议实现了完全去信任化，还需要考虑是否去中心化的问题吗？
现在很多跨链项目使用一条专门的链来实现跨链操作，这种做法是使跨链协议更加去中心化，但没有实现去信任化。去中心化仍然是跨链的发起方将其跨链的安全寄托在一个去中心化的网络上。但跨链协议应该实现的是去信任化，而不是去中心化，因为一旦实现跨链操作的去信任化，就不存在去中心化这个问题了。试想一下，当中继者生成的 ZKP 用户自身就可以轻易验证了，那还需要再去讨论去中心化的必要性吗？
在跨链操作过程中，信任源链共识和目标链共识是跨链操作得以存在的前提。此外，信任任何组织都会降低资产的安全性。跨链操作最好能够实现去信任化，而去信任化最终是无信任假设。要实现去信任化跨链，最好的途径就是使用 ZKP 构建跨链互操作协议的底层信任机制，实现去信任跨链。
基于 ZKP 构建的跨链桥一般涉及三个逻辑角色：
1.Proof 的生成者，其功能是观察原链状态，并使用原链数据生成 ZKP。
2. 中继者，将 ZKP 传递到目标链。
3. 链上轻客户端，链上轻客户端也是验证者，可以独立完成对 ZKP 的验证。
证明者和中继可以是同一个人也可以是不同的人，因为决定是否采纳 ZKP 的是链上轻客户端。因此，这种设置不会带来任何安全问题。此外，在 ZKP 中，只要有一个诚实的中继节点，就可以保证协议的正常运行。
现行的所有 ZK 互操作协议基本都是围绕 Ethereum 展开的，有些实现的是 Ethereum 与其他异构链的互操作，有些要完成的是 Ehtereum 与其同构链的互操作。但无论实现的是 Ehtereum 与哪一条链的互操作，都需要生成 Ethereum 的共识证明，并且在其他链上实现 Ethereum 轻客户端对该共识证明的验证。
三、zkRouter 与其他 ZK 互操作协议
基于 ZKP 构建的跨链协议可以完美地实现去信任。当前最典型的协议应该就是 Multichain 推出的 zkRouter 了。
1.zkRouter 是如何基于 ZKP 实现跨链
无论是资产跨链、消息跨链，还是跨链互操作，其本质上做的都是同一件事情，那就是用户通过智能合约在源链发起一个动作，并在目标链上验证该动作。只要这个动作能够被去信任化地验证，就可以支撑起真正意义上的原生多链，也就能够实现真正的多链互操作。
zkRouter 白皮书描述的是将 Ethereum 的消息传递到 Fantom，这涉及以下几个步骤：
首先在源链发生一笔交易（该交易可以通过区块头 hash 配合默克尔树路径验证）；
中继者将该交易提交到目标链上的轻客户端；
链上轻客户端验证该交易。
读者看到这里会有两个疑问：
轻客户端与链上轻客户端是什么？
在以上几个步骤中哪里体现了 ZKP，以及 ZKP 的作用是什么？
（1）轻客户端与链上轻客户端
自从 LayerZero 协议推出后，轻客户端的概念似乎被滥用了，在 LayerZero 协议中的超轻节点和通常意义上的轻客户端是有差异的。LayerZero 超轻节点只是验证中继者传递过来的数据是否和预言机传递过来的数据相匹配，并不直接验证链上交易。而通常意义上的轻客户端是直接验证链上交易的，从本质上讲 LayerZero 还是需要信任中继者和预言机不会联合作恶，没有实现去信任化。
我们从如何验证一笔链上交易开始探讨什么是真正的轻客户端与链上轻客户端。
什么是轻客户端？Ethereum 同一时间会发生很多笔交易，历史上也发生过很多笔交易，在没有轻客户端的情况下，用户要验证这笔交易就必须同步所有区块的所有交易数据，这显然是不可能的。
在比特币网络中，每个区块都有区块头，区块头包含了一个指向上一个区块的指针，和当前区块链内所有交易的哈希的默克尔根。其中指向上一个区块的指针能保证上一个区块内的交易数据不被篡改，而每个区块内的默克尔树包含当前区块所有交易，而通过根哈希值可以验证当前所有交易。如图 1 所示。这就可以确保当前和历史区块包含的所有交易信息都不会被篡改。Ethereum 继承了这种验证方法。Ethereum 网络的区块头也包含默克尔根和指向上一个区块的指针，可以用于验证存储的任何类型的数据。
图 1 比特币网络的默克尔树结构示意图
如图 1 所示，对交易 L1、L2、L3、L4 分别进行哈希运算, 得到 Hsh0-0=hash(L1), Hash0-1=hash(L2), Hash1-0=hash(L3), Hash1-1=hash(L4)。
轻客户端要获取根哈希（Top Hash），只需要再计算：
Hash0=hash（Hsh0-0,Hash0-1）
Hash1=hash（Hash1-0,Hash1-1）
Top Hash=hash(Hash0,hash1)
hash 运算只能是单向的，即只能通过 X 计算出 Y=Hash(X)，但却无法通过 Y 计算出 X。由此，轻客户端只需同步区块内的根哈希值，并询问全节点路径哈希数据，便可验证交易真伪。
如果轻客户端想要验证 L1 的交易。轻客户端如果有了根哈希值，通过向全节点申请 Hash1 与 Hash0-1 的值，然后就可以验证 L1 的交易了，具体的做法是：
1. 计算出 Hash0-0；
2. 根据全节点同步过来的 Hash0-1 和上一步计算出来的 Hash0-0，可以计算出 Hash0=hash(Hash0-0，Hash0-1)。
3. 根据全节点同步过来的 Hash1 和上一步计算出的 Hash0，计算出根哈希 RootH=hash（Hash0，Hash1）, 并比较计算出来的根哈希 RootH 是否等于轻客户端同步的 Top Hash。如果两者是相同的，证明 L1 交易确实在链上并且没有被更改。整个区块链正是通过这种方式实现了可信的轻客户端。
上述过程演示了轻客户端如何对链上交易进行验证。那如果在目标链上能够实现源链的轻客户端，也就是链上轻客户端，是不是就可以实现在目标链验证源链交易了呢？
试想一下，在跨链这个具体的应用当中，关键性的困难就是在目标链上无法去信任地验证源链发生的交易，而需要通过第三方进行中继，无形中降低了跨链的安全性。如果使用智能合约在另一条链上实现轻客户端，便可以在目标链上验证源链发生的交易，实现去信任化的跨链了。
（2）为什么链上轻客户端需要使用 ZKP 技术
上一小节说明了通过链上轻客户端验证源链交易的方式，完全可以实现跨链。那为什么要使用 ZKP 技术呢？
轻客户端验证涉及到大量共识产生过程中的计算，如果这些计算都在链上完成，需要消耗极高的 Gas 费用，不具有推广的可行性。而零知识证明技术可以将大量共识产生过程中的计算转移到链下可信地进行，进而生成简洁的证明结果，该结果在链上只需花费较少的 Gas 即可验证。
但凡涉及到中继，用户就会觉得有中心化的嫌疑，不够去信任化。但是在基于 ZKP 实现的跨链桥中的中继者只负责中继消息，并不负责验证消息，验证的工作由目标链的轻客户端完成。这其中严谨的数学和密码学证明可以保证目标链的轻客户端可以完成验证，实现了去信任化。
（3）zkRouter 如何使用 ZKP 技术实现跨链
zkRouter 实现的跨链方案在其白皮书上有详细的说明，但是当前市场上并无对其进行解读的文档。为理解 zkRouter，需要补充一些背景知识。
目前零知识证明的应用领域出现了几种典型的图灵完备证明算法，其中最为流行的是 zkSnark（zero-knowledge succinct non-interactive arguments of knowledge，零知识简洁非交互知识论证）和 zk-Stark（Zero-Knowledge Scalable Transparent Argument of Knowledge，零知识可拓展的透明知识论证）。zk-Stark 生成的 ZKP 文件大小为 200KB 左右，zk-Snark 生成的 ZKP 文件大小为 192B 左右。zk-Stark 生成的 ZKP 文件过大，如果使用 zk-Stark 实现跨链，目标链消耗的 Gas 会很大，因此在具体应用当中，不具备经济优势。而 zk-snark 生成的 ZKP，因其非交互、证明生成速度快、证明结果简短的优势，在区块链中应用较多，目前市场上绝大部分 ZK 跨链桥都是使用的 zk-Snark，或者是 zk-Snark 技术的变体，zkRouter 使用的也是 zk-Snark。
zkRouter 协议主要包含四个步骤。
1. 初始设置（Setup）
目标链轻客户端要完成对源链 ZKP 证明的验证，就必须有上一个源链区块的共识状态，区块链的共识状态具有连续性，即当前的区块共识结果是基于上一个区块的共识结果的更新。因此目标链轻客户端必须先获取源链当前的共识状态，然后才能验证后续区块共识的正确性。
目标链的轻客户端在一开始需要初始 initial_data，这个数据包括初始的区块高度，区块头 hash 等。这个初始设置只需要设置一次，后续随着跨链行为发生，该数据会自动被更新。
2. 共识证明生成（Proof Gen）
这个步骤发生在具体的跨链行为中。当源链产生新的区块后，目标链需要同步新的信息，这些新的信息包括了前一区块的状态，出块节点选择，签名节点的合法性等内容。对于非即时最终性的共识机制，还需要设置一定的冗余区块数，避免分叉带来的损失。然后中继者通过链下 ZKP 技术计算生成链下 ZKP，同步到目标链。
3. 验证共识证明（ProofVerify）
当简洁 ZKP 被中继者提交到目标链后，就需要对该 ZKP 进行验证了，这部分工作由链上轻客户端完成。验证通过后返回验证结果，并在目标链更新源链的共识状态信息。
4. 互操作合约调用（InterOperCall）
当目标链轻客户端通过对源链共识（包含源链交易）的验证后，参与者就可以发起跨链合约互操作调用，完成跨链交互了。
例如对于跨链 Swap，任意参与者提交对应源链交易的 TXS 和对应的默克尔树证明路径，根据轻客户端已有的源链共识信息，合约可以很简单地验证交易的真伪。
在 Multichain 的白皮书当中还有相当部分的 Ethereum->Fantom ZK 跨链实现的说明，步骤与上面的过程类似，这里不再赘述。
2. 其他主要 ZK 跨链方案
目前很多团队都在致力于 ZK 跨链桥的开发。由于 ZKP 的生成和源链共识紧密相关，而不同链达成共识的方式、使用的签名算法都不相同，因此在实践当中，项目方所要实现的不同链上轻客户端所用的方法也会有所不同，但是核心算法基本都与 zkRouter 的做法相似。
（1）Electronlabs
Electronlabs 实现了 Ethereum 测试网到 Near 测试网的双向跨链桥，这表明 Electronlabs 不仅在 Near 上实现了 Ethereum 的轻客户端，也在 Ethereum 网络上实现了 Near 的轻客户端。Cosmos 支持 Ed25519[ Ed25519 已成为 Cosmos、NEAR、Solana 等区块链生态系统的首选签名方案。验证区块链共识需要验证大量的 Ed25519 签名（验证者签名）。因此，需要对一批 Ed25519 签名进行简洁验证。] 签名算法，但是 Ethereum 并不支持该算法。因此，要在以太坊进行 Ed25519 签名的链上验证就需要一些额外的工作。
此外 Ed25519 算法不支持聚合签名，因此 Eletronlabs 使用递归的方式实现了对大量 Ed25519 算法的验证。验证签名会生成大型电路，因此，其关键问题是如何在以太坊链上高效、低成本地验证来自 Cosmos SDK 中任何区块链的 Ed25519 签名。Electronlabs 的解决方案是构建一个 zk-Snark 在链下生成签名有效性的证明，并且只在以太坊链上验证该证明。
从 Electronlabs 目前的成果上看，其在异构链部署上有一些进展，包括 Cosmos 系的公链签名算法都是 Ed25519，未来其拓展 Ed25519 签名算法的公链能力应该较强。
（2）Succinct
Succinct 同样也只上线了单向的 ZK 跨链桥，所不同的是其上线的是 Goerli->Gnosis，Optimism，Polygon，Avalanch 等测试网的 ZK 跨链桥。源链只有 Goerli 一条链。
ZK 跨链当中最复杂的部分就是根据源链共识设置电路，目标链客户端的开发工作并不会太多。因此 Succinct 上线 Goerli->Gnosis，Optimism，Polygon，Avalanch 等测试网的 ZK 跨链桥，其实和只上线一个单向的跨链桥处于同一进度。Succinct 使用的也是 zk-Snark 方案，其基本方案与通用方案区别不是很大，这里不做赘述。
Succinct 主要目标是围绕 Ethereum 周边二层网络进行拓展。从目前进度上看，如果未来其能完成 Gnosis，Optimism，Polygon，Avalanch->Goerli 的跨链，则想象空间较大。但是鉴于源链 ZKP 生成需要大量的电路设置，共识不同差异很大，这部分工作内容是 ZK 跨链实现最耗时的部分，Succinct 目前还没有完成。
（3）nil.foundation
Nil 实现了在 Ethereum 测试网与 Polygon 测试网上验证 Mina 测试网的状态，但并未实现在 Mina 测试网上验证 Ethereum 测试网与 Polygon 测试网的状态，因此在进度上，Nil 与其他的 ZK 跨链项目处于同一梯队。
但是 nil.foundation 项目得到了 ZK 赛道头部机构 Starkware 和 Mina 的投资，其技术实力可见一斑。另外，Nil 开源了 zkLLVM 产品，该产品定位于帮助开发者使用高级语言编译 ZKP，极大地降低了开发者的准入门槛。通过这个工具，开发者可以使用自己熟悉的语言专注于电路设计，而不是陷入特定领域语言–DSL 学习的怪圈。编译零知识电路往往需要特定领域语言与工具包，需要花费大量时间。
（4）Herodotus
Herodotus 官方说明使用的是「MPC+轻客户端+ZKP」实现的跨链桥，使用乐观的 MPC 方式挑战中继者中继的消息。但既然任意中继者都可以将生成的 ZKP 中继到目标链，验证由目标链上的轻客户端完成。如果还需要可信的 MPC 网络，再加入 ZKP，则意义不大，当然其测试网尚未上线，具体的方案还有待项目方后续公布。
（5）Polyhedra
Polyhedra 是目前上线测试网最多的跨链桥，上线的测试网包括了 Goerli、BNB Chain Testnet、Polygon Testnet、Fantom Testnet、Avalanche Testnet。Polyhedra 目前推出的是 NFT 跨链，用户可以通过 Polyhedra 生成跨链 NFT，然后可以使用其 NFT 跨链桥进行跨链。Polyhedra 获得了包括 Binance Labs，Polychain Capital 等机构 1000 万美金的支持。
但我们经过分析测试，发现该项目测试网并没有使用 ZKP，轻客户端也没有验证默克尔树，具体如下。
测试交易源链地址：
https://mumbai.polygonscan.com/tx/0xc89904563b9f26a2eaeae5da91e87f6c86a8a2ebc33ca9d23a02b9ffb0e58aca
测试目标链地址：
https://testnet.bscscan.com/tx/0xbcbe3f47ae9b2d17c38d0ee4271669690e5c5049b2dd150c90ad50efbaa9848b
中间嵌套合约地址：
https://testnet.bscscan.com/address/0x7b95cf4cefdd218017e0e0e4da99f3b2c6f9e2a5
最终调用验证默克尔树合约地址：
https://testnet.bscscan.com/address/0x3BBd3ECa3C1bA24603f8C8EC247f225fb629a40B
图 2 polyhedra 相关合约代码
在合约代码如图 2 所示。Hash 头验证直接返回 true。并没有没有使用的 ZK 技术，哈希头也未验证，就默认跨链消息的正确性。从测试网合约上看，并不能看到其进展，当然我们也会持续关注其测试网动态。
四、基于 ZKP 的跨链项目发展展望
当前 ZK 跨链已经成为行业热点，相关解决方案还有很多，未来的竞争极可能围绕以下几个方面展开。
1. 合约安全性。尽管很多 ZK 跨链方案都在努力实现去信任化，但是 ZKP 给出的只是底层的技术架构。底层技术架构稳固了，但还是难以避免智能合约在编写和运行方面可能产生的安全问题。
2. 多链双向部署。这一方向的进展目前还不是很分明，以上几个案例都没有实现多链双向部署。如果哪一家的跨链桥能够率先实现多链双向部署，将会成为很大的竞争优势。
3. 是否是去信任的 ZK 跨链桥，从上述论述中，读者可以发现，ZK 跨链桥最重要的优势就是可以实现去信任化的跨链，如果不能实现去信任化跨链，那么将 ZKP 应用在跨链领域意义不大。
五、总结
我们从测试网进度、Non-EVM 支持性、产品可靠性、团队技术能力、是否去信任等维度比较了 ZK 跨链赛道内的几个知名项目，具体如表 2 所示。
表 2 当前几个主要 zk 跨链赛道项目比较
由表 2 可以看到，目前几个主要的 zk 跨链项目基本都处于起步阶段，技术方案也大致相同。但 ZKP 在理论上的完全去信任化，使得未来基于 ZKP 去信任化地实现跨链，进而对推动多链生态、多链宇宙、原生多链应用的发展而具有了更加重要的意义。
根据 Multichain 公布的路线图，其从 Anyswap 诞生的时候就有两种方案，一种是基于 MPC 的跨链方案，一种是基于 ZKP 的方案。对于 Multichain 开发的 zkRouter 我认为有几点是值的期待的：
1.Multichain 深厚的跨链技术背景。Multichain 深耕跨链业务多年，技术背景深厚，基于此，我们可以期待 Multichain 的 zkRouter 在 ZK 跨链的赛道上取得更大进展。在 zkRoutr 测试网上线后，用户也可以亲自感受一下 zkRouter 的使用体验。当然，作为 POC 阶段的产品，普通用户还是难以从使用中获得直接的去信任体验，包括 zkRouter 未来可能达到的跨链速度、跨链费用等指标。这些内容还有待更多专家从更专业的层面和角度进行研判。
2. 庞大的生态伙伴。Multichain 与上千个多链项目有深入的合作，这个优势是其他跨链协议不具备的。因此，zkRouter 一旦进入实用阶段，借助 Multichain 的庞大生态，zkRouter 就完全有可能成为下一代跨链有力的竞争者。
文章来源于互联网:zkRouter如何实现安全跨链