CN110049051A - 请求的验证方法、装置、存储介质及联盟链验证系统 - Google Patents

Abstract

本申请提供一种请求的验证方法、装置、存储介质及联盟链验证系统，方法包括：获取待验证的请求；从记账节点中确定出用于处理请求的目标记账节点，以及获取目标记账节点的信任度，其中，记账节点的信任度中有至少两个信任度不同；将目标记账节点的信任度发送给共识节点，使得共识节点根据目标记账节点对请求的验证结果，以及根据目标记账节点的信任度，确定请求是否验证通过。通过确定出处理请求的目标记账节点，可以针对不同的请求确定适合处理该请求的记账节点，提高验证请求的灵活性和准确性；而确定出目标记账节点的信任度，由于不同的目标记账节点可以有不同的信任度，使得记账节点的投票趋于灵活和精准，进而提高验证请求的灵活性和准确性。

Description

请求的验证方法、装置、存储介质及联盟链验证系统

技术领域

本申请涉及区块链领域，具体而言，涉及一种请求的验证方法、装置、存储介质及联盟链验证系统。

背景技术

目前的区块链技术中，联盟链内的各个组织的管理和验证授权的可靠性和准确性不是很理想，通常是简单聚合验证记账节点的投票率，判断其是否高于某一数值，这样的方式灵活性有所欠缺，不利于提高验证的准确性。

发明内容

有鉴于此，本申请的目的在于提供一种验证方法、装置、存储介质及联盟链验证系统，以提高联盟链请求验证的灵活性和准确性。

为了实现上述目的，本申请的实施例通过如下方式实现：

第一方面，本申请实施例提供了一种请求的验证方法，所述方法应用于所述联盟链包括的记账节点和共识节点中的任一节点，所述方法包括：

获取待验证的请求；从所述记账节点中确定出用于处理所述请求的目标记账节点，以及获取所述目标记账节点的信任度，其中，所述记账节点的信任度中有至少两个信任度不同；将所述目标记账节点的信任度发送给所述共识节点，使得所述共识节点根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

在本申请实施例中，通过在需要对请求进行验证时，确定出处理该请求的目标记账节点，这样可以针对不同的请求确定更合适对该请求打分的记账节点，提高验证请求的灵活性和准确性；而对应确定出目标记账节点的信任度，信任度可以是打分的权重值或者投票的分数等等，不同的目标记账节点可以赋予不同的信任度，可以使得记账节点的投票趋于灵活和精准，进一步提高验证请求的灵活性和准确性。

结合第一方面，在第一方面的第一种可能的实现方式中，从所述记账节点中确定出用于处理所述请求的目标记账节点，包括：

确定出所述请求的类型；从所述记账节点中确定出对所述类型有处理权限的所述目标记账节点。

在本申请实施例中，通过对待验证的请求的类型进行识别，确定出对该类型的请求有处理权限的目标记账节点，可以使得确定目标记账节点的过程更加迅速和准确，只有对该请求的类型有处理权限的目标记账节点能够处理该请求，能够从记账节点中筛选出对该请求预期的处理效果更好的目标记账节点，从而能够提高验证请求的准确性。

结合第一方面，在第一方面的第二种可能的实现方式中，获取所述目标记账节点的信任度，包括：

从所述目标记账节点预设的多个信任度中选择出与所述请求的类型对应的信任度；或根据所述请求，生成所述目标记账节点的信任度。

在本申请实施例中，目标记账节点的信任度可以是预设的多个信任度中的一个，预设的信任度，具有打分稳定的特点；也可以是根据请求而生成的信任度，临时生成的信任度，具有更强的灵活性，可以提高验证请求的准确性。

结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，根据所述请求，生成所述目标记账节点的信任度，包括：

获取所述目标记账节点处理与所述请求的类型相同的历史请求的数量；根据所述数量，生成所述目标记账节点的信任度，其中，所述数量越多，所述目标记账节点的信任度越高。

在本申请实施例中，通过根据目标记账节点处理该类型请求的历史数量的多少来生成目标记账节点的信任度，数量越多，信任度越高，这样可以对处理该类型请求的数量不同的目标记账节点灵活地赋予不同的信任度，以此提高验证请求的准确性。

结合第一方面，或者结合第一方面的第一种至第三种中任一可能的实现方式，在第一方面的第四种可能的实现方式中，获取待验证的请求，包括：

接收请求生成设备发送的所述请求；或基于响应用户的操作生成所述请求。

在本申请实施例中，待验证的请求可以是接收请求生成设备发送的待验证的请求，也可以是该节点自己生成的，使得请求的验证方法可以应用得更加广泛。

第二方面，本申请实施例提供了一种请求的验证方法，联盟链包括共识节点和记账节点，所述方法应用于所述共识节点中，所述方法包括：

接收所述联盟链内其它节点发送的目标记账节点的信任度，其中，所述其它节点用于从所述记账节点中确定出目标记账节点，以及所述其它节点还用于获取所述目标记账节点的信任度，其中，所述目标记账节点用于处理待验证的请求，所述记账节点的信任度中有至少两个信任度不同；根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

在本申请实施例中，共识节点可以根据接收的目标记账节点的信任度，结合目标记账节点对待验证的请求的验证结果，去验证该请求是否通过。由于对待验证的请求有处理权限的目标记账节点的信任度可以不同，因此可以提高验证请求的灵活性和准确性。

结合第二方面，在第二方面的第一种可能的实现方式中，所述目标记账节点对所述请求的验证结果中包含验证分数，根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过，包括：

获取所述目标记账节点的验证分数；获取所述目标记账节点的信任度和所述目标记账节点的验证分数的乘积值；通过将所有所述乘积值进行加总，获取所述请求的验证总分数；通过将所述验证总分数与预设分数比较而确定所述请求是否通过验证。

在本申请实施例中，通过将目标记账节点的信任度与该目标记账节点的验证分数相乘，并将所有的乘积值加总，可以确定出所有目标记账节点对该请求的验证结果，再将加总后得到的验证总分数与预设分数相比较，可以确定该请求是否验证通过。通过这样的方式验证请求，具有很高的准确性。

第三方面，本申请实施例提供了一种请求的验证装置，所述装置装载于所述联盟链包括的记账节点和共识节点中的任一节点中，所述装置包括：

获取模块，用于获取待验证的请求；处理模块，用于从所述记账节点中确定出用于处理所述请求的目标记账节点，以及获取所述目标记账节点的信任度，其中，所述记账节点的信任度中有至少两个信任度不同；发送模块，用于将所述目标记账节点的信任度发送给所述共识节点，使得所述共识节点根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

结合第三方面，在第三方面的第一种可能的实现方式中，所述处理模块：

还用于确定出所述请求的类型；从所述记账节点中确定出对所述类型有处理权限的所述目标记账节点。

结合第三方面，在第三方面的第二种可能的实现方式中，所述处理模块：

还用于从所述目标记账节点预设的多个信任度中选择出与所述请求的类型对应的信任度；或根据所述请求，生成所述目标记账节点的信任度。

结合第三方面的第二种可能的实现方式，在第三方面的第三种可能的实现方式中，所述处理模块：

还用于获取所述目标记账节点处理与所述请求的类型相同的历史请求的数量；根据所述数量，生成所述目标记账节点的信任度，其中，所述数量越多，所述目标记账节点的信任度越高。

结合第三方面，或者结合第三方面的第一种至第三种中任一可能的实现方式，在第三方面的第四种可能的实现方式中，所述获取模块：

还用于接收请求生成设备发送的所述请求；或基于响应用户的操作生成所述请求。

第四方面，本申请实施例提供了一种请求的验证装置，联盟链包括共识节点和记账节点，所述装置装载于所述共识节点中，所述装置包括：

接收模块，用于接收所述联盟链内其它节点发送的目标记账节点的信任度，其中，所述其它节点用于从所述记账节点中确定出目标记账节点，以及所述其它节点还用于获取所述目标记账节点的信任度，其中，所述目标记账节点用于处理待验证的请求，所述记账节点的信任度中有至少两个信任度不同；验证模块，用于根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

结合第四方面，在第四方面的第一种可能的实现方式中，所述目标记账节点对所述请求的验证结果中包含验证分数，所述验证模块：

还用于获取所述目标记账节点的验证分数；获取所述目标记账节点的信任度和所述目标记账节点的验证分数的乘积值；通过将所有所述乘积值进行加总，获取所述请求的验证总分数；通过将所述验证总分数与预设分数比较而确定所述请求是否通过验证。

第五方面，本申请实施例提供了一种具有计算机可执行的非易失程序代码的计算机可读储存介质，用于存储程序代码，所述程序代码在被计算机读取并运行时，执行第一方面、第一方面的任一可能的实现方式、第二方面或第二方面的任一可能的实现方式所述的请求的验证方法。

第六方面，本申请实施例提供了一种联盟链验证系统，包括：共识节点和记账节点，所述共识节点和记账节点中的任一节点用于执行第一方面或第一方面的任一可能的实现方式所述的请求的验证方法；以及，所述共识节点，还用于执行第二方面或第二方面的任一可能的实现方式所述的请求验证方法。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它相关的附图。

图1示出了本申请实施例提供的一种联盟链验证系统的第一应用场景图；

图2示出了本申请实施例提供的一种联盟链验证系统的第三应用场景图；

图3示出了本申请实施例提供的一种请求的验证方法应用于联盟链内任一节点的流程图；

图4示出了本申请实施例提供的一种请求的验证方法应用于联盟链内共识节点的流程图；

图5示出了本申请实施例提供的一种请求的验证方法的时序图；

图6示出了本申请实施例提供的请求的验证装置应用于联盟链内任一节点的结构框图；

图7示出了本申请实施例提供的请求的验证装置应用于联盟链内共识节点的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

本申请实施例提供一种联盟链验证系统，联盟链验证系统由多个节点构成，其中可以包括多个记账节点和多个共识节点。当然，在一些特殊的情况下，共识节点也可以为一个，此处不作限定。

请参阅图1，联盟链验证系统10包括共识节点11和记账节点12。其中，共识节点11和记账节点12都可以为多个。例如，图1中的共识节点11包括：节点A1、节点A2、节点A3和节点A4；记账节点12包括：节点B1、节点B2、节点B3、节点B4、节点B5、节点B6和节点B7。其中，共识节点11之间可以相互传递信息，因此每个共识节点11无需与每个记账节点12直接建立通信连接关系，就可以实现共识节点11与每个记账节点12的通信连接。这样的方式可以提高整个联盟链验证系统10的运行效率。可以理解的是，图中示出4个共识节点11和7个记账节点12是为了便于例举说明，其并不作为对本实施例的限定，实际中可以根据需求选择共识节点11和记账节点12的数量。

本申请实施例提供的请求的验证方法可以应用于联盟链内包括的记账节点和共识节点中的任一节点，例如图1，该方法应用于节点A2，那么节点A2，相当于一个执行管理员角色的节点，运行请求的验证方法。

当然，此处在节点A2上运行请求的验证方法只是举例，并非对本申请的限定。请求的验证方法也可以在联盟链内的其他节点上运行，例如，请求的验证方法可以在节点B5上运行，那么此时节点B5就相当于相当于一个执行管理员角色的节点。

需要说明的是，本实施例的图1中给出的联盟链验证系统，是以一个组织为单位的，即一个组织作为一个联盟链验证系统，在图2中，还给出了一种多个组织之间联盟的状态下形成的联盟链验证系统10。该联盟链验证系统10包括第一子联盟链验证系统110和第二子联盟链验证系统120，协同运作，为运行本申请实施例提供的请求的验证方法提供运行环境。其中，一个子联盟链验证系统可以表示实际中的一个公司、一个企业或者一个单位部门等。

第一子联盟链验证系统110包括节点A1、节点A2、节点A3、节点A4、节点A5和节点A6；还包括：节点B1、节点B3、节点B4、节点B5、节点B6、节点B7和节点B8；节点B5相当于执行管理员角色的节点。而第二子联盟链验证系统120包括：节点A7、节点A8和节点A9；还包括：节点B11、节点B12、节点B13、节点B14和节点B15；节点A9相当于执行管理员角色的节点。而由多个子联盟链验证系统构成的联盟链验证系统10，每个子联盟链验证系统中可由一个节点执行管理员角色的功能。但请求发起时，可以由首先接收并处理该请求的运行管理员角色的节点与其他子联盟链验证系统中的运行管理员角色的节点通信，在达成共识后决定是将该请求驳回还是以将该请求共享给共识节点处理。因此，联盟链验证系统10的形式有多种，还可以为5个组织、8个组织等多个组织结成联盟的状态而构成联盟链验证系统10，此处不作限定。具有多个子联盟链验证系统的联盟链验证系统，其运行管理员角色的节点可以为一个，也可以为多个，此处不限定。

通过这样的方式，可以在多个组织结成联盟而形成的联盟链验证系统的情况下，也能够便捷地运行本申请实施例提供的请求的验证方法，从而使得请求的验证方法的应用更加广泛。

另外，在联盟链验证系统具有多个子联盟链验证系统时，若存在的运行管理员角色的节点为多个，各个子联盟链验证系统可以相互独立，那么各个子联盟链验证系统中对同一个待验证请求的验证标准可以不同，可以有不同的验证结果。相当于每个子联盟链验证系统都是一个独立的联盟链验证系统，只是多个子联盟链验证系统之间具有连接关系。

通过这样的方式，可以使得联盟链验证系统中的多个子联盟链验证系统可以具备一定的相对独立性。

本实施例的联盟链验证系统10中的共识节点11和记账节点12可以是智能手机、平板电脑、个人电脑、个人数字助理等终端设备；也可以为服务器，例如可以为网络服务器、数据库服务器、云服务器或由多个子服务器构成的服务器集成等。本实施例提供的请求的验证方法，可以应用于联盟链验证系统10的任一节点中，以实现对待验证请求的验证。

为了清楚地说明联盟链内各个节点在运行本实施例提供的请求的验证方法的具体过程，以下将结合图3-图5从联盟链的不同节点的角度介绍本方法。由于包括多个子联盟链验证系统的联盟链验证系统中的每个子联盟链验证系统在执行请求的验证方法时，其过程是类似的，因此，本实施例以包括两个子联盟链验证系统的联盟链验证系统为例进行说明。

请参阅图3，图3示出了本实施例提供的请求的验证方法应用于联盟链内任一节点的流程图。需要说明的是，本实施例提供的请求的验证方法可以应用于联盟链内的共识节点11或者记账节点12中的任一节点，在该节点应用本实施例提供的请求的验证方法时，相当于管理员角色，执行管理员的功能。

在本实施例中，请求的验证方法可以包括：步骤S110、步骤S120和步骤S130。

步骤S110：获取待验证的请求。

步骤S120：从所述记账节点中确定出用于处理所述请求的目标记账节点，以及获取所述目标记账节点的信任度，其中，所述记账节点的信任度中有至少两个信任度不同。

步骤S130：将所述目标记账节点的信任度发送给所述共识节点，使得所述共识节点根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

请参阅图4，图4示出了本实施例提供的请求的验证方法应用于联盟链内共识节点的流程图。本实施例提供的请求的验证方法可以应用于联盟链内所有的共识节点11。需要说明的是，在共识节点11运行管理员角色执行管理功能时，该共识节点11也可以运行共识节点11应当运行的请求的验证方法。

在本实施例中，应用于联盟链内共识节点的请求的验证方法可以包括步骤S210和步骤S220。

步骤S210：接收所述联盟链内其它节点发送的目标记账节点的信任度，其中，所述其它节点用于从所述记账节点中确定出目标记账节点，以及所述其它节点还用于获取所述目标记账节点的信任度，其中，所述目标记账节点用于处理待验证的请求，所述记账节点的信任度中有至少两个信任度不同。

步骤S220：根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

在本实施例中，在有可获得的待验证的请求时，执行管理员角色的节点可以执行步骤S110。

步骤S110：获取待验证的请求。

当某一子联盟链验证系统中的某一共识节点11或者记账节点12基于响应用户的操作而生成待验证的请求时，若该节点在生成该请求时是基于管理员角色而生成的，就可以对该请求进行后续处理；若该节点在生成该请求时并非基于管理员角色生成，而是基于用户角色生成的，那么该节点需要将该请求发送给执行管理员角色的节点，而执行管理员角色的节点，就可以接收来自该节点发送的待验证的请求，该节点也就可以视为请求生成设备。当然，请求生成设备也可以是外部的设备临时与联盟链通信而提出的请求，不限于由联盟链内的节点生成，因此，此处不应视为对本申请的限定。

在子联盟链验证系统的执行管理员角色的节点获取到请求后，可以将该请求共享给属于同一联盟链验证系统的另外的子联盟链验证系统的执行管理员角色的节点，在联盟链验证系统内所有的执行管理员角色的节点达成同意对该请求进行处理的共识后，即可对该请求进行处理。需要说明的是，此处联盟链验证系统内所有的执行管理员角色的节点达成同意对该请求进行处理的共识，可以是全部执行管理员角色的节点一致同意，也可以是部分同意，以实际需要为准，此处不作限定。

请参阅图2，以下将以图2中的联盟链验证系统10为例，对其举例进行说明。

假设1：节点B5获取到的请求为：一个包含转账信息的验证请求。那么节点B5可以将该请求通过临时建立的通道共享给联盟链验证系统内的另一子联盟链验证系统内的节点A9，共同决策是否处理该请求。本例中以同意处理该请求为例，那么节点B5和节点A9都会对该请求进行处理。

假设2：节点A9获取到的请求为：一个访问联盟链内的数据库的请求。同样的，节点A9可以将该请求通过临时建立的通道共享给联盟链验证系统内的另一子联盟链验证系统内的节点B5，共同决策是否处理该请求。本例中以同意处理该请求为例，那么节点B5和节点A9都会对该请求进行处理。

通过这样的方式，待验证的请求可以在联盟链验证系统内的任一节点提出，而提出的待验证的请求都会统一由执行管理员角色的节点先行处理。而这样的方式，在验证的准确性上就可以得到把控，以及，联盟链验证系统处理的效率能够提高不少。而通过建立临时通道的方式将请求在执行管理员角色的节点之间共享，可以提高验证请求的效率。

在获取待验证的请求后，执行管理员角色的节点可以执行步骤S120。

步骤S120：从所述记账节点中确定出用于处理所述请求的目标记账节点，以及获取所述目标记账节点的信任度，其中，所述记账节点的信任度中有至少两个信任度不同。

在本实施例中，执行管理员角色的节点可以对该请求进行处理，确定出该请求的类型。例如，可以根据该请求所携带的标记，识别标记而确定该请求的类型；也可以根据请求发起所使用的通道，确定出该请求的类型，此处不作具体限定。

确定出该请求的类型后，执行管理员角色的节点可以获取每个记账节点的处理请求的类型权限，从记账节点中确定出对该类型的请求有处理权限的目标记账节点。

继续前述假设1：节点B5确定出该包含转账信息的验证请求的类型为交易类型。例如，子联盟链验证系统110的记账节点12中：节点B1用于处理转账、存款、取款等信息；节点B3用于验证访问者的身份信息；节点B4用于处理线上转账的信息，其余的记账节点12用于处理数据查询和身份验证等业务。那么遍历节点B5所在的子联盟链验证系统110的记账节点12，对该交易类型的请求有处理权限的记账节点12为节点B1、节点B3、节点B4。而节点A9确定出该包含转账信息的验证请求的类型为交易类型，子联盟链验证系统120的记账节点12中：节点B12、节点B13、节点B14用于处理转账、存取款等业务，而其余记账节点12多数用于数据查询。那么，遍历其所在的子联盟链验证系统120的记账节点12，对该交易类型的请求有处理权限的记账节点为节点B12、节点B13、节点B14。

继续前述假设2：节点B5确定出该访问联盟链内的数据库的请求的类型为访问类型。子联盟链验证系统110的记账节点12中：节点B7用于验证访问信息的合法性；节点B8用于验证访问信息的合法性以及验证访问者的访问权限，其余的记账节点12用于处理其他类型的业务。那么，遍历其所在的子联盟链验证系统110的记账节点12，对该访问类型的请求有处理权限的记账节点为节点B7和节点B8。而节点A9确定出该访问联盟链内的数据库的请求的类型为访问类型。子联盟链验证系统120的记账节点12中：节点B11用于验证访问信息的合法性以及验证访问者的访问权限；节点B12用于验证访问信息的合法性，其余的记账节点12用于处理其他类型的业务。那么，遍历其所在的子联盟链验证系统120的记账节点，对该访问类型的请求有处理权限的记账节点为节点B11和节点B12。

通过对不同类型的请求，从联盟链验证系统内的记账节点中确定出对该类型请求有处理权限的目标记账节点，可以由处理不同类型的请求的记账节点处理其有权限处理的请求，使得请求的验证更具灵活性和准确性。

当然，除了通过请求的类型确定出目标记账节点的方式之外，还可以通过请求发起的通道，确定与该通道对应的地址，以地址确定出目标记账节点。这样就是通过对应关系确定目标记账节点，确定的目标记账节点相对固定，此处不作限定。

在确定出对待验证的请求有处理权限的目标记账节点后，执行管理员角色的节点可以确定出每个目标记账节点的信任度。其中，信任度可以理解为目标记账节点的投票结果对总的投票结果的一种影响的大小，例如权重值、投票的分数上限等。

在本实施例中，目标记账节点可以预设有多个信任度。执行管理员角色的节点可以从目标记账节点预设的多个信任度中确定出与待验证的请求类型对应的一个信任度，确定出的这个信任度就是目标记账节点的信任度。

从目标记账节点预设的多个信任度中确定出目标记账节点的信任度的方式，确定出的目标记账节点的信任度具有稳定性高的特点。

在本实施例中，执行管理员角色的节点可以获取目标记账节点的处理与待验证的请求类型一致的请求的历史数量，根据确定出来的历史数量，视其数量的大小，确定信任度的高低。通常情况下，可以是历史数量越大，信任度越高。例如，与历史数量成正比，或者预先设置数值范围对应信任度，历史数量与哪个范围对应则确定为哪个信任度。

通过这样的方式确定记账节点的信任度，可以使得处理过该类型请求的数量越多的目标记账节点，具有更高的信任度，相当于处理该类型请求的经验越丰富，就具有更高的话语权。这样的方式使得请求的验证具有更高的准确性。

继续前述假设1：节点B5获取节点B1处理交易类型的请求的历史数量为511，节点B3处理交易类型的请求的历史数量为2019，节点B4处理交易类型的请求的历史数量为58。那么，节点B5可以根据这些历史数量所在的范围，确定出节点B1的信任度为2分、节点B3的信任度为3分、节点B4的信任度为1分。节点A9获取节点B12处理交易类型的请求的历史数量为5022，节点B13处理交易类型的请求的历史数量为23865，节点B14处理交易类型的请求的历史数量为8023。那么，节点A9可以根据这些历史数量所在的范围，确定出节点B12的信任度为0.2的权重值、节点B13的信任度为0.5的权重值、节点B14的信任度为0.3的权重值。

继续前述假设2：节点B5获取节点B7处理访问类型的请求的历史数量为4396，节点B8处理访问类型的请求的历史数量为15682。那么，节点B5可以根据这些历史数量所在的范围，确定出节点B7的信任度为3分，节点B8的信任度为5分。而节点A9获取节点B11处理访问类型的请求的历史数量为24031，节点B12处理访问类型的请求的历史数量为16021。那么，节点A9可以根据这些历史数量的比例，确定出节点B11的信任度为0.6的权重值，节点B12的信任度为0.4的权重值。

在确定出目标记账节点和目标记账节点对应的信任度后，执行管理员角色的节点可以执行步骤S130。

步骤S130：将所述目标记账节点的信任度发送给所述共识节点，使得所述共识节点根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

在本实施例中，执行管理员角色的节点可以将目标记账节点的信任度发送给联盟链验证系统内的共识节点11。需要说明的是，执行管理员角色的节点将目标记账节点的信任度发送给共识节点11中的一部分共识节点11就可以了，而接收到目标记账节点的信任度的共识节点11可以将接收到的信息共享给联盟链验证系统内的所有共识节点11，以使共识节点11就处理待验证的请求的目标记账节点和目标记账节点的信任度达成共识。

在共识节点有可以接收的目标记账节点的信任度时，可以执行步骤S210。

步骤S210：接收所述联盟链内其它节点发送的目标记账节点的信任度，其中，所述其它节点用于从所述记账节点中确定出目标记账节点，以及所述其它节点还用于获取所述目标记账节点的信任度，其中，所述目标记账节点用于处理待验证的请求，所述记账节点的信任度中有至少两个信任度不同。

在本实施例中，共识节点可以接收联盟链验证系统内其它节点发送的目标记账节点的信任度。此处的其他节点，可以是联盟链验证系统内执行管理员角色的任一节点，也可以是联盟链验证系统内其他共识节点11。

在共识节点接收到联盟链验证系统内其它节点发送的目标记账节点的信任度后，可以执行步骤S220。

步骤S220：根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

在本实施例中，共识节点11可以根据目标记账节点的信任度，以及根据目标记账节点对待验证的请求的验证结果，确定该请求是否通过验证。

具体地，请参阅图5，图5示出了本实施例提供的请求的验证方法的时序图。

共识节点11可以将待验证的请求发送给对应的目标记账节点。在本实施例中，共识节点11可以视为一个整体，向所有目标记账节点发送待验证的请求。具体到每一个共识节点11的动作，那么就可以是：每个共识节点11从接收到的目标记账节点的信任度中，确定是否有与自己建立通信连接的记账节点，若有，则向该记账节点发送该请求，若无，就无需发送。

继续前述假设1：子联盟链验证系统110中所有共识节点接收到的节点B1的信任度为2分、节点B3的信任度为3分、节点B4的信任度为1分。那么节点A1、节点A2中的一个可以将该交易请求发送给节点B1，并获取节点B1返回的对该交易请求的验证结果；而节点A3可以将该交易请求分别发送给节点B3和节点B4，并对应获取节点B3和节点B4返回的对该交易请求的验证结果。

而子联盟链验证系统120中所有共识节点接收到的节点B12的信任度为0.2的权重值、节点B13的信任度为0.5的权重值、节点B14的信任度为0.3的权重值。那么，节点A9可以将该交易请求分别发送给节点B12和节点B13，并对应获取节点B12和节点B13返回的对该交易请求的验证结果；节点A8可以将该交易请求发送给节点B14，并并获取节点B14返回的对该交易请求的验证结果。

继续前述假设2：子联盟链验证系统110中所有共识节点接收到的节点B7的信任度为3分，节点B8的信任度为5分。那么，节点A1可以将该数据查询请求发送给节点B7，并获取节点B7返回的对该数据查询请求的验证结果，节点A6可以将该数据查询请求发送给节点B8，并获取节点B8返回的对该数据查询请求的验证结果。

而子联盟链验证系统120中所有共识节点接收到的节点B11的信任度为0.6的权重值，节点B12的信任度为0.4的权重值。那么，节点A7可以将该数据查询请求发送给节点B11，并获取节点B11返回的对该数据查询请求的验证结果；节点A9可以将该数据查询请求发送给节点B12，并获取节点B12返回的对该数据查询请求的验证结果。

而记账节点在接收到待验证的请求时，可以对该请求进行验证，并将验证结果返回给发送该请求的共识节点。

在接收到目标记账节点返回的对该请求的验证结果后，共识节点可以获取验证结果中包含的验证分数。验证分数可以是分数，例如通过为1，不通过为0。

共识节点可以将目标记账节点的验证分数和该目标记账节点的信任度相乘，获得每个目标记账节点的乘积值。共识节点还可以将每个目标记账节点的乘积值相加，获得一个对该请求的验证总分数。将验证总分数与对应执行管理员角色的节点基于该请求的类型而确定出的预设的分数相比较，以判断该请求是否通过验证。

继续前述假设1：例如，节点A1接收到节点B1返回的对该交易请求的验证结果，其中的验证分数为1，那么节点B1的乘积值为2；而节点A3接收到的节点B3返回的对该交易请求的验证结果，其中的验证分数为1，那么节点B3的乘积值为3；以及，接收到节点B4返回的对该交易请求的验证结果，其中的验证分数为0，那么节点B4的乘积值为0。加总后得到验证总分数为5分，而预设分数为4分。因此，该交易请求在子联盟链验证系统110中通过验证。

而节点A9接收到节点B12返回的对该交易请求的验证结果，其中的验证分数为1，那么节点B12的乘积值为0.2；以及，接收到节点B13返回的对该交易请求的验证结果，其中的验证分数为1，那么节点B13的乘积值为0.5；节点A8接收到节点B14返回的对该交易请求的验证结果，其中的验证分数为0，那么节点B14的乘积值为0。加总后得到验证总分数为0.7分，而预设分数为0.7分，因此，该交易请求在子联盟链验证系统120中通过验证。

继续前述假设2：例如，节点A1接收到节点B7返回的对该交易请求的验证结果，其中的验证分数为0，那么节点B1的乘积值为0；而节点A6接收到的节点B8返回的对该交易请求的验证结果，其中的验证分数为1，那么节点B3的乘积值为5。加总后得到验证总分数为5分，而预设分数为8分。因此，该数据查询请求在子联盟链验证系统110中不通过验证。

而节点A7接收到节点B11返回的对该交易请求的验证结果，其中的验证分数为1，那么节点B11的乘积值为0.6；节点A9接收到节点B12返回的对该交易请求的验证结果，其中的验证分数为1，那么节点B12的乘积值为0.4。加总后得到验证总分数为1.0分，而预设分数为1.0分，因此，该交易请求在子联盟链验证系统120中通过验证。

在待验证的请求通过验证后，共识节点可以将该请求通过验证的消息发送给联盟链验证系统内所有的节点，使该联盟链验证系统内所有的节点基于此消息执行后续的工作。当然，若联盟链验证系统包括多个子联盟链验证系统，由于各个子联盟链验证系统相对独立，那么各个子联盟链验证系统可以根据系统内的节点对于该请求的验证结果，执行相应的动作。若请求未通过验证，那么联盟链验证系统就可以驳回该请求。

需要说明的是，本实施例中举例所描述的获取目标记账节点的验证结果的过程，是获取了每一个目标记账节点的验证结果的。但在实际的情况中，由于节点数量众多，数据量较大，传输速度不一，因此，共识节点可以在接收结果的过程中进行加总，在验证总分数达到预设分数时，就可以不必再接收和计算还未返回验证结果的目标结账节点返回的验证结果了，而是可以直接判定该请求通过验证，以提高验证请求的效率。因此，这些方式都在本申请的保护范围内。

另外，共识节点获取目标记账节点的验证总分数时，可以由其中的一部分甚至个别共识节点进行统计，统计的分数达到预设分数时即确定请求通过验证，并共享给所有共识节点；或者，统计完成后将结果共享给所有共识节点。这样能够节约计算资源，当然，为了验证结果的准确性，可以同时由多个共识节点进行统计，并验证统计的结果是否在误差范围内一致。这样既可以节约资源又能够保证统计的准确性。

当然，本申请提供的请求的验证方法，在共识节点对请求进行验证时，所遵循的由执行管理员角色的节点确定出的验证方式，还可以为验证目标记账节点中的部分特定目标记账节点的投票情况，例如，需要特定目标记账节点全部通过对该节点的验证，且所有目标记账节点的投票情况的通过率需要达到预设的数值。通过这样的方式，使得请求的验证能够随使用者的需求而变化和制定，增加联盟链验证系统的应用的广泛性。

以下，将结合图2，以几个实际的例子进行说明，以利于更好地理解本申请实施例提供的请求的验证方法。

假设3：节点B1以用户角色提出一个正常的交易请求，那么节点B5确定出该交易类型的请求的验证规则为：目标记账节点为节点B7和节点B15，节点B7的信任度为0.5，节点B15的信任度为0.5，预设分数为1；并将该验证规则传递给所有共识节点，即节点A1-A9，节点A1-A9就根据该验证规则，验证节点B7和节点B15的对请求的验证结果，在节点B7和节点B15都通过该请求的验证时，确定请求通过验证，并将数据打包成区块进行上链。若验证不通过，驳回该请求。

假设4：节点B2以用户角色提出一个正常的访问请求，那么节点B5确定出该访问类型的请求的验证规则为：目标记账节点为节点B3、节点B4、节点B6、节点B11和节点B12；节点B3、节点B4、节点B6、节点B11和节点B12的信任度分别为0.2、0.2、0.2、0.1和0.3，预设分数为0.9；并将该验证规则传递给节点A1-A9，节点A1-A9就根据该验证规则，验证节点B3、节点B4、节点B6、节点B11和节点B12的对请求的验证结果，在节点B3、节点B4和节点B6中至少两个节点通过验证，以及节点B11和节点B12都通过该请求的验证时，确定请求通过验证，并将数据打包成区块进行上链。若验证不通过，驳回该请求。

假设5：节点A9以管理员角色提出一个规则变更请求，那么，节点A9首先与节点B5建立通信，在经节点B5同意后，确定出请求对应的验证规则为：需要每个联盟链验证系统10中所有记账节点的验证中超过0.67的通过率。那么，节点A9将该验证规则传递给所有的记账节点：节点B1-B8，节点B11-B15。节点B1-B8每个节点的信任度为0.1，节点B11-B15的信任度分别为：0.02、0.1、0.04、0.01和0.03。在所有记账节点对该请求的验证通过率超过0.67时，所有共识节点，即节点A1-A9，将规则进行更新，所有记账节点，即节点B1-B8，节点B11-B15，将记录本次规则变更的数据打包成区块进行上链。若验证不通过，驳回该请求。

以上述几个具体的例子，可以很好地阐释本申请实施例提供的请求的验证方法的应用。在实际的应用过程中，验证规则可以是：需要每个子联盟链验证系统中各一个记账节点通过验证、可以是每个子联盟链验证系统中至少两个记账节点通过验证、也可以是每个子联盟链验证系统中记账节点的验证通过率超过一半或超过三分之二；当然，联盟链验证系统的所有记账节点至少存在两个记账节点的信任度不同，但是，可以是每个子联盟链验证系统中记账节点信任度相同，但是不同子联盟链验证系统中记账节点的信任度有所不同。这些验证规则，可以是预置的，预置的验证规则具有稳定和可信的特点；当然，实际情况中也可能存在一些验证规则可以根据实际的情况而新生成，新生成的验证规则也需要经过验证才能够达成共识。另外，预知的验证规则中预设分数的具体数值，可以根据实际需要而预先设定，以更好地应用本方法为准，例如、0.51、0.67、0.33等常用的预设分数，此处不作为限定，这些情况都应当在本申请实施例提供的请求的验证方法的保护范围内。

请参阅图6，本申请实施例还提供一种应用于联盟链包括的记账节点和共识节点中的任一节点中的请求的验证装置210，包括：

获取模块211，用于获取待验证的请求；处理模块212，用于从所述记账节点中确定出用于处理所述请求的目标记账节点，以及获取所述目标记账节点的信任度，其中，所述记账节点的信任度中有至少两个信任度不同；发送模块213，用于将所述目标记账节点的信任度发送给所述共识节点，使得所述共识节点根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

在本实施例中，所述处理模块212，还用于确定出所述请求的类型；从所述记账节点中确定出对所述类型有处理权限的所述目标记账节点。

在本实施例中，所述处理模块212，还用于从所述目标记账节点预设的多个信任度中选择出与所述请求的类型对应的信任度；或根据所述请求，生成所述目标记账节点的信任度。

在本实施例中，所述处理模块212，还用于获取所述目标记账节点处理与所述请求的类型相同的历史请求的数量；根据所述数量，生成所述目标记账节点的信任度，其中，所述数量越多，所述目标记账节点的信任度越高。

在本实施例中，所述获取模块211，还用于接收请求生成设备发送的所述请求；或基于响应用户的操作生成所述请求。

请参阅图7，联盟链包括共识节点和记账节点，本申请实施例还提供一种应用于所述共识节点中的请求的验证装置220，包括：

接收模块221，用于接收所述联盟链内其它节点发送的目标记账节点的信任度，其中，所述其它节点用于从所述记账节点中确定出目标记账节点，以及所述其它节点还用于获取所述目标记账节点的信任度，其中，所述目标记账节点用于处理待验证的请求，所述记账节点的信任度中有至少两个信任度不同；验证模块222，用于根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

在本实施例中，所述目标记账节点对所述请求的验证结果中包含验证分数，所述验证模块222，还用于获取所述目标记账节点的验证分数；获取所述目标记账节点的信任度和所述目标记账节点的验证分数的乘积值；通过将所有所述乘积值进行加总，获取所述请求的验证总分数；通过将所述验证总分数与预设分数比较而确定所述请求是否通过验证。

综上所述，本申请实施例提供了一种请求的验证方法、装置、存储介质及联盟链验证系统。通过在需要对请求进行验证时，确定出处理该请求的目标记账节点，这样可以针对不同的请求确定更合适对该请求打分的记账节点，提高验证请求的灵活性和准确性；而对应确定出目标记账节点的信任度，信任度可以是打分的权重值或者投票的分数等等，不同的目标记账节点可以赋予不同的信任度，可以使得记账节点的投票趋于灵活和精准，进一步提高验证请求的灵活性和准确性。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (11)

1.一种请求的验证方法，其特征在于，所述方法应用于所述联盟链包括的记账节点和共识节点中的任一节点，所述方法包括：

获取待验证的请求；

从所述记账节点中确定出用于处理所述请求的目标记账节点，以及获取所述目标记账节点的信任度，其中，所述记账节点的信任度中有至少两个信任度不同；

将所述目标记账节点的信任度发送给所述共识节点，使得所述共识节点根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

2.根据权利要求1所述的请求的验证方法，其特征在于，从所述记账节点中确定出用于处理所述请求的目标记账节点，包括：

确定出所述请求的类型；

从所述记账节点中确定出对所述类型有处理权限的所述目标记账节点。

3.根据权利要求1所述的请求的验证方法，其特征在于，获取所述目标记账节点的信任度，包括：

从所述目标记账节点预设的多个信任度中选择出与所述请求的类型对应的信任度；或

根据所述请求，生成所述目标记账节点的信任度。

4.根据权利要求3所述的请求的验证方法，其特征在于，根据所述请求，生成所述目标记账节点的信任度，包括：

获取所述目标记账节点处理与所述请求的类型相同的历史请求的数量；

根据所述数量，生成所述目标记账节点的信任度，其中，所述数量越多，所述目标记账节点的信任度越高。

5.根据权利要求1-4任一所述的请求的验证方法，其特征在于，获取待验证的请求，包括：

接收请求生成设备发送的所述请求；或

基于响应用户的操作生成所述请求。

6.一种请求的验证方法，其特征在于，联盟链包括共识节点和记账节点，所述方法应用于所述共识节点中，所述方法包括：

接收所述联盟链内其它节点发送的目标记账节点的信任度，其中，所述其它节点用于从所述记账节点中确定出目标记账节点，以及所述其它节点还用于获取所述目标记账节点的信任度，其中，所述目标记账节点用于处理待验证的请求，所述记账节点的信任度中有至少两个信任度不同；

根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

7.根据权利要求6所述的请求的验证方法，其特征在于，所述目标记账节点对所述请求的验证结果中包含验证分数，根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过，包括：

获取所述目标记账节点的验证分数；

获取所述目标记账节点的信任度和所述目标记账节点的验证分数的乘积值；

通过将所有所述乘积值进行加总，获取所述请求的验证总分数；

通过将所述验证总分数与预设分数比较而确定所述请求是否通过验证。

8.一种请求的验证装置，其特征在于，所述装置装载于所述联盟链包括的记账节点和共识节点中的任一节点中，所述装置包括：

获取模块，用于获取待验证的请求；

处理模块，用于从所述记账节点中确定出用于处理所述请求的目标记账节点，以及获取所述目标记账节点的信任度，其中，所述记账节点的信任度中有至少两个信任度不同；

发送模块，用于将所述目标记账节点的信任度发送给所述共识节点，使得所述共识节点根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

9.一种请求的验证装置，其特征在于，联盟链包括共识节点和记账节点，所述装置装载于所述共识节点中，所述装置包括：

接收模块，用于接收所述联盟链内其它节点发送的目标记账节点的信任度，其中，所述其它节点用于从所述记账节点中确定出目标记账节点，以及所述其它节点还用于获取所述目标记账节点的信任度，其中，所述目标记账节点用于处理待验证的请求，所述记账节点的信任度中有至少两个信任度不同；

验证模块，用于根据所述目标记账节点对所述请求的验证结果，以及根据所述目标记账节点的信任度，确定所述请求是否验证通过。

10.一种具有计算机可执行的非易失程序代码的计算机可读储存介质，用于存储程序代码，其特征在于，所述程序代码在被计算机读取并运行时，执行权利要求1-7中任一所述的请求的验证方法。

11.一种联盟链验证系统，其特征在于，包括：共识节点和记账节点，

所述共识节点和记账节点中的任一节点用于执行如权利要求1-5任一所述的请求的验证方法；

以及，所述共识节点，还用于执行如权利要求6或7所述的请求验证方法。