一种基于多分类子链的政务数据质量管理架构

杨建豪 宋 超 周国富 汤梦玲 洪 薇 李京昆

1(湖北省大数据中心 武汉 430071)2(武汉大学计算机学院 武汉 430072)3(湖北央中巨石信息技术有限公司 武汉 430060)(1031499@qq.com)

“十四五”规划纲要明确提出以联盟链为重点，发展区块链服务平台和政务服务领域应用，完善监管机制.充分体现区块链技术在数字政务应用领域的必要性和迫切性[1-2].区块链安全体系体现在安全哈希算法与数字签名技术方面[3-5].区块链分布存储特性，极大提高了政务数据的安全性和容错性，为信息共享提供良好平台，可实现跨系统、跨部门、跨区域的数字政务协同[6-8].

区块链基于在不可靠网络中的传输、存储和访问，因此数据访问权限[9-10]均由本地计算节点实施单点认证.然而，政务数据的一个重要特点是同一社会个体的数据可能分散存储在政府多部门、多编码、多应用中，同时数据具有显著的所有权属性[11-12].任何政务数据的分享均需数据源部门的授权，数据的再加工也需要数据源部门的授权.

本文应用区块链相关技术，针对政务数据分享与再加工问题，提出一种存证、修证机制，保证数据所有者对数据再加工的监管与授权.同时，为保证数据的规范性，增加了第三方标准规范认证.多分类子链架构基于存证、修证、认证3类子链的协同认证机制，扩展了传统区块链单点单规则验证模式，动态构建3类子链，对数据访问实施不同规则的验证.

1 基本架构

数据一致性是分布存储带来的重要问题.区块链解决一致性问题的过程称之为共识，解决由哪个节点发起提案，网络中参与节点经过验证授权，与其他节点达成一致.本文系统架构利用区块链技术，将政务数据真实性、所有权、标准化进一步地固化.通过区块链共识机制，实现政务协同治理.

网络中的节点成员具有3种不同角色：存证、修证、认证.存证节点在网络中具有存储作用；修证节点则针对账本作一定的修改，产生新的账本版本；认证节点则作为第三方，提供相关数据认证作用.基本架构如图1所示.

图1 多分类子链架构

所有数据均具有唯一的所有者.任何对数据的访问包括查询和加工等，均需数据所有者授权(获得源数据账本).查询过程不产生新数据，分享加工过程产生新数据，新数据不对源数据进行覆盖.授权加工产生的数据由加工者所有.系统保留源数据和加工后的数据关系，保证数据的可追溯性.

网络新节点的加入需要申请，由相关节点成员共同授权，确定该节点在网络中担任的角色.因此，网络所有节点均保存1张相同的网络节点表，记录经过认证的合法网络节点信息.网络节点表实际上就是一种数据账本，这类账本的查询、修改、增加等均可由修证方发起事务处理.

事务申请由修证方发起.事务可以是网络新节点的加入，以及数据的查询、修改和创建等.每个事务申请根据源数据创建1个申请账本，账本包含修证方、存证方、认证方3类网络节点信息.这3类网路节点构成功能不同的子链.每个事务申请均向这3类子链节点广播发送.接收到事务申请的节点，基于事务申请账本中的信息，根据本节点所担任的角色实施不同规则验证，并反馈给事务发起方.修证方根据事务返回结果，应用预设定的共识规则，确认申请是否被授权.

2 基于树的账本组织

从数据存储角度看，传统数据库管理系统由数据库、表、字段3级结构组成.从应用角度看，应用域的数据可能涉及多个部门的数据库、数据表、记录和字段的重新组合.本节以数据库数据组织结构为基础，分别构建字段、记录、表、数据库、应用域等层次目录账本.

2.1 基本数据对象

基于树的数据组织包含3类数据对象：规则对象、元数据对象、目录对象.其底层存储的区块链特性可以参考文献[13-15].

规则对象描述数据分享和加工需要遵循的约束，给出相关数据需要满足的语义/语法规则集.目录对象描述数据对象之间逻辑构成关系.目录需要满足的关系通过规则集来描述.

数据对象用唯一的哈希值作为标识和索引.哈希值作为标识或指针可以实现快速定位查找，同时又可以作为完整性验证.下文论述中，标识、索引、地址、指针等均为相应的哈希值表示.

1) 规则对象.

规则对象是约束条件、验证操作及其映射的描述，如图2所示.规则对象规定数据对象约束条件及其验证操作.

图2 规则对象

图2中，规则哈希值由约束条件和验证操作动态生成.约束条件是对系统中数据需要满足约束的规范化描述，如正则表达式、一阶逻辑、lambda算子等[16-18].验证操作是对应约束条件验证的算法实现.在实际系统中，验证操作可指定程序代码的路径信息.

2) 元数据对象.

数据库中实体数据称为元数据.采用数据库表“字段”作为最小数据单元.哈希值作为字段数据的标识和存储索引.字段需要满足的约束通过规则集描述.这种结构的数据组织称为元数据对象，如图3所示：

图3 元数据对象

图3中，字段数据值表示具体数据.字段哈希值由字段数据值、规则集和父亲指针动态生成.规则集包含字段必须满足的多个约束条件.在申请访问字段时，系统根据规则集进行验证，如对数据进行解密和哈希值验证，也可以增加数据编码验证和数据精度的验证等.父亲指针指向本数据由哪一数据修改而成.

在具体实现中，可以增加多个解释性字段，帮助对各字段的理解.对于长文本数据，字段数据值可采取增量数据存储策略，即仅保存与其父亲数据不同的部分[16,19].

3) 目录对象.

目录对象描述数据对象之间逻辑关系和存储信息，不保存实际元数据.目录可以嵌套描述不同层次的数据关系.

目录对象通过设置父亲指针，把目录以版本形式链接起来，如图4所示：

图4 目录对象

图4中，目录哈希值标识目录对象.规则集描述本目录所有数据必须遵循的约束条件，如目录下有多少个合法对象.目录父亲指向其他已存在的目录.计数描述本目录下由多少个数据对象构成.名字标识数据对象i.数据对象哈希值i表示目录可包含多个数据对象.数据对象i存储节点记录数据对象实际存储的网络节点集合.

2.2 数据的树形目录

参照传统数据库组织结构，应用2.1节定义的数据对象组织成树形结构.数据的变化历史可以通过相关数据对象的父亲指针构建.

1) 字段.

字段是数据库中最基本数据单元，属于元数据对象.字段中设置1个规则集，规定字段数据需要满足的约束条件.字段各个时期的不同值构成字段数据的历史版本.数据的所有版本通过字段历史目录描述字段数据的变迁.

2) 记录.

每条记录由不同字段构成.每条记录可设置1个规则集.规则集对记录中各个字段进行约束.记录不保存具体数据，而是由字段哈希值标识.记录保存相关字段的路径信息.这种机制具有动态可更新特性，特别适合动态组建新的逻辑关系.可以建立记录的历史目录，追踪记录的变化轨迹.

3) 表.

表由多个记录构成.表目录记载该表的所有记录路径信息.规则集规定该表所有记录需要满足的条件约束.表不保存记录的具体数据，只是保存记录的哈希值.因此，记录具体数据对于表来说是透明的.记录值的变换可以通过记录哈希值切换实现.

4) 数据库.

数据库由表构成.数据库目录记载数据库中所有表的标识、路径等相关信息.规则集规定该数据库中表需要满足的条件约束.数据库哈希值由数据库目录数据动态生成.

5) 基于应用域目录.

应用域目录描述具体应用涉及到多部门、多数据库的数据访问.规则集定义该域应用需要遵循的约束条件限制.每个数据库均有对应的哈希值作为唯一标识.

基于以上所讨论的各类数据对象，应用树结构把数据对象组织在一起，构成目录层次.叶节点为元数据对象，中间节点均为目录对象.域目录描述具体应用域涉及到的多个数据库.数据库目录描述数据库的表数据构成.每个表由多个记录构成，由表目录描述.每个记录由多个字段构成，由记录目录描述.字段均以元数据对象存储.不同层次的目录对象分别描述系统中数据库、表、记录、字段之间的逻辑组成，如图5所示：

图5 应用域目录树

在数据分享时，选取不同层级的目录，创建不同的数据访问账本.数据更新操作根据获得数据账本信息，可构建出新的数据目录树.动态数据加工实际上是动态创建或更新目录过程，这种目录机制向应用层提供一个完整的逻辑数据库视图.

3 多分类链验证

多分类链机制是针对动态产生的数据，应用区块链共识机制，实现政务数据的协同治理[6].在传统区块链中，数字签名处理以及合法性确认均由本地节点独立实施完成.事实上，各政府部门均处于相对平等地位，对各自的数据拥有所有权，并对公开的数据负有行政和法律责任.在数据分享和再加工过程中，需要对数据加工进行监督与授权.同时，政务数据存在多源情形，依据国家对大数据规范化要求，政务数据迫切需要规范化和标准化，即对加工的数据是否满足规范化要求作出认证.根据政务数据的实际需要，多分类链架构设置以下3类角色进行协作：

1) 存证.保存有原始数据和账本的节点；存证节点将对修证节点修改自己的数据进行验证和授权，保证数据所有者权益，对数据的流通历史回溯提供可能.

2) 修证.根据原始数据和账本，修改后的数据必须得到原始数据和账本的所有权节点授权和第三方数据规范化认证节点的认可.

3) 认证.作为客观的第三方，对请求事务提供第三方认证.特别是在数据规范化和标准化方面，对新增和更新的数据是否满足规范化进行验证.

根据数据访问申请，在政务网络中，分别选择并构建存证、修证、认证3组网络节点集合，每类节点根据所处的角色类型实施不同的操作.即：系统构建存证链、修证链、认证链3类子区块链对数据的再加工进行协同认证(如图6所示)，其中节点集合中的网络节点构成相应的子链.这些子链具有区块链属性和功能.

图6 数据访问请求中的3类子链

数据访问请求包含数据目录(账本)信息.为简洁起见，图6中没有附着相关账本信息.账本由修证方创建.账本创建完成后向存证、修证、认证相关节点广播账本，等待广播返回信息.收到账本的节点，依据本节点在账本中所属角色，实施规则验证，并返回账本发起方.

图6中，对数据的更新需要存证、修正、认证3类节点分别审核才能实施数据的修改.存证节点集合表示具有存证角色的网络节点集合.规则集合描述相关节点需要实施的规则验证.签名集合保存着规则验证的结果反馈.

修证方根据收到的账本反馈签名集合，应用拜占庭算法或者其他用户自定义策略，审核事务的合法性.只有三方均通过审核后，系统才能保存账本信息，并存储账本对应的元数据.具体的数据存储访问依赖于更底层的网络(区块链)平台.

3.1 网络节点加入

在传统的区块链中，任意节点可以自由加入网络，隐含的前提是网络节点不总是可靠的[5-6,10,14,20-21].基于政务网络和联盟链特性，网络节点的加入必须通过相关部门认证，并分派一定角色.

新节点的加入申请需由存证、修证、认证节点共同授权，并确定该节点在网络中担任的角色.存证角色在网络中具有存储元数据作用，一般作为数据所有者.修证角色根据源数据作一定的修改加工，产生新的数据.认证角色则作为第三方，提供相关数据证明.网络中所有节点保存1张网络节点表(目录对象).表1为网络节点表的基本信息：

表1 网络节点表

在网络节点加入申请中，修证节点提出申请网络节点表数据修改.新节点至少是存证、修证、认证3种角色类型之一，其中地址是可以通信的网络地址.

网络节点加入申请实际上就是对网络节点列表(账本)数据的修改请求，创建网络节点表数据的更新请求.图7中，网络节点表更新请求申请包含将要更新的网络节点表.规则集合就是对相关节点角色的验证.如果同意该节点加入网络，则返回同意签名，否则返回不同意签名.

图7 网络节点加入申请

3.2 新增数据

新增数据时，首先创建基于元数据的树形目录，并设置数据对象规则集，创建与图7类似的新增数据账本(如图8所示).新增数据请求事务总是由修证节点提出.每个新增数据请求均包括1个新增数据账本.新增数据请求将有存证、修正和认证3类角色共同授权.新增数据无历史数据，无需设置存证节点.新增数据请求必须设置认证节点集合.

图8 新增数据请求

系统向认证节点广播事务请求，等待认证返回.系统根据认证链返回的签名，确认是否通过新增数据授权.在认证通过后，设置存证节点信息，指派元数据实际存储的网络节点.元数据存储和数据目录账本分别独立分布存储.

3.3 更新数据

修证节点创建更新数据请求账本.数据更新包括元数据的更新和数据目录的更新.数据的更新一般会导致更高层次目录的更新.

图9所示为更新数据的请求.更新请求向存证、修证、认证子链广播，从存证、修证、认证子链返回签名集合中，应用决策算法，确认是否通过事务审核.只有三方均通过审核后，才能实施数据存储和数据目录账本的存储.

图9 更新数据请求

数据更新时，如需对数据进行版本管理，设置更新后数据的父亲指针，构建数据历史版本链.

3.4 规则验证

在传统区块链中，仅隐含2种全局性约束，即解密和数字签名验证，相关节点均执行解密和数字签名相关的本地验证操作，本地验证通过即可获得数据访问授权[15,20,22-24].这种单点单一规则验证机制包含3类基本的规则和验证：

1) 加密规则.接收数据节点，实施加密/解密操作.

2) 数字签名规则.设施哈希算法，针对数据一致性进行验证.

3) 决策规则.如拜占庭算法，一人一票的投票机制，少数服从多数原则.

综上可知，单一单点规则验证机制只能保证数据在网络传输(无语义)中的可靠性问题，不能解决数据的权属与数据再加工规范化问题、数据属性与应用层相互影响等问题.因此在数据更高应用层次(数据语义层)，需要更多约束保证数据权属、加工的一致性、可靠性和合法性.因此，除了上述基本规则和验证过程外，需要扩展数据所有权和数据标准化等规则和验证.接收数据更新请求的节点，依据请求账本中设置的规则，调用相应的验证算法.扩展的规则与验证算法包括：

1) 基本属性验证规则.根据国家数据标准设置数据规则约束条件，采用相应统一的算法进行验证.

2) 扩展属性规则.根据政务数据的具体要求，自定义数据库、表、字段、数据等需要满足的规则约束条件.设计实现相关的算法.

每个数据对象原则上可以施加任意条规则集合.每条规则对应一种验证过程，并构建规则库.规则库的构成参照工标、行标、国标等规范[25].

4 案例实现

本节简要说明湖北省电子政务系统关于企业电子证照数据的产生过程.典型的业务场景描述如下：企业去工商局进行企业信息注册登记，办理注册手续后，政府制证部门通过数据链路获取到该登记信息并进行电子证照的制证.

制证方提起证照数据创建申请，证照原始数据由工商局所有并存储.因此，制证的数据再加工需要得到工商局的审核并授权.为了保证证照数据的标准化、规范化，制证的数据也需要第三方审核并认可.因此，制证过程涉及制证方——制证单位、核验方——工商局、监管方——第三方监管.

对应上文讨论的修正、存证、认证子链，构建制证方、核验方、监管方3条子链，分别实现证照数据加工的申请、核验与监管.

4.1 建立规则库

系统根据各级数据标准建立共享规则库.表2是参考C0135 国家政务服务平台-电子证照-营业执照工程标准，建立的一个示范性规则库.每个规则均有标识符，对应一个可执行的验证函数.是否符合规则，由验证函数进行验算.

表2 规则库表

在设置具体数据规则时，系统将会映射规则验证函数所需的参数.如在表2中验证函数Few(d1,d2)需要2个参数，在实际系统实现中将设计一种参数传递机制.

4.2 建立网络节点列表

系统首先建立网络节点表，每个节点均保存1份网络节点表，网络节点表可作为一种账本.以下讨论所列出的哈希值均是假设的，且取其中前8位.

在图10中，工商局是网络中1个节点，作为数据所有方，保存企业原始数据，主要作为存证角色.工商局也可以具有其他数据再加工的能力，因此，工商局可以担任修正角色.相应位置为“空”，表示不承担验证角色.

制证单位是网络中1个节点，请求工商局数据，执行证照数据加工.主要作为修证角色.同样也可以向外提供原始数据服务，作为存证角色.相应位置为“空”，表示不承担验证角色.

第三方监管单位是网络中1个节点，担任数据规范化验证工作验证角色.假设监管单位不独立加工生产新数据，因此相应的位置为空，表示不设置为修正角色.但监管单位可以为原始数据提供存储功能的存证角色.

图10 政务网络节点表

节点数表示网络已存在的节点总数.修正节点数表示网络中已指派为修正角色的节点数.存证节点数表示网络中已指派为存证角色的节点数.认证节点数表示网络中已指派为认证角色的节点数.

每个网络节点均提供各自的签名和可通信的网络地址.

网络节点表中可以设置以下规则集：

1) 制证单位签名、工商局签名、第三方监管签名必须遵循签名规则FileSignVal约束(见表2).

2) 如果对网络节点数进行限定，可增加约束.如验证函数Few(节点数,20)，表示网络节点数最多只能有20个节点(见表2).

3) 网络地址必须遵循规则IPadd约束(见表2).

4.3 证照元数据

假设制作证照需要持证者、持证者代码、证照编号、有效期起始、有效期截至等数据.

在具体实现中，为方便管理，可以在以下结构基础上增加字段.

1) 持证者.

持证者数据由工商局所有，具有表3所示的基本结构：

表3 持证者数据

表3中，规则集定义如下.

字段哈希值：67cdab23，遵循签名规则FileSignVal(见表2).

字段数据值：杨黎，表示持证者姓名，遵循编码规则函数C200(见表2).

父亲指针：NULL，表示没有父亲，属于新创建的数据，遵循签名规则FileSignVal(见表2).

2) 持证者代码.

持证者代码数据由工商局所有，具有表4所示的基本结构：

表4 持证者代码数据

表4中，规则集定义如下.

字段哈希值：78ba3412，遵循签名规则FileSignVal(见表2).

字段数据值：92421381MA4DP9R094，表示持证代码，遵循编码规则UniSCID(见表2).

父亲指针：NULL，表示没有父亲，属于新创建的数据，遵循签名规则FileSignVal(见表2).

3) 证照编号.

证照编号数据由工商局所有，具有表5所示的基本结构：

表5 证照编号数据

表5中，规则集定义如下.

字段哈希值：ba2345ac，遵循签名规则FileSignVal(见表2).

字段数据值：904200002020050408003400000 7571729，表示证照编号，遵循编码规则FileBLicNo(见表2).

父亲指针：NULL，表示没有父亲，属于新创建的数据，遵循签名规则FileSignVal(见表2).

4) 有效期起始.

有效期起始数据由工商局所有，具有表6所示的基本结构：

表6 有效期起始数据

表6中，规则集定义如下.

字段哈希值：cd12bcac，遵循签名规则FileSignVal(见表2).

字段数据值：2019-10-10 00:00:43.000，表示日期，遵循编码规则OpFrom(见表2).

父亲指针：NULL，表示没有父亲，属于新创建的数据，遵循签名规则FileSignVal(见表2).

5) 有效期截至.

本节假设对生成的证照数据中证照的“有效期截至”进行修改.“有效期截至”具有表7所示的基本结构：

表7 有效期截至数据

表7中，规则集定义如下.

字段哈希值：27baec2a，遵循签名规则FileSignVal(见表2).

字段数据值：NULL，表示日期，即没有数据，遵循编码规则OpTo(见表2).

父亲指针：NULL，表示没有父亲，属于新创建的数据，遵循签名规则FileSignVal(见表2).

假设工商局已经对数据均完成以元数据对象形式的组织.系统可以获得与证照制作所需的原始数据.

4.4 数据目录

每张证照均由多个字段构成，系统保存证照数据记录目录.所有证照用表目录组织.

1) 证照数据目录.

图11中“{工商局节点地址}”表示元数据只保存在工商局节点上.理论上可以分配到多个网络节点中存储.

图11中，规则集定义如下.

记录哈希值：872aec3a，表示证照数据的哈希值，遵循签名规则FileSignVal(见表2).

字段数：5，表示证照由5个字段构成.

工商局节点地址：网络通信地址遵循规则IPadd(见表2).

名字：表示证照的组成字段，名字是字段哈希值的一种别称.在规则集中，对不同名字分别进行不同约定.

图11 证照记录

记录父亲指针：NULL，表示没有父亲，属于新创建的数据，遵循签名规则FileSignVal(见表2).

2) 证照表目录.

证照表由1组结构相同的数据构成.每条数据称为1条证照.

图12中，规则集定义如下.

表哈希值：ab12e43e，表示表的哈希值，遵循签名规则FileSignVal(见表2).

记录数：3，表示本表由多少条记录构成，记录字段数遵循规则Equal(记录数,3)(见表2).

工商局节点地址：网络通信地址，遵循规则IPadd(见表2).

表父亲指针：NULL，表示没有父亲，属于新创建的数据，遵循签名规则FileSignVal(见表2).

图12 证照表目录结构

4.5 创建数据修改申请

根据需要，生成字段“有效期截至”修改的申请(如图13所示).修改数据粒度指定本次修改的数据所处的层次.粒度可以是字段、记录、表、数据库、应用域等.

图13 修改数据申请

证照原始数据记录位于872aec3a目录中(如图11所示)，证照编号、有效期起始、持证者、持证者代码、有效期截至均以元数据对象保存，由相应的哈希值作标识和索引.

1) 修改元数据“有效期截至”.

修改表7中字段“有效期截至”为：2029-10-10 00:00:43.000，得到表8.

表8 有效期截至元数据

表8中，规则集定义如下.

字段哈希值：38ecec2b，遵循签名规则FileSignVal(见表2).

字段数据值：2029-10-10 00:00:43.000，修改日期，遵循编码规则OpTo(见表2).

父亲指针：27baec2a(见表7)，表示由父亲数据修改而成，遵循签名规则FileSignVal(见表2).

2) 新的记录目录.

由于需要修改“有效期截至”，系统依据记录账本(哈希值872aec3a)修改相应的数据(如图14所示).

系统从网络节点列表中的”存证”节点角色集合，选择分布存储的网络节点.为新的“有效期截至”元数据选择分布存储的网络节点.

记录父亲指针由账本(哈希值872aec3a)数据修改而来.其他字段保持不变.

“有效期截至”的地址27baec2a变成地址38ecec2b，数据的更新最终使得本证照数据的哈希值发生变化，即56dcac21.

图14 记录数据变更

3) 证照表目录变化.

表由相同结构的证照构成，证照数据发生变化，相应的表目录也会发生变化，如图15所示.

由于数据库由证照表目录构成，表、证照数据的更新，数据库相关哈希值也会发生变化.这里不赘述.

修改申请由哈希值512aecef(如图13所示)唯一标识.申请修改字段是字段“有效期截至”数据，需要遵循编码规则OpTo(见表2).数据粒度可定义为“字段”.

图15 表数据变更

通过系统提供搜索手段，定位到修改数据的上一级872aec3a(如图11所示).其中27baec2a索引指向“有效期截至”元数据，实际值为NULL.申请修改为2029-10-10 00:00:43.000，并生成新的索引号38ecec2b(见表8)，并记录在证照记录512aecef(如图13所示)相应的位置.由上述可知，元数据38ecec2b由元数据27baec2a(父亲指针)修改而成.证照数据记录512aecef由证照数据记录872aec3a(父亲指针)修改而成(如图16所示).

图16 证照记录数据更新关系

更新请求由修正角色的制证单位提出，制证单位由{制证单位}描述其通信相关信息.数据能否修改由数据存证角色，即数据的所有者{工商局}授权.数据规范化由认证角色，即{第三方单位}验证.用大括号{}表示相同角色可以包含多个网络节点.每个节点根据角色执行验证函数C64进行验证，返回各自签名{ok:sig}或{sorry:sig}.其中ok表示通过审核，sorry表示审核失败，sig标识节点的签名信息.

申请中的3类角色网络节点，根据一定策略从网络节点表中选择.申请表中所选择的存证、修证、认证节点不能与网络节点注册授权得到的节点角色矛盾.修正节点向存证节点(工商局)、认证节点(第三方认证)广播发送请求，并等待回答.审核通过后执行分布存储过程.

4.6 合约策略

网络节点接收数据修改请求后，基于节点角色，根据请求账本上规则集，调用相关验证函数进行验算.存证节点验证数据加工是否得到授权.认证节点验证加工数据规则是否符合规范.如果审核通过，返回审核结果ok并附加本节点签名{ok:sig}.其中如果审核未通过，返回审核结果sorry并附加本节点签名{sorry:sig}，sig表示节点签名.根据系统需要，每个接收到的修改账本的节点，可以保存审核后账本信息.

制证单位将登记网络节点的返回值如图17所示：

图17 数据修改申请返回状态

1) 如果存证集合有多个节点，将返回授权结果集合AUTH,并附加相关节点的审核结果和签名AUTH={ok:sig1,ok:sig2,…,ok:sign}.

2) 如果认证集合有多个节点，将返回验证结果集合VERI,并附加相关节点的审核结果和签名VERI={ok:sig1,ok:sig2,…, ok:sign}.

发出数据更新的制证单位，在一定时间内，验证和统计存证和认证节点返回的结果.可以自定义策略确定请求申请是否通过审核.

5 结束语

为落实国家对大数据质量治理战略部署，湖北省政务大数据中心逐步实施基于区块链技术，应用修证链、存证链和认证链实现3边数据治理.研究并应用实现修证方(数据治理方)、存证方(数据所有方)与认证方(第三方监督)三方角色，构建三方数据处理互信机制，将现有数据治理独立记账方式，升级为修证、存证和认证3种角色协作的即时、同步合约复核机制.突破单点同源异步计算架构中信任度不足的问题.构建以规则为核心，在数据治理和服务过程中增加第三方认证子链，打造多参与方规则验证的共识算法，使数据生产方和数据所有方对“数据”和“价值”达成一致性共识，保证数据所有权方对数据再加工的监控、数据加工的可溯源性.同时，增加数据规则验证的第三方认证评估客观性，保证数据分享与再加工的规范化标准化.从而保证数据源与数据加工的可查、可控、可追溯，实现数据加工的规范化、标准化，推动湖北省大数据治理标准化能力的提升.