1. HTLC（HashTimeLockContract） HTLC的原理比较简单：如果Alice和Tom想要交换资产，Alice首先创建HTLC，然后Tom创建具有相同哈希的HTLC。简单来说，Tom和Alice创建了具有相同秘钥的“锁”，用于锁住各自的资产。当Alice使用秘钥打开Tom的资产时，Tom可以使用相同的秘钥打开Alice的资产。当然，Tom和Alice都需要确认资产和锁的时间。通过HTLC实现跨链交易简单且保证了交易双方的原子操作，但要求两条链都支持智能合约，并且交换的资产不可分割。事实上，为了确保交易双方有效交易，交易双方需要额外的沟通渠道预先达成共识。
2. 跨链桥：基于共识 基于其他共识的跨链桥在逻辑上比较容易实现，通过共识机制确认一条链上的事件，并在另外一条链上执行。整个桥的安全性取决于共识机制的强弱。共识机制不仅包括传统意义上的共识（如BFT、PoS等），还包括多方计算（MPC）和多签。
3. 跨链桥：基于轻客户端 为了在一条链上能够验证另外一条链上的信息，在这条链上“运行”另外一条链的轻客户端。通常，轻客户端都是基于SPV（Simple Payment Verification）协议的。SPV协议源于比特币，主要用于PoW共识机制的链中。Celo和Harmony也针对自身链的共识算法实现了轻客户端。纯粹的PoS共识机制的链相对较难实现轻客户端，因为共识机制依赖于Staking，而Staking由交易组成。为了实现轻客户端，遍历所有Staking交易是不现实的。
跨链桥的两个链通过轻客户端验证彼此链的状态。这种跨链桥依赖中继（Relay），及时同步链的区块头信息。由于需要同步区块头，需要考虑以下几个因素：
1. 同步频率和费用：在另外一条链上存储区块头信息是需要费用的，尤其是对于TPS较高的链来说，区块数较多。 2. 确认主链以及区块确认：根据链的共识机制，通过区块头信息确定主链。以PoW链为例，区块确认一般通过后续区块的数量来确定。
优化同步费用有几种思路：1. 随机挑战（NiPoPOW、FlyClient）；2. zk-SNARK（包括递归zk-SNARK）。
BTCRelay 采用传统的SPV轻客户端的实现方式来实现从比特币（BTC）到以太坊（ETH）的跨链。显然，在以太坊上同步比特币的区块头需要消耗Gas。在以太坊的Gas价格较高的情况下，同步费用较高。
FlyClient FlyClient采用随机挑战和MMR（Merkle Mountain Range）技术，降低轻客户端同步区块的数量。随机挑战的目的是在一定范围内，并不需要将所有区块同步到链上，而是随机抽取一些区块进行同步。为了在链上能够验证未被抽取的区块，所有区块的信息通过MMR进行组织。MMR是一种变种的Merkle树，适用于追加节点的场景。与普通二叉的Merkle树相比，MMR具有更新叶子节点代价小的特点。
zkRelay zkRelay也尝试降低链上轻客户端同步区块的费用。与FlyClient不同，zkRelay采用的是zk-SNARK证明。将一段范围内的区块的有效性通过将链下证明提交到链上，链上只需要检查证明的有效性。
Celo Celo是一个有趣的项目。尽管Celo项目本身与跨链没有直接关系，但它为轻客户端提供了一些新思路。为了实现更轻的客户端，Celo采用了递归零知识证明技术来证明区块头的连接性。一个证明就可以证明从创世区块到当前区块的合法性。一个轻节点只需要同步最新的证明即可确定所有区块的有效性。
Summa（StatelessSPV） 上
