CN112835605B - 区块链版本灰度升级验证方法、装置及系统 - Google Patents

Abstract

本发明公开了一种区块链版本灰度升级验证方法、装置及系统，该方法包括：分别获取原业务链以及灰度验证业务链的待验证信息，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理；将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比；若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述原业务链和所述灰度验证业务链采用的软件版本不同。本发明实现了高效和灵活的对区块链版本灰度升级进行验证的有益效果。

Description

区块链版本灰度升级验证方法、装置及系统

技术领域

本发明涉及区块链技术领域，具体而言，涉及一种区块链版本灰度升级验证方法、装置及系统。

背景技术

区块链网络是一种利用P2P通讯技术实现对等通信、利用共识机制实现记账合法性、利用链式结构存储数据的共同记账的解决方案。区块链业务场景落地时，业务系统将业务的智能合约部署到区块链业务链系统中的每一个验证成员节点上，接收到业务系统交易请求后各验证节点进行交易共识、交易执行。

在区块链系统因技术迭代进行软件版本升级时，会对区块链系统承载的存量业务场景分析并制定对应的灰度试点策略，先选取部分业务场景进行升级试点，试点后再根据试点情况制定对应的迁移策略，这种方法被称为灰度升级。

目前对区块链系统软件版本进行灰度升级验证的策略制定十分复杂，在选择试点业务场景时常面临着选择难题：业务量小或逻辑简单的场景可能对升级后的版本验证不充分，业务量大或逻辑复杂的场景在试点过程中出现问题时业务影响面广，数据移行量大，同时也因为依赖于下游业务系统的迁移配合，无法灵活调整策略，导致整个灰度升级周期长且复杂。因此，现有技术缺少一种更为高效和灵活的对区块链版本灰度升级进行验证的方法

发明内容

本发明为了解决上述背景技术中的技术问题，提出了一种区块链版本灰度升级验证方法及装置。

为了实现上述目的，根据本发明的一个方面，提供了一种区块链版本灰度升级验证方法，该方法包括：

分别获取原业务链以及灰度验证业务链的待验证信息，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理；

将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比；

若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述原业务链和所述灰度验证业务链采用的软件版本不同。

可选的，该区块链版本灰度升级验证方法，还包括：

接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID；

若所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点，以使所述灰度验证业务链中的各验证节点对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

为了实现上述目的，根据本发明的另一方面，提供了一种区块链版本灰度升级验证装置，该装置包括：

待验证信息获取模块，用于分别获取原业务链以及灰度验证业务链的待验证信息，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理；

对比模块，用于将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比；

验证结果确定模块，用于若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述原业务链和所述灰度验证业务链采用的软件版本不同。

可选的，该区块链版本灰度升级验证方法，还包括：

业务交易请求接收模块，用于接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID；

校验模块，用于对所述业务交易请求进行合法性校验以及交易重复性校验；

处理模块，用于在校验通过后，在所述原业务链中对所述业务交易请求进行共识，在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

可选的，该区块链版本灰度升级验证方法，还包括：

业务交易请求接收模块，用于接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID；

旁路模块，用于若所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点，以使所述灰度验证业务链中的各验证节点对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

为了实现上述目的，根据本发明的另一方面，提供了一种区块链版本灰度升级验证系统，该系统包括：

原业务链以及灰度验证业务链，所述原业务链和所述灰度验证业务链采用的软件版本不同，所述原业务链以及所述灰度验证业务链均包括多个验证节点；

所述原业务链中的验证节点，用于获取所述原业务链的待验证信息以及从所述灰度验证业务链的验证节点获取所述灰度验证业务链的待验证信息，将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比，若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理。

可选的，该区块链版本灰度升级验证系统，还包括：业务系统；

所述原业务链中的验证节点，还用于接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID，以及在所述智能合约ID对应的智能合约为所述需要验证的智能合约时将所述业务交易请求发送到所述灰度验证业务链中的验证节点；

所述灰度验证业务链中的验证节点，用于对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

为了实现上述目的，根据本发明的另一方面，还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述区块链版本灰度升级验证方法中的步骤。

为了实现上述目的，根据本发明的另一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序在计算机处理器中执行时实现上述区块链版本灰度升级验证方法中的步骤。

本发明的有益效果为：本发明实施例在原业务链的基础上设置了灰度验证业务链，其中，所述原业务链和所述灰度验证业务链采用的软件版本不同，若一条业务交易请求对应的智能合约为预设的需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该条业务交易请求进行处理，最终通过统计原业务链以及灰度验证业务链的待验证信息并进行对比，来确定所述灰度验证业务链采用的软件版本是否通过验证，本发明在原业务链的基础上设置了灰度验证业务链，灰度验证业务链的运行不会对原业务链产生影响，有助于提升验证的效率，此外，由于本发明的需要验证的智能合约可以自由配置，使版本灰度升级验证更为灵活。

附图说明

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

图1是本发明实施例区块链版本灰度升级验证方法的第一流程图；

图2是本发明实施例区块链版本灰度升级验证方法的第二流程图；

图3是本发明实施例区块链版本灰度升级验证方法的第三流程图；

图4是本发明实施例区块链版本灰度升级验证系统示意图；

图5是本发明实施例验证节点的结构示意图；

图6是本发明实施例区块链版本灰度升级验证装置的第一结构框图；

图7是本发明实施例区块链版本灰度升级验证装置的第二结构框图；

图8是本发明实施例计算机设备示意图。

具体实施方式

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

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

本发明提供一种区块链版本灰度升级验证系统及方法，通过引入灰度验证业务链进行区块链版本升级验证。灰度验证业务链与业务链的程序节点程序版本不同，但区块链节点上部署的智能合约一致，业务链接收到更新类业务系统请求后同步将业务请求旁路到灰度验证业务链，业务链和灰度验证业务链各自进行交易共识及区块持久化操作，灰度验证链定时与业务链进行灰度交易结果一致性验证，在灰度验证时间段内灰度交易结果一致性验证通过，则表示本次升级版本灰度验证通过，可直接升级业务链的区块链版本，将灰度升级策略简单化，同时可随时对灰度验证业务链进行版本更新而不会影响业务链的正常工作，提升版本灰度验证效率。

本发明设计新引入灰度验证业务链，在区块链业务场景落地时，选择经过稳定性验证的区块链版本组建区块链网络，并将区块链网络上部署满足各业务场景的不同智能合约组建为业务链，当区块链版本进行迭代升级且需要进行灰度升级验证时，选择升级区块链版本组建灰度验证业务链，将业务链上的所有智能合约同步部署到灰度验证业务链上，业务链接收到更新类业务请求后同步将请求旁路至灰度验证业务链上。图4是本发明实施例区块链版本灰度升级验证系统示意图，如图4所示，本发明的区块链版本灰度升级验证系统具体包括：原业务链1、灰度验证业务链2以及业务系统4，其中，原业务链1和灰度验证业务链2包含多个验证节点3。在本发明实施例中，原业务链1和灰度验证业务链2的验证节点的结构以及部署的智能合约完全相同。但是原业务链1和灰度验证业务链2的软件版本不同，灰度验证业务链2上应用的是待验证的软件版本。

在系统具体应用时，业务系统4将业务交易请求发送给原业务链1的验证节点，其中，业务交易请求中包含智能合约ID，原业务链中的验证节点对所述业务交易请求进行合法性校验以及交易重复性校验，在校验通过后，在所述原业务链中对所述业务交易请求进行共识，在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态，完成在原业务链1中对业务交易请求的处理。

同时，原业务链1的每个验证节点中都部署有灰度验证策略文件，并在存在新版本的文件时对该灰度验证策略文件进行更新，其中，灰度验证策略具体包含：灰度验证的开关状态信息、需要验证的智能合约信息以及统计验证结果的时间信息。灰度验证的开关状态信息用于表示是否进行灰度验证，开关状态为开时表示进行灰度验证，为关时表示不进行灰度验证。当原业务链1的验证节点接收到业务系统4发送的业务交易请求时，先确定当前灰度验证的开关状态，若开关状态为开，进而确定业务交易请求中的智能合约ID是否为需要验证的智能合约，若为需要验证的智能合约，则将该业务交易请求旁路到灰度验证业务链2的验证节点，以使灰度验证业务链2对该业务交易请求进行处理。具体的，灰度验证业务链2的各验证节点对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

在本发明实施例中，灰度验证策略中的统计验证结果的时间信息用于表示何时进行验证结果的统计。在到达预设的验证结果统计时间时，原业务链1中的验证节点获取所述原业务链的待验证信息以及从所述灰度验证业务链2的验证节点获取所述灰度验证业务链的待验证信息，将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比，若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种。在本发明一个可选实施例中，同时对区块高度、区块hash以及预设的需要验证的智能合约的世界状态这三种数据进行对比验证。

基于上述实施例的区块链版本灰度升级验证系统，本发明还提供了一种区块链版本灰度升级验证方法，如以下实施例所示。以下实施例的区块链版本灰度升级验证方法的实施主体为区块链版本灰度升级验证系统中原业务链1的验证节点。

图1是本发明实施例区块链版本灰度升级验证方法的第一流程图，如图1所示，在本发明一个实施例中，本发明的区块链版本灰度升级验证方法包括步骤S101至步骤S103。

步骤S101，分别获取原业务链以及灰度验证业务链的待验证信息，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理。

在本发明一个实施例中，原业务链1和灰度验证业务链2的验证节点的结构以及部署的智能合约完全相同。

步骤S102，将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比。

步骤S103，若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述原业务链和所述灰度验证业务链采用的软件版本不同。

在本发明实施例中，灰度验证业务链采用的是待验证的软件版本，若对比一致，则确定待验证的软件版本验证通过。

在本发明实施例中，原业务链1的每个验证节点中都部署有灰度验证策略文件，并在存在新版本的文件时对该灰度验证策略文件进行更新，其中，灰度验证策略具体包含：灰度验证的开关状态信息、需要验证的智能合约信息以及统计验证结果的时间信息。统计验证结果的时间信息用于表示何时进行验证结果的统计。在到达预设的验证结果统计时间时，原业务链1中的验证节点执行上述步骤S101至步骤S103。

图2是本发明实施例区块链版本灰度升级验证方法的第二流程图，如图2所示，在本发明一个实施例中，本发明的区块链版本灰度升级验证方法还包括步骤S201至步骤S203。

步骤S201，接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID。

步骤S202，对所述业务交易请求进行合法性校验以及交易重复性校验。

步骤S203，在校验通过后，在所述原业务链中对所述业务交易请求进行共识，在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

步骤S201至步骤S203为原业务链对业务交易请求进行处理的流程。

图3是本发明实施例区块链版本灰度升级验证方法的第三流程图，如图3所示，在本发明一个实施例中，本发明的区块链版本灰度升级验证方法还包括步骤S301和步骤S302。

步骤S301，接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID。

步骤S302，若所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点，以使所述灰度验证业务链中的各验证节点对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

步骤S301至步骤S302为将业务交易请求旁路到灰度验证业务链中由灰度验证业务链对其进行处理的流程。

在本发明实施例中，灰度验证策略具体包含：灰度验证的开关状态信息以及需要验证的智能合约信息。灰度验证的开关状态信息用于表示是否进行灰度验证，开关状态为开时表示进行灰度验证，为关时表示不进行灰度验证。

在本发明一个实施例中，上述步骤S302的若所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点，具体为：

若灰度验证的开关状态为开，并且所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点。

下面对本发明区块链版本灰度升级验证系统及方法进行详细的介绍。本发明的区块链版本灰度升级验证系统具体包括：原业务链1、灰度验证业务链2以及业务系统4，其中，原业务链1和灰度验证业务链2包含多个验证节点3。

原业务链1是根据业务系统4的上链业务需求组建而成，由多个验证节点3组成，所有验证节点上均部署有与业务系统4进行业务请求交互的1个或多个业智能合约，每个业务智能合约部署成功后都会反馈一个唯一的合约ID，业务智能合约ID会通知到调用方业务系统。验证节点3负责接收业务系统4发起的业务交易请求，根据请求交易包中的智能合约ID进行交易路由，根据灰度旁路设置将交易旁路到灰度验证业务链2，并完成对应的交易共识处理。原业务链1中验证节点总数为3f+1个，其中f表示可支持的容错节点个数，最小值为1，业务智能合约均采用pbft拜占庭容错算法进行共识，一笔共识请求必须在业务链1中的每个验证节点3收到至少2f+1个来自其他验证节点的一致的确认消息后，该笔交易才能完成当前阶段的共识，拜占庭容错算法三个阶段的共识都完成后才共识成功，业务请求才被执行，才会更新对应的世界状态数据。

灰度验证业务链2是根据原业务链1的灰度升级验证需求组建而成，其组织机构与原业务链1完全一致，也包括多个验证节点3，所有验证节点上均部署有业务链1上部署的所有业务智能合约，且采用指定智能合约ID的形式进行部署，保证所部署的业务智能合约ID与原业务链1上的业务智能合约ID一致。灰度验证业务链2中的验证节点总数也为3f+1个，其中f表示可支持的容错节点个数，最小值为1，函件地址系统智能合约和业务智能合约均采用pbft拜占庭容错算法进行共识，一笔共识请求必须在灰度验证业务链2中的每个验证节点3收到至少2f+1个来自其他验证节点的一致的确认消息后，该笔交易才能完成当前阶段的共识，拜占庭容错算法三个阶段的共识都完成后才共识成功，业务请求才被执行，才会更新对应的世界状态数据。灰度验证业务链2的验证节点与原业务链1的验证节点进行通讯交互，接收灰度旁路交易请求，并根据智能合约ID将交易路由到验证节点中进行共识。

验证节点3用于接收交易请求，根据智能合约ID信息进行对应的交易共识路由，根据灰度验证策略进行交易灰度验证旁路及灰度验证结果核对。对业务智能合约的交易进行共识处理。其中灰度验证策略支持根据业务智能合约ID进行灵活配置，灰度策略可灵活配置到智能合约级别，同时支持通过定期统计分析灰度验证结果。原业务链1及灰度验证业务链2中所有验证节点3内部结构均一致，对待共识交易进行参数合法性校验，校验通过后则进入三段式共识过程，第一阶段为pre-prepare共识，第二阶段为prepare共识，第三阶段为commit共识，三个阶段为顺序执行，当前一阶段累计收到2f+1个其他交易共识节点的一致确认消息后当前阶段的共识完成并进入下一阶段，三个阶段的共识全部完成后代表共识消息合法，按合约中的逻辑处理后的数据生成新的区块数据，更新合约对应的是饥饿状态数据并触发合约执行后的相关系统流程。

业务系统4是业务交易请求发起系统，向业务链1的接入节点3发起业务交易请求，并接收接入节点3的交易请求处理返回信息并进行相关业务逻辑闭环。

图5是本发明实施例验证节点的结构示意图，如图5所示，验证节点包含交易请求收发装置11、灰度验证执行装置12、交易路由装置13以及业务合约共识及执行装置14。

所述“交易请求收发装置11”负责接收业务系统4发起的业务请求，根据交易证书对交易进行验密，根据交易请求Invoke(stubId,function,args)中的智能合约ID信息stubId(stubId为部署合约后业务链1返回的标识某一合约的唯一ID)进行合法性校验以及交易重复性校验等操作，校验通过的交易请求将会连同请求调用的智能合约ID转发至交易路由装置13。

所述“灰度验证执行装置12”负责加载对应的灰度验证策略，并定时输出灰度验证统计信息供用户进行灰度验证结果查看分析并灵活调整灰度验证策略，具体包括灰度配置加载模块121及灰度验证统计模块122。

所述“灰度配置加载模块121”负责加载灰度验证策略文件，业务链启动时对灰度验证策略文件testPolicy.ini进行首次加载并记录文件最后更新时间，后续在业务链运行过程中定时监测灰度验证策略文件testPolicy.ini的最新更新时间，如果最新更新时间发生变化则重新加载最新修改的灰度验证策略文件。灰度验证策略文件testPolicy.ini的配置格式可以为：

flag:1

timeInterval:12h

[智能合约ID1；智能合约ID2；智能合约ID3；....；智能合约IDn]

flag为灰度验证总开关，即灰度验证的开关状态信息，flag为0时表示灰度验证开关关闭，无需加载配置的进行灰度验证的智能合约ID信息，即无灰度验证交易；flag为1时表示灰度验证开关开启，且验证的智能合约可为1个或多个，用智能合约ID进行标识。

timeInterval为验证结果输出周期，单位为小时，即统计验证结果的时间信息，支持按照试点结果统计周期进行自定义配置。

因灰度验证策略配置文件testPolicy.ini会被验证节点3系统定时加载，因此支持灰度策略动态更新，可实时开启或关闭灰度验证，也可实时调整需灰度验证的智能合约。原业务链1中所有验证节点3的结构均一致，根据需求对外开放原业务链1上的1个或多个验证节点3地址信息给业务系统接入，即对外开放的验证节点3均会接收到业务系统4发起的交易，所以多有对外开放的验证节点3上均需配置相同的灰度验证策略配置文件testPolicy.ini。灰度验证业务链1中的验证节点灰度开关为关，即灰度验证策略配置文件testPolicy.ini中的flag配置为0，灰度验证业务链1不做交易业务旁路。

所述“灰度验证统计模块122”负责定时对灰度验证结果进行搜集及汇总，根据系统中的timeInterval验证结果输出周期进行定期对业务链1和灰度验证业务链1中的数据进行查询并输出到验证结果文件中，定时灰度验证结果统计文件名称为testResult.年月日时分秒，文件内容包括原业务链1及灰度验证业务链2的区块高度、区块hash，灰度验证策略配置文件testPolicy.ini中的配置智能合约(即需要验证的智能合约)的状态数据一致性信息：

blockChainNum:[chain1:x；chain2:x]

blockChainHash:[chain1:y；chain2:x]

stateData:[智能合约ID1:result1；智能合约ID2:result2；.....智能合约IDn:resultN；]

其中blockChainNum标识业务链1和灰度验证业务链1的区块高度比对结果，blockChainHash标识业务链1和灰度验证业务链1的最后区块的Hash比对结果，stateData记录灰度验证智能合约的世界状态一致性信息，用result来标识其一致性结果：0表示一致，1表示不一致。只有灰度验证结果统计文件testResult中区块高度和区块Hash一致、所有验证的智能合约的一致性结果为0即代表灰度验证结果一致，验证结果通过。

所述“交易路由装置13”负责主控交易进入对应的合约共识路由，根据智能合约ID路由到对应的业务合约共识及执行装置，并根据灰度配置策略将灰度验证交易旁路到灰度验证业务链1的验证节点3，具体包括交易路由转发模块131，交易路由查询模块132，灰度验证旁路发送模块133。

所述“交易路由转发模块131”负责根据交易请求收发装置11请求交易Invoke(stubId,function,args)中的智能合约ID信息stubId在交易路由查询模块132维护的交易路由信息列表StubMap中查询当前智能合约是否已经部署，如果已经部署则根据ID路由到对应的业务智能合约共识及执行装置，如果没有部署则返回错误信息给业务系统。

所述“交易路由查询模块132”负责更新当前系统中需要进行灰度验证旁路的智能合约ID信息，定时维护交易路由信息列表StubMap，其在内存中的格式可以为：{智能合约1ID:智能合约1旁路标识；智能合约2ID；智能合约2旁路标识；.......智能合约nID:智能合约n旁路标识}，在内存中按key:value格式存储，key为业务链1系统中全局唯一的智能合约ID，value为智能合约旁路开关(0为关闭，1为开启)，该列表中包含当前业务链1系统中部署的所有业务智能合约的ID信息，每新增一个业务智能合约就会在列表中插入一条初始vlae为0的智能合约记录。同时定时根据当前系统中配置的灰度验证智能合约ID信息进行列表检索并将灰度验证策略配置文件testPolicy.ini中开启灰度验证开关的智能合约ID为key的记录value更新为1。

所述“灰度验证旁路发送模块133”根据请求交易Invoke(stubId,function,args)中的智能合约ID信息在交易路由信息列表StubMap中进行检索，若该合约ID为key值对应的灰度策略开关为1则表示该交易需要进行旁路，将请求交易Invoke(stubId,function,args)直接原包转发至灰度验证业务链2的验证节点3，并接收灰度验证业务链2的验证节点3的反馈，在超时时间内未收到反馈则按配置重发次数进行重发。

所述“业务合约共识及执行装置14”是对业务系统4发起的业务交易请求进行共识处理的装置，负责对业务系统4发起的业务请求进行交易共识、业务合约逻辑处理及区块更新等处理，对业务请求参数进行校验并进行交易共识处理的模块，负责校验交易请求参数及来源等信息，将业务请求区块的hash,将区块共识消息保存到本地磁盘中，将区块序号加1，封装区块共识广播消息以便广播到原业务链1中所有验证节点3中。同时可接收原业务链1中其他验证节点3发起的业务交易共识请求，使用拜占庭共识算法对交易进行三段式共识处理，第一阶段为pre-prepare共识，第二阶段为prepare共识，第三阶段为commit共识，三个阶段为顺序执行，当前一阶段累计收到2f+1个其他交易共识节点的一致确认消息后当前阶段的共识完成并进入下一阶段，三个阶段的共识全部完成后代表该业务请求合法，按业务合约请求区块进行持久化，并执行业务逻辑将结果写入对应业务合约的世界状态数据中。

在本发明一个实施例中，本发明的验证节点灰度验证旁路的流程具体可以包括以下步骤S401至步骤S405。

步骤S401：原业务链1的验证节点3启动，灰度验证执行装置12的灰度配置加载灰度验证策略文件testPolicy.ini及文件定期刷新时间间隔t，灰度开关flag，结果统计时间timeInterval，灰度智能合约ID列表加载到内存中，并记录灰度验证策略配置文件testPolicy.ini的最新修改时间t1，并每隔时间t检测一次灰度验证策略配置文件testPolicy.ini验证策略配置文件的最新修改时间。

步骤S402A：灰度验证策略文件testPolicy.ini的最新修改时间发生改变，灰度验证策略文件testPolicy.ini有更新，重新加载灰度开关flag，结果统计时间timeInterval，灰度智能合约ID列表加载到内存中。

步骤S402B：灰度验证策略文件testPolicy.ini的最新修改时间没有发生改变，灰度验证策略文件testPolicy.ini无更新，无需重新加载。

步骤S403：原业务链1的验证节点3启动时交易路由装置13的交易路由查询模块132加载当前系统的所有智能合约ID信息并对交易路由信息列表StubMap进行初始化，初始化所有智能合约的灰度标识别均为0，并根据灰度验证执行装置12中记录的最新灰度智能合约ID列表更新交易路由信息列表StubMap中这些智能合约ID的灰度标识为1，且每隔时间t进行一次交易路由信息列表StubMap刷新，更新业务链1全量智能合约ID列表及智能合约灰度标识。

步骤S404：交易请求收发装置11接收业务系统4发起的业务请求，Invoke(stubId,function,args)，验证交易证书，交易重复性，并将验证通过的交易请求转发至交易路由装置13。

步骤S405：交易路由装置13的灰度验证旁路发送模块133根据交易请求Invoke(stubId,function,args)中的智能合约ID：stubId在交易路由信息列表StubMap中检索灰度标识，如果该智能合约的灰度标识为1，则将该交易旁路至灰度验证业务链1中的验证节点3。

由以上实施例可以看出，本发明提供一种区块链版本灰度升级验证系统及方法，通过引入灰度验证业务链对区块链网络升级版本进行灰度验证，验证期间与业务链并行运行，不影响业务链正常对外服务，同时能根据灰度验证情况灵活调整升级版本程序，验证通过后可将存量业务一次性升级到新版本，灰度策略灵活可控，业务体验良好。本发明至少实现了以下有益效果：

1、屏蔽区块链版本升级对业务影响：灰度验证业务链与原业务链并行运行，在灰度验证期间业务交易仍由旧版本业务链系统进行处理，能有效避免因升级版本发生异常及回切会升级前系统过程中的业务影响。

2、灰度验证更充分：通过将业务请求旁路到灰度验证业务链进行升级验证，能保障对全量业务类型交易进行验证，而不是只能针对选中的少量试点交易进行验证，验证后的系统运行稳定性更有保障。

3、灰度验证过程中可灵活调整：灰度验证业务链定时对验证结果进行一致性核对，如果发现程序问题可随时进行调整替换并快速进入下一个灰度验证迭代周期，灵活性高。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

基于同一发明构思，本发明实施例还提供了一种区块链版本灰度升级验证装置，可以用于实现上述实施例所描述的区块链版本灰度升级验证方法，如下面的实施例所述。由于区块链版本灰度升级验证装置解决问题的原理与区块链版本灰度升级验证方法相似，因此区块链版本灰度升级验证装置的实施例可以参见区块链版本灰度升级验证方法的实施例，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图6是本发明实施例区块链版本灰度升级验证装置的第一结构框图，如图6所示，本发明实施例区块链版本灰度升级验证装置包括：

待验证信息获取模块101，用于分别获取原业务链以及灰度验证业务链的待验证信息，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理；

对比模块102，用于将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比；

验证结果确定模块103，用于若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述原业务链和所述灰度验证业务链采用的软件版本不同。

图7是本发明实施例区块链版本灰度升级验证装置的第二结构框图，如图7所示，本发明实施例区块链版本灰度升级验证装置还包括：

业务交易请求接收模块104，用于接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID。

校验模块105，用于对所述业务交易请求进行合法性校验以及交易重复性校验；

处理模块106，用于在校验通过后，在所述原业务链中对所述业务交易请求进行共识，在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态；

旁路模块107，用于若所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点，以使所述灰度验证业务链中的各验证节点对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

在本发明一个实施例中，本发明的区块链版本灰度升级验证装置还包括：

灰度验证策略更新模块，用于对本地的灰度验证策略进行更新，其中，所述灰度验证策略包含：灰度验证的开关状态信息、需要验证的智能合约信息以及统计验证结果的时间信息。

为了实现上述目的，根据本申请的另一方面，还提供了一种计算机设备。如图8所示，该计算机设备包括存储器、处理器、通信接口以及通信总线，在存储器上存储有可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述实施例方法中的步骤。

处理器可以为中央处理器(Central Processing Unit，CPU)。处理器还可以为其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及单元，如本发明上述方法实施例中对应的程序单元。处理器通过运行存储在存储器中的非暂态软件程序、指令以及模块，从而执行处理器的各种功能应用以及作品数据处理，即实现上述方法实施例中的方法。

存储器可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储处理器所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述一个或者多个单元存储在所述存储器中，当被所述处理器执行时，执行上述实施例中的方法。

上述计算机设备具体细节可以对应参阅上述实施例中对应的相关描述和效果进行理解，此处不再赘述。

为了实现上述目的，根据本申请的另一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序在计算机处理器中执行时实现上述区块链版本灰度升级验证方法中的步骤。本领域技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)、随机存储记忆体(RandomAccessMemory，RAM)、快闪存储器(Flash Memory)、硬盘(Hard DiskDrive，缩写：HDD)或固态硬盘(Solid-State Drive，SSD)等；所述存储介质还可以包括上述种类的存储器的组合。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (17)

1.一种区块链版本灰度升级验证方法，其特征在于，包括：

分别获取原业务链以及灰度验证业务链的待验证信息，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理；

将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比；

若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述原业务链和所述灰度验证业务链采用的软件版本不同。

2.根据权利要求1所述的区块链版本灰度升级验证方法，其特征在于，还包括：

接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID；

对所述业务交易请求进行合法性校验以及交易重复性校验；

在校验通过后，在所述原业务链中对所述业务交易请求进行共识，在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

3.根据权利要求1所述的区块链版本灰度升级验证方法，其特征在于，还包括：

接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID；

若所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点，以使所述灰度验证业务链中的各验证节点对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

4.根据权利要求3所述的区块链版本灰度升级验证方法，其特征在于，若所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点，具体包括：

若灰度验证的开关状态为开，并且所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点。

5.根据权利要求1所述的区块链版本灰度升级验证方法，其特征在于，还包括：

对本地的灰度验证策略进行更新，其中，所述灰度验证策略包含：灰度验证的开关状态信息、需要验证的智能合约信息以及统计验证结果的时间信息。

6.根据权利要求1所述的区块链版本灰度升级验证方法，其特征在于，所述原业务链的验证节点以及所述灰度验证业务链的验证节点上部署的智能合约相同。

7.一种区块链版本灰度升级验证装置，其特征在于，包括：

待验证信息获取模块，用于分别获取原业务链以及灰度验证业务链的待验证信息，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理；

对比模块，用于将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比；

验证结果确定模块，用于若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述原业务链和所述灰度验证业务链采用的软件版本不同。

8.根据权利要求7所述的区块链版本灰度升级验证装置，其特征在于，还包括：

业务交易请求接收模块，用于接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID；

校验模块，用于对所述业务交易请求进行合法性校验以及交易重复性校验；

处理模块，用于在校验通过后，在所述原业务链中对所述业务交易请求进行共识，在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

9.根据权利要求7所述的区块链版本灰度升级验证装置，其特征在于，还包括：

业务交易请求接收模块，用于接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID；

旁路模块，用于若所述智能合约ID对应的智能合约为所述需要验证的智能合约，则将所述业务交易请求发送到所述灰度验证业务链中的验证节点，以使所述灰度验证业务链中的各验证节点对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

10.根据权利要求7所述的区块链版本灰度升级验证装置，其特征在于，还包括：

灰度验证策略更新模块，用于对本地的灰度验证策略进行更新，其中，所述灰度验证策略包含：灰度验证的开关状态信息、需要验证的智能合约信息以及统计验证结果的时间信息。

11.一种区块链版本灰度升级验证系统，其特征在于，包括：原业务链以及灰度验证业务链，所述原业务链和所述灰度验证业务链采用的软件版本不同，所述原业务链以及所述灰度验证业务链均包括多个验证节点；

所述原业务链中的验证节点，用于获取所述原业务链的待验证信息以及从所述灰度验证业务链的验证节点获取所述灰度验证业务链的待验证信息，将所述原业务链的待验证信息与所述灰度验证业务链的待验证信息进行对比，若对比一致，则确定所述灰度验证业务链采用的软件版本通过验证，其中，所述待验证信息包括：区块高度、区块hash以及预设的需要验证的智能合约的世界状态中的至少一种；若业务交易请求对应的智能合约为所述需要验证的智能合约，则所述原业务链以及所述灰度验证业务链均对该业务交易请求进行处理。

12.根据权利要求11所述的区块链版本灰度升级验证系统，其特征在于，还包括：业务系统；

所述原业务链中的验证节点，还用于接收所述业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID；

所述原业务链中的验证节点，还用于对所述业务交易请求进行合法性校验以及交易重复性校验，在校验通过后，在所述原业务链中对所述业务交易请求进行共识，在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

13.根据权利要求11所述的区块链版本灰度升级验证系统，其特征在于，还包括：业务系统；

所述原业务链中的验证节点，还用于接收业务系统发送的业务交易请求，其中，所述业务交易请求中包含智能合约ID，以及在所述智能合约ID对应的智能合约为所述需要验证的智能合约时将所述业务交易请求发送到所述灰度验证业务链中的验证节点；

所述灰度验证业务链中的验证节点，用于对所述业务交易请求进行共识，以及在共识成功后生成数据区块并更新所述智能合约ID对应的智能合约的世界状态。

14.根据权利要求11所述的区块链版本灰度升级验证系统，其特征在于，还包括：

所述原业务链中的验证节点，还用于对本地存储的灰度验证策略进行更新，其中，所述灰度验证策略包含：灰度验证的开关状态信息、需要验证的智能合约信息以及统计验证结果的时间信息。

15.根据权利要求11所述的区块链版本灰度升级验证系统，其特征在于，所述原业务链的验证节点以及所述灰度验证业务链的验证节点上部署的智能合约相同。

16.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6任一项所述的方法。

17.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序在计算机处理器中执行时实现如权利要求1至6任意一项所述的方法。