浅谈XChain的跨链设计机制

Posted 2021-06-29 跨链技术践行者

一、跨链的背景与难题

区块链技术日异月新，从BitCoin的诞生到现在已经有十年已久，在此期间各种公链百花齐放百家争鸣，然而如果从价值流通的角度来看，这些公链之间都是一座座价值孤岛，他们之间相互孤立无法让价值流通。如同互联网的发展史一般，二十世纪六七十年代，网络底层传递协议有ARPANET、UUCP、Usenet、Bitnet等，这些协议组网，最终导致信息只能在有限范围的网络内传递，直至TCP/IP出现之后，才让所有的局域网互联互通，进而形成形成更大广域网、互联网乃至物联网。反观现在区块链技术的发展，正如互联网的二十世纪六七十年代一般，区块链技术蓬勃发展，但最终形成的确是一座座价值孤岛，资产及其价值无法跨链传递、流通。所以跨链技术的研究也是区块链技术研究的重要方向之一，让价值自由流通，消除价值孤岛，这也正是XChain所追求的目标之一。

想解决资产流通问题，务必先提出跨链的解决方案。我们对跨链方案必须要解决的几大难题做了汇总，如下：

• 操作的原子性。跨链操作具备事务性，必须要保证所跨的两个链中的操作具有原子性，即要么两个链上的操作都执行成功，要么都执行失败，否则会导致两链结果不一致，最终导致跨链失败。
• 交易的有效性。有效性包含两层意思：一是怎样信任这个交易是合法的，单链中我们很容易校验交易的合法性，因为区块链内部有一套演算机制，保证交易的合法性，而在跨链时，两链之间必须校验对手链的交易的合法性；二是怎样信任这个交易是最终确认的，xBFT系列的共识的具备最终确认性，及出块即可确认，而POW、POS系列的算法需要N（6个）区块后才能确认，在此期间的交易有可能会被回撤，因此跨链过程中的必须判断对手端交易是否被确认，方可被认定为有效。
• 资产的守恒性。资产转移后，可用资产的总量务必守恒，否则资产凭空增加或消失，必然导致跨链失败。

在问题和因素已经确定的情况下，解决问题的办法和方案就可以有多种多样。XChain在分析和设计跨链方案的过程中，充分考虑了以上各种因素和难题，总结和设计了以下几种可行性较高的跨链方案：

• 公证人方案（Notary schemes）
• HASH 锁定方案（Hash-locking）
• 侧链/中继方案（Sidechains/relays）

这些各种方案各有利弊，后续系列的文章，我们将会分别予以深入分析和探讨，今天我们则主要讨论公证人方案。

二、公证人方案

         公证人机制顾名思义，即由一个/一组人担当公证人节点，承担一条链接收资产，另一条链里转出资产的功能。这种机制的优势较为明显，轻量级，简单易实现，扩展性高。另外功能丰富，公证人在这个过程中，可以充当兑换（资产交换）资产的角色，也可以充当资产转移（锁定原始资产，并发行等量等属性的资产）的角色。公证人需要在跨链的过程中，公证人承载着如下的功能：

• 保证跨链交易的原子性。公证人（节点/程序）必须保证两链操作的原子性，即两条交易的执行结果要么同时成功，要么同时失败。
• 检验数据的有效性。公证人必须主动检查两条链区块的合法性，也要检查相关交易是否的有效性，否则跨链必定失败，造成资产损失。
• 保证资产守恒性。收到Alice的资产，究竟是兑换给Bob多少何种类型的资产，是1:1转换或者1:N兑换，需要事先制定规则。否则会造成资产凭空增发或消失的问题，这点也需要公证人自行保证。

         公证人机制的跨链方案，按照公证人签名的方式可以划分为三种类型：

2.1单签名机制

单签名，即一个公证人即可决定跨链的整个流程。

假设有Chain A和 Chain B，Alice和Bob在分别在两条不同的链上，如果Alice想转移资产给Bob，在公证人机制过程如下：

1. Alice把资产转移给Notary在Chain A的账号里，并告知公证人其目标为Chain B 的Bob。
2. Notary 确认收到Alice在Chain A的资产。
3. Notary 在Chain B有自己的账号，并转移（兑换）相应的资产给Bob。
4. Notary发现有超时、出错等问题，则回退Chain A 里给Alice。

这种单签名机制的公证人跨链机制，架构简单但信用过于集中，存在很大的安全风险。

2.2多签名机制

所谓多签名机制，即在跨链中需要多个公证人签名授权才能进行转移资产的机制。这种方式与单一签名的机制向比较，较为去中心化。在实际的商业应用场景中，信任一组公证人的安全性相对而言要高于单一公证人的安全性。其原理如下图所示：

其过程如下：

其整体流程与单签名的基本一致，唯一区别是，公证人的账号Notary-account-A和Notary-account-B由一组公证人的私钥控制。这组公证人分别校验两条链和跨链交易的有效性，当校验跨链交易有效后，提交自己的签名，当公证人签名达到一定的比例时(如2/3的人数)，则认为签名有效，才允许对Notarys账号资产的控制。通过这种方式规避了单签名的中心化，能够有效的抵御单个或者部分节点被攻击所带来的风险。

2.3分布式签名机制

分布式签名基于密码学算法来实现，综合使用了分布式密钥，门限签名等密码学算法。其实现原理如下：把密钥以碎片加密的方式并随机派发于各个节点，当需要操作该账号时，各节点使用碎片密钥加密，签名满足一定门限时，即可签名验证通过。

其整体流程跟单签名基本一直。区别仍在于对公证人的账号Notary-account-A和Notary-account-B账号的控制权上，分布式签名的密钥以碎片分散于各个公证人节点，公证人校验交易的有效性并使用碎片密钥签名，当公证人的签名数达到一定门限则会校验成功，然后做后续的操作。在整个过程中，密钥加密分散于各公证人，安全性更好，但实现复杂度也更高。

三、XChain的Constellation跨链方案

XChain 在公证人设计方案上，采用的多签名机制，并做了一系列的优化和改进形成了XChain Constellation跨链方案。这是在多方因素下综合考虑的，相比较于传统的其他三种公证人跨链方案，X-Constellation跨链有如下优势：

1. 安全性高。有多方担保，去中心化程度较高，不会因某个公证人失效或被攻击而导致整个跨链失败。
2. 轻量级。相对于分布式签名机制，在使用原有链的加密算法的基础上，无需额外增加新的加密算法；另外框架和模块的交互设计较为简单。
3. 可扩展性高。框架的通用性极高，可以平行移植到任意链之间的跨链（当然需要该链支持多签名机制，后续将会详细分析）。
4. 易实现。基于X Constellation的框架和协议，就可轻松解决跨链的原子性、有效性、资产守恒性的多个难点。

X-Constellation按照多签名的实现方式，又细分了为多签的账号模式和合约模式。他们的基本功能都是一致，都是解决由多私钥控制一个账号的问题，但因其实现方式的不同，我们拆分为这两个模式。根据不同的应用场景，XChain会适配不同的应用模式。

3.1多签账号模式

在XChain和其他链如Bitcoin的账本里，账号本身支持有多重签名的概念，目的是为了实现分散控制账号的功能。如‘联合地址’X，假设有N个人分别持有N个私钥，只要其中M个人同意签名就可以动用某个X的资金。如下图所示：

其过程如下：

1、创建联合账号X，由指定四人控制，操作门限为2/3.

2、公证人之间针对某一个提案签名，并传递给其他公证人，其他人校验提案的合法性并依次签名。

3、当达到门限后，即可向区块链网络广播该交易

4、区块链打包后，达到了X的签名门限，并给Charlie转账。

这种方式抵御单个私钥丢失或被盗的风险，保证账号的安全。这种账号模式的公证人多签名的机制，简单有效，但是其功能单一，没有办法实现更复杂的业务逻辑功能。

3.2多签合约模式

在XChain以及其他支持智能合约的链（如Ethereum）里，通过合约可以实现类似多签名的业务功能，并且可以实现更丰富的业务逻辑，例如动态设置资产兑换比率等。

其过程如下：

1. 创建一个联合合约，业务逻辑为由2/3的人确认同一个提案，则该提案有效，并触发转账资产转移。
2. 公证人1~3分别发起同一个提案交易。
3. 合约接收了三笔交易，并触发执行，达到门限后，自动触发实现好的业务逻辑，转账给Charlie 一定的资产。

相比账号模式的公证人，合约模式更加灵活，可实现较多的跨链互操作业务。

X-Constellation在设计方案上，采用的多签名机制的公证人方案，针对有合约的链将优先使用多签合约模式，其次使用多签账号模式。下面我们将分析X-Constellation的架构设计，以及对原有多签公证人的方案上做的优化与改进。

四、X Constellation

4.1框架图

正常情况下，在实现跨链功能尤其涉及到多条链时，需要适配每条链，这样肯定会带来复杂的工作量，为了减轻这种工作量，我们将定义一套跨链协议，用来简化跨链流程。同时我们设计了一套可复用的X-Constellation框架，基于这套框架和协议，可以快速、方便的实现任意两条链的跨链互操作。

自上而下的顺序依次为：

1. APP Layer（应用协议层）。即跨链的交互操作，我们设计完整的交互协议流程，保证资产安全，原子性的转移到其他链中。例如强制用户填写目标链的账户、金额；超时或出错回退余额机制等。
2. Xsiness Layer（业务层）。XChain设定跨链交易为一个提案，业务层主要用于校验提案。例如检测提案合法性，自身是否已经提案；签名提案并发起交易提案。
3. Data Layer（数据层）。XChain 设计的区块和交易的校验。POW的六个块确认；交易的合法性检查等。
4. Network Layer（网络适配层）。用于连接区块链节点获取区块数据，或者连接其他公证人用于获取多重账号签名交易等。

4.2 跨链协议

         制定一套协议有利于快速实现跨链的功能对接，正如TCP/IP协议族一样，互联网之所以能快速发展，是因为其完善的协议族，例如基于TCP/IP而产生的HTTP协议，FTP协议，SSL协议等，这些协议丰富了互联网的资源，让开发者在开发软件时，只关心上层应用，而不用关心网络通讯层的实现。

         上图中的架构中网络适配、数据、业务层，则认定为物理层、数据层、网络层，他们主要的功能是用于寻址、路由。而网络层之上需要更加丰富的应用协议，才能支撑各种丰富的业务场景实现。我们定义了基本的跨链协议类型，通具备通用性，如下几个点：

• 资产转移。需要校验发起者资产的合法性，目标信息的合法性，交易摘要等。
• 资产兑换。需要校验发起者资产的合法性，目标信息合法性，兑换比例，交易摘要等
• 其他信息传递。透传其他任何区块链信息，校验交易摘要。

4.3 可扩展性

我们之前提到的多签模式分为账号模式和合约模式，考虑到账号模式的局限性，以上协议类型为最基本的。而基于合约的模式，我们可以更加灵活的扩展丰富业务功能。

• 公证人选举。公证人的选举可以使用DPOS方式进行投票选举，防止某些公证不作为或者作恶。
• 跨链防火墙。如同网络防火墙一样，可以限制某些资产的跨链流通，或者规避有风险的用户进行跨链转移。
• 跨链费用与激励。公证人可以通过费用协议设置跨链费用，并以此激励公证人。
• 其他任意用户自定义。

当然这些都是基于合约的可选模块，是一种可插拔模块，任何情况下，只要用户需要，可以随时热插拔的使用这些功能进行相应的操作。

五、小结

         如同二十世纪七八十年代的网络，在TCP/IP出现之后，才能解决区块链的价值孤岛问题，让资产自由流通。而XChain也正有至于推动价值孤岛的互联互通，本文就X Constellation跨链方案进行详细的阐述和分析，也希望有更多的开发者加入XCore的团队之中，为区块链的技术发展贡献力量。