Highway engineering electronic file credible evidence storage method and system based on block chain

Abstract

The invention discloses a block chain-based highway engineering electronic file credible evidence storage method and system, and relates to the technical field of block chain data evidence storage. The method comprises the following steps: constructing an under-chain data cabin to uniformly store and manage original data of a multi-source electronic file, and generating a real-time state identifier; defining a key evidence storage event through an intelligent contract, and monitoring a triggered signal by using an oracle machine service; in response to the trigger signal, calling a sampling verification strategy according to an event type to perform credible verification on the state of the data cabin; after the verification is passed, generating an evidence storage transaction abstract containing an event identifier, a state root hash and other elements, and submitting the evidence storage transaction abstract to the block chain for evidence storage; and meanwhile, reverse verification on the off-chain data cabin according to the on-chain abstract is supported. According to the invention, low-cost and high-efficiency management of the highway engineering electronic archives is realized, verifiability of on-chain and off-chain data is ensured, and credibility of highway engineering electronic archive management is improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain data storage technology, specifically to a blockchain-based method and system for trusted storage of electronic archives for highway engineering projects. Background Technology

[0002] In the field of highway engineering construction, electronic archives serve as the core data carrier for the entire life cycle management of projects. They encompass multi-source information such as design documents, testing data, supervision logs, construction photos, video surveillance streams, and BIM model versions. Their authenticity, completeness, and traceability are directly related to the effectiveness of project quality supervision, acceptance audits, and dispute evidence collection.

[0003] However, traditional management models, which rely heavily on centralized servers to store electronic records, have several limitations: First, they lack a distributed consensus mechanism, making it difficult to form a globally trusted unified view; data from different participants is isolated, resulting in low collaboration efficiency. Second, centralized architectures are susceptible to internal tampering, data updates are delayed, and storage costs are high. Furthermore, while some solutions have attempted to introduce blockchain to prevent data tampering, these remain limited to the security of on-chain information and fail to establish a reliable link between the original off-chain electronic records and the on-chain evidence, thus hindering the effective verification of the authenticity and integrity of off-chain records. Summary of the Invention

[0004] This invention addresses the technical problems in existing technologies, such as the dispersed and isolated nature of electronic archive data, the susceptibility to tampering and difficulty in tracing centralized storage, and the insufficient guarantee of consistency between on-chain and off-chain data. It provides a blockchain-based method and system for the trusted storage of electronic archives for highway engineering projects.

[0005] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0006] In a first aspect, the present invention provides a blockchain-based method for trusted storage of electronic archives for highway engineering projects, comprising:

[0007] Construct an off-chain data cabin for the target engineering unit, store the original multi-source electronic archive data of the target engineering unit in the off-chain data cabin according to a predetermined data structure, and generate a real-time status identifier corresponding to the current data status;

[0008] Key evidence-keeping events are defined on the blockchain through smart contracts, and oracle services are used to listen for the trigger signals of the key evidence-keeping events.

[0009] In response to the detected trigger signal, the off-chain data compartment is sampled and verified.

[0010] If the sampling verification result is passed, a transaction summary is generated based on the real-time status identifier, the trigger signal, and the sampling verification result.

[0011] The transaction summary is submitted to the blockchain, the transaction is executed through a smart contract, and recorded in the distributed ledger of the blockchain to complete the trusted electronic archiving of the target engineering unit.

[0012] Secondly, this invention provides a blockchain-based trusted electronic archive storage system for highway engineering projects, including...

[0013] The off-chain data cabin module is used to store multi-source electronic files of the target engineering unit according to a predetermined data structure and generate a real-time status identifier corresponding to the current data status.

[0014] The event listening module is used to define key evidence storage events on the blockchain through smart contracts and to listen for the trigger signals of the key evidence storage events in conjunction with the oracle service.

[0015] The sampling verification module is used to perform sampling verification on the off-chain data compartment in response to the detected trigger signal.

[0016] The evidence storage summary generation module is used to generate an evidence storage transaction summary based on the real-time status identifier, the trigger signal and the sampling verification result when the sampling verification result is passed.

[0017] The blockchain evidence storage module is used to submit the evidence storage transaction summary to the blockchain, execute the transaction through a smart contract and record it in the distributed ledger of the blockchain, thereby completing the trusted evidence storage of the electronic archives of the target engineering unit.

[0018] The beneficial effects of this invention are:

[0019] Compared to existing technologies, this invention firstly solves the problem of scattered and isolated multi-source electronic archive data by constructing an off-chain data cabin and generating real-time status identifiers, achieving unified organization and efficient management of massive amounts of data. Secondly, by using smart contracts and oracle services to monitor key events and trigger sampling verification, it ensures the reliable on-chain status of off-chain data, overcoming the shortcomings of centralized storage, such as ease of tampering and difficulty in traceability. Thirdly, by recording the transaction summary of the evidence storage on the blockchain distributed ledger, it reduces storage costs while achieving reliable correlation and consistency between on-chain evidence storage and off-chain original data. Finally, through full-cycle verifiability and audit traceability, it significantly improves the credibility, security, and operational efficiency of highway engineering electronic archive management. Attached Figure Description

[0020] Figure 1 A flowchart illustrating a blockchain-based trusted evidence storage method for electronic archives of highway engineering projects provided by this invention;

[0021] Figure 2This invention provides a schematic diagram of a blockchain-based trusted electronic archive storage system for highway engineering.

[0022] In the attached diagram, the components represented by each number are as follows:

[0023] The module consists of: an off-chain data cabin module 11, an event monitoring module 12, a sampling verification module 13, a storage digest generation module 14, and a blockchain storage module 15. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0026] In the description of this invention, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this invention is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed herein.

[0027] Example 1, as Figure 1 As shown, this embodiment of the invention provides a blockchain-based trusted evidence storage method for electronic archives of highway engineering projects, including:

[0028] S10: Construct the off-chain data cabin of the target engineering unit, store the original data of the multi-source electronic archives of the target engineering unit in the off-chain data cabin according to the predetermined data structure, and generate a real-time status identifier corresponding to the current data status;

[0029] Specifically, an off-chain data cabin for the target engineering unit is constructed. The original multi-source electronic archive data of the target engineering unit is stored in the off-chain data cabin according to a predetermined data structure, and a real-time status identifier corresponding to the current data status is generated, including:

[0030] Obtain the original data of the multi-source electronic archives of the target engineering unit, wherein the original data of the multi-source electronic archives includes at least one of the following: design documents, inspection data, supervision logs, construction photos, video surveillance streams, and BIM models;

[0031] Obtain the multi-source logical relationships of the original data of the multi-source electronic archives, and construct the off-chain data cabin by combining the multi-source logical relationships with the predetermined data structure;

[0032] The original data of the multi-source electronic archives is organized based on the preset data structure and stored in the off-chain data compartment;

[0033] When the original data of the multi-source electronic archive changes, the off-chain data compartment is dynamically updated, and a corresponding real-time status identifier is generated. The real-time status identifier includes at least the state root hash, the data compartment version number, and the timestamp.

[0034] A target engineering unit refers to the smallest engineering module in a highway project that possesses independent functions and can be managed independently. This includes a contract section, a major bridge, a long tunnel, etc. Decomposing the entire project into smaller, more manageable logical units enables modular data management and refined evidence preservation and traceability. Outside of blockchain, a unified, structured, and verifiable raw data repository is established for each target engineering unit—this is the off-chain data repository. Each target engineering unit corresponds to a dedicated off-chain data repository.

[0035] First, acquire multi-source electronic archive raw data for the target engineering unit. Multi-source electronic archive raw data refers to original electronic files generated throughout the entire lifecycle of highway engineering construction, originating from different participants, different business stages, and different formats. This includes at least one of the following: design documents, testing data, supervision logs, construction photos, video surveillance streams, and BIM models, comprehensively representing the current data landscape of the project. Second, analyze the multi-source logical relationships between the data, that is, the associations between different categories of raw data based on the engineering business process. For example, a construction photo belongs to a specific sub-project, and that sub-project corresponds to a certain testing report and design drawing, avoiding fragmented storage of raw data. Third, construct an off-chain data cabin according to the rules of the selected data structure. An off-chain data cabin refers to an independent data storage and management unit deployed outside the blockchain network, not an on-chain node, and for a single target engineering unit. It has the functions of data reception, organization, updating, and hash calculation, and is the off-chain version of the raw data. Because highway engineering data is large in volume, on-chain storage costs are high, and massive amounts of data are difficult to handle. Therefore, setting up an off-chain data cabin can avoid the high storage costs of blockchain, facilitate flexible data processing and management, and is not restricted by blockchain rules.

[0036] Furthermore, by combining multi-source logical relationships with a predetermined data structure, an off-chain data cabin is constructed. The predetermined data structure refers to a pre-designed tree or graph-like logical structure for efficiently organizing and verifying large amounts of data, including Merkle trees and any type of Merkle directed acyclic graph. A Merkle tree, also known as a hash tree, is a tree-like data structure where each leaf node is the hash value of a single data block, and each non-leaf node is the hash value of the combination of the hash values ​​of all its child nodes. Hashing refers to calculating a fixed-length, unique, and irreversible string from input data of arbitrary length using a hash algorithm. Hashing possesses key characteristics, including determinism (the same input produces the same output); efficiency (calculating the hash value of data of any size is very fast); one-wayness (it is impossible to deduce the original input data from the output hash value); and uniqueness (even if different input data differ by only one character or one pixel, the calculated hash values ​​cannot be the same; conversely, if two data have the same hash value, they can be considered the same data). Therefore, when choosing the Merkle tree structure, it is only necessary to verify one path from the file to the root hash to prove that the file belongs to the entire dataset. There is no need to download all the data, which facilitates rapid verification. At the same time, any modification to the data will cause all hash values ​​on its path to change, eventually leading to a major change in the root hash, thus preventing tampering.

[0037] Furthermore, the Merkle Directed Acyclic Graph (DAG) is a generalization of the Merkle tree. It also uses cryptographic hashes to identify content, but its structure is no longer a simple binary tree. Instead, it is a DAG, which can express more complex dependencies, versions, and structural relationships while saving storage space.

[0038] Furthermore, based on the data structure, the original data of multi-source electronic archives is organized and stored in an off-chain data cabin. The off-chain data cabin is dynamically updated as the original data of the multi-source electronic archives changes, generating a corresponding real-time status identifier. This real-time status identifier is a unique digital digest and metadata representing the overall state of all data within the off-chain data cabin at a specific moment, including at least a state root hash, a data cabin version number, and a timestamp. The state root hash is a hash value calculated from the root node of the entire data structure; the data cabin version number is a monotonically increasing integer or timestamp sequence used to identify the order in which the data cabin is updated; the timestamp records the precise time when the current state of the data cabin was generated, corresponding to the time of the last data update. The real-time status identifier provides a lightweight, verifiable, and time-bound anchor for on-chain evidence storage. The blockchain only needs to store this real-time status identifier to represent the complete state of all current data.

[0039] Specifically, as the project progresses and the original data of the multi-source electronic archives changes, the off-chain data cabin needs to be updated dynamically in real time. When data in the off-chain data cabin is added, deleted, or modified, the process of calculating hash, building structure, and generating root hash is re-executed to generate a new real-time status identifier, ensuring absolute synchronization between the real-time status identifier and the data content.

[0040] S20: Define key evidence storage events on the blockchain through smart contracts, and combine oracle services to listen for the trigger signals of the key evidence storage events;

[0041] Specifically, key evidence-keeping events are defined on the blockchain through smart contracts, and oracle services are used to listen for trigger signals of these key evidence-keeping events, including:

[0042] The triggering conditions for the key evidence storage event are defined through the smart contract;

[0043] Based on the oracle service, a decentralized oracle network is deployed, which is used to monitor whether the triggering condition is met.

[0044] The triggering condition is at least one of the following:

[0045] A predetermined number of participants use their private keys to digitally sign the content of the evidence-based event.

[0046] Event signals are emitted by an authorized third-party business platform through an application programming interface (API).

[0047] First, the triggering conditions for key evidence-gathering events are defined using smart contracts. A smart contract is a piece of automatically executing computer code deployed on the blockchain, defining rules and logic. Once the preset conditions are met, the code will execute automatically and cannot be prevented or tampered with. The key evidence-gathering events and the conditions that must be met to trigger them must be predefined in the smart contract. Key evidence-gathering events refer to milestones of significant quality or management importance in the lifecycle of highway engineering construction, including at least one of the following: process recording events, project acceptance events, and document management events. Among them, process recording events refer to events used to record important procedures, concealed works, and daily inspections during construction, such as project changes, project meetings and important decisions, handling of quality / safety accidents, and issuance of payment certificates; project acceptance events refer to events that signify quality compliance and acceptance by all parties during the acceptance process at each level of the project, from procedures, sub-items, and sub-sections to the unit project, such as pre-coverage documentation of concealed works, documentation of important procedures transferred to the next stage, acceptance of key materials / components upon arrival, acceptance of sub-sections / sub-items, and issuance of test reports; and document management events refer to key node events in the management process of electronic document creation, organization, transfer, and archiving, such as document transfer and receipt, authorized access and decryption, and document status updates (adjustment of security classification, change of retention period). The triggering conditions for each type of key documentation event are different.

[0048] Secondly, based on oracle services, a decentralized oracle network is deployed. Oracles serve as middleware for secure data interaction between the blockchain and off-chain systems. A decentralized oracle network consists of multiple independent node operators, not relying on a single trusted entity. Each independent node is jointly responsible for acquiring, verifying, and transmitting external data. Since the blockchain itself is a closed system and cannot actively access off-chain data or events, the oracle network continuously monitors the triggering conditions defined in smart contracts. Once the conditions are met off-chain, multiple oracle nodes independently acquire the information. When the oracle network reaches a consensus on the authenticity of the information through a consensus mechanism, it sends the verified trigger signal to the smart contract on the blockchain. The smart contract verifies the validity of the signal and performs a notarization operation.

[0049] The triggering conditions include multi-party signature triggering and third-party signal triggering, specifically at least one of the following methods: a preset number of participants use their private keys to digitally sign the content of the evidence storage event, or an authorized third-party business platform sends an event signal through an application programming interface.

[0050] A predetermined number of participants use their private keys to digitally sign the content of the evidence-keeping event. These participants refer to engineering entities with a stake in the event, such as construction companies, supervision companies, development companies, and design companies. Their blockchain identities are pre-recorded in a smart contract. The predetermined number refers to the minimum number of signatures required for the event to be considered valid. This typically employs an M / N multi-signature rule, where agreement from three out of four parties is sufficient to trigger the event. This prevents the process from stalling due to non-cooperation from one party and also prevents abuse of power by a single party. The private key is an encryption key held independently by each participant, representing their digital identity. Signing a message with the private key proves that the participant acknowledges the message content and serves as the sole credential for signing authority.

[0051] Furthermore, event signals emitted by authorized third-party business platforms via application programming interfaces (APIs) constitute external triggering conditions. These third-party business platforms refer to external systems with credibility and authority within their business scope, whose system data is considered a trusted source, such as government quality inspection platforms or laboratory management systems. They emit event signals through secure API interfaces. Authorized third-party business platforms must pre-register with smart contracts or oracle networks, indicating that the smart contracts trust their signals. Oracles obtain event states by polling or listening to the API interface.

[0052] S30: In response to the detected trigger signal, perform sampling verification on the off-chain data bay;

[0053] Specifically, in response to the detected trigger signal, sampling verification is performed on the off-chain data bay, including:

[0054] In response to the detected trigger signal, the event identifier is extracted and the trigger type of the key evidence storage event is determined accordingly;

[0055] Based on the trigger type of the key evidence storage event, the preset sampling verification range is invoked;

[0056] The oracle service initiates a query to the off-chain data cabin to request the real-time status identifier, and performs random sampling verification by combining the sampling verification range with the real-time status identifier.

[0057] Since the off-chain data cabin itself is a centralized system that may be tampered with or malfunction, the state identifiers it provides unilaterally cannot prove their authenticity. Therefore, sampling verification is also required as an independent trusted inspection mechanism.

[0058] First, in response to the detected trigger signal, the event identifier is extracted, and the trigger type of the key evidence storage event is determined accordingly. Specifically, the oracle network parses the received trigger signal to extract the event identifier. The event identifier is a unique digital credential representing a specific evidence storage event instance; it is essentially a set of structured metadata, including at least the event type, event name, and event trigger timestamp. This event identifier is generated when preset conditions are detected and transmitted to the oracle and smart contract along with the trigger signal, used to locate and trace the event source throughout the evidence storage process. By parsing the event identifier, the type of the currently triggered event can be accurately determined, and the corresponding sampling verification strategy can then be invoked.

[0059] Secondly, based on the trigger type of the key evidence storage event, a preset sampling verification range is invoked. Since sampling verification is a strategy that uses a small sample of data for inspection—a strategy that achieves high reliability at minimal cost—differentiated sampling ranges need to be preset for different trigger types and event attributes. Specifically, the oracle service has a pre-defined mapping table between trigger types and sampling strategies. This mapping table defines the specific sampling parameters corresponding to different event types. Once an event is determined to be triggered, its triggering method is first determined: it must be at least one of multi-party signature triggering or third-party API triggering. Specifically, for multi-party signature triggering, the determination requires verifying whether the number of participant signatures in the trigger signal reaches a preset value, and the signatures must be verified using the participant's public key registered in the smart contract. For third-party API triggering, the determination requires verifying whether the third-party platform identifier in the trigger signal is within the smart contract's preset authorization list, and the signal must be accompanied by the third-party platform's digital signature.

[0060] Furthermore, by identifying the event type, including process record events, project acceptance events, and document management events, the system automatically queries a mapping table to retrieve the corresponding, pre-defined sampling verification scope. The sampling verification scope includes: the sampling ratio (e.g., routine process record events may only require a 1% sampling rate, while critical project acceptance events may require 5%); and the scope of the sampling data (e.g., for project acceptance events, priority is given to data related to key control items in the quality acceptance standards, such as concrete strength test reports and rebar cover thickness test records). The more important the event and the stronger the data correlation, the more focused the sampling scope is on core data, and the higher the sampling ratio.

[0061] Furthermore, an oracle service is used to query the off-chain data cabin, requesting a real-time state identifier. Random sampling verification is then performed by combining the sampling verification range with the real-time state identifier. Specifically, this process is executed by one or more nodes in the decentralized oracle network: First, a request is sent to the service interface of the off-chain data cabin to obtain its latest state identifier, including the state root hash, data cabin version number, and timestamp. Then, based on the determined sampling verification range, the off-chain data cabin is requested to return a specified number of random file samples and their corresponding Merkle path proofs. The oracle nodes independently calculate hashes based on the obtained file data and verify whether they match the known state root hash using Merkle proofs. If all sampled files pass verification, the sampling verification is considered successful.

[0062] S40: If the sampling verification result is passed, a transaction summary is generated based on the real-time status identifier, the trigger signal, and the sampling verification result;

[0063] Specifically, if the sampling verification result is passed, a notarized transaction summary is generated based on the real-time status identifier, the trigger signal, and the sampling verification result, including:

[0064] Obtain the event identifier corresponding to the trigger signal, and update the off-chain data compartment according to the event identifier;

[0065] Based on the updated off-chain data bay, obtain the root hash of the evidence storage status;

[0066] Based on the real-time status identifier, extract the timestamp and data cabin version number;

[0067] The evidence storage status root hash, the timestamp, the data compartment version number, and the event identifier are combined to obtain the evidence storage transaction summary.

[0068] When the sampling verification result is passed, it proves that all original data of multi-source electronic archives in the off-chain data cabin at the time of the current key evidence storage event triggering point have not been tampered with or missing, and the overall data status is complete and correct. Furthermore, a summary of evidence storage transactions is generated based on the real-time status identifier, trigger signal, and sampling verification result.

[0069] First, the event identifier corresponding to the trigger signal is obtained, and the off-chain data container is updated based on the event identifier. The event identifier is an encoding carried in the trigger signal sent by the oracle, indicating what kind of event has occurred, and includes at least the event type, event name, and event trigger timestamp. The event identifier is obtained, and then notarization is performed for that specific event, appending the event identifier as a new data entry to the off-chain data container. Second, based on the updated off-chain data container, the notarization state root hash is obtained. This involves recalculating the value of the root node of the hash tree based on the latest data state, ensuring that the final notarization state root hash used for notarization not only represents the original data state at the time the event occurred, but also contains a reliable record that this operation has been performed for this notarization event, thus binding an immutable causal relationship between the event and the data state.

[0070] Furthermore, based on the real-time status identifier, the timestamp and data cabin version number are extracted, introducing a time dimension and sequential logic into the evidence storage transaction. The timestamp accurately records the moment the status identifier is generated, providing an immutable time anchor for the evidence storage content, while the data cabin version number identifies the specific position of the status in the continuous update sequence of the data cabin. Together, they constitute the unique coordinates of the evidence storage event in the spatiotemporal dimension, ensuring that each on-chain evidence storage summary has a traceable, reproducible, and logically ordered verification basis.

[0071] Finally, the root hash of the evidence storage state, timestamp, data compartment version number, and event identifier are merged to generate an evidence storage transaction digest, aggregating the scattered key elements into a lightweight global proof. The root hash of the evidence storage state represents the complete state of the data compartment after the event is triggered; the timestamp establishes the moment the evidence storage occurred; the data compartment version number identifies the sequence logic of the state update; and the event identifier expresses its specific business meaning. Through structured encapsulation, a self-contained, independently verifiable data unit is formed, providing the blockchain with a minimal evidence storage object that combines data integrity, time determinism, sequential continuity, and business relevance.

[0072] The data structure can be either a Merkle tree or a Merkle directed acyclic graph.

[0073] The event identifier includes at least the event type, event name, and event trigger timestamp.

[0074] S50: Submit the notarized transaction summary to the blockchain, execute the transaction through a smart contract, record it in the distributed ledger of the blockchain, and complete the trusted notarization of the electronic archive of the target engineering unit.

[0075] Specifically, the transaction summary is submitted to the blockchain, the transaction is executed via a smart contract, and recorded in the distributed ledger of the blockchain to complete the trusted electronic archiving of the target engineering unit. Following this, the process also includes:

[0076] Based on the evidence retrieval instruction, obtain the summary of the evidence-stored transaction to be verified from the blockchain;

[0077] Based on the notarized transaction summary, extract the data compartment version number, and use the data compartment version number to call and obtain the off-chain data compartment to be verified.

[0078] Obtain the event identifier of the notarized transaction summary, update the off-chain data compartment to be verified based on the event identifier, and calculate the root hash of the state to be verified accordingly;

[0079] The electronic archive trust verification of the target engineering unit is performed by comparing the root hash of the state to be verified with the root hash of the stored state of the stored transaction digest.

[0080] After generating the transaction summary, it is submitted to the blockchain. Following verification of the transaction's validity via a smart contract, the summary is packaged into a new block as transaction data. After consensus confirmation by network nodes, it is permanently written onto the blockchain's distributed ledger, ensuring that any subsequent attempts at tampering are immediately detected due to breaches of cryptographic connections. Therefore, the electronic record state of the target engineering unit at the time of a specific event achieves decentralized, globally verifiable, and permanently stored trusted evidence, realizing a complete closed loop from off-chain data to on-chain trust.

[0081] Following this, long-term verification and auditing are required. First, based on the evidence storage retrieval instruction, the digest of the evidence storage transaction to be verified is obtained from the blockchain. A query request is submitted to the blockchain network, containing search conditions such as the hash value of the evidence storage transaction or the event identifier and time range at the time of storage. Second, based on the evidence storage transaction digest, the data module version number is extracted, and the off-chain data module to be verified is retrieved. During verification, the evidence storage transaction digest is parsed, and the data module version number is extracted from it. Since the data module version number is the unique coordinate for establishing the correspondence between on-chain credentials and off-chain data, the verifier can obtain all the original electronic archive data corresponding to that version based on the data module version number.

[0082] Next, the event identifier is obtained, the off-chain data container to be verified is updated, and the root hash of the state to be verified is calculated. The verifier extracts the event identifier from the same notarized transaction digest, appends it as a new record to the corresponding version of the previously obtained off-chain data container, and recalculates the state root hash using the exact same hash algorithm and tree structure as when the notarization was performed, based on the updated data set. This yields the root hash of the state to be verified. Finally, the root hash of the state to be verified is compared with the notarized state root hash for trusted verification. If they are completely identical, it proves that all electronic file data in this version of the off-chain data container has not been tampered with since the notarization date, and its integrity is confirmed. If they are inconsistent, it proves that the original electronic files in the off-chain data container have been tampered with, or that the verification process is flawed.

[0083] This verification process does not rely on the backend or database of the original evidence storage system. Any verification agency can independently complete the verification with only blockchain access and read-only access to the data compartment, which can meet the requirements of auditing and judicial evidence collection.

[0084] In summary, the embodiments of this application have at least the following technical effects:

[0085] The beneficial effects of this invention are significantly reflected in multiple aspects such as efficiency, reliability, and scalability. Firstly, by adopting a collaborative architecture combining off-chain data storage and blockchain, the burden of storing and computing massive amounts of raw data is placed off-chain, with the blockchain storing only lightweight hash values. This greatly reduces on-chain load and evidence preservation costs, improving overall operational efficiency. Secondly, regarding reliability, the invention utilizes an oracle mechanism to monitor and trigger key evidence preservation events, combined with sampling verification to ensure the reliability of the off-chain data state upload process. Furthermore, relying on the immutable nature of the blockchain itself, it provides ultimate credible endorsement for the data state. Simultaneously, this invention supports the off-chain data storage to flexibly adapt to various storage solutions and evolve independently, effectively supporting the management needs of highway engineering archives with their extended lifecycles. Moreover, by focusing on key event nodes for evidence preservation based on multi-party consensus, the evidence preservation process better aligns with actual engineering management processes, significantly enhancing the effectiveness and probative value of evidence records in scenarios such as auditing and dispute resolution.

[0086] In summary, this invention comprehensively solves the long-standing problems in the management of electronic archives for highway engineering projects, such as the difficulty in balancing the cost of evidence preservation and the reliability of data, the lack of reliable consistency between off-chain original data and on-chain evidence preservation content, and the insufficient effectiveness caused by the disconnect between the archive preservation process and actual engineering management business.

[0087] Example 2, as Figure 2As shown, based on the same inventive concept as Embodiment 1, which provides a blockchain-based trusted evidence storage method for electronic archives of highway engineering projects, this embodiment of the invention also provides a blockchain-based trusted evidence storage system for electronic archives of highway engineering projects, comprising:

[0088] The off-chain data cabin module 11 is used to store multi-source electronic files of the target engineering unit according to a predetermined data structure and generate a real-time status identifier corresponding to the current data status.

[0089] Event listening module 12 is used to define key evidence storage events on the blockchain through smart contracts, and to listen for the trigger signals of the key evidence storage events in conjunction with oracle services.

[0090] The sampling verification module 13 is used to perform sampling verification on the off-chain data compartment in response to the detected trigger signal.

[0091] The evidence storage summary generation module 14 is used to generate an evidence storage transaction summary based on the real-time status identifier, the trigger signal and the sampling verification result when the sampling verification result is passed.

[0092] Blockchain evidence storage module 15 is used to submit the evidence storage transaction summary to the blockchain, execute the transaction through a smart contract and record it in the distributed ledger of the blockchain, thereby completing the trusted evidence storage of the electronic archives of the target engineering unit.

[0093] Specifically, the off-chain data cabin module 11 is used for:

[0094] Construct an off-chain data cabin for the target engineering unit, store the original multi-source electronic archive data of the target engineering unit in the off-chain data cabin according to a predetermined data structure, and generate a real-time status identifier corresponding to the current data status, including:

[0095] Obtain the original data of the multi-source electronic archives of the target engineering unit, wherein the original data of the multi-source electronic archives includes at least one of the following: design documents, inspection data, supervision logs, construction photos, video surveillance streams, and BIM models;

[0096] Obtain the multi-source logical relationships of the original data of the multi-source electronic archives, and construct the off-chain data cabin by combining the multi-source logical relationships with the predetermined data structure;

[0097] The original data of the multi-source electronic archives is organized based on the preset data structure and stored in the off-chain data compartment;

[0098] When the original data of the multi-source electronic archive changes, the off-chain data compartment is dynamically updated, and a corresponding real-time status identifier is generated. The real-time status identifier includes at least the state root hash, the data compartment version number, and the timestamp.

[0099] The event listening module 12 is specifically used for:

[0100] Key evidence-gathering events are defined on the blockchain through smart contracts, and trigger signals of these events are monitored using oracle services, including:

[0101] The triggering conditions for the key evidence storage event are defined through the smart contract;

[0102] Based on the oracle service, a decentralized oracle network is deployed, which is used to monitor whether the triggering condition is met.

[0103] The triggering condition is at least one of the following:

[0104] A predetermined number of participants use their private keys to digitally sign the content of the evidence-based event.

[0105] Event signals are emitted by an authorized third-party business platform through an application programming interface (API).

[0106] Specifically, the key evidence-preserving events include at least one of the following: process record events, project acceptance events, and document management events.

[0107] The sampling verification module 13 is specifically used for:

[0108] In response to the detected trigger signal, sampling verification is performed on the off-chain data bay, including:

[0109] In response to the detected trigger signal, the event identifier is extracted and the trigger type of the key evidence storage event is determined accordingly;

[0110] Based on the trigger type of the key evidence storage event, the preset sampling verification range is invoked;

[0111] The oracle service initiates a query to the off-chain data cabin to request the real-time status identifier, and performs random sampling verification by combining the sampling verification range with the real-time status identifier.

[0112] Specifically, the evidence digest generation module 14 is used for:

[0113] If the sampling verification result is successful, a transaction summary is generated based on the real-time status identifier, the trigger signal, and the sampling verification result, including:

[0114] Obtain the event identifier corresponding to the trigger signal, and update the off-chain data compartment according to the event identifier;

[0115] Based on the updated off-chain data bay, obtain the root hash of the evidence storage status;

[0116] Based on the real-time status identifier, extract the timestamp and data cabin version number;

[0117] The evidence storage status root hash, the timestamp, the data compartment version number, and the event identifier are combined to obtain the evidence storage transaction summary.

[0118] Specifically, the data structure can be either a Merkle tree or a Merkle directed acyclic graph.

[0119] Specifically, the event identifier includes at least the event type, event name, and event trigger timestamp.

[0120] Specifically, the blockchain evidence storage module 15 is used for:

[0121] The transaction summary is submitted to the blockchain, the transaction is executed via a smart contract, and recorded in the distributed ledger of the blockchain, thus completing the trusted electronic archiving of the target engineering unit. Afterwards, the process also includes:

[0122] Based on the evidence retrieval instruction, obtain the summary of the evidence-stored transaction to be verified from the blockchain;

[0123] Based on the notarized transaction summary, extract the data compartment version number, and use the data compartment version number to call and obtain the off-chain data compartment to be verified.

[0124] Obtain the event identifier of the notarized transaction summary, update the off-chain data compartment to be verified based on the event identifier, and calculate the root hash of the state to be verified accordingly;

[0125] The electronic archive trust verification of the target engineering unit is performed by comparing the root hash of the state to be verified with the root hash of the stored state of the stored transaction digest.

[0126] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. Additionally, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0127] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0128] This specification and accompanying drawings are merely illustrative examples of this application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Therefore, if such modifications and modifications fall within the scope of this application and its equivalents, this application intends to include such modifications and modifications.

Claims

1. A blockchain-based method for trusted storage of electronic archives for highway engineering projects, characterized in that, include: Construct an off-chain data cabin for the target engineering unit, store the original multi-source electronic archive data of the target engineering unit in the off-chain data cabin according to a predetermined data structure, and generate a real-time status identifier corresponding to the current data status; Key evidence-keeping events are defined on the blockchain through smart contracts, and oracle services are used to listen for the trigger signals of the key evidence-keeping events. In response to the detected trigger signal, the off-chain data compartment is sampled and verified. If the sampling verification result is passed, a transaction summary is generated based on the real-time status identifier, the trigger signal, and the sampling verification result. The transaction summary is submitted to the blockchain, the transaction is executed through a smart contract, and recorded in the distributed ledger of the blockchain to complete the trusted electronic archiving of the target engineering unit.

2. The blockchain-based trusted evidence storage method for highway engineering electronic archives as described in claim 1, characterized in that, Construct an off-chain data cabin for the target engineering unit, store the original multi-source electronic archive data of the target engineering unit in the off-chain data cabin according to a predetermined data structure, and generate a real-time status identifier corresponding to the current data status, including: Obtain the original data of the multi-source electronic archives of the target engineering unit, wherein the original data of the multi-source electronic archives includes at least one of the following: design documents, inspection data, supervision logs, construction photos, video surveillance streams, and BIM models; Obtain the multi-source logical relationships of the original data of the multi-source electronic archives, and construct the off-chain data cabin by combining the multi-source logical relationships with the predetermined data structure; The original data of the multi-source electronic archives is organized based on the preset data structure and stored in the off-chain data compartment; When the original data of the multi-source electronic archive changes, the off-chain data compartment is dynamically updated, and a corresponding real-time status identifier is generated. The real-time status identifier includes at least the state root hash, the data compartment version number, and the timestamp.

3. The blockchain-based trusted evidence storage method for highway engineering electronic archives as described in claim 2, characterized in that, Key evidence-gathering events are defined on the blockchain through smart contracts, and trigger signals of these events are monitored using oracle services, including: The triggering conditions for the key evidence storage event are defined through the smart contract; Based on the oracle service, a decentralized oracle network is deployed, which is used to monitor whether the triggering condition is met. The triggering condition is at least one of the following: A predetermined number of participants use their private keys to digitally sign the content of the evidence-based event. Event signals are emitted by an authorized third-party business platform through an application programming interface (API).

4. The blockchain-based trusted evidence storage method for highway engineering electronic archives as described in claim 3, characterized in that, The key evidence-preserving events include at least one of the following: process recording events, project acceptance events, and document management events.

5. A blockchain-based trusted evidence storage method for electronic archives of highway engineering projects as described in claim 4, characterized in that, In response to the detected trigger signal, sampling verification is performed on the off-chain data bay, including: In response to the detected trigger signal, the event identifier is extracted and the trigger type of the key evidence storage event is determined accordingly; Based on the trigger type of the key evidence storage event, the preset sampling verification range is invoked; The oracle service initiates a query to the off-chain data cabin to request the real-time status identifier, and performs random sampling verification by combining the sampling verification range with the real-time status identifier.

6. The blockchain-based trusted evidence storage method for electronic archives of highway engineering projects as described in claim 5, characterized in that, If the sampling verification result is successful, a transaction summary is generated based on the real-time status identifier, the trigger signal, and the sampling verification result, including: Obtain the event identifier corresponding to the trigger signal, and update the off-chain data compartment according to the event identifier; Based on the updated off-chain data bay, obtain the root hash of the evidence storage status; Based on the real-time status identifier, extract the timestamp and data cabin version number; The evidence storage status root hash, the timestamp, the data compartment version number, and the event identifier are combined to obtain the evidence storage transaction summary.

7. A blockchain-based trusted evidence storage method for electronic archives of highway engineering projects as described in claim 1, characterized in that, The data structure can be either a Merkle tree or a Merkle directed acyclic graph.

8. A blockchain-based trusted evidence storage method for electronic archives of highway engineering projects as described in claim 5, characterized in that, The event identifier includes at least the event type, event name, and event trigger timestamp.

9. A blockchain-based trusted evidence storage method for electronic archives of highway engineering projects as described in claim 6, characterized in that, The transaction summary is submitted to the blockchain, the transaction is executed via a smart contract, and recorded in the distributed ledger of the blockchain, thus completing the trusted electronic archiving of the target engineering unit. Afterwards, the process also includes: Based on the evidence retrieval instruction, obtain the summary of the evidence-stored transaction to be verified from the blockchain; Based on the notarized transaction summary, extract the data compartment version number, and use the data compartment version number to call and obtain the off-chain data compartment to be verified. Obtain the event identifier of the notarized transaction summary, update the off-chain data compartment to be verified based on the event identifier, and calculate the root hash of the state to be verified accordingly; The electronic archive trust verification of the target engineering unit is performed by comparing the root hash of the state to be verified with the root hash of the stored state of the stored transaction digest.

10. A blockchain-based trusted electronic archive storage system for highway engineering projects, characterized in that, For performing the method according to any one of claims 1-9, comprising: The off-chain data cabin module is used to store multi-source electronic files of the target engineering unit according to a predetermined data structure and generate a real-time status identifier corresponding to the current data status. The event listening module is used to define key evidence storage events on the blockchain through smart contracts and to listen for the trigger signals of the key evidence storage events in conjunction with the oracle service. The sampling verification module is used to perform sampling verification on the off-chain data compartment in response to the detected trigger signal. The evidence storage summary generation module is used to generate an evidence storage transaction summary based on the real-time status identifier, the trigger signal and the sampling verification result when the sampling verification result is passed. The blockchain evidence storage module is used to submit the evidence storage transaction summary to the blockchain, execute the transaction through a smart contract and record it in the distributed ledger of the blockchain, thereby completing the trusted evidence storage of the electronic archives of the target engineering unit.

Images