关于跨链技术的分析和思考

当前的区块链底层技术平台百花齐放，不同的业务、不同的技术底层的区块链之间缺乏统一的互联互通的机制，这极大限制了区块链技术和应用生态的健康发展。跨链的需求由此而来，本文通过分析几种主流的跨链方案探讨跨链技术的本质及相应的解决思路。

一、跨链的类型

跨链交互根据所跨越的区块链底层技术平台的不同可以分为同构链跨链和异构链跨链：同构链之间安全机制、共识算法、网络拓扑、区块生成验证逻辑都一致，它们之间的跨链交互相对简单。而异构链的跨链交互相对复杂，比如比特币采用 PoW 算法而联盟链 Fabric 采用传统确定性共识算法，其区块的组成形式和确定性保证机制均有很大不同，直接跨链交互机制不易设计。异构链之间的跨链交互一般需要第三方辅助服务辅助跨链交互。

二、主流跨链机制概述

截至目前，主流的区块链跨链技术方案按照其具体的实现方式主要分为三大类，分别是公证人机制、侧链/中继和哈希锁定：

1.公证人机制（Notary schemes）: 公证人也称见证人机制，公证人机制本质上是一种中介的方式。具体而言，假设区块链 A 和 B 本身是不能直接进行互操作的，那么他们可以引入一个共同信任的第三方作为中介，由这个共同信任的中介进行跨链消息的验证和转发。公证人机制的优点在于能够灵活地支持各种不同结构的区块链（前提是公证人能够访问相关方的链上信息），缺点在于存在中心化风险。

2.哈希锁定（Hash-locking）: 哈希锁定技术主要是支持跨链中的原子资产交换，最早起源自比特币的闪电网络。其典型实现是 h 哈希时间锁定合约 HTLC(Hashed TimeLock Contract)。哈希锁定的原理是通过时间差和影藏哈希值来达到资产的原子交换。哈希锁定只能做到交换而不能做到资产或者信息的转移，因此其使用场景有限。

3.侧链/中继链（Sidechains / Relays）: 侧链是指完全拥有某链的功能的另一条区块链，侧链可以读取和验证主链上的信息。主链不知道侧链的存在，由侧链主动感知主链信息并进行相应的动作。而中继链则是侧链和公证人机制的结合体，中继链具有访问需要和验证进行互操作的链的关键信息并对两条链的跨链消息进行转移。从这个角度看中继链也是一种去中心的公证人机制。

下面就这几种跨链方式的典型实现方式进行详细分析：

 典型跨链机制实现分析

1.公证人机制

• Alice 通过交易所钱包将自己的比特币打入交易所地址;
• Alice 在交易所上挂上卖单 1 个 BTC 卖出 20ETH 价格；
• Bob 需要将自己的 ETH 打入交易所的以太坊地址；
• Bob 通过交易所挂出购买比特币的单子 20ETH 买一个比特币；
• 交易所将 Alice 的卖单和 Bob 的卖单进行撮合；
• 交易所将 Alice 在交易所存储的 1BTC 转移给 Bob 的比特币地址；
• 交易所将 Bob 在交易所存储的 20ETH 转移给 Alice 的以太坊地址；

至此完成了 Alice 和 Bob 的 BTC 和 ETH 的交换（案例中省去了交易所的服务费）。通过该例子可以看出交易所的方式目前仅能够支持资产的交换，且资产交换的原子性、安全性完全由中心化的交易所保障存在较大的中心化风险。

除此之外还有一种著名的分布式账本技术 Ripple，也是采用类似公证人的机制来解决全球金融机构之间的资产交换。Ripple 的系统架构如上图所示，Ripple 系统中交易通过网络中的验证者进行交易的验证，验证者验证的交易通过加密算法保护交易内容不能被验证着窥探从而保证交易的隐私性。

公证人机制的跨链技术实现简单，且能够比较灵活地支持不同类型的底层区块链体系。公证人机制的主要问题在于公证人机制的安全性保障完全由公证人系统保障。参与跨链的相关方需要对中间人给予较大的信任。

2.哈希锁定

哈希时间锁定（HTLC）最早出现在比特币的闪电网络，跨链资产交换支持一定数量的 A 链资产和一定数量的 B 链资产进行原子交换。哈希时间锁定巧妙地采用了哈希锁和时间锁，迫使资产的接收方在 deadline 内确定收款并产生一种收款证明给打款人，否则资产会归还给打款人。收款证明能够被付款人用来获取接收人区块链上的等量价值的数量资产或触发其他事件。

如下图所示，我们用一个例子来阐述如何使用哈希时间锁定进行跨链的原子资产交换，假设 Alice 和 Bob 有资产交换的需求，Alice 想用 1 个 BTC 和 Bob 换 20 个 ETH. 那么首先需要在两条链上设置哈希时间锁定合约，然后执行如下步骤：

• Alice 随机构建一个字符串 s，并计算出其哈希 h = hash(s) ；
• Alice 将 h 发送给 Bob 的合约；
• Alice 锁定自己的 1 个 BTC 资产，并设置一个较长的锁定时间 t1, 并设置了获取该 BTC 的一个条件：谁能够提供 h 的原始值 s 就可以得到该 BTC;
• Bob 观察到 Alice 合约中锁定了一个 BTC, 然后 Bob 锁定自己的 20 个 ETH 资产，并设置一个相对较短的锁定时间 t2 , t2 < t1, Bob 也设置了同样获取条件（谁提供 h 的原始值 s 就可以获取 20 个 ETH）；
• Alice 将自己最初生成的字符串 s 发送到 Bob 的合约里取得了 20 个 ETH;
• Bob 观察到步骤 5 中 Alice 的 s 值，将其发送给 Alice 的合约成功获取 1 个 BTC; 至此 Alice 和 Bob 完成了资产的交换。

从上述的过程我们可以看出哈希时间锁定合约有一些约束条件：

• 进行跨链资产交换的双方必须能够解析双方的合约内部数据，例如 s，例如锁定资产的证明等；
• 哈希锁定的超时时间设置时需要保证存在时间差，这样在单方面作弊时另一方可以及时撤回自己的资产。

哈希锁定的思想运用在支付领域较多，例如闪电网络、雷电网络以及跨链资产转移协议 Interledger 等。但是哈希锁定目前看只适合偏资产或者关键数据的交换，甚至不支持转移因此其试用场景受限。

3.侧链/中继链

侧链：侧链是相对于主链而言的，最初的侧链提出是针对比特币做新特性的测试和研发。侧链相对主链而言能够验证和解析主链中的区块数据和账本数据。侧链实现的基础技术是双向锚定（Two-way Peg），通过双向锚定技术可以将数字资产在主链上进行锁定，同时将等价的资产在侧链中释放。相反当侧链中相关资产进行锁定时，主链上锚定的等价资产也可以被释放。

BTC-Relay 是号称的史上第一个侧链，BTC-Relay 是通过以太坊构建了一个比特币的侧面，运用以太坊的智能合约允许用户验证比特币的交易。这里我们仍然以 Alice 1BTC 和 Bob 的 20ETH 数字资产交换为例阐述相应原理：

• Bob 将 20ETH 发送到 BTCSwap 的合约进行冻结；(该合约只要能够确认 BTC 网络上 Bob 接收到来自 Alice 1BTC 就自动将 20ETH 转给 Alice)；
• Alice 确认 Bob 冻结信息后，将 1 BTC 转给 Bob 比特币账户；
• BTC Relayer 将比特币区块头推送到 BTCSwap 合约；
• Alice 接下来就可以调用 relay tx;
• BTCSwap 合约结合 tx 和 BTC 链的区块链进行 SPV 验证，验证通过则将 20ETH 转给 Alice 以太坊地址。

这种跨链的实现方式简单，但是 BTC Relay 需要额外的信任和维护成本，且智能合约内部的数据存储会有体积膨胀的问题。但是侧链的机制相对哈希锁定而言能够提供更多的跨链交互场景，侧链以及类 SPV 验证的思想适合所有跨链的场景。

中继链：中继链本质上算是公证人机制和侧链机制的融合和扩展，目前社区内最活跃的两个跨链项目 Cosmos 和 Polkadot 采用的都是基于中继链的多链多层架构，其中 Cosmos 目前支持的是跨链资产交互而 Polkadot 则宣称提供任意类型的跨链交互，具体实现还有待观察。

为了支持平行链之间的跨链互操作，Cosmos 提出了一种跨链交互协议 IBC(Inter-Blockchain Communication protocol), 并利用 tendermint 共识算法的即时确定性实现多个异构链之间的价值和数据传输。

首先我们以 Chain A 到 Chain B 转账 10 token 为例说明使用 IBC 的跨链交互：

• 互相跟踪，也就是说如果 A 要和 B 进行跨链交易，那么 A 和 B 链需要分别运行相当于对方区块链的轻节点服务，这样互相可以实时接收到对方的区块头信息（方便后续执行类 SPV 验证）；
• A 链上初始化 IBC 协议，冻结相关资产 10 token, 并生成相应的证明发送给 B 区块链；
• B 链接收到相应的 IBC 消息，通过 A 链的区块头信息确定 A 确实进行相应的资产冻结，然后 B 链会生成等价值 10 token 的资产。

以上是使用 IBC 协议的两个平行链直接进行跨链的基本过程，如果区块链很多，那么这种方式的两两跨链复杂度会呈现组合级别增加。因此 Cosmos 网络又引入了一种 Hub 的中继链，所有的平行链都通过 IBC 连接到 Hub，让 Hub 辅助跨链交易的验证和转移，目前 Cosmos 实现了一个官方的 Hub 称为 Cosmos Hub（如前图所示）。

如下图所示是 Cosmos 网络的详细架构图 Cosmos 为方便平行链开发提供了基本服务 CosmosSDK 包括：共识、网络以及 IBC 协议等，这样基于 Cosmos SDK 开发的子链之间都能够方便地互相交互。此外对于非 Cosmos SDK 开发的区块链需要使用 Peg Zone 进行桥接，如图中的 Ethereum。

笔者认为 Cosmos 为跨链带来的最大贡献在于 IBC 协议的设计，IBC 协议提供了一种通用的跨链协议标准。IBC 的设计使得跨链交易可以在多个 Hub 之间进行安全路由和转发，类似目前互联网的 TCP/IP 协议。但是遗憾的是目前的 Cosmos 设计也只能够支持资产的跨链，而且由于不同区块链的业务不同其共识速率的不一致也会影响跨链交易有效性的证明。

Polkadot：Polkadot 也是一种集成平行链和中继链的多层多链架构，Polkadot 区块链的整体架构图如下图所示，主要包含三种角色链和四种参与方：

三种链角色：

• 中继链（Relay chain）: 中继链位于 Polkadot 的体系的核心地位，主要是为整个系统提供统一的共识和安全性保障；
• 平行链（Parachain）: 在 Polkadot 中平行链负责具体的业务场景，平行链自身不具备区块的共识，它们将共识的职责渡让给了中继链，所有平行链共享来自中继链的安全保障，中继链是 Polkadot 组成的一部分；
• 桥接链：桥接链指的是非 Polkadot 体系之外的区块链，如 Bitcoin, Ethereum， 这些区块链有自身的共识算法，它们通过不同的 Bridge 与 Polkadot 连接在一起进行跨链交互。

四种参与方：

• 验证者(Validator): 验证者负责 Polkadot 的网络出块，会运行一个中继链的客户端，在每一轮区块产生中会对其提名的平行链出的块进行核验。当平行链的跨都被他们的子验证者集合确定好之后，验证者们会将所有平行链区块头组装到中继链的区块并进行共识。
• 核验人(Collator): 帮助验证者收集、验证和提交备选平行链区块，维护了一个平行链的全节点。
• 钓鱼人(Fisherman):钓鱼人主要靠检举非法交易或者区块以获取收益；
• 提名人(Nominator): 拥有 stake 的相关方，维护和负责验证者的安全性。

Polkadot 的特性包括两个，一个是共享安全性，一个是不需信任的跨链交互。这里的不需信任的跨链交互其实是和第一个特点共享安全性密切相关的，而且 Polkadot 的不需信任的跨链交互也主要是只其内部的平行链之间。

在 Polkadot 中如果 parachain A 需要发送一笔交易到 parachain B 的过程如下：

• A 链将跨链交易放到自己的 engress(每个平行链有一个消息输出队列 engress 和一个消息输入队列 ingress);
• A 链的 Collator 收集 A 链的普通交易以及跨链交易并提交给 A 链的验证者集合；
• A 链的验证者集合验证成功，将本次 A 链的区块头信息以及 A 链的 engress 内信息提交到中继链上；
• 中继链运行共识算法进行区块确认以及跨链交易路由，中继链上的验证者会将 A 链的相应交易从 A 链的 engress queue 中移动到 B 链的 ingress queue 中。
• B 链执行区块，将 ingress queue 中相应交易执行并修改自身账本。

以上便是 Polkadot 跨链交易的主要步骤，由于所有平行链的共识同步发生（中继链区块示意图如下），因此跨链交易不会有诸如双花等安全性问题。

Polkadot 的平行链之间的跨链交换的安全性保障主要来自共享安全性这个特点，共享安全性使得跨链交易和普通交易同步发生也就不存在其他跨链场景中的双花等跨链数据不一致问题。其次 Polkadot 中的引入的特殊状态验证方法方便中继链进行跨链等消息的有效性验证。

值得一提的是 Polkadot 项目目前还处在项目初期，对于 parachain 的设计、Collator 的协作以及 Validator 的共识、工作效率等都未完善。这种共享安全性的方式是否也限制了平行链自身的性能都还有待考证。

  关于跨链技术的几点思考：

综合以上的一些主流跨链场景和方案的分析，从跨链的概念以及需求上看跨链的本质其实就是如何将 A 链上的消息 M 安全可信地转移到 B 链并在 B 链上产生预期效果。那么一个成功的跨链交互到底需要解决哪些问题呢？笔者认为主要有以下四个问题：

• 消息 M 的真实性证明，也就是说 M 是否确实是存在 A 链上的，也确实是 A 链发给 B 链的；
• 消息 M 的路由，如何让跨链消息安全跨系统路由；
• 消息 M 的有效性证明，这里的有效性是指来自 A 链的消息 M 如何让 B 链认可其抵达 B 链时状态仍然有效，比如转移的资产是否是冻结的，没有双花的，如果是状态那么是否在此期间未发生改变等；
• 消息 M 的执行结果证明，这个是指 A 链需要确认跨链操作是否成功，以及成功操作的相应回执。

那么针对这些关键本质问题，如何去处理呢？笔者设想未来的区块链应该在底层平台的设计之初就需要遵循统一的跨链协议标准，就像现在的操作系统对 TCP/IP 协议的支持一样。需要进行通用跨链的区块链至少要支持一下功能：

• 提供跨链消息的输入和输出口径，例如 Cosmos 和 Polkadot 的跨链队列；
• 提供跨链消息的真实性证明，区块链需要提供类似 SPV 的证明手段；
• 消息的有效路由需要构建跨链消息的统一格式，定义好消息的来源和去处以及消息内容，如 Cosmos 的 IBC 协议；
• 消息的有效性证明，区块链可能需要设计新的类似 UTXO 的可验证存储结构，方便做类 SPV 类验证，否则目前的基于 KV 的数据存储方式做有效性证明几乎不可能；
• 跨链执行结果证明，和有效性证明类似，需要全新的数据结构和运行算法支持。
• 除此之外，跨链系统的设计还需要考虑系统稳定性、可扩展性以及易升级性、容错等等，总而言之，真正的可信互联网建设艰辛漫长，诸君共勉！