Offline transmission and blockchain-based evidence storage methods and systems for building inspection data

Abstract

This invention relates to the field of data transmission and data storage technology, and provides a method and system for offline transmission and blockchain storage of house inspection data. The method is executed by a first mobile terminal and includes: collecting house inspection data in a network-free environment and sequentially constructing a chain hash; dividing the data to be transmitted into multiple data blocks and performing fountain code encoding to obtain redundant encoded packets, converting them into a dynamic QR code image sequence for frame-by-frame display for data recovery and verification; decoding the dynamic QR code image sequence displayed by a second mobile terminal to obtain data and chain hash information for integrity verification; comparing version information through version QR code interaction and performing incremental data synchronization based on differences; and recording the chain hash root hash value to the blockchain via a smart contract after network recovery. This invention achieves efficient visual transmission of multi-terminal inspection data in a network-free environment, decentralized synchronization, and reliable on-chain anchoring of offline data.

Description

Technical Field

[0001] This invention relates to the field of data transmission and data storage technology, and in particular to a method and system for offline transmission and blockchain storage of house inspection data. Background Technology

[0002] Structural safety inspection data of buildings is the direct basis for assessing structural safety. In building inspection scenarios involving the collaborative operation of multiple mobile data acquisition terminals, the issues of reliable exchange of inspection data between multiple terminals in network-free environments and the reliable assurance of inspection data throughout its entire lifecycle have not yet been resolved simultaneously.

[0003] Actual testing work is often carried out in environments with poor or intermittent network signal coverage, such as basements, remote areas, or inside historical buildings, where real-time network communication is not possible. Large-scale testing projects require multiple inspectors to collaborate in different areas to collect data. When the network is unavailable, each terminal becomes an isolated node, and the on-site data collection, comparison, and preliminary judgment rely on manual transmission or post-event export, resulting in low collaborative efficiency.

[0004] For data transmission without a network, existing solutions include short-range wireless and optical identification. Bluetooth is limited by communication distance and wall attenuation, and pairing is complex and throughput is insufficient when multiple devices are connected concurrently; Wi-Fi... Direct Fi connections suffer from poor signal stability in complex electromagnetic environments, such as construction sites, and are often disabled by security policies in some scenarios. While traditional optical methods based on QR codes do not rely on radio frequency, their single-frame capacity is low, requiring a large number of frames to transmit large files. This process is lengthy and prone to interruption due to consecutive frame acquisition failures, and their error correction capabilities are insufficient to handle recognition defects under dynamic lighting conditions. None of the aforementioned solutions provide a high-capacity detection data exchange mechanism that is robust to data loss and error recovery, suitable for multi-terminal collaboration, and independent of network infrastructure.

[0005] Regarding data trustworthiness, there are trust-deficient links throughout the entire lifecycle from on-site data collection to report generation. During the offline collection phase, the lack of a network verification environment means that data stored locally on the terminal lacks integrity protection, making tampering difficult to detect. Existing blockchain evidence storage solutions generally assume that data is in a trusted state or that the device is online before being uploaded to the blockchain, failing to address the trustworthy connection during the state transition of detection data from offline collection to on-chain evidence storage, and thus failing to form a closed, trustworthy chain throughout the entire process. Summary of the Invention

[0006] Therefore, it is necessary to address the problems of low data transmission efficiency, difficulty in multi-device collaboration, and lack of reliable connection between offline data and on-chain evidence storage in existing technologies for house inspection data transmission in offline environments. This would provide a method and system for offline transmission and blockchain evidence storage of house inspection data, so as to achieve efficient visual transmission of inspection data between multiple terminals in offline environments, decentralized synchronization, and reliable on-chain anchoring of offline data.

[0007] This invention provides a method for offline transmission and blockchain storage of house inspection data, executed by a first mobile terminal, comprising: In a network-free environment, house inspection data is collected, and a chain hash is constructed sequentially for each collected inspection data. The hash value of the current inspection data is generated by calculating the hash value of the current inspection data and the hash value of the previous inspection data using a collision-avoiding hash function. The data packet to be transmitted is divided into multiple data blocks and fountain code encoded to obtain a redundant encoded packet. The redundant encoded packet is converted into a dynamic QR code image sequence and displayed frame by frame for the second mobile terminal to collect and recover the data packet to be transmitted and to perform integrity verification. The data packet to be transmitted includes at least the detection data and chain hash information reflecting the chain association relationship between each detection data. The sequence of dynamic QR code images displayed on the second mobile terminal is collected and the fountain code is decoded. The data packet to be transmitted sent by the second mobile terminal and its chain hash information are obtained. The chain hash information is then used to verify the integrity of the detection data in the obtained data packet to be transmitted. The local data version information is encoded into a version QR code and displayed. The version QR codes displayed on other mobile terminals are collected and decoded. The decoded version information of other terminals is compared with the local version information. If the local version is higher than the other party's version, the local difference data is transmitted to the other party through the dynamic QR code image sequence. If the local version is lower than the other party's version, the difference data is received from the other party and the local data is updated. After any of the mobile terminals restores network connectivity, the root hash value of the locally held chain hash is recorded to the blockchain network by calling a smart contract.

[0008] In one embodiment, the process of dividing the data packet to be transmitted into multiple data blocks further includes: The detection data is pre-compressed, wherein text data is compressed using LZMA, image data is compressed using WebP, location data is encoded using differential encoding, and signature data is compressed using PNG lossless compression.

[0009] In one embodiment, the fountain code is encoded as an LT code; the generation method of the dynamic QR code image sequence includes automatically switching between color QR code mode and black and white QR code mode according to the amount of data to be transmitted and the current environmental conditions; each QR code image adopts H-level error correction encoding and includes CRC32 check code.

[0010] In one embodiment, the chained hash is constructed as follows: The hash value of the item detection data is obtained through the formula Calculation, where For the first Item test data content, For the first The hash value of the item detection data.

[0011] In one embodiment, the local data version information is compared with the version information of other terminals. The range of data that needs to be synchronized is determined by the Merkle tree structure, and only the difference data is transmitted. When the same data is modified by multiple mobile terminals, the timestamps are compared first. If the timestamps are the same, the data of the mobile terminal that is pre-set as the master node is given priority.

[0012] In one embodiment, recording the root hash value of the locally held chain hash to the blockchain network by calling a smart contract specifically includes: During offline periods, data changes are recorded locally to construct an incremental Merkle subtree. Once the network is restored, only the root hash and the changed path of this subtree are uploaded. The smart contract verifies the legality of the path and then updates the global Merkle root. Before recording the root hash value, the contract verifies the correctness of the root hash value format and the consistency between the uploaded node timestamp and the block time.

[0013] This invention also provides an offline transmission and blockchain-based evidence storage system for house inspection data, comprising: The perception layer includes multiple mobile terminals, each equipped with a camera, a touch screen, and a local storage device, for collecting and storing house detection data locally in a network-free environment. The platform layer includes: The data fragmentation and encoding module is used to divide the data packet to be transmitted into multiple data blocks, and to encode the data blocks using fountain codes to obtain redundant encoded packets. The data packet to be transmitted includes at least the detection data and chain hash information reflecting the chained relationship between the detection data. A QR code generation module is used to convert the redundant encoding packet into a dynamic QR code image sequence and display it frame by frame on the touch screen. The scanning and decoding module is used to capture the dynamic QR code image sequence displayed by other mobile terminals through the camera and perform fountain code decoding to obtain the data packet to be transmitted from the other party and its chain hash information. The data reconstruction and verification module is used to perform integrity verification on the detection data in the acquired data packet to be transmitted using the chained hash information; The synchronization management module is used to encode local data version information into version QR codes and display them, as well as to collect and decode version QR codes displayed by other mobile terminals. The decoded version information of other terminals is compared with the local version information. If the local version is higher than the other party's version, the local difference data is transmitted to the other party through the dynamic QR code image sequence. If the local version is lower than the other party's version, the difference data is received from the other party and the local data is updated. The blockchain layer is used to record the root hash value of the chain hash held by any of the mobile terminals to the blockchain network by calling a smart contract after the mobile terminal restores its network connection.

[0014] In one embodiment, the platform layer further includes a data compression preprocessing module for compressing the detection data before segmentation encoding, wherein text data is compressed using LZMA, image data is compressed using WebP, location data is encoded using differential encoding, and signature data is compressed using PNG lossless compression.

[0015] In one embodiment, the synchronization management module includes: Device discoverer, used to discover nearby mobile devices by broadcasting and scanning QR codes; The version comparator is used to compare the local data version with other terminal versions using a Merkle tree structure to determine the differences that need to be synchronized. Synchronization protocol processor, used to perform incremental data synchronization; The conflict resolver is used to handle data conflicts according to a strategy that first compares timestamps, and if the timestamps are the same, prioritizes the mobile terminal that is pre-set as the master node.

[0016] In one embodiment, the blockchain layer is deployed on the Hyperledger Fabric consortium blockchain platform and uses the PBFT consensus algorithm to achieve data consistency among multiple nodes; the smart contract is deployed in the form of Go language chaincode.

[0017] The aforementioned offline transmission and blockchain-based evidence storage method and system for house inspection data, in a network-free environment, involves a first mobile terminal collecting house inspection data. By sequentially constructing a chain hash of each collected inspection data item, the hash value of the current inspection data is generated by concatenating the hash value of the previous inspection data with a collision-resistant hash function. Any tampering with historical data will result in changes to subsequent hash values, thus ensuring the integrity of the inspection data during the offline collection phase. During data transmission, the data packet containing the chain hash information is divided into multiple data blocks and encoded using fountain codes. The resulting redundant encoded packets are converted into a dynamic QR code image sequence displayed frame by frame for the second mobile terminal to collect and recover. Due to the characteristics of fountain code encoding, the receiving end only needs to receive slightly more encoded packets than the original data to recover all the data. This provides fault tolerance for QR code recognition defects during transmission, overcoming the limitations of traditional QR codes, which have limited single-frame data capacity and insufficient self-correction capabilities to handle consecutive frame acquisition failures. The first mobile terminal collects the dynamic QR code image sequence displayed by the second mobile terminal and decodes the fountain code. After obtaining the data from the other party, it uses the chain hash information to verify the integrity of the received detection data, thus achieving the exchange and integrity verification of detection data between terminals without relying on network infrastructure. When the first mobile terminal compares versions with other terminals, it transmits difference data to or receives difference data from the other party through the dynamic QR code image sequence based on version differences, realizing decentralized incremental synchronization only for changed data and supporting data version updates in multi-terminal collaborative operation scenarios. When any mobile terminal restores network connection, it records the root hash value of the chain hash held locally to the blockchain network by calling a smart contract, so that the chain hash built in the offline stage is connected with the on-chain evidence storage, forming a trusted data closed loop from offline collection, visual transmission to on-chain anchoring, solving the trust gap in the state migration process of detection data from offline collection to on-chain evidence storage. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a flowchart of the offline transmission and blockchain evidence storage method for house inspection data according to an embodiment of the present invention; Figure 2 This is a detailed diagram illustrating the offline data transmission implementation of an embodiment of the present invention; Figure 3This is a detailed diagram illustrating the implementation of recording the root hash value of the locally held chain hash to the blockchain network through a smart contract, according to an embodiment of the present invention. Figure 4 This is a framework diagram of an offline transmission and blockchain evidence storage system for house inspection data according to an embodiment of the present invention. Detailed Implementation

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

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0022] The following is combined Figures 1-4 This invention describes a method and system for offline transmission and blockchain-based evidence storage of house inspection data.

[0023] like Figure 1 As shown, in one embodiment, an offline transmission and blockchain-based evidence storage method for house inspection data is executed by a first mobile terminal and applied to inspection sites without network coverage, such as basements, remote rural areas, or inside historical buildings. It can be understood that in actual multi-device collaborative operations, any mobile terminal participating in the inspection can act as the first mobile terminal to execute this method.

[0024] Step S110: In a network-free environment, collect house inspection data and construct a chain hash for each collected inspection data item sequentially. The hash value of the current inspection data is generated by calculating the hash values ​​of the current and previous inspection data using a collision-avoidance hash function.

[0025] When inspectors use mobile devices to take photos of cracks, record measurement values, or enter text descriptions, a hash calculation is triggered each time a data point is collected, making the hash value of the first data point... The hash value of a data item depends not only on its own content, but also on the hash value of the first data item. The hash values ​​of each piece of data are used to form a hash chain with temporal and logical dependencies locally. Through this chain structure, in a completely offline environment without third-party timestamps or server verification, tampering, deletion, or insertion of any historical detection data will cause changes to all subsequent hash values, ensuring the data generated in the offline phase has self-verifiable integrity. It should be noted that the hash value of the first detection data is generated by calculating the collision-resistant hash value from that data using a collision-avoidance hash function.

[0026] Step S120: Divide the data packet to be transmitted into multiple data blocks and encode them with fountain codes to obtain redundant encoded packets. Convert the redundant encoded packets into dynamic QR code image sequences and display them frame by frame for the second mobile terminal to collect and recover the data packet to be transmitted and to perform integrity verification.

[0027] The data packet to be transmitted includes at least detection data and chained hash information reflecting the chained relationships between the detection data. The data packet is encapsulated using a Type-Length-Value (TLV) structure or a similar extensible serialization format to support the bundled transmission of multimodal detection data and integrity verification information. Optionally, the payload of the data packet consists of multiple consecutive data entries, each containing: a type identifier (Type) to distinguish whether the entry encapsulates original detection data, chained hash verification information, or metadata; a length field (Length) to indicate the byte length of the subsequent value field; and a value field (Value) to carry the specific content. For example, the hash value corresponding to the first detection data generated in step S110 is encapsulated as an independent TLV entry with a type identifier of a chained hash (also called a hash chain) node, and its value field records the hash value and data identifier of that detection data. After the receiver completes the decoding and reassembly of the fountain code to obtain the complete data packet, it can accurately separate the original detection data block from the chain hash information by parsing the TLV structure line by line, thereby providing deterministic data input for subsequent chain hash recalculation and comparison.

[0028] The payload data carried by each frame of the dynamic QR code image does not directly correspond to a complete redundant encoded packet, but rather includes a custom frame header structure. Specifically, the fields of this frame header include at least: a data stream identifier for identifying the data transmission batch, a fountain code parameter set for the decoder to identify the encoding parameters, and a list of 'encoded symbol identifiers' for identifying the sequence number of one or more encoded packets encapsulated in the current frame. Each redundant encoded packet generated by the fountain code encoder, along with its unique encoded symbol identifier, is encapsulated as a data unit into the frame payload area. The receiver scanning module extracts the frame header and encoded packet payload from each successfully decoded QR code, classifies the encoded packets according to the data stream identifier, and submits the extracted encoded symbol identifiers and encoded packet data to the fountain code decoder. This mapping mechanism ensures the establishment of a correct data association between the two independent processes of frame decoding and fountain code decoding, and is the technical basis for the receiver to reliably recover the original 'data packet to be transmitted' from a series of unordered captured QR code frames. Due to the lack of radio frequency communication conditions at the detection site, this embodiment utilizes the screen and camera of a mobile terminal to establish a one-way visual transmission channel. The data packet to be transmitted encapsulates the original detection result and the chain hash information generated in step S110, enabling the receiver to verify the credibility of the data source. The redundant encoded packets generated by the fountain code encoding have a rate-free characteristic, and the second mobile terminal does not need to receive them in a specific order. As long as a sufficient number of arbitrary encoded packets are collected, the original data can be recovered, adapting to possible jitter, occlusion, or frame loss during handheld device scanning. The dynamic QR code image sequence is displayed through screen refresh, converting digital signals into optical signals for spatial transmission, bypassing the dependence on radio spectrum resources such as Wi-Fi or Bluetooth.

[0029] Step S130: Collect the dynamic QR code image sequence displayed by the second mobile terminal and decode the fountain code to obtain the data packet to be transmitted sent by the second mobile terminal and its chain hash information, and use the chain hash information to perform integrity verification on the detection data in the obtained data packet to be transmitted.

[0030] This step is a mirror image of step S120, forming the basis for bidirectional data transmission. The first mobile terminal continuously captures the dynamic QR code stream displayed on the other party's screen through its camera, and obtains the business data and the chain hash maintained by the other party after decoding and reassembly. When using the chain hash information for verification, the receiver recalculates the hash value of the received data using the same hash algorithm and compares it with the chain hash carried in the data packet, thereby achieving trusted verification at the data semantic layer and ensuring that the received data is not only error-free but also the original data that has not been tampered with.

[0031] Step S140: Encode the local data version information into a version QR code and display it, and collect and decode the version QR codes displayed by other mobile terminals. Compare the decoded version information of other terminals with the local version information. If the local version is higher than the other party's version, transmit the local difference data to the other party through a dynamic QR code image sequence. If the local version is lower than the other party's version, receive the difference data from the other party and update the local data.

[0032] The local data version information is not a simple linear version number, but a structured summary of synchronization metadata. Optionally, this information includes at least: a monotonically increasing logical clock or dataset version counter, and the Merkle tree root hash value of the current local dataset. This root hash value is a top-level summary of the Merkle tree constructed from all local data items or their hash values, uniquely and irreversibly identifying the current state of the entire dataset. Correspondingly, the version QR code is a QR code generated by encoding the structured data containing this version counter and Merkle root hash. During the comparison process, the first mobile terminal decodes the other party's version QR code to obtain the other party's version counter and Merkle root hash. It first compares whether the Merkle root hashes of both parties are consistent; if they are inconsistent, a difference is determined, triggering a subsequent difference localization process based on recursive comparison of Merkle subtrees. The version counter is used to assist in deciding the priority of data flow in bidirectional synchronization scenarios.

[0033] The version QR code carries a very small amount of data, containing only summary information such as the version number and device identifier, used for rapid handshake and status comparison. The dynamic QR code image sequence serves as a heavy-load data channel, only initiating transmission after a difference is confirmed. By comparing version information, the system only transmits incremental difference data instead of the full data, reducing channel occupancy time and power consumption during visual transmission. This bidirectional difference synchronization mechanism allows inspection personnel to autonomously complete data merging and updating without server coordination, ensuring eventual data consistency during offline collaboration across multiple terminals.

[0034] When a mobile terminal generates a version QR code for device broadcasting, it utilizes its local light sensor and built-in gyroscope to obtain the current ambient light intensity and device jitter status parameters, and reads the local hardware's color decoding support identifier. These physical environment parameters and hardware capability identifiers, as handshake metadata, are encapsulated within the version QR code along with the version counter and Merkle tree root hash. Therefore, when any mobile terminal scans and decodes the other party's version QR code to complete device discovery, it can simultaneously learn about the other party's physical environment and receiving capabilities even without a network connection, providing a precise objective basis for subsequent adaptive switching of one-way visual transmission modes.

[0035] Step S150: After any mobile terminal restores its network connection, the root hash value of the locally held chain hash is recorded to the blockchain network by calling the smart contract.

[0036] The root hash is the final cumulative summary of the entire offline chain hash, representing the overall state of all detected data within that time period. When the mobile terminal returns to a network environment, the on-chain process is automatically triggered, anchoring the root hash as a digital fingerprint to the blockchain. The execution of smart contracts ensures the automation and standardization of the on-chain process, eliminating human intervention. Once the root hash is recorded on the immutable distributed ledger, all data collected offline is stored on the blockchain. Subsequent verification of offline data only requires recalculating the chain hash and comparing it with the root hash recorded on the chain, thus achieving a closed loop from offline collection and visual transmission to on-chain storage.

[0037] like Figure 2 As shown, in one embodiment, the specific implementation details of offline data transmission and integrity verification are further defined. Before dividing the data packet to be transmitted into multiple data blocks, the detection data is further compressed and preprocessed, wherein text data is compressed using LZMA, image data is compressed using WebP, location data is differentially encoded, and signature data is compressed using PNG lossless compression.

[0038] Building inspection data exhibits multimodal characteristics. For text data such as inspection reports and notes, the LZMA algorithm offers a high compression ratio, reducing byte size. For image data such as cracks and leaks captured on-site, WebP reduces file size compared to JPEG at the same image quality and supports alpha channels, balancing visual recognition needs with transmission efficiency. For location data such as GPS coordinates, since adjacent collection points typically have spatial continuity, differential encoding records only relative offsets, eliminating redundant information in absolute coordinates. For legally binding signature data such as handwritten signatures and seals, PNG lossless compression format is used to ensure zero loss of pen stroke edges and pressure sensitivity details, avoiding the impact of lossy compression on subsequent identification or verification. Through categorized differential preprocessing, data is lightweighted before entering the encoding and transmission stage, providing a foundation for transmitting more effective payload in the limited bandwidth of the visual channel.

[0039] After data preprocessing, the fountain code encoding adopts LT code; the generation of dynamic QR code image sequences includes automatic switching between color QR code mode and black and white QR code mode according to the amount of data to be transmitted and the current environmental conditions; each QR code image adopts H-level error correction coding and includes CRC32 check code. As a rateless erasure code, LT code allows the transmitter to continuously generate encoded packets, and the receiver only needs to collect any number of encoded packets slightly more than the original data block to recover the original data, naturally adapting to non-ideal channels such as frame loss and out-of-order delivery when scanning with handheld devices. Regarding the selection of the QR code carrier, before generating the dynamic QR code image sequence, the system obtains the total amount of data to be transmitted and extracts conditions such as ambient light intensity, jitter parameters, and color decoding capability obtained from the receiving end during the early device discovery and handshake phases. When the data volume exceeds a preset threshold and the ambient light is sufficient, and the receiving device supports color decoding, it automatically switches to color QR code mode, using the color dimension to expand the information density. When the ambient light is dim, the device jitter is severe, or the receiving end does not support color recognition, it automatically downgrades to black and white QR code mode, sacrificing some transmission rate for higher recognition robustness. Each frame of the QR code image is superimposed with H-level error correction coding and CRC32 check code for dual protection. H-level error correction provides approximately 30% area fault tolerance to resist physical layer damage such as screen reflection and dirt obstruction, while CRC32 check code is used to verify the bit-level integrity of the data block after decoding, eliminating erroneous data caused by decoding misjudgment.

[0040] To ensure the sending end can reliably obtain the aforementioned switching conditions in a network-free environment, the sending and receiving ends reuse the version QR code interaction process to conduct offline handshake negotiation of the physical environment and device capabilities before transmitting large amounts of business data via dynamic QR code image sequences. The receiving mobile terminal uses its local light sensor to obtain the current ambient light intensity parameters, uses its built-in gyroscope or accelerometer to assess the device's current jitter parameters, and reads the local camera resolution and the system's support for color decoding. Subsequently, the receiving end encapsulates these environmental parameters and capability identifiers as handshake metadata, along with a version counter and a Merkle tree root hash, to generate and display a version QR code. After the sending end scans and decodes this version QR code with its camera, it extracts the aforementioned handshake metadata, thereby accurately knowing the receiving end's environmental physical conditions and hardware decoding capabilities even without a network connection. This information serves as the precise input for executing the color and black-and-white QR code mode switching logic when subsequently generating dynamic QR code image sequences.

[0041] In terms of data integrity verification, chained hashing is constructed as follows: the hash value of the nth item being checked is calculated using the following formula: , in, For the nth detection data item, The hash value of the (n-1)th detection data item, symbol This indicates data splicing. The formula defines a strict unidirectional dependency. For example, when inspectors sequentially collect photos of cracks in the living room ( ), Bedroom humidity readings ( ) and records of hollow tiles in the kitchen ( When considering three data points, the system first calculates... The SHA256 value is Then and After concatenation, SHA256 operation is performed to obtain Finally and splicing operation yields In this chain structure, Not only includes Its own information also implies and All historical information. If early information is tampered with... The result of recalculation Will be with the original Differences, which in turn lead to , All changes occur and cannot be matched with the root hash anchored locally or on-chain. This mechanism ensures that any change to historical data is captured by all subsequent hash values, enabling self-verification of data sequence integrity through local computation alone, even in a network-free environment, without relying on external timestamp servers or centralized databases.

[0042] In one embodiment, the comparison of local data version information with other terminal version information is further limited. A Merkle tree structure is used to determine the range of data to be synchronized, and only differing data is transmitted. When the same data is modified by multiple mobile terminals, timestamps are compared first; if the timestamps are the same, the data from the mobile terminal pre-set as the master node takes priority. In multi-device collaborative operations in a network-free environment, the data sets maintained by each mobile terminal may diverge due to independent collection, making traditional line-by-line comparison inefficient. This embodiment uses a Merkle tree as the core data structure for version comparison, treating each piece of detection data or its hash value as a leaf node. The hash of the parent node is calculated layer by layer from bottom to top until a unique root hash is generated. This root hash represents the overall state fingerprint of the dataset held by the current device. During synchronization, the mobile terminal first displays a version QR code containing the local Merkle tree root hash and key metadata on its screen for other terminals to scan and obtain. After decoding, the receiver compares the other party's root hash with its local root hash. If they match, it indicates that the data is fully synchronized. If they do not match, a recursive comparison of subtree hashes is used to locate the specific leaf node that has changed in logarithmic time complexity, thereby accurately identifying the difference data items that need to be synchronized. Specifically, the recursive comparison of subtree hashes is implemented through an offline visual request-response protocol for version QR codes: when the receiver finds that the root hash is inconsistent, it encapsulates the node level and node index that it judges to be inconsistent into a sub-version QR code containing a synchronization request instruction and displays it on the screen. After scanning and parsing the instruction, the sender extracts the hash value of the child node at the corresponding level and encapsulates it into a response QR code for display. The two parties alternately send and receive to complete a shallow comparison. To avoid the time consumption and device alignment difficulties caused by multiple rounds of visual interaction in a deep tree structure, the system sets a visual interaction threshold: when the number of inconsistent child nodes exceeds a preset threshold or the recursion depth reaches a set number of levels, the sender directly extracts the locally maintained incremental Merkle subtree (including the affected leaf nodes and hashes of all ancestor nodes), packages it, and transmits it in a one-time one-way broadcast via a dynamic QR code image sequence; the receiver, after fully receiving the incremental subtree using the scanning decoding module, directly completes the traversal and comparison of the remaining levels in its local memory. This cryptographic digest-based level comparison mechanism allows the system to complete the global state consistency detection through lightweight version QR code interaction, avoiding the blind transmission of the entire data over the visual channel.

[0043] After determining the range of differing data, the system only initiates the transmission process for the data content corresponding to these changed leaf nodes. The sender packages the differing data and transmits it unidirectionally via the aforementioned dynamic QR code image sequence. The receiver decodes the data, merges it into the local dataset, and recalculates the Merkle tree root hash to complete incremental synchronization. It is understood that although this embodiment uses a Merkle tree as an example to illustrate the implementation of version comparison and incremental synchronization, similar functions can be achieved in other embodiments using Bloom filters, inverted indexes, or other data structures capable of expressing set differences, as long as they can support the exchange of summary information and location of differing data via visual channels in an offline environment. The interaction of version QR codes is not limited to a request-response model. Each mobile terminal can periodically broadcast its own version QR code during idle periods or actively trigger comparison when a new device is detected nearby. This decentralized interaction method eliminates the dependence on a central coordination server.

[0044] To address potential data conflicts in multi-device offline collaboration—specifically, when the same detection data item is modified by two or more mobile terminals at different times or locations—this embodiment employs a tiered conflict resolution strategy. When multiple versions of the same data item are detected through Merkle tree comparison, the generation timestamps of each version are first compared, retaining the version with the newest timestamp to ensure data timeliness. Considering that local clocks on each device may drift or be manually adjusted in an offline environment, when multiple versions have the same timestamp or fall within a preset tolerance window, a second-level criterion is activated: prioritizing data from the mobile terminal pre-designated as the master node. The master node is a mobile terminal assigned higher data priority in multi-terminal collaborative operations. For example, during project initialization, the terminal of the project manager is designated as the master node, or the terminal of the person in charge of a specific region is designated as the master node for data within that region. Through this dual mechanism of timestamp priority and master node fallback, data from multiple terminals can ultimately converge to a consistent state that conforms to business logic, without the intervention of an arbitration server.

[0045] like Figure 3As shown, in one embodiment, the specific implementation method of recording the root hash value of the locally held chain hash to the blockchain network by calling a smart contract is further defined. Data changes during offline periods construct an incremental Merkle subtree locally. After network recovery, only the root hash and change path of this subtree are uploaded. In a house inspection scenario, a single inspection task may generate a large number of data records. If the entire data or the entire Merkle tree is uploaded to the blockchain every time a connection is established, it will face high gas fees and network bandwidth consumption. In this embodiment, during offline operation, the mobile terminal not only maintains the chain hash but also synchronously maintains a complete local Merkle tree. Whenever new inspection data is written or existing data is modified, the system only recalculates the hash values ​​of the affected leaf nodes and all their ancestor nodes, and caches the hashes of these changed nodes and their corresponding sibling nodes, forming a sparse incremental Merkle subtree. When the mobile terminal restores network connection and triggers the on-chain process, only the root hash of this incremental Merkle subtree and the change path that can prove its legitimacy are packaged and sent to the blockchain node. This process decouples the amount of data on-chain from the total data size, and is only logarithmically related to the frequency of changes during offline periods, reducing storage costs and transaction latency while ensuring data verifiability.

[0046] After data is submitted to the blockchain network, the smart contract verifies the legality of the path and updates the global Merkle root. Before recording the root hash value, it verifies the correctness of the root hash value's format and the consistency between the upload node's timestamp and the block time. This verification process is crucial to ensuring the trustworthiness of the on-chain state. First, the contract verifies the format of the received root hash value, confirming that its length and encoding method conform to a preset standard (such as a 32-byte hexadecimal string of SHA256), avoiding subsequent verification failures or contract state corruption due to format errors. Second, the contract reads the upload node's timestamp attached to the transaction and compares it with the current block time. If the deviation exceeds a preset threshold (e.g., ±5 minutes), it determines that the transaction may have a replay attack risk or a serious device clock offset, automatically rejecting the on-chain request to ensure the objective authenticity of the data's timing. Finally, the contract uses the global Merkle root hash stored on-chain and the submitted change path to recalculate the expected new root hash and compares it with the submitted incremental subtree root hash. Only when the two are completely consistent is the data change during the offline period confirmed as legal and complete, thus atomically updating the global Merkle root. Through a triple verification mechanism of format, timing, and cryptographic proof, the system achieves seamless integration between the offline data collection environment and the on-chain trusted environment, ensuring that data generated offline acquires the same level of tamper-proof capability as online data after being connected to the network.

[0047] In addition, the present invention also provides an offline transmission and blockchain evidence storage system for house inspection data.

[0048] like Figure 4 As shown in one embodiment, an offline transmission and blockchain evidence storage system for house inspection data adopts a layered modular architecture, including a perception layer, a platform layer, and a blockchain layer. The layers are connected through standardized data interfaces and communication protocols to support data acquisition, visual transmission, multi-terminal synchronization, and trusted evidence storage in a network-free environment.

[0049] The perception layer comprises multiple mobile terminals, each equipped with a camera, touchscreen, and local storage, used for acquiring and storing building inspection data in offline environments. As the physical carrier and human-machine interface of the system, the mobile terminals are selected with hardware adapted to the specific working conditions of the building inspection site. The camera is used to acquire inspection images and scan dynamic QR codes, supporting high frame rate video stream acquisition to provide a stable image source for decoding dynamic QR codes. The touchscreen displays the inspection interface and acts as the transmitter of dynamic QR code image sequences; its refresh rate and brightness meet the channel requirements for visual transmission. The local storage uses large-capacity flash memory to cache inspection data generated during offline periods and metadata such as chained hashes and Merkle trees, ensuring data integrity even in network-disconnected environments. The mobile terminals can be tablets, smartphones, or industrial handheld terminals, or other devices with image acquisition, display, and storage capabilities.

[0050] The platform layer includes a data fragmentation and encoding module, a QR code generation module, a scanning and decoding module, a data reassembly and verification module, and a synchronization management module. The data fragmentation and encoding module divides the data packet to be transmitted into multiple data blocks, performs fountain code encoding on the data blocks to obtain redundant encoded packets. The data packet to be transmitted includes at least detection data and chained hash information reflecting the chained relationships between the detection data. The QR code generation module converts the redundant encoded packets into a dynamic QR code image sequence and displays it frame by frame on the touchscreen. The scanning and decoding module uses a camera to capture dynamic QR code image sequences displayed on other mobile terminals and performs fountain code decoding to obtain the other party's data packet to be transmitted and its chained hash information. The data reassembly and verification module uses the chained hash information to perform integrity verification on the detection data in the acquired data packet to be transmitted. These four modules constitute a complete unidirectional visual transmission pipeline. Data flows through fragmentation, encoding, display, acquisition, decoding, reassembly, and verification stages, achieving reliable conversion from digital signals to optical signals and back to digital signals. In terms of specific implementation, each module can adopt independent software components or hardware acceleration units. For example, the scanning and decoding module can call the mobile terminal's GPU or NPU for real-time image processing to reduce CPU load and improve the decoding frame rate.

[0051] The platform layer also includes a data compression preprocessing module, used to compress the detection data before fragmentation encoding. Text data uses LZMA compression, image data uses WebP compression, location data uses differential encoding, and signature data uses PNG lossless compression. This module is located before the data fragmentation encoding module in the data flow, serving as the entry-level optimization unit of the transmission link. It integrates multiple heterogeneous compression engines and automatically routes data to the corresponding processing channel based on data type identifiers.

[0052] The synchronization management module comprises four sub-units: a device discoverer, a version comparator, a synchronization protocol processor, and a conflict resolver. The device discoverer discovers nearby mobile terminals via QR code broadcasting and scanning. It periodically controls the touchscreen to display a version QR code containing the device ID and status summary, and drives the camera to identify similar signals within its field of view, establishing topology awareness of nearby devices even without radio frequency communication. The version comparator compares the local data version with other terminal versions using a Merkle tree structure to determine the difference data that needs to be synchronized. Internally, it maintains a Merkle tree instance that is linked to the local dataset in real time, cryptographically pinpointing the scope of changes by comparing root hashes and recursively searching subtrees. The synchronization protocol processor performs incremental data synchronization. Based on the output of the version comparator, it schedules the data fragmentation and encoding module and the QR code generation module to package and send only the difference data, or controls the scanning and decoding module to receive missing data in a targeted manner. The conflict resolver is used to handle data conflicts according to a strategy of first comparing timestamps, and if the timestamps are the same, the mobile terminal that is set as the master node is given priority. When multiple versions of the same data item are detected to be competing, the resolver automatically decides the winner according to the preset rules and feeds back the decision to the synchronization protocol processor to update the local state.

[0053] The blockchain layer is used to record the root hash value of the chained hash held by any mobile terminal to the blockchain network by calling a smart contract after the mobile terminal restores its network connection. The blockchain layer is deployed on the Hyperledger Fabric consortium blockchain platform and uses the PBFT consensus algorithm to achieve data consistency among multiple nodes; the smart contract is deployed in Go language chaincode. Fabric's channel mechanism effectively isolates the data privacy of different detection projects; the PBFT consensus algorithm provides Byzantine fault tolerance and high transaction confirmation efficiency; the Go language chaincode encapsulates business logic such as data anchoring, format verification, timestamp comparison, and global Merkle root update. In other implementations, consortium blockchain platforms such as FISCOBCOS and XuperChain, or consensus algorithms such as Raft and HotStuff, can be selected according to the actual trust model and performance requirements.

[0054] Through the above architecture, the system has built a complete technical closed loop from physical perception, data processing, decentralized synchronization to trusted evidence storage.

[0055] In one specific embodiment, an application example of an offline transmission and blockchain-based evidence storage method for building inspection data is provided in a business scenario, aiming to illustrate the operational logic and technical effects of the technical solutions described in the foregoing embodiments under conditions such as basement inspection without network access and multi-floor collaborative operations.

[0056] Scenario 1: Offline sharing and subsequent evidence storage of inspection data in environments with no network coverage, such as basements of old buildings. After completing structural inspections, inspectors used mobile terminals to collect multiple data items, including photos of on-site cracks, measurement records, and handwritten signature confirmations. The system first performs differential processing on the data based on compression preprocessing: photos are compressed using WebP, text records are compressed using the LZMA algorithm, location coordinates are differentially encoded, and signature data is compressed using PNG lossless compression. After preprocessing, the batch of inspection data has been sequentially chained into hashes for each data item, forming a complete offline trust chain.

[0057] During the data transmission phase, given the large data volume and the receiving device's support for color decoding, the system automatically switched to color QR code mode. In actual transmission, slight shaking caused by personnel walking with the device and uneven lighting in the basement resulted in some QR code frames failing to be successfully recognized or decoded. At this point, the LT code fountain code encoding mechanism came into play: the receiving end did not need to request retransmission of specific lost frames, but only needed to continue collecting subsequent redundant encoded packets. When the cumulative number of received valid encoded packets slightly exceeded the total number of original data fragments, the decoding algorithm could completely recover all the original data. After data recovery, the system used the chained hash information carried in the data packets for integrity verification, confirming that the data had not been tampered with during offline transmission, thus achieving reliable delivery of large volumes of detection data even under harsh physical conditions.

[0058] Scenario 2: Distributed Detection and Real-Time Collaborative Operations Across Multiple Floors in a Large Commercial Complex. This project involves multiple detection teams working in parallel on different floors, each equipped with a mobile terminal. Decentralized device discovery and status synchronization are achieved between terminals via version QR codes. When a detection team on a particular floor completes a phase of work, its mobile terminal displays a version QR code containing the local Merkle tree root hash. Adjacent floors or project leaders scan this QR code and compare the other party's root hash with their local root hash. If they do not match, the system recursively searches the Merkle tree to quickly locate the changed leaf nodes and initiates incremental synchronization requests only for these discrepancies, avoiding the duplicate transmission of all data.

[0059] During the collaboration process, if the same detection item is modified by multiple terminals, the system handles it according to the conflict resolution strategy: First, it compares the timestamps of each version and retains the newest version; if the timestamps are the same or within the tolerance range, the data from the mobile terminal pre-set as the master node (such as the project leader's terminal) takes precedence. Once all detection tasks are completed and the mobile terminal regains network connectivity, the incremental on-chain process is triggered: only the root hash and change path of the incremental Merkle subtree built during offline operations are uploaded to the consortium blockchain. After verifying the path's legality, format correctness, and timestamp consistency, the smart contract updates the global Merkle root and generates a certificate of authenticity. The final generated detection report includes a verification QR code, which third parties can scan to query the on-chain records and verify the integrity and authenticity of the report data, thus achieving closed-loop management of the entire process from offline collection and multi-terminal collaboration to on-chain certificate of authenticity.

[0060] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0061] The above-described embodiments are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

Claims

1. A method for offline transmission and blockchain-based evidence storage of house inspection data, characterized in that, Executed by the first mobile terminal, including: In a network-free environment, house inspection data is collected, and a chain hash is constructed sequentially for each collected inspection data. The hash value of the current inspection data is generated by calculating the hash value of the current inspection data and the hash value of the previous inspection data using a collision-avoiding hash function. The data packet to be transmitted is divided into multiple data blocks and fountain code encoded to obtain a redundant encoded packet. The redundant encoded packet is converted into a dynamic QR code image sequence and displayed frame by frame for the second mobile terminal to collect and recover the data packet to be transmitted and to perform integrity verification. The data packet to be transmitted includes at least the detection data and chain hash information reflecting the chain association relationship between each detection data. The sequence of dynamic QR code images displayed on the second mobile terminal is collected and the fountain code is decoded. The data packet to be transmitted sent by the second mobile terminal and its chain hash information are obtained. The chain hash information is then used to verify the integrity of the detection data in the obtained data packet to be transmitted. The local data version information is encoded into a version QR code and displayed. The version QR codes displayed on other mobile terminals are collected and decoded. The decoded version information of other terminals is compared with the local version information. If the local version is higher than the other party's version, the local difference data is transmitted to the other party through the dynamic QR code image sequence. If the local version is lower than the other party's version, the difference data is received from the other party and the local data is updated. After any of the mobile terminals restores network connectivity, the root hash value of the locally held chain hash is recorded to the blockchain network by calling a smart contract.

2. The method for offline transmission and blockchain storage of house inspection data according to claim 1, characterized in that, The step of dividing the data packet to be transmitted into multiple data blocks also includes: The detection data is pre-compressed, wherein text data is compressed using LZMA, image data is compressed using WebP, location data is encoded using differential encoding, and signature data is compressed using PNG lossless compression.

3. The method for offline transmission and blockchain storage of house inspection data according to claim 1, characterized in that, The fountain code is encoded as LT code; the generation method of the dynamic QR code image sequence includes automatically switching between color QR code mode and black and white QR code mode according to the amount of data to be transmitted and the current environmental conditions; each QR code image adopts H-level error correction encoding and includes CRC32 check code.

4. The method for offline transmission and blockchain storage of house inspection data according to claim 1, characterized in that, The chain hash is constructed as follows: The hash value of the item detection data is obtained through the formula Calculation, where For the first Item test data content, For the first The hash value of the item detection data.

5. The method for offline transmission and blockchain storage of house inspection data according to claim 1, characterized in that, The comparison of local data version information with other terminal version information uses a Merkle tree structure to determine the range of data that needs to be synchronized, and only transmits the difference data. When the same data is modified by multiple mobile terminals, the timestamps are compared first. If the timestamps are the same, the data of the mobile terminal that is pre-set as the master node takes priority.

6. The method for offline transmission and blockchain storage of house inspection data according to claim 1, characterized in that, The step of recording the root hash value of the locally held chain hash to the blockchain network by calling a smart contract includes: During offline periods, data changes are recorded locally to construct an incremental Merkle subtree. Once the network is restored, only the root hash and the changed path of this subtree are uploaded. The smart contract verifies the legality of the path and then updates the global Merkle root. Before recording the root hash value, the contract verifies the correctness of the root hash value format and the consistency between the uploaded node timestamp and the block time.

7. An offline transmission and blockchain-based evidence storage system for house inspection data, characterized in that, include: The perception layer includes multiple mobile terminals, each equipped with a camera, a touch screen, and a local storage device, for collecting and storing house detection data locally in a network-free environment. The platform layer includes: The data fragmentation and encoding module is used to divide the data packet to be transmitted into multiple data blocks, and to encode the data blocks using fountain codes to obtain redundant encoded packets. The data packet to be transmitted includes at least the detection data and chain hash information reflecting the chained relationship between the detection data. A QR code generation module is used to convert the redundant encoding packet into a dynamic QR code image sequence and display it frame by frame on the touch screen. The scanning and decoding module is used to capture the dynamic QR code image sequence displayed by other mobile terminals through the camera and perform fountain code decoding to obtain the data packet to be transmitted from the other party and its chain hash information. The data reconstruction and verification module is used to perform integrity verification on the detection data in the acquired data packet to be transmitted using the chained hash information; The synchronization management module is used to encode local data version information into version QR codes and display them, as well as to collect and decode version QR codes displayed by other mobile terminals. The decoded version information of other terminals is compared with the local version information. If the local version is higher than the other party's version, the local difference data is transmitted to the other party through the dynamic QR code image sequence. If the local version is lower than the other party's version, the difference data is received from the other party and the local data is updated. The blockchain layer is used to record the root hash value of the chain hash held by any of the mobile terminals to the blockchain network by calling a smart contract after the mobile terminal restores its network connection.

8. The offline transmission and blockchain-based evidence storage system for house inspection data according to claim 7, characterized in that, The platform layer also includes a data compression preprocessing module, which is used to compress the detection data before segmentation encoding. The text data uses LZMA compression, the image data uses WebP compression, the location data uses differential encoding, and the signature data uses PNG lossless compression.

9. The offline transmission and blockchain-based evidence storage system for house inspection data according to claim 7, characterized in that, The synchronization management module includes: Device discoverer, used to discover nearby mobile devices by broadcasting and scanning QR codes; The version comparator is used to compare the local data version with other terminal versions using a Merkle tree structure to determine the differences that need to be synchronized. Synchronization protocol processor, used to perform incremental data synchronization; The conflict resolver is used to handle data conflicts according to a strategy that first compares timestamps, and if the timestamps are the same, prioritizes the mobile terminal that is pre-set as the master node.

10. The offline transmission and blockchain-based evidence storage system for house inspection data according to claim 7, characterized in that, The blockchain layer is deployed on the Hyperledger Fabric consortium blockchain platform and uses the PBFT consensus algorithm to achieve data consistency among multiple nodes; the smart contracts are deployed in the form of Go language chaincode.

Images