Construction process evidence storage method and system, and verification method and system

Abstract

The embodiment of the specification provides a construction process evidence storage method and system and a verification method and system. The storage method comprises the following steps: acquiring rules configured for a construction task and rule identifiers corresponding to the rules; when the construction task is executed, verifying one or more pieces of to-be-verified construction process data based on a verification condition, and generating a verification result; in response to the verification result being a verification pass, generating a process evidence package, and digitally signing the process evidence package by using a private key of an edge server; storing the digitally signed process evidence package in an off-chain storage device, and obtaining a content identifier corresponding to the digitally signed process evidence package returned by the off-chain storage device; and sending the content identifier, the digital signature and the rule identifier to a block chain network for notarization.

Description

Technical Field

[0001] This manual relates to the field of information technology in the construction industry, and in particular to a method, system, and verification method and system for storing evidence of the construction process. Background Technology

[0002] Construction logs and safety logs are core legal documents for engineering projects, and their legal evidentiary value depends on the authenticity of their content, compliance of the process, and the immutability of their storage. Although the construction process has now been digitized, some shortcomings exist: manual recording is inefficient and prone to errors; digital or blockchain-based evidence storage solutions only focus on the final document storage and cannot address the authenticity of the data source; and the system cannot verify the compliance of the data source in real time.

[0003] Therefore, it is necessary to provide a method, system, and verification method and system for storing construction process evidence, which can ensure the authenticity of data from the source, solidify evidence in a timely manner, and support automated verification. Summary of the Invention

[0004] One embodiment of this specification provides a method for storing construction process evidence. The storage method is executed via an edge server and includes: obtaining rules configured for a construction task and rule identifiers corresponding to the rules, wherein the rules reflect one or more construction process data to be verified and verification conditions corresponding to the one or more construction process data to be verified; when the construction task is executed, verifying the one or more construction process data to be verified based on the verification conditions and generating a verification result; in response to the verification result being a successful verification, generating a process evidence package and digitally signing the process evidence package using the private key of the edge server, wherein the process evidence package includes the rule identifier, the verification result, a process identifier of the one or more construction process data to be verified, and a process hash value; storing the digitally signed process evidence package to an off-chain storage device and obtaining a content identifier of the process evidence package corresponding to the digital signature returned by the off-chain storage device; and sending the content identifier, the digital signature, and the rule identifier to a blockchain network for evidence storage.

[0005] One embodiment of this specification provides a method for verifying construction process evidence. The verification method is used to verify construction process evidence stored by a storage method, comprising: accepting a verification request, the verification request including a rule identifier of a construction task to be verified; obtaining a corresponding content identifier and digital signature from a blockchain network based on the rule identifier; obtaining a process evidence package corresponding to the content identifier and the digital signature from an off-chain storage device based on the content identifier and the digital signature; verifying the validity of the digital signature on the process evidence package based on a public key corresponding to an edge server; and verifying the construction process evidence based on the process evidence package when the validity verification passes.

[0006] One embodiment of this specification provides a storage system for construction process evidence. The storage system includes: an acquisition module configured to acquire rules configured for a construction task and rule identifiers corresponding to the rules, wherein the rules reflect one or more construction process data to be verified and verification conditions corresponding to the one or more construction process data to be verified; a verification module configured to verify the one or more construction process data to be verified based on the verification conditions when the construction task is executed, and generate a verification result; a generation module configured to generate a process evidence package in response to the verification result being a verification pass, and digitally sign the process evidence package using the private key of the edge server, wherein the process evidence package includes the rule identifier, the verification result, a process identifier of the one or more construction process data to be verified, and a process hash value; a storage module configured to store the digitally signed process evidence package to an off-chain storage device, and obtain a content identifier of the process evidence package corresponding to the digital signature returned by the off-chain storage device; and an evidence preservation module configured to send the content identifier, the digital signature, and the rule identifier to a blockchain network for evidence preservation.

[0007] One embodiment of this specification provides a verification system for construction process evidence, comprising: an acceptance module configured to accept verification requests, the verification requests including a rule identifier of a construction task to be verified; a first acquisition module configured to acquire a corresponding content identifier and digital signature from a blockchain network based on the rule identifier; a second acquisition module configured to acquire a process evidence package corresponding to the content identifier and the digital signature from an off-chain storage device based on the content identifier and the digital signature; a verification module configured to verify the validity of the digital signature on the process evidence package based on a public key corresponding to an edge server; and a verification module configured to verify the construction process evidence based on the process evidence package in response to the successful verification of the validity.

[0008] One embodiment of this specification provides a storage device for construction process evidence, the device including at least one processor and at least one memory; the at least one memory is used to store computer instructions; the at least one processor is used to execute at least a portion of the computer instructions to implement the storage method as described above.

[0009] One embodiment of this specification provides a verification device for construction process evidence. The device includes at least one processor and at least one memory; the at least one memory is used to store computer instructions; the at least one processor is used to execute at least a portion of the computer instructions to implement the verification method as described above.

[0010] One embodiment of this specification provides a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions in the storage medium, the computer executes the storage method or the verification method described above. Attached Figure Description

[0011] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0012] Figure 1 This is a schematic diagram illustrating an application scenario of a system for storing construction process evidence, based on some embodiments of this specification. Figure 2 This is an exemplary block diagram of a system for storing construction process evidence according to some embodiments of this specification; Figure 3 This is an exemplary flowchart of a method for storing construction process evidence according to some embodiments of this specification; Figure 4 This is an exemplary schematic diagram of a risk assessment model shown according to some embodiments of this specification; Figure 5 This is an exemplary flowchart of a method for verifying construction process evidence according to some embodiments of this specification. Detailed Implementation

[0013] The accompanying drawings used in the description of the embodiments will be briefly introduced below. The drawings do not represent all embodiments.

[0014] The terms “system,” “device,” “unit,” and / or “module” as used herein are one method of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0015] Unless the context clearly indicates an exception, words such as "a," "an," "a kind," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0016] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of a system for storing construction process evidence, based on some embodiments of this specification.

[0018] In some embodiments, such as Figure 1 As shown, the application scenario 100 of the construction process evidence storage system includes a server 110, other data sources 120, storage devices 130, user terminals 140, and a network 150.

[0019] Server 110 can be used to manage resources and process data and / or information from at least one component of the system or an external data source (e.g., a cloud data center). In some embodiments, server 110 can be a single server or a group of servers. The server group can be centralized or distributed (e.g., edge servers can be distributed systems), and can be dedicated or simultaneously provided by other devices or systems. In some embodiments, server 110 can be regional or remote. In some embodiments, server 110 can be implemented on a cloud platform or provided virtually. By way of example only, a cloud platform can include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-tiered cloud, etc., or any combination thereof.

[0020] In some embodiments, server 110 includes edge servers, verification servers, etc.

[0021] An edge server can be a computing and access unit deployed at a construction site, such as a dedicated server or an industrial computer. The edge server is configured to receive construction process data to be inspected in real time; based on preset rules, it processes and logically judges the received data locally; it encapsulates the judgment results and related original data (construction process data), and ensures the integrity, immutability, and traceability of the data through a signature mechanism.

[0022] Verification servers are servers deployed in the cloud, regulatory data centers, or third-party auditing firms. They are configured to verify data packaged on edge servers to ensure accuracy.

[0023] Other data sources 120 refer to one or more sources that provide additional information to the system. Other data sources 120 can be one or more devices, one or more application programming interfaces (APIs), one or more database query interfaces, one or more protocol-based information retrieval interfaces, other methods of information retrieval, or a combination of two or more of the above methods. The information provided by other information sources can exist at the time of information retrieval, be generated temporarily at the time of information retrieval, or be a combination of the above methods. In some embodiments, other data sources 120 can be federated learning aggregation servers. Federated learning aggregation servers refer to trusted relay service nodes deployed in the cloud or on a consortium blockchain. The federated learning aggregation server is configured to globally optimize the data uploaded by edge servers and return the optimized data to the edge servers.

[0024] Storage device 130 can be used to store data and / or instructions. Storage device 130 may include one or more storage components, each of which may be a separate device or part of another device. In some embodiments, storage device 130 may include random access memory (RAM), read-only memory (ROM), mass storage, removable memory, volatile read-write memory, etc., or any combination thereof. Exemplarily, mass storage may include disks, optical disks, solid-state drives, etc. In some embodiments, storage device 130 may be implemented on a cloud platform. In some embodiments, storage device 130 includes off-chain storage devices, etc.

[0025] User terminal 140 refers to one or more terminal devices or software used by a user. In some embodiments, the user of user terminal 140 may be one or more users, including users who directly use the service (i.e., users performing construction tasks) and other related users (i.e., users receiving collaboration requests). In some embodiments, user terminal 140 may be one or any combination of other devices with input and / or output functions, such as mobile device 140-1, tablet computer 140-2, laptop computer 140-3, and desktop computer 140-4. In some embodiments, user terminal 140 includes related user terminals, verification request initiators, etc.

[0026] Network 150 can connect the various components of the system and / or connect the system to external resources. Network 150 enables communication between the components and with other parts outside the system, facilitating the exchange of data and / or information. In some embodiments, network 150 can be any one or more of a wired network or a wireless network. For example, network 150 may include a cable network, fiber optic network, telecommunications network, Internet, local area network (LAN), wide area network (WAN), wireless local area network (WLAN), metropolitan area network (MAN), public switched telephone network (PSTN), Bluetooth network, ZigBee network, near field communication (NFC), device bus, device wiring, cable connection, etc., or any combination thereof.

[0027] It should be noted that the application scenario 100 of the construction process evidence storage system is provided for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can make various modifications or variations based on the description in this specification. For example, the application scenario 100 of the construction process evidence storage system can achieve similar or different functions on other devices. However, these changes and modifications will not depart from the scope of this application.

[0028] Figure 2 This is an exemplary block diagram of a system for storing construction process evidence according to some embodiments of this specification.

[0029] In some embodiments, such as Figure 2 As shown, the construction process evidence storage system 200 (hereinafter referred to as the system) includes an acquisition module 210, a verification module 220, a generation module 230, a storage module 240, and an evidence preservation module 250.

[0030] The acquisition module 210 refers to the module used to acquire rules and rule identifiers. In some embodiments, the acquisition module 210 is configured to acquire rules configured for construction tasks and rule identifiers corresponding to the rules, wherein the rules reflect one or more construction process data to be verified and one or more verification conditions corresponding to the construction process data to be verified.

[0031] The verification module 220 refers to a module used to verify construction process data. In some embodiments, the verification module 220 is configured to verify one or more construction process data to be verified based on verification conditions during the execution of a construction task, and generate verification results.

[0032] The generation module 230 refers to the module used to generate a process evidence package. In some embodiments, the generation module 230 is configured to generate a process evidence package in response to a verification result of passing the verification, and to digitally sign the process evidence package using the private key of the edge server. The process evidence package includes a rule identifier, a verification result, a process identifier and a process hash value of one or more construction process data to be verified.

[0033] Storage module 240 refers to a module used for storing procedural evidence packages. In some embodiments, storage module 240 is configured to store the digitally signed procedural evidence package to an off-chain storage device and obtain a content identifier corresponding to the digitally signed procedural evidence package returned by the off-chain storage device.

[0034] The evidence storage module 250 refers to a module used for storing content identifiers, etc. In some embodiments, the evidence storage module 250 is configured to send the content identifier, digital signature, and rule identifier to a blockchain network for evidence storage.

[0035] In some embodiments, one or more of the acquisition module 210, verification module 220, generation module 230, storage module 240, and evidence preservation module 250 may be integrated into an edge server.

[0036] For more information on the construction process evidence storage system 200, please refer to [link / reference needed]. Figures 3-5 The corresponding description.

[0037] It should be noted that the above description of the construction process evidence storage system 200 and its modules is for convenience only and should not limit this specification to the scope of the embodiments described. It is understood that those skilled in the art, after understanding the principles of this system, may arbitrarily combine the various modules or construct subsystems connected to other modules without departing from these principles. In some embodiments, Figure 2 The acquisition module 210, verification module 220, generation module 230, storage module 240, and evidence storage module 250 disclosed herein can be different modules within a single system, or a single module can implement the functions of two or more of the aforementioned modules. For example, the modules can share a single storage module, or each module can have its own separate storage module. Such variations are all within the scope of protection of this specification.

[0038] Figure 3 This is an exemplary flowchart of a method for storing construction process evidence according to some embodiments of this specification. In some embodiments, process 300 may be executed by an edge server. Figure 3 As shown, process 300 includes the following steps.

[0039] Step 310: Obtain the rules configured for the construction task and the rule identifiers corresponding to the rules.

[0040] Construction tasks refer to the specific operational activities during the implementation of an engineering project. For example, construction tasks could include hoisting steel structures for buildings or binding reinforcement bars for basement slabs.

[0041] Rules refer to the business logic or technical constraints used to determine whether the execution of a construction task is compliant. For example, rules include safety rules for the construction site, internal rules of the construction unit, and relevant rules configured for the construction task.

[0042] In some embodiments, a rule may include multiple rules, each rule reflecting one or more construction process data to be verified and the corresponding verification conditions for one or more construction process data to be verified.

[0043] Construction process data refers to raw data that reflects the real-time status or specific operational activities on site during the execution of a construction task. In some embodiments, the construction process data to be verified includes one or more items, such as real-time wind speed, concrete temperature, operator certificate number, inspection photos, etc.

[0044] In some embodiments, the edge server can acquire construction process data to be verified in various ways. For example, the edge server can interact and link with various sensors. The construction process data to be verified can be automatically collected by various sensors, exported by an information system, or generated through manual input, and then transmitted to the edge server. The edge server can receive the construction process data to be verified, which is automatically collected by various sensors, exported by an information system, or generated through manual input. These various sensors include wind speed sensors, temperature and humidity sensors, noise sensors, dust sensors, etc. An information system refers to a software platform or database system used to store, process, and manage data related to construction tasks, and capable of data interaction with external devices. External devices refer to hardware devices or software modules independent of the information system itself that can exchange data with it. For example, information systems include human resource systems, project inspection systems, etc. As an example only, for a project inspection system, the mobile phones, tablets, walkie-talkies, etc., of inspection personnel are external devices. A project inspection system refers to a software system used for on-site quality, safety, and progress inspection and management of engineering projects. The inspection photos uploaded by the project inspection system can be used as construction process data to be verified.

[0045] Verification criteria refer to the compliance standards set for the construction process data to be verified. In some embodiments, verification criteria can be represented by thresholds, ranges, or status matching. For example, verification criteria include real-time wind speed <12m / s, concrete pouring temperature between 10℃ and 30℃, and certificate status being valid. The above thresholds, ranges, etc., are preset according to actual requirements.

[0046] A rule identifier is a unique identifier assigned to each rule. In some embodiments, the rule identifier is used to locate and invoke a specific rule, and to bind all generated construction process data to that rule in subsequent processes.

[0047] In some embodiments, the edge server can obtain the rules configured for the construction task and the corresponding rule identifiers in various ways. For example, the edge server can load the rules configured for the construction task and the corresponding rule identifiers by engineering experts, such as safety directors and quality managers, based on a rule template library. The rule template library refers to a pre-stored collection of standardized, reusable templates containing different rules and rule identifiers configured for different construction tasks. As an example, during the system initialization phase, based on the rule template library, a rule and its corresponding rule identifier RULE_TEMP_001 are configured for the "concrete pouring" construction task. This rule reflects that the construction process data to be verified is "concrete pouring temperature," and the corresponding verification condition is "the concrete pouring temperature is between 10℃ and 30℃." Before the construction task begins, the edge server can load this rule and enter real-time monitoring mode, waiting to receive construction process data for verification.

[0048] In some embodiments, the edge server can also obtain safety rules of the construction site and internal rules of the construction unit related to the construction task through the network, and automatically generate corresponding rule identifiers for them.

[0049] Step 320: When the construction task is executed, verify one or more construction process data to be verified based on the verification conditions, and generate verification results.

[0050] Verification results refer to the results obtained after verifying the construction process data to be verified. For example, verification results include verification passed and verification failed.

[0051] In some embodiments, during the execution of a construction task, the edge server can obtain the values ​​of various items (such as real-time wind speed, concrete pouring temperature, etc.) in the construction process data to be verified in the construction task, compare the corresponding values ​​with the corresponding thresholds in the verification conditions, and determine that the verification passes when the corresponding values ​​meet the corresponding thresholds in the verification conditions; otherwise, the verification fails. As an example, when the pouring operation begins, the edge server obtains the reading of the temperature sensor installed at the pump inlet of the concrete pump (for example, a reading of 22.5℃), calls the rule identifier RULE_TEMP_001 and its corresponding rule, compares the reading (22.5℃) with the range (10℃-30℃) in the verification conditions, and determines that the verification passes if the reading is within the range.

[0052] Step 330: In response to a successful verification result, a process evidence package is generated, and the process evidence package is digitally signed using the edge server's private key.

[0053] A process evidence package refers to the set of evidence generated for a single verification. In some embodiments, a process evidence package includes a rule identifier, a verification result, a process identifier and a process hash value of one or more construction process data to be verified.

[0054] A process identifier is a unique identification code assigned to a single piece (or a single collection) of construction process data.

[0055] In some embodiments, the edge server can generate a process identifier by concatenating a data source identifier and a timestamp. The data source identifier is a unique identifier assigned to the source of each construction process data. The timestamp is the point in time when the process data to be verified was acquired. For example, the process identifier could be Thermometer-7_20231027143005, indicating that the data acquisition device is thermometer number 7 and the timestamp is October 27, 2023, at 14:30:05.

[0056] A process hash value is a string obtained by performing mathematical operations on construction process data. In some embodiments, the process hash value can be obtained using a hash algorithm. Hash algorithms include secure hash algorithms, lightweight hash algorithms, etc.

[0057] In some embodiments, in response to a successful verification result, the edge server can generate a process evidence package in various ways. As an example only, the edge server can invoke the rule identifier and verification result for this verification, and generate a corresponding process identifier and process hash value for each piece of construction process data involved in the verification, assembling the aforementioned data into structured text, i.e., the process evidence package.

[0058] In some embodiments, during the execution of a construction task, the edge server can perform real-time risk assessment based on one or more construction process data to be verified using a risk prediction model to obtain a risk score; in response to a successful verification result, a process evidence package containing the risk score is generated. For more information on this section, please refer to... Figure 4 And its corresponding description.

[0059] In some embodiments, the edge server may generate a collaboration request containing a rule identifier and send it to the relevant user terminal; receive and verify digital signatures from the relevant user terminal, and determine a set of digital signatures based on the verified digital signatures; and generate a process evidence package containing the set of digital signatures in response to a verification result that the verification is successful.

[0060] A collaboration request is a request for manual confirmation or endorsement of the verification results.

[0061] In some embodiments, a collaboration request may be a digital confirmation request automatically created by the system after the edge server completes the verification and generates the verification result.

[0062] In some embodiments, a collaboration request may include a rule identifier, a timestamp, a task identifier, and a verification result. The task identifier is a unique identifier used to represent a construction task. The task identifier can be generated by the system by default. The edge server can send the generated collaboration request to the relevant user client.

[0063] Taking "concrete pouring" as an example, before executing this task, a joint acceptance inspection of the high-rise formwork support system before concrete pouring is required. The corresponding construction task is "Stability Check of Formwork Support System" (task identifier: POUR-20231027-001). Rules and corresponding rule identifiers (such as RULE_FORMWORK_SAFETY) are configured for the construction task. The rules reflect the construction process data to be verified as the axial force and horizontal displacement of the uprights. The verification conditions are that the axial force of the uprights is within the range of 40kN-50kN and the horizontal displacement is within the range of 30mm-50mm. The verification process for this construction task can be found in the previous description. In response to successful verification, the edge server can generate a collaboration request. The collaboration request includes: rule identifier: RULE_FORMWORK_SAFETY, task identifier: POUR-20231027-001, verification result: passed, and timestamp.

[0064] Relevant user terminals refer to terminal devices pre-installed and held by personnel responsible for supervising, reviewing, or managing specific construction tasks or rules. For example, relevant user terminals include terminals belonging to project supervising engineers, safety officers, and owner representatives.

[0065] In some embodiments, upon receiving a collaboration request, the relevant users (i.e., project supervising engineers, safety officers, owner representatives, etc.) view the collaboration request on their respective user terminals (such as mobile phones). After confirming that the on-site inspection data and verification results are correct, they click "Confirm" or "Approve" on the user terminal interface, thus entering the subsequent digital signature process. The on-site inspection data refers to the values ​​of the aforementioned construction process data to be verified.

[0066] In some embodiments, each relevant user terminal holds its own exclusive asymmetric key pair (private key for signing, public key for verification), etc.

[0067] Digital signature is a cryptographic technique based on asymmetric encryption algorithms.

[0068] A signer's digital signature is the result of mathematical operations performed on a data fragment and the signer's private key. For example, a relevant user's digital signature is a data string generated by encrypting a collaboration request using their proprietary private key. Another example is a data string generated by encrypting a specific digest of a process evidence package using their proprietary private key. The specific digest of a process evidence package refers to a specific version of the process evidence package generated for different relevant user clients. For example, a specific digest of a process evidence package sent to the project supervising engineer contains all sensor data; a specific digest of a process evidence package sent to the owner's representative only contains the final conclusion and photographs. Different specific digests represent confirmations within their respective scopes of authority.

[0069] In some embodiments, after receiving a digital signature from a relevant user terminal, the edge server uses the user terminal's public key to perform cryptographic operations on the received digital signature and related data to verify whether it satisfies requirements such as identity authenticity, data integrity, and data non-repudiation. Identity authenticity means that the digital signature was indeed generated by the relevant user terminal holding the corresponding private key. Data integrity means that the digitally signed content has not been tampered with during transmission and storage. Data non-repudiation means that the relevant user terminal cannot deny its confirmation of the content of the cooperation request.

[0070] In some embodiments, when the authenticity of identity, data integrity, and data non-repudiation are all satisfied, the edge server confirms that the digital signature has been verified.

[0071] A digital signature set refers to the collection of digital signatures from all relevant user terminals that have been verified in a multi-party collaborative confirmation process for the same collaborative request. In some embodiments, the digital signature set is used to cryptographically document the actions of multiple responsible parties (relevant user terminals) jointly participating in the verification of an event.

[0072] In some embodiments, the edge server can collect all verified digital signatures to form a digital signature set. In some embodiments, in response to a verification result of passing verification, a process evidence package containing the digital signature set is generated. The process evidence package includes a rule identifier, a verification result, an identifier and hash value of each piece of construction task process data in one or more construction task process data, and the digital signature set, etc.

[0073] In some embodiments of this specification, the steps in construction management that require signature confirmation from relevant users are embedded into the automated evidence chain generation process. This digitizes and cryptographically transforms manual confirmation actions, achieving a deep integration of legal procedures and digital processes. By collecting and solidifying verified digital signatures from various relevant users, the process evidence package is upgraded from a "system-issued report" to an "electronic certificate jointly confirmed by multiple parties," constructing an undeniable multi-party responsibility traceability system. Introducing a set of digital signatures from relevant users is equivalent to adding "human verification" and "collective decision-making" endorsement to the machine's judgment, greatly enhancing the acceptability and authority of such key evidence in internal audits, third-party audits, or legal procedures. Compared with the traditional transmission, collection, scanning, and archiving of paper-based countersignature forms, this mechanism achieves instantaneous synchronization of multi-party confirmation, online completion, automatic archiving, and permanent anti-counterfeiting, improving management efficiency and forming credible archives.

[0074] In some embodiments, the edge server can generate a corresponding zero-knowledge proof based on one or more construction process data to be verified and verification conditions. The zero-knowledge proof represents the ability to prove that one or more construction process data to be verified meet the verification conditions without disclosing one or more construction process data to be verified. In response to a verification result of verification passing, a process evidence package containing the zero-knowledge proof is generated.

[0075] Zero-knowledge proofs are verifiable cryptographic evidence generated by a prover (such as an edge server) for a verifier (such as an auditor, supervisory agency, regulatory agency, auditing platform, etc.). Zero-knowledge proofs can demonstrate the truthfulness of a statement to a verifier that "the original data meets a preset verification condition (such as not exceeding a threshold, being within a preset range, or matching a state)" without disclosing the original data (i.e., the content of the construction process data to be verified).

[0076] In some embodiments, the edge server can generate zero-knowledge proofs through two steps: **Circuit pre-compilation step:** During system deployment, a trust setup process is performed for each predefined assertion to generate the corresponding zero-knowledge proof circuit and its cryptographic parameters. The cryptographic parameters include a proof key and a verification key. The proof key is deployed on the edge server to generate the zero-knowledge proof; the verification key is publicly available for verification by the verifier. **Proof generation step:** During automated verification of a specific construction task, the edge server takes two types of data as input: one is private input, i.e., the specific data content that needs to be protected, including the content of the construction process data to be verified, timestamps, process identifiers, etc.; the other is public input, including rule identifiers, verification results, process hash values, etc. The edge server calls the prover corresponding to the rule, using the private and public inputs as parameters, to run the pre-compiled zero-knowledge proof circuit and generate a proof string (i.e., the zero-knowledge proof). Here, the predefined assertion refers to an atomic statement in a predefined rule that can be independently proven. For example, assuming the rule includes "the operator must hold a valid certificate and be no more than 60 years old," then predefined assertions include "the certificate is valid" and "the age is less than or equal to 60 years old." A trusted setup is a one-time cryptographic protocol executed during the initialization phase of a zero-knowledge proof system. Its purpose is to generate public cryptographic parameters (proof key and verification key) for a specific zero-knowledge proof circuit and ensure that the security of these parameters does not depend on any single party. A zero-knowledge proof circuit is a formalized description of the assertion to be proven (such as "the certificate is valid") into a system of mathematical constraints. Zero-knowledge proof circuits include zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs) circuits, etc. A prover is a software component or algorithmic entity in a zero-knowledge proof system responsible for generating proofs. Proofrs include ZK provers, etc.

[0077] As an example only, assume the rule reflects the construction process data to be verified as a certificate status, the corresponding verification condition is "the welding operator must hold a valid special operation certificate," and the predefined assertion is "the certificate is valid." During construction task execution, the edge server reads the welding operator's certificate information and verifies its validity. In response to validity, it generates a corresponding process evidence package, including a rule identifier, verification result, a process identifier and process hash value for the certificate status, and a zero-knowledge proof. This zero-knowledge proof states that "the certificate data used for verification at this moment is valid."

[0078] In some embodiments of this specification, by embedding zero-knowledge proofs in the process evidence package, selective disclosure of evidence content is achieved: all facts are shown to high-authority parties, while only compliance conclusions are shown to low-authority parties. This mechanism constructs a hierarchical, configurable trust output system, enabling the secure output of the credible state of the construction process to supply chain partners, insurance companies, or regulatory authorities. It satisfies evidentiary requirements with cryptographic strength while protecting trade secrets and the privacy of relevant parties, significantly enhancing the applicability and acceptability of evidence in complex legal and commercial environments. The process evidence package containing zero-knowledge proofs allows the holder to cryptographically prove the authenticity of specific facts to the verifying party without disclosing specific data details when evidence is required in disputes or audits. This represents a systematic upgrade of evidence from simple, transparent storage to support hierarchical disclosure and programmable trust output, ensuring that the evidence system built upon it maintains its effectiveness and acceptability in complex legal and commercial environments where trade secrets or the privacy of unrelated parties must be protected.

[0079] The edge server's private key is the confidential part of its digital identity card, used to digitally sign process evidence packages to prove their authenticity and integrity. The edge server's private key is generated during system initialization.

[0080] In some embodiments, after generating the process evidence package, the edge server can convert the content of the process evidence package into a unified byte string format; perform a hash operation on the unified byte string to generate a fixed-length digest value; the edge server can read its private key and perform a signature operation on the digest value; and append the generated signature value to the original process evidence package to form the final digitally signed process evidence package. The conversion to a unified byte string format can be implemented using any feasible method, such as text-based serialization or binary-based serialization. The hash operation can be performed using secure hash algorithms, lightweight hash algorithms, etc. The fixed length can be 32 bytes, 64 bytes, etc. As an example, when the reading of 22.5℃ is compared with the range of 10℃-30℃ in the verification conditions, and the verification is deemed successful, the edge server obtains the process identifier "Thermometer-7_20231027143005" based on the temperature sensor and timestamp used to obtain the concrete pouring temperature, calculates the process hash value based on 22.5℃, and thus obtains the process evidence package. The edge server uses its own private key to digitally sign the entire contents of the process evidence packet, generating an additional signature data, such as Sig_Node_A. At this point, the process evidence packet is bound to the digital signature, representing the edge server's authentication of the event record.

[0081] Step 340: Store the digitally signed process evidence package to an off-chain storage device and obtain the content identifier of the digitally signed process evidence package returned by the off-chain storage device.

[0082] Off-chain storage devices refer to distributed file storage systems or services that are independent of the blockchain network and used to store large volumes of data. Examples of off-chain storage devices include the InterPlanetary File System (IPFS) and distributed databases.

[0083] A blockchain network refers to a decentralized, tamper-proof, and traceable distributed ledger system jointly maintained by multiple participants (such as owners, supervisors, and construction companies). A content identifier is a unique and permanent address generated by off-chain storage devices based on the entire content of the process evidence package using hash algorithms and other methods.

[0084] In some embodiments, after receiving a digitally signed process evidence packet, the off-chain storage device calculates the content of the process evidence packet to generate a unique content identifier (e.g., QmTiyV9RfqR...) and returns this content identifier to the edge server. The calculation process may include: dividing the file into fixed-size data blocks and calculating a hash for each data block; constructing a Merkel directed acyclic graph (DAG) based on the data blocks; performing a hash operation on the root node of the entire DAG to obtain the root hash of the file; combining the root hash with metadata such as a version identifier and a hash algorithm identifier to form a byte string with multiple format prefixes; and encoding the byte string to generate the content identifier string. The fixed size can be 256KB, etc. The version identifier refers to a fixed byte or encoding used to distinguish the format version of the content identifier. The hash algorithm identifier refers to a fixed byte encoding used to identify the type of hash algorithm used to generate the content identifier. Encoding methods include Base58 encoding, etc.

[0085] Step 350: Send the content identifier, digital signature, and rule identifier to the blockchain network for storage.

[0086] Evidence preservation refers to the process of writing the core fingerprint information (including rule identifiers, content identifiers, digital signatures, etc.) of the process evidence package into the blockchain network to form a permanent and tamper-proof evidence record.

[0087] In some embodiments, the edge server submits a rule identifier, a content identifier, and a digital signature as a single notarization transaction to the blockchain network. The rule identifier serves as an index key, the content identifier as a data location code for the process evidence package stored off-chain, and the digital signature as proof of origin. After receiving the notarization transaction, the blockchain network performs consensus verification, sorting, and packaging, ultimately solidifying the transaction record in the blockchain and returning the transaction hash and block height as a notarization receipt. Once notarization is complete, any verifying party can query the on-chain record using the rule identifier, retrieve the content identifier, and then retrieve the complete process evidence package from off-chain storage. By recalculating the content identifier and verifying the digital signature, they can independently confirm the authenticity, completeness, and credible source of the evidence.

[0088] In some embodiments of this specification, the generation of the process evidence package is moved from post-construction processing to in-process automatic execution, making the process evidence package a "digital twin record" of the construction process, ensuring the real-time nature and originality of the process evidence package. A complete evidence chain is formed through five layers of binding: "rule identifier" for verification, "process hash value" for locking construction process data, "verification result" for recording conclusions, "digital signature" for binding to the edge server, and "blockchain notarization" for fixing timestamps, ensuring traceability of anomalies. An architecture using off-chain storage devices to store the process evidence package and the blockchain network to anchor the content identifier ensures both economical storage of massive amounts of data and the immutability of the content identifier and digital signature, solving the bottleneck of on-chain storage. Simultaneously, the digital signature of the edge server enables non-repudiation of identity authentication; the process hash value ensures that once the content is not stored, it cannot be modified; and using the blockchain network for notarization solidifies the process evidence package in a distributed consensus, preventing unilateral destruction and tampering.

[0089] Figure 4 This is an exemplary schematic diagram of a risk assessment model shown in some embodiments of this specification.

[0090] In some embodiments, such as Figure 4 As shown, during the execution of a construction task, the edge server can perform real-time risk estimation based on one or more construction process data 401 to be verified, using the risk prediction model 402, to obtain a risk score 403. In response to a successful verification result, a process evidence package containing the risk score is generated. For more information on process evidence packages, edge servers, construction tasks, and construction process data to be verified, please refer to [link to relevant documentation]. Figure 1 and Figure 3 The corresponding description.

[0091] Real-time prediction refers to the continuous calculation process in which a risk prediction model analyzes and evaluates construction process data received from an edge server in real time during the construction task. In some embodiments, real-time prediction is performed synchronously with the construction task. At each moment when the construction process data to be monitored is acquired, the risk prediction model combines real-time data, time-series data, and static data to output an accurate risk score for that moment. The risk prediction model not only focuses on the current risk score but also predicts future risk trends by analyzing the changes in time-series data such as the fluctuation of concrete pouring temperature and the cumulative volume. When the system detects a continuous deterioration or accelerated change in risk indicators, it can issue an early warning, providing a window of opportunity for intervention.

[0092] A risk score is a metric output after quantitatively analyzing the current state of a construction process. It characterizes the likelihood and severity of a safety accident occurring within a future period. In some embodiments, the risk score can be represented in various ways. For example, it can be represented by a score ranging from 0 to 100, with higher scores indicating greater risk. Alternatively, it can be represented by four levels: low, medium, high, and critical.

[0093] In some embodiments, in response to a successful verification result, a process evidence package containing a risk score is generated. The process evidence package includes a rule identifier, the verification result, process identifiers and process hash values ​​of one or more construction process data to be verified, and a risk score. It is understood that the fact that the construction process data to be verified meets the verification conditions does not necessarily mean that the risk score is low; that is, there may be cases where the construction process data to be verified meets the verification conditions, but the risk score is "high risk".

[0094] A risk prediction model is a model used to determine a risk score. In some embodiments, the risk prediction model is a machine learning model, such as any one or a combination of Long Short-Term Memory (LSTM), Convolutional Neural Network (CNN), or other custom model structures.

[0095] In some embodiments, the risk prediction model performs a fusion analysis on the aforementioned multi-dimensional and heterogeneous data, potentially identifying risk patterns that are not easily captured by simple rules. For example, the inputs to the risk prediction model include: concrete pouring temperature of 22.5℃ (within the range of 10℃-30℃), ambient humidity of 95%, and pouring speed exceeding the recommended process threshold. The risk prediction model, through fusion analysis, identifies that although the combination of "high humidity + excessively fast pouring speed" does not trigger a single indicator alarm, the coupling of the two will significantly increase the risk of early concrete cracking. Accordingly, the risk prediction model outputs a risk score of 78 (out of 100), corresponding to a "high risk" level, prompting on-site personnel to take intervention measures.

[0096] In some embodiments, the input to the risk prediction model includes one or more construction process data to be verified, and the output includes a risk score.

[0097] In some embodiments, the inputs to the risk prediction model also include real-time data, time-series data, and static data. Real-time data refers to dynamic indicators reflecting the current instantaneous state. Time-series data refers to process data reflecting historical trends. Static data refers to inherent attributes bound to specific construction tasks. For example, taking "concrete pouring" as the construction task, real-time data includes ambient humidity, pouring speed, pump truck pressure, and formwork displacement monitoring data. Time-series data includes fluctuations in concrete temperature upon placement and the cumulative volume poured within a preset historical time period. Static data includes concrete grade, pouring location (e.g., shear wall or floor slab), and current work team information. Pouring speed refers to the volume of concrete poured per unit time. Pump truck pressure refers to the real-time hydraulic or pipeline pressure in the concrete pumping system. Formwork displacement monitoring data refers to the horizontal or vertical displacement of the formwork during concrete pouring. The preset historical time period can be the past 30 minutes, 60 minutes, etc. The preset historical time period can be set based on actual needs. The fluctuation of concrete pouring temperature refers to the characteristics of the concrete pouring temperature change, including: maximum temperature difference, rate of change, and fluctuation frequency. Concrete grade refers to the concrete strength grade, such as C30, C40, etc. Current work team information refers to the team identification and related attributes responsible for this pouring operation, including: team identifier, team leader, member qualifications, and historical quality records.

[0098] In some embodiments, the risk prediction model can be obtained in a variety of ways, such as by local training with a large number of labeled training samples.

[0099] In some embodiments, the edge server can obtain locally stored historical construction data as training samples, and obtain the actual risk scores corresponding to subsequent historical time periods for the construction process data of the historical time period as labels for the training samples. Here, a historical time period refers to a specific time period in the past, such as the past 10 minutes. The actual risk score refers to the score for a subsequent safety accident or other negative event occurring in a future historical time period corresponding to a given training sample. The actual risk score can be manually labeled.

[0100] Historical construction data refers to the collection of all data related to a specific construction task within a historical period, stored locally on an edge server. For example, historical construction data includes normal construction process data, accident records, and risk cases for a historical period. Normal construction process data refers to construction process data related to normal construction records. Accident records refer to construction records of quality / safety issues (cracks, formwork bursts, pipe blockages, etc.). Risk cases refer to rare risk patterns that may be missing from the company's historical data. In some embodiments, normal construction process data serves as negative samples, accident records as positive samples, and risk cases as expert samples.

[0101] A safety accident refers to an unexpected event that has caused or is highly likely to cause personal injury, property damage, or environmental harm. Other negative events refer to abnormal events that have not yet directly caused personal injury or property damage, but will seriously affect the construction progress, quality, cost, or reputation.

[0102] In some embodiments, the edge server can input training samples into an initial risk prediction model to obtain the output of the initial risk prediction model; construct a loss function based on the output of the initial risk prediction model and the labels of the training samples; iteratively update the parameters of the initial risk prediction model based on the loss function; and continue until preset conditions are met, training is complete, and a trained risk prediction model is obtained. These preset conditions include loss function convergence and the number of iterations reaching a threshold.

[0103] In some embodiments, the risk prediction model update process includes: training the risk prediction model locally based on historical construction data stored locally on the edge server to obtain the first weight parameters of the risk prediction model; encrypting the first weight parameters and uploading the encrypted first weight parameters to the federated learning aggregation server; receiving the second weight parameters issued by the federated learning aggregation server and updated globally, and updating the risk prediction model based on the second weight parameters.

[0104] In some embodiments, the edge server can train the risk prediction model locally based on locally stored historical construction data. The process of training based on historical construction data is similar to that of training based on training samples and labels, as described above.

[0105] The first weight parameter refers to the updated model parameters obtained after training the risk prediction model using locally stored historical construction data.

[0106] In some embodiments, the edge server can use the parameters of the risk prediction model obtained after training based on historical construction data as the first weight parameter.

[0107] In some embodiments, the first weight parameter (such as weights and biases in a convolutional neural network) encodes the risk patterns inherent in specific historical construction data, representing "local experience" learned by the risk prediction model from local data (i.e., construction process data of a construction site). Since the local data is always stored on a local edge server and never leaves the construction site, and the first weight parameter is encrypted before being uploaded or shared, the privacy protection goal of "data available but not visible" is achieved.

[0108] As an example only, suppose there are three different construction sites: A (sand pit), B (pebble layer pit), and C (soft soil pit). The edge servers for the three sites are trained based on their respective historical construction data to obtain the first weight parameter W. A W B and W C Among them, W A The risk model of sand dune shifting caused by inappropriate rainfall in sandy soil areas was encoded. B It exhibits higher sensitivity to risk patterns of support structure bias in gravel formations. C We studied the characteristics and patterns of foundation pit uplift and creep in soft soil areas.

[0109] In some embodiments, before uploading the first weight parameter from the edge server to the federated learning aggregation server, the edge server encrypts the first weight parameter using a preset algorithm and uploads the encrypted first weight parameter to the federated learning aggregation server. This prevents unauthorized third parties (including the federated learning aggregation server) from reading or reconstructing the actual parameter value, but the federated learning aggregation server can still perform aggregation calculations on these encrypted first weight parameters. The preset algorithm includes homomorphic encryption, secure multi-party computation, etc. The preset algorithm can be set according to actual needs. As an example only, the edge server encrypts the first weight parameter W... A W B W C Encryption is performed to obtain the encrypted W. A W B W C .

[0110] In some embodiments, the federated learning aggregation server is used to receive encrypted first weight parameters uploaded from multiple edge servers, and to perform fusion calculation on multiple first weight parameters according to a predetermined secure aggregation algorithm (such as federated averaging algorithm, etc.) to generate a better "global model" parameter that integrates knowledge from multiple parties, namely the second weight parameter.

[0111] The second weight parameter refers to the optimized global model weight parameter generated by the federated learning aggregation server after securely aggregating multiple received "first weight parameters". The second weight parameter encodes the local risk experience of all participating sites (covering various geological conditions such as sand, gravel, and soft soil). Compared to a local model (i.e., a risk prediction model) for a single site, it is trained under a wider data distribution and has a stronger adaptability to unseen conditions; it integrates multiple geological risk patterns such as quicksand, bias, and uplift, and can identify a wider range of potential risks. In some embodiments, the second weight parameter will be distributed to each participating node to update its local model.

[0112] In some embodiments, the federated learning aggregation server receives encrypted first weight parameters uploaded from multiple construction sites (e.g., multiple edge servers), performs global aggregation on these encrypted first weight parameters using a secure aggregation algorithm, and then sends the globally aggregated updated model parameters back to the multiple construction sites to update their respective local models (i.e., risk prediction models). A secure aggregation algorithm refers to a method within the federated learning framework where the federated learning aggregation server, without directly viewing the plaintext of the encrypted parameters uploaded by each participant, uses specific mathematical and cryptographic techniques to fuse and calculate multiple encrypted model parameters to generate a new model parameter representing global knowledge. For example, secure aggregation algorithms include secure aggregation based on homomorphic encryption and secure aggregation based on secure multi-party computation. As an example, assume there are t construction sites, and the encrypted first weight parameters uploaded by t construction sites are W1, W2, ..., W... t The second weighting parameter can be obtained through the federated average algorithm. The federated average algorithm can be expressed by the following formula (1): (1) in, Identify the second weight parameter. This represents the weight of the k-th construction site, where 1 ≤ k ≤ t. The weight can be determined by the local training sample size of each construction site; the larger the local training sample size, the greater the weight. The weight can also be set based on experience.

[0113] In some embodiments, after receiving the second weight parameter, the edge server can decrypt the second weight parameter according to a selected preset algorithm, and update the model parameters of the risk prediction model based on the decrypted second weight parameter to obtain the updated risk prediction model. For details on the preset algorithm, please refer to the preceding description.

[0114] As an example only, the federated learning aggregation server will optimize the second weight parameter. Distributed to construction sites A, B, and C. For use by each construction site. Update the local risk prediction model. After the update, the model for site A not only retains the original ability to identify risks in sandy soil, but also has the ability to identify risks of gravel layer bias and soft soil creep to a certain extent. Its generalization and accuracy of risk prediction have been comprehensively improved.

[0115] In some embodiments of this specification, by encrypting the first weight parameter, knowledge and experience sharing across projects and regions is achieved, breaking down the data silos that have long existed in the construction field and providing a feasible path for training a more powerful risk prediction model. Through the federated learning aggregation server, the risk prediction model can learn diverse risk patterns from different geological conditions, different processes, and different management styles, thereby significantly improving its adaptability and prediction accuracy in new scenarios and new projects, and enhancing the generalization ability and robustness of the risk prediction model. At the same time, federated aggregation enables the risk prediction model to periodically learn from the latest construction process data and integrate the latest experience from the entire network, supporting the continuous evolution and self-adaptation of the risk prediction model and building a distributed, sustainable, and intelligent ecosystem.

[0116] In some embodiments, the edge server may take corresponding risk control strategies in response to a risk score exceeding a preset threshold; and generate a process evidence package containing the risk score and risk control strategies in response to a verification result that passes the verification.

[0117] A preset threshold refers to a pre-set and configured critical value for one or more risk scores. In some embodiments, preset thresholds can be set in levels according to factors such as the task type and risk tolerance of the construction task. For example, preset thresholds include warning thresholds, high thresholds, and critical thresholds. Task type refers to the specific work category or procedure in the construction process, such as high-altitude work or ground work. Risk tolerance refers to the degree of risk acceptance by project stakeholders (owners, contractors, regulatory authorities, etc.), for example, construction near hospitals has low tolerance. The warning threshold is the critical value that triggers the lowest level alarm, indicating that there are potential risk signs at the construction site that require attention but do not yet constitute an imminent threat. The high threshold is the critical value that triggers a medium-to-high level alarm, indicating that the risk has significantly increased and exceeded the normal fluctuation range, requiring immediate intervention. The critical threshold is the critical value that triggers the highest level alarm, indicating that the risk is approaching or has reached a critical accident state, requiring emergency handling to ensure personnel safety. Preset thresholds can be manually preset based on experience or set by system default.

[0118] As an example, taking concrete pouring as an example, when the edge server receives a risk score of 78, it compares the risk score with a preset threshold. Assuming the high threshold is 75, since 78 > 75, the preset risk control strategy is triggered.

[0119] A risk control strategy refers to a set of predefined response actions or instructions that the system automatically triggers when the risk score exceeds a preset threshold. In some embodiments, a risk control strategy includes adjusting the data sampling frequency of sensors and / or issuing risk warnings.

[0120] Data sampling frequency refers to the number of times a sensor collects and records physical quantities per unit of time.

[0121] In some embodiments, when the risk score exceeds a preset threshold, the edge server instructs the relevant sensors to increase the data sampling frequency (e.g., from once per minute to once every 15 seconds) to obtain data with higher temporal resolution, facilitating more precise tracking of risk dynamics. Conversely, when the risk score is low, the data sampling frequency can be reduced to conserve resources.

[0122] Risk warnings are risk alerts sent to relevant personnel to remind them to pay attention to risks and take appropriate measures to prevent the situation from worsening.

[0123] In some embodiments, when the risk score exceeds a preset threshold, the edge server sends the risk warning information to the preset responsible personnel (such as team leaders, safety officers, project managers, etc.) in real time through preset communication channels (such as sound and light alarms, industrial IoT platform messages, SMS, application push, etc.).

[0124] As an example, taking concrete pouring as an example, when the risk score is 78, the edge server can simultaneously execute one or more of the following risk control strategies: The edge server sends instructions to sensors related to the pouring risk (such as formwork displacement monitoring sensors, pump truck pressure sensors, etc.) to adjust their data sampling frequency from the usual "once every 2 hours" to "once every 10 minutes"; or the edge server immediately generates a risk warning (e.g., Alert: Pouring point of floor slab No. 3 in Zone C, risk score is 78 (high risk), suspected increase in concrete cracking risk, please immediately check the pouring speed and environmental control measures), and sends it to the on-site commander, safety director and project manager, etc. via messages, SMS, etc.

[0125] In some embodiments, in response to a successful verification result, the edge server can generate a process evidence package containing a risk score and a risk control strategy, that is, the executed risk control strategy is included in the process evidence package. The process evidence package includes a rule identifier, a verification result, process identifiers and process hash values ​​of one or more construction process data to be verified, as well as a risk score and a risk control strategy, etc.

[0126] In some embodiments of this specification, by setting preset thresholds, the system can automatically execute preliminary risk control strategies, significantly shortening the time from risk identification to the implementation of risk control strategies, and realizing an automated closed loop from "risk perception" to "risk intervention." By adjusting the data sampling frequency of sensors, the system can acquire higher-density data during high-risk periods, providing support for accurate decision-making. During low-risk periods, resource consumption is reduced, optimizing the overall system efficiency and resource allocation. By incorporating the "adopted risk control strategies" into the process evidence package and credibly storing them, the handling process of each risk event becomes auditable, traceable, and replayable, providing managers with objective evidence to evaluate system effectiveness and personnel performance, while enhancing the decision-making and action dimensions of the evidence chain.

[0127] In some embodiments of this specification, by setting risk scores, the system's capabilities are expanded from passive response (checking established rules) to proactive early warning (predicting unknown risks), achieving a fundamental shift in the construction safety monitoring paradigm. Simultaneously, incorporating risk scores into the process evidence package adds a quantitative risk assessment of the construction task's state. Continuous risk scores record the risk evolution trajectory throughout the construction process, providing quantitative clues for tracing the root causes of accidents and enriching and deepening the information dimensions and value of the process evidence package. By introducing machine learning models, the system can learn and identify complex, implicit risk association patterns not covered by explicit rules (such as system risks arising from the superposition of multiple edge compliance conditions), improving the intelligence and foresight of safety management. As part of the process evidence package, the risk score maintains the consistency of the trusted architecture, is signed and confirmed by the edge server, ensuring the traceability and non-repudiation of the risk score's generator, and through hash anchoring and blockchain storage, ensures that the risk score cannot be tampered with once generated, enhancing the credibility of subsequent risk control strategies.

[0128] In some embodiments, in response to successful notarization on the blockchain network, the edge server may also determine the incentive amount based on a preset incentive strategy and distribute contribution credentials to one or more preset blockchain addresses. The one or more preset blockchain addresses are respectively associated with contributors to one or more construction process data to be verified; the incentive amount is positively correlated with both the contributor's credibility score and risk score.

[0129] Successful notarization refers to the event where a transaction initiated by an edge server, containing content identifiers, digital signatures, and rule identifiers, is confirmed by the blockchain network consensus and permanently recorded in a new block.

[0130] A pre-defined incentive strategy refers to a set of publicly transparent, automated incentive calculation rules that are pre-coded and deployed in a blockchain smart contract. In some embodiments, the pre-defined incentive strategy includes an algorithm that ultimately determines the incentive amount based on various input parameters (such as credibility scores, risk scores, etc.).

[0131] Incentive amount refers to the value unit used to quantify rewards for data contributors. Incentive amount typically corresponds to a specific number of blockchain contribution certificates. Blockchain contribution certificates are programmable, tradable digital value certificates issued and circulated on the blockchain network.

[0132] Contributors refer to the original sources of data during the construction process. For example, contributors include sensors, equipment, or data providers.

[0133] A credibility score is a dynamically maintained quantified value of historical reputation for each contributor. In some embodiments, the credibility score can be represented by a quantified numerical value, such as a value between 0 and 100.

[0134] In some embodiments, the credibility score is calculated based on quality dimensions such as the accuracy, timeliness, and continuity of the data provided by the contributor in the past. In some embodiments, the edge server calculates the quality dimensions such as the accuracy, timeliness, and continuity of the data provided by the contributor in the most recent evaluation period (e.g., the past 30 days) on a rolling basis, on a daily or weekly basis.

[0135] Accuracy refers to the degree of closeness between the construction process data received by the edge server and the trusted data. Trusted data refers to the value of the content corresponding to the construction process data obtained by the edge server through trusted methods (such as manual sampling, higher-precision instrument calibration, multi-sensor cross-validation, etc.). In some embodiments, the edge server can calculate the difference between a certain construction process data and its corresponding trusted data, and determine whether it is within the allowable threshold range. If it is within the allowable threshold range, the construction process data is confirmed as accurate, and the count is incremented by 1; otherwise, it is considered inaccurate. The number of times accuracy is confirmed within the evaluation period is counted, and the ratio of this number to the total number of data reported by contributors is calculated. This ratio is used as the accuracy. For example, if the wind speed sensor on the tower crane reports a wind speed of 15.2 m / s, and the on-site calibrator records a wind speed of 15.5 m / s, and the allowable threshold range is ±5%, then the edge server determines that the data reported by the wind speed sensor is accurate, and the count of accuracy is incremented by 1. The allowable threshold range can be set based on actual needs.

[0136] Timeliness refers to a quantitative indicator used to measure the uploading of construction process data to the edge server within a specified time window. The specified time window is a pre-defined allowed reporting period. For example, the specified time window is 5 minutes. The specified time window can be set based on actual needs. In some embodiments, the edge server can query the time when the sensor reports data. If the data is reported within the specified time window (T+), it is considered timely, and the count is incremented by 1; otherwise, it is considered untimely. The server counts the number of times data is considered timely within the evaluation period and calculates the ratio of this number to the total number of data reports submitted by the contributors. This ratio is used as the timeliness indicator. For example, the tower crane's wind speed sensor is required to report wind speed data every 5 minutes. If the data is reported within T+4 minutes, it is considered timely; if it is reported after T+5 minutes or not at all, it is considered untimely.

[0137] Continuity refers to a quantitative indicator used to assess whether there are interruptions or missing data in the collection of construction process data. In some embodiments, the edge server can calculate the ratio of the number of times construction process data is received within a specified working time to a preset number; and calculate the average of multiple ratios within the evaluation period, using the average as the continuity indicator. The specified working time can be 8 hours, etc. The preset number refers to the preset number of times construction process data needs to be reported within the specified working time, for example, 96 times.

[0138] In some embodiments, quality dimensions such as accuracy, timeliness, and continuity need to be normalized to map them to a 0-100 score scale for easier calculation of credibility scores. Normalization methods include linear piecewise normalization and extreme value normalization.

[0139] In some embodiments, the accuracy, timeliness, continuity, and other quality dimensions of the data previously provided by the contributor are positively correlated with the credibility score. The edge server can obtain the credibility score based on the quality dimensions using a preset formula. For example, the preset formula can be shown in the following formulas (2) and (3): (2) (3) In the formula, This represents the basic trust score. Indicates the first Performance score for each contribution This indicates the quality dimension number (such as accuracy, timeliness, continuity, etc.). Indicates the first Weights of each dimension Indicates the first The normalized values ​​of each dimension; This indicates the updated credibility score. This indicates the credibility score before the update. This represents the historical weighting factor. Where 0 < <1, such as It is 0.8, Configure according to actual needs. The weights of each dimension are pre-assigned by the system based on the importance of the construction task. For example, the weights for accuracy, timeliness, and continuity are 0.5, 0.3, and 0.2, respectively.

[0140] In some embodiments, when a contributor first accesses the system and has no prior ratings, the system assigns the contributor a basic trust score. For example, 70 points, etc.

[0141] In some embodiments, the credibility score also includes behavioral reward and punishment factors. Behavioral reward and punishment factors refer to data related to rewards or punishments for contributors' reporting behavior. These factors include positive incentives and negative penalties. Positive incentives mean that contributors who proactively report significant risks not detected by the system (such as sensor self-testing detecting and reporting faults) can receive an additional one-time credibility bonus (the credibility score after the bonus will not exceed 100). Negative penalties mean that if a contributor is found to have maliciously falsified data or has systemic contradictions with other credible data (long-term, persistent inconsistencies), their credibility score can be significantly reduced or even reset to zero.

[0142] In some embodiments, the incentive amount is positively correlated with both the contributor's credibility score and risk score. The edge server can determine the incentive amount based on the contributor's credibility score and risk score using a preset formula. For example, the preset formula is shown in formula (4) below: (4) In the formula, Indicates the first The amount of incentive received by each contributor. Indicates the risk coefficient. Indicates a fixed reward. This indicates the contributor's credibility rating.

[0143] A risk coefficient is a parameter used to quantitatively map a risk score to the calculation of an incentive amount. In some embodiments, the risk coefficient is calculated from the risk score using a preset mapping rule. Preset mapping rules include piecewise linear mapping, linear mapping, exponential mapping, etc. Taking piecewise linear mapping as an example, the risk score is divided into multiple intervals, each interval corresponding to a fixed risk coefficient. For example, the risk score is divided into four intervals: 0-50, 51-70, 71-90, and 91-100, corresponding to risk coefficients of 1.0, 1.2, 1.5, and 2.0, respectively.

[0144] A fixed reward refers to the basic incentive value of a single evidence-gathering event under standard risk conditions (such as a risk score of 0 or the lowest risk level). Fixed rewards can be set based on actual needs.

[0145] As an example only, if there are three sensors D, E, and F with corresponding credibility scores of 95, 75, and 60 respectively, and assuming a fixed reward of 100 contribution vouchers and a risk coefficient of 1.5, then the incentive amounts obtained by sensors D, E, and F can be calculated to be 142.5 contribution vouchers, 112.5 contribution vouchers, and 90 contribution vouchers respectively.

[0146] The preset blockchain address refers to the fixed target address that will automatically receive contribution certificates in the subsequent incentive mechanism.

[0147] In some embodiments, one or more preset blockchain addresses are associated with one or more contributors to the construction process data to be verified. That is, the preset blockchain address is a unique blockchain account address that the contributor pre-specifies and binds to their digital identity during the system initialization or device registration phase.

[0148] In some embodiments, the edge server distributes the calculated incentive amount to blockchain addresses pre-bound to each contributor.

[0149] In some embodiments of this specification, by introducing two core dimensions—credibility scoring and risk scoring—a refined measurement of the value of contributors' data contributions is achieved. The entire measurement and distribution process is automated, eliminating human intervention. This mechanism constructs a positive reinforcement loop: at the individual level, credibility scoring is linked to rewards, incentivizing contributors to continuously improve the quality of their reported data; at the system level, high-risk scenarios are given high incentive weights, guiding resources to focus on key aspects and achieving a virtuous cycle of "high risk - high attention - high incentive - higher security." Simultaneously, all incentive rules, calculation bases, and distribution records are publicly available and tamper-proof on the blockchain, establishing a transparent and trustworthy reward mechanism that greatly enhances the sense of fairness and enthusiasm of all parties involved. By quantifying data contributions into credibility scores and linking them to contribution credentials for incentives, a decentralized secure data market ecosystem is fostered, attracting more high-quality data sources to actively connect, forming a blockchain-based, sustainably evolving construction safety data service ecosystem.

[0150] Figure 5 This is an exemplary flowchart of a method for verifying construction process evidence according to some embodiments of this specification. In some embodiments, process 500 is used to verify construction process evidence stored by a storage method, and process 500 can be executed by a verification server. More information on methods for storing construction process evidence can be found in [link to relevant documentation]. Figures 3-4 The corresponding description. For example... Figure 5 As shown, process 500 includes the following steps.

[0151] Step 510: Accept the verification request.

[0152] A verification request is a digital instruction initiated by a verification party to verify the historical compliance of a specific construction task. More information about verification parties can be found at [link to relevant documentation]. Figure 3 And its corresponding description.

[0153] In some embodiments, the verification request includes a rule identifier for the construction task to be verified. More information about rule identifiers can be found at [link to relevant documentation]. Figure 3 And its corresponding description.

[0154] The construction task to be verified is the construction task referred to in the verification request.

[0155] In some embodiments, the verification server determines the verification request based on the rule identifier to be verified, such as RULE_TEMP_001, input by the verifier.

[0156] Step 520: Based on the rule identifier, obtain the corresponding content identifier and digital signature from the blockchain network.

[0157] In some embodiments, the verification server initiates a query to the blockchain network based on the rule identifier. The blockchain returns the latest (or specified batch) evidence record associated with the rule identifier. This evidence record includes a content identifier and a digital signature, etc. For example, the obtained content identifier is QmTiyV9RfqR..., and the digital signature is Sig_Node_A, etc. More information about blockchain networks, content identifiers, and digital signatures can be found in [link to relevant documentation]. Figure 3 And its corresponding description.

[0158] Step 530: Based on the content identifier and digital signature, obtain the process evidence package corresponding to the content identifier and digital signature from the off-chain storage device.

[0159] For more information on off-chain storage devices and process evidence packages, please refer to [link / reference]. Figure 3 And its corresponding description.

[0160] In some embodiments, the verification server uses the content identifier obtained in the previous step as an address to directly request the complete process evidence package from IPFS, etc.; at the same time, it also obtains the corresponding digital signature from the on-chain record.

[0161] Step 540: Verify the validity of the digital signature on the process evidence packet based on the public key corresponding to the edge server.

[0162] The public key of an edge server is a public cryptographic parameter generated in pairs with the private key of the edge server and used to verify digital signatures.

[0163] In some embodiments, the verification server may obtain the edge server's public key from a pre-set or public source, and use the public key to perform cryptographic verification on the process evidence package and digital signature to confirm the authenticity and integrity of the process evidence package, i.e., the validity of the digital signature.

[0164] Step 550: In response to the validity verification passing, verify the construction process evidence based on the process evidence package.

[0165] In some embodiments, after successful verification, the verification server confirms that the process evidence package is authentic and complete. Based on the process evidence package, the verification server can verify the construction process evidence in various ways. For example, the verification server can perform verification based on preset verification logic. Preset verification logic includes complete hash comparisons or verification of zero-knowledge proofs, etc. More information on zero-knowledge proofs can be found in [link to relevant documentation]. Figure 3 And its corresponding description.

[0166] In some embodiments, upon successful validity verification, the verification server acquires permissions from the verification request initiator; upon obtaining first-level permissions, verification is performed based on zero-knowledge proofs in the process evidence package; upon obtaining second-level permissions, verification is performed based on the process identifiers and process hash values ​​of one or more construction process data to be verified in the process evidence package. More information on process identifiers and process hash values ​​can be found in [link to relevant documentation]. Figure 3 And its corresponding description.

[0167] The verification request initiator is the user terminal corresponding to the aforementioned verification party.

[0168] The permissions of the verification request initiator refer to the predefined, identity-bound verification capability levels for different verification parties. The permissions of the verification request initiator determine the evidence verification technology path that verification party can adopt, directly corresponding to its legal authorization and data access scope.

[0169] In some embodiments, after verifying the digital signature of the process evidence package, the verification server can check the source authority of the verification request. Taking "Verification of Compliance of High-Altitude Workers Holding Certificates" as an example, the corresponding rule's verification condition is "the workers must hold a valid special operation certificate." When the verification request initiator is identified as "owner's representative," its authority level is configured as Level 1, meaning the owner has the right to confirm overall compliance but not the right to obtain the identity information of specific construction workers. When the verification request initiator is "company safety system," its authority level is Level 2, meaning the company safety system has the right to comprehensively manage, verify, and hold accountable personnel qualifications.

[0170] Level 1 refers to a low level of verification access. The core characteristic of Level 1 is that the user is not authorized to know or access specific original construction process data. As a verifier with Level 1 access, the verification objective is to confirm the veracity of compliance assertions.

[0171] In some embodiments, the verification server determines the access level to be Level 1, extracts the zero-knowledge proof and public input from the process evidence package; obtains the corresponding verification key from the public keystore according to the rule identifier; and runs the verification algorithm with the verification key, public input, and zero-knowledge proof as input to obtain the verification result. The verification algorithm refers to a mathematical process that takes the verification key, public input, and zero-knowledge proof as input, performs a series of defined cryptographic operations, and outputs "accept" or "reject" (i.e., whether the proof is valid).

[0172] As an example only, the owner's representative has Level 1 authority and performs verification based on zero-knowledge proof. The verification result is: "Verified by zero-knowledge proof, the compliance assertion of rule [High-altitude work permit] in [Task X] is valid, and the evidence is credible." The owner's representative is confident that safety regulations are being followed, but their entire verification process involves "zero contact" with any worker's personal privacy information.

[0173] Level 2 refers to a higher level of verification authority. The core characteristic of Level 2 is that it is explicitly authorized to obtain and verify the specific original data (i.e., construction process data) used to generate evidence. Verification parties with Level 2 authority aim to conduct in-depth audits and reviews of data integrity and business decisions.

[0174] In some embodiments, the verification server determines the permission level to be second, extracts the process identifier and process hash value of one or more construction process data to be verified from the process evidence package, obtains the construction process data according to the process identifier, calculates the hash value according to the construction process data using a hash algorithm, compares the calculated hash value with the process hash value (i.e., verification), and if the hash value matches the process hash value, it proves that the data has not been tampered with and the verification is successful.

[0175] As an example, the company's security system has a second-level access level. It can extract the process identifier and process hash value from the process evidence package. Using the process identifier, it requests the original record (such as "Name: Zhang San; Certificate Number: TS123456; Valid until: 2025-12-31") from the company's internal human resources or qualification management system. It calculates the hash value based on the original record and compares it with the process hash value. If they match, it proves that the data has not been tampered with. It then reviews the original data that has passed the integrity verification, verifies whether "Zhang San's" certificate is valid, and confirms whether the certificate category includes high-altitude operations.

[0176] In some embodiments of this specification, different permission levels are set for the verifiers. For example, a verification paradigm of "trust without seeing" is provided for external stakeholders at the first level through zero-knowledge proofs, allowing different verifiers to perform verification in different ways, perfectly balancing privacy protection and compliance proof. At the same time, an audit channel with direct access to the original data is provided for internal stakeholders at the second level, ensuring the depth and validity of internal management and providing a solid data foundation for dynamic management of personnel qualifications, targeted security training, and potential liability tracing. The same process evidence package has the dual utility of internal and external verification, enabling enterprises to meet both internal and external requirements with a single process, maximizing the utility of evidence and minimizing compliance risks, and building a collaborative relationship based on cryptographic trust.

[0177] In some embodiments of this specification, all data required for verification (such as rule identifiers, content identifiers, etc.) is publicly available. The verification logic can be implemented by the verification server. Construction parties, supervisors, owners, or regulatory departments can all conduct independent verification. The verification results do not depend on the backend of the original edge server, breaking the trust bottleneck of "self-verification" and establishing genuine credibility. The solution forms a standard verification paradigm of "on-chain indexing - off-chain evidence storage," clearly defining how to collaboratively verify the content identifiers of the blockchain network and the process evidence package of the off-chain storage device, verifying the complete and trustworthy chain from data generation, signing to storage, and establishing a standardized process for the trustworthy auditing of massive amounts of construction data. At the same time, the verification process has non-repudiation and auditability: the starting point of verification is the immutable record on the blockchain network, the verification object is the process evidence package with digital signature, and each step of operation (query, acquisition, verification) can be recorded and reviewed, making the verification activity itself a traceable and responsible behavior.

[0178] It should be noted that the above descriptions of processes 300 and 500 are for illustrative purposes only and do not limit the scope of this specification. Those skilled in the art can make various modifications and changes to processes 300 and 500 under the guidance of this specification. However, these modifications and changes remain within the scope of this specification.

[0179] This specification provides a system for verifying construction process evidence, comprising: an accepting module configured to accept verification requests, the verification requests including a rule identifier for a construction task to be verified; a first obtaining module configured to obtain a corresponding content identifier and digital signature from a blockchain network based on the rule identifier; a second obtaining module configured to obtain a process evidence package corresponding to the content identifier and digital signature from an off-chain storage device based on the content identifier and digital signature; a verification module configured to verify the validity of the digital signature on the process evidence package based on a public key corresponding to an edge server; and a verification module configured to verify the construction process evidence based on the process evidence package in response to successful validity verification.

[0180] In some embodiments, one or more of the accepting module, the first obtaining module, the second obtaining module, the verification module, and the authentication module may be integrated into the authentication server. For more information on authentication servers, please refer to [link to relevant documentation]. Figure 1 Related descriptions.

[0181] For more information about the verification system mentioned above, please refer to [link / reference]. Figure 5 Related descriptions.

[0182] This specification provides a storage device for construction process evidence, the device including at least one processor and at least one memory; the at least one memory is used to store computer instructions; the at least one processor is used to execute at least a portion of the computer instructions to implement the storage method as described above.

[0183] This specification provides an embodiment of a device for verifying evidence of a construction process. The device includes at least one processor and at least one memory. The at least one memory is used to store computer instructions. The at least one processor is used to execute at least a portion of the computer instructions to implement the verification method as described above.

[0184] This specification provides a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions from the storage medium, the computer executes the storage method or verification method described above.

[0185] The embodiments in this specification are merely illustrative and not intended to limit the scope of this specification. Various modifications and alterations that can be made by those skilled in the art under the guidance of this specification remain within its scope.

[0186] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0187] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "some embodiments" refers to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Additionally, certain features, structures, or characteristics in one or more embodiments of this specification may be appropriately combined.

Claims

1. A method for storing evidence of the construction process, characterized in that, The storage method is executed via an edge server and includes: Obtain the rules configured for the construction task and the rule identifiers corresponding to the rules. The rules reflect one or more construction process data to be verified and the verification conditions corresponding to the one or more construction process data to be verified. When the construction task is executed, the one or more construction process data to be verified are verified based on the verification conditions, and verification results are generated. When the verification result is successful, a process evidence package is generated, and the process evidence package is digitally signed using the private key of the edge server. The process evidence package includes the rule identifier, the verification result, the process identifier and process hash value of one or more construction process data to be verified. The digitally signed process evidence package is stored in an off-chain storage device, and the content identifier of the process evidence package corresponding to the digital signature is returned by the off-chain storage device. The content identifier, the digital signature, and the rule identifier are sent to the blockchain network for storage.

2. The storage method according to claim 1, characterized in that, Also includes: When the construction task is executed, a risk score is obtained in real time based on one or more construction process data to be verified by a risk prediction model. The risk prediction model is a machine learning model. The process evidence package generated in response to the verification result being a successful verification includes: In response to the verification result being that the verification passed, a process evidence package containing the risk score is generated.

3. The storage method according to claim 2, characterized in that, Also includes: In response to the risk score exceeding a preset threshold, a corresponding risk control strategy is adopted, wherein the risk control strategy includes adjusting the data sampling frequency of the sensor and / or issuing a risk warning; The process evidence package generated in response to the verification result being a successful verification includes: In response to the verification result being that the verification passed, a process evidence package containing the risk score and the risk control strategy is generated.

4. The storage method according to claim 2, characterized in that, The updating process of the risk prediction model includes: Based on the historical construction data stored locally on the edge server, the risk prediction model is trained locally to obtain the first weight parameters of the risk prediction model. The first weight parameter is encrypted, and the encrypted first weight parameter is uploaded to the federated learning aggregation server; Receive the second weight parameter, which is globally aggregated and updated, issued by the federated learning aggregation server, and update the risk prediction model based on the second weight parameter.

5. The storage method according to claim 2, characterized in that, Also includes: In response to successful notarization on the blockchain network, an incentive amount is determined based on a preset incentive strategy, and contribution certificates are distributed to one or more preset blockchain addresses; the one or more preset blockchain addresses are respectively associated with the contributors of one or more construction process data to be verified. The incentive amount is positively correlated with both the contributor's credibility score and risk score.

6. The storage method according to claim 1, characterized in that, Also includes: Generate a collaboration request containing the rule identifier and send it to the relevant user terminal; Receive and verify digital signatures from the relevant user terminals, and determine a set of digital signatures based on the verified digital signatures; The process evidence package generated in response to the verification result being a successful verification further includes: In response to the verification result being that the verification passed, a process evidence package containing the digital signature set is generated.

7. The storage method according to claim 1, characterized in that, Also includes: Based on one or more construction process data to be verified and the verification conditions, a corresponding zero-knowledge proof is generated. The zero-knowledge proof represents that the one or more construction process data to be verified satisfy the verification conditions without disclosing the one or more construction process data to be verified. The process evidence package generated in response to the verification result being a successful verification further includes: In response to the verification result being that the verification passed, a process evidence package containing the zero-knowledge proof is generated.

8. A method for verifying evidence of the construction process, characterized in that, The verification method is used to verify the construction process evidence stored by the storage method according to claim 1, including: Accept the verification request, which includes the rule identifier of the construction task to be verified; Based on the rule identifier, obtain the corresponding content identifier and digital signature from the blockchain network; Based on the content identifier and the digital signature, obtain the process evidence package corresponding to the content identifier and the digital signature from the off-chain storage device; The validity of the digital signature on the process evidence package is verified based on the public key corresponding to the edge server. Upon successful verification of the validity, the construction process evidence is verified based on the process evidence package.

9. The verification method according to claim 8, characterized in that, When the validity verification passes, the verification of construction process evidence based on the process evidence package includes: Upon successful verification of the validity, the permissions of the verification request initiator are obtained. In response to the permission being at the first level, verification is performed based on the zero-knowledge proof in the process evidence package; In response to the permission being at the second level, verification is performed based on the process identifier and process hash value of one or more construction process data to be verified in the process evidence package.

10. A system for storing evidence of the construction process, characterized in that, include: The acquisition module is configured to acquire the rules configured for the construction task and the rule identifiers corresponding to the rules, wherein the rules reflect one or more construction process data to be verified and the verification conditions corresponding to the one or more construction process data to be verified. The verification module is configured to verify one or more construction process data to be verified based on the verification conditions when the construction task is executed, and generate verification results. The generation module is configured to generate a process evidence package in response to the verification result being a successful verification, and to digitally sign the process evidence package using the private key of the edge server. The process evidence package includes the rule identifier, the verification result, the process identifier and process hash value of one or more construction process data to be verified. The storage module is configured to store the digitally signed process evidence package to an off-chain storage device and obtain a content identifier of the process evidence package corresponding to the digital signature returned by the off-chain storage device. The evidence storage module is configured to send the content identifier, the digital signature, and the rule identifier to the blockchain network for evidence storage.

11. A verification system for construction process evidence, characterized in that, include: The receiving module is configured to accept verification requests, the verification requests including rule identifiers for construction tasks to be verified; The first acquisition module is configured to acquire the corresponding content identifier and digital signature from the blockchain network based on the rule identifier; The second acquisition module is configured to acquire the process evidence package corresponding to the content identifier and the digital signature from the off-chain storage device based on the content identifier and the digital signature; The verification module is configured to verify the validity of the digital signature on the process evidence package based on the public key corresponding to the edge server. The verification module is configured to verify the construction process evidence based on the process evidence package in response to the successful verification of the validity.

12. A storage device for evidence of the construction process, characterized in that, The device includes at least one processor and at least one memory; The at least one memory is used to store computer instructions; The at least one processor is configured to execute at least a portion of the computer instructions to implement the storage method as described in any one of claims 1-7.

13. A device for verifying evidence of construction process, characterized in that, The device includes at least one processor and at least one memory; The at least one memory is used to store computer instructions; The at least one processor is configured to execute at least a portion of the computer instructions to implement the verification method as described in any one of claims 8-9.

14. A computer-readable storage medium, characterized in that, The storage medium stores computer instructions. When the computer reads the computer instructions in the storage medium, the computer executes the storage method as described in any one of claims 1-7 or the verification method as described in any one of claims 8-9.

Images