CN111556133A - 区块链共识方法、系统及计算机存储介质、电子设备 - Google Patents

区块链共识方法、系统及计算机存储介质、电子设备 Download PDF

Info

Publication number
CN111556133A
CN111556133A CN202010337072.0A CN202010337072A CN111556133A CN 111556133 A CN111556133 A CN 111556133A CN 202010337072 A CN202010337072 A CN 202010337072A CN 111556133 A CN111556133 A CN 111556133A
Authority
CN
China
Prior art keywords
block
consensus
stage
hash
phase
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.)
Granted
Application number
CN202010337072.0A
Other languages
English (en)
Other versions
CN111556133B (zh
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.)
Bubi Beijing Network Technology Co ltd
Original Assignee
Bubi Beijing Network 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 Bubi Beijing Network Technology Co ltd filed Critical Bubi Beijing Network Technology Co ltd
Priority to CN202010337072.0A priority Critical patent/CN111556133B/zh
Publication of CN111556133A publication Critical patent/CN111556133A/zh
Application granted granted Critical
Publication of CN111556133B publication Critical patent/CN111556133B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • 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
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • 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
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1051—Group master selection mechanisms
    • 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
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

区块链共识方法、系统及计算机存储介质、电子设备，包括：区块BlockN的共识进入Confirm阶段后，BlockN+1进入Propose阶段；BlockN进入Commit阶段后，BlockN+1进入Confirm阶段，BlockN+2进入Propose阶段；BlockN、BlockN+1、BlockN+2依次执行；并发共识过程中，前一区块的完成某一阶段后，后一区块开始该阶段；在本轮并发共识完成后，将最新共识完成的区块BlockN+2设为稳定区块；下一轮并发共识从稳定区块开始。本申请多个区块的共识流程并发处理，提高了共识性能，且不需要额外的Checkpoint机制。

Description

区块链共识方法、系统及计算机存储介质、电子设备
技术领域
本申请涉及区块链技术，具体地，涉及一种区块链共识方法、系统及计算机存储介质、电子设备。
背景技术
在区块链领域中，共识算法是区块链的关键部分，各节点通过共识达成一致,接收并认可一致的区块，然后执行区块中包含的交易，生成一致的新状态；共识算法被设计于有不可靠节点的网络中，不可靠的节点通常包括拜占庭节点，即节点可能会作恶或出现故障，共识算法在这样的网络中实现了可靠性。可以容忍拜占庭节点的共识算法称为拜占庭容错共识算法。
拜占庭容错共识算法由于其高性能和强一致的特性逐渐成为区块链领域中主流的共识算法。拜占庭容错共识算法主要有PBFT(Practical Byzantine Fault Tolerance)、Tendermint。
PBFT算法是最早的拜占庭容错算法，是一种传统的基于消息传递的分布式一致性算法，PBFT虽然支持并发处理提案，但是需要额外的Checkpoint机制来保证所有副本节点维持相同进度。
Tendermint算法是一种适用于区块链的拜占庭容错共识算法，采用与PBFT类似的Pre-Vote和Pre-Commit两阶段投票过程来达成共识，一个区块打包完成才能接着打包下一个区块，不具备Responsiveness特性，也不支持并发打包区块，性能无法达到最优。
现有技术中存在的问题：
Tendermint算法不支持并发打包区块，PBFT算法虽然支持并发打包区块，但需要额外的Checkpoint机制来保证所有副本节点维持相同进度。
发明内容
本申请实施例中提供了一种区块链共识方法、系统及计算机存储介质、电子设备，以解决上述技术问题。
根据本申请实施例的第一个方面，提供了一种区块链共识方法，包括如下步骤：
区块BlockN的共识进入确认Confirm阶段后，后一区块BlockN+1进入提案Propose阶段；
BlockN进入提交Commit阶段后，BlockN+1进入Confirm阶段，后一区块BlockN+2进入Propose阶段；
BlockN、BlockN+1、BlockN+2依次执行；
并发共识过程中，前一区块的完成A阶段后，后一区块开始A阶段；所述A阶段为提案Propose阶段、确认Confirm阶段、或提交Commit阶段；
在本轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，将最新共识完成的区块BlockN+2设置为稳定区块StableBlock；下一轮并发共识从所述StableBlock开始。
根据本申请实施例的第二个方面，提供了一种区块链共识系统，包括：共识阶段控制模块以及稳定区块设置模块；其中，
共识阶段控制模块，用于控制区块BlockN的共识进入确认Confirm阶段后，后一区块BlockN+1进入提案Propose阶段；BlockN进入提交Commit阶段后，BlockN+1进入Confirm阶段，后一区块BlockN+2进入Propose阶段；BlockN、BlockN+1、BlockN+2依次执行；并发共识过程中，前一区块的完成A阶段后，后一区块开始A阶段；所述A阶段为提案Propose阶段、确认Confirm阶段、或提交Commit阶段；
稳定区块设置模块，用于在本轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，将最新共识完成的区块BlockN+2设置为稳定区块StableBlock；下一轮并发共识从所述StableBlock开始。
根据本申请实施例的第三个方面，提供了一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述方法的步骤。
根据本申请实施例的第四个方面，提供了一种电子设备，包括存储器、以及一个或多个处理器，所述存储器用于存储一个或多个程序；所述一个或多个程序被所述一个或多个处理器执行时，实现如上所述的方法。
采用本申请实施例中提供的区块链共识方法、系统及计算机存储介质、电子设备，提供即时确认的同时，多个区块的共识流程并发处理，提高了共识的性能，高效稳定；且每轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，设置稳定区块StableBlock，系统进入Stable状态，避免了副本节点在长时间共识后导致序号不一致，需要额外的Checkpoint机制(PBFT中用来定期同步所有节点序号的机制)来达成序号一致。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1示出了本申请实施例一中区块链共识方法实施的流程示意图；
图2示出了本申请实施例二中区块链共识系统的结构示意图；
图3示出了本申请实施例四中电子设备的结构示意图；
图4示出了本申请实施例五中区块链并发共识架构示意图；
图5示出了本申请实施例五中基于一致性的hash的Leader选举机制示意图；
图6示出了本申请实施例五中基于区块链的并发共识方法的流程示意图。
具体实施方式
本申请实施例的符号表达式和名词定义如下：
R1,R2,R3,R4：表示副本节点；
BlockN：N为序号，BlockN表示第N个区块；
StableBlockN-1：表示第N-1个区块为已完成共识的稳定区块；
ProposeN：N表示区块序号，ProposeN为BlockN的Propose消息；
ConfirmN：N表示区块序号，ConfirmN为BlockN的Confirm消息；
CommitN：N表示区块序号，CommitN为BlockN的Commit消息；
视图：表示某个副本节点做为主节点的共识期限，共识完成后视图号递增；
Func(x)：表示对x进行Func功能的操作，比如Hash(Tx)表示对交易进行Hash运算；
Qsize：表示法定集合数，共识状态机收到该数量的消息后即可进入下一状态。
为了使本申请实施例中的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
实施例一
图1示出了本申请实施例一中区块链共识方法实施的流程示意图。
如图所示，所述区块链共识方法包括：
步骤101、区块BlockN的共识进入确认Confirm阶段后，后一区块BlockN+1进入提案Propose阶段；
步骤102、BlockN进入提交Commit阶段后，BlockN+1进入Confirm阶段，后一区块BlockN+2进入Propose阶段；
步骤103、BlockN、BlockN+1、BlockN+2依次执行；
并发共识过程中，前一区块的完成A阶段后，后一区块开始A阶段；所述A阶段为提案Propose阶段、确认Confirm阶段、或提交Commit阶段；
步骤104、在本轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，将最新共识完成的区块BlockN+2设置为稳定区块StableBlock；下一轮并发共识从所述StableBlock开始。
采用本申请实施例中提供的区块链共识方法，提供即时确认的同时，多个区块的共识流程并发处理，提高了共识的性能，高效稳定；且每轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，设置稳定区块StableBlock，系统进入Stable状态，避免了副本节点在长时间共识后导致序号不一致，需要额外的Checkpoint机制(PBFT中用来定期同步所有节点序号的机制)来达成序号一致。
在一种实施方式中，所述方法进一步包括：
若任一区块的任一共识阶段处理失败、或者、区块提案者Leader不作为或作恶，清除共识状态以及当前区块后的区块共识消息，并进行视图切换；
在视图变更的区块打包完成后开始下一轮并发共识。
在一种实施方式中，所述清除共识状态以及当前区块后的区块共识消息，并进行视图切换，包括：
设置视图变更标识，选取当前未完成的区块中区块高度最低的区块高度作为视图变更的区块高度；
根据视图变更的区块高度BlockHeight及其所处的阶段Phase，清除所有未进入Commit阶段的区块的共识消息；
节点创建VIEW-CHANGE消息，当Leader接收到Qsize个VIEW-CHANGE消息后，根据区块高度BlockHeight和交易集合的hash值Hash(TxSet)创建合法证明ViewChangeSet，并根据所述合法证明构建NEW-VIEW消息并广播，节点状态进入下一视图。
在一种实施方式中，并发共识过程中，根据最新StableBlock的区块hash以及当前视图号v计算哈希h值在hash虚拟圆环上的位置；根据h值在所述虚拟圆环上的位置确定当前视图的区块提案者Leader；
其中，每个节点在hash虚拟圆环上预先分配有一段空间；所述虚拟圆环为整个hash空间。
在一种实施方式中，所述根据哈希h值在所述虚拟圆环上的位置确定当前视图的区块提案者Leader，包括：
Figure BDA0002467043420000061
其中，N为节点个数；R0、Ri、RN-1为所选取的区块提案者Leader。
在一种实施方式中，所述方法进一步包括：
增大或缩小节点在hash虚拟圆环上分配的空间。
实施例二
基于同一发明构思，本申请实施例提供了一种区块链共识系统，该装置解决技术问题的原理与一种区块链共识方法相似，重复之处不再赘述。
图2示出了本申请实施例二中区块链共识系统的结构示意图。
如图所示，所述区块链共识系统包括：共识阶段控制模块以及稳定区块设置模块；其中，
共识阶段控制模块，用于控制区块BlockN的共识进入确认Confirm阶段后，后一区块BlockN+1进入提案Propose阶段；BlockN进入提交Commit阶段后，BlockN+1进入Confirm阶段，后一区块BlockN+2进入Propose阶段；BlockN、BlockN+1、BlockN+2依次执行；并发共识过程中，前一区块的完成A阶段后，后一区块开始A阶段；所述A阶段为提案Propose阶段、确认Confirm阶段、或提交Commit阶段；
稳定区块设置模块，用于在本轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，将最新共识完成的区块BlockN+2设置为稳定区块StableBlock；下一轮并发共识从所述StableBlock开始。
采用本申请实施例中提供的区块链共识系统，提供即时确认的同时，多个区块的共识流程并发处理，提高了共识的性能，高效稳定；且每轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，设置稳定区块StableBlock，StableBlock是一个区块高度值，设置在共识模块当中，表示系统当前达到确定状态的最新区块高度。稳定区块是所有节点协调一致的体现，为并发共识提供了一种协同机制，所有节点设置了相同的StableBlock，下一轮的并发共识才正常进行。设置了StableBlock，等于在所有节点之间加了一个协调同步的机制，使得整个系统进入Stable状态，避免了副本节点在长时间共识后导致序号不一致，需要额外的Checkpoint机制(PBFT中用来定期同步所有节点序号的机制)来达成序号一致。
在一种实施方式中，所述系统进一步包括：
异常处理模块，用于若任一区块的任一共识阶段处理失败、或者、区块提案者Leader不作为或作恶，清除共识状态以及当前区块后的区块共识消息，并进行视图切换；在视图变更的区块打包完成后开始下一轮并发共识。
在一种实施方式中，所述系统进一步包括：
Leader选取模块，用于并发共识过程中，根据最新StableBlock的区块hash以及当前视图号v计算哈希h值在hash虚拟圆环上的位置；根据h值在所述虚拟圆环上的位置确定当前视图的区块提案者Leader；其中，每个节点在hash虚拟圆环上预先分配有一段空间；所述虚拟圆环为整个hash空间。
在一种实施方式中，所述系统进一步包括：
空间分配模块，用于增大或缩小节点在hash虚拟圆环上分配的空间。
实施例三
基于同一发明构思，本申请实施例还提供一种计算机存储介质，下面进行说明。
所述计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如实施例一所述区块链共识方法的步骤。
采用本申请实施例中提供的计算机存储介质，提供即时确认的同时，多个区块的共识流程并发处理，提高了共识的性能，高效稳定；且每轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，设置稳定区块StableBlock，系统进入Stable状态，避免了副本节点在长时间共识后导致序号不一致，需要额外的Checkpoint机制(PBFT中用来定期同步所有节点序号的机制)来达成序号一致。
实施例四
基于同一发明构思，本申请实施例还提供一种电子设备，下面进行说明。
图3示出了本申请实施例四中电子设备的结构示意图。
如图所示，所述电子设备包括存储器301、以及一个或多个处理器302，所述存储器用于存储一个或多个程序；所述一个或多个程序被所述一个或多个处理器执行时，实现如实施例一所述的区块链共识方法。
采用本申请实施例中提供的电子设备，提供即时确认的同时，多个区块的共识流程并发处理，提高了共识的性能，高效稳定；且每轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，设置稳定区块StableBlock，系统进入Stable状态，避免了副本节点在长时间共识后导致序号不一致，需要额外的Checkpoint机制(PBFT中用来定期同步所有节点序号的机制)来达成序号一致。
实施例五
为了便于本申请的实施，本申请实施例以一具体实例进行说明。
本申请实施例提供了一种基于区块链的并发共识方法，角色包含：区块的提案者Leader、参与共识的副本节点Replica、故障或作恶节点Fault。这些节点通过三个阶段提案(Propose)、确认(Confirm)、提交(Commit)进行两轮投票达成共识。
图4示出了本申请实施例五中区块链并发共识架构示意图。
如图所示，假设系统中包括R1、R2、R3、R4四个节点，当前的稳定区块为上一轮并发共识的最后完成共识的区块BlockN-1；
每轮共识三个提案逐步并发进行：
第一列，区块N进入Propose阶段；
第二列，BlockN的共识进入Confirm阶段后，BlockN+1进入Propose阶段；
第三列，BlockN进入Commit阶段后，BlockN+1进入Confirm阶段，BlockN+2进入Propose阶段；
第四列，BlockN+1进入Commit阶段，BlockN+2进入Confirm阶段；
第五列，BlockN+2进入Commit阶段。
BlockN、BlockN+1、BlockN+2将依次执行，即使有交易依赖也不会产生交易冲突。在一轮共识完成后，将最新共识完成的区块BlockN+2设置为稳定点StableBlock，新一轮并发共识将从StableBlock开始。
并发共识过程中，只有前一个区块的某个阶段完成，后一个区块的相同阶段才能开始。例如BlockN的Propose完成后才会开启BlockN+1的Propose阶段处理，因为BlockN+1需要依赖BlockN的状态确定，而BlockN的Propose阶段完成，相当于交易执行顺序已经确定，且BlockN的交易执行后系统的状态已经确定，该状态可以被ProposeN+1消息引用。并且，同一时刻各个区块的共识都只会在各自所属的阶段处理，不会开始下一个阶段，例如，BlockN在Commit阶段处理的时候，BlockN+1肯定在Confirm阶段，BlockN+2一定在Propose阶段，因为BlockN+1进入下一个阶段依赖与BlockN的Commit阶段完成，BlockN+2进入下一个阶段也依赖于BlockN+1的Confirm阶段完成。相邻区块共识阶段之间的“链式”启动提高了共识效率，同时也避免了过早开始新的共识阶段，加大网络中的通信压力；一旦某个区块的某个共识阶段处理失败，或者Leader不作为或者作恶，最终都将导致区块打包没有按时完成，可以直接执行清除操作ClearConsensusStatus，清除当前区块之后区块共识消息，然后进行视图切换ViewChange，等视图变更的区块打包完成再开始新一轮的并发共识。
与PBFT不同的是，StableBlock的设定，使得每轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，系统进入Stable状态，避免了副本节点在长时间共识后导致序号不一致，需要额外的Checkpoint机制(PBFT中用来定期同步所有节点序号的机制)来达成序号一致。同时三个区块并发的执行可以提高共识的性能。
本申请实施例采用一致性hash方式选取Leader节点，将整个hash空间组织成一个虚拟圆环，为N个节点各自分配一段hash空间，比如第i个节点Ri的范围是
Figure BDA0002467043420000101
通过计算h＝Hash(LastBlockHash,v)落在那个节点的范围来确定当前视图的Leader，LastBlockHash为最新StableBlock的区块hash，v为当前视图号。这种分配方式可以描述为：
Figure BDA0002467043420000102
假设系统中有4个节点，即N等于4，当前区块高度为1000，视图号为1001，序号为2的节点想知道自己是否是Leader，执行以下步骤：
首先，将N和i代入公式
Figure BDA0002467043420000103
可得：
Figure BDA0002467043420000104
由此确认自己在hash环上所占的空间为[1073741824，2147483648)；
然后计算出Hash(1000,1001)＝1073741825(Hash运算结果可转换为数值)，该结果正好落在自己所占的空间内，由此判断，自己是当前区块链高度1000，视图1001的Leader节点，发起共识提案开始共识。
图5示出了本申请实施例五中基于一致性的hash的Leader选举机制示意图。
如图所示，假设整个hash空间形成一个虚拟圆环，每个节点在该圆环上预先分配有一段hash空间，计算h＝Hash(LastBlockHash,v)落在那个节点的范围来确定当前视图的Leader，其中，LastBlcokHash为最新StableBlock的区块hash，v为当前视图号。
系统中有4个节点R1,R2,R3R4，所述R1,R2,R3R4在hash环上的边界范围LR1,LR2,LR3,LR4分别为：
Figure BDA0002467043420000111
Figure BDA0002467043420000112
根据Leader的选取规则，hash值落在哪个节点所属hash空间上哪个节点就是该视图的Leader，如图所示，一轮并发共识产生的三个视图v,v+1,v+2的Leader分别是R1,R2,R3。
Leader的选举机制通过固定的计算公式完成，但每个节点在hash环上的空间可以由其他模块来设置，增加了Leader选举的灵活性，比如可以通过缩小Replica在hash环上的空间自动降低下一轮其成为Leader节点的概率，提高系统可用性。
图6示出了本申请实施例五中基于区块链的并发共识方法的流程示意图。
如图所示，包括以下步骤：
步骤S10，Replica收集并广播交易，BlockN的Leader发送的ProposeN消息。
步骤S20，Replica接收并处理ProposeN消息，处理完成发送ConfirmN消息,同时BlockN+1的Leader发送ProposeN+1消息。
步骤S30，Replica接收并处理ConfirmN、ProposeN+1消息，处理完成发送CommitN、ConfirmN+1消息，同时BlockN+2的Leader发送ProposeN+2消息。
步骤S40，Replica接收并处理CommitN、ConfirmN+1、ProposeN+2消息，处理完成执行BlockN的交易、发送CommitN+1、ConfirmN+2消息。
步骤S50，Replica接收并处理CommitN+1、ConfirmN+2消息，处理完成执行BlockN+1的交易、发送CommitN+2消息。
步骤S60，Replica接收并处理CommitN+2消息，处理完成执行BlockN+2的交易，更新StableBlock为BlockN+2。
步骤S70，如果Replica在共识过程中，发现Leader不作为或者作恶或者其他原因导致共识失败，则执行ClearConsensusStatus操作，清除没有进入Commit阶段的共识消息，执行视图变更ViewChange选举新的Leader节点。
下面详细描述步骤S10，Replica收集并广播交易，BlockN的Leader发送的ProposeN消息，包括如下步骤：
步骤S101，Replica收集用户提交过来的交易Tx，并广播到整个区块链网络。
步骤S102，Replica检查自己是否为BlockN的Leader，如果是，将收集到的交易TxSet打包成提案广播到区块链网络，即，BlockN的LeaderR1发出提案ProposeN消息；如果不是，则返回上一步骤S101，等待BlockN的LeaderR1发出提案ProposeN消息；
打包提案：<PROPOSE,v,CreateTime,BlockHeight,TxSet,LastBlockState>σi
即ProposeN，其中：
σi：Leader的签名
v:BlockN的视图号
CreateTime：区块链创建时间
BlockHeight：区块高度
TxSet：交易的有序集合
LastBlockState：最新区块的状态。
下面详细描述步骤S20，Replica接收并处理ProposeN消息，处理完成发送ConfirmN消息，同时BlockN+1的Leader发送ProposeN+1消息，包括如下步骤：
步骤S201，Replica校验ProposeN的有效性，校验包括以下内容：
签名正确；
对应的节点在本地的共识节点集之中；
消息视图v与当前状态的视图一致；
在此之前Replica没有收到过与该消息冲突的其他CONFIRM消息，判断冲突的条件是：v，BlockHeight与这条CONFIRM的相同，而TxSet不同；
区块序号正确，StableBlock<N<StableBlock+2；
步骤S202,当Replica判断ProposeN消息满足如上条件后，Replica处理ConfirmN消息，即封装ConfirmN消息并签名:
<CONFIRM,v,BlockHeight,Hash(TxSet)>σi
步骤S203，Replica发送CONFIRM消息。
步骤S204，Replica检查是否为BlockN+1的Leader，计算：
h＝Hash(LastBlockHash,v)，
假设
Figure BDA0002467043420000131
序号为i的Replica是视图v的Leader，组装并发送ProposeN+1消息，参考Propose消息组装。
下面详细描述步骤S30,Replica接收并处理ConfirmN、ProposeN+1消息，处理完成发送CommitN、ConfirmN+1消息，同时BlockN+2的Leader发送ProposeN+2消息，包括如下步骤：
步骤S301,Replica监听网络并接收ConfirmN消息，先判断该消息是否合法，然后判断消息数量是否达到Q_size个，如果是则代表BlockN确认阶段完成，发送CommitN消息：
<COMMIT,v,BlockHeight,Hash(TxSet)>σi
步骤S302,Replica接收并校验ProposeN+1的合法性，参考Propose消息的校验。
步骤S303,ProposeN+1校验合法后，发送ConfirmN+1消息。
BlockN+1进入Confirm阶段、Replica发送ConfirmN+1消息；
BlockN+2进入Commit阶段、Replica发送CommitN消息。
待BlockN+2的leaderR3发出提案ProposeN+2消息后，执行步骤40。
下面详细描述步骤S40,Replica接收并处理CommitN、ConfirmN+1、ProposeN+2消息，处理完成执行BlockN的交易、发送CommitN+1、ConfirmN+2消息，包括如下步骤：
步骤S401,接收并校验CommitN消息的合法性，参考Confirm消息的校验(仅有消息标识符COMMIT不同)；然后判断消息数量是否达到Qsize个，如果是则代表BlockN提交阶段完成，执行BlockN的交易集合TxSet，更新区块链的状态。
步骤S402，接收并校验ConfirmN+1消息的合法性，参考Confirm消息的校验；然后判断消息数量是否达到Qsize个，如果是则代表BlockN+1确认阶段完成，发送CommitN+1消息。
步骤S403，接收并校验ProposeN+2消息，参考Propose消息的校验。
上述校验都通过，则BlockN共识完成，BlockN+1进入Commit阶段，BlockN+2进入Confirm阶段，发送ConfirmN+2消息。
下面详细描述步骤S50,Replica接收并处理CommitN+1、ConfirmN+2消息，处理完成执行BlockN+1的交易、发送CommitN+2消息，包括如下步骤：
步骤S501，Replica接收并校验CommitN+1消息的合法性，参考Confirm消息的校验；然后判断消息数量是否达到Qsize个，如果是则代表BlockN+1提交阶段完成(共识完成)，执行BlockN+1的交易集合TxSet，更新区块链的状态。
步骤S502，Replica接收并校验ConfirmN+2消息的合法性，参考Confirm消息的校验，然后判断消息数量是否达到Qsize个，如果是则代表BlockN+2确认阶段完成，发送CommitN+2消息。
下面详细描述步骤S60,Replica接收并处理CommitN+2消息，处理完成执行BlockN+2的交易，更新StableBlock为BlockN+2。
步骤S601，Replica接收并校验CommitN+2消息的合法性，参考Confirm消息的校验；然后判断消息数量是否达到Qsize个，如果是则代表BlockN+2提交阶段完成(共识完成)，执行BlockN+2的交易集合TxSet，更新区块链的状态。
步骤S602更新StableBlock为BlockN+2。
下面详细描述步骤S70,如果Replica在共识过程中，如果Leader不作为或作恶或者其他原因导致共识失败，则执行ClearConsensusStatus操作，清除没有进入Commit阶段的共识消息，执行视图变更ViewChange选举新的Leader节点，包括如下步骤：
步骤S701，Leader不作为或作恶或者其他原因导致共识失败时，先设置视图变更标识，选取当前未完成的区块中，区块高度最低的(例BlockHeight)作为视图变更的区块高度，然后执行ClearConsensusStatus操作,清除所有没有进入Commit阶段的区块的共识消息：
ClearConsensusStatus(BlockHeight,Phase)
该操作根据视图变更的区块高度BlockHeight及其所处的阶段Phase，清除不同的共识消息，需要清除的共识消息详见下表：
Figure BDA0002467043420000151
Figure BDA0002467043420000161
步骤S702，节点创建视图变更VIEW-CHANGE消息：
<VIEWCHANGE,<v,BlockHeight,Hash(TxSet),ReplicaId>σi,ConfirmedSet>σi；
步骤S703，Replica监听网络并接收VIEW-CHANGE消息，判断该消息的有效性，过程如下：
a)签名正确；对应的验证节点在列表之中；
b)v比节点状态保存的视图大1；
c)当Hash(TxSet)不为空时，ConfirmedSet是该TxSet达成Confirmed状态的证据，Hash(TxSet)为空表示进行视图变更的区块尚未进入Commit阶段。
步骤S704，当Leader接收到Qsize个VIEW-CHANGE消息后，创建合法证明：
ViewChangeSet＝<v+1,BlockHeight,Hash(TxSet),ReplicaId>σ1…n
步骤S705，创建NEW-VIEW消息:
<NEW-VIEW,v+1,ViewChangeSet,ConfirmedSet>σi,ViewChangeSet>σi
广播NEW-VIEW消息后，节点状态进入v+1视图；
步骤S706，Replica监听网络并接收NEW-VIEW消息，同样判断该消息的有效性，过程如下：
a)参照VIEW-CHANGE消息检查流程对ViewChangeSet集合中的每个元素进行校验；
b)v比节点状态保存的视图大；
c)ViewChangeSet集合中元素个数必须大于等于Qsize；
当满足上述条件后，Replica节点视图状态进入v+1；
步骤S707，等待当前区块共识完成，更新StableBlock，然后重新开始新一轮的并发共识流程。
本申请实施例提出了多区块并发共识机制，提供即时确认的同时，多个区块的共识流程并发处理，高效稳定；本申请实施例还提出了基于一致性hash算法管理Leader节点选取和异常处理机制，可以通过调整节点所属的hash空间变更Leader选举规则，比如降低恶意节点成为主节点概率；此外，本申请实施例还提出了可定制的Leader节点和共识节点集合的选取机制，Leader节点选举规则变更可以用单独模块实现，共识算法的Safety和Liveness特性模块化实现，核心功能变更互不影响，Safety和Liveness特性可以分离实现。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本申请实施例中的方案可以采用各种计算机语言实现，例如，面向对象的程序设计语言Java和直译式脚本语言JavaScript等。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (12)

1.一种区块链共识方法，其特征在于，包括：
区块BlockN的共识进入确认Confirm阶段后，后一区块BlockN+1进入提案Propose阶段；
BlockN进入提交Commit阶段后，BlockN+1进入Confirm阶段，后一区块BlockN+2进入Propose阶段；
BlockN、BlockN+1、BlockN+2依次执行；
并发共识过程中，前一区块的完成A阶段后，后一区块开始A阶段；所述A阶段为提案Propose阶段、确认Confirm阶段、或提交Commit阶段；
在本轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，将最新共识完成的区块BlockN+2设置为稳定区块StableBlock；下一轮并发共识从所述StableBlock开始。
2.根据权利要求1所述的方法，其特征在于，进一步包括：
若任一区块的任一共识阶段处理失败、或者、区块提案者Leader不作为或作恶，清除共识状态以及当前区块后的区块共识消息，并进行视图切换；
在视图变更的区块打包完成后开始下一轮并发共识。
3.根据权利要求2所述的方法，其特征在于，所述清除共识状态以及当前区块后的区块共识消息，并进行视图切换，包括：
设置视图变更标识，选取当前未完成的区块中区块高度最低的区块高度作为视图变更的区块高度；
根据视图变更的区块高度BlockHeight及其所处的阶段Phase，清除所有未进入Commit阶段的区块的共识消息；
节点创建VIEW-CHANGE消息，当Leader接收到Qsize个VIEW-CHANGE消息后，根据区块高度BlockHeight和交易集合的hash值Hash(TxSet)创建合法证明ViewChangeSet，并根据所述合法证明构建NEW-VIEW消息并广播，节点状态进入下一视图。
4.根据权利要求1所述的方法，其特征在于，
并发共识过程中，根据最新StableBlock的区块hash以及当前视图号v计算哈希h值在hash虚拟圆环上的位置；根据h值在所述虚拟圆环上的位置确定当前视图的区块提案者Leader；
其中，每个节点在hash虚拟圆环上预先分配有一段空间；所述虚拟圆环为整个hash空间。
5.根据权利要求4所述的方法，其特征在于，
所述根据哈希h值在所述虚拟圆环上的位置确定当前视图的区块提案者Leader，包括：
Figure FDA0002467043410000021
其中，N为节点个数；R0、Ri、RN-1为所选取的区块提案者Leader。
6.根据权利要求4所述的方法，其特征在于，进一步包括：
增大或缩小节点在hash虚拟圆环上分配的空间。
7.一种区块链共识系统，其特征在于，包括：共识阶段控制模块以及稳定区块设置模块；其中，
共识阶段控制模块，用于控制区块BlockN的共识进入确认Confirm阶段后，后一区块BlockN+1进入提案Propose阶段；BlockN进入提交Commit阶段后，BlockN+1进入Confirm阶段，后一区块BlockN+2进入Propose阶段；BlockN、BlockN+1、BlockN+2依次执行；并发共识过程中，前一区块的完成A阶段后，后一区块开始A阶段；所述A阶段为提案Propose阶段、确认Confirm阶段、或提交Commit阶段；
稳定区块设置模块，用于在本轮并发共识Consensus(Bn,Bn+1,Bn+2)完成后，将最新共识完成的区块BlockN+2设置为稳定区块StableBlock；下一轮并发共识从所述StableBlock开始。
8.根据权利要求7所述的系统，其特征在于，进一步包括：
异常处理模块，用于若任一区块的任一共识阶段处理失败、或者、区块提案者Leader不作为或作恶，清除共识状态以及当前区块后的区块共识消息，并进行视图切换；在视图变更的区块打包完成后开始下一轮并发共识。
9.根据权利要求7所述的系统，其特征在于，进一步包括：
Leader选取模块，用于并发共识过程中，根据最新StableBlock的区块hash以及当前视图号v计算哈希h值在hash虚拟圆环上的位置；根据h值在所述虚拟圆环上的位置确定当前视图的区块提案者Leader；其中，每个节点在hash虚拟圆环上预先分配有一段空间；所述虚拟圆环为整个hash空间。
10.根据权利要求9所述的系统，其特征在于，进一步包括：
空间分配模块，用于增大或缩小节点在hash虚拟圆环上分配的空间。
11.一种计算机存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6任一所述方法的步骤。
12.一种电子设备，其特征在于，包括存储器、以及一个或多个处理器，所述存储器用于存储一个或多个程序；所述一个或多个程序被所述一个或多个处理器执行时，实现如权利要求1至6任一所述的方法。
CN202010337072.0A 2020-04-26 2020-04-26 区块链共识方法、系统及计算机存储介质、电子设备 Active CN111556133B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010337072.0A CN111556133B (zh) 2020-04-26 2020-04-26 区块链共识方法、系统及计算机存储介质、电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010337072.0A CN111556133B (zh) 2020-04-26 2020-04-26 区块链共识方法、系统及计算机存储介质、电子设备

Publications (2)

Publication Number Publication Date
CN111556133A true CN111556133A (zh) 2020-08-18
CN111556133B CN111556133B (zh) 2023-03-14

Family

ID=72003994

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010337072.0A Active CN111556133B (zh) 2020-04-26 2020-04-26 区块链共识方法、系统及计算机存储介质、电子设备

Country Status (1)

Country Link
CN (1) CN111556133B (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111931220A (zh) * 2020-09-24 2020-11-13 腾讯科技（深圳）有限公司 区块链网络的共识处理方法、装置、介质及电子设备
CN112118239A (zh) * 2020-09-03 2020-12-22 腾讯科技（深圳）有限公司 区块链共识方法及装置、电子设备、存储介质
CN112182113A (zh) * 2020-10-23 2021-01-05 网易（杭州）网络有限公司 区块链共识方法、系统、电子设备及存储介质
CN112862650A (zh) * 2021-02-24 2021-05-28 浙江蓝景科技有限公司 对象交接方法、装置和电子设备
CN112887436A (zh) * 2021-04-28 2021-06-01 支付宝(杭州)信息技术有限公司 一种共识方法、共识节点和流水线方式的区块链系统
CN113395165A (zh) * 2021-05-28 2021-09-14 网易（杭州）网络有限公司 共识流程处理方法、装置、存储介质及计算机设备
CN114090693A (zh) * 2022-01-18 2022-02-25 安徽中科晶格技术有限公司 基于拜占庭容错的区块链见证共识方法、系统、设备及存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108108967A (zh) * 2017-12-29 2018-06-01 山大地纬软件股份有限公司 面向复杂数字资产的多阶段pbft共识系统及方法
CN108492103A (zh) * 2018-02-07 2018-09-04 北京大学深圳研究生院 一种联盟区块链共识方法
US20190020729A1 (en) * 2017-07-14 2019-01-17 Alibaba Group Holding Limited Method, apparatus, and electronic device for processing consensus requests in a blockchain consensus network
US20190354518A1 (en) * 2018-05-01 2019-11-21 Michael Zochowski Chain mesh network for decentralized transaction systems
CN110493198A (zh) * 2019-07-26 2019-11-22 北京工业大学 一种基于改进PBFT算法防御区块链中Sybil攻击的方法
WO2019232789A1 (zh) * 2018-06-08 2019-12-12 北京大学深圳研究生院 一种基于投票的共识方法
CN110659988A (zh) * 2019-09-10 2020-01-07 杭州秘猿科技有限公司 区块链共识与执行的并行处理方法、装置和电子设备
CN110995439A (zh) * 2019-11-20 2020-04-10 上海链颉科技有限公司 区块链共识方法、电子装置及存储介质

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190020729A1 (en) * 2017-07-14 2019-01-17 Alibaba Group Holding Limited Method, apparatus, and electronic device for processing consensus requests in a blockchain consensus network
CN108108967A (zh) * 2017-12-29 2018-06-01 山大地纬软件股份有限公司 面向复杂数字资产的多阶段pbft共识系统及方法
CN108492103A (zh) * 2018-02-07 2018-09-04 北京大学深圳研究生院 一种联盟区块链共识方法
US20190354518A1 (en) * 2018-05-01 2019-11-21 Michael Zochowski Chain mesh network for decentralized transaction systems
WO2019232789A1 (zh) * 2018-06-08 2019-12-12 北京大学深圳研究生院 一种基于投票的共识方法
CN110493198A (zh) * 2019-07-26 2019-11-22 北京工业大学 一种基于改进PBFT算法防御区块链中Sybil攻击的方法
CN110659988A (zh) * 2019-09-10 2020-01-07 杭州秘猿科技有限公司 区块链共识与执行的并行处理方法、装置和电子设备
CN110995439A (zh) * 2019-11-20 2020-04-10 上海链颉科技有限公司 区块链共识方法、电子装置及存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CHUN-WEI CHEN,JIAN-WEI SU,TUNG-WEI KUO,KUNG CHEN: "MSig-BFT:A Witness-Based Consensus Algorithm for Private Blockchains", 《IEEE》 *
方维维，王子岳，宋慧丽，王云鹏，丁毅: "一种面向区块链的优化PBFT共识算法", 《北京交通大学学报》 *
李忠诚，黄建华，唐瑞琮，胡庆春，夏旭: "一种基于权益代表的可扩展共识协议", 《应用科学学报》 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112118239A (zh) * 2020-09-03 2020-12-22 腾讯科技（深圳）有限公司 区块链共识方法及装置、电子设备、存储介质
CN112118239B (zh) * 2020-09-03 2022-01-11 腾讯科技（深圳）有限公司 区块链共识方法及装置、电子设备、存储介质
CN111931220A (zh) * 2020-09-24 2020-11-13 腾讯科技（深圳）有限公司 区块链网络的共识处理方法、装置、介质及电子设备
CN112182113A (zh) * 2020-10-23 2021-01-05 网易（杭州）网络有限公司 区块链共识方法、系统、电子设备及存储介质
CN112862650A (zh) * 2021-02-24 2021-05-28 浙江蓝景科技有限公司 对象交接方法、装置和电子设备
CN112887436A (zh) * 2021-04-28 2021-06-01 支付宝(杭州)信息技术有限公司 一种共识方法、共识节点和流水线方式的区块链系统
CN113395165A (zh) * 2021-05-28 2021-09-14 网易（杭州）网络有限公司 共识流程处理方法、装置、存储介质及计算机设备
CN113395165B (zh) * 2021-05-28 2022-08-16 网易（杭州）网络有限公司 共识流程处理方法、装置、存储介质及计算机设备
CN114090693A (zh) * 2022-01-18 2022-02-25 安徽中科晶格技术有限公司 基于拜占庭容错的区块链见证共识方法、系统、设备及存储介质

Also Published As

Publication number Publication date
CN111556133B (zh) 2023-03-14

Similar Documents

Publication Publication Date Title
CN111556133B (zh) 区块链共识方法、系统及计算机存储介质、电子设备
US10671599B2 (en) Consensus system and method
US10922195B2 (en) Consensus system downtime recovery
CN108683539B (zh) 区块链网络的管理方法、装置、介质及电子设备
AU2019203864B2 (en) Consensus system downtime recovery
CN109525636B (zh) 基于Raft算法的区块链共识方法
CN111932257B (zh) 一种区块链并行化处理方法及装置
US20220027970A1 (en) Method and apparatus for agreement of block in blockchain network
CN111327414A (zh) 一种区块链共识方法、系统及计算机存储介质、电子设备
CN105069152B (zh) 数据处理方法及装置
WO2011018724A1 (en) Method for generating an upgrade campaign for a system
EP4195033A1 (en) Method and apparatus for upgrading blockchain system, and terminal device
US7849355B2 (en) Distributed object sharing system and method thereof
CN114422155A (zh) 提案共识执行方法、区块链系统、设备和存储介质
US20240097919A1 (en) Consensus trusted cluster changing method, computer device and computer-readable storage medium
CN112650561B (zh) 事务管理方法、系统、网络设备和可读存储介质
CN114760198B (zh) 一种基于区块链网络的共识方法、装置及系统
CN115801553A (zh) 一种基于Raft改进的共识方法及相关设备
JP7512529B2 (ja) データ処理のためのデータ処理ネットワーク
CN114710238A (zh) 纠删码算法冗余度确定方法及区块链节点
CN116846916B (zh) 数据同步方法、装置、电子设备及计算机可读存储介质
AU2019101612A4 (en) Consensus system downtime recovery
AU2019101610A4 (en) Consensus system downtime recovery
CN112306962A (zh) 计算机集群系统中的文件拷贝方法、装置及存储介质
CN114268624B (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
GR01 Patent grant
GR01 Patent grant