一种优化的区块链共识算法的制作方法

[0001]
本发明涉及计算机技术领域，具体为一种优化的区块链共识算法。


背景技术：

[0002]
fabric具备完备的权限控制和安全保障、高性能、可扩展、较低信任要求的优势，最重要的一点是，其模块化设计，可插拔的架构设计，使得我们在共识机制这块可以根据实际情况选择替换不一样的共识算法。fabric默认提供noops和pbft这两个算法。noops算法是针对单节点模式设计，而pbft算法则是应对多节点验证的共识机制。由第二章的介绍可以知道pbft算法分为pre-prepare、prepare和commit三个阶段。pbft的特点是为了应对高频的共识失败业务，并确保在共识失败出现时所有已达到prepared状态的交易可以在下一轮共识中直接进行区块组装(pass and shi,2017)。这样使得验证节点间的通讯流程过于复杂，降低了交易共识效率从而无法支持大规模的网络节点活动(sukhwani and martinez et al.,2017)，针对上述问题，我们提出一种优化的区块链共识算法。


技术实现要素：

[0003]
针对现有技术的不足，本发明提供了一种优化的区块链共识算法，解决了上述背景技术中提出的问题。
[0004]
为实现以上目的，本发明通过以下技术方案予以实现：一种优化的区块链共识算法，包括：所述区块链网络中的节点：所述区块链网络中的节点中包括保留fabric框架的peer节点和orderer节点，chaincode部署在peer节点上并对账本进行读写操作，所述一个peer节点继续充当多种角色，orderer节点对交易进行共识排序，按照区块生成策略，将交易打包到一起生成区块，发送给peer节点；
[0005]
所述primary节点为主节点，，且primary节点为任一时间段内提交大量交易的唯一节点
[0006]
所述节点状态：每个peer节点都有一个状态标识，标明自己是处于无请求状态、已发送请求状态/等待生成区块状态或是大数据量录入请求状态这三个状态中的任一个，所述无请求状态为状态1，所述已发送请求状态/等待生成区块状态为状态2，所述大数据量录入请求状态为状态3；
[0007]
所述status list状态列表：每个peer节点维护一张状态列表，且上面记录着能访问到其他节点的必要信息以及节点状态。
[0008]
优选的，所述区块链共识算法中r是所有replicas节点的集合，每一个replica节点用一个整数来表示，依次为{0,1,2，...,r-1|r＝3f+1}，f为最大可容忍的faulty节点，生成状态列表，节点a进行大量数据的录入：
[0009]
步骤一：节点a接收到第一个交易请求和状态数据后，将自身修改为大数据量录入请求状态，并将本节点加入状态列表中；
[0010]
步骤二：节点a将交易和节点状态向全网进行广播，等待接收超过2f+1的状态为无
请求的节点，并将这些节点加入状态列表中；
[0011]
步骤三：确定好状态列表后，节点a通过channel将状态列表发送给列表中的每一个节点。
[0012]
优选的，所述区块链网络中同个channel中的每一个节点区块都获取到相同的状态列表之后，进行交易打包和区块共识，具体步骤如下：
[0013]
步骤一：第一次交易请求生成状态列表后，每个节点开始打包新的区块，打包区块的过程如下：把当前区块号、交易的hash、父区块hash、当前时间戳等内容放到一起，计算一个区块哈希；
[0014]
步骤二：每个节点广播自己得出的区块哈希到状态列表中的节点；
[0015]
步骤三：节点收集到所有状态列表中节点广播过来的区块哈希后，结合自己生成的区块哈希，对每个区块哈希计算一个比例，某一哈希的比例超过一个阈值2f+1或80％，则认为这个哈希是共识通过的区块哈希；
[0016]
步骤四：自己的哈希与之相同，则说明自己打包的区块得到了确认，是新的被共识过的区块，直接存到本地，并且更新状态；自己的哈希与共识通过的哈希不同，则重新开始共识过程，直到满足条件。
[0017]
优选的，所述一个区块的共识过程结束，开启下一轮共识过程，从第二轮共识开始，继续使用第一轮的状态列表，并直接进行区块打包共识。
[0018]
优选的，所述fabric采用模块化架构把交易处理划分为3个阶段：通过chaincode进行分布式业务逻辑处理和协商endorsers；交易排序orderders；交易的验证和提交committers。
[0019]
本发明提供了一种优化的区块链共识算法，具备以下有益效果：
[0020]
本申请fabric框架提供的身份管理服务保障网络中节点的可靠性，因此我们无需像rpca算法一样让每个节点维护一个可信列表，然而相对的，在节点处于大数据量录入请求状态时，我们需要让每一个节点维护一个相同的状态列表，而这个列表中的每个节点的状态均为无请求状态除了节点a，rpca算法的共识过程分为两步，先进行交易共识形成交易集，打包成区块后再共识。由于维护的状态列表中除了节点a外，其余节点都处于无请求状态，也就是说只有节点a在发生交易，因此我们可以省去交易共识这一步，直接进行区块共识；
[0021]
不同的阶段由不同的节点(角色endorsers,orderders,committers)参与，不需要全网的节点都参加，网络的性能和扩展性得到优化。
附图说明
[0022]
图1为本发明系统流程示意图。
具体实施方式
[0023]
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。
[0024]
在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上；术语“上”、“下”、“左”、“右”、“内”、“外”、“前端”、“后端”、“头部”、“尾部”等指示的方位或位置关系为
基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”等仅用于描述目的，而不能理解为指示或暗示相对重要性。
[0025]
在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。
[0026]
请参阅图1，本发明提供一种技术方案：一种优化的区块链共识算法，包括：
[0027]
所述区块链网络中的节点：所述区块链网络中的节点中包括保留fabric框架的peer节点和orderer节点，chaincode部署在peer节点上并对账本进行读写操作，所述一个peer节点继续充当多种角色，orderer节点对交易进行共识排序，按照区块生成策略，将交易打包到一起生成区块，发送给peer节点；
[0028]
所述primary节点为主节点，，且primary节点为任一时间段内提交大量交易的唯一节点
[0029]
所述节点状态：每个peer节点都有一个状态标识，标明自己是处于无请求状态、已发送请求状态/等待生成区块状态或是大数据量录入请求状态这三个状态中的任一个，所述无请求状态为状态1，所述已发送请求状态/等待生成区块状态为状态2，所述大数据量录入请求状态为状态3；
[0030]
所述status list状态列表：每个peer节点维护一张状态列表，且上面记录着能访问到其他节点的必要信息以及节点状态。
[0031]
区块链共识算法中r是所有replicas节点的集合，每一个replica节点用一个整数来表示，依次为{0,1,2，...,r-1|r＝3f+1}，f为最大可容忍的faulty节点，生成状态列表，节点a进行大量数据的录入：
[0032]
步骤一：节点a接收到第一个交易请求和状态数据后，将自身修改为大数据量录入请求状态，并将本节点加入状态列表中；
[0033]
步骤二：节点a将交易和节点状态向全网进行广播，等待接收超过2f+1的状态为无请求的节点，并将这些节点加入状态列表中；
[0034]
步骤三：确定好状态列表后，节点a通过channel将状态列表发送给列表中的每一个节点。
[0035]
区块链网络中同个channel中的每一个节点区块都获取到相同的状态列表之后，进行交易打包和区块共识，具体步骤如下：
[0036]
步骤一：第一次交易请求生成状态列表后，每个节点开始打包新的区块，打包区块的过程如下：把当前区块号、交易的hash、父区块hash、当前时间戳等内容放到一起，计算一个区块哈希；
[0037]
步骤二：每个节点广播自己得出的区块哈希到状态列表中的节点；
[0038]
步骤三：节点收集到所有状态列表中节点广播过来的区块哈希后，结合自己生成的区块哈希，对每个区块哈希计算一个比例，某一哈希的比例超过一个阈值2f+1或80％，则认为这个哈希是共识通过的区块哈希；
[0039]
步骤四：自己的哈希与之相同，则说明自己打包的区块得到了确认，是新的被共识过的区块，直接存到本地，并且更新状态；自己的哈希与共识通过的哈希不同，则重新开始共识过程，直到满足条件。
[0040]
一个区块的共识过程结束，开启下一轮共识过程，从第二轮共识开始，继续使用第一轮的状态列表，并直接进行区块打包共识。
[0041]
fabric采用模块化架构把交易处理划分为3个阶段：通过chaincode进行分布式业务逻辑处理和协商endorsers；交易排序orderders；交易的验证和提交committers。
[0042]
理想情况下，系统中只有一家企业在进行大数据量的录入，这样sbft共识算法便能发挥它最优的性能，然而实际上这种理想情况很难存在，因为系统是由多家企业同时在使用，因此会有几种导致大数据量数据录入失败或暂缓的情况：
[0043]
(1)生成状态列表的时候，其他节点返回的节点状态除了无请求状态之外，还有已请求状态；
[0044]
(2)状态列表中的某个或某些节点由无请求状态变成已请求状态；
[0045]
(3)非状态列表中(可能是新添加的节点，也可能是先前状态为已发送请求状态转变成无请求状态的节点)的某个或某些节点由无请求状态变成已请求状态；
[0046]
(4)状态列表中的某个或某些节点由无请求状态变成大数据量录入请求状态；
[0047]
(5)非状态列表中(可能是新添加的节点，也可能是先前状态为已发送请求状态转变成无请求状态的节点)的某个或某些节点由无请求状态变成大数据量录入请求状态；
[0048]
(6)新的节点加入到网络中，使得状态列表里面的节点数量不再超过全网络的80％；
[0049]
(7)状态列表中一定数量的节点发生故障使得列表中的诚实节点数量不再超过全网络的80％；
[0050]
(8)新的节点加入网络，同时状态列表中一定数量的节点发生故障使得节点数量不再超过全网络的80％。
[0051]
针对上面提到的七种情况，本申请采取了如下的处理措施：
[0052]
第1、2种情况，可让变成已请求状态的节点继续参与到状态列表构成的网络中，具体步骤如下：
[0053]
(1)改变了状态的节点(假设只有一个，称为节点b，多个节点情况一样)向状态列表中的其他节点广播自己的交易，其他节点将收到的交易暂时缓存起来，等待这一轮节点a的区块共识结束。
[0054]
(2)在下一轮节点a向状态列表中的节点发送自己的交易后，其余每个节点各自将节点a的交易和节点b的交易打包在一起。我们让节点b在广播了自己的交易后不进行任何等待反馈，而是在交易打包后直接进行区块打包并共识，如果成功，则进入下一轮共识，如果失败，则节点b继续向状态列表的其他节点发送自己的交易，直到成功为止。
[0055]
(3)成功后，节点b的状态从已请求状态变成无请求状态，并告知状态列表上的所有节点，更新状态列表。
[0056]
第3种情况，在节点a进行完本轮的共识过程后，可将改变状态的节点加入状态列表中，形成新的状态列表，再按照上述第2种情况的解决方法去处理。
[0057]
第4、5种情况，状态列表构成的网络中将有超过一个节点处于大数据量录入状态，
因此交易共识这一步将无法省略。但本文在最开始就保留了pbft的诸多基础特性，因此对于4、5这两种情况，本文选用dbft共识算法进行交易共识。等到区块链网络中只剩下一个状态为3的节点后，再重新生成状态列表，使用sbft算法进行共识。
[0058]
第6、7、8种情况：无论是因为新加入的节点数量过多或状态列表中发生故障的节点数量过多使得状态列表失效从而导致区块共识失败，都属于数据录入失败的情况，需要从新生成状态列表
[0059]
以上，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，根据本发明的技术方案及其发明构思加以等同替换或改变，都应涵盖在本发明的保护范围之内。