A chain response management method and system for construction fault handling information

Abstract

The application provides a chain response management method and system for construction fault processing information, and relates to the technical fields of blockchains and construction management. The method comprises the following steps: obtaining a fault trigger message; querying a post routing configuration table based on a fault type code to generate a chain response record; deploying an intelligent contract instance of a maintenance state machine, a current pointer and a permission mapping table; listening to a signed transaction, verifying consistency, atomically updating the state machine, moving the pointer and configuring temporary write permissions; receiving a processing result, mapping and notarizing two hash values, and updating the write permission to submitted; when the pointer points to a terminal node and the closed loop signature verification is passed, comparing the two hash values, if they are consistent, releasing the contract resources and generating a closed loop notarization transaction, if they are inconsistent, rolling back the pointer and generating an abnormal trace record. The technical problems of opaque construction fault processing flow, difficult responsibility traceability and chaotic permission management are solved, and the technical effects of process automation, data credibility and accurate controllable permission are achieved.

Description

Technical Field

[0001] This application relates to the fields of blockchain and construction management technology, and in particular to a chain-response management method and system for construction fault handling information. Background Technology

[0002] During the construction of large-scale buildings, unexpected problems such as equipment failures, safety hazards, and quality defects occur frequently. Timely and efficient handling of these problems is crucial to ensuring construction safety, progress, and quality. Existing methods for handling construction problems mainly rely on manual repair requests, telephone notifications, WeChat group chats, or traditional work order management systems.

[0003] However, the above method has the following technical drawbacks.

[0004] First, fault information is usually stored in unstructured voice, image, or text formats across different communication tools, lacking a unified data processing node. When a fault involves collaborative processing by multiple job roles, information transmission is prone to interruption, preventing responders from obtaining complete fault information in a timely manner. The processing flow often stalls due to information asynchrony, resulting in delayed responses.

[0005] Secondly, traditional work order systems only record a simple "dispatch-acceptance-completion" status, lacking granular records of each step in the process. When disputes arise, they cannot provide a reliable and tamper-proof complete chain of evidence, making it difficult to trace the entire fault handling process, resulting in untraceable processes and unclear responsibilities.

[0006] Secondly, existing systems typically employ static role-based access control, meaning that processing permissions are preset based on job roles. This static allocation method cannot dynamically adjust permissions according to the actual progress of fault handling. Permissions may remain after the preceding node has completed its processing, posing a security risk of data tampering. Subsequent nodes may acquire data access permissions before reaching their processing stage, leading to process out of control and chaotic access control.

[0007] In addition, fault handling involves asynchronous collaboration among multiple tasks. Traditional systems cannot dynamically generate the optimal processing path based on factors such as fault type, fault location, node qualifications, and historical processing efficiency. They often rely on manual assignment or fixed processes, resulting in wasted manpower or processing delays and low resource scheduling efficiency.

[0008] In summary, existing technologies lack a technical solution capable of automating construction fault handling processes, ensuring data reliability, dynamically managing permissions, and optimizing resource scheduling. How to achieve mandatory sequential control, automatic permission revocation, reliable data storage, and efficient resource scheduling throughout the entire fault handling process through technical means is a pressing technical problem that needs to be solved in this field. Summary of the Invention

[0009] The purpose of this application is to provide a chain-response management method and system for construction fault handling information. This aims to solve the technical problems in existing technologies, such as opaque construction fault handling processes, difficulty in tracing responsibility, chaotic access control, and low resource scheduling efficiency.

[0010] In view of the above technical problems, this application provides a chain response management method and system for construction fault handling information.

[0011] A first aspect of this application provides a chain response management method for construction fault handling information, the method comprising: Obtain fault trigger messages during the construction process, wherein the fault trigger messages include at least a fault type code and a hash value of the original fault data; Based on the fault type code, a preset construction fault type-job routing configuration table is queried to generate a chain response record. The chain response record is a sequence of node identifiers arranged according to the construction processing logic sequence, and each node identifier is associated with a blockchain account address. Using the fault trigger message and the chain response record as construction parameters, a smart contract instance for the current fault event is deployed on the blockchain. The smart contract instance maintains a state machine and initializes the current pointer to point to the first node identifier in the chain response record. The smart contract instance also maintains a permission mapping table to record the write permission status of the blockchain account address associated with each node identifier for fault handling data. The smart contract instance listens to signed transactions in the blockchain. When the issuing account address of the listened signed transaction matches the blockchain account address associated with the node identifier pointed to by the current pointer, and the signature data carried by the signed transaction is decrypted and verified to match the hash value of the original fault data, the smart contract instance atomically updates the current state of the state machine to the preset next state within a transaction execution cycle, updates the current pointer to point to the next node identifier in the chain response record, and updates the permission mapping table to configure the temporary write permission of the node pointed to by the current pointer. The temporary write permission corresponds to the period during which the current pointer stays at the node identifier. The smart contract instance receives the processing result data and its hash value returned by the node holding temporary write permission, and establishes a mapping relationship between the hash value of the processing result and the hash value of the original fault data on the blockchain and stores it. At the same time, it updates the write permission status of the node in the permission mapping table to "committed". When the current pointer points to the terminal node identifier in the chain response record, and the closed-loop signature submitted through the blockchain account address associated with the terminal node identifier is verified, the smart contract instance extracts the hash value encapsulated in the closed-loop signature and compares it with the hash value of the processing result that establishes a mapping relationship on the blockchain: If the comparison matches, the termination function of the smart contract instance is called to release the computing and storage resources occupied by the smart contract instance from the node memory of the blockchain network, and a closed-loop evidence-based transaction is generated and written to the blockchain. If the comparison is inconsistent, the smart contract instance remains active, the current pointer is rolled back to the previous node identifier, and an anomaly trace record is generated and written to the blockchain.

[0012] A second aspect of this application provides a chain response management system for construction fault handling information, the system comprising: The message acquisition module is used to acquire fault trigger messages during the construction process. The fault trigger message includes at least a fault type code and a hash value of the original fault data. A chain response record generation module is used to query a preset construction fault type-job routing configuration table based on the fault type code and generate chain response records. The chain response record is a sequence of node identifiers arranged according to the construction processing logic sequence, and each node identifier is associated with a blockchain account address. The contract deployment module is used to deploy a smart contract instance for the current fault event on the blockchain using the fault trigger message and the chain response record as construction parameters. The smart contract instance maintains a state machine and initializes the current pointer to point to the first node identifier in the chain response record. The smart contract instance also maintains a permission mapping table to record the write permission status of the blockchain account address associated with each node identifier for fault handling data. The transaction monitoring and execution module is used to monitor signed transactions in the blockchain. When the issuing account address of the monitored signed transaction is consistent with the blockchain account address associated with the node identifier pointed to by the current pointer, and the signature data carried by the signed transaction is decrypted and verified to match the hash value of the faulty original data, the smart contract instance atomically updates the current state of the state machine to the preset next state within a transaction execution cycle, updates the current pointer to point to the next node identifier in the chain response record, and updates the permission mapping table to configure the temporary write permission of the node pointed to by the current pointer, wherein the temporary write permission corresponds to the period during which the current pointer stays at the node identifier; The result processing module is used by the smart contract instance to receive the processing result data and its hash value returned by the node holding temporary write permission, and to establish a mapping relationship between the hash value of the processing result and the hash value of the original fault data on the blockchain and store it, while updating the write permission status of the node in the permission mapping table to "committed". The closed-loop verification and processing module is used to compare the hash value encapsulated in the closed-loop signature with the hash value of the processing result that establishes a mapping relationship on the blockchain when the current pointer points to the terminal node identifier in the chain response record and the closed-loop signature submitted through the blockchain account address associated with the terminal node identifier is verified. If the comparison matches, the termination function of the smart contract instance is called to release the computing and storage resources occupied by the smart contract instance from the node memory of the blockchain network, and a closed-loop evidence-based transaction is generated and written to the blockchain. If the comparison is inconsistent, the smart contract instance remains active, the current pointer is rolled back to the previous node identifier, and an anomaly trace record is generated and written to the blockchain.

[0013] One or more technical solutions provided in this application have at least the following technical effects or advantages: By dynamically generating chain response records based on fault type coding and combining smart contract instances to maintain state machines, current pointers, and permission mapping tables, mandatory sequential control of the construction fault handling process is achieved, avoiding chaos caused by process skipping or human intervention; by atomically executing state updates, pointer movements, and permission mapping table updates, and configuring temporary write permissions bound to the pointer's dwell time, the original node permissions are automatically revoked and cannot be recovered when the pointer moves, realizing dynamic transfer and automatic reclamation of permissions, effectively eliminating the security risks of permission residue; By establishing a key-value mapping between the hash value of the processing result and the hash value of the original fault data and storing them on the blockchain, combined with the "committed" status prohibiting duplicate submissions by the same node, and the hash comparison and anomaly rollback mechanism during closed-loop signature verification, a complete, tamper-proof, and traceable chain of evidence is formed. Through dynamically adjusting the node sequence based on historical fault processing data, comprehensively determining execution priority by combining fault location coordinates and node qualification levels, and automatically switching to backup nodes based on error counts when discrepancies occur, adaptive optimization and real-time fault tolerance of the processing chain are achieved, effectively improving the efficiency, reliability, and rationality of fault handling and resource scheduling. This solves the technical problems of opaque construction fault handling processes, difficulty in tracing responsibility, chaotic access management, and low resource scheduling efficiency in existing technologies.

[0014] The above description is merely an overview of the technical solution of this application. In order to more clearly explain the technical means of this application, and to enable its implementation in accordance with the contents of the specification, and to make the above and other objectives, features and advantages of this application more apparent and understandable, specific embodiments of this application are described below. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments of this disclosure will be briefly described below. Flowcharts are used in this application to illustrate the operations performed by the system according to the embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from these processes.

[0016] Figure 1 A flowchart illustrating a chain response management method for construction fault handling information provided in an embodiment of this application; Figure 2 This is a schematic diagram of a chain response management system for construction fault handling information provided in an embodiment of this application.

[0017] Figure labeling: Message acquisition module 10, chain response record generation module 20, contract deployment module 30, transaction monitoring and execution module 40, result processing module 50, closed-loop verification and processing module 60. Detailed Implementation

[0018] This application provides a chain-response management method and system for construction fault handling information, which solves the technical problems in the prior art such as opaque construction fault handling process, difficulty in tracing responsibility, chaotic access control, and low resource scheduling efficiency.

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0020] It should be noted that the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or modules that are not explicitly listed or that are inherent to such processes, methods, products, or devices.

[0021] Example 1, as Figure 1 As shown, this application provides a chain response management method for construction fault handling information, wherein the method includes: Obtain fault trigger messages during the construction process, wherein the fault trigger messages include at least a fault type code and a hash value of the original fault data; Specifically, in construction scenarios, when sensors on construction equipment (such as tower cranes and elevators) detect operational anomalies (e.g., abnormal current, voltage, temperature, or vibration), the IoT terminal automatically generates a fault trigger message. This message includes a fault type code, such as "E001" representing a circuit fault, and a hash value of the original fault data. This hash value is obtained by hashing the original data, including the fault occurrence time, equipment number, abnormal parameter values, and on-site images (including photos, videos, and thermal images). The hash operation can use SHA-256 or SM3 algorithms to ensure the integrity verification of the original data in subsequent processing. For example, when a safety officer discovers loose scaffolding connections on-site, they can report the fault information via a mobile application. The mobile terminal automatically uses the reported time, location coordinates, hazard description, and on-site photos as the original fault data, calculates its hash value, and encapsulates it together with a preset fault type code into a fault trigger message. This fault trigger message is sent to the management node in the blockchain network as input data for the entire chain-response management process. It should be understood that the specific devices, fault types, hash algorithms, and data content in the above embodiments are merely examples for ease of understanding and do not constitute a limitation on the scope of protection of this application.

[0022] Based on the fault type code, a preset construction fault type-job routing configuration table is queried to generate a chain response record. The chain response record is a sequence of node identifiers arranged according to the construction processing logic sequence, and each node identifier is associated with a blockchain account address. Furthermore, the step of querying the preset construction fault type-job routing configuration table based on the fault type code to generate chained response records includes: The fault type code is used to query the pre-stored fault type-node sequence mapping relationship to determine the node sequence corresponding to the fault type code. The node sequence is the chained response record. The job routing configuration table is dynamically updated based on historical fault handling data. When the hash value of the processing result corresponding to the same fault type code is inconsistent after multiple verifications within a preset time period, the node identifier order in the node sequence corresponding to the fault type code is automatically adjusted or the node identifier is replaced. The adjustment is used for subsequent new fault events of the same type.

[0023] Furthermore, the generation of chained response records also includes: The fault trigger message also carries the fault location coordinates. Based on the fault location coordinates, candidate nodes whose distance from the fault location coordinates is within a preset threshold range are selected from the preset processing node resource pool associated with the construction fault type-job routing configuration table. Based on the distance between the candidate node and the fault location, the hash verification pass rate of historical processing results, and the node's qualification level for handling fault types, the processing priority of each candidate node is comprehensively determined, and the identifier of the node with the highest priority is used as the execution node in the chain response record. The hash verification pass rate of the historical processing results is obtained based on the dynamic update of the historical fault processing data.

[0024] Specifically, a construction fault type-position routing configuration table is pre-configured in the construction management platform. This table is stored in key-value pair format, where the key is the fault type code, and the value is a sequence of multiple node identifiers arranged according to the processing logic sequence. Each node identifier is associated with a blockchain account address. For example, when the fault type code is "E001" (indicating a circuit fault), the routing configuration table returns the following node sequence: the blockchain account address of the supervising engineer corresponding to the review node, the blockchain account address of the electrician team corresponding to the execution node, and the blockchain account address of the safety and quality officer corresponding to the acceptance node. When the fault type code is "S002" (indicating a structural hazard), the following node sequence is returned: the blockchain account address of the chief supervising engineer corresponding to the review node, the blockchain account address of the structural engineer corresponding to the execution node, and the blockchain account address of the project manager corresponding to the acceptance node. When deployed, the smart contract queries this routing configuration table based on the fault type code in the fault trigger message to obtain the corresponding node sequence, which is the chained response record. This routing configuration table is not static. The smart contract maintains a historical fault handling data storage, recording the results (consistency or inconsistency) of closed-loop signature verification during each fault handling process. The initial pass rate for historical processing result hash verification of each node is set to 100%, using the default value before the first processing. After each fault handling is completed, the smart contract updates the historical processing result hash verification pass rate of that node based on the closed-loop signature verification result: if the verification matches, the updated pass rate = (pass rate before update × historical count + 1) / (historical count + 1); if the verification does not match, the updated pass rate = (pass rate before update × historical count) / (historical count + 1). Here, the historical count is the number of similar faults processed (initially 0), and the initial pass rate before update is set to 100%. When the hash value of the processing result corresponding to the same fault type code is inconsistent with the hash value encapsulated in the closed-loop signature during the closed-loop signature verification at the terminal node, and the cumulative number of inconsistencies exceeds the preset threshold (e.g., 3 times, which is dynamically adjusted by the system based on the historical fault frequency) within a preset time period (e.g., the most recent 30 days), the smart contract first calculates the pass rate of the historical processing result hash verification of the same fault type for each node from the historical fault processing data (i.e., the proportion of closed-loop signature verification that is consistent when the node processes this type of fault).Then, from the resource pool of processing nodes associated with the construction fault type-job routing configuration table, nodes matching the fault type and with a historical processing result hash verification pass rate higher than the current node are selected. The original execution node is replaced by the selected node, and the original execution node is demoted to a backup node. If there is no node with a higher success rate, the order of the execution node in the original node sequence is shifted one position to the right according to a preset order adjustment strategy. The original execution node's position in the sequence is shifted to the right, and the adjusted sequence is used first in subsequent fault handling. For example, if the electrician team in the original sequence fails verification multiple times in a row, the system will automatically replace it with a backup electrician team and store the adjusted sequence in the routing configuration table for subsequent new fault events of the same fault type. The dynamic update of the routing configuration table is a long-term optimization at the configuration table level. The adjusted node sequence is stored in the routing configuration table and only takes effect for subsequent new fault events of the same type. Deployed smart contract instances still use the original chain response record determined at the time of deployment to ensure that the ongoing fault handling process is not affected by configuration changes. In addition, the fault trigger message also carries the fault location coordinates (e.g., latitude and longitude obtained through GPS positioning). Based on these coordinates, the smart contract filters candidate nodes from a pre-defined resource pool of processing nodes associated with the routing configuration table. These candidate nodes are within a pre-defined threshold (e.g., 500 meters, which can be configured by the administrator based on the construction site area). The resource pool pre-stores information on all construction personnel, their positions, qualification levels, and historical processing success rates. The system uses three dimensions—distance, historical processing result hash verification pass rate, and the node's qualification level for handling fault types (e.g., electrician A holds a high-voltage electrician's certificate, with a qualification level of A for circuit faults; electrician B only has a low-voltage certificate, with a qualification level of C)—to calculate the priority of each candidate node through a weighted scoring. The specific formula is as follows: Priority = α × (1 - Distance / Maximum Distance) + β × Pass Rate + γ × Qualification Level Coefficient. In this context, α, β, and γ are preset weights, satisfying α + β + γ = 1. These weights correspond to the influence of distance, historical pass rate, and qualification level in priority calculation, respectively. The initial configuration of the weight values ​​can be set by the administrator according to the characteristics of the construction project. For example, the distance weight α can be increased when the construction period is tight, and the pass rate weight β can be increased when the quality requirements are high. The weight values ​​can also be dynamically adjusted based on historical data using a preset algorithm. The maximum distance is a preset threshold (e.g., 500 meters), which is the straight-line distance between the candidate node and the fault location. The pass rate is the hash verification pass rate of the node's handling result for the fault type. The qualification level coefficient is a pre-set value based on the node's qualification (e.g., A-level = 1, B-level = 0.8, C-level = 0.5). The node identifier with the highest priority is selected as the execution node for this fault.For example, if there is an electrician with a high-voltage electrician's license and a historical pass rate of 98% located 300 meters from the fault point, while there is an electrician with a low-voltage license and a pass rate of only 80% located 500 meters away, the system will prioritize the former. When a node needs to be switched due to node timeout or processing failure during the same fault handling process, the system will automatically activate the next candidate node according to the above priority order. It should be understood that the fault type coding, job configuration, distance threshold, priority weight, and dynamic update strategy in the above embodiments are only examples. In actual applications, they can be adjusted according to specific circumstances such as the scale of the construction project, personnel qualifications, and geographical location, and do not constitute a limitation on the scope of protection of this application.

[0025] Using the fault trigger message and the chain response record as construction parameters, a smart contract instance for the current fault event is deployed on the blockchain. The smart contract instance maintains a state machine and initializes the current pointer to point to the first node identifier in the chain response record. The smart contract instance also maintains a permission mapping table to record the write permission status of the blockchain account address associated with each node identifier for fault handling data. Furthermore, the step of deploying a smart contract instance for the current fault event on the blockchain using the fault trigger message and the chained response record as construction parameters includes: An independent smart contract instance is created for each fault event. The independent smart contract instance is constructed using the fault trigger message and the chain response record as construction parameters. The state machine, current pointer and permission mapping table maintained inside the independent smart contract instance are isolated from the smart contract instances corresponding to other fault events. The current pointer is an integer index value stored in the state variable of the smart contract instance, with an initial value of 1, pointing to the first node identifier in the chained response record arranged according to the processing logic sequence; The permission mapping table is a key-value data structure maintained in the smart contract instance, with the blockchain account address associated with the node identifier as the key and the write permission status of the fault handling data as the value. When the permission mapping table is initialized, only the write permission status of the blockchain account address associated with the first node identifier in the chain response record is set to temporary write permission, while the write permission status of the blockchain account addresses associated with the remaining node identifiers is set to no permission.

[0026] Specifically, when deploying smart contract instances for the current failure event on the blockchain, a factory contract pattern is used to create an independent smart contract instance for each failure event. This factory contract receives the failure trigger message and chained response records as construction parameters, instantiates a new smart contract using the `new` operator, and stores the failure type code, the hash value of the original failure data, and the chained response records as state variables within the instance. The state machine, current pointer, and permission mapping table maintained internally by each smart contract instance are stored in the instance's independent storage space, isolated from smart contract instances corresponding to other failure events, thus ensuring that the processing flows of different failure events do not interfere with each other. The business state machine (`stateMachine`) uses integer encoding to represent the process status: 1 indicates pending review, 2 indicates under review, 3 indicates pending execution, 4 indicates execution, 5 indicates pending acceptance, and 6 indicates completed. The initial value of the state machine is 1 (pending review). The current pointer is implemented as an integer index value stored in the smart contract instance's state variable, initially set to 1. This value directly corresponds to the position number of the first node identifier in the chained response record, arranged according to the processing logic sequence. For example, when the chained response record is [node A, node B, node C], the initial value of the current pointer is 1, indicating that node A should be processed now. The permission mapping table is implemented as a key-value pair data structure maintained in the smart contract instance, specifically using the mapping(address => uint8) type in Solidity. The key is the blockchain account address associated with the node identifier, and the value is the write permission status of that account address for fault handling data. The write permission status is represented by integer encoding: 0 indicates no permission, 1 indicates temporary write permission, and 2 indicates committed. During permission mapping table initialization, the smart contract iterates through all node identifiers in the chained response record, setting only the value of the blockchain account address associated with the first node identifier in the mapping table to 1 (i.e., temporary write permission), while setting the values ​​of the blockchain account addresses associated with the remaining node identifiers to 0 (i.e., no permission). After the iteration is complete, all nodes except the first node remain in the no-permission state. For example, when the chained response record contains the audit node account address Addr_A, the execution node account address Addr_B, and the acceptance node account address Addr_C, the value corresponding to Addr_A in the initialized permission mapping table is 1, while the values ​​corresponding to Addr_B and Addr_C are both 0. It should be understood that the above factory contract pattern, state variable storage method, mapping table data structure, and initialization loop are merely examples. In actual implementation, equivalent techniques from other programming languages ​​or contract frameworks can be used, and this does not constitute a limitation on the scope of protection of this application.

[0027] The smart contract instance listens to signed transactions in the blockchain. When the issuing account address of the listened signed transaction matches the blockchain account address associated with the node identifier pointed to by the current pointer, and the signature data carried by the signed transaction is decrypted and verified to match the hash value of the original fault data, the smart contract instance atomically updates the current state of the state machine to the preset next state within a transaction execution cycle, updates the current pointer to point to the next node identifier in the chain response record, and updates the permission mapping table to configure the temporary write permission of the node pointed to by the current pointer. The temporary write permission corresponds to the period during which the current pointer stays at the node identifier. Furthermore, the update permission mapping table includes: Update the write permission status of the blockchain account address originally associated with the node identifier in the permission mapping table from temporary write permission to no permission; Update the write permission status of the blockchain account address associated with the node identifier currently pointed to by the pointer in the permission mapping table from no permission to temporary write permission; The temporary write permission is valid from the time the current pointer points to the node identifier until the current pointer points to the next node identifier. When the current pointer leaves the node identifier, the temporary write permission automatically expires and cannot be recovered.

[0028] Specifically, smart contract instances receive and process signed transactions through their publicly exposed `submitSignature` function. When a signed transaction is sent to this function, the contract first obtains the transaction initiator's account address `tx.origin` and compares it with the blockchain account address `allowedAddress` associated with the node identifier pointed to by the current pointer `currentPointer`. If they do not match, the contract terminates execution and throws an exception. If they match, the contract extracts the signature data `signature` from the transaction payload, decrypts the signature using the blockchain's built-in elliptic curve digital signature algorithm recovery function `ecrecover`, and obtains the decrypted hash value `decryptedHash`. This decrypted hash value is then compared byte-by-byte with the hash value `originalHash` of the faulty original data stored during contract initialization. Only when the decrypted hash value exactly matches the original hash value is the signature verification successful. After successful verification, the smart contract atomically executes three operations within a transaction execution cycle: First, it updates the state machine variable `stateMachine` from its current state value to a preset next state value, for example, from state value 1 (pending review) to state value 2 (under review); Second, it increments the value of the current pointer `currentPointer` by 1, making it point to the next node identifier in the chain response record. For example, when the chain response record is [NodeA, NodeB, NodeC], initially `currentPointer=1` points to NodeA, and after execution, `currentPointer=2` points to NodeB; Specifically, the smart contract retrieves the blockchain account address corresponding to the original node identifier from the stored chain response record based on the current pointer value as `oldAddress`, and retrieves the blockchain account address corresponding to the new node identifier from the chain response record based on the incremented pointer value as `newAddress`. Third, the permission mapping table `permissionTable` is updated. The value of `oldAddress`, the blockchain account address originally pointed to by the node identifier, is changed from 1 (temporary write permission) to 0 (no permission). Similarly, the value of `newAddress`, the blockchain account address now pointed to by the current pointer, is changed from 0 (no permission) to 1 (temporary write permission). These three operations are executed sequentially within the same function call. If any operation fails, the entire transaction is automatically rolled back by the underlying blockchain virtual machine, and all state variables are restored to their pre-execution values. Through this mechanism, the validity period of the temporary write permission is strictly limited to the period during which the current pointer points to that node identifier.For example, when the current pointer value is 1 pointing to NodeA, the value of permissionTable[Addr_A] is 1, indicating that node NodeA has temporary write permission. When the signature verification passes and the atomic operation increments the pointer value to 2 pointing to NodeB, the operation simultaneously sets permissionTable[Addr_A] to 0 and permissionTable[Addr_B] to 1. The moment the pointer leaves NodeA, NodeA's write permission is immediately revoked and cannot be recovered. After the auditing node completes the signed transaction and passes verification, the current pointer moves to the execution node, the auditing node's write permission in the permission mapping table is revoked, and the execution node obtains temporary write permission. At this time, the execution node becomes the node that should be processed and is responsible for subsequent fault handling operations. It should be understood that the above state machine state values, pointer initial values, increment step size, mapping table encoding method, and permission check logic are only examples. In actual implementation, they can be adjusted according to specific business scenarios and blockchain platform characteristics, and do not constitute a limitation on the scope of protection of this application.

[0029] Furthermore, the atomicity within the execution cycle includes: When any operation fails to update the current state of the state machine to the preset next state, update the current pointer to point to the next node identifier in the chained response record, or update any operation in the permission mapping table, all executed operations are automatically rolled back, and the state machine, the current pointer, and the permission mapping table are restored to their states before atomic execution.

[0030] Specifically, in the `submitSignature` function of the smart contract instance, the aforementioned three operations—state machine state update, current pointer movement, and permission mapping table update—are sequentially written within the same function body. The Solidity compiler compiles the entire function call into an atomic transaction, guaranteed by the underlying Ethereum Virtual Machine (EVM): if any step during function execution throws an exception due to a non-metrequired condition, a proactive rollback via `revert`, or a failed `assert`, all modifications to state variables within the entire transaction will be automatically reverted, and the state will roll back to its state before the function call. For example, inside the function, `require(stateMachine != STATE_COMPLETED)` first checks whether the current state allows transition; if the state does not allow transition, a rollback is triggered. Next, `currentPointer++` is executed. If `currentPointer` exceeds the length of the chain response record, `require(currentPointer <= recordLength)` will fail, causing a rollback. Finally, when updating the permission mapping table, if the current value of `permissionTable[oldAddress]` is not 1 (temporary write permission), `require(permissionTable[oldAddress] == 1)` will fail, also triggering a rollback. If any of these three operations fails, previously executed state updates (such as changes to the state machine or incremented pointers) will be automatically restored by the EVM. The state machine, current pointer, and permission mapping table will all be restored to their values ​​before the function execution. For example, if the state machine successfully updates from 1 (pending review) to 2 (under review), but subsequent pointer movement fails due to out-of-bounds access, the state machine will revert to 1, the pointer will retain its original value, and the permission mapping table will also be restored to its original state, as if the call had never occurred. Through this mechanism, the three operations form an atomic whole; either all succeed or all fail, ensuring that the state machine, current pointer, and permission mapping table remain consistent. It should be understood that the above verification logic, conditional judgment, and rollback triggering method are merely examples. In actual implementations, corresponding require or revert statements can be designed according to specific business rules, and do not constitute a limitation on the scope of protection of this application.

[0031] The smart contract instance receives the processing result data and its hash value returned by the node holding temporary write permission, and establishes a mapping relationship between the hash value of the processing result and the hash value of the original fault data on the blockchain and stores it. At the same time, it updates the write permission status of the node in the permission mapping table to "committed". Furthermore, the step of establishing and storing a mapping relationship between the hash value of the processing result and the hash value of the original fault data on the blockchain, and simultaneously updating the write permission status of the node in the permission mapping table to "committed", includes: The smart contract instance updates the write permission status of the blockchain account address associated with the node identifier holding temporary write permission in the permission mapping table from temporary write permission to "submitted", and rejects the request from the blockchain account address associated with the node identifier to submit the processing result again. The mapping relationship between the hash value of the processing result and the hash value of the original fault data, as well as the storage identifier of the processing result data, are stored in the blockchain.

[0032] Specifically, when the node pointed to by the current pointer holds temporary write permissions, the node submits the processing result by calling the `submitResult` function of the smart contract. The function receives two parameters: the processing result data `resultData` and its hash value `resultHash`. After the executing node completes fault handling (e.g., equipment repair, hazard elimination), it generates processing result data, which includes a processing description, repair records, a list of replaced parts, and on-site images. The executing node performs a hash operation on the processing result data using client software to obtain the processing result hash value. The executing node calls the `submitResult` function to submit the processing result data (e.g., off-chain storage) and its hash value to the smart contract. The smart contract first verifies whether the caller address `msg.sender` has a value of 1 in the permission mapping table `permissionTable` (temporary write permission). If not, it rolls back directly. Since account addresses with a value of 1 in the permission mapping table always match the blockchain account address associated with the node identifier pointed to by the current pointer `currentPointer`, this verification confirms that the caller is the node that should be processed. After successful verification, the contract establishes a key-value mapping between the input resultHash and the hash value originalHash of the original fault data stored in the contract: the mapping is stored in the blockchain state variable using storedMapping[originalHash] = resultHash. This mapping, once on-chain, is immutable. Other nodes can query the corresponding resultHash through originalHash, thereby verifying the correspondence between the processing result and the original fault, forming a complete chain of evidence. The processing result data itself is stored by the executing node using an off-chain distributed storage system (such as IPFS). After generating the processing result data, the executing node uploads it to the storage system and obtains the storage identifier (e.g., the Content Identifier (CID) in IPFS). When the executing node calls the submitResult function, in addition to passing resultHash, it also passes the storage identifier as a parameter. The smart contract associates the storage identifier with originalHash and stores it in storedMapping. When the current pointer points to the acceptance node, after the acceptance node obtains temporary write permission, it first reads the storage identifier from the blockchain before submitting the closed-loop signature. Using this identifier, it retrieves the processing result data from the storage system, calculates its hash value, and compares it with the resultHash stored on the chain. If they match, the authenticity is confirmed, and the closed-loop signature operation can continue. If off-chain data retrieval fails, the acceptance node can call the requestRetransmission function in the contract to trigger a retransmission mechanism. The smart contract records this event and notifies the execution node to re-upload the data.If the system fails to retry after the preset number of retries, it records the exception as "data transmission failure" and triggers the same self-healing process as the closed-loop verification failure. After successful mapping and storage, the smart contract immediately updates the permission mapping table `permissionTable`, changing the value of the node's blockchain account address `msg.sender` from 1 (temporary write permission) to 2 ("committed" status). Simultaneously, it increments the current pointer `currentPointer` by 1, making it point to the acceptance node in the chain response record, and updates the acceptance node's write permission status from 0 (no permission) to 1 (temporary write permission). The business state machine `stateMachine` is also updated to state value 5 (pending acceptance). All these operations are executed sequentially within the same transaction to ensure atomicity. After the update, the node's value in the permission mapping table is 2, indicating that the processing result has been submitted. Subsequently, if the same node calls `submitResult` again to attempt a duplicate submission, the `require(permissionTable[msg.sender] == 1)` at the beginning of the contract will fail due to the current value being 2, thus rejecting the request and preventing the same node from repeatedly submitting processing result data, ensuring the uniqueness of the mapping relationship. It should be understood that the above-mentioned submitResult function, hash mapping storage method, permission status encoding, and generation and transmission method of processing result data are only examples. In actual implementation, they can be adjusted according to specific business needs and do not constitute a limitation on the scope of protection of this application.

[0033] When the current pointer points to the terminal node identifier in the chain response record, and the closed-loop signature submitted through the blockchain account address associated with the terminal node identifier is verified, the smart contract instance extracts the hash value encapsulated in the closed-loop signature and compares it with the hash value of the processing result that establishes a mapping relationship on the blockchain: If the comparison matches, the termination function of the smart contract instance is called to release the computing and storage resources occupied by the smart contract instance from the node memory of the blockchain network, and a closed-loop evidence-based transaction is generated and written to the blockchain. If the comparison is inconsistent, the smart contract instance remains active, the current pointer is rolled back to the previous node identifier, and an anomaly trace record is generated and written to the blockchain.

[0034] Furthermore, if the comparison is inconsistent, it includes: The current pointer is rolled back to the previous node identifier, and the write permission status of the blockchain account address associated with the previous node identifier is reconfigured to temporary write permission. Increment the error attempt count associated with the previous node identifier by one; the error attempt count is stored in the state variable maintained by the smart contract instance. When the error attempt count exceeds a preset threshold, the backup node identifier corresponding to the current fault type code is automatically obtained according to the construction fault type-job routing configuration table. The previous node identifier in the chain response record is replaced with the backup node identifier, the error attempt count is cleared to zero, and the current pointer is set to the backup node identifier.

[0035] Specifically, when the current pointer (currentPointer) of a smart contract instance points to the terminal node identifier in the chain response record, and this terminal node submits a closed-loop signature by calling the submitFinalSignature function, the contract first extracts the hash value finalHash encapsulated in the signature and compares it with the storedMapping[originalHash], i.e., the hash value of the processing result, stored in the contract. If the comparison matches, the smart contract calls the Solidity built-in selfdestruct function to remove the contract instance's code and current state variables (including the state machine stateMachine, current pointer currentPointer, permission table permissionTable, error count errorCount, etc.) from the active state of the blockchain node, so that the contract no longer responds to any external calls. At the same time, it releases the storage space occupied by the contract account (including state variable storage) and returns the remaining Gas. This mechanism has practical technical significance in blockchain resource-constrained environments: by promptly destroying contract instances that have completed their mission, it can prevent invalid contracts from occupying on-chain storage resources for a long time, reduce the overall storage cost of the system, and release available contract address space for subsequent new failure events. Simultaneously, the smart contract generates a closed-loop notarized transaction, which includes a fault event identifier, a matching result, and a completion timestamp. This transaction is written to the blockchain distributed ledger, marking the successful termination of the fault handling process. It should be understood that historical transactions and event logs written to the blockchain are permanently retained in the distributed ledger and are not deleted due to contract self-destruction. If the matching is inconsistent, the contract remains active and performs the following operations: First, decrement the value of the current pointer `currentPointer` by 1, causing it to roll back to the previous node identifier. Obtain the current permission status `status` of the previous node in the permission mapping table. If `status == 0` (no permission), call the `resetPermission` function to update the write permission status of the blockchain account address associated with the previous node identifier in the permission mapping table from 0 to 1 (temporary write permission), restoring the node's processing permissions. Simultaneously, roll back the business state machine `stateMachine` to the state corresponding to the node's role: if rolling back to the execution node, update to state value 4 (executing); if rolling back to the audit node, update to state value 2 (auditing). If status == 2 (committed), the permission recovery step is skipped, and the node is directly marked as failed. The business state machine (stateMachine) remains in its current state (pending acceptance) without rollback. Next, the contract increments the error count (errorCount) associated with that node, stored in the state variable, by 1. This count is initially 0 and increments each time the node fails to complete the loop closure verification.The contract then checks if `errorCount` exceeds a preset threshold `MAX_RETRIES` (e.g., 3 times). If it does not, only an anomaly traceability record is generated, recording the reason for failure, the current fault event identifier, and a timestamp, written to the blockchain, and the node is left to attempt to submit the closed-loop signature again. If the threshold is exceeded, the contract executes a temporary fault tolerance mechanism for the current fault instance: based on the current fault type code, it queries the construction fault type-job routing configuration table for a backup node identifier that matches the fault type. For example, if the fault type is "E001" (circuit fault), the routing configuration table returns the backup electrician team's account address. The contract calls the `updateNodeSequence` function, replacing the previous node identifier that failed in the chain response record with the backup node identifier, clearing `errorCount` to zero, and setting the current pointer `currentPointer` to the newly replaced backup node identifier, thereby enabling the backup node to continue processing. It should be noted that this replacement only applies to the current fault event instance and does not modify the global routing configuration table; updates to the global configuration table are still managed independently by the aforementioned "dynamic adjustment at the configuration table level" mechanism. It should be understood that the above-mentioned submitFinalSignature function, selfdestruct self-destruct mechanism, resetPermission permission recovery function, error count storage, MAX_RETRIES threshold, and updateNodeSequence node sequence update function are only examples. In actual implementation, they can be adjusted according to specific business rules and blockchain platform characteristics, and do not constitute a limitation on the scope of protection of this application.

[0036] Example 2, based on the same inventive concept as the chain response management method for construction fault handling information in the foregoing examples, such as... Figure 2 As shown, this application provides a chain response management system for construction fault handling information. The system and method embodiments in this application are based on the same inventive concept. The system includes: The message acquisition module 10 is used to acquire fault trigger messages during the construction process. The fault trigger message includes at least a fault type code and a hash value of the original fault data. The chain response record generation module 20 is used to query the preset construction fault type-job routing configuration table based on the fault type code and generate chain response records. The chain response record is a sequence of node identifiers arranged according to the construction processing logic sequence, and each node identifier is associated with a blockchain account address. The contract deployment module 30 is used to deploy a smart contract instance for the current fault event on the blockchain using the fault trigger message and the chain response record as construction parameters. The smart contract instance maintains a state machine and initializes the current pointer to point to the first node identifier in the chain response record. The smart contract instance also maintains a permission mapping table to record the write permission status of the blockchain account address associated with each node identifier for fault handling data. The transaction monitoring and execution module 40 is used to monitor signed transactions in the blockchain. When the issuing account address of the monitored signed transaction is consistent with the blockchain account address associated with the node identifier pointed to by the current pointer, and the signature data carried by the signed transaction is decrypted and verified to match the hash value of the faulty original data, the smart contract instance atomically updates the current state of the state machine to the preset next state within a transaction execution cycle, updates the current pointer to point to the next node identifier in the chain response record, and updates the permission mapping table to configure the temporary write permission of the node pointed to by the current pointer. The temporary write permission corresponds to the period during which the current pointer stays at the node identifier. The result processing module 50 is used by the smart contract instance to receive the processing result data and its hash value returned by the node holding temporary write permission, and to establish a mapping relationship between the hash value of the processing result and the hash value of the original fault data on the blockchain and store it, while updating the write permission status of the node in the permission mapping table to "committed". The closed-loop verification and processing module 60 is used to, when the current pointer points to the terminal node identifier in the chain response record, and the closed-loop signature submitted through the blockchain account address associated with the terminal node identifier is verified, extract the hash value encapsulated in the closed-loop signature from the smart contract instance and compare it with the hash value of the processing result that establishes a mapping relationship on the blockchain. If the comparison matches, the termination function of the smart contract instance is called to release the computing and storage resources occupied by the smart contract instance from the node memory of the blockchain network, and a closed-loop evidence-based transaction is generated and written to the blockchain. If the comparison is inconsistent, the smart contract instance remains active, the current pointer is rolled back to the previous node identifier, and an anomaly trace record is generated and written to the blockchain.

[0037] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

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

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

Claims

1. A chain-response management method for construction fault handling information, characterized in that, The method includes: Obtain fault trigger messages during the construction process, wherein the fault trigger messages include at least a fault type code and a hash value of the original fault data; Based on the fault type code, a preset construction fault type-job routing configuration table is queried to generate a chain response record. The chain response record is a sequence of node identifiers arranged according to the construction processing logic sequence, and each node identifier is associated with a blockchain account address. Using the fault trigger message and the chain response record as construction parameters, a smart contract instance for the current fault event is deployed on the blockchain. The smart contract instance maintains a state machine and initializes the current pointer to point to the first node identifier in the chain response record. The smart contract instance also maintains a permission mapping table to record the write permission status of the blockchain account address associated with each node identifier for fault handling data. The smart contract instance listens to signed transactions in the blockchain. When the issuing account address of the listened signed transaction matches the blockchain account address associated with the node identifier pointed to by the current pointer, and the signature data carried by the signed transaction is decrypted and verified to match the hash value of the original fault data, the smart contract instance atomically updates the current state of the state machine to the preset next state within a transaction execution cycle, updates the current pointer to point to the next node identifier in the chain response record, and updates the permission mapping table to configure the temporary write permission of the node pointed to by the current pointer. The temporary write permission corresponds to the period during which the current pointer stays at the node identifier. The smart contract instance receives the processing result data and its hash value returned by the node holding temporary write permission, and establishes a mapping relationship between the hash value of the processing result and the hash value of the original fault data on the blockchain and stores it. At the same time, it updates the write permission status of the node in the permission mapping table to "committed". When the current pointer points to the terminal node identifier in the chain response record, and the closed-loop signature submitted through the blockchain account address associated with the terminal node identifier is verified, the smart contract instance extracts the hash value encapsulated in the closed-loop signature and compares it with the hash value of the processing result that establishes a mapping relationship on the blockchain: If the comparison matches, the termination function of the smart contract instance is called to release the computing and storage resources occupied by the smart contract instance from the node memory of the blockchain network, and a closed-loop evidence-based transaction is generated and written to the blockchain. If the comparison is inconsistent, the smart contract instance remains active, the current pointer is rolled back to the previous node identifier, and an anomaly trace record is generated and written to the blockchain.

2. The chain response management method for construction fault handling information according to claim 1, characterized in that, The step of querying the preset construction fault type-job routing configuration table based on the fault type code to generate chained response records includes: The fault type code is used to query the pre-stored fault type-node sequence mapping relationship to determine the node sequence corresponding to the fault type code. The node sequence is the chained response record. The job routing configuration table is dynamically updated based on historical fault handling data. When the hash value of the processing result corresponding to the same fault type code is inconsistent after multiple verifications within a preset time period, the node identifier order in the node sequence corresponding to the fault type code is automatically adjusted or the node identifier is replaced. The adjustment is used for subsequent new fault events of the same type.

3. The chain response management method for construction fault handling information according to claim 2, characterized in that, The generation of chained response records also includes: The fault trigger message also carries the fault location coordinates. Based on the fault location coordinates, candidate nodes whose distance from the fault location coordinates is within a preset threshold range are selected from the preset processing node resource pool associated with the construction fault type-job routing configuration table. Based on the distance between the candidate node and the fault location, the hash verification pass rate of historical processing results, and the node's qualification level for handling fault types, the processing priority of each candidate node is comprehensively determined, and the identifier of the node with the highest priority is used as the execution node in the chain response record. The hash verification pass rate of the historical processing results is obtained based on the dynamic update of the historical fault processing data.

4. The chain response management method for construction fault handling information according to claim 1, characterized in that, The step of deploying a smart contract instance for the current fault event on the blockchain, using the fault trigger message and the chained response record as construction parameters, includes: An independent smart contract instance is created for each fault event. The independent smart contract instance is constructed using the fault trigger message and the chain response record as construction parameters. The state machine, current pointer and permission mapping table maintained inside the independent smart contract instance are isolated from the smart contract instances corresponding to other fault events. The current pointer is an integer index value stored in the state variable of the smart contract instance, with an initial value of 1, pointing to the first node identifier in the chained response record arranged according to the processing logic sequence; The permission mapping table is a key-value data structure maintained in the smart contract instance, with the blockchain account address associated with the node identifier as the key and the write permission status of the fault handling data as the value. When the permission mapping table is initialized, only the write permission status of the blockchain account address associated with the first node identifier in the chain response record is set to temporary write permission, while the write permission status of the blockchain account addresses associated with the remaining node identifiers is set to no permission.

5. The chain response management method for construction fault handling information according to claim 1, characterized in that, The update permission mapping table includes: Update the write permission status of the blockchain account address originally associated with the node identifier in the permission mapping table from temporary write permission to no permission; Update the write permission status of the blockchain account address associated with the node identifier currently pointed to by the pointer in the permission mapping table from no permission to temporary write permission; The temporary write permission is valid from the time the current pointer points to the node identifier until the current pointer points to the next node identifier. When the current pointer leaves the node identifier, the temporary write permission automatically expires and cannot be recovered.

6. The chain response management method for construction fault handling information according to claim 1, characterized in that, The atomicity within the execution cycle includes: When any operation fails to update the current state of the state machine to the preset next state, update the current pointer to point to the next node identifier in the chained response record, or update any operation in the permission mapping table, all executed operations are automatically rolled back, and the state machine, the current pointer, and the permission mapping table are restored to their states before atomic execution.

7. The chain response management method for construction fault handling information according to claim 1, characterized in that, The step of establishing and storing a mapping relationship between the hash value of the processing result and the hash value of the original fault data on the blockchain, and simultaneously updating the write permission status of the node in the permission mapping table to "committed", includes: The smart contract instance updates the write permission status of the blockchain account address associated with the node identifier holding temporary write permission in the permission mapping table from temporary write permission to "submitted", and rejects the request from the blockchain account address associated with the node identifier to submit the processing result again. The mapping relationship between the hash value of the processing result and the hash value of the original fault data, as well as the storage identifier of the processing result data, are stored in the blockchain.

8. The chain response management method for construction fault handling information according to claim 1, characterized in that, If the comparison is inconsistent, it includes: The current pointer is rolled back to the previous node identifier, and the write permission status of the blockchain account address associated with the previous node identifier is reconfigured to temporary write permission. Increment the error attempt count associated with the previous node identifier by one; the error attempt count is stored in the state variable maintained by the smart contract instance. When the error attempt count exceeds a preset threshold, the backup node identifier corresponding to the current fault type code is automatically obtained according to the construction fault type-job routing configuration table. The previous node identifier in the chain response record is replaced with the backup node identifier, the error attempt count is cleared to zero, and the current pointer is set to the backup node identifier.

9. A chain-response management system for construction fault handling information, characterized in that, For implementing the method of any one of claims 1 to 8, comprising: The message acquisition module is used to acquire fault trigger messages during the construction process. The fault trigger message includes at least a fault type code and a hash value of the original fault data. A chain response record generation module is used to query a preset construction fault type-job routing configuration table based on the fault type code and generate chain response records. The chain response record is a sequence of node identifiers arranged according to the construction processing logic sequence, and each node identifier is associated with a blockchain account address. The contract deployment module is used to deploy a smart contract instance for the current fault event on the blockchain using the fault trigger message and the chain response record as construction parameters. The smart contract instance maintains a state machine and initializes the current pointer to point to the first node identifier in the chain response record. The smart contract instance also maintains a permission mapping table to record the write permission status of the blockchain account address associated with each node identifier for fault handling data. The transaction monitoring and execution module is used to monitor signed transactions in the blockchain. When the issuing account address of the monitored signed transaction is consistent with the blockchain account address associated with the node identifier pointed to by the current pointer, and the signature data carried by the signed transaction is decrypted and verified to match the hash value of the faulty original data, the smart contract instance atomically updates the current state of the state machine to the preset next state within a transaction execution cycle, updates the current pointer to point to the next node identifier in the chain response record, and updates the permission mapping table to configure the temporary write permission of the node pointed to by the current pointer. The temporary write permission corresponds to the period during which the current pointer stays at the node identifier. The result processing module is used by the smart contract instance to receive the processing result data and its hash value returned by the node holding temporary write permission, and to establish a mapping relationship between the hash value of the processing result and the hash value of the original fault data on the blockchain and store it, while updating the write permission status of the node in the permission mapping table to "committed". The closed-loop verification and processing module is used to compare the hash value encapsulated in the closed-loop signature with the hash value of the processing result that establishes a mapping relationship on the blockchain when the current pointer points to the terminal node identifier in the chain response record and the closed-loop signature submitted through the blockchain account address associated with the terminal node identifier is verified. If the comparison matches, the termination function of the smart contract instance is called to release the computing and storage resources occupied by the smart contract instance from the node memory of the blockchain network, and a closed-loop evidence-based transaction is generated and written to the blockchain. If the comparison is inconsistent, the smart contract instance remains active, the current pointer is rolled back to the previous node identifier, and an anomaly trace record is generated and written to the blockchain.

Images