CN109493051A - 可动态进行账户分配及迁移的主链加并行多子链系统架构 - Google Patents

Abstract

本发明提供一种可动态进行账户分配及迁移的主链加并行多子链系统架构，其包含一条主链和N条并行子链，每个节点存储主链数据，其包含子链负载，每个节点被系统初始分配存储一条子链的全部数据；在本系统中，账户属于哪个子链是系统动态分配的，这个分配不是固定不变的，系统会分析账户的行为，动态调度到最适合的子链上。系统有多少子链也不是固定的，可以随着节点数的增加而自动扩展，给定一个节点，它负责哪个子链也是系统动态分配的。

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，其中每个节点存储主链数据，每个节点被系统初始分配存储一条子链的全部数据；其中，所述各节点由系统初始分配存储的子链的全部数据包含相应子链的账户、合约及交易；其中，所述主链数据不存储具体交易，而存储系统全局信息，至少包含：子链个数、子链块头、账户与子链的映射关系、合约与子链的映射关系、数据节点与子链的映射关系、验证节点与子链的映射关系、跨链请求/响应通知信息、所有合约代码及子链负载；账户分配和迁移的流程为：

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

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

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

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

S2-3：如果需要迁移，提交账户迁移交易，该交易包括两部分，一是修改主链上账户与子链的映射关系，二是跨链转账至目标子链同名账户，因为是同名账户，不需要账户签名；其他相同子链的节点依据同样的算法验证迁移交易，验证出块后，提交到主链，主链出块后同步到所有节点，修改主链上的映射关系。

值得注意的是：创建过合约的账户不能迁移，不需要分析。

在本系统中，账户属于哪个子链是系统动态分配的，这个分配不是固定不变的，系统会分析账户的行为，动态调度到最适合的子链上。系统有多少子链也不是固定的，可以随着节点数的增加而自动扩展，给定一个节点，它负责哪个子链也是系统动态分配的。本发明中系统架构有如下特点：

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为发起交易的节点和目标节点之间通过默克尔证明（Merkle Proof）进行数据验证的流程图。

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

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

图11为节点与子链在主链数据中的存储。

图12为节点注册与子链拓展的基本流程图。

具体实施方式

请参阅图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地址和端口。

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

请参阅图8所示，其为跨链请求/响应的流程，为发起交易的节点和目标节点之间通过默克尔证明（Merkle Proof）进行数据验证的流程图。本发明基于上述主链加并行多子链架构，提出一跨链系统合约，该跨链系统合约对外的接口是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 支付失败，则给用户退款，最后调用用户提供的回调函数。

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

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

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

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

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

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

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

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

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

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

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

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

Claims (8)

1.可动态进行账户分配及迁移的主链加并行多子链系统架构，其特征在于：包含一条主链和N条并行子链，其中n=1….X，其中每个节点存储主链数据，每个节点被系统初始分配存储一条子链的全部数据；其中，所述各节点由系统初始分配存储的子链的全部数据包含相应子链的账户、合约及交易；其中，所述主链数据不存储具体交易，而存储系统全局信息，至少包含：子链个数、子链块头、账户与子链的映射关系、合约与子链的映射关系、数据节点与子链的映射关系、验证节点与子链的映射关系、跨链请求/响应通知信息、所有合约代码及子链负载；账户分配和迁移的流程为：

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

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

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

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

S2-3：如果需要迁移，提交账户迁移交易，该交易包括两部分，一是修改主链上账户与子链的映射关系，二是跨链转账至目标子链同名账户，因为是同名账户，不需要账户签名；其他相同子链的节点依据同样的算法验证迁移交易，验证出块后，提交到主链，主链出块后同步到所有节点，修改主链上的映射关系。

2.如权利要求1所述的可动态进行账户分配及迁移的主链加并行多子链系统架构，其特征在于：创建过合约的账户不能迁移，不需要分析。

3.如权利要求2所述的可动态进行账户分配及迁移的主链加并行多子链系统架构，其特征在于：所述主链数据设置两个系统配置参数，一是最少节点数min Nodes，另一是最大节点数max Nodes，子链对应的节点个数不小于最少节点数才会生效，子链节点数不超过最大节点数，主链数据中还包含子链是否生效的状态数据；注册节点时，向主链系统合约提交注册请求，系统判断是否存在节点数小于max Nodes的子链，如果有，就将节点分配到节点数最少的子链上，否则，就扩展出一条新子链，但该子链还不生效；如果节点注册后，对应子链的节点数首次不小于min Nodes，则使新子链生效。

4.如权利要求3所述的可动态进行账户分配及迁移的主链加并行多子链系统架构，其特征在于：其中，每个节点还包含子链跨链消息队列，所述子链跨链消息队列包含两种，一类是跨链请求队列，每个目标子链创建一个，存储发往目标子链的请求消息详情，不同的目标子链分成不同的队列；另一类是跨链响应队列，每个源链创建一个，存储发往源链的响应消息详情，不同的源链分成不同的队列； 每个节点网络层，包含主链P2P网络，子链数据P2P网络和子链验证P2P网络；其中，主链P2P网络用于子链向主链提交数据、传播主链数据、跨链通信协调；其中，存储某条子链的全部数据的各个节点通过子链数据P2P网络同步子链交易和区块；其中，负责验证同一子链交易的各个节点通过子链验证P2P网络对交易和区块进行验证并签名；所有子链的提交的数据会形成主链块，广播到所有节点，每个节点在收到主链块后，会更新本地主链，以保持所有节点的主链一致。

5.如权利要求4所述的可动态进行账户分配及迁移的主链加并行多子链系统架构，其特征在于：子链出块后，会通过主链P2P网络广播向主链提交子链块头，子链对主链的修改信息，跨链请求/响应通知信息；所有子链的提交会形成主链块，广播到所有节点；每个节点在收到主链块后，会更新本地主链，以保持所有节点的主链数据一致；当前节点根据主链数据中的跨链请求/响应通知信息获取请求或响应当前子链的其他子链信息，直接连该其他子链节点获取请求或响应信息详情并进行处理。

6.如权利要求5所述可动态进行账户分配及迁移的主链加并行多子链系统架构，其特征在于：当前节点获取跨链请求或响应信息详情时，一并请求默克尔证明数据，目标节点根据本地的主链信息中包含的当前子链块头和默克尔证明数据验证当前节点的请求信息，验证通过后，处理请求。

7.如权利要求6所述的可动态进行账户分配及迁移的主链加并行多子链系统架构，其特征在于：还包含一种跨链系统合约，该合约对外的接口是send方法， 它的参数有源地址、目标子链、接收地址、支付金额和/或请求消息，所述跨链系统合约中具有一跨链系统合约的地址，该地址是一个没有私钥的固定值，该地址是在代码中固定的、公开的；所述跨链系统合约的工作流程为：用户首先支付给源子链的跨链系统合约，所在的源子链用户子链节点收到请求消息详情后，它会放入本地针对接收子链的跨链请求队列，在源子链出块后，源子链节点会通过主链P2P网络向主链提交源链块头信息，提交信息中还有汇聚的块中所有交易的跨链请求通知信息；各个子链向主链提交的交易会形成主链块，及包含其中的跨链通知信息，通过主链P2P网络广播到所有节点；当接收子链目标节点收到主链块时，发现其中有源子链向接收子链的跨链请求通知，就直接连接源子链节点，获取请求信息详情，及请求的默克尔证明数据；接收子链目标节点根据本地的主链信息中包含的源子链块头和默克尔证明数据验证用户子链节点的请求信息，验证用户确实支付过后，处理请求，支付给目标地址，生成跨链响应详情信息，存入并更新跨链响应队列状态；在接收子链目标节点通过主链P2P网络向主链提交块头信息时，会提交跨链响应通知信息；当接收子链的提交被包含到主链块中并被同步到用户子链节点时，用户子链节点直接连接接收子链目标节点，获取响应详情，包括响应的默克尔证数据；用户子链节点根据本地的主链信息中包含的接收子链块头和默克尔证明数据验证链目标节点的响应，验证通过后，更新请求队列，处理可能的失败回滚，如果接收子链支付失败，则给用户退款，最后调用用户提供的回调函数。

8.如权利要求7可动态进行账户分配及迁移的主链加并行多子链系统架构，其特征在于：节点返回任何交易或区块hash的时候，在hash中嵌入子链id值，查询是从交易hash和块hash中解析出源子链id和/或接收子链id，并根据子链id查询到子链节点连接信息，该子链节点连接信息存储在主链数据的数据节点与子链的映射关系中。