Electronic lead seal data management method based on block chain

Abstract

The invention discloses an electronic lead seal data management method based on a block chain, relates to the technical field of internet data services, and aims to solve the problems of node data asynchronization, state updating failure and potential safety hazards of an intelligent contract in the prior art. The data consistency is ensured through a distributed clock synchronization algorithm and a version number verification mechanism; the reliability and fault tolerance of state updating are improved by adopting an improved Byzantine fault-tolerant algorithm and an asynchronous two-stage transaction submission mechanism; data integrity and traceability are guaranteed through a state machine detection mechanism and transaction log records; the security and maintainability of the smart contract are improved based on an automatic code auditing algorithm and a proxy contract mode of a graph neural network; real-time data monitoring and exception repair are realized by using an under-chain auditing mechanism and a cross-chain data consistency verification protocol; according to the invention, the data consistency, the system safety and the reliability of electronic lead seal data management are obviously improved.

Description

Technical Field

[0001] The present invention relates to the field of Internet data service technology, and more specifically to a blockchain-based electronic seal data management method. Background Art

[0002] With the rapid development of the Internet of Things (IoT), electronic seals, a key means of ensuring cargo transportation safety, face increasingly complex data management requirements. The introduction of blockchain technology aims to enhance the security and reliability of electronic seal data management through its decentralized, transparent, and tamper-proof features.

[0003] An electronic seal is a device that uses electronic locks and sensor technology to seal goods. It ensures the safety of goods during transportation by recording the open and closed status. The blockchain-based electronic seal data management method uses the distributed ledger characteristics of blockchain technology to achieve sharing and tamper-proofing of seal status data. In the prior art, smart contracts are widely used to process status changes and event triggers of electronic seals. As an automatically executed program, a smart contract can automatically judge and execute corresponding operations based on preset logical conditions. For example, patent CN114866249B discloses a blockchain-based multi-group electronic tag seal sealing system and interaction method. By establishing a data interaction channel between the Internet of Things device and the blockchain, the status of the electronic seal is monitored in real time using smart contracts to achieve secure data transmission and non-tampering. However, although the existing technical solutions have achieved certain results in ensuring data security and transparency, there are still some problems in actual application:

[0004] First, due to the asynchronous and delayed nature of blockchain transaction processing, data from different nodes may become out of sync when updating the seal status. For example, during transportation, multiple nodes simultaneously uploading the seal status could lead to status conflicts, resulting in inconsistent understandings of the seal status between regulators and logistics providers. Second, anomalies during smart contract execution (such as network latency, contract logic flaws, or resource contention) could cause status updates to fail or data to roll back. For example, if the seal status is updated from "closed" to "opened," if the transaction is not confirmed in a timely manner, the status may remain at "closed," resulting in data mismatches. Furthermore, patent CN114866249B fails to account for data synchronization anomalies between nodes, which could result in missing data from the chain, compromising data integrity. Finally, since smart contracts cannot be modified after deployment, code vulnerabilities and logical flaws could be exploited maliciously, posing security risks to the system. If smart contracts contain design flaws in permission management or input validation, attackers could tamper with seal data or bypass security mechanisms, leading to system loss of control. Summary of the Invention

[0005] In response to the shortcomings of the existing technology, the present invention discloses a blockchain-based electronic seal data management method, which aims to solve the problems in the existing technology such as data asynchrony and latency caused by blockchain transactions, status update failure or data rollback caused by smart contract execution exceptions, data loss caused by data synchronization exceptions between nodes, and security risks caused by smart contract code vulnerabilities and logical defects.

[0006] The present invention adopts the following technical solutions:

[0007] A blockchain-based electronic seal data management method includes the following steps:

[0008] Step S1: Generate a unique identifier for each seal status update based on the timestamp and version number, and manage the status updates of each seal node through a distributed clock synchronization algorithm; the distributed clock synchronization algorithm verifies the timestamp and version number of each status update through a smart contract, and automatically rejects the status update request if the version number of the current node does not match the latest version;

[0009] Step S2: When the status of the electronic seal changes, the state change request is verified by multi-node threshold signature using the improved Byzantine fault-tolerant algorithm. If the verification passes, a state update transaction is generated. If the verification fails, the request is rejected and the exception recording mechanism is triggered.

[0010] Step S3: Before the state is changed, an asynchronous two-phase commit transaction mechanism is used. In the pre-commit phase, a smart contract is used to lock the sealed state resource and generate a globally unique transaction identifier. If the multi-node consistency verification passes, the formal commit phase is entered and the state update is executed. If an anomaly is detected, the transaction rollback mechanism is immediately triggered to restore the initial state.

[0011] Step S4: Each time the seal status is updated, the finite state machine is used to detect abnormal conditions, including but not limited to contract logic defects and network delays. The transaction log records the preceding and subsequent transactions of each seal update operation, and automatically restores the preceding transaction status in the event of a transaction failure.

[0012] Step S5: After the status update is completed, the updated seal status data is encrypted and backed up through the distributed storage system based on blockchain, and the data hash value is synchronized to the chain in real time. If the off-chain data backup fails, the data storage is re-executed;

[0013] Step S6: Before the smart contract is deployed, static symbolic execution analysis and dynamic fuzz testing are performed on the contract code using an automated code auditing algorithm based on a graph neural network. If a security vulnerability is detected, the deployment is blocked and a multi-dimensional vulnerability report is automatically generated. If the code is safe, the contract is allowed to go online safely.

[0014] Step S7: Separate the business logic and data storage into the business layer and storage layer through the proxy contract model and access control mechanism. If the business logic needs to be updated, the proxy contract is used to complete the logic hot update;

[0015] Step S8: The main chain data is monitored in real time through the off-chain audit mechanism and the cross-chain data consistency verification protocol to check the legality, timeliness and consistency of the seal status; if data anomalies are detected, the state machine-based repair strategy is automatically called to repair the data. If the data is consistent, the result record is updated and the process is completed.

[0016] Preferably, in step S1, the working principle of the distributed clock synchronization algorithm is as follows: a unique identifier is generated based on the timestamp and version number, the timestamp of each node is calibrated by the distributed clock synchronization protocol NTP, and during the processing of the status update request, the timestamp T in the request is extracted by the smart contract. req and version number V req , based on the latest version number V on the chain latest Compare; if V req <V latest , then the rejection mechanism is triggered, the request is rejected and the log is recorded; if V req =V latest +1, then enter the timestamp verification phase; during the timestamp verification process, calculate the timestamp difference ΔT = T req -T latest If ΔT exceeds the preset threshold, the status update request with the latest timestamp is selected through the priority strategy, which calculates the priority score through formula (1):

[0017] S=w1V req +w2(T req -T base ) (1)

[0018] In formula (1), w1 and w2 are weight coefficients, T base The state update request with the highest score is selected as the valid request, and then the valid state update data is written into the blockchain through the smart contract, and the updated state data is broadcast to all nodes based on the Gossip protocol. After the node receives the broadcast data, it calibrates the timestamp based on the local clock synchronization module and updates the local state data. If network delay or node failure is detected, it will retry through the exponential backoff algorithm, and the retry interval is T. retyp The calculation formula is:

[0019] T retyp =T base ×2 n-1 (2)

[0020] In formula (2), Tbase is the initial retry interval; n is the number of retries.

[0021] Preferably, the improved Byzantine fault-tolerant algorithm performs multi-node threshold signature verification on the state change request as follows: based on the electronic seal state change request data, including the seal ID, target state value, timestamp and node signature, a distributed key generation algorithm is used to generate the private key shard s of each node i. i , and calculate the aggregate signature based on the Lagrange interpolation formula. The calculation formula is:

[0022]

[0023] In formula (3), L i (0) is the Lagrange basis polynomial, k is the threshold number of nodes; in the signature generation process, each node is based on the private key shard s i Partially sign the request data and transmit the partial signature to the aggregation node; the aggregation node reconstructs the complete signature S based on the Lagrange interpolation formula agg and verify the signature S based on the elliptic curve digital signature algorithm agg Effectiveness.

[0024] Preferably, the asynchronous two-phase commit transaction mechanism includes a first commit phase and a second commit phase. In the first commit phase, the sealed state resources are encrypted and locked based on the hash time lock contract, and a globally unique transaction identifier is generated; then, the node voting results are encrypted and aggregated using multi-party secure computing; if the multi-node consistency verification is passed, the second commit phase is entered, and the transaction execution is confirmed through the improved cross-node consistency voting mechanism; if an anomaly is detected, the transaction rollback mechanism based on the Merkle tree is triggered, and the initial state is quickly restored by tracing back the storage path, and the blockchain log is updated in real time.

[0025] Preferably, the working method of step S4 is as follows: based on each seal status update operation, the state transition process is dynamically monitored by a finite state machine, and potential abnormalities are detected in real time, including contract logic defects, network delays and data synchronization inconsistencies; the finite state machine performs feature extraction and pattern matching on the state change sequence based on a behavior anomaly detection algorithm; during the state transfer process, if an abnormality is detected, the preceding transaction state S of each state update operation is pre and post-transaction status S post Recorded to the distributed log storage system; during the transaction execution process, if the state transfer fails, the previous transaction state S in the transaction log is used pre, restore the seal state to the initial state before the update through the state rollback function; the state rollback function is based on the log playback method, and ensures the accuracy and consistency of the state recovery by replaying the transaction log records one by one; if the state transfer is successful, the post-transaction state S post Write to the blockchain and verify the integrity of the state data based on the Merkle tree structure.

[0026] Preferably, the working method of step S5 is: first, the sealed data is encrypted by a homomorphic encryption algorithm; then, the encrypted data is sharded and stored in a multi-node environment using a distributed hash table, and a unique hash value is generated for each data shard, and the data hash value is uploaded to the chain in real time through a smart contract; if a node storage failure is detected during the off-chain data backup process, the redundancy check mechanism is automatically triggered, the data is reallocated to other stable nodes, and the storage operation is repeated.

[0027] Preferably, the working method of the automated code audit algorithm based on graph neural network is:

[0028] U1. Based on the smart contract source code, the control flow graph and data flow graph of the code are extracted through static symbolic execution analysis, and a graph data structure G = (V, E, A) is constructed, where V represents the code basic block node, including functions and variables; E represents the control flow or data flow edge, and A represents the semantic association matrix between nodes; in the process of processing the graph structure data, the code is feature extracted through the graph attention network, which calculates the embedding vector h of each node through the node embedding formula v ; The node embedding formula is:

[0029]

[0030] In formula (4), represents the embedding vector of node v in the l+1 layer, which is used to capture the semantic features of the node; σ represents the activation function; W (l) represents the weight matrix of the lth layer, which is used to linearly transform node features; b (l) represents the bias vector of the lth layer, which is used to adjust the offset of the node feature; N(v) represents the neighbor set of node v, which is used to aggregate the local graph structure information; a vu represents the attention coefficient between node v and node u, which is used to dynamically allocate the importance weights between nodes; a represents the learnable parameter vector in the attention mechanism;

[0031] U2, in the static symbolic execution analysis, the symbolic execution path set P = {p1, p2, ... p n}, and based on the path coverage formula Evaluate code coverage; where P coveredrepresents the set of paths that have been covered by symbolic execution or dynamic fuzz testing; P total Represents the set of all theoretical execution paths in the code; in dynamic fuzz testing, the test case set T={t1,t2,...t m}, and optimize the test case generation strategy based on coverage feedback; through the collaborative optimization mechanism, the symbolic execution path P is dynamically combined with the fuzz test case T to detect security vulnerabilities, including but not limited to reentrancy attacks and integer overflows;

[0032] U3, if a vulnerability is detected, based on the vulnerability feature vector F v ={f1,f2,...f m Generate multidimensional vulnerability report R v , and calculate the vulnerability severity score using the vulnerability scoring formula; the vulnerability scoring formula is:

[0033]

[0034] In formula (5), S v Indicates the vulnerability severity score; w i Represents vulnerability feature f i The weight is used to adjust the influence of the feature on the score, where f i Indicates the specific characteristics of the vulnerability, including but not limited to vulnerability type, impact scope, and triggering conditions; R v represents the complexity of vulnerability repair; γ represents the weight coefficient of repair complexity, which is used to adjust the impact of repair complexity on the score;

[0035] U4, if S v If S is lower than the preset threshold, the contract deployment is allowed; v If the value is higher than or equal to the preset threshold, the deployment is blocked and a repair code snippet is automatically generated through a template-based repair suggestion generation mechanism.

[0036] Preferably, in step S7, the business layer uses the proxy contract as the entry point for the business logic and stores the address A pointing to the logic contract. logic , and forward the user request to the logic contract execution through the delegate call; when the business logic is updated, based on the hot update mechanism, the logic contract address A is updated through the management interface of the proxy contract logic The new version contract address A new; In the storage layer, the business logic and data storage are decoupled through the state variable separation method; the state variable separation method performs read and write operations on state variables through the data storage contract, and accesses the storage contract through the logic contract using interface calls; during the logic hot update process, the version number of the logic contract is recorded through the version control mechanism, and the upgrade history of the contract is managed based on the version number; if the hot update fails, the logic contract address is restored to the previous version address.

[0037] Preferably, the working principle of step S8 is: based on the light node MPT, synchronize the main chain block header data and extract the seal status update transaction T x and related status data S x During the data monitoring process, the main chain data and the cross-chain copy data are compared through the cross-chain data consistency verification protocol, where the cross-chain copy data is stored in the side chain or distributed storage system, and the consistency is verified by the hash value and the main chain data hash value; if the hash value is inconsistent with the main chain data hash value, the data anomaly detection mechanism is triggered, and the legality, timeliness and consistency of the seal status are checked through the state machine model; the state machine model defines the legal transition rules of the seal status, including "initial state", "update state" and "completed state"; if the state transition does not comply with the rules, it is determined to be an illegal state; if the timestamp exceeds the preset time limit, it is determined to be an expired state; if the cross-chain data hash values ​​are inconsistent, it is determined to be an inconsistent state; if a data anomaly is detected, the state machine-based repair strategy is automatically called, and the transaction log is replayed through the log replay method to restore the seal status to a legal state, and the status update request is resubmitted; if the data is consistent, the audit result record is updated, and the result is written to the main chain to complete the process.

[0038] Based on the above technical solutions, the positive beneficial effects of the present invention are:

[0039] 1. A distributed clock synchronization algorithm and version number verification mechanism ensure that the timestamp and version number of each node are consistent when the seal status is updated, avoiding data asynchrony caused by the asynchrony and latency of blockchain transactions. In addition, an off-chain audit mechanism and a cross-chain data consistency verification protocol monitor the legitimacy, timeliness, and consistency of the main chain data in real time, and automatically invoke a state machine-based repair strategy to repair data when data anomalies are detected. This mechanism ensures real-time monitoring of the seal status and anomaly repair capabilities, improving the system's data consistency and reliability.

[0040] 2. An improved Byzantine fault-tolerant algorithm and an asynchronous two-phase commit transaction mechanism are used to ensure that state change requests are updated only after multi-node verification. This design also provides anomaly detection and transaction rollback capabilities. This design effectively addresses issues of state update failure or data rollback caused by network latency, resource contention, or logical defects during smart contract execution, improving the system's reliability and fault tolerance. An automated code audit algorithm based on graph neural networks is used to perform static symbolic execution analysis and dynamic fuzz testing before smart contracts are deployed to detect and fix code vulnerabilities and logical defects. Through the proxy contract model and access control mechanism, hot updates of business logic and refined permission management are supported, solving the problem of smart contracts being unable to be modified after deployment, significantly improving the system's security and maintainability.

[0041] 3. Through state machine detection mechanisms and transaction logging, the legitimacy, timeliness, and consistency of seal status updates are monitored in real time, and the previous transaction status is automatically restored when an anomaly is detected. Combined with a distributed storage system and encrypted backup technology, this ensures the security of off-chain data and the integrity of on-chain data, preventing data loss caused by data synchronization anomalies between nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a schematic diagram of the steps of a blockchain-based electronic seal data management method of the present invention;

[0043] Figure 2 This is a framework diagram of the working method of step S1 of the present invention;

[0044] Figure 3 Schematic diagram of the principle framework of step S3 of the present invention;

[0045] Figure 4 This is a framework diagram of the working method of step S4 of the present invention;

[0046] Figure 5 This is a framework diagram of the working method of step S8 of the present invention. DETAILED DESCRIPTION

[0047] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0048] In an embodiment, Figure 1As shown: The steps of a blockchain-based electronic seal data management method are as follows: Step S1: Generate a unique identifier for each seal status update based on the timestamp and version number, and manage the status update of each seal node through a distributed clock synchronization algorithm; the distributed clock synchronization algorithm verifies the timestamp and version number of each status update through a smart contract. If the version number of the current node does not match the latest version, the status update request is automatically rejected; the working principle of the distributed clock synchronization algorithm is as follows: generate a unique identifier based on the timestamp and version number, calibrate the timestamp of each node through the distributed clock synchronization protocol NTP, and extract the timestamp T in the request through the smart contract during the processing of the status update request. req and version number V req , based on the latest version number V on the chain latest Compare; if V req <V latest , then the rejection mechanism is triggered, the request is rejected and the log is recorded; if V req =V latest +1, then enter the timestamp verification phase; during the timestamp verification process, calculate the timestamp difference ΔT = T req -T latest If ΔT exceeds the preset threshold, the status update request with the latest timestamp is selected through the priority strategy, and the priority strategy calculates the priority score through formula (1): S = w1V req +w2(T req -T base ), where w1 and w2 are weight coefficients, T base The state update request with the highest score is selected as the valid request, and then the valid state update data is written into the blockchain through the smart contract, and the updated state data is broadcast to all nodes based on the Gossip protocol. After the node receives the broadcast data, it calibrates the timestamp based on the local clock synchronization module and updates the local state data. If network delay or node failure is detected, it will retry through the exponential backoff algorithm, and the retry interval is T. retyp The calculation formula is: retyp =T base ×2 n-1 , where T base is the initial retry interval; n is the number of retries;

[0049] Step S2: When the state of the electronic seal changes, the state change request is verified by multi-node threshold signature using the improved Byzantine fault-tolerant algorithm. If the verification passes, a state update transaction is generated. If the verification fails, the request is rejected and the exception recording mechanism is triggered. The working method of the improved Byzantine fault-tolerant algorithm for multi-node threshold signature verification of the state change request is as follows: based on the electronic seal state change request data, including the seal ID, target state value, timestamp and node signature, a private key shard of each node i is generated by the distributed key generation algorithm. i , and calculate the aggregate signature based on the Lagrange interpolation formula. The calculation formula is: Among them, L i (0) is the Lagrange basis polynomial, k is the threshold number of nodes; in the signature generation process, each node is based on the private key shard s i Partially sign the request data and transmit the partial signature to the aggregation node; the aggregation node reconstructs the complete signature S based on the Lagrange interpolation formula agg and verify the signature S based on the elliptic curve digital signature algorithm agg effectiveness;

[0050] Step S3: Before the state changes, an asynchronous two-phase commit transaction mechanism is adopted. In the pre-commit phase, a smart contract is used to lock the sealed state resource and generate a globally unique transaction identifier. If the multi-node consistency verification passes, the formal commit phase is entered to execute the state update. If an anomaly is detected, the transaction rollback mechanism is immediately triggered to restore the initial state. The asynchronous two-phase commit transaction mechanism includes a first commit phase and a second commit phase. In the first commit phase, the sealed state resource is encrypted and locked based on the hash time lock contract, and a globally unique transaction identifier is generated. Then, the node voting results are encrypted and aggregated using multi-party secure computing. If the multi-node consistency verification passes, the second commit phase is entered, and the transaction execution is confirmed through the improved cross-node consistency voting mechanism. If an anomaly is detected, the transaction rollback mechanism based on the Merkle tree is triggered to quickly restore to the initial state by backtracking the storage path, and the blockchain log is updated in real time.

[0051] Step S4: Each time the seal status is updated, the finite state machine is used to detect abnormal conditions, including but not limited to contract logic defects and network delays, and the transaction log records the preceding and following transactions of each seal update operation, and automatically restores the preceding transaction status when the transaction fails; Figure 4As shown in the figure, the specific working method is as follows: based on each seal status update operation, the state transition process is dynamically monitored by the finite state machine, and potential abnormalities are detected in real time, including contract logic defects, network delays and data synchronization inconsistencies; the finite state machine extracts features and performs pattern matching on the state change sequence based on the behavior anomaly detection algorithm; during the state transfer process, if an abnormality is detected, the previous transaction state S of each state update operation is pre and post-transaction status S post Recorded to the distributed log storage system; during the transaction execution process, if the state transfer fails, the previous transaction state S in the transaction log is used pre , restore the seal state to the initial state before the update through the state rollback function; the state rollback function is based on the log playback method, and ensures the accuracy and consistency of the state recovery by replaying the transaction log records one by one; if the state transfer is successful, the post-transaction state S post Write to the blockchain and verify the integrity of the state data based on the Merkle tree structure;

[0052] Step S5: After the status update is completed, the updated seal status data is encrypted and backed up through a distributed storage system based on blockchain, and the data hash value is synchronized to the chain in real time. If the off-chain data backup fails, the data storage is re-executed. The specific working method is as follows: first, the seal data is encrypted using a homomorphic encryption algorithm; then, the encrypted data is sharded and stored in a multi-node environment using a distributed hash table, and a unique hash value is generated for each data shard. The data hash value is uploaded to the chain in real time through a smart contract; if a node storage failure is detected during the off-chain data backup process, the redundancy check mechanism is automatically triggered, the data is reallocated to other stable nodes, and the storage operation is repeated;

[0053] Step S6: Before the smart contract is deployed, the contract code is subjected to static symbolic execution analysis and dynamic fuzz testing using an automated code auditing algorithm based on a graph neural network. If a security vulnerability is detected, the deployment is blocked and a multi-dimensional vulnerability report is automatically generated. If the code is secure, the contract is allowed to go online safely. The working method of the automated code auditing algorithm based on a graph neural network is as follows:

[0054] U1. Based on the smart contract source code, the control flow graph and data flow graph of the code are extracted through static symbolic execution analysis, and a graph data structure G = (V, E, A) is constructed, where V represents the code basic block node, including functions and variables; E represents the control flow or data flow edge, and A represents the semantic association matrix between nodes; in the process of processing the graph structure data, the code is feature extracted through the graph attention network, which calculates the embedding vector h of each node through the node embedding formula v ; The node embedding formula is: in, represents the embedding vector of node v in the l+1 layer, which is used to capture the semantic features of the node; σ represents the activation function; W (l) represents the weight matrix of the lth layer, which is used to linearly transform node features; b (l) represents the bias vector of the lth layer, which is used to adjust the offset of the node feature; N(v) represents the neighbor set of node v, which is used to aggregate the local graph structure information; a vu represents the attention coefficient between node v and node u, which is used to dynamically allocate the importance weights between nodes; a represents the learnable parameter vector in the attention mechanism;

[0055] U2, in the static symbolic execution analysis, the symbolic execution path set P = {p1, p2, ... p n}, and based on the path coverage formula Evaluate code coverage; where P covered represents the set of paths that have been covered by symbolic execution or dynamic fuzz testing; P total Represents the set of all theoretical execution paths in the code; in dynamic fuzz testing, the test case set T={t1,t2,...t m}, and optimize the test case generation strategy based on coverage feedback; through the collaborative optimization mechanism, the symbolic execution path P is dynamically combined with the fuzz test case T to detect security vulnerabilities, including but not limited to reentrancy attacks and integer overflows;

[0056] U3, if a vulnerability is detected, based on the vulnerability feature vector F v ={f1,f2,...f m Generate multidimensional vulnerability report R v , and calculate the vulnerability severity score using the vulnerability scoring formula; the vulnerability scoring formula is: Among them, S v Indicates the vulnerability severity score; w i Represents vulnerability feature f i The weight is used to adjust the influence of the feature on the score, where f i Indicates the specific characteristics of the vulnerability, including but not limited to vulnerability type, impact scope, and triggering conditions; R v represents the complexity of vulnerability repair; γ represents the weight coefficient of repair complexity, which is used to adjust the impact of repair complexity on the score;

[0057] U4, if S v If S is lower than the preset threshold, the contract deployment is allowed; v If the value is higher than or equal to the preset threshold, the deployment is blocked and a repair code snippet is automatically generated through a template-based repair suggestion generation mechanism.

[0058] Step S7: The business logic and data storage are separated into the business layer and the storage layer through the proxy contract mode and access control mechanism. If the business logic needs to be updated, the logic hot update is completed through the proxy contract; the business layer uses the proxy contract as the entry point of the business logic and stores the address A pointing to the logic contract. logic , and forward the user request to the logic contract execution through the delegate call; when the business logic is updated, based on the hot update mechanism, the logic contract address A is updated through the management interface of the proxy contract logic The new version contract address A new In the storage layer, the business logic is decoupled from the data storage through a state variable separation method. The state variable separation method performs read and write operations on state variables through the data storage contract, and accesses the storage contract through the logic contract using an interface call. During the logic hot update process, the version number of the logic contract is recorded through the version control mechanism, and the upgrade history of the contract is managed based on the version number. If the hot update fails, the logic contract address is restored to the previous version address.

[0059] Step S8: The main chain data is monitored in real time through the off-chain audit mechanism and the cross-chain data consistency verification protocol to check the legality, timeliness and consistency of the seal status; if data anomalies are detected, the state machine-based repair strategy is automatically called to repair the data. If the data is consistent, the result record is updated and the process is completed; Figure 5 As shown, the specific working principle is: based on the light node MPT, synchronize the main chain block header data and extract the lead seal status update transaction T x and related status data S x During the data monitoring process, the main chain data and the cross-chain copy data are compared through the cross-chain data consistency verification protocol, where the cross-chain copy data is stored in the side chain or distributed storage system, and the consistency is verified by the hash value and the main chain data hash value; if the hash value is inconsistent with the main chain data hash value, the data anomaly detection mechanism is triggered, and the legality, timeliness and consistency of the seal status are checked through the state machine model; the state machine model defines the legal transition rules of the seal status, including "initial state", "update state" and "completed state"; if the state transition does not comply with the rules, it is determined to be an illegal state; if the timestamp exceeds the preset time limit, it is determined to be an expired state; if the cross-chain data hash values ​​are inconsistent, it is determined to be an inconsistent state; if a data anomaly is detected, the state machine-based repair strategy is automatically called, and the transaction log is replayed through the log replay method to restore the seal status to a legal state, and the status update request is resubmitted; if the data is consistent, the audit result record is updated, and the result is written to the main chain to complete the process.

[0060] In step S1 of the above embodiment, the timestamp records the precise time of the status update, reflecting the order of update operations. This time stamp is typically obtained through the node's local clock and calibrated in conjunction with the distributed clock synchronization protocol NTP. The NTP protocol synchronizes node clocks by exchanging information between multiple time servers and nodes in the network. Specifically, the NTP protocol uses a layered architecture, with nodes requesting and feeding back time information to and from a higher-level time server. By calculating network delays and clock offsets, the version number is used to identify the number of iterations of the seal status update. When a seal status undergoes a new change, its version number increments, ensuring the distinction between different updates under the same timestamp. The unique identifier formed by the combination of the two provides the basis for subsequent status update processing.

[0061] In a distributed environment, node clock synchronization is critical to ensuring system operation. The NTP protocol goes beyond simply transmitting time information; it uses complex algorithms to mitigate the impact of network latency on clock synchronization. Nodes periodically send time synchronization requests to multiple time servers. Upon receiving the requests, these time servers relay their own time information and the timestamp of the request to the node. Upon receiving the feedback, the node constructs a timestamp pair using this information. Using the least squares curve fit method, it calculates the clock offset and network latency, and then adjusts its own clock. This integration of multi-source information and precise calculations allows the node's clock to more accurately align with the network's standard time, providing a reliable time basis for status update timestamps.

[0062] Smart contracts, as automated code executed on the blockchain, play a key role in verifying state updates. When receiving a state update request, the smart contract extracts the timestamp and version number information from the request. For the version number, the smart contract accesses the latest version of the seal stored on the blockchain. Through a comparison mechanism, if the requested version number is lower than the latest version, the update may be outdated or duplicate, triggering a rejection mechanism and logging. This is based on the blockchain's immutability and traceability, as data stored on the blockchain provides authoritative version information. Timestamp verification is more than a simple comparison; calculating timestamp differences requires consideration of network latency and system clock skew. When multiple nodes initiate update requests nearly simultaneously, the timestamp difference may be small. Determining whether a timestamp exceeds a preset threshold requires a comprehensive consideration of the network's dynamic characteristics and the system's tolerance.

[0063] The Gossip protocol is a decentralized information dissemination mechanism. After valid status updates are written to the blockchain, they are broadcast to all nodes. Each node randomly selects a subset of its neighbors and transmits the update to them. The neighbors that receive the update then repeat this process. This method, similar to viral propagation, offers excellent scalability and fault tolerance. Compared to traditional centralized broadcasting, the Gossip protocol eliminates the need for central control and efficiently disseminates information within a distributed system, while avoiding the risk of single points of failure. During the process of information transmission between nodes, it leverages message redundancy and random propagation to ensure that information ultimately permeates the entire network. Furthermore, the node's own timestamp and version number are carried throughout the transmission process, facilitating information integration and synchronization among other nodes.

[0064] When a node receives broadcast data, it calibrates the timestamp based on the local clock synchronization module and updates the local state data. However, in complex network environments, network delays or node failures may occur, causing update failures. At this point, the exponential backoff algorithm comes into play. As shown in formula (2), the retry interval increases exponentially with each retry. This is to avoid the waste of network resources and interference with the system caused by continuous frequent retries when network congestion or node failures have not been recovered. This adaptive retry mechanism dynamically adjusts the retry interval according to the number of retries, which can effectively reduce system load and increase the probability of successful retries.

[0065] In actual implementation, Figure 2 As shown, step S1 operates as follows: First, when preparing to update the seal status, each sealing node synchronizes its own clock using the NTP protocol and generates a unique identifier based on the current seal status version number. When a status update request is initiated, this unique identifier, along with the update information, is sent to the smart contract for verification. The smart contract strictly follows the verification process described above, extracting the timestamp and version number from the request, comparing the version number with the latest version stored on the blockchain, calculating the timestamp difference, and applying a priority policy to filter requests. If the request passes verification, it is deemed valid and the corresponding data is written to the blockchain through the smart contract. Subsequently, the gossip protocol is used to disseminate the update information to other nodes in a distributed, self-organizing manner. Upon receiving the information, other nodes first use their local clock synchronization module to calibrate the timestamp and then update their local status information. If an anomaly occurs during the update process, such as network congestion or a node failure, the node will retry using an exponential backoff algorithm, adjusting the retry interval and retry strategy based on the retry results.

[0066] For example, in a logistics scenario, different transport vehicles act as nodes to update the seal status of cargo. After completing loading and unloading operations, the equipment on the vehicle initiates a seal status update request. These requests are processed within the blockchain network according to the process described in step S1 above, from timestamp and version number generation, smart contract verification, to final information broadcast and node update, forming a closed-loop, orderly information update chain. Furthermore, thanks to the use of distributed clock synchronization and the gossip protocol, information synchronization and timely updates are guaranteed even when vehicles are in different network environments.

[0067] Compared with existing technologies, the distributed clock synchronization algorithm of the present invention effectively avoids data conflicts caused by node time deviation through a multi-layer verification mechanism and dynamic priority strategy, significantly improving the real-time and consistency of seal status data updates. The introduction of the Gossip protocol solves the single-point bottleneck problem existing in traditional data broadcast mechanisms, achieving efficient and robust data synchronization. At the same time, the exponential backoff algorithm adaptively adjusts network load, enhancing the system's fault tolerance and stability in complex network environments. The integration of these innovative technologies ensures the reliability of seal status data and the efficiency of the overall system operation, significantly improving the security, stability, and real-time responsiveness of the electronic seal data management system.

[0068] In implementation, the distributed clock synchronization algorithm's system support hardware includes high-precision time synchronization servers, blockchain node servers, distributed storage devices, network switches, and routers. The time synchronization servers use GPS or atomic clocks as their time source, ensuring the high-precision operation of the NTP protocol. Node servers are geographically distributed to ensure system decentralization and high availability.

[0069] To verify the performance of the distributed clock synchronization algorithm, two sets of hardware environments with identical configurations were selected for comparative experiments. Group A used the distributed clock synchronization algorithm, while Group B used the traditional NTP time synchronization method. Both sets of experiments were run under the same network conditions, with five runs conducted in each set to test parameters such as state update latency, data consistency, network congestion recovery efficiency, and system throughput. The data records are shown in Table 1:

[0070] Table 1 Algorithm comparison experiment record

[0071]

[0072] Experimental results show that Group A, using the distributed clock synchronization algorithm, significantly outperformed Group B, using the traditional NTP synchronization method, in terms of state update latency, data consistency, network congestion recovery efficiency, and system throughput. Group A achieved a reduction of approximately 45% in average state update latency, an improvement of approximately 3.5% in data consistency, a reduction of over 60% in network congestion recovery time, and a growth of approximately 67% in system throughput. This demonstrates that the distributed clock synchronization algorithm can effectively improve the system's real-time performance, reliability, and high-concurrency processing capabilities in complex network environments.

[0073] In step S2 of the above embodiment, the distributed key generation algorithm splits the private key required for signing into multiple private key shards and distributes these shards to different nodes. Specifically, the distributed key generation algorithm utilizes secret sharing technology to break the private key into multiple parts based on a pre-set threshold and the number of nodes in the system. This makes it impossible to recover the complete private key from any set of nodes with fewer than the threshold number. This ensures that the private key remains secure even if some nodes are attacked or fail.

[0074] When the state of the electronic seal changes, the data involved in the state change request includes information such as the seal ID, target state value, timestamp, and node signature. Each node uses its private key fragment to partially sign the request data. The partial signature is completed on each node based on the elliptic curve digital signature algorithm (ECDSA). These partial signatures will be sent to the aggregation node, which uses the Lagrange interpolation formula to aggregate the signatures. The Lagrange basis polynomial in formula (3) plays a key role. It can calculate the complete signature based on the node's private key fragment and the corresponding node identifier. This aggregate signature method ensures that the validity of the signature depends on the collaboration of multiple nodes. At the same time, only when a threshold number of nodes participate in the signature can the complete signature be successfully reconstructed, which enhances the system's fault tolerance and anti-attack capabilities. The essence of the Lagrange interpolation formula is to use the properties of the polynomial to restore the complete information based on the partial information of multiple nodes. In this case, it is to restore the complete signature information to prevent the validity of the signature from being affected by abnormal or malicious behavior of some nodes.

[0075] The Elliptic Curve Digital Signature Algorithm (ECDSA) is a digital signature algorithm based on elliptic curve cryptography, leveraging the mathematical properties of elliptic curves for signing and verification operations. To verify the validity of a signature, the recipient (typically an aggregator) possesses the public key, message, and signature. The recipient calculates the hash value of the message and verifies the signature using the elliptic curve's operational rules and the public key. This involves complex point arithmetic and scalar multiplication operations performed over a finite field, and its security is based on the difficulty of the elliptic curve discrete logarithm problem. For state change requests, the aggregator verifies through ECDSA that the signature originates from a legitimate private key based on the received signature information, ensuring the authenticity and integrity of the signature and preventing data tampering and forgery.

[0076] In the actual implementation of step S2, when the status of an electronic seal changes, a state change request is triggered. This request contains detailed information such as the seal ID, target state value, timestamp, and node signature. First, a distributed key generation algorithm generates private key shards for participating nodes. These nodes use ECDSA to partially sign the request data based on their own private key shards. These partial signatures are sent to the aggregator node, which then calculates the full signature using the Lagrange interpolation formula. The aggregator node verifies the validity of the full signature according to ECDSA rules. This process requires hashing the request data and combining public key and elliptic curve operations for precise verification. If the verification succeeds, the system generates a state update transaction to update the state of the electronic seal. If the verification fails, the request is rejected and an exception logging mechanism is triggered. The exception information is stored in the blockchain log for subsequent analysis and processing. For example, in a logistics transportation scenario, different transportation nodes may update the open or closed state of an electronic seal. These nodes will participate in the entire process as signing nodes, and the partial signatures they generate jointly ensure the legitimacy and security of the state change.

[0077] Compared with the traditional single-node signature verification mechanism, this invention significantly improves the security and fault tolerance of the system through an improved Byzantine fault-tolerant algorithm and multi-node threshold signature technology. Traditional methods may cause system crashes or data tampering when nodes are attacked or fail. However, this invention adopts a multi-node joint verification mechanism to ensure system stability and data consistency even if some nodes fail or maliciously tamper with data. Through distributed key generation and aggregate signature mechanisms, key management risks are effectively reduced and single points of failure are avoided. In addition, the introduction of the Lagrange interpolation formula improves the efficiency of signature aggregation, reduces network communication overhead, and makes the state update process more efficient.

[0078] During implementation, experiments were designed to evaluate the performance advantages of the improved Byzantine fault-tolerant algorithm. The hardware environment of the improved Byzantine fault-tolerant algorithm in actual work includes: blockchain node servers, network equipment, time synchronization equipment, security modules and data storage equipment: used to store blockchain data and transaction logs.

[0079] The experiment selected 10 blockchain node servers, divided into Group A (applying the improved Byzantine fault tolerance algorithm) and Group B (using the traditional Byzantine fault tolerance algorithm). The traditional Byzantine fault tolerance algorithm is based on a simple majority voting mechanism, with low fault tolerance and high communication overhead. The two groups of experiments were conducted under the same hardware environment and network conditions, with each group conducting five experiments. During the experiment, the seal status change request was simulated, and the following parameters were recorded: signature verification time, status update delay, fault tolerance (number of malicious nodes tolerated), data consistency error rate, and system throughput. The experimental results of Group A and Group B are compared as shown in Table 2:

[0080] Table 2 Experimental record of improved Byzantine fault-tolerant algorithm

[0081]

[0082] Experimental results show that Group A's signature verification time averages 20ms, significantly lower than Group B's 80ms; Group A's state update latency averages 60ms, lower than Group B's 150ms; Group A can tolerate three malicious nodes, while Group B can only tolerate one; Group A's data consistency error rate is only 0.1%-0.2%, while Group B's is around 5%; and Group A's system throughput is significantly higher than Group B. Therefore, the improved Byzantine fault-tolerant algorithm has significant advantages in improving the efficiency, fault tolerance, and consistency of electronic seal data management.

[0083] In step S3 of the above embodiment, the first phase (pre-submission phase): the Hash Time Lock Contract (HTLC) is a smart contract mechanism based on hash functions and time locks. When encrypting and locking a sealed resource, a hash function is first used to hash the key information of the sealed resource to generate a unique hash value. This hash value serves as the lock identifier, and only by providing a matching pre-image can the resource be unlocked. At the same time, combined with the time lock, if the unlocking conditions are not met within a predetermined time, the locked resource will remain locked or trigger a corresponding rollback operation. Its essence is to utilize the unidirectional nature of the hash function and the time limit characteristics of the time lock to ensure the exclusivity and security of the resource within the predetermined time.

[0084] Multi-party secure computation (MPC) allows nodes to encrypt and aggregate voting results without revealing their own voting information. Based on complex cryptographic algorithms, it enables nodes to perform calculations on voting information in an encrypted space, such as summation and averaging. Its core is to utilize technologies such as homomorphic encryption or secret sharing to encrypt voting information and then perform calculations in an encrypted domain, ensuring the correctness of the results while ensuring that the privacy of each node is not leaked. For example, when using homomorphic encryption, after encrypting the voting value, operations such as addition or multiplication can be performed directly on the ciphertext. The decrypted result is equivalent to the result of the corresponding operation on the plaintext, ensuring the privacy and security of the node voting process.

[0085] Phase 2 (Formal Commitment): An improved cross-node consensus voting mechanism is key to ensuring transaction consistency in a multi-node environment. It collects and evaluates voting information from different nodes and employs more complex voting weight allocation and voting strategies. For example, each node is assigned a different weight based on factors such as reputation, computing resources, and historical voting accuracy, giving votes from highly reputable nodes greater influence. At the same time, it employs optimization strategies for distributed consensus algorithms, such as variants of the Byzantine Fault Tolerance algorithm. While ensuring a certain number of nodes reach consensus, it reduces the impact of partial node failures or malicious behavior on consistency. This approach makes transaction execution decisions more scientific and reasonable, and improves the system's adaptability to complex network environments and node behaviors.

[0086] A Merkle tree is a binary tree structure in which each non-leaf node is the hash value of its two child nodes. During transaction processing, key transaction information is stored in the leaf nodes of the Merkle tree. When a rollback is required, the corresponding transaction information can be quickly located based on the Merkle root hash and storage path stored on the blockchain. Due to the characteristics of the Merkle tree, only the root hash and a portion of the storage path need to be stored to verify the integrity of the information and quickly restore it to its original state. This advantage lies in its efficient verification of data integrity and rapid data recovery. By calculating the hash value of the nodes along the storage path and comparing it with the root hash, it is possible to quickly determine whether the information has been tampered with and quickly restore the original state based on the storage path, reducing the time and computation required for data recovery.

[0087] When implementing step S3, Figure 3As shown, first, when a seal status change requires a transaction, the system enters an asynchronous two-phase commit transaction process. During the pre-commit phase, the smart contract invokes a hash timelock contract to encrypt and lock the seal status resource. Key information about the sealed resource is hashed and combined with the timelock to ensure resource security during subsequent operations. Simultaneously, a globally unique transaction identifier (GTI) is generated, consisting of a timestamp, node information, and a random number. During this process, each node votes based on its own judgment. Voting information is encrypted and aggregated using multi-party secure computation technology to ensure privacy and security. The encrypted and aggregated voting results then undergo multi-node consistency verification. If verification passes, the transaction enters the final commit phase. An improved cross-node consensus voting mechanism determines the final transaction execution decision based on comprehensive node factors, and the state update is executed based on the decision. Any anomalies during the pre-commit or final commit phases, such as network fluctuations, node failures, or voting anomalies, immediately trigger a Merkle tree-based transaction rollback mechanism. Based on the storage path of the Merkle tree, the system can quickly locate the initial information of the transaction, verify the integrity by calculating the hash value, and then restore the state to the initial state. At the same time, it records the abnormal information and rollback operations in the blockchain log for subsequent analysis and auditing.

[0088] For example, in a complex logistics supply chain, multiple nodes may manipulate the opening or closing status of an electronic seal. This mechanism ensures consistency and security throughout the entire process during state changes. Different logistics nodes can vote securely without leaking voting information. Furthermore, even if an unexpected event occurs during the voting process, the system can quickly restore to its previous state, preventing errors in state changes from impacting the entire supply chain.

[0089] Compared to existing technologies, step S3 ensures the atomicity of state changes through an asynchronous two-phase commit transaction mechanism, preventing situations where some nodes successfully update while others fail. Furthermore, a hash timelock contract and an improved cross-node consistency voting mechanism ensure the consistency of multi-node data, preventing data conflicts and inconsistencies. Secondly, multi-party secure computation and threshold signature technology ensure the security of the voting process and transaction execution, preventing malicious nodes from tampering with or leaking data. Furthermore, a Merkle tree-based transaction rollback mechanism can quickly locate abnormal data and restore it to its initial state, improving the system's fault tolerance and reliability. Finally, real-time updates to the blockchain log ensure the traceability and auditability of data changes, facilitating problem investigation and accountability.

[0090] In step S4 of the above embodiment, the finite state machine abstracts the different states of the seal into different state nodes, with transitions between states triggered by predefined events or conditions. For example, an electronic seal may have states such as "unused," "used," "locked," "opened," and "damaged." Transitions between these states are triggered by operations during the cargo transportation process (such as loading, transportation commencement, arrival at the destination, seal opening, etc.). Based on a behavioral anomaly detection algorithm, the finite state machine performs feature extraction and pattern matching on the state change sequence when the seal transitions between states. Specifically, it observes the sequence of state transitions, time intervals, triggering conditions, and other features. By analyzing these features, it detects whether they conform to normal business logic. The behavioral anomaly detection algorithm utilizes machine learning or statistical analysis methods, such as by constructing a library of normal state transition patterns and using distance metrics (such as Euclidean distance or cosine similarity) to compare the current state transition sequence with the normal pattern. If the sequence exceeds a certain threshold, it is considered to be an anomaly.

[0091] For each seal update operation, the preceding transaction and the following transaction will be recorded in the distributed log storage system. The preceding transaction status contains the seal information before the status update, including timestamp, seal position, current status, etc., while the following transaction status is the new information that may be brought by the update operation. This information is stored in a structured manner in the distributed log storage system, which can use a distributed file system (such as IPFS) or a distributed database. The distributed storage system uses data redundancy and distributed hash tables (DHT) to ensure high availability and consistency of data. With distributed storage, even if some nodes fail, the log data will not be lost. During the storage process, a unique identifier is assigned to each transaction log. For example, a hash function is used to perform a hash operation on the transaction information to obtain an identifier to facilitate subsequent retrieval and backtracking operations.

[0092] The state rollback function is based on the log replay method and is essentially a reverse operation mechanism. When a state transfer fails, the seal's state is restored to its initial state before the update based on the previous transaction state information in the transaction log. It ensures the accuracy and consistency of state restoration by replaying the transaction log records one by one. During this process, the seal's various attributes (such as state, position, and timestamp) are restored to their previous states based on the previous transaction state information stored in the log. Its implementation relies on the integrity and accuracy of the log records, gradually restoring the seal's state by performing the inverse of the state update operations recorded in the log. For example, if the previous state update operation updated the seal from "locked" to "opened," the rollback operation will reset it to "locked" and restore the previous position and timestamp information based on the relevant information stored in the log.

[0093] When the state transfer succeeds, the post-transaction state is written to the blockchain, and the integrity of the state data is verified using a Merkle tree structure. A Merkle tree is a binary tree structure in which each non-leaf node is the hash value of its two child nodes, and leaf nodes store the hash value of the data block. When storing the post-transaction state, the state data is hashed to form leaf nodes. The hash values ​​are then calculated layer by layer to construct the Merkle tree. To verify the integrity of the state data, only the root hash needs to be stored. By calculating the hash path from the leaf nodes to the root node and comparing it with the stored root hash, it is possible to quickly determine whether the data has been tampered with.

[0094] During the actual implementation of step S4, when the electronic seal status needs to be updated, the finite state machine comes into play. It continuously monitors each step of the state transition, starting from the initial trigger of the state change, and monitors the state change sequence according to predefined state transition rules and events. During this process, a behavioral anomaly detection algorithm extracts and pattern-matches various state transition features to determine whether any anomalies exist. Simultaneously, the preceding and subsequent transaction states of each state update operation are recorded in detail in a distributed log storage system to ensure that every operation is traceable. If an anomaly is detected during the state transition, such as a state transition that does not conform to normal business logic or a timeout caused by network latency, the anomaly information is recorded. If the state transition fails, the state rollback function is called based on the preceding transaction state in the transaction log. Using the log replay method, the seal state is restored to its initial state before the update according to the transaction log records. If the state transition succeeds, the subsequent transaction state data is stored in the blockchain and verified for integrity using a Merkle tree structure. The integrity of the data is ensured during storage and transmission by calculating and comparing hash values.

[0095] In step S5 of the above embodiment, homomorphic encryption allows specific operations to be performed on ciphertext without decrypting the data, while maintaining the confidentiality of the encrypted data. Its principles are based on complex number theory and algebraic structures, such as operations based on certain groups or rings. For sealed data, homomorphic encryption functions are used to map the plaintext data into a ciphertext space during encryption. When storing and processing the encrypted data, operations such as statistical analysis or status updates can be performed directly on the ciphertext without leaking the original data.

[0096] Distributed hash tables (DHTs) are a key technology for storing encrypted data shards in a multi-node environment. They map data to different nodes based on hash functions to achieve distributed storage. Specifically, for each encrypted data shard, a hash value is calculated using a hash function and mapped to the corresponding storage node. DHTs are also self-organizing and scalable. When new nodes join or old nodes leave, they automatically adjust data storage locations, redistributing data to appropriate nodes by updating the hash map, ensuring balanced data storage and system stability.

[0097] Before each data shard is stored, a unique hash value is generated. This is calculated using a hash function. The one-way and unique nature of the hash function ensures that each data shard's hash value uniquely identifies that shard. Furthermore, the hash value calculation takes data integrity into account; even minor changes to the data will result in a significantly different hash value. These data hash values ​​are uploaded to the blockchain in real time via smart contracts, leveraging the blockchain's immutable nature to ensure data traceability and consistency. Smart contracts are responsible for storing and managing these hash values. By storing them in a specific location on the blockchain, a reliable audit trail is formed, making any data tampering easily detectable by comparing the on-chain hash value with the off-chain hash value.

[0098] When actually implementing step S5, in an actual electronic seal data management system, such as a cross-regional logistics and transportation network, different seal status data (such as the seal opening time, location, temperature, and other information) will be encrypted after updating and then stored in multiple distributed nodes. These nodes may be distributed in different geographical locations and are responsible for storing different data shards. At the same time, the stored data hash values ​​will be recorded on the blockchain, forming a verifiable data chain. If a node encounters a storage problem, the system will automatically transfer the data to other nodes to ensure the integrity of data storage and the stability of the system.

[0099] Compared to existing technologies, homomorphic encryption algorithms ensure data privacy even when stored across multiple nodes, minimizing the risk of data leakage during storage. This offers higher security than traditional encryption methods. Furthermore, using distributed distributed list storage, data is distributed across multiple nodes, improving both storage efficiency and fault tolerance. If a node fails, an iterative update mechanism ensures data is not lost and automatically recovers to a stable node. Furthermore, by synchronizing data hash values ​​to the blockchain in real time, any tampering with the data will result in a hash change, allowing detection and correction. The further use of smart contracts ensures the automation and transparency of the data synchronization process, eliminating the risk of human intervention. Furthermore, a redundancy check mechanism ensures that the system automatically redistributes data in the event of a data backup failure, reducing manual intervention and improving system reliability and high availability.

[0100] In step S6 of the above embodiment, the control flow graph describes the execution order and possible branch paths of the program, showing the execution order between functions and basic blocks; the data flow graph shows the data dependencies between variables. These elements are abstracted into nodes and edges of the graph to form a graph data structure.

[0101] The graph attention network is used to extract features from the constructed graph data structure. In formula (4), the node embedding formula updates the node embedding vector through multiple iterations. At each layer, the node features are first linearly transformed through the weight matrix, the bias vector adjusts the feature offset, and the activation function introduces nonlinear factors to enhance the expressiveness of the model. Importantly, the attention coefficient between nodes is calculated through the attention mechanism, which dynamically assigns the importance weights between nodes based on the node's neighbor set, enabling the network to focus on more important parts of the graph structure. The graph attention network can selectively aggregate information based on the relationship and semantic importance between different parts of the code, capture the complex relationship between code structure and semantics, and extract deep-level features of the code.

[0102] In static symbolic execution analysis, the path constraint solver Z3 is used to generate a set of symbolic execution paths. Z3 symbolizes the variables in the code, constructs constraints based on the program's logical conditions and operations, and solves these constraints to obtain different execution paths. For each possible branch and conditional judgment, Z3 converts it into mathematical constraints and solves these constraints to find the possible execution paths of the program. This makes it possible to analyze the execution behavior of the code under different input conditions without actually running the code, explore various possible execution paths, and detect potential vulnerabilities.

[0103] In dynamic fuzz testing, an adaptive fuzzing algorithm dynamically adjusts the test case generation strategy based on the code's characteristics and feedback from previous tests to find more inputs that are likely to trigger vulnerabilities. Rather than simply generating random inputs, it specifically generates more challenging inputs based on the code's structure and previous test results, increasing the likelihood of discovering vulnerabilities. The symbolic execution paths obtained by static symbolic execution are dynamically combined with fuzz test cases to achieve collaborative optimization. This approach leverages the path information from symbolic execution to guide fuzz testing, making it more effective. Furthermore, the actual execution results of fuzz testing complement paths that symbolic execution may have missed. The two complement each other and together uncover more security vulnerabilities, especially complex vulnerabilities such as reentrancy attacks and integer overflows, which can be hidden under specific code execution conditions and input combinations. This collaborative approach can better uncover these vulnerabilities.

[0104] When a vulnerability is detected, a multi-dimensional vulnerability report is generated based on the vulnerability's feature vector. These feature vectors contain various information about the vulnerability, such as the vulnerability type (such as permission issue, data overflow, etc.), the scope of impact (the affected code area and data range), and the triggering conditions (under what input or execution conditions the vulnerability is triggered).

[0105] In practice, the hardware environment of the automated code audit algorithm based on graph neural networks in actual work includes: GPU servers, blockchain node servers, network equipment, storage devices and security modules; 10 blockchain node servers were selected, and the same hardware equipment was used for experiments in Group A (using the automated code audit algorithm based on graph neural networks) and Group B (based on static code analysis tools such as Slither) to evaluate the performance advantages of the automated code audit algorithm based on graph neural networks. The two groups of experiments were conducted under the same hardware environment and network conditions, and each group conducted five experiments. During the experiment, the smart contract code audit task was simulated and the following parameters were recorded: vulnerability detection accuracy, code coverage, audit time, false alarm rate and system resource usage. The experimental data record table is shown in Table 3:

[0106] Table 3 Experimental record of automated code audit algorithm based on graph neural network

[0107]

[0108] Experimental results show that Group A's vulnerability detection accuracy averaged 98.5%, significantly higher than Group B's 85.0%. Group A's code coverage averaged 95.0%, higher than Group B's 80.0%. Group A's audit time averaged 120 seconds, significantly lower than Group B's 300 seconds. Group A's false positive rate was only 1.0%, compared to Group B's 10.0%. Group A also had significantly lower system resource utilization than Group B. Therefore, automated code auditing algorithms based on graph neural networks offer significant advantages in improving the efficiency, accuracy, and resource utilization of smart contract code audits.

[0109] In step S7 of the above embodiment, the proxy contract acts as the entry point to the business logic in the architecture, and its core principle is to store the address pointing to the logic contract. This mechanism is similar to a pointer, which directs user requests to the corresponding logic contract for execution by storing the address of the logic contract. It is implemented through a delegate call. When the user request reaches the proxy contract, the proxy contract forwards the request to the logic contract based on the stored logic contract address. The advantage of a delegate call is that it allows the function of another contract to be called without changing the storage and execution environment of the proxy contract, while maintaining the caller's context. For example, when a user initiates an operation request to update the status of an electronic seal, the proxy contract will delegate the request to the stored logic contract address to execute the business logic. This model realizes the separation of the business layer and the storage layer, so that the update of the business logic will not affect the data storage, thereby improving the flexibility and maintainability of the system.

[0110] At the storage layer, the data storage contract is specifically responsible for reading and writing state variables. State variables are data that stores system status, such as the seal's status (open, closed, etc.), location, timestamp, and other information. The logic contract only accesses the storage contract through interface calls, decoupling business logic from data storage. This means that the logic contract does not directly operate on the data storage, but instead retrieves or modifies data by calling the storage contract's interface. This clearly separates the responsibilities of business logic and data storage, reducing the coupling between the two. For example, when the logic contract needs to query the current status of the seal, it calls the storage contract's query interface. The storage contract is responsible for retrieving the corresponding data from the storage and returning it to the logic contract. This separation helps improve the modularity and scalability of the system.

[0111] When business logic is updated, a hot update mechanism is implemented through the proxy contract's management interface. The key is to update the address of the logic contract to the address of the new contract version, thereby switching the business logic to the new implementation without stopping the entire system or redeploying the entire contract system. This mechanism leverages the interchangeability of smart contracts on the blockchain, enabling seamless switching of business logic by modifying the logic contract address stored in the proxy contract. The process is similar to updating a dynamic link library in a software system. When a new business logic version needs to be released, the logic contract address stored in the proxy contract only needs to be updated to the new contract address, without redeploying the storage contract or affecting the stored data.

[0112] When business logic needs to be updated, the hot update mechanism is used to update the logical contract address through the proxy contract's management interface. For example, a developer develops a new logical contract version to improve the rules for updating the seal status or add new business functionality. This version is deployed on the blockchain, and the new contract address is updated to the current logical contract address through the proxy contract's management interface. Simultaneously, a version control mechanism is used to record the new contract address and corresponding version number. During the update process, the success of the update is continuously monitored. If any problems occur, such as anomalies or malfunctions during execution of the new logical contract, the logical contract address in the proxy contract is restored to the previous version based on the stored address of the previous version to ensure continued stable operation of the system.

[0113] In a real-world electronic seal data management system, such as one used in logistics and transportation, the seal management logic might need to be updated based on different business needs, such as adjusting the seal opening and closing rules based on different transportation routes or cargo types. This proxy contract model and hot update mechanism allows for flexible updates to business logic without impacting existing data storage or system operations.

[0114] Compared with existing technologies, the proxy contract model and hot update mechanism enable hot updates of business logic without modifying the proxy contract, significantly improving the system's flexibility and maintainability. The state variable separation method and access control mechanism ensure that updates to business logic do not affect data storage, preventing data leakage and tampering. The version control mechanism and rollback mechanism ensure that hot update failures can be quickly restored to the previous version, improving system stability and continuity. Delegated calls and interface calls reduce the coupling between business logic and data storage, improving system processing efficiency. The proxy contract model and state variable separation method support modular design and expansion of the system to adapt to different business needs.

[0115] In step S8 of the above embodiment, a light node is a node that only stores partial blockchain information (such as block headers) rather than the complete blockchain data. In step S8, the light node is used to synchronize the main chain block header data using the Merkle Patricia Tree (MPT). MPT is a hash tree-based data structure that stores data in a tree-like structure, with each node containing the hash value of a data block and leaf nodes storing key-value pairs for the data. Leveraging the characteristics of MPT, light nodes only need to store a small amount of block header information. By verifying the block header hash value and Merkle path, they can verify whether a transaction is included in a block. During the synchronization process, the light node requests and stores the latest main chain block header and verifies its validity by verifying the Merkle path and hash value. For example, when verifying the inclusion of a sealed status update transaction in a block, the light node can quickly verify the existence and validity of the transaction by requesting the corresponding Merkle path and hash value from the full node, while reducing storage and computational overhead. This approach enables light nodes to participate in the blockchain network at a lower resource cost and provide basic data for subsequent data monitoring.

[0116] The cross-chain data consistency verification protocol aims to ensure the consistency of mainchain data and cross-chain replica data. Mainchain and cross-chain replica data (stored on sidechains or distributed storage systems) are verified for consistency using hash values. Its core approach is to leverage the unidirectionality and uniqueness of hash functions to perform hash operations on the mainchain and cross-chain data to generate their respective hash values. For the seal status update transaction and related status data on the mainchain, as well as the cross-chain replica data stored on the sidechain or distributed storage system, hash values ​​are calculated separately. Data consistency is determined by comparing these two hash values ​​to determine if they are equal. Due to the characteristics of hash functions, even minor changes in data can result in significantly different hash values, enabling accurate data consistency detection. For example, when storing the same seal status information across different chains, using the same hash algorithm (such as SHA-256) to calculate their hash values, any update to the mainchain data will result in a change in the hash value. The cross-chain data consistency verification protocol can quickly detect this change, ensuring data consistency and integrity across different chains.

[0117] The state machine model defines the legal transition rules for seal states, dividing them into different states, such as "Initial," "Updated," and "Completed." The state machine specifies the legal transition conditions and sequence between states. For example, transitioning from "Initial" to "Updated" may require certain preconditions (such as an action triggering the start of shipping), while transitioning from "Updated" to "Completed" also requires corresponding business operations or time conditions. The state machine verifies the legality of seal states, essentially determining whether the current state transition meets expectations based on pre-defined rules and conditions. Timestamps are checked based on a pre-defined timeframe. If the timestamp of a status update falls outside of that range, the state is considered expired. This comparison of timestamps and pre-defined rules ensures that seal status updates occur within a reasonable timeframe, preventing status anomalies caused by delays or erroneous operations. For example, if a seal status update's timestamp appears several months ago, but the system assumes the operation should have been completed within the past few days, the state machine will determine the state as expired.

[0118] When data anomalies are detected, a state machine-based repair strategy is adopted. Through the log playback method, the transaction log is used as the basis for repair. The log records detailed information about the seal status update, including the time of the operation, the status before and after the operation, etc. When an illegal state, expired state, or inconsistent state occurs, the seal status is restored to a legal state based on the log playback. For example, if a seal jumps directly from the "initial state" to the "completed state" due to some anomaly, this does not comply with the legal transition rules of the state machine. The system will find the previous legal state, such as the "updated state", based on the log playback, and resubmit the status update request to restore the state to the "updated state". Then, based on the business logic and state machine rules, it will try to gradually advance the state to the correct state to ensure the legality and consistency of the seal status.

[0119] In a practical application scenario of electronic seal data management, such as a complex supply chain system involving multiple logistics participants, different participants may operate the seal status on different chains. This mechanism can ensure the consistency of the main chain and cross-chain data and the validity of the seal status. When a logistics node updates the seal status on the side chain, the main chain ensures the consistency of the update across different chains through light node synchronization and cross-chain data consistency verification protocol. At the same time, its legitimacy is checked through the state machine model to avoid status errors caused by various abnormal situations.

[0120] Step S8 demonstrates unique advantages in blockchain-based electronic seal data management methods through innovative technologies such as light node MPT synchronization, cross-chain data consistency verification protocols, state machine models, and state machine-based repair strategies. During implementation, a complete process was formed from data monitoring, status checking, to data repair. Compared with existing technologies, this process significantly improves resource utilization, data consistency, refined status checking, and automated data repair, providing stronger guarantees for the stable operation of the electronic seal data management system and data reliability.

[0121] Although specific embodiments of the present invention have been described above, those skilled in the art will appreciate that these specific embodiments are merely illustrative, and that those skilled in the art may omit, substitute, and modify the details of the methods and systems described above without departing from the principles and spirit of the present invention. For example, combining the above method steps to perform substantially the same functions in substantially the same manner to achieve substantially the same results falls within the scope of the present invention. Accordingly, the scope of the present invention is limited solely by the appended claims.

Claims

1. A blockchain-based electronic seal data management method, characterized by: The following steps are involved: Step S1: Generate a unique identifier for each seal status update based on the timestamp and version number, and manage the status updates of each seal node through a distributed clock synchronization algorithm; the distributed clock synchronization algorithm verifies the timestamp and version number of each status update through a smart contract, and automatically rejects the status update request if the version number of the current node does not match the latest version; Step S2: When the status of the electronic seal changes, the state change request is verified by multi-node threshold signature using the improved Byzantine fault-tolerant algorithm. If the verification passes, a state update transaction is generated. If the verification fails, the request is rejected and the exception recording mechanism is triggered. Step S3: Before the state is changed, an asynchronous two-phase commit transaction mechanism is used. In the pre-commit phase, a smart contract is used to lock the sealed state resource and generate a globally unique transaction identifier. If the multi-node consistency verification passes, the formal commit phase is entered and the state update is executed. If an anomaly is detected, the transaction rollback mechanism is immediately triggered to restore the initial state. Step S4: Each time the seal status is updated, the finite state machine is used to detect abnormal conditions, including but not limited to contract logic defects and network delays. The transaction log records the preceding and subsequent transactions of each seal update operation, and automatically restores the preceding transaction status in the event of a transaction failure. Step S5: After the status update is completed, the updated seal status data is encrypted and backed up through the distributed storage system based on blockchain, and the data hash value is synchronized to the chain in real time. If the off-chain data backup fails, the data storage is re-executed; Step S6: Before the smart contract is deployed, static symbolic execution analysis and dynamic fuzz testing are performed on the contract code using an automated code auditing algorithm based on a graph neural network. If a security vulnerability is detected, the deployment is blocked and a multi-dimensional vulnerability report is automatically generated. If the code is safe, the contract is allowed to go online safely. Step S7: Separate the business logic and data storage into the business layer and storage layer through the proxy contract model and access control mechanism. If the business logic needs to be updated, the proxy contract is used to complete the logic hot update; Step S8: The main chain data is monitored in real time through the off-chain audit mechanism and the cross-chain data consistency verification protocol to check the legality, timeliness and consistency of the seal status; if data anomalies are detected, the state machine-based repair strategy is automatically called to repair the data. If the data is consistent, the result record is updated and the process is completed.

2. The blockchain-based electronic seal data management method according to claim 1, characterized in that: In step S1, the working principle of the distributed clock synchronization algorithm is as follows: a unique identifier is generated based on the timestamp and version number, the timestamp of each node is calibrated by the distributed clock synchronization protocol NTP, and during the processing of the status update request, the timestamp T in the request is extracted by the smart contract. req and version number V req , based on the latest version number V on the chain latest Compare; if V req <V latest , then the rejection mechanism is triggered, the request is rejected and the log is recorded; if V req =V latest +1, then enter the timestamp verification phase; during the timestamp verification process, calculate the timestamp difference ΔT = T req -T latest If ΔT exceeds the preset threshold, the status update request with the latest timestamp is selected through the priority strategy, which calculates the priority score through formula (1): S=w1V req +w2(T req -T base ) (1) In formula (1), w1 and w2 are weight coefficients, T base The state update request with the highest score is selected as the valid request, and then the valid state update data is written into the blockchain through the smart contract, and the updated state data is broadcast to all nodes based on the Gossip protocol. After the node receives the broadcast data, it calibrates the timestamp based on the local clock synchronization module and updates the local state data. If network delay or node failure is detected, it will retry through the exponential backoff algorithm, and the retry interval is T. retyp The calculation formula is: T retyp =T base ×2 n-1 (2) In formula (2), T base is the initial retry interval; n is the number of retries.

3. The blockchain-based electronic seal data management method according to claim 1, characterized in that: The improved Byzantine fault-tolerant algorithm performs multi-node threshold signature verification on the state change request as follows: based on the electronic seal state change request data, including the seal ID, target state value, timestamp and node signature, a distributed key generation algorithm is used to generate the private key shard of each node i. i , and calculate the aggregate signature based on the Lagrange interpolation formula. The calculation formula is: In formula (3), L i (0) is the Lagrange basis polynomial, k is the threshold number of nodes; in the signature generation process, each node is based on the private key shard s i Partially sign the request data and transmit the partial signature to the aggregation node; The aggregation node reconstructs the complete signature S based on the Lagrange interpolation formula agg and verify the signature S based on the elliptic curve digital signature algorithm agg Effectiveness.

4. The blockchain-based electronic seal data management method according to claim 1, characterized in that: The asynchronous two-phase transaction mechanism includes a first commit phase and a second commit phase. In the first commit phase, the sealed state resources are encrypted and locked based on the hash time lock contract, and a globally unique transaction identifier is generated. Then, the node voting results are encrypted and aggregated using multi-party secure computing. If the multi-node consistency verification passes, the second submission phase begins, and the transaction execution is confirmed through the improved cross-node consistency voting mechanism; If an anomaly is detected, the transaction rollback mechanism based on the Merkle tree is triggered, and the initial state is quickly restored by tracing back the storage path, and the blockchain log is updated in real time.

5. The blockchain-based electronic seal data management method according to claim 1, characterized in that: The working method of step S4 is as follows: based on each seal status update operation, the state transition process is dynamically monitored by the finite state machine, and potential abnormalities are detected in real time, including contract logic defects, network delays and data synchronization inconsistencies; the finite state machine extracts features and performs pattern matching on the state change sequence based on the behavior anomaly detection algorithm; during the state transfer process, if an abnormality is detected, the previous transaction state S of each state update operation is pre and post-transaction status S post Recorded to the distributed log storage system; during the transaction execution process, if the state transfer fails, the previous transaction state S in the transaction log is used pre , restore the seal state to the initial state before the update through the state rollback function; The state rollback function is based on the log playback method, which ensures the accuracy and consistency of state recovery by playing back transaction log records one by one; If the state transfer is successful, the post-transaction state S post Write to the blockchain and verify the integrity of the state data based on the Merkle tree structure.

6. The blockchain-based electronic seal data management method according to claim 1, characterized in that: The working method of step S5 is as follows: first, the sealed data is encrypted using a homomorphic encryption algorithm; then, the encrypted data is sharded and stored in a multi-node environment using a distributed hash table, and a unique hash value is generated for each data shard, and the data hash value is uploaded to the chain in real time through a smart contract; if a node storage failure is detected during the off-chain data backup process, the redundancy check mechanism is automatically triggered, the data is reallocated to other stable nodes, and the storage operation is repeated.

7. The blockchain-based electronic seal data management method according to claim 1, characterized in that: The working method of the automated code audit algorithm based on graph neural network is as follows: U1. Based on the smart contract source code, the control flow graph and data flow graph of the code are extracted through static symbolic execution analysis, and a graph data structure G = (V, E, A) is constructed, where V represents the code basic block node, including functions and variables; E represents the control flow or data flow edge, and A represents the semantic association matrix between nodes; in the process of processing the graph structure data, the code is feature extracted through the graph attention network, which calculates the embedding vector h of each node through the node embedding formula v ; The node embedding formula is: In formula (4), represents the embedding vector of node v in the l+1 layer, which is used to capture the semantic features of the node; σ represents the activation function; W (l) represents the weight matrix of the lth layer, which is used to linearly transform node features; b (l) represents the bias vector of the lth layer, which is used to adjust the offset of the node feature; N(v) represents the neighbor set of node v, which is used to aggregate the local graph structure information; a vu represents the attention coefficient between node v and node u, which is used to dynamically allocate the importance weights between nodes; a represents the learnable parameter vector in the attention mechanism; U2, in the static symbolic execution analysis, the symbolic execution path set P = {p1, p2, ... p n }, and based on the path coverage formula Evaluate code coverage; where P covered represents the set of paths that have been covered by symbolic execution or dynamic fuzz testing; P total Represents the set of all theoretical execution paths in the code; in dynamic fuzz testing, the test case set T={t1,t2,...t m }, and optimize the test case generation strategy based on coverage feedback; Through the collaborative optimization mechanism, the symbolic execution path P is dynamically combined with the fuzz test case T to detect security vulnerabilities, including but not limited to reentrancy attacks and integer overflows; U3, if a vulnerability is detected, based on the vulnerability feature vector F v ={f1,f2,...f m Generate multidimensional vulnerability report R v , and calculate the vulnerability severity score using the vulnerability scoring formula; the vulnerability scoring formula is: In formula (5), S v Indicates the vulnerability severity score; w i Represents vulnerability feature f i The weight is used to adjust the influence of the feature on the score, where f i Indicates the specific characteristics of the vulnerability, including but not limited to vulnerability type, impact scope, and triggering conditions; R v represents the complexity of vulnerability repair; γ represents the weight coefficient of repair complexity, which is used to adjust the impact of repair complexity on the score; U4, if S v If S is lower than the preset threshold, the contract deployment is allowed; v If the value is higher than or equal to the preset threshold, the deployment is blocked and a repair code snippet is automatically generated through a template-based repair suggestion generation mechanism.

8. The blockchain-based electronic seal data management method according to claim 1, characterized in that: In step S7, the business layer uses the proxy contract as the entry point for the business logic and stores the address A pointing to the logic contract. logic , and forward the user request to the logic contract for execution through delegated call; When the business logic is updated, based on the hot update mechanism, the logical contract address A is updated through the management interface of the proxy contract logic The new version contract address A new In the storage layer, the business logic is decoupled from the data storage through a state variable separation method. The state variable separation method performs read and write operations on state variables through a data storage contract, and accesses the storage contract through an interface call through a logic contract. During the logic hot update process, the version number of the logic contract is recorded through a version control mechanism, and the upgrade history of the contract is managed based on the version number. If the hot update fails, the logical contract address will be restored to the previous version address.

9. The blockchain-based electronic seal data management method according to claim 1, characterized in that: The working principle of step S8 is: synchronize the main chain block header data based on the light node MPT, and extract the seal status update transaction T x and related status data S x During the data monitoring process, the main chain data and cross-chain replica data are compared through the cross-chain data consistency verification protocol. The cross-chain replica data is stored in the side chain or distributed storage system, and the consistency is verified by comparing the hash value with the main chain data hash value. If the hash value is inconsistent with the main chain data hash value, the data anomaly detection mechanism is triggered, and the legitimacy, timeliness and consistency of the seal status are checked through the state machine model. The state machine model defines the legal transition rules of the seal status, including "initial state", "updated state" and "completed state". If the state transition does not comply with the rules, it is judged as an illegal state. If the timestamp exceeds the preset validity range, it is determined to be expired; if the cross-chain data hash value is inconsistent, it is determined to be inconsistent; if data anomalies are detected, the state machine-based repair strategy is automatically called to replay the transaction log through the log replay method, restore the seal status to a legal state, and resubmit the status update request; If the data is consistent, the audit result record is updated and the result is written to the main chain to complete the process.

Images