CN111682942A - 一种应用于许可链的二元加权拜占庭容错共识方法 - Google Patents
一种应用于许可链的二元加权拜占庭容错共识方法 Download PDFInfo
- Publication number
- CN111682942A CN111682942A CN202010419521.6A CN202010419521A CN111682942A CN 111682942 A CN111682942 A CN 111682942A CN 202010419521 A CN202010419521 A CN 202010419521A CN 111682942 A CN111682942 A CN 111682942A
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- nodes
- decision
- client
- 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
Links
Images
Classifications
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Hardware Redundancy (AREA)
Abstract
一种应用于许可链的二元加权拜占庭容错共识方法,属于区块链技术领域。本发明是为了在弱同步网络环境下、O(n2)通信复杂度内实现加权拜占庭容错共识而提出的。技术要点:网络中包含若干参与共识的节点,持续监听来自客户端或其他节点的消息;共识开始前系统需配置全局参数,包含节点地址、事务类型、主节点信息以及决策阈值,并由每个节点各自完成权值分配;在初始阶段,当主节点监听到来自客户端的请求时,由主节点发起共识;二元加权拜占庭容错共识分为预准备阶段、投票阶段、决策阶段、提交阶段四个阶段,当节点完成对账簿的更新后,还需将执行结果返回给客户端,以便客户端掌握共识完成情况。适用于非开放网络、非均匀信任的许可链中解决共识问题。
Description
技术领域
本发明涉及拜占庭容错共识算法,属于区块链技术领域。
背景技术
区块链技术由于其去中心化、不可篡改、可追溯等特性成为近年来的研究热点,如今被广泛应用于金融、物联网等各个领域。共识算法作为支撑区块链技术的一个重要组成部分,构建了区块链的信任基础。
共识算法起初是解决分布式系统中多节点就某个状态达成一致的问题,确保所有非故障节点能够按相同顺序执行操作并产生相同的状态,且不受节点故障、链路延迟等因素影响。在共识算法中,一类重要的问题是拜占庭容错共识,即故障节点可以有不响应、伪造消息、向不同节点发送不一致消息等任意行为。PBFT被认为是解决拜占庭容错共识问题的经典,该算法及其变种类BFT共识被广泛应用于解决许可链中的共识问题。
传统拜占庭容错共识均在一个或多个阶段完成类似节点对事务的投票和计票工作,且默认所有节点的投票具有等同的重要性,因此只需计算投票数量。然而,当每个参与节点有不同的权力,或节点的信任分配不均,此时传统拜占庭容错共识无法胜任,需采用加权拜占庭容错共识。
文献号为CN201910124305.6的现有技术公开了一种低通信复杂度的高效异步拜占庭容错共识方法,网络中的节点计算交易数据块、冗余数据块、数据块哈希和指纹交叉校验和,利用异步可验证信息传播协议将相关数据发送给网络中的每一个节点。节点在确认网络中已经正确存储了某些节点广播发送的交易后,就执行二元向量一致性协议,对交易进行共识;节点向网络请求特定的数据块,重构得到原始交易数据。然而尚未有算法能在弱同步网络环境下、O(n2)通信复杂度内解决加权拜占庭容错共识问题。
发明内容
本发明要解决的技术问题为:
本发明为了在弱同步网络环境下、O(n2)通信复杂度内实现加权拜占庭容错共识问题,提出一种应用于许可链的二元加权拜占庭容错共识方法。
本发明为解决上述技术问题采用的技术方案为:
一种应用于许可链的二元加权拜占庭容错共识方法,所述方法的实现过程为:
步骤一、构建系统模型
1)共识模型:采用二元共识模型,共识的输入和输出均由一个二进制位表示,共识的输入和输出均由一个二进制位表示,1表示通过,事务将被执行并改变账簿状态;0表示拒绝,事务不被执行且不改变账簿状态;
2)故障模型假设:采用拜占庭故障模型,故障节点的行为是任意的,包括向正常节点发送错误的或不一致的消息,或不做出响应,允许有一个强大的对手统一控制所有故障节点阻碍共识;基于某类事务的共识与对应主节点命运共享的前提,在共识中不考虑主节点发生故障的情况;
3)可靠信道假设:各节点间均有可靠的授权点对点信道,保证正常节点发送的消息最终会被正确交付;允许同一时刻有多个主节点共同发起共识,且消息可能以乱序到达;对手计算能力有限,无法破解密码学技术;
4)时间假设:系统运行在弱同步环境下,通信延迟不会随着时间推移而无限增长;
步骤二、给出系统参数
假设系统中有n个节点N1,N2,…,Nn,m种事务类型T1,T2,…,Tm。事务类型Tj对应的主节点为Pj,节点Ni对事务类型Tj的权值分配用n维权值向量Wij表示,即
(Tj,Ni)→Wij=[wij1 wij2 …… wijn]
wijk表示针对事务Tj,节点Ni为节点Nk分配的权值大小,权值向量需满足条件
对任意i和j均成立;
Vi是由节点i对该次共识的事务列表L中全体事务的投票组成的投票向量;矩阵V=[V1 V2 … Vn]保存所有节点的投票;同样地,LocalDecisioni和LocalDecision分别为在决策阶段节点i产生的局部决策结果和所有节点的局部决策矩阵,GlobalDecision为主节点在提交阶段产生的全局决策结果;
在任意非故障节点的权值分配中,拜占庭节点所占总权值均不能超过f;当结果超过决策阈值θ时,该事务的决策结果为1通过,反之为0拒绝;
步骤三、二元加权拜占庭容错共识过程:
网络中包含若干参与共识的节点,持续监听来自客户端或其他节点的消息;共识开始前,系统需配置全局参数,包含节点地址、事务类型、主节点信息以及决策阈值,并由每个节点各自完成权值分配;在初始阶段,当主节点监听到来自客户端的请求时,由主节点发起共识;
二元加权拜占庭容错共识(BWBFT共识)分为预准备阶段、投票阶段、决策阶段、提交阶段四个阶段,当节点完成对账簿的更新后,还需将执行结果返回给客户端,以便客户端掌握共识完成情况;BWBFT共识仅在投票阶段包含一次全体广播,其通信复杂度为O(n2)。
进一步地,在二元加权拜占庭容错共识过程中每个共识阶段的实现过程为:
客户端:
客户端针对事务类型为T的有序事务列表L发起请求时,需将请求提交给对应的主节点,消息格式为<REQUEST,c,T,L,sig>;其中,c表示客户端身份,便于节点在达成共识后将共识结果回复给客户端,事务种类T决定本次共识中采用的主节点和权值,L为待共识的有序事务列表;
预准备阶段:
当主节点收到来自客户端的请求后,先验证消息有效性,包括事务类型与事务列表之间是否对应、消息是否被提交到正确的主节点处以及消息完整性,若无效则丢弃该消息;否则,主节点为请求生成唯一wID,并将其告知客户端;然后主节点将请求打包成work,格式为(wID,c,T,L,t),其中客户端身份c、事务类型T、事务列表L均来自客户端请求,时间戳t为主节点生成work时的本地时钟,用于保证顺序一致性;然后,主节点广播一个预准备消息将work分发给所有节点,消息格式为<PRE-PREPARE,P,work,sig>,主节点身份P便于其他节点校验其身份有效性,work包含本次共识请求的全部信息,在预准备阶段分发给全体节点,后面阶段仅使用wID作为区分不同work的唯一标识;
投票阶段:
当收到来自主节点的预准备消息时,节点先验证消息有效性并将work记录在本地;然后,节点为work中的事务列表生成投票向量,并将投票广播给全体节点;投票消息格式为<VOTE,wID,I,Vi,sig>,表明节点i针对编号为wID的work在投票阶段产生的投票向量为Vi;
决策阶段:
节点持续收到其他节点的投票消息,并将每个节点的投票向量记录到投票矩阵V中,当节点收集到总权值不少于1-f的投票后,将未收到投票消息的节点的投票向量全部记为0,然后进行局部决策;当节点i对事务类型为Tj的work进行局部决策时,计算
并将结果向量中的每个分量与决策阈值θ进行比较,生成节点i的局部决策结果LocalDecisioni;为将局部决策结果告知主节点,节点生成局部决策消息,格式为<DECISION,wID,i,LocalDecisioni,sig>,表示节点i针对编号为wID的work在决策阶段产生的局部决策结果为LocalDecisioni;
提交阶段:
主节点持续收到其他节点的局部决策消息,并将其记录到局部决策矩阵LocalDecision中;当主节点收集到总权值不少于1-f的局部决策后,将未收到的局部决策全部记为0,然后进行全局决策;当主节点Pj对事务类型为Tj的work进行全局决策时,计算
并将结果向量中的每个分量与决策阈值θ进行比较,生成全局决策结果GlobalDecision,即最终共识结果。为将共识结果告知全体节点,主节点将广播一个提交消息,格式为<COMMIT,wID,GlobalDecision,sig>,表示编号为wID的work的共识结果为GlobalDecision;当节点收到来自主节点的提交消息后,根据共识结果及对应work信息完成对账簿的更新操作,保证账簿的全局一致性。
回复:
当节点完成账簿更新后,需将执行结果回复给客户端,回复格式为<REPLY,I,wID,R,sig>,表示节点i针对编号为wID的work的执行结果为R;在不考虑主节点发生故障的前提下,当收到来自主节点的回复消息后,客户端可确认已达成共识;正常情况下所有节点的执行结果应与主节点相同,若在主节点回复一段时间过后仍有节点未回复,或结果与主节点不同,则认为该节点可能发生故障,客户端可以将主节点的回复消息转发给该节点,帮助其达成共识。
进一步地,采用ecdsa算法对各节点间发送的消息进行数字签名,客户端与节点间的交互采用sha256算法验证消息完整性;在通信前为每个节点生成其公私钥对,并为所有节点预先配置所有节点的通信地址和公钥,所有事务类型及其对应主节点,以及在每种事务类型下每个节点的权值分配情况,权值为随机生成。
进一步地,所述方法对多种类型的事务进行共识,且不同种类事务的主节点、权值等信息相互隔绝,彼此间互不影响。
进一步地,在步骤1中的密码学技术为无碰撞哈希、加密或数字签名。
本发明具有以下有益技术效果:
本发明是为了在弱同步环境下、O(n2)通信复杂度内解决加权拜占庭容错共识问题而提出的一种二元加权拜占庭容错共识算法,即BWBFT。适用于在非开放网络、非均匀信任的许可链中解决共识问题。为契合许可链的应用场景,BWBFT可以对多种类型的事务进行共识,且不同种类事务的主节点、权值等信息相互隔绝,彼此间互不影响。
BWBFT具有如下三个特点:1)命运共享,由于主节点通常由事务的利益相关者运行,当主节点故障时,由于缺少利益相关者,对该事务的共识变得不再有意义,因此主节点故障导致对应种类事务的共识失活是可接受的;2)非均匀信任,节点间的信任关系是非均匀、非对称的,与事务类型有关,所有节点需在共识开始前根据信任关系为每个节点分配权值;3)分类共识,主节点可以一次将来自客户端的相同事务类型的多个请求打包并进行共识,提高吞吐量。
从理论上证明,为保证系统安全性,BWBFT能容忍的最大拜占庭节点所占总权值少于1/4。我们实现了BWBFT原型并进行实验,使用共识延迟和吞吐量两个评价指标对BWBFT性能进行分析。实验表明,在4共识节点时峰值吞吐量趋近200000tx/s,而32节点时约为13000tx/s;32共识节点和8客户端(单客户端提交10000tx)时,共识延迟约为6.1s,符合许可链的应用场景。本发明完全适用于非开放网络、非均匀信任的许可链中解决共识问题。
附图说明
图1为包含预准备阶段、投票阶段、决策阶段、提交阶段这四个阶段的BWBFT共识算法执行过程原理示意图(算法执行过程);
图2是共识延迟和吞吐量与批处理大小的关系;
图3是共识延迟和吞吐量与客户端数量的关系;
图4是共识延迟和吞吐量与节点数量的关系。
具体实施方式
本实施方式结合附图1至4对所述的应用于许可链的二元加权拜占庭容错共识方法进行如下阐述:
1系统模型
1)共识模型:采用二元共识模型,共识的输入和输出均由一个二进制位表示,共识的输入和输出均由一个二进制位表示,1表示通过,事务将被执行并改变账簿状态;0表示拒绝,事务不被执行且不改变账簿状态;
2)故障模型假设:采用拜占庭故障模型,故障节点的行为是任意的,包括向正常节点发送错误的或不一致的消息,或不做出响应,允许有一个强大的对手统一控制所有故障节点阻碍共识。基于某类事务的共识与对应主节点命运共享的前提,在共识中不考虑主节点发生故障的情况;
3)可靠信道假设:各节点间均有可靠的授权点对点信道,保证正常节点发送的消息最终会被正确交付。允许同一时刻有多个主节点共同发起共识,且消息可能以乱序到达。对手计算能力有限,无法破解如无碰撞哈希、加密或数字签名等密码学技术;
4)时间假设:系统运行在弱同步环境下,通信延迟不会随着时间推移而无限增长;
2系统参数
假设系统中有n个节点N1,N2,…,Nn,m种事务类型T1,T2,…,Tm。事务类型Tj对应的主节点为Pj。节点Ni对事务类型Tj的权值分配用n维权值向量Wij表示,即
(Tj,Ni)→Wij=[wij1 wij2 …… wijn]
wijk表示针对事务Tj,节点Ni为节点Nk分配的权值大小。权值向量需满足条件
对任意i和j均成立。
Vi是由节点i对该次共识的事务列表L中全体事务的投票组成的投票向量。矩阵V=[V1 V2 … Vn]保存所有节点的投票。同样地,LocalDecisioni和LocalDecision分别为在决策阶段节点i产生的局部决策结果和所有节点的局部决策矩阵,GlobalDecision为主节点在提交阶段产生的全局决策结果。
在任意非故障节点的权值分配中,拜占庭节点所占总权值均不能超过f。当结果超过决策阈值θ时,该事务的决策结果为1通过,反之为0拒绝。
3算法实现
网络中包含若干参与共识的节点,持续监听来自客户端或其他节点的消息。共识开始前,系统需配置全局参数,包含节点地址、事务类型、主节点信息以及决策阈值等,并由每个节点各自完成权值分配。在初始阶段,当主节点监听到来自客户端的请求时,由主节点发起共识;
BWBFT共识分为预准备阶段、投票阶段、决策阶段、提交阶段这四个阶段(如图1所示)。当节点完成对账簿的更新后,还需将执行结果返回给客户端,以便客户端掌握共识完成情况。容易发现,BWBFT共识仅在投票阶段包含一次全体广播,因此其通信复杂度为O(n2)。
下面将说明每个共识阶段的实现过程:
客户端
客户端针对事务类型为T的有序事务列表L发起请求时,需将请求提交给对应的主节点,消息格式为<REQUEST,c,T,L,sig>。其中,c表示客户端身份,便于节点在达成共识后将共识结果回复给客户端,事务种类T决定本次共识中采用的主节点和权值,L为待共识的有序事务列表。
预准备阶段
当主节点收到来自客户端的请求后,先验证消息有效性,包括事务类型与事务列表之间是否对应、消息是否被提交到正确的主节点处以及消息完整性,若无效则丢弃该消息。否则,主节点为请求生成唯一wID,并将其告知客户端(对应图1中的虚线箭头)。然后主节点将请求打包成work,格式为(wID,c,T,L,t),其中客户端身份c、事务类型T、事务列表L均来自客户端请求,时间戳t为主节点生成work时的本地时钟,用于保证顺序一致性。然后,主节点广播一个预准备消息将work分发给所有节点,消息格式为<PRE-PREPARE,P,work,sig>,主节点身份P便于其他节点校验其身份有效性,work包含本次共识请求的全部信息,在预准备阶段分发给全体节点,后面阶段仅使用wID作为区分不同work的唯一标识。
投票阶段
当收到来自主节点的预准备消息时,节点先验证消息有效性并将work记录在本地。然后,节点为work中的事务列表生成投票向量,并将投票广播给全体节点。投票消息格式为<VOTE,wID,I,Vi,sig>,表明节点i针对编号为wID的work在投票阶段产生的投票向量为Vi。
决策阶段
节点持续收到其他节点的投票消息,并将每个节点的投票向量记录到投票矩阵V中。当节点收集到总权值不少于1-f的投票后,将未收到投票消息的节点的投票向量全部记为0,然后进行局部决策。当节点i对事务类型为Tj的work进行局部决策时,计算
并将结果向量中的每个分量与决策阈值θ进行比较,生成节点i的局部决策结果LocalDecisioni。为将局部决策结果告知主节点,节点生成局部决策消息,格式为<DECISION,wID,i,LocalDecisioni,sig>,表示节点i针对编号为wID的work在决策阶段产生的局部决策结果为LocalDecisioni。
提交阶段
主节点持续收到其他节点的局部决策消息,并将其记录到局部决策矩阵LocalDecision中。当主节点收集到总权值不少于1-f的局部决策后,将未收到的局部决策全部记为0,然后进行全局决策。当主节点Pj对事务类型为Tj的work进行全局决策时,计算
并将结果向量中的每个分量与决策阈值θ进行比较,生成全局决策结果GlobalDecision,即最终共识结果。为将共识结果告知全体节点,主节点将广播一个提交消息,格式为<COMMIT,wID,GlobalDecision,sig>,表示编号为wID的work的共识结果为GlobalDecision。当节点收到来自主节点的提交消息后,根据共识结果及对应work信息完成对账簿的更新操作,保证账簿的全局一致性。
回复
当节点完成账簿更新后,需将执行结果回复给客户端,回复格式为<REPLY,I,wID,R,sig>,表示节点i针对编号为wID的work的执行结果为R。在不考虑主节点发生故障的前提下,当收到来自主节点的回复消息后,客户端可以确认已达成共识。正常情况下所有节点的执行结果应与主节点相同,若在主节点回复一段时间过后仍有节点未回复,或结果与主节点不同,则认为该节点可能发生故障。客户端可以将主节点的回复消息转发给该节点,帮助其达成共识。
针对本发明能产生的技术效果再进行如下说明:
1理论证明
1)安全性:
安全性可以从一致性和有效性两个方面考虑。
从一致性上看,提交阶段由主节点独自计算全局决策结果并广播给全体节点,基于可靠信道假设和命运共享特性,所有节点会接收到一致的共识结果,且所有非故障节点均按照work中的时间戳顺序t执行相同的有序事务序列L,因此所有非故障节点必然产生相同的账簿状态。
有效性是指节点在决策和提交阶段产生的决策结果不受拜占庭节点的投票影响。换句话说,如果决策结果为v,则v一定是多数非故障节点的投票值。试想如果有一个强大的对手控制所有拜占庭节点投相同票,使原本未达到决策阈值θ的投票超过θ,那么此时的决策结果应是无效的。为达到这一目的,必须控制决策阈值θ在合理范围内。
假设节点收到消息的总权值为a后开始决策,基于可靠信道的假设,节点能收到的消息总权值必然不小于1-f,即
1-f≤a≤1 (1)。
考虑最坏情况,a中包含所有故障节点的投票,此时若其他a-f非故障节点均投相同票v,则必须保证决策结果为v。另外,在二元共识中,决策阈值必然要超过半数票,即a/2。因此决策阈值θ有如下范围
a/2<θ≤a-f (2)。
为保证拜占庭节点的投票不会对决策结果产生影响,必须使决策结果所占权值与相反票所占权值的差值超过f,即
θ-(a-θ)>f (3)。
(3)保证超过决策阈值θ的投票必然是由绝对多数票产生的。即使在最坏情况下所有拜占庭节点均投相反票,也无法将原先的多数票变为少数票,即决策结果满足有效性。
结合(2)和(3)可以得到决策阈值θ的范围
a/2+f/2<θ≤a-f (4)。
结合(1)和(4)可以得到f的范围
f<1/4 (5)。
因此,BWBFT能够容忍的拜占庭节点所占总权值少于1/4。
2)活性:
BWBFT依靠弱同步假设来保证算法每个阶段节点必定会收到足够多的消息来进入下一阶段,进而保证算法在每个阶段的活性,以此来规避FLP不可能性。实际系统中有一套消息重传机制,保证消息最终会交付,且延迟不会随时间推移而无限增长。这在现实系统中容易实现。
在有主节点领导的弱同步环境下的共识协议中,同一时刻最多只能有一个节点(主节点)发起请求,不会出现争用的情况,因此主节点故障是另一个可能导致系统失活的情况。基于命运共享的特性,当主节点发生故障时,对该类事务共识的失活是可接受的,以此来保证活性。在现实系统中,每个BWBFT中的主节点都代表一个小型分布式系统,统一负责接收请求和进行共识,在分布式系统内部保证活性来进而保证主节点不发生故障。
3)假阴性:
为保证决策结果满足有效性,(4)表明决策阈值θ必须至少比收到的半数票多f/2,这会导致当投票v超过半数但未达θ时,决策结果不为v。实际中可能会出现三种情况:通过票达到决策阈值、拒绝票达到决策阈值、通过票和拒绝票均未达到决策阈值。前两种情况只需要简单地将决策结果设置为通过或拒绝即可。而当第三种情况出现时,为保证算法安全性,事务将被拒绝。这种做法可能会造成决策结果产生假阴性,即通过占多数票的事务由于未达到决策阈值而被拒绝。为保证算法有效性这种情况无法避免,只能由客户端重新提交事务。
2实验结果
实验环境:
我使用go语言实现了一个BWBFT原型,并在单服务器上搭建实验环境。服务器配置参数如下:服务器型号:sugon I620-T20;CPU:Intel Xeon E5-2603 v3*2;Storage:32GB;OS:Ubuntu 16。04。6LTS。在单服务器上模拟多个共识节点,每个节点运行在单一协程中,保证各节点间相互连通,节点间采用HTTP POST方式通信,通信延迟可以忽略且不会发生丢包,消除网络通信对共识算法性能造成的影响。采用ecdsa算法对各节点间发送的消息进行数字签名,客户端与节点间的交互采用sha256算法验证消息完整性。在通信前为每个节点生成其公私钥对,并为所有节点预先配置所有节点的通信地址和公钥,所有事务类型及其对应主节点,以及在每种事务类型下每个节点的权值分配情况,权值为随机生成。另外,在该服务器上模拟多个客户端协程用于向主节点提交请求并接收响应。在实验中,设置决策阈值θ为70%,拜占庭节点所占总权值不超过10%。
实验结果分析:
实验中包含三个可控变量:1)客户端在一次请求中包含的事务数量,也是一次共识的事务数量,即批处理大小(Batch Size),这些事务均属于同一事务类型;2)客户端数量,不同客户端针对多种事务类型的事务同时发起请求,目的是模拟现实中的并发情况,在实验中选择让共识节点轮流作为主节点进行共识;3)共识节点数量,该变量是制约共识算法性能的关键因素。
在实验中采用两个评价指标对实验结果进行分析:1)共识延迟,即所有事务从被提交到主节点开始到客户端收到1-f的节点回复为止所需要的平均时间;2)吞吐量,即单位时间内达成共识的事务数量,单位为(tx/s)。
下面将针对这三个可控变量采用控制变量法实施三组实验,测量并计算每组实验中的共识延迟和吞吐量。
图2为单客户端提交请求且共识节点数量不变的情况下,共识延迟和吞吐量随批处理大小的变化情况。从图中可以看出,共识延迟与批处理大小呈线性关系。在吞吐量方面,事务数量较少时,吞吐量随批处理大小迅速增长,此时影响共识效率的关键因素并非批处理大小,而是共识算法本身。当批处理大小增长到一定规模后,吞吐量会达到峰值并保持稳定,该峰值主要受共识节点数量制约,可以看到在不同共识节点数量下,该峰值有显著的差异。另外,峰值大小还会受服务器配置、带宽大小等因素影响。注意,该峰值仅是在单客户端下系统的吞吐量最大值,并非系统的峰值吞吐量。从图中还可以发现,不同共识节点数量下达到峰值对应的批处理大小大致相同,均处于10000tx-20000tx之间。
图3为多客户端提交请求的情况下系统吞吐量变化情况,在实验中设置批处理大小为10000tx,这是因为在该批处理大小下,单客户端吞吐量趋近峰值,便于测量整个系统的峰值吞吐量。从图中可以看出,相比单客户端的情况,多客户端并发下的峰值吞吐量有明显的增长,该峰值也是在该节点规模下系统所能达到的吞吐量的最大值。在4共识节点时峰值吞吐量趋近200000tx/s,而32节点时峰值约为13000tx/s
图4为批处理大小和客户端数量固定的情况下共识延迟和峰值吞吐量随共识节点数量的变化情况。同样的,设置批处理大小为10000tx,在客户端数量为1、4、8的条件下进行测量。该实验反映算法的可扩展性,即在不严重损失效率的情况下所能容纳的节点数量。从微观上看,可扩展性取决于算法的通信复杂度,前文分析过BWBFT共识的通信复杂度为O(n2),实验结果符合其理论通信复杂度。32共识节点和8客户端时,共识延迟约为6.1s,符合许可链的应用场景。
Claims (5)
1.一种应用于许可链的二元加权拜占庭容错共识方法,其特征在于,所述方法的实现过程为:
步骤一、构建系统模型
1)共识模型:采用二元共识模型,共识的输入和输出均由一个二进制位表示,共识的输入和输出均由一个二进制位表示,1表示通过,事务将被执行并改变账簿状态;0表示拒绝,事务不被执行且不改变账簿状态;
2)故障模型假设:采用拜占庭故障模型,故障节点的行为是任意的,包括向正常节点发送错误的或不一致的消息,或不做出响应,允许有一个强大的对手统一控制所有故障节点阻碍共识;基于某类事务的共识与对应主节点命运共享的前提,在共识中不考虑主节点发生故障的情况;
3)可靠信道假设:各节点间均有可靠的授权点对点信道,保证正常节点发送的消息最终会被正确交付;允许同一时刻有多个主节点共同发起共识,且消息可能以乱序到达;对手计算能力有限,无法破解密码学技术;
4)时间假设:系统运行在弱同步环境下,通信延迟不会随着时间推移而无限增长;
步骤二、给出系统参数
假设系统中有n个节点N1,N2,…,Nn,m种事务类型T1,T2,…,Tm。事务类型Tj对应的主节点为Pj,节点Ni对事务类型Tj的权值分配用n维权值向量Wij表示,即
(Tj,Ni)→Wij=[wij1 wij2 …… wijn]
wijk表示针对事务Tj,节点Ni为节点Nk分配的权值大小,权值向量需满足条件
对任意i和.j均成立;
Vi是由节点i对该次共识的事务列表L中全体事务的投票组成的投票向量;矩阵V=[V1V2 … Vn]保存所有节点的投票;同样地,LocalDecisioni和LocalDecision分别为在决策阶段节点i产生的局部决策结果和所有节点的局部决策矩阵,GlobalDecision为主节点在提交阶段产生的全局决策结果;
在任意非故障节点的权值分配中,拜占庭节点所占总权值均不能超过f;当结果超过决策阈值θ时,该事务的决策结果为1通过,反之为0拒绝;
步骤三、二元加权拜占庭容错共识过程:
网络中包含若干参与共识的节点,持续监听来自客户端或其他节点的消息;共识开始前,系统需配置全局参数,包含节点地址、事务类型、主节点信息以及决策阈值,并由每个节点各自完成权值分配;在初始阶段,当主节点监听到来自客户端的请求时,由主节点发起共识;
二元加权拜占庭容错共识(BWBFT共识)分为预准备阶段、投票阶段、决策阶段、提交阶段四个阶段,当节点完成对账簿的更新后,还需将执行结果返回给客户端,以便客户端掌握共识完成情况;BWBFT共识仅在投票阶段包含一次全体广播,其通信复杂度为O(n2)。
2.根据权利要求1所述的一种应用于许可链的二元加权拜占庭容错共识方法,其特征在于,在二元加权拜占庭容错共识过程中每个共识阶段的实现过程为:
客户端:
客户端针对事务类型为T的有序事务列表L发起请求时,需将请求提交给对应的主节点,消息格式为<REQUEST,c,T,L,sig>;其中,c表示客户端身份,便于节点在达成共识后将共识结果回复给客户端,事务种类T决定本次共识中采用的主节点和权值,L为待共识的有序事务列表;
预准备阶段:
当主节点收到来自客户端的请求后,先验证消息有效性,包括事务类型与事务列表之间是否对应、消息是否被提交到正确的主节点处以及消息完整性,若无效则丢弃该消息;否则,主节点为请求生成唯一wID,并将其告知客户端;然后主节点将请求打包成work,格式为(wID,c,T,L,t),其中客户端身份c、事务类型T、事务列表L均来自客户端请求,时间戳t为主节点生成work时的本地时钟,用于保证顺序一致性;然后,主节点广播一个预准备消息将work分发给所有节点,消息格式为<PRE-PREPARE,P,work,sig>,主节点身份P便于其他节点校验其身份有效性,work包含本次共识请求的全部信息,在预准备阶段分发给全体节点,后面阶段仅使用wID作为区分不同work的唯一标识;
投票阶段:
当收到来自主节点的预准备消息时,节点先验证消息有效性并将work记录在本地;然后,节点为work中的事务列表生成投票向量,并将投票广播给全体节点;投票消息格式为<VOTE,wID,I,Vi,sig>,表明节点i针对编号为wID的work在投票阶段产生的投票向量为Vi;
决策阶段:
节点持续收到其他节点的投票消息,并将每个节点的投票向量记录到投票矩阵V中,当节点收集到总权值不少于1-f的投票后,将未收到投票消息的节点的投票向量全部记为0,然后进行局部决策;当节点i对事务类型为Tj的work进行局部决策时,计算
并将结果向量中的每个分量与决策阈值θ进行比较,生成节点i的局部决策结果LocalDecisioni;为将局部决策结果告知主节点,节点生成局部决策消息,格式为<DECISION,wID,i,LocalDecisioni,sig>,表示节点i针对编号为wID的work在决策阶段产生的局部决策结果为LocalDecisioni;
提交阶段:
主节点持续收到其他节点的局部决策消息,并将其记录到局部决策矩阵LocalDecision中;当主节点收集到总权值不少于1-f的局部决策后,将未收到的局部决策全部记为0,然后进行全局决策;当主节点Pj对事务类型为Tj的work进行全局决策时,计算
并将结果向量中的每个分量与决策阈值θ进行比较,生成全局决策结果GlobalDecision,即最终共识结果。为将共识结果告知全体节点,主节点将广播一个提交消息,格式为<COMMIT,wID,GlobalDecision,sig>,表示编号为wID的work的共识结果为GlobalDecision;当节点收到来自主节点的提交消息后,根据共识结果及对应work信息完成对账簿的更新操作,保证账簿的全局一致性。
回复:
当节点完成账簿更新后,需将执行结果回复给客户端,回复格式为<REPLY,I,wID,R,sig>,表示节点i针对编号为wID的work的执行结果为R;在不考虑主节点发生故障的前提下,当收到来自主节点的回复消息后,客户端可确认已达成共识;正常情况下所有节点的执行结果应与主节点相同,若在主节点回复一段时间过后仍有节点未回复,或结果与主节点不同,则认为该节点可能发生故障,客户端可以将主节点的回复消息转发给该节点,帮助其达成共识。
3.根据权利要求2所述的一种应用于许可链的二元加权拜占庭容错共识方法,其特征在于,采用ecdsa算法对各节点间发送的消息进行数字签名,客户端与节点间的交互采用sha256算法验证消息完整性;在通信前为每个节点生成其公私钥对,并为所有节点预先配置所有节点的通信地址和公钥,所有事务类型及其对应主节点,以及在每种事务类型下每个节点的权值分配情况,权值为随机生成。
4.根据权利要求1、2或3所述的一种应用于许可链的二元加权拜占庭容错共识方法,其特征在于,所述方法对多种类型的事务进行共识,且不同种类事务的主节点、权值等信息相互隔绝,彼此间互不影响。
5.根据权利要求1所述的一种应用于许可链的二元加权拜占庭容错共识方法,其特征在于,在步骤1中的密码学技术为无碰撞哈希、加密或数字签名。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010419521.6A CN111682942B (zh) | 2020-05-18 | 2020-05-18 | 一种应用于许可链的二元加权拜占庭容错共识方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010419521.6A CN111682942B (zh) | 2020-05-18 | 2020-05-18 | 一种应用于许可链的二元加权拜占庭容错共识方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111682942A true CN111682942A (zh) | 2020-09-18 |
CN111682942B CN111682942B (zh) | 2022-06-10 |
Family
ID=72434187
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010419521.6A Active CN111682942B (zh) | 2020-05-18 | 2020-05-18 | 一种应用于许可链的二元加权拜占庭容错共识方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111682942B (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112395113A (zh) * | 2020-12-02 | 2021-02-23 | 国网浙江省电力有限公司物资分公司 | 实用拜占庭容错共识方法及装置、可读存储介质 |
CN112714177A (zh) * | 2020-12-24 | 2021-04-27 | 天津科技大学 | 一种具有线性消息复杂度的pbft改进算法 |
CN113783708A (zh) * | 2021-08-25 | 2021-12-10 | 山东区块链研究院 | 一种基于可靠广播的可再投票二元共识方法及装置 |
CN113794576A (zh) * | 2021-08-12 | 2021-12-14 | 山东区块链研究院 | 一种可再投票的二元共识方法及装置 |
CN114189325A (zh) * | 2021-11-19 | 2022-03-15 | 新疆大学 | 具有高容错可扩展的拜占庭容错方法、装置及存储介质 |
CN114584312A (zh) * | 2021-10-09 | 2022-06-03 | 支付宝(杭州)信息技术有限公司 | 一种共识方法、区块链系统和共识节点 |
CN114629772A (zh) * | 2022-03-22 | 2022-06-14 | 浙江大学 | 一种拜占庭容错方法、装置、系统、电子装置和存储介质 |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106445711A (zh) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | 一种应用于区块链的拜占庭容错共识方法 |
CN107423962A (zh) * | 2017-07-11 | 2017-12-01 | 成都励睿德企业管理有限公司 | 基于奖惩的数据区块链授权参与共识的拜占庭容错方法及其奖惩方法 |
CN109347804A (zh) * | 2018-09-19 | 2019-02-15 | 电子科技大学 | 一种用于区块链的拜占庭容错共识优化方法 |
CN109685505A (zh) * | 2018-12-24 | 2019-04-26 | 电子科技大学 | 基于关联环签名的拜占庭容错共识优化方法 |
CN109767199A (zh) * | 2018-12-10 | 2019-05-17 | 西安电子科技大学 | 基于信誉的pbft共识系统及方法、区块链数据处理系统 |
US20190251077A1 (en) * | 2018-11-07 | 2019-08-15 | Alibaba Group Holding Limited | Facilitating practical byzantine fault tolerance blockchain consensus and node synchronization |
CN110278091A (zh) * | 2018-03-13 | 2019-09-24 | 焦臻桢 | 一种物联网区块链共识方法 |
CN110445619A (zh) * | 2017-03-30 | 2019-11-12 | 腾讯科技(深圳)有限公司 | 区块链系统、消息处理方法及存储介质 |
CN110569675A (zh) * | 2019-09-18 | 2019-12-13 | 上海海事大学 | 一种基于区块链技术的多Agent交易信息保护方法 |
CN110636113A (zh) * | 2019-08-23 | 2019-12-31 | 上海电力大学 | 区块链的拜占庭容错共识方法、系统、设备和存储介质 |
-
2020
- 2020-05-18 CN CN202010419521.6A patent/CN111682942B/zh active Active
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106445711A (zh) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | 一种应用于区块链的拜占庭容错共识方法 |
CN110445619A (zh) * | 2017-03-30 | 2019-11-12 | 腾讯科技(深圳)有限公司 | 区块链系统、消息处理方法及存储介质 |
CN107423962A (zh) * | 2017-07-11 | 2017-12-01 | 成都励睿德企业管理有限公司 | 基于奖惩的数据区块链授权参与共识的拜占庭容错方法及其奖惩方法 |
CN110278091A (zh) * | 2018-03-13 | 2019-09-24 | 焦臻桢 | 一种物联网区块链共识方法 |
CN109347804A (zh) * | 2018-09-19 | 2019-02-15 | 电子科技大学 | 一种用于区块链的拜占庭容错共识优化方法 |
US20190251077A1 (en) * | 2018-11-07 | 2019-08-15 | Alibaba Group Holding Limited | Facilitating practical byzantine fault tolerance blockchain consensus and node synchronization |
CN109767199A (zh) * | 2018-12-10 | 2019-05-17 | 西安电子科技大学 | 基于信誉的pbft共识系统及方法、区块链数据处理系统 |
CN109685505A (zh) * | 2018-12-24 | 2019-04-26 | 电子科技大学 | 基于关联环签名的拜占庭容错共识优化方法 |
CN110636113A (zh) * | 2019-08-23 | 2019-12-31 | 上海电力大学 | 区块链的拜占庭容错共识方法、系统、设备和存储介质 |
CN110569675A (zh) * | 2019-09-18 | 2019-12-13 | 上海海事大学 | 一种基于区块链技术的多Agent交易信息保护方法 |
Non-Patent Citations (2)
Title |
---|
VIJAY K. GARG ET AL: "The Weighted Byzantine Agreement Problem", 《2011 IEEE INTERNATIONAL PARALLEL & DISTRIBUTED PROCESSING SYMPOSIUM》 * |
张良嵩: "基于拜占庭容错的区块链共识算法研究", 《中国优秀硕士学位论文全文数据库》 * |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112395113A (zh) * | 2020-12-02 | 2021-02-23 | 国网浙江省电力有限公司物资分公司 | 实用拜占庭容错共识方法及装置、可读存储介质 |
CN112395113B (zh) * | 2020-12-02 | 2023-06-27 | 国网浙江省电力有限公司物资分公司 | 实用拜占庭容错共识方法及装置、可读存储介质 |
CN112714177A (zh) * | 2020-12-24 | 2021-04-27 | 天津科技大学 | 一种具有线性消息复杂度的pbft改进算法 |
CN112714177B (zh) * | 2020-12-24 | 2022-11-29 | 天津科技大学 | 一种具有线性消息复杂度的pbft改进算法 |
CN113794576A (zh) * | 2021-08-12 | 2021-12-14 | 山东区块链研究院 | 一种可再投票的二元共识方法及装置 |
WO2023016429A1 (zh) * | 2021-08-12 | 2023-02-16 | 山东区块链研究院 | 一种可再投票的二元共识方法、装置、电子设备及存储介质 |
CN113783708A (zh) * | 2021-08-25 | 2021-12-10 | 山东区块链研究院 | 一种基于可靠广播的可再投票二元共识方法及装置 |
CN114584312A (zh) * | 2021-10-09 | 2022-06-03 | 支付宝(杭州)信息技术有限公司 | 一种共识方法、区块链系统和共识节点 |
CN114584312B (zh) * | 2021-10-09 | 2024-03-29 | 支付宝(杭州)信息技术有限公司 | 一种共识方法、区块链系统和共识节点 |
CN114189325B (zh) * | 2021-11-19 | 2023-09-29 | 新疆大学 | 具有高容错可扩展的拜占庭容错方法、装置及存储介质 |
CN114189325A (zh) * | 2021-11-19 | 2022-03-15 | 新疆大学 | 具有高容错可扩展的拜占庭容错方法、装置及存储介质 |
CN114629772A (zh) * | 2022-03-22 | 2022-06-14 | 浙江大学 | 一种拜占庭容错方法、装置、系统、电子装置和存储介质 |
CN114629772B (zh) * | 2022-03-22 | 2023-03-10 | 浙江大学 | 一种拜占庭容错方法、装置、系统、电子装置和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN111682942B (zh) | 2022-06-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111682942B (zh) | 一种应用于许可链的二元加权拜占庭容错共识方法 | |
Gupta et al. | Resilientdb: Global scale resilient blockchain fabric | |
CN109246176B (zh) | 软件定义网络中基于区块链的多控制器同步方法及装置 | |
CN110399424B (zh) | 区块生成方法、装置、区块链节点及存储介质 | |
CN111311414A (zh) | 一种基于一致性哈希算法的区块链多方共识方法 | |
CN111988203B (zh) | 节点选举方法、装置及存储介质 | |
CN111698094B (zh) | 一种基于区块链系统的共识方法及区块链系统 | |
CN111092896A (zh) | 基于优化paxos的食品溯源分布式数据同步方法 | |
CN111478795B (zh) | 一种基于混合拜占庭容错的联盟区块链网络共识方法 | |
CN114050904B (zh) | 一种基于两层级领导节点分片结构的共识系统及方法 | |
CN112636905B (zh) | 基于多角色的可扩展共识机制的系统及方法 | |
CN111582843A (zh) | 一种基于聚合签名的区块链隐私交易方法 | |
CN113132401A (zh) | 基于区块链的数据处理方法和装置 | |
Tian et al. | A byzantine fault-tolerant raft algorithm combined with Schnorr signature | |
CN114503143A (zh) | 统一协议共识 | |
CN112395113A (zh) | 实用拜占庭容错共识方法及装置、可读存储介质 | |
CN110990790B (zh) | 一种数据处理方法及设备 | |
CN115134086A (zh) | 异步网络的动态委员会秘密分享更新方法及装置 | |
Chen et al. | MSig-BFT: A witness-based consensus algorithm for private blockchains | |
CN114513510A (zh) | 一种面向许可链的分布式跨链事务中继系统及其通信方法 | |
CN114422146A (zh) | 一种区块链主节点匿名排序方法 | |
CN116567631B (zh) | 一种基于分片区块链的移动终端安全认证方法 | |
Wu et al. | Reinforced practical Byzantine fault tolerance consensus protocol for cyber physical systems | |
CN113254526A (zh) | 区块链共识方法、装置及系统 | |
CN113507528B (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 | ||
CB02 | Change of applicant information |
Address after: 150001 No. 92 West straight street, Nangang District, Heilongjiang, Harbin Applicant after: HARBIN INSTITUTE OF TECHNOLOGY Applicant after: Beijing Jingning Data Technology Co., Ltd Address before: 150001 No. 92 West straight street, Nangang District, Heilongjiang, Harbin Applicant before: HARBIN INSTITUTE OF TECHNOLOGY Applicant before: Nanjing Yuanzhi Data Technology Co.,Ltd. |
|
CB02 | Change of applicant information | ||
GR01 | Patent grant | ||
GR01 | Patent grant |