联盟链配置更新方法、设备及计算机介质与流程

本申请涉及区块链技术领域，具体涉及一种联盟链配置更新方法、设备及计算机介质。

背景技术：

联盟链是由多个对等或非对等节点共同组成的分布式系统，联盟链的配置项繁多，有用于控制联盟链中区块大小的配置项，也有控制联盟链中交易缓冲区大小的配置项，还有用于控制是否开启证书在线验证的配置项等，而这些配置项通常一经配置后，在区块链运行期间都不允许被更新，若联盟链中一部分节点更新了配置文件而另一部分未更新，有可能引起联盟链的共识异常。

目前市面上对区块链配置文件的更新，通常做法是将联盟链所有节点停止运行，各个节点依次更新配置文件后，再依次启动区块链节点。该方式存在的缺点：节点的停机通常伴随业务的暂停，对业务的运营影响较大；节点停机、更新配置文件、启动，整个过程人工介入因素较多，出错率较高。

技术实现要素：

本申请提供一种联盟链配置更新方法，旨在解决现有技术下的联盟链配置更新需要暂停业务，且准确率不高的问题。

第一方面，本申请提供一种联盟链配置更新方法，所述联盟链包括多个区块链节点，

所述多个区块链节点中包括第一区块链节点，所述方法包括：

所述第一区块链节点生成第一配置更新提案，所述第一配置更新提案包括约定更新时间点，所述约定更新时间点用于指示所述多个区块链节点在时间到达所述约定更新时间点后同时更新配置；

所述第一区块链节点将所述第一配置更新提案发送至第二区块链节点，所述第二区块链节点为所述多个区块链节点中除所述第一区块链节点之外的其他所有节点；

所述第一区块链节点实时接收来自所述第二区块链节点的第一投票信息，得到投票信息集合，所述投票信息集合包括所述第一区块链节点针对所述第一配置更新提案生成的第一投票信息，以及所述第二区块链节点针对所述第一配置更新提案生成的第一投票信息；

所述第一区块链节点根据所述投票信息集合确认所述第一配置更新提案是否通过；

若所述第一配置更新提案通过，则在所述约定更新时间点根据所述第一配置更新提案进行配置更新。

在本申请一种可能的实现方式中，所述投票信息集合中包括所述第一区块链节点对所述第一配置更新提案的第一投票信息；

所述第一区块链节点根据所述投票信息集合确认所述第一配置更新提案是否通过，包括：

判断所述投票信息集合中的第一投票信息的数量，与所述多个区块链节点的数量是否相等；

若相等，则判断所述投票信息集合中是否存在不通过的第一投票信息；

若不存在，则认为所述第一配置更新提案通过。

在本申请一种可能的实现方式中，

所述若所述第一配置更新提案通过，则在所述约定更新时间点所述第一配置更新提案进行配置更新，包括：

若所述第一配置更新提案通过，判断当前时间是否到达所述约定更新时间点；

若到达，则所述第一区块链节点根据所述第一配置更新提案进行配置更新。

在本申请一种可能的实现方式中，在所述若到达，则在所述约定更新时间点根据所述第一配置更新提案进行配置更新之前，所述方法还包括：

对所述联盟链中的多个区块链节点进行共识处理，保证所述多个区块链节点配置更新的准确性。

在本申请一种可能的实现方式中，所述第一配置更新提案包括需要更新的配置项对应的目标路径，以及配置项对应的需要更新的新的目标值；

所述若到达，则所述第一区块链节点根据所述第一配置更新提案进行配置更新，包括：

确定所述配置项对应的目标路径；

根据所述目标路径，在所述第一区块链节点中确认与所述配置项对应的初始值；

将所述目标路径下的初始值更新为所述目标值，完成配置更新。

在本申请一种可能的实现方式中，所述方法还包括：

在所述第一区块链节点进行配置更新时，将所述第一区块链节点上正在进行的交易以及在更新期间接收到的交易暂存在缓存中；

在所述第一区块链节点配置更新完成后，重新处理所述缓存中的交易。

在本申请一种可能的实现方式中，所述方法还包括：

所述第一区块链节点接收第二配置更新提案；

所述第一区块链节点对所述第二配置更新提案进行投票确认，生成与所述第二配置更新提案对应的第二投票信息；

所述第一区块链节点将所述第二投票信息发送给除所述第二区块链节点。

第二方面，本申请提供一种联盟链配置更新方法，所述联盟链包括多个区块链节点，所述多个区块链节点中包括第二区块链节点，所述方法包括：

所述联盟链包括多个区块链节点，所述多个区块链节点中包括第二区块链节点，所述方法包括：

所述第二区块链节点接收第一配置更新提案，所述第一配置更新提案包括约定更新时间点，所述约定更新时间点用于指示所述多个区块链节点在时间到达所述约定更新时间点后同时更新配置；

所述第二区块链节点对所述第一配置更新提案进行投票确认，生成与所述第一配置更新提案对应的第一投票信息；

所述第二区块链节点将所述第一投票信息发送至第三区块链节点，所述第三区块链节点为所述多个区块链节点中除所述第二区块链节点之外的其他所有节点；

所述第二区块链节点实时接收来自所述第三区块链节点针对所述第一配置更新提案生成的第一投票信息，得到投票信息集合，所述投票信息集合包括所述第三区块链节点针对所述第一配置更新提案生成的第一投票信息，以及所述第二区块链节点针对所述第一配置更新提案生成的第一投票信息；

所述第二区块链节点根据所述投票信息集合，判断所述第一配置更新提案是否通过；

若所述第一配置更新提案通过，则在所述约定更新时间点根据所述第一配置更新提案进行配置更新。

在本申请一种可能的实现方式中，

在所述第二区块链节点对所述第一配置更新提案进行投票确认，得到与所述第一配置更新提案对应的第一投票信息之前，所述方法还包括：

所述第二区块链节点对所述第一配置更新提案进行验证；

若所述第一配置更新提案通过验证，确认所述第一配置更新提案合法。

在本申请一种可能的实现方式中，

所述第一配置更新提案包括所述第一配置更新提案对应的哈希值；

所述第二区块链节点对所述第一配置更新提案进行投票确认，得到与所述第一配置更新提案对应的第一投票信息，包括：

获取所述第一配置更新提案的哈希值；

根据所述第一配置更新提案的哈希值，确认所述第一配置更新提案；

获取与所述第一配置更新提案对应的第一投票信息。

第三方面，本申请还提供一种联盟链配置更新设备，所述联盟链包括多个区块链节点，所述多个区块链节点中包括第一区块链节点，所述设备包括：

提案生成模块，用于生成第一配置更新提案，所述第一配置更新提案包括约定更新时间点，所述约定更新时间点用于指示所述多个区块链节点在时间到达所述约定更新时间点后同时更新配置；

第一发送模块，用于将所述第一配置更新提案发送至第二区块链节点，所述第二区块链节点为所述多个区块链节点中除所述第一区块链节点之外的其他所有节点；

第一接收模块，用于实时接收来自所述第二区块链节点的第一投票信息，得到投票信息集合，所述投票信息集合包括所述第一区块链节点针对所述第一配置更新提案生成的第一投票信息，以及所述第二区块链节点针对所述第一配置更新提案生成的第一投票信息；

第一判断模块，用于根据所述投票信息集合确认所述第一配置更新提案是否通过；

第一更新模块，用于若所述第一配置更新提案通过，则在所述约定更新时间点根据所述第一配置更新提案进行配置更新。

第四方面，本申请还提供一种联盟链配置更新设备，所述联盟链包括多个区块链节点，所述多个区块链节点中包括第一区块链节点，所述设备包括：

第二接收模块，用于接收第一配置更新提案，所述第一配置更新提案包括约定更新时间点，所述约定更新时间点用于指示所述多个区块链节点在时间到达所述约定更新时间点后同时更新配置；

投票模块，用于所述第一配置更新提案进行投票确认，生成与所述第一配置更新提案对应的第一投票信息；

第二发送模块，用于将所述第一投票信息发送至第三区块链节点，所述第三区块链节点为所述多个区块链节点中除所述第二区块链节点之外的其他所有节点；

第三接收模块，用于实时接收来自所述第三区块链节点的第一投票信息，得到投票信息集合，所述投票信息集合包括所述第三区块链节点针对所述第一配置更新提案生成的第一投票信息，以及所述第二区块链节点针对所述第一配置更新提案生成的第一投票信息；

第二判断模块，用于根据所述投票信息集合，判断所述第一配置更新提案是否通过；

第二更新模块，用于若所述第一配置更新提案通过，则在所述约定更新时间点根据所述第一配置更新提案进行配置更新。

第五方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如第一方面任一项所述的联盟链配置更新方法，或所述程序指令当被处理器执行时使所述处理器执行如第二方面任一项所述的联盟链配置更新方法。

本申请中提供一种联盟链配置更新方法，通过将配置更新提案发送给联盟链中的所有节点，而所有节点均对配置更新提案进行在线投票确认，当配置更新提案通过后所有的节点同步进行配置更新。该方法避免了停止运行节点，避免联盟链中的业务暂停；且节点可以在线更新配置，避免人工因素介入，提高配置更新的准确性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的联盟链系统的场景示意图；

图2为本申请实施例中联盟链配置更新方法的一个实施例流程示意图；

图3为本申请实施例提供的判断配置更新提案是否通过一实施例流程示意图；

图4为本申请实施例提供的节点进行配置更新一实施例流程示意图；

图5为本申请实施例提供的配置更新文件一实施例示意图；

图6为本申请实施例提供的根据配置更新文件进行更新的一实施例流程示意图；

图7为本申请实施例提供的配置更新提案一实施例示意图；

图8为本申请实施例提供的配置更新提案一具体实施例示意图；

图9为本申请实施例提供的联盟链配置更新方法另一实施例流程示意图；

图10为本申请实施例提供的得到第一投票信息一实施例流程示意图；

图11为本申请实施例提供的联盟链配置更新一具体实施例示意图；

图12为本申请实施例提供的联盟链配置更新设备一实施例示意图；

图13为本申请实施例提供的联盟链配置更新设备一实施例示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个所述特征。在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在本申请中，“示例性”一词用来表示“用作例子、例证或说明”。本申请中被描述为“示例性”的任何实施例不一定被解释为比其它实施例更优选或更具优势。为了使本领域任何技术人员能够实现和使用本发明，给出了以下描述。在以下描述中，为了解释的目的而列出了细节。应当明白的是，本领域普通技术人员可以认识到，在不使用这些特定细节的情况下也可以实现本发明。在其它实例中，不会对公知的结构和过程进行详细阐述，以避免不必要的细节使本发明的描述变得晦涩。因此，本发明并非旨在限于所示的实施例，而是与符合本申请所公开的原理和特征的最广范围相一致。

本申请实施例提供一种联盟链配置更新方法、设备及计算机介质，以下分别进行详细说明。

在本申请的实施例中，联盟链是由多个对等或非对等节点共同组成的分布式系统，联盟链的配置项繁多，有用于控制联盟链中区块大小的配置项，也有控制联盟链中交易缓冲区大小的配置项，还有用于控制是否开启证书在线验证的配置项等。而这些配置项通常一经配置后，在区块链运行期间都不允许更新，若是联盟中的一部分节点更新了配置文件而另一部分未更新，会造成联盟链共识异常，影响交易的正常执行。

如图1所示，为本申请实施例提供的联盟链系统的场景示意图，该联盟链系统可以包括多个区块链节点100，多个区块链节点100之间可以互相广播传递信息，节点100中集成有提案模块200。

本发明实施例中提案模块200主要用于以多个区块链节点中任意节点为第一区块链节点，第一区块链节点生成第一配置更新提案；第一区块链节点将第一配置更新提案发送至除第一区块链节点之外的其他所有节点；第一区块链节点实时接收来自除第一区块链节点之外的其他所有节点的第一投票信息，得到投票信息集合；第一区块链节点根据投票信息集合确认第一配置更新提案是否通过；若第一配置更新提案通过，则多个区块链节点根据第一配置更新提案同时进行配置更新。

本发明的实施例中，节点与节点之间可通过任何通信方式实现通信，包括但不限于，基于第三代合作伙伴计划(3rdgenerationpartnershipproject，3gpp)、长期演进(longtermevolution，lte)、全球互通微波访问(worldwideinteroperabilityformicrowaveaccess，wimax)的移动通信，或基于tcp/ip协议族(tcp/ipprotocolsuite，tcp/ip)、用户数据报协议(userdatagramprotocol，udp)的计算机网络通信等。

可以理解的是，本发明实施例中所使用的节点100可以是既包括接收和发射硬件的设备，即具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种节点可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备。具体的节点100具体可以是台式终端或移动终端，节点100具体还可以是手机、平板电脑、笔记本电脑等中的一种。

本领域技术人员可以理解，图1中示出的应用环境，仅仅是与本申请方案一种应用场景，并不构成对本申请方案应用场景的限定，其他的应用环境还可以包括比图1中所示更多或更少的服务器，或者服务器网络连接关系，例如图1中仅示出五个节点和五个提案模块，可以理解的，该联盟链系统还可以包括更多节点以及更多与节点连接的提案模块，具体此处不作限定。

另外，如图1所示，该联盟链系统还可以包括存储器300，用于存储数据，如存储主机数据，例如主机运行时的主机状态数据等。

需要说明的是，图1所示的联盟链系统的场景示意图仅仅是一个示例，本发明实施例描述的联盟链系统以及场景是为了更加清楚的说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着联盟链系统的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。

如图2所示，为本申请实施例中联盟链配置更新方法的一个实施例流程示意图，本申请实施例中的联盟链是多个对等或非对等节点共同组成的分布式系统，联盟链中包括多个区块链节点，而多个区块链节点中包括第一区块链节点。该联盟链配置更新方法可以包括：

21、第一区块链节点生成第一配置更新提案。

具体的，由于联盟链中包括多个区块链节点，而这些节点中又可以分为联盟链业务参与方和联盟链技术提供方；联盟链业务参与方对应的节点和联盟链技术提供方对应的节点需要共同确定需要升级的目标节点的版本，并有技术提供方对目标版本进行充分的测试，并打包以便后续更新。

在本申请的实施例中，技术提供方可以单独持有一个节点，也可以与业务参与方共用一个节点，只需要业务参与方节点授予技术提供方节点调用权限即可。即在本申请的实施例中，联盟链中的任一个节点均可以生成配置更新提案，以便节点进行配置更新。

具体的，联盟链中可以包括第一区块链节点，当需要进行配置更新时，第一区块链节点需要先生成第一配置更新提案。而第一配置更新提案中包括约定更新时间点，而约定时间点用于指示联盟链中的多个区块链节点在时间到达约定时间点后同时更新配置。即在本申请的实施例中，联盟链中的多个区块链节点需要同时更新配置。

22、第一区块链节点将第一配置更新提案发送至第二区块链节点。

在本申请的实施例中，若是联盟链中的节点需要更新配置，则联盟链中的所有节点均需要更新配置，避免影响节点的共识。因此第一区块链节点需要将生成的第一配置更新提案发送至第二区块链节点，而第二区块链节点为联盟链的多个区块链节点中除第一区块链节点之外的其他所有节点，这样其他所有节点才能根据第一配置更新提案更新自身的配置。

23、第一区块链节点实时接收来自第二区块链节点的第一投票信息，得到投票信息集合。

本申请实施例中的配置更新主要分为两个过程，包括技术提供方发起更新提案，业务参与方对提案进行投票并达成共识；节点根据更新提案中的信息完成配置更新。

即在本申请的实施例中，当第一区块链节点将第一配置更新提案发送给联盟链中的第二区块链节点后，第二区块链节点中的每个节点均会对第一配置更新提案进行投票表决，得到第一投票信息，决定是否需要更新配置。

而第二区块链节点在投票表决结束生成第一投票信息后，会将第一投票信息发送给第一区块链节点；第一区块链节点会实时接收来自其他所有节点的第一投票信息，并将获取的所有的第一投票信息汇总，得到投票信息的集合。而投票信息集合中包括第一区块链节点自身针对所述第一配置更新提案生成的第一投票信息，以及第二区块链节点针对所述第一配置更新提案生成的第一投票信息；投票信息集合中的第一投票信息的数量应当与联盟链中多个区块链节点的数量相同。

需要说明的是，在上述实施例中，节点对配置更新提案进行投票是实时在线的投票。

且在上述实施例中，区块链中的第一区块链节点针对第一配置更新提案生成第一投票信息，第二区块链节点针对第二配置更新提案也生成第一投票信息；但第一区块链节点和第二区块链节点针对同一个配置更新提案生成的投票信息中包含的内容不同。

24、第一区块链节点根据投票信息集合确认第一配置更新提案是否通过。

当第一区块链节点获取了所有区块链节点针对第一配置更新提案投票后的第一投票信息后，第一区块链节点可以根据所有第一投票信息汇总得到的投票信息集合确定第一配置更新提案是否通过。

由于第一投票信息中包括了不同区块链节点针对第一配置更新提案的投票结果，投票结果可以为通过或不通过；第一区块链节点可以根据每个节点的通过或不通过的投票结果，确定第一配置更新提案是否通过。

需要说明的是，在本申请的实施例中，投票信息集合包括发出配置更新提案的节点自身针对不同配置更新提案的投票信息。即投票信息集合中包括第一区块链节点针对第一配置更新提案，进行投票表决后得到的第一投票信息。

25、若第一配置更新提案通过，则在约定时间点根据第一配置更新提案进行配置更新。

具体的，若是第一配置更新提案通过，则第一区块链节点可以根据第一配置更新提案中的关于配置的描述信息进行配置更新。

本申请中提供一种联盟链配置更新方法，通过将配置更新提案发送给联盟链中的所有节点，而所有节点均对配置更新提案进行在线投票确认，当配置更新提案通过后所有的节点同步进行配置更新。该方法避免了停止运行节点，避免联盟链中的业务暂停；且节点可以在线更新配置，避免人工因素介入，提高配置更新的准确性。

如图3所示，为本申请实施例提供的判断配置更新提案是否通过一实施例流程示意图，可以包括：

31、判断投票集合中的第一投票信息的数量，与多个区块链节点的数量是否相等。

32、若相等，判断投票信息集合中是否存在不通过的第一投票信息。

33、若不存在，则认为第一配置更新提案通过。

具体的，本申请实施例中，第一区块链节点会将自身生成的第一配置更新提案发送给除自身之外的其他所有节点，即发送给第二区块链节点；而第二区块链节点接收到第一配置更新提案后，会针对配置更新提案进行投票表决，判断第一配置更新提案中的更新是否通过；即每个区块链节点均会生成一个投票结果，投票结果可以为通过或不通过。

每个节点会根据投票结果生成第一投票信息并反馈给发出第一配置更新提案的第一区块链节点。第一区块链节点会接收来自其他所有节点的第一投票信息，并将第一投票信息进行汇总得到投票信息集合，根据投票信息集合判断第一配置更新提案是否通过。

其中，第一区块链节点为生成第一配置更新提案的区块链节点，因此第一区块链节点针对第一配置更新提案的投票结果默认为通过。

在本申请的实施例中，当第一区块链节点在得到投票信息集合后，首先需要判断投票信息集合中的第一投票信息的数量是否与联盟链中多个区块链节点的数量相同；即判断投票信息集合中是否包括所有区块链节点的投票结果。若是第一区块链节点获取了多个区块链节点对应的投票结果，还需要判断投票信息集合中是否有不通过的投票结果；若是有，则说明第一配置更新提案没有通过，无法进行配置更新。

即在本申请的一些实施例中，只有联盟链中所有区块链节点均生成针对配置更新提案的投票结果，且投票结果均为通过，才能认为配置更新提案通过，区块链节点才能进行配置更新。

在本申请的另一些实施例中，若是联盟链中存在三分之二及以上的区块链节点通过了配置更新提案，也可以认为配置更新提案通过，无需所有的区块链节点均通过配置更新提案。

具体的，联盟链的多个区块链节点中，若是有三分之二及以上的区块链节点针对配置更新提案的投票结果为通过，即可认为配置更新提案通过。联盟链中的所有节点同时根据配置更新提案更新配置。

需要说明的是，由于本申请实施例中的区块链节点生成的配置更新提案和投票信息是发送给除自身之外的其他所有区块链节点的，因此在判断配置更新提案是否通过时，需要对区块链所有的节点均进行判断。例如在本申请的一个具体实施例中，只有所有区块链节点均判断配置更新提案通过，才能最终认为配置更新提案通过，所有区块链节点才能进行配置更新。仅判断生成配置更新提案中区块链节点中的配置更新提案是否通过是不完整的。

在本申请的实施例中，第一配置更新提案中可以包括提案的哈希值(hash)，提案发起方签名、配置更新时间、配置更新描述文件以及备注信息等。其中，可以通过提案发起方签名判断提案是由联盟链中哪个节点提出的，不同节点对应的签名可以不同，以便更好的区分提案的发起方。

而提案的哈希值可以确定配置更新提案具体的是哪种提案，提案的哈希值可以相当于提案的id，根据提案的id即提案的哈希值可以确定是哪个提案。而配置更新描述文件以及备注信息则涉及了节点中的配置具体是如何更新的。

而更新时间则是配置更新提案对应的约定更新时间点，即节点需要在什么时间开始配置更新。而第一配置更新提案中也包括有更新时间，即包括有第一配置更新提案对应的约定更新时间点。

若是第一配置更新提案通过，则在约定更新时间点根据第一配置更新提案同时进行配置更新可以包括：

若第一配置更新提案通过，判断当前时间是否达到约定更新时间点；若达到，则第一区块链节点根据第一配置更新提案进行配置更新。

具体的，若是第一区块链节点检测到当前时间到达了约定更新时间点，则第一区块链节点可以根据第一配置更新提案进行更新。

同时，由于第一配置更新提案发送给了联盟链中的每一个区块链节点，因此每一个区块链节点都可以根据第一配置更新提案进行配置更新。即每一个区块链节点均可以判断第一配置更新提案是否通过，若通过再判断当前时间是否到达了第一配置更新提案中的约定更新时间点；若是到达，则所有的区块链节点同时开始配置更新。

需要说明的是，由于每个区块链节点均接受到了来自其他节点的投票信息，因此若是第一区块链节点判断第一配置更新提案通过，那么实际上所以的节点均可以判断第一配置更新提案通过。因此所有的区块链节点可以根据约定更新时间点同时进行配置更新。

且在上述实施例中，每个区块链节点判断当前时间是否到达约定更新时间点是独立的，因此还需要对每个区块链节点进行时间矫正，以保证所有区块链节点所处的当前时间相同。

具体的，在本申请的实施例中，在区块链节点根据第一配置更新提案进行配置更新之前，还需要对联盟链中的多个区块链节点进行共识处理，保证多个区块链节点处于同一时间，且避免多个区块链节点在配置更新过程中出现错误，保证多个区块链节点配置更新的准确性。

具体的，多个区块链节点之间需要互相发送共识请求，而区块链节点可以基于联盟链自身的共识机制实现所有节点之间的共识。所有区块链节点之间达到共识之后，等待第一配置更新提案中的约定更新时间点到达，所有区块链节点同时开始配置更新。

在本申请的实施例中，多个区块链节点之间可以利用拜占庭容错算法(practicalbyzantinefaulttolerance，pbft)或权益证明(proofofstake，pos)等多种方法实现共识。共识的具体过程可以参考现有技术，此处不做任何限定。

如前所述，第一配置更新提案中还包括配置更新描述文件，即第一配置更新提案中还包括有节点中需要更新的配置项对应的目标值以及目标值对应的目标路径。

如图4所示，为本申请实施例提供的节点进行配置更新一实施例流程示意图，在到达约定更新时间点后，第一区块链节点根据第一配置更新提案进行配置更新，可以包括：

41、确定配置项对应的目标路径。

42、根据目标路径，在第一区块链节点中确认与配置项对应的初始值。

43、将目标路径下的初始值更新为目标值，完成配置更新。

具体的，由于节点的配置项繁多，因此需要确定需要更新的配置项，并确定需要更新的配置项对应的目标路径，以便在节点中根据目标路径确定需要更新的配置项。

每一个配置项均对应一个初始值，对配置项进行更新可以为将配置项对应的初始值进行更新。因此根据第一配置更新提案将配置项对应的初始值进行更新，更新为第一配置更新提案中的目标值。

在本申请的实施例中，配置更新描述文件是一串jsonstring字符，如图5所示，为本申请实施例提供的配置更新文件一实施例示意图，包括如下多个不同的字段：字段“targetconf”、字段“targetitem”和字段“value”。其中，字段“targetconf”代表需要更新的目标配置文件的路径，而字段“targetitem”代表需要更新配置中的配置项，字段“value”代表配置项对应的目标值。其中，配置更新描述文件中的三个字段均以string格式进行保存。

如图6所示，为本申请实施例提供的根据配置更新文件进行更新的一实施例流程示意图，可以包括：

61、读取配置更新文件，判断需要更新的目标配置文件是否存在。

62、若目标配置文件存在，判断目标配置项是否存在。

63、若目标配置项是否存在，判断目标配置项对应的目标值是否合法。

64、若合法，根据配置更新文件，将目标配置项对应的初始值进行更新。

65、刷新目标配置文件，使得配置项中的值刷新生效。

具体的，可以读取配置更新文件，获取需要更新的目标配置文件的目标路径，并根据目标路径在节点的配置项中找到对应的目标配置文件；若是能够找到需要更新的目标配置文件，还需要在目标配置文件中确定需要更新的目标配置项。若是确定了需要更新的目标配置项，则需要新一步确定目标配置项对应的目标值是否合法，若是合法，则可以将目标配置项对应的初始值更新为目标值。

其中，将目标配置项对应的初始值更新为目标值，可以为对节点中的目标配置项进行写操作，而写操作的值为“value”，即完成了更新。

而在将目标配置项对应的初始值更新为目标值后，还需要对目标路径中的目标配置项进行刷新，以使得目标配置项中的目标值生效。这样才算完成了配置项的更新。

如图7所示，为本申请实施例提供的配置更新提案一实施例示意图，实际上的配置更新提案即为一串代码。如图7中所示，配置更新提案中可以包括多个不同的字段，每个字段分别代表配置更新提案中的一种信息。例如，字段“proposahash”即代表配置更新提案的哈希值，读取配置更新提案中的字段“proposahash”即可以确定该配置更新提案的哈希值，即确定配置更新提案具体是什么提案。

而“signature”字段即为配置更新提案发起方的签名，读取“signature”字段可以判断配置更新提案是哪个节点发出的。且为了保证签名的安全性，可以利用公钥或私钥对签名进行加密。

“updatetime”字段可以为提案发起方希望提案通过后，节点使用提案进行更新的时间，即提案对应的约定更新时间点。而“conupdatedesc”字段即为配置更新描述文件，即节点读取“conupdatedesc”字段可以知晓需要更新的配置项，以及将配置项对应的初始值如何更新。

而“describe”字段是配置更新提案中的备注信息，提供本次更新的描述信息，供操作人员阅读。与前述其他的字段不同，前述其他的字段均是节点读取的，而“describe”字段中的内容是供操作人员读取的，便于操作人员了解此处配置更新。

如图8所示，为本申请实施例提供的配置更新提案一具体实施例示意图。如图8中所示，字段“proposahash”可以为“0x7541f6a29581d25a0498d97a36e34e0639d4b5d672aabfc859512a26bdee32c8”，即“0x7541f6a29581d25a0498d97a36e34e0639d4b5d672aabfc859512a26bdee32c8”为一种配置更新提案的哈希值，读取该字段可以确定当前的配置更新提案具体为哪个提案。在如图8所示的配置更新提案中，读取该字段可以确定当前的配置更新提案为更新区块大小的提案。

而“signature”字段为“sign(proposal)”，即当前更新区块大小的提案的发起方是“proposal”。“updatetime”字段即为配置更新的时间点，为2020-10-10：00:00:00。而“conupdatedesc”字段包括了配置项“区块大小”的路径，以及如何将区块大小更新为多少；即将路径“$install_path/conf/global.conf\”下的代表区块大小的配置项“batchsize”更新为“500”。这样就完成了对配置项的更新。

在图8中，“describe”字段代表的是此次配置更新为更新区块大小，该部分内容展示给操作人员，便于操作人员了解此次配置更新。

在本申请的实施例中，节点同时进行配置更新时，节点仍处于工作状态，即节点仍会接收交易，但由于节点中的配置项发生了更改，因此节点对于交易的处理也发生了变化。因此在多个区块链节点进行配置更新时，需要将多个区块链节点上正在进行的交易以及在配置更新期间接收到的新的交易暂存在缓存中，暂时不处理。在多个区块链节点配置更新完成后，多个区块链节点再重新处理缓存中的交易。

需要说明的是，在本申请的实施例中，由于业务的参与方和业务的提供方可以复用同一个节点，因此联盟链中的每个区块链节点都可以生成配置更新提案，发送给其他所有区块链节点；也可以接受来自其他所有区块链节点的配置更新提案。因此第一区块链节点还可以接受第二配置更新提案；第一区块链节点对第二配置更新提案进行投票确定，生成与第二配置更新提案对应的第二投票信息；第一区块链节点将第二投票信息发送给第二区块链节点。

需要说明的是，在本申请的实施例中，每个区块链节点不论是发送配置更新提案或是投票信息，均需要发送给除自身外的其他所有区块链节点。同时，每个区块链节点在接收投票信息时，需要接收除自身之外的其他所有区块链节点发出的投票信息。

具体的，配置更新提案或是投票信息可以利用联盟链网络广播到联盟链中的每个区块链节点。

如图9所示，为本申请实施例提供的联盟链配置更新方法另一实施例流程示意图，其中联盟链中包括多个区块链节点，而多个区块链节点中可以包括第二区块链节点，该方法可以包括：

91、第二区块链节点接收第一配置更新提案。

联盟链中的多个区块链节点，既可以生成配置更新提案，也可以接收配置更新提案，因此当第一区块链节点生成第一配置更新提案后，第二区块链节点可以接收第一配置更新提案；其中，第二区块链节点可以为联盟链的多个区块链节点中除第一区块链节点之外的其他所有节点。

同时，第一配置更新提案中可以包括约定更新时间点，而约定更新时间点用于指示多个区块链节点在时间到达约定更新时间点后同时更新配置。

92、第二区块链节点对第一配置更新提案进行投票确认，生成与第一配置更新提案对应的第一投票信息。

第二区块链节点在接收到第一配置更新提案后，需要对第一配置更新提案进行投票确认，判断第一配置更新提案是否通过；并根据投票结果生成与第一配置更新提案对应的第一投票信息。

93、第二区块链节点将第一投票信息发送至第三区块链节点。

在第二区块链节点生成了第一投票信息后，需要将第一投票信息发送至第三区块链节点，而第三区块链节点可以为联盟链的多个区块链节点中除第二区块链节点之外的其他所有节点。

94、第二区块链节点实时接收来自第三区块链节点的第一投票信息，得到投票信息集合。

第二区块链节点需要将自身针对第一配置更新提案生成的第一投票信息发送给第三区块链节点，而第三区块链节点可以为联盟链的多个区块链节点中除第二区块链节点之外的其他所有节点；同时，第二区块链节点也需要接收来自第三区块链节点针对第一配置更新提案生成的第一投票信息。

第一区块链节点接收到来自第三区块链节点的第一投票信息后，可以将第三区块链节点的第一投票信息以及自身的第一投票信息汇总，得到投票信息集合。

95、第二区块链节点根据投票信息集合，判断第一配置更新提案是否通过。

96、若第一配置更新提案通过，则在约定更新时间点根据第一配置更新提案进行配置更新。

本申请中提供一种联盟链配置更新方法，通过将配置更新提案发送给联盟链中的所有节点，而所有节点均对配置更新提案进行在线投票确认，当配置更新提案通过后所有的节点同步进行配置更新。该方法避免了停止运行节点，避免联盟链中的业务暂停；且节点可以在线更新配置，避免人工因素介入，提高配置更新的准确性。

在本申请的实施例中，在第二区块链节点对第一配置更新提案进行投票确认，得到与第一配置更新提案对应的第一投票信息之前，第二区块链节点需要对配置更新提案进行验证，若是第一配置更新提案通过了验证，确认第一配置更新提案合法后，才能进行投票确认。

在上述实施例中，验证配置更新提案是否合法的方法和步骤可以参考现有技术，此处不做限定。

在本申请的实施例中，当节点接收到配置更新提案后，实际上是将配置更新提案记录到节点中的提案库，并等待配置更新提案通过后再使用。而节点对配置更新提案进行投票确实时，需要获取配置更新提案中包含的提案哈希值；并根据提案哈希值确定配置更新提案；再对配置更新提案进行投票确认。

如图10所示，为本申请实施例提供的得到第一投票信息一实施例流程示意图，可以包括：

101、获取第一配置更新提案的哈希值。

102、根据第一配置更新提案的哈希值，确认第一配置更新提案。

103、获取与第一配置更新提案对应的第一投票信息。

具体的，当第二区块链节点接收到第一配置更新提案后，需要将第一配置更新提案记录到提案库，并获取第一配置更新提案对应的哈希值。而根据第一配置更新提案对应的哈希值，可以确认第一配置更新提案具体为哪种提案。并且调用第二区块链节点自身的投票接口，对第一配置更新提案进行投票确认，得到第二区块链节点针对第一配置更新提案的投票结果。其中，投票结果可以为通过或不通过。

在上述实施例中，在得到了投票结果后，还需要对投票结果进行封装，将第一配置更新提案中的发起方签名，第一配置更新提案的哈希值以及第二区块链节点针对第一配置更新提案生成的投票结果封装在一起，生成与第一配置更新提案对应的第一投票信息。

其中，第一投票信息中还包括投票哈希值，且投票哈希值与第一配置更新提案对应，便于节点确认第一投票信息是针对第一配置更新提案生成的。

即在本申请的实施例中，配置更新提案中包括提案的哈希值，便于确认配置更新提案是哪种提案，且便于区分不同的配置更新提案；而不同节点针对配置更新提案生成的投票信息中还包括投票哈希值，投票哈希值与提案的哈希值对应，便于区分不同的投票信息。

如图11所示，为本申请实施例提供的联盟链配置更新一具体实施例示意图，如图11中所示，联盟链包括多个区块链节点，而多个区块链节点之间互相连接，或者说是多个区块链节点之间均可以进行广播，传输配置更新提案以及投票信息。

联盟链中的多个区块链节点中，每个节点均可以生成配置更新提案并广播给其他所有节点，同时也可以接收来自其他所有节点的配置更新提案。如图11中所示，技术提供方对应的节点发起配置更新提案，并将配置更新提案广播给业务参与方1、业务参与方2、业务参与方3、业务参与方4以及业务参与方5。而业务参与方1、业务参与方2、业务参与方3、业务参与方4以及业务参与方5接收到配置更新提案后，需要对配置更新提案进行投票，同意更新；并将同意更新的投票信息发送给除自身之外的其他所有节点。

以业务参与方5为例，业务参与方5需要将同意更新的投票信息发送给业务参与方1、业务参与方2、业务参与方3、业务参与方4以及技术提供方。

在上述实施例中，业务参与方5将同意更新的投票信息发送给业务参与方1、业务参与方2、业务参与方3、业务参与方4以及技术提供方后；业务参与方5也同样接收到了来自业务参与方1、业务参与方2、业务参与方3、业务参与方4以及技术提供方的同意更新的投票信息。而业务参与方5将接收到的投票信息，以及自身生成的投票信息汇总，得到投票信息集合。

业务参与方5先判断投票信息集合中投票信息的数量是否与节点的数量一致，即投票信息的数量是否为六个；若一致，则业务参与方5再判断投票信息集合中是否有不同意更新的投票信息。若是不存在，则对于业务参与方5来说，配置更新提案通过，可以进行配置更新。

在上述实施例中，由于技术提供方将配置更新提案发送给了业务参与方1、业务参与方2、业务参与方3、业务参与方4以及业务参与方5，即发送给了联盟链中的除自身之外的其他所有节点；因此联盟链中的每个节点均可以生成针对配置更新提案的投票信息。而每一个业务参与方以及技术提供方又会将自身生成的投票信息发送给除自身之外的其他所有节点；即每个节点均会接收到来自其他节点的投票信息。

因此，当业务参与方5根据投票信息集合判断第一配置更新提案通过，那么其他节点也可以认为第一配置更新提案通过；此时技术提供方、业务参与方1、业务参与方2、业务参与方3、业务参与方4以及业务参与方5可以根据配置更新提案同时进行配置更新。

且在上述实施例中，当联盟链进行配置更新前，还需要对多个区块链节点进行共识处理，以保证节点更新的准确性。而当当业务参与方1、业务参与方2、业务参与方3、业务参与方4、业务参与方5接收到配置更新提案后，是将配置更新提案记录在提案库中，以便投票通过后再调用。

在上述实施例中，只有当业务参与方1、业务参与方2、业务参与方3、业务参与方4、业务参与方5以及技术提供方均确认配置更新提案通过后，业务参与方1、业务参与方2、业务参与方3、业务参与方4、业务参与方5以及技术提供方根据配置更新提案中的约定更新时间点同时进行配置更新。

本申请还提供一种联盟链配置更新设备，如图12所示，为本申请实施例提供的联盟链配置更新设备一实施例示意图，该联盟链中包括多个区块链节点，而多个区块链节点中可以包括第一区块链节点。该配置更新设备可以包括：

提案生成模块121，用于生成第一配置更新提案，第一配置更新提案包括约定更新时间点，约定更新时间点用于指示多个区块链节点在时间到达约定更新时间点后同时更新配置。

第一发送模块122，用于将第一配置更新提案发送至第二区块链节点，第二区块链节点为多个区块链节点中除第一区块链节点之外的其他所有节点。

第一接收模块123，用于实时接收来自第二区块链节点的第一投票信息，得到投票信息集合，投票信息集合包括第一区块链节点针对第一配置更新提案生成的第一投票信息，以及第二区块链节点针对第一配置更新提案生成的第一投票信息。

第一判断模块124，用于根据投票信息集合确认第一配置更新提案是否通过。

第一更新模块125，用于若第一配置更新提案通过，则在约定更新时间点根据第一配置更新提案进行配置更新。

本申请中提供一种联盟链配置更新设备，通过将配置更新提案发送给联盟链中的所有节点，而所有节点均对配置更新提案进行在线投票确认，当配置更新提案通过后所有的节点同步进行配置更新。该方法避免了停止运行节点，避免联盟链中的业务暂停；且节点可以在线更新配置，避免人工因素介入，提高配置更新的准确性。

同时，本申请还提供一种联盟链配置更新设备，联盟链包括多个区块链节点，多个区块链节点中包括第一区块链节点，如图13所示，为本申请实施例提供的联盟链配置更新设备一实施例示意图，该设备包括：

第二接收模块131，用于接收第一配置更新提案，第一配置更新提案包括约定更新时间点，约定更新时间点用于指示多个区块链节点在时间到达约定更新时间点后同时更新配置。

投票模块132，用于第一配置更新提案进行投票确认，生成与第一配置更新提案对应的第一投票信息；

第二发送模块133，用于将第一投票信息发送至第三区块链节点，第三区块链节点为多个区块链节点中除第二区块链节点之外的其他所有节点；

第三接收模块134，用于实时接收来自第三区块链节点的第一投票信息，得到投票信息集合，投票信息集合包括第三区块链节点针对第一配置更新提案生成的第一投票信息，以及第二区块链节点针对第一配置更新提案生成的第一投票信息；

第二判断模块135，用于根据投票信息集合，判断第一配置更新提案是否通过；

第二更新模块136，用于若第一配置更新提案通过，则在约定更新时间点根据第一配置更新提案进行配置更新。

本申请中提供的联盟链配置更新设备，通过将配置更新提案发送给联盟链中的所有节点，而所有节点均对配置更新提案进行在线投票确认，当配置更新提案通过后所有的节点同步进行配置更新。该方法避免了停止运行节点，避免联盟链中的业务暂停；且节点可以在线更新配置，避免人工因素介入，提高配置更新的准确性。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如上任一项所述的联盟链配置更新方法；具体可以包括：

第一区块链节点生成第一配置更新提案，第一配置更新提案包括约定更新时间点，约定更新时间点用于指示多个区块链节点在时间到达约定更新时间点后同时更新配置；第一区块链节点将第一配置更新提案发送至第二区块链节点，第二区块链节点为多个区块链节点中除第一区块链节点之外的其他所有节点；第一区块链节点实时接收来自第二区块链节点的第一投票信息，得到投票信息集合，投票信息集合包括第一区块链节点的第一投票信息，以及第二区块链节点的第一投票信息；第一区块链节点根据投票信息集合确认第一配置更新提案是否通过；若第一配置更新提案通过，则在约定更新时间点根据第一配置更新提案进行配置更新。

或所述程序指令当被处理器执行时使所述处理器执行如下任一项所述的联盟链配置更新方法；具体可以包括：

第二区块链节点接收第一配置更新提案，第一配置更新提案包括约定更新时间点，约定更新时间点用于指示多个区块链节点在时间到达约定更新时间点后同时更新配置；第二区块链节点对第一配置更新提案进行投票确认，生成与第一配置更新提案对应的第一投票信息；第二区块链节点将第一投票信息发送至第三区块链节点，第三区块链节点为多个区块链节点中除第二区块链节点之外的其他所有节点；第二区块链节点实时接收来自第三区块链节点的第一投票信息，得到投票信息集合，投票信息集合包括第三区块链节点针对第一配置更新提案生成的第一投票信息，以及第二区块链节点针对第一配置更新提案生成的第一投票信息；第二区块链节点根据投票信息集合，判断第一配置更新提案是否通过；若第一配置更新提案通过，则在约定更新时间点根据第一配置更新提案进行配置更新。

需要说明的是，本申请实施例方法由于是在电子设备中执行，各电子设备的处理对象均以数据或信息的形式存在，例如时间，实质为时间信息，可以理解的是，后续实施例中若提及尺寸、数量、位置等，均为对应的数据存在，以便电子设备进行处理，具体此处不作赘述。

以上对本申请实施例所提供的一种联盟链配置更新方法、设备及计算机介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。