Internet of Things industrial data right confirmation and credible sharing method and system based on block chain

Abstract

The invention provides an Internet of Things industrial data right confirmation and credible sharing method and system based on a block chain, and belongs to the cross field of block chains, Internet of Things and artificial intelligence, and the method comprises the steps: constructing a double-chain separation data layer composed of a private chain and a public chain, and achieving the classification isolation of data and hardware fingerprint right confirmation; in the consensus layer, an improved IPBT consensus protocol of a dynamic weight distribution mechanism based on a Transform model is adopted to adapt to a heterogeneous node environment; in an application layer, a federated learning framework and an intelligent contract are deeply integrated, and data value mining and credible sharing under privacy protection are realized. According to the method, the problems that the sovereignty of the data of the Internet of Things is fuzzy, the privacy leakage risk is high and an existing block chain scheme is not adaptive to a heterogeneous environment are solved, and safe right confirmation, privacy protection and efficient and credible sharing of the data are realized.

Description

Technical Field

[0001] This invention belongs to the fields of blockchain technology, Internet of Things (IoT) and Artificial Intelligence (AI), and specifically relates to a blockchain-based method and system for confirming ownership and trustworthy sharing of IoT industry data. Background Technology

[0002] As the wave of "Industry 4.0" and digital transformation sweeps the globe, the Internet of Things (IoT) technology has moved from concept to large-scale application, becoming a key infrastructure connecting the physical and digital worlds. Massive numbers of IoT devices, such as industrial sensors, medical monitors, vehicle terminals, and smart home devices, are generating massive amounts of multi-dimensional, high-value industrial data at an unprecedented rate. This data is not only a core asset for enterprises to optimize production, improve efficiency, and innovate services, but also a strategic resource driving the digital and intelligent development of the entire society. However, in the practice of effectively managing, securely sharing, and fully releasing the value of this data, traditional technical architectures and data management paradigms have created increasingly prominent bottlenecks and challenges. In the complex IoT industry chain, the generation, aggregation, processing, and use of data involve multiple entities, such as equipment manufacturers, data collectors, platform operators, and end users. Data ownership, usage rights, and revenue rights are intertwined, and the ownership relationships are extremely vague. Traditional centralized data management platforms typically assign data ownership to the platform provider, causing data producers (such as enterprises or individuals) to lose actual control over their data assets, making it impossible to effectively trace data usage, and even more difficult to obtain the due value return when the data is used. This situation of "data sovereignty slipping away" greatly inhibits the enthusiasm for data sharing and creates a large number of "data silos." Secondly, IoT industry data, especially information involving core industrial production parameters, corporate trade secrets, and users' personal health and behavior, is extremely sensitive. Traditional centralized database architectures inherently have a "single point of failure" risk; once a server is hacked or maliciously manipulated by insiders, it can easily lead to large-scale, catastrophic data breaches. Furthermore, in multi-party data sharing scenarios, there is often a lack of effective trust among the parties. Data requesters worry about the authenticity or incompleteness of the data they obtain, while data providers worry about the misuse or overuse of their sensitive data. This pervasive "trust deficit" makes cross-institutional and cross-domain data collaboration extremely difficult, severely hindering the free flow of data elements and value creation.

[0003] Existing blockchain technology, with its decentralized, immutable, and traceable characteristics, is considered an ideal solution to the aforementioned data sovereignty and trust issues. However, existing general-purpose blockchain solutions show significant shortcomings when directly applied to complex IoT industry scenarios. Public blockchains, represented by Bitcoin and Ethereum, while ensuring extremely high security through their consensus mechanisms (such as Proof-of-Work), suffer from extremely low transaction throughput (TPS) and long transaction confirmation delays, completely failing to meet the demands of high-concurrency on-chain processing of massive amounts of data in IoT scenarios. Data on public blockchains is public to all nodes, failing to meet the confidentiality requirements of industry data, especially sensitive data. While traditional consortium blockchains offer access control, their privacy protection schemes (such as channels and private data sets) still have shortcomings in terms of flexibility, scalability, and cross-institutional auditing. Existing consensus protocols (such as Proof-of-Work, Proof-of-Stake, and PBFT) are mostly designed for homogeneous computing nodes. However, nodes in an IoT environment vary greatly in computing power, network conditions, storage capacity, and trustworthiness, exhibiting a high degree of heterogeneity. Employing "one vote, one vote" or simple computational power / proof-of-stake mechanisms cannot fairly and efficiently reflect the true contributions and reliability of nodes. In fact, the widespread participation of low-quality nodes may drag down the overall network performance and security, or allow nodes with powerful computing capabilities to monopolize consensus power. While traditional smart contracts can execute pre-defined business logic, their computing and data processing capabilities are extremely limited, making it impossible to run complex artificial intelligence or machine learning models directly on the blockchain. This leads to the prevalence of an "on-chain rights confirmation, off-chain computation" model, but in off-chain computation, data privacy and compliance are equally difficult to guarantee. How to deeply and securely integrate the powerful analytical capabilities of AI with the trusted environment of blockchain is a pressing technical challenge that needs to be addressed.

[0004] Federated learning, as an emerging distributed privacy computing technology, allows participating parties to jointly train a global model without sharing their local raw data, offering a new approach to solving data silos and privacy protection issues. However, in practical applications, federated learning itself faces numerous challenges. In federated learning tasks, how to fairly and accurately quantify and evaluate the data quality and model contribution of each participant, and design a transparent and automated incentive mechanism accordingly, is crucial to driving continuous and high-quality participation from all parties. Existing frameworks lack effective solutions for this. Traditional federated learning typically relies on a centralized coordinator (or aggregation server) to collect and aggregate model updates from all parties. This centralized coordinator itself becomes a new point of trust risk and a single point of failure. Ensuring the decentralization, transparency, and verifiability of the model aggregation process is a core issue that needs to be addressed when combining federated learning with blockchain.

[0005] In conclusion, the current IoT industry urgently needs a new technological paradigm that can collaboratively address the four core challenges—data sovereignty verification, deep privacy protection, efficient consensus among heterogeneous nodes, and trusted value mining—within a unified framework. Existing single technologies, whether traditional centralized platforms or general-purpose blockchains or federated learning schemes, cannot independently and perfectly address this complex systemic problem. Therefore, developing a comprehensive solution that deeply integrates a dual-chain architecture, improved consensus protocols, Transformer-enabled dynamic weight allocation, and a collaborative mechanism between federated learning and smart contracts has extremely important theoretical significance and broad industrial application prospects. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a blockchain-based method for confirming and trusting the ownership of IoT industry data, comprising the following steps:

[0007] Step S1: Construct a dual-chain separation architecture that is physically and logically isolated for systematic full lifecycle management of raw data collected by various IoT devices;

[0008] Step S2: In the consensus layer composed of all nodes in the network, run the improved Byzantine Fault-Tolerant IPBFT consensus protocol and the improved view switching process, which have been deeply optimized and enhanced by multiple mechanisms, to ensure data consistency and transaction finality of the entire distributed ledger network.

[0009] Step S3: Construct a federated learning framework with a three-layer distributed architecture of client-agent-coordinator at the application layer and modular smart contracts to ensure that no raw data leaves the control of its local owner, thereby achieving information synchronization and verification between the private chain and the public chain.

[0010] Beneficial effects:

[0011] 1. This invention achieves complete data sovereignty restitution and refined ownership confirmation throughout the entire data lifecycle, fundamentally solving the problems of ambiguous data ownership and "data silos." In existing technologies, whether centralized data platforms or general blockchain solutions, it is difficult to clearly define and effectively protect the complex ownership of IoT data. This invention binds each IoT device with an immutable decentralized identity identifier (DID) based on its underlying hardware physical characteristics. From the very source of data generation, it endows data with an inherent, cryptographically verifiable "identity tag." This is equivalent to issuing a unique "digital ID card" to each piece of data, firmly anchoring its ownership to the data producer (device owner) from the outset. Based on this, this invention utilizes a dual-chain architecture to record key metadata such as data usage permissions and access records on a public blockchain in the form of smart contracts, forming a public, transparent, and immutable ownership confirmation and authorization ledger. Data owners can manage their data like their own digital assets, by calling smart contracts to perform refined operations such as authorizing, revoking, and setting access periods at extremely low cost and high efficiency. This design completely overturns the traditional platform model of "passive data surrender and loss of sovereignty," returning complete control of data (including ownership, usage rights, and revenue rights) to its rightful owner. This complete return of data sovereignty greatly enhances the sense of security and trust among data owners, effectively breaking down "data silos" formed due to concerns about data loss of control. It fundamentally stimulates the intrinsic motivation for data sharing and circulation, laying a solid foundation of trust for building a thriving data market.

[0012] 2. This invention constructs a deep privacy protection system that balances ultimate security isolation with trusted and controlled interaction, realizing the technological ideal of "data usable but invisible." The high sensitivity of IoT industry data is a core obstacle hindering its sharing. Existing technologies often compromise on privacy protection: public blockchains lack privacy, traditional databases pose centralized risks, and consortium blockchain privacy solutions are insufficient in terms of flexibility and auditability. This invention's unique dual-chain separation architecture provides an elegant and robust solution. Highly sensitive raw data, after being encrypted with high-strength AES-256 based on device keys, is securely stored on a private blockchain with strictly controlled access permissions, inaccessible to outsiders. Only the existence proof (hash anchor), metadata, and access control policies of this encrypted data are recorded on a completely public and transparent public blockchain. This "content inside, credentials outside" design achieves physical-level security isolation and logical-level trusted association. More importantly, this invention constructs a programmatic and automated "data gatekeeper" by deploying cross-chain interactive smart contracts. Any request to access data on the private blockchain must undergo rigorous review by a smart contract on the public blockchain. This review process is entirely executed by code, is transparent, and eliminates the possibility of human intervention. Access is only permitted if predefined permission policies are met (such as verifying DID, signatures, and reputation scores), and typically returns computation results or a limited view of the data, rather than the original data itself. This architecture perfectly realizes the technological ideal of "data usable but invisible," meaning that data can be used for collaborative computation and value mining without leaving its secure domain, thereby maximizing its application value while ensuring absolute data security and privacy.

[0013] 3. This invention pioneers an intelligent and forward-looking consensus mechanism capable of adapting to the highly heterogeneous environment of the Internet of Things (IoT), significantly improving network performance and security. The heterogeneity of nodes in the IoT environment poses a significant challenge to traditional consensus protocols. This invention revolutionarily abandons traditional weight allocation methods that rely on simple formulas or single dimensions (such as computing power or stake), and innovatively introduces a dynamic weight allocation mechanism based on the Transformer model. This represents a paradigm shift from "rule-based" to "learning-based." The Transformer model, with its powerful self-attention mechanism, can deeply mine complex, non-linear long-term behavioral patterns and potential correlations from the time series of multi-dimensional state data (covering computing power, network, behavioral reputation, etc.) of a node's history, revealing patterns that are difficult to capture with static formulas. For example, it can identify a node with low instantaneous computing power but extremely stable network connectivity and a perfect historical behavioral record, thus assigning it higher weight. This mechanism endows the consensus layer with "intelligence" and "foresight," no longer simply summarizing the past of nodes, but predicting the future reliability and contribution potential of nodes. Based on this precise weight allocation, the IPBFT protocol becomes more efficient and fair in areas such as master node election and voting weight calculation. The network can adaptively and dynamically assign core consensus power to nodes that are most likely to make positive contributions to the network now and in the future, while marginalizing or penalizing nodes with poor behavior or performance. This not only significantly improves the transaction throughput (TPS) and confirmation speed of the entire distributed network in high-concurrency, high-dynamic IoT scenarios, but also significantly enhances its robustness against malicious attacks and in response to node failures.

[0014] 4. This invention achieves a seamless and deep integration of federated learning and blockchain technology, constructing an automated and trustworthy value closed loop from data contribution to value realization. By deeply integrating a three-layer federated learning framework with IPBFT consensus and smart contracts, this invention systematically solves the core pain points of federated learning in independent applications, such as centralized risks, difficulties in contribution measurement, and lack of incentives. First, the Paillier homomorphic encryption scheme ensures absolute privacy and security of all model gradients during the uploading and aggregation process. Second, and most importantly, the verification right of the model aggregation results is entrusted to the decentralized IPBFT consensus protocol. This means that the aggregation behavior of any proxy node must be verified by the consensus of all nodes in the network, thereby completely eliminating the single point of trust dependence on centralized aggregation servers in traditional federated learning and ensuring the transparency, fairness, and immutability of the global model update process. Furthermore, this invention constructs a complete value closed loop for the entire federated learning ecosystem by deploying a series of functional smart contracts. Task management contracts ensure the standardization and automation of the process; while data contribution and proof-of-stake contracts act like a diligent and absolutely impartial "bookkeeper," recording the effective contributions of each participant (whether a data-providing client or an aggregation agent node) immutably on the blockchain in the form of verifiable digital credentials. These credentials can be directly used as the basis for revenue distribution, service fee settlement, or acquisition of other network rights in the future. This design not only provides participants with strong and credible incentives for participation but also bridges the last mile from "data contribution" to "value realization," thereby attracting more and higher-quality data owners to join this trustworthy distributed AI collaborative ecosystem, forming a virtuous cycle of sustainable development. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of a blockchain-based method for confirming and trusting the ownership of IoT industry data according to the present invention.

[0016] Figure 2 This is a schematic diagram of a dual-chain separation architecture;

[0017] Figure 3 A schematic diagram of the collaborative process of dynamic weighted consensus and federated learning executed between the consensus layer and the application layer;

[0018] Figure 4 This is a structural block diagram of a blockchain-based IoT industry data ownership confirmation and trusted sharing system according to the present invention. Detailed Implementation

[0019] 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.

[0020] Example 1:

[0021] like Figure 1 As shown in the figure, an embodiment of the present invention provides a method for confirming ownership and trusting the sharing of IoT industry data based on blockchain, which includes the following steps:

[0022] Step S1: Construct a dual-chain separation architecture that is physically and logically isolated for systematic full lifecycle management of raw data collected by various IoT devices;

[0023] Step S2: In the consensus layer composed of all nodes in the network, run the improved Byzantine Fault-Tolerant IPBFT consensus protocol and the improved view switching process, which have been deeply optimized and enhanced by multiple mechanisms, to ensure data consistency and transaction finality of the entire distributed ledger network.

[0024] Step S3: Construct a federated learning framework with a three-layer distributed architecture of client-agent-coordinator at the application layer and modular smart contracts to ensure that no raw data leaves the control of its local owner, thereby achieving information synchronization and verification between the private chain and the public chain.

[0025] In one embodiment, step S1 above: constructing a physically and logically isolated dual-chain separation architecture for systematic full lifecycle management of raw data collected by various IoT devices, specifically including:

[0026] Step S11: The dual-chain separation architecture includes: a private chain for storing encrypted sensitive data and a public chain for storing public metadata;

[0027] like Figure 2 The diagram shown is a schematic of this dual-chain separation architecture, and its specific components are as follows:

[0028] Private blockchain:

[0029] A permissioned blockchain network dedicated to storing encrypted, highly sensitive raw data or fragments thereof. Its design goal is to maximize data confidentiality and isolation.

[0030] It is built using an enterprise-grade distributed ledger technology platform. In its implementation, Hyperledger Fabric's channel mechanism is used to create isolated ledgers for a group of participants with specific data-sharing relationships (e.g., party A and party B), ensuring that members outside the channel cannot access the data within the channel. The data itself can leverage Fabric's private data set functionality to achieve on-chain hash notarization and off-chain peer-to-peer data distribution, further enhancing privacy.

[0031] Public blockchain:

[0032] A blockchain network open to all alliance members or a wider range of participants, used to store publicly verifiable metadata, identity information, state anchors, and system-level smart contracts. Its design goal is to maximize the system's transparency, auditability, and interoperability.

[0033] It is built using a blockchain framework compatible with the Ethereum Virtual Machine to leverage the mature Solidity smart contract development ecosystem. The consensus protocol running on this chain is the Improved Byzantine Fault-Tolerant (IPBFT) protocol, which will be detailed later in this invention.

[0034] Step S12: Based on the Trusted Execution Environment (TEE), generate the decentralized identity (DID) of the IoT device, specifically including:

[0035] Step S121: In the Trusted Execution Environment (TEE), read and extract the set of hardware characteristics inherent to the IoT device, which are physically unique and cannot be tampered with by software after leaving the factory. The set of hardware characteristics includes: the unique chip ID of the TEE environment itself, the factory serial numbers of various sensors installed on the IoT device, and the physical MAC address of its network interface card (NIC). The specific steps are as follows:

[0036] a. Read and extract the unique and tamper-proof set of hardware characteristics H inherent to the physical device through specific APIs or instructions provided by the TEE (such as sgx_getkey or sgx_create_report).

[0037] b. The feature set H includes at least:

[0038] H id The unique chip ID of the TEE environment itself.

[0039] H sn The serial number of the key sensors (such as encoders and grating rulers) installed on the equipment is fixed during manufacturing.

[0040] H macThe physical MAC address of its network interface card.

[0041] Step S122: Concatenate the hardware feature set into strings according to a predefined deterministic order to form an original fingerprint string that represents the unique hardware DNA of the IoT device;

[0042] The extracted features of multiple heterogeneous physical hardware {H id H sn H mac The strings are concatenated according to a predefined deterministic order (e.g., alphabetical order of feature names) to form a raw fingerprint string S representing the unique hardware DNA of the device. raw :

[0043] S raw = Concatenate(Sort_by_key({key1:value1, key2:value2, ...}));

[0044] Step S123: Using the initial fingerprint string as input, call the SHA-256 cryptographic hash algorithm to perform a one-way operation, generating a 256-bit fixed-length hash digest H. did It serves as the unique identifier (DID) for IoT devices throughout the entire blockchain network and is used for all subsequent authentication, signing, and access control operations.

[0045] H did = SHA256(S raw );

[0046] This H did This is the core part that is formally established as the unique identifier (DID) of the device within the entire blockchain network, which can be represented as did:method_name: H did The DID and its associated public key (via H did As a seed derivative, it is recorded in the DID registration smart contract on the public blockchain.

[0047] Step S13: Automatically classify the collected raw data according to data sensitivity, specifically including:

[0048] Step S131: Deploy and run a multi-dimensional sensitivity auto-grading model. The model’s rule engine-based logical decision matrix is ​​based on three independent dimensions: the inherent attributes of the data itself, the source or owner attributes of the data, and the business context attributes in which the data will be applied.

[0049] Real-time, automated sensitivity analysis and classification of the collected data streams are a prerequisite for achieving hierarchical storage.

[0050] This invention deploys and runs a rule-based logical decision matrix. The model quantifies and evaluates data from three independent dimensions:

[0051] Dimension 1: Inherent Data Attributes: Analyze the type and content of data fields. Example of a preset rule: If the data type is a core production process parameter, a user's personal biometric characteristic, or a company's undisclosed trade secret, then assign a high sensitivity weight value W_c_high.

[0052] Dimension Two: Data Source / Owner Attributes: Analyzes the identity of the data provider. Example of a preset rule: If the data originates from a certified enterprise-level or government-level node, it is assigned the second-highest sensitivity weight value, W_o_medium.

[0053] Dimension 3: Data Application Context Attributes: Analyze the intended purpose for which the data is collected. Example of a preset rule: If the data application scenario is financial risk control or core algorithm training, then assign a high sensitivity weight value W_p_high.

[0054] Step S132: Calculate the total sensitivity score for each piece of original data, determine its sensitivity level based on the total sensitivity score, and store it in the corresponding private or public blockchain, including the following steps:

[0055] a. For each data point D, calculate its total sensitivity score Score(D) = Σ W based on the rules it matches. i .

[0056] b. Based on the preset scoring threshold {T} low , T high}, divide the data D into {L} according to its total sensitivity score. high ,L medium , L low There are three levels.

[0057] c. If the grade of D is L high If so, perform a symmetric encryption operation C = Encrypt_AES256(D, K) on it and store the ciphertext C in the private chain.

[0058] d. If the rank of D is L medium or L low If the data is metadata (Meta(D)) of highly sensitive data, it will be directly stored in the public blockchain.

[0059] Figure 2 This is a schematic diagram of a dual-chain separation architecture.

[0060] In one embodiment, step S2 above—running a deeply optimized and multi-mechanism-enhanced improved Byzantine Fault-Tolerant (IPBFT) consensus protocol and an improved view switching process in the consensus layer composed of nodes in the network—specifically includes:

[0061] Step S21: Improve the dynamic weight allocation mechanism based on the Transformer model introduced in the Byzantine Fault-Tolerant IPBFT consensus protocol. Based on the time-series dataset reflecting the historical state and behavior of each node, generate a comprehensive weight prediction value for the node's contribution potential and reliability in the next consensus cycle. This value is used for calculating the voting weights for the IPBFT protocol's master node election and block confirmation. Specifically, this includes:

[0062] Step S211: Improve the Byzantine Fault-Tolerant IPBFT consensus protocol. Based on the Transformer model, its input is a multi-dimensional time series dataset TS collected and constructed for each consensus node i. i TS i = {X i X(t) | t = 1, 2, ..., T}, where X i (t) is the state vector of node i at time step t;

[0063] X i (t) contains three parallel subsequences:

[0064] Historical computing power metrics sequence: S_compute(t) = [cpu_usage(t), mem_usage(t), disk_iops(t)];

[0065] Where cpu_usage is the CPU utilization rate, mem_usage is the memory usage rate, and disk_iops is the disk IOPS metric;

[0066] Historical network quality index sequence: S_network(t) = [bandwidth(t), rtt(t)];

[0067] Where bandwidth is the real-time bandwidth and rtt is the network round-trip latency;

[0068] Historical behavioral reputation score sequence: S_reputation(t) = α VoteAccuracy(t-1) + (1-α) TaskCompletionRate(t-1); α is the weight;

[0069] Wherein, VoteAccuracy is the voting accuracy rate, and TaskCompletionRate is the contribution completion rate in the historical federated learning task;

[0070] Among them, the historical computing power index sequence reflects its physical processing capability, the historical network quality index sequence measures its communication efficiency, and the historical behavior reputation score sequence evaluates its reliability through its historical voting and task performance. From three dimensions—hardware performance, communication capability, and historical reliability—the overall state of a node at time t is comprehensively quantified.

[0071] Step S212: Transfer TS i Input a pre-trained Transformer model, and the model's multi-head self-attention layer captures the complex, non-linear dependencies and long-term evolution patterns of node state data over time.

[0072] Step S213: Finally, the Encoder layer of the Transformer model outputs a context vector sequence H containing temporal information. i Take the output vector h of the last time step T. i (T) is nonlinearly mapped through one or more fully connected layers (FC) to generate the comprehensive weight prediction value W of the node in the next consensus cycle. i (T+1), where W i (T+1) = FC(h i (T));

[0073] Weight value W i (T+1) is then applied to the IPBFT protocol for master node election (e.g., using weighted random sampling) and the calculation of voting weights for block confirmation (e.g., requiring a COMMIT message with a cumulative weight of more than 2 / 3 to be received).

[0074] Step S22: The improved view switching process introduces an adaptive failure rate threshold T that is dynamically correlated with network status. fault When a master node is detected to have a cumulative number of consecutive timeouts, non-response, or broadcasting malicious messages exceeding T... fault At that time, all honest nodes will automatically and synchronously trigger the view switching protocol; in the process of electing a new master node, priority will be given to selecting from the candidate pool, which consists of nodes ranked at the top of the comprehensive weight prediction value.

[0075] This invention optimizes the view change mechanism in the IBFT protocol to improve efficiency and robustness. This is achieved by introducing a threshold T. faultThis threshold is dynamically calculated based on the total number of nodes n in the current network and the theoretically tolerable maximum number of Byzantine nodes f (f < (n-1) / 3). For example, T fault It can be set to f+1. When a master node is detected to have accumulated more than T_fault instances of consecutive timeouts, non-response, or broadcasting malicious messages, all honest nodes in the system will automatically and synchronously trigger the View Change protocol.

[0076] During the election of a new master node, the process is designed to prioritize selection from a high-reputation candidate pool of 506. This candidate pool is composed of the recent comprehensive weighted prediction value W obtained through the aforementioned step S213. i The newly elected master node is composed of the top k nodes (where k is a system parameter, e.g., k = ceil(n / 2)). This method ensures that the newly elected master node has excellent performance and historical behavior records, thereby improving the success rate of view switching and the stability of the new view.

[0077] In one embodiment, step S3 above—building a client-proxy-coordinator three-layer distributed federated learning framework and modular smart contracts at the application layer—ensures that any raw data does not leave the control of its local owner, thereby achieving information synchronization and verification between the private chain and the public chain. Specifically, this includes:

[0078] Step S31: Construct a federated learning framework with a three-tier distributed architecture of client-agent-coordinator at the application layer, including:

[0079] Client: A participant that holds local private data and performs local model training;

[0080] Proxy node: Responsible for aggregating the encrypted model updates of a group of clients, and does not handle plaintext data itself;

[0081] Coordinator: Responsible for the management of the global model, key distribution, and decryption of the final aggregation result;

[0082] The federated learning framework of this invention employs a Paillier homomorphic encryption scheme to encrypt gradient data with a public key, generating homomorphic ciphertext. This ensures that even during transmission and aggregation, no intermediary (including proxy nodes) can access any information about local private data contained within the gradient itself. Proxy nodes perform a weighted average operation on the encrypted gradients in ciphertext. This improves the efficiency and security of the aggregation process, and the aggregated encrypted results are uniformly submitted to the coordinator node. The coordinator node verifies the hash digests of the aggregation results submitted by each proxy node through the IPBFT consensus protocol, ensuring that no proxy node maliciously tampers with or submits false aggregation results. After achieving network-wide consensus, the coordinator node decrypts the final aggregated gradient and uses an asynchronous update mechanism to apply the update to the global model. The specific steps are as follows:

[0083] a. The coordinator generates a Paillier public-private key pair (pk, sk) and distributes the public key pk.

[0084] b. Client i calculates the local model gradient g. i Then, use pk for encryption: c i = Enc(pk, g i ).

[0085] c. The proxy node collects cryptographic gradients from the clients it governs. i Then, a weighted average operation is performed in the encrypted state. This utilizes Paillier's additive homomorphism Enc(m1). Homomorphism of Enc(m2) = Enc(m1+m2) and scalar multiplication Calculate the encrypted gradient C after aggregation. agg .

[0086] d. The proxy node will C agg Submit to the coordinator.

[0087] e. The coordinator first uses the IPBFT consensus protocol to process the hash(C) submitted by each proxy node. agg To conduct network-wide consensus verification.

[0088] f. After consensus is reached, the coordinator uses the private key sk to decrypt the final aggregate gradient: G_final = Dec(sk, C_final_agg), and updates the global model with G_final.

[0089] Step S32: Deploy a set of modular smart contracts on the public blockchain, including: federated learning task management contract, data contribution and proof-of-stake contract, and data access control and audit contract;

[0090] To automate processes and clarify responsibilities, this invention deploys a set of modular smart contracts on a public blockchain.

[0091] Federated Learning Task Management Contract: Responsible for the lifecycle management of the entire federated learning task, including task release (defining the model, hyperparameters, and rewards), participant registration and qualification review, global model version distribution, time window control for cryptographic gradient submission, and on-chain recording and announcement of the final results.

[0092] Data Contribution and Proof-of-Stake Contract: This serves as an immutable contribution ledger. When a participant successfully completes their contribution (e.g., submitting a valid cryptographic gradient), the coordinator node invokes this contract to record a verifiable proof of contribution. This proof includes the participant's DID, task ID, contribution quantification value, etc., and can serve as the basis for future value distribution or stake settlement.

[0093] Data Access Control and Audit Contract: Defines access policies for the trained global model or data insights generated by the model. The contract embeds Access Control Lists (ACLs) or Role-Based Access Control (RBAC) logic. Any external call must be authenticated through this contract. Each successful access or call, including the requester, timestamp, call parameters, and purpose, is recorded through the contract's event mechanism, forming a transparent, traceable, and tamper-proof audit trail.

[0094] Step S33: Employ a cross-chain interaction mechanism that includes hash anchoring and smart contract verification to achieve information synchronization and verification between the private chain and the public chain.

[0095] To coordinate information synchronization and verification between private and public blockchains, this invention employs a cross-chain interaction mechanism that includes hash anchoring and smart contract verification.

[0096] Hash anchoring and state synchronization are performed by retrieving the block header hash of the latest confirmed block from the confidential blockchain's on-chain state at pre-defined, fixed time intervals via one or more relay nodes. This block header hash is then encapsulated into a cross-chain transaction, broadcast to all public blockchain nodes via a P2P network, and ultimately verified and recorded by a specific smart contract deployed on the public blockchain. This process creates a series of trustworthy, timestamped, and immutable anchor points on the public blockchain regarding the confidential blockchain's state, providing a solid foundation for subsequent verification of the existence and integrity of cross-chain data. The specific steps are as follows:

[0097] a. One or more relay nodes periodically retrieve the block header (Header_B) of the latest confirmed block from private chain 110.

[0098] b. The relay node encapsulates the Hash(Header_B) into a cross-chain transaction and submits it to the anchor contract deployed on the public chain.

[0099] c. After the anchor contract verifies the legality of the transaction (such as the signature of the relay node), it records the Hash(Header_B) together with the corresponding private chain block height Height_B and public chain timestamp Timestamp_P to form a state anchor.

[0100] Executing cross-chain permission verification based on smart contracts: When any external entity or smart contract on another chain intends to request access to encrypted data stored on a confidential chain via the API provided by the public chain, the request must be routed to a permission verification smart contract deployed on the public chain. This contract will strictly enforce a preset access control policy, requiring the requester to provide its valid DID and submit a digital signature or credential proving its access rights. The contract will ultimately decide atomically whether to approve the cross-chain access request and return the data index, or reject the request, by verifying multiple conditions, including verifying the valid path of the DID in the Merkle tree on the public chain, checking whether its associated behavioral reputation score meets the threshold, and verifying the legality of its digital signature. The specific steps are as follows:

[0101] a. When an external entity E intends to request access to encrypted data D_c stored on a private blockchain, its request must be routed to the permission verification smart contract on the public blockchain.

[0102] b. The requesting party E must provide its valid DID, a digital signature or credential proving its access rights (such as a token issued by the data owner), and the target data D. c Location information on the private blockchain (such as transaction IDTxID_B and block height Height_B).

[0103] c. The authorization verification contract performs the following multiple verifications:

[0104] i. Verify the validity of E's DID and credentials.

[0105] ii. Query the anchor contract to obtain the private chain block header hash H_anchor corresponding to Height_B.

[0106] iii. Require the data owner or requester to provide a Merkel proof from TxID_B to the Merkel root hash of the transaction in the block header.

[0107] iv. Execute the Merkle proof verification algorithm within the smart contract.

[0108] d. The contract will only approve the cross-chain access request if all verifications pass, and may return the path to the data decryption key or a one-time access token.

[0109] Figure 3 A schematic diagram of the collaborative process of dynamic weighted consensus and federated learning executed between the consensus layer and the application layer.

[0110] Example 2:

[0111] like Figure 4 As shown, this embodiment of the invention provides a blockchain-based IoT industry data ownership confirmation and trusted sharing system, including the following modules:

[0112] Data layer module 41 is used to build a dual-chain separation architecture that is physically and logically isolated, and is used to systematically manage the raw data collected by various IoT devices throughout their entire lifecycle.

[0113] Consensus layer module 42 is used to run the improved Byzantine Fault-Tolerant IPBFT consensus protocol and the improved view switching process, which are deeply optimized and enhanced by multiple mechanisms, in the consensus layer composed of nodes in the network, so as to ensure data consistency and transaction finality of the entire distributed ledger network.

[0114] Application layer module 43 is used to build a federated learning framework and modular smart contracts with a three-layer distributed architecture of client-agent-coordinator in the application layer, so as to realize information synchronization and verification between private chain and public chain under the condition that no raw data leaves the control of its local owner.

[0115] A blockchain-based device for confirming and trusting the ownership of IoT industry data includes one or more electronic devices, wherein the one or more electronic devices are used to implement a blockchain-based method for confirming and trusting the ownership of IoT industry data.

[0116] 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 blockchain-based method for confirming and trusting the ownership of IoT industry data.

[0117] 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 blockchain-based method for confirming data ownership and trustworthy sharing in the Internet of Things (IoT) industry, characterized in that: include: Step S1: Construct a dual-chain separation architecture that is physically and logically isolated for systematic full lifecycle management of raw data collected from various IoT devices; Step S2: In the consensus layer composed of all nodes in the network, run the improved Byzantine Fault-Tolerant IPBFT consensus protocol and the improved view switching process, which have been deeply optimized and enhanced by multiple mechanisms, to ensure data consistency and transaction finality of the entire distributed ledger network. Step S3: Construct a federated learning framework with a three-layer distributed architecture of client-agent-coordinator and modular smart contracts in the application layer to ensure that no raw data leaves the control of its local owner, thereby achieving information synchronization and verification between the private chain and the public chain.

2. The method for confirming and trusting the ownership of IoT industry data based on blockchain according to claim 1, characterized in that, Step S1: Construct a dual-chain separation architecture that is physically and logically isolated for systematic, full lifecycle management of raw data collected from various IoT devices, specifically including: Step S11: The dual-chain separation architecture includes: a private chain for storing encrypted sensitive data and a public chain for storing public metadata; Step S12: Generate the decentralized identity (DID) of IoT devices based on the Trusted Execution Environment (TEE); Step S13: Automatically classify the collected raw data according to data sensitivity.

3. The method for confirming and trusting the ownership of IoT industry data based on blockchain according to claim 2, characterized in that, Step S12: Based on the Trusted Execution Environment (TEE), generate the decentralized identity (DID) of the IoT device, specifically including: Step S121: In the Trusted Execution Environment (TEE), read and extract the set of hardware features inherent to the IoT device, which are unique at the physical level and cannot be tampered with by software after leaving the factory; the set of hardware features includes: the unique chip ID of the TEE environment itself, the factory serial number of various sensors on the IoT device, and the physical MAC address of its network interface card (NIC). Step S122: Concatenate the hardware feature set into strings according to a predefined deterministic order to form an original fingerprint string representing the unique hardware DNA of the IoT device; Step S123: Using the initial fingerprint string as input, call the SHA-256 cryptographic hash algorithm to perform one-way operation to generate a 256-bit fixed-length hash digest, which serves as the unique identity identifier (DID) of the IoT device in the entire blockchain network and is used for all subsequent authentication, signing, and access control operations.

4. The method for confirming and trusting the ownership of IoT industry data based on blockchain according to claim 2, characterized in that, Step S13: Automated classification of the collected raw data based on data sensitivity, specifically including: Step S131: Deploy and run a multi-dimensional sensitivity auto-grading model. The model’s rule engine-based logical decision matrix is ​​based on three independent dimensions: the inherent attributes of the data itself, the source or owner attributes of the data, and the business context attributes in which the data will be applied. Step S132: Calculate the total sensitivity score for each piece of original data, determine its sensitivity level based on its total sensitivity score, and store it in the corresponding private chain or public chain.

5. The method for confirming and trusting the ownership of IoT industry data based on blockchain according to claim 1, characterized in that, Step S2: In the consensus layer composed of all nodes in the network, an improved Byzantine Fault-Tolerant (IPBFT) consensus protocol with deep optimization and multi-mechanism enhancements and an improved view switching process are run to ensure data consistency and transaction finality of the entire distributed ledger network, specifically including: Step S21: The improved Byzantine Fault-Tolerant IPBFT consensus protocol introduces a dynamic weight allocation mechanism based on the Transformer model. Based on the time series dataset collected by each node reflecting its historical state and behavior, it generates a comprehensive weight prediction value of the node's contribution potential and reliability in the next consensus cycle, which is used for the voting weight calculation of the IPBFT protocol's master node election and block confirmation. Step S22: The improved view switching process introduces a fault rate adaptive threshold T that is dynamically correlated with the network state. fault When a master node is detected to have a cumulative number of consecutive timeouts, non-response, or broadcasting malicious messages exceeding T... fault At that time, all honest nodes will automatically and synchronously trigger the view switching protocol; in the process of electing a new master node, priority will be given to selecting from the candidate pool, which consists of the nodes ranked at the top of the comprehensive weight prediction value.

6. The method for confirming and trusting the ownership of IoT industry data based on blockchain according to claim 5, characterized in that, Step S21: The improved Byzantine Fault-Tolerant IPBFT consensus protocol introduces a dynamic weight allocation mechanism based on the Transformer model. This mechanism generates a comprehensive weight prediction value for each node's contribution potential and reliability in the next consensus cycle, based on the time-series dataset reflecting its historical state and behavior collected from each node. This prediction value is used for calculating the voting weights in the IPBFT protocol's master node election and block confirmation. Specifically, this includes: Step S211: The improved Byzantine Fault-Tolerant IPBFT consensus protocol is based on the Transformer model, and its input is a multi-dimensional time series dataset TS collected and constructed for each consensus node i. i TS i = {X i X(t) | t = 1, 2, ..., T}, where X i (t) is the state vector of node i at time step t; X i (t) contains three parallel subsequences: Historical computing power metrics sequence: S_compute(t) = [cpu_usage(t), mem_usage(t), disk_iops(t)]; Where cpu_usage is the CPU utilization rate, mem_usage is the memory usage rate, and disk_iops is the disk IOPS metric; Historical network quality index sequence: S_network(t) = [bandwidth(t), rtt(t)]; Where bandwidth is the real-time bandwidth and rtt is the network round-trip latency; Historical behavioral reputation score sequence: S_reputation(t) = α VoteAccuracy(t-1) + (1-α) TaskCompletionRate(t-1); Where VoteAccuracy is the voting accuracy rate, TaskCompletionRate is the contribution completion rate in the historical federated learning task, and α is the weight; Step S212: Transfer TS i Input a pre-trained Transformer model, and the model's multi-head self-attention layer captures the complex, non-linear dependencies and long-term evolution patterns of node state data over time. Step S213: Finally, the Encoder layer of the Transformer model outputs a context vector sequence H containing temporal information. i Take the output vector h of the last time step T. i (T) is nonlinearly mapped through one or more fully connected layers (FC) to generate the comprehensive weight prediction value W of the node in the next consensus cycle. i (T+1), where W i (T+1) = FC(h i (T)); Weight value W i (T+1) is then used to calculate the voting weights for master node election and block confirmation in the IPBFT protocol.

7. The method for confirming and trusting the ownership of IoT industry data based on blockchain according to claim 1, characterized in that, Step S3: Construct a federated learning framework with a three-layer distributed architecture of client-proxy-coordinator at the application layer and modular smart contracts to ensure that no raw data leaves the control of its local owner, thereby achieving information synchronization and verification between the private chain and the public chain. Specifically, this includes: Step S31: Construct a federated learning framework with a three-tier distributed architecture of client-agent-coordinator, including: Client: A participant that holds local private data and performs local model training; Proxy node: Responsible for aggregating the encrypted model updates of a group of clients, and does not handle plaintext data itself; Coordinator: Responsible for the management of the global model, key distribution, and decryption of the final aggregation result; Step S32: Deploy a set of modular smart contracts on the public blockchain, including: federated learning task management contract, data contribution and proof-of-stake contract, and data access control and audit contract; Step S33: Employ a cross-chain interaction mechanism that includes hash anchoring and smart contract verification to achieve information synchronization and verification between the private chain and the public chain.

8. A blockchain-based IoT industry data ownership confirmation and trusted sharing system, characterized in that, Includes the following modules: The data layer module is used to build a dual-chain separation architecture that is physically and logically isolated, and is used for systematic full lifecycle management of raw data collected by various IoT devices. The consensus layer module is used to run the improved Byzantine Fault-Tolerant IPBFT consensus protocol and the improved view switching process, which are deeply optimized and enhanced by multiple mechanisms, in the consensus layer composed of nodes in the network, so as to ensure data consistency and transaction finality of the entire distributed ledger network. The application layer module is used to build a federated learning framework and modular smart contracts with a three-layer distributed architecture of client-agent-coordinator in the application layer, ensuring that information synchronization and verification between private and public chains are achieved while ensuring that no raw data leaves the control of its local owner.

9. A blockchain-based device for confirming and trusting the ownership of IoT industry data, 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 7.

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 7.

Images