CN109981565A - 基于Meta-BFT共识机制的区块链平台及实现方法 - Google Patents
基于Meta-BFT共识机制的区块链平台及实现方法 Download PDFInfo
- Publication number
- CN109981565A CN109981565A CN201910088522.4A CN201910088522A CN109981565A CN 109981565 A CN109981565 A CN 109981565A CN 201910088522 A CN201910088522 A CN 201910088522A CN 109981565 A CN109981565 A CN 109981565A
- Authority
- CN
- China
- Prior art keywords
- node
- block
- orderers
- controller node
- meta
- 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
Classifications
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Abstract
本发明属于区块链共识算法技术领域,具体为一种基于Meta‑BFT(Metamorphosis Byzantine Fault‑Tolerant)共识机制的区块链平台及实现方法,主要包括:Controller节点选择模型、Orderers节点、Controller节点、Peers节点、CA认证中心和APP/SDK客户端。所述方法包括以下步骤:步骤S1、所述APP/SDK客户端向所述CA认证中心进行注册/登录;步骤S2、根据所述Controller节点选择模型从所述Orderers节点中选择出Controller节点,进而所有所述APP/SDK客户端只向所述Controller节点发送服务请求;步骤S3、所述Controller节点基于所述Meta‑BFT共识机制对区块链网络中所有合法交易进行排序,并把排序好的交易组合生成区块结构,同时将结果发送所述Peers节点;步骤S4、由所述Peers节点确认后把结果返回给所述APP/SDK客户端,以及将信息同步给所述Orderers节点。
Description
技术领域
本发明属于区块链共识算法技术领域,具体涉及为基于 Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链 平台及实现方法。
背景技术
近年来,区块链技术作为一种新兴技术而备受各个行业关注,并 且因其具备去中心化、分布式、不可篡改、加密计算、可追溯、可信 任等独特优势而已经被广泛运用于各个领域。特别是在以太坊 (Ethereum)和超级账本(Hyperledger)Fabric等区块链平台被相继发布 之后,各个行业逐渐开始研究如何将自己原有产业与区块链融合,进 而力图改善其产品的效率和可靠性。与此同时,越来越多的区块链项 目也相继被开发与试运行。另一方面,共识算法是区块链中最为关键 的技术之一,也是影响区块链吞吐量和区块打包效率的主要因素。
目前,在区块链共识算法研究领域中,主要有以下两种共识算法:
(1)PoW(Proof-of-Work)共识算法。PoW一词最早由Markus Jakobsson和AriJuels提出,而中本聪(Satoshi Nakamoto)在它的基础 上,在其发表的论文《Bitcoin:APeer-to-Peer Electronic Cash System》 中首先引入了PoW共识算法概念。该算法的主要思想为:首先生成比 特币(Bitcoin)交易,并与其它所有准备打包到区块中的信息一起组成交易列表;其次,通过Merkle Tree算法生成Merkle Root Hash;然 后,把Merkle RootHash及其他相关字段组装成区块头 (Block_Header),并将区块头的字节数据作为工作量证明的输入; 最后,持续变更区块头中的随机数(nonce值),对每次变更后的区块 头做双重SHA256运算(SHA256(SHA256(Block_Header))),直至结果 值小于当前网络给定的目标值时结束。
PoW共识算法主要运用于比特币和以太坊区块链平台中,具有较 高的公信力和可扩展性等优点。但是,它们都存在吞吐量较低和延迟 较大等问题。例如:在比特币网络中,其吞吐量约等于7,延迟约等 于1个小时;在以太坊网络中,其吞吐量约等于100,延迟约等于90 秒。此外,在PoW基础上,PoS、DPoS等共识算法相继被提出。但是, 已有这类算法普遍具有吞吐量较低、延迟较大、区块链打包效率较低 等缺点。
(2)PBFT(Practical Byzantine Fault-Tolerant)共识算法。PBFT 共识算法是卡斯特罗(Miguel Castro)等人在1999年提出的一种高效 的拜占庭容错共识算法,相比PoW共识算法具有更高的效率。PBFT 共识算法主要包括四个阶段:第一阶段为Request阶段,客户端向主 节点发送服务请求;第二阶段为Pre-prepare阶段,主节点向所有副本 节点发送Pre-prepare信息;第三阶段为Prepare阶段,副本节点通过验 证主节点信息,然后向给主节点和其它副本节点发送Prepare信息;第 四阶段为Commit阶段,所有节点向其它节点发送Commit信息,然后 在每个节点接收到一定数量的确认信息后,把执行结果反馈给客户端。
PBFT共识算法主要被应用于超级账本Fabric区块链平台,具体是 在Orderers节点的排序过程中被调用执行,使得对客户端的请求达成 共识。与PoW共识算法相比,PBFT共识算法虽然具有相对较高的吞 吐量(1000左右)和较小的延迟(1秒左右),但是仍然难以满足实际 交易过程中高并发的需求。此外,PBFT共识还存在可扩展性较低和 公信力较差等问题,并且随着节点数的增加,其吞吐量呈现急剧下降。
已有的这些区块链服务平台普遍存在着吞吐量较低、延迟较大、 区块打包速度低和节点难扩展等问题,以至于几乎无法满足实际市场 交易中需要达到每秒万次的高并发量要求。因此,研究设计一种高效 可信任的区块链共识机制尤为重要,并且是进一步提高区块链平台吞 吐量和区块打包效率的重要方法之一。
发明内容
本发明主要目的是为了解决已有许可区块链平台中吞吐量较低、 延迟较大、共识效率低和可扩展性低等问题,进而提出一种基于 Meta-BFT(Metamorphosis ByzantineFault-Tolerant)共识机制的区块链 平台及实现方法。
本发明主要通过以下技术方案解决上述问题:
提供一种基于Meta-BFT共识机制的区块链平台,包括APP/SDK 客户端、CA(Certificate Administrator)认证中心、Orderers节点、Peers 节点、Controller节点选择模型以及Controller节点;
所述APP/SDK客户端,用于向所述CA认证中心进行注册/登录以 获得授权,发起服务请求和接收执行结果;
所述CA认证中心,用于对所述APP/SDK客户端进行认证、校验、 授权;
所述Orderers节点是区块链网络中的权威节点,具有对交易排序 的权利;
所述Peers节点,用于维护区块链和账本结构;
所述Controller节点选择模型,用于从所述Orderers节点中选择出 Controller节点;
所述Controller节点,用于基于所述Meta-BFT共识机制对区块链 网络中所有的合法交易进行排序服务,并将排好序的合法交易组合成 区块结构发送给Peers节点。
进一步地,所述CA认证中心包括PKI架构和客户端源码校验进 程,其中所述PKI架构用于管理区块链网络用户证书,所述客户端源 码校验进程用于校验客户端源码是否被篡改。
进一步地,所述Controller节点包括服务请求API,Meta-BFT服务 代理,生产区块结构进程,节点进程以及签名、发送进程;其中所述 服务请求API用于和所述APP/SDK客户端进行信息交互;所述 Meta-BFT服务代理用于基于所述Meta-BFT共识机制对所有合法交易 进行排序;所述生产区块结构进程用于生成经过排序交易后的区块结 构;所述节点进程用于监听生产区块结构进度;所述签名、发送进程 主用于对区块结构进行签名和向Peers节点发送区块。
进一步地,所述Controller节点选择模型是利用前一个区块Hash 值对所述Orderers节点总数求余数,进而从所述Orderers节点选择出与 计算结果的余数具有相同编号的Orderers节点作为所述Controller节 点,其中平台初始化时需产生第一个创世区块。
进一步地,所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制包括请求、准备、确认和回复/广播四个阶段;
所述请求阶段:所述APP/SDK客户端向所述Controller节点发送 请求服务;
所述准备阶段:所述Controller节点基于所述请求服务向所有 Orderers节点发送准备消息,然后所有Orderers节点验证所述Controller 节点身份、服务请求、签名信息,如果一致,则进入确认阶段;
所述确认阶段:所有Orderers节点给所述Controller节点发送确认 消息;如果Controller节点收到确认成功的消息个数大于等于即 可达成共识,其中f为拜占庭错误容忍个数,且3f+1≤|N|,|N|为 网络中所有Orderers节点个数;
所述回复/广播阶段:在完成确认后,所述Controller节点再把执 行结果返回给所述APP/SDK客户端和所有Orderers节点。
还提供一种基于Meta-BFT共识机制的区块链平台的实现方法, 所述区块链平台包括APP/SDK客户端、CA(Certificate Administrator) 认证中心、Orderers节点、Peers节点、Controller节点选择模型以及 Controller节点;
步骤S1、所述APP/SDK客户端向所述CA认证中心进行注册/登 录;
步骤S2、根据所述Controller节点选择模型从所述Orderers节点中 选择出Controller节点,进而所有所述APP/SDK客户端只向所述 Controller节点发送服务请求;
步骤S3、所述Controller节点基于所述Meta-BFT(Metamorphosis ByzantineFault-Tolerant)共识机制对区块链网络中所有合法交易进行 排序,并把排序好的交易组合生成区块结构,同时将结果发送所述 Peers节点;
步骤S4、由所述Peers节点确认后把结果返回给所述APP/SDK客 户端,以及将信息同步给所述Orderers节点。
进一步地,所述步骤S3包括:
步骤S31、由服务请求API接收来自于所述APP/SDK客户端的服 务请求;
步骤S32、调用Meta-BFT(Metamorphosis Byzantine Fault-Tolerant) 服务代理基于所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant) 共识机制对所有合法交易进行排序;
步骤S33、生产区块结构进程将排序后交易打包成区块结构,并 由节点进程通知签名、发送进程完成区块打包的信息;
步骤S34、签名、发送进程对区块进行签名和向所述Peers节点发 送交易区块。
进一步地,所述步骤S4包括:
步骤S41、对所述Controller节点发送过来的交易区间进行检查与 确认;
步骤S42、把通过检查的合法交易记录到账中;
步骤S43、把执行结果同步到所述APP/SDK客户端和所述 Orderers节点,同时发送当前产生的区块Hash值发送到所述Controller 节点选择模型,用以触发所述Controller节点选择模型从所述Orderers 节点选择出Controller节点。
进一步地,所述Controller节点选择模型是利用前一个区块Hash 值对所述Orderers节点总数求余数,进而从所述Orderers节点选择出与 计算结果的余数具有相同编号的Orderers节点作为所述Controller节 点,其中平台初始化时需产生第一个创世区块。
进一步地,所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制包括请求、准备、确认和回复/广播四个阶段;
所述请求阶段:所述APP/SDK客户端向所述Controller节点发送 请求服务;
所述准备阶段:所述Controller节点基于所述请求服务向所有 Orderers节点发送准备消息,然后所有Orderers节点验证所述Controller 节点身份、服务请求、签名信息,如果一致,则进入确认阶段;
所述确认阶段:所有Orderers节点给所述Controller节点发送确认 消息;如果Controller节点收到确认成功的消息个数大于等于即 可达成共识,其中f为拜占庭错误容忍个数,且3f+1≤|N|,|N|为 网络中所有Orderers节点个数;
所述回复/广播阶段:在完成确认后,所述Controller节点再把执 行结果返回给所述APP/SDK客户端和所有Orderers节点。
与已有技术相比,本发明的优势主要包括:
(1)提高已有许可区块链平台的吞吐量、共识效率;
(2)降低已有许可区块链平台的交易确认延迟时间;
(3)有助于解决已有许可区块链平台的节点难扩展问题。
附图说明
为了更清楚地描述本发明实施例中的技术方案,下面对实施例 描述中所需要使用的附图进行简要说明。
图1为本发明的一种基于Meta-BFT共识机制的区块链平台总体 架构示意图。
图2为本发明的Controller节点选择模型的实现流程示意图。
图3为本发明的Meta-BFT共识机制示意图。
图4为本发明的一种基于Meta-BFT共识机制的区块链平台及实 现方法具体应用于Fabric区块链平台的交易处理流程示意图。
具体实施方式
为方便读者能够更加清晰地了解本发明的技术方案、特征和优点, 下面将结合附图和相应的实施例对本发明作详细说明。需指出的是, 下面所描述的实施例仅仅是本发明的部分实施例内容,也就是说,不 能仅根据以下实施例来限制本发明的保护范围。
实施例一
如图1所示,本发明提供一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台,包括APP/SDK客户 端、CA(CertificateAdministrator)认证中心、Orderers节点、Peers节点、 Controller节点选择模型以及Controller节点;
所述APP/SDK客户端,用于向所述CA认证中心进行注册/登录以 获得授权,发起服务请求和接收执行结果;
所述CA认证中心,用于对所述APP/SDK客户端进行认证、校验、 授权;
所述Orderers节点是区块链网络中的权威节点,具有对交易排序 的权利;
所述Peers节点,用于维护区块链和账本结构;
所述Controller节点选择模型,用于从所述Orderers节点中选择出 Controller节点;
所述Controller节点,用于基于所述Meta-BFT共识机制对区块链 网络中所有的合法交易进行排序服务,并将排好序的合法交易组合成 区块结构发送给Peers节点。
进一步地,所述CA认证中心包括PKI架构和客户端源码校验进 程,其中所述PKI架构用于管理区块链网络用户证书,所述客户端源 码校验进程用于校验客户端源码是否被篡改。
进一步地,所述Controller节点包括服务请求API,Meta-BFT服务 代理,生产区块结构进程,节点进程以及签名、发送进程;其中所述 服务请求API用于和所述APP/SDK客户端进行信息交互;所述 Meta-BFT服务代理用于基于所述Meta-BFT共识机制对所有合法交易 进行排序;所述生产区块结构进程用于生成经过排序交易后的区块结 构;所述节点进程用于监听生产区块结构进度;所述签名、发送进程 主用于对区块结构进行签名和向Peers节点发送区块。
进一步地,所述Controller节点选择模型是利用前一个区块Hash 值对所述Orderers节点总数求余数,进而从所述Orderers节点选择出与 计算结果的余数具有相同编号的Orderers节点作为所述Controller节 点,其中平台初始化时需产生第一个创世区块。
更具体的Controller节点选择模型的实现流程如图2所示,Controller节点选择模型实施的主要过程为:首先初始化视图变量v=0;然后通过前一个区块Hash 值对Orderers节点总数|N|(N为网络中Orderers节点的集合)求余数来计算 Controller节点的编号i(0≤i≤|N|);接着调用verify()函数来验证Controller节点 是否有效,如果有效,则选择编号为i的Orderers节点Ni为Controller节点,同时 结束本次运行,如果无效,则令v++,同时广播发送改变视图消息。这时,如果 收到改变视图消息个数count()大于等于|N|-f(f为拜占庭错误容忍个数,且 3f+1≤|N|),则令v=0,同时重新根据Controller节点选择计算公式生成 Controller节点。反之,如果收到改变视图消息个数count()小于|N|-f,则再次回 到v++过程,重新发起改变视图消息,进入下一次Controller节点选择过程。Controller节点选择的具体计算公式如下:
Controller=Ni (1)
其中:
i=(Pre_hash)10%|N| (2)
Pre_hash为前一个区块的Hash值,(Pre_hash)10表示将Pre_hash转 为十进制数,|N|为总的Orderers节点个数。
进一步地,如图3所示,是本发明中Meta-BFT共识机制的一个实 施例示意图,其主要包括:APP/SDK客户端、Controller节点和Orderers 节点。
与PBFT相比,Meta-BFT共识算法减少了预准备(Pre-prepare) 阶段和通信次数,进而有效地提高了共识过程执行的效率。
所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制 包括请求、准备、确认和回复/广播四个阶段;
所述请求阶段:所述APP/SDK客户端向所述Controller节点发送 请求服务;
所述准备阶段:所述Controller节点基于所述请求服务向所有 Orderers节点发送准备消息,然后所有Orderers节点验证所述Controller 节点身份、服务请求、签名信息,如果一致,则进入确认阶段;
所述确认阶段:所有Orderers节点给所述Controller节点发送确认 消息;如果Controller节点收到确认成功的消息个数大于等于即 可达成共识;
所述回复/广播阶段:在完成确认后,所述Controller节点再把执 行结果返回给所述APP/SDK客户端和所有Orderers节点。
需要说明的是,根据实际许可区块链网络中的节点部署,所述执 行结果所返回的节点即可以仅是Orderers节点,也可以是Orderers、 Peers等节点。
本发明还提供一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台的实现方法,所述区块链平台包 括APP/SDK客户端、CA(Certificate Administrator)认证中心、Orderers 节点、Peers节点、Controller节点选择模型以及Controller节点;
所述方法主要包括以下步骤:
步骤S1、所述APP/SDK客户端向所述CA认证中心进行注册/登 录;
步骤S2、根据所述Controller节点选择模型从所述Orderers节点中 选择出Controller节点,进而所有所述APP/SDK客户端只向所述 Controller节点发送服务请求;
步骤S3、所述Controller节点基于所述Meta-BFT(Metamorphosis ByzantineFault-Tolerant)共识机制对区块链网络中所有合法交易进行 排序,并把排序好的交易组合生成区块结构,同时将结果发送所述 Peers节点;
步骤S4、由所述Peers节点确认后把结果返回给所述APP/SDK客 户端,以及将信息同步给所述Orderers节点。
进一步地,所述CA认证中心,包括PKI架构和客户端源码校验进 程。PKI架构用于管理区块链网络用户证书,客户端源码校验进程用 于校验客户端源码是否被篡改。
进一步地,所述步骤S3包括:
步骤S31、由服务请求API接收来自于所述APP/SDK客户端的服 务请求;
步骤S32、调用Meta-BFT(Metamorphosis Byzantine Fault-Tolerant) 服务代理基于所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant) 共识机制对所有合法交易进行排序;
步骤S33、生产区块结构进程将排序后交易打包成区块结构,并 由节点进程通知签名、发送进程完成区块打包的信息;
步骤S34、签名、发送进程对区块进行签名和向所述Peers节点发 送交易区块。
进一步地,所述Peers节点负责维护区块链和账本结构(包括维 护状态DB、历史DB、索引DB等)。
所述步骤S4进一步包括:
步骤S41、对所述Controller节点发送过来的交易区间进行检查与 确认;
步骤S42、把通过检查的合法交易记录到账中;
步骤S43、把执行结果同步到所述APP/SDK客户端和所述 Orderers节点,同时发送当前产生的区块Hash值发送到所述Controller 节点选择模型,用以触发所述Controller节点选择模型从所述Orderers 节点选择出Controller节点。
进一步地,所述Controller节点选择模型是利用前一个区块Hash 值对所述Orderers节点总数求余数,进而从所述Orderers节点选择出与 计算结果的余数具有相同编号的Orderers节点作为所述Controller节 点。
更具体的Controller节点选择模型的实现流程如图2所示,Controller节点选择模型实施的主要过程为:首先初始化视图变量v=0;然后通过前一个区块Hash 值对Orderers节点总数|N|(N为网络中Orderers节点的集合)求余数来计算 Controller节点的编号i(0≤i≤|N|);接着调用verify()函数来验证Controller节点 是否有效,如果有效,则选择编号为i的Orderers节点Ni为Controller节点,同时 结束本次运行,如果无效,则令v++,同时广播发送改变视图消息。这时,如果 收到改变视图消息个数count()大于等于|N|-f(f为拜占庭错误容忍个数,且 3f+1≤|N|),则令v=0,同时重新根据Controller节点选择计算公式生成 Controller节点。反之,如果收到改变视图消息个数count()小于|N|-f,则再次回 到v++过程,重新发起改变视图消息,进入下一次Controller节点选择过程。Controller节点选择的具体计算过程如公式(1)所示。
进一步地,所述Meta-BFT共识机制如图3所示,包括请求、准备、 确认和回复/广播四个阶段;
所述请求阶段:所述APP/SDK客户端向所述Controller节点发送 请求服务;
所述准备阶段:所述Controller节点基于所述请求服务向所有 Orderers节点发送准备消息,然后所有Orderers节点验证所述Controller 节点身份、服务请求、签名信息,如果一致,则进入确认阶段;
所述确认阶段:所有Orderers节点给所述Controller节点发送确认 消息;如果Controller节点收到确认成功的消息个数大于等于即 可达成共识;
所述回复/广播阶段:在完成确认后,所述Controller节点再把执 行结果返回给所述APP/SDK客户端和所有Orderers节点。
实施例二
如图4所示,为本发明的一种基于Meta-BFT共识机制的区块链平 台及实现方法具体应用在Fabric区块链平台上的的交易处理流程示意 图,在实施例一的基础上,将Peers节点进一步细分为Peers(Endorser) 节点和Peers(Committer)节点。
所述区块链平台主要包括:APP/SDK客户端、CA(Certificate Administrator)认证中心、Peers(Endorser)节点、Peers(Committer)节点、 Controller节点选择模型、Controller节点和Orderers节点。
所述APP/SDK客户端,用于向所述CA认证中心进行注册/登录以 获得授权,发起服务请求和接收执行结果。
进一步地,所述APP/SDK客户端,还需要进行签名校验,比对多 个Endorser以及检查是否收集到了足够多(根据系统实际背书策略而 定)的背书(Endorsement)支持。
所述CA认证中心,是区块链网络上的一个认证授权机构,用于 对所述APP/SDK客户端进行认证、校验、授权。
进一步地,所述CA认证中心还用于实现PKI架构、管理区块链网 络证书和校验客户端源代码是否被篡改。
所述Peers(Endorser)节点为背书节点,其主要任务是对交易提案 进行背书处理,然后把背书处理后的决定反馈给所述APP/SDK客户 端。此外,该节点还将一直监听区块链网络中服务请求的执行结果, 以及把监听到的执行结果转发给所述APP/SDK客户端。
进一步地,所述Peers(Endorser)节点还用于校验Proposal签名;检 验是否满足Channel ACL;模拟执行交易并对结果签名(ESCC)。
所述Peers(Committer)节点是确认节点,其主要职责是维护区块 链和账本结构,它将对所述Controller节点发送过来的交易区块结构进 行记账前的最后一次检查与确认,然后把通过检查的区块结构打包成 区块,最后把区块录到账本中,以及将信息同步到所述Peers(Endorser) 节点和所述Orderers节点。
进一步地,所述Peers(Committer)节点检查交易结构完整性、签 名、是否重复;检验交易是否符合背书(Endorsement)策略(VSCC); 检查读集合中版本与账本是否一致;以及执行区块中的合法交易,更 新账本状态。
所述Controller节点选择模型采用图2中的实施例方式,其主要功 能为从所述Orderers节点中产生一个Controller节点。
所述Controller节点主要用于基于图3中的Meta-BFT共识机制对 所述APP/SDK客户端发送过来的交易进行排序操作,并把排好序的交 易组合成区块结构,最后发送给Peers(Committer)节点进行检查与确 以。
所述Orderers节点是区块链网络中的权威节点,具有对交易排序 的权利。
本发明的实施例二还提供又一种基于Meta-BFT共识机制的区块 链平台实现方法,主要包括以下步骤:
步骤0、所述APP/SDK客户端向所述CA认证中心进行注册/登录 以获得一个合法的身份证书来加入到网络;
步骤1、所述APP/SDK客户端构造一个交易提案给所述 Peers(Endorser)节点;其中所述交易提案包括通道id、链码、参数、 用户签名;
步骤2、所述Peers(Endorser)节点回复所述交易提案响应;所述交 易提案响应包括读写设置、endorsement状态、endorser签名;
步骤3、待所述APP/SDK客户端接收到满足条件的背书决定后就 会构造一个合法的交易请求给所述Peers(Endorser)节点,并由所述 Peers(Endorser)节点将该请求转发给所述Controller节点;所述交易请 求包括读写设置、endorser签名、通道id;
步骤4、所述Controller节点根据所述Controller节点选择模型从所 述Orderers节点中选择出Controller节点,进而所有所述APP/SDK客户 端只向所述Controller节点发送服务请求;所述Controller节点基于所 述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制对区块 链网络中所有合法交易进行排序,并把排序好的交易组合生成交易区 块结构;
步骤5、所述Controller节点发送所述交易区块结构到所述 Peers(Committer)节点;所述Peers(Committer)节点对所述Controller节 点发送过来的交易区块结构进行记账前的最后一次检查与确认,然后 把通过检查的交易区块结构打包成区块,最后把区块录到账本中,以 及将信息同步到所述Peers(Endorser)节点和所述Orderers节点。
进一步地,所述APP/SDK客户端还将通过监听网络中所述 Peers(Endorser)节点的状态来确认交易请求是否被成功执行。
尽管上述实施例已经对本发明进行了较为具体的表述与说明,但 是其仅仅只能表述本发明的几种主要实施方式,而不能代表本发明专 利所涵盖的保护范围。因此,如果本领域的相关研究人员,在不脱离 本发明构思的前提下,对本发明进行相关的实施与应用,那么仍然属 于本发明的保护范围之内。
Claims (10)
1.一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台,其特征在于,包括APP/SDK客户端、CA认证中心、Orderers节点、Peers节点、Controller节点选择模型以及Controller节点;
所述APP/SDK客户端,用于向所述CA认证中心进行注册/登录以获得授权,发起服务请求和接收执行结果;
所述CA认证中心,用于对所述APP/SDK客户端进行认证、校验、授权;
所述Orderers节点是区块链网络中的权威节点,具有对交易排序的权利;
所述Peers节点,用于维护区块链和账本结构;
所述Controller节点选择模型,用于从所述Orderers节点中选择出Controller节点;
所述Controller节点,用于基于所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制对区块链网络中所有的合法交易进行排序服务,并将排好序的合法交易组合成区块结构发送给Peers节点。
2.根据权利要求1所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台,其特征在于,所述CA认证中心包括PKI架构和客户端源码校验进程,其中所述PKI架构用于管理区块链网络用户证书,所述客户端源码校验进程用于校验客户端源码是否被篡改。
3.根据权利要求1所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台,其特征在于,所述Controller节点包括服务请求API,Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)服务代理,生产区块结构进程,节点进程以及签名、发送进程;其中所述服务请求API用于和所述APP/SDK客户端进行信息交互;所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)服务代理用于基于所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制对所有合法交易进行排序;所述生产区块结构进程用于生成经过排序交易后的区块结构;所述节点进程用于监听生产区块结构进度;所述签名、发送进程主用于对区块结构进行签名和向Peers节点发送区块。
4.根据权利要求1所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台,其特征在于,所述Controller节点选择模型是利用前一个区块Hash值对所述Orderers节点总数求余数,进而从所述Orderers节点选择出与计算结果的余数具有相同编号的Orderers节点作为所述Controller节点,其中平台初始化时需产生第一个创世区块。
5.根据权利要求1所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台,其特征在于,所述Meta-BFT(Metamorphosis ByzantineFault-Tolerant)共识机制包括请求、准备、确认和回复/广播四个阶段;
所述请求阶段:所述APP/SDK客户端向所述Controller节点发送请求服务;
所述准备阶段:所述Controller节点基于所述请求服务向所有Orderers节点发送准备消息,然后所有Orderers节点验证所述Controller节点身份、服务请求、签名信息,如果一致,则进入确认阶段;
所述确认阶段:所有Orderers节点给所述Controller节点发送确认消息;如果Controller节点收到确认成功的消息个数大于等于即可达成共识,其中f为拜占庭错误容忍个数,且3f+1≤|N|,|N|为网络中所有Orderers节点个数;
所述回复/广播阶段:在完成确认后,所述Controller节点再把执行结果返回给所述APP/SDK客户端和所有Orderers节点。
6.一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台的实现方法,其特征在于,所述区块链平台包括APP/SDK客户端、CA(CertificateAdministrator)认证中心、Orderers节点、Peers节点、Controller节点选择模型以及Controller节点;所述方法包括以下步骤:
步骤S1、所述APP/SDK客户端向所述CA认证中心进行注册/登录;
步骤S2、根据所述Controller节点选择模型从所述Orderers节点中选择出Controller节点,进而所有所述APP/SDK客户端只向所述Controller节点发送服务请求;
步骤S3、所述Controller节点基于所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制对区块链网络中所有合法交易进行排序,并把排序好的交易组合生成区块结构,同时将结果发送所述Peers节点;
步骤S4、由所述Peers节点确认后把结果返回给所述APP/SDK客户端,以及将信息同步给所述Orderers节点。
7.根据权利要求6所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台的实现方法,其特征在于,所述步骤S3进一步包括:
步骤S31、由服务请求API接收来自于所述APP/SDK客户端的服务请求;
步骤S32、调用Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)服务代理基于所述Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制对所有合法交易进行排序;
步骤S33、生产区块结构进程将排序后交易打包成区块结构,并由节点进程通知签名、发送进程完成区块打包的信息;
步骤S34、签名、发送进程对区块进行签名和向所述Peers节点发送交易区块。
8.根据权利要求6所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台的实现方法,其特征在于,所述步骤S4进一步包括:
步骤S41、对所述Controller节点发送过来的交易区间进行检查与确认;
步骤S42、把通过检查的合法交易记录到账中;
步骤S43、把执行结果同步到所述APP/SDK客户端和所述Orderers节点,同时发送当前产生的区块Hash值发送到所述Controller节点选择模型,用以触发所述Controller节点选择模型从所述Orderers节点选择出Controller节点。
9.根据权利要求6所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台的实现方法,其特征在于,所述Controller节点选择模型是利用前一个区块Hash值对所述Orderers节点总数求余数,进而从所述Orderers节点选择出与计算结果的余数具有相同编号的Orderers节点作为所述Controller节点,其中平台初始化时需产生第一个创世区块。
10.根据权利要求6所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台的实现方法,其特征在于,所述Meta-BFT(MetamorphosisByzantine Fault-Tolerant)共识机制包括请求、准备、确认和回复/广播四个阶段;
所述请求阶段:所述APP/SDK客户端向所述Controller节点发送请求服务;
所述准备阶段:所述Controller节点基于所述请求服务向所有Orderers节点发送准备消息,然后所有Orderers节点验证所述Controller节点身份、服务请求、签名信息,如果一致,则进入确认阶段;
所述确认阶段:所有Orderers节点给所述Controller节点发送确认消息;如果Controller节点收到确认成功的消息个数大于等于即可达成共识,其中f为拜占庭错误容忍个数,且3f+1≤|N|,|N|为网络中所有Orderers节点个数;
所述回复/广播阶段:在完成确认后,所述Controller节点再把执行结果返回给所述APP/SDK客户端和所有Orderers节点。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910088522.4A CN109981565B (zh) | 2019-01-29 | 2019-01-29 | 基于Meta-BFT共识机制的区块链平台及实现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910088522.4A CN109981565B (zh) | 2019-01-29 | 2019-01-29 | 基于Meta-BFT共识机制的区块链平台及实现方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109981565A true CN109981565A (zh) | 2019-07-05 |
CN109981565B CN109981565B (zh) | 2021-10-15 |
Family
ID=67076777
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910088522.4A Active CN109981565B (zh) | 2019-01-29 | 2019-01-29 | 基于Meta-BFT共识机制的区块链平台及实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109981565B (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110401656A (zh) * | 2019-07-24 | 2019-11-01 | 西安纸贵互联网科技有限公司 | 区块链管理系统 |
CN111277636A (zh) * | 2020-01-15 | 2020-06-12 | 成都理工大学 | 一种对传统pbft进行改进的共识算法 |
WO2020098844A3 (en) * | 2019-11-08 | 2020-08-06 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for implementing a blockchain-based decentralized application |
CN112527647A (zh) * | 2020-12-15 | 2021-03-19 | 浙江大学 | 基于NS-3的Raft共识算法测试系统 |
CN112565289A (zh) * | 2020-12-21 | 2021-03-26 | 北京航空航天大学 | 基于区块链的医疗证照可信签发与验证系统及方法 |
US11086621B2 (en) | 2019-11-08 | 2021-08-10 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for blockchain-based decentralized application development |
US11250021B2 (en) | 2020-04-17 | 2022-02-15 | International Business Machines Corporation | Faster view change for blockchain |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108616596A (zh) * | 2018-05-09 | 2018-10-02 | 南京邮电大学 | 基于动态授权和网络环境感知的区块链自适应共识方法 |
CN108833081A (zh) * | 2018-06-22 | 2018-11-16 | 中国人民解放军国防科技大学 | 一种基于区块链的设备组网认证方法 |
CN109191124A (zh) * | 2018-08-16 | 2019-01-11 | 北京京东尚科信息技术有限公司 | 区块链网络、部署方法及存储介质 |
CN109242483A (zh) * | 2018-08-07 | 2019-01-18 | 阿里巴巴集团控股有限公司 | 一种基于中心化与去中心化的双重交易方法及系统 |
-
2019
- 2019-01-29 CN CN201910088522.4A patent/CN109981565B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108616596A (zh) * | 2018-05-09 | 2018-10-02 | 南京邮电大学 | 基于动态授权和网络环境感知的区块链自适应共识方法 |
CN108833081A (zh) * | 2018-06-22 | 2018-11-16 | 中国人民解放军国防科技大学 | 一种基于区块链的设备组网认证方法 |
CN109242483A (zh) * | 2018-08-07 | 2019-01-18 | 阿里巴巴集团控股有限公司 | 一种基于中心化与去中心化的双重交易方法及系统 |
CN109191124A (zh) * | 2018-08-16 | 2019-01-11 | 北京京东尚科信息技术有限公司 | 区块链网络、部署方法及存储介质 |
Non-Patent Citations (3)
Title |
---|
JAMBEAU: "Hyperledger fabric V1.0 架构解析", 《BLOG.CSDN.NET》 * |
勋爵-X-KNIGHT: "[区块链] 共识算法之争(PBFT,Raft,PoW,PoS,DPoS,Ripple)", 《WWW.CNBLOGS.COM》 * |
李剑锋: "基于拜占庭容错机制的区块链共识算法研究与应用", 《郑州大学》 * |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110401656A (zh) * | 2019-07-24 | 2019-11-01 | 西安纸贵互联网科技有限公司 | 区块链管理系统 |
CN110401656B (zh) * | 2019-07-24 | 2021-11-30 | 西安纸贵互联网科技有限公司 | 区块链管理系统 |
US11086621B2 (en) | 2019-11-08 | 2021-08-10 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for blockchain-based decentralized application development |
CN111512333A (zh) * | 2019-11-08 | 2020-08-07 | 支付宝(杭州)信息技术有限公司 | 实现基于区块链的去中心化应用的系统和方法 |
WO2020098844A3 (en) * | 2019-11-08 | 2020-08-06 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for implementing a blockchain-based decentralized application |
US11163775B2 (en) | 2019-11-08 | 2021-11-02 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for implementing a blockchain-based decentralized application |
US11429617B2 (en) | 2019-11-08 | 2022-08-30 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for blockchain-based data synchronization |
CN111277636A (zh) * | 2020-01-15 | 2020-06-12 | 成都理工大学 | 一种对传统pbft进行改进的共识算法 |
US11250021B2 (en) | 2020-04-17 | 2022-02-15 | International Business Machines Corporation | Faster view change for blockchain |
US11775556B2 (en) | 2020-04-17 | 2023-10-03 | International Business Machines Corporation | Faster view change for blockchain |
CN112527647A (zh) * | 2020-12-15 | 2021-03-19 | 浙江大学 | 基于NS-3的Raft共识算法测试系统 |
CN112527647B (zh) * | 2020-12-15 | 2022-06-14 | 浙江大学 | 基于NS-3的Raft共识算法测试系统 |
CN112565289A (zh) * | 2020-12-21 | 2021-03-26 | 北京航空航天大学 | 基于区块链的医疗证照可信签发与验证系统及方法 |
CN112565289B (zh) * | 2020-12-21 | 2022-06-24 | 北京航空航天大学 | 基于区块链的医疗证照可信签发与验证系统及方法 |
Also Published As
Publication number | Publication date |
---|---|
CN109981565B (zh) | 2021-10-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109981565A (zh) | 基于Meta-BFT共识机制的区块链平台及实现方法 | |
CN107240017B (zh) | 区块链交易管理系统及方法 | |
CN110351133A (zh) | 用于区块链系统中的主节点切换处理的方法及装置 | |
CN111314067B (zh) | 区块存储方法、装置、计算机设备及存储介质 | |
CN112311772B (zh) | 基于Hyperledger的跨域证书管理系统及方法 | |
CN107769922B (zh) | 区块链安全管理系统及方法 | |
CN102170356B (zh) | 一种支持数字签名密钥专属控制的认证系统实现方法 | |
CN108681965A (zh) | 离线节点的区块链网络交易处理方法和接收方节点 | |
CN109672537A (zh) | 基于公钥池的抗量子证书获取系统及获取方法 | |
CN108200208B (zh) | 基于云计算的物流区块链共识算法 | |
CN107480990A (zh) | 区块链记账方法及装置 | |
CN109583893B (zh) | 可追踪的基于区块链的数字货币交易系统 | |
CN109165944A (zh) | 基于区块链的多方签名认证方法、装置、设备及存储介质 | |
CN110070362A (zh) | 一种使用国密算法的金融行业区块链交易系统 | |
Wan et al. | Electronic contract signing without using trusted third party | |
US20110167258A1 (en) | Efficient Secure Cloud-Based Processing of Certificate Status Information | |
CN110717759A (zh) | 一种跨链锚定的区块链异构系统 | |
CN111899002A (zh) | 一种区块链中高效进行跨链信息交易交互的方法 | |
CN106886722A (zh) | 大数据信息处理方法及装置 | |
CN111815321A (zh) | 交易提案的处理方法、装置、系统、存储介质和电子装置 | |
CN114240439B (zh) | 基于阈值签名与双哈希链模式的跨链交易回滚方法及装置 | |
CN110868295A (zh) | 基于秘密共享的抗量子计算联盟链系统及通信方法 | |
CN110661613A (zh) | 基于联盟链的抗量子计算隐式证书颁发方法及系统 | |
Vives-Guasch et al. | A secure e-ticketing scheme for mobile devices with near field communication (NFC) that includes exculpability and reusability | |
CN115174570B (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 |