CN109981565B - 基于Meta-BFT共识机制的区块链平台及实现方法 - Google Patents
基于Meta-BFT共识机制的区块链平台及实现方法 Download PDFInfo
- Publication number
- CN109981565B CN109981565B CN201910088522.4A CN201910088522A CN109981565B CN 109981565 B CN109981565 B CN 109981565B CN 201910088522 A CN201910088522 A CN 201910088522A CN 109981565 B CN109981565 B CN 109981565B
- Authority
- CN
- China
- Prior art keywords
- node
- controller node
- meta
- orderers
- nodes
- 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
-
- 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(MetamorphosisByzantine 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(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节 点，其中平台初始化时需产生第一个创世区块。
更具体的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 (8)
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节点；
所述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节点。
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.一种基于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节点；
步骤S3中所述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节点。
6.根据权利要求5所述的一种基于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节点发送交易区块。
7.根据权利要求5所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台的实现方法，其特征在于，所述步骤S4进一步包括：
步骤S41、对所述Controller节点发送过来的交易区间进行检查与确认；
步骤S42、把通过检查的合法交易记录到账中；
步骤S43、把执行结果同步到所述APP/SDK客户端和所述Orderers节点，同时发送当前产生的区块Hash值发送到所述Controller节点选择模型，用以触发所述Controller节点选择模型从所述Orderers节点选择出Controller节点。
8.根据权利要求5所述的一种基于Meta-BFT(Metamorphosis Byzantine Fault-Tolerant)共识机制的区块链平台的实现方法，其特征在于，所述Controller节点选择模型是利用前一个区块Hash值对所述Orderers节点总数求余数，进而从所述Orderers节点选择出与计算结果的余数具有相同编号的Orderers节点作为所述Controller节点，其中平台初始化时需产生第一个创世区块。
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 CN109981565A (zh) | 2019-07-05 |
| CN109981565B true 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) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110401656B (zh) * | 2019-07-24 | 2021-11-30 | 西安纸贵互联网科技有限公司 | 区块链管理系统 |
| WO2020035090A2 (en) * | 2019-11-08 | 2020-02-20 | Alipay (Hangzhou) Information Technology Co., Ltd. | Lightweight decentralized application platform |
| EP3776430B1 (en) | 2019-11-08 | 2022-04-27 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for blockchain-based decentralized application development |
| 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 |
| CN112527647B (zh) * | 2020-12-15 | 2022-06-14 | 浙江大学 | 基于NS-3的Raft共识算法测试系统 |
| CN112565289B (zh) * | 2020-12-21 | 2022-06-24 | 北京航空航天大学 | 基于区块链的医疗证照可信签发与验证系统及方法 |
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 |
|---|
| [区块链] 共识算法之争（PBFT，Raft，PoW，PoS，DPoS，Ripple）;勋爵-X-knight;《www.cnblogs.com》;20180608 * |
| Hyperledger fabric V1.0 架构解析;jambeau;《blog.csdn.net》;20171212 * |
| 基于拜占庭容错机制的区块链共识算法研究与应用;李剑锋;《郑州大学》;20180501;第三章 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109981565A (zh) | 2019-07-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109981565B (zh) | 基于Meta-BFT共识机制的区块链平台及实现方法 | |
| CN111466096B (zh) | 提供不可变记录的系统和方法 | |
| US20210295321A1 (en) | Methods for decentralized digital asset transfer and smart contract state transition | |
| CN108805570B (zh) | 数据处理方法、装置及存储介质 | |
| Hong et al. | Pyramid: A layered sharding blockchain system | |
| CN110869967B (zh) | 用于并行处理区块链交易的系统和方法 | |
| CN108492183B (zh) | 区块链的账户交易方法、系统和计算机可读存储介质 | |
| KR102652551B1 (ko) | 분산 조정을 사용한 스마트 계약 실행 | |
| EP3693886B1 (en) | Optimizations for verification of interactions system and method | |
| CN110612700B (zh) | 基于恢复的公钥进行认证 | |
| CN111226248A (zh) | 管理基于区块链的中心化账本系统 | |
| CN111418183A (zh) | 区块链区块的异步处理 | |
| CN111837359A (zh) | 管理基于区块链的中心化账本系统 | |
| CN112583917A (zh) | 一种基于cscp的混合链构建方法 | |
| CN114391241A (zh) | 具有可调整法定数量的区块链分片 | |
| Jalalzai et al. | Window based BFT blockchain consensus | |
| Sohrabi et al. | ZyConChain: A scalable blockchain for general applications | |
| CN110599175A (zh) | 一种区块处理方法及相关设备 | |
| CN111339551B (zh) | 数据的验证方法及相关装置、设备 | |
| Santiago et al. | Concordia: a streamlined consensus protocol for blockchain networks | |
| CN111787034B (zh) | 区块生成方法、同步方法、装置、区块链系统和存储介质 | |
| CN111385096B (zh) | 一种区块链网络系统、签名处理方法、终端及存储介质 | |
| CN113570365A (zh) | 一种基于社区发现的dag网络拓扑构建方法及交易方法 | |
| Benedetti et al. | A pow-less bitcoin with certified byzantine consensus | |
| Liu et al. | Flexible Advancement in Asynchronous BFT Consensus |
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 |