跨链 - 技术分类总结

最近看了看跨链相关的项目，总结一下跨链的相关技术。所谓“跨链”，一条链上的“跨链”语义能在另外链上正确执行。目前跨链项目主要实现在一个链上的资产映射到另外一条链上。从技术角度看，个人认为目前跨链技术主要有三种：HTLC，跨链桥（基于共识）和跨链桥（基于轻客户端）。相关的技术以及项目总结如下图：

01 HTLC（Hash Time Lock Contract）

HTLC原理比较简单：

如果Alice和Tom之间想交换资产，Alice先创建HTLC，Tom接着创建具有同样Hash的HTLC。简单的说，Tom和Alice创建了具有同样秘钥的“锁”，锁住各自资产。当Alice用秘钥打开Tom的资产时，Tom用同样的秘钥可以打开Alice的资产。当然，Tom和Alice都需要确认资产和锁的时间。

通过HTLC实现跨链，简单并且保证了交易双方的原子操作，但是要求两条链都支持智能合约，限定了两个交易方并且交换的资产不可分割。事实上，为了保证交易双方有效交易，交易双方需要额外的沟通渠道预先达成共识。

02 跨链桥 - 基于共识

基于其他共识的跨链桥逻辑上比较好实现，由共识确认一个链上的事件，并在另外一条链上执行。整个桥的安全性取决于共识的强弱。共识，除了传统意义的共识机制（BFT，PoS等等）外，还包括多方计算（MPC）和多签。

03 跨链桥 - 基于轻客户端

为了在一条链上能验证另外一条链上的信息，在这条链上“运行”另外一条链的轻客户端。通常轻客户端都是基于SPV（Simple Payment Verification）协议。SPV源自BTC，主要用在PoW共识的链中。Celo和Harmony也针对自己链的共识算法实现了轻客户端。纯粹的PoS共识的链比较难实现轻客户端，因为共识依赖Staking，而Staking由交易组成。为了实现轻客户端，穷举Staking交易不现实。

跨链桥的两个链互相通过轻客户端验证对方链的状态。这种跨链桥依赖Relay（中继），及时同步链的区块头信息。因为要同步区块头，需要如下的一些因素：

1/ 同步频次和费用：在另外一条链上存储区块头信息需要费用。特别是tps比较高的链，区块比较多。

2/ 确认主链以及区块确认：根据链的共识，通过区块头信息确定主链。以PoW的链为例，区块确认一般通过后续区块个数确认。

优化同步费用有几种思路：1/ 随机挑战（NiPoPOW，FlyClient）2/ zk-SNARK （包括recursive zk-SNARK）。选一些典型介绍：

• BTCRelay

采用传统的SPV轻客户端的实现方式实现从BTC到ETH的跨链。显然为了同步BTC的区块头，在ETH消耗Gas。在以太坊Gas price比较高的情况下，同步费用比较高。

• FlyClient

FlyClient采用随机挑战和MMR（Merkle Mountain Range)的技术，降低轻客户端同步区块的个数。随机挑战的目的是在一定范围的区块并不需要全部同步到链上，随机抽取一些区块同步。为了在链上能验证没有抽取到的区块，所有的区块信息通过MMR组织在一起。MMR是一种变种的Merkle树，适用于追加节点的场景。MMR，相对于普通二叉的Merkle树，具有更新叶子结点代价小的特点。

• zkRelay

zkRelay也尝试降低链上轻客户端同步区块的费用。和FlyClient不同，zkRelay采用的是zk-SNARK证明。将一段范围内的区块有效性，通过将链下证明提交到链上，链上只需要检查证明是否有效。

• Celo

Celo是个有意思的项目。Celo项目本身和跨链没有什么关系，但是给轻客户端提供了一些新思路。为了实现更轻客户端，Celo采用递归零知识证明技术，将区块头的连接信息进行递归证明。一个证明就能证明从创世区块到当前区块的合法性。一个轻结点，只需要同步最新的证明就能确定所有区块的有效性。

• Summa (Stateless SPV)

上述的项目，还都是在降低轻客户端链上同步代价方面做优化。Summa提供了一个全新的思路：

摘抄自Summa介绍的PPT。Summa项目观察到一个有趣的事实：一条链的区块头在另外一条链上同步了，但是很多区块有可能是浪费的。原因是并没有需要证明的交易在这些区块中。Summa假设了一种“Ecnomic“安全的做法：证明一个交易在一个区块中，并且区块后有若干区块确认。Summa认为在伪造的区块后连续出块是一个非常不经济的做法，有这样的算力应该去计算真正的区块。使用这种方式，在链上不需要存储轻结点信息，只需要在一个交易需要证明时提供相应区块以及确认区块的证明即可。这样的方式也称为Stateless SPV（无状态SPV）。当然这种经济安全假设需要推敲，特别是在难度较低的情况下，伪造区块以及确认区块相对比较容易。

• Xclaim

针对传统的没有链上计算能力的链，不可能在链上实现其他链的轻客户端。也就是说，如果只是通过链上轻客户端的方式，在这些链上只能实现单向的跨链。为了在这些链上也实现双向跨链，Xclaim在引入抵押角色的情况下实现资产双向映射。Xclaim在论文中提出了三种操作：issue（发行），swap（交换），redeem（赎回）。以issue和redeem为例，看看抵押角色的作用：

大部分链都支持转账功能。抵押者作为中间人，在另外一条链（支持智能合约）有抵押的情况下，接受其他人的资金的转账。转账发起者，可以通过轻客户端验证的方式在另外链上证明交易合法。在另外一条链上，验证合法的跨链交易后，进行转账。

在一条链上提出burn操作后，抵押者观察到后，主动先发起转账。并在转账成功后，向另外一条链上的智能合约提供交易证明“赎回”资金。简单的说，在两条链只要有一条支持智能合约的基础上，通过抵押者角色，可以完成双向跨链的操作。根本原因就是链上的转账交易能够被确认验证。

总结：

跨链是个复杂的话题。通过其他共识实现跨链相对简单现实。HTLC能实现交易双方的原子操作，但是限定交易为两方，而且为了提供交易的效率需要交易双方预先沟通。通过在链上实现轻客户端验证其他链的状态是一直探索的方向。对于PoW链，链上实现轻客户端需要考虑区块头同步成本以及主链确认逻辑。