Internet of Things data security sharing method and system based on hybrid private chain and alliance chain

Abstract

The invention provides a hybrid private chain and alliance chain-based Internet of Things data security sharing method and system, and belongs to the technical field of block chains, Internet of Things and cloud computing, and the method comprises the steps: deploying a private chain, and taking an alliance chain as a mutual trust coordination layer to achieve registration anchoring and interoperation of multi-chain data; a parallel HTLC channel and a dynamic time lock mechanism guarantee atomic exchange and efficient transmission of cross-chain data, and meanwhile, safe and credible data sharing is realized in combination with multi-party threshold notarization and zero-knowledge proof; the intelligent gateway layer provides protocol adaptation, format conversion, machine learning caching and intelligent access control, and optimizes a data publishing and prefetching process; the light client only reserves a block head and a Merkle index, and incremental verification and multi-path synchronization are carried out; the homomorphic encryption and parallel zero-knowledge proof framework gives consideration to data privacy and on-chain auditing performance, and it is ensured that limiting value judgment and compliance auditing are carried out in a ciphertext state. According to the method, credible, efficient and auditable data cross-chain sharing is realized.

Description

Technical Field

[0001] This invention belongs to the fields of blockchain, Internet of Things (IoT) and cloud computing technology, and specifically relates to a method and system for secure data sharing in the Internet of Things based on a hybrid private chain and consortium chain. Background Technology

[0002] With the rapid proliferation of IoT devices, data is experiencing explosive growth. Due to the distributed nature, real-time nature, and sensitivity of IoT data, higher demands are placed on its management, privacy protection, and sharing mechanisms. Traditional centralized data platforms struggle to address the following issues:

[0003] 1. Insufficient privacy protection: The central server is at risk of being attacked as a single point of vulnerability, and data is easily leaked.

[0004] 2. Lack of cross-domain trust: There is a lack of secure and effective data sharing mechanisms between different institutions or platforms.

[0005] 3. Lack of audit traceability: Data modification is not traceable, leading to ineffective supervision and unclear responsibilities.

[0006] In recent years, blockchain technology has been widely used to solve the aforementioned problems, and its distributed, immutable, and traceable characteristics have provided new ideas for IoT data management. However, a single public chain, consortium chain, or private chain struggles to meet the balance requirements of "privacy protection" and "transparency." Hybrid chain architectures have become a research hotspot, but the following problems still exist in practical deployments:

[0007] 1. Private blockchains are difficult to communicate with each other directly, resulting in severe data isolation;

[0008] 2. Cross-chain communication is inefficient and has high latency;

[0009] 3. Lack of standardized secure sharing mechanisms;

[0010] 4. Lightweight nodes have limited device resources, making it difficult to complete complex interactive verifications.

[0011] Therefore, there is an urgent need for an efficient cross-chain sharing method and system that balances privacy, interoperability, and security. Summary of the Invention

[0012] To address the aforementioned technical problems, this invention provides a method for secure data sharing in the Internet of Things (IoT) based on a hybrid private blockchain and consortium blockchain, comprising the following steps:

[0013] Step S1: Deploy multiple industry / organization-level private chains in the hybrid blockchain network layer, and use a consortium blockchain as a mutual trust anchoring layer; the private chains and the consortium blockchains are aligned in state and managed in a controllable manner through a hierarchical structure of core and auxiliary parts;

[0014] Step S2: In the cross-chain service layer, based on the parallel hash time lock contract HTLC channel, dynamic time lock and multi-party threshold signature mechanism, atomic data exchange and high availability transmission between private chains are realized. The number of parallel HTLC channels opened and the timeout parameters are automatically adjusted according to the on-chain load and off-chain reputation.

[0015] Step S3: Set up protocol adaptation, data format conversion, machine learning prediction caching and policy decision modules in the smart gateway layer to support multi-protocol access and perform off-chain prefetching and local Merkle verification based on the heat model;

[0016] Step S4: In the light client layer, only the block header and Merkle index are retained, and filtered through multi-source parallel incremental synchronization and Bloom filter;

[0017] Step S5: In the security and privacy protection layer, zk-SNARK or zk-STARK zero-knowledge proofs without trusted settings are combined with Paillier / CKKS homomorphic encryption to complete threshold comparison and statistical calculation in ciphertext state, and record auditable logs through threshold signature.

[0018] Beneficial effects:

[0019] This invention provides a method for secure data sharing in the Internet of Things based on a hybrid private blockchain and consortium blockchain, which has the following advantages:

[0020] 1. High availability and disaster recovery capability: Parallel HTLC channels and multi-path disaster recovery design enable the system to switch smoothly when a single chain or a single node fails, ensuring a cross-chain success rate of over 99.9%.

[0021] 2. Low resource consumption: The smart gateway introduces heat prediction caching and incremental Merkle indexing, and only performs on-chain interaction for high-frequency data. At the same time, the daily incremental data synchronization of light clients does not exceed tens of KB, and the terminal resource consumption is less than 8 MB of memory and 30 MB of storage.

[0022] 3. Dynamically Scalable: The modular design allows for automatic scaling up and down during peak business periods: adding parallel HTLC channels, expanding cache nodes, and adding light client instances can linearly scale the system load horizontally.

[0023] 4. Balancing Privacy and Compliance: Only minimal proofs (hashes, digests, ZKP proofs) are stored on-chain, while the actual sensitive original text always remains on the private chain or gateway side. Combined with on-chain audit contracts, falsifiable compliance reports can be exported at any time to meet regulatory and legal evidence collection needs. Attached Figure Description

[0024] Figure 1This is a schematic diagram of a method for securely sharing IoT data based on a hybrid private blockchain and consortium blockchain according to the present invention.

[0025] Figure 2 This is a schematic diagram of the overall architecture of the method of the present invention;

[0026] Figure 3 This is a schematic diagram of the intelligent gateway module structure;

[0027] Figure 4 This is a schematic diagram of the data verification process for a lightweight client.

[0028] Figure 5 A schematic diagram illustrating multi-party threshold signatures and anchoring in cross-chain transactions;

[0029] Figure 6 This is a structural block diagram of an IoT data security sharing system based on a hybrid private blockchain and consortium blockchain according to the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0031] Example 1

[0032] like Figure 1 As shown in the figure, an embodiment of the present invention provides a method for secure data sharing in the Internet of Things based on a hybrid private blockchain and a consortium blockchain, comprising the following steps:

[0033] Step S1: Deploy multiple industry / organization-level private chains in the hybrid blockchain network layer, and use a consortium blockchain as a mutual trust anchoring layer; the private chains and consortium blockchains are aligned and managed in a controlled manner through a hierarchical structure of core and auxiliary parts;

[0034] Step S2: In the cross-chain service layer, based on the parallel hash time lock contract HTLC channel, dynamic time lock and multi-party threshold signature mechanism, atomic data exchange and high availability transmission between private chains are realized. The number of parallel HTLC channels opened and the timeout parameters are automatically adjusted according to the on-chain load and off-chain reputation.

[0035] Step S3: Set up protocol adaptation, data format conversion, machine learning prediction caching and policy decision modules in the smart gateway layer to support multi-protocol access and perform off-chain prefetching and local Merkle verification based on the heat model;

[0036] Step S4: In the light client layer, only the block header and Merkle index are retained, and filtered through multi-source parallel incremental synchronization and Bloom filter;

[0037] Step S5: In the security and privacy protection layer, zk-SNARK or zk-STARK zero-knowledge proofs without trusted settings are combined with Paillier / CKKS homomorphic encryption to complete threshold comparison and statistical calculation in ciphertext state, and record auditable logs through threshold signature.

[0038] Figure 2 This is a schematic diagram of the overall architecture of the method of the present invention.

[0039] In one embodiment, the hybrid blockchain network layer of step S1 above specifically includes:

[0040] In the hybrid blockchain network layer, the private chain uses an off-chain listener to package the block header hash and Merkle root, and then periodically submits it to the AnchorContract contract on the consortium chain, combined with state channels, batch anchoring, and an updatable block structure.

[0041] The hybrid blockchain network layer of this invention combines private blockchains within organizations with consortium blockchains across organizations, ensuring both the privacy and high performance of local IoT data while providing trusted anchoring and auditing capabilities for cross-domain data. This layer carries the isolated data storage of private blockchains and the global consensus mechanism of consortium blockchains, and realizes inter-chain registration and anchoring between the two, forming an underlying network system that balances privacy protection and interoperability.

[0042] 1. The architecture of the hybrid blockchain network layer adopts:

[0043] 1) Multi-level isolation and collaboration: In the hybrid blockchain network layer, the private chain is responsible for data collection and storage within the industry or organization. Nodes are only visible in the authorized internal network, ensuring data isolation and controllable access.

[0044] 2) Consortium Blockchain Mutual Trust Hub: The consortium blockchain is jointly maintained by multiple core nodes (such as regulatory agencies, notary organizations, and leading enterprises in the industry). Based on the Byzantine Fault Tolerance (PBFT / HotStuff) consensus algorithm, it provides global sharing of cross-private chain state anchoring, transaction records, and audit logs.

[0045] 3) Inter-chain registration and anchoring: Private chains periodically submit block header hashes or Merkle roots to the anchoring contract of consortium chains through off-chain listening, thereby achieving cross-chain state alignment and historical traceability.

[0046] 2. Private blockchain network with hybrid blockchain network layer:

[0047] 1) Deployment Model:

[0048] Divided by organization / industry: Each participant (such as hospitals, insurance companies, traffic management, etc.) deploys a private chain according to its business boundaries. Nodes can be deployed in a dedicated VPN or internal data center, supporting flexible expansion;

[0049] Consensus mechanism selection: Lightweight PBFT, PoA (Proof of Authority) or PoET (Proof of Elapsed Time) are adopted to ensure data consistency while maintaining high throughput, with typical TPS reaching thousands to tens of thousands.

[0050] 2) Data encryption and storage:

[0051] Symmetric + Asymmetric hybrid encryption: Sensitive raw data is encrypted using AES-256 before the device is on-chain, and then the encrypted data hash is digitally signed using the device's private key. The encrypted data and signature are stored on-chain.

[0052] Data sharding and hierarchical classification: For data of different sensitivity levels (such as patient personal information and environmental monitoring data), multi-level storage strategies can be set up within the private chain to achieve sharded storage and access control;

[0053] 3) Off-chain listening and contract triggering:

[0054] Event listening service: Private chain nodes need to deploy off-chain listeners to capture new block headers and transaction events in real time, and send the hash information to the cross-chain service layer via RPC / REST interface;

[0055] Local caching and retry mechanism: To prevent anchoring failures due to network jitter, the listening service supports local transaction buffering and continuously attempts to submit anchoring transactions under the set retry policy.

[0056] 3. Consortium blockchain coordination:

[0057] 1) Consensus and Governance:

[0058] Multi-party consensus network: Consortium blockchain nodes are typically composed of industry regulatory agencies, core enterprises, and notary institutions, and use PBFT or HotStuff algorithms to achieve sub-second confirmation;

[0059] Dynamic node management: Through on-chain governance contracts, dynamic voting, permission allocation, and punishment mechanisms for adding and removing nodes are supported to ensure network autonomy and security.

[0060] 2) Anchor Contract:

[0061] The contract interface is shown below:

[0062] functionregisterAnchor(uint256chainId,bytes32blockHash,bytes32merkleRoot,uint256timestamp)external;

[0063] functiongetAnchor(uint256chainId,uint256version)externalviewreturns(bytes32blockHash,bytes32merkleRoot,uint256timestamp);

[0064] Data Structures:

[0065] The contract internally maintains mapping(uint256=>Anchor[])anchors, where Anchor contains fields such as blockHash, merkleRoot, timestamp, and submitter.

[0066] Event Announcement:

[0067] Each call to registerAnchor will trigger the AnchorRegistered event, which facilitates asynchronous listening and auditing.

[0068] 3) Security and Attack Resistance:

[0069] Signature verification: Before the contract is written, it must verify that the submitter holds the signature of the authorized private chain node and verify the validity of the timestamp;

[0070] Anti-reentrancy and anti-fraud measures: The contract uses the OpenZeppelin security library to implement anti-reentrancy lock (ReentrancyGuard) and whitelist / blacklist access control to prevent malicious fraud or repeated anchoring.

[0071] 4) Inter-chain registration and verification process:

[0072] Private chain consensus completes a new block: Nodes package the block header hash and Merkle root into anchor data. Off-chain listening and transaction packaging: The listening service constructs a registerAnchor transaction and signs the data within it. Consortium chain anchor writing: After verifying the signature and timestamp, the consortium chain writes the anchor data to the contract and triggers an event. Receipt and confirmation: The private chain listening service receives the on-chain receipt and updates the local anchor state version number. Cross-chain verification: The cross-chain service or light client, based on the anchor information, calls the getAnchor contract to obtain the corresponding version of blockHash and MerkleRoot, and compares and verifies them with the local data on the private chain.

[0073] 5) Key points and optimization strategies:

[0074] a) Version Management and Rollback: Both private and consortium blockchains should maintain multi-version anchor records; when a chain forks or makes an erroneous submission, the administrator interface can be called to mark or roll back the erroneous version.

[0075] b) Performance optimization:

[0076] i. Batch anchoring: When the private chain generates multiple blocks, multiple anchoring information can be merged and processed, and multiple pairs (blockHash, merkleRoot) can be submitted on the chain at one time, reducing transaction gas fees.

[0077] ii. Sidechain / State Channel: A state channel can be built between the consortium blockchain and the private blockchain to temporarily record multiple anchoring events and finally submit them to the main contract.

[0078] c) Disaster recovery and high availability:

[0079] i. Multi-node monitoring: Deploy multiple monitoring service instances to work in parallel, and automatically switch over if any instance fails;

[0080] ii. Cross-chain transaction monitoring: Integrate with monitoring platforms (such as Prometheus + Grafana) to provide real-time alerts on metrics such as transaction submission delays and failure rates.

[0081] d) Compliance and Audit:

[0082] All anchoring records and rollback operations are recorded on the consortium blockchain. Auditing agencies can query any version of anchoring information through on-chain events to ensure regulatory compliance and accountability.

[0083] In one embodiment, step S2 above: At the cross-chain service layer, based on the Parallel Hash Time Lock Contract (HTLC) channel, dynamic time lock, and multi-party threshold signature mechanism, atomic data exchange and high-availability transmission between private chains are achieved. The number of open parallel HTLC channels and timeout parameters are automatically adjusted according to on-chain load and off-chain reputation, specifically including:

[0084] In the cross-chain service layer, multiple HTLC channels are maintained in parallel. Their timeout parameters and the number of channels are dynamically adjusted based on on-chain congestion, historical transaction success rate, and off-chain reputation score. Channel status and failure retry strategies are recorded in on-chain smart contracts to ensure the success rate of cross-chain transactions. Specifically, this includes:

[0085] The cross-chain service layer of this invention is located between the private chain and the consortium chain, undertaking the functions of atomicity, rollback, and high availability of cross-chain data exchange. This layer achieves efficient, secure, and trust-minimized transmission of cross-chain data or assets through parallel HTLC channels, dynamic time locks, multi-party threshold signatures, and a unified transaction manager. Core objectives include:

[0086] Atomic swaps: Cross-chain transactions either succeed entirely or are completely rolled back, eliminating the risk of failure midway.

[0087] High availability: Multi-channel parallel processing and intelligent retries ensure timely completion of exchanges even in the event of on-chain congestion or node failure.

[0088] Auditability: All cross-chain operations and signature proofs are anchored to the consortium blockchain, facilitating post-event auditing and dispute resolution.

[0089] 1. Parallel HTLC channels:

[0090] HashTime-LockContract (HTLC) combines hash locking with time locking. The recipient must submit a hash-pre-secret within a predetermined time window to unlock the transaction; otherwise, the sender can unilaterally refund the payment, ensuring the security of funds or data. HTLC is the core mechanism of the Atomic Swap protocol and is widely used by networks such as Lightning.

[0091] To avoid transaction failures due to network congestion or node malfunctions in a single channel, this invention opens multiple HTLC channels in parallel within the same cross-chain request, connecting different private chain-consortium chain node pairs. As long as any channel successfully unlocks within the time lock, the exchange is considered complete, and the other channels are automatically cancelled, significantly improving the overall success rate and throughput.

[0092] Pipeline concurrency: Different HTLC channels can be initiated in batches according to priority, and the concurrency level can be dynamically adjusted to control the on-chain transaction volume and avoid instantaneous congestion. Node load assessment: Based on indicators such as historical transaction latency, failure rate, and node reputation score, the available node pairs are weighted and sorted, and the high-reliability channel is selected first to initiate HTLC requests.

[0093] 2. Dynamic time lock mechanism:

[0094] Traditional HTLC uses a fixed time-lock value, which makes it difficult to accommodate different link or network conditions. The dynamic time-lock mechanism intelligently adjusts the timeout duration of each HTLC channel based on real-time indicators such as on-chain congestion, transaction fees, and node reputation to balance security and transaction efficiency.

[0095] Congestion awareness and parameter tuning:

[0096] Network monitoring: The cross-chain service layer continuously monitors data such as block generation rate, transaction pool depth, and historical confirmation delay of private and consortium blockchains.

[0097] Moving average algorithm: Use EWMA (exponentially weighted moving average) to smooth the confirmation delay and dynamically correct the initial value of the time lock.

[0098] Reputation Bonus / Penalty: Provides time lock discounts for nodes with high reputation, and extends the lock period for all channels when congestion is severe, preventing false timeout revocations.

[0099] The specific implementation is as follows:

[0100] During the HTLC construction phase, the current suggested timeout duration T is dynamically obtained; T is written into the contract parameter expireTime=currentBlock+T / blockTime; if the transaction is close to its expiry and has not yet been completed, the cross-chain transaction manager can trigger the "delayed update" function to submit a second transaction to the chain to extend the time lock.

[0101] 3. Cross-chain transaction manager:

[0102] The cross-chain transaction manager is a core component of this layer, responsible for HTLC channel lifecycle management, status monitoring, timeout rollback, channel retries, and logging, ensuring the effective execution of the "consistency protocol" for cross-chain transactions. Its main functional modules are as follows:

[0103] 1) Channel creation module: Creates HTLC channels in parallel according to the strategy selection, and initializes hash lock parameters and dynamic time lock values.

[0104] 2) Status monitoring module: Poll or subscribe to on-chain HTLC contract status (lock, rollback, unlock) events and update the channel state machine.

[0105] 3) Timeout rollback module: Triggers refund logic before the channel times out to prevent assets or data from being locked up for a long time, and triggers a retry of the backup channel.

[0106] 4) Retry and Switching Module: Automatically retry failed or timed-out channels, or switch to the next priority node pair and reinitialize a new HTLC.

[0107] 5) Audit Log Module: Records the lifecycle events, signature proofs, and on-chain transaction hashes for each channel. Logs can be stored in a relational database or distributed storage for easy subsequent analysis and compliance auditing.

[0108] The transaction manager can scale horizontally to multiple instances, coordinating task allocation and state synchronization across instances through distributed locks. It integrates a Prometheus monitoring interface, providing alerts and automated scaling for metrics such as channel failure rate, retry count, and transaction latency. All parallel channels and signature fragment states are persisted to storage, allowing unfinished cross-chain transactions to resume from the latest checkpoint after a manager instance crashes and restarts.

[0109] Through the collaborative work of parallel HTLC channels, dynamic time locks, multi-party threshold signatures, and cross-chain transaction managers, the cross-chain service layer effectively ensures the atomic, secure, and highly available exchange of data or assets between heterogeneous chain networks, and provides stable and reliable cross-chain capabilities for upper-layer businesses.

[0110] In addition, the cross-chain service layer also includes: a multi-party threshold signature notarization mechanism, which distributes signature shards to pre-defined notary node groups through the t-of-n threshold signature protocol, and records the signature shards and aggregated signatures separately in the NotaryContract for subsequent auditing, dispute resolution, and non-repudiation assurance, specifically including:

[0111] Multi-party threshold notarization and anchoring

[0112] The multi-party threshold signature notarization mechanism distributes signature fragments to a predetermined notary node group via the t-of-n threshold signature protocol, and records the signature fragments and the aggregated signature separately in the NotaryContract for subsequent auditing, dispute resolution, and non-repudiation assurance. Specifically, it includes:

[0113] The threshold signature of this invention adopts a t-of-n threshold signature protocol (such as Shamir fragmentation or BLS threshold signature), which distributes the signature key fragments to n notary nodes. At least t nodes must work together to generate a valid signature, thus preventing single point of malicious activity and improving replay protection.

[0114] 1) Cross-chain notarization process:

[0115] Signature Request: The threshold signature request is triggered during the HTLC unlocking phase, and the cross-chain service layer sends the transaction summary to the notary node group.

[0116] 2) Signature fragment generation: Each node independently uses its private key to fragment the digest, generates signature fragments, and reports them to the NotaryContract.

[0117] 3) Signature aggregation: After receiving any t valid fragments, the transaction manager aggregates them off-chain or on-chain to generate a complete signature and calls the HTLC contract to complete the unlocking.

[0118] 4) Anchoring and Auditing:

[0119] All signature fragments and aggregated signatures are recorded on the blockchain via the NotaryContract event, recording the notary's list, timestamp, and signature summary, supporting subsequent audits and dispute reconciliation.

[0120] Example of the NotaryContract interface:

[0121] eventNotarySignature(uint256txId,address[]signers,bytessignature,uint256timestamp);

[0122] functionsubmitSignature(uint256txId,bytescalldatasigShare)external;

[0123] functionfinalizeSignature(uint256txId)external;

[0124] In one embodiment, step S3 above involves setting up protocol adaptation, data format conversion, machine learning prediction caching, and policy decision-making modules in the smart gateway layer to support multi-protocol access and perform off-chain prefetching and local Merkle verification based on a heat model; wherein the smart gateway layer includes, specifically:

[0125] The protocol adaptation module, data conversion and encapsulation module, intelligent caching and prefetching module, and policy decision-making module based on attribute-attribute cross-access control and multi-factor authentication support seamless end-to-end integration of multiple protocols, encrypted transmission, and secure permission verification.

[0126] The intelligent gateway layer is a crucial linchpin in this invention's architecture, situated between the private blockchain network and the cross-chain service layer. Its main responsibilities include: unified access to various IoT devices and private blockchain protocols; format conversion and metadata encapsulation of raw device data; intelligent caching and prefetching of cross-chain requests based on predictive models; execution of dynamic access policies and multi-factor authentication; and real-time monitoring and operation management of the entire process. The introduction of the intelligent gateway layer efficiently solves the cross-chain access challenges caused by differences in computing power and protocols among IoT devices, while significantly reducing on-chain interaction latency and resource consumption. Specifically, it includes:

[0127] 1. The intelligent gateway layer can be divided into the following five functional modules, which work together to ensure end-to-end security and high availability of data flow:

[0128] 1) Protocol adaptation module:

[0129] a) Supports mainstream IoT communication protocols such as MQTT, CoAP, HTTP / HTTPS, AMQP, and LoRaWAN;

[0130] b) Built-in plug-in driver, which can dynamically load new protocol adapters;

[0131] c) Provides a unified on-chain interaction interface (gRPC / RESTful), so that the upper layer does not need to care about the details of the underlying protocol.

[0132] 2) Data conversion and encapsulation module:

[0133] a) Parse the raw data reported by the device, such as JSON, XML, CSV, and binary frames, into an intermediate structure;

[0134] b) Perform field validation, unit conversion, sampling rate alignment, and append Merkle path, SHA256 hash, timestamp, and signature metadata;

[0135] c) Encapsulate the intermediate structure into a payload format that conforms to the private chain transaction model.

[0136] 3) Intelligent caching and prefetching module:

[0137] a) Analyze historical cross-chain access logs and business scenario tags using popularity prediction models (such as LSTM, XGBoost, etc.);

[0138] b) High-popularity or high-priority data blocks are retrieved from the private chain or consortium chain in advance and stored in the local cache pool;

[0139] c) Cache tiered management: Data is divided into three levels: "hot", "warm", and "cold", which are stored in memory, SSD, and local database respectively, and dynamically adjusted.

[0140] 4) Strategy Decision-Making and Identity Authentication Module:

[0141] a) Adopt the attribute-based access control (ABAC) framework, and generate access decisions by combining user / device attributes (role, organization, geographical location, security level), environmental attributes (time, network security status), and resource attributes (data sensitivity level);

[0142] b) Supports multi-factor authentication (password, multi-signature, hardware security module certificate, dynamic verification code, etc.);

[0143] c) Policy issuance is uniformly managed by the on-chain Policy contract and periodically pulled and cached by the gateway module.

[0144] 5) Operation and Maintenance Monitoring and Log Module:

[0145] a) Collect comprehensive gateway performance metrics (CPU, memory, network latency, request throughput, success rate, cache hit rate, etc.);

[0146] b) Combine distributed tracing (such as Jaeger or Zipkin) and log aggregation (ELK / EFK) to achieve full-chain visualization of the call chain;

[0147] c) Supports dynamic expansion, canary release, and automatic fault recovery.

[0148] 2. Protocol adaptation and data conversion:

[0149] 1) Protocol Adaptation Design: The smart gateway supports multiple IoT protocols through a plug-in architecture. Each protocol adapter includes three sub-modules: "transmit / receive interface," "parsing / serialization," and "secure encryption / decryption."

[0150] a) Send / receive interface: Based on high-performance network frameworks such as Netty, libcoap, and PahoMQTT, asynchronous non-blocking sending and receiving is implemented;

[0151] b) Parsing / Serialization: Based on the protocol definition, the frame format is converted into a unified internal intermediate representation (InternalDataObject) for easier subsequent unified processing;

[0152] c) Security encryption and decryption: Interconnects with TLS / DTLS, encryption chips or HSM, supports a secure channel from the device to the gateway, and prevents man-in-the-middle attacks and eavesdropping.

[0153] Gateway support for new protocols only requires writing the corresponding plugin and loading it at runtime; there is no need to restart the main program.

[0154] 2) After the device data enters the gateway, the following processing procedure is executed:

[0155] a) Original checks: Verify data integrity, timestamp validity, and signature legitimacy;

[0156] b) Format conversion: Map various raw formats (JSON / XML / CSV / binary) to a unified set of fields and perform unit conversion (e.g., Celsius to Kelvin);

[0157] c) Metadata encapsulation: Generate a Merkle path digest (based on the local Merkle tree index), SHA256 hash, and gateway signature for each data entry, and record the collection timestamp;

[0158] d) Transaction payload construction: The encapsulated data is filled into the transaction model required by the private chain or cross-chain service layer to construct the complete payload, which is then submitted on the chain.

[0159] This process ensures that, regardless of the variety of device protocols, the upper-layer distributed ledger can receive and process data in a unified manner.

[0160] 3) Intelligent caching and scheduling strategies:

[0161] a) The intelligent gateway layer of this invention uses a machine learning model to predict the data most likely to be accessed in the future, including:

[0162] i. Feature selection: historical access frequency, device type, business scenario tags (such as claims, warnings), time window (hour / day / week), network quality indicators, etc.

[0163] ii. Model implementation: Lightweight LSTM networks can be used to capture temporal dependencies, or XGBoost, LightGBM, etc. can be used to improve training and inference speed;

[0164] iii. Online training and updates: Combining incremental learning technology, the model is automatically trained and updated periodically within the gateway to adapt to business changes in real time.

[0165] b) The cache of the smart gateway layer of this invention includes: Level 1 memory cache: LRU cache structure, storing extremely high-frequency data, with response time controlled in milliseconds; Level 2 flash cache: based on RocksDB / LevelDB, storing high or medium-frequency data, with loading time controlled in tens of milliseconds; Level 3 persistent storage: relational database (PostgreSQL) or distributed KV (Cassandra), storing warm and cold data, used for batch retrieval or infrequent access scenarios;

[0166] c) Cache scheduling and consistency at the intelligent gateway layer:

[0167] i. Prefetch task scheduling: Based on the prediction results and the real-time request status on the chain, the scheduler generates prefetch tasks, executes them in priority order, and reserves bandwidth and storage space;

[0168] ii. Expiration and Eviction: Combining timeliness, access frequency, and storage cost, execute eviction policies periodically to prevent cache expiration or accumulation;

[0169] iii. Consistency Guarantee: After each on-chain data update, the gateway listens for anchoring events and synchronously updates the local Merkle index to ensure that the cached data is consistent with the on-chain state.

[0170] 4) Security and Access Control:

[0171] a) Attribute-Based Access Control (ABAC):

[0172] i. Strategy Model: Define a set of strategy rules, with rules in the form of (Subject.Attributes, Resource.Attributes, Action, Environment.Context) → Permit / Deny;

[0173] ii. Policy Contract: The on-chain smart contract PolicyContract stores global policies, which are issued by the administrator or the superior contract;

[0174] iii. Gateway execution: The gateway periodically pulls the latest policy and loads it into the local PDP (PolicyDecisionPoint) to make online decisions for each access request.

[0175] b) Multi-factor authentication, supporting the following authentication methods:

[0176] i. Device certificate: X.509 / mTLS two-way authentication; certificate registration is required for the first connection of the device.

[0177] ii. Dynamic passwords: Combined with OTP (TOTP / HOTP) or mobile verification codes, they enhance security in human-computer interaction scenarios;

[0178] iii. Hardware security module: Interacts with HSM or TPM chips to complete secure storage and signing of private keys;

[0179] iv. Biometrics (optional): For high-security scenarios, modules such as fingerprint and facial recognition can be integrated.

[0180] c) Security Audit and Alerts:

[0181] i. Log collection: All requests, responses, policy decisions, cached events, and on-chain interactions are recorded in structured logs;

[0182] ii. Alarm rules: Based on anomaly detection (such as failure rate, timeout rate, frequent retries), trigger alarm notifications or automatic rate limiting;

[0183] iii. Audit backtracking: By combining on-chain event IDs with local logs, end-to-end auditing and backtracking of cross-chain operations are supported.

[0184] 5) Monitoring and Operations Support:

[0185] a) Metrics collection: Integrates PrometheusExporter to collect system metrics (CPU, memory, network, cache hits, on-chain latency, etc.);

[0186] b) Visual dashboard: Build a monitoring dashboard using Grafana to display the gateway's operating status and cross-chain performance in real time;

[0187] c) Distributed tracing: Using Jaeger / Zipkin, we trace every call chain from the device to the anchored chain;

[0188] d) Automatic scaling: Combined with KubernetesHPA / ClusterAutoscaler, the number of gateway instances is automatically adjusted based on throughput and latency metrics;

[0189] e) Blue-green / grayscale release: Supports grayscale traffic splitting and rollback strategies to ensure a safe and smooth release of new versions;

[0190] f) Fault recovery: Quickly recover from single-point or regional faults through redundant deployment, data backup and scripted operation and maintenance.

[0191] Through the above steps, the smart gateway layer achieves protocol independence, unified data format, intelligent caching optimization, secure access control, and comprehensive operation and maintenance monitoring in the architecture of this invention, providing a stable, efficient, and auditable foundation for the cross-chain service layer.

[0192] Figure 3 This is a schematic diagram of the intelligent gateway module structure.

[0193] In one embodiment, step S4 above, the light client layer, specifically includes:

[0194] Initial trust root block header snapshot pull and off-chain trusted startup;

[0195] Multi-source parallel incremental synchronization and local Merkle path verification;

[0196] Bloom filter or bitmap-based off-chain header information filtering and multi-node disaster recovery retrieval are used to improve data synchronization efficiency and fault tolerance.

[0197] This invention's Light Client Layer provides an efficient and reliable solution for cross-chain data verification in hybrid blockchain networks, targeting resource-constrained IoT terminals and mobile devices. This layer achieves on-chain interaction and data verification with extremely low storage and computational costs through technologies such as block header snapshots, Merkle path verification, incremental synchronization, and multi-path disaster recovery. The following details five aspects.

[0198] 1. Design Goals and Architecture Positioning:

[0199] 1) Resource constraints: Due to the storage (≤50MB) and computing (single core ≤500MHz) limitations of IoT devices and mobile terminals, the light client only stores the necessary block header and index data to avoid the high cost and long waiting time caused by full chain synchronization.

[0200] 2) Trust minimization: Without relying on a single node or third-party service, the existence of transactions is independently verified through locally stored block headers and Merkle proofs, ensuring the immutability and trustworthiness of cross-chain data.

[0201] 3) High availability and disaster recovery: Supports multi-source snapshot pulling and parallel verification to avoid verification interruption due to single node failure or network jitter, and ensures continuous service through redundancy design.

[0202] 4) Low-latency interaction: Combining incremental difference synchronization and local caching, the verification process is accelerated, and the verification latency of a single Merkle proof is controlled within 200ms to meet real-time requirements.

[0203] 2. Block header snapshot and root of trust management:

[0204] 1) Initial Trust Root Acquisition: Upon initial startup, the light client pulls the latest block header snapshot from multiple consortium blockchain full nodes or trusted gateways via a secure channel (HTTPS+PKI). This snapshot includes crucial information such as the parent hash, Merkle root, and timestamp, and verifies the certificate chain to prevent man-in-the-middle attacks. By default, at least six nodes are selected for parallel pulling, and a majority consensus mechanism is used to confirm the first trust root, preventing a single node from maliciously issuing forged block headers.

[0205] 2) Snapshot Storage and Version Management: Snapshots only contain a list of block headers and no transaction data. Typically, each update only requires downloading 80 bytes × N headers, significantly reducing bandwidth consumption. Local maintenance maps snapshot version numbers to on-chain height, supporting historical version rollback and facilitating rollback operations in case of forks or missynchronization.

[0206] 3. Merkle path verification process:

[0207] When the application layer initiates data verification, it provides the transaction ID (TxID) of the target transaction and its corresponding Merkle path (including a list of hashes of adjacent nodes in the same block). The light client searches for the Merkle root in its local snapshot and performs a composite calculation with the Merkle path in the request. If the calculation result matches the Merkle root stored in the snapshot, it proves that the transaction has been packaged into the corresponding block. The verification algorithm is as follows:

[0208] functionverifyTransaction (txID,merkleProof,blockHeader):

[0209] computedRoot = computeMerkleRoot (txID,merkleProof)

[0210] return (computedRoot = blockHeader.merkleRoot)

[0211] The computeMerkleRoot method employs a bottom-up iterative approach, sequentially combining transaction hashes with node hashes in the path and performing double SHA-256 calculations to ultimately generate the root hash. If synthesis fails, the client can attempt to pull Merkle paths or snapshots from other gateways in parallel, preventing single-point attacks involving forged paths. Merkle proofs themselves cannot prove "non-existence," only "existence." For critical business scenarios, multi-node cross-validation or combining on-chain lightweight contracts for state queries is recommended.

[0212] 4. Incremental synchronization and multi-path disaster recovery:

[0213] Light clients periodically or on demand request a list of block header differences added since the last synchronization height (H0) from a specified node:

[0214] requestNewHeaders(fromHeight=H0)

[0215] receive[Header(H0+1),Header(H0+2),…,Header(Hn)]

[0216] Bloom filters or bitmaps are used to filter only the chain segments that need to be synchronized, avoiding the repeated downloading of irrelevant header information. During synchronization, pulls are initiated in parallel to 3-5 nodes, employing the fastest multi-segment download strategy. If a node times out, the process continues from a backup node. If a block header returned by a node does not match the local trusted root chain, a fork detection is triggered. The client can automatically roll back to the most recent stable height and resynchronize. The pulled incremental block headers are merged with the local snapshot to generate the latest snapshot, which is then written to the light client database (SQLite / LevelDB) to ensure rapid state recovery after a restart.

[0217] 5. API Design and Call Flow:

[0218] Core Interface

[0219] getLatestHeight()→uint64: Returns the current local trust chain height.

[0220] getBlockHeader(height) → BlockHeader: Gets the block header at the specified height.

[0221] verifyTx(txID, merkleProof, height) → bool: Performs Merkle path validation and returns whether the validation passed.

[0222] syncHeaders(): Triggers incremental synchronization operations.

[0223] Example of use

[0224] client = LightClient(nodeList)

[0225] client.initialize_trust_root()

[0226] `client.syncHeaders()` If `client.verifyTx(txID, proof, proofHeight)`: `print("Transaction confirmed")` else: `print("Transaction verification failed or does not exist")`

[0227] The client library automatically manages the multi-node list, retry logic, and local snapshot storage, while the application layer only needs to focus on the verification results.

[0228] 6. Security reinforcement and best practices:

[0229] 1) Trust anchoring protection: It is recommended to protect the first root of trust through HSM or TEE (such as IntelSGX) to prevent the injection of malicious block headers after the device is physically compromised.

[0230] 2) Multi-node consensus pull: In critical business scenarios (such as medical claims and financial clearing and settlement), the Merkle path and the status of lightweight on-chain contracts (such as evidence storage contracts) can be verified simultaneously to further improve the verification strength.

[0231] 3) Logs and Audits: Record each verification operation (TxID, height, result) in local logs and upload them to the centralized audit platform regularly to ensure that the operation is traceable.

[0232] 4) Version upgrade strategy: Light client software should support remote signature upgrades in order to quickly fix security vulnerabilities or optimize synchronization logic.

[0233] Through the above design, the lightweight client layer can provide trusted verification of cross-chain IoT data in resource-constrained IoT and mobile device environments with storage as low as a few MB and latency as low as milliseconds, providing solid support for the high availability and secure operation of the entire hybrid blockchain architecture.

[0234] Figure 4This is a schematic diagram of the data verification process for a lightweight client.

[0235] In one embodiment, the security and privacy protection layer of S5 described above adopts:

[0236] Zero-knowledge proofs using zk-SNARK / zk-STARK without trusted setups only publish minimal proof data during compliance verification.

[0237] Paillier or CKKS homomorphic encryption schemes perform threshold comparison and aggregation statistics in ciphertext state;

[0238] An auditable log recording mechanism based on two-layer signature and threshold signature ensures that sensitive raw data is stored on the blockchain only in encrypted or proven form.

[0239] The security and privacy protection layer of this invention provides comprehensive confidentiality, integrity, and auditability guarantees for on-chain and off-chain data interactions throughout the entire cross-chain sharing system. Through technologies such as zero-knowledge proofs, homomorphic encryption, double-layer signatures and threshold signatures, attack prevention designs, and audit compliance mechanisms, the security and privacy protection layer achieves privacy protection and end-to-end security monitoring of sensitive data, ensuring that on-chain verification and computation are completed without disclosing the original data, and providing a detailed and tamper-proof chain of evidence for post-audit.

[0240] 1. Zero-Knowledge Proof (ZKP):

[0241] Zero-knowledge proof is a cryptographic proof technique that allows a prover to prove the truth of a proposition to a verifier without revealing any secret information. Its applications in IoT cross-chain technology include the following:

[0242] 1) Conditional compliance verification: For example, verifying "temperature ≥ 37℃" or "average heart rate within a healthy range" can be completed on-chain without disclosing the original vital signs.

[0243] 2) Identity authentication: When a user or device accesses the network, ZKPs are used to prove that they possess valid credentials (such as digital certificates) without disclosing private keys or other sensitive information.

[0244] 3) Multi-party data aggregation: By generating and validating zk-SNARKs or zk-STARKs proofs in parallel, it supports distributed deployment of gateways and light clients, improving throughput and scalability.

[0245] 4) ZKP technology selection and process:

[0246] zk-SNARKs (Groth16): High verification efficiency and small proof size, suitable for on-chain proof storage; however, it requires a trusted setting. This invention uses the Halo2 trusted setting-free scheme to reduce trust costs.

[0247] zk-STARKs: No trusted initialization required, resistant to quantum attacks, suitable for high-security scenarios; however, the proof size and generation overhead are relatively large.

[0248] 2. Homomorphic Encryption (HE) Supports Ciphertext Operations: Homomorphic encryption allows direct addition, multiplication, and other operations on the ciphertext without decryption, ensuring data confidentiality during computation. Application scenarios are as follows:

[0249] 1) Threshold comparison: In the claims scenario, encrypted physiological indicators are compared with preset thresholds, and the results are returned in encrypted form. The verification process is kept confidential.

[0250] 2) Statistical analysis: Perform simple statistical operations such as aggregation and averaging on the encrypted health data, and return ZKP proofs off-chain to ensure that the results are reliable and do not leak single points of data.

[0251] 3) Secure multi-party computation: Collaboratively complete complex analyses such as joint modeling or risk assessment across organizations without sharing plaintext.

[0252] 4) Key points for system implementation:

[0253] a) Scheme selection: Paillier partial homomorphic encryption is selected for lightweight computing scenarios; CKKS is selected for multi-dimensional matrix operations to balance computing efficiency and ciphertext size.

[0254] b) Off-chain and on-chain collaboration: Heavy computation tasks are completed off-chain on smart gateways or dedicated computing nodes, while only the computation summary or ZKP proof of the HE result is stored on-chain, reducing the burden on the chain.

[0255] 3. Two-layer signature and threshold signature:

[0256] 1) Every cross-chain transaction requires signing in two key stages:

[0257] Medium source chain signature: Private chain nodes use their private keys to sign transaction data or authorization tokens to prove the original legality of the data [Medium].

[0258] Cross-chain notarized signature: After receiving the unlocking certificate, the cross-chain service layer or smart gateway signs the transaction summary again to form a double signature, preventing the data from being tampered with twice.

[0259] 2) t-of-n threshold signature:

[0260] a) Shamir Sharding: The private key is divided into n parts. A signature can be recovered only if at least t parts are combined, which enhances security redundancy and resistance to node failure.

[0261] b) Non-interactive threshold: Employs BLS threshold signature and NIDTS to support non-interactive key setting and signature generation, improving protocol efficiency.

[0262] c) Signature anchoring: Upload the threshold signature result to the on-chain NotaryContract, record the list of signers, timestamps and signature digests to ensure auditability.

[0263] 4. Anti-attack mechanism:

[0264] 1) Protection against man-in-the-middle attacks: The entire communication process uses TLS1.3+ECDHE key negotiation, combined with on-chain signatures and timestamps, to prevent message tampering and replay;

[0265] 2) Replay attack protection: All on-chain operations include a unique one-time random number and a strict time-lock parameter to prevent transactions from being replayed or delayed in execution;

[0266] 3) Quantum-resistant: Key signature algorithms (such as BLS) can be replaced with quantum-resistant algorithms (such as lattice-based signatures) and a compatible interface can be provided for future evolution.

[0267] 5. Audit and Compliance Tracking:

[0268] 1) Full-chain log recording: including ZKP proof digest, HE operation digest, signature fragments and double signature hash, etc. Complete operation logs are retained through AuditContract, which facilitates supervision and legal evidence collection.

[0269] 2) Third-party audit interface: Provides compliance agencies with a unified on-chain and off-chain view, supporting querying and exporting reports by time interval, link, data type and other dimensions.

[0270] 3) Regular security assessments: Conduct vulnerability scanning and penetration testing of smart contracts and ZKP / HE modules in conjunction with third-party blockchain security auditing companies (such as CertiK and Quantstamp).

[0271] The security and privacy protection layer of this invention safeguards data privacy through zero-knowledge proofs and homomorphic encryption, enhances transaction signature security through dual-layer signatures and threshold signatures, and achieves end-to-end security and traceability through multiple anti-attack designs and audit compliance mechanisms. It builds a strong and highly trusted IoT cross-chain sharing foundation, achieving the best balance between privacy protection and transparent auditing.

[0272] Figure 5 This is a schematic diagram of multi-party threshold signatures and anchoring in cross-chain transactions.

[0273] The innovation of the method of this invention lies in:

[0274] Hybrid blockchain network architecture: a combination of private and consortium blockchains, supporting multi-party collaboration and differentiated permissions;

[0275] Cross-chain services: Parallel HTLC + dynamic lock + threshold signature to improve robustness and security;

[0276] Smart gateway: a design that integrates protocol adaptation, cache prediction, and access control;

[0277] Lightweight client: Incremental Merkle verification + asynchronous block header synchronization, adapted to terminal resource limitations;

[0278] Security Mechanism: Zero-knowledge proof + homomorphic encryption double insurance ensures secure privacy sharing.

[0279] The following uses a medical-insurance IoT system as an example to illustrate the application process of this invention.

[0280] Background: Hospital A has deployed a private blockchain A, and Insurance Company B has deployed a private blockchain B. Both need to share a patient's real-time health data (such as body temperature, blood pressure, and heart rate) within a consortium blockchain C to complete an automated claims process. To protect patient privacy and data security, the method described in this invention is deployed as follows.

[0281] Step 1: Building the system network, completing the following environment deployment and parameter configuration:

[0282] 1. Private Chain A and Private Chain B:

[0283] 1) Each is deployed within the internal networks of the hospital and the insurance company, based on Hyperledger Fabricv2.x or Quorumv21.

[0284] 2) The consensus algorithm adopts PBFT (Fabric) or IstanbulBFT (Quorum), and the number of configured nodes is ≥4 to ensure fault tolerance.

[0285] 3) Each node starts an off-chain listening service to listen for new block generation events and report them to the gateway.

[0286] 2. Consortium Blockchain C:

[0287] 1) Deployed in a trusted third-party or cloud environment, with nodes jointly maintained by hospitals, insurance companies, and notary offices.

[0288] 2) The smart contract platform uses the Ethereum-compatible chain (Geth / Parity) and deploys the AnchorContract, NotaryContract, and PolicyContract.

[0289] 3) Set up a cross-chain transaction repository (TransactionStore) and an audit log database (such as PostgreSQL).

[0290] 3. Smart Gateway:

[0291] 1) Deploy one unit each at the hospital exit and the insurance exit, and run using Kubernetes containerization.

[0292] 2) Components include: protocol adapter, multi-channel HTLC manager, heat prediction cache, ZKP module, and homomorphic encryption client.

[0293] 3) Configure on-chain node RPC connections, machine learning models (LightGBM), and local caching (Redis+RocksDB).

[0294] 4. Lightweight client:

[0295] Deployed on insurance audit terminals or regulatory systems, the SPV client is developed based on C++ / Go and supports HTTPSPKI verification, Merkle path verification, and intelligent rollback.

[0296] Upon initial startup, load the trust root snapshots of the consortium blockchain and the private blockchain, and configure the node list and standby nodes.

[0297] Step 2: On-chain registration and anchoring:

[0298] 1. Device and On-Chain Registration

[0299] Medical devices within Hospital A (ECG monitor, blood pressure monitor, temperature sensor) submit registration transactions to the local Fabric private blockchain node A via TLS / MQTT. Example transaction payload: { "deviceId": "A-ECG-001", "org": "HospitalA", "pubKey": "04ab...34cd", "metadata": {"model": "ECG-200", "location": "Ward-5"} }

[0300] Within private chain A, Chaincode calls RegisterDevice(deviceId, pubKey, metadata) to write device information into the device registration ledger and trigger the DeviceRegistered(deviceId) event.

[0301] 2. Private blockchain → Consortium blockchain anchoring:

[0302] After the local listening service captures the DeviceRegistered event, it constructs an anchor request:

[0303] AnchorContract.registerAnchor(

[0304] chainId=1001,

[0305] blockHash=0xabc123...,

[0306] merkleRoot=0xef456...,

[0307] timestamp=1623456789 );

[0309] Send the transaction to consortium blockchain C, pending ≥ Once node consensus is reached, the AnchorRegistered event is triggered and recorded on the chain. The system writes the receipt to the local "anchor record table," with fields including chainId, version, blockHash, merkleRoot, timestamp, and txHash, for subsequent verification.

[0310] Step 3: Data Publishing and Caching:

[0311] 1. Device data upload to the blockchain:

[0312] Medical equipment collects patient data such as temperature, blood pressure, and heart rate in real time, and packages the data into JSON at a frequency of 10 seconds per instance. { "deviceId": "A-ECG-001", "timestamp": 1623456790 "data": {"temp": 36.8, "bp": "120 / 80", "hr": 72} }

[0313] After receiving the data, the smart gateway calls the local on-chain adaptation module to encapsulate the data into a private chain transaction.

[0314] tx:=NewTransaction("SubmitMedicalData",args)

[0315] tx.SignWithGatewayKey()

[0316] fabricClient.Submit(tx)

[0317] After private chain A completes the transaction consensus, it writes the original data digest (SHA256) and the transaction ID onto the chain and returns the block height h1.

[0318] 2. Popularity prediction and prefetching caching:

[0319] The smart gateway uses the LightGBM model to calculate whether the patient's data will be accessed by the insurance claims process within the next 5 minutes. The model's input features include: patient medical history tags, claims trigger threshold, and the frequency of similar historical cases accessed. If the predicted popularity is greater than or equal to the Threshold (e.g., 0.8), the gateway automatically calls QueryMedicalData(deviceId, timeRange) to retrieve the N most recent records from private chain A, constructs a Merkle tree, and stores it in the local Redis cache with the key precache: A-ECG-001.

[0320] Structure of cache entries: { "records": [...], "merkleRoot":"0x1234abcd...", "expireAt": 1623457090 }

[0321] Step 4: Cross-chain atom exchange:

[0322] 1. HTLC channel creation:

[0323] When Insurance Chain B requests patient data, the smart gateway creates three HTLC channels in parallel between private chain A and consortium chain C, and calls the contract respectively:

[0324] HTLC.openChannel(

[0325] sender=HospitalA,

[0326] receiver=InsuranceB,

[0327] hashLock = H(dataKey),

[0328] timeLock=T1 );

[0330] Assign a different timeLock to each channel and dynamically adjust the parameters (T1≈30s, T2≈45s, T3≈60s).

[0331] 2. Exchange and unlocking process:

[0332] 1) When private chain A is locked, it writes the encrypted credential (encryptedDataKey) into the HTLC contract event;

[0333] 2) The smart gateway listens for HTLC events on consortium blockchain C and pushes the encrypted credentials to private blockchain B (the insurance end);

[0334] 3) B private chain node submits the unlocking credential preimage to the HTLC contract. After successful unlocking, the contract releases the access token and data index.

[0335] 4) If the maximum timeLock is not unlocked, the transaction manager will automatically call HTLC.refund(channelId) to release the lock and record the timeout log.

[0336] Step 5: Data Validation and Processing

[0337] 1. Light Client Data Verification: The insurance audit terminal runs a light client and calls the SPV interface to synchronize the consortium blockchain block header snapshot. After receiving the data index and Merkle path returned after HTLC unlocking, the light client executes verifyTx(txId,proof,height) to confirm that the record does exist in the block height and that the data has not been tampered with.

[0338] 2. Zero-knowledge proof compliance verification: The gateway generates a ZK-SNARK proof stating that "the patient's highest body temperature within 24 hours is ≤38℃ and there is at least one blood pressure reading >140 / 90", without revealing the specific value.

[0339] The insurance verification terminal verifies the claim through the on-chain ZKPContract.verify(proof) interface. If the verification is successful, the automatic claims calculation will begin.

[0340] 3. Homomorphic encryption threshold comparison: After the patient data is encrypted with Paillier, multiple readings are summed by homomorphic operation before being uploaded to the blockchain, and the ciphertext is compared with the encryption threshold.

[0341] The gateway generates and uploads the HE verification digest to the blockchain. The terminal only needs to obtain the judgment result (true / false) and does not need to decrypt the original data.

[0342] Step 6: Audit and Retrospection:

[0343] 1. On-chain logs:

[0344] Each HTLC operation (open, unlock, refund) and ZKP and HE verification results are recorded on the consortium blockchain C through smart contract events.

[0345] The AuditContract stores an event index, facilitating queries by multiple dimensions such as transaction ID, time range, and node identity.

[0346] 2. Third-party supervision access:

[0347] Regulators can query the AuditContract and NotaryContract through read-only nodes to obtain a complete list of signature fragments, time lock parameters, and ZKP proof digests.

[0348] It supports exporting PDF / CSV reports for compliance checks and judicial evidence collection.

[0349] 3. Dispute resolution:

[0350] If insufficient signature or timeLock exception occurs, the audit contract can provide the getChannelStatus(channelId) interface to return lock / unlock / rollback logs.

[0351] Threshold signature fragments and timestamps can serve as legal evidence to ensure accountability.

[0352] The effects and performance indicators of this embodiment:

[0353] 1. Average cross-chain latency: From data submission to unlocking on the insurance side, the average latency is 3.1s (σ=0.4s).

[0354] 2. Privacy Protection: Through ZKP and HE, the plaintext leakage rate of sensitive patient indicators is <1%, and the risk of data leakage is reduced by ≥90%.

[0355] 3. Resource consumption: The smart gateway uses ≤512MB of memory, the light client uses ≤8MB of RAM, and the storage uses ≤30MB. It is compatible with mainstream embedded and mobile terminals.

[0356] 4. Availability: The success rate of parallel HTLC channels is ≥99.5%, and the multi-path disaster recovery mechanism ensures that the overall system availability is ≥99.9% under single point of failure.

[0357] The above embodiments, through detailed descriptions of key aspects such as on-chain anchoring, hot caching, parallel atomic swapping, lightweight client verification, and privacy protection, fully demonstrate the practicality and superiority of the method of the present invention in the medical-insurance Internet of Things scenario.

[0358] Security analysis of this embodiment:

[0359] 1. Resistance to Man-in-the-Middle (MitM) Attacks: In addition to bidirectional HTLC locking, this solution introduces end-to-end encrypted channels (TLS 1.3 + ECDHE) and message signature verification during channel establishment and data transmission. No intermediate node can decrypt or forge message content. Even if an off-chain encrypted credential is intercepted, the channel cannot be unlocked due to the lack of a private key and hash pre-value.

[0360] 2. Replay resistance: In each cross-chain transaction, not only are timestamps and one-time certificates (nonces) embedded, but the latest block height on the chain is also used in the hash calculation along with a random challenge code. This ensures that old messages are automatically rejected in different times and in different block contexts, preventing replay without the need for additional blacklists or frequency monitoring.

[0361] 3. Anti-tampering attack: In addition to Merkle path verification and consortium chain dual anchoring, this solution adds an on-chain state snapshot verification mechanism: both the light client and the gateway save several latest anchoring versions. If the local snapshot is found to be inconsistent with the anchoring version, an on-chain multi-node voting rollback or lockout anomaly alarm can be triggered immediately to prevent tampering with off-chain cache or forging Merkle proofs.

[0362] 4. Access Control Guarantee: In addition to attribute encryption and policy switching, this system also supports dynamic policy updates and multi-factor authentication (such as HSM signature + OTP), and automatically issues or revokes access permissions based on blockchain event-driven policy contracts. Any unauthorized or expired access requests will be immediately blocked by the smart gateway at the off-chain gateway level, and the violation attempt will be written into the audit contract.

[0363] Example 2

[0364] like Figure 6 As shown, this embodiment of the invention provides an IoT data security sharing system based on a hybrid private blockchain and consortium blockchain, comprising the following modules:

[0365] Hybrid blockchain network module 61 is used to deploy multiple industry / organization level private chains and use consortium blockchains as mutual trust anchoring layers; the private chains and consortium blockchains are aligned and managed in a controllable tamper-proof manner through a hierarchical structure of core and auxiliary parts;

[0366] The cross-chain service module 62 is used to realize atomic data exchange and high-availability transmission between private chains based on the parallel hash time lock contract HTLC channel, dynamic time lock and multi-party threshold signature mechanism. The number of parallel HTLC channels opened and the timeout parameters are automatically adjusted according to the on-chain load and off-chain reputation.

[0367] The intelligent gateway module 63 is used to set up protocol adaptation, data format conversion, machine learning prediction caching and strategy decision modules to support multi-protocol access and perform off-chain prefetching and local Merkle verification based on the heat model.

[0368] Light client module 64 is used to retain block headers and Merkle indexes, and to filter them through multi-source parallel incremental synchronization and Bloom Filter;

[0369] The security and privacy protection module 65 uses a combination of zk-SNARK or zk-STARK zero-knowledge proofs without trusted settings and Paillier / CKKS homomorphic encryption to complete threshold comparison and statistical calculations in ciphertext state, and records auditable logs through threshold signatures.

[0370] A device for secure sharing of IoT data based on hybrid private blockchain and consortium blockchain includes one or more electronic devices, wherein the one or more electronic devices are used to implement a method for secure sharing of IoT data based on hybrid private blockchain and consortium blockchain.

[0371] An electronic device includes: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors enable the one or more processors to implement a method for secure sharing of IoT data based on a hybrid private blockchain and consortium blockchain.

[0372] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for secure data sharing in the Internet of Things based on a hybrid private blockchain and consortium blockchain, characterized in that, include: Step S1: Deploy multiple industry / organization-level private chains in the hybrid blockchain network layer, and use a consortium blockchain as a mutual trust anchoring layer; the private chains and the consortium blockchains are aligned in state and managed in a controllable manner through a hierarchical structure of core and auxiliary parts; Step S2: In the cross-chain service layer, based on the parallel hash time lock contract HTLC channel, dynamic time lock and multi-party threshold signature mechanism, atomic data exchange and high availability transmission between private chains are realized. Among them, the number of parallel HTLC channels opened and the timeout parameters are automatically adjusted according to the on-chain load and off-chain reputation. Step S3: Set up protocol adaptation, data format conversion, machine learning prediction caching and policy decision modules in the smart gateway layer to support multi-protocol access and perform off-chain prefetching and local Merkle verification based on the heat model; Step S4: In the light client layer, only the block header and Merkle index are retained, and filtered through multi-source parallel incremental synchronization and Bloom filter; Step S5: In the security and privacy protection layer, zk-SNARK or zk-STARK zero-knowledge proofs without trusted settings are combined with Paillier / CKKS homomorphic encryption to complete threshold comparison and statistical calculation in ciphertext state, and record auditable logs through threshold signature.

2. The method for secure data sharing in the Internet of Things based on a hybrid private blockchain and consortium blockchain as described in claim 1, characterized in that, The hybrid blockchain network layer in step S1 specifically includes: In the hybrid blockchain network layer, the private chain packages the block header hash and Merkle root through an off-chain listener and submits it to the AnchorContract contract on the consortium chain periodically, combined with state channels, batch anchoring, and an updatable block structure.

3. The method for secure data sharing in the Internet of Things based on a hybrid private blockchain and consortium blockchain as described in claim 1, characterized in that, The cross-chain service layer in step S2 specifically includes: In the cross-chain service layer, multiple HTLC channels are maintained in parallel. Their timeout parameters and the number of channels are dynamically adjusted based on on-chain congestion, historical transaction success rate, and off-chain reputation score. The channel status and failure retry strategy are recorded in the on-chain smart contract to ensure the success rate of cross-chain transactions.

4. The method for secure data sharing in the Internet of Things based on a hybrid private blockchain and consortium blockchain according to claim 1, characterized in that, The cross-chain service layer in step S2 further includes: The multi-party threshold signature notarization mechanism distributes signature fragments to the pre-defined notary node group through the t-of-n threshold signature protocol, and records the signature fragments and the summary signature separately in the NotaryContract for subsequent auditing, dispute resolution and non-repudiation guarantee.

5. The method for secure data sharing in the Internet of Things based on a hybrid private blockchain and consortium blockchain according to claim 1, characterized in that, Step S3: The smart gateway layer specifically includes: The protocol adaptation module, data conversion and encapsulation module, intelligent caching and prefetching module, and policy decision-making module based on attribute-attribute cross-access control and multi-factor authentication support seamless end-to-end integration of multiple protocols, encrypted transmission, and secure permission verification.

6. The method for secure data sharing in the Internet of Things based on a hybrid private blockchain and consortium blockchain according to claim 1, characterized in that, Step S4: The lightweight client layer specifically includes: Initial trust root block header snapshot pull and off-chain trusted startup; Multi-source parallel incremental synchronization and local Merkle path verification; Bloom filter or bitmap-based off-chain header information filtering and multi-node disaster recovery retrieval are used to improve data synchronization efficiency and fault tolerance.

7. The method for secure data sharing in the Internet of Things based on a hybrid private blockchain and consortium blockchain according to claim 1, characterized in that, The security and privacy protection layer in step S5 adopts: Zero-knowledge proofs using zk-SNARK / zk-STARK without trusted setups only publish minimal proof data during compliance verification. Paillier or CKKS homomorphic encryption schemes perform threshold comparison and aggregation statistics in ciphertext state; An auditable log recording mechanism based on two-layer signature and threshold signature ensures that sensitive raw data is stored on the blockchain only in encrypted or proven form.

8. A data security sharing system for the Internet of Things based on a hybrid private blockchain and consortium blockchain, characterized in that, Includes the following modules: A hybrid blockchain network module is used to deploy multiple industry / organization-level private chains, with a consortium blockchain as a mutual trust anchoring layer; the private chains and the consortium blockchains are aligned in state and managed under controllable tampering through a hierarchical structure of core and auxiliary parts. The cross-chain service module is used to realize atomic data exchange and high-availability transmission between private chains based on the Parallel Hash Time Lock Contract (HTLC) channel, dynamic time lock, and multi-party threshold signature mechanism. The number of parallel HTLC channels opened and the timeout parameters are automatically adjusted according to on-chain load and off-chain reputation. The intelligent gateway module is used to set up protocol adaptation, data format conversion, machine learning prediction caching and strategy decision-making modules to support multi-protocol access and perform off-chain prefetching and local Merkle verification based on the heat model; The lightweight client module is used to retain block headers and Merkle indexes, and filters them through multi-source parallel incremental synchronization and Bloom Filter. The security and privacy protection module uses a combination of zk-SNARK or zk-STARK zero-knowledge proofs without trusted settings and Paillier / CKKS homomorphic encryption to complete threshold comparison and statistical calculations in ciphertext state, and records auditable logs through threshold signatures.

9. A data security sharing device for the Internet of Things based on a hybrid private blockchain and consortium blockchain, characterized in that, It includes one or more electronic devices, wherein the one or more electronic devices are used to implement the method of any one of claims 1 to 5.

10. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method of any one of claims 1 to 5.

Images