本报告由火币区块链研究院出品，报告发布时间2018年10月15日，作者：袁煜明、李慧、钟维
摘要
跨链狭义上指的是相对独立的区块链账本间进行资产互操作的过程。火币研究院本次主要在狭义范畴内剖析了跨链的设计原则、技术难点及其解决方案；并辅以8类应用场景介绍、10个项目的跨链原理阐述以及22个项目整体概况、技术开发和社群建设等维度数据分析，深度刻画了跨链产业全景图。
跨链的实现形态主要表现为资产互换和资产转移，业界已有落地应用，且多种跨链应用场景均可以由此演变。本文将重点阐述两者的跨链原理，从问题出发，提出了5大技术难点并介绍了其对应的解决方案和思路。
1）如何保障跨链交易的原子性：介绍了原子互换和哈希时间锁协议原理。2）如何完成对另一条链的交易确认：介绍了公证人、中继以及榫卯式三大类模式异同。3）如何保障两条链的资产总量不变：从正常和异常两种情况分别阐述了应对方案。4）如何保障两条链的独立安全性：主要从隔离机制和安全检测机制分析了应对思路。5）如何实现多条链之间的跨链互联：介绍了主动兼容和被动兼容两种跨链网络建设方案。
最后对于跨链产业现状和未来，我们认为：1）跨链项目总体处于探索阶段，未有大规模应用；2）跨链技术成熟度较低，仍有较大发展空间；3）跨链的推动依赖于区块链应用的实质性落地；4）跨链网络将推动数字资产金融的繁荣；5）跨链标准的建立将会是区块链行业发展的强劲引擎。
*由于文章篇幅较长，分上下篇推送，跨链篇（上）包含第一章至第三章的内容。
第四章至第六章的内容，请搜索【火币区块链产业专题报告】跨链篇（下）
第一章 跨链概述
1.1 何为“跨链”
跨链，狭义上来说是两个相对独立[1]的区块链账本间进行资产互操作（Interoperability）的过程；广义上来说是两个独立的账本[2]间进行资产、数据互操作的过程。本文主要是从狭义上来阐述区块链体系之间的跨链互操作问题。
传统信息领域对于互操作的定义为：“不同系统或模块之间进行信息交互和使用的能力” [19]。而Vitalik在《Chain Interoperability》[2]的论文中提到，区块链的互操作主要指的是两条区块链之间进行资产转移、支付或者信息交互的能力，而这些通过引入第三方并且在不改变原生链的前提下是可以做到的。
单一的区块链网络是一个相对封闭的体系，不会主动与外界发生交互，每条链的资产也都是一个独立的价值体系而存在。若是能打通链与链之间的孤岛，让价值在更广大的世界中流通，那必然能从更广阔的范围中增加通证资产的价值，从而推动区块链产业的快速发展。跨链技术正是致力于搭建链与链之间的信任桥梁，打破一链一孤岛的局面，实现链与链之间的资产互操作，以期实现真正的共赢。
[1]指两个区块链账本间相互独立，没有在某方统一进行清/结算的情况（交易都在母链账本进行清算的母子链结构不存在本文所述的跨链操作）
[2] 此处所指的账本不仅指的是区块链账本，也指中心化账本或者其他形式的分布式账本（如DAG账本）。
1.2跨链意义何在
在阐述跨链意义之前，不妨先回顾一下计算机网络的发展历程，也许会对我们有重要启示。1969年投入运行的阿帕网是计算机网络的鼻祖，当时由于大部分计算机互不兼容，且传输速度极慢，计算机网络多以局域网的形式存在，彼此难以连通。直到80年代TCP/IP协议（一种可支持多种底层协议以及异构网络互连协议）逐渐成熟，计算机网络才逐渐被建立起来。到90年代，互联网面向公众开放，以及网络浏览器的出现，才带来了现在互联网的繁荣。
从计算机网络的发展历程，我们仿佛也看到了区块链跨链网络的未来。目前的区块链世界就好比60年代的单机时代，链与链之间高度异构化，彼此难以互通，所有的数据和服务都局限于孤岛式的区块链中。若是未来，所有的区块链系统能通过某一标准化跨链协议链接起来，那众多的区块链系统就能协同工作，为更多的用户、更多的服务提供支撑。跨链技术的成熟与普及或将引爆区块链网络的繁荣。不同的是：互联网是信息自由流通的网络，而区块链跨链网络则是价值自由流通的网络。
1.3跨链进化史
如下图所示，自2009年比特币网络问世后的很长一段时间，到2012年Ripple才发布了跨账本互操作协议《Interledger Protocol (ILP)》，通过第三方公证人的方式实现了跨账本转账，在区块链领域首次提出了跨账本互操作方案。2014年，由比特币核心开发人员组成立的BlockStream团队首次提出锚定式侧链（Pegged Sidechains）跨链交互方案，引入一条与主链双向锚定（Two-way peg）的侧链，可实现跨链资产转移。2015年比特币闪电网络（Lightning Network）采用哈希时间锁（Hashed Timelock）机制，实现了比特币链下快速交易通道。2016年BTCRelay方案发表，基于中继跨链方案实现了比特币到以太坊的单向跨链连通。同年Vitalik Buterin发表的《Chain Interoperability》对区块链互操作问题做了全面和深度的分析。2017年，Polkadot和Cosmos第一次提出了建设跨链网络基础平台的方案，目前这两个项目还在开发过程中。
第二章 初识跨链
2.1 跨链的实现形态
我们知道，目前的区块链公链是一个自适应分布式系统，也是一个相对封闭的自循环系统，虽然可以允许新节点加入、旧节点退出，也可容忍一小部分错误，但却难以兼容外部其它系统。链和链之间的信息交互，尤其是以通证为载体的价值交互，可谓困难重重，这对区块链网络来说是一大发展瓶颈。
总体来说，链和链之间的价值/数据交互主要有以下两种实现形式：
1） 链间资产互换：通常指两条链上的不同用户之间进行资产互换，但每条链上的资产总量并无增减，只是资产所有权发生了变化，且这个所有权改变的过程需在两条链同步发生。如Alice想用比特币上的10个BTC换Bob在以太坊的100个ETH，最终交易成功的结果是Bob 在以太坊的100个ETH转移到了Alice在以太坊的地址，而Alice在比特币上的10个BTC转移到了Bob在比特币的地址。比特币和以太坊资产总数并无增加或者减少。
2） 链间资产转移（单向/双向）：资产转移和资产互换虽看起来相似，却有本质的不同。上文所述资产互换中各链的资产总数是不变的，但资产转移，是资产价值的转移，各链中可用的资产总量将相应增加或者减少。如Alice想将链A的资产转移100枚到链B，最终交易成功的结果是链A的可用资产将减少100枚（减少的100枚被冻结在链A的特定地址），B链上将新生成相应的等价资产。
目前对跨链的研究和应用落地主要是集中在资产互换和资产转移这两种方式。有些项目提出了跨链智能合约的概念，多指一条链上的智能合约能确认原链跨链交易的场景，这从技术实现上来说和实现跨链资产转移是相似的，都需要对原链交易进行确认和验证，因此本文不再做单独讨论，而主要针对资产互换和资产转移这两类问题进行技术方案分析。
2.2实现跨链要解决的问题
我们知道，区块链的特点之一就是账本的不可篡改性，因此写入账本的信息需要是准确无误的，特别是资产信息，一定要精确无误。两个区块链系统进行资产信息互换，也需要保证在交换的过程中资产和信息数据要精确记录在彼此的账本上，要做到这一点是非常不容易的。要实现跨链，我们需要解决的问题很多，但是总结起来看，以下几个问题是最核心的：
1）如何保障跨链交易的原子性。即跨链交易要么发生，要么不发生，否则两条链的不一致和不同步状态将成为跨链交易最大的系统漏洞，两个系统的安全性都将受到威胁。这一点是实现跨链交易的基本要求，也是跨链交易必须要解决的难点。
2）如何完成对另一条链的交易确认。对交易的确认，包含了两个层次的问题，一是确认交易已经发生并且上链，写入了区块账本；二是该交易已经获得了系统足够多区块的确认，这样由于系统发生重构而导致交易无效的概率将非常低。区块链系统本身是较为封闭的系统，缺乏主动获取外部信息的机制，因此要确认另外一条链的交易状态并非一件容易的事，可以说是跨链交易的核心难点之一。
3）如何保障两条链的资产总量不变。在资产互换的场景下，两条链的资产并未发生实质性的交换，因此该类情况不会改变各链的资产总量。但是在资产转移的场景下，每条链的可用资产数量是变化的，只有保障跨链交易精确记账，且两条链的账本记账完全同步，才可实现，换种说法就是两条链的记账必须是原子性的，要么都同时记，要么都不记。除此之外，问题的关键是当某条链发生重构时，是否依然能保持两条链的资产总量不变。
4）如何保障两条链的独立安全性。当两个系统发生交互时，难免会对彼此系统产生影响，如何在跨链交易的过程中保障自己系统和对方系统的安全性是个值得考虑的问题。若是安全性问题无法隔离，那一条链受到攻击，将影响整个跨链网络。
5）如何实现多条链之间的跨链互联。参照计算机网络的发展历程，独立的区块链网络终究要走上互联互通的未来，那如何将这些已有的和未来将要开发的区块链网络都联系起来成为统一的整体将是未来跨链网络最重要的问题之一。
2.3跨链协议设计原则
基于上文对实现跨链网络难点的分析，在设计一个支持跨链的体系时，可以参考以下原则[1]，若是以下几点无法实现，则该跨链系统的安全性和稳定性是难以保障的。
1.资产在链之间的转移是自由的，既可从A链到B链，也可从B链到A链，且与谁拥有这些资产无关。
2.资产转移不能有对手方风险，没有第三方能阻止资产的转移。
3.转移交易必须是原子性的，要么发生，要么不发生。不能存在凭空损失或者创造资产，也不能有欺骗交易的发生。
4.跨链协议或系统应该具备防火墙的功能，一个链发生的资产丢失和创造不会影响另外一个链。
5.一条链的重构不能影响另外一条链，要么在重构概率非常低时再完成资产交易，要么在重构发生时能同步修改/作废之前发生的跨链交易，或至少做一些补偿性的操作。
第三章 跨链难点解决方案剖析
3.1难点一：如何保障跨链交易的原子性
3.1.1原子互换
原子互换[1]是保障跨链交易原子性的基础理论框架。原子互换，即原子性的互相交换。原子性是计算机领域非常重要的设计理念，如原子交易，原子操作等，通常指最小单位的操作，该操作要么成功，要么失败，不存在第三种中间状态。
为更直观的介绍原子互换协议，我们假设一个交换场景,通过例子来理解原子互换协议的原理。
1) Alice在链A上有1个BTC，Bob在链B上有20个ETH，Alice想用1个BTC换Bob的20个ETH。Alice和Bob同时在链A和链B上都有钱包地址。
2) 首先Alice随机生成一个密钥K，该密钥只有Alice知道，然后在链A上发起一笔给Bob 1个BTC的转账交易（交易①），该交易只有在获得Bob的签名以及提供密钥K之后才能完成。
3) 在交易①广播之前，Alice会先在链A上广播一个回撤交易（交易②），若交易①在48小时内未获得正确的密钥和签名，那么交易①支付的金额将退回给Alice。交易②广播出去后需获得Alice和Bob的共同签名，该交易才会生效。同时，Alice只有在交易②成功生效的情况下才会向网络广播交易①。
4) Bob此时看到Alice发来的交易②，若Bob愿意进行这次交易，则Bob会对交易②签名，当然Alice也会完成签名，这样回撤交易就能生效，Alice此时将交易①向全网广播。
5) Bob此时无法得知密钥K，只能通过向Alice支付20个ETH后才能获得密钥K，因此，Bob在链B上发起交易③，向Alice支付20个ETH，只有当Alice输入密钥K成功解密，并附上Alice签名才可获得这20个ETH。为防止Alice抵赖，保障自己能成功拿到密钥K，Bob也在广播交易③之前先发布一个需要Alice和Bob共同签名的回撤交易④，当Alice在24小时内未提供正确的密钥K并附上签名，就激活回撤交易④，20ETH退回给Bob。
6) Alice看到Bob发起的回撤交易④，Alice和Bob为了继续交易将会给该交易附上自己的签名，回撤交易④生效。此时Bob也会将交易③广播给全网。
7) Alice为了获得20ETH，将会对交易③附上自己的签名，并且输入正确的密钥K，此时交易③成功，Alice获得20ETH，Bob获得密钥K。
8) Bob拿到密钥K后，回到链A，输入密钥和自己的签名，最终拿到Alice的1个BTC。
由上过程可知，原子互换协议并未将链A的资产转移到链B，而只是同时交换了链A和链B资产的所有权，链A的资产总量和链B的资产总量并未改变，因此原子互换协议只能实现链间的资产互换，无法实现资产转移。
原子互换是系统之间进行价值原子交易的基本框架，不仅可应用于区块链去中心化账本系统之间，还可扩展到中心化账本的系统之间，只要两个系统能提供回撤交易、时间锁定和密钥锁定的功能即可。
3.1.2 HTLC，哈希时间锁协议
哈希时间锁协议，即HTLC（Hashed Time-Lock Contract）,是原子互换协议的具体实现，通过哈希锁和时间锁机制保障了交易的原子性。在不同的系统里，不管是区块链系统还是中心化的账本系统，其实现哈希锁和时间锁的方式都不尽相同，但原理是一样的，即只有满足一定的哈希条件或者时间条件后才允许交易生效。
若只使用哈希时间锁，只能实现跨链的资产互换，而非跨链资产转移，各链的资产总量不变，只是资产的持有者发生了变化而已。如果要实现资产的跨链转移，除了需要哈希时间锁保障交易的原子性，还需配合其他跨链技术，确保跨链交易的真实性，即2.2小节所述的需完成对其它链的交易确认。
哈希锁
在2.1.1小节介绍的例子中，Bob要如何验证Alice提供的密钥K是正确呢?这里最通常的做法是用哈希函数来实现。Alice在最开始的时候产生一个随机数K（即密钥K），用一个哈希函数对该随机数做计算得到M,即H(K)=M，Alice会将函数H和M告诉Bob，我们知道哈希函数的计算是不可逆的，几乎无法通过H和M反向计算得到K。所以Bob只能让Alice主动披露一个密钥K’，并用H和M来验证Alice提供的K’是否能通过哈希函数H计算得到M，若验证通过，则证明Alice提供的K’就是真实的密钥K。这种哈希函数锁定的方式就是我们所说的哈希锁，只有密钥K才能打开的锁。在比特币系统中通常用OP_HASH256操作符来进行哈希计算操作。
时间锁
在2.2小节介绍的原子互换协议中，需要交易在某个时间范围内不生效，如回撤交易需要在超时以后再被触发。时间锁在比特币系统中有两种实现方式[3]。
1) CheckLockTimeVerify（CLTV）
比特币2015年BIP65的软分叉版本中提出了CLTV操作码，允许交易的输出在一段时间内被阻塞（交易的其它部分不受影响）。当CLTV操作码被调用的时候，会检测交易中的nLockTime参数，只有当nLockTime的时间大于或者等于CLTV参数指定的时间时，交易才会被完整执行，否则交易会被阻塞在memory pool中。
nLockTime是比特币交易最原始的参数类型，表示了该交易可最早被写到区块上的时间，或者是最小可写入的区块高度。nLockTime设置为0，表明该交易写入任何一个区块都将有效。
2) CheckSequenceVerify（CSV）
比特币2016年BIP68/112/113软分叉时提出了CSV操作码，相对于CLTV提出的绝对锁定时间来说，CSV提出的是相对锁定时间。当执行CSV操作码时，系统会检查NSequence参数，若其表示的相对时间大于或者等于CSV参数的时间，则交易开始执行；否则交易会被阻塞在memory pool中。
Relative Locktime是2016年BIP68/112/113软分叉提出来的，参数由nSequence表示，是交易输入域参数的一种，表明了该交易最早能被写入区块的时间，该时间是相对于上次UTXO写入区块的时间而言的。
3.1.3 HTLA，哈希时间锁协定
哈希时间锁协定[4]，即HTLA（Hashed Time-Lock Agreements）是Interledger[10]提出的HTLC泛化协定，不管系统是否支持HTLC协议，不管其是分布式账本还是中心化账本，系统和系统之间都能使用HTLA实现跨链交换，且支持多个系统之间的多跳跨链互换，如下图所示。Alice和Bob可以通过HTLA在区块链A、B、C之间进行跨链交换，且每一种区块链都支持不同的跨链协议，连接器在这其中起到了连接、隔离的作用，将支持不同跨链协议的区块链连接到一起，并且又起到了隔离的作用，使得区块链之间不会相互影响。例如，链A和连接器1的交易失败不会影响到其它链(而Interledger这种连接器的设计也是公证人机制的典型代表,详情可参考4.2小节对Ripple的介绍)。
HTLA支持多种基于HTLC的跨链协议，主要的几种如下文所述。
1）有条件的支付通道（Conditional Payment Channels）
对账本的功能性需求：支持支付通道的HTLC更新
对账本的非功能性需求：支持高速交易
交易风险：无
使用案例：闪电网络[5]
协议简介：支持有条件支付通道协议的系统，交易参与者需要在账本上预付一笔资金到一个双方共享的临时账户。当交易开始时，发送者会发送一个带有哈希锁和时间锁以及附带签名的更新到接收者。若接收者能在超时前反馈哈希锁的原像，则其可从临时账户中赎回资金，并且发送者接收者同时签名确认共享账户的余额变动。当发生争议时，账本将依据账本信息进行判断和仲裁。由于交易的传输和处理时间会被计算在超时的范围内，所以该种协议更适合支持高速交易的账本系统。
2）On-Ledger持有/托管
对账本的功能性需求：支持HTLC交易
对账本的非功能性需求：支持高速、低费用和高吞吐量
交易风险：无
使用案例：以太坊第三方托管合约[6]、Ripple第三方托管[7]
协议简介：当账本支持HTLC协议时，并且该账本交易速度快、费率低、吞吐量高，那么参与者之间可以直接通过HTLC协议发起跨链交易。交易发起者将要传输的资金先放到账本提供的特定持有账户中，并且附带哈希锁和时间锁，只有当接收者在超时前能提供正确的哈希原像，账本账户才将资金发送给接收者，否则账本将会把资金退回给发送者。这种方式可由账本负责全权控制交易状态，交易双方没有额外的风险。
3）简单支付通道（Simple Payment Channels）
对账本的功能性需求：支持无条件的、单向支付通道
对账本的非功能性需求：无
交易风险：有交易对手风险
使用案例：比特币CLTV通道[8]、Ripple PayChan[9]
协议简介：简单支付通道是建立的off-chain交易通道，无论账本交易速率如何，链下的通道可支持大规模快速交易。在建立单向通道时，发送者需要将资金存入链上和接收者共享的临时账户中，只有当双方对交易金额的数量和转移方向都同意且同时签名时，该账户的资金才可被取出。发送者传给接收者的是一个带哈希锁和时间锁的消息，当接收者在超时前提供了正确的哈希原像，发送者再发起一个新的带有签名的申明给接收者，使得接收者能接收到全部的交易金额。
在这种事后支付的情况下，接收者将承担较大的风险，他必须信任发送者，否则出现争议后，将无可信第三方进行仲裁。接收者控制风险的方式就是尽量控制交易金额，因此该种方式适合小额快速交易的场景。不过接收者也可以通过让发送者提前预付资金的方式，将交易风险转移给发送者。不过这种方式会使得系统变得复杂，因为一旦交易发生回滚，接收方需要重新建立单向支付通道，向发送方退回资金。
3.2难点二：如何完成对另一条链的交易确认
我们知道，一个区块链系统相对另一个区块链系统来说是封闭和独立的，系统和系统之间未知，也不兼容，他们之间并没有直接的沟通渠道，那发起跨链交易的时候要如何才能确认发送链的交易真的发生并且被它确认了呢？既然两条链是相互独立的系统，所以无论如何演变，两条链之间总会出现一个“中间人”的角色，承担了为两条链进行信息交互的角色，只不过在具体实现时这个“中间人”的角色有很多种演化的可能性。“中间人”可能是一个也可能是一群，可能是中心化机构也可能是分布式群体，两条链的中间人可能是同一个/组节点，也可能不同，甚至这个“中间人”可能是一条独立的链或者又只是一个功能模块而已。“中间人”通常会同时充当两个区块链的节点，这样只需在同一节点上再部署一个应用软件获取对方系统数据即可。
在交易确认这个问题上其实隐含了三层意思，第一层含义是跨链数据传递，即需要获取/收集发送链的数据，为交易确认做好准备；第二层含义是发送链对交易的确认，即发送链的交易并不是只要写入区块就能最终确认的，我们知道比特币的交易要等待6个区块才能大概率确认，否则可能较大概率发生区块重构的现象。发送链对交易确认的方式主要取决于其共识算法，不同的算法，对交易确认的方式和时间都不相同，跨链交易的速度也很大程度上受制于发送链的交易确认速度。第三层含义是目标链对发送链已经确认过的交易再次核实，即需要依据收集到的数据来做确认，到底发送链声称的跨链交易是否发生，以及交易是否得到最终确认。
“中间人”基本上完成了前者数据收集的工作，那交易如何确认，在哪确认，以及由谁来确认成为了问题的关键。根据不同的方案，我们可以将该过程主要概括为三种实现方式，即公证人模式、中继模式和榫卯模式。
公证人模式是最为简洁的设计，即“中间人”不仅进行数据收集，还进行交易确认和验证。此时的“中间人”将成为可信第三方，可以是一个双方可信的中心化机构，也可以是一群节点。其验证交易是否正确的过程又将有多种演化，主要分为三种：单签名公证人机制、多签名公证人机制以及分布式签名公证人机制，详情可见3.2.1小节介绍。
中继模式中，“中间人”仅仅充当数据收集者的角色，并将收集的数据转发给目标链，由目标链依据收集的数据去完成交易确认的工作。中继模式是个相对去中心化和松耦合的方式，两个链之间的设计和结构是较为独立的，因此也具备了更高的可扩展性。“中间人”更多地充当了中继桥梁的角色。详情可见3.2.2小节介绍。
榫卯[3]模式表述的是一种通过数据强耦合关系来实现跨链互操作的模式。链A和链B通过“中间人”收集到对方的数据，并且将对方的数据纳入到自己的区块链体系中来。这种纳入不一定是记录到自己的区块中，有可能是记录到自己系统中的存储空间。但无论是哪一种方式，这都是一种强耦合的设计，双方要在系统设计之初就做好彼此关联的体系设计。若链A是已经存在的区块链，那链B要么只能单向嵌入链A，要么链A就要进行相应的升级改造。这种强耦合的结构通常用于侧链的设计中。详情可见3.2.3小节。
[3]榫卯（sǔn mǎo），是古代中国建筑、家具及其它器械的主要结构方式，是在两个构件上采用凹凸部位相结合的一种连接方式。凸出部分叫榫（或叫榫头）；凹进部分叫卯（或叫榫眼、榫槽）。本文用来特指一种采用强耦合数据结构实现跨链的技术模式。
这三种方式只是概念上较为宽泛的分类，便于大家更好理解，在实际应用过程中会更为复杂，可能会多种方式结合在一起使用。在理解跨链的技术原理时不必拘泥于模式的定义，而是要充分理解其如何实现对原链交易的确认，即数据如何传递，原链交易如何确认，接收链对原链交易如何验证即可。
3.2.1公证人机制
由上文可知，公证人机制（Notary schemes）[2]在解决发送链交易确认这件事情上，在结构上是相对简单和易于理解的方式。即有一个或一组节点能作为相对独立的角色参与到对双方交易确认的事件上来。总体说来有三种方式，一是中心化/单签名公证人机制，二是多重签名公证人机制，三是分布式签名公证人机制。
1）中心化公证人机制（Centralized Notary schemes）
中心化公证人机制也叫单签名公证人机制，通常由单一指定的独立节点或者机构充当，这是最简单的模式，通常，这种模式被用于某类单一或特定的交易。如下图所示，与其Alice和Bob两个陌生人直接交易，不如两者都和有信用背书的第三方机构间接交易更可靠（如支付宝模式）。由于Alice和Bob存在于不同的账本系统，所以，公证人在技术上需要同时兼容两个或者多个系统。其进行跨链交易的基本原理如下图所示。
1. Alice将账本A上的资产M转入公证人在账本A上的账户；
2. 此时，Bob也将账本B上的资产N转入公证人在账本B上的账户；
3. 公证人分别在账本A和账本B上确认资产M和N已分别到了公证人所在账户，则公证人在账本A上将资产M转交给Bob，同时在账本B上将资产N转交给Alice；
4. 这样，Alice和Bob就分别在账本B和账本A上收到了跨链资产N和M。
公证人在该交易过程中充当了交易确认者和冲突仲裁者的角色，从某种程度上来说，用中心化机构替代了技术上的信用保障，从技术可信转移到了传统的信用中介。这种模式虽然交易处理速度快，兼容性强，技术架构简单，但中心节点的安全性也成为系统稳定的关键瓶颈。
2）多重签名的公证人机制（ Multi-sig Notary schemes）
多重签名的公证人机制是由多位公证人在各自账本上共同签名达成共识后才能完成跨链交易。公证人的选取可以有多种方式，比如1）随机抽取公证人；2）对交易双方可信公证人节点列表求交集；3）直接采用可信联盟中的可信节点等。
多重签名的公证人组的每一个节点都拥有自己的一个密钥，只有当达到一定的公证人签名数量或比例时，跨链交易才能被确认。这种方式相较于单签名模式的安全性更高，少数几个公证人被攻击或者是作恶都不会影响系统的正常运行。但是这种方式要求两条链本身都要有支持多重签名的功能。
比如，比特币的DMMS动态成员多签名机制（Dynamic Membership Multi-party Signature）就提供了多签名模式。DMMS对签名者的数量没有要求，是一个动态的签名者集合，POW的挖矿机制以及比特币区块头的数据结构允许矿工自由加入签名，并且签名的权重和矿工的算力成正比，这样不仅能避免女巫攻击也能一定程度上解决拜占庭将军难题[12]。在联盟链中，多签名的集合数量通常是固定的，且采用的是传统的多签名模式，这种多方集中参与的模式能尽可能保障交易的一致性和完整性。
强联盟模式（Strong Federation）[11]下的联盟式锚定侧链（Federated Pegged Sidechain）是多重签名公证人机制的典型应用场景，如Blockstream开发的Liquid项目就是代表应用，详见4.3.2小节介绍。
3）分布式签名的公证人机制（ Multi-sig Notary schemes）
分布式签名的公证人机制和多重签名的公证人机制最大的区别在于签名的方式不同，采用了多方计算MPC（Multi-Party Computation）的思想，分布式签名相较于多重签名，安全性更高，但实现也更复杂。
如上图所示，分布式签名基于密码学技术，关键点在于，对于跨链交易，系统有且仅产生一个密钥，而且公证人组中谁都不会拥有完整的密钥，密钥是以碎片的形式随机地发送给每一个公证人节点，且碎片是经过处理后的密文，因此即使所有公证人将碎片拼凑在一起也无法得知完整的密钥，全面地保障了密钥的安全性。
门限多方计算，允许一定比例的公证人进行签名，换句话说，它能保障满足一定比例的公证人就能拼凑出完成的密钥。这种方法更灵活，也更安全，当少数节点遭受攻击时或发生各种错误时，并不会影响整个系统。
小结
公证人机制模式简单，更易于和对现有区块链系统进行对接，其较为中心化的处理模式也能带来更高的处理效率，并能较好地保障跨链交易的一致性。但其可信人的设定也同样会带来很多问题。1.公证人即便是以公证人组的形式存在，其数量也是有限，通常不会很多，是较为中心化的组件，风险更集中，更易成为黑客的攻击目标，从而影响账本的安全性。2.公证人节点的密钥丢失、不在线、宕机、被迫作恶等等情况将会让跨链交易陷入停滞或置于较大的安全风险中。3.去中心化账本只要有参与者存在就能永远存续下去，但中心化的公证人是否能和账本系统一样永续存在，是极大的挑战。
针对这些问题，业界也提出了很多的解决方案，比如说多重签名和分布式签名的方案，弱化了中心化组件的特性，从多种角度提高了系统安全性。
3.2.2中继
中继（Relay）是更灵活、易于扩展的跨链技术，其不依赖可信第三方帮助其进行交易验证，而是在拿到发送链数据后由接收链自行验证，自行验证的方式依据系统结构不同而不同，例如BTC-Relay依赖于SPV证明（如下文SPV小节所示），Cosmos还依靠验证节点签名数量等。
Vitalik在其互操作性论文[2]中提到Relay，指出链A和链B可通过对方的区块数据来进行信息同步和跨链函数调用，目前信息同步是可以做到的，但是跨链函数调用还没有成熟的技术方案。但两个链不能同时验证对方区块的有效性，否则将陷入互为嵌套的死循环。如链A拥有链B的区块数据，则链A需在链B交易确认的情况下才能进行确认，而链B因为同时拥有链A的区块数据，链B又需等待链A的交易确认，……,这样，交易确认就陷入了死循环。
中继模式看似简单，但实现形式却是多种多样，如Cosmos中的Hub、Polkadot中的Relay chain（中继链）、BTC-Relayer中的Relayer、比原链中的中继器XRelay[17]等都充当了中继的角色，一些侧链[4]的实现也采用了中继的模式，下文将介绍几种常用的中继实现方案。
[4]侧链表达的是两条链之间的关系，并不是特指某种跨链技术或方案，详情参见4.3小节对侧链的定义。
1）BTC-Relay
2016年Consensys团队推出的BTC-Relay是最经典的中继（Relay）跨链方案，实现了以太坊和比特币之间的跨链交易，使得以太坊的DApp应用可以支持BTC支付。由于比特币的脚本是非图灵完备的，难以支持复杂的应用，因此BTC-Relay只实现了从比特币到以太坊的单向跨链。比如以太坊中的某游戏应用需要支付ETH购买游戏道具，但用户只有BTC没有ETH，这时游戏就可以调用BTC-Relay智能合约，确认该用户确实在比特币网络进行了相应的转账支付交易，就可在以太坊的游戏中给该用户发放相应游戏道具。
如上图所示，BTC-Relay本身为以太坊的一个智能合约，该合约的功能就是对比特币上的某些交易进行验证，并且提供验证信息给以太坊上的其它DApp用户。Relayer是从比特币获取区块头数据的一群用户，并拥有以太坊网络的账户地址，最快向BTC-Relay合约提交区块头数据的Relayer可以得到以太坊的交易费奖励。BTC-Relay智能合约获得区块头数据以后就可以依据SPV证明的原理对某交易进行验证，当比特币网络中的某交易确实发生，则可触发以太坊网络的特定交易或者智能合约执行。
2）SPV证明
SPV，Simplified Payment Verification，即简单支付证明，其中，“支付”是关键字，即该种证明只是对是否发生支付行为做验证，而不是对“交易”做验证。这两者有本质的不同，一个是验证交易是否发生，一个是验证交易是否合法正确。
本小节将以比特币为例介绍SPV证明的原理，如下表所示为比特币区块的数据结构，下图为比特币区块数据结构示意图。我们知道比特币一个区块的大小为1M，而区块头只占了80个字节（Byte），交易列表则占用了区块中的绝大部分空间。SPV的基本原理就是在只有区块头数据的情况下验证某交易是否发生，这样既方便快速也节省了大量的存储空间。
如下图所示，区块中的交易是以Merkle[13]树的形式存储的，交易为树的叶子节点，交易的Hash值通过层层Hash计算生成了Merkle根哈希，该Merkle树中任何一个节点发生了变化都会让根Hash值发生变化，因此也能用Merkle根哈希来代表这一区块中所有叶子节点的交易。
为了通过区块链头数据来验证某交易是否已发生，可以按照如下的步骤进行：
1．下载区块中最长链的区块头数据
2．计算该交易的哈希值，得到Tx_hash;
3．通过Tx_hash索引定位到包含该交易的区块
4．为验证该交易是否存在于该区块中，需重新计算与该交易相关的哈希值，直到根部，并将计算得到的哈希值与区块头中的Merkle根哈希进行比较；若一致，则表明该交易确实发生并存在于该区块中；若不一致，则说明该交易并未被打包到最长的链中，即未被验证确认。
关于步骤4，可用验证交易3的例子具体说明一下。为了验证交易3，系统会从全节点中获得交易3生成Merkle根哈希的路径：该路径为交易3->H(3) ->H(3,4) ->H(12,34) ->H(1-8) ->Merkle根。同时下载该路径上相邻节点的哈希值，如会获取H(4)、H(1,2)、H(56,78)节点的哈希值。然后再按照交易3计算的哈希值与相邻节点哈希计算得到Merkle根哈希，以此于区块头中的Merkle根哈希进行比较。
3.2.3榫卯[5]式
榫卯式是一种强耦合结构的跨链模式，通过某种方式直接将原链的部分数据嵌入到自己的区块或者存储空间中。在进行跨链交易时，直接通过本系统存储的原链数据便可完成交易验证。这种方式一般在系统设计之初就进行了双向考虑，通常用于主链+侧链的设计中，多采用协同挖矿模式，如下文所述的Aelf主链+侧链的架构。若主链已经存在，则侧链通常是单向锚定主链，即侧链锚定了主链的数据，但主链却无法识别侧链状态。
[5] 榫卯（sǔn mǎo），是古代中国建筑、家具及其它器械的主要结构方式，是在两个构件上采用凹凸部位相结合的一种连接方式。凸出部分叫榫（或叫榫头）；凹进部分叫卯（或叫榫眼、榫槽）。本文用来特指一种采用强耦合数据结构实现跨链的技术模式。
相对于公证人和中继的模式，榫卯式更直接，耦合度也更高，双方紧密地绑定在一起，一条链的状态将直接地反应到另外一条链的数据中。当一条链被攻击时，另外一条链也可能会受到影响。这种模式更适用于同一个系统的主链+侧链的设计，这让双方能成为有机的整体，又不失账本的相对独立性。
Aelf
Aelf为了提高自身平台的整体性能，采用主链+侧链的扩容架构，主链上可挂载多个侧链，侧链和侧链之间是独立的，一条侧链支持一个DApp应用场景，也可以是一组合约，每条侧链和主链在数据上是互相嵌入的。Aelf主要解决了资源隔离的问题，即不同的应用对资源和性能的需求不同，因此其在各自独立的空间运行是对系统资源的一种优化配置。
Aelf的主链和侧链高度同构化，采用主侧链联合挖矿的模式，如上图所示，即一组节点挖矿可对主链和侧链同时拥有记账权。矿工同时拥有主链和侧链的数据信息，因此主链通过矿工可获取侧链的区块头数据，并将其存储在自己的区块体中，这样主链在验证侧链的交易时，只需查看自己区块体中该侧链的区块头信息就能进行交易的验证（类SPV证明），同时也是对侧链交易的间接确认。由于主链将侧链的信息写入到了自己的区块体中，因此，对于这些数据的正确性，主链需要额外地再做一次共识，Aelf采用的是PBFT共识算法，确保该过程能快速完成，否则将影响主链的出块速度。
不过，侧链不会将主链的数据写入自己的区块结构中，但是它依然会通过智能合约将主链的数据存储到侧链的数据空间中，以便对主链交易进行查询和数据验证。
3.3难点三：如何保障两条链的资产总量不变
我们知道跨链目前主要实现的两大场景，一个是跨链资产互换，另一个是跨链资产转移。在跨链资产互换中，本质上只是两条链上的资产同时交换了资产持有者，资产还是在原有链上，并未发生转移，因此每条链的资产总量是不会发生改变的。 而在跨链资产转移的过程，链上的可用资产是实际发生价值流转的，A链上的资产价值确实能流转到B链上，A链可用资产总量减少，B链可用资产增加，但是A链和B链的资产总和是恒定的。难点三其实主要是针对这种应用场景而言的。
保障资产总量不变，这里面隐含了两层含义，一是在正常的情况下，未被攻击的情况下如何保障资产总量不变；二是在异常的情况下，即受到攻击的情况下要如何确保资产总量的恒定。
在正常的情况下，虽未受攻击，但还是有网络状态不稳定、宕机、部分节点作恶或者部分用户作恶等情况的存在，因此，要保障资产总量不变，必须要确保资产转移的过程在两条链上都是精确记账。拆开了来说，就是要保障1.跨链交易在两条链上必须是同步的，即交易的原子性，要么都发生，要么都不发生。2跨链交易在两条链上都是真实有效的，被整个网络确认过大概率有效的，后期分叉的可能性很小。所以，正常情况下难点三的解决是依赖于难点一和难点二的，只要前面两者可以实现，难点三就自然不攻而破了。
在异常情况下，假如链A已经完成了一笔从链A到链B的跨链交易，如下图所示：
随后链A被黑客攻击发生了分叉，之前的跨链交易已经不在链A最长的那条链上了，那么之前转账的账户可以发起一笔双花攻击，再次给链B发送一笔跨链交易，这样，链B将第二次接收到从链A某账户发来的资产，链A和链B的资产总和将因双花攻击而增大。由于资产总价值不变，那么链B中资产数量不对等的增多将导致链B的资产贬值，链B的每一个用户都要为此次双花攻击买单。
同理，如果发生双花攻击的是链B，则链A和链B资产总和将减小，链A转到链B的资产由于不在主链上，就如同消失了一样，链A上发起转账交易的用户将受到损失。
以上异常的情况发生的概率非常低，但是又不能排除其发生的可能性，所以，在做跨链设计的时候还是需要对其进行相应的处理。总体来说，有以下几种处理方向：
1.首先，隔离受攻击的链。由于链和链之间的通信通常不是直接进行的，而是需要经过第三方的，公证人也好，“中间人”也好，中继节点也好，这个第三方角色不仅承担了链接人的角色，也同时承担了隔离者的作用。当发现某条链出现安全问题时，隔离者应该拒绝该链所有的跨链交易请求，直至安全问题被解决。
2.冻结跨链交易创建的失效资产。对于异常攻击的第一种情况，链B凭空增多了资产，原因就是之前确认过的跨链交易由于链A重构，交易已然失效，对于这种失效的跨链交易，应该在链B对其相关资产实施冻结处理，以确保资产总量的恒定。
3.释放跨链交易冻结的资产。对于异常攻击的第二种情况，链A会因为链B被攻击而失去已经发生跨链转移的资产，由3.2小节可知，实际上链A转移的资产是冻结在链A的特殊账户里，如果攻击发生后，能释放冻结在链A特殊账户中的资产，即可为链A中的用户挽回损失。
以上3种处理思路更多的是逻辑的自洽，而非实际的落地方案。思路1是针对公证人机制而言的，也是较容易实现的，目前wanchain等项目已有落地方案。思路2和思路3的实现相对复杂，目前还未有项目发布具体的技术实现方案，更多的可能将倾向于动用系统的管理员权限去做特殊处理。由于跨链项目整体的成熟度较低，对于这个低概率问题的思考和处理方案也相对滞后，期待未来更完善的解决方案。
3.4难点四：如何保障两条链的独立安全性
安全性一直是区块链领域的重中之重，在跨链交易的过程中保障两条链的安全系数不会被降低，或者不被过度降低是一个重要的命题。总体说来，可从以下几个方面进行考虑：
1.适度隔离。两条链之间应该保持各自的独立性，尽量通过第三方节点或者独立的模块处理跨链事务，当跨链交易发生问题时，也不会影响链本身交易的处理。特别是对于高度耦合的系统设计，如榫卯式模式，需要更多地从其他角度进行系统的安全性保证。
2.检测安全事件。系统架构上做了隔离只是第一步，重要的是这个第三方节点或者独立模块要具备检测安全事件的能力，并且具备响应能力。
3.跨链交易正确性。这一点是最基础的，只有在保障跨链交易正确和安全的前提下才能保障其相关的区块链体系不受影响。而这主要由跨链交易的原子性以及保障交易最终确认性来完成的，详情可见3.1和3.2小节，此处不再赘述。
目前的项目对于跨链方案设计有基本的安全性、独立性考虑，但是对于更深入的安全措施的研究还有待加强，比如说安全性问题发生后的补救措施、奖惩机制、以及对安全事件的检测能力等问题还需进一步探讨。
3.5难点五：如何实现多条链之间的跨链互联
计算机网络让原本独立的计算机连成了局域网，局域网发展为城域网，城域网演变为广域网/互联网，互联网则前所未有的将世界人民联系在一起。对于区块链这项新兴的技术/产业来说，现在还只是处于“单机”时代，链和链之间的互通需求将会随着区块链的应用落地越来越强烈。
我们上文讨论的主要是两条链之间的互联互通，那如何实现多条链的连通呢？其实，这个问题隐藏了两个潜在问题：一是已经存在区块链系统如何实现互联互通；二是对于未来要开发的区块链，如何为其互联互通做好准备和铺垫。本小节将从这两个方面分别进行阐述。
3.5.1主动兼容
主动兼容方案是自上而下进行的，主要针对的是已有的区块链系统，先有了上层不同的区块链应用系统，再进行底层的跨链机制研发。通常这些系统都是异构链，需要一一进行对接，不过一一对接也有不同的方案，如下图左侧所示。一种是两两链之间直接进行互联，这种方式若无统一的底层协议支持，是最费时费力的了，四条链之间需要建立6条链接通路才可实现两两互联，且两两之间的通路需要定制化实现。这种方式虽然可扩展性不强，但能保障较好的安全性和独立性，一旦有攻击事件发生，难以影响到整个网络。
第二种是建立一个第三方跨链平台，链和链之间都通过这个跨链平台进行间接互联，这样要实现两两之间的互联只需要四条链接通路即可，如上图所示。但这样，跨链平台将成为整个跨链网络的关键点和性能瓶颈（目前还不一定是瓶颈，但未来有可能是），一旦跨链平台受到攻击，那整个跨链网络都将陷入瘫痪。
3.5.2被动兼容
被动兼容方案是自下而上进行设计的，主要针对的是未来还未开发的区块链体系，先搭建好底层的跨链平台，让其它区块链系统能简单、便捷、安全地接入进来，共享跨链平台的系统便利。跨链平台会优先将适用于各链之间进行互操作的系统和协议标准开发出来，后续只需在其已有的平台上进行符合标准的开发就可建立天然具有系统内跨链功能的区块链。不过这里说到的跨链是指的符合这套协议标准的链之间能简单地互相连通，若是要和该体系外的其它链之间进行互操作，还需要开发单独的中间件来进行连通。此外，不同的跨链平台其支持的区块链类型也可以不同，如Cosmos支持的是同构链，而Polkadot则可支持异构链，两者都有很高的可扩展性，详细介绍可参考4.5.1的Cosmos和4.5.2小节的Polkadot项目介绍。
3.6小结
本章从问题出发梳理了一个跨链项目将要面对的主要问题，并给出了业界的一些主流解决方案和解决思路。但并不是每个涉及到跨链的项目都需要解决以上所有问题，而是各取所需：若要实现跨链资产互换功能，解决难点一即可；若要实现跨链资产转移，解决难点一和难点二即可，若是能在此基础上尽量解决难点三和难点四那将得到更安全和稳定的系统；若要建立一个跨链平台，那么难点五是必须要考虑的问题。
对跨链技术的研究现在仅仅是个开始，跨链过程中的众多难题还需要一步步去解决，特别是跨链安全性的研究现在还较为缺失，期待未来有更多优质的跨链项目能推动区块链网络的建立和完善。
火币区块链应用研究院
关于我们：
火币区块链应用研究院（简称“火币研究院”）成立于2016年4月，于2018年3月起全面拓展区块链各领域的研究与探索，主要研究内容包括区块链领域的技术研究、行业分析、应用创新、模式探索等。我们希望搭建涵盖区块链完整产业链的研究平台，为区块链产业人士提供坚实的理论基础与趋势判断，推动整个区块链行业的发展。
《火币区块链产业专题报告》是火币研究院推出的针对区块链行业细分领域的专项研究分析，一般会涵盖该细分领域技术发展、竞争格局、标杆项目分析、市场前景分析、未来模式预测等，以专业的研究方法帮助大家深入的了解行业，发现技术走向、投资价值和投资机会，规避经营风险，提高管理和运营能力，为行业企业提供最全、最佳的信息支持。
联系我们：
咨询邮箱：[email protected]
号：火币区块链研究院
Twitter:Huobi_Research
Medium:Huobi Research
Facebook:Huobi Research
免责声明：
1. 火币区块链研究院与本报告中所涉及的数字资产或其他第三方不存在任何影响报告客观性、独立性、公正性的关联关系。
2. 本报告所引用的资料及数据均来自合规渠道，资料及数据的出处皆被火币区块链研究院认为可靠，且已对其真实性、准确性及完整性进行了必要的核查，但火币区块链研究院不对其真实性、准确性或完整性做出任何保证。
3. 报告的内容仅供参考，报告中的事实和观点不构成相关数字资产的任何投资建议。火币区块链研究院不对因使用本报告内容而导致的损失承担任何责任，除非法律法规有明确规定。读者不应仅依据本报告作出投资决策，也不应依据本报告丧失独立判断的能力。
4. 本报告所载资料、意见及推测仅反映研究人员于定稿本报告当日的判断，未来基于行业变化和数据信息的更新，存在观点与判断更新的可能性。
5. 本报告版权仅为火币区块链研究院所有，如需引用本报告内容，请注明出处。如需大幅引用请事先告知，并在允许的范围内使用。在任何情况下不得对本报告进行任何有悖原意的引用、删节和修改。