# 马上2023年，跨链还有哪些可能性？

By [Jeffrey Hu](https://paragraph.com/@huzhiwei) · 2022-10-31

---

跨链技术似乎一直是一个争议不断，但又不断被人提及的技术。特别是每当有跨链桥被盗时，对跨链技术的争议就会随之而起。而另一方面随着 IBC、LayerZero 等技术不断成熟，社区似乎对跨链未来的期待也会止步于此。

那么，这就是跨链的 endgame 了？Well,

> This is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.

跨链在 2022 年最近几个月就有不少新的进展值得关注。借着近期被邀请进行了几次跨链分享的机会，把自己对于跨链技术和动向的观察和思考记录下来。

一、跨链技术的分层概览
===========

1\. 通过分层来理解跨链
-------------

在理解这些进展之前，有必要再回顾一下跨链的具体问题：当我们谈到跨链，其背后具体的本质是什么？用最近比较流行的话来说，怎么用“第一性原理”来理解跨链。

如果说区块链最核心或最不同于其他技术的特点是去信任化，即信息可以在链上不用去信任而是可被验证（Don’t trust, verify），那么**跨链其实就是把原本一个链上的信息如何在链间被验证**。传递的信息从广义上来讲包括交易以及对于该交易的有效性证明（一般为 merkle proof）。

与此对应的，基于链上可被验证的信息，区块链就可以构建出来资产转账交易等基本类型的应用。而基于验证后的跨链信息，一些跨链应用也可以构建出来，例如采用最常见的 lock & mint（源链锁定后在目标链上发行）方式来跨链转移 token。

因此，根据“跨链”技术或项目所解决的问题的不同，**可以从通信层、应用层这两个方面进行分类**。

2\. 跨链技术分类
----------

![](https://storage.googleapis.com/papyrus_images/8ecc10285981aab248c2d18eb7ee3ecc4eb4c7d6c3901ffbe2feb8a80229579d.png)

### 通信层

首先看通信层。如何实现一个链上的信息可以被另一个链所验证？根据验证方的不同，主要可以分为：外部验证、本地验证、原生验证

*   **外部验证**：跨链的信息由外部的一些见证人（也被称为公证人、网关等）来验证其有效性。这种方式一般可以更快速的连接各种异构链，因为只需要见证人在各个链上可读写信息即可，但跨链的信息有效性，比如交易信息是否真的在源链被确认了，则需要依赖于见证人。即整个跨链的安全性需要依赖于见证人的诚实假设。
    
*   **本地验证**：如果不依赖于外部的见证人，用户自己可以直接去观察链上的交易情况，并和交易对手方通过 HTLC 等技术手段去保证互换的交易可以达成。这种方式避免了信任第三方的见证人，也可以快速在异构链上实现跨链转移，但缺点是比较难去实现更复杂的应用，例如通用信息传递、智能合约调用等。
    
*   **原生验证**：由区块链自己来独立校验跨链信息的合法性。一般会采用集成其他区块链的轻客户端的形式来实现，这样区块链可以去跟踪、获取、校验其他区块链上的信息，并对应的采取一些行为，例如跨链转移、释放 token 等。由于异构链的模型很多，因此也比较需要一类跨链标准来简化设计和实现，例如 IBC 跨链协议等。这种跨链技术的安全性最好，因为不需要增加额外的信任假设，但开发工作量也较大，因为需要在链上相互实现轻客户端，以及可能需要实现完整的跨链协议栈等。
    

### 应用层

只有底层的通信层还不够，还需要构建出面向用户的应用。基于底层验证好的跨链信息，理论上不要求强事务一致性的跨链应用都可以构建出来。不过最常见的应该仍然属于跨链的 token 转移等基本交易形式。因此，问题也就主要是如何解决跨链流动性的传递。而这类问题的解决方式可以借鉴交易类型进行划分：中央对手方、OTC/P2P、自动兑换（Swap）

*   中央对手方：一般“官方跨链桥”多采用这种方式，由官方指定的地址来承担换入换出的操作。即上文提到的 lock & mint 的形式。例如用户在源链上发起跨链时，将 token 锁定到某一地址中，并由该地址在目标链上铸造出 token；
    
*   OTC/P2P：除了官方承担兑换职责外，交易对手方还可以是第三方的做市商或其他用户等。例如用户发布跨链转账的流动性，跨链做市商可以接收这个报价并在目标链上为用户释放流动性。
    
*   自动兑换（Swap）：除了用户间的交易之外，交易的对手还可以是一个自动兑换协议，例如用户在源链的 AMM 上换入之后，由协议再在目标链上换出。
    
*   流动性聚合：和 1inch 等本链上的流动性聚合协议类似，有一些协议会通过聚合上述各种跨链流动性实现，提供链间的流动性聚合应用，以给用户提供流动性最好/报价最优/成本最低的跨链转移渠道。
    

二、跨链还有哪些可能性
===========

![](https://storage.googleapis.com/papyrus_images/6561df4186cc5633683ceb5ba94e02e8d7b2cdc58d7797401ee28d23db1333ec.png)

1\. 底层更轻量化
----------

虽然 IBC 协议被誉为跨链的黄金标准，但在异构链的实现上可能会遇到一些实际的困难，例如以太坊对于原生验证 Tendermint 的区块头时的签名等计算可能就会超出 gas 限制。

### 从中继器到预言机

IBC 协议的正常运行需要中继器这个角色。一个有些“反直觉”之处在于，这个中继器可以是中心化的但不需要被信任（trusted）。原因是传递的信息是可以由目标链独立的去验证，因此中继器无法像外部验证的方式一样篡改消息来实现盗取用户资金的作恶行为。中继器即类似于互联网协议中的物理层，起到了连接不同网络并传输信息的作用。

尽管 IBC 协议的安全性（security）不依赖于中继器，但 IBC 能够正常运行的确需要依赖于至少有一个在正常工作的中继器来保证整个协议的活性（liveness）。

不过因为中继器的主要任务是要将观测源链信息，并在目标链上提交，即完成信息传递的过程。那么，这一过程就可以通过预言机的方式来实现。也就是预言机从“链下到链上”变为链上到链上”的信息传输。

这可能也是很多预言机项目，例如 Chainlink CCIP\[1\]、SupraOracle 等都在朝着跨链的方向来实现的原因之一。

### 从预言机到 TEE

那么，具体哪些可以被预言机所传递？LayerZero 是一个很好的案例。它是将 IBC 协议中的共识状态的验证通过预言机的方式来进行，即不需要再不断的根据最新验证人等变化情况来更新和验证区块头的工作，而是当需要的时候通过预言机去查询和校验所需要的信息。

![LayerZero 将轻客户端的部分工作交给预言机来完成[2]](https://storage.googleapis.com/papyrus_images/3e409d679231803f6e078f7c1b263ad86eb687db1326fdb955650bf5eeb1994b.png)

LayerZero 将轻客户端的部分工作交给预言机来完成\[2\]

这样可以极大降低链上验证成本，而原先在链间负责传递信息的中继器（relayer）只需要传递跨链的交易及其证明即可。因此 LayerZero 可以快速连接多个 EVM 链。不过因为引入了第三方预言机这一额外的安全假设（需要信任预言机不会串通作恶），降低了一定的系统安全性。其他可能的实现还包括利用 Substrate 的“原生预言机” off-chain workers 来传递\[3\]。

因此，要降低对于预言机的信任依赖，还有一个办法是通过其他的技术手段来改进区块头同步的工作。例如 LCP Network 采用了使用 TEE（可信执行环境）来对跨链交易进行验证\[4\]。

### 从 Merkle proof 到 ZK proof

除了如何解决信息的传递之外，对于信息（包括信息的证明）本身如何构造，最近也有一些利用零知识证明技术的探索。回顾本文开头对于跨链的定义，跨链核心要传递的信息之一是对于交易的有效性证明（validity proof）。当前的跨链实现一般利用的是 Merkle proof。

而另一大类有效性证明是当前大热的零知识证明技术对应的 ZK Proof。近期的零知识证明等技术的发展，也将基于零知识证明的跨链桥（ZK Bridge）从理论\[5\]逐渐变为可能。

通过生成零知识证明，可以用来解决上述的以太坊上验证 Ed25519 等签名成本困难的问题。例如 Electron Labs 通过实现 ZK SNARKs 的证明来校验基于 Tendermint 链的签名合法性\[6\]，以此来避免在智能合约里的来执行签名相关的高成本计算。

![通过零知识证明在以太坊上实现 IBC 的设计[6]](https://storage.googleapis.com/papyrus_images/5fb5eaffb0232afd0707943133860a52b41d606f5b242239d9ab24cff5f0c2fe.png)

通过零知识证明在以太坊上实现 IBC 的设计\[6\]

其他目前在开发 ZK 跨链桥的团队和项目还包括 Succinct Labs、zkbridge\[7\]、Polymer\[8\] 以及 Mina\[9\] 等。

![目前部分基于零知识证明的跨链设计[7]](https://storage.googleapis.com/papyrus_images/7a9f60d45ac0e373458e0732295b1ebb6b6d070c6cec8ef454675d8df8215b91.png)

目前部分基于零知识证明的跨链设计\[7\]

2\. 更好的开发支持（通用信息、智能合约调用）
------------------------

上述底层跨链协议，可以更好的支持通用信息的传递，包括智能合约调用等等。因此不少项目已经在此基础上开始做进一步的封装，提供 SDK 等，支持应用开发方开发出多链、全链（omni chain）的应用。

这其中包括 IBC Interchain Account\[10\]、Multichain anycall、Celer IM 等等；也可以基于这些底层跨链协议开发出封装更友好的一些中间件（例如 Spanning Labs 等），支持开发出来多链部署、跨链结算的应用。即把以往应用层需要关心的 token 如何跨链转移等工作下放到中间件或底层来实现。

3\. 应用层流动性
----------

基于跨链底层、中间件等，在应用层流动性上面可以有更多创新的设计。例如近期提出的 slAMM\[11\]（共享流动性的 AMM），通过 Hub 链来协调各个“卫星链”上的流动性。其中，可以基于跨链协议来实现在各个链上的流动性移动、结算等等管理功能。

![dAMM、slAMM 的设计及区别[11]](https://storage.googleapis.com/papyrus_images/3f1f4fa188d856549bf61bba9917facb3c1c21db0d3860ab5fe72479fec62949.png)

dAMM、slAMM 的设计及区别\[11\]

4.“反作用”于协议层
-----------

跨链一般被认为是对区块链基础协议层的支持。不过随着跨链技术的发展，它可能也会反过来对区块链协议本身未来的设计产生一定的变化。

### 对共识的改进

首先的影响在于区块链共识方面。

由于应用链+跨链的设计，很多应用链在开始设计时对于自身安全的维护可能是不够的，因此还需要采用一定的跨链验证的方式，由大网络来保证小网络的安全。例如 Cosmos 链间安全（interchain security）、Polkadot 的中继链+平行链的设计等。

除了这种子链围绕在主链的单向跨链验证的方式外，还有一种可能是近期提出的网状安全\[12\]（Mesh Security），即网络之间相互跨链验证。由于想法还比较早期，具体设计、实现还有待观察。

![网状安全示例[12]](https://storage.googleapis.com/papyrus_images/3b7ba18cd18fe44fba565123b064dfb9d125d0a8f35efaca8f342fc5cd5baec5.png)

网状安全示例\[12\]

### 对 MEV 的影响

另一个影响比较大的对于 MEV（最大可提取价值）的设计。单链上的 MEV 的产业规模已经很大。据 Chorus One 统计\[13\]，截止 2022 年 10 月，以太坊上已有累积超过 10 亿美金的 MEV。

跨链协议的设计在考虑对 MEV 的设计，从而可能对目前的 MEV 格局产生影响。例如 Cosmos 2.0 白皮书\[14\]、Zenith\[15\]等区块空间市场化。例如，通过链间调度器（Interchain Allocator）实现：

*   链间安全（共享安全）的消费者链提供区块空间
    
*   用户通过购买来确保锁定跨链套利、结算机会等
    

写在最后
====

尽管目前区块链行业内对于技术创新的主要关注点还在以太坊上的 ZK、AA、MEV 等等，但跨链协议近期的 BUIDL，在轻量化底层协议、更完善的开发支持、流动性应用创新、反作用于协议层方面，特别是 ZK bridge 方面都有不少值得期待的新进展。不过由于技术进展快、项目多，本文这一点维小的总结难免有疏漏和错误，欢迎联系讨论！

参考资料
====

\[1\] Cross-Chain Interoperability Protocol (CCIP) | Chainlink\[EB/OL\]. \[2022-10-15\]. [https://chain.link/cross-chain](https://chain.link/cross-chain). \[2\] ZARICK R, PELLEGRINO B, BANISTER C. LayerZero: Trustless Omnichain Interoperability Protocol\[J\]. 10. \[3\] LIU L. 0x499播客DeLight：刘毅谈 dYdX “叛逃”以太坊\[EB/OL\]//Weixin Official Accounts Platform. \[2022-10-15\]. [http://mp.weixin.qq.com/s?\_\_biz=MzkyMTI3MTc2NA==&mid=2247484618&idx=1&sn=ac16472df09304ad840a6758accc62e3&chksm=c1876871f6f0e167c9d32bdbf37090a3580bab97a33df0516d16a5d91836502baa1f07e2e879#rd](http://mp.weixin.qq.com/s?__biz=MzkyMTI3MTc2NA==&mid=2247484618&idx=1&sn=ac16472df09304ad840a6758accc62e3&chksm=c1876871f6f0e167c9d32bdbf37090a3580bab97a33df0516d16a5d91836502baa1f07e2e879#rd). \[4\] LCP — A Proxy for Light Client Verification to Realize Trust-minimized and Gas-efficient Cross-chain Bridges | LCP Blog\[EB/OL\]. \[2022-10-15\]. [https://medium.com/lcp-network/lcp-a-proxy-for-light-client-verification-to-realize-trust-minimized-and-gas-efficient-f7d5868e4b0](https://medium.com/lcp-network/lcp-a-proxy-for-light-client-verification-to-realize-trust-minimized-and-gas-efficient-f7d5868e4b0). \[5\] CHAND A. [LI.FI](http://LI.FI): With Bridges, Trust is a Spectrum\[EB/OL\]. (2022-04-28)\[2022-10-08\]. [https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8). \[6\] Bringing IBC to Ethereum using ZK-Snarks\[EB/OL\]//Ethereum Research. (2022-09-12)\[2022-10-16\]. [https://ethresear.ch/t/bringing-ibc-to-ethereum-using-zk-snarks/13634](https://ethresear.ch/t/bringing-ibc-to-ethereum-using-zk-snarks/13634). \[7\] INGONYAMA. Bridging the Multichain Universe with Zero Knowledge Proofs\[EB/OL\]. (2022-10-03)\[2022-10-08\]. [https://medium.com/@ingonyama/bridging-the-multichain-universe-with-zero-knowledge-proofs-6157464fbc86](https://medium.com/@ingonyama/bridging-the-multichain-universe-with-zero-knowledge-proofs-6157464fbc86). \[8\] POLYMER LABS. Developing the Most Truly Decentralized Interoperability Solution | Polymer ZK-IBC\[EB/OL\]//Medium. (2022-10-07)\[2022-10-20\]. [https://polymerlabs.medium.com/developing-the-most-truly-decentralized-interoperability-solution-polymer-zk-ibc-f0287ea84a2b](https://polymerlabs.medium.com/developing-the-most-truly-decentralized-interoperability-solution-polymer-zk-ibc-f0287ea84a2b). \[9\] MINASISM 🪶 \[@MINASISM\_\]. What is zkBridge?\[EB/OL\]//Twitter. (2022-10-15)\[2022-10-15\]. [https://twitter.com/minasism\_/status/1581243439685206016](https://twitter.com/minasism_/status/1581243439685206016). \[10\] ICS27 Interchain Accounts\[CP/OL\]. COSMOS, 2022\[2022-10-16\]. [https://github.com/cosmos/ibc/blob/c919d8ec8bec086be00b68d6f0e9ca4b0a0b8c5e/spec/app/ics-027-interchain-accounts/README.md](https://github.com/cosmos/ibc/blob/c919d8ec8bec086be00b68d6f0e9ca4b0a0b8c5e/spec/app/ics-027-interchain-accounts/README.md). \[11\] DELPHI DIGITAL. SLAMM: A Unified Model for Cross-Chain Liquidity\[EB/OL\]//Delphi Digital. \[2022-10-15\]. [https://members.delphidigital.io/reports/slamm-unified-model-cross-chain-liquidity/](https://members.delphidigital.io/reports/slamm-unified-model-cross-chain-liquidity/). \[12\] CRYPTOCITO. Cosmoverse Medellín - The Cosmos Ecosystem Conference 2022\[Z/OL\]. (2022-09-26)\[2022-10-16\]. [https://www.youtube.com/watch?v=Z2ZBKo9-iRs](https://www.youtube.com/watch?v=Z2ZBKo9-iRs). \[13\] CHORUS ONE. Ethereum MEV data\[EB/OL\]. \[2022-10-16\]. [https://dune.com/chorus\_one/ethereum-mev-data](https://dune.com/chorus_one/ethereum-mev-data). \[14\] \[PROPOSAL ##\]\[DRAFT\] A new vision for Cosmos Hub - Hub Proposals / Signaling/Text\[EB/OL\]//Cosmos Hub Forum. (2022-09-26)\[2022-10-16\]. [https://forum.cosmos.network/t/proposal-draft-a-new-vision-for-cosmos-hub/7328](https://forum.cosmos.network/t/proposal-draft-a-new-vision-for-cosmos-hub/7328). \[15\] Introducing Zenith: the first Maximum Aggregate Value (MAV) market for the Interchain\[EB/OL\]. \[2022-10-16\]. [https://meka.tech/writing/introducing-zenith-the-first-maximum-aggregate-value-mav-market-for-the-interchain-697b5298-75d5-4cdd-9e3b-ae1d0ffc36c1](https://meka.tech/writing/introducing-zenith-the-first-maximum-aggregate-value-mav-market-for-the-interchain-697b5298-75d5-4cdd-9e3b-ae1d0ffc36c1).

---

*Originally published on [Jeffrey Hu](https://paragraph.com/@huzhiwei/2023)*
