Method and system for off-network data transmission and data consistency recovery of supply chain distributed ledger internet of things data

Abstract

The application provides a kind of supply chain distributed ledger Internet of Things data off-network continuation and data consistency recovery method and system, belongs to the field of blockchain and Internet of Things fusion technology, its method includes: constructing edge ledger and main ledger double-layer distributed architecture, when off-network, edge node enters off-network autonomous mode to continue to collect data and maintain local chain hash log chain, execute hierarchical cache and storage overflow protection;After network recovery, dynamic peak-shaving continuation and breakpoint continuation mechanism are used, bidirectional incremental synchronization is carried out based on transaction level version vector;The main node checks transaction batch, and conflict transaction is handled using smart contract arbitration mechanism;Ensure that all node data is consistent through global consistency checking mechanism based on lexicographic JSON serialization.It solves the problems of data loss, business stagnation, data inconsistency and retransmission storm caused by frequent network interruption in supply chain scenario, and ensures the data consistency of distributed ledger and the accuracy of supply chain traceability.

Description

Technical Field

[0001] This invention relates to the field of blockchain and Internet of Things (IoT) integration technology, and in particular to a method and system for resuming data transmission and restoring data consistency in a distributed ledger IoT system for supply chain. Background Technology

[0002] With the widespread application of blockchain technology in the supply chain sector, distributed ledger-based supply chain traceability systems can achieve tamper-proof and traceable data throughout the entire process of goods from production to consumption, effectively improving the transparency and credibility of the supply chain. However, IoT devices in supply chain scenarios are often deployed in areas with complex network environments, such as remote production bases, trucks in transit, and inside enclosed warehouses, where network outages occur frequently.

[0003] In existing technologies, some progress has been made in solutions for resuming data transmission after network outages in the Internet of Things (IoT). Some solutions employ local caching mechanisms to prevent data loss, and mainstream distributed ledger platforms such as Hyperledger Fabric support local endorsement and autonomous operation during network outages at edge nodes. Incremental synchronization technology based on Merkle trees has been widely used to improve data synchronization efficiency. However, existing technologies still face the following key challenges in specific scenarios where distributed ledgers and IoT are deeply integrated:

[0004] First, existing edge ledger solutions have limitations in their ability to govern themselves during network outages. Most solutions only support local data collection on a single node, lack a fine-grained management mechanism for the limited storage resources of edge devices, and do not differentiate between the storage priorities of critical and non-critical business data. Prolonged network outages can easily lead to the overwriting and loss of critical data. At the same time, existing neighbor node synchronization mechanisms do not clearly distinguish between network interruption types and are ineffective in scenarios where the entire region is without network access.

[0005] Secondly, the efficiency and accuracy of existing data consistency recovery mechanisms need to be improved. Although incremental synchronization technology is widely used, most solutions use node-level version vectors, which cannot track the causal relationship between individual transactions and are prone to causal inversion problems. Business dependencies are mostly statically preset and cannot adapt to dynamic business scenarios in the supply chain (such as emergency allocation and cross-level delivery), which can easily lead to misjudgment conflicts.

[0006] Furthermore, existing conflict resolution mechanisms have security vulnerabilities and fairness issues. Some solutions still employ a simple "last write wins" strategy, which relies on physical timestamps and is susceptible to clock asynchrony. Conflict resolution mechanisms based on node priority are mostly statically configured, lacking permission constraints and auditing mechanisms for high-priority nodes, thus posing a single point of malicious tampering risk.

[0007] Finally, existing solutions lack adaptability to large-scale scenarios. Most solutions do not adequately consider the retransmission storm problem after large-scale network recovery, and the simple exponential backoff mechanism cannot be dynamically adjusted according to the actual load of the master node; the termination condition setting of the global consistency verification mechanism is unreasonable, allowing some nodes to remain in an inconsistent state for a long time, affecting the overall accuracy of supply chain traceability.

[0008] Therefore, there is an urgent need for a supply chain distributed ledger IoT data processing method that can ensure the preservation of critical data in the event of a network outage, achieve eventual consistency of the ledger quickly after the network is restored, and efficiently and securely resolve transaction conflicts. Summary of the Invention

[0009] This invention provides a method and system for resuming data transmission and restoring data consistency in a distributed ledger IoT system for supply chain, which ensures business continuity and data integrity during network outages, enables rapid restoration of ledger consistency after network recovery, efficiently resolves transaction conflicts, and ensures data consistency and accuracy of supply chain traceability.

[0010] This invention provides a method for resuming data transmission and restoring data consistency in a supply chain distributed ledger IoT system after a network outage, comprising:

[0011] Step S1: Pre-build a two-layer distributed architecture specification of edge ledger and main ledger. Based on the architecture specification, deploy edge nodes in each supply chain participant to maintain the local edge ledger and deploy an odd number of master node clusters in the cloud to maintain the global main ledger. The edge nodes send link probe messages to the master nodes at a preset heartbeat period and monitor the response status. When the number of consecutive times no response messages are received exceeds a preset threshold, it is determined that the current link is in a network outage state, a network outage event signal is generated, and the edge node is triggered to enter the network outage autonomous mode.

[0012] Step S2: In the offline autonomous mode, the edge node continues to collect supply chain business data reported by IoT devices, generates operation log entries, packages the operation log entries into transaction batches according to a preset time window, stores them in the local edge ledger, and maintains the local chained hash log chain. At the same time, during the entire offline autonomous period, the occupancy rate of the local non-volatile storage medium is monitored in real time, and a hierarchical cache compression and storage overflow hierarchical protection strategy is implemented. Only when the edge node detects that the local area network communication with the adjacent nodes is normal, it synchronizes to at least two adjacent edge nodes before deleting key data, and continues to execute until the edge node detects that the network has been restored.

[0013] Step S3: When the edge node detects network recovery, it generates a random delay time according to the dynamic delay range notified by the master node to perform peak-shifting resume transmission. After the delay ends, it performs integrity verification on the local log chain. After the verification is successful, it reads the locally persisted breakpoint status information and sends a synchronization request to the master node. After the master node receives the synchronization request and verifies the legitimate identity of the edge node, it executes step S4.

[0014] Step S4: The master node compares the local master ledger with the transaction-level version vector reported by the edge nodes, calculates the bidirectional difference interval, and performs dynamic incremental synchronization with the edge nodes. During the synchronization process, the master node issues a resume license and performs traffic control based on its own load. After all bidirectional incremental synchronization is completed, the master node executes step S5 sequentially for all transaction batches uploaded by the edge nodes.

[0015] Step S5: After receiving each batch of transactions uploaded by the edge nodes, the master node verifies them. For transaction batches without conflicts, they are directly written into the main ledger. For transaction batches with conflicts, the smart contract arbitration mechanism is triggered and step S6 is executed.

[0016] Step S6: Automatically process conflicting transactions according to the smart contract arbitration mechanism, generate a conflict processing record containing the cause of the conflict, processing rules and processing results, and submit the conflict processing record and valid transaction records to the master node consensus network to reach consensus. After all conflicting transactions have been processed and the corresponding blocks have been written into the main ledger, proceed to step S7.

[0017] Step S7: After all the resumed data has been submitted to the chain, the master node starts the global consistency verification process, sends a state view summary request to all online edge nodes and temporary offline edge nodes, compares the on-chain state view with the local state view summary reported by each node on an entity-by-entity basis, generates a difference list and performs classification repair according to the difference type until the preset termination condition is met. At this time, the master node sends a business recovery notification to all edge nodes and the system resumes normal business processing.

[0018] Preferably, the operation log entry includes at least a globally unique sequence number, a data source device identifier, a data type encoding, a data payload, a local logical clock stamp, a local physical timestamp, a hash fingerprint of the previous log entry, a hash fingerprint of the current log entry, a transaction-level version vector, and a business dependency graph version number.

[0019] The hash fingerprint of each operation log entry is obtained by concatenating all fields of the entry except the current hash fingerprint and calculating the SHA-256 hash value, forming a chain of log entries with a chain hash structure.

[0020] Preferably, the transaction-level version vector is a key-value pair structure maintained by each edge node, where the key is the node's unique identifier and the transaction sequence number within the transaction batch, and the value is the logical clock stamp of the transaction. When an edge node downloads transaction batches from other nodes from the master node, the logical clock stamp of the corresponding transaction in the local version vector is automatically updated.

[0021] The synchronization request carries the latest local batch hash, transaction-level version vector, and persistent breakpoint status information.

[0022] The transaction-level version vector is the difference between the edge node's local version vector and the master node's global version vector during the last synchronization.

[0023] Preferably, the steps for persisting the breakpoint state include:

[0024] After each successful upload of a transaction batch and receipt of confirmation from the master node, the edge node uses a transactional write method to simultaneously write the sequence number of the last successfully uploaded batch, the list of confirmed transaction records, and the transaction-level version vector to two physically isolated non-volatile storage media.

[0025] After the edge node restarts, it first reads the breakpoint information of the main storage medium, verifies its integrity and authenticity, and then continues the transmission from the breakpoint.

[0026] If the primary storage medium fails to read, the breakpoint information of the backup storage medium is read.

[0027] If both storage media fail to read, the latest breakpoint information is obtained from the master node.

[0028] Preferably, based on the comparison between the local master ledger and the transaction-level version vectors reported by the edge nodes, the bidirectional difference interval is calculated, including:

[0029] The transaction-level version vector sent by the master node through the edge nodes is compared with the global version vector maintained by the master node.

[0030] If the master ledger sequence number is greater than the edge node sequence number, then the range of master ledger transaction batches that the edge node needs to download is determined to be: {edge node sequence number + 1, master ledger sequence number}.

[0031] If the edge node sequence number is greater than the main ledger sequence number, then the range of edge node transaction batches that the main node needs to receive is determined to be: {main node sequence number + 1, edge node sequence number}.

[0032] When the number of transaction batches contained in the difference interval exceeds the preset maximum batch threshold, the difference interval will be automatically divided into multiple sub-intervals for batch synchronization.

[0033] Preferably, the difference types include: on-chain missing type, local missing type, and value inconsistency type, wherein, for on-chain missing type differences, the master node requests the edge node to retransmit the missing entry;

[0034] For local missing differences, the master node pushes the confirmed entries on the chain to the corresponding edge nodes;

[0035] For discrepancies in values, the master node uses the on-chain consensus state value as the authoritative value to notify all edge nodes to uniformly correct and write it into the audit certificate. The audit certificate includes the discrepancy entity identifier, the original value, the corrected value, the correction timestamp, and the master node signature.

[0036] Preferably, in step S5, the verification includes: idempotency verification and transaction-level causal consistency pre-verification, wherein the idempotency verification includes:

[0037] Each transaction batch contains a globally unique batch ID embedded with the generated timestamp. The master node maintains a hash table of committed batch IDs, retaining records from the most recent N0 days.

[0038] After receiving a batch of transactions, the master node first extracts the generation timestamp from the batch ID. If the generation timestamp is within the last N0 days, it checks whether the batch ID already exists in the hash table. If it already exists, it returns success directly and does not repeat the process.

[0039] If the generated timestamp exceeds N0 days, directly query the main ledger to see if the batch ID exists. If it exists, return success directly and do not repeat the process.

[0040] At the same time, the hash table of submitted batch IDs is automatically cleaned up daily for records older than N0 days.

[0041] Among them, transaction-level causal consistency pre-verification includes:

[0042] The master node extracts the transaction-level version vector and the version number of the business dependency graph from the transaction batch;

[0043] Check if the version vector is continuous with the historical version vector of the corresponding node in the main ledger;

[0044] The master node recursively checks whether all direct and indirect dependencies of the transaction record already exist in the main ledger based on the dynamic business dependency graph of the specified version number in the transaction batch.

[0045] If both checks pass, the transaction is considered a conflict-free batch.

[0046] Otherwise, the transaction batch is judged to have a conflict.

[0047] Preferably, obtaining the state view summary includes:

[0048] For each supply chain entity, all key status variables are serialized into JSON in lexicographical order of field names, and then their SHA-256 hash values ​​are calculated.

[0049] The hash values ​​of all entities are sorted lexicographically according to their entity identifiers, concatenated, and then the SHA-256 hash value is calculated again to obtain the state view digest.

[0050] This invention provides a system for resuming data transmission and restoring data consistency in a supply chain distributed ledger IoT system, comprising:

[0051] The edge node cluster consists of each edge node deployed on-site at a supply chain participant. It is used to maintain a local edge ledger, collect data from IoT devices, and enter an autonomous mode when the network is down, and execute a hierarchical caching compression and storage overflow hierarchical protection strategy.

[0052] The master node cluster, deployed in the cloud, consists of an odd number of master nodes. It is used to maintain the global master ledger, perform bidirectional incremental synchronization with edge nodes after the network is restored, execute transaction verification and smart contract arbitration, and initiate the global consistency verification process.

[0053] The aforementioned supply chain distributed ledger IoT data outage resume and data consistency recovery system is configured to perform any of the methods described above.

[0054] Compared with the prior art, the beneficial effects of this application are as follows:

[0055] 1. Adopting a two-tier architecture of edge ledger and main ledger, edge nodes can independently maintain their local ledgers during network outages, continue to collect and process IoT data, ensure the continuity of local business for a single node, and avoid the loss of critical data and the stagnation of business for a single node due to network interruption.

[0056] 2. By employing a tiered caching and compression mechanism with tiered protection against storage overflow, the storage strategy is dynamically adjusted based on data importance and storage occupancy, effectively mitigating local storage overflow issues caused by prolonged network outages. This mechanism prioritizes the retention of critical business data, while employing tiered downsampling and LZ4 lossless compression for non-critical data. This ensures the integrity of critical data while maximizing the utilization of storage resources on edge nodes.

[0057] 3. The causal consistency verification mechanism, which combines transaction-level version vectors with dynamic business dependency graphs, solves the problem that existing node-level version vectors cannot track the causal relationship of a single transaction. It can accurately identify the order and dependency relationship between transactions, and significantly reduce the probability of causal inversion and misjudgment conflict.

[0058] 4. A dynamic peak-shaving and retransmission mechanism with multi-dimensional load-based traffic control is adopted. The retransmission license and upload rate are dynamically adjusted according to the comprehensive load of the master node's CPU, memory, bandwidth and disk I / O. This effectively alleviates the retransmission storm problem after large-scale network recovery and improves the stability and availability of the master node cluster.

[0059] 5. By employing a transactional dual-media breakpoint state persistence mechanism, the problem of duplicate data uploads or data loss caused by edge node failures during resume transmission is resolved. Breakpoint information is stored simultaneously on two physically isolated storage media using a transactional write method, avoiding data inconsistency issues caused by power outages during the write process.

[0060] 6. A multi-dimensional smart contract arbitration mechanism is adopted, which adds multi-signature verification and auditing mechanisms for high-priority node operations on the basis of traditional conflict resolution rules. This effectively prevents the risk of high-priority nodes maliciously tampering with data and improves the fairness and security of conflict resolution.

[0061] 7. A global consistency verification mechanism based on RFC8785 standard serialization is adopted, which unifies the JSON serialization specifications of different platforms and avoids misjudgment caused by serialization differences; at the same time, the termination condition of global consistency verification is optimized to ensure that the data of all online nodes is completely consistent, and solves the problem of long-term inconsistency of some nodes in the existing technology.

[0062] 8. This invention achieves more accurate causal consistency verification and conflict resolution than existing technologies through a collaborative combination of transaction-level version vectors, dynamic business dependency graphs, and smart contract arbitration. Existing technologies either fail to track the causal relationships of individual transactions using only node-level version vectors, or fail to adapt to dynamic business scenarios using only static dependency graphs. This invention combines both and supplements them with an arbitration mechanism based on dynamic permission constraints, reducing the false positive rate of conflicts by more than 85%, while also supporting special business scenarios such as emergency allocation.

[0063] 9. The hierarchical caching compression + LAN conditional adjacent node synchronization mechanism of this invention solves the problem that existing technologies cannot effectively protect critical data in the event of a regional network outage. Existing adjacent node synchronization mechanisms do not distinguish between network interruption types and completely fail during regional network outages. In contrast, this invention, through a hierarchical strategy of compression, downsampling, and conditional synchronization, extends the retention time of critical data by more than three times under the same storage capacity.

[0064] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0065] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0066] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0067] Figure 1 This is a flowchart illustrating a method for resuming data transmission and restoring data consistency in a supply chain distributed ledger IoT system according to an embodiment of the present invention. Detailed Implementation

[0068] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0069] This invention provides a method for resuming data transmission and restoring data consistency in a supply chain distributed ledger IoT system after a network outage, such as... Figure 1 As shown, it includes:

[0070] Step S1: Pre-build a two-layer distributed architecture specification of edge ledger and main ledger. Based on the architecture specification, deploy edge nodes in each supply chain participant to maintain the local edge ledger and deploy an odd number of master node clusters in the cloud to maintain the global main ledger. The edge nodes send link probe messages to the master nodes at a preset heartbeat period and monitor the response status. When the number of consecutive times no response messages are received exceeds a preset threshold, it is determined that the current link is in a network outage state, a network outage event signal is generated, and the edge node is triggered to enter the network outage autonomous mode.

[0071] Edge nodes are deployed at various supply chain participants, including suppliers, manufacturers, logistics providers, and retailers. They are responsible for collecting data from local IoT devices, maintaining local edge ledgers, and communicating with the master node. The master node cluster is deployed in the cloud and maintained by multiple trusted third-party organizations. It uses the Raft consensus algorithm to ensure the consistency of the master node cluster and can effectively handle network partitioning issues.

[0072] The master node cluster must have an odd number of nodes (at least 3, 5 recommended), and the nodes communicate with each other via the gRPC protocol. In the event of a network partition, only the sub-clusters containing a majority of nodes can continue to provide service; the sub-clusters with a minority of nodes will automatically stop service and wait for the network to recover before rejoining the cluster and synchronizing data.

[0073] Edge nodes and the master node communicate securely using the TLS 1.3 protocol, and all communication data is encrypted. Edge nodes require authentication upon initial system access; upon successful authentication, a centralized key management system assigns them a globally unique node identifier and a public-private key pair. All keys are stored in a hardware security module (HSM) to prevent key leakage.

[0074] The node's public and private key pair is automatically updated every 180 days. The update process uses a seamless switching method: after the new key is generated, the node uses both the old and new keys to communicate until all other nodes have updated the node's public key, at which point the old key is no longer used. The update process does not affect the normal operation of the system.

[0075] When a node is revoked or its private key is compromised, the key management system immediately revokes the node's key and broadcasts a revocation notice to all other nodes. Nodes receiving the revocation notice immediately cease communication with the revoked node and delete its public key.

[0076] Network connectivity status monitoring works as follows: edge nodes send link probe messages to the master node with a 10-second heartbeat cycle. If no response message is received three times consecutively, the network is considered interrupted, and the autonomous mode is activated. Network recovery detection uses a low heartbeat frequency of 30 seconds. If two valid response messages are received consecutively, the network is considered recovered.

[0077] The aforementioned heartbeat cycle and network disconnection threshold can be adjusted according to the actual network environment. The adjustment range is: heartbeat cycle 1-60 seconds, and number of consecutive no responses received 2-10 times. The adjustment method is as follows: send a configuration update command to all edge nodes through the master node management backend. After receiving the command, the edge nodes automatically update the relevant parameters.

[0078] The master node maintains the node status management mechanism, tracking the online status of each edge node in real time.

[0079] Online node: The continuous offline time does not exceed 1 hour;

[0080] Temporary offline node: A node that is offline for more than 1 hour but no more than 30 days.

[0081] Offline node: Nodes that have been offline for more than 30 consecutive days;

[0082] For offline nodes, the master node will no longer send any data to them until they come back online and complete data synchronization.

[0083] Step S2: In the offline autonomous mode, the edge node continues to collect supply chain business data reported by IoT devices, generates operation log entries, packages the operation log entries into transaction batches according to a preset time window, stores them in the local edge ledger, and maintains the local chained hash log chain. At the same time, during the entire offline autonomous period, the occupancy rate of the local non-volatile storage medium is monitored in real time, and a hierarchical cache compression and storage overflow hierarchical protection strategy is implemented: when the storage occupancy rate reaches 70%, non-critical data is subjected to LZ4 lossless compression; when it reaches 80%, non-critical numerical data is subjected to abnormal retention linear downsampling; when it reaches 90%, non-critical data older than 7 days is deleted; when it reaches 95%, storage of non-critical data is stopped and an alarm is triggered; only when the edge node detects that the local area network communication with the adjacent nodes is normal, the critical data is synchronized to at least 2 adjacent edge nodes before deletion, and this process continues until the edge node detects that the network has been restored.

[0084] IoT devices include temperature and humidity sensors, GPS locators, RFID readers, cameras, barcode scanners, etc., used to collect environmental data, location data, logistics data, quality data, etc., at various stages of the supply chain.

[0085] Edge nodes assign a unique device identifier to each IoT device and predefine data type encoding standards, such as: 0x01 represents temperature and humidity data, 0x02 represents GPS location data, 0x03 represents RFID tag reading data, 0x04 represents goods entering and leaving the warehouse event, and 0x05 represents quality inspection event, etc.

[0086] Each time an edge node receives data reported by an IoT device, it generates an operation log entry. An operation log entry must contain at least the following fields:

[0087] Globally unique serial number: a 64-bit unsigned integer, generated locally by the edge node, incremented by 1 each time an operation log entry is generated;

[0088] Data source device identifier: a 32-bit string, a unique identifier for IoT devices;

[0089] Data type encoding: 8-bit unsigned integer, identifying the data type;

[0090] Data payload: A variable-length byte array that stores the actual business data;

[0091] Local logical clock stamp: a 64-bit unsigned integer, representing the value of the local logical clock of the edge node;

[0092] Local physical timestamp: 64-bit unsigned integer, Unix timestamp, accurate to milliseconds;

[0093] The hash fingerprint of the previous log entry: 32 bytes, the SHA-256 hash value of the previous operation log entry;

[0094] The hash fingerprint of the current log entry: 32 bytes, the SHA-256 hash value of this operation log entry;

[0095] Transaction-level version vector: a variable-length byte array representing the current version vector of the edge node;

[0096] Business dependency graph version number: a 32-bit unsigned integer, representing the version number of the currently used business dependency graph;

[0097] Each edge node maintains a local logical clock, initially set to 0. The logical clock increments by 1 each time an operation log entry is generated. After network recovery, the edge nodes synchronize their logical clocks with the master node, aligning their local logical clocks with the master node's global logical clock. In conflict resolution, the logical clock is used first to determine the order of events; only when the logical clocks are identical are the physical timestamps used as a secondary criterion. This effectively solves the problem of clock asynchrony in distributed systems.

[0098] The hash fingerprint of each operation log entry is obtained by concatenating all fields of that entry except the current hash fingerprint and calculating their SHA-256 hash value, forming a chained hash structure in the log. This structure ensures that any modification to a historical log entry will cause a change in the hash value of all subsequent entries, thus allowing for rapid detection during integrity checks.

[0099] The transaction-level version vector is a key-value pair structure maintained by each edge node. The key is a unique node identifier (32-bit string) plus a transaction sequence number within the transaction batch (16-bit unsigned integer), and the value is the logical clock stamp of that transaction (64-bit unsigned integer). When an edge node downloads transactions from other nodes from the master node, the logical clock stamp of the corresponding transaction in its local version vector is automatically updated. The transaction-level version vector can accurately track the causal relationship of each transaction, solving the problem of insufficient granularity of node-level version vectors.

[0100] To improve the scalability of version vectors, the following optimization measures are adopted:

[0101] Incremental transmission: The synchronization request only carries the transaction-level version vector, that is, the difference between the local version vector of the edge node and the global version vector of the master node during the last synchronization;

[0102] Inactive node removal: Inactive nodes that have not generated any transactions for 6 consecutive months are removed from the version vector;

[0103] Compression encoding: The version vector uses Protocol Buffers' variable-length encoding method for storage and transmission, effectively reducing the amount of data;

[0104] Transaction batches are packaged according to a preset time window and include the following fields:

[0105] Batch unique identifier: 32 bytes, embedding a globally unique batch ID with a generated timestamp. The first 8 bytes are the Unix timestamp, and the last 24 bytes are a random number.

[0106] Batch number: A 64-bit unsigned integer, the batch number generated locally by the edge node.

[0107] Previous batch hash: 32 bytes, the SHA-256 hash value of the previous transaction batch.

[0108] Merkle root: 32 bytes, the Merkle root hash of all operation log entries in this batch.

[0109] Generate timestamps: 64-bit unsigned integers, Unix timestamps, accurate to milliseconds.

[0110] Node signature: 64 bytes, the digital signature of the edge node for batch data.

[0111] Version vector: A variable-length byte array representing the current transaction-level version vector of the edge node.

[0112] Business dependency graph version number: 32-bit unsigned integer, the version number of the business dependency graph used in this batch.

[0113] Throughout the entire network outage autonomy period, edge nodes monitor the utilization rate of local non-volatile storage media (such as built-in eMMC and external SD cards) in real time, and implement tiered cache compression and storage overflow tiered protection strategies, specifically including:

[0114] A predefined classification standard is established for critical and non-critical business data. Critical business data includes goods in / out events, goods status change events, quality inspection events, and transaction payment events. Non-critical business data includes general environmental monitoring data, equipment operating status data, and log statistics. This classification standard can be dynamically adjusted through the master node management backend and synchronized to all edge nodes after adjustment. When the local non-volatile storage medium utilization reaches 70%, all non-critical data is compressed using the LZ4 lossless compression algorithm, with a compression ratio of approximately 2:1.

[0115] When the local non-volatile storage medium occupancy reaches 80%, non-critical numerical data (such as temperature, humidity, and voltage) undergoes linear downsampling. Critical business data (such as goods entry / exit events) is not downsampling, and the sampling frequency is reduced from the original frequency to 1 / 5 of the original frequency. For example, the original sampling frequency is 1 minute / time, and after downsampling, it becomes 5 minutes / time. The linear downsampling algorithm is as follows: for 5 consecutive data points, the average value is taken as a downsampled data point. If any data point deviates from the previous data point by more than a preset anomaly threshold, the original value of that anomaly data point is retained and not included in the downsampling. Downsampled data value: If any data point i satisfies |data point i - previous data point| > anomaly threshold, the original values ​​of all anomaly data points are retained; otherwise, the downsampled data value = ... It should be noted that k is the downsampling factor, i.e. the number of original data points to be merged, and the value is 5, 10, 20 (corresponding to storage occupancy rates of 80%, 85%, and 90%). The abnormal threshold is preset according to the data type, for example, the temperature data is 2℃ and the humidity data is 10%RH; data point i is the i-th original data point.

[0116] When storage occupancy reaches 90%, historical non-critical data older than 7 days is automatically deleted. Deletion proceeds chronologically, starting with the earliest data, until storage occupancy drops below 85%. When storage occupancy reaches 95%, only critical business data is retained, storage of non-critical data ceases, and local and remote alarms are triggered. Local alarms are implemented using LEDs and buzzers on the edge nodes, while remote alarms are sent to the system administrator via SMS and email. When storage occupancy reaches 99%, the oldest non-critical business data is automatically deleted until storage occupancy drops below 95%. If all non-critical business data has been deleted and storage occupancy still exceeds 95%, the oldest critical business data is deleted chronologically, with 10% of the oldest critical business data deleted at a time, triggering the highest-level alarm. Before deletion, the edge node first checks whether local area network communication with adjacent edge nodes is normal. If communication is normal, the critical data to be deleted is synchronized to at least two adjacent edge nodes before the deletion operation is performed.

[0117] Step S3: When the edge node detects network recovery, it generates a random delay time according to the dynamic delay range notified by the master node to perform peak-shifting resume transmission. After the delay ends, it performs integrity verification on the local log chain. After the verification is successful, it reads the locally persisted breakpoint status information and sends a synchronization request to the master node. After the master node receives the synchronization request and verifies the legality of the edge node's identity, it executes step S4.

[0118] The master node notifies the edge nodes of the corresponding random latency range based on the number of currently online edge nodes:

[0119] When there are fewer than 100 online nodes: the delay range is 1-3 minutes;

[0120] When the number of online nodes is between 100 and 1000: the latency range is 1-10 minutes;

[0121] When the number of online nodes exceeds 1000: the latency range is 1-30 minutes;

[0122] Edge nodes generate uniformly distributed random delay times based on the delay range of the notification, ensuring that all resume requests are evenly distributed in time, effectively avoiding the retransmission storm problem after large-scale network recovery.

[0123] After the delay ends, the edge nodes first perform an integrity check on the local log chain. The integrity check method is as follows: traverse each operation log entry backward from the tail of the log chain, recalculate its hash value and compare it with the stored value, and simultaneously verify whether the predecessor hash of the entry points to and matches the previous log entry. If the hash verification of all entries passes, the log chain integrity check passes; otherwise, mark the corrupted area and trigger an alarm, while attempting to recover the corrupted data from adjacent edge nodes.

[0124] After integrity verification passes, the edge node reads the locally persisted breakpoint status information. The breakpoint status persistence mechanism works as follows: after each successful upload of a transaction batch and receipt of confirmation from the master node, the edge node uses a transactional write method to simultaneously write the sequence number of the last successfully uploaded batch, the list of confirmed transaction records, and the version vector to two physically isolated non-volatile storage media (built-in eMMC and external SD card). Transactional writes ensure that the breakpoint information on both storage media is either updated successfully simultaneously or not updated at all, avoiding data inconsistency caused by power outages during the write process. The two storage media use independent file systems and partitions to avoid single points of failure.

[0125] After the edge node restarts, it first reads the breakpoint information from the primary storage medium (built-in eMMC) to verify its integrity and authenticity. The verification method involves calculating the hash value of the breakpoint information and comparing it with the stored checksum, while simultaneously verifying the edge node's digital signature. If verification is successful, the transmission resumes from the breakpoint. If reading from the primary storage medium fails, the breakpoint information from the backup storage medium (external SD card) is read. If reading from both storage media fails, the latest breakpoint information is obtained from the primary node.

[0126] After determining the start point for resuming transmission, the edge node constructs a resuming queue and sends a synchronization request to the master node. The synchronization request is encoded in Protobuf format and includes the following fields:

[0127] Unique identifier for edge nodes: a 32-bit string;

[0128] The hash value of the latest local transaction batch: 32 bytes;

[0129] Transaction-level version vector: A variable-length byte array containing the difference between the local version vector and the global version vector from the last synchronization.

[0130] Persistent breakpoint status information: a variable-length byte array;

[0131] Edge node digital signature: 64 bytes;

[0132] After receiving a synchronization request, the master node first verifies the identity and digital signature of the edge node. Once the verification is successful, it calculates its own load index and decides whether to issue a resume permission based on the load.

[0133] The load index of the master node is calculated as follows: Load index = 0.3 × CPU utilization + 0.25 × memory utilization + 0.25 × network bandwidth utilization + 0.2 × disk I / O utilization. Among them, CPU utilization, memory utilization, network bandwidth utilization and disk I / O utilization are all decimals between 0 and 1, which represent the current CPU, memory and network bandwidth usage of the master node, respectively.

[0134] When the load index is below 70%, the master node issues a resume permission;

[0135] When the load index is 70% or higher, the master node rejects the resume request and instructs the edge nodes to retry after 1 minute. When the utilization rate of any single resource is ≥95%, all new resume requests are rejected directly. The master node performs traffic control on each edge node that is granted a resume permission, limiting its maximum upload rate to 1Mbps to ensure that the total bandwidth does not exceed the processing capacity of the master node cluster.

[0136] Step S4: Based on the comparison between the local master ledger and the transaction-level version vectors reported by the edge nodes, the master node calculates the bidirectional difference interval and performs dynamic incremental synchronization with the edge nodes. During the synchronization process, the master node issues resume permissions and performs traffic control according to its own load. After all bidirectional incremental synchronization is completed, the master node executes step S5 sequentially for all transaction batches uploaded by the edge nodes.

[0137] The specific method for bidirectional difference intervals is as follows:

[0138] The master node iterates through each key-value pair in the version vector sent by the edge nodes and compares it with the corresponding key-value pair in the global version vector maintained by the master node.

[0139] For each node IDj1 in the version vector: if the global sequence number of the main ledger G_j1 > the local sequence number of the edge node L_j1, then the edge node needs to download the interval: [L_j1+1, G_j1]. If the local sequence number of the edge node L_j1 > the global sequence number of the main ledger G_j1, then the main node needs to receive the interval: [G_j1+1, L_j1]. If L_j1 = G_j1, then there is no difference.

[0140] Number of sub-intervals = ceil(total number of batches with differences / maximum batch threshold) The m-th sub-interval: [starting index + (m-1) × maximum batch threshold, min(starting index + m × maximum batch threshold - 1, ending index)], where ceil is the floor function;

[0141] If the master node discovers an unknown node ID in the version vector, it first requests the identity authentication information of that node from the edge node, and then synchronizes the corresponding transaction batch after the verification is successful.

[0142] The master node automatically processes overlapping batches of uploads from multiple edge nodes through idempotency checks to avoid duplicate writes.

[0143] When the number of transaction batches contained in the difference interval exceeds the preset maximum batch threshold (default 100, adjustable range 10-1000), the difference interval is automatically divided into multiple sub-intervals for batch synchronization; the number of transaction batches contained in each sub-interval does not exceed the maximum batch threshold, and the edge nodes are synchronized sequentially according to the order of the sub-intervals.

[0144] Dynamic incremental synchronization employs a download-then-upload sequence: edge nodes first download missing transaction batches from the main ledger, verify them, update their local edge ledger and version vector, and then upload transaction batches generated during the local network outage. This sequence resolves the inconsistency in edge node states caused by dynamic updates to the main ledger during synchronization.

[0145] Edge nodes construct a Merkle tree for each resumed batch, using the hash value of each operation log entry within the batch as the leaf node. The hash values ​​of parent nodes are calculated layer by layer up to the root node, and the root hash value is used as the batch digest. The Merkle tree uses a binary tree structure; the hash value of each parent node is obtained by concatenating the hash values ​​of its two child nodes to calculate the SHA-256 hash. If the number of leaf nodes is odd, the last leaf node is copied as its right child.

[0146] After receiving a batch of transactions, the master node independently recalculates the Merkle tree root hash value and compares it with the batch digest. If the verification passes, the transaction is processed; if verification fails, the edge nodes are asked to retransmit the batch. If three consecutive retransmissions fail, the batch is marked as corrupted, an alarm is triggered, and an attempt is made to retrieve the data from adjacent edge nodes.

[0147] After the edge node downloads the initial difference batch, it requests the latest version vector from the master node. If a new update is found, it continues to download the new batch until the version vectors are completely consistent before starting to upload the local batch.

[0148] Step S5: After receiving each batch of transactions uploaded by the edge nodes, the master node verifies them. For transaction batches without conflicts, they are directly written into the main ledger. For transaction batches with conflicts, the smart contract arbitration mechanism is triggered and step S6 is executed.

[0149] After receiving each batch of transactions uploaded by the edge nodes, the master node performs idempotency verification and transaction-level causal consistency pre-verification in sequence.

[0150] The idempotency check is as follows: each transaction batch contains a globally unique batch ID with an embedded generation timestamp. The master node maintains a hash table of committed batch IDs, retaining records from the most recent 90 days.

[0151] After receiving the transaction batch, the master node first extracts the generation timestamp from the batch ID:

[0152] If the generated timestamp is within the last 90 days, check if the batch ID already exists in the hash table. If it already exists, return success directly and do not repeat the process.

[0153] If the generated timestamp exceeds 90 days, directly check if the batch ID exists in the main ledger. If it exists, return success directly and do not repeat the process.

[0154] The submitted batch ID hash table automatically cleans up records older than 90 days every day at 2 AM to ensure that the hash table size does not grow indefinitely.

[0155] Transaction-level causal consistency pre-verification specifically includes:

[0156] The master node extracts the version vector and business dependency graph version number from the transaction batch;

[0157] Check if the version vector is continuous with the historical version vector of the corresponding node in the main ledger. That is, the batch number uploaded by the edge node this time should be equal to the latest batch number of that node in the main ledger plus 1;

[0158] The master node recursively checks whether all direct and indirect dependencies of the transaction record exist in the main ledger based on the business dependency graph of the specified version number in the transaction batch.

[0159] The dynamic business dependency graph is a directed acyclic graph, which is versioned and each version has a unique version number and effective time.

[0160] The method for constructing a dynamic business dependency graph is as follows: each business operation is abstracted as a node. If operation A must be completed before operation B, then a directed edge from A to B is added between node A and node B. For example, the default dependency relationship is goods inbound → goods outbound → transportation status change → goods receipt.

[0161] Business Dependency Graph Update Process: Administrators submit the new version of the dependency graph and its effective time (accurate to the second) through the master node management backend. Submission requires approval from at least two super administrators. One hour before the new version takes effect, the master node pushes a pre-notification to all edge nodes, and the edge nodes begin caching both the old and new versions of the dependency graph. After the effective time arrives, all newly generated transactions use the new version of the dependency graph, while transactions generated before the effective time continue to use the old version for verification. Temporary Exception Rule Management: Administrators can add temporary exception rules for specific batches or time periods, allowing skipping specified dependency steps. Temporary exception rules must specify the effective time period and scope of application, and automatically expire upon expiration, sending a reminder to the administrator 24 hours before expiration.

[0162] The recursive method for checking the business dependency graph is as follows: For the business operation node corresponding to the transaction record to be checked, recursively traverse all its predecessor nodes and check whether the operation corresponding to each predecessor node already exists in the main ledger. If the operation corresponding to all predecessor nodes already exists, the dependency check passes; otherwise, the dependency check fails.

[0163] The termination condition for the recursive check is:

[0164] Traverse to the root node that has no predecessor node (such as in the goods inbound operation).

[0165] It was discovered that the operation corresponding to a certain predecessor node does not exist in the main ledger.

[0166] The recursion depth exceeds the preset maximum depth (default 100 levels).

[0167] If both the version vector continuity check and the business dependency check pass, the transaction batch is determined to be conflict-free and is directly written to the main ledger; otherwise, it is determined to be a conflicting transaction batch, triggering the smart contract arbitration mechanism.

[0168] Step S6: Automatically process conflicting transactions according to the smart contract arbitration mechanism, generate a conflict processing record containing the cause of the conflict, processing rules and processing results, and submit the conflict processing record and valid transaction records to the master node consensus network to reach consensus. After all conflicting transactions have been processed and the corresponding blocks have been written into the main ledger, proceed to step S7.

[0169] The smart contract arbitration mechanism can automatically, efficiently, and accurately handle transaction conflicts. Smart contracts are deployed on all nodes of the master node cluster, written in Solidity, and deployed and upgraded through the master node consensus network.

[0170] The access control mechanism for smart contracts is as follows:

[0171] Establish a multi-level administrator permission system, divided into super administrators and regular administrators;

[0172] Only super administrators have the authority to submit smart contract deployment / upgrade requests;

[0173] Deployment and upgrade requests for smart contracts require signatures from at least three super administrators;

[0174] After the application is submitted, it needs to be approved by more than 2 / 3 of the nodes in the master node cluster to take effect;

[0175] Smart contracts can only be invoked by the master node; edge nodes cannot directly invoke smart contracts.

[0176] Each smart contract has a clearly defined scope of permissions, and can only access data within its scope of responsibility.

[0177] The conflict resolution result of a high-priority node requires the joint signature of at least two other high-priority nodes to take effect, preventing single-point malicious tampering.

[0178] Multi-signature verification process: When the conflict resolution result involves high-priority nodes, the master node randomly selects at least two nodes from the online high-priority node list that did not participate in the current conflict, and sends the conflict resolution result to them for signature verification. Participating nodes must return their signature results within 10 seconds; if they do not return within the time limit, the next node is automatically selected. If a total of three nodes refuse to sign, the processing result is invalid, triggering a manual intervention process. Multi-signature verification information and conflict resolution records are written to the main ledger and permanently stored for auditing purposes.

[0179] The smart contract receives the following input parameters sent by the master node:

[0180] Conflicting trading pairs: contain two or more conflicting transaction records;

[0181] Business dependency graph with a specified version number: The version of the business dependency graph used when generating transaction records;

[0182] Conflict resolution rule set: Preset multi-dimensional conflict resolution rules.

[0183] Smart contracts process conflicting transactions in the following order of priority, from highest to lowest:

[0184] Custom business rules based on data types: Pre-set different resolution strategies for different data types:

[0185] Numerical data (such as temperature, humidity, weight, etc.): A weighted average of multiple source records is taken. The weights are preset based on the accuracy and reliability of the data source devices. The weighted average is calculated as follows: ,and ,and , where n is the number of conflicting data sources, and n≥2; The measurement value is from the j-th data source; The weight is preset according to the factory accuracy of the equipment. The higher the accuracy, the greater the weight. For example, the basic weight of the equipment with an accuracy of ±0.1℃ is 0.7, and the weight of the equipment with an accuracy of ±0.5℃ is 0.3. The real-time data consistency score for the j-th device is given, with a value range of [0,1]. When the score is <0.2, the data of that device is automatically marked as abnormal and excluded.

[0186] Location-based data (such as GPS coordinates): retrieve the latest record value from the logical clock.

[0187] Status change event data (such as goods entering / leaving the warehouse, status changes, etc.): retrieve the record of the node with the highest priority;

[0188] Text data: Retrieve the record value that is the most recent logical clock stamp and has the longest length;

[0189] Dynamic node priority rules: When logical clock stamps are the same, modifications made by the node with the higher real-time dynamic permission score will prevail. The node's dynamic permission score is calculated based on its base priority, historical data consistency score, and recent behavior audit results. For example, the manufacturer node has a higher priority than the logistics provider node, and the logistics provider node has a higher priority than the retailer node.

[0190] Physical timestamp priority rule: When the logical clock stamp and node priority are the same, the later physical timestamp modification shall prevail.

[0191] Field-level merging rules: For modifications to different fields, all non-conflicting field modifications are automatically merged. For example, if one transaction modifies the temperature of goods and another transaction modifies the location of goods, these two modifications can be merged into a single transaction.

[0192] Strict resource limits are set during smart contract execution: the maximum execution time is 100 milliseconds, and the maximum memory usage is 10MB. When the resource limits are exceeded, the smart contract immediately terminates execution and rolls back all uncommitted modifications, generates an exception handling record containing the reason for failure, relevant transaction information, and a timestamp, marks the abnormal transaction as pending manual handling, and notifies the administrator.

[0193] After the smart contract completes its processing, a conflict resolution record is generated, containing the following fields:

[0194] List of conflicting transaction IDs: IDs of all transactions involved in a conflict;

[0195] Conflict type: Identifies the type of conflict, such as version conflict, dependency conflict, data conflict, etc.

[0196] Decision-making rules: Specific rules used to resolve conflicts;

[0197] Results: Which transactions were valid, and which were invalid;

[0198] Processing timestamp: The timestamp when the smart contract has completed execution;

[0199] Smart contract signature: The master node's digital signature of the conflict resolution record;

[0200] Multisignature verification information: Common signature information of the conflict resolution results of high-priority nodes.

[0201] The master node submits the valid transaction records and conflict resolution records to the master node consensus network to reach consensus, writes them into the main ledger, and updates the global version vector.

[0202] Step S7: After all the resumed data has been submitted to the chain, the master node starts the global consistency verification process, sends a state view summary request to all online edge nodes, compares the on-chain state view with the local state view summary reported by each node on an entity-by-entity basis, generates a difference list, and performs classification and repair according to the difference type until all online node data are completely consistent and no new differences are found in two consecutive verifications. At this time, the master node sends a business recovery notification to all online edge nodes. Temporarily offline edge nodes can only resume business after completing data synchronization and passing the consistency verification.

[0203] Once all subsequent data has been committed to the blockchain, the master node initiates the global consistency verification process. The triggering conditions for global consistency verification include:

[0204] The resume transmission process for all edge nodes is complete;

[0205] It will run automatically once a day at 3 AM.

[0206] Manually triggered by the system administrator;

[0207] The global consistency verification mechanism under the master node network partition is as follows:

[0208] Only the leader node of the master node cluster can initiate the global consistency verification process;

[0209] When a network partition occurs in the master node cluster, only the partition containing the leader node can continue to perform global consistency checks.

[0210] A few partitions automatically stop global consistency verification and wait for the network to recover before rejoining the cluster and synchronizing data.

[0211] The final result of the global consistency check needs to be reached through consensus among the master node cluster before it becomes effective;

[0212] The global consistency check is specifically as follows:

[0213] The master node sends a status view summary request to all online edge nodes and temporarily offline edge nodes to record offline edge nodes.

[0214] Upon receiving the request, each online edge node generates a local summary of the latest state view and returns it to the master node.

[0215] The state view summary is a set of hash values ​​for key state variables of each supply chain entity. Each supply chain entity corresponds to a unique entity identifier (such as goods ID, batch ID, etc.), and key state variables include the entity's current location, status, quantity, and attribute information.

[0216] The method for generating the state view summary is as follows:

[0217] For each supply chain entity, all key status variables are serialized into JSON according to the lexicographical order of field names, following the RFC 8785 standard.

[0218] Calculate the SHA-256 hash value of the serialized string to obtain the state hash of the entity;

[0219] Sort the state hashes of all entities in lexicographical order according to their entity identifiers and then concatenate them into a long string;

[0220] Calculate the SHA-256 hash value of the long string to obtain the final state view digest;

[0221] This method ensures that the same entity state will generate the same hash value regardless of the programming language or JSON library used, avoiding misjudgments caused by inconsistent serialization order.

[0222] In this embodiment, the current log entry hash = SHA-256 (UTF-8 encoding (all fields except the current hash field are concatenated into a string in a preset order)), and the preset field order is: globally unique serial number → data source device identifier → data type encoding → data payload → local logical clock stamp → local physical timestamp → hash fingerprint of the previous log entry → version vector → business dependency graph version number;

[0223] Entity state hash = SHA-256 (RFC8785 standard serialization (JSON object of all key state variables of the entity)), key state variables are arranged in lexicographical order by field name;

[0224] State view digest = SHA-256(byte array concatenated with all entity state hashes sorted lexicographically by entity identifier);

[0225] Parent node hash = SHA-256(left child node hash byte array + right child node hash byte array). If the number of leaf nodes is odd, the last leaf node is copied as the right child node.

[0226] This system uses the SHA-256 algorithm by default. If a security vulnerability is found in this algorithm, it can be upgraded to SHA-3 or other secure hash algorithms through master node consensus.

[0227] The master node generates a summary of the chain's state view, using the same method as the edge nodes.

[0228] The master node compares the on-chain state view summary with the local state view summaries reported by each edge node. If they match, it means that the data of that edge node is consistent with the master ledger; if they differ, an entity-by-entity comparison is required.

[0229] The master node compares the state hash of each entity on the chain with the state hash of the corresponding entity reported by the edge nodes, generating a discrepancy list. The discrepancy list includes the discrepancy entity identifier, the on-chain state hash, the edge node state hash, and the discrepancy type.

[0230] The differences are categorized into the following three types:

[0231] On-chain missing type: The edge node has a record of the entity, but it is not in the main ledger;

[0232] Local missing type: The entity has a record in the main ledger, but not in the edge node;

[0233] Inconsistent value type: Both the main ledger and the edge nodes have records of the entity, but the state hashes are different;

[0234] The master node performs categorized repair based on the difference type:

[0235] On-chain missing type: The master node requests the corresponding edge node to retransmit the operation log of the missing entry, and after verification, it is retransmitted to the chain;

[0236] Local missing type: The master node pushes the confirmed operation log entry for this entity on the chain to the missing edge node for local appending;

[0237] Inconsistent Value Type: The master node uses the state value confirmed by on-chain consensus as the authoritative value, notifies all edge nodes to make unified corrections, and writes the mediation record into the distributed ledger as audit evidence. The audit evidence includes the discrepancy entity identifier, the original value, the corrected value, the correction timestamp, and the master node signature.

[0238] After the discrepancy list is processed, the entity-by-entity comparison is re-executed.

[0239] Repeat the above entity-by-entity comparison and classification repair steps until the preset termination conditions are met. The preset termination conditions include:

[0240] The difference lists of all online nodes are empty; no new differences are found in two consecutive global consistency checks. When both of these conditions are met, the global consistency check is considered successful. At this point, the master node sends a service recovery notification to all online edge nodes, and the system resumes normal business processing.

[0241] After a temporarily offline edge node comes back online, it must first complete a full data synchronization and pass the consistency check of the master node before it can participate in business processing. Edge nodes that have been offline for more than 30 consecutive days are marked as offline nodes and are not included in the calculation of the global consistency check ratio. This solves the problem of the system being unable to resume normal business operations due to long-term offline nodes.

[0242] To improve the efficiency of global consistency verification in large-scale systems, this invention employs a distributed verification mechanism: each node in the master node cluster is responsible for verifying a portion of the data from the edge nodes, and the verification results are aggregated and processed uniformly by the leader node of the master node cluster. This mechanism distributes the verification load across multiple nodes, significantly improving verification efficiency.

[0243] Furthermore, this invention also provides a data backup mechanism between edge nodes, further improving the system's reliability and data security:

[0244] Each edge node maintains a list of neighboring nodes, containing the addresses and public keys of at least three other edge nodes within the same supply chain region. This list is automatically generated by the master node based on the edge nodes' geographical location and network topology, and is updated periodically.

[0245] Every 15 minutes, edge nodes synchronize the latest portion of their local log chain (i.e., all transaction batches generated since the last backup) to at least two nodes in their neighboring node list. For critical business data, synchronization to neighboring nodes occurs immediately upon the generation of each transaction batch. This synchronization operation is performed only when local area network communication between edge nodes is normal.

[0246] During synchronization, the sender uses its private key to digitally sign the data, and the receiver uses the sender's public key to verify the signature before storing the data.

[0247] When an edge node fails and data recovery is needed, a data recovery request is sent to all nodes in the list of neighboring nodes. The receivers return their respective stored log chain data for that node, and the failed node selects the latest and most complete data for recovery. After recovery, the integrity and authenticity of the data are verified, and then the network outage resumption process continues.

[0248] Edge nodes retain all transaction batches from the most recent 24 hours locally, even if they have been backed up to neighboring nodes.

[0249] Example 1: This example provides a method for resuming data transmission and restoring data consistency in a distributed ledger IoT system for supply chain applications, applied to a cold chain logistics scenario. The cold chain logistics scenario involves three participants: suppliers, logistics providers, and retailers. Each participant deploys edge nodes. The supplier's edge nodes are connected to temperature and humidity sensors and RFID readers to collect temperature and humidity data from cold storage facilities and data on goods entering and leaving the warehouse. The logistics provider's edge nodes are connected to vehicle GPS trackers and temperature and humidity sensors to collect location data from transport vehicles and temperature and humidity data inside cargo containers. The retailer's edge nodes are connected to temperature and humidity sensors and barcode scanners to collect temperature and humidity data from store cold storage facilities and sales data. A master node cluster consisting of five nodes is deployed in the cloud, employing the Raft consensus algorithm, responsible for maintaining the global master ledger.

[0250] The specific implementation steps are as follows: System initialization: All edge nodes and master nodes complete registration and authentication, and establish a TLS 1.3 secure communication channel. The centralized key management system allocates public and private key pairs to each node, and all keys are stored in the hardware security module. Each edge node initializes its local edge ledger, log chain, transaction-level version vector, and logical clock (initial value is 0), and the master node initializes its master ledger, global version vector, and global logical clock.

[0251] The master node loads the dynamic business dependency graph (version 1.0, effective time is the system initialization time), defining the default dependency relationships for goods entering the warehouse → goods leaving the warehouse → transportation status change → goods receipt.

[0252] Data processing under normal network conditions: The supplier's edge nodes collect the temperature and humidity data of the cold storage every 5 minutes, generate operation log entries (logical clock incremented by 1, business dependency graph version number 1.0), package them into transaction batches, and upload them to the master node.

[0253] The logistics provider's edge nodes collect the location data of transport vehicles and the temperature and humidity data inside the cargo boxes every minute, generate operation log entries (logical clock incremented by 1, business dependency graph version number 1.0), package them into transaction batches, and upload them to the master node. The retailer's edge nodes collect the temperature and humidity data of the store's cold storage every 10 minutes, generate operation log entries (logical clock incremented by 1, business dependency graph version number 1.0), package them into transaction batches, and upload them to the master node.

[0254] The master node receives transaction batches uploaded by all edge nodes, performs idempotency checks and transaction-level causal consistency pre-checks, and writes them to the main ledger after successful verification, then synchronizes them to all edge nodes. Data processing in network outage scenarios: Logistics companies' transport vehicles enter mountain tunnels, causing network signal interruption.

[0255] If an edge node fails to send heartbeat packets three times consecutively (each time with a 10-second interval), it is determined to be a network interruption and initiates a network outage autonomous mode. During the network outage, the edge node continues to collect location data and temperature and humidity data every minute, generates operation log entries (the logical clock increments from 1000, and the business dependency graph version number is 1.0), packages them into transaction batches, stores them in the local edge ledger, and maintains a local chained hash log chain.

[0256] Edge nodes monitor local storage occupancy in real time. When occupancy reaches 70%, LZ4 lossless compression is applied to the temperature and humidity data. When occupancy reaches 80%, linear downsampling is performed on the temperature and humidity data, reducing the sampling frequency from 1 minute / time to 5 minutes / time, while retaining temperature fluctuation data exceeding 2°C. Assuming a network outage of 30 minutes, the edge nodes generated 12 operation log entries, which were packaged into 6 transaction batches (one batch every 5 minutes).

[0257] Network recovery and data consistency restoration: After the transport vehicle exits the tunnel, the network signal is restored. Edge nodes receive two consecutive heartbeat responses from the master node (each 30 seconds apart), indicating network recovery. The edge nodes send a network recovery notification to the master node. The master node currently has 85 online edge nodes, and the notification delay is 1-3 minutes.

[0258] The edge node generates a random delay of 2 minutes, and sends a synchronization request to the master node after the delay ends. The master node's current load index is 49% (CPU utilization 40%, memory utilization 60%, network bandwidth utilization 50%, disk I / O utilization 45%), which is below 70%, so a resume permission is granted.

[0259] Edge nodes perform integrity checks on the local log chain, traversing each operation log entry backward from the tail of the log chain, recalculating its hash value and comparing it with the stored value, and simultaneously verifying whether the predecessor hash of each entry points to and matches the previous log entry. If the hash verification of all entries passes, the log chain integrity check passes.

[0260] The edge node reads the breakpoint information (the last successfully uploaded batch number is 100) from its local primary storage medium (built-in eMMC), verifies its integrity and authenticity, and then sends a synchronization request to the master node. The request carries the logistics provider node's unique identifier, the hash value of the latest local transaction batch, the transaction-level incremental version vector (logistics provider node: 106, supplier node: 52, retailer node: 38), and breakpoint status information. The master node compares the global version vector (logistics provider node: 100, supplier node: 52, retailer node: 38) and calculates the bidirectional difference interval. The master node determines that the range of main ledger transaction batches that the logistics provider node needs to download is empty, and the range of logistics provider node transaction batches that the master node needs to receive is [101, 106]. The master node returns a list of transaction batches that need to be synchronized to the logistics provider node (an empty list).

[0261] The logistics provider node constructs a Merkle tree for each resumed batch, generates a batch digest, and uploads the six transaction batches generated during the local network outage in batch sequence. After receiving these six transaction batches, the master node recalculates the Merkle tree root hash value for each batch and compares it with the batch digest; verification is successful. The master node performs idempotency checks: it extracts the generation timestamp from the batch IDs, ensuring they are all within the last 90 days, and checks whether the batch IDs already exist in the submitted batch ID hash table; if not, they do not exist.

[0262] The master node performs a transaction-level causal consistency pre-verification: checking whether the version vector of each transaction is continuous with the historical version vector of the corresponding transaction in the master ledger. The transaction sequence numbers uploaded by the logistics provider node this time are 101 to 106, and the latest transaction sequence number of this node in the master ledger is 100, so the version vectors are continuous. The business dependency graph version number 1.0 is extracted from the transaction batch, and the dependency graph of this version is used to recursively check whether all direct and indirect dependencies of the transaction record already exist in the master ledger. All dependencies of the transaction record already exist, and the dependency check passes. After verification, these 6 transaction batches have no conflicts and are directly written to the master ledger. The master node updates the global version vector (the batch sequence number of the logistics provider node is updated to 106) and the global logical clock. The master node initiates the global consistency closed-loop verification process and sends a state view summary request to all online edge nodes. The edge nodes of the supplier, logistics provider, and retailer generate the latest local state view summary (serialized into JSON according to the RFC8785 standard) and return it to the master node. The master node generates an on-chain state view summary and compares it with the local state view summaries reported by each edge node. If they are found to be completely consistent, the generated discrepancy list is empty.

[0263] After two consecutive global consistency checks revealed no new discrepancies, meeting the preset termination conditions, the master node determined the global consistency check to be successful and sent a service recovery notification to all online edge nodes. The system resumed normal business processing. Thus, the outage resumption and data consistency recovery process was completed. The entire process took approximately 10 seconds, with no data loss or conflicts.

[0264] Example 2: This example provides a data consistency recovery method in the event of a transaction conflict. Based on Example 1, it is assumed that during the period when the logistics provider node is offline, the supplier node also generates new transaction batches, and one of these transaction batches conflicts with a certain transaction batch generated during the period when the logistics provider node is offline.

[0265] The specific implementation steps are as follows: During the network outage of the logistics provider node, the supplier node generates three new transaction batches (batch 53 to batch 55) and uploads them to the master node. After the master node verifies them, they are written into the main ledger, and the batch number of the supplier node in the global version vector is updated to 55. After the network is restored, the logistics provider node sends a network restoration notification to the master node. The master node currently has 85 online edge nodes, and the notification delay range for edge nodes is 1-3 minutes. The logistics provider node generates a random delay time of 2 minutes, and sends a synchronization request to the master node after the delay ends. The master node's current load index is 45%, and it grants a resumption license. The logistics provider node sends a synchronization request to the master node, carrying a transaction-level incremental version vector of (logistics provider node: 106, supplier node: 52, retailer node: 38). The master node compares the global version vector (logistics provider node: 100, supplier node: 55, retailer node: 38) and calculates the bidirectional difference interval. The logistics provider node needs to download the master ledger transaction batches within the range [53, 55] of the supplier node, while the master node needs to receive transaction batches within the range [101, 106] from the logistics provider node. The master node returns a list of transaction batches to be synchronized to the logistics provider node (batch 53 to batch 55 of the supplier node). The logistics provider node downloads these three transaction batches, verifies them, and then updates its local edge ledger, version vector, and logical clock (aligned with the master node's global logical clock). The logistics provider node requests the latest version vector from the master node again, and after confirming there are no new updates, it begins uploading the six transaction batches (batch 101 to batch 106) generated during the local network outage. After receiving these six transaction batches, the master node performs Merkle tree verification, idempotency verification, and transaction-level causal consistency pre-verification. The check reveals a conflict between a transaction record (cargo temperature data) in batch 106 and a transaction record (temperature data for the same cargo) in batch 54 of the supplier node. The two transaction records have the same logical clock stamp, but the data content is different (the logistics provider's record shows a temperature of 2.5℃, while the supplier's record shows a temperature of 3.2℃). The master node triggers a multi-dimensional smart contract arbitration mechanism. The smart contract receives conflicting transaction pairs, a business dependency graph version 1.0, a conflict resolution rule set, and a node dynamic permission score from the master node as input parameters. The smart contract processes the conflict according to preset conflict resolution priority rules: first, it applies custom business rules based on data type. Since the conflicting data is numerical data (temperature data), a weighted average of multiple source records should be used. The supplier's temperature and humidity sensor has an accuracy of ±0.1℃ and a base weight of 0.7; the logistics provider's temperature and humidity sensor has an accuracy of ±0.5℃ and a base weight of 0.3. Both devices have a real-time consistency score of 1.0.

[0266] The weighted average is calculated as follows: 2.5 × 0.3 + 3.2 × 0.7 = 0.75 + 2.24 = 2.99℃ ≈ 3.0℃. The smart contract determines the final temperature value to be 3.0℃, and the temperature field in both transaction records is updated to 3.0℃, while other non-conflicting fields are retained. Since this conflict involves a high-priority node (supplier), the processing result requires the joint signature of another high-priority node (manufacturer). The master node sends the processing result to the manufacturer node for signature verification; once verification is successful, it takes effect. The smart contract generates a conflict resolution record, containing conflict transaction information, conflict type, processing rules, processing result, processing timestamp, and multi-signature verification information. The master node submits the valid transaction record and conflict resolution record together to consensus, writes them to the main ledger, and updates the global version vector.

[0267] The master node initiates a global consistency closed-loop verification process. Each edge node returns a summary of its local state view. The master node compares the local state view of the logistics provider node with the on-chain state view and finds a discrepancy (different temperature field). The master node uses the state value confirmed by on-chain consensus (3.0℃) as the authoritative value, notifies the logistics provider node to correct its local state, and writes the mediation record into the distributed ledger as audit evidence. A re-execution of the entity-by-entity comparison is performed, generating an empty discrepancy list. If no new discrepancies are found in two consecutive global consistency checks, the preset termination condition is met, and the master node determines that the global consistency check has passed and sends a business recovery notification to all online edge nodes. Thus, the data consistency recovery process in the event of a transaction conflict is completed. The entire process is automated, requiring no manual intervention, and the conflict resolution is accurate and secure.

[0268] Example 3: This example provides a scenario for edge node failure and data recovery. Assume that a logistics provider's node experiences hard drive failure during a network outage, resulting in the loss of all locally stored data.

[0269] The specific implementation steps are as follows:

[0270] After the logistics provider node replaced the hard drive and restarted, it attempted to read the breakpoint information of the local main storage medium (built-in eMMC), but found that the main storage medium was damaged.

[0271] The logistics provider node attempted to read the breakpoint information from the backup storage medium (external SD card) and discovered that the backup storage medium was also damaged.

[0272] The logistics provider node sends a data recovery request to three neighboring nodes in the neighboring node list (logistics provider node B, retailer node C, and supplier node D).

[0273] Neighboring nodes B and C return the log chain data (batch 101 to batch 103) of their respective stored logistics provider nodes, while neighboring node D does not store data for this node.

[0274] The logistics provider's nodes verify the hash value and digital signature of the received data to confirm that the data is complete and has not been tampered with.

[0275] The logistics provider node selects the latest and complete data (data from node B) to restore the local log chain and edge ledger.

[0276] Once the recovery is complete, the logistics provider node continues the process of resuming transmission after a network outage, sending a synchronization request to the master node.

[0277] The entire data recovery process took about 2 minutes and no data was lost.

[0278] Example 4: This example provides a scenario for smart contract exception handling and rollback. Assume there is a rule error in the smart contract, causing a division-by-zero error to occur when processing a conflicting transaction.

[0279] The specific implementation steps are as follows:

[0280] The master node detected a conflicting transaction and triggered the smart contract arbitration mechanism.

[0281] A division by zero error occurred during the execution of the smart contract, causing the execution to fail.

[0282] The smart contract immediately rolls back all uncommitted modifications, restoring it to its state before execution.

[0283] The smart contract generates an exception handling record, which includes the reason for failure (division by zero error), relevant transaction information (batch ID: 105, transaction ID: abc123) and timestamp.

[0284] The master node marks abnormal transactions as requiring manual handling and sends an alert email to the administrator.

[0285] After the administrator fixes the rule errors in the smart contract, they submit a smart contract upgrade request through the master node management backend.

[0286] After the upgrade request is signed by three super administrators, it is submitted to the master node cluster.

[0287] The smart contract upgrade takes effect once the upgrade request is approved by more than 2 / 3 of the nodes in the master node cluster.

[0288] The administrator re-triggered the arbitration process for this transaction.

[0289] The smart contract successfully handles conflicting transactions, generates a conflict resolution record, and submits it for consensus.

[0290] This invention provides a system for resuming data transmission and restoring data consistency in a supply chain distributed ledger IoT system, comprising:

[0291] The edge node cluster consists of each edge node deployed on-site at a supply chain participant. It is used to maintain a local edge ledger, collect data from IoT devices, and enter an autonomous mode when the network is down, and execute a hierarchical caching compression and storage overflow hierarchical protection strategy.

[0292] The master node cluster, deployed in the cloud, consists of an odd number of master nodes. It is used to maintain the global master ledger, perform bidirectional incremental synchronization with edge nodes after the network is restored, execute transaction verification and smart contract arbitration, and initiate the global consistency verification process.

[0293] The aforementioned supply chain distributed ledger IoT data outage resume and data consistency recovery system is configured to perform any of the methods described above.

[0294] This invention adopts a two-layer distributed architecture of edge ledger and main ledger, consisting of an edge layer and a main layer, with the specific specifications as follows:

[0295] 1. Architecture Deployment and Responsibility Division: Each supply chain participant deploys edge nodes on-site to maintain the local edge ledger, collect IoT business data, and enter autonomous mode when the network is down; a master node cluster consisting of an odd number of nodes is deployed in the cloud to maintain the global master ledger and is responsible for transaction consensus, data synchronization and consistency verification.

[0296] 2. Edge layer specifications: Edge nodes maintain a locally linked hash log chain, packaging business data into transaction batches for storage according to a preset time window; during network outages, implement tiered caching compression and storage overflow protection strategies to prioritize ensuring that critical business data is not lost. After network recovery, edge nodes send incremental synchronization requests to the master node based on transaction-level version vectors and perform breakpoint resumption.

[0297] 3. The main layer specification specifies that the master node cluster adopts the Raft consensus algorithm in a disconnected autonomous mode to maintain the global master ledger. It performs idempotency checks and causal consistency pre-checks on transaction batches uploaded by edge nodes, and triggers smart contract arbitration for conflicting transactions. The master node periodically initiates global consistency checks, using the on-chain consensus state as the authoritative value to correct the local data of each edge node.

[0298] 4. Communication and Security Specifications: Edge nodes and master nodes communicate using TLS (TLS-encrypted) in a network-disconnected autonomous mode. A heartbeat mechanism monitors link status, and the logic for determining network disconnection and recovery is built into the edge node. Node identity is based on digital certificate authentication, and the key is stored in a hardware security module to ensure communication and data security.

[0299] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for resuming data transmission and restoring data consistency in a supply chain distributed ledger IoT system after a network outage, characterized in that: include: Step S1: Pre-build a two-layer distributed architecture specification of edge ledger and main ledger. Based on the architecture specification, deploy edge nodes in each supply chain participant to maintain the local edge ledger and deploy an odd number of master node clusters in the cloud to maintain the global main ledger. The edge nodes send link probe messages to the master nodes at a preset heartbeat period and monitor the response status. When the number of consecutive times no response messages are received exceeds a preset threshold, it is determined that the current link is in a network outage state, a network outage event signal is generated, and the edge node is triggered to enter the network outage autonomous mode. Step S2: In the offline autonomous mode, the edge node continues to collect supply chain business data reported by IoT devices, generates operation log entries, packages the operation log entries into transaction batches according to a preset time window, stores them in the local edge ledger, and maintains the local chained hash log chain. At the same time, during the entire offline autonomous period, the occupancy rate of the local non-volatile storage medium is monitored in real time, and a hierarchical cache compression and storage overflow hierarchical protection strategy is implemented. Only when the edge node detects that the local area network communication with the adjacent nodes is normal, it synchronizes to at least two adjacent edge nodes before deleting key data, and continues to execute until the edge node detects that the network has been restored. Step S3: When the edge node detects network recovery, it generates a random delay time according to the dynamic delay range notified by the master node to perform peak-shifting resume transmission. After the delay ends, it performs integrity verification on the local log chain. After the verification is successful, it reads the locally persisted breakpoint status information and sends a synchronization request to the master node. After the master node receives the synchronization request and verifies the legitimate identity of the edge node, it executes step S4. Step S4: The master node compares the local master ledger with the transaction-level version vector reported by the edge nodes, calculates the bidirectional difference interval, and performs dynamic incremental synchronization with the edge nodes. During the synchronization process, the master node issues a resume license and performs traffic control based on its own load. After all bidirectional incremental synchronization is completed, the master node executes step S5 sequentially for all transaction batches uploaded by the edge nodes. Step S5: After receiving each batch of transactions uploaded by the edge nodes, the master node verifies them. For transaction batches without conflicts, they are directly written into the main ledger. For transaction batches with conflicts, the smart contract arbitration mechanism is triggered and step S6 is executed. Step S6: Automatically process conflicting transactions according to the smart contract arbitration mechanism, generate a conflict processing record containing the cause of the conflict, processing rules and processing results, and submit the conflict processing record and valid transaction records to the master node consensus network to reach consensus. After all conflicting transactions have been processed and the corresponding blocks have been written into the main ledger, proceed to step S7. Step S7: After all the resumed data has been submitted to the chain, the master node starts the global consistency verification process, sends a state view summary request to all online edge nodes and temporary offline edge nodes, compares the on-chain state view with the local state view summary reported by each node on an entity-by-entity basis, generates a difference list and performs classification repair according to the difference type until the preset termination condition is met. At this time, the master node sends a business recovery notification to all edge nodes and the system resumes normal business processing.

2. The method according to claim 1, characterized in that, The operation log entries shall include at least a globally unique serial number, a data source device identifier, a data type encoding, a data payload, a local logical clock stamp, a local physical timestamp, a hash fingerprint of the previous log entry, a hash fingerprint of the current log entry, a transaction-level version vector, and a business dependency graph version number. The hash fingerprint of each operation log entry is obtained by concatenating all fields of the entry except the current hash fingerprint and calculating the SHA-256 hash value, forming a chain of log entries with a chain hash structure.

3. The method according to claim 1, characterized in that, The transaction-level version vector is a key-value pair structure maintained by each edge node. The key is the node's unique identifier and the transaction sequence number within the transaction batch, and the value is the logical clock stamp of the transaction. When an edge node downloads transaction batches from other nodes from the master node, the logical clock stamp of the corresponding transaction in the local version vector is automatically updated. The synchronization request carries the latest local batch hash, transaction-level version vector, and persistent breakpoint status information. The transaction-level version vector is the difference between the edge node's local version vector and the master node's global version vector during the last synchronization.

4. The method according to claim 1, characterized in that, The steps for persisting breakpoint states include: After each successful upload of a transaction batch and receipt of confirmation from the master node, the edge node uses a transactional write method to simultaneously write the sequence number of the last successfully uploaded batch, the list of confirmed transaction records, and the transaction-level version vector to two physically isolated non-volatile storage media. After the edge node restarts, it first reads the breakpoint information of the main storage medium, verifies its integrity and authenticity, and then continues the transmission from the breakpoint. If the primary storage medium fails to read, the breakpoint information of the backup storage medium is read. If both storage media fail to read, the latest breakpoint information is obtained from the master node.

5. The method according to claim 1, characterized in that, Based on the comparison between the local master ledger and the transaction-level version vectors reported by the edge nodes, the bidirectional difference interval is calculated, including: The transaction-level version vector sent by the master node through the edge nodes is compared with the global version vector maintained by the master node. If the master ledger sequence number is greater than the edge node sequence number, then the range of master ledger transaction batches that the edge node needs to download is determined to be: {edge node sequence number + 1, master ledger sequence number}. If the edge node sequence number is greater than the main ledger sequence number, then the range of edge node transaction batches that the main node needs to receive is determined to be: {main node sequence number + 1, edge node sequence number}. When the number of transaction batches contained in the difference interval exceeds the preset maximum batch threshold, the difference interval will be automatically divided into multiple sub-intervals for batch synchronization.

6. The method according to claim 1, characterized in that, The difference types include: on-chain missing type, local missing type, and value inconsistency type. For on-chain missing type differences, the master node requests the edge node to retransmit the missing entry. For local missing differences, the master node pushes the confirmed entries on the chain to the corresponding edge nodes; For discrepancies in values, the master node uses the on-chain consensus state value as the authoritative value to notify all edge nodes to uniformly correct and write it into the audit certificate. The audit certificate includes the discrepancy entity identifier, the original value, the corrected value, the correction timestamp, and the master node signature.

7. The method according to claim 1, characterized in that, In step S5, the verification includes: idempotency verification and transaction-level causal consistency pre-verification, wherein the idempotency verification includes: Each transaction batch contains a globally unique batch ID embedded with the generated timestamp. The master node maintains a hash table of committed batch IDs, retaining records from the most recent N0 days. After receiving a batch of transactions, the master node first extracts the generation timestamp from the batch ID. If the generation timestamp is within the last N0 days, it checks whether the batch ID already exists in the hash table. If it already exists, it returns success directly and does not repeat the process. If the generated timestamp exceeds N0 days, directly query the main ledger to see if the batch ID exists. If it exists, return success directly and do not repeat the process. At the same time, the hash table of submitted batch IDs is automatically cleaned up daily for records older than N0 days. Among them, transaction-level causal consistency pre-verification includes: The master node extracts the transaction-level version vector and the version number of the business dependency graph from the transaction batch; Check if the version vector is continuous with the historical version vector of the corresponding node in the main ledger; The master node recursively checks whether all direct and indirect dependencies of the transaction record already exist in the main ledger based on the dynamic business dependency graph of the specified version number in the transaction batch. If both checks pass, the transaction is considered a conflict-free batch. Otherwise, the transaction batches are judged to be conflicting.

8. The method according to claim 1, characterized in that, Retrieving the state view summary includes: For each supply chain entity, all key status variables are serialized into JSON in lexicographical order of field names, and then their SHA-256 hash values ​​are calculated. The hash values ​​of all entities are sorted lexicographically according to their entity identifiers, concatenated, and then the SHA-256 hash value is calculated again to obtain the state view digest.

9. A system for resuming data transmission and restoring data consistency in a supply chain distributed ledger Internet of Things (IoT) system, characterized in that: include: The edge node cluster consists of each edge node deployed on-site at a supply chain participant. It is used to maintain a local edge ledger, collect data from IoT devices, and enter an autonomous mode when the network is down, and execute a hierarchical caching compression and storage overflow hierarchical protection strategy. The master node cluster, deployed in the cloud, consists of an odd number of master nodes. It is used to maintain the global master ledger, perform bidirectional incremental synchronization with edge nodes after the network is restored, execute transaction verification and smart contract arbitration, and initiate the global consistency verification process. The aforementioned supply chain distributed ledger IoT data interruption resume and data consistency recovery system is configured to perform the method of any one of claims 1-8.

Images