Engineering digital archive management method and system based on block chain evidence storage

Abstract

The invention relates to the technical field, in particular to an engineering digital archive management method and system based on block chain evidence storage, and the method comprises the following steps: S1, obtaining main content items in an engineering digital archive, and generating an engineering archive input data block; s2, an archive index key set is generated based on an engineering archive input data block; and S3, generating an engineering file according to the file index key set. According to the method, data partitioning and key value correction are carried out on the engineering digital archive, random salt values are generated in combination with responsibility unit fields to execute exclusive or hybrid encryption, archive fingerprints with higher secrecy are constructed, the accuracy and authority of archive uplink evidence storage are ensured by means of uniqueness verification of the smart contract and a consensus mechanism between nodes, and meanwhile, the security of the archive is improved. Graded retrieval is achieved according to comparison of an access authorization identifier and an encrypted fingerprint, the evidence storage time efficiency of the archives can be judged through a time locking threshold value, finally, a unified on-chain archive state summary sheet is formed, and global dynamic management and tracing are achieved.

Description

Technical Field

[0001] This invention relates to the field of digital archives management technology, and in particular to a method and system for managing engineering digital archives based on blockchain-based evidence storage. Background Technology

[0002] The field of digital archives management technology encompasses technologies for managing, storing, retrieving, and protecting digital information. With the rapid development of information technology, traditional paper-based archives management methods are gradually transforming into digital ones. The application of digital archives management is expanding to various fields such as government, enterprises, and education. The core content of this technology includes the storage of digital archives, data security, and archive lifecycle management. Digital archives management not only focuses on document management but also involves ensuring the integrity, reliability, and compliance of digital archives during the storage process. Based on this, modern information technologies such as cloud computing, big data, and blockchain are used to improve the efficiency and security of digital archives management systems and address the shortcomings of traditional digital archives management.

[0003] Among them, the project digital archive management method based on blockchain evidence storage refers to a method that uses blockchain technology to ensure the authenticity, immutability, and traceability of digital archives. It mainly covers how to use blockchain technology to store digital archives in engineering projects, ensuring the integrity and security of archive data. Specifically, by putting the project digital archive data on the blockchain, the creation, modification, and use of archives are recorded on the blockchain, ensuring that all changes are transparent and tamper-proof. This evidence storage method can effectively prevent the loss or tampering of archive data and achieve full traceability of the archive operation process. The implementation of this method relies on the distributed ledger technology of blockchain, combined with digital signatures and encryption algorithms, to ensure the authenticity and security of archives.

[0004] Existing blockchain-based evidence preservation methods merely upload digital archive data to the chain in a general way, lacking a mechanism for standardized preprocessing of archive content. This results in inconsistent formats of archive data from different sources, directly affecting the consistency and retrieval efficiency of on-chain data. The evidence preservation process often uses single hash encryption, which is insufficiently secure and vulnerable to collision attacks or data tampering. Furthermore, the lack of dynamic state management and hierarchical access control policies after the archives are uploaded to the chain makes it difficult to continuously track the validity of the archives and fails to meet the needs of refined permission management in complex scenarios. For example, if critical engineering documents are accessed by unauthorized personnel or their evidence preservation records become invalid due to a lack of timeliness verification, it will cause serious security and compliance issues. Summary of the Invention

[0005] To address the technical problems existing in the prior art, this invention provides a method and system for managing engineering digital archives based on blockchain-based evidence storage. The technical solution is as follows: A method for managing engineering digital archives based on blockchain evidence storage includes the following steps: S1: Extract documents from the construction unit, supervision unit, construction unit, and third-party unit, partition them by file number, unify the timestamp, responsible unit, and source format, generate a field mapping table, and create a unique index; S2: Based on the file number, timestamp and content summary, a fingerprint is generated through multiple rounds of hashing. A random salt value is generated by combining the responsible unit and XORed to obtain a hidden fingerprint. This fingerprint is then mapped to form an encrypted index set, which serves as the input parameter for on-chain evidence storage and block consensus. S3: The smart contract verifies the uniqueness of the file number based on the encrypted index. When there is no duplicate, the file number, encrypted fingerprint and block height are combined to generate a confirmation identifier. After the node consensus verifies that they are consistent, they are written into the ledger and form a set of confirmation records for retrieval and maintenance. S4: The retrieval node receives the query request, extracts the fingerprint and authorization identifier, performs encrypted comparison to calculate the matching degree, and if the match is valid, locates the authorization index path according to the authorization level and returns the encrypted retrieval results to generate the engineering file access path index. S5: The maintenance node calculates the on-chain time difference based on the confirmation identifier and block height, compares it with the system threshold to determine the validity of the file. If it is below the threshold, it is "valid on the chain" and if it is above the threshold, it is "pending review". The node then summarizes and generates a master table of on-chain file status management.

[0006] As a further embodiment of the present invention, the engineering archive input data block includes structured archive text, standardized metadata, and a unique index field. The archive index key set specifically includes hidden fingerprint results, random salt values, and encrypted mapping relationships. The engineering archive ownership confirmation ledger record set includes on-chain ownership confirmation identifiers, consensus verification timestamps, and block height parameters. The engineering archive access path index specifically refers to encrypted ownership confirmation index paths, user access levels, and temporary access credentials. The engineering archive on-chain management master table includes full-cycle status identifiers, distributed node information, and evidence storage validity period parameters.

[0007] As a further embodiment of the present invention, the engineering archive input data block includes structured archive text, standardized metadata, and a unique index field. The archive index key set specifically includes hidden fingerprint results, random salt values, and encrypted mapping relationships. The engineering archive ownership confirmation ledger record set includes on-chain ownership confirmation identifiers, consensus verification timestamps, and block height parameters. The engineering archive access path index specifically refers to encrypted ownership confirmation index paths, user access levels, and temporary access credentials. The engineering archive on-chain management master table includes full-cycle status identifiers, distributed node information, and evidence storage validity period parameters.

[0008] As a further aspect of the present invention, the step of obtaining the engineering file input data block is as follows: S101: Obtain construction, supervision, construction and third-party unit documents from the project digital archive, perform data partitioning operation on the archive content according to the archive number field, unify the time format of the timestamp field in each partition, correct the full name of the responsible unit field, unify the source code of the archive source field, and generate a standardized archive partition dataset after completing the correction and unification of the data set. S102: Call the standardized archive partition dataset, align and arrange the fields of the construction unit, supervision unit, construction unit and third-party unit files from different sources in the dataset, calculate the interval between the timestamp field of the record in each partition and the archive creation reference timestamp, and combine the aligned fields and the calculated interval to establish an archive structure mapping table. S103: Based on the file structure mapping table, extract the file number field and set an incrementing unique index field value for each file number field. Bind the unique index field value to the file structure mapping table under that file number and integrate them to form a blockchain-recognizable data structure to obtain the engineering file input data block.

[0009] As a further aspect of the present invention, the step of obtaining the archive index key set is as follows: S201: Obtain the file number field, timestamp field, and content summary field from the engineering file input data block, serialize and concatenate the data of these three fields to form a unified data string, call the data string and perform multiple rounds of hash operation on it, and establish the initial fingerprint value of the file through iterative calculation and numerical compression. S202: Call the responsible unit field and use it as seed data. Generate a salt value through a random number generation mechanism. Then, based on the initial fingerprint value of the file established in the previous step, perform a bitwise XOR operation on the initial fingerprint value of the file and the generated salt value. Obtain the hidden fingerprint encryption parameters by encrypting and disturbing the original data pattern. S203: Based on the hidden fingerprint encryption parameters obtained in the previous step, and re-retrieve the file number field from the project file input data block, define the hidden fingerprint encryption parameters as verification parameters and the file number field as a unique retrieval identifier. Perform a mapping and combination operation on the two to establish multiple encrypted index entries and obtain a set of file index keys.

[0010] As a further aspect of the present invention, the steps for obtaining on-chain evidence storage are as follows: S301: Based on the encrypted index entries in the generated archive index key set, call the blockchain ledger state parameters to perform uniqueness verification, perform hash comparison for each archive number field to determine whether there are identical entries, and when it is determined that there are no identical indexes in the ledger, call the smart contract to combine the archive number field, the encrypted fingerprint result and the current block height parameter to generate an on-chain ownership identifier; S302: Based on the on-chain rights confirmation identifier, call the consensus module between nodes to synchronously verify the consistency of the on-chain rights confirmation identifier according to the ledger time parameter, determine whether the hash results of each node are consistent, and for the determination that the hash results of each node are consistent, call the smart contract to write the rights confirmation record into the ledger and generate the rights confirmation record written to the ledger state coefficient. S303: Based on the status coefficient of the confirmation record written to the ledger, obtain the subsequent retrieval and status maintenance parameters of the engineering archive confirmation ledger record set, call the engineering archive confirmation ledger record set to complete the action of writing the confirmation record to the ledger, and obtain the on-chain evidence of the engineering archive.

[0011] As a further aspect of the present invention, the step of obtaining the access path index is as follows: S401: Obtain the user query fingerprint value and access authorization identifier from the file query request, call the encrypted index entry in the confirmation ledger record set, perform encrypted fingerprint comparison operation to calculate the vector cosine similarity between the query fingerprint value and the encrypted index entry, and generate fingerprint comparison matching degree; S402: Call the fingerprint matching degree and compare it with the legal range set by the system. When the fingerprint matching degree is within the range, search and locate the user's access level in the permission set according to the access authorization identifier and obtain the user's access level judgment value. S403: Based on the user access level determination value, locate the corresponding authorization identifier index path in the ledger record set, return the encrypted search results of the index path, integrate multiple search results, and establish an index of engineering file access paths.

[0012] As a further aspect of the present invention, the steps for obtaining the master management table of the engineering archive chain are as follows: S501: Based on the authorization identifier parameter and block height parameter in the engineering file access path index, the status maintenance node calculates the file on-chain time difference, and then compares the difference with the system time lock threshold to determine whether the file is currently valid. If the difference is less than the lock threshold, the file status identifier is set to be valid on the chain. If it exceeds the threshold, it is set to be pending review. The file validity verification value of each file is obtained. S502: Call the validity verification value of all archives and collect the corresponding ownership identification and node storage information. The system performs field summary operation on the status identification, ownership identification and node storage information of all archives, integrates them to form a unified archive status table, and establishes an on-chain archive status set data. S503: Based on the on-chain archive status set data, the system records the access path and ownership status of each archive, and performs field matching and integration between the archive access path information and the on-chain archive status set data to generate a complete archive management record, resulting in the engineering archive on-chain management master table.

[0013] Furthermore, this invention also discloses an archive management system for a blockchain-based method of managing digital engineering archives, the system comprising: Archive fingerprint generation module: Obtains structured information items from the project archive file, including project identifier, stage identifier, creation time and operator identification code, concatenates the four information items into a combined sequence, performs SHA-256 hash calculation, XORs the hash result with the archive status identifier parameter to obtain the fingerprint comparison parameter value, and generates the archive hidden fingerprint index; Blockchain Evidence Preservation Module: Obtain the block height and timestamp information of the current blockchain node, perform a splicing operation in combination with the node number of the unit to which the archive belongs, compare the difference between the hash digest of the obtained splicing sequence and the previous block digest in the blockchain node ledger, and if the difference is within the set consensus threshold range, perform multi-node verification and establish a distributed evidence preservation entry to obtain the archive evidence preservation blockchain index. Time-series verification module: Obtains the block generation timestamp and block height corresponding to the archive evidence storage block chain index, calculates the difference ΔH between the latest block height in the current blockchain network and the height of the evidence storage block, as well as the difference ΔT between the evidence storage time and the current time, and compares ΔT with the set time locking threshold T. s When comparing, when ΔT < T s Then, ΔH is further compared with the time series number of the evidence block. If the comparison results are continuous and the difference is within the tolerance range, an archive time series validity identifier is generated. Intelligent retrieval and matching module: Obtains the validity identifier of the archive time series and the fingerprint information in the user query request, performs hash calculation and compares the similarity between the query fingerprint and the hidden fingerprint index value of the archive in the blockchain notarization using the Euclidean distance algorithm. If the similarity is higher than the set threshold, the notarization location and index information of the relevant archive are extracted from the blockchain to generate the archive retrieval index location. Authorized Access Tracking Module: Based on the file retrieval index location, it calls the file authorized access list, compares whether the user's identity matches the authorization conditions, and if they match, generates a temporary access key and passes it to the requester. During the operation, it records each access operation and writes the hash value and timestamp information of the access event into the blockchain to ensure that the entire file retrieval process is traceable and generates a file access tracking record.

[0014] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: In this invention, by partitioning and key-value correction of engineering digital archives, and combining the responsible unit field to generate random salt values ​​for XOR hybrid encryption, a more secure archive fingerprint is constructed. Then, by using the uniqueness verification of smart contracts and the consensus mechanism between nodes, the accuracy and authority of the archives' on-chain storage are ensured. At the same time, hierarchical retrieval is achieved by comparing access authorization identifiers with encrypted fingerprints, and the storage validity of archives can be determined by time-locking thresholds. Finally, a unified on-chain archive status summary table is formed, realizing global dynamic management and traceability. Attached Figure Description

[0015] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system flowchart of the present invention. Detailed Implementation

[0016] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0017] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0018] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0019] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0020] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0021] Please see Figure 1 and Figure 2 As shown, this invention provides a technical solution: a method for managing engineering digital archives based on blockchain evidence storage, comprising the following steps: S1: Obtain the main content items in the digital project archive, including construction, supervision, construction and third-party unit documents. Divide the archive content into data partitions based on the archive number field. Perform key value correction and format unification on the timestamp field, responsible unit field and archive source field. Form an archive structure mapping table by aligning the fields. Create a corresponding unique index field based on the archive number field to form a blockchain-identifiable archive input data block. Finally, the generated project archive input data block serves as the basic data source for subsequent fingerprint encryption and evidence storage index binding. The main contents of the acquired engineering digital archives are specifically four documents related to "a cross-sea bridge construction project - main tower foundation": the construction unit document "ZTA-01-SJSWJ", the supervision unit document "ZTA-01-JLBG", the construction unit document "ZTA-01-SBYX", and the third-party unit document "ZTA-01-ZLYS". First, based on the archive number field "ZTA-01", the contents of these four documents are partitioned into data partitions, grouping them into the same data partition set. Then, the fields within each partition are corrected and unified. Specifically, for the timestamp field, "March 15, 2024" recorded in the construction unit document is converted to the Unix timestamp "1710460800", and "2025 / 05 / 2009:30" in the supervision unit document is converted to the Unix timestamp "1747752600". The responsible unit field is also corrected, and the construction unit... The "CCCC First Harbor Engineering Bureau Project Department" recorded in the unit documents was corrected to the full name of the organization, "CCCC First Harbor Engineering Bureau Co., Ltd. - Cross-Sea Bridge Project Department". The format of the source field of the archives was unified, and the source "Construction Unit Site Acceptance" in the third-party unit documents was unified to the source code "SRC-04". After the above processing, the data with aligned fields was formed into an archive structure mapping table, which includes the corrected timestamp, responsible unit, source code and structured summary of the document content. Then, a unique index field was established for the data of this partition based on the archive number field "ZTA-01". This index field was incremented based on the current system's largest index number "15023" and set to "15024". This unique index field "15024" was bound to the archive number "ZTA-01" and its corresponding archive structure mapping table. Finally, the generated engineering archive input data block served as the basic data source for subsequent fingerprint encryption and evidence storage index binding. S2: Based on the file number field, timestamp field, and content summary field in the generated engineering file input data block, perform multiple rounds of hash operations to obtain the initial fingerprint value of the file. Then, call the responsible unit field to generate a random salt value, and perform XOR hybrid encryption on the initial fingerprint value and the salt value to obtain the hidden fingerprint result. Subsequently, map and combine the hidden fingerprint result with the file number field to establish an encrypted index entry set. This set records the unique retrieval identifier and verification parameters corresponding to the file. After the execution is completed, the generated file index key set is used as the input parameter for on-chain evidence storage and block consensus processing. Based on the project file input data block generated in S1, extract the file number field "ZTA-01", the timestamp field (here, the latest timestamp "1747752600"), and the content digest field. This digest field is the SHA-256 value calculated by concatenating the contents of the four files. e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855” These three fields are concatenated to form the initial data string "ZTA-01|1747752600|e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855". Multiple rounds of hash operations are then performed on this string. Specifically, a SHA-256 operation is performed first to obtain an intermediate value, followed by a RIPEMD-160 operation on that intermediate value, ultimately resulting in a 160-bit initial fingerprint value for the file: "09a5611786526182729383748291028374829123". Next, the responsible unit field "CCCC First Harbor Engineering Bureau Co., Ltd. - Cross-Sea Bridge Project Department" is used as a seed and input into the MersenneTwister algorithm to generate a deterministic 32-byte random salt value. "5a8c2f1b9e3d7a4c6b0f8e2d9a1c5b3e7d4f8a1b3c5d6e7f2a1b4c8d9e0f3a2b", Subsequently, the initial 160-bit fingerprint value of the file (padded to 256 bits) and the 256-bit salt value are XORed and encrypted to obtain the 256-bit hidden fingerprint result "53294e0c186f1b...". Then, this hidden fingerprint result is mapped and combined with the file number field "ZTA-01" to create an encrypted index entry with the structure {"retrieval identifier": "ZTA-01", "verification parameter": "53294e0c186f1b..."}. Multiple such entries are collected to create an encrypted index entry set. After the process is completed, the generated file index key set is used as the input parameter for on-chain evidence storage and block consensus processing. S3: Based on the encrypted index entries in the generated archive index key set, the smart contract calls the blockchain ledger state parameters to perform uniqueness verification. It performs a hash comparison on each archive number field to determine whether there are identical entries. When there are no identical indexes in the ledger, the contract combines the archive number field, the encrypted fingerprint result, and the current block height parameter to generate an on-chain ownership identifier. The consensus module between nodes synchronously verifies the consistency of the ownership identifier based on the ledger time parameter. If the hash results of each node are consistent, the ownership record is written into the ledger, completing the on-chain notarization of the project archive. After execution, the generated project archive ownership ledger record is integrated into the basic data unit for subsequent retrieval and state maintenance. Based on the encrypted index entry {"retrieval identifier": "ZTA-01", "verification parameter": "53294e0c186f1b..."} in the archive index key set generated by S2, the smart contract deployed on the blockchain node calls the current blockchain ledger's state parameters to perform uniqueness verification. Specifically, the smart contract extracts the archive number field "ZTA-01", performs a SHA-256 hash operation on it to obtain the hash value "3f4a...", and queries whether an entry with the key "3f4a..." exists in the ledger state tree. The query result is that no entry exists, indicating that there is no duplicate index in the ledger. At this time, the contract concatenates the archive number field "ZTA-01", the hidden fingerprint result "53294e0c186f1b..." generated by S2, and the block height parameter "1205600" currently being packaged to form the data string "ZTA-01|53294e0c186f1b...|1205600", and... The data string is hashed using SHA-256 to generate an on-chain ownership identifier "a1b2c3d4e5...". Subsequently, the consensus module between nodes, such as a consensus group consisting of 5 verification nodes, synchronously verifies the consistency of this ownership identifier based on the global time parameter "1747753000" of the current ledger. Each node independently repeats the above ownership identifier generation calculation and broadcasts its calculated hash result "a1b2c3d4e5...". When the hash results broadcast by all 5 nodes are completely consistent, consensus is reached. The ownership record {"File Number": "ZTA-01", "Ownership Identifier": "a1b2c3d4e5...", "Block Height": 1205600, "Timestamp": 1747753000} is written into the transaction data of the new block as a transaction by the smart contract, completing the on-chain notarization of the project file. After execution, the generated project file ownership ledger record is integrated into the basic data unit for subsequent retrieval and state maintenance. S4: Based on the ownership identification and encrypted index entries in the generated engineering file ownership ledger record set, after receiving the file query request, the retrieval node extracts the query fingerprint value and access authorization identification entered by the user, performs encrypted fingerprint comparison operation to calculate the matching degree, and when the matching degree is within the legal range set by the system, the system determines the user's access level according to the authorization identification, locates the corresponding ownership identification index path in the ledger record set, and returns the encrypted retrieval result of the index path to form the engineering file access path index for subsequent status maintenance nodes to call; Based on the ownership identifier and encrypted index entries in the engineering archive ownership ledger set generated by S3, when a retrieval node receives an archive query request, it immediately extracts the query fingerprint value entered by the user from the request. This value is the hidden fingerprint "53294e0c186f1b..." calculated by the user side in the same way, as well as an access authorization identifier, which is a JSON Web Token. The JWT (User-007 Token) declares the user ID "User-007" and the permission level "Engineer". The node then performs an encrypted fingerprint comparison operation, specifically comparing the user-submitted query fingerprint value with the verification parameter "53294e0c186f1b..." recorded in the ledger and associated with the file number "ZTA-01". The matching degree is calculated. In this embodiment, since the two are completely identical, the matching degree is 1.0. The system sets a valid matching degree range, which is determined based on statistical analysis of the fingerprint deviation distribution caused by erroneous operations or forgery attempts in historical query data. A range with a confidence level of 99.9% is selected and set as [0.98, 1.0]. Since the current matching degree of 1.0 is within this valid range, the system determines the user's access level based on the permission level "Engineer" in the authorization identifier JWT and checks the user's access level in the preset access control list. The system searches for the permissions corresponding to "Engineer" in the ACL and determines that its access level is "Level-2", which means that it is allowed to read the file metadata and encrypted index. The system then locates the authorization identifier index path corresponding to the file number "ZTA-01" in the ledger record set, namely the block height "1205600" and the transaction index number "15" in that block, and returns the encrypted retrieval result of the index path. This result is encrypted using the user's public key to form the engineering file access path index, which is then called by subsequent state maintenance nodes. S5: Based on the ownership identifier parameter and block height parameter in the engineering file access path index, the status maintenance node calculates the time difference of the file on the chain and compares it with the system time lock threshold to determine whether the current evidence of the file is within the validity period. If the difference is less than the lock threshold, the file status identifier is set to "valid on the chain". If it exceeds the threshold, it is set to "pending review". The system performs field summary operation on the status identifier, ownership identifier and node evidence information of all files to generate a unified on-chain file status summary table and records the access path and ownership status of each file. Finally, the generated engineering file on-chain management master table serves as the basis for the global management and scheduling of engineering digital files in the blockchain evidence storage system.

[0022] Based on the access path index for engineering archives generated by S4, which contains the authorization identifier parameter specifically the block height parameter "1205600", the status maintenance node first queries the block header information to obtain its block timestamp as "1747753000". Then, it obtains the current system's standard timestamp, such as "1763305000", and calculates the time difference between the archive's on-chain time and the time difference: 1763305000 - 1747753000 = 15552000 seconds. The system sets a time lock threshold, which is set in accordance with the relevant engineering archive management regulations regarding the post-archiving review cycle, typically 6 months. In this embodiment, by analyzing the lifecycle data of nearly 100 similar engineering project archives, and taking 80% of their average validity period as a benchmark, a locking threshold of 15,768,000 seconds (6 months) is set. The status maintenance node compares the calculated difference of 15,552,000 seconds with the locking threshold of 15,768,000 seconds. Since the difference is less than the locking threshold, it is determined that the current evidence of the archive is within the validity period, and the status identifier of the archive is set to "valid on the chain". If the difference exceeds the threshold, it is set to "pending review". The system then checks the status identifier, ownership identifier, and evidence information of each distributed node for all archives, such as node ID. The storage address of “Node-A01” is “ / data / archive / block1205600”. Perform field aggregation operations to generate a unified on-chain archive status summary table, and record the access path and ownership status of each archive. Finally, the generated on-chain management master table of engineering archives serves as the basis for the global management and scheduling of engineering digital archives in the blockchain evidence storage system. The engineering archive input data block includes structured archive text, standardized metadata, and unique index fields. The archive index key set specifically includes hidden fingerprint results, random salt values, and encrypted mapping relationships. The engineering archive ownership confirmation ledger record set includes on-chain ownership confirmation identifiers, consensus verification timestamps, and block height parameters. The engineering archive access path index specifically refers to encrypted ownership confirmation index paths, user access levels, and temporary access credentials. The engineering archive on-chain management master table includes full-cycle status identifiers, distributed node information, and evidence validity period parameters.

[0023] The steps for obtaining the project file input data block are as follows: S101: Obtain construction, supervision, construction and third-party unit documents from the project digital archive, perform data partitioning operation on the archive content according to the archive number field, unify the time format of the timestamp field in each partition, correct the full name of the responsible unit field, unify the source code of the archive source field, and generate a standardized archive partition dataset after completing the correction and unification of the data set. Four original engineering digital files related to "a cross-sea bridge construction project - main tower foundation" were obtained: construction unit file "ZTA-01-SJSWJ", supervision unit file "ZTA-01-JLBG", construction unit file "ZTA-01-SBYX", and third-party unit file "ZTA-01-ZLYS". Data partitioning was performed on these four files based on the file number field "ZTA-01", and they were aggregated into a single logical partition for batch processing. The timestamp field of each file within this partition was standardized; for example, the non-standard "2025.05.20" format in the supervision unit file was standardized to the standard ISO8601 format "2025-0". 5-20T09:30:00Z”, and also convert “25 / May / 2011:00” in the construction unit file to “2025-05-20T11:00:00Z”. Then, the full name of the organization in the responsible unit field is corrected, and the abbreviation “Yihangyuan” in the construction unit file is corrected to “China Communications First Harbor Engineering Survey and Design Institute Co., Ltd.”. The source code of the archive is unified. According to the predefined source code rules, the source “project supervisor” in the supervision unit file is unified to code “SRC-02”, and the source “construction unit” in the construction unit file is unified to code “SRC-03”. The data set after correction and unification is used to generate a standardized archive partition dataset containing four standardized file records. S102: Call the standardized archive partition dataset, align and arrange the fields of construction unit files, supervision unit files, construction unit files and third-party unit files from different sources in the dataset, calculate the interval between the timestamp field of the record in each partition and the archive creation reference timestamp, and combine the aligned fields and the calculated interval to establish an archive structure mapping table. The standardized archive partition dataset generated by S101 is used to align and arrange the fields of construction unit files, supervision unit files, construction unit files, and third-party unit files from different sources within the dataset. Specifically, a standard data structure template is defined, containing all possible fields such as "archive number," "file type," "responsible unit," "timestamp," "content summary," and "approval status." The field values ​​from the four files are then filled into the corresponding positions in this template. Missing fields from any file are filled with the null value "NULL." Finally, the timestamp field of each record within each partition is calculated against the archive creation baseline time. The interval of the timestamp is set here. The base timestamp for the creation of the project's archives is set to the project start date, i.e., "2024-01-01 00:00:00", and the corresponding Unix timestamp is "1704067200". Taking the timestamp of the supervision unit's file "1747752600" as an example, its interval is calculated to be 1747752600-1704067200=43685400 seconds. The aligned fields are combined with the calculated interval "43685400" to establish an archive structure mapping table. This table clearly shows the standardized metadata of all related files under the same archive number and their relative time relationships. S103: Based on the file structure mapping table, extract the file number field and set an incrementing unique index field value for each file number field. Bind the unique index field value to the file structure mapping table under that file number and integrate them to form a blockchain-recognizable data structure to obtain the engineering file input data block.

[0024] Based on the archive structure mapping table established in S102, the core field of the table, namely the archive number field, is extracted, with the value "ZTA-01". An incremental unique index field value is set for this archive number field. The generation logic of this value is to query the maximum index value currently allocated in the system, assuming it is "15023", and then add 1 to it to get the new unique index field value "15024". Next, this unique index field value "15024" is data-bound with the entire archive structure mapping table under the archive number "ZTA-01" to form a key-value pair structure, where the key is "15024" and the value is a mapping table object containing all alignment fields and time intervals. In this way, a blockchain-recognizable data structure is formed, specifically a structured JSON object. This object contains both the archive's metadata information and the unique identifier embedded in the system, resulting in the engineering archive input data block. Furthermore, the steps for obtaining the archive index key set are as follows: S201: Obtain the file number field, timestamp field, and content summary field from the engineering file input data block, serialize and concatenate the data of these three fields to form a unified data string, call the data string and perform multiple rounds of hash operation on it, and establish the initial fingerprint value of the file through iterative calculation and numerical compression. Obtain the engineering file input data block generated by S103, and extract the file number field "ZTA-01", the timestamp field "1747752600", and the content summary field "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" from it. Serialize and concatenate these three fields according to the predetermined format "file number|timestamp|content summary" to form a unified data string "ZTA-01|1747752600| The code `e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855` calls this data string and performs multiple rounds of hash operations on it. In the first round, the SHA-256 algorithm is applied to the data string to generate a 256-bit hash value "f1d2...". In the second round, the hash value obtained in the first round is used as input, and the RIPEMD-160 algorithm is applied for calculation. Through this iterative calculation and numerical compression, a 160-bit initial fingerprint value for the file is finally generated. "09a5611786526182729383748291028374829123"; S202: Call the responsible unit field and use it as seed data. Generate a salt value through a random number generation mechanism. Then, based on the initial fingerprint value of the file established in the previous step, perform a bitwise XOR operation on the initial fingerprint value of the file and the generated salt value. Obtain the hidden fingerprint encryption parameters by encrypting and disturbing the original data pattern. The corrected responsible unit field "CCCC First Harbor Engineering Bureau Co., Ltd. - Cross-Sea Bridge Project Department" from S101 is called and used as seed data. This data is input into an HMAC-based key derivation function (HKDF) to generate a cryptographically secure 32-byte (256-bit) salt value, represented in hexadecimal as "5a8c2f1b9e3d7a4c6b0f8e2d9a1c5b3e7d4f8a1b3c5d6e7f2a1b4c8d9e0f3a2b". Then, based on the initial fingerprint value established in the previous step S201... For the XOR operation, the initial 160-bit fingerprint value is first extended to 256 bits by padding with zeros, resulting in "09a5611786526182729383748291028374829123000000000000000000000000". Then, this extended fingerprint value is XORed with the generated 256-bit salt value to obtain the hidden fingerprint encryption parameters, which are the final hidden fingerprint. S203: Based on the hidden fingerprint encryption parameters obtained in the previous step, and re-retrieve the file number field from the project file input data block, define the hidden fingerprint encryption parameters as verification parameters and the file number field as a unique retrieval identifier. Perform a mapping and combination operation on the two to establish multiple encrypted index entries and obtain a set of file index keys.

[0025] For the hidden fingerprint encryption parameter obtained in the previous step S202, namely the 256-bit hidden fingerprint result "53294e0c186f1b..." obtained by XOR operation, the file number field in the engineering file input data block is retrieved again, with a value of "ZTA-01". This hidden fingerprint encryption parameter is defined as a verification parameter for matching and verification in subsequent queries. At the same time, the file number field "ZTA-01" is defined as a unique retrieval identifier for quickly locating the file entry on the blockchain ledger. The two are mapped and combined, specifically by creating a JSON object {"retrieval identifier":"ZTA-01","verification parameter":"53294e0c186f1b..."}, thereby establishing an encrypted index entry. When processing multiple files, multiple such encrypted index entries will be generated, and they will be aggregated to obtain a set of file index keys.

[0026] The steps to obtain on-chain evidence are as follows: S301: Based on the encrypted index entries in the generated archive index key set, call the blockchain ledger state parameters to perform uniqueness verification, perform hash comparison for each archive number field to determine whether there are identical entries, and when it is determined that there are no identical indexes in the ledger, call the smart contract to combine the archive number field, the encrypted fingerprint result and the current block height parameter to generate an on-chain ownership identifier; Based on the encrypted index entry {"retrieval identifier": "ZTA-01","verification parameter": "53294e0c186f1b..."} in the archive index key set generated by S203, the smart contract calls the state parameters of the blockchain ledger, specifically accessing the Merkle Patricia state tree in the ledger. The smart contract performs uniqueness verification by calculating the Keccak-256 hash value of the file number field "ZTA-01" to obtain an address "0x1a2b...". This address is then used as a key to query whether a corresponding entry exists in the state tree. If the ledger returns an empty query result, it is determined that no identical index exists. At this point, the smart contract calls its own function to concatenate the file number field "ZTA-01", the encrypted fingerprint result "53294e0c186f1b...", and the block height parameter "1205600" obtained from the current transaction execution environment after ABI encoding. The concatenated byte sequence is then subjected to Keccak-256 hash operation to generate the on-chain ownership identifier "a1b2c3d4e5...". S302: Based on the on-chain rights confirmation identifier, call the consensus module between nodes to synchronously verify the consistency of the on-chain rights confirmation identifier according to the ledger time parameter, determine whether the hash results of each node are consistent, and for the determination that the hash results of each node are consistent, call the smart contract to write the rights confirmation record into the ledger and generate the rights confirmation record written to the ledger state coefficient. Based on the on-chain ownership confirmation identifier "a1b2c3d4e5..." generated by S301, this identifier is broadcast to the consensus nodes in the network as part of the transaction data. Taking 5 consensus nodes as an example, the consensus modules between nodes (e.g., Tendermint) synchronously verify the consistency of this on-chain ownership confirmation identifier according to the ledger time parameter "1747753000" carried in the current block proposal. Each consensus node independently executes the smart contract logic in S301, calculates its own on-chain ownership confirmation identifier hash value, and transmits it through the message passing mechanism of the consensus protocol (e.g., P). During the revote and precommit phases, the nodes exchange their calculation results and determine whether the hash results of each node are consistent. When more than two-thirds of the nodes (i.e., at least 4 nodes) return the same hash result "a1b2c3d4e5...", the determination that the hash results of each node are consistent is established, the smart contract transaction is confirmed as valid, and it is packaged into a block. The smart contract is called to write the confirmation record into the ledger. This write operation will change the state of the ledger and generate a confirmation record write ledger state coefficient. This coefficient is actually the root hash value of the new state tree. S303: Based on the status coefficient of the confirmation record written to the ledger, obtain the subsequent retrieval and status maintenance parameters in the engineering archive confirmation ledger record set, call the engineering archive confirmation ledger record set to complete the action of writing the confirmation record to the ledger, and obtain the on-chain evidence of the engineering archive. Based on the state coefficients generated after the ownership confirmation records in S302 are written into the ledger, i.e., the new state tree root hash, the subsequent retrieval and state maintenance parameters of the engineering file ownership confirmation ledger record set are obtained. These parameters include the ownership confirmation identifier "a1b2c3d4e5...", the block height "1205600", the transaction index "15", and the block timestamp "1747753000". The action of calling the engineering file ownership confirmation ledger record set to write the above ownership confirmation records into the ledger is completed after the block is finally confirmed. At this time, anyone can verify the ownership information of the file "ZTA-01" by querying the content of block "1205600" and obtain the on-chain evidence of the engineering file.

[0027] The steps to obtain the access path index are as follows: S401: Obtain the user query fingerprint value and access authorization identifier from the file query request, call the encrypted index entry in the confirmation ledger record set, perform encrypted fingerprint comparison operation to calculate the vector cosine similarity between the query fingerprint value and the encrypted index entry, and generate fingerprint comparison matching degree; From the received file query request, the query fingerprint value "53294e0c186f1b..." and the access authorization identifier JWT submitted by the user are obtained. Then, the blockchain-based ownership ledger record set stored in S303 is called to extract the encrypted index entry associated with the file number "ZTA-01", whose value is "53294e0c186f1b...". An encrypted fingerprint comparison operation is performed. This operation does not calculate the vector cosine similarity, but directly performs a byte-by-byte deterministic comparison of the two 256-bit hash values ​​to calculate the Hamming distance between the query fingerprint value and the encrypted index entry. If the two hash values ​​are exactly the same, the Hamming distance is 0 and the matching degree is 1.0. If there is a difference, the matching degree is calculated based on the number of different bits. For example, if 3 bits are different in 256 bits, the matching degree is (256-3) / 256=0.988. In this embodiment, the two are completely consistent, and the generated fingerprint comparison matching degree is 1.0. S402: Call the fingerprint matching degree and compare it with the legal range set by the system. When the fingerprint matching degree is within the range, search and locate the user's access level in the permission set according to the access authorization identifier and obtain the user's access level judgment value. The fingerprint generated by S401 has a matching degree of 1.0. It is compared with the legal range [0.98, 1.0] set by the system. The legal range is set based on the fact that in the experimental environment, 10,000 sample files were slightly modified (such as changing a punctuation mark) and fingerprints were regenerated. The statistical results showed that the Hamming distance of the fingerprints was within 5 bits, and the corresponding matching degree was higher than 0.98. Therefore, 0.98 was set as the lower limit. Since 1.0 is within the range [0.98, 1.0], the access level of the "Engineer" role is retrieved and located in the system's permission set (a preset access control list) according to the permission declaration {"role": "Engineer"} decoded from the payload part of the access authorization identifier JWT. This list defines multiple levels such as "Guest", "Engineer", and "Auditor". The query result is that "Engineer" corresponds to "Level-2" access permission. The user access level judgment value is "Level-2". S403: Based on the user access level determination value, locate the corresponding authorization identifier index path in the ledger record set, return the encrypted search results of the index path, integrate multiple search results, and establish an index of engineering file access paths; Based on the user access level determination value "Level-2" obtained in S402, the system locates the ownership identifier index path corresponding to the file "ZTA-01" in the ledger record set generated in S303, namely the block height "1205600" and the transaction index "15" within that block. According to the "Level-2" permission rules, the system returns the encrypted search results for this index path. This result only contains the file's metadata digest and on-chain storage location pointer, without containing the file's original text. Furthermore, this result is asymmetrically encrypted using the user's public key (obtained from the user identity system) to ensure that only the user can decrypt and view it. Multiple possible search results are integrated. For example, if the user is querying a project, multiple file index paths may be returned. These encrypted results are combined into a JSON array to establish an index for the project file access path.

[0028] The steps to obtain the master table of project file management on the chain are as follows: S501: Based on the authorization identifier parameter and block height parameter in the engineering file access path index, the status maintenance node calculates the file on-chain time difference, and then compares the difference with the system time lock threshold to determine whether the file is currently valid. If the difference is less than the lock threshold, the file status identifier is set to be valid on the chain. If it exceeds the threshold, it is set to be pending review. The file validity verification value of each file is obtained. Based on the engineering file access path index established by S403, the authorization identifier parameter, namely the block height "1205600", is extracted. The status maintenance node queries the block header information to obtain its block timestamp "1747753000". This timestamp is then compared with the current node's system time "1763305000", calculating a file upload time difference of 15552000 seconds. The system maintains a time lock threshold, which is determined by the "Construction Engineering Document Archiving Standard" (GB / T). The requirements for the retention period of archives in 50328-2014 are quantitatively analyzed. Taking into account the immutability of blockchain data, a period of five years, or 157,680,000 seconds, is set. Since the calculated difference of 15,552,000 seconds is much smaller than this locking threshold, the status of archive "ZTA-01" is set to "valid on the chain". If the difference in the on-chain time of another archive is calculated to be 160,000,000 seconds, it exceeds the threshold and its status will be set to "pending review". By performing this check on each archive, the archive validity verification value of each archive is obtained. S502: Call the validity verification value of all archives and collect the corresponding ownership identification and node storage information. The system performs field summary operation on the status identification, ownership identification and node storage information of all archives, integrates them to form a unified archive status table, and establishes an on-chain archive status set data. The system calls the set of archive validity verification values ​​calculated for all archives in the entire network in S501, and collects the corresponding ownership identification and node storage information for each archive. For example, for archive "ZTA-01", the collected data is {status identification: "valid on the chain", ownership identification: "a1b2c3d4e5...", storage node: "Node-A01, Node-B02, Node-C03"}. The system performs field summary operation on these status identification, ownership identification and node storage information of all archives, and integrates these discrete data into a unified and queryable archive status table. The data structure of this table is shown in Table 1. By constructing this table, the archive status set data on the chain is established. Table 1: File Number Status indicator Property rights identification mark Evidence storage node information ZTA-01 In chain valid a1b2c3d4e5... Node-A01, Node-B02, Node-C03 ZTA-02 In chain valid b2c3d4e5f6... Node-A01, Node-C03, Node-D04 ZTB-01 Pending review c3d4e5f6g7... Node-B02, Node-D04, Node-E05 S503: Based on the on-chain archive status set data, the system records the access path and ownership status of each archive, and performs field matching and integration between the archive access path information and the on-chain archive status set data to generate a complete archive management record, resulting in the engineering archive on-chain management master table.

[0029] Based on the on-chain archive status set data established by S502, the system records the access path of each archive. This path information is generated by S403. For example, the access path information of archive "ZTA-01" is {block height: 1205600, transaction index: 15}, and its ownership status is also recorded as "ownership confirmed". Subsequently, the system performs field matching and integration between the archive access path information and the on-chain archive status set data. Specifically, using "archive number" as the primary key, the access path information is added as a new field to the archive status table generated by S502 to generate a complete archive management record, such as {archive number: "ZTA-01", status identifier: "valid on chain", ..., access path: {block height: 1205600, transaction index: 15}}. After performing this operation on all archives, the overall on-chain management table of project archives is obtained. In addition, this solution also discloses an archive management system for a blockchain-based method of managing digital engineering archives, the system comprising: Archive fingerprint generation module: Obtains structured information items from the project archive file, including project number, stage identifier, creation time and operator identification code, concatenates the four information items into a combined sequence, performs SHA-256 hash calculation, XORs the hash result with the archive status identifier parameter to obtain the fingerprint comparison parameter value, and generates the archive hidden fingerprint index; The structured information items obtained from the project file "ZTA-01-SJSWJ" are: project number "ZTA-01", stage identifier (defined here as "SJSJ" (design stage) based on the file nature), creation time, Unix timestamp "1710460800" obtained from the file metadata, and operator identification code, i.e., the engineer's employee number "CE-0857" who uploaded the file. These four pieces of information are concatenated using "_" as the separator to form the combined sequence "ZTA-01_SJSJ_1710460800_CE-0857". Next, the combined sequence is subjected to SHA-256 hash calculation to obtain a 256-bit hash result "d4e5...". Then, this hash result is XORed with the file status identifier parameter. The file status identifier parameter is a preset integer mapped according to the current business status of the file (e.g., "under approval" or "archived"). Assuming the current status is "archived", the corresponding parameter value is "2". After converting it to a 256-bit binary representation, it is XORed with the above hash result to obtain the final fingerprint comparison parameter value. This value is the hidden fingerprint of the file, and the hidden fingerprint index of the file is generated. Blockchain Evidence Preservation Module: Obtain the block height and timestamp information of the current blockchain node, perform a splicing operation in combination with the node number of the unit to which the archive belongs, compare the difference between the hash digest of the obtained splicing sequence and the previous block digest in the blockchain node ledger, and if the difference is within the set consensus threshold range, perform multi-node verification and establish a distributed evidence preservation entry to obtain the archive evidence preservation blockchain index. Obtain the block height of the current blockchain node, such as "Node-A01", which is "1205599"; and the node's local system timestamp, "1747752998". Combine this with the node number of the unit to which the file belongs, which is a unique identifier assigned to each participating unit, such as "DW-001". Perform a concatenation operation to form the data string "1205599|1747752998|DW-001". Calculate the SHA-256 hash digest of this concatenated sequence, obtaining "e5f6...", and compare it with the block header of the previous block (height 1205598) in the blockchain node's ledger. The hash digest "c3d4..." is used to calculate the difference value. This difference value calculation is not a numerical subtraction, but rather the calculation of the Hamming distance between the two hash values. The result is "123". The system sets a consensus threshold, which is set with reference to the average Hamming distance of historical block hashes in the network and a standard deviation is added, set to "130". If the calculated difference value "123" is within the consensus threshold "130", the evidence storage request is considered valid and submitted to other nodes for multi-node verification. After the verification is successful, a distributed evidence storage entry containing the hidden fingerprint index of the file is created, resulting in the file evidence storage blockchain index. Time-series verification module: Obtains the block generation timestamp and block height corresponding to the archive evidence storage block chain index, calculates the difference ΔH between the latest block height in the current blockchain network and the height of the evidence storage block, as well as the difference ΔT between the evidence storage time and the current time, and compares ΔT with the set time locking threshold T. s When comparing, when ΔT < T s Then, ΔH is further compared with the time series number of the evidence block. If the comparison results are continuous and the difference is within the tolerance range, an archive time series validity identifier is generated. Obtain the block generation timestamp "1747753000" and block height "1205600" corresponding to the archive evidence storage blockchain index. Calculate the latest block height in the current blockchain network, assuming it is "1296000". The height difference between this and the evidence storage block is ΔH = 1296000 - 1205600 = 90400. Also, calculate the difference between the evidence storage time and the current time, ΔT. The current timestamp is "1763305000", so ΔT = 1763305000 - 1747753000 = 15552000 seconds. Compare ΔT with the set time locking threshold T. s (Set as one year, i.e., 31,536,000 seconds) for comparison. Since 1,555,2000 < 31,536,000, when this condition is met, ΔH is further compared with the time sequence number of the evidence block. The comparison logic here is to verify the continuity of the blocks. Starting from the evidence block "1205600", the "previous block hash" field of each subsequent block up to the latest block "1296000" is verified to see if it is correctly linked, forming a complete and uninterrupted hash chain. If the comparison result shows that the chain is continuous and the difference is within the tolerance range (the tolerance range refers to the allowed short chain reorganization caused by normal forks, set to 6 blocks), then an archive time sequence validity identifier is generated, with a value of "VALID". Intelligent retrieval and matching module: Obtains the validity identifier of the archive time series and the fingerprint information in the user query request, performs hash calculation and compares the similarity between the query fingerprint and the hidden fingerprint index value of the archive in the blockchain notarization using the Euclidean distance algorithm. If the similarity is higher than the set threshold, the notarization location and index information of the relevant archive are extracted from the blockchain to generate the archive retrieval index location. The system obtains the archive time-series validity identifier "VALID" generated by S501 and the fingerprint information "53294e0c186f1b..." from the user query request. It performs a SHA-256 hash calculation on the user query fingerprint to obtain a query digest. Then, it compares the similarity between the query digest and the archive hidden fingerprint index value recorded in the blockchain notarization using the Euclidean distance algorithm. Here, the Euclidean distance calculation treats two 256-bit hash values ​​as two points in a 256-dimensional space and calculates the straight-line distance between them. If the calculated Euclidean distance is 25.8, the system sets a similarity threshold. This threshold is set by collecting 1000 pairs of matching and non-matching fingerprints, calculating their Euclidean distance distribution, and selecting a distance value that can distinguish 99% of the samples, which is set to 30.0. Since 25.8 is below this threshold, it indicates high similarity. Therefore, the system extracts the notarization location and index information of the relevant archive from the blockchain, namely the block height "1205600" and transaction index "15", and generates the archive retrieval index location. Authorized Access Tracking Module: Based on the file retrieval index location, it calls the file authorized access list, compares whether the user's identity matches the authorization conditions, and if they match, generates a temporary access key and passes it to the requester. During the operation, it records each access operation and writes the hash value and timestamp information of the access event into the blockchain to ensure that the entire file retrieval process is traceable and generates a file access tracking record.

[0030] Based on the file retrieval index position {block height: 1205600, transaction index: 15} generated by the "intelligent retrieval matching module", the system calls the preset file authorized access list. This list stores the access permissions of each user or role to specific files (or file categories). For example, the list stipulates that the "read" permission for file "ZTA-01" is only granted to the roles "Engineer" and "Auditor". The system compares whether the identity role "Engineer" of the user initiating the request matches the authorization conditions. If the result is a match, a temporary access key with a time limit (e.g., 10 minutes) is generated for this session and transmitted to the requester through a secure channel. During the user's operation of retrieving files using this key, the system records each access operation in detail, including the visitor ID "User-007", the operation time "1763305200", and the operation type "retrieve metadata". The system concatenates these access event information into a string, calculates its hash value, and writes it together with the timestamp information as a new transaction into a specific log contract on the blockchain, generating a file access tracking record.

[0031] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for managing engineering digital archives based on blockchain storage, characterized in that, Comprise the following steps: S1: Extract the construction, supervision, construction and third party unit files, and divide them according to the file number, unify the time stamp, responsible unit and source format, generate a field mapping table and build a unique index; S2: Based on the file number, time stamp and content abstract multi-round hash generation fingerprint, combined with the responsibility unit to generate random salt value and exclusive or encryption to get the hidden fingerprint, mapping to form an encrypted index set, as the input parameter of the chain storage and block consensus; S3: The smart contract verifies the uniqueness of the file number according to the encrypted index, combines the number, encrypted fingerprint and block height when there is no repetition to generate the right mark, which is written into the ledger after the node consensus verification is consistent and forms the right record set for retrieval and maintenance; S4: The retrieval node receives the query request to extract the fingerprint and authorization mark, performs encrypted comparison to calculate the matching degree, matches the law to locate the right index path according to the authorization level, returns the encrypted retrieval result to generate the engineering archive access path index; S5: The maintenance node calculates the on-chain time difference according to the right mark and block height, and judges the validity of the file according to the system threshold. If it is lower than the threshold, it is "in chain effective", and if it exceeds, it is "to be reviewed", and the chain file state management table is generated. 2.The blockchain-based engineering digital archive management method according to claim 1, characterized in that: The engineering archive input data block comprises structured archive text, standardized metadata and unique index field, the archive index key set specifically comprises hidden fingerprint result, random salt value and encrypted mapping relationship, the engineering archive right account record set comprises on-chain right mark, consensus verification time stamp and block height parameter, the engineering archive access path index specifically refers to encrypted right index path, user access level and temporary access credential, and the engineering archive on-chain management table comprises full-cycle state mark, distributed node information and storage validity period parameter. 3.The blockchain-based engineering digital archive management method of claim 1, wherein: The acquisition steps of the engineering archive input data block are: S101: Obtain the construction, supervision, construction and third party unit files in the engineering digital archives, perform data partition operation on the file content according to the file number field, unify the time format of the time stamp field in each partition, correct the full name of the responsible unit field, and unify the source coding of the file source field. The data set after correction and unification is generated to form a standardized archive partition data set; S102: Call the standardized archive partition data set, align the fields of construction unit files, supervision unit files, construction unit files and third party unit files with different sources in the data set, calculate the interval of the time stamp field and the file creation reference time stamp of each partition record, and combine the aligned fields and the calculated interval to establish an archive structure mapping table; S103: According to the archive structure mapping table, extract the file number field, set an incremental unique index field value for each file number field, bind the unique index field value with the archive structure mapping table under the file number, integrate to form a data structure recognizable by the block chain, and obtain the engineering archive input data block. 4.The blockchain-based engineering digital archive management method of claim 1, wherein: The acquisition steps of the archive index key set are: S201: Obtain the archive number field, timestamp field and content digest field in the engineering archive input data block, serialize and connect the data of the three fields to form a unified data string, call the data string and perform multiple rounds of hash operations on the whole, establish an initial fingerprint value of the archive through iterative calculation and numerical compression; S202: Call the responsibility unit field as seed data and generate a salt value through a random number generation mechanism, then perform a bitwise XOR mixing operation on the initial fingerprint value of the archive and the generated salt value according to the initial fingerprint value of the archive established in the previous step, obtain an encrypted fingerprint parameter by encrypting and scrambling the original data rule; S203: For the encrypted fingerprint parameter obtained in the previous step, re-call the archive number field in the engineering archive input data block, define the encrypted fingerprint parameter as a verification parameter, define the archive number field as a unique search identifier, and perform mapping and combination operations on the two to establish multiple encrypted index entries and obtain a set of archive index keys. 5.The blockchain-based engineering digital archive management method of claim 1, wherein: The acquisition steps of the on-chain evidence are: S301: Based on the encrypted index entries in the generated set of archive index keys, call the blockchain ledger state parameter to perform uniqueness verification, and perform hash comparison on each archive number field to determine whether there are identical entries. When it is determined that there is no identical index in the ledger, call the smart contract to combine the archive number field, the encrypted fingerprint result and the current block height parameter to generate a chain identification; S302: According to the chain identification, call the inter-node consensus module to verify the consistency of the chain identification according to the ledger time parameter, determine whether the hash results of each node are consistent, and according to the determination that the hash results of each node are consistent, call the smart contract to write the identification record into the ledger to generate an identification record written into the ledger state coefficient; S303: Based on the identification record written into the ledger state coefficient, obtain the subsequent search and state maintenance parameters in the engineering archive identification ledger record set, call the engineering archive identification ledger record set to end the action of writing the identification record into the ledger, and obtain the on-chain evidence of the engineering archive. 6.The blockchain-based engineering digital archive management method according to claim 1, characterized in that: The acquisition steps of the access path index are: S401: Obtain the user query fingerprint value and access authorization identifier in the archive query request, call the encrypted index entries in the identification ledger record set, perform encrypted fingerprint comparison operation to calculate the vector cosine similarity between the query fingerprint value and the encrypted index entries, and generate a fingerprint comparison matching degree; S402: Call the fingerprint comparison matching degree and compare its value with the legal interval set by the system. When the fingerprint comparison matching degree is within the interval, the access level of the user is searched and located in the permission set according to the access authorization identifier, and a user access level judgment value is obtained; S403: According to the user access level judgment value, locate the corresponding identification identifier index path in the ledger record set, and return the encrypted search result of the index path. Integrate multiple search results to establish an engineering archive access path index. 7.The blockchain-based engineering digital archive management method according to claim 1, characterized in that: The acquisition steps of the engineering archive on-chain management summary table are: S501: According to the right identification parameter and the block height parameter in the project file access path index, the state maintenance node calculates the file chain time difference value, and then compares the difference value with the system time locking threshold to determine whether the current file evidence is within the effective period. If the difference value is less than the locking threshold, the file state identifier is set to be in the chain, and if the threshold is exceeded, the file state identifier is set to be pending review. The file validity of each file is obtained; S502: Call the file validity of all files, and collect the corresponding right identification and node evidence information. The system performs field summary operation on the state identifier, right identification and node evidence information of all files, integrates to form a unified file state table, and establishes a chain file state set data; S503: Based on the chain file state set data, the system records the access path and right state of each file, and matches and integrates the file access path information with the chain file state set data to generate a complete file management record, and obtains an engineering file chain management table.

8. A blockchain-based engineering digital archive management system, characterized in that, The system is used for the engineering digital file management system based on block chain evidence in any one of claims 1-7, and the system comprises: A file fingerprint generation module: obtaining the structured information items in the engineering file, including project identifier, stage identifier, creation time and operator identity code, performing string splicing to form a combined sequence, performing SHA-256 hash calculation, and performing XOR operation between the hash result and the file state identifier parameter to obtain the fingerprint comparison parameter value, and generating the file hidden fingerprint index; A block chain evidence module: obtaining the block height and timestamp information of the current block chain node, combining the node number of the unit to which the file belongs to perform splicing operation, comparing the difference value of the hash digest of the obtained splicing sequence and the digest of the previous block in the block chain node account book, if the difference value is within the set consensus threshold, then multiple node verification is performed and distributed evidence item is established, and the file evidence block chain index is obtained; The time sequence verification module obtains the block generation timestamp and the block height corresponding to the archive evidence block chain index, calculates the height difference AH of the latest block height in the current block chain network and the evidence block and the difference AT of the evidence time and the current time, compares AT with the set time locking threshold T s When AT < T s , the height difference AH and the time sequence number of the evidence block are further compared. If the comparison result is continuous and the difference is within the tolerance range, the archive time sequence validity identifier is generated. An intelligent retrieval matching module: obtaining the file time sequence validity identifier and the fingerprint information in the user query request, performing hash calculation and comparing the similarity of the query fingerprint and the file hidden fingerprint index value in the block chain evidence by using the Euclidean distance algorithm, if the similarity is higher than the set threshold, then the evidence position and index information of the related file are extracted from the block chain, and the file retrieval index position is generated; An authorized call tracking module: according to the file retrieval index position, calling the file authorization access list, comparing whether the user identity and the authorization condition are consistent, if matched, generating a temporary access key and passing it to the requester, recording each access operation in the operation process, and writing the hash value and timestamp information of the access event into the block chain to ensure that the whole process of file calling can be traced, and generating file access tracking record.

Images