CN116561228A - 基于工程档案单套制归档***及方法 - Google Patents

Abstract

本公开提供一种基于工程档案单套制归档***及方法，包括业务层，用于识别能源行业文档管理的业务环节，所述业务环节用于管理基于文件生命周期的流程关系；资源层，用于区块链的链上资源内容与结构管理，存储有各类文件和档案资源；平台层，包括企业文件与档案管理平台，连接所述业务层和所述资源层，集成所述业务层中可上链的业务，链接所述资源层中各类文件和档案资源；监管层，用于对所述平台层的文档管理中的各类管理对象和活动进行识别和监管，确保整个文档管理活动处于安全和可感知状态；区块链，用于将需要上链的各类信息进行计算、打包、组装、发布，并按照业务时序组成区块链用于数据管理。

Description

基于工程档案单套制归档***及方法

技术领域

本公开涉及区块链技术领域，尤其涉及一种基于工程档案单套制归档***及方法。

背景技术

国外学者和实践部门在区块链领域的研究和应用起步相对较早，他们最先利用区块链技术去解决档案管理中的真实性和完整性保障问题。在这一阶段的区块链电子档案项目主要聚焦于档案馆内部维护档案资源的真实性和完整性，尚没有完全发挥出区块链面向多主体、分布式、强信任、可溯源的技术优势。

随着区块链技术在金融、贸易、物流、食品溯源等多个领域应用的初步落地，国内开始考虑在文档领域应用区块链技术，一些大型企业开始“试水”区块链应用。这一阶段的区块链应用实现了与前端业务***或后端数字档案馆***的初步集成，基本发挥出了区块链的“透明、可溯源、不易篡改”的技术特点。但业务场景主要停留在企业单主体范围内，对于区块链通过多主体的参与来保证可信性的优势体现不足，对电子档案全生命周期管理的覆盖还有提升空间。

公开于本申请背景技术部分的信息仅仅旨在加深对本申请的一般背景技术的理解，而不应当被视为承认或以任何形式暗示该信息构成已为本领域技术人员所公知的现有技术。

发明内容

本公开实施例提供一种基于工程档案单套制归档方法及***，至少能够解决现有技术中的部分问题。

本公开实施例的第一方面，

提供一种基于工程档案单套制归档***，包括：

业务层，用于识别能源行业文档管理的业务环节，其中，所述业务层包括在文件与档案管理业务中具备上链可行性的业务环节，所述业务环节用于管理基于文件生命周期的流程关系；

资源层，用于区块链的链上资源内容与结构管理，存储有各类文件和档案资源；

平台层，包括企业文件与档案管理平台，连接所述业务层和所述资源层，集成所述业务层中可上链的业务，链接所述资源层中各类文件和档案资源；其中，所述平台层采用了业务***、电子档案管理***和数字档案资源长期保存***三类***进行前后衔接；

监管层，用于通过采用访问控制管理、审计跟踪日志记录、文件保障技术对所述平台层的文档管理中的各类管理对象和活动进行识别和监管，确保整个文档管理活动处于安全和可感知状态；

区块链，用于将需要上链的各类信息进行计算、打包、组装、发布，并按照业务时序组成区块链用于数据管理。

在一种可选的实施方式中，

所述业务层还包括收业务环节、管业务环节、存业务环节以及用业务环节，其中，

所述收业务环节，包括将电子文件从所述业务层捕获或者归档到所述电子文件管理***，其中，所述收业务环节包括捕获环节和归档环节，所述捕获环节用于获取所述电子文件及所述电子文件对应的元数据；所述归档环节用于将所述电子文件及所述电子文件对应的元数据的管理权限向档案部门提交；

所述管业务环节，包括捕获登记、分类组织、鉴定处置、统计管理、存储保管电子文件中至少一种；

所述存业务环节，包括将所述电子档案在档案管理***中复制、备份、更新、迁移中至少一种；

所述用业务环节，包括通过档案管理***对电子文件和电子档案进行检索。

在一种可选的实施方式中，

所述平台层包括业务***、电子档案管理***和数字档案资源保存***，其中，

所述业务***，用于在电子文件形成时自动或半自动开展鉴定、整理工作，实施预归档；

所述电子档案管理***，用于对电子文件、电子档案进行捕获、维护、利用和处置，

所述数字档案资源保存***，用于将数字档案资源保存在可信数字仓储***。

在一种可选的实施方式中，

所述资源层还用于将电子文件及所述电子文件对应的元数据通过至少三种方式进行上链：

单独通过Hash值上链；

Hash值、所述电子文件对应的元数据上链；

以及Hash值、所述电子文件及所述电子文件对应的元数据都上链。

在一种可选的实施方式中，

所述区块链是以区块形式组织的链式数据结构，使用哈希指针的链表，其节点为多个区块；

一个区块由区块头和区块体组成；所述区块头用于存储上一个区块的哈希值与当前区块的哈希值以及区块大小、时间戳区块元数据信息；

所述区块体存储与业务相关的交易记录，在交易账本的每一条记录中，包含每一次操作的内容，同时还存储了状态账本前后变化的哈希值。

在一种可选的实施方式中，

交易记录由用Merkle树的结构方式进行组织并计算哈希值：

将Merkle树中任何变动的底层数据，传递到其父节点的哈希值变化，一直到根节点的哈希值变化；

将区块体中的数据分组进行哈希运算，向上不断递归运算产生新的哈希值并存储在区块头中；

当区块体中的某一条交易数据被篡改时，区块头中所存储的Merkle根哈希值发生变化，确定被篡改区块并定位有问题的交易记录。

本发明实施例的第二方面，

提供一种基于工程档案单套制归档方法，所述方法应用于前述中任一项所述的基于工程档案单套制归档***，所述方法包括：

识别能源行业文档管理的业务环节，其中，所述业务环节用于管理基于文件生命周期的流程关系；

实现对区块链的链上资源内容与结构管理，存储各类文件和档案资源；

集成所述业务层中可上链的业务，链接所述资源层中各类文件和档案资源；

通过采用访问控制管理、审计跟踪日志记录、文件保障技术对所述平台层的文档管理中的各类管理对象和活动进行识别和监管，确保整个文档管理活动处于安全和可感知状态；

将需要上链的各类信息进行计算、打包、组装、发布，并按照业务时序组成区块链用于数据管理。

本公开实施例的第三方面，

提供一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为调用所述存储器存储的指令，以执行前述所述的方法。

本公开实施例的第四方面，

提供一种计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现前述所述的方法。

基于业务管理要素、***运行要素和生命周期要素的综合考虑，创造性地提出了“单套制”归档管理的区块链存证通用模型。该模型基于业务层、平台层、资源层、监管层(合约层)和区块链层五个板块，基于五个板块之间的相互配合，能够实现业务流、信息流、文件流的顺利运转。

除此之外，还叠加了区块结构，通过区块结构的设计做到了关键管理信息和规则的集约，通过扩展还可以做到跨业务、跨部门、跨***的方案建设，从而将内部信任扩展出来成为公共信任，为文档管理单套制运行管理提供信任层面的保障支持。

附图说明

图1为本公开实施例基于工程档案单套制归档***的结构示意图。

图2为本公开实施例区块链的基本数据结构示意图。

图3为本公开实施例文档区块链的区块与账本结构图。

图4为本公开实施例全树结构模型与状态Merkle树的结合示意图。

具体实施方式

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

下面以具体地实施例对本公开的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

为了更方便理解本申请的技术方案，先对相应名词进行解释：

单套制：电子档案“单套制”是指对于由电子设备生成的源生电子文件，在进行归档时只保存电子档案，而不再生成和保存纸质档案的归档制度。

四性检测：是指对电子档案的真实性、可用性、安全性、完整性进行检测，这是确保电子档案凭证价值、查考价值和保存价值的关键。

需要说明的是，本申请实施例的方法可以应用于多个技术领域，例如煤化工行业，还可以应用于其他领域，本申请对方法所应用的具体技术领域并不进行限定。

图1为本公开实施例基于工程档案单套制归档***的结构示意图，如图1所示，所述***包括：

业务层，用于识别能源行业文档管理的主要业务环节，其中，所述业务层是指在文件与档案管理业务中具备上链可行性的业务环节，业务环节将主体基于文件生命周期的流程关系进行编排；

为此主要需要识别组织机构文档管理的主要业务环节。从机构电子文件从形成到长期保存的生命周期中经历的***类型角度来看，组织机构电子文档管理大致可分为“收、管、存、用”四个主要业务环节。

在一种可选的实施方式中，

所述业务层还包括收业务环节、管业务环节、存业务环节以及用业务环节，其中，

所述收业务环节，包括将电子文件从业务层到电子文件管理***所经历的捕获或归档环节，其中，捕获环节是指适时获取电子文件及其元数据的方法与过程；归档环节是指将具有凭证、查考和保存价值且办理完毕、经***整理的电子文件及其元数据管理权限向档案部门提交的过程；

所述管业务环节，包括电子文件在电子文件管理***或者电子档案在档案管理***所经历的管理环节，其中，电子文件管理***中的管理内容包括捕获登记、分类组织、鉴定处置、统计管理、存储保管中至少一种，电子档案在电子档案管理***中的管理内容包括存储、统计、元数据维护、处置和移交中至少一种；

所述存业务环节，包括电子档案在档案管理***的长期保存，包括复制、备份、更新、迁移中至少一种；

所述用业务环节，包括档案利用者通过档案管理***查找、利用档案信息，满足用户利用需求的行为过程，包括对电子文件和电子档案的检索利用。

在一种可选的实施方式中，

长期保存***被划分为接收、档案存储、数据管理、保存计划、存取、行政管理六大功能实体，在此之下，每个功能模块下又有详细的二级功能，基本上覆盖了“单套制”归档管理中的基本和核心环节。

六大功能模块有不同的侧重点，因而其功能实现与区块链价值的契合点也不同，需要分别进行开发和设计。以六大功能分区为基础，以区块链参与的二级功能实现为落点，构建起一张清晰、明确的区块链技术与“单套制”归档管理相结合的功能地图，促进了功能可视化，说明了***目前的功能侧重点和未来继续开发的可能性。

区块链***在文档创建、审批、编辑、归档以及档案保管、借阅、销毁的一系列流程中设置了认证节点，通过将文档信息和流程信息及时上链存证和认证，实现了文档管理流程的全程可追溯。

平台层，包括企业文件与档案管理平台，连接业务层和资源层，向下集成可上链的业务，向上承接各类文件和档案资源；其中，所述平台层采用了业务***、电子档案管理***和数字档案资源长期保存***三类***进行前后衔接，使前端控制、中期归档、后期保存得以贯通，实现了对电子文件和电子档案的全生命周期管理；

在一种可选的实施方式中，

所述平台层包括业务***、电子档案管理***和数字档案资源长期保存***，其中，

所述业务***，是指形成或管理机构活动数据的计算机***，嵌入电子文件分类方案、归档范围与保管期限表和整理要求，在电子文件形成时自动或半自动开展鉴定、整理工作，实施预归档；

所述电子档案管理***，包括对电子文件、电子档案进行捕获、维护、利用和处置的计算机信息***，

所述数字档案资源长期保存***，包括对数字档案资源进行长期保存的可信数字仓储***。

其中，

业务***(BS)是指形成或管理机构活动数据的计算机***，常见的有办公自动化***及其他业务***。办公自动化***和其他业务***应当嵌入电子文件分类方案、归档范围与保管期限表和整理要求，在电子文件形成时自动或半自动开展鉴定、整理工作，实施预归档。

业务***的主要关注点包括：

应能按相关要求形成、收集、整理、归档电子文件及其元数据；应内置电子文件分类方案、保管期限表等工具，支持电子文件形成或办理部门完整收集、整理应归档电子文件及其元数据；应能以单个流式文档集中记录电子文件拟制、办理过程中对其进行的全部修改信息；能按内置规则自动命名、存储电子文件及其组件，保持电子文件内在的有机联系，建立电子文件与元数据之间的关联关系；能按标准生成电子文件及其元数据归档数据包，或向归档接口推送电子文件及其元数据；能对已收集、积累的电子文件的所有操作进行跟踪、审计。

电子档案管理***(ERMS)是指对电子文件、电子档案进行捕获、维护、利用和处置的计算机信息***。电子档案管理***应当功能完善、适度前瞻，满足电子档案真实性、可靠性、完整性、可用性管理要求。

电子档案管理***(ERMS)基本功能包括文件管理配置、文件管理业务、安全管理、***管理等方面，具体包括：

应具备电子档案管理配置功能，包括分类方案管理、档号规则管理、保管期限表管理、元数据方案管理、门类定义等功能；应具备电子档案管理功能，包括电子档案及其元数据的采集、登记、分类、编目、命名、存储、利用、统计、鉴定、销毁、移交、备份、报表管理等功能；应具备电子档案安全管理功能，包括身份认证、权限管理、跟踪审计、生成固化信息等功能；应具备***管理功能，包括***参数管理、***用户和资源管理、***功能配置、操作权限分配、事件报告等功能；应具备各门类纸质档案管理功能，包括对电子档案和纸质档案同步编目、排序、编制档号等功能；应具备纸质档案数字化以及纸质档案数字副本管理功能。

数字档案资源长期保存***(TDR)是对数字档案资源进行长期保存的可信数字仓储***。数字档案长期保存技术包括封装技术、格式技术、仿真技术、再生技术、迁移技术等。因此，数字档案长期保存***(TDR)应注重完善以下功能：

确保形成可信数字档案资源；支持元数据自动获取、管理；具备完善的封装功能；确保静态存储数字档案的有效管理；迁移功能，包括格式迁移和***迁移。

平台层兼容了已有的智慧项目平台、文档管理***、OA***(综合办公管理平台)、电子签章***、数字化财务共享服务中心***电子数据，避免重复投资与建设。***关注独立性和操作便捷性，预留本***外的业务***接入本***的接口，使整个***利用率达到最高、业务流程更高效(尤其需要避免各种重复录入、重复操作)、***投入产出比最大、所有数据可以形成统一数据池以便进行数据分析，支持企业决策。

区块链档案管理平台主要由档案管理***、区块链存证***、电子文件管理***三类子***组成，其中区块链存证***包含区块链平台和电子印控平台，电子文件管理***则包含文档管理平台、交工资料平台和OCR管理平台，档案管理***则包含数字档案资源长期保存的各项功能。

***交互，

档案管理***、区块链存证***、业务***的交互主要包括两个环节——上链存证与上链认证。通过与区块链的交互，可以实现对电子文件的起草、审核、归档、共享和应用等全过程重要环节实现全程管控。

以电子文件的生成和归档两个环节为例，分析区块链、业务***及电子文件管理***的交互流程，在生成环节进行上链存证，在归档环节进行上链验证。

资源层，用于文档区块链的链上资源内容与结构管控；

所述资源层包括静态的业务原始记录、动态的各类档案管理日志记录以及各类文件或者记录的核心元数据部分；其中，

业务原始记录包括内容数据和元数据，还包括至少三种上链方式：仅Hash值上链、Hash值和电子文档元数据上链以及Hash值、电子文档元数据和内容数据都上链。

第一，静态的业务原始记录。这也是未来构成区块链状态账本的主体内容。本部分构成与业务层所代表的职能活动密切相关，该业务活动形成的具有档案意义的各类记录(包括直接的、间接的、过程的记录材料)都可以以特定的形式(原始文件或者哈希值)记录到区块链***中。

第二，动态的各类档案管理日志记录。这是构成档案区块链中交易账本的主要来源，本部分记录了文档变化的过程，通过日志的记录实现了文档变化过程的全程可追溯。

第三，各类文件或者记录的核心元数据部分。多数情况下，档案机构不会选择将原始记录直接上链，而会将其核心元数据部分(包括签名)整合后进行哈希计算后上链。不同业务的文件或者记录的元数据构成存在较大差异，这将是档案部门参与区块链需要准备的核心内容。

区块链本质上是一种信息存储***，其实现功能的方式是处理和存储数据，其核心是账本管理和交易处理。从成本的角度考虑，决定文档上链范围的是数据量，并不是所有文档业务或者不是某一项业务的所有数据都适合上链，而是要通过合理分析，最终确定上链内容。区块链档案管理平台的上链资源主要包括业务数据、元数据及相应的活动记录，其中业务原始记录可以有不同的上链方法，档案管理活动记录则将以状态账本形式存储上链，同时也从电子文件经历的***、与之相关的业务角度出发确定了适宜上链的元数据组成。

业务原始记录不同上链方式

业务原始记录包括内容数据和元数据，在以往的区块链应用实践中，主要形成了以下几种上链存储方式：

(1)上链方式A：仅Hash值上链；

(2)上链方式B：Hash值和电子文档元数据上链；

(3)上链方式C：Hash值、电子文档元数据和内容数据都上链。

下表为对不同上链方式在应用情况、成本、适用对象、真实性保障、长期性保障方面的对比：

整体上看，现阶段区块链平台仅适合存储电子文档的哈希值和部分元数据，并不适合存储内容数据。究其原因主要在于：(1)功能定位需要。现阶段区块链技术在文档管理中的定位是主要是增强真实性和完整性保障，而并非“数据备份”；(2)性能考虑。利用现阶段的区块链平台进行大量数据的处理既不经济也不现实，囿于现阶段区块链技术成熟度，如果将内容数据上链，不仅增加了各区块链节点的数据存储和处理的压力，而且可能带来极其高昂的计算代价；(3)安全原因。由于安全原因，不能不加以鉴定就将内容数据完全上链。

在电子文档管理的场景下，电子文档操作的日志记录和与电子文档可信认证相关的元数据是核心上链内容，而交易账本和状态账本就分别对应了电子文档操作的日志记录和与电子文档可信认证相关的元数据记录。交易账本存储的是对电子文档创建、更改的操作记录与说明，是电子文档变化的动态记录；状态账本是电子文档当前的状态和信息记录，是指向资源文件的静态数据。其中，电子文档的哈希值是区块链功能实现的核心，是电子文档真实性、完整性认证的关键工具，通过对电子文档资源“动静结合”的记录来实现对电子文档的共识可信、全程追溯和真实安全的有效支撑。

对于电子文档而言，为了维护同一业务活动中形成的电子文档的有机关联，确保文档背景信息被充分理解，不能只将固化后的电子文档终稿的哈希值上链保存，必须将电子文档的不同版本的哈希值都上链。例如，文件形成过程重要节点的稿本、长期保存工作实施格式迁移形成的不同格式的格本、不同发布对象和应用场景形成的不同文本等文件哈希值需要上链保存。

对于状态账本中电子文档的元数据，为保证后续溯源查询的有效性，需要较为完整地将相关元数据上链保存。具体而言，确定需要上链保存的元数据的基本思路是：从电子文档经历的***角度出发，将不同***中形成的独特的、具有检索唯一标识、凭证意义的元数据进行上链保存；从电子文档的相关业务出发，可以将业务操作证明和业务监管的结果性信息上链保存，包括电子文档交接、“四性”检测、借阅利用、转换与迁移、处置与销毁等业务行为。

监管层，用于通过采用访问控制管理、审计跟踪日志记录、文件保障技术对文档管理中的各类管理对象和活动进行识别和监管，确保整个文档管理活动处于安全和可感知状态；

在一种可选的实施方式中，

所述监管层还用于：

前端监管，用于梳理机构职能与业务环节，对可能出现的风险点进行提前管理与预防；

中端监管，用于完善相关业务环节标准并且定时检查标准执行力度；

后端监管，用于实现电子档案的永久保存与销毁。

其中，

前端监管的核心在于充分梳理机构职能与业务环节，对可能出现的风险点进行提前管理与预防。在这一阶段，业务主体主要是文件形成者、档案管理部门以及技术部门，主要任务是搭建电子档案接收管理的环境，形成规范的配套元数据，促进电子档案顺利形成接收捕获。

对“单套制”归档管理进行监管的目的在于保障电子档案质量，维护其真实、完整、可用、安全，在信任的前提下发挥电子档案优势，使得档案管理的痛点得到针对性解决。而区块链的功能集合恰与”单套制“归档管理监管需求相匹配，其在成员管理、密钥管理、权限管理三方面的应用如下：

成员管理

平台主要通过CA体系进行身份认证，证书颁发体系从1.6版本到1.8版本进行了以下精简；

root.ca(根证书颁发机构)代表PKI体系中的信任锚。根CA是PKI层次结构中最上层的CA，用于签发证书认证机构以及角色证书准入认证机构。ECA(EnrollmentCertificate Authority)为准入证书颁发机构，该机构能够向下颁发节点准入证书ECert。ECert(Enrollment Certificate)准入证书是一种长期证书，持有ECert的节点才能够同平台链上服务交互，否则无法加入相应的Namespace。

另外，平台的ECert设计上有两种实现。持有ECert1的机构不仅拥有同区块链上服务交互的权限，还能够向下颁发TCert(Transaction Certificate)交易证书。交易证书用于实现伪匿名交易，客户发起交易的时候需携带，客户端会使用TCert相匹配的私钥对Transaction进行加密。TCert可以实现线上申请，由各个节点签发，每一条Transaction都可以用一个新的TCert进行签名，可以实现每条交易的相对匿名，但是可以由签发方审查。

此外，平台提供了证书管理的配套工具certgen，主要用来生成和管理相关的CA证书和数字证书，包括证书签发、公私钥生成、证书检查等功能。

证书签发：节点启动前需要生成一对公私钥，节点启动时各节点首先根据公钥生成自签证书，并以此生成根证书。签发子证书时可以由本节点根证书生成指定类型的子证书(ECert、RCert、TCert和SDKCert)，或者用户提供公钥给签发方，再由签发方对其签发子证书。

节点准入：新节点首先向各节点发出加入请求，链上所有VP节点根据申请节点的握手信息查询其CA公钥证书，并使用公钥证书进行签名验证，然后通过CAF表决是否允许持有该CA证书的节点加入。如果允许，则向其签发本节点的ECert证书，同时新节点也向被申请节点发放ECert证书。

证书检查：certgen提供证书检查服务，检查内容包括证书是否由CA证书签发、签名是否合法、是否为能够签发子证书的CA证书。

证书撤销：当用户个人身份信息发生变化，或者私钥丢失、泄露或者疑似泄露时，证书用户可以向CA提出证书的撤销请求，CA将把此证书放入公开发布的证书撤销列表，该列表中列举着所有在有效期内但被撤销的数字证书。

密钥管理

用户私钥在颁发时拆为两部分分别进行加密，其中一部分由机构自行托管，另一部分交由可信的第三方机构进行托管。若用户私钥丢失，首先机构在线下对用户进行身份鉴定，鉴定通过后，发起私钥找回流程。

用户自行保管完整的公私钥对，不进行备份。用户私钥一旦丢失则无法找回，机构给用户新生成私钥，并通过后台调用一份超级管理员的智能合约，将用户原有的资产划拨到新的公钥地址中。该方案依赖于以下操作：

在现有的业务合约基础上，单独设计一个超级管理员智能合约；

在用户密钥对生成时，将对应的公钥地址存储在机构数据库中，形成一个映射关系(用户账户/身份信息—>公钥地址)，这里的用户身份信息需要可以通过线下进行鉴定；

用户私钥丢失后向机构发起私钥重置申请，机构先对用户身份进行鉴定；用户新的公钥地址添加至数据库中(不删除用户原公钥地址)。

权限管理

平台采用分级的权限管理机制，进一步保障数据安全，形成了“链级管理员-节点管理员-用户”三级权限分配机制：

链级管理员：参与区块链级别的权限管理，包括节点管理、***升级、合约升级的权限控制，往往是各联盟机构指定的内部超级管理员。节点准入、***升级、合约升级这种链级别的操作权限需由联盟各机构投票决定，而不仅仅是单一主体可以主导的。具体的投票规则由各联盟机构线下协商好，并写入Genesis区块。后续若要更改需按照之前约定的规则进行一轮投票才能完成更改。链级权限管理需要借助上面提到的自治联盟组织(CAF)。

节点管理员：参与节点级别的权限管理，包括节点访问权限的控制，往往是各联盟机构指定的运维管理员。由其给各用户颁发访问证书(SDKCert)，控制用户访问SDK接口的权限，带有节点访问证书的请求才会被该节点受理。节点管理员可通过客户端颁发证书，配置用户权限表，分配用户访问SDK的权限，比如访问调用合约的权限、获取区块权限等。链级管理员默认带有节点访问证书SDKCert。

用户：普通用户，参与链上业务场景。用户可持有不同节点颁发的证书，用以向不同的节点发起交易。具体用户在对应业务场景中的权限，由上层业务***自己定义。后续平台可抽象出一系列通用的权限管理接口，供业务层更好地进行权限管理。

区块链，按照技术要求将需要上链的各类信息进行计算、打包、组装、发布，并按照业务时序组成区块链用于数据管理。

在一种可选的实施方式中，

所述区块链是以区块形式组织的链式数据结构，使用哈希指针的链表，其节点为一个个区块；

一个区块由区块头和区块体组成；区块头包含区块相关的控制信息，用于存储上一个区块的哈希值与当前区块的哈希值以及区块大小、时间戳区块元数据信息；

区块体包含具体的事务数据，存储与业务相关的交易记录，在交易账本的每一条记录中，不仅包含每一次操作的内容，同时还存储了状态账本前后变化的哈希值。

在一种可选的实施方式中，

交易记录由用Merkle树的结构方式进行组织并计算哈希值：

将Merkle树中任何变动的底层数据，传递到其父节点的哈希值变化，一直到根节点的哈希值变化；

将区块体中的数据分组进行哈希运算，向上不断递归运算产生新的哈希值并存储在区块头中；

当区块体中的某一条交易数据被篡改时，区块头中所存储的Merkle根哈希值发生变化，确定被篡改区块并定位有问题的交易记录。

区块链构造了一种以区块形式组织的链式数据结构，是使用哈希指针的链表，其节点为一个个区块。当区块中内容发生改变，该哈希值也会发生改变，从而保证了区块内容不能被篡改。此外，每个区块(除创世纪块)都保存有前一个区块的哈希值。用户只需记住最后一个区块的哈希值，就可以检测区块链上的内容是否被篡改。同一个区块中的多个数据块通过Merkle树的形式组织在一起，在区块头中存储的是根节点的哈希值。该数据结构的优点在于：只需要记住根哈希值，便可以检测出对树中任何部位的修改。在文档体系中，所有电子文档也可以按照树形结构组织，任意一个电子文档的变化都会引起根哈希值的变化，通过根哈希值的变化反映整体电子文档的变化。

区块链与其他链表的最大区别是用Hash指针代替了普通指针。当区块链上的数据本身较大，需要占用较大空间时，明显会造成一定麻烦，此时可以引入指针这一概念。当需要获取数据时，只需要按照指针所给的地址，去对应的位置读取数据即可，这样大大节省了内存空间。在实际中，为了便于程序移植性等原因，指针实际上存储的是逻辑地址而非物理地址。

图2为本公开实施例区块链的基本数据结构示意图。通常情况下，一个区块由区块头和区块体组成。区块头包含区块相关的控制信息，用于存储上一个区块的哈希值与当前区块的哈希值以及区块大小、时间戳等区块元数据信息；区块体包含具体的事务数据，存储与业务相关的交易数据(即交易账本)，在交易账本的每一条记录中，不仅包含每一次操作的内容，同时还存储了状态账本前后变化的哈希值。

图3为本公开实施例文档区块链的区块与账本结构图。图4为本公开实施例全树结构模型与状态Merkle树的结合示意图。

根据区块链的基本结构设计适合于文档领域的区块链数据结构。在电子文档管理的场景下，区块头的本块哈希值是区块的主键，作为区块的唯一标识符来使用，通过与前一个区块的哈希值相组合，可以实现区块的链式结构。区块体的交易记录中存储了对电子文档的每一次事务操作日志，记录了变化前与变化后的电子文档哈希值。交易账本中的每一项事务都记录了一条电子文档***作的日志记录，其结构一般包括文档ID、交易动作、操作用户、哈希变化值等。状态账本中则记录了电子文档实体的哈希值和元数据信息，区块链通过哈希值的变化将日志记录(交易账本)与电子文档的元数据记录(状态账本)进行连接整合，使二者成为同生同变、相互统一的有机整体。区块链中的数据完整地记录了***中的电子文档从生成、变更到销毁的全生命过程，能够对链上的业务进行有效的回溯，确保了电子文档的真实性、完整性和安全性。

交易账本与状态账本采用树形结构组织：

在区块链的技术体系中，交易记录通常用Merkle树的结构方式进行组织并计算哈希值。Merkle树是一种哈希二叉树，其叶节点用于存储数据文件，非叶节点存储的是其叶节点的哈希值。在Merkle树中底层数据的任何变动，都会传递到其父节点的哈希值变化，一直到根节点的哈希值变化。Merkle树可以用于快速归纳和校验区块数据的完整性，将区块体中的数据分组进行哈希运算，向上不断递归运算产生新的哈希值并存储在区块头中。当区块体中的某一条交易数据被篡改时，会导致区块头中所存储的Merkle根哈希值发生变化，从而快速发现被篡改区块并定位有问题的交易数据。

在电子文档管理的场景中，树形结构既可应用于交易账本，亦可以应用于状态账本。交易账本的应用与传统区块链的应用基本一致，将电子文档变更的每一条日志记录视作一个事务(或交易)，将其组织为Merkle树，计算根节点的哈希值并将其存储在区块头中，当不同节点间的区块哈希值发生不一致时，能够快速定位发生问题的区块及日志记录。在状态账本中的应用则可依托于电子文档体系的树形结构进行Merkle二叉树的设计，即将电子文档元数据记录作为普通的数据体对待。任何一个电子文档的变化，都会引起区块头中本块哈希值的变化，从而快速发现和定位发生变化的电子文档。

状态树与数字档案对象全树结构模型相结合：

数字档案对象全树模型是以树结构来集中描述展现档案资源从全宗到元数据的总体架构的模型，全树模型表达的数字档案对象模型能在最大程度符合我国档案管理原则，贴合职能分类的核心思想，符合多数机构和业务活动自顶向下逐步求精的分解方式。状态账本的业务实体对象是电子文档，而电子文档的目录体系本身可以依托于全树模型组织成为一个树形结构，因此可以基于此结构自底向上计算哈希值，最终得到根节点的本块哈希值，记录在区块头中。此外，在状态账本发生变化时，将变化前与变化后的哈希值存入与其相关交易账本的日志记录中，从而连接了状态树与交易树。

本公开实施例的第二方面，

提供一种基于工程档案单套制归档方法，所述方法包括：

识别能源行业文档管理的主要业务环节，业务环节将主体基于文件生命周期的流程关系进行编排；

向下集成可上链的业务，向上承接各类文件和档案资源；通过业务***、电子档案管理***和数字档案资源长期保存***三类***进行前后衔接，使前端控制、中期归档、后期保存得以贯通，实现了对电子文件和电子档案的全生命周期管理；

对文档区块链的链上资源内容与结构管控；

通过采用访问控制管理、审计跟踪日志记录、文件保障技术对文档管理中的各类管理对象和活动进行识别和监管，确保整个文档管理活动处于安全和可感知状态；

按照技术要求将需要上链的各类信息进行计算、打包、组装、发布，并按照业务时序组成区块链用于数据管理。

本公开实施例的第三方面，

提供一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为调用所述存储器存储的指令，以执行前述所述的方法。

本公开实施例的第四方面，

提供一种计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现前述所述的方法。

本发明可以是方法、装置、***和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本发明的各个方面的计算机可读程序指令。

本领域的技术人员应理解，上述描述及附图中所示的本发明的实施例只作为举例而并不限制本发明。本发明的目的已经完整并有效地实现。本发明的功能及结构原理已在实施例中展示和说明，在没有背离所述原理下，本发明的实施方式可以有任何变形或修改。

最后应说明的是：以上各实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述各实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的范围。

Claims (9)

1.一种基于工程档案单套制归档***，其特征在于，所述***包括：

业务层，用于识别能源行业文档管理的业务环节，其中，所述业务层包括在文件与档案管理业务中具备上链可行性的业务环节，所述业务环节用于管理基于文件生命周期的流程关系；

资源层，用于区块链的链上资源内容与结构管理，存储有各类文件和档案资源；

平台层，包括企业文件与档案管理平台，连接所述业务层和所述资源层，集成所述业务层中可上链的业务，链接所述资源层中各类文件和档案资源；其中，所述平台层采用了业务***、电子档案管理***和数字档案资源长期保存***三类***进行前后衔接；

监管层，用于通过采用访问控制管理、审计跟踪日志记录、文件保障技术对所述平台层的文档管理中的各类管理对象和活动进行识别和监管，确保整个文档管理活动处于安全和可感知状态；

区块链，用于将需要上链的各类信息进行计算、打包、组装、发布，并按照业务时序组成区块链用于数据管理。

2.根据权利要求1所述的***，其特征在于，所述业务层还包括收业务环节、管业务环节、存业务环节以及用业务环节，其中，

所述收业务环节，包括将电子文件从所述业务层捕获或者归档到电子文件管理***，其中，所述收业务环节包括捕获环节和归档环节，所述捕获环节用于获取所述电子文件及所述电子文件对应的元数据；所述归档环节用于将所述电子文件及所述电子文件对应的元数据的管理权限向档案部门提交；

所述管业务环节，包括捕获登记、分类组织、鉴定处置、统计管理、存储保管电子文件中至少一种；

所述存业务环节，包括将所述电子档案在档案管理***中复制、备份、更新、迁移中至少一种；

所述用业务环节，包括通过档案管理***对电子文件和电子档案进行检索。

3.根据权利要求1所述的***，其特征在于，所述平台层包括业务***、电子档案管理***和数字档案资源保存***，其中，

所述业务***，用于在电子文件形成时自动或半自动开展鉴定、整理工作，实施预归档；

所述电子档案管理***，用于对电子文件、电子档案进行捕获、维护、利用和处置，

所述数字档案资源保存***，用于将数字档案资源保存在可信数字仓储***。

4.根据权利要求1所述的***，其特征在于，

所述资源层还用于将电子文件及所述电子文件对应的元数据通过至少三种方式进行上链：

单独通过Hash值上链；

Hash值、所述电子文件对应的元数据上链；

以及Hash值、所述电子文件及所述电子文件对应的元数据都上链。

5.根据权利要求1所述的***，其特征在于，所述区块链是以区块形式组织的链式数据结构，使用哈希指针的链表，其节点为多个区块；

一个区块由区块头和区块体组成；所述区块头用于存储上一个区块的哈希值与当前区块的哈希值以及区块大小、时间戳区块元数据信息；

所述区块体存储与业务相关的交易记录，在交易账本的每一条记录中，包含每一次操作的内容，同时还存储了状态账本前后变化的哈希值。

6.根据权利要求5所述的***，其特征在于，交易记录由用Merkle树的结构方式进行组织并计算哈希值：

将Merkle树中任何变动的底层数据，传递到其父节点的哈希值变化，一直到根节点的哈希值变化；

将区块体中的数据分组进行哈希运算，向上不断递归运算产生新的哈希值并存储在区块头中；

当区块体中的某一条交易数据被篡改时，区块头中所存储的Merkle根哈希值发生变化，确定被篡改区块并定位有问题的交易记录。

7.一种基于工程档案单套制归档方法，其特征在于，所述方法应用于权利要求1至6中任一项所述的基于工程档案单套制归档***，所述方法包括：

识别能源行业文档管理的业务环节，其中，所述业务环节用于管理基于文件生命周期的流程关系；

实现对区块链的链上资源内容与结构管理，存储各类文件和档案资源；

集成所述业务层中可上链的业务，链接所述资源层中各类文件和档案资源；

通过采用访问控制管理、审计跟踪日志记录、文件保障技术对所述平台层的文档管理中的各类管理对象和活动进行识别和监管；

将需要上链的各类信息进行计算、打包、组装、发布，并按照业务时序组成区块链用于数据管理。

8.一种电子设备，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为调用所述存储器存储的指令，以执行权利要求7所述的方法。

9.一种计算机可读存储介质，其上存储有计算机程序指令，其特征在于，所述计算机程序指令被处理器执行时实现权利要求7所述的方法。