CN113518126A - 一种面向联盟链的交叉容错方法 - Google Patents

一种面向联盟链的交叉容错方法 Download PDF

Info

Publication number
CN113518126A
CN113518126A CN202110741103.3A CN202110741103A CN113518126A CN 113518126 A CN113518126 A CN 113518126A CN 202110741103 A CN202110741103 A CN 202110741103A CN 113518126 A CN113518126 A CN 113518126A
Authority
CN
China
Prior art keywords
group
node
leader
agenda
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110741103.3A
Other languages
English (en)
Inventor
闵炜
肖烽
张宗立
吴刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Qianhaize Jinchanrong Technology Co ltd
Original Assignee
Shenzhen Qianhaize Jinchanrong Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Qianhaize Jinchanrong Technology Co ltd filed Critical Shenzhen Qianhaize Jinchanrong Technology Co ltd
Priority to CN202110741103.3A priority Critical patent/CN113518126A/zh
Publication of CN113518126A publication Critical patent/CN113518126A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明涉及区块链应用技术领域，公开了一种面向联盟链的交叉容错方法，其包括以下步骤：Fabric中实现XRaft排序后端；各个XRaft Orderer group内选举产生自己的Leader节点，而后各group内的Leader按顺时针向下一个group发生本组的Leader标识消息；议员之间运行XRaft算法，产生自己的Leader节点。本发明可以定位到具体的故障节点，从而简单的将该故障节点隔离为Passive节点，提高了故障恢复的速度，减少了全局配置信息的变更，在小范围内进行一致性检查，降低了算法视图变更的复杂度。

Description

一种面向联盟链的交叉容错方法
技术领域
本发明涉及区块链应用技术领域，尤其涉及一种面向联盟链的交叉容错方法。
背景技术
随着区块链(Blockchain，又被称为分布式共享账本)应用范围的逐步扩大，得到了产业界和学术界的广泛关注。区块链作为分布式系统，从访问控制的角度可分为公有链、联盟链和私有链。而共识算法在分布式系统中对维护数据一致性、保证系统安全性和可靠性方面起着决定性作用。目前，在公有链中基本采用PoW等非确定算法，联盟链和私有链中主要采用PBFT系列确定性算法。然而它们都存在扩展性问题，同时传统的Paxos、Raft等算法又不适用于拜占庭容错环境，因此，我们提出一种面向联盟链的交叉容错方法来解决以上问题。
发明内容
本发明提出的一种面向联盟链的交叉容错方法,解决了背景技术中的问题。
为了实现上述目的，本发明采用了如下技术方案：
一种面向联盟链的交叉容错方法，包括以下步骤：
S1、Fabric中实现XRaft排序后端；
S2、各个XRaft Orderer group内选举产生自己的Leader节点，而后各group内的Leader按顺时针向下一个group发生本组的Leader标识消息
Figure BDA0003141447030000011
S3、议员之间运行XRaft算法，产生自己的Leader节点；
S4、Shard master集群内部故障处理，将通知该故障节点所在group的Leader重新推举新的议员节点；
S5、处理负载和故障；
所述S5具体包括：
步骤1：对于每个group维持这样一个元组<CAPACITY(k),ACTIVE DEGREE(k)，DEPENDENCY(k)>,其中CAPACITY(k)表示一段时间内第k个group收到的请求总数，ACTIVEDEGREE(k)表示第k个group单位时间内平均处理的事务，DEPENDENCY(k)表示第k组请求对shard master的依赖情况；
步骤2：系统依据公式对负载过重的group内的议员进行调整。
优选的，所述S1中包括以下步骤：
S11：实现Chain接口和ConsenterSupport接口；
S12：读取XRaft配置参数，初始化XRaft集群；
S13：在Chain接口的Order方法中，调用XRaft算法，接收消息，并在各个节点同步数据；
S14：在ConsenterSupport的BlockCutter方法中，获取XRaft的CommitLog，进行区块打包；
S15：适配Consenter、Chain及ConsenterSupport内的方法。
优选的，步骤S2包括以下步骤：
S21：如果下一个group内尚未产生Leader节点，则忽略该消息；
S22：产生Leader节点后，该组内的任何一个非Leader节点收到该消息后都转发给本组的Leader节点，Leader节点收到mgl消息后，根据已知的group配置信息和签名验证消息的合法性；
S23：验证通过后，记录group x的Leader为j，并附带t+1个成员的投票信息发往下一个组；
S24：在继续发往下一个组之前Leader节点可以把上一个组的投票信息去除，只保留自己组的投票，同时将本组的Leader信息附加在内往下传递；
S25：消息的合法性验证过程也只验证上一组的投票信息与原始签名，直至发送该消息的Leader节点收到了自己发送的mgl消息，该Leader节点可以确定其他组内已经产生Leader节点并且均已知道group x的Leader为j；
S26：Leader节点收到自己发送过的mgl消息后检查是否附带有其他group的Leader信息，如果附有其他Leader信息，则记录该信息并将附带的信息继续往下发送。
优选的，步骤S3包括以下步骤：
S31：Leader依据自己所在group内的配置信息随机产生一个节点s作为议员，并为该议员收集本组内的t+1个签名信息形成
Figure BDA0003141447030000031
S32：该消息由Leader节点发送给下一组的Leader，收到该消息的Leader节点检查消息的合法性并且如果本组内已经产生议员节点，则把该消息公布给本组的议员节点；
S33：直至Leader收到了自己发送的ms消息，则通知本组议员节点，当议员节点收集到|group|个议员信息后，则与其他group的议员共同组成逻辑上的shard master集群。
优选的，步骤S4中，议员推选算法包括以下步骤：
S41：当XRaft group内的Leader节点失效时，该组内的议员节点将报告该信息，并等待新的Leader产生；
S42：议员节点将对本组内的负载情况进行监测和其他议员节点的响应速度进行监测；
S43：当发现某个议员节点由于本组的负载响应速度变慢时，可以向负载较轻的group申请临时议员节点，该议员节点变为master组内的passive节点；
S44：当负载恢复后，该议员节点重新恢复active状态，停用临时议员节点。
优选的，所述S5中，包括以下公式：
Figure BDA0003141447030000041
score(k)＝WL(k)·e-DEPENDENCY(k) (2)
按公式(1)对每个group负载进行计算，当系统中某个group的WL(k)大于某个预置的参数α时，则说明该group负载过高，group负载过高，按公式(2)对每个group的情况进行评价，然后从k个group内选择得分较高的委派Leader节点再指定一个临时议员加入到shard master组代替负载过高的group的议员。
优选的，每个group内至少有一个节点作为议员节点；每个group内至少同时有两个节点处于正常工作状态。
优选的，步骤S3中算法为以下算法：
Figure BDA0003141447030000042
Figure BDA0003141447030000051
本发明的有益效果是：
本发明以PeerReview为基础，使得XPaxos算法的FD中只能发现当前的视图中存在故障节点的情况变为可以定位到具体的故障节点，从而简单的将该故障节点隔离为Passive节点，提高了故障恢复的速度。
本发明算法不需要在每次故障恢复环节都需要变换主节点和变更视图。只要原来的Leader节点通过peer视角证明是运行良好的，就没有必要把主节点替换掉，从而减少了全局配置信息的变更。由于节点的状态可以被检测到，在换入新的节点时，只要将Leader节点的状态完整的复制给新加入进来的节点。本发明在小范围内进行一致性检查，降低了算法视图变更的复杂度。
附图说明
图1为本发明的HLF整体架构示意图。
图2为本发明的HLF工作流程。
图3为HLF网络中的Orderer服务示意图。
图4为Orderer主要结构示意图。
图5为multiLedger的主要结构示意图。
图6为Consenter接口及其实现结构示意图。
图7为XRaft排序后端中的chainImpl类图。
图8为Sharding Orderer拓扑结构示意图。
图9为本发明的自适应shards拓扑结构。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。
参照图1-9，一种面向联盟链的交叉容错方法，包括以下步骤：
S1、Fabric中实现XRaft排序后端；
S2、各个XRaft Orderer group内选举产生自己的Leader节点，而后各group内的Leader按顺时针向下一个group发生本组的Leader标识消息
Figure BDA0003141447030000061
S3、议员之间运行XRaft算法，产生自己的Leader节点；
S4、Shard master集群内部故障处理，将通知该故障节点所在group的Leader重新推举新的议员节点；
S5、处理负载和故障；
所述S5具体包括：
步骤1：对于每个group维持这样一个元组<CAPACITY(k),ACTIVE DEGREE(k)，DEPENDENCY(k)>,其中CAPACITY(k)表示一段时间内第k个group收到的请求总数，ACTIVEDEGREE(k)表示第k个group单位时间内平均处理的事务，DEPENDENCY(k)表示第k组请求对shard master的依赖情况；
步骤2：系统依据公式对负载过重的group内的议员进行调整。
如图1所示，HLF v1.0的设计体现了高度模块化的思想。在该版本中，将Orderer排序节点(共识机制)独立出来，实现了可插拔的特点。将证书管理作为单独的服务模块，与HLF项目分离，形成了Fabric CA，用来处理证书的发放与撤销。区块链应用程序可以通过HLF提供的API来访问系统内部的逻辑结构，包括账本、交易和链码等。账本是区块链系统最核心的概念，是数据记录的实体。应用程序通过修改账本的状态，实现资产的转移。链码(其他区块链系统中也叫做智能合约)则定义了状态转移的规则，构成了区块链应用的基础。在Hyperledger Fabric中，更提出了通道(channel)的概念，将不同的应用和业务逻辑和通道相关联，实现了不同业务的隔离。这样一来，使得数据的安全性进一步的到保证。
如图2所示，HLF通过各个模块之间相互协作完成整个交易流程。在交易过程中，各个模块的协作关系。客户端程序通过Fabric平台提供的SDK调用系统底层的接口，以CA颁发的数字证书作为加入网络通道的凭证。在交易的初始阶段，首先要由客户端发起提议(Proposal)。该提议发送到有效的背书节点(Endorser)进行背书。当客户端收集到的背书响应符合背书策略之后才能构造出合法的交易请求。交易请求会被提交给排序节点(Orderer)进行进一步处理。排序节点会根据收到的交易请求进行全局排序，将符合条件的交易打包成区块。同时客户端可以利用事件监听机制来确认交易是否被成功接收。
HLF中的背书节点提供ProcessProposal方法供客户端访问，完成对交易提案的背书处理。该处理过程主要是由受信任的背书节点对交易提案进行签名。当交易收集到足够多的签名后才能被Fabric网络接受。在收到来自客户端的交易提案后，背书节点首先检查发送提案交易的客户端的证书信息是否合法，然后对交易进行模拟执行，并记录交后账本状态的变化。背书节点的工作由网络中的部分Peer节点来完成。
排序节点(Orderer)只负责排序工作。为了保证网络中所有合法交易的顺序，排序节点对于提交的交易进行全局排序，并有后端程序将交易打包成区块结构。本文所讨论的XRaft在HLF中主要起到排序后端的作用。排序节点一般情况下不关心交易的具体内容，将其透明对待。该模块主要提供Broadcast和Deliver两个远程过程调用供其他模块调用。
Committer节点的主要任务是维护区块链和账本状态，这其中包括状态、历史和索引数据等等。Committer节点定期的从Orderer节点批量获取最新的区块信息，并对这些区块进行最终确认。检查通过后执行交易，并更新相关的信息。Peer节点可以只负责背书或者提交一种角色，也可以在同一个Peer节点中同时执行这两种不同的任务。
如图3所示，在超级账本Fabric中，共识指的是网络内节点之间始终保持同样的状态，这样对于同样顺序到达的事物就能进行相同的处理。维护Fabric网络达成共识的操作包括背书、排序和验证三个阶段，其中最重要的就是排序。所有的交易在经过Committer节点验证和提交之前，都要通过排序服务获得全局的有序性。即排序服务提供了原子广播的作用。在Fabric v1.0版本中，排序服务有独立的Orderer模块来实现。Orderer本身包括三部分内容：一是通过gRPC提供对外接口，二是由账本组件来为不同通道维护的区块链结构，三是具体的排序后端。整个排序服务的在HLF网络中的位置。
Orderer对外提供了两个接口：
1)Broadcast(srv ab.AtomicBroadcast_BroadcastServer)
2)Deliver(srv ab.AtomicBroadcast_BroadcastServer)
如图4所示，其中，Broadcast将客户端的请求发送到Orderer节点进行排序操作，而Peer节点通过Deliver批量拉取排序好的区块。Orderer服务的关键结构。Orderer节点通过server对这两个接口进行了封装，其中Processor结构对通道配置进行update操作，multiLedger维护Fabric网络中的链和账本结构。
如图5所示，Orderer节点本身需要维护近期生成的区块，超级账本Fabric支持三种类型的存储格式：1)ram：将数据存储在内存中；2)file：以文件形式保存到本地；3)json：以文件形式保存，存储格式为json。Orderer节点维护的数据只包含区块链结构，不需要保存状态信息。区块链是通过multiLedger结构进行维护的，其中最主要的是chains、systemChannel、后端共识算法(插件)的调用接口Consenter、账本文件和用于签名的signer。multiLedger提供的主要方法包括对chainSupport进行访问的getChain，生成新的配置管理的NewChannelConfig以及获取系统channel ID的systemChannelID。而各种类型的账本结构都实现了Append、Height和Iterator方法，从而实现对账本的追加、获取区块总数以及迭代查询账本信息。
在本实施例中，Fabric v1.0本身提供了solo模式和kafka共识模块。如图6所示本发明在此基础上扩展了基于xraft的consenter实现。
如图7所示，相应地，Chain接口需要提供不同版本的实现。这是因为Chain和排序后端算法密切相关。Chain的start方法在Orderer启动时会被调用，进行相关信息的初始化。
XRaft排序后端实现了Chain接口，其中的simpleConsenter结构对XRaft算法进行了封装。msg是各个排序后端之间传递的消息，该消息被signer通过本地私钥进行签名。消息本身附带了数据部分的摘要信息，以保证消息在各个节点之间的传输过程中不会被篡改。
总体来说，在Fabric中实现XRaft排序后端需要以下步骤：(1)实现Chain接口和ConsenterSupport接口。(2)读取XRaft配置参数，初始化XRaft集群(默认与orderer节点对应)(3)在Chain接口的Order方法中，调用XRaft算法，接收消息，并在各个节点同步数据。(4)在ConsenterSupport的BlockCutter方法中，获取XRaft的CommitLog，进行区块打包。(5)适配Consenter、Chain及ConsenterSupport内的其他方法。
sharding算法的主要思想是把算力平均分到不同的委员会(committees)，每个委员会处理相互独立的事务(shards)。具体过程包括下面的五步：
1)标识建立和委员会组建。每个处理机本机生成一个标识，这其中包括公钥、IP以及PoW的结论。
2)确立委员会覆盖(Overlay Setup for Committees)。在这一步里，处理机之间相互通信，来发现在同一个committee内的其他处理机。
3)委员会内部共识。
4)最终共识广播。
5)随机序列生成。终止委员会(final committee)在大范围内生成一个有限的随机数集合，这些随机数被广播到全网，用作下一个阶段的PoW。
在开放的网络环境下进行sharding的难题在于各个节点没有确定的身份标识，而在联盟链等具有明确身份标识的场景下实现sharding相对简单。本节其余的部分将讨论如何在超级账本Fabric环境下对XRaft进行sharding以及相应的sharding策略。
超级账本Fabric将区块网络配置为不同的通道，根据不同的业务对象使得彼此隔离。基于此，可以构建分区账本(Shards Ledger)。将同一个通道中的事物映射到同一个Orderer group。这样通过有效的sharding策略，可以进一步提高系统的吞吐量。
由若干个基于XRaft算法Orderer节点构成shard master集群，用于对分区的元数据达成共识。Master集群定期将元数据打包成区块，形成元数据区块链。具体各个通道上的应用事务区块由各个Orderer group进行构造。
如图8所示，给出的网络拓扑结构虽然可以起到消息隔离、提高系统吞吐量的目的，但是shard master集群容易成为整个系统的瓶颈。另外，该集群负责元数据的共识，其安全性对整个系统不言而喻。如何去动态的调整shard master集群的组成，使其具有高度的自适应性和可靠性也就成了另一个值得研究的问题。也强调了动态拓扑结构相对于传统的静态主从拓扑结构的优势。本节针对此问题提出一种新的结构，如图9所示，该图中Gi表示不同的Orderer group，由实际存在的物理节点上构成，彼此互通；M表示shard master集群，该master集群是逻辑上的结构，实际服务由不同的group共同参与完成。
系统初始化时，在各个XRaft Orderer group内选举产生自己的Leader节点。而后各group内的Leader按顺时针向下一个group发生本组的Leader标识消息
Figure BDA0003141447030000111
如果下一个group内尚未产生Leader节点，则忽略该消息。产生Leader节点后，该组内的任何一个非Leader节点收到该消息后都转发给本组的Leader节点。Leader节点收到mgl消息后，根据已知的group配置信息和签名验证消息的合法性。验证通过后，记录group x的Leader为j，并附带t+1个成员的投票信息发往下一个组。为了进一步节省带宽，在继续发往下一个组之前Leader节点可以把上一个组的投票信息去除，只保留自己组的投票，同时将本组的Leader信息附加在内往下传递。消息的合法性验证过程也只验证上一组的投票信息与原始签名。直至发送该消息的Leader节点收到了自己发送的mgl消息，该Leader节点可以确定其他组内已经产生Leader节点并且均已知道group x的Leader为j。Leader节点收到自己发送过的mgl消息后检查是否附带有其他group的Leader信息。如果附有其他Leader信息，则记录该信息并将附带的信息继续往下发送。
Leader依据自己所在group内的配置信息随机产生一个节点s作为议员，并为该议员收集本组内的t+1个签名信息形成
Figure BDA0003141447030000112
该消息由Leader节点发送给下一组的Leader。收到该消息的Leader节点检查消息的合法性并且如果本组内已经产生议员节点，则把该消息公布给本组的议员节点。直至Leader收到了自己发送的ms消息，则通知本组议员节点。当议员节点收集到|group|个议员信息(包括自己)后，则与其他group的议员共同组成逻辑上的shard master集群。议员之间运行XRaft算法，产生自己的Leader节点。
Figure BDA0003141447030000121
Shard master集群内部发生故障时，将通知该故障节点所在group的Leader重新推举新的议员节点。当XRaft group内的Leader节点失效时，该组内的议员节点将报告该信息，并等待新的Leader产生。议员节点将对本组内的负载情况进行监测和其他议员节点的响应速度进行监测。当发现某个议员节点由于本组的负载响应速度变慢时，可以向负载较轻的group申请临时议员节点，该议员节点变为master组内的passive节点。当负载恢复后，该议员节点重新恢复active状态，停用临时议员节点。
在议员推选算法中，2至3行是每个group内部产生Leader节点以及议员节点。算法第4至11行是Leader节点收到ms消息的应答方案，第5行接收消息并对消息的合法性进行验证；第6至7行，如果在group内存在议员节点，则该Leader节点通知议员节点ms消息内所包含的议员节点信息；第8行，如果该group内尚未产生议员节点，则Leader只将该信息记录下来；第9至11行，如果Leader节点收到了自己发送过的消息，则通知group内的议员节点，否则继续往下一个group传递；第12至14行，如果议员节点确认所有的group均产生议员节点或者已收到通知，则加入到shard master group内。
对于负载和故障情况，对于每个group维持这样一个元组<CAPACITY(k),ACTIVEDEGREE(k)，DEPENDENCY(k)>,其中CAPACITY(k)表示一段时间内第k个group收到的请求总数，ACTIVE DEGREE(k)表示第k个group单位时间内平均处理的事务，DEPENDENCY(k)表示第k组请求对shard master的依赖情况(即发生Leader重新选举或者议员节点发生故障的次数)。系统依据以下公式对负载过重的group内的议员进行调整：
Figure BDA0003141447030000131
score(k)＝WL(k)·e-DEPENDENCY(k) (2)
按公式1对每个group负载进行计算，当系统中某个group的WL(k)大于某个预置的参数α时，则说明该group负载过高。此时按公式2对每个group的情况进行评价，然后从k个group内选择得分较高的委派Leader节点再指定一个临时议员加入到shard master组代替负载过高的group的议员作。
该过程要保证以下两点：
1)每个group内至少有一个节点作为议员节点；
2)每个group内至少同时有两个节点处于正常工作状态。
本发明以PeerReview为基础，使得XPaxos算法的FD中只能发现当前的视图中存在故障节点的情况变为可以定位到具体的故障节点，从而简单的将该故障节点隔离为Passive节点，提高了故障恢复的速度。本发明算法不需要在每次故障恢复环节都需要变换主节点和变更视图。只要原来的Leader节点通过peer视角证明是运行良好的，就没有必要把主节点替换掉，从而减少了全局配置信息的变更。由于节点的状态可以被检测到，在换入新的节点时，只要将Leader节点的状态完整的复制给新加入进来的节点。本发明在小范围内进行一致性检查，降低了XPaxos算法视图变更的复杂度。

Claims (8)

1.一种面向联盟链的交叉容错方法，其特征在于，包括以下步骤：
S1、Fabric中实现XRaft排序后端；
S2、各个XRaft Orderer group内选举产生自己的Leader节点，而后各group内的Leader按顺时针向下一个group发生本组的Leader标识消息
Figure FDA0003141447020000011
S3、议员之间运行XRaft算法，产生自己的Leader节点；
S4、Shard master集群内部故障处理，将通知该故障节点所在group的Leader重新推举新的议员节点；
S5、处理负载和故障；
所述S5具体包括：
步骤1：对于每个group维持这样一个元组<CAPACITY(k),ACTIVE DEGREE(k)，DEPENDENCY(k)>,其中CAPACITY(k)表示一段时间内第k个group收到的请求总数，ACTIVEDEGREE(k)表示第k个group单位时间内平均处理的事务，DEPENDENCY(k)表示第k组请求对shard master的依赖情况；
步骤2：系统依据公式对负载过重的group内的议员进行调整。
2.根据权利要求1所述的一种面向联盟链的交叉容错方法，其特征在于，所述S1中包括以下步骤：
S11：实现Chain接口和ConsenterSupport接口；
S12：读取XRaft配置参数，初始化XRaft集群；
S13：在Chain接口的Order方法中，调用XRaft算法，接收消息，并在各个节点同步数据；
S14：在ConsenterSupport的BlockCutter方法中，获取XRaft的CommitLog，进行区块打包；
S15：适配Consenter、Chain及ConsenterSupport内的方法。
3.根据权利要求1所述的一种面向联盟链的交叉容错方法，其特征在于，步骤S2包括以下步骤：
S21：如果下一个group内尚未产生Leader节点，则忽略该消息；
S22：产生Leader节点后，该组内的任何一个非Leader节点收到该消息后都转发给本组的Leader节点，Leader节点收到mgl消息后，根据已知的group配置信息和签名验证消息的合法性；
S23：验证通过后，记录group x的Leader为j，并附带t+1个成员的投票信息发往下一个组；
S24：在继续发往下一个组之前Leader节点可以把上一个组的投票信息去除，只保留自己组的投票，同时将本组的Leader信息附加在内往下传递；
S25：消息的合法性验证过程也只验证上一组的投票信息与原始签名，直至发送该消息的Leader节点收到了自己发送的mgl消息，该Leader节点可以确定其他组内已经产生Leader节点并且均已知道group x的Leader为j；
S26：Leader节点收到自己发送过的mgl消息后检查是否附带有其他group的Leader信息，如果附有其他Leader信息，则记录该信息并将附带的信息继续往下发送。
4.根据权利要求1所述的一种面向联盟链的交叉容错方法，其特征在于，步骤S3包括以下步骤：
S31：Leader依据自己所在group内的配置信息随机产生一个节点s作为议员，并为该议员收集本组内的t+1个签名信息形成
Figure FDA0003141447020000021
S32：该消息由Leader节点发送给下一组的Leader，收到该消息的Leader节点检查消息的合法性并且如果本组内已经产生议员节点，则把该消息公布给本组的议员节点；
S33：直至Leader收到了自己发送的ms消息，则通知本组议员节点，当议员节点收集到|group|个议员信息后，则与其他group的议员共同组成逻辑上的shard master集群。
5.根据权利要求1所述的一种面向联盟链的交叉容错方法，其特征在于，步骤S4中，议员推选算法包括以下步骤：
S41：当XRaft group内的Leader节点失效时，该组内的议员节点将报告该信息，并等待新的Leader产生；
S42：议员节点将对本组内的负载情况进行监测和其他议员节点的响应速度进行监测；
S43：当发现某个议员节点由于本组的负载响应速度变慢时，可以向负载较轻的group申请临时议员节点，该议员节点变为master组内的passive节点；
S44：当负载恢复后，该议员节点重新恢复active状态，停用临时议员节点。
6.根据权利要求1所述的一种面向联盟链的交叉容错方法，其特征在于，所述S5中，包括以下公式：
Figure FDA0003141447020000031
score(k)＝WL(k)·e-DEPENDENCY(k) (2)
按公式(1)对每个group负载进行计算，当系统中某个group的WL(k)大于某个预置的参数α时，则说明该group负载过高，group负载过高，按公式(2)对每个group的情况进行评价，然后从k个group内选择得分较高的委派Leader节点再指定一个临时议员加入到shardmaster组代替负载过高的group的议员。
7.根据权利要求6所述的一种面向联盟链的交叉容错方法，其特征在于，每个group内至少有一个节点作为议员节点；每个group内至少同时有两个节点处于正常工作状态。
8.根据权利要求1所述的一种面向联盟链的交叉容错方法，其特征在于，步骤S3中算法为以下算法：
Figure FDA0003141447020000041
CN202110741103.3A 2021-06-30 2021-06-30 一种面向联盟链的交叉容错方法 Pending CN113518126A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110741103.3A CN113518126A (zh) 2021-06-30 2021-06-30 一种面向联盟链的交叉容错方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110741103.3A CN113518126A (zh) 2021-06-30 2021-06-30 一种面向联盟链的交叉容错方法

Publications (1)

Publication Number Publication Date
CN113518126A true CN113518126A (zh) 2021-10-19

Family

ID=78066585

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110741103.3A Pending CN113518126A (zh) 2021-06-30 2021-06-30 一种面向联盟链的交叉容错方法

Country Status (1)

Country Link
CN (1) CN113518126A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116827966A (zh) * 2023-08-29 2023-09-29 中国兵器装备集团兵器装备研究所 一种数据处理方法与系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105159818A (zh) * 2015-08-28 2015-12-16 东北大学 内存数据管理中日志恢复方法及其仿真系统
CN109327459A (zh) * 2018-11-12 2019-02-12 崔晓晖 一种联盟区块链网络的共识方法
US20200177373A1 (en) * 2018-11-14 2020-06-04 Royal Bank Of Canada System and method for storing contract data structures on permissioned distributed ledgers
CN111901149A (zh) * 2020-06-30 2020-11-06 苏宁金融科技(南京)有限公司 自动生成和检测Fabric网络配置文件的方法及系统
CN112801778A (zh) * 2021-03-01 2021-05-14 华融融通（北京）科技有限公司 联盟式不良资产区块链

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105159818A (zh) * 2015-08-28 2015-12-16 东北大学 内存数据管理中日志恢复方法及其仿真系统
CN109327459A (zh) * 2018-11-12 2019-02-12 崔晓晖 一种联盟区块链网络的共识方法
US20200177373A1 (en) * 2018-11-14 2020-06-04 Royal Bank Of Canada System and method for storing contract data structures on permissioned distributed ledgers
CN111901149A (zh) * 2020-06-30 2020-11-06 苏宁金融科技(南京)有限公司 自动生成和检测Fabric网络配置文件的方法及系统
CN112801778A (zh) * 2021-03-01 2021-05-14 华融融通（北京）科技有限公司 联盟式不良资产区块链

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
赵会群;张隆龙;: "一种面向Fabric区块链应用软件的体系结构演化算法", 软件, no. 07, 15 July 2020 (2020-07-15) *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116827966A (zh) * 2023-08-29 2023-09-29 中国兵器装备集团兵器装备研究所 一种数据处理方法与系统
CN116827966B (zh) * 2023-08-29 2024-04-26 中国兵器装备集团兵器装备研究所 一种数据处理方法与系统

Similar Documents

Publication Publication Date Title
CN107193490B (zh) 一种基于区块链的分布式数据存储系统及方法
US10608870B2 (en) System and method for data replication using a single master failover protocol
CN111400112B (zh) 分布式集群的存储系统的写入方法、装置及可读存储介质
CN109002725B (zh) 基于区块链的数据处理系统
US9069827B1 (en) System and method for adjusting membership of a data replication group
CN112000448A (zh) 基于微服务架构的应用管理方法
US7984094B2 (en) Using distributed queues in an overlay network
CN109189751A (zh) 基于区块链的数据同步方法及终端设备
CN114301972B (zh) 一种基于云边协同的区块链节点分级部署方法和系统
CN111711526B (zh) 一种区块链节点的共识方法及系统
CN111163148B (zh) 一种区块链系统的共识状态的同步方法及相关设备
CN103488526A (zh) 在分布式系统中锁定业务资源的系统和方法
CN110557416B (zh) 一种多节点协同打块的方法及系统
CN112422341B (zh) 区块链网络的故障检测方法及相关设备
Albassam et al. DARE: A distributed adaptation and failure recovery framework for software systems
CN112650812A (zh) 一种数据分片存储方法、装置、计算机设备和存储介质
CN106796537A (zh) 计算集群中的分布式组件
US20230370285A1 (en) Block-chain-based data processing method, computer device, computer-readable storage medium
CN103164262B (zh) 一种任务管理方法及装置
CN112492022A (zh) 提高数据库可用性的集群、方法、系统及存储介质
CN113518126A (zh) 一种面向联盟链的交叉容错方法
CN114422331A (zh) 容灾切换方法、装置及系统
CN112200680B (zh) 区块链节点管理方法、装置、计算机以及可读存储介质
CN112565368B (zh) 基于区块链的海上装备自组网系统、方法和介质
CN113157450A (zh) 在区块链系统中执行区块的方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination