CN113282562B - 一种基于私有链的文件管理方法及系统 - Google Patents

Abstract

本发明公开了一种基于私有链的文件管理方法及系统，根据电力设计院部门设置，将节点角色分为：设计、校核、审批；根据业务设计以下流程：设计、校核、审批定稿与存档，历史检索。并依据前述节点角色划分，搭建私有链架构即：由以上角色节点共同组成设计单位内部私有链，并给不同角色节点赋予不同文件权限。最后，结合私有链技术实现业务流程并搭建管理系统。通过上述方式，实现了对设计文件进行了全生命周期管理；将每个操作过程都在区块链所有参与节点中备份记录，并借助全局共识保证各角色所获设计文件完全一致，整个操作流程可追溯，做到权责分明。同时彻底摆脱了中心化存储风险，极大提升了文件查询的读取速度。

Description

一种基于私有链的文件管理方法及系统

技术领域

本发明涉及区块链技术领域，具体涉及一种基于私有链的文件管理方法及系统。

背景技术

随着国家级电力基建计划全面展开，电力系统建设项目数目飞速增多；电力设计院作为电力系统建设的关键一环，需要满足更大的设计需求，更高的工作效率；但由于设计文件的独特要求，设计过程中需要经过专业校核阶段；但现行电力设计院文件管理系统大多采取线下人工校核的形式，工作效率较低且权责不明，经常出现不同设计人员修改图纸后，版本不归一，导致后继流程反复，甚至导致最终设计稿不统一。

现行电力设计院设计文件的设计、修改、审核、复核与通过，基本靠人工交接与记录，失误难以避免，权责不明，各环节设计文件不一致时有发生，严重耽误设计进度，甚至导致最后设计稿件有错误，拖累施工造成重大损失。且现有电力设计单位并没有针对设计文件的专用管理系统，基本都是一般文件服务器方式管理。该种中心化的存储与管理，容易形成瓶颈，且容易成为攻击的目标，一旦文件服务器被攻破，则设计文件备份极容易被恶意破坏或者被窃取。且随着施工项目的增多，设计文件数量庞大，其索引编排、历史版本查找仍采用传统索引机制，效率很低，难以满足信息化的需要。

同时，电力设计文件管理传统分为：1)电子设计文件中间稿件的中心化服务器管理；2)设计定稿的纸板蓝图管理。前者安全性保障低容易形成瓶颈，一旦被攻击者攻破，所有设计文件包括审核修改记录都面临危险，且中心化管理存在责权不明，传统发生过大量文件不知道被谁修改过的实例。后者，大量的纸板蓝图归档存储过程中，耗费大量人力物力，且查找效率低下。

综上所述，现在技术存在的问题是：

1、现行电力设计院设计文件的设计、修改、审核、复核与通过，基本靠人工交接与记录，失误难以避免，权责不明，各环节设计文件不一致时有发生，严重耽误设计进度，甚至导致最后设计稿件有错误，拖累施工造成重大损失。

2、现有电力设计单位并没有针对设计文件的专用管理系统，基本都是一般文件服务器方式管理。该种中心化的存储与管理，容易形成瓶颈，且容易成为攻击的目标，一旦文件服务器被攻破，则设计文件备份极容易被恶意破坏或者被窃取。

3、电力设计院内部设计文件数量庞大，其索引编排、历史版本查找仍采用传统索引机制，效率很低难以满足信息化的要求。

区块链技术具有分布式、防篡改、一致性存储、集体维护、数据可追溯等特性，能够较好弥补现行电力设计院设计文件管理的不足。本发明在充分研究现有电力设计院设计文件生命周期和管理缺陷的基础上，引入区块链技术，解决设计文件校核流程效率低下、权责不明、不可追溯、中心化存储风险、海量历史设计文件索引编排等关键性问题。研究构建了符合电力设计院设计文件设计、专业校核、审批等流程的区块链架构。实现设计文件从初始设计，专业校核，到设计存档、文件检索全过程管理。

发明内容

为解决上述问题，本发明提出一种基于私有链的文件管理方法，通过下述技术方案实现：

一种基于私有链的文件管理方法，包括如下步骤：

S1、设置不同的节点，根据节点类型构建私有链架构，并对不同节点赋予对应权限其中，所述节点类型包括设计节点、校核节点、共识主节点和审批节点；

S2、所述设计节点向指定的校核节点提交校核请求，反复校核直至校核通过，生成校核结果；

S3、随机选择共识主节点，周期性的将校核结果通过共识机制发送给设计私有链各节点进行校核结果共识；

S4、完成所有校核之后，对设计文件进行审批和归档。

上述方案的有益效果为：针对现行电力设计院设计文件的各业务流程基本靠人工交接与记录，失误难以避免，权责不明，各环节设计文件不一致问题，在充分分析电力设计院业务的基础上，引入区块链技术，设计了私有链网络架构，对设计文件进行了全生命周期管理；将每个操作过程都在区块链所有参与节点中备份记录，并借助全局共识保证各角色所获设计文件完全一致，整个操作流程可追溯，权责分明。

针对设计单位缺乏专用设计文件管理系统，且采用中心化服务器管理风险的问题，通过私有链网络分布式存储文件，彻底摆脱了中心化存储风险。

针对设计文件数量庞大，其传统索引机制效率低下的问题，建立了从文件编号到区块哈希的快速索引机制，极大提升文件查询读取速度。

进一步的，所述S1中设置不同节点类型为：

根据节点职能定义私有链网络中多种类型节点，所有节点分布式存储设计文件，其中，

设计节点用于修改和提交自身负责的设计文件数据，并在结果共识中同步区块；

校核节点用于再校核共识中对设计文件数据进行参数校验、可行性评估等专业校核并投票，并在结果共识中同步区块；

共识主节点用于发起一次基于PBFT共识机制的结果共识分发过程，且在每轮共识结束后更新；

审批节点用于在所有设计模块都通过校核后，对全局设计文件数据进行最终审批，并形成最终版设计文件稿。

上述进一步方案的有益效果为，

将现有区块链技术跟设计院设计、校核和审批流程有机结合，使得每一步骤都有记录，且记录被所有参与本私有链的节点认可和保存，避免了文件的内容不统一和个别节点有意无意篡改文件的可能。

进一步的，所述S2中的校核过程为：

S21、所述校核节点收到校核请求后，通过设计节点的ID值验证消息来源，输入数据处理逆操作代码和文件加密压缩数据；

S22、所述校核节点通过设定规则对设计文件源数据进行校核，若校核未通过，则校核节点向设计节点发送校核节结果通知及修改建议，使其继续修改；若校核通过，则向设计节点发送校核通过通知；

S23、无论校核是否通过，所述校核节点均向共识主节点提交校核结果。

上述进一步方案的有益效果为，

将区块链技术和设计文件校核修改过程结合，改进现有区块链的消息和消息机制，使之支持本业务环境下的设计文件的反复修改。

进一步的，所述S3中校核结果共识的过程为：

S31、所述共识主节点接收解析接收到的校核结果，并验证消息的有效性；

S32、当到达设定周期时间或收到设定数量消息后，所述共识主节点将所有校核结果信息打包出块，并将结果共识请求发送给私有链各节点；

S33、所述私有链各节点收到工时请求后，通过设计节点ID值验证消息来源，并将区块数据上链。

上述进一步方案的有益效果为，

本步骤是使所有节点都记录阶段性的校核修改结果，保证了整个校核过程可追溯，且防止单个节点有意无意篡改文件。

进一步的，所述S4中审批和归档的过程包括：

S41、每次完成校核结果的共识后，审批节点对已经通过校核的设计结果进行全局完整性判断：

若审批节点判定有设计节点数据未通过校核，则继续等待新一轮校核结果共识；

若审批节点判定所有设计节点数据均已通过校核，则整合所有设计结果生成全局设计文件，并对其进行终稿审批；

S42、若终稿审批通过，则审批节点将该全局设计文件作为设计文件最终稿，提交到当前共识主节点；

S43、当前共识主节点将设计文件最终稿打包出块，并发起一次终稿归档共识，其余私有链各节点验证消息有效性后，将区块数据Block入链，完成终稿归档。

上述进一步方案的有益效果为，

改进现有区块链技术，使之适合电力系统设计文件审批归档环节，即所有设计节点数据均已通过校核才通过审批，而不是现有区块链一般超过一定投票比例即通过。只有通过最终审批的终稿才进行归档。节省了存储空间和归档复杂度。

进一步的，所述管理方法还包括：

S6、历史设计文件检索，通过文件索引快速定位区块，访问设计文件数据。

进一步的，所述S6具体为：

在每次校核或审批结果共识完成并区块上链后，每个节点集合文件编号为每个设计文件建立定位到区块中的映射，并将次映射关系添加到索引关系树中。

上述进一步方案的有益效果为，

将原来系统文件的顺序查找，变为多层索引，极大加快了文件的检索速度。

还提出一种基于私有链的文件管理系统，包括设计功能模块、校核功能模块、审批功能模块、客户端、验证模块、数据预处理模块、P2P通信模块和文件索引模块，其中

设计功能模块：提供主流设计软件文件导入导出接口，接收设计人员提交的设计文件；

校核功能模块：用于对设计文件源数据进行多项专业性审核，综合形成规范化的校核结果消息；

审批功能模块：用于在每轮校核结果共识完成后，判断是否所有设计任务均已完成，并对设计文件源数据进行全局最终审核；

客户端：用于提供可视化操作界面，通过账号类型区分节点职能并装载不同功能模块，以完成设计、校核、审批等业务流程；

验证模块：用于验证节点有效性，即通过节点唯一标识id，查询注册信息、业务职能等验证节点有效性；

数据预处理模块：用于压缩并加密设计文件源数据及其逆操作；通过可插拔多接口，接入不同加密、压缩插件，进行随机多层加密压缩；并根据加密压缩操作生成逆操作码，记录解密解压操作顺序及所采用算法；

P2P通讯模块：用于设计文件提交、共识消息传递；私有链网络采用混合式P2P网络结构，并依据PBFT共识机制需求设计通讯消息结构；

文件索引模块：用于根据文件编号快速定位区块，访问设计文件数据。

附图说明

此处所说明的附图用来提供对本发明实施例的进一步理解，构成本申请的一部分，并不构成对本发明实施例的限定。在附图中：

图1是本发明提供的结合私有链技术的电力设计院文件管理方案及系统流程图。

图2是本发明设计的基于私有链的电力设计院文件管理系统架构图；

图3是本发明提供的电力设计院设计校核与审批业务流程图；

图4是本发明设计的快速检索文件索引树图；

图5是本发明设计的区块节点结构图。

具体实施方式

在下文中，可在本发明的各种实施例中使用的术语“包括”或“可包括”指示所发明的功能、操作或元件的存在，并且不限制一个或更多个功能、操作或元件的增加。此外，如在本发明的各种实施例中所使用，术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合，并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。

在本发明的各种实施例中，表述“或”或“A或/和B中的至少一个”包括同时列出的文字的任何组合或所有组合。例如，表述“A或B”或“A或/和B中的至少一个”可包括A、可包括B或可包括A和B二者。

在本发明的各种实施例中使用的表述(诸如“第一”、“第二”等)可修饰在各种实施例中的各种组成元件，不过可不限制相应组成元件。例如，以上表述并不限制所述元件的顺序和/或重要性。以上表述仅用于将一个元件与其它元件区别开的目的。例如，第一用户装置和第二用户装置指示不同用户装置，尽管二者都是用户装置。例如，在不脱离本发明的各种实施例的范围的情况下，第一元件可被称为第二元件，同样地，第二元件也可被称为第一元件。

应注意到：如果描述将一个组成元件“连接”到另一组成元件，则可将第一组成元件直接连接到第二组成元件，并且可在第一组成元件和第二组成元件之间“连接”第三组成元件。相反地，当将一个组成元件“直接连接”到另一组成元件时，可理解为在第一组成元件和第二组成元件之间不存在第三组成元件。

在本发明的各种实施例中使用的术语仅用于描述特定实施例的目的并且并非意在限制本发明的各种实施例。如在此所使用，单数形式意在也包括复数形式，除非上下文清楚地另有指示。除非另有限定，否则在这里使用的所有术语(包括技术术语和科学术语)具有与本发明的各种实施例所属领域普通技术人员通常理解的含义相同的含义。所述术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义，除非在本发明的各种实施例中被清楚地限定。

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明作进一步的详细说明，本发明的示意性实施方式及其说明仅用于解释本发明，并不作为对本发明的限定。

实施例1

一种基于私有链的文件管理方法，如图1所示，包括如下步骤：

S1、设置不同的节点类型，根据节点类型构建私有链架构，并对不同节点赋予对应权限其中，所述节点类型包括设计节点、校核节点、共识主节点和审批节点，区块节点的设置如图5所示，

具体而言，设置不同节点类型为：

根据节点职能定义私有链网络中多种类型节点，所有节点分布式存储设计文件，其中，

设计节点用于修改和提交自身负责的设计文件数据，并在结果共识中同步区块；

校核节点用于再校核共识中对设计文件数据进行参数校验、可行性评估等专业校核并投票，并在结果共识中同步区块；

共识主节点用于发起一次基于PBFT共识机制的结果共识分发过程，以随机抽签方式选出且在每轮共识结束后更新；

审批节点用于在所有设计模块都通过校核后，对全局设计文件数据进行最终审批，并形成最终版设计文件稿。

上述节点之间通信的消息格式为：

*<Source_id，Purpose_id，Indexes，Data，Reoperation，Result，Block>

其各字段含义包括：

*为消息类型标志：其取值包括：校核请求消息CheckQuest、校核结果通知消息CheckResponse、结果共识消息ResultConsensus；

Source_id为消息源节点id，用于唯一标识消息源节点；

Purpose_id为消息目的节点id，用于唯一标识消息目的节点；

Indexes为文件编号，用于设计文件历史版本索引，由文件索引模块生成，其格式为：项目编号+文件名+版本号+时间戳。

Data为文件加密压缩数据，由数据预处理模块生成，节点执行对应逆操作即得设计文件源数据。

Reoperation为数据处理逆操作码，用于记录解密、解压顺序以及所采用算法，由数据预处理模块在加密压缩处理结束后生成。

Result为校核/审批结果，用于存放某次校核或审批的结果信息，包括：参与的设计、校核节点id，是否通过以及修改意见。

Block为区块数据，用于存放某次共识中的区块信息。

以上消息格式根据消息类型选择不同字段填入，非必须字段可为空

S2、所述设计节点向指定的校核节点提交校核请求，反复校核直至校核通过，生成校核结果；

具体而言，设计节点设计好某一模块就会提交校核，校核结果通过与不通过的修改意见会返回设计节点。设计节点如果接受到通过通知则进行下一步设计；如果接收到不通过的修改意见，则会按意见修改后再次提交校核。所有设计完成并通过校核后的设计终稿才会提交给审批节点审批，如图3所示。

设计节点dpDesign完成文件设计或修改任务后，向指定校核节点dpCheck提交校核请求消息CheckQuest，其消息格式为：

CheckRequest<Source_id，Purpose_id，Indexes，Data，Reoperation>；

其中，Source_id字段为设计节点dpDesign的id值；Purpose_id字段为校核节点dpCheck的id值。

而校核过程又包括：

校核节点接收到校核请求消息后，先通过Source_id验证消息来源；然后将数据处理逆操作码Reoperation和文件加密压缩数据data输入数据预处理模块，解密解压后得到设计模块源数据。

校核节点dpCheck通过校核功能模块加专业人员的判断对设计文件源数据进行专业校核。

若校核未通过，则校核节点dpCheck向设计节点dpDesign发送校核结果通知消息CheckResponse，使其继续修改。其消息格式为：CheckResponse<Source_id，Purpose_id，Indexes，Data，Reoperation，Result>。其中，Result字段存放校核结果信息及修改意见。

若校核通过，校核节点dpCheck仍向设计节点发送通知消息，但其校核结果字段Result只存放校核通过信息。

无论校核通过与否，校核节点dpCheck都将校核结果提交给私有链主节点dpMain。

S3、随机选择共识主节点，周期性的将校核结果通过共识机制发送给设计私有链各节点进行校核结果共识；

具体而言，所述校核结果共识过程包括：

主节点dpMain接收校核节点dpCheck提交的请求，验证消息有效性并解析得到Result字段信息，即校核结果信息。

当到达某个周期时间或收到一定数量消息后，主节点dpMain将校核结果信息打包出块，并将结果共识请求ResultConsensus发送给所有节点，其消息格式为：ResultConsensus<Source_id，Purpose_id，Block>。

所有节点收到共识请求ResultConsensus后，通过Source_id验证消息来源，随后将区块数据Block入链。

S4、完成所有校核之后，对设计文件进行审批和归档。

具体而言，所述审批和归档的方法为：

每次完成校核结果的共识同步后，审批节点dpExamine对已经通过校核的设计结果进行全局完整性判断。

若审批节点dpExamine判定尚有设计模块未通过校核，即设计文件不具有全局完整性，则继续等待新一轮校核结果共识。

若审批节点dpExamine判定所有设计模块均已通过校核，即设计文件已完成全局设计，则整合所有设计结果，生成全局设计文件，并对其进行终稿审批。

若终稿审批未通过，则审批节点dpExamine广播审批结果及修改意见，然后返回以上步骤二、三的设计-校核流程。

若终稿审批通过，则审批节点将该全局设计文件作为设计文件最终稿，提交到当前主节点dpMain。

当前主节点dpMain将设计文件最终稿打包出块，并发起一次终稿归档共识(即审批结果共识)；其消息格式为：ResultConsensus<Source_id，Purpose_id，Block>；其余节点验证消息有效性后，将区块数据Block入链，完成终稿归档。

所述管理方法还包括

S5、历史设计文件检索，通过文件索引快速定位区块，访问设计文件数据，在每次校核或审批结果共识完成，区块入链后，每个节点通过文件索引模块，结合文件编号Indexes，为每个设计文件建立定位到区块的检索映射，并将此映射关系添加到索引关系树中如图4所示，通过项目编号、文件名、版本号、时间戳等特征项，建立多级检索结构；通过根节点快速比对，定位设计文件所在区块，并从区块中读取设计文件源数据。

实施例2

一种基于私有链的文件管理系统，如图2所示，包括设计功能模块、校核功能模块、审批功能模块、客户端、验证模块、数据预处理模块、P2P通信模块和文件索引模块，其中

设计功能模块：提供主流设计软件文件导入导出接口，接收设计人员提交的设计文件；

校核功能模块：用于对设计文件源数据进行多项专业性审核，综合形成规范化的校核结果消息；

审批功能模块：用于在每轮校核结果共识完成后，判断是否所有设计任务均已完成，并对设计文件源数据进行全局最终审核；

客户端：用于提供可视化操作界面，通过账号类型区分节点职能并装载不同功能模块，以完成设计、校核、审批等业务流程；

验证模块：用于验证节点有效性，即通过节点唯一标识id，查询注册信息、业务职能等验证节点有效性；

数据预处理模块：用于压缩并加密设计文件源数据及其逆操作；通过可插拔多接口，接入不同加密、压缩插件，进行随机多层加密压缩；并根据加密压缩操作生成逆操作码，记录解密解压操作顺序及所采用算法；

P2P通讯模块：用于设计文件提交、共识消息传递；私有链网络采用混合式P2P网络结构，并依据PBFT共识机制需求设计通讯消息结构；

文件索引模块：用于根据文件编号快速定位区块，访问设计文件数据。

实施例3

以具体的一个区块链建模过程为例说明：

S1：根据电力设计院部门设置，将节点角色分为：设计、校核、审批；并依据前述节点角色划分，搭建私有链架构，即：

区块节点根据职能包括以下模块：

Mods＝{设计功能模块001，校核功能模块002，审批功能模块003，验证模块004，数据预处理模块005，P2P通讯模块006，文件索引模块007}；

各职能节点结构组成：

设计节点dpDesign：

节点、客户端标识键值对：<节点id，客户端编号>＝<dp_D01,cl_D01>。

客户端加载模块编号：{001，004，005，006，007}

校核节点dpCheck；

节点、客户端标识键值对：<节点id，客户端编号>＝<dp_C01,cl_C01>。

客户端加载模块编号：{002，004，005，006，007}

私有链主节点dpMain：

节点、客户端标识键值对：<节点id，客户端编号>＝<dp_M,cl_M>。

客户端加载模块编号：{004，005，006，007}

审批节点dpExamine；

节点、客户端标识键值对：<节点id，客户端编号>＝<dp_E01,cl_E01>。

客户端加载模块编号：{003，004，005，006，007}

S2：设计节点dpDesign在模块001完成设计文件设计或修改任务后，通过模块007，生成符合“项目编号+文件名+版本号+时间戳”格式的文件编号并通过模块005对设计文件源数据进行预处理，生成加密压缩数据Data值，以及由逆操作接口值组成的逆操作码Reoperation值＝Impl_03/Impl_02/Impl_01，向指定校核节点dpCheck提交校核请求消息CheckQuest，其消息内容为：

CheckRequest<设计节点代码，校核节点代码，设计文件编号，设计文件数据，数据处理逆操作码>；

所述校核过程包括：

1)校核节点dpCheck接收到校核请求消息后，先将dp_D01输入模块004验证消息有效性；然后将数据处理逆操作码Reoperation＝“Impl_03/Impl_02/Impl_01”、加密压缩文件数据Data输入模块005，解密解压后得到设计模块源数据。

2)校核节点dpCheck通过模块002对设计文件源数据进行专业校核，模块输出结果包含校核结果＝{通过0，未通过1}、及修改建议＝“The design is notfeasible······”，拼接后作为result字段值放入后续消息中。

3)若校核结果为0，则校核节点dpCheck向设计节点dpDesign发送校核结果通知消息CheckResponse，使其继续修改。其消息内容为：CheckResponse<设计节点代码，校核节点代码，设计文件编号，设计文件数据，数据处理逆操作码，校核结果信息>。

4)若校核结果为1，校核节点dpCheck仍向设计节点发送通知消息，但其校核结果字段Result只存放校核结果{通过0}。

5)无论校核通过与否，校核节点dpCheck都将校核结果提交给私有链主节点dpMain。

S3：所述校核结果共识过程包括：

1)主节点dpMain接收校核节点dpCheck提交的请求，验证消息有效性并解析得到Result字段信息，即校核结果信息。

2)当到达某个周期时间或收到一定数量消息后，本设计设定为24小时或者50个交易数据，因为在本应用中一般设计、校核都以天为单位进行，校核交易不会像电子货币那么频繁，根据经验全系统一天50个设计文件交易已经比较多。主节点dpMain将校核结果信息Result打包出块，并将结果共识请求ResultConsensus发送给所有节点，其消息格式为：ResultConsensus<主节点代码，目的节点代码(Purpose_id)，校核结果信息，区块数据>,其中Purpose_id字段值为1，代表全网广播。

3)所有节点收到共识请求ResultConsensus后，将值dp_M输入模块004验证消息来源，随后将区块数据Block入链，完成共识过程，此时各节点存储的设计文件及其校核信息，校核流程一致。

S4：所述审批和归档包括：

1)每次完成校核结果的共识同步后，审批节点dpExamine对已经通过校核的设计结果进行全局完整性判断，即将自身已上链的设计文件数据、项目编号、文件名、版本号四个参数输入模块003，检验是否完成该设计文件的所有设计任务，输出值为＝{已完成0，未完成1}。

2)若模块003输出为1，即设计文件不具有全局完整性，则继续等待新一轮校核结果共识。

3)若模块003输出为0，即设计文件已完成全局设计，则整合所有设计结果，生成全局设计文件，并将该全局设计文件作为单个参数输入模块003，模块003输出结果包含审批结果＝{通过0，未通过1}、修改意见＝“The design risk coefficient is toohigh······”；此处模块003根据输入参数数量和类型不同自动判断进行全局完整性验证或终稿审批。

4)若模块003输出为1，即终稿审批未通过，则审批节点dpExamine广播审批结果及修改意见，然后返回以上步骤二、三的设计-校核流程。

5)若模块003输出为0，即终稿审批通过，则审批节点将该全局设计文件作为设计文件最终稿，提交到当前主节点dpMain。

6)当前主节点dpMain将设计文件最终稿打包出块，并发起一次终稿归档共识(即审批结果共识)；其消息内容为：ResultConsensus<主节点代码，目的节点代码，区块数据>；其余节点先将dp_M输入模块004验证消息有效性后，然后将区块数据Block入链，完成终稿归档。

S5：历史设计文件检索:通过模块007，结合文件编号Indexes，为每个设计文件建立定位到区块哈希的检索映射<设计文件编号,区块头哈希值>，并通过包括但不限于项目编号、文件名、版本号、时间戳等特征项，建立多级检索结构；依靠索引树根节点快速比对，检索得到设计文件编号对应的区块hash值，并通过hash检索定位区块具体存储地址，读取设计文件源数据

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种基于私有链的文件管理方法，其特征在于，包括如下步骤：

S1、设置不同的节点类型，根据节点类型构建私有链架构，并对不同节点赋予对应权限其中，所述节点类型包括设计节点、校核节点、共识主节点和审批节点，其中，设计节点用于修改和提交自身负责的设计文件数据，并在结果共识中同步区块；

校核节点用于在校核共识中对设计文件数据进行参数校验、可行性评估专业校核并投票，并在结果共识中同步区块；

共识主节点用于发起一次基于PBFT共识机制的结果共识分发过程，以随机抽签的形式选出且在每轮共识结束后更新；

审批节点用于在所有设计模块都通过校核后，对全局设计文件数据进行最终审批，并形成最终版设计文件稿；

S2、所述设计节点向指定的校核节点提交校核请求，反复校核直至校核通过，生成校核结果；

S3、随机选择共识主节点，周期性的将校核结果通过共识机制发送给设计私有链各节点进行校核结果共识；

S4、完成所有校核之后，对设计文件进行审批和归档。

2.根据权利要求1所述的一种基于私有链的文件管理方法，其特征在于，所述S2中的校核过程为：

S21、所述校核节点收到校核请求后，通过设计节点的ID值验证消息来源，输入数据处理逆操作代码和文件加密压缩数据；

S22、所述校核节点通过设定规则对设计文件源数据进行校核，若校核未通过，则校核节点向设计节点发送校核节结果通知及修改建议，使其继续修改；若校核通过，则向设计节点发送校核通过通知；

S23、无论校核是否通过，所述校核节点均向共识主节点提交校核结果。

3.根据权利要求2所述的一种基于私有链的文件管理方法，其特征在于，所述S3中校核结果共识的过程为：

S31、所述共识主节点接收解析接收到的校核结果，并验证消息的有效性；

S32、当到达设定周期时间或收到设定数量消息后，所述共识主节点将所有校核结果信息打包出块，并将结果共识请求发送给私有链各节点；

S33、所述私有链各节点收到共识请求后，通过设计节点ID值验证消息来源，并将区块数据上链。

4.根据权利要求3所述的一种基于私有链的文件管理方法，其特征在于，所述S4中审批和归档的过程包括：

S41、每次完成校核结果的共识后，审批节点对已经通过校核的设计结果进行全局完整性判断：

若审批节点判定有设计节点数据未通过校核，则继续等待新一轮校核结果共识；

若审批节点判定所有设计节点数据均已通过校核，则整合所有设计结果生成全局设计文件，并对其进行终稿审批；

S42、若终稿审批通过，则审批节点将该全局设计文件作为设计文件最终稿，提交到当前共识主节点；

S43、当前共识主节点将设计文件最终稿打包出块，并发起一次终稿归档共识，其余私有链各节点验证消息有效性后，将区块数据Block入链，完成终稿归档。

5.根据权利要求4所述的一种基于私有链的文件管理方法，其特征在于，所述管理方法还包括：

S5、历史设计文件检索，通过文件索引快速定位区块，访问设计文件数据。

6.根据权利要求5所述的一种基于私有链的文件管理方法，其特征在于，所述S5具体为：

在每次校核或审批结果共识完成并区块上链后，每个节点集合文件编号为每个设计文件建立定位到区块中的映射，并将映射关系添加到索引关系树中。

7.一种基于私有链的文件管理系统，其特征在于，包括设计功能模块、校核功能模块、审批功能模块、客户端、验证模块、数据预处理模块、P2P通信模块和文件索引模块，其中

设计功能模块：提供主流设计软件文件导入导出接口，接收设计人员提交的设计文件；

校核功能模块：用于对设计文件源数据进行多项专业性审核，综合形成规范化的校核结果消息；

审批功能模块：用于在每轮校核结果共识完成后，判断是否所有设计任务均已完成，并对设计文件源数据进行全局最终审核；

客户端：用于提供可视化操作界面，通过账号类型区分节点职能并装载不同功能模块，以完成设计、校核、审批业务流程；

验证模块：用于验证节点有效性，即通过节点唯一标识id，查询注册信息、业务职能验证节点有效性；

数据预处理模块：用于压缩并加密设计文件源数据及其逆操作；通过可插拔多接口，接入不同加密、压缩插件，进行随机多层加密压缩；并根据加密压缩操作生成逆操作码，记录解密解压操作顺序及所采用算法；

P2P通讯模块：用于设计文件提交、共识消息传递；私有链网络采用混合式P2P网络结构，并依据PBFT共识机制需求设计通讯消息结构；

文件索引模块：用于根据文件编号快速定位区块，访问设计文件数据。