链上链下数据协同下的政务材料共享设计实现

2023-10-30朱俊伟张晓东

计算机工程与应用 2023年20期

王茜，朱俊伟，张晓东

上海市大数据中心应用开发部，上海 200072

1 需求分析

政务材料，指行政和政务服务过程中产生或所需的各类证照、文书、卷宗、材料所对应的文件，在现代电子政务中也主要特指各类电子化的政务材料[1]。其跨部门、跨行业互通共享，是海量政务数据的核心价值体现。现有的政务材料共享应用种类繁多、量级巨大。据统计，国内一线城市仅重点收集的电子证照类材料就达近700 种、约1.7 亿份，单日提请的使用申请超30 万次。而这些仅占常用共享材料类型的25%左右，体量占比约10%～15%。但是，这些材料往往分散存储在不同的区县、部直属单位乃至相关社会机构的分布式数据库中，存在大量通信不畅、调用困难等问题。海量增长的材料使用需求从存储、算力、传输、治理、共享使用、安全控制等各方面，给现代政务带来了资源、功能、性能的多重挑战[2]。

因此，现有政务材料共享急需解决的核心需求包括：（1）在功能上，需要实现政府多部门及相关社会群体间电子材料最大程度的共享复用；（2）在性能上，需要打造各部门间的互信互通体系，实现高性能和高安全性的海量材料数据传输；（3）在资源配置上，需要尽可能在原有政务体系上进行提升和优化，但不过度改变以往多部门分布式存储、分头管理的政务模式。这些需求，通过以往电子政务相关技术和方法难以全面解决。

区块链技术是一项具有颠覆多种传统行业潜力的新兴技术，其从最早P2P 分布式网络、交易信息加密传输、无需第三方支持的1.0区块链技术到更加通用化、模块化、可编辑化的2.0共识网络，大大提升了链上合约可容纳的业务逻辑量、携带信息量和自动化程度[3]。短短几年内，区块链技术从较单一的金融货币应用拓展到了存储共享、溯源鉴证、公评众议、资产管理、流程管理等多个应用方向，其去中心化、可追溯性、难以篡改性、可编程性、可拓展性的特点，使得其在数字资产流通、数据资源共享领域的价值日益凸显。它的产生，使得政务材料共享应用找到了解决多方信任、分布式共享、数据加密传递等问题的重要途径。各级政府开始争相引入区块链作为政务发展的前导性方向，并将其列入“十四五”期间加快政府数字化发展、提升公共服务、社会治理等数字化智能化水平、打造“一网通办”全国一体化政务的国家级重点战略计划[4]。

但是，区块链自存在以来，其传输性能和链上存储能力一直为学者们所诟病。基于多账本副本的共识算法本身已引起了大量的数据空间要求和消息传递计算的消耗；现有技术也存在大量链与原有业务系统耦合性低，线上线下共识、通信效能低，功能性能拓展方法不足等问题，导致数据的一致性、完整性受损，数据双花[5]、重复数据上链等问题时有发生，很大程度制约了材料数据的共享价值实现。哪怕是以超级账本（Hyperledger）为代表，通过减少部分交易验证节点牺牲一定去中心化能力的联盟链，其设计本身，虽一定程度加强了对性能、安全的保证，但面对海量数据的存储、查询和快速响应需求，仍会有所欠缺[6]。学者们开始寻找各类方法，对单链进行各类拓展，主要的链上优化方法包括网络结构变通[7-8]、链上性能调优[9]、共识方式变更[8]等等。这些方法虽然最大限度在某些方向上做出了提升，但无法解决根本性的瓶颈问题。同时根据蒙代尔“不可能三角”理论[10]在区块链技术领域的投射，同链中的去中心化程度、安全性和性能三者之间存在不可兼顾性，必须根据各个项目的核心需求有所偏重和取舍。Huang等人[11]为在三角中实现多方面提升，在变更共识方法的基础上提出了一种“类区块链”分布式账本BDLedger，放弃了块基于时间戳的排顺共识，实现了吞吐量的近似线性增长，但这种方法牺牲了区块链的核心账本结构，目前很难与主流区块链技术实现共通。

在单链优化方法无法全面支撑海量数据存储、传输、性能、安全各项需求的情况下，大量学者开始从链下资源协同拓展[12]和跨链资源协同[13]的方向进行尝试。大量已知应用采用了链上存储材料摘要、链下存储原文件混合存储方法以借用链下的存储空间和衔接原数据的链下管理系统，同时避免了敏感数据上链的安全性担忧；部分文献提出了链接口链下云或算力池的方法，大幅缓解了区块链的性能瓶颈，并提出链上与链下传输的方法是同时实现安全和性能的保证；文献[9]反向提出了区块链对现有“旧系统”改造的支撑方法，认为可以利用区块链的隐私保护性能连接多个原本无法相互信任的“平等”数据库，对不可见数据下发联盟计算请求，完成分布式的算力合并。还有大量应用立足于跨链技术，提出了平行区块链、多链等各类理论，以分散单链的压力。

总而言之，较之单一的链上资源优化和调整，链上链下数据协同技术将链上链下优势相融合，形成了互补效能：一方面对于区块链本身而言，可缓解现有链上的存储压力和提升访问效能，链接多个链下资源；另一方面对原有链下系统而言，可在无需上链所有数据和改变原有数据分布式存储和管理模式的前提下实现安全共享。总而言之，链上链下数据协同技术的优势在于能实现链上和链下的“共赢”。因此，越来越多的学者投入到了该技术体系的研究中。中国工程院陈纯院士甚至提出，在区块链技术全面进军各行业领域的今天，链上链下数据协同技术将成为区块链技术未来几年内的重点研究方向和支撑区块链架构落地的重要方法。

为在保留现有政务体制下分布式的材料存储和各部门分散管理机制前提下实现各部门间安全可靠、传输高效的政务材料共享应用，同时最大限度发挥区块链的去中心化和安全可信特色，提升区块链对海量数据的处理能力，推动区块链在政务领域的应用落地，本文在整体设计中采用了链上链下的数据协同技术体系，并针对该体系方法下的元数据设计、智能合约控制下的去中心化共享方案设计、基于Token令牌的访问控制方法等展开深入研究，并在政务材料共享场景落地，最终实现了共享应用在性能、安全、去中心化多方向上的提升。

2 预备知识

2.1 链上链下数据协同

链上链下数据协同（on-chain and off-chain data collaboration，OODC）又称链上链下协同访问[14]。狭义的OODC 主要指“链上存数据索引和哈希，链下存完整数据”的元数据设计和访问方法；广义的OODC 除元数据设计访问外，包含了上章性能拓展方法中的链上性能调优、链下存储算力协同拓展、部分跨链协同（部分文献将主侧链技术、多链协作技术也纳入到OODC 架构中）等多个区块链分支技术。而OODC 方案实施的重点在于：兼顾存储容量和安全的链上链下元数据设计、保证数据一致性安全性协同访问方法及访问性能提升方法。

在基于OODC的元数据设计方法上，文献[14]提出了对链下存储的原始数据进行签名后在链上验证调取的方法，避免消耗昂贵的链上存储空间；张磊等人[15]提出了云链协同的病历共享模型，为提供多索引搜索引擎，将链下原数据改造为医疗数据块统一存储在云服务器上、摘要数据块上链，但显然存在数据上云的额外开销；文献[16]将链下访问客体的访问地址和摘要值等生成索引存储在客体区块链上，但对原链下数据未采取任何增加安全或搜索性能的元数据改造。Xu等人[17]在实现基于事务的医疗链访问同时，将读取权限的访问指针及实际记录链接存储在智能合约中，以避免脱机字典攻击（offline dictionary attack）提升了安全性。

在协同访问方法上，文献[14]采用基于属性加密（CP-ABE）的数据访问方法，将跟随分布式账本发给各节点客户端；文献[16]采用了按合约功能分链的方法，分离出了一个日志子链记录了整个授权和访问过程，但由于日志链的日益扩充导致了链访问性能下降问题；但未考虑到链下访问的日志存证问题，无法对链下操作做出溯源。在一致性保证上，文献[17]通过包含用户事务哈希值Merkle树作为块主体，进而生成基于用户子链的协商一致性算法（consensus algorithm for userchain）保证数据完整性与一致性；文献[18]提出了基于预言机（Oracle）的数据真实性完整性验证机制，当有数据交互需求时，帮助链上合约在提出收集链外数据要求后对数据进行验证后反馈，但其中心化设计给区块链带来了风险，易导致信任攻击。

在提升性能和计算能力方面，文献[15]通过改进实用拜占庭共识算法，使得各节点可以更高效地达成共识，提升协同访问的资源搜索效率；文献[16]与文献[17]不约而同采用了分离单独功能的授权子链、用户子链来实施访问控制，加速同链通信；其他一些文献也提出了通过边缘计算（edge computing）实现链下分发的云资源和服务方法[19]，或其他链与AI、云计算等通过API接口算力调用式协同应用。可以看出改进原有共识算法、分离功能性子链（也称为侧链）是目前较有可行性的方法，“区块链+”融合技术也给链上链下协同技术带来了一定的拓展前景。

整体而言，上述基于OODC的理论研究尚在起步阶段，系统化、平台化、落地化的OODC方案仍需积极探索。

2.2 访问控制

传统访问控制方法主要包含基于属性（attributebased，ABAC）[15-16]、基于事务（transaction-based，TABC）[20]、基于角色（role-based，rBAC）[21]、基于信任度（trust-based，TrBAC）[22]、基于权能（capability-based，CBAC）[23]的访问控制等。表1 展示了基于区块链的相关访问方法中的核心访问语句以及对应语义解读，展现了不同方法的基本原理，其中表示主体S（也定义为访问用户User）获取到规则为P的客体O的访问权限。区块链的介入使得传统访问策略逐步向动态响应、易传递、可插拔、易编辑等与链技术更易融合的特性上靠拢。ABAC对各实体的细致化分割约束能力、TBAC基于事务的动态响应和资源保护能力、rBAC 在链上链下角色权限协同中的高对应性、CapAC基于令牌的分布式可插拔能力和抗攻击能力，都在区块链上有了长足的发展。而CapAC 方法，传输便捷，尤其是其中基于Token 令牌[24]的访问控制方法更易与OODC技术相结合，将成为本文关注的重点。

表1 不同访问策略下的访问核心语句表示和解读Table 1 Representation and interpretation of access core statements in different access control strategies

2.3 基于Token令牌的访问方法

Token的概念较为多样，有“临时”“令牌”“代币”“卡牌”等意思，在访问控制中可以看作是允许其拥有者某段时间内操作或控制计算机系统中某实体或材料权力人的一则独立消息或特殊帧[25]。有别于CapAC 中基于票据、钥匙、证书的权限控制方法，Token具有非前置性、轻量级、临时性、不可预测性的特点，非常符合政务分布式系统高安全等级、权限动态发布和更新的需求。

基于Token的访问控制方法主要通过令牌生成、真实性检验、有效性检验这三个过程实现。其中Token生成过程CreateToken可定义为：

即设主体为S访问客体为O、访问权限要求为PC、从时刻x1到x2的访问时长写入Token，并加上使用者签名Usig，赋予Uid为令牌持有人。常规操作中，Uid往往为各类实体用户或实体设备（多见于物联网类模型）。

公式（2）和（3）分别对应真实性检验、有效性检验，前者验证Token申请者的真实性，往往通过验证申请者是否属于合法用户实现；后者确认Token的有效性以及完整性，也称为策略能力验证（capability verification），部分辅以客体权力人签名验证。验证通过返回1，否则为0：

其中，Usig为使用者签名，签名函数Sig()一般指客体O的所有人O.owner的签名函数即Sig(O.owner) ；isvalid(Uid)表示Uid是合法的令牌申请用户，PT⊆PO表示主体申请的策略PT要符合客体允许的策略要求PO。实际操作中（2）、（3）往往会合并实施。

另外，Token 还拥有便捷灵活的传递（或继承）能力[26]，即：

该过程TransTokenS,O将Token从用户Uid1转移给Uid2使用。该能力非常便于政务处理中将访问消息进行传递。

2.4 智能合约下的去中心化访问

去中心化是区块链的一个核心能力。原有系统往往通过授权中心、属性中心、策略中心、控制中台等一系列中心化机构，对应完成权限授予、属性分配、策略生成、事件控制等工作，极易造成通信拥堵、单点故障、拒绝服务攻击等问题。文献[26]中讨论了多种中心化、半中心化和完全去中心化的访问控制方法，提出了通过链上智能合约完成实体注册、策略生成、策略合约化、访问合约执行等一系列操作的方法，同时认为通过链上合约实施策略统一规划、访问权限判决，节点配合完成合约策略操作更具可行性；文献[16]采用了在链下部署策略执行点、管理点、信息点，链上同步部署策略决策、策略部署、策略验证、策略存储合约的方法，但大大增加了存储资源和共识的负担；史锦山等人[27]通过事件智能合约生成一系列请求访问事件、Token，并通过Token生成事件、传递事件和使用事件取代各执行点、管理点功能，以提升去中心化能力和增加策略灵活性，但可能导致部分Token 调用冲突；宋丽华等人[28]将访问策略存储于策略合约中，并通过权限裁决智能合约（Decision-SC）链上读取策略合约的同时控制链下的策略实施点（policy handle point，PHP）实施访问，但易导致PHP单点传输负担过重。

在处理链合约与链下交互性能问题上，文献[27]提出了对token一次申请多次使用和将权限验证点分别部署到智能合约和网关上的方法；文献[28]通过在访问策略生成时提请申请Token 的方式减小链上链下传输对访问性能的影响，均值得本文思考和借鉴。

本文为进一步发挥区块链安全可信、性能拓展、去中心化的能力，首先实施了链上链下协同存储的元数据上链，再设计了链上链下分工协同的访问控制策略和基于Token设计的访问智能合约，最后辅以链上链下日志协同下的溯源机制，实现完整设计。

3 链上链下协同下政务材料共享系统设计

3.1 设计概述

项目整体根据政务需求，首先选择安全和去中心化重点保障，同时通过链上链下协同实现存储、性能、算力的拓展，运用Merkle 树结构验证数据完整性与真实性，并通过多链协同方法减少节点不断扩张和链下资源增长而引起的性能下降。

本文方法在访问控制部分撷取了各传统方法的优势，通过属性值的赋予、读取方法生成可分割实体的约束条件，运用事件触发机制推动合约执行或属性变更，主要通过基于Token令牌的访问控制传递权限规则，设置合理的触发条件和时序参数的模块化合约编写完成基于OODC的访问控制。

在性能保障上，项目拟在节点架构和合约编写中，通过区分记账（共识）节点、存证节点、轻量化节点，精简链上存储，减少资源消耗，并着重对日志存证内容、资源搜索方法、链下材料调用协同和一致性保证等相关合约进行优化和改进。

为保证安全，在合约编写上，要尽可能遵循“增加动态条件触发、最少静态合约变更”的原则，同时分离授权访问合约便于修改替换，并在合约中增加回滚、权限冲突、紧急制动方案。

链上链下协同下的政务材料共享网络架构如图1所示，主要展示区块链AC1的架构部分；左面虚线隔开的是跨链部分，在本文中不予展开。整体架构中的实体名称和承担功能如下：

图1 基于OODC的政务材料共享网络架构图Fig.1 Architecture diagram of sharing of materials related to government affairs network based on OODC method

材料索引链Index-chain1（IC1）：按时间戳顺序存储多个链上规范元数据块Ind(i)，其中i为根据上链时间戳给出的链上顺序编号。

合约控制链AC1-SC-chain（SC1）：上链阶段负责上链申请响应，调整单件材料访问策略，完成多权力人签名个人部分，保证链上元数据块Ind(i)和链下元数据Fil(i)的一致性和完整性；访问时，承担访问策略决策、属性策略辅助、环境变量监听导致的访问权限变化。除此之外，还承担合约运行中为突发攻击、冲突制定的紧急制动方案。

日志链Log-Chain1（LC1）：记录链上确权和访问日志Onchain-Log（OLog），同时存储链下元数据被访问日志的哈希值。

链下系统Off-AP（OAPF，上标F为所链接Node节点ID）：承担与材料共享相关的线下业务，如房产证办理、户籍转移业务受理应用等。记录所有成功的访问申请OAPF-Log。

链下存储Off-FF（OFF）：由原文件临时池（OPoolF）和链数据提供池（ODPF）组成。OPoolF用于临时存储从OAPF接口导入的原文件MS，ODPF存储加有数字签名和部分加密的链和链下规范元数据Fil(i)；同时记录Fil(i)生成和被访问日志ODPF-Log。

链节点NodeF（NF，为记账节点）：参与共识；上链时，负责提交本节点链接的所有带管理人签名和访问策略的上链文件申请，进行策略预判定；访问时，负责链下OAPF策略执行；收集OAPF-Log、OFF-Log，生成链下日志Off-LogF，并上传哈希值O-HasF至LC1。

轻量级节点Mobilepe（Mbpe，上标pe为所在链给所有者owner分配的接入节点编号）：不参与共识，用于所有人名下所有材料的个体策略调整管理，本人名下材料使用和授权权限转移，在本文中不做展开。

跨链单元Crosschain-Unit（CUnit）：负责链间权限映射、生成跨链索引账本，带防火墙以规避网络风险。

平行区块链AC2：包含与AC1 相同结构，用于平行拓展AC1，以保证节点大幅增加后的链性能。

整体参与架构的三主体及其相互关系概括如下：

材料管理者Mad：将所辖同一类型的材料批量发布上链，同时设置整体访问策略；对材料集TM 批量生成管理者签名，后续与所有人签名共同合成多重权利人签名Sig(i)；材料所有人Owner：可读取名下材料的整体访问策略，并基于整体策略对个体MS访问策略进行调整，同时叠加数字签名，与Mad共同生成Sig(i)。

使用用户User：通过OAPF向链递交所需的材料客体查询条件，通过访问策略获取相关客体资源。

可以看到，由于政务应用的特殊性，Mad 与Owner共同设计成了MS的权利人，对MS的上链和访问进行控制。User通过对MS进行申请，并通过合约约束获得Mad与Owner的认同，最终成为MS的实际使用人。具体设计实现，将在后续章节中按照元数据设计、上链流程、协同访问流程的顺序予以详细讲述。

3.2 元数据设计

政务材料元数据Meta(i)为原材料MS的上链规范化数据，由链上的摘要数据块Ind(i)（左面部分）和链下规范化数据Fil(i)两部分构成（右面部分）如图2 所示。两个部分元数据均包括唯一OODC 编号、数据位置、访问权限、负载（Payload，也可称内容）、时间戳等五部分必备结构。分别起到了唯一性保证、确定相互访问位置、实现加密可控访问、确定具体材料内容，和根据时间戳顺序溯源和排列多个区块的作用。

图2 链上链下元数据结构示意图Fig.2 Metadata structure schematic diagram based on OODC

3.3 数据上链流程设计

数据上链，某些文献也称客体上传[26]，本文主要指将政务材料数据按上节元数据构成方法变化为可进行链上链下查询、访问等操作的元数据过程。由于政务材料存储和管理的特殊性，上链主要由同一类型材料的管理者批量完成，在数据访问环节中根据单一材料的所有人要求进行访问策略调整。在本文的设计中，上链包括了上链前处理、元数据链上链下分类存储部分。整体方法流程如下：

步骤1预上链申请。先假设每个用户和实体均已在注册阶段进行过身份认证，并且每个使用用户已获得了链上唯一编号。TMtcode为材料管理者Mad(MS)管理下的与MS类型编码tcode一致的所有材料的集合，知MS∈TMtcode。管理者提出初始策略PreP(MS.tcode)向所在节点OFc申请上链。

步骤2上链前预判定。OFc预置了材料策略预判点（policy prejudge point，PreP），首先通过其与IC1 和SC1通信，判定该材料的有效性。首先搜索已有上链索引中是否已有该材料信息、并获取材料有效期数据，判定材料是否涉及重复上链和过期情况。接着，读取所有已上链同类型材料的整体策略集合CodeP(MS.tcode)。该信息从SC1 上的策略管理智能合约（policy administration smart contract，PA-SC）上的全策略集OnP 前期通过共识方法raft(AC1)获取。可知：

如PreP(MS.tcode)⊆CodeP则直接生成访问MS的正式整体策略集MP(MS.tcode)：

否则PA-SC 将对新策略进行合规预判以规避某些错误策略设置，确认CodeP需修改后，对MP集合进行更新（PreP和PA-SC具体讲解可参见第4章）。

步骤3数字签名和个体权限调整。在通过Mad(MS)实体验证后，SC1开始正式上链过程，SCl的签名策略合约（Sig-SC）向材料所有人Owner(MS)发送准备上链的签名邀请。按现有法规，只有获得所有人签名的材料才能被运行链上可见和后续使用，故本文实施了对客体O的所有权限主体集合(Ot1,Ot2,…,Otn)∈Φ的多重权利人签名[29]Sig(n),n为签名人数，本文中签名人为Mad(MS)和Owner(MS)。同时，允许Owner(MS)对MP(MS.tcode)进行不超出该策略的调整，即PP(MS)⊆MP(MS.tcode)，故个体策略PP(MS)最小可允许零访问，最大即直接沿用整体策略。最后，确认后获得LC1给出的链上MS唯一顺序号i，将材料个体对整体策略修改的补集P(i)，而非个体策略PP(MS)存入Ind(i)中，即：

且同时存入表示材料整体策略是否被个人修改的参数ModPi。这样设置的优势是：85%以上的所有者并不对整体策略进行修改，将大大节省以往系统单个客体的访问策略存储，同时链上合约及各节点PreP中只需存储材料的类别策略集，存储量非常有限；访问时，如快捷读取到ModPi，则无需继续读取P(i)，继而节省大量计算开销。

步骤4元数据及Merkle 树生成。将MS正式转化为访问策略补集P(i)及加密链下地址的链上Ind(i)数据格式，并为其添加多重数字签名Msig，上链在索引链IC1 上，将Ind(i)按文献[17]方法转化为Merkle树结构，便于快速访问；统一时间戳t，将链下规范结构元数据Fil(i)同时存入OFc连接的下数据提供池ODPc。

步骤5生成日志记录。ODPc上增加链下日志、链下日志哈希off-use-LogH（oLogH）和链上日志chain-Log（cLog）会在Log-Chain1（LC1）上分别增加MS上链记录用于溯源。

元数据上链流程如图3 所示，按顺序由上而下，其中链上链下交互域用灰色表示。本上链流程利用整体策略代替了大量重复个体策略进行存储，将PreP设置在节点上减少链上链下交互，并通过将补集Pi和修改参数ModPi加入Ind(i)减少共识消耗；并通过链上链下元数据、日志同步生成策略保证一致性；通过链下日志哈希上链防止链下数据篡改。

4 系统实现

系统的实施既访问控制实施环节中，参与访问控制的策略集合包括：链下整体策略集CodeP(MS.Tcode)、链上策略集合约OnP、分布式账本上个体策略补集Pi和修改参数ModPi；链下节点参与控制点包含：材料策略预判点PreP、策略执行点（policy handle point，PHP）；链上功能合约包含：策略管理智能合约PA-SC、属性管理合约（attribute administration smart contract，AA-SC）、Token生成智能合约（token creat smart contract，TC-SC）、Token真实性验证智能合约（token authenticity verification smart contract，TAV-SC）、Token有效性验证智能合约（token validity verification smart contract，TVV-SC）。

参与访问各功能点和功能合约作用如下：

PreP：上链申请时预判材料是否有效，整体策略是否有误。

PA-SC：整体策略的管理，上链时根据Pi和ModPi合成P(i)存储，访问时根据反向方法生成PP(i)。

PT-SC：申请访问时，读取PP(i)和相关参数，实时生成Token；验证完成后传输Token 至PHP；临时Token销毁。

AA-SC：包含所有属性{attr}，帮助TVV-SC 判定Token是否符合加入属性的规则要求。

TAV-SC：实体唯一身份验证、各类签名验证等。

TVV-SC：确认Token权限是否有效。

PHP：解析Token 中携带的信息，私钥加密材料地址，实施访问。

模型实施方法包含以下步骤：

步骤1用户提交事务r触发材料检索语句生成。User通过链下应用系统OAPa首先向节点Na发送检索语句，索引账本关键词kword中满足条件Cond1 的J个材料或材料组索引为,j为符合要求的材料编号，得：

其中，kword.attr表示kword中的多个属性值attr。

步骤2个体访问策略生成。根据每个Ind(j)的材料类型向SC1 上PA-SC 申请获取整体策略MP(j)=MP(Ind(j).Tcode)，同时读取Ind(j).P(j)，获得j的访问策略PP(j)，可知：

步骤3事务时间区间控制下的资源令牌生成。对每个客体j，读取访问权限rPj，根据公式（1），生成该事务申请访问的客体元数据Mata(j)对应的Token(j)，其中被取代为ttrend-systime，其中systime 为现在时间戳，trend 参数为事务r结束时间，可后期由从环境（environment）读取，rPj表示本次事务中对客体j申请的访问策略。令牌由TC-SC 合约生成后暂存该合约内。改写公式（1）得公式（11）：

步骤4真实性和有效性验证。合并执行公式（2）和（3），即：

首先由TAV-SC向链上合约RC1确认事务r是否合法，再对事务发起人签名USigr进行验证；接着，根据现有政策规定，所有材料使用需获取所有人的确认。SCl的Sign-SC 向材料所有人{ }Owner(j) 进行去重操作生成Ownerlist集合，使得对所有人重复的材料仅需签名一次；最后，TVV-SC参照基于属性的访问控制方法读取AA-AC中的O.attr，及事务中获取环境条件trattr符合设定相关环境属性EVAttr，定义公式（12）中rPj⊆PP(j)的判定方法如下：

步骤5返回资源令牌和链下资源获取。User 获取令牌后将Ind(j)中的链上地址Ad解密；接着，将带有Usig、Uid、控制者签名Csig的令牌认证结果CToken一起发送给符合要求的Meta(j)所在的链下节点OFc的策略执行点PHPc；PHPc根据CToken 再次进行身份和签名验证，并通过地址验证和Fil(j)哈希验证确认链下文件未失效和未篡改，将Fil(j)所在Fc的链接地址明文、原文件密文点对点传输至Uid，并通过PHP 实施其对链下资源Fil(j)的访问。事务结束后访问令牌由于超出ttrend-systime时间导致自动失效。未采用文献[26]中将Token一次性申请后存储在cookie、外部存储里的方法，是为了避免匿名攻击、方便Token 修改撤销，从而进一步提升安全性。

步骤6记录访问日志。文件操作日志与上链一致，会分链下申请节点日志哈希oLogHA、链下文件读取节点日志哈希oLogHC和链上日志chain-Log部分，分别存入LC1。

步骤7（选用流程）转移授权访问。为增强模型的灵活性，Token 被允许Uidj通过点对点传递的方法，交给信任用户Permitidj使用，期间需要进行公式（2）中的真实性验证以确认其真伪及有获取该令牌的资格，即：

该方法在本设计模型中，主要适用于材料委托授权，如将所有人的材料使用权限传递给代理人、部门将企业相关材料权限传递给下属子单位等。基于传递获得的Token会专门生成Token转移日志记录Trans-log。

步骤8（选用流程）Token 撤销。为增强本设计的灵活性，Token 被允许Uidj通过点对点传递的方法，交给信任用户Permitidj使用，期间需要进行公式（2）中的真实性验证以确认其真伪及有获取该令牌的资格，即：

撤销方法统一由链上PT-SC 发出，故需要其签名SCSig；td为要求撤销时间，往往设置为当前系统时刻。在本设计中撤销方法主要用于配合发现临时访问错误后的操作；Token传递语句后选择关闭原用户访问；紧急消除越权访问等安全隐患等。

上述访问控制流程如图4所示，设计通过智能合约对策略进行管理、对访问Token 进行生成和验证；通过控制每个置于共识节点的PreP进行策略预审、PHP执行线下数据访问策略。在保证安全、去中心化控制的基础上，进一步减少了链上链下通信以及共识消耗。

图4 链上链下数据协同下的访问控制流程Fig.4 Access control flow chart based on OODC

5 应用验证

本章将设计中对安全保证、去中心化能力、性能提升三方面的设置和方法进行了汇总，并将各自的贡献成效进行了展示，如表2 所示。可知，本文对三类方向实施了多个卓有成效的方法，并重点在改进性能方面作出了提升。在多个方法中，基于链上链下元数据和策略参数存储方法、基于智能合约及各共识节点控制链上链下访问、基于Token 的各类安全性灵活性设置，对整体设计的性能提升起到了重要作用。

表2 本文相关设置或方法和对应贡献成效表Table 2 Proposed settings or methods and corresponding resulting contributions

其次，对实际搭建的性能展开测试。现平台环境为：6 个华为联盟链节点，其中共识节点2 个，验证节点4个。计算资源为2台鲲鹏架构虚拟机，每台虚拟机配置为32vCPU、64 GB 内存，操作系统为64 位华为EulerOS 2.8。采用Raft 共识机制，golang 编写智能合约，链应用层利用java语言sdk接口方式来与区块链平台集成进行数据上链和查询交互操作。

图5（a）中比较了不同链上链下数据存储方法链上生成索引块和生成链下数据平均总时延。可知本文方法较之文献[16]ABAC 方法一直处于优势，但在并发50～150次间，较之文献[28]同样基于令牌的方法无明显优势，但在并发超出150 次后较之文献[28]优势明显放大。究其原因，本文由于增加了管理者签名步骤，在并发增加后本文链上仅存储同类型整体策略和减小Index块会逐步导致性能改进优势放大，使得高并发时的时延上升趋势平缓。

图5 不同模型的上链、访问平均延时值比较Fig.5 Comparison of average time delays in meta data creation and access control steps of different models

图5（b）中记录了ABAC[16]、CapAC[25]与本文访问策略中不同并发访问次数下的平均访问时延值比较。本文方法较之其他方法从并发数为100 后一直处于优势地位，且在200～300 阶段时延增幅仅为文献[16]方法的47.3%。这得益于方法中各类提升共识效能、减少链上链下通信次数、基于Token的灵活访问控制机制等。

最后该设计在具体实施中，目前已实现政府部门内核发的身份类、证明类常用材料的初始化上链，并通过区块链链接至多个政府对外办事机构的办事系统，并同时支持公民通过轻量级节点上链进行本人名下的材料整理、隐私设置和共享许可签名，构建出一个链上链下统一的电子材料共享应用体系。在多个事务办理中针对非政府核发材料，实现了用户首次办件材料一次提交上链、多次复用、多部门共享。同时针对用户管理，划定了符合项目管理规范的开发人员、链管人员、应用运维人员三类不同角色人员，对链上链下进行协同化分工管理，具体安排见表3，进一步确保整体正常运转的情况下保护数据安全。目前系统已进入初始运转阶段，并纳入“一网通办”政务体系予以实施。