CN116304265A - 一种基于区块链的电子档案管理方法及系统 - Google Patents

Abstract

本申请提出了一种基于区块链的电子档案管理方法及系统，涉及区块链技术领域。一种基于区块链的电子档案管理方法包括：应用区块链管理电子档案，根据电子档案管理各业务环节梳理和明确上链信息；根据应用目的、存储空间、数据大小及保密性要求，选择电子文档全文和/或哈希值、全部和/或部分元数据的不同组合方式进行上链；由至少两个电子文档组成电子档案并选择电子文档哈希值上链的，则以单个电子文档为单位进行哈希函数运算后分别上链；根据电子文件全生命周期管理需要，梳理电子文件和/或电子档案发生变化的业务环节，对变化的元数据、电子文档作为上链信息进行存证。能够从源头确保电子文件真实性，并对其生命周期全过程进行管控。

Description

一种基于区块链的电子档案管理方法及系统

技术领域

本申请涉及区块链技术领域，具体而言，涉及一种基于区块链的电子档案管理方法及系统。

背景技术

随着当前数字经济快速发展，计算机技术的广泛应用使电子文件大量生产，电子文件归档管理相较于传统档案工作重要地位凸显。但由于电子文件所特有的非人工识读性、信息与特定载体之间的易分离性、信息的易变性等特点[1]，长期以来，电子文件真实性保障成了困扰档案部门归档和管理电子文件的一大难题。

根据ISO15489—2016《信息与文献—文件管理》有关文件管理原则，文件管理的质量目标在于提供“权威文件”，即具有真实性、可靠性、完整性、可用性特点的文件。电子文件真实性是电子文件价值实现的基础和前提。当前电子文件真实性保障在国内并没有统一标准与做法，除基本的管理手段外，主要采用数字摘要、电子签名等技术来实现。

数字摘要(哈希)是利用哈希算法的单向性、抗碰撞性等特点，将任意大小的电子文件映射为较小的、固定长度的值(哈希值)，并进行比对的一种方法。数字摘要应用于电子文件归档中，普遍做法是电子文件在业务系统办理完毕后，触发归档操作，由业务系统归档模块将电子文件及其元数据打包封装，形成归档信息包，然后调用哈希算法生成哈希值，通过WebService或中间库等方式将哈希值传输至电子档案管理信息系统(以下简称“档案系统”)，并将归档信息包通过FTP、HTTP等方式传输至档案系统。档案系统再次调用哈希算法对归档信息包进行计算，重新生成哈希值与业务系统传输过来的哈希值进行比对，确认二者是否一致。

哈希算法只是一种在计算机领域中用于确认消息完整性的单向散列算法，通过对比散列值可判断两条消息是否一致，这种技术对辨别篡改非常有效。但在有些情况下，即便能够检查出消息未被篡改也是没有意义的。例如发生消息与其散列值一并被截取、篡改并重新传输的情况，或者攻击者伪装成业务系统向档案系统发送消息及其散列值时，哈希算法是无法检查出来的。因此，这种数字摘要方法在电子文件归档中，仅可在单位内部结合其他安全技术共同保证电子文件真实性。否则，归档电子文件依然存在被篡改的风险，特别是外来电子文件，若无法验证其来源真实性则无法保证电子文件真实性。

在上述方法的基础上，为了进一步验证电子文件来源真实性，基于非对称密码体制的电子签名可以弥补数字摘要的不足。电子签名是在以计算机文件为基础的现代事务处理中，采用电子形式的一种签名，以防源点或终点抵赖的鉴别技术。电子签名应用于电子文件归档中，电子文件在由业务系统打包封装成归档信息包后，调用非对称加密算法，用私钥进行签名，或先调用哈希算法生成哈希值，再用私钥对哈希值进行签名，然后将签名结果回写入归档信息包，通过FTP、HTTP等方式传输至档案系统。档案系统同样调用非对称加密算法，用公钥进行解签名，如果顺利解开，则表示签名验证成功。如果业务系统使用了哈希算法，档案系统解签名后得到归档信息包的哈希值，还需再调用同样的哈希算法对原归档信息包进行哈希运算，重新生成哈希值与得到的哈希值进行比对，比对成功则表示验证通过。

由于非对称加密体制的特点，电子签名在保障电子文件真实性上与数字摘要方法相比具有明显优势。发送方使用私钥签名，接收方使用公钥验证，既能保证消息的完整性，又能保证消息的抗否认性。电子签名是在当前电子文件归档工作中解决真实性问题的一种可选方法，但这种方法在满足档案信息完整性、保存格式长期性等需求方面却存在着弊端。例如，在签名处理方式上，电子签名通过版式文件自带的签名域实现，容易损坏文件信息结果；在真实性验证上，电子签名使用有期限的数字证书，验证需在证书有效期内进行，一般期限较短；在长期保存格式转换时，电子签名需要对转换后的电子文件进行重签名；在全生命周期管理时，电子签名不便证明该电子文件全生命周期的管理过程；等等。

区块链是一种链式数据结构，链上的每个数据单元(数据区块)按照时间顺序依次相连，并以密码学方式保证其不可篡改和不可伪造。区块链同时存储在多个节点上，也称为分布式账本。自2009年比特币应用区块链技术至今，经过十多年的发展，区块链去中心化、不可篡改、可编程等特点已被人们所熟知。在档案业务场景下，区块链除了可像电子签名一样解决电子文件真实性问题外，还可在满足信息完整性、保存格式长期性等需求方面，帮助回避电子签名的弊端。例如，在处理方式上，区块链通过分布式账本记录“交易”来保证电子文件真实，不涉及电子文件信息结果；在验证期限上，区块链无限制；在长期保存格式转换时，区块链对转换行为作一笔“交易”即可；在全生命周期管理时，区块链将多笔“交易”串联起来，可追溯该电子文件生命周期管理全过程。因此，区块链技术在电子文件真实性保障方面与电子签名相比，提供了更好的解决方案，促使试点单位积极探索和实践。目前，立足于某一行业或某一集团型企业为档案业务场景而自建区块链的首数中国石化。中国石化自2018年初即开始了对区块链技术平台的选型和技术验证，搭建区块链网络，开发存证合约，基于电子档案存证的需求对相关资产进行了定义。但现有区块链较多关注于电子文件的档案系统管理阶段，仅将电子文件归档后的数据上链，也只能保证该电子文件在档案系统管理阶段的部分行为可信，不能保证它在业务系统形成之初的真实可靠。同时，现有区块链仅存证了档案系统关于电子文件接收、整理、巡检、利用等几个环节数据，其他可能造成电子文件改变的环节数据并未涉及，电子文件真实性在长期保存阶段可能存在着缺陷。

发明内容

本申请的目的在于提供一种基于区块链的电子档案管理方法，其能够向前端业务系统延伸，从源头确保电子文件真实性，并对其生命周期全过程进行管控，形成设计方案。

本申请的另一目的在于提供一种基于区块链的电子档案管理系统，其能够运行一种基于区块链的电子档案管理方法。

本申请的实施例是这样实现的：

第一方面，本申请实施例提供一种基于区块链的电子档案管理方法，其包括应用区块链管理电子档案，根据电子档案管理各业务环节梳理和明确上链信息；根据应用目的、存储空间、数据大小及保密性要求，选择电子文档全文和/或哈希值、全部和/或部分元数据的不同组合方式进行上链；由至少两个电子文档组成电子档案并选择电子文档哈希值上链的，则以单个电子文档为单位进行哈希函数运算后分别上链；根据电子文件全生命周期管理需要，梳理电子文件和/或电子档案发生变化的业务环节，对变化的元数据、电子文档作为上链信息进行存证。

在本申请的一些实施例中，上述当电子档案管理过程中生成了新的电子文档，应作为此电子档案的组成部分进行上链。

在本申请的一些实施例中，上述还包括：当业务系统不具备信息上链条件时，初始上链的业务环节变为文件接收，已归档保存的电子档案根据实际需要决定是否进行信息上链。

在本申请的一些实施例中，上述还包括：初次上链元数据主要包括文件实体元数据和业务实体元数据，其中，文件实体元数据包括文件题名、文号、责任者，业务实体元数据包括行为时间、行为描述，后续上链元数据主要包括新增业务实体元数据，以及发生变化的文件实体元数据。

在本申请的一些实施例中，上述还包括：对元数据进行明文上链，对涉密和/或具备泄密风险的元数据采用哈希值上链。

在本申请的一些实施例中，上述还包括系统交互：业务系统与区块链系统交互，将上链信息通过存证接口传输给区块链系统，区块链系统向业务系统返回存证结果；

业务系统与电子档案管理信息系统交互，将归档电子文件及其唯一标识通过归档接口传输给电子档案管理信息系统，电子档案管理信息系统向业务系统返回接收结果。

在本申请的一些实施例中，上述还包括：电子档案管理信息系统与区块链系统的交互包括，通过验证接口验证归档电子文件真实性，将电子文件接收、整理和电子档案转换、迁移、鉴定、处置等业务环节新增或更新的元数据及电子文档或其哈希值上链存证，通过追溯接口查询电子档案全生命周期管理状态。

第二方面，本申请实施例提供一种基于区块链的电子档案管理系统，其包括梳理明确模块，用于应用区块链管理电子档案，根据电子档案管理各业务环节梳理和明确上链信息；

组合上链模块，用于根据应用目的、存储空间、数据大小及保密性要求，选择电子文档全文和/或哈希值、全部和/或部分元数据的不同组合方式进行上链；

电子文档上链模块，用于由至少两个电子文档组成电子档案并选择电子文档哈希值上链的，则以单个电子文档为单位进行哈希函数运算后分别上链；

存证模块，用于根据电子文件全生命周期管理需要，梳理电子文件和/或电子档案发生变化的业务环节，对变化的元数据、电子文档作为上链信息进行存证。

在本申请的一些实施例中，上述包括：用于存储计算机指令的至少一个存储器；与上述存储器通讯的至少一个处理器，其中当上述至少一个处理器执行上述计算机指令时，上述至少一个处理器使上述系统执行：梳理明确模块、组合上链模块、电子文档上链模块及存证模块。

第三方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如一种基于区块链的电子档案管理方法中任一项的方法。

相对于现有技术，本申请的实施例至少具有如下优点或有益效果：

档案系统或浏览器访问区块链，依据电子档案ID读取其业务处理过程，可展现电子档案整个生命周期中每个致其改变环节的操作记录，追溯各阶段状态。由此可知，一份电子档案是由哪个业务系统形成的，经历了怎样的处理，发生了哪些改变，由谁改变，改变的结果如何等等。上链数据是应用区块链系统存证的核心。区块链通过数据上链存证来保证该数据来源和变动历史的可信性。因此，梳理电子文件在各系统管理阶段可能导致电子文件及其元数据发生变化的环节，以元数据记录其变化方式进行存证的过程十分关键。在系统需求分析阶段即对电子文件在业务系统和档案系统两个管理阶段经历的各个环节进行了认真梳理，明确了每个系统对电子文件进行管理的哪一个环节应当有记录和记录哪些元数据，哪些应当是原始记录，哪些可以是哈希记录。同时说明这些记录的上链方式、ID在其中的关键作用等。这种做法比之前增加了多个关键环节的上链数据，可以完整地为电子文件存证全生命过程信息。

附图说明

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

图1为本申请实施例提供的一种基于区块链的电子档案管理方法步骤示意图；

图2为本申请实施例提供的一种系统关系示意图；

图3为本申请实施例提供的一种传统PBFT流程示意图；

图4为本申请实施例提供的一种改进的QBFT流程示意图；

图5为本申请实施例提供的一种系统集成功能示意图；

图6为本申请实施例提供的一种交易处理流程示意图；

图7为本申请实施例提供的一种基于区块链的电子档案管理系统模块示意图；

图8为本申请实施例提供的一种电子设备。

图标：10-梳理明确模块；20-组合上链模块；30-电子文档上链模块；40-存证模块；101-存储器；102-处理器；103-通信接口。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

需要说明的是，术语“包括”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的各个实施例及实施例中的各个特征可以相互组合。

实施例1

对等网络peer-to-peer network

一种仅包含对控制和操作能力等效的节点的计算机网络。

区块链blockchain，一种在对等网络环境下，通过透明和可信规则，构建不可伪造、不可篡改和可追溯的块链式数据结构，实现和管理事务处理的模式。

联盟链consortium blockchains，由多个互相已知身份的组织之间构建的区块链。

交易transaction

从一个节点提交上链请求到达成共识并进行存储的过程。每个交易可能包含多次上链请求。

账本ledger，区块链中分布式数据的存储机制，通过不同节点对账本的共同记录与维护，形成区块链系统中数据的公共管理、防篡改、可信任的机制。

节点node，在区块链网络中，将其连接到一个或多个其他实体的实体。

共识机制consensus mechanism，在区块链系统中实现不同信任主体节点之间建立信任、获取权益的数学算法，提供给分布式网络参识节点以用于确认交易动作引起的账本中的状态数据变化，并且能够达成最终一致性。

智能合约smart contract，一套以数字形式定义的承诺，包括合约参与方可以在上面执行这些承诺的协议，它是一种用计算机语言取代法律语言去记录条款的合约。

哈希函数hash function，是对不定长的输入产生定长输出的一种单向函数，具有错误检测能力。

哈希值hash value，通过哈希函数运算生成的固定长度的字符串。

电子文档electronic document，归档电子文件最小的文件单元，可以是一个独立的自然件，也可以是组合电子文件中的某一自然件或某一自然件的附件，一般以一个独立的计算机文件形成存在。

AES：高级加密标准(Advanced Encryption Standard)

API：应用编程接口(Application Programming Interface)

BFT：拜占庭容错(Byzantine Fault Tolerance)

CA：身份认证授权(Certificate Authority)

DDoS：分布式拒绝服务(Distributed Denial of Service)

ECC：椭圆曲线加密(Elliptic Curve Cryptography)

HTTP：超文本传输协议(Hyper Text Transfer Protocol)

MD：消息摘要(Message Digest)

PKI：公钥基础设施(Public Key Infrastructure)

RPC：远程过程调用(Remote Procedure Call)

SDK：软件开发工具包(Software Development Kit)

SHA：安全哈希算法(Secure Hash Algorithm)

请参阅图1，图1为本申请实施例提供的一种基于区块链的电子档案管理方法步骤示意图，其如下所示：

步骤S100，应用区块链管理电子档案，根据电子档案管理各业务环节梳理和明确上链信息；

步骤S110，根据应用目的、存储空间、数据大小及保密性要求，选择电子文档全文和/或哈希值、全部和/或部分元数据的不同组合方式进行上链；

步骤S120，由至少两个电子文档组成电子档案并选择电子文档哈希值上链的，则以单个电子文档为单位进行哈希函数运算后分别上链；

步骤S130，当电子档案管理过程中生成了新的电子文档，应作为此电子档案的组成部分进行上链。

步骤S140，根据电子文件全生命周期管理需要，梳理电子文件和/或电子档案发生变化的业务环节，对变化的元数据、电子文档作为上链信息进行存证。

步骤S150，当业务系统不具备信息上链条件时，初始上链的业务环节变为文件接收，已归档保存的电子档案根据实际需要决定是否进行信息上链。

步骤S160，初次上链元数据主要包括文件实体元数据和业务实体元数据，其中，文件实体元数据包括文件题名、文号、责任者，业务实体元数据包括行为时间、行为描述，后续上链元数据主要包括新增业务实体元数据，以及发生变化的文件实体元数据。

在一些实施方式中，初次上链元数据主要包括文件实体元数据和业务处理过程元数据，其中，文件实体元数据包括文件题名、文号、责任者、形成时间等，业务处理过程元数据包括处理类型、处理部门、处理人员、处理时间、处理结果等，后续上链元数据主要包括新增业务处理过程元数据，以及发生变化的文件实体元数据。

步骤S170，对元数据进行明文上链，对涉密和/或具备泄密风险的元数据采用哈希值上链。

在一些实施方式中，首先，在档案业务场景下，要将存证功能伸向前端业务系统，归档电子文件形成时即进行数据上链，并将后续修改数据记录上链，实现电子文件全生命周期过程可追溯。其次，在当前的电子文件归档环节，要实现将归档电子文件通过接口传送至档案系统过程中不发生改变，并为将来电子档案移交与接收、长期保存环节的真实性检测做足准备。经验证，通过SDK方式满足这些业务需求对档案系统的改造较大。

除SDK方式外，可在应用层与联盟链之间搭建存证服务平台，联盟链与存证服务共同构成区块链平台。存证服务通过JSON RPC接口实现应用层数据上链和数据查询服务，同时提供缓存和重传功能。应用系统只需要将数据发送给存证服务，上链成功与否由存证服务平台保证，可降低应用系统运行压力。

应用层将存证数据传递给存证服务，由存证服务构建符合区块链格式的交易传给联盟链。对于图片、视频、压缩包等大文件存证数据，

存证服务做哈希后上链存证，并将大文件数据对接电建云进行链下存储。若链下存储数据发生篡改，其计算产生的哈希值就会发生变化，数据验证时即被发现，由此可解决链下数据的防篡改问题，也解决了大数据存储成本和效率问题。同时存证服务提供验证电子文件真实性的用户接口，用户登录网页客户端上传电子文件或哈希值，便可查验电子文件真实性并查看其生命周期状态。系统关系图可以参考图2.

在P2P网络中，共识机制被誉为区块链的核心。鉴于档案部门资源有限、彼此信任程度较高，共识机制的建立需要与档案业务需求、特点相适应。相较于工作量证明(PoW)、权益证明(PoS)等共识机制，拜占庭协议(PBFT)作为一种强共识机制在安全性、可扩展性、资源消耗等方面应用于档案领域具有明显优势。但传统PBFT的消息复杂度较高，需经历二轮投票/三个阶段才能达成共识，每一轮都要保证其见证的2/3以上节点接受对区块的提议，导致消息数量过多，可以参考图3。随着共识节点数量的增长，共识消息成倍增加。假设共识节点数为n，传统PBFT的消息复杂度为O(n²)，不适合大规模的共识节点部署。

为提升效率采用聚合签名的方法传统PBFT进行改进(QBFT)。通过轮流指定网络中的某节点作为协调者(聚合节点)来发送/接收每个节点的投票，在二轮投票/三个阶段，共识节点将自己的投票发送给协调者，然后协调者收集这些投票进行聚合签名，并采用聚合投票数大于最低投票数(门槛签名)来保证协调者的正当行为。协调者将签名结果广播给其他共识节点，避免n-n通讯，减少了消息数量，可以参考图4。假设共识节点数为n，这样投票过程的消息复杂度为O(n)，适合大规模共识节点部署。

数据进行检查和缓存，并对共识节点发送的区块进行验证和存储。选择其中4个验证节点为共识节点，负责对所有发往网络中的交易进行排序，构造区块，并将该区块的共识消息广播给验证存储节点。4个共识节点中随机选择1个聚合节点，负责收集共识过程中的投票消息，并经聚合签名后广播给其他3个共识节点。

后续加入新节点，可以通过节点管理模块选择成为共识节点还是验证存储节点。随着新节点的增加，共识节点也适当增加。在联盟链网络中，当链上节点数量较少时，如果各节点均为全账本节点，那么所有节点同时篡改同一账本似乎并不难。为增加篡改难度，在各验证存储节点中选择2个节点做全账本节点，其他验证存储节点采用差异化账本存储方式。共识节点将构造区块的共识消息广播给2个全账本验证存储节点和随机80％验证存储节点，对新构造区块进行验证和存储，另外20％验证存储节点与之关联。当链上节点达到20个以上时，还可根据需要对交易数据进行分片处理，将要上链存储的交易数据冗余并分片化，分布存储在链上多个节点。数据冗余程度确保即使某个节点的数据出现问题，整体数据丢失的可能性也几乎为零。

平台将智能合约称为链码，分为系统链码和用户链码两类。系统链码主要实现系统管理功能，如链码部署、配置管理、查询管理、交易验证等，在大多数应用场景下均可使用。用户链码则是用户使用Golang、Node、Java等语言编写的智能合约，运行在平台提供的容器中。

用户链码对于解决电子文件真实性保障的档案业务场景来说，主要是存证合约和验证合约。存证合约通过对电子文件的形成、鉴定、整理、归档、存储、迁移、销毁等整个生命周期状态变化的交易数据进行存证，验证导致各方变化的每次交易数据所带的电子签名，保证电子文件的状态更新由对应的角色完成。相关业务系统或其他参与方负责维护电子文件在其管理周期内和自身相关的数据交易，从而完善电子文件从形成至长期保存或销毁的过程跟踪。验证合约即通过判断验证者身份，提供对电子文件真实性验证和追溯过程记录，出具信用证明。

存证合约与验证合约都可作为独立平台，分别部署在联盟链各验证存储节点上自动分散式地执行，也可作为分布式应用程序运行。合约源码应公开并存于区块链系统，让查询和需要提供信用证明的用户知道区块链系统不会因智能合约而发生暗箱操作，维护区块链系统的公开、透明。

可以参考图5，将业务系统、档案系统分别与区块链系统集成。

业务系统与区块链系统之间，由业务系统通过存证服务将本系统形成电子文件的交易数据上链，包括电子文件哈希值及部分元数据。通过接口将交易数据构造成Json格式，传递给存证服务平台，存证服务平台对交易作哈希运算后，将哈希值返回给业务系统作为此笔交易的ID。

业务系统与档案系统之间，由业务系统将电子文件及其元数据封装成归档信息包，与存证服务平台返回的ID一并传递给档案系统。这个ID就是这个电子文件在其生命周期中的唯一标识。

档案系统与区块链系统之间，档案系统对获取的归档信息包及其ID(哈希值)与区块链存证信息进行比对，确认归档信息包在传输过程中没有被篡改，继续四性检测、接收、暂存等操作，并将四性检测、文件接收业务过程元数据作为交易数据上链。档案系统对接收的归档信息包进行解包、存储、整理、格式转换等操作，并把操作过程元数据、格式转换后新生成文件的哈希值作为交易数据上链。

梳理电子文件全生命周期节点，分析电子文件及其元数据状态。自业务系统中电子文件办理完毕时起，即形成了电子档案的雏形，虽未经鉴定、整理等过程还不具备档案的身份，但如同新生儿通过户口登记可获得“身份证号”一样，电子文件及其元数据上链登记可获得区块链系统赋予的档案“身份证号”。

“证”是元数据的集合，人的一生总是通过各种“证”来记录人生节点给一个人带来的变化。如果一份电子文件在其生命周期中也像人的一生一样被合理地改变，其变化的信息可以登记进入区块链，使之固化并权威可信，同样意味着当一份电子文件被修改即创建了一个跟踪，用户据此能准确地知道修改是如何发生的。这就要求电子文件形成后在多个环节创建关于它各种的状态“证”，通过“证”上的记录便可回溯电子文件的“一生”。经过对电子文件在业务系统和档案系统两个管理阶段经历的各个环节进行梳理，形成应对的上链数据、上链方式等上链数据表。

电子文件在业务系统、档案系统中进行流转、处理时，可将业务系统、档案系统分别看作对同一电子文件实施处理的各方，通过密钥对两个系统实施系统级签名。当业务系统生成电子文件后，数据交易的上链处理可参考图5，如下流程操作。

业务系统/档案系统将交易签名后，通过RPC模块发送到请求交易节点的交易缓存池模块缓存。

请求交易节点的缓存池检查交易的合法性，包括交易是否重复、签名是否正确、证书是否过期等。

请求交易节点将交易通过P2P网络向全部节点广播，使所有节点交易缓存池中的交易一致。

共识节点从交易缓存池中拉取交易列表，构造区块。

共识节点将对该区块的共识消息广播给网络中的其他节点。

共识节点发送区块给验证和存储节点并触发智能合约执行器(存证合约)执行合约。

验证和存储节点缓存并验证区块和共识消息。

验证和存储节点调用底层存储，将账本存储在本节点数据库中。

通过P2P网络的病毒式传播机制，验证和存储节点将区块广播给其他验证和存储节点，接收到区块的节点再次验证区块中的交易并存储区块。

实施例2

单位应用区块链管理电子档案应按照电子档案管理各业务环节梳理和明确上链信息。上链信息一般由电子文档信息和元数据信息组成，单位应将组成电子档案的一个或多个电子文档及其元数据一并上链。

单位可根据应用目的、存储空间、数据大小及保密性等要求，选择电子文档全文或哈希值、全部或部分元数据的不同组合方式进行上链。不同选择结果的比较及其适用性见表1。

表1上链信息选择及其适用性对比表

由多个电子文档组成电子档案并选择电子文档哈希值上链的，宜以单个电子文档为单位进行哈希函数运算后分别上链。

电子档案管理过程中新生成电子文档，应作为此电子档案的组成部分进行上链。如格式转换、迁移形成的新的电子文档。

根据电子文件全生命周期管理需要，梳理电子文件或电子档案发生变化的业务环节，对变化的元数据、电子文档作为上链信息进行存证。具体可参见表2。

表2上链信息表

信息上链的业务环节尽可能向前延伸，初始上链的业务环节尽量不晚于“文件办结”。业务系统不具备信息上链条件的，初始上链的业务环节可为“文件接收”。已归档保存的电子档案，根据实际需要进行信息上链。

初次上链元数据主要包括文件实体元数据和业务实体元数据。其中，文件实体元数据包括文件题名、文号、责任者等，业务实体元数据包括行为时间、行为描述等。后续上链元数据主要包括新增业务实体元数据，以及发生变化的文件实体元数据。机构人员实体元数据应在各上链环节均有记录。

元数据一般明文上链，对涉密或可能带来泄密风险的元数据应采用哈希值上链。

实施例3

请参阅图7，图7为本申请实施例提供的一种基于区块链的电子档案管理系统模块示意图，其如下所示：

梳理明确模块10，用于应用区块链管理电子档案，根据电子档案管理各业务环节梳理和明确上链信息；

组合上链模块20，用于根据应用目的、存储空间、数据大小及保密性要求，选择电子文档全文和/或哈希值、全部和/或部分元数据的不同组合方式进行上链；

电子文档上链模块30，用于由至少两个电子文档组成电子档案并选择电子文档哈希值上链的，则以单个电子文档为单位进行哈希函数运算后分别上链；

存证模块40，用于根据电子文件全生命周期管理需要，梳理电子文件和/或电子档案发生变化的业务环节，对变化的元数据、电子文档作为上链信息进行存证。

如图8所示，本申请实施例提供一种电子设备，其包括存储器101，用于存储一个或多个程序；处理器102。当一个或多个程序被处理器102执行时，实现如上述第一方面中任一项的方法。

还包括通信接口103，该存储器101、处理器102和通信接口103相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。存储器101可用于存储软件程序及模块，处理器102通过执行存储在存储器101内的软件程序及模块，从而执行各种功能应用以及数据处理。该通信接口103可用于与其他节点设备进行信令或数据的通信。

其中，存储器101可以是但不限于，随机存取存储器101(Random Access Memory，RAM)，只读存储器101(Read Only Memory，ROM)，可编程只读存储器101(ProgrammableRead-Only Memory，PROM)，可擦除只读存储器101(Erasable Programmable Read-OnlyMemory，EPROM)，电可擦除只读存储器101(Electric Erasable Programmable Read-OnlyMemory，EEPROM)等。

处理器102可以是一种集成电路芯片，具有信号处理能力。该处理器102可以是通用处理器102，包括中央处理器102(Central Processing Unit，CPU)、网络处理器102(Network Processor，NP)等；还可以是数字信号处理器102(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本申请所提供的实施例中，应该理解到，所揭露的方法及系统，也可以通过其它的方式实现。以上所描述的方法及系统实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的方法及系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

另一方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器102执行时实现如上述第一方面中任一项的方法。所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器101(ROM，Read-Only Memory)、随机存取存储器101(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

综上所述，本申请实施例提供的一种基于区块链的电子档案管理方法及系统，档案系统或浏览器访问区块链，依据电子档案ID读取其业务处理过程，可展现电子档案整个生命周期中每个致其改变环节的操作记录，追溯各阶段状态。由此可知，一份电子档案是由哪个业务系统形成的，经历了怎样的处理，发生了哪些改变，由谁改变，改变的结果如何等等。

电子文件验真平台支持电子文件、批量电子文件以及电子文件哈希值三种验证方式，查询链上存储的数据记录。

用户可选择本地电子文件上传给验真平台。验真平台收到电子文件验证请求后，上链查询前会先做哈希运算生成哈希值，再访问区块链数据库进行查询比对。若查询到与之一致的哈希值则说明验证成功，返回“该电子文件受区块链保护，内容未被修改”的结果，同时展现该电子文件经历的处理过程及其元数据。返回的结果与过程元数据可生成版式文件下载，也提供在线打印功能。

用户可一次选择多个本地电子文件上传给验真平台。验真平台收到请求后，批量做哈希运算生成哈希值列表，然后批量进行查询比对，返回电子文件真实性结果列表及其业务处理过程元数据链接。为避免拒绝服务攻击(Dos)，验真平台在授权用户、一次性验证数量等方面有一定限制。

验真平台还提供电子文件哈希值验证方式。为提高验证效率，用户可输入从档案系统获取的或本地记录的电子文件哈希值，查询即可获得该哈希值对应电子文件的处理过程信息。

PBFT是20年前为了解决分布式系统中的拜占庭将军问题而诞生的一个共识协议。它虽然不像工作量证明那样消耗大量计算资源，但数量庞大的通讯也成为降低系统性能和限制节点扩展的瓶颈。为了突破这一瓶颈，在联盟链的搭建中，QBFT作为PBFT的变种应运而生。结合前文提到的系统性能设计原则，区块链在确保安全的前提下，计协调者(聚合节点)角色来减少P2P网络通信次数，大幅提升了共识效率和系统性能，是在高效性和去中心化之间寻求平衡的一个表现。区块链的P2P网络以节点多且平等作为一大特点，以此来保证链上数据公开透明。特别是在公有链系统中，任何人都可以作为节点参与区块链数据的维护和读取，节点之间不知彼此身份，也不受任何中心控制，仅通过共识算法、激励或惩罚机制、P2P网络数据同步来保证一使用QBFT对传统PBFT共识机制进行适当改进，设致性。而联盟链一般是在多个互相已知身份的组织之间构建，特别是在一个行业或企业内部，各节点之间因行业类型或组织结构等因素而具有一定耦合关系，由此先天具备节点之间彼此熟知和比公有链节点更加信任的运行环境。在保障电子文件真实性的档案业务场景下，联盟链更是以电子文件存证和真实性验证的作用出现，节点之间完全平等，似乎并没有P2P网络强调得那么重要。由此，中国电建区块链创新联盟链网络节点设计，将P2P网络去中心化变为多中心化和随机中心化(聚合签名)，对不同节点赋予不同角色并提供不同服务，是为在高效性和去中心化之间寻求平衡的另一个表现。

上链数据是应用区块链系统存证的核心。区块链通过数据上链存证来保证该数据来源和变动历史的可信性。因此，梳理电子文件在各系统管理阶段可能导致电子文件及其元数据发生变化的环节，以元数据记录其变化方式进行存证的过程十分关键。在系统需求分析阶段即对电子文件在业务系统和档案系统两个管理阶段经历的各个环节进行了认真梳理，明确了每个系统对电子文件进行管理的哪一个环节应当记录，记录哪些元数据，哪些应当是原始记录，哪些可以是哈希记录。同时说明这些记录的上链方式、ID在其中的关键作用等。这种做法比之前增加了多个关键环节的上链数据，可以完整地为电子文件存证全生命过程信息。

以上仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

Claims (10)

1.一种基于区块链的电子档案管理方法，其特征在于，包括：

应用区块链管理电子档案，根据电子档案管理各业务环节梳理和明确上链信息；

根据应用目的、存储空间、数据大小及保密性要求，选择电子文档全文和/或哈希值、全部和/或部分元数据的不同组合方式进行上链；

由至少两个电子文档组成电子档案并选择电子文档哈希值上链的，则以单个电子文档为单位进行哈希函数运算后分别上链；

根据电子文件全生命周期管理需要，梳理电子文件和/或电子档案发生变化的业务环节，对变化的元数据、电子文档作为上链信息进行存证。

2.如权利要求1所述的一种基于区块链的电子档案管理方法，其特征在于，还包括：

当电子档案管理过程中生成了新的电子文档，应作为此电子档案的组成部分进行上链。

3.如权利要求1所述的一种基于区块链的电子档案管理方法，其特征在于，还包括：

当业务系统不具备信息上链条件时，初始上链的业务环节变为文件接收，已归档保存的电子档案根据实际需要决定是否进行信息上链。

4.如权利要求1所述的一种基于区块链的电子档案管理方法，其特征在于，还包括：

初次上链元数据主要包括文件实体元数据和业务实体元数据，其中，文件实体元数据包括文件题名、文号、责任者，业务实体元数据包括行为时间、行为描述，后续上链元数据主要包括新增业务实体元数据，以及发生变化的文件实体元数据。

5.如权利要求1所述的一种基于区块链的电子档案管理方法，其特征在于，还包括：

对元数据进行明文上链，对涉密和/或具备泄密风险的元数据采用哈希值上链。

6.如权利要求1所述的一种基于区块链的电子档案管理方法，其特征在于，还包括系统交互：

业务系统与区块链系统交互，将上链信息通过存证接口传输给区块链系统，区块链系统向业务系统返回存证结果；

业务系统与电子档案管理信息系统交互，将归档电子文件及其唯一标识通过归档接口传输给电子档案管理信息系统，电子档案管理信息系统向业务系统返回接收结果。

7.如权利要求6所述的一种基于区块链的电子档案管理方法，其特征在于，还包括：

电子档案管理信息系统与区块链系统的交互包括，通过验证接口验证归档电子文件真实性，将电子文件接收、整理和电子档案转换、迁移、鉴定、处置等业务环节新增或更新的元数据及电子文档或其哈希值上链存证，通过追溯接口查询电子档案全生命周期管理状态。

8.一种基于区块链的电子档案管理系统，其特征在于，包括：

梳理明确模块，用于应用区块链管理电子档案，根据电子档案管理各业务环节梳理和明确上链信息；

组合上链模块，用于根据应用目的、存储空间、数据大小及保密性要求，选择电子文档全文和/或哈希值、全部和/或部分元数据的不同组合方式进行上链；

电子文档上链模块，用于由至少两个电子文档组成电子档案并选择电子文档哈希值上链的，则以单个电子文档为单位进行哈希函数运算后分别上链；

存证模块，用于根据电子文件全生命周期管理需要，梳理电子文件和/或电子档案发生变化的业务环节，对变化的元数据、电子文档作为上链信息进行存证。

9.如权利要求8所述的一种基于区块链的电子档案管理系统，其特征在于，包括：

用于存储计算机指令的至少一个存储器；

与所述存储器通讯的至少一个处理器，其中当所述至少一个处理器执行所述计算机指令时，所述至少一个处理器使所述系统执行：梳理明确模块、组合上链模块、电子文档上链模块及存证模块。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1-7中任一项所述的方法。

Images