CN113610531B - 一种共识方法、区块链系统和共识节点 - Google Patents
一种共识方法、区块链系统和共识节点 Download PDFInfo
- Publication number
- CN113610531B CN113610531B CN202111175144.7A CN202111175144A CN113610531B CN 113610531 B CN113610531 B CN 113610531B CN 202111175144 A CN202111175144 A CN 202111175144A CN 113610531 B CN113610531 B CN 113610531B
- Authority
- CN
- China
- Prior art keywords
- consensus
- message
- node
- nodes
- consensus node
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3825—Use of electronic signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Hardware Redundancy (AREA)
- Computer And Data Communications (AREA)
Abstract
一种共识方法、区块链系统和共识节点,该共识方法包括:第一轮:第一共识节点广播第一消息,第一消息中包括共识提议的交易集合和第一共识节点的签名;第二轮:接收到所述第一消息的共识节点广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;第三轮:接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后,如果自身针对该提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;共识节点收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为共识结果的至少一部分输出。
Description
技术领域
本说明书实施例属于区块链技术领域,尤其涉及一种共识方法、区块链系统和共识节点。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构,并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性,区块链也受到人们越来越多的重视和应用。
发明内容
本发明的目的在于提供一种共识方法、区块链系统和共识节点,包括:
一种区块链系统中的共识方法,包括:
第一轮:第一共识节点广播第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名;
第二轮:接收到所述第一消息的共识节点广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;
第三轮:接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后,如果自身针对该提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;
共识节点收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
一种区块链系统,包括共识节点,其中:
第一共识节点广播第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名;
接收到所述第一消息的共识节点广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;
接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后,如果自身针对该提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;
共识节点收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
一种区块链系统中的共识节点,包括:
第一消息接收单元,用于接收第一共识节点广播的第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名;
第二消息广播单元,用于当第一消息接收单元接收到所述第一消息后广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;
投票收集单元,用于收集来自于共识节点的投票;
第三消息广播单元,当投票收集单元收集到至少Quorum个来自于不同共识节点的一致的投票,如果自身针对该提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;
第三消息收集单元,收集来自于共识节点的第三消息;
输出单元,当第三消息收集单元收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
上述实施例中,在共识提议被提出时即确定对应的区块在区块链上的相对位置。而且,对于一个最终生成的区块来说,其包含一个共识提议,即对应一个共识结果的产生过程,则该共识结果不需要等待其它共识提议的结果,能够快速输出共识结果。这也就省去了在一个共识结果的生成过程中需要等待、配合其它共识提议的共识完成。对于没有提议的共识节点,也不必提出内容实际为空的共识提议,降低了网络带宽的消耗。对于无法提出共识提议的失效节点,上述实施例中只要正常工作的节点达到Quorum数量,则生成共识结果的过程并不需要HBBFT中那样超时赋值为0后再进入ABA过程,而是可以跳过该失效节点,从而可以大大降低共识的时延。
附图说明
为了更清楚地说明本说明书实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是一实施例中实用拜占庭容错算法常规阶段的示意图;
图2是一实施例中实用拜占庭容错算法视图切换阶段的示意图;
图3是一实施例中蜜獾拜占庭容错算法的示意图;
图4是本说明书一实施例中共识算法的流程图;
图5是本说明书一实施例中共识算法的示意图;
图6是本说明书一实施例中共识算法的示意图;
图7是本说明书一实施例中共识算法的示意图;
图8是本说明书一实施例中共识算法的示意图;
图9是本说明书一实施例中共识算法的示意图;
图10是本说明书一实施例中共识算法的示意图;
图11是本说明书一实施例中共识节点分布图;
图12是本说明书一实施例中共识节点架构图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本说明书保护的范围。
区块链系统中,不同参与方通过部署的节点(Node)可以建立一个分布式的区块链网络。利用链式区块结构构造的去中心化(或称为多中心化)的分布式账本,保存于分布式的区块链网络中的每个节点(或大多节点上,如共识节点)上。这样的区块链系统需要解决去中心化(或多中心化)的多个节点上各自的账本数据的一致性和正确性的问题。每个节点上都运行着区块链程序,在一定容错需求的设计下,通过共识(consensus)机制保证所有忠诚节点具有相同的交易,从而保证所有忠诚节点对相同交易的执行结果一致,并将交易及执行结果打包生成区块。当前主流的共识机制包括:工作量证明(Proof of Work,POW)、股权证明(Proof of Stake,POS)、委任权益证明(Delegated Proof of Stake,DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance,PBFT)算法,蜜獾拜占庭容错(HoneyBadgerBFT)算法等。
以PBFT为例,该算法是Miguel Castro (卡斯特罗)和Barbara Liskov(利斯科夫)在1999年提出来的,解决了原始拜占庭容错算法效率不高的问题,将算法复杂度由指数级降低到多项式级,使得拜占庭容错算法在实际系统应用中变得可行。该论文发表在1999年的操作系统设计与实现国际会议上(OSDI99)。PBFT算法中,所有的副本(replica)在一个被称为视图(View)的轮换过程(succession of configuration)中运行。在某个视图中,一个副本作为主节点(primary),其他的副本作为备份节点(backups)。视图是连续编号的整数。主节点由公式p = v mod |R|计算得到,这里v是视图编号,p是副本编号,|R|是副本集合的个数。该算法中假设,当最多存在f个副本(即节点)失效时,如果存在总数为至少3f+1个副本,就能保证在异步系统中提供安全性和活性。为了能够确保所有副本的数据一致性要求和容错要求,需要一定数量副本的集合,一般是分布式系统中的大多数节点构成的集合,构成大多数(Quorum)。例如在总节点数n为3f+1(n=3f+2或n=3f的情况一般不会对容错效果带来提升)的情况下,Quorum为2f+1。这样,对于包含四个节点的分布式系统,任意三个节点可以构成一个Quorum。
PBFT包括Normal Case Phase和View Change Phase两个过程,图1为Normal CasePhase(常规阶段)过程的流程图。Normal Case Phase中主要包括PRE-PREPARE(预准备)、PREPARE(准备)和COMMIT(提交)三个阶段,其中3号节点例如可以表示宕机的节点(图1中以×表示)。当主节点失效的时候(图2中以×表示,如更换视图前主节点Primary也就是Replica 0(副本0)失效)就需要启动视图更换(view change)过程,从而在系统存在故障时进行状态调整,更换新的主节点(如更换视图后Replica 1为主节点Primary)。图2为ViewChange Phase(视图切换)的示意图。如果主节点掉线或者作恶而不广播客户端的请求等,客户端可以设置超时机制。如果超时的话,客户端可以向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线后,也可以发起View Change协议阶段,以更换主节点(经常简称为“换主”)。此外,也可能由于主节点发起错误的提议导致PRE-PREPARE、PREPARE和COMMIT三阶段共识过程失败,或者,PREPARE、COMMIT阶段可能达不成 Quorum 数量(如3f+1个节点中的2f+1个,也称为法定数量)的一致,也都无法完成共识。这些情况下也可能发起View Change协议阶段,以更换主节点。
PBFT协议属于半同步(partial synchronous)协议,其特点是假设网络一开始是异步的,但是能够从某一时刻开始同步。要在网络中让不同节点对同一提议达成共识,最简便的方式是设置主节点,由主节点来统一各个节点的意见。通过设置定时器,可以防止主节点出错。PBFT中,如果在有限时间内没有完成 Normal Case Phase,会触发 Backups 发起View Change Phase,以更换主节点。PBFT将主节点固定在一个位置,所有请求都可以先发送到主节点,再由主节点广播到其他共识节点。除了引入额外的、将请求发送到主节点的延迟之外,主节点的出入口带宽也可能成为性能瓶颈。
PBFT这类单主节点类型的协议,在同一次共识中只有主节点能够发起共识提议,其它节点没有能力发起共识提议。或者,如果其它节点也有提议,就需要将提议转发至主节点,由主节点代为发起提议。前者对于共识节点构造区块的权力是不公平的,后者虽然备份节点也可以提议,但是会增加主节点出口带宽的压力。对于大多共识节点都需要发起共识提议的情况,两者都不是特别适合。
与此相对的,HoneyBadgerBFT(也常简称为HBBFT)算法属于一种异步(asynchronous)协议。异步协议适用于异步网络,也就是这个网络中节点间的消息可以被任意延迟,但最终会到达。HoneyBadgerBFT中去掉了定时器,而是通过消息来驱动协议的执行。同时,HoneyBadgerBFT算法中所有节点都是对等的,没有主节点和备份节点之分,也就没有换主的过程。HBBFT等异步网络共识协议无主节点的概念,各节点都可提议请求,尝试构造区块,因此异步网络协议在一定程度上缓解了公平性和单节点瓶颈的问题。
图3为HoneyBadgerBFT算法单节点角度的流程图。实际上,如前所述,HoneyBadgerBFT算法中所有节点都是对等的,也就是说,所有节点都可以执行图3所示的流程。如图3所示,从单节点的视角来看,HoneyBadgerBFT主要包括两个阶段,分别为可靠广播(Reliable BroadCast, RBC)和异步共识(Asynchronous Binary Agreement, ABA,异步二进制协议,也称为“01异步共识”)。此外,还有RBC和ABA之上的异步公共子集(AsynchronousCommon Subset,ACS)协议。RBC阶段至少包括Rval、Echo、Ready三轮消息交互,ABA阶段至少包括Bval、Aux和Coin三轮消息交互。RBC使用三轮消息交互保证可靠的提议广播。ABA首先进行两轮投票(Bval和AUX消息),然后借助抛硬币(Coin)对各节点的提议统一认识,从而绕开半同步协议对网络同步的要求。一次HoneyBadgerBFT共识,要经过RBC阶段和至少一次ABA阶段。最好的情况下,存在1/2的概率可以结束本次HoneyBadgerBFT共识过程,这样,需要经过6个轮次完成一次共识。此外,有1/4概率会进入再一次的ABA过程,如图3中第二次ABA过程(7、8、9轮次表示的ABA过程),有1/4概率会在第二轮结束,且存在至少1/4的概率可以结束本次HoneyBadgerBFT共识过程,这样,需要经过9个轮次完成一次共识。在第二次ABA过程后,整体上有1/8的概率会进入再一次的ABA过程……以此类推。
综上所述,HoneyBadgerBFT至少包括一次RBC(三轮)和一次ABA(三轮),如果ABA的投票结果与抛币结果不一致,协议进入新一轮的ABA(至少额外三轮)。抛币给共识的轮次带来不确定性,可能增加延迟。
另外,对于一个最终生成的区块(对应一个epoch)来说,一个节点可以运行一个ACS和n个RBC+n个ABA,n为共识节点个数,且其中1个RBC和ABA对应自身发起的共识提议,其它(n-1)个RBC和ABA对应其它(n-1)个节点发起的共识提议。也就是说,对于一个epoch来说,一个节点发起共识提议的同时,也会配合完成其它节点发起的共识提议。这样,对于一个节点来说,至少(n-f)个RBC结束后会将这些RBC已经完成的情况(通过Ready消息表示)发至ACS,进而由ACS为对应的ABA赋初值,启动对应的ABA过程。在至少(n-f)个共识提议完成ABA之后如果剩余的共识提议仍未完成RBC,则会被赋初值为0,进而执行该提议对应的ABA过程。从全局的视角来看,至少(n-f)个节点会执行相同的上述共识过程(至少(n-f)个不同节点发起提议的过程),并最终由ACS来收集各个提议的ABA结果后按照某种规则对ABA结果为1的提议排序后输出。
上述的过程中,与PBFT相反的,对各个参与共识的节点提出了较强的提议要求,即参与共识的节点需要在每一个epoch中都发起提议,不论这个节点是否真的有提议。如果这个节点实际上没有提议,也需要发起一个内容为空的提议请求(RBC中可以对这个空的提议请求加密,这样其他节点并不能确定这个提议的内容,以避免恶意节点因能看到提议中的内容而有选择的在BA过程中赋值输入或输出)。即使这个节点是失效节点,无法发出提议,那么在其他节点的ACS中仍然要给这个节点对应的提议留出位置。具体的,在其他节点中的每一个执行完至少Quorum个ABA过程后,如果还没有收到这个节点的提议对应RBC阶段的Quorum个Ready消息,ACS需要给这个节点的提议对应的ABA初值赋为0,进而进入ABA过程。这样,其它节点还需要配合完成这个失效节点对应提议的ABA过程。
本申请提供一种共识算法实施例,如图4所示,具体包括:
S41:【第一轮】第一共识节点广播第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名。
本申请一种共识算法实施例中,可以包括3轮的交互。与HBBFT类似的,图5所示实施例的共识算法,也属于一种异步协议,即假设网络中节点间的消息可以被任意延迟,但最终会到达。类似的,图5实施例中也去掉了定时器,通过消息来驱动协议的执行;同时,所有节点可以都是对等的,没有主节点和备份节点之分,任一共识节点都可以发起共识提议,每一个共识节点也都可以参与其他节点提起共识提议的共识过程。一次共识的结果,可以包括本次共识中所有节点提起且获得至少Quorum数量投票一致的共识提议中的交易集合的总和。
以一个节点的视角来看,例如以发起共识提议的视角来看,交互过程如图5
所示。在一次共识中,可以发起共识提议,这个共识提议中可以包括打包的交易集
合,例如标记为,中可以包括一系列的交易构成的集合{}。进而,可以广播第一消息至其它共识节点,如图5中广播至、和。广播的
第一消息中可以包括的共识提议的交易集合。这个消息可以称为Val消息。
此外,这个消息还可以包括第一共识节点对的签名,例如记为。一般地,第
一共识节点可以用自身的私钥对直接签名,得到,也可以是先对进行
hash计算,得到hash值(即摘要值),进而再用自身的私钥对该hash值签名,从而得到。
第一消息中还可以包括时间戳。这个时间戳可以是第一共识节点广播第一消息时或之前的物理时间,可以由本地时钟确定。如果区块链网络中的各个共识节点能够做到相对准确的时钟同步,第一消息中的时间戳也是接收到该第一消息的节点中相对准确的时间。
考虑到节点之间可能存在一定的物理距离,因此消息的传播存在不可忽略的延
迟,因此,第一消息中包括的时间戳,可以基于第一共识节点广播第一消息时或之前的物理
时间以及网络传输时延确定。例如在一个包括4个共识节点的区块链网络中,第一共识节点
到其它三个共识节点的平均传输时延或最大传输时延为Δ,则第一消息中的时间戳为 ,其中可以是第一共识节点广播第一消息的本地物理时间。这个Δ可以由
RTT(Round-Trip Time,往返时延)来确定,RTT一般可以表示网络中从一个发送端发送数据
至接收端开始,到该发送端收到来自该接收端的确认总共经历的时间。一般的,Δ可以是
RTT的一半。对于第一共识节点与其它三个共识节点之间的RTT不同的情况,可以取三个Δ
的平均值,或者取三个Δ的最大值,具体如Δ=或者Δ=。
Val消息的格式可以如<, , >,其中可以表示发起共识提议
的时间戳,可以表示共识提议中的交易集合。所述,可以是采用自身私钥对
包括和在内的数据的签名,也可以是先对进行hash计算,得到hash值,进而再用自
身的私钥对该hash值和在内的数据进行签名,从而得到。
例如,、、可以通过广播第二消息来告诉其他共识节点自身对
共识提议的投票,投票可以是对共识提议中的消息集合表示认可或者不认可。具体的,在第
一轮的末尾,收到Val消息的共识节点,可以计算Val消息中共识提议的交易集合的hash值。
进而,如果共识节点认可该次共识中提议的交易集合,可以在第2轮次的消息交互中
广播该hash值。相反的,如果共识节点不认可该次共识中提议的交易集合,可以在第
2轮次的消息交互中广播0。这个广播的第二消息可以记为Bval。此外,也可以是在第2轮次
的消息交互中广播该hash值的同时,用1来表示对该hash值代表的提议的认可,这只是简单
的变化。
需要说明的是,共识节点可以更改自己的观点并再次投票,即发出多个不同的
Bval消息。例如,可以首次发出内容是所述交易集合的hash值的Bval消息,以表示对
所述共识提议中的交易集合的认可,而后续可以再次发送内容是0的Bval消息,以表示对所
述共识提议中的交易集合的不认可。再例如,可以首次发出内容是0的Bval消息,以
表示对所述共识提议中的交易集合的不认可,而后续可以再次发出内容是所述交易集合的
hash值的Bval消息,以表示对所述共识提议中的交易集合的认可。
此外,第二消息中还可以包括对所述交易集合的签名。前述提到,在第一轮的末尾
接收到第一消息的共识节点可以验证接收到的第一消息的正确性,例如验证
的签名是否正确。进而,接收到第一消息的共识节点,可以用自己的私钥对第一消息中的交
易集合进行签名。例如对第一消息中的交易集合进行签名,得到;也可以是先对进行hash计算,得到hash值(即摘要值),进而再用自身的私钥对该hash值签
名,从而得到。
类似的,Bval消息的格式可以如<, hash, >,其中可以是收到的Val消
息中的,hash为的hash值,表示对的投票观点是认同。则所述,也可以是采用
自身私钥对包括和在内的数据的签名。类似的,也可以是先对进行hash计算,得到
hash值,进而再用自身的私钥对该hash值和在内的数据进行签名,从而得到。
收到发来的Val消息后,类似的,也可以计算Val消息中的的hash
值,并采用自身私钥对该hash值签名得到,进而也可以广播Bval消息。Bval消息中可
以包括计算得到的hash值以及签名,也可以是包括、hash值以及签名。
收到发来的Val消息后,类似的,也可以计算Val消息中的的hash
值,并采用自身私钥对该hash值签名得到,进而也可以广播Bval消息。Bval消息中可
以包括计算得到的hash值以及签名,也可以是包括、hash值以及签名。
S45:【第三轮】接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后,如果自身针对该提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名。
第二轮中的共识节点广播第二消息,这样,在第二轮的末尾,接收到第二消息的共识节点可以收集第二消息中的投票,进而广播第三消息。
例如,在第二轮的末尾可以收集Bval消息中的投票。假设收集到,、分别广播的Bval消息中的投票都是所述交易集合的hash值,且在第一轮中广播的Val消息中也是,其对应的hash显然也是的hash值,则在本轮次中收集到至少Quorum个一致的摘要值(例如此时f=1,Quorum=3,实际收集
到4)。
例如,在第二轮的末尾可以收集Bval消息中的投票,假设收集到、分别广播的第二消息中的投票都是所述交易集合的hash值,且在
第二轮中广播的第二消息中的投票如果也是所述交易集合的hash值(也表示对所述交
易集合的认可),且在第一轮中接收到的发出的Val消息中的也是同样的hash值,
则在本轮次中收集到至少Quorum个一致的摘要值(例如此时f=1,Quorum=3,实际收
集到4)。需要说明的是,第一轮中,广播的Val消息中可以包括,这样在第一轮的
末尾可以计算Val消息中包括的的hash值,从而可以统计与第二轮中广播
的Bval消息中的的hash值是否相同,以及是否与第二轮中接收到的和发来
的的hash值是否相同,进而得出是否收集到至少Quorum个来自于不同共识节点的一致
的hash值。
此外,共识节点还可以在第二轮末尾收集到不同节点的签名,如前所述。通过签名
可以统计第二轮中收集到的投票的数量。例如收集到分别有、、签名
的同一hash值,则说明对该hash共有3个表示认可的投票。当然,也可以通过共识节点之间
建立的安全传输通道来确定消息的唯一性,进而确定消息的数量。所述安全传输通道例如
通过消息认证码(Message Authentication Code,MAC)、安全传输层协议(Transport
Layer Security,TTL)之类的技术创建。
对于,如果收集到至少Quorum个来自于不同共识节点的一致的hash值,且自
身针对该提议没有广播过0(即不同的投票),则广播第三消息。第三消息可以记为Prom
消息,意思是承诺不会对提议更改观点。如前所述,的hash值可以表示认可,0可以表
示不认可。针对该提议没有广播过0,是指没有对提议持有过不认可的观点,当
然也可以用0以外的其它形式表示这种不认可。和也是类似的。
例如,假设在第二轮中收集到,、分别广播的Bval
消息中的投票都是所述交易集合的hash值,这样也就收集到、和各
自分别对(或的hash值)的签名是、、的投票,且在第一轮中广
播的Val消息中也包括自身对(或的hash值)的签名为的hash值。这样,在
本轮次中收集到至少Quorum个一致的摘要值(例如此时Quorum=3)。进而,在第三轮
中广播的Prom消息中,可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合,签名集合例如为、、、。
例如,假设在第二轮中收集到、分别广播的Bval消息中的投票
都是所述交易集合的hash值,这样也就收集到和各自分别对(或的
hash值)的签名是、的投票,且在第一轮中广播的Val消息中也包括其对(或的hash值)的签名是的投票,且在第二轮中广播的Bval消息中也包括
其对(或的hash值)的签名是的投票。这样,在第一轮和第二轮中收集到
至少Quorum个一致的摘要值(例如此时Quorum=3)和不同节点的签名。进而,在第三
轮中广播的Prom消息中,可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合,签名集合例如包括、、、。
需要说明的是,上述签名集合,也可以用聚合签名或门限签名替代。
S47:共识节点收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
第三轮执行后,接收到Prom消息的共识节点可以统计收集的Prom消息的数量。共
识节点在第三轮中发出Prom消息的条件是第二轮中收集到至少Quorum个来自于不同共识
节点的一致的投票,且自身针对该提议没有广播过不同的投票,即相当于第二轮末尾该共
识节点确认总计至少Quorum数量的共识节点(包括自身)对该提议的投票都是认同的。
但是,第二轮结束之后还不能马上输出共识结果,而是还需要观察其他节点是否也是在第
二轮末尾收集到至少Quorum数量的对提议的表示认同的投票,因此需要通过第三轮的
Prom消息来确认,并且通过该Prom消息承诺自身不会再针对同一提议的表示不同的观
点。
例如在第一轮和第二轮中收集到至少Quorum个一致的摘要值,进而,
在第三轮中广播的Prom消息中,可以包括该hash值以及收集到的不同节点针对该提议的交
易集合表示认可的hash值及签名集合,签名集合例如包括、、、。
例如在第一轮和第二轮中收集到至少Quorum个一致的摘要值,进而,
在第三轮中广播的Prom消息中,可以包括该hash值以及收集到的不同节点针对该提议的交
易集合表示认可的hash值及签名集合,签名集合例如包括、、、。
这样,通过第三轮,例如可以收集到至少Quorum个Prom消息。通过至少
Quorum个Prom消息,可以确认至少Quorum个共识节点中的每一个都收集到了对该提
议的交易集合表示认可的至少Quorum数量的投票,且发出Prom消息的每一个共识节点
都承诺不再会更改投票的观点,这样,可以进一步完成本次共识。
上述实施例中,首先,可以在一定前提下缩短至3个轮次完成一次共识,相对于HBBFT中的至少6轮,大大降低了共识过程带来的延迟。实际上,本申请实施例中,相当于采用前瞻投票和数字签名技术将HBBFT中RBC过程的后两轮和ABA过程的前两轮进行了合并,从而缩短了所需的轮次。所述前瞻投票,是指上述实施例中第二轮次的Bval中进行投票,而HBBFT在ABA过程中需要在第四轮次的Bval中才投票。所述数字签名,指上述实施例中第一轮次和第二轮次中采用的数字签名。
此外,上述的,如前所述,可以对应。实际上,可以并行或先后发起两
个不同的第一消息。例如,在发起(对应)的上述三轮过程中,可以并行或在
前/在后发起(对应)的上述三轮过程。假设对应,。则发起共识提
议的节点和参与共识的节点、和在输出共识结果时,可以按照时
间戳的先后顺序排序,这样,共识结果排在之前。相应的,最终生成的对应的区
块,其区块高度小于对应的区块。
所述区块链系统中的至少Quorum数量的共识节点中的每一个,都可以作为第一共
识节点执行上述第一轮至第三轮的过程。例如,上述图5的实施例,可以扩展到由、、和均执行。、和各自分别作为第一共识节点执行,
也可以如图6、7、8中所示。这样,从整体的视角来看可以是图5、6、7、8的叠加。其中,例如发起共识提议的交易集合为且时间戳为,发起共识提议的交易集合为且时间戳为、发起共识提议的交易集合为且时间戳为,发起共识
提议的交易集合为且时间戳为,这样,可以对应,可以对应,可
以对应,可以对应。假设,则、、和各自本地的共识结果均为、、、,即按照时间戳排序的结果。、、、可以分别对应一个最终的区块。上述排序,可以由共识节点的ACS协议收集共识结果后
进行。具体的,ACS可以收集各个共识提议的结果后按照各个共识提议的时间戳来排序共识
结果并输出。
按照考虑传输时延的时间戳排序,充分考虑了共识结束的时间,即尽可能的将生成区块的顺序与共识结果的完成顺序保持一致。
这样,通过上述方式,可以在共识提议被提出时即确定对应的区块在区块链上的相对位置。而且,对于一个最终生成的区块来说,其包含一个共识提议,即对应一个共识结果的产生过程,则该共识结果不需要等待其它共识提议的结果,能够快速输出共识结果。这也就省去了在一个共识结果的生成过程中需要等待、配合其它共识提议的共识完成。对于没有提议的共识节点,也不必提出内容实际为空的共识提议,降低了网络带宽的消耗。对于无法提出共识提议的失效节点,上述实施例中只要正常工作的节点达到Quorum数量,则生成共识结果的过程并不需要HBBFT中那样超时赋值为0后再进入ABA过程,而是可以跳过该失效节点,从而可以大大降低共识的时延。
本申请实施例中,与PBFT和HBBFT类似,可以容忍一定数量的错误节点,例如是总数n为3f+1的共识节点中可以容错f个错误节点,Quorum为2f+1。以下给出一个存在f(f=1)的失效节点的例子。
如图9所示:
第一轮中,广播Val消息,Val消息的格式可以如<, , >,其中
可以表示发起共识提议的时间戳,可以表示共识提议中的交易集合。所述,
可以是采用自身私钥对包括和在内的数据的签名,也可以是先对进行hash
计算,得到hash值,进而再用自身的私钥对该hash值和在内的数据进行签名,从而得到。
第一轮的末尾,接收到Val消息的共识节点可以验证接收到的Val消息的正确性。
具体的,可以采用的公钥对第一消息中的的签名进行验证,如果通
过验证,则进入第二轮。类似的,可以采用的公钥对第一消息中的的签名
进行验证,如果通过验证,则进入第二轮。而为失效节点。
第二轮中,接收到所述Val消息的共识节点广播Bval消息,Bval消息中包括对所述
交易集合的投票和签名;所述投票包括所述交易集合的hash值。由于是失效节
点,因此不响应,即不会广播Bval消息,而由、分别广播Bval消息至其它共识节
点。广播的Bval消息例如包括的hash值和采用自身的私钥对的hash值
的签名。此外,Bval消息也可以是如<, hash, >,则其中的可以是
用自身私钥对包括和的hash值在内的数据的签名。
第二轮的末尾,接收到Bval消息的共识节点可以收集Bval中的投票。对于,
在第二轮的末尾收集Bval消息中的投票,收集到,分别广播的Bval消息中的投
票都包括所述交易集合的hash值,且在第一轮中广播的Val消息中也是,其对
应的hash也是的hash值,且,分别广播的Bval消息中包括各自的签名
和,在第一轮中广播的Val消息中也包括签名,则在第二轮末尾收集
到总计3个一致的hash值(此时f=1,Quorum=3)。对于,在第二轮的末尾收集广
播的Bval消息中的投票是的hash值和,且在第二轮中广播的Bval消息中的
投票也是hash值及,且在第一轮中接收到的发出的Val消息中的也是同样的
hash值以及,则在本轮次中收集到3个一致的hash值,满足Quorum数量。对于,在第二轮的末尾收集广播的Bval消息中的投票是的hash值和,且在第二轮中广播的Bval消息中的投票也是hash值及,且在第一轮中接收到的发出的Val消息中的也是同样的hash值以及,则在本轮次中收集到3
个一致的hash值,满足Quorum数量。
第三轮中,接收到Bval消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的hash值后,如果自身针对该提议没有广播过0,则广播Prom消息,Prom消息包括所述hash值以及收集到的签名。
例如,在第三轮中广播的Prom消息中,可以包括该hash值以及收集到的不
同节点针对该提议的交易集合表示认可的hash值及签名集合,签名集合为、、。在第三轮中广播的Prom消息中,可以包括该hash值以及收集到的不同节点针
对该提议的交易集合表示认可的hash值及签名集合,签名集合也是、、。在第三轮中广播的Prom消息中,可以包括该hash值以及收集到的不同节点针对该提
议的交易集合表示认可的hash值及签名集合,签名集合也是、、。
通过第三轮,收集到3个Prom,可以确认至少3个共识节点中的每一个(满足
Quorum)都收集到了对该提议的交易集合表示认可的至少3个投票(满足Quorum),且发
出Prom消息的每一个共识节点都承诺不再会更改投票的观点,这样,可以进一步完
成本次共识,即将所述hash值对应的交易集合作为共识结果输出。、也类
似,即、也将所述hash值对应的交易集合作为共识结果输出。
假设的时间戳为,的时间戳为,且,则、和各自在本地都产生两个共识结果。每个共识节点都可以按照时间戳对这两个共识结
果排序,则排序结果为、,对于最终生成的两个区块来说,对应的区块的区块高度
较小,对应的区块的区块高度较大。
在上述实施例中,在共识提议被提出时即确定对应的区块在区块链上的相对位置。而且,对于一个最终生成的区块来说,其包含一个共识提议,即对应一个共识结果的产生过程,则该共识结果不需要等待其它共识提议的结果,能够快速输出共识结果。这也就省去了在一个共识结果的生成过程中需要等待、配合其它共识提议的共识完成。对于没有提议的共识节点,也不必提出内容实际为空的共识提议,降低了网络带宽的消耗。对于无法提出共识提议的失效节点,上述实施例中只要正常工作的节点达到Quorum数量,则生成共识结果的过程并不需要HBBFT中那样超时赋值为0后再进入ABA过程,而是可以跳过该失效节点,从而可以大大降低共识的时延。
在实际的区块链应用中,上述实施例针对特定的情形有更为重要的意义。如图11
所示,例如组成一个联盟链的4个节点分别部署于不同的国家,位于英国,
位于德国,位于法国,位于中国。显然的,位于欧洲的,和三个节点之间的通信时延较小,而这三个节点与位于亚洲的通信时延较
大。假设,和三个节点之间的通信时延均为10ms,这三个欧洲节点
与的通信时延均为80ms。如果采用HBBFT,这4个节点中位于欧洲的3个节点即可以
构成Quorum,且其在30ms多的时间内内均能完成RBC过程,在另外的30ms多的时间内均能完
成ABA过程,而发起的提议由于总是较慢的执行,这样,的提议的RBC过程有较大概
率在其它三个节点的ABA过程结束前仍然没有完成,因此的提议在ABA赋初值中赋
值为0,从而的提议经常无法被纳入生成的区块中(按照抛币结果有大于1/2的概
率),相当于经常失去对区块的构造权。而且,即使拥有对区块的构造权,较
大的延迟也会拖慢一次共识的过程。
而采用本申请上述实施例的共识方案,每个节点的提议可以单独成块(生成区块),且共识结果按照时间戳排序,这样可以保证在不失去区块构造权的情况下,在发起共识提议时即确定成块的相对位置。特别是对于失效节点,无须等待其发起共识提议,其它节点也就不需要配合其完成共识。换句话说,可以按照实际的提议需求,并按照时间戳的顺序对完成共识的结果排序。此外,没有提议的共识节点,也不需要发起实际内容为空的提议,从而可以降低网络带宽的消耗。
特别的,针对同一提议,第二消息和第三消息中具有与第一消息中相同的时间戳,该时间戳可以用于标识相同提议的共识过程,而不需要引入其它的标识,从而可以节省协议过程的数据量。
本申请还提供一种区块链系统实施例,包括共识节点,其中:
第一共识节点广播第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名;
接收到所述第一消息的共识节点广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;
接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后,如果自身针对该提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;
共识节点收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
其中,所述第二消息、第三消息中还包括所述时间戳,相应地,第二消息、第三消息中的所述签名包括对所述时间戳在内的数据的签名。
其中,在同一次共识过程中,所述区块链系统中的至少Quorum数量的共识节点参与共识,且其中至少一个共识节点作为第一共识节点。
其中,至少一个共识节点作为第一共识节点,产生至少两个共识结果,所述两个共识结果按照所述时间戳顺序生成区块。
其中,至少两个共识节点分别作为第一共识节点,产生至少两个共识结果,所述两个共识结果按照所述时间戳顺序生成区块。
本申请还提供一种区块链系统中的共识节点实施例,可以如图12所示,包括:
第一消息接收单元121,用于接收第一共识节点广播的第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名;
第二消息广播单元122,用于当第一消息接收单元接收到所述第一消息后广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;
投票收集单元123,用于收集来自于共识节点的投票;
第三消息广播单元124,当投票收集单元收集到至少Quorum个来自于不同共识节点的一致的投票,如果自身针对该提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;
第三消息收集单元125,收集来自于共识节点的第三消息;
输出单元126,当第三消息收集单元收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
其中,所述第二消息、第三消息中还包括所述时间戳。
其中,在同一次共识过程中,至少Quorum数量的共识节点参与共识,且其中至少一个共识节点作为第一共识节点。
其中,至少一个共识节点作为第一共识节点,产生至少两个共识结果,所述两个共识结果按照所述时间戳顺序生成区块。
其中,至少两个共识节点分别作为第一共识节点,产生至少两个共识结果,所述两个共识结果按照所述时间戳顺序生成区块。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device, PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20 以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然,本申请不排除随着未来计算机技术的发展,实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的装置或终端产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境,甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下,并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一,第二等词语用来表示名称,而并不表示任何特定的顺序。
为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现,也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
本领域技术人员应明白,本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此,本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书一个或多个实施例的实施例而已,并不用于限制本说明书一个或多个实施例。对于本领域技术人员来说,本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在权利要求范围之内。
Claims (21)
1.一种区块链系统中的共识方法,包括:
第一轮:第一共识节点广播第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名;
第二轮:接收到所述第一消息的共识节点广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;
第三轮:接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后,如果自身针对提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;
共识节点收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
2.如权利要求1所述的方法,所述第二消息、第三消息中还包括所述时间戳。
3.如权利要求1或2所述的方法,所述时间戳基于第一共识节点广播第一消息时或之前的物理时间以及网络传输时延确定。
4.如权利要求3所述的方法,所述网络传输时延包括第一共识节点与其它共识节点的网络传输时延的平均值或最大值。
5.如权利要求1所述的方法,在同一次共识过程中,所述区块链系统中的至少Quorum数量的共识节点参与共识,且其中至少一个共识节点作为第一共识节点执行权利要求1的方法。
6.如权利要求1所述的方法,至少一个共识节点作为第一共识节点执行权利要求1的方法所产生的至少两个共识结果,按照所述时间戳顺序生成区块。
7.如权利要求1所述的方法,至少两个共识节点分别作为第一共识节点执行权利要求1的方法所产生的至少两个共识结果,按照所述时间戳顺序生成区块。
8.一种区块链系统,包括共识节点,其中:
第一共识节点广播第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名;
接收到所述第一消息的共识节点广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;
接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后,如果自身针对提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;
共识节点收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
9.如权利要求8所述的系统,所述第二消息、第三消息中还包括所述时间戳,相应地,第二消息、第三消息中的所述签名包括对所述时间戳在内的数据的签名。
10.如权利要求8或9所述的系统,所述时间戳基于第一共识节点广播第一消息时或之前的物理时间以及网络传输时延确定。
11.如权利要求10所述的系统,所述网络传输时延包括第一共识节点与其它共识节点的网络传输时延的平均值或最大值。
12.如权利要求8所述的系统,在同一次共识过程中,所述区块链系统中的至少Quorum数量的共识节点参与共识,且其中至少一个共识节点作为第一共识节点。
13.如权利要求8所述的系统,至少一个共识节点作为第一共识节点,产生至少两个共识结果,所述两个共识结果按照所述时间戳顺序生成区块。
14.如权利要求8所述的系统,至少两个共识节点分别作为第一共识节点,产生至少两个共识结果,所述两个共识结果按照所述时间戳顺序生成区块。
15.一种区块链系统中的共识节点,包括:
第一消息接收单元,用于接收第一共识节点广播的第一消息,第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名;
第二消息广播单元,用于当第一消息接收单元接收到所述第一消息后广播第二消息,第二消息中包括对所述交易集合的投票和签名;所述投票包括所述交易集合的摘要值;
投票收集单元,用于收集来自于共识节点的投票;
第三消息广播单元,当投票收集单元收集到至少Quorum个来自于不同共识节点的一致的投票,如果自身针对提议没有广播过不同的投票,则广播第三消息,第三消息包括所述摘要值以及收集到的签名集合;
第三消息收集单元,收集来自于共识节点的第三消息;
输出单元,当第三消息收集单元收集到至少Quorum个来自于不同节点的第三消息后,将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
16.如权利要求15所述的共识节点,所述第二消息、第三消息中还包括所述时间戳。
17.如权利要求15或16所述的共识节点,所述时间戳基于第一共识节点广播第一消息时或之前的物理时间以及网络传输时延确定。
18.如权利要求17所述的共识节点,所述网络传输时延包括第一共识节点与其它共识节点的网络传输时延的平均值或最大值。
19.如权利要求15所述的共识节点,在同一次共识过程中,所述区块链系统中的至少Quorum数量的共识节点参与共识,且其中至少一个共识节点作为第一共识节点。
20.如权利要求15所述的共识节点,至少一个共识节点作为第一共识节点,产生至少两个共识结果,所述两个共识结果按照所述时间戳顺序生成区块。
21.如权利要求15所述的共识节点,至少两个共识节点分别作为第一共识节点,产生至少两个共识结果,所述两个共识结果按照所述时间戳顺序生成区块。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111175144.7A CN113610531B (zh) | 2021-10-09 | 2021-10-09 | 一种共识方法、区块链系统和共识节点 |
PCT/CN2022/124159 WO2023056976A1 (zh) | 2021-10-09 | 2022-10-09 | 共识方法、区块链系统和共识节点 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111175144.7A CN113610531B (zh) | 2021-10-09 | 2021-10-09 | 一种共识方法、区块链系统和共识节点 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113610531A CN113610531A (zh) | 2021-11-05 |
CN113610531B true CN113610531B (zh) | 2021-12-14 |
Family
ID=78343382
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111175144.7A Active CN113610531B (zh) | 2021-10-09 | 2021-10-09 | 一种共识方法、区块链系统和共识节点 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN113610531B (zh) |
WO (1) | WO2023056976A1 (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113610531B (zh) * | 2021-10-09 | 2021-12-14 | 支付宝(杭州)信息技术有限公司 | 一种共识方法、区块链系统和共识节点 |
CN114782047B (zh) * | 2021-12-29 | 2023-06-30 | 张海滨 | 数据共识方法及分布式系统 |
CN114697344B (zh) * | 2022-03-30 | 2023-12-19 | 蚂蚁区块链科技(上海)有限公司 | 区块链系统中共识节点的确定方法、区块链系统、节点、存储介质及计算设备 |
CN115174090B (zh) * | 2022-05-20 | 2023-04-25 | 清华大学 | 区块链共识方法、装置、计算机设备及可读存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9998286B1 (en) * | 2017-02-17 | 2018-06-12 | Accenture Global Solutions Limited | Hardware blockchain consensus operating procedure enforcement |
CN109842606A (zh) * | 2018-02-24 | 2019-06-04 | 中国科学院计算技术研究所 | 基于一致性哈希算法的区块链共识算法和系统 |
CN112685796A (zh) * | 2021-03-12 | 2021-04-20 | 腾讯科技(深圳)有限公司 | 一种基于区块链的区块共识方法以及相关设备 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190258610A1 (en) * | 2018-02-21 | 2019-08-22 | Wei Kang Tsai | Byzantine fault-tolerant algorithm with four steps |
CN110247774A (zh) * | 2019-06-28 | 2019-09-17 | 深圳市网心科技有限公司 | 一种区块链数据的共识方法及相关设备 |
CN112769936B (zh) * | 2021-01-11 | 2022-08-16 | 电子科技大学 | 一种基于投票与信用机制的povt共识算法 |
CN113610531B (zh) * | 2021-10-09 | 2021-12-14 | 支付宝(杭州)信息技术有限公司 | 一种共识方法、区块链系统和共识节点 |
-
2021
- 2021-10-09 CN CN202111175144.7A patent/CN113610531B/zh active Active
-
2022
- 2022-10-09 WO PCT/CN2022/124159 patent/WO2023056976A1/zh unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9998286B1 (en) * | 2017-02-17 | 2018-06-12 | Accenture Global Solutions Limited | Hardware blockchain consensus operating procedure enforcement |
CN109842606A (zh) * | 2018-02-24 | 2019-06-04 | 中国科学院计算技术研究所 | 基于一致性哈希算法的区块链共识算法和系统 |
CN112685796A (zh) * | 2021-03-12 | 2021-04-20 | 腾讯科技(深圳)有限公司 | 一种基于区块链的区块共识方法以及相关设备 |
Non-Patent Citations (2)
Title |
---|
Continuous Distributed Key Generation on Blockchain Based on BFT Consensus;Lei Lei 等;《2020 第三届国际热点信息中心网络会议 (HotICN)》;20201214;第8-17页 * |
异步环境下的拜占庭共识算法研究;翁良;《万方数据》;20200507;第1-57页 * |
Also Published As
Publication number | Publication date |
---|---|
WO2023056976A1 (zh) | 2023-04-13 |
CN113610531A (zh) | 2021-11-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113610531B (zh) | 一种共识方法、区块链系统和共识节点 | |
CN113630257B (zh) | 一种共识方法、区块链系统和共识节点 | |
CN114401150B (zh) | 区块链网络中加入节点的方法和区块链系统 | |
CN110730204B (zh) | 区块链网络中删除节点的方法和区块链系统 | |
CN113609515B (zh) | 一种共识方法、区块链系统 | |
CN114584312B (zh) | 一种共识方法、区块链系统和共识节点 | |
CN113630258B (zh) | 一种共识方法、区块链系统和共识节点 | |
CN113761071B (zh) | 一种共识方法、区块链系统和共识节点 | |
CN111147261B (zh) | 在区块链中使用HotStuff共识算法的方法及系统 | |
WO2023056966A1 (zh) | 共识方法、区块链系统和共识节点 | |
CN110298754A (zh) | 一种应用于区块链的共识方法 | |
US20230017790A1 (en) | Graphic-blockchain-orientated hybrid consensus implementation apparatus and implementation method thereof | |
CN114726517A (zh) | 一种区块链上产生随机数种子的方法、系统和共识节点 | |
CN114884652A (zh) | 一种区块链上产生随机数种子的方法、系统和共识节点 | |
CN115037472B (zh) | 基于双层dag共识机制的交易处理方法及系统、服务设备 | |
CN115174048A (zh) | 一种共识方法、系统和共识节点 | |
CN116846907A (zh) | 一种共识方法、区块链节点 | |
CN116846906A (zh) | 一种共识方法、区块链节点 | |
Yin | Scaling the Infrastructure of Practical Blockchain Systems | |
CN116846912A (zh) | Pbft算法中的视图切换方法、共识节点和区块链系统 | |
CN116484417A (zh) | 区块链系统中的交易提议方法、共识节点和区块链系统 | |
CN116823463A (zh) | 区块链系统中的交易提议方法、共识节点和区块链系统 | |
CN116823465A (zh) | 区块链系统中的交易提议方法、共识节点和区块链系统 | |
CN116823466A (zh) | 区块链系统中的交易提议方法、共识节点和区块链系统 | |
CN116527694A (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 |