为了巩固对跨链的认识，为此对跨链的知识点概念等进行查漏补缺，利用了周末的时间重新阅读了一份关于跨链的报告，方便更系统地熟悉跨链的应用场景与方案。

跨链的定义:

跨链，狭义上来说是两个相对独立[1]的区块链账本间进行资产互操作（Interoperability）的过程；广义上来说是两个独立的账本[2]间进行资产、数据互操作的过程。

[1]指两个区块链账本间相互独立，没有在某方统一进行清/结算的情况（交易都在母链账本进行清算的母子链结构不存在本文所述的跨链操作）

[2] 此处所指的账本不仅指的是区块链账本，也指中心化账本或者其他形式的分布式账本（如DAG账本）。

案例应用：

1. 链下通道：闪电网络、雷电网络
2. 跨账本多跳协议：Ripple
3. 侧链：单向/双向锚定侧链：Liquid、Elastos
4. 跨链平台：Wanchain
5. 跨链平台：Cosmos、Polkadot

跨链的实现形态主要表现为资产互换和资产转移

跨链进化史

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第一次提出了建设跨链网络基础平台的方案，目前这两个项目还在开发过程中。

跨链实现形态：

链间资产互换：通常指两条链上的不同用户之间进行资产互换，但每条链上的资产总量并无增减，只是资产所有权发生了变化，且这个所有权改变的过程需在两条链同步发生。

链间资产转移（单向/双向）：资产转移和资产互换虽看起来相似，却有本质的不同。上文所述资产互换中各链的资产总数是不变的，但资产转移，是资产价值的转移，各链中可用的资产总量将相应增加或者减少。

有些项目提出了跨链智能合约的概念，多指一条链上的智能合约能确认原链跨链交易的场景，这从技术实现上来说和实现跨链资产转移是相似的，都需要对原链交易进行确认和验证。

1）如何保障跨链交易的原子性。即跨链交易要么发生，要么不发生，否则两条链的不一致和不同步状态将成为跨链交易最大的系统漏洞，两个系统的安全性都将受到威胁。

2）如何完成对另一条链的交易确认。对交易的确认，包含了两个层次的问题，一是确认交易已经发生并且上链，写入了区块账本；二是该交易已经获得了系统足够多区块的确认，这样由于系统发生重构而导致交易无效的概率将非常低。区块链系统本身是较为封闭的系统，缺乏主动获取外部信息的机制，因此要确认另外一条链的交易状态并非一件容易的事，可以说是跨链交易的核心难点之一。

3）如何保障两条链的资产总量不变。在资产互换的场景下，两条链的资产并未发生实质性的交换，因此该类情况不会改变各链的资产总量。但是在资产转移的场景下，每条链的可用资产数量是变化的，只有保障跨链交易精确记账，且两条链的账本记账完全同步，才可实现，换种说法就是两条链的记账必须是原子性的，要么都同时记，要么都不记。除此之外，问题的关键是当某条链发生重构时，是否依然能保持两条链的资产总量不变。

4）如何保障两条链的独立安全性。当两个系统发生交互时，难免会对彼此系统产生影响，如何在跨链交易的过程中保障自己系统和对方系统的安全性是个值得考虑的问题。若是安全性问题无法隔离，那一条链受到攻击，将影响整个跨链网络。

5）如何实现多条链之间的跨链互联。参照计算机网络的发展历程，独立的区块链网络终究要走上互联互通的未来，那如何将这些已有的和未来将要开发的区块链网络都联系起来成为统一的整体将是未来跨链网络最重要的问题之一。

跨链具体的关键点与实现方式可以总结为：

1. 如何保障跨链交易的原子性：介绍了原子互换和哈希时间锁协议原理。
2. 如何完成对另一条链的交易确认：介绍了公证人、中继以及榫卯式三大类模式异同。
3. 如何保障两条链的资产总量不变：从正常和异常两种情况分别阐述了应对方案。
4. 如何保障两条链的独立安全性：主要从隔离机制和安全检测机制分析了应对思路。
5. 如何实现多条链之间的跨链互联：介绍了主动兼容和被动兼容两种跨链网络建设方案。

保障跨链交易的原子性

需要两个转账交易，两个保证对方转账的回撤交易。

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的资产总量并未改变，因此原子互换协议只能实现链间的资产互换，无法实现资产转移。

HTLC哈希时间锁协议：

哈希时间锁协议，即HTLC（Hashed Time-Lock Contract）,是原子互换协议的具体实现，通过哈希锁和时间锁机制保障了交易的原子性。若只使用哈希时间锁，只能实现跨链的资产互换，而非跨链资产转移

哈希锁

在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写入区块的时间而言的。

HTLA，哈希时间锁协定

哈希时间锁协定[4]，即HTLA（Hashed Time-Lock Agreements）是Interledger[10]提出的HTLC泛化协定，不管系统是否支持HTLC协议，不管其是分布式账本还是中心化账本，系统和系统之间都能使用HTLA实现跨链交换，且支持多个系统之间的多跳跨链互换。Alice和Bob可以通过HTLA在区块链A、B、C之间进行跨链交换，且每一种区块链都支持不同的跨链协议，连接器在这其中起到了连接、隔离的作用，将支持不同跨链协议的区块链连接到一起，并且又起到了隔离的作用，使得区块链之间不会相互影响。

有条件的支付通道（Conditional Payment Channels）

对账本的功能性需求：支持支付通道的HTLC更新

对账本的非功能性需求：支持高速交易

交易风险：无

使用案例：闪电网络[5]

协议简介：支持有条件支付通道协议的系统，交易参与者需要在账本上预付一笔资金到一个双方共享的临时账户。当交易开始时，发送者会发送一个带有哈希锁和时间锁以及附带签名的更新到接收者。若接收者能在超时前反馈哈希锁的原像，则其可从临时账户中赎回资金，并且发送者接收者同时签名确认共享账户的余额变动。当发生争议时，账本将依据账本信息进行判断和仲裁。由于交易的传输和处理时间会被计算在超时的范围内，所以该种协议更适合支持高速交易的账本系统。

On-Ledger持有/托管

对账本的功能性需求：支持HTLC交易

对账本的非功能性需求：支持高速、低费用和高吞吐量

交易风险：无

使用案例：以太坊第三方托管合约、Ripple第三方托管

协议简介：当账本支持HTLC协议时，并且该账本交易速度快、费率低、吞吐量高，那么参与者之间可以直接通过HTLC协议发起跨链交易。交易发起者将要传输的资金先放到账本提供的特定持有账户中，并且附带哈希锁和时间锁，只有当接收者在超时前能提供正确的哈希原像，账本账户才将资金发送给接收者，否则账本将会把资金退回给发送者。这种方式可由账本负责全权控制交易状态，交易双方没有额外的风险。

简单支付通道（Simple Payment Channels）

对账本的功能性需求：支持无条件的、单向支付通道

对账本的非功能性需求：无

交易风险：有交易对手风险

使用案例：比特币CLTV通道[8]、Ripple PayChan[9]

协议简介：简单支付通道是建立的off-chain交易通道，无论账本交易速率如何，链下的通道可支持大规模快速交易。在建立单向通道时，发送者需要将资金存入链上和接收者共享的临时账户中，只有当双方对交易金额的数量和转移方向都同意且同时签名时，该账户的资金才可被取出。发送者传给接收者的是一个带哈希锁和时间锁的消息，当接收者在超时前提供了正确的哈希原像，发送者再发起一个新的带有签名的申明给接收者，使得接收者能接收到全部的交易金额。

保障对另一条链的交易确认

两条链之间发起跨链交易的时候要如何才能确认发送链的交易真的发生并且被它确认了呢？

两条链之间总会出现一个“中间人”的角色，承担了为两条链进行信息交互的角色，只不过在具体实现时这个“中间人”的角色有很多种演化的可能性。“中间人”可能是一个也可能是一群，可能是中心化机构也可能是分布式群体，两条链的中间人可能是同一个/组节点，也可能不同，甚至这个“中间人”可能是一条独立的链或者又只是一个功能模块而已。“中间人”通常会同时充当两个区块链的节点，这样只需在同一节点上再部署一个应用软件获取对方系统数据即可。

在交易确认这个问题上其实隐含了三层意思:

• 第一层含义是跨链数据传递，即需要获取/收集发送链的数据，为交易确认做好准备；
• 第二层含义是发送链对交易的确认，即发送链的交易并不是只要写入区块就能最终确认的
• 第三层含义是目标链对发送链已经确认过的交易再次核实，即需要依据收集到的数据来做确认，到底发送链声称的跨链交易是否发生，以及交易是否得到最终确认。

公证人、中继、榫卯

“中间人”基本上完成了前者数据收集的工作，那交易如何确认，在哪确认，以及由谁来确认成为了问题的关键。根据不同的方案，我们可以将该过程主要概括为三种实现方式，即公证人模式、中继模式和榫卯模式。

image

公证人模式是最为简洁的设计，即“中间人”不仅进行数据收集，还进行交易确认和验证。此时的“中间人”将成为可信第三方，可以是一个双方可信的中心化机构，也可以是一群节点。其验证交易是否正确的过程又将有多种演化，主要分为三种：单签名公证人机制、多签名公证人机制以及分布式签名公证人机制

image

中继模式中，“中间人”仅仅充当数据收集者的角色，并将收集的数据转发给目标链，由目标链依据收集的数据去完成交易确认的工作。中继模式是个相对去中心化和松耦合的方式，两个链之间的设计和结构是较为独立的，因此也具备了更高的可扩展性。“中间人”更多地充当了中继桥梁的角色。

image

榫卯[3]模式表述的是一种通过数据强耦合关系来实现跨链互操作的模式。链A和链B通过“中间人”收集到对方的数据，并且将对方的数据纳入到自己的区块链体系中来。这种纳入不一定是记录到自己的区块中，有可能是记录到自己系统中的存储空间。若链A是已经存在的区块链，那链B要么只能单向嵌入链A，要么链A就要进行相应的升级改造。这种强耦合的结构通常用于侧链的设计中。

榫卯（sǔn mǎo）是古代中国建筑、家具及其它器械的主要结构方式，是在两个构件上采用凹凸部位相结合的一种连接方式。凸出部分叫榫（或叫榫头）；凹进部分叫卯（或叫榫眼、榫槽）。其特点是在物件上不使用钉子，利用卯榫加固物件。本文用来特指一种采用强耦合数据结构实现跨链的技术模式。

理解三种方式的关键点就是：要充分理解其如何实现对原链交易的确认，即数据如何传递，原链交易如何确认，接收链对原链交易如何验证即可。

公证人

中心化公证人模式为:中心化公证人机制也叫单签名公证人机制，通常由单一指定的独立节点或者机构充当，这是最简单的模式，通常，这种模式被用于某类单一或特定的交易。与其Alice和Bob两个陌生人直接交易，不如两者都和有信用背书的第三方机构间接交易更可靠（如支付宝模式）

多重签名的公证人机制是由多位公证人在各自账本上共同签名达成共识后才能完成跨链交易。公证人的选取可以有多种方式，比如1）随机抽取公证人；2）对交易双方可信公证人节点列表求交集；3）直接采用可信联盟中的可信节点等。

分布式签名的公证人机制和多重签名的公证人机制最大的区别在于签名的方式不同，采用了多方计算MPC（Multi-Party Computation）的思想，分布式签名相较于多重签名，安全性更高，但实现也更复杂。

中继Relay

中继（Relay）是更灵活、易于扩展的跨链技术，其不依赖可信第三方帮助其进行交易验证，而是在拿到发送链数据后由接收链自行验证，自行验证的方式依据系统结构不同而不同，例如BTC-Relay依赖于SPV证明（如下文SPV小节所示），Cosmos还依靠验证节点签名数量等。

Vitalik在其互操作性论文[2]中提到Relay，指出链A和链B可通过对方的区块数据来进行信息同步和跨链函数调用，目前信息同步是可以做到的，但是跨链函数调用还没有成熟的技术方案。但两个链不能同时验证对方区块的有效性，否则将陷入互为嵌套的死循环。如链A拥有链B的区块数据，则链A需在链B交易确认的情况下才能进行确认，而链B因为同时拥有链A的区块数据，链B又需等待链A的交易确认，……,这样，交易确认就陷入了死循环。

BTC-Relay

2016年Consensys团队推出的BTC-Relay是最经典的中继（Relay）跨链方案，实现了以太坊和比特币之间的跨链交易，使得以太坊的DApp应用可以支持BTC支付。

BTC-Relay本身为以太坊的一个智能合约，该合约的功能就是对比特币上的某些交易进行验证，并且提供验证信息给以太坊上的其它DApp用户。Relayer是从比特币获取区块头数据的一群用户，并拥有以太坊网络的账户地址，最快向BTC-Relay合约提交区块头数据的Relayer可以得到以太坊的交易费奖励。BTC-Relay智能合约获得区块头数据以后就可以依据SPV证明的原理对某交易进行验证，当比特币网络中的某交易确实发生，则可触发以太坊网络的特定交易或者智能合约执行。

SPV证明

SPV，Simplified Payment Verification，即简单支付证明，其中，“支付”是关键字，即该种证明只是对是否发生支付行为做验证，而不是对“交易”做验证。

比特币一个区块的大小为1M，而区块头只占了80个字节（Byte），交易列表则占用了区块中的绝大部分空间。SPV的基本原理就是在只有区块头数据的情况下验证某交易是否发生，这样既方便快速也节省了大量的存储空间。

通过区块链头数据来验证某交易是否已发生，可以按照如下的步骤进行：

1. 下载区块中最长链的区块头数据
2. 计算该交易的哈希值，得到Tx_hash;
3. 通过Tx_hash索引定位到包含该交易的区块
4. 为验证该交易是否存在于该区块中，需重新计算与该交易相关的哈希值，直到根部，并将计算得到的哈希值与区块头中的Merkle根哈希进行比较；若一致，则表明该交易确实发生并存在于该区块中；若不一致，则说明该交易并未被打包到最长的链中，即未被验证确认。

榫卯式

榫卯式是一种强耦合结构的跨链模式，通过某种方式直接将原链的部分数据嵌入到自己的区块或者存储空间中。在进行跨链交易时，直接通过本系统存储的原链数据便可完成交易验证。这种方式一般在系统设计之初就进行了双向考虑，通常用于主链+侧链的设计中，多采用协同挖矿模式。若主链已经存在，则侧链通常是单向锚定主链，即侧链锚定了主链的数据，但主链却无法识别侧链状态。

榫卯式更直接，耦合度也更高，双方紧密地绑定在一起，一条链的状态将直接地反应到另外一条链的数据中。当一条链被攻击时，另外一条链也可能会受到影响。这种模式更适用于同一个系统的主链+侧链的设计，这让双方能成为有机的整体，又不失账本的相对独立性。

主链通过矿工可获取侧链的区块头数据，并将其存储在自己的区块体中，这样主链在验证侧链的交易时，只需查看自己区块体中该侧链的区块头信息就能进行交易的验证（类SPV证明），同时也是对侧链交易的间接确认。由于主链将侧链的信息写入到了自己的区块体中，因此，对于这些数据的正确性，主链需要额外地再做一次共识。比如一条联盟链咬定ETH来给自己增加公信力

保障两条链的资产总量不变

保障资产总量不变，这里面隐含了两层含义，一是在正常的情况下，未被攻击的情况下如何保障资产总量不变；二是在异常的情况下，即受到攻击的情况下要如何确保资产总量的恒定。

在正常的情况下，虽未受攻击，但还是有网络状态不稳定、宕机、部分节点作恶或者部分用户作恶等情况的存在，因此，要保障资产总量不变，必须要确保资产转移的过程在两条链上都是精确记账。拆开了来说，就是要保障

1. 跨链交易在两条链上必须是同步的，即交易的原子性，要么都发生，要么都不发生。
2. 跨链交易在两条链上都是真实有效的，被整个网络确认过大概率有效的，后期分叉的可能性很小。

所以，正常情况下本章的难点三的解决是依赖于上文提的难点一和难点二的，只要前面两者可以实现，难点三就自然不攻而破了。

具体情况：

在异常情况下，假如链A已经完成了一笔从链A到链B的跨链交易，如下图所示：

image

随后链A被黑客攻击发生了分叉，之前的跨链交易已经不在链A最长的那条链上了，那么之前转账的账户可以发起一笔双花攻击，再次给链B发送一笔跨链交易，这样，链B将第二次接收到从链A某账户发来的资产，链A和链B的资产总和将因双花攻击而增大。由于资产总价值不变，那么链B中资产数量不对等的增多将导致链B的资产贬值，链B的每一个用户都要为此次双花攻击买单。

image

同理，如果发生双花攻击的是链B，则链A和链B资产总和将减小，链A转到链B的资产由于不在主链上，就如同消失了一样，链A上发起转账交易的用户将受到损失。

image

相应的处理。总体来说，有以下几种处理方向：

1. 首先，隔离受攻击的链。由于链和链之间的通信通常不是直接进行的，而是需要经过第三方的，公证人也好，“中间人”也好，中继节点也好，这个第三方角色不仅承担了链接人的角色，也同时承担了隔离者的作用。当发现某条链出现安全问题时，隔离者应该拒绝该链所有的跨链交易请求，直至安全问题被解决。

2. 冻结跨链交易创建的失效资产。对于异常攻击的第一种情况，链B凭空增多了资产，原因就是之前确认过的跨链交易由于链A重构，交易已然失效，对于这种失效的跨链交易，应该在链B对其相关资产实施冻结处理，以确保资产总量的恒定。

3. 释放跨链交易冻结的资产。对于异常攻击的第二种情况，链A会因为链B被攻击而失去已经发生跨链转移的资产，由3.2小节可知，实际上链A转移的资产是冻结在链A的特殊账户里，如果攻击发生后，能释放冻结在链A特殊账户中的资产，即可为链A中的用户挽回损失。

以上3种处理思路更多的是逻辑的自洽，而非实际的落地方案。思路1是针对公证人机制而言的，也是较容易实现的，目前wanchain等项目已有落地方案。思路2和思路3的实现相对复杂，目前还未有项目发布具体的技术实现方案

保障两条链的独立安全性

在跨链交易的过程中保障两条链的安全系数不会被降低，或者不被过度降低是一个重要的命题。总体说来，可从以下几个方面进行考虑：

1. 适度隔离。两条链之间应该保持各自的独立性，尽量通过第三方节点或者独立的模块处理跨链事务，当跨链交易发生问题时，也不会影响链本身交易的处理。特别是对于高度耦合的系统设计，如榫卯式模式，需要更多地从其他角度进行系统的安全性保证。

2. 检测安全事件。系统架构上做了隔离只是第一步，重要的是这个第三方节点或者独立模块要具备检测安全事件的能力，并且具备响应能力。

3. 跨链交易正确性。这一点是最基础的，只有在保障跨链交易正确和安全的前提下才能保障其相关的区块链体系不受影响。而这主要由跨链交易的原子性以及保障交易最终确认性来完成的，详情可见上文，此处不再赘述。

多条链之间的跨链互联

上文讨论的主要是两条链之间的互联互通，那如何实现多条链的连通呢？其实，这个问题隐藏了两个潜在问题：一是已经存在区块链系统如何实现互联互通；二是对于未来要开发的区块链，如何为其互联互通做好准备和铺垫。

主动兼容

主动兼容方案是自上而下进行的，主要针对的是已有的区块链系统，先有了上层不同的区块链应用系统，再进行底层的跨链机制研发。通常这些系统都是异构链，需要一一进行对接，不过一一对接也有不同的方案，如下图左侧所示。

一种是两两链之间直接进行互联，这种方式若无统一的底层协议支持，是最费时费力的了，四条链之间需要建立6条链接通路才可实现两两互联，且两两之间的通路需要定制化实现。这种方式虽然可扩展性不强，但能保障较好的安全性和独立性，一旦有攻击事件发生，难以影响到整个网络。

image

第二种是建立一个第三方跨链平台，链和链之间都通过这个跨链平台进行间接互联，这样要实现两两之间的互联只需要四条链接通路即可，如上图所示。但这样，跨链平台将成为整个跨链网络的关键点和性能瓶颈（目前还不一定是瓶颈，但未来有可能是），一旦跨链平台受到攻击，那整个跨链网络都将陷入瘫痪。

被动兼容

被动兼容方案是自下而上进行设计的，主要针对的是未来还未开发的区块链体系，先搭建好底层的跨链平台，让其它区块链系统能简单、便捷、安全地接入进来，共享跨链平台的系统便利。

跨链平台会优先将适用于各链之间进行互操作的系统和协议标准开发出来，后续只需在其已有的平台上进行符合标准的开发就可建立天然具有系统内跨链功能的区块链。

不过这里说到的跨链是指的符合这套协议标准的链之间能简单地互相连通，若是要和该体系外的其它链之间进行互操作，还需要开发单独的中间件来进行连通。此外，不同的跨链平台其支持的区块链类型也可以不同，如Cosmos支持的是同构链，而Polkadot则可支持异构链，两者都有很高的可扩展性

小结

我们回顾一下前文提到的五个难点与具体解决方案参考：

1. 如何保障跨链交易的原子性：介绍了原子互换和哈希时间锁协议原理。
2. 如何完成对另一条链的交易确认：介绍了公证人、中继以及榫卯式三大类模式异同。
3. 如何保障两条链的资产总量不变：从正常和异常两种情况分别阐述了应对方案。
4. 如何保障两条链的独立安全性：主要从隔离机制和安全检测机制分析了应对思路。
5. 如何实现多条链之间的跨链互联：介绍了主动兼容和被动兼容两种跨链网络建设方案。

本章从问题出发梳理了一个跨链项目将要面对的主要问题，并给出了业界的一些主流解决方案和解决思路。但并不是每个涉及到跨链的项目都需要解决以上所有问题，而是各取所需：

1. 若要实现跨链资产互换功能，解决难点一即可；
2. 若要实现跨链资产转移，解决难点一和难点二即可
3. 若是能在此基础上尽量解决难点三和难点四那将得到更安全和稳定的系统；
4. 若要建立一个跨链平台，那么难点五是必须要考虑的问题。

对跨链技术的研究现在仅仅是个开始，跨链过程中的众多难题还需要一步步去解决，特别是跨链安全性的研究现在还较为缺失，期待未来有更多优质的跨链项目能推动区块链网络的建立和完善。

后续资料整理集中在具体的技术实现案例，可参考跨链调研（下）

原文引用自：
【火币区块链产业专题报告】跨链篇（上）跨链难点解决方案剖析 https://www.jianshu.com/p/f2d2e83473fc
【火币区块链产业专题报告】跨链篇（下）跨链案例解析 https://www.jianshu.com/p/b19b1f3cb9c7