多链生态的蓬勃发展，使得跨链协议变得不可或缺。但是由于跨链桥抵押了大量资产，再加上跨链协议逻辑较一般的Swap更为复杂，因此跨链协议遭到黑客攻击的可能性也就越来越高。截止2022年底，因跨链桥安全问题导致的损失就达到20亿美金以上，其中损失上亿美元的的跨链桥就有Ronin Network、Horizon、BNB Chain、Wormhole、Nomad等。 跨链桥主要解决的是跨链互操作问题。以往大量跨链桥安全事件说明，现行的跨链互操作方案还有极大的优化空间。近期Multichain就推出了基于零知识证明的去信任跨链解决方案zkRouter。 Multichain是跨链领域的龙头项目，其21年底就获得了币安领投的6000万美金投资，目前占跨链市场份额第一。之前Uniswap跨链治理投票闹的沸沸扬扬，但是稳定币DEX王者--Curve早就使用Multichain的anyCall完成了多链LP激励分配。表1给出了当前主要跨链项目相关数据对比。

数据来源:https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148） 本文将重点分析Multichain基于ZKP推出的最新去信任产品zkRouter，同时对市场上其他优秀ZK跨链项目作一对照。

一、ZKP成为解决去信任化跨链的最佳方案

区块链的主权区域特征导致链上合约难以获取准确链外信息，而不得不依赖于第三方进行资产和消息的中继跨链，维护不同链上合约间资产的安全和信息传递的可信可靠。这与预言机的作用是类似的。这意味着跨链之间的交易需要建立在对第三方的中继跨链或预言机的信任基础上，而中继跨链和预言机在一些时候却又是难以被完全信任的。因此，如何通过去信任的手段获取链外信息，变成了一个重要的研究课题。 无论是通过中继网络，预言机或者链实现跨链中继，都可以做到部分甚至完全去中心化，但却做不到去信任化。目前市场上通过主流跨链桥构建的应用，其安全都托管给了第三方，用户需要信任跨链中继网络从而采信其传递的源链状态，而无法对其安全进行验证，而这阻碍了真正的跨链生态的出现。从某种意义上说，跨链桥最重要的特征应该是实现完全的去信任化。如果能够以一种去信任的方式构建跨链服务，由链上轻客户端独立进行验证从而直接采信源链信息，这将极大推动多链生态的进一步发展，以及原生多链应用的大规模涌现。 ZKP技术的出现，以及由ZKP技术构造的跨链桥，将成为实现去信任跨链的最佳方案。

二、基于ZKP实现的跨链去信任化

一个优秀的跨链协议首先一定是安全的，其次是生态丰富，最后才是跨链费用低、速度快。由此，优秀的跨链协议应该具有去信任程度高、去中心化程度高、可拓展性好、跨链速度快和成本低等特性。这个观点大部分人都比较认可，笔者认为这个观点可能存在一些问题。如果一个跨链协议实现了完全去信任化，还需要考虑是否去中心化的问题吗？           现在很多跨链项目使用一条专门的链来实现跨链操作，这种做法是使跨链协议更加去中心化，但没有实现去信任化。去中心化仍然是跨链的发起方将其跨链的安全寄托在一个去中心化的网络上。但跨链协议应该实现的是去信任化，而不是去中心化，因为一旦实现跨链操作的去信任化，就不存在去中心化这个问题了。试想一下，当中继者生成的ZKP用户自身就可以轻易验证了，那还需要再去讨论去中心化的必要性吗？           在跨链操作过程中，信任源链共识和目标链共识是跨链操作得以存在的前提。此外，信任任何组织都会降低资产的安全性。跨链操作最好能够实现去信任化，而去信任化最终是无信任假设。要实现去信任化跨链，最好的途径就是使用ZKP构建跨链互操作协议的底层信任机制，实现去信任跨链。基于ZKP构建的跨链桥一般涉及三个逻辑角色：

①Proof的生成者，其功能是观察原链状态，并使用原链数据生成ZKP。

②中继者，将ZKP传递到目标链。

③链上轻客户端，链上轻客户端也是验证者，可以独立完成对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所示，对交易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的交易了，具体的做法是：

①计算出Hash0-0；

②根据全节点同步过来的Hash0-1和上一步计算出来的Hash0-0，可以计算出Hash0=hash(Hash0-0，Hash0-1)。

③根据全节点同步过来的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 协议主要包含四个步骤。

①初始设置（Setup） 目标链轻客户端要完成对源链ZKP证明的验证，就必须有上一个源链区块的共识状态，区块链的共识状态具有连续性，即当前的区块共识结果是基于上一个区块的共识结果的更新。因此目标链轻客户端必须先获取源链当前的共识状态，然后才能验证后续区块共识的正确性。 目标链的轻客户端在一开始需要初始initial_data，这个数据包括初始的区块高度，区块头hash等。这个初始设置只需要设置一次，后续随着跨链行为发生，该数据会自动被更新。

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

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

④互操作合约调用（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所示。Hash头验证直接返回true。并没有没有使用的ZK技术，哈希头也未验证，就默认跨链消息的正确性。从测试网合约上看，并不能看到其进展，当然我们也会持续关注其测试网动态。

四、基于ZKP的跨链项目发展展望

当前ZK跨链已经成为行业热点，相关解决方案还有很多，未来的竞争极可能围绕以下几个方面展开。

1.合约安全性。尽管很多ZK跨链方案都在努力实现去信任化，但是ZKP给出的只是底层的技术架构。底层技术架构稳固了，但还是难以避免智能合约在编写和运行方面可能产生的安全问题。

2. 多链双向部署。这一方向的进展目前还不是很分明，以上几个案例都没有实现多链双向部署。如果哪一家的跨链桥能够率先实现多链双向部署，将会成为很大的竞争优势。

3. 是否是去信任的ZK跨链桥，从上述论述中，读者可以发现，ZK跨链桥最重要的优势就是可以实现去信任化的跨链，如果不能实现去信任化跨链，那么将ZKP应用在跨链领域意义不大。

五、总结

我们从测试网进度、Non-EVM支持性、产品可靠性、团队技术能力、是否去信任等维度比较了ZK跨链赛道内的几个知名项目，具体如表2所示。

由表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就完全有可能成为下一代跨链有力的竞争者。

作者：theodore WEIWEI

https://twitter.com/ZhanweiC

多链生态的蓬勃发展，使得跨链协议变得不可或缺。但是由于跨链桥抵押了大量资产，再加上跨链协议逻辑较一般的Swap更为复杂，因此跨链协议遭到黑客攻击的可能性也就越来越高。截止2022年底，因跨链桥安全问题导致的损失就达到20亿美金以上，其中损失上亿美元的的跨链桥就有Ronin Network、Horizon、BNB Chain、Wormhole、Nomad等。 跨链桥主要解决的是跨链互操作问题。以往大量跨链桥安全事件说明，现行的跨链互操作方案还有极大的优化空间。近期Multichain就推出了基于零知识证明的去信任跨链解决方案zkRouter。 Multichain是跨链领域的龙头项目，其21年底就获得了币安领投的6000万美金投资，目前占跨链市场份额第一。之前Uniswap跨链治理投票闹的沸沸扬扬，但是稳定币DEX王者--Curve早就使用Multichain的anyCall完成了多链LP激励分配。表1给出了当前主要跨链项目相关数据对比。

数据来源:https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148） 本文将重点分析Multichain基于ZKP推出的最新去信任产品zkRouter，同时对市场上其他优秀ZK跨链项目作一对照。

一、ZKP成为解决去信任化跨链的最佳方案

区块链的主权区域特征导致链上合约难以获取准确链外信息，而不得不依赖于第三方进行资产和消息的中继跨链，维护不同链上合约间资产的安全和信息传递的可信可靠。这与预言机的作用是类似的。这意味着跨链之间的交易需要建立在对第三方的中继跨链或预言机的信任基础上，而中继跨链和预言机在一些时候却又是难以被完全信任的。因此，如何通过去信任的手段获取链外信息，变成了一个重要的研究课题。 无论是通过中继网络，预言机或者链实现跨链中继，都可以做到部分甚至完全去中心化，但却做不到去信任化。目前市场上通过主流跨链桥构建的应用，其安全都托管给了第三方，用户需要信任跨链中继网络从而采信其传递的源链状态，而无法对其安全进行验证，而这阻碍了真正的跨链生态的出现。从某种意义上说，跨链桥最重要的特征应该是实现完全的去信任化。如果能够以一种去信任的方式构建跨链服务，由链上轻客户端独立进行验证从而直接采信源链信息，这将极大推动多链生态的进一步发展，以及原生多链应用的大规模涌现。 ZKP技术的出现，以及由ZKP技术构造的跨链桥，将成为实现去信任跨链的最佳方案。

二、基于ZKP实现的跨链去信任化

一个优秀的跨链协议首先一定是安全的，其次是生态丰富，最后才是跨链费用低、速度快。由此，优秀的跨链协议应该具有去信任程度高、去中心化程度高、可拓展性好、跨链速度快和成本低等特性。这个观点大部分人都比较认可，笔者认为这个观点可能存在一些问题。如果一个跨链协议实现了完全去信任化，还需要考虑是否去中心化的问题吗？           现在很多跨链项目使用一条专门的链来实现跨链操作，这种做法是使跨链协议更加去中心化，但没有实现去信任化。去中心化仍然是跨链的发起方将其跨链的安全寄托在一个去中心化的网络上。但跨链协议应该实现的是去信任化，而不是去中心化，因为一旦实现跨链操作的去信任化，就不存在去中心化这个问题了。试想一下，当中继者生成的ZKP用户自身就可以轻易验证了，那还需要再去讨论去中心化的必要性吗？           在跨链操作过程中，信任源链共识和目标链共识是跨链操作得以存在的前提。此外，信任任何组织都会降低资产的安全性。跨链操作最好能够实现去信任化，而去信任化最终是无信任假设。要实现去信任化跨链，最好的途径就是使用ZKP构建跨链互操作协议的底层信任机制，实现去信任跨链。基于ZKP构建的跨链桥一般涉及三个逻辑角色：

①Proof的生成者，其功能是观察原链状态，并使用原链数据生成ZKP。

②中继者，将ZKP传递到目标链。

③链上轻客户端，链上轻客户端也是验证者，可以独立完成对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所示，对交易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的交易了，具体的做法是：

①计算出Hash0-0；

②根据全节点同步过来的Hash0-1和上一步计算出来的Hash0-0，可以计算出Hash0=hash(Hash0-0，Hash0-1)。

③根据全节点同步过来的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 协议主要包含四个步骤。

①初始设置（Setup） 目标链轻客户端要完成对源链ZKP证明的验证，就必须有上一个源链区块的共识状态，区块链的共识状态具有连续性，即当前的区块共识结果是基于上一个区块的共识结果的更新。因此目标链轻客户端必须先获取源链当前的共识状态，然后才能验证后续区块共识的正确性。 目标链的轻客户端在一开始需要初始initial_data，这个数据包括初始的区块高度，区块头hash等。这个初始设置只需要设置一次，后续随着跨链行为发生，该数据会自动被更新。

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

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

④互操作合约调用（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所示。Hash头验证直接返回true。并没有没有使用的ZK技术，哈希头也未验证，就默认跨链消息的正确性。从测试网合约上看，并不能看到其进展，当然我们也会持续关注其测试网动态。

四、基于ZKP的跨链项目发展展望

当前ZK跨链已经成为行业热点，相关解决方案还有很多，未来的竞争极可能围绕以下几个方面展开。

1.合约安全性。尽管很多ZK跨链方案都在努力实现去信任化，但是ZKP给出的只是底层的技术架构。底层技术架构稳固了，但还是难以避免智能合约在编写和运行方面可能产生的安全问题。

2. 多链双向部署。这一方向的进展目前还不是很分明，以上几个案例都没有实现多链双向部署。如果哪一家的跨链桥能够率先实现多链双向部署，将会成为很大的竞争优势。

3. 是否是去信任的ZK跨链桥，从上述论述中，读者可以发现，ZK跨链桥最重要的优势就是可以实现去信任化的跨链，如果不能实现去信任化跨链，那么将ZKP应用在跨链领域意义不大。

五、总结

我们从测试网进度、Non-EVM支持性、产品可靠性、团队技术能力、是否去信任等维度比较了ZK跨链赛道内的几个知名项目，具体如表2所示。

由表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就完全有可能成为下一代跨链有力的竞争者。

作者：theodore WEIWEI

https://twitter.com/ZhanweiC