日前，北京金融科技产业联盟成功举办“区块链跨链技术研讨会”。本次研讨会聚焦区块链跨链技术、方案对比、实现路径及发展趋势等方面，相关案例为实现跨链互操作提供行业借鉴。本次研讨会分享嘉宾来自华为、溪塔科技、微众银行、趣链科技等。以下内容根据溪塔科技副总裁宁志伟在会上分享的“异构联盟链互操作协议简介”主题演讲整理而成。
本次分享主要围绕四个方面，即现有互操作技术介绍、现有技术在联盟链中的问题、新方案介绍以及应用场景介绍。
一、现有互操作技术介绍
现在比较常见的跨链互操作技术，按照以太坊创始人Vitalik的总结可以分成公证人、侧链(中继)、哈希时间锁(HTLC)三类方案。今天我们会尝试从不同的角度来分析这些方案。
互操作技术顾名思义就是一种可以让不同的区块链上面的用户或者资产可以跨链互相操作的技术，所以最基本的功能就是两个区块链之间的交互。区块链本身是运行在不可信的环境下的，不会轻易信任外来的数据，所以交互需要一定的信任基础，通过技术手段来创建信任，所以信任的基础就来自于双方在技术上的共同点。这是一种比较通用的分析互操作协议的思路，接下来我们就尝试用这种思路来分析现有的互操作技术。
公证人方案最常见的例子就是通过公证人的数字资产交易，这个场景下的交互操作有转账和交易。首先A需要在链上把自己的资产转给公证人，B也要做同样的操作。然后A和B分别向公证人提出交易的请求，公证人进行交易撮合。最后A和B再分别把数字资产从中间人转移到自己的个人地址中。
我们对转账操作的信任基础来自于区块链提供的所有权转移功能，同时还有链具有的确定性，确保转账操作不会在将来被回退。中间交易操作的信任基础则完全是对公证人的信任，跟区块链并没有关系。共同技术方面，因为所有权转移和确定性是区块链的标配，而公证人又与技术无关，因此这里就算作没有。
侧链(中继)方案的一个例子是RELAY，可以实现两个链之间资产的转移。其交互操作流程大致如下。首先通过发送交易指令在A链上将资产锁定；其次Relayer将该笔交易以及相应的证明搬运到B链上；最后B链上的合约验证证明的有效性并发放对应价值的资产。
信任基础主要依靠搬运的交易数据和相应证明的可靠性。共同技术则比较多，需要双方能够理解对方的数据结构；支持证明中所使用的密码学算法，甚至是证明和交易数据所使用的序列化方法。
哈希时间锁(HTLC)方案原理是用一个秘密来锁定资产，这个秘密一般是一个哈希的原象。然后双方交换秘密，再分别去解锁对方的资产，完成资产互换。其中交互操作包含用秘密进行资产锁定和交换秘密。
信任基础则是用于锁定的合约和秘密对应的哈希算法。共同技术包括支持同样的哈希算法以及都要支持特殊的锁定功能。
现在做个小结，按照对共同技术要求的多少，简单排个序。
公证人对交互的两个链几乎没有额外的共同技术要求，所要求的都是区块链必备的功能，只是需要对公证人信任。HTLC其次，需要两个链支持同样的哈希算法和锁定功能。侧链方案对双方的共同技术要求最多，包含核心的数据结构、密码学算法、证明的验证逻辑以及数据的序列化方式。
之前网上会有一种说法，在三种方案中，侧链适合同构链跨链，其他两种方案则适用于异构链。其实这里并没有严格的适用于同构链和异构链的明显的界限，仅仅只是不同方案对双方的共同技术要求多寡的区别。
二、现有技术在联盟链中的问题
前述的三种方案在公链场景都有实施，通过分析来看看这些现有技术在联盟链场景下会有些什么样的问题。
公证人方案—最大的问题是联盟链场景很难找到合适的公证人。公链场景比较接近ToC场景，公证人是经历了市场化的优胜劣汰之后脱颖而出的。但是在更接近ToB市场的联盟链场景中，市场化程度以及参与者的体量都有很大的不同，很难复制公链上的经验。
HTLC—最怕的是双方没有共同的哈希算法。目前联盟链基本上都以虚拟机的方式支持智能功能，且大多采用EVM以支持以太坊的合约生态。哈希算法都是以预编译的方式集成在EVM的实现中，想要支持更多的哈希算法，需要修改底层代码，破坏性太大。如果以智能合约的方式支持新的哈希算法又太慢。
侧链方案—目前联盟链市场不同的异构链差异太大，想要多种区块链相互理解对方的数据结构、算法和序列化方式，工作量巨大，且随着加入的链的种类呈指数级增加。
此外，在联盟链场景下跨链还有些非技术性问题。一是流动性问题。对于HTLC方案来说，要求交易双方同时在线。这就意味着必须先找到对手方，然后才能进行交易。如果找不到对手方，即流动性不足，则无法进行交易。对于另外两种方案来说，其实也有同样的问题。例如通过公证人的数字资产交易，看似不需要交易双方同时在线，但是其实在这个方案下用户真正的对手方是公证人。如果交易对中的两种数字资产，短时间发生大量的单向兑换，导致公证人某种数字资产的储备耗尽，也会造成流动性不足。二是冷启动问题。公链最重要的其实不是它的软件，而是对应主网那条链。而联盟链主要是卖软件，链的实例会启动很多个。以我们的联盟链产品CITA为例，每一个客户都会启动一条甚至多条链，总数可能达到了上百条。当跨链的时候，不只要确认所用的底层是否为CITA，还要确认具体要连的是哪条链。公链知名度一般都比较高，相应的资料也比较多，所以其验证方式通常为大家所熟知。而联盟链比较碎片化，知名度不高，相应的资料也比较少，验证方式等技术细节通常只有对应厂家才知晓。
基于以上两点，公链跨链时所需的共同知识，通常已经作为常识被双方知晓，推进起来更加容易。但是对于联盟链来说，就需要事先建立联系，有一些信任之后才能开始跨链，所需的前期和链外的工作要多得多。
三、新方案介绍
新的方案是溪塔科技联合微众银行和中钞杭州区块链研究院共同设计和发起的，这里简单介绍一下思路。
我们前面看到制约异构联盟链跨链最大的问题是相互之间差异太大，本方案的思路是求同存异。求同方面，我们建立了一套统一的数据结构和接口。各家链只要分别适配到这套接口，相互之间就可以支持最基本的交互功能，将指数级的工作量降低为O(n)级别。存异方面，各家链可能基于不同的考虑选择不同的验证方法、数据结构和序列化，这个很难统一起来，我们只能接受这个现实。如上图所示，视频接口种类这么多，不同的产品根据实际情况选择不同的接口。想要让这些设备互通，只能相互增加对方插头对应的接口才能实现互通。所以我们的方案是各家链提供自家证明对应的验证工具，然后跨链双方交叉使用对方的验证工具。
到此为止，该方案也仅仅是提供了最基本的异构链交互和相互验证的能力，并没有提供跨链交易事务性方面的保障。对于这一点，我们分析发现，事务性保障是可以单独提供的，跟前述机制并无耦合，属于比较通用、比较独立的功能。在该方案中，我们会以组件的方式提供事务性解决方案，跨链应用开发者可以根据需要进行选择。
在该方案中，双方是交叉使用对方的验证工具，如果对方的验证工具存在问题，则对整个跨链方案是非常大的打击。对此，我们的解决方案是验证工具必须开源，并且可以开放给任何人来检查，以确保其真实并正确的执行了验证工作。
四、应用场景
最后以一个具体的应用场景来看一下新的方案下跨链应用如何实现。这里的假设场景是同一家机构发行的数字资产，在不同的链上有不同的实现，但是相互之间其实是等价的。需求是进行跨链资产兑换。
实现方案可以参考上图。不同的链通过插件将各自的接口转换到统一的接口上，然后通过跨链路由汇聚到一起。跨链资产兑换这个跨链应用则在汇聚端的跨链路由之上，通过跨链路由就可以对四种不同的链进行任意的操作。对于跨链资产兑换操作来说，用户向跨链应用发起请求之后，假设是将资产从BCOS链上兑换到CITA链上。跨链应用先往BCOS链上发交易锁定一定数量的资产，接受证明并验证通过之后，再往CITA链上发交易释放等价值的资产。
上述例子是假设的，但是现实中确实存在类似的需求，只不过情况刚好反过来。因为联盟链生态的碎片化，只要是做过一定数量的区块链项目的公司，都会存在因为每个项目选择不同的链，导致不同的链上有不同的资产。当公司想把这些资产做一个统一纳管的时候，就会发现因为链的差异而困难重重。使用我们的方案，只要在已有的多种链上部署跨链路由和对应的插件，就可以在汇聚端实现多条链上资产的统一纳管。
本文来源：区块链专委会
投稿邮箱：News
bfia.org.cn