CN109493052B - 一种基于主链加并行多子链的跨链合约系统 - Google Patents

Abstract

本发明一种基于主链加并行多子链的跨链合约系统，是基于主链加并行多子链的跨链系统架构，子链出块后，会通过主链P2P网络广播向主链提交子链块头，子链对主链的修改信息，跨链请求/响应通知信息；所有子链的提交会形成主链块，广播到所有节点；每个节点在收到主链块后，会更新本地主链，以保持所有节点的主链数据一致；当前节点根据主链数据中的跨链请求/响应通知信息获取请求或响应当前子链的其他子链信息，直接连该其他子链节点获取请求或响应信息详情并进行处理。对于跨链转账，目的地址不是接收地址，而是跨链转账系统合约的地址，该地址是在代码中固定的、公开的，只要该地址是正确的，接收地址和金额也是正确的，跨链转账就是安全的。

Description

一种基于主链加并行多子链的跨链合约系统

技术领域

本发明涉及到区块链的扩展性方案。

背景技术

现在区块链中的每个普通节点都要：1、存储所有状态；2、串行执行所有交易；3、与其他所有机器达成共识。

针对现有区块链的扩展基本思路是：1、单个节点只存储部分状态；2、单个节点只处理部分交易； 3、只让部分节点参与共识。

请参阅图1所示，其为按用户分片的示意图。如果按用户分片，则难以处理不同分片用户之间的转账，合约也难以部署，如果部署在所有分片上，则合约状态无法一致，如果只部署在某一个分片上，又无法处理其他分片用户的请求。

请参阅图2所示，其为按合约分片的示意图。如果按合约分片，每个合约都需要能处理所有用户的交易，而每笔交易都会查看/修改用户的账户状态（例如，对于以太坊，所有交易都因消耗gas要修改账户余额，对于EOS，要修改账户的CPU/带宽/存储配额），合约是并行执行的，无法保证用户状态的一致性，此外，合约之间经常互相调用，如果分布在不同分片上，又无法调用。

而，第三个扩展思路，部分节点参与共识，会引发1%攻击，即假定有100个分片，攻击者只需要控制1%的节点，即可完全控制一个分片。

现有扩展方案主要有以太坊sharding、以太坊plasma、Cosmos Network、Polkadot、Lisk、阿希链、Zilliqa、VBFT、DPOS、Algorand、Dfinity等。

以太坊sharding：长远解决以太坊扩展问题。目前主要考虑1%攻击，分片链不能执行交易，离实际应用有较远距离。

以太坊plasma：按应用即合约分片，部分合约在侧链上存储和执行，可以将代币转至侧链，后续交易在侧链上进行，即使侧链不可信，也可以将代币安全转回主链，代表实现有Loom network的游戏链。局限是侧链必须采用UTXO模型，现实应用范围过窄，转回代币耗时过长，需要至少7天。

Cosmos Network、Polkadot：按应用分片，有一个主链，每个应用使用自己的侧链，定义主链/侧链交互协议，同时提供底层平台和工具方便第三方开发自定义的侧链。局限是子链对用户不透明，子链有1%攻击问题，两个项目都在开发中，缺乏详细介绍。

Lisk、阿希链：按应用分片，侧重于创建侧链的易用性。局限是子链对用户不透明，子链有1%攻击问题，相比Cosmos/Polkadot，侧链定制化弱。

Zilliqa：按用户分片，不同子链的链内交易（即用户和合约在同一个分片）可以并行执行。局限是不能完全并行，没有状态分片，没有跨链通信，在开发中，缺乏详细介绍。

VBFT、DPOS、Algorand、Dfinity：部分节点参与共识，同时避免1%攻击，DPOS是投票选举节点，VBFT/Algorand/Dfinity采用可验证随机选择共识节点。局限是依然受限于单机存储/处理/网络能力。

总结来说，目前可扩展性依然是一个难点，通过分片和多链进行扩展是一个基本解决思路，但关键问题是如何进行分片，如何使多链对外呈现为一个链，如何在保证安全的前提下，保持较低的跨链开销，实现线性扩展。这也正是本发明要研究和解决的问题。

发明内容

本发明的目的在于在不牺牲安全性和分布式的前提下，解决当前区块链的扩展性问题。

本发明提供一种基于主链加并行多子链的跨链合约系统，所述主链加并行多子链架构包含一条主链和N条并行子链，其中N=1….X，其中每个节点存储主链数据，所述主链数据不存储具体交易，而存储系统全局信息，至少包含跨链请求/响应通知信息；每个节点被系统初始分配存储一条子链的全部数据，每个节点还包含子链跨链消息队列；所述跨链请求/响应通知信息是对应于跨链请求/响应队列的通知，不含详情；一个用户属于且只属于某一条子链，一个节点拥有且只拥有一条子链的数据，一个用户的请求只能由拥有其数据的节点处理，该节点称为用户子链节点。

本系统提供一个跨链系统合约，所述跨链系统合约对外的接口是send方法，它的参数有源地址、目标子链、接收地址、支付金额和请求消息，所述跨链系统合约中具有一跨链系统合约的地址，该地址是一个没有私钥的固定值，该地址是在代码中固定的、公开的。

所述跨链系统合约的工作流程为：

用户首先支付给源子链的跨链系统合约，所在的源子链用户子链节点收到请求消息详情后，它会放入本地针对接收子链的跨链请求队列，在源子链出块后，源子链节点会通过主链P2P网络向主链提交源链块头信息，提交信息中还有汇聚的块中所有交易的跨链请求通知信息；各个子链向主链提交的交易会形成主链块，及包含其中的跨链通知信息，通过主链P2P网络广播到所有节点。

当接收子链目标节点收到主链块时，发现其中有源子链向接收子链的跨链请求通知，就直接连接源子链节点，获取请求信息详情，及请求的默克尔证明数据；接收子链目标节点根据本地的主链信息中包含的源子链块头和默克尔证明数据验证用户子链节点的请求信息，验证用户确实支付过后，处理请求，支付给目标地址，生成跨链响应详情信息，存入并更新跨链响应队列状态；在接收子链目标节点通过主链P2P网络向主链提交块头信息时，会提交跨链响应通知信息。

当接收子链的提交被包含到主链块中并被同步到用户子链节点时，用户子链节点直接连接接收子链目标节点，获取响应详情，包括响应的默克尔证数据；用户子链节点根据本地的主链信息中包含的接收子链块头和默克尔证明数据验证链目标节点的响应，验证通过后，更新请求队列，处理可能的失败回滚，如果接收子链支付失败，则给用户退款，最后调用用户提供的回调函数。

上述方案的优点是，对于跨链转账，目的地址不是接收地址，而是跨链转账系统合约的地址，该地址是在代码中固定的、公开的，只要该地址是正确的，接收地址和金额也是正确的，跨链转账就是安全的。

本发明系统架构还具有如下特点：

1、通用性：不仅仅可以实现跨链转账，还可以实现任何跨链消息传递。

2、可靠性：与TCP协议类似，通信是可靠的，请求一定有响应，不是单向传输。

3、安全性：任何节点都有主链信息，也即有所有子链的子链块头，可以作为所有子链的SPV客户端，可以通过Merkle Proof验证任意子链的请求/响应，而不需要信任直接连接的子链节点。

跨链通信也是高效和可扩展的，这体现在：

1、子链的跨链通信详情不发送到主链，也不在主链P2P网络传播，主链上传播的只有新请求/响应通知信息。

2、子链的跨链通信通知消息是子链块中所有交易的汇总，随子链块头一起提交给主链，没有额外的通信开销。

3、主链上没有具体交易，在一个主链块中的交易个数仅与子链个数有关，在一个共识周期中，每个子链只有一个节点提交交易到主链，交易内容只是主链修改、子链块头和汇总的跨链通知信息，所以主链的交易、网络通信、存储等都不是瓶颈。

4、子链节点独立应用主链块，直接连接邻近的其他子链节点获取请求/响应详情，这个过程是并行的、分布式的，没有节点是瓶颈。

总结来说，虽然跨链通信经由主链，但主链的负载很低，不是瓶颈，可以容纳的子链个数与主链块中可以包含的交易数有关，以块大小1MB、单笔交易1KB计算，可以容纳1024个子链，在子链个数到达该值之前，整个系统处理能力可以随子链个数增加而线性扩展。

附图说明

图1为现有技术中按用户分片的区块链拓展方式示意图。

图2为现有技术中按合约分片的区块链拓展方式示意图。

图3为本发明中使用主链加并行多子链的系统逻辑图。

图4为本发明中基于主链加并行多子链逻辑下的单个节点的架构图。

图5为本发明中基于图4中单点而部署的多点架构方案。

图6为主链和子链交互的流程图。

图7为根据交易哈希txhash和块哈希blockhash获得节点连接信息及交易和块详情的流程图。

图8为用户及用户端基于本发明主链加并行子链的架构进行转账的流程。

图9为转账交易的内部逻辑图。

图10为跨链请求及响应流程。

图11为跨链转账交易流程。

图12为本发明中部署合约的流程图。

图13为本发明中提交合约交易的流程图。

图14为节点与子链的存储示意图。

图15为节点注册的流程图。

图16为主链及子链存储示意图。

图17为账户分配与迁移流程图。

具体实施方式

请参阅图3所示，其为本发明提出的主链加多并行子链的系统逻辑图。本发明包含1条主链及n条并行子链，其中n=1….X，每个节点存储主链数据，并被系统初始分配存储某条子链的全部数据，每个节点还包含子链跨链消息队列。其中，所述主链数据不存储具体交易，而存储系统全局信息，至少包含：子链个数、子链块头、账户与子链的映射关系、合约与子链的映射关系、数据节点与子链的映射关系、验证节点与子链的映射关系、跨链请求/响应通知信息、所有合约代码、子链负载、子链是否生效等。其中，所述跨链通知消息是与子链跨链消息队列中消息详情对应的一个通知消息。每一条子链具有一个子链id，每一个节点具有一个节点id，本文中子链信息指子链id，子链位置包含子链id及源子链对应的子链节点连接信息，该子链节点连接信息存储在数据节点<->子链映射表，主要包含一个子链位于那些节点上，这些节点的IP地址和端口。

其中，所述各节点由系统初始分配的子链的全部数据包含相应子链的账户、合约及交易。该子链的全部数据中的合约，除包含合约代码，还包含合约的状态等完整信息。其中，所述子链跨链消息队列包含两类，一类是跨链请求队列，每个目标子链创建一个，存储发往目标子链的请求消息详情，不同的目标子链分成不同的队列；另一类是跨链响应队列，每个源链创建一个，存储发往源链的响应消息详情，不同的源链分成不同的队列。

所述各个节点通过P2P网络实现点对点的访问，实现上述架构方案，在网络层，除包含主链P2P外，还包含子链P2P，主链P2P网络用于子链向主链提交数据（子链块头，子链对主链的修改信息，跨链通知信息）、传播主链数据、跨链通信协调（跨链通知信息在各个节点之间的通信）。子链P2P又分为两类：子链数据P2P和子链验证P2P。存储某条子链的全部数据的各个节点通过子链数据P2P网络同步子链交易和区块。负责验证同一子链交易的各个节点通过子链验证P2P对交易和区块进行验证并签名。对于某一个节点，它可能是某个子链数据的存储者，参与子链数据P2P网络，同时可能是同一个子链或其他子链的验证者，参与子链验证P2P网络。节点的子链角色是系统初始分配的，存储者角色相对不变，而负责哪条子链的验证则是动态随机调整的，每个出块周期都不一样，这是在实现可扩展的同时保证安全，避免1%攻击的方法。

请参阅图4所示，其为本发明中单个节点的架构图。每个节点存储主链数据、被分配的子链数据及该子链的跨链消息队列。请同时参阅图5所示，其为基于图4中节点架构下的多节点部署方案。该方案中示例的列出了6个节点A、B、C、D、E、F。每个节点均存储有主链数据，其中节点A、B和C被系统初始分配存储子链x的数据，组成子链x的数据P2P网络。节点D、E和F被系统初始分配存储子链y的数据，组成子链y的数据P2P网络。该图中显示的方案包含一条主链及并行的2条x，y子链。在图中时刻，节点A、D和E负责子链x数据的验证，节点B、C和F负责子链y数据的验证。

请参阅图6所示，其为主链加并行多子链系统架构下主链和子链的交互。子链出块后，会通过主链P2P网络广播子链块头、子链对主链的修改以及跨链请求/响应通知信息的子链集。所有子链的提交会形成主链块，广播到所有节点。每个节点在收到主链块后，会更新本地主链，以保持所有节点的主链一致，根据主链块头中的跨链请求/响应通知消息通知获取请求或响应当前子链的其他子链信息，直接连接其他子链节点获取请求/响应详情并进行处理。

在此架构下，可以使用主链块头验证其他子链交易。本架构下，每个节点因为被系统初始分配存储某一条子链的全部数据，其是其对应子链的全节点，同时每个节点均存储主链数据，是其他所有子链的轻节点，每个节点是主链的全节点。默克尔证明：指一个轻节点向一个全节点发起一次证明请求，询问全节点完整的默克尔树中，是否存在一个指定的数据或者交易；全节点向轻节点返回一个默尔克证明路径，由轻节点进行计算，验证存在性。

本方案中，默克尔证明可用于验证请求/响应详情。

请参阅图7所示，其为根据交易哈希txhash和块哈希blockhash获得节点连接信息及交易和块详情的流程图。在hash中嵌入子链id值，查询是从交易hash和块hash中解析出源子链id和/或接收子链id，并根据子链id查询到子链节点连接信息，该子链节点连接信息存储在主链数据的数据节点与子链的映射关系中，主要包含一个子链位于那些节点上，这些节点的IP地址和端口。

上述方案，实际交易不通过主链完成，主链仅仅记录子链的摘要信息，极大地提高了区块链的性能，随机选取子链的验证节点，可以避免1%的共计，大大提高了安全性能。

本系统内部由主链和多条子链组成，每个节点都有主链信息，但只有一条子链的信息。然而，在用户看来，子链的概念并不存在，每个节点都只有一条链，都有关于这条链的完整信息，它的所有交互都可以通过该节点完成。传统主链的交易功能转为协调功能，由其并行的子链来处理每一笔具体的交易，由于每个节点存储了主链数据，每个用户与某个节点交互时，均可以通过主链数据中记录的系统全局信息实现最终的交易。

用户通过用户端钱包软件与某个节点交互，该节点称为直接交互节点，但该节点可能没有该用户的信息，不能处理该用户的请求。在系统中，一个用户属于且只属于某一条子链，一个节点拥有且只拥有一条子链的数据，一个用户的请求只能由拥有其数据的节点处理，该节点称为用户子链节点。用户端钱包软件、直接交互节点和用户子链节点相互配合，对用户提供一个简单的体验。

基于主链加并行多子链的架构，但对外部用户呈现为一条单链，实现对用户透明的路由，本发明设计了四种典型的交互场景，介绍其实现流程，并分析其安全特性，这四种场景是：1）转账； 2）部署合约；3）提交合约交易；4）交易/块查询。

请参阅图8所示，其为用户及用户端基于本发明主链加并行子链的架构进行转账的流程。图9为转账交易的内部逻辑图。图10为跨链请求及响应流程。图11为跨链转账交易流程。

请参阅图8所示，转账的流程包含：

S1：用户打开用户端钱包，用户端钱包接入直接交互节点，用户在用户端钱包内输入接收地址destAddr和转账金额bill。

S2：用户端钱包向与之直连的直接交互节点查询当前用户的源地址srcAddr的子链信息，及该子链的节点连接信息，和接收地址destAddr的子链信息。其中子链信息为子链id。

S3：所述直接交互节点查询本地主链信息，获取当前用户的源地址srcAddr对应的源子链srcChain的子链id以及源子链srcChain的节点连接信息和接收地址destAddr对应的接收子链destChain的子链id返回钱包。

S4：钱包检查源子链srcChain和接收子链destChain是否是同一条链，如果相同，则构造直接转账交易，否则构造跨链转账交易，并请求用户签名。

用户确认交易信息并签名，钱包发送交易给用户子链节点进行处理。

S5:用户子链节点处理请求。

请参阅图9所示，其为用户子链节点处理转账交易的内部逻辑图。用户子链节点处理具体请求。

S5-1：用户子链节点收到转账的源地址srcAddr、接收地址destAddr和转账金额bill，判断源地址srcAddr是否由当前子链负责。如果不是，则交易处理失败，返回失败的信息，如果是由当前子链负责，继续判断接收地址destAddr是否存在，如果不存在，则需要创建一个新的账户。

S5-1-1该新增账户流程：

判断目标接收地址destAddr是否存在于主链数据中，如果不存在，则分配一个destChain，用户新增主链交易set(destaddr, destChain)，将账户和子链的映射关系存储于主链数据中。

S5-2：判断源地址srcAddr、接收地址destAddr是否由当前子链负责，如果是，则直接进行转账交易，如果不是，通过跨链系统合约进行跨链转账交易。

其中，直接转账交易：为现有技术。

其中，跨链转账交易，是通过跨链系统合约来完成，请参阅图10所示，其为跨链请求/响应的流程。跨链系统合约对外的接口是send方法，它的参数有源地址srcAddr、目标子链destChain、接收地址destAddr、支付金额bill和请求消息reqMsg。跨链系统合约中具有一跨链系统合约的地址，该地址是一个没有私钥的固定值，该地址是在代码中固定的、公开的，只要该地址是正确的，接收地址和金额也是正确的，跨链转账就是安全的。

图中，链A是源子链，A节点是用户子链节点，链B是接收子链，B节点是目标接收节点，每个节点的交易均通过其所在子链进行数据提交、验证、出块和同步等，链A节点包含了节点的概念也包含了所在链的概念，文中及图中简化了共识过程，用一个节点作为代表。

用户首先支付给链A的跨链系统合约，用户所在的源子链A节点收到请求消息详情reqMsg后，它会放入本地针对接收子链destChain的跨链请求队列。在源子链A出块后，源子链A节点会通过主链P2P网络向主链提源交链A块头信息，提交信息中还有汇聚的块中所有交易的跨链请求通知信息，比如链A有向链B的请求[req,A->B]，但不含请求详情。各个子链向主链提交的交易会形成主链块，及包含其中的跨链通知信息，通过主链P2P网络广播到所有节点。

接收子链B节点收到主链块时，发现其中有链A向链B的请求通知，就直接连接链A节点，获取请求详情，及请求的默克尔证明（Merkle Proof）数据。链B节点根据本地的主链信息中包含的链A块头和默克尔证明（Merkle Proof）数据验证链A节点的请求信息，验证用户确实支付过后，处理请求，支付给目标地址，生成跨链响应详情信息，存入并更新跨链响应队列状态。在链B节点通过主链P2P网络向主链提交块头信息时，会提交跨链响应通知信息，比如链B有向链A的响应，但不含响应详情。

当链B的提交被包含到主链块中并被同步到链A节点时，链A节点直接连接链B节点，获取响应详情，包括响应的默克尔证明（Merkle Proof）数据。链A节点根据本地的主链信息中包含的链B块头和默克尔证明（Merkle Proof）数据验证链B节点的响应，验证通过后，更新请求队列，处理可能的失败回滚，如果链 B 支付失败，则给用户退款，最后调用用户提供的回调函数。

请参阅图11所示，其为用户支付的过程，用户首先支付给链A的跨链系统合约，跨链系统合约执行过程为图8所述流程，接收链A节点将A块头信息及包含的跨链请求通知信息提交至主链，主链同步时，链B发现A的跨链请求通知信息，链B连接链A，请求获取请求详情，及请求的Merkle Proof数据。链B节点在使用Merkle Proof验证用户确实支付后，支付给目标接收地址，生成跨链响应通知信息，链B出块，并将块头信息及跨链响应通知信息提交至主链，主链同步时，链A节点连接链B，获取响应详情，及请求Merkle Proof数据，链A收到响应详情后，同样使用Merkle Proof验证链B的响应，如果链B支付失败，则给用户退款。

在上述关于转账的流程中，看上去引入了一些安全问题。在没有引入多链技术时，用户不需要查询任何信息就可以离线构造交易并签名，不需要信任钱包软件和任何节点。而在上述流程中，看上去则需要信任钱包和直接交互节点，其实，这不是必须的，下面分别分析下直接交互节点和钱包作恶的可能。

如果直接交互节点是恶意的，它返回给钱包的信息是错误的，比如srcAddr和destAddr实际位于同一子链但返回的是不同子链，或者srcAddr和destAddr实际位于不同子链但返回的是同一子链，在这两种情况下，处理转账的节点都会验证子链信息并拒绝交易，即使个别节点同意交易也不会取得多数共识。如果返回的srcAddr对应的子链节点连接信息有误，钱包可能连接不上，也可能把签名后的交易发送给错误节点，该节点会拒绝交易，即使同意，也不会取得多数共识。总结来说，与没有引入多链技术时一样，用户不需要信任直接交互节点，如果该节点是恶意的，转账可能会失败，但用户的资产是安全的。

在高安全性的场景中，钱包软件没有私钥，它只是负责构造待签交易，待签交易通过离线的方式发给用户，用户在高安全的环境中签名，再将签名后的交易离线发给钱包软件，钱包软件再发送到网络。在这个过程中，用户不需要信任钱包软件，它只要验证交易的接收地址和金额是正确的就可以。

在多链的情况下，需要区分直接转账和跨链转账。对于直接转账，与单链相同，用户只需验证接收地址和金额。对于跨链转账，目的地址不是接收地址，而是跨链转账系统合约的地址，用户如何确保该地址的正确性呢。答案是该地址是一个没有私钥的固定值，该地址是在代码中固定的、公开的，只要该地址是正确的，接收地址和金额也是正确的，跨链转账就是安全的。总结来说，引入多链技术后，用户也不需要信任钱包软件，但需要知道跨链转账系统合约的地址，这牺牲了一定的透明性，但在大多数日常场景中，用户的私钥一般由钱包管理，是信任钱包的，这时多链技术对用户就是透明的。

请参阅图12所示，其为部署合约的流程。合约会部署到其创建者所在的子链上，主链上会记录合约与子链的映射关系（合约A存在子链x上）。合约部署时会分析其依赖的合约，如果依赖其他子链的合约，则部署会失败。

具体流程为：用户登录用户端钱包，用户端钱包连接至直接交互节点，用户端钱包将源地址srcAddr发送至直接交互节点查询其账户的子链位置，该直接交互节点返回其对应的源子链srcChain，及源地址srcAddr对应的子链节点连接信息，及分析合约依赖关系，返回是否依赖其他子链合约的内容。用户如果收到不依赖其他子链合约的内容，则用户确认签名，部署子链完成，然后子链提交至主链，主链新增合约及合约与子链的映射关系，完成合约部署至主链。如果收到依赖其他子链合约的内容，则部署失败，返回部署失败的原因。

请参阅图13所示，其为一种提交合约交易的流程图。用户将交易请求[destAddr,req]提交至用户端钱包，用户端钱包向其直接交互节点发送查询源地址scrAddr和接收地址destAddr所在子链位置的请求及合约所在子链位置的请求。直接交互节点返回相应的源子链srcChain、源地址scrAddr对应的子链节点连接信息、接收子链destChain及是否依赖其他子链合约。如果用户属于某一个子链，而合约也属于某一个子链，如果这两个子链相同，用户子链节点就可以直接处理合约交易。如果属于不同的子链，则钱包会将合约交易修改为跨链交易，通过上述跨链系统合约，最终由用户子链节点处理。

在本系统中，请参阅图14所示，其为节点与子链的存储，主链数据中还设置两个系统配置参数，一是最少节点数-min Nodes和另一是最大节点数-max Nodes，子链对应的节点个数不小于最少节点数-minNodes才会生效，子链节点数不超过最大节点数-maxNodes。

请参阅图15，注册节点时，向主链系统合约提交注册请求，系统判断是否存在节点数小于maxNodes的子链，如果有，就将节点分配到节点数最少的子链上，否则，就扩展出一条新子链，但该子链还不生效。如果节点注册后，对应子链的节点数首次不小于minNodes，则使新子链生效。本方案中子链个数和系统能力是动态扩展的，参与节点越多，子链越多，系统能力也越强。

请参阅图16和图17所示，在主链上存储有账户和子链的映射关系，同时存储有每个子链的负载，子链的负载是根据用户、合约、交易、存储综合计算得到。出块节点定期对账户交易进行分析，对每个账户，分析其链内交易以及其他每个子链交易的交易数，获得每个子链交易频率。

账户分配和迁移的流程为：

S1：账户初始分配到负载最轻的子链上。

S2：出块节点定期对账户交易进行分析，动态迁移至交互最频繁的子链上，具体过程是：

S2-1：对每个账户，分析其链内交易以及其他每个子链交易的交易数，获得每个子链交易频率。

S2-2：判断是否迁移，迁移至哪个子链。

S2-3：如果需要迁移，提交账户迁移交易，该交易包括两部分，一是修改主链上账户与子链的映射关系，二是跨链转账至目标子链同名账户，因为是同名账户，不需要账户签名。

值得注意的是，创建过合约的账户不能迁移，不需要分析，这是因为如果账户A部署了合约C1到链X，A迁移至链Y后，如果再部署C2，且C2依赖C1，则部署会失败。

其他相同子链的节点依据同样的算法验证迁移交易，验证出块后，提交到主链，主链出块后同步到所有节点，修改主链上的映射关系，目标子链节点创建账户，完成转账。

Claims (4)

1.一种基于主链加并行多子链的跨链合约系统，其特征在于：所述主链加并行多子链架构包含一条主链和N条并行子链，其中N=1….X，其中每个节点存储主链数据，所述主链数据不存储具体交易，而存储系统全局信息，至少包含跨链请求/响应通知信息；每个节点被系统初始分配存储一条子链的全部数据，每个节点还包含子链跨链消息队列；所述跨链请求/响应通知信息是对应于跨链请求/响应队列的通知，不含详情；一个用户属于且只属于某一条子链，一个节点拥有且只拥有一条子链的数据，一个用户的请求只能由拥有其数据的节点处理，该节点称为用户子链节点；

本系统提供一个跨链系统合约，所述跨链系统合约对外的接口是send方法，它的参数有源地址、目标子链、接收地址、支付金额和/或请求消息，所述跨链系统合约中具有一跨链系统合约的地址，该地址是一个没有私钥的固定值，该地址是在代码中固定的、公开的；

所述跨链系统合约的工作流程为：

用户首先支付给源子链的跨链系统合约，所在的源子链用户子链节点收到请求消息详情后，它会放入本地针对接收子链的跨链请求队列，在源子链出块后，源子链节点会通过主链P2P网络向主链提源交链块头信息，提交信息中还有汇聚的块中所有交易的跨链请求通知信息；各个子链向主链提交的交易会形成主链块，及包含其中的跨链通知信息，通过主链P2P网络广播到所有节点；

当接收子链目标节点收到主链块时，发现其中有源子链向接收子链的跨链请求通知，就直接连接源子链节点，获取请求信息详情，及请求的默克尔证明数据；接收子链目标节点根据本地的主链信息中包含的源子链块头和默克尔证明数据验证用户子链节点的请求信息，验证用户确实支付过后，处理请求，支付给目标地址，生成跨链响应详情信息，存入并更新跨链响应队列状态；在接收子链目标节点通过主链P2P网络向主链提交块头信息时，会提交跨链响应通知信息；

当接收子链的提交被包含到主链块中并被同步到用户子链节点时，用户子链节点直接连接接收子链目标节点，获取响应详情，包括响应的默克尔证数据；用户子链节点根据本地的主链信息中包含的接收子链块头和默克尔证明数据验证链目标节点的响应，验证通过后，更新请求队列，处理可能的失败回滚，如果接收子链支付失败，则给用户退款，最后调用用户提供的回调函数。

2.如权利要求1所述的一种基于主链加并行多子链的跨链合约系统，其特征在于：

用户通过用户端钱包软件与某个节点交互，该节点称为直接交互节点；

基于上述架构的用户转账流程为：

S1：用户打开用户端钱包，用户端钱包接入直接交互节点，用户在用户端钱包内输入接收地址和转账金额；

S2：用户端钱包向与之直连的直接交互节点查询当前用户的源地址的子链信息，及该子链的节点连接信息，和接收地址的子链信息；

S3：所述直接交互节点查询本地主链数据，获取当前用户的源地址对应的源子链的子链信息以及源子链的节点连接信息和接收地址对应的接收子链的子链信息，返回钱包；

S4：钱包检查源子链和接收子链是否是同一条链，如果相同，则构造直接转账交易，否则构造跨链转账交易，并请求用户签名，用户确认交易信息并签名，钱包发送交易给用户子链节点进行处理；

S5: 用户子链节点处理转账请求。

3.如权利要求2所述的一种基于主链加并行多子链的跨链合约系统，其特征在于：

所述用户子链节点处理转账的流程是：

S5-1：用户子链节点收到转账的源地址、接收地址和转账金额，判断源地址是否由当前子链负责，如果不是，则交易处理失败，返回失败的信息；如果是，则进行下一步；

S5-2：判断源地址、接收地址是否由当前子链负责，如果是，则直接进行转账交易，如果不是，将进行跨链转账交易。

4.如权利要求3所述的一种基于主链加并行多子链的跨链合约系统，其特征在于：节点返回任何交易或区块hash的时候，在hash中嵌入子链id值，查询是从交易hash和区块hash中解析出源子链id和/或接收子链id，并根据子链id查询到子链节点连接信息，该子链节点连接信息存储在主链数据的数据节点与子链的映射关系中。

Images