CN114547704A - 基于分布式账本的数据处理方法以及装置 - Google Patents

Abstract

本说明书实施例提供基于分布式账本的数据处理方法，包括：根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与目标成员节点匹配的目标成员角色，其中，目标成员节点为分布式账本中的至少两个成员节点之一，基于目标成员角色对应的角色属性值，确定目标成员节点对应的目标角色属性值，将目标角色属性值添加至目标成员节点。通过为分布式账本中的各成员节点添加角色属性，以及目标角色属性值，以实现为各成员节点进行角色添加，使得分布式账本中各成员节点可以基于其自身的属性信息，拥有不同的成员角色，后续可根据成员节点的角色进行权限控制和背书验证，有利于提高分布式账本的可用性和安全性。

Description

基于分布式账本的数据处理方法以及装置

技术领域

本说明书实施例涉及计算机技术领域，特别涉及基于分布式账本的数据处理方法。

背景技术

Hyperledger Fabric是由Linux基金会发起创建的开源的企业级许可分布式账本技术平台，专为在企业环境中使用而设计。Fabric具有高度模块化和可配置的架构，可为各行各业的业务提供创新性、多样性和优化，其中包括银行、金融、保险、医疗保健、人力资源、供应链甚至数字音乐分发等。

基于Hyperledger Fabric开发的分布式账本都要面临配置修改（组织加入，通道策略修改等）、安装链码等需要各个组织进行协同才能进行操作的问题。但对于一个联盟链而言，链中的多个成员节点可能并不是完全平等的，即不同成员节点的管理权限不同。这种情况下，当需要进行配置修改时，这些配置修改的过程若没有一个帮助协同操作的方案时，会导致成员节点间的信息交互需要花费更多时间，导致错误发生的概率也会增加。因此，亟需一种有效的方法以解决此类问题。

发明内容

有鉴于此，本说明书实施例提供了基于分布式账本的数据处理方法。本说明书一个或者多个实施例同时涉及基于分布式账本的数据处理装置，一种计算设备，一种计算机可读存储介质以及一种计算机程序，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种基于分布式账本的数据处理方法，包括：

根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与所述目标成员节点匹配的目标成员角色，其中，所述目标成员节点为所述分布式账本中的至少两个成员节点之一；

基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值；

将所述目标角色属性值添加至所述目标成员节点。

可选地，所述将所述目标角色属性值添加至所述目标成员节点，包括：

将所述目标角色属性值作为所述目标成员节点的键值，添加至所述分布式账本的配置信息存储结构，其中，所述至少两个成员节点的属性信息以键值对的形式存储在所述配置信息存储结构中。

可选地，所述基于分布式账本的数据处理方法，还包括：

创建成员角色，并确定所述成员角色对应的角色属性值。

可选地，所述基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值，包括：

对至少两个目标成员角色分别对应的角色属性值进行求和处理，生成所述目标成员节点对应的目标角色属性值。

可选地，所述将所述目标角色属性值添加至所述目标成员节点，包括：

将所述目标角色属性值转化为目标数据类型，并将转化结果作为所述目标成员节点的键值，添加至所述分布式账本的配置信息存储结构，其中，所述至少两个成员节点的属性信息以键值对的形式存储在所述配置信息存储结构中。

可选地，所述基于分布式账本的数据处理方法，还包括：

根据所述预设的成员角色，生成所述分布式账本的链码对应的至少一个信息验证策略。

可选地，所述基于分布式账本的数据处理方法，还包括：

接收针对所述分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据；

确定所述待修改数据对应的目标信息验证策略，并基于所述目标信息验证策略包含的成员角色的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点；

向所述投票成员节点发送所述待修改数据的投票请求；

接收所述投票成员节点返回的投票结果，并根据所述目标信息验证策略对所述投票结果进行验证；

在根据验证结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

可选地，所述基于分布式账本的数据处理方法，还包括：

接收针对目标项目提交的交易处理请求；

确定所述分布式账本中与所述目标项目相关的第一项目成员节点，通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的交易处理逻辑，生成对应的交易处理结果。

可选地，所述基于分布式账本的数据处理方法，还包括：

确定所述目标项目对应的目标信息验证策略，并对所述目标信息验证策略进行解析；

根据解析结果确定所述目标信息验证策略是否包含角色属性值；

若是，则根据所述角色属性值、所述目标信息验证策略及所述分布式账本中各项目成员节点分别对应的目标角色属性值，确定满足预设条件的第二项目成员节点；

基于所述第二项目成员节点的目标信息验证子策略，生成所述目标信息验证策略的子策略集合；

向所述第二项目成员节点发送所述交易处理结果的签名请求，并利用所述目标信息验证子策略对所述第二项目成员节点的签名结果进行验证；

根据所述子策略集合中各目标信息验证子策略对应的验证结果，确定所述交易处理结果的目标签名结果。

可选地，所述基于分布式账本的数据处理方法，还包括：

在确定所述交易处理结果的目标签名结果为签名通过的第二项目成员节点的数量，大于等于预设数量阈值的情况下，则通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的背书逻辑，对所述交易处理结果进行背书。

可选地，所述基于分布式账本的数据处理方法，还包括：

获取所述配置信息存储结构对应的策略存储结构；

根据所述配置信息存储结构与所述策略存储结构中，成员节点的位置对应关系，将所述配置信息结构中存储的所述目标成员节点对应的目标角色属性值，添加至所述策略存储结构的对应位置。

根据本说明书实施例的第二方面，提供了一种基于分布式账本的数据处理装置，包括：

第一确定模块，被配置为根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与所述目标成员节点匹配的目标成员角色，其中，所述目标成员节点为所述分布式账本中的至少两个成员节点之一；

第二确定模块，被配置为基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值；

添加模块，被配置为将所述目标角色属性值添加至所述目标成员节点。

根据本说明书实施例的第三方面，提供了另一种基于分布式账本的数据处理方法，包括：

接收针对分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据；

确定所述待修改数据对应的数据修改策略，并基于所述数据修改策略包含的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点；

向所述投票成员节点发送所述待修改数据的投票请求；

接收所述投票成员节点返回的投票结果，在根据所述投票结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

根据本说明书实施例的第四方面，提供了另一种基于分布式账本的数据处理装置，包括：

接收模块，被配置为接收针对分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据；

确定模块，被配置为确定所述待修改数据对应的数据修改策略，并基于所述数据修改策略包含的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点；

发送模块，被配置为向所述投票成员节点发送所述待修改数据的投票请求；

修改模块，被配置为接收所述投票成员节点返回的投票结果，在根据所述投票结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

根据本说明书实施例的第五方面，提供了一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令实现任意一项所述基于分布式账本的数据处理方法的步骤。

根据本说明书实施例的第六方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现任意一项所述基于分布式账本的数据处理方法的步骤。

根据本说明书实施例的第七方面，提供了一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述基于分布式账本的数据处理方法的步骤。

本说明书一个实施例通过根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与所述目标成员节点匹配的目标成员角色，其中，所述目标成员节点为所述分布式账本中的至少两个成员节点之一，基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值，将所述目标角色属性值添加至所述目标成员节点。

本说明书实施例通过为分布式账本中的各成员节点添加角色属性，以及为各成员节点添加角色属性对应的目标角色属性值，以实现为各成员节点进行角色添加，使得分布式账本中各成员节点可以基于其自身的属性信息，拥有不同的成员角色，后续可根据成员节点的角色进行权限控制和背书验证，有利于提高分布式账本的可用性和安全性。

附图说明

图1是本说明书一个实施例提供的一种基于分布式账本的数据处理方法的流程图；

图2是本说明书一个实施例提供的一种基于分布式账本的数据处理方法的处理过程流程图；

图3是本说明书一个实施例提供的一种基于分布式账本的数据处理装置的结构示意图；

图4是本说明书一个实施例提供的另一种基于分布式账本的数据处理方法的流程图；

图5是本说明书一个实施例提供的另一种基于分布式账本的数据处理装置的结构示意图；

图6是本说明书一个实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本说明书中，提供了基于分布式账本的数据处理方法，本说明书同时涉及基于分布式账本的数据处理装置，一种计算设备，一种计算机可读存储介质，以及一种计算机程序，在下面的实施例中逐一进行详细说明。

基于角色的权限控制(RBAC)是软件安全的基本要求。对于一个联盟链而言，链中的多个成员在真实世界中并不是完全平等的，需要根据成员角色对不同成员的相应功能进行权限控制，在联盟链中尤其如此。

Hyperledger Fabric是由Linux基金会创建和管理，旨在创建企业级、开源的分布式账本框架和代码库，本说明书实施例通过为Hyperledger Fabric上的成员节点增加角色属性，并实现基于成员角色的验证策略、背书策略、权限检查和访问控制，满足联盟链实际应用的灵活管理控制以及基于角色权限的基本安全要求。

图1示出了根据本说明书一个实施例提供的一种基于分布式账本的数据处理方法的流程图，具体包括以下步骤。

步骤102，根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与所述目标成员节点匹配的目标成员角色，其中，所述目标成员节点为所述分布式账本中的至少两个成员节点之一。

具体的，分布式账本可以是区块链，具体可以是联盟链，且该分布式账本基于Hyperledger Fabric构建。分布式账本中的至少两个成员节点，即加入同一通道的成员节点；预设的成员角色，即预先定义或创建的成员角色；目标成员角色，为预设的成员角色中的一个或至少两个。

由于区块链一般被划分为三种类型：公有链(Public Block chain)，私有链(Private Block chain)和联盟链(Consortium Block chain)。此外，还可以有上述多种类型的结合，比如私有链与联盟链的结合、联盟链与公有链的结合等。

其中，去中心化程度最高的是公有链，其次是私有链，联盟链则介于公有链以及私有链之间，可以实现“部分去中心化”。联盟链中各个成员节点通常有与之对应的实体机构或者组织；成员节点通过授权加入网络并组成利益相关联盟，共同维护区块链的运行。

在区块链中，成员节点是逻辑上的通信实体；不同类型的多个区块链节点可以运行在同一个物理服务器上，也可以运行在不同的物理服务器上。

对于联盟链而言，基于Hyperledger Fabric的区块链***是联盟链***的一种实现方式。

在基于Hyperledger Fabric的区块链***中，通常可以基于组织对区块链节点进行区分。也即，基于Hyperledger Fabric的区块链***的参与方可以是组织。

在实际应用中，上述组织可以是现实世界中的一个公司、一个企业或者一个协会。

基于Hyperledger Fabric的区块链***的数据存储结构，通常可以被设计成多账本体系。为了对不同的分布式账本进行数据隔离，可以在逻辑上将基于HyperledgerFabric的区块链***划分为不同的通道(channel)。

其中，上述通道可以由区块链账本、链码、组织和排序服务节点定义；每个通道中都可以有一套完全独立的分布式账本，并且可以有一套完全独立的链码；不同的通道可以共用同一个排序服务节点；同一个组织可以通过该组织中的不同的Peer节点，加入不同的通道；每个交易都是在某一个通道中被独立执行的。

因此，在基于Hyperledger Fabric的区块链***中，可以将一个通道视为一条区块链。也即，基于Hyperledger Fabric的区块链***可以包括多条区块链。

需要说明的是，加入到同一个通道中的Peer节点可以维护相同的区块链账本，并且不能访问由加入到其他通道中的Peer节点维护的区块链账本。同一个Peer节点可以加入不同的通道；该Peer节点可以维护与各个通道分别对应的区块链账本，但是，该Peer节点维护的多个区块链账户之间数据隔离。

当加入通道的成员节点访问该通道内的分布式账本时，可利用Fabric进行访问控制，而Fabric的访问控制、配置更新权限验证以及交易有效性验证都使用一个名为“策略（Policy）”的接口，用来评估数据的签名者是否满足预定义的规则，包括访问请求、交易数据、更新账本配置的配置更新交易等。

Fabric的策略(Policy)有两种实现，分别是签名规则策略(Signature Policy)和隐式规则策略(Implicit Meta Policy)。

其中，签名规则是指定MSP Principals（Fabric中的加密身份概念）的评估规则组合，支持AND、OR、OutOf规则。例如“OR('Org1.member'，'Org2.member')”表示需要组织Org1和Org2中任何一个成员签名；“OutOf(2,'Org1.admin','Org2.admin','Org3.admin')”表示Org1、Org2、org3中至少2个组织的管理员签名。

隐式规则策略并不直接进行签名检查，而是通过引用其它子策略来实现，通过检查引用的子策略的评估结果进行约束，支持ANY、ALL和MAJORITY三种规则。例如“MAJORITYWriters”表示过半数的子策略Writers签名，“ALL Admins”表示所有子策略Admins签名。隐式规则策略与账本配置树上下文有关，账本配置树中定义了成员节点的MSP信息，通过隐私规则策略就可以实现如“要求联盟成员过半数的管理员签名”这类规则。

另外，Fabric的策略可应用于链码签名背书（智能合约交易有效性校验）、访问控制、配置更新。

关于链码，链码（Fabric称智能合约为链码），每个链码都有背书策略，背书策略指定了通道上的一组Peer节点必须执行链码，并且为执行结果进行背书，以此证明交易是有效的。这些背书策略指定了必须为交易提案进行背书的组织。

关于访问控制，Fabric使用权限控制列表（ACLs）通过给资源关联的策略（Policy）来管理资源的访问权限。

关于配置更新，Fabric的关键配置都存储在账本上，以一个树状数据结构展现。树上的每个节点和值都有一个“mod_policy（修改策略）”指定修改该节点/值需要满足的验证策略。

目前，由于联盟链的中的成员节点本身没有角色权限控制，但在实际应用中，需要控制只有指定权限的组织才可以访问区块链的相应资源，例如：“只有联盟指定的拥有KYC资质的成员才能上传证书”、“只有联盟指定的运维组织才能安装部署智能合约”、“监管机构在紧急状况下可以强制冻结（停用）智能合约”。

另外，在有新成员节点加入通道时，需要修改该通道的链码（区块链的智能合约）中的所有背书策略。如果有一个新成员加入联盟链，并且该成员需要参与联盟链共识流程，那么就需要将该联盟链中已经安装的智能合约全部更新，这在实际应用中是无法接受的。

为解决这些问题，本说明书实施例给Fabric的成员节点“角色(Role)”属性，联盟链（通道）中的成员是有角色的，可以根据角色执行访问控制和规则验证，并且智能合约（链码）的背书策略也可以配置为角色相关，例如联盟约定“核心成员”才参与共识流程，交易有效需要过半数的“核心成员”验证，这种情况下，具备核心成员这一角色属性的成员节点即可参与共识流程，或对交易进行有效验证，而无需约定具体有哪些成员节点参与共识流程或参与交易有效验证。

因此，通过给Fabric的策略(Policy)增加带角色属性的特性，可以实现当新成员加入或成员角色变更时，智能合约无需修改，新成员的权限会自动生效，从而大大提高Fabric的实际可用性和安全性。

基于此，在为分布式账本的成员节点添加角色信息之前，需先定义角色，具体即创建成员角色，并确定所述成员角色对应的角色属性值。

具体的，可先为分布式账本中的成员节点创建成员角色，并且各成员角色赋予对应的角色属性值，例如：创建的成员角色为无效成员、有效成员、主要成员、核心成员、操作员、管理员、审核员、开发者，其中无效成员的角色属性值为0、有效成员的角色属性值为1、主要成员的角色属性值为2、核心成员的角色属性值为4、操作员的角色属性值为8、管理员的角色属性值为16、审核员的角色属性值为32、开发者的角色属性值为64。

在创建成员角色之后，即可根据分布式账本中各成员节点的属性信息，确定创建的成员角色中，与各成员节点匹配的一个或至少两个目标成员角色。

其中，成员节点的属性信息，包括但不限于成员的服务性质、规模大小、成员在分布式账本中的职责权限等等，例如，若两个成员节点中，成员节点1别为A银行的总行，成员节点2为A银行的支行，那么与成员节点1匹配的目标成员角色则可以是有效成员、管理员、核心成员等，而与成员节点2匹配的目标成员角色则可以是有效成员；作为司法机构的成员节点，与其匹配的目标成员角色则可以是有效成员、审核员等。

本说明书实施例中，目标成员节点即为分布式账本中至少两个成员节点之一，且本说明书实施例以目标成员节点为例，对目标成员节点的角色添加过程进行说明，其他成员节点的角色添加过程，与目标成员节点的角色添加过程类似，参见目标成员节点的角色添加过程即可。

步骤104，基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值。

具体的，确定与目标成员节点匹配的目标成员角色后，即可基于目标成员角色对应的角色属性值，确定目标成员节点对应的目标角色属性值。

具体实施时，基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值，具体即对至少两个目标成员角色分别对应的角色属性值进行求和处理，生成所述目标成员节点对应的目标角色属性值。

具体的，在与目标成员节点匹配的目标成员角色为两个或两个以上的情况下，可将各个目标成员角色的角色属性值进行求和处理，并将求和结果作为该目标成员节点对应的目标角色属性值。其中，角色属性值定义可采用二进制位运算方式，二进制的每个位表示一种角色属性值；如果目标成员节点有多个目标成员角色，可以直接采用二进制或操作处理，即对各目标成员角色的二进制角色属性值进行或操作（等同于加法求和），得到该目标成员节点的目标角色属性值。

步骤106，将所述目标角色属性值添加至所述目标成员节点。

具体的，在确定目标成员节点的目标角色属性值后，即可将该目标角色属性值添加至该目标成员节点。

具体实施时，将所述目标角色属性值添加至所述目标成员节点，具体可将所述目标角色属性值作为所述目标成员节点的键值，添加至所述分布式账本的配置信息存储结构，其中，所述至少两个成员节点的属性信息以键值对的形式存储在所述配置信息存储结构中。

具体的，配置信息存储结构，即可以是账本配置树。

由于Fabric的关键配置数据都存储在账本上，以一个树状数据结构展现，因此，将该树状数据结构称为账本配置树，通道中的各成员节点的属性信息均以键值对，即key-value的形式存储在树节点中。

实际应用中，该账本配置树包含三层，第一层为应用节点（Application节点），第二层为群组节点（groups节点），第三层为各群组下的组织节点（organization节点），即成员节点。

因此，将目标角色属性值添加至目标成员节点，具体可将目标角色属性值作为目标成员节点的键值，添加至账本配置树中的该目标成员节点，也即，在账本配置树的成员节点（最底层节点）的键值value增加角色（role）属性对应的目标角色属性值。

另外，在账本配置树中为目标成员节点添加目标角色属性值之后，还可获取所述配置信息存储结构对应的策略存储结构，根据所述配置信息存储结构与所述策略存储结构中，成员节点的位置对应关系，将所述配置信息结构中存储的所述目标成员节点对应的目标角色属性值，添加至所述策略存储结构的对应位置。

具体的，策略存储结构，即可以是策略管理器树。

Fabric在解析账本配置信息时（启动或账本配置更新后），会根据账本配置树生成策略管理器（Policy Manager）树，该策略管理器树用于存储各成员节点的策略管理器，并且该策略管理器树中的节点与账本配置树中的节点存在一一对应关系。

因此，在账本配置树中为各成员节点添加角色之后，可根据账本配置树中各成员节点的角色添加结果，对应的为策略管理器树中的各节点添加角色。具体的，如果策略管理器树中的某个目标节点用于表征组织的策略管理器，则可将账本配置树中，为该组织对应的成员节点添加的目标角色属性值，添加至该目标节点。还可为该目标节点增加“withRole(boolean)”接口，用于判断其是否拥有指定的角色（pm.roleValue&role==role）。

本说明书实施例通过为分布式账本中的各成员节点添加角色属性，以及为各成员节点添加角色属性对应的目标角色属性值，以实现为各成员节点进行角色添加，使得分布式账本中各成员节点可以基于其自身的属性信息，拥有不同的成员角色，后续可根据成员节点的角色进行权限控制和背书验证，有利于提高分布式账本的可用性和安全性。

或者，将所述目标角色属性值添加至所述目标成员节点，具体可将所述目标角色属性值转化为目标数据类型，并将转化结果作为所述目标成员节点的键值，添加至所述分布式账本的配置信息存储结构，其中，所述至少两个成员节点的属性信息以键值对的形式存储在所述配置信息存储结构中。

具体的，目标数据类型即可以是二进制数据类型。

如前所述，无效成员的角色属性值为0、有效成员的角色属性值为1、主要成员的角色属性值为2、核心成员的角色属性值为4、操作员的角色属性值为8、管理员的角色属性值为16、审核员的角色属性值为32、开发者的角色属性值为64。

无效成员的二进制数据类型的角色属性值即为00000000、有效成员的二进制数据类型的角色属性值00000001，以此类推，开发者的二进制数据类型的角色属性值为01000000；若与目标成员节点匹配的目标成员角色为有效成员和管理员，则其目标角色属性值即为17，将其转化为二进制数据类型，则为00010001。

获得转化结果后，即可将转化结果作为目标成员节点的键值，添加至分布式账本的账本配置树。

以二进制数据类型存储各成员节点的目标角色属性值后，在后续的角色比对过程中，即可通过比对二进制数据的方式，确定目标成员节点是否具有目标成员角色。例如，若目标成员节点的目标角色属性值为00010001，核心成员的角色属性值为00000100，若需确定该目标成员节点是否具有核心成员这一角色，则可判断目标成员节点的目标角色属性值中的第6位的值是否等于1，若等于1，则可确定目标成员角色具有核心成员这一角色。

通过上述比对方式确定目标成员节点是否具有某一角色，有利于简化比对过程，并有利于提高比对结果的准确性。

具体实施时，在为各成员节点配置角色后，还可根据预先定义的成员角色生成链码，使得链码（智能合约）的信息验证策略也可以配置为角色相关，具体即根据所述预设的成员角色，生成所述分布式账本的链码对应的至少一个信息验证策略。

具体的，信息验证策略，包括但不限于背书策略、访问控制策略以及配置更新策略等。

在链码实例化时，为其设置信息验证策略，而该信息验证策略即可根据预先创建的成员角色生成，例如，该信息验证策略可以是：“核心成员”可参与共识流程、过半数的“核心成员”验证通过的交易有效等。

以所述信息验证策略为背书策略为例，在实例化链码（智能合约）时，可以引用隐式规则策略作为背书策略，例如：假设联盟链中有5个成员节点，其中3个成员节点的信任度较高（如大型银行），另外2个成员节点是城商行或小企业，智能合约要求需要3个信任度高的成员节点参与背书，并可以设定其角色为“CORE_MEMBER”，即核心成员，配置智能合约的背书策略为“MAJORITY CORE_MEMBER.Writers”，即过半数的核心成员Writer参与背书。如果有新的高信任度成员节点加入，只需要为其分配角色属性值即可，***会自动将其加入需要参与背书的集合。

通过给Fabric的策略(Policy)增加带角色属性的特性，可以实现当新成员加入或成员角色变更时，链码（智能合约）无需修改，新成员的权限会自动生效，从而有利于提高Fabric的实际可用性和安全性。

进一步的，还可接收针对所述分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据；

确定所述待修改数据对应的目标信息验证策略，并基于所述目标信息验证策略包含的成员角色的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点；

向所述投票成员节点发送所述待修改数据的投票请求；

接收所述投票成员节点返回的投票结果，并根据所述目标信息验证策略对所述投票结果进行验证；

在根据验证结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

具体的，待修改数据，包括但不限于增加或删除成员节点，或者修改成员节点的键值（value），即修改成员节点的配置信息。

由于账本配置树上的每个成员节点的属性信息均以键值对，即key-value的形式存储在树节点中，关键字（key）可用于表征成员节点的标识，键值（value）可用于表征成员节点的配置信息，可以在需要时修改，但每个树节点，即成员节点都有一个“mod_policy（修改策略）”指定修改该成员节点/键值需要满足的验证策略。例如，若目标成员节点的修改策略为“/Channel/Application/Admins”，则其对应的验证策略是通道上过半数的管理员投票通过。

因此，在接收针对分布式账本的账本数据提交的修改请求后，可根据修改请求中包含的待修改数据，确定是否需要增加或删除成员节点，或是否需要对目标成员节点的配置信息（value值）进行修改。若确定需对目标成员节点的配置信息进行修改，例如，为目标成员节点添加目标角色属性值，则首先需确定该目标成员节点的修改策略，并将其作为待修改数据对应的目标信息验证策略，然后可确定该修改策略中包含的角色属性值。

仍以目标成员节点的修改策略为“/Channel/Application/Admins”为例，该修改策略中包含的成员角色为Admins，即管理员，而管理员对应的角色属性值即为16。由于该策略要求是通道上过半数的管理员对待修改数据投票通过，因此，在确定目标信息验证策略包含的角色属性值后，即需获取各成员节点的目标角色属性值，以通过将角色属性值与目标角色属性值进行比对的方式，确定成员节点中，具有该角色属性值所对应成员角色的投票成员节点。

由于账本配置树中，成员节点的目标角色属性值以二进制数据类型存储，因此，可将修改策略中的成员角色的角色属性值转化为二进制数据，然后确定该二进制数据中值等于1的位置，再确定目标角色属性值中该位置的值是否等于1，若等于1，则可确定目该成员节点具有该角色属性值所对应的成员角色，反之，则可确定目该成员节点不具有该角色属性值所对应的成员角色。

确定具有该角色属性值所对应的成员角色的投票成员节点后，即可向投票成员节点发送待修改数据的投票请求，并接收投票成员节点返回的投票结果，再根据目标信息验证策略对投票结果进行验证，以根据验证结果确定待修改数据是否满足该目标成员节点的修改策略。例如，若修改策略要求是通道上过半数的管理员对待修改数据投票通过，则可通过验证确定投票结果为投票通过的管理员的数量，是否大于等于通道内管理员总数的二分之一；若是，则确定该待修改数据投票通过。

在根据验证结果确定投票通过的情况下，即可基于待修改数据对账本数据进行修改，生成对应的修改结果。例如，将目标角色属性值作为键值添加至账本配置树的目标成员节点。

本说明书实施例通过为分布式账本中的成员节点增加角色属性以及目标角色属性值，以实现基于成员角色的验证策略和访问控制等，从而满足分布式账本实际应用的灵活管理控制以及基于成员角色进行权限管控的基本安全要求。

另外，在为目标成员节点添加目标角色属性值后，还可接收针对目标项目提交的交易处理请求；

确定所述分布式账本中与所述目标项目相关的第一项目成员节点，通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的交易处理逻辑，生成对应的交易处理结果。

进一步的，本说明书实施例在引用隐式规则策略作为链码的背书策略的情况下，背书策略可以配置为与成员角色相关，因此，在生成交易处理结果，并在需通过背书策略中的成员节点对交易处理结果进行背书的情况下，可确定所述目标项目对应的目标信息验证策略，并对所述目标信息验证策略进行解析；

根据解析结果确定所述目标信息验证策略是否包含角色属性值；

若是，则根据所述角色属性值、所述目标信息验证策略及所述分布式账本中各项目成员节点分别对应的目标角色属性值，确定满足预设条件的第二项目成员节点；

基于所述第二项目成员节点的目标信息验证子策略，生成所述目标信息验证策略的子策略集合；

向所述第二项目成员节点发送所述交易处理结果的签名请求，并利用所述目标信息验证子策略对所述第二项目成员节点的签名结果进行验证；

根据所述子策略集合中各目标信息验证子策略对应的验证结果，确定所述交易处理结果的目标签名结果。

在确定所述交易处理结果的目标签名结果为签名通过的第二项目成员节点的数量，大于等于预设数量阈值的情况下，则通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的背书逻辑，对所述交易处理结果进行背书。

具体的，分布式账本中的每个链码都有背书策略，背书策略指定了通道上的一组Peer节点必须执行链码，并且为执行结果进行背书，以此证明交易是有效的。这些背书策略指定了必须为交易提案进行背书的组织，及成员节点。

另外，由于隐式规则策略并不直接进行签名检查，而是通过引用其它子策略来实现，通过检查引用的子策略的签名结果进行约束，支持ANY、ALL和MAJORITY三种规则。例如“MAJORITY Writers”表示过半数的子策略Writers签名，“ALL Admins”表示所有子策略Admins签名。

因此，分布式账本在接收针对目标项目提交的交易处理请求后，可先确定与目标项目对应的目标信息验证策略，即背书策略，其中，目标项目包括但不限于商品交易项目、金融项目、保险项目、医疗保健项目等；然后可根据背书策略确定分布式账本中与目标项目相关的第一项目成员节点，通过第一项目成员节点调用分布式账本的链码，并执行链码中的交易处理逻辑，生成对应的交易处理结果。然后在需要通过背书策略中指定的成员节点对交易处理结果进行背书，并在引用隐式规则策略作为链码的背书策略的情况下，即可对目标信息验证策略进行解析，以确定目标信息验证策略中是否包含角色属性值，即确定目标信息验证策略是否与成员角色相关。

实际应用中，若将目标信息验证策略命名为“sub_policy”，则可在“sub_policy”的策略内容中增加分隔符“.”，该分隔符之前的信息即为成员角色的角色属性值，以此来表示目标信息验证策略与成员角色相关。

基于此，在确定目标信息验证策略中包含角色属性值的情况下，即可确定下级成员节点中，具有该角色属性值对应的成员角色，并包含该目标信息验证子策略的第二项目成员节点。

具体的，由于本说明书实施例中存在策略管理器树，该树中的树节点与账本配置树的树节点具有一一对应的关系，且在为账本配置树中的成员节点添加目标角色属性值后，同样可为策略管理器树的树节点添加对应的目标角色属性值，还可为其增加“withRole(boolean)”接口，用于判断该节点是否拥有指定的角色（pm.roleValue&role==role）。因此，在确定下级成员节点中，具有该角色属性值对应的成员角色的第二项目成员节点时，可通过循环策略管理器树中所有下级策略管理器所在节点的方式，确定各管理器树所在节点是否具有该角色属性值对应的成员角色；若是，则可将第二项目成员节点的目标信息验证子策略，加入目标信息验证策略的子策略集合。

其中，若目标信息验证策略的名称为“sub_policy”，则子策略即账本配置树的下级成员节点中定义为该名称的策略。

在需基于目标信息验证策略对交易处理结果进行背书时，则需将第二项目成员节点中该名称的策略搜集为一个子策略集合，然后请求第二项目成员节点对交易处理结果进行签名，然后利用子策略集合中的目标信息验证子策略对第二项目成员节点的签名结果进行验证，并通过子策略集合中验证通过（即签名通过）的情况评估该目标信息验证策略的验证结果。

例如，目标信息验证策略定义的文字描述为“MAJORITY Admins”，即表示需要过半数“Admins”的目标信息验证子策略对应的验证结果为验证通过，因此，在确定所述交易处理结果的目标签名结果为签名通过的第二项目成员节点的数量，大于等于预设数量阈值的情况下，则通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的背书逻辑，对所述交易处理结果进行背书。

本说明书实施例为分布式账本的组织成员增加角色属性，实现联盟中的成员可以拥有不同的角色，并且可以根据组织成员的角色进行权限控制和背书验证，有利于提高分布式账本的可用性和安全性。

本说明书一个实施例通过根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与目标成员节点匹配的目标成员角色，其中，所述目标成员节点为所述分布式账本中的至少两个成员节点之一，基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值，将所述目标角色属性值添加至所述目标成员节点。

本说明书实施例通过为分布式账本中的各成员节点添加角色属性，以及为各成员节点添加角色属性对应的目标角色属性值，以实现为各成员节点进行角色添加，使得分布式账本中各成员节点可以基于其自身的属性信息，拥有不同的成员角色，后续可根据成员节点的角色进行权限控制和背书验证，有利于提高分布式账本的可用性和安全性。

下述结合附图2，以本说明书提供的基于分布式账本的数据处理方法在实际场景的应用为例，对所述基于分布式账本的数据处理方法进行进一步说明。其中，图2示出了本说明书一个实施例提供的一种基于分布式账本的数据处理方法的处理过程流程图，具体包括以下步骤。

步骤202，创建至少两个成员角色，并确定至少两个成员角色分别对应的角色属性值。

步骤204，根据分布式账本中至少两个成员节点的属性信息，确定至少两个成员角色中，与目标成员节点匹配的目标成员角色，其中，目标成员节点为至少两个成员节点之一。

步骤206，对至少两个目标成员角色分别对应的角色属性值进行求和处理，生成目标成员节点对应的目标角色属性值。

步骤208，将目标角色属性值转化为二进制掩码，并将转化结果作为目标成员节点的键值，添加至分布式账本的账本配置树，其中，至少两个成员节点的属性信息以键值对的形式存储在账本配置树中。

步骤210，根据创建的至少两个成员角色，生成分布式账本的链码对应的至少一个信息验证策略。

步骤212，接收针对目标项目提交的交易处理请求。

步骤214，确定分布式账本中与目标项目相关的第一项目成员节点，通过第一项目成员节点调用分布式账本的链码，并执行链码中的交易处理逻辑，生成对应的交易处理结果。

步骤216，确定目标项目对应的目标信息验证策略，并对目标信息验证策略进行解析。

步骤218，在根据解析结果确定目标信息验证策略包含角色属性值的情况下，根据角色属性值、目标信息验证策略及分布式账本中各项目成员节点分别对应的目标角色属性值，确定满足预设条件的第二项目成员节点。

步骤220，基于第二项目成员节点的目标信息验证子策略，生成目标信息验证策略的子策略集合。

步骤222，向第二项目成员节点发送交易处理结果的签名请求，并利用目标信息验证子策略对第二项目成员的签名结果进行验证。

步骤224，根据子策略集合中各目标信息验证子策略对应的验证结果，确定交易处理结果的目标签名结果。

步骤226，在确定交易处理结果的目标签名结果为签名通过的第二项目成员节点的数量，大于等于预设数量阈值的情况下，则通过第一项目成员节点调用分布式账本的链码，并执行链码中的背书逻辑，对交易处理结果进行背书。

本说明书实施例通过为分布式账本中的各成员节点添加角色属性，以及为各成员节点添加角色属性对应的目标角色属性值，以实现为各成员节点进行角色添加，使得分布式账本中各成员节点可以基于其自身的属性信息，拥有不同的成员角色，后续可根据成员节点的角色进行权限控制和背书验证，有利于提高分布式账本的可用性和安全性。另外，通过给分布式账本的策略(Policy)增加带角色属性的特性，还可以实现当新成员加入或成员角色变更时，链码无需修改，新成员的权限会自动生效，从而大大提高分布式账本的实际可用性和安全性。

与上述方法实施例相对应，本说明书还提供了基于分布式账本的数据处理装置实施例，图3示出了本说明书一个实施例提供的一种基于分布式账本的数据处理装置的结构示意图。如图3所示，该装置包括：

第一确定模块302，被配置为根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与所述目标成员节点匹配的目标成员角色，其中，所述目标成员节点为所述分布式账本中的至少两个成员节点之一；

第二确定模块304，被配置为基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值；

添加模块306，被配置为将所述目标角色属性值添加至所述目标成员节点。

可选地，所述添加模块306，进一步被配置为：

将所述目标角色属性值作为所述目标成员节点的键值，添加至所述分布式账本的配置信息存储结构，其中，所述至少两个成员节点的属性信息以键值对的形式存储在所述配置信息存储结构中。

可选地，所述基于分布式账本的数据处理装置，还包括创建模块，被配置为：

创建成员角色，并确定所述成员角色对应的角色属性值。

可选地，所述第二确定模块304，进一步被配置为：

对至少两个目标成员角色分别对应的角色属性值进行求和处理，生成所述目标成员节点对应的目标角色属性值。

可选地，所述添加模块306，进一步被配置为：

将所述目标角色属性值转化为目标数据类型，并将转化结果作为所述目标成员节点的键值，添加至所述分布式账本的配置信息存储结构，其中，所述至少两个成员节点的属性信息以键值对的形式存储在所述配置信息存储结构中。

可选地，所述基于分布式账本的数据处理装置，还包括生成模块，被配置为：

根据所述预设的成员角色，生成所述分布式账本的链码对应的至少一个信息验证策略。

可选地，所述基于分布式账本的数据处理装置，还包括接收模块，被配置为：

接收针对所述分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据；

确定所述待修改数据对应的目标信息验证策略，并基于所述目标信息验证策略包含的成员角色的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点；

向所述投票成员节点发送所述待修改数据的投票请求；

接收所述投票成员节点返回的投票结果，并根据所述目标信息验证策略对所述投票结果进行验证；

在根据验证结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

可选地，所述基于分布式账本的数据处理装置，还包括调用模块，被配置为：

接收针对目标项目提交的交易处理请求；

确定所述分布式账本中与所述目标项目相关的第一项目成员节点，通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的交易处理逻辑，生成对应的交易处理结果。

可选地，所述基于分布式账本的数据处理装置，还包括验证模块，被配置为：

确定所述目标项目对应的目标信息验证策略，并对所述目标信息验证策略进行解析；

根据解析结果确定所述目标信息验证策略是否包含角色属性值；

若是，则根据所述角色属性值、所述目标信息验证策略及所述分布式账本中各项目成员节点分别对应的目标角色属性值，确定满足预设条件的第二项目成员节点；

基于所述第二项目成员节点的目标信息验证子策略，生成所述目标信息验证策略的子策略集合；

向所述第二项目成员节点发送所述交易处理结果的签名请求，并利用所述目标信息验证子策略对所述第二项目成员节点的签名结果进行验证；

根据所述子策略集合中各目标信息验证子策略对应的验证结果，确定所述交易处理结果的目标签名结果。

可选地，所述基于分布式账本的数据处理装置，还包括背书模块，被配置为：

在确定所述交易处理结果的目标签名结果为签名通过的第二项目成员节点的数量，大于等于预设数量阈值的情况下，则通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的背书逻辑，对所述交易处理结果进行背书。

可选地，所述基于分布式账本的数据处理装置，还包括获取模块，被配置为：

获取所述配置信息存储结构对应的策略存储结构；

根据所述配置信息存储结构与所述策略存储结构中，成员节点的位置对应关系，将所述配置信息结构中存储的所述目标成员节点对应的目标角色属性值，添加至所述策略存储结构的对应位置。

上述为本实施例的一种基于分布式账本的数据处理装置的示意性方案。需要说明的是，该基于分布式账本的数据处理装置的技术方案与上述的基于分布式账本的数据处理方法的技术方案属于同一构思，基于分布式账本的数据处理装置的技术方案未详细描述的细节内容，均可以参见上述基于分布式账本的数据处理方法的技术方案的描述。

图4示出了根据本说明书一个实施例提供的另一种基于分布式账本的数据处理方法的流程图，具体包括以下步骤。

步骤402，接收针对分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据。

步骤404，确定所述待修改数据对应的数据修改策略，并基于所述数据修改策略包含的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点。

步骤406，向所述投票成员节点发送所述待修改数据的投票请求。

步骤408，接收所述投票成员节点返回的投票结果，在根据所述投票结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

本说明书实施例通过为分布式账本中的各成员节点添加角色属性，以及为各成员节点添加角色属性对应的目标角色属性值，以实现为各成员节点进行角色添加，使得分布式账本中各成员节点可以基于其自身的属性信息，拥有不同的成员角色，后续可根据成员节点的角色进行权限控制和背书验证，有利于提高分布式账本的可用性和安全性。

上述为本实施例的另一种基于分布式账本的数据处理方法的示意性方案。需要说明的是，该另一种基于分布式账本的数据处理方法的技术方案与上述的一种基于分布式账本的数据处理方法的技术方案属于同一构思，该另一种基于分布式账本的数据处理方法的技术方案未详细描述的细节内容，均可以参见上述一种基于分布式账本的数据处理方法的技术方案的描述。

与上述方法实施例相对应，本说明书还提供了另一种基于分布式账本的数据处理装置实施例，图5示出了本说明书一个实施例提供的另一种基于分布式账本的数据处理装置的结构示意图。如图5所示，该装置包括：

接收模块502，被配置为接收针对分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据；

确定模块504，被配置为确定所述待修改数据对应的数据修改策略，并基于所述数据修改策略包含的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点；

发送模块506，被配置为向所述投票成员节点发送所述待修改数据的投票请求；

修改模块508，被配置为接收所述投票成员节点返回的投票结果，在根据所述投票结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

上述为本实施例的另一种基于分布式账本的数据处理装置的示意性方案。需要说明的是，该另一种基于分布式账本的数据处理装置的技术方案与上述的另一种基于分布式账本的数据处理方法的技术方案属于同一构思，另一种基于分布式账本的数据处理装置的技术方案未详细描述的细节内容，均可以参见上述另一种基于分布式账本的数据处理方法的技术方案的描述。

图6示出了根据本说明书一个实施例提供的一种计算设备600的结构框图。该计算设备600的部件包括但不限于存储器610和处理器620。处理器620与存储器610通过总线630相连接，数据库650用于保存数据。

计算设备600还包括接入设备640，接入设备640使得计算设备600能够经由一个或多个网络660通信。这些网络的示例包括公用交换电话网（PSTN）、局域网（LAN）、广域网（WAN）、个域网（PAN）或诸如因特网的通信网络的组合。接入设备640可以包括有线或无线的任何类型的网络接口（例如，网络接口卡（NIC））中的一个或多个，诸如IEEE802.11无线局域网（WLAN）无线接口、全球微波互联接入（Wi-MAX）接口、以太网接口、通用串行总线（USB）接口、蜂窝网络接口、蓝牙接口、近场通信（NFC）接口，等等。

在本说明书的一个实施例中，计算设备600的上述部件以及图6中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图6所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备600可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备（例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等）、移动电话（例如，智能手机）、可佩戴的计算设备（例如，智能手表、智能眼镜等）或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备600还可以是移动式或静止式的服务器。

其中，处理器620用于执行如下计算机可执行指令，该计算机可执行指令被处理器执行时实现上述基于分布式账本的数据处理方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的基于分布式账本的数据处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述基于分布式账本的数据处理方法的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现上述基于分布式账本的数据处理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的基于分布式账本的数据处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述基于分布式账本的数据处理方法的技术方案的描述。

本说明书一实施例还提供一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述基于分布式账本的数据处理方法的步骤。

上述为本实施例的一种计算机程序的示意性方案。需要说明的是，该计算机程序的技术方案与上述的基于分布式账本的数据处理方法的技术方案属于同一构思，计算机程序的技术方案未详细描述的细节内容，均可以参见上述基于分布式账本的数据处理方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书实施例并不受所描述的动作顺序的限制，因为依据本说明书实施例，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书实施例所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书实施例的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims (15)

1.一种基于分布式账本的数据处理方法，其特征在于，包括：

根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与所述目标成员节点匹配的目标成员角色，其中，所述目标成员节点为所述分布式账本中的至少两个成员节点之一；

基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值；

将所述目标角色属性值添加至所述目标成员节点。

2.根据权利要求1所述的基于分布式账本的数据处理方法，其特征在于，所述将所述目标角色属性值添加至所述目标成员节点，包括：

将所述目标角色属性值作为所述目标成员节点的键值，添加至所述分布式账本的配置信息存储结构，其中，所述至少两个成员节点的属性信息以键值对的形式存储在所述配置信息存储结构中。

3.根据权利要求1所述的基于分布式账本的数据处理方法，其特征在于，还包括：

创建成员角色，并确定所述成员角色对应的角色属性值。

4.根据权利要求1所述的基于分布式账本的数据处理方法，其特征在于，所述基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值，包括：

对至少两个目标成员角色分别对应的角色属性值进行求和处理，生成所述目标成员节点对应的目标角色属性值。

5.根据权利要求1或4所述的基于分布式账本的数据处理方法，其特征在于，所述将所述目标角色属性值添加至所述目标成员节点，包括：

将所述目标角色属性值转化为目标数据类型，并将转化结果作为所述目标成员节点的键值，添加至所述分布式账本的配置信息存储结构，其中，所述至少两个成员节点的属性信息以键值对的形式存储在所述配置信息存储结构中。

6.根据权利要求1所述的基于分布式账本的数据处理方法，其特征在于，还包括：

根据所述预设的成员角色，生成所述分布式账本的链码对应的至少一个信息验证策略。

7.根据权利要求6所述的基于分布式账本的数据处理方法，其特征在于，还包括：

接收针对所述分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据；

确定所述待修改数据对应的目标信息验证策略，并基于所述目标信息验证策略包含的成员角色的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点；

向所述投票成员节点发送所述待修改数据的投票请求；

接收所述投票成员节点返回的投票结果，并根据所述目标信息验证策略对所述投票结果进行验证；

在根据验证结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

8.根据权利要求6所述的基于分布式账本的数据处理方法，其特征在于，还包括：

接收针对目标项目提交的交易处理请求；

确定所述分布式账本中与所述目标项目相关的第一项目成员节点，通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的交易处理逻辑，生成对应的交易处理结果。

9.根据权利要求8所述的基于分布式账本的数据处理方法，其特征在于，还包括：

确定所述目标项目对应的目标信息验证策略，并对所述目标信息验证策略进行解析；

根据解析结果确定所述目标信息验证策略是否包含角色属性值；

若是，则根据所述角色属性值、所述目标信息验证策略及所述分布式账本中各项目成员节点分别对应的目标角色属性值，确定满足预设条件的第二项目成员节点；

基于所述第二项目成员节点的目标信息验证子策略，生成所述目标信息验证策略的子策略集合；

向所述第二项目成员节点发送所述交易处理结果的签名请求，并利用所述目标信息验证子策略对所述第二项目成员节点的签名结果进行验证；

根据所述子策略集合中各目标信息验证子策略对应的验证结果，确定所述交易处理结果的目标签名结果。

10.根据权利要求9所述的基于分布式账本的数据处理方法，其特征在于，还包括：

在确定所述交易处理结果的目标签名结果为签名通过的第二项目成员节点的数量，大于等于预设数量阈值的情况下，则通过所述第一项目成员节点调用所述分布式账本的链码，并执行所述链码中的背书逻辑，对所述交易处理结果进行背书。

11.根据权利要求2所述的基于分布式账本的数据处理方法，其特征在于，还包括：

获取所述配置信息存储结构对应的策略存储结构；

根据所述配置信息存储结构与所述策略存储结构中，成员节点的位置对应关系，将所述配置信息结构中存储的所述目标成员节点对应的目标角色属性值，添加至所述策略存储结构的对应位置。

12.一种基于分布式账本的数据处理方法，其特征在于，包括：

接收针对分布式账本的账本数据提交的修改请求，其中，所述修改请求中包含待修改数据；

确定所述待修改数据对应的数据修改策略，并基于所述数据修改策略包含的角色属性值，及所述分布式账本中各成员节点分别对应的目标角色属性值，确定满足预设条件的投票成员节点；

向所述投票成员节点发送所述待修改数据的投票请求；

接收所述投票成员节点返回的投票结果，在根据所述投票结果确定投票通过的情况下，基于所述待修改数据对所述账本数据进行修改，生成对应的修改结果。

13.一种基于分布式账本的数据处理装置，其特征在于，包括：

第一确定模块，被配置为根据分布式账本中目标成员节点的属性信息，确定预设的成员角色中，与所述目标成员节点匹配的目标成员角色，其中，所述目标成员节点为所述分布式账本中的至少两个成员节点之一；

第二确定模块，被配置为基于所述目标成员角色对应的角色属性值，确定所述目标成员节点对应的目标角色属性值；

添加模块，被配置为将所述目标角色属性值添加至所述目标成员节点。

14.一种计算设备，其特征在于，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1至12任意一项所述基于分布式账本的数据处理方法的步骤。

15.一种计算机可读存储介质，其特征在于，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1至12任意一项所述基于分布式账本的数据处理方法的步骤。

Images