Layered dpos-based multi-chain architecture and data access method

Abstract

The application provides a layered DPoS-based multi-chain architecture and a data access method. The layered DPoS-based multi-chain architecture comprises: a plurality of attribute blockchains, each corresponding to an attribute subdomain divided by mutual exclusion, each attribute blockchain being maintained by a corresponding attribute committee and being used for recording data access control transactions in the attribute subdomain; wherein each attribute committee internally elects a verification node through a first layer of layered DPoS consensus, and the verification node performs consensus confirmation on transactions on the attribute blockchain; a global verification chain is in communication connection with each attribute blockchain, and is used for performing final consensus confirmation on transactions on each attribute blockchain that are confirmed by the first layer of consensus through a second layer of layered DPoS consensus, and maintaining global state consistency across attribute subdomains. The global state consistency across domains is efficiently maintained when multi-attribute domain data sharing is processed, and the system scalability is improved.

Description

Technical Field

[0001] This invention relates to the field of data sharing technology, and in particular to a multi-chain architecture and data access method based on hierarchical DPoS. Background Technology

[0002] The Internet of Things (IoT) is driving its large-scale deployment in smart cities, intelligent manufacturing, connected vehicles, and healthcare. Cross-domain collaboration between devices and the sharing of heterogeneous data from multiple sources are becoming key capabilities for intelligent applications. However, this also exposes data to higher risks of tampering and attacks throughout the entire data collection, transmission, storage, and sharing chain. Traditional access control schemes relying on centralized servers not only require additional trust and management costs in cross-domain scenarios but also suffer from single points of failure and difficulties in independently verifying policy states. Blockchain, with its decentralized, immutable, and traceable advantages, offers a new approach to trusted data sharing.

[0003] However, traditional blockchain architectures struggle to efficiently maintain cross-domain global state consistency when dealing with multi-attribute domain data sharing, and their system scalability is insufficient. Summary of the Invention

[0004] This invention provides a multi-chain architecture and data access method based on hierarchical DPoS, which solves the shortcomings of traditional blockchain architecture in the prior art, such as difficulty in efficiently maintaining cross-domain global state consistency and insufficient system scalability when handling multi-attribute domain data sharing.

[0005] This invention provides a multi-chain architecture based on hierarchical DPoS to support trusted data sharing in an IoT environment, comprising: Multiple attribute blockchains correspond to mutually exclusive attribute subdomains. Each attribute blockchain is maintained by a corresponding attribute committee to record data access control transactions within the attribute subdomain. Each attribute committee elects a verification node through the first layer of a hierarchical DPoS consensus mechanism. The verification node then confirms the transactions on the attribute blockchain. The global verification chain communicates and connects with blockchains of various attributes. It is used to perform final consensus confirmation on transactions on each attribute blockchain that have been confirmed by the first layer consensus through the second layer of the hierarchical DPoS consensus, and maintain the global state consistency across attribute subdomains.

[0006] According to a multi-chain architecture based on hierarchical DPoS provided by the present invention, the attribute committee is composed of blockchain nodes with preset computing capabilities and stable network connections, and the blockchain nodes include server nodes or edge computing nodes. Each attribute committee is independently responsible for identity management, access control policy storage, and data access transaction records within its corresponding attribute subdomain.

[0007] According to a multi-chain architecture based on hierarchical DPoS provided by the present invention, the nodes of the attribute committee elect representative nodes through a stake voting method, and the representative nodes serve as verification nodes. The attribute chain verification node set, composed of the verification nodes, packages, verifies, and confirms transactions on the attribute blockchain.

[0008] According to the multi-chain architecture based on hierarchical DPoS provided by the present invention, the consensus nodes of the global verification chain are composed of representative nodes elected by each attribute committee, or are composed of a set of global consensus nodes independent of the attribute committee.

[0009] According to the multi-chain architecture based on hierarchical DPoS provided by the present invention, it further includes: The Trust Center is used to generate common system parameters, register entities, and generate pseudonyms for each entity, which interact on each chain using the pseudonyms. Decentralized storage systems are used to store encrypted data; The proxy re-encryption module, integrated into the attribute committee, is used to perform re-encryption of the data encryption key in response to data access requests.

[0010] The present invention also provides a data access method applied to a multi-chain architecture based on hierarchical DPoS as described in any of the preceding claims, the method comprising: The data owner encrypts the data locally, uploads the encrypted data to a decentralized storage system, and submits the data hash and access control policy to the attribute blockchain of the attribute subdomain. The data accessor sends a data access request to the attribute committee of its attribute subdomain; After the attribute committee approves the data access request based on the access control policy, it re-encrypts the data encryption key through proxy re-encryption and returns the re-encrypted key ciphertext to the data accesser. The data access user uses the original key they hold to decrypt the key ciphertext and retrieves the encrypted data from the decentralized storage system.

[0011] According to a data access method provided by the present invention, the attribute committee also acts as a proxy re-encryption node, and performs re-encryption operations in response to the re-encryption request of the data accesser.

[0012] According to a data access method provided by the present invention, the data owner is an Internet of Things (IoT) device, which does not participate in blockchain consensus confirmation but is responsible for data encryption and integrity verification.

[0013] A data access method provided by the present invention further includes: Generate a hash aggregation traceability index for access authorization events recorded on the attribute blockchain, and compress multiple access authorization evidences into a fixed-length digest; Based on the comparison results between the fixed-length digest and the commitment value, the consistency of the data access records is verified without obtaining the original plaintext data.

[0014] According to a data access method provided by the present invention, the trusted center does not participate in the node key generation and access control process, but is used for entity registration and pseudonym generation.

[0015] This invention provides a multi-chain architecture and data access method based on layered DPoS. The multi-chain architecture based on layered DPoS establishes independent attribute committees for each mutually exclusive attribute subdomain, enabling parallel processing of access control transactions within different attribute domains. This significantly improves system throughput and scalability. Within each attribute committee, a first-layer election verification node using layered DPoS consensus completes the attribute chain consensus confirmation, reducing communication overhead and confirmation latency. The global verification chain uses a second-layer layered DPoS consensus to perform final consensus confirmation of confirmed transactions in each attribute chain. This achieves trusted, unified, and verifiable cross-domain global state without relying on centralized cross-chain coordination nodes, providing a highly scalable, efficient, and strongly consistent layered blockchain solution for multi-domain data sharing. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram of the multi-chain architecture based on hierarchical DPoS provided by the present invention; Figure 2 This is a flowchart of the data access method provided by the present invention; Figure 3 This is a schematic diagram of the multi-chain architecture and data access interaction based on hierarchical DPoS provided in this embodiment. Detailed Implementation

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

[0019] Figure 1 This is a schematic diagram of the multi-chain architecture based on hierarchical DPoS provided by the present invention.

[0020] like Figure 1 As shown in the figure, this embodiment provides a multi-chain architecture based on layered DPoS, which is mainly applied to cross-domain data sharing scenarios of the Internet of Things in smart cities, intelligent manufacturing, vehicle networking and healthcare. It solves the problems of low efficiency in maintaining global state consistency and insufficient system scalability in multi-attribute domain data sharing of blockchain architecture. At the same time, it takes into account the privacy, security and auditability of data access. The multi-chain architecture based on layered DPoS is constructed through the layered DPoS consensus mechanism to realize autonomous processing within attribute subdomains and trusted unity of global state across domains.

[0021] The multi-chain architecture based on layered DPoS includes: multiple attribute blockchains, each corresponding to a mutually exclusive attribute subdomain. Each attribute blockchain is maintained by a corresponding attribute committee to record data access control transactions within the attribute subdomain. Within each attribute committee, a verification node is elected through the first layer of layered DPoS consensus. The verification node then confirms the transactions on the attribute blockchain through consensus. A global verification chain communicates with each attribute blockchain and uses the second layer of layered DPoS consensus to finally confirm the transactions confirmed through the first layer consensus on each attribute blockchain, maintaining global state consistency across attribute subdomains.

[0022] Specifically, the global attribute space for IoT data sharing is first divided into mutually exclusive subdomains, resulting in several attribute subdomains. Each subdomain corresponds to an independent attribute blockchain, with no attribute overlap between them. Each blockchain is maintained by its respective attribute committee, which serves as the core management and consensus body for its respective attribute blockchain. The function of each attribute blockchain is to record data access control transactions within its subdomain, including but not limited to the on-chain recording of encrypted data hashes by data owners, registration of access control policies, recording of data access request audits, and storage of access authorization events. All transactions are stored on the blockchain as blockchain transactions, ensuring immutability and traceability.

[0023] Each attribute committee employs a layered DPoS consensus mechanism. The first layer completes the election of verification nodes and transaction consensus: the attribute committee first elects verification nodes with high computing power and high network stability from its own nodes through a stake voting method. The verification nodes then conduct consensus confirmation on all transactions on the blockchain of their respective attribute, including transaction legality verification, packaging, block generation and confirmation. The process is completed only within the attribute subdomain, realizing autonomous processing of transactions within the attribute subdomain, significantly reducing cross-domain communication overhead, improving consensus efficiency of transactions within a single domain, and shortening confirmation latency.

[0024] The Global Verification Chain is the core consensus chain across attribute subdomains. It establishes bidirectional communication connections with all attribute blockchains, enabling it to obtain transaction data and block information from each attribute blockchain in real time after confirmation through the first-layer consensus. The Global Verification Chain uses the second layer of layered DPoS consensus to complete the final consensus confirmation: it uniformly collects and verifies transactions that have passed the first-layer consensus on each attribute blockchain, confirms the cross-domain legality and consistency of transactions, and completes the final consensus on-chain. Simultaneously, based on this process, it synchronously updates the transaction status of all attribute subdomains. Without relying on centralized cross-chain coordination nodes, it can achieve trusted and unified global state and independent external verification across attribute subdomains, ensuring global consistency when sharing data across multiple attribute domains.

[0025] Each attribute blockchain processes access control transactions within its own subdomain in parallel, while the global verification chain is only responsible for cross-domain final consensus and state synchronization. The two work together to achieve domain autonomy and global management, significantly improving the system's throughput and scalability, and solving the problems of low processing efficiency and insufficient scalability in multi-attribute domain data sharing in traditional blockchain architectures.

[0026] Furthermore, based on the above embodiments, in this embodiment, the attribute committee is composed of blockchain nodes with preset computing capabilities and stable network connections. The blockchain nodes include server nodes or edge computing nodes. Each attribute committee is independently responsible for identity management, access control policy storage, and data access transaction records within its corresponding attribute subdomain.

[0027] Specifically, the nodes constituting each attribute committee are blockchain nodes with preset computing capabilities and stable network connections. Server nodes or edge computing nodes can be selected. These nodes can meet the attribute committee's computing resource requirements for transaction verification, consensus processing, and re-encryption operations. At the same time, the stable network connection ensures that the communication between the attribute chain and the global verification chain is synchronized without delay, adapts to the real-time data access requirements of the Internet of Things, ensures that various transaction processing within the attribute subdomain can be carried out efficiently and stably, and adapts to the access control requirements of large-scale IoT devices.

[0028] Each attribute committee possesses complete autonomy, independently responsible for three core tasks within its corresponding attribute subdomain: First, identity management, managing the entire lifecycle of all IoT devices within its subdomain, including identity registration, verification, and updates. Second, access control policy storage, persistently storing all data access control policies submitted by data owners and synchronizing them with policy records on the attribute blockchain. Third, data access transaction recording, working with the attribute blockchain to completely and accurately record all data access control transactions within its subdomain, ensuring transaction traceability. Management of each subdomain does not require cross-domain coordination, further improving system scalability and processing efficiency, while ensuring standardized management of identities and transactions within each subdomain.

[0029] Furthermore, based on the above embodiments, in this embodiment, the nodes of the attribute committee elect representative nodes through a stake voting method, and the representative nodes serve as verification nodes; the verification nodes form an attribute chain verification node set, which packages, verifies, and confirms the transactions on the attribute blockchain.

[0030] Specifically, within the attribute committee, a representative node is elected from all nodes through a stake-based voting process. This representative node is then directly appointed as the validator node. The rules of the stake-based voting are compatible with the first-layer rules of the hierarchical DPoS consensus mechanism, ensuring that the elected validator node possesses sufficient node stake and credibility. Electing validator nodes through stake-based voting complies with the requirements of DPoS consensus, ensuring the authority of the validator node and enhancing the credibility of the attribute chain transaction consensus.

[0031] The elected verification nodes will collectively form the attribute chain verification node set, which serves as the sole consensus entity for the attribute chain. This set performs three tasks: First, it packages non-consensus transactions on the attribute blockchain, processing them in batches according to their creation time or importance. Second, it verifies the packaged transaction packets, checking the legality and authenticity of each transaction. Third, it confirms the transaction blocks, generating new blocks from the verified transaction packets and confirming their on-chain status, thus formally completing the transaction consensus for the attribute chain. By concentrating the consensus work on a small number of authoritative nodes through the attribute chain verification node set, the communication overhead within the attribute committee is significantly reduced, further improving the efficiency of transaction consensus.

[0032] Furthermore, based on the above embodiments, in this embodiment, the consensus nodes of the global verification chain are composed of representative nodes elected by each attribute committee, or are composed of a set of global consensus nodes independent of the attribute committee.

[0033] Specifically, the consensus nodes of the global verification chain are its core consensus entities, responsible for completing the final consensus confirmation of the second layer of the layered DPoS consensus. This embodiment provides two feasible configuration methods, which can be flexibly selected according to the actual scenario of IoT data sharing, as follows: Method 1: Consensus nodes are jointly formed by representative nodes elected by each attribute committee. The verification nodes elected by each attribute committee through stake voting (i.e., nodes in the attribute chain verification node set) are directly used as the consensus nodes of the global verification chain. The verification nodes of each attribute committee participate in the consensus process of the global verification chain proportionally. No additional nodes need to be deployed, reducing the deployment and maintenance costs of the system. At the same time, it ensures that the consensus nodes have a full understanding of the transaction status of each attribute subdomain, improving the accuracy of cross-domain transaction verification.

[0034] Method 2: Composed of a global consensus node set independent of the attribute committees. Deploy dedicated global consensus nodes, this node set is independent of all attribute committees. Each node has ultra-high performance computing power and network-wide connectivity, achieving complete separation of consensus nodes between the attribute blockchain and the global verification chain. This avoids the impact of consensus node failures in attribute subdomains on the operation of the global verification chain, improving the stability and security of the global consensus.

[0035] Both methods can achieve the final consensus function of the global verification chain, ensuring that the global verification chain effectively verifies blockchain transactions of each attribute and synchronizes the global state.

[0036] Furthermore, based on the above embodiments, this embodiment also includes: a trusted center, used to generate system public parameters, register entities, and generate pseudonym identifiers for each entity, with entities interacting on each chain using pseudonym identifiers; a decentralized storage system, used to store encrypted data; and a proxy re-encryption module, integrated in the attribute committee, used to perform re-encryption operations on the data encryption key in response to data access requests.

[0037] Specifically, three additional modules are added to the multi-chain architecture based on layered DPoS: a trusted center, a decentralized storage system, and a proxy re-encryption module. Each module works in conjunction with the attribute blockchain and the global verification chain to achieve privacy protection, secure storage, and controllable key transfer authorization for IoT data.

[0038] The Trusted Center is the trusted root entity of the system, independent of all attribute blockchains and the global verification chain. Its core functions include three aspects: (1) generating system public parameters to provide unified public parameters for the operation, data encryption and signature verification of the entire multi-chain architecture based on layered DPoS; (2) entity registration to uniformly register all entities participating in data sharing within the system and record the basic information of the entities; (3) generating pseudonym identifiers to generate a unique pseudonym identifier for each registered entity. When the entity performs all interactive operations on each chain, it uses the pseudonym identifier instead of its real identity to realize anonymous interaction of the entity, avoid the leakage of the entity's privacy information by publicly recording on the chain, and solve the privacy leakage problem of IoT data sharing.

[0039] Decentralized storage systems serve as dedicated storage carriers for IoT data. For example, IPFS (InterPlanetary File System) stores encrypted data. Data owners upload their locally encrypted raw data to the system instead of storing it directly on the blockchain. Only the data hash and access control policies are uploaded to the blockchain, avoiding the linear increase in blockchain storage overhead with transactions and significantly reducing on-chain storage pressure. At the same time, decentralized storage avoids single points of failure and improves data storage security.

[0040] The proxy re-encryption module is directly integrated into each attribute committee and works in conjunction with the access request review function of the attribute committee. It is used to respond to data access requests and perform re-encryption operations on the data encryption key. Without the data owner disclosing the original private key, the data encryption key is re-encrypted into ciphertext that only the data accesser can decrypt, realizing controllable sub-authorization of the data key, reducing the risk of key leakage, and ensuring fine-grained control of data access.

[0041] The overall architecture of the blockchain is explained as follows: 1. Blockchain Design To ensure system scalability in large-scale IoT scenarios, the network is divided into K attribute chains and one global verification chain. Each attribute chain is governed by a corresponding attribute committee. The global verification chain manages and independently generates blocks, performing operations such as user registration, attribute verification, and hash-based notarization. After a fixed time window (epoch) ends, the global verification chain performs secondary verification and final confirmation on the blocks submitted by each attribute chain. This scheme uses DPoS for both intra-chain consensus and final consensus to reduce communication complexity and improve scalability.

[0042] (1) Blockchain nodes and network sharding Blockchain node network sharding mainly involves two steps. First, nodes in the network are assigned to different attribute committees according to attribute space partitioning rules. Each attribute chain maintains K attribute chains. Each attribute chain internally runs DPoS, selecting a set of block-producing representatives based on metrics such as stake, reputation, or historical block production performance. Each chain independently maintains its own transaction pool and ledger state. Then, from the block-producing representative set, verification representative nodes are selected based on a random verification function. These nodes, along with verification nodes from other attribute chains, form a verification chain responsible for periodically verifying the information submitted by each attribute chain and forming verification blocks. Since the representative nodes reside on two blockchains, no additional communication overhead is required when exchanging information.

[0043] To prevent collusion risks caused by long-term node solidification, this scheme adopts a periodic rotation mechanism. After a fixed epoch ends and the final confirmation of the verification chain is completed, the election process for the verification chain representative and the representatives of each attribute chain will be re-executed, thereby ensuring the dynamic randomness of node distribution and resistance to collusion.

[0044] (2) Layered DPoS In the proposed multi-attribute chain blockchain system, the consensus mechanism adopts a layered DPoS structure, consisting of two parts: the attribute chain layer consensus and the verification chain layer consensus. The attribute chain focuses on low-latency data recording, while the verification chain focuses on cross-chain consistency and finality confirmation.

[0045] ① Attribute chain consensus mechanism Each attribute chain As an independent blockchain, each runs its own DPoS consensus protocol. The DPoS consensus process of the Attribute Chain is as follows: Representative election phase: Nodes participating in the consensus within the attribute chain elect representatives through a stake voting mechanism. Each block represents a representative set that constitutes the attribute chain: The election results take effect after consensus is reached within the blockchain and are used in subsequent block production cycles.

[0046] Transaction collection and block proposal phase: In each block time slice, the rotating block producer collects transactions from the transaction pool of this attribute chain to construct a new block. It calculates the transaction Merkle Root and state digest, and signs the block header using its private key.

[0047] Block verification phase: Other nodes in the attribute chain verify the new block, including the legality of the block structure, the validity of the identity represented by the block, the correctness of the signature, the legality of the transaction, and the consistency of the smart contract execution results.

[0048] Block confirmation and on-chain phase: Once a new block meets the DPoS consensus rules, it is written to the attribute chain ledger. After the attribute chain consensus is completed, the block can be read and used immediately within the chain, but it still needs further confirmation by the verification chain.

[0049] ②Verification Chain Consensus Mechanism The verification chain, serving as the global verification and final confirmation layer, also employs the DPoS consensus mechanism. An epoch is defined by a fixed time window or a fixed number of blocks. At the end of each epoch, the verification chain performs unified verification and confirmation of the blocks generated by each attribute chain within that epoch. The process is as follows: Data Submission Phase: At the end of each epoch, each attribute chain submits the block digest generated during that period to the verification chain. The block digest includes the block hash, MerkleRoot, block representative signature, and necessary state proof information.

[0050] Proposal Verification Phase: The rotating verification representatives of the verification chain collect block digests from all attribute chains and perform secondary verification on them. Verification includes checking the legitimacy of the block-producing representative, the consistency between the block hash and the digest, and detecting forged signatures or obvious conflicts. Based on this verification, the verification representatives construct the verification block. This includes the verification results for each attribute chain block.

[0051] Validation Chain Consensus Phase: Validation blocks reach a consensus within the validation chain through the DPoS consensus mechanism and are written into the validation chain ledger.

[0052] ③Final confirmation and synchronization mechanism After the verification chain completes consensus on the verification block for a given epoch, the representative nodes of each attribute chain will view the verification results and update their own block status. If the verification block includes a block from a marked attribute chain... If the verification result is Accept, no processing is performed on the block. If the verification result is Reject, the attribute chain must perform rollback or isolation processing on the rejected block and its subsequent blocks according to the protocol rules, and take punitive measures such as canceling the representative qualification and confiscating the rights of the malicious block producer, so as to ensure the consistency and security of the system globally.

[0053] 2. Specific Structure 2.1 System Initialization TCA generation parameters and .in, It is a large prime number. cyclic group It is a group The generator. TCA randomly selects. As the system's private key, calculate and publish the public key. Then, TCA selected four one-way hash functions. , , and Finally, the parameters are made public. .

[0054] Blockchain networks include Each attribute committee consists of an attribute chain and a global verification chain. Based on the system scale and attribute space partitioning rules, TCA allocates each attribute committee node to a different attribute chain. Each attribute chain independently maintains its transaction pool and independently generates local blocks. Then, the attribute committee... Each node initializes its own attribute set. .exist In, each Select random number As a private key, calculate As the public key. In each attribute chain, a certain group of nodes are elected to join the global verification chain. The global verification nodes act as global coordinators and are responsible for verifying the blocks that have reached consensus in each attribute chain.

[0055] 2.2 Entity Registration Internet of Things (IoT) devices Send a registration request to TCA. First, generate a public and private key using the KeyGen algorithm. Specifically, Select random number Use the private key to calculate the public key. .Then, Send to TCA in the secure channel Request registration. (The following is a list of steps / parts:) yes The true identity. TCA selects a random number. ,calculate , and select As The katakana. Then, TCA is... Generate identity credentials and will Send to .

[0056] Internet of Things (IoT) devices Verify the equation Is it valid? If the verification passes, Can As their pseudonym. When IoT devices Desiring to visit the Attributes Committee At that time, first check the nearest attribute committee node. Generate session keys by running the Diffie-Hellman key exchange protocol. .

[0057] Equipment registration transactions are handled by The corresponding attribute link is received and passed through The method is written into the blockchain.

[0058] 2.3 Data Encryption and Transmission Assuming the data owner is The data requester is . Calculate the hash value of the data Regarding publicly available data, Store it directly in IPFS and obtain the data storage address (CID). For non-public data, Local data Using symmetric keys After encryption This is then stored in IPFS, which returns the data storage address (CID). For symmetric keys... , Execute the PRE.Enc algorithm to generate the initial ciphertext. Random selection ,calculate , , , , Obtain the key ciphertext .Then, Will Send to nearby .in, It is a data index, Refers to public or private data, yes Access control policies are set. use After decryption, call the AddData() method of the data sharing contract to... Uploaded to the blockchain network.

[0059] 2.4 Access Control Mechanism Data requester Will pass Submitted to the blockchain, specific data is queried and retrieved through the QueryData() method of the data sharing contract. yes The attributes of the blockchain. After receiving a data request, the blockchain first... Check if there is stored data. If matching data is found, the blockchain... Determine if the data requester has the necessary access permissions and check if the configured access policy is met. If the verification passes, the data requester is considered a legitimate user. The contract is based on... Find public key ,Will Stored on the blockchain, then the data storage address is returned. Give .at last, Transmit information Encrypted and sent to .

[0060] 2.5 Key Proxy Re-encryption The QueryList() method is used to query the list of devices with access permissions, resulting in a device set. and through Send to For equipment , Execute the PRE.ReKeyGen algorithm to calculate the re-encryption key. Then Send to .

[0061] Upon receiving the message, the re-encrypted ciphertext is calculated based on the PRE.ReEnc algorithm. , , , .at last, Will Submit to the blockchain using the AddInformation() method.

[0062] 2.6 Data Decryption Regarding publicly available data, Plaintext can be obtained directly from IPFS based on the CID. Then through Verify whether the data has been tampered with. For private data, Towards submit To request the decryption key. Call the QueryInformation() method, based on and Query The encrypted ciphertext is re-encrypted. If the user is unauthorized, the request for data access is denied. If the user is authorized, Will Return to .

[0063] from After obtaining the re-encrypted ciphertext, the PRE.Dec algorithm is executed to calculate... and Obtain the decrypted data, and then verify it. Does the equation hold true? If the equation holds true, It can be done Obtain plaintext .at last, verify To determine if the data hash is correct, it proves that the data has not been tampered with.

[0064] This invention proposes a hierarchical DPoS-based multi-chain architecture. By dividing the global attribute space into multiple mutually exclusive attribute subdomains, each maintained by a corresponding attribute committee, and using an independent attribute chain for data sharing, a global verification chain is introduced for final confirmation, thereby improving the system's scalability and cross-domain consistency.

[0065] This invention proposes a blockchain-based attribute-based multi-dimensional permission determination mechanism. Fine-grained access policies are defined on the attribute chain to achieve in-chain autonomy in identity management and access control, ensuring the legitimacy and consistency of cross-domain data sharing.

[0066] This invention proposes a data security sharing scheme that combines proxy re-encryption with IPFS. By utilizing proxy re-encryption to achieve controllable transfer of data keys, and combining it with IPFS decentralized storage and hash-based notarization, the risk of key leakage is significantly reduced while ensuring data shareability.

[0067] Figure 2 This is a flowchart illustrating the data access method provided by the present invention.

[0068] like Figure 2 As shown, this embodiment provides a data access method applied to a multi-chain architecture based on hierarchical DPoS as described in any of the above embodiments, which mainly includes the following steps: 201. The data owner encrypts the data locally, uploads the encrypted data to a decentralized storage system, and submits the data hash and access control policy to the attribute blockchain of the attribute subdomain.

[0069] Specifically, the data owner first encrypts the raw IoT data locally, generating a data encryption key using an encryption algorithm to ensure data security. The encrypted data is then uploaded to a decentralized storage system for secure storage. Simultaneously, the hash value of the encrypted data is calculated, and the hash, along with the access control policies set for the data, is submitted to the attribute blockchain of its respective attribute subdomain. Local encryption prevents leakage during data transmission, decentralized storage reduces on-chain storage pressure, and on-chain hashing ensures data integrity and immutability.

[0070] 202. The data accesser sends a data access request to the attribute committee of its attribute subdomain.

[0071] Specifically, data users send data access requests to the attribute committee of their respective attribute subdomain based on their data needs. These requests include key information such as their pseudonym, the hash value of the data to be accessed, and their own attribute information, which are then reviewed by the attribute committee. By initiating requests to the attribute committee of their subdomain, the architecture adheres to the principle of domain autonomy, reducing cross-domain review delays and improving request processing efficiency.

[0072] 203. After the attribute committee approves the data access request based on the access control policy, it re-encrypts the data encryption key through the proxy re-encryption and returns the re-encrypted key ciphertext to the data accesser.

[0073] Specifically, upon receiving an access request, the attribute committee performs multi-dimensional permission checks on the data accesser's attribute information and the request content based on the access control policies stored on the blockchain. Once the data access request is approved, it invokes its integrated proxy re-encryption module to perform proxy re-encryption on the data's encryption key, generating a re-encrypted key ciphertext, which is then returned to the data accesser. The access control policies enable fine-grained, multi-dimensional determination of data access, ensuring the accuracy of access authorization. Proxy re-encryption enables controllable key transfer authorization, preventing the leakage of the data owner's original private key and improving key security.

[0074] 204. Data access users use the original key they hold to decrypt the key ciphertext and retrieve encrypted data from the decentralized storage system.

[0075] Specifically, after receiving the ciphertext key returned by the attribute committee, the data access user decrypts the ciphertext using their own original key (attribute private key) to obtain a session key that can decrypt the ciphertext data. Then, using this session key, they retrieve the corresponding encrypted data from the decentralized storage system, completing the entire data access process. Because only authorized users can decrypt the ciphertext key and obtain the data, the uniqueness and security of data access are guaranteed, enabling trusted sharing of IoT data.

[0076] Furthermore, based on the above embodiments, in this embodiment, the attribute committee also acts as a proxy re-encryption node, responding to the re-encryption request of the data accessor and performing the re-encryption operation.

[0077] Specifically, the Attribute Committee also acts as a proxy re-encryption node. This means that the Attribute Committee not only undertakes its original responsibilities such as access request review and identity management, but also acts as a dedicated proxy re-encryption node, directly responding to data accessors' re-encryption requests and autonomously executing re-encryption operations without the need for additional independent re-encryption nodes. This reduces the number of nodes deployed in the system, lowers system maintenance costs, and simultaneously achieves integrated processing of access request review and re-encryption operations, reducing communication links between nodes and further improving data access processing efficiency.

[0078] Furthermore, based on the above embodiments, in this embodiment the data owner is an IoT device. The IoT device does not participate in blockchain consensus confirmation but is responsible for data encryption and integrity verification.

[0079] Specifically, the data owners are IoT devices, including IoT edge devices such as sensors, smart terminals, and industrial control equipment. These devices are the main producers of IoT data and are edge participants in the system.

[0080] Due to the limited computing resources of IoT devices, these devices do not participate in any consensus confirmation process of the blockchain, but only undertake two core responsibilities: (1) data encryption, which encrypts the original IoT data generated by itself locally to ensure the security of the data source; (2) data integrity verification, which verifies the integrity of encrypted data in the storage and transmission process through data hash verification and other methods to prevent data from being tampered with.

[0081] By adapting to the resource-constrained nature of IoT devices, the consensus process avoids consuming the device's limited computing power, ensuring normal data collection and production. At the same time, the core security responsibilities of the device are clearly defined to ensure the integrity and security of data from the source to storage.

[0082] Furthermore, based on the above embodiments, this embodiment also includes generating a hash aggregation traceability index for the access authorization events recorded on the attribute blockchain, compressing multiple access authorization evidences into a fixed-length digest; and verifying the consistency of data access records without obtaining the original data plaintext based on the comparison results of the fixed-length digest and the commitment value.

[0083] Specifically, all access authorization events recorded on the attribute blockchain are processed uniformly, and a hash aggregation traceability index is generated based on a hash aggregation algorithm. Each hash aggregation traceability index corresponds one-to-one with an access authorization event. Simultaneously, multiple access authorization evidences, including access requests, audit results, and authorization records, are compressed into fixed-length digests through hash aggregation. These fixed-length digests have a fixed length and do not change with the amount of evidence. The hash aggregation traceability index provides a unique traceability identifier for each access authorization event, enabling rapid event retrieval. The fixed-length digest significantly compresses the amount of evidence data, reducing data transmission and storage overhead during the audit process.

[0084] When auditing data access records, the auditor does not need to obtain the original plaintext data. Instead, they compare a fixed-length digest with a pre-stored commitment value in the system. Based on the comparison result, they can verify whether the data access records on the attribute blockchain are authentic, complete, and consistent. If they match, the access records are consistent and have not been tampered with; if they do not match, the access records have been tampered with or are missing. This achieves plaintext-free verification, avoiding the leakage of original data privacy during the audit process, while significantly reducing the communication and verification overhead of the audit and improving audit efficiency for massive amounts of access records.

[0085] Furthermore, based on the above embodiments, in this embodiment, the trusted center does not participate in the node key generation and access control process, but is used for entity registration and pseudonym generation.

[0086] Specifically, the Trusted Center does not participate in the node key generation and access control process, retaining only three core functions: entity registration, generating system public parameters, and generating pseudonyms for entities. Node keys, including public-private key pairs for verification nodes, consensus nodes, and entities, are generated autonomously by each node or entity. Access control is handled independently by each attribute committee, with no intervention from the Trusted Center. By clearly defining the principle of minimum trust in the Trusted Center, it avoids becoming a single point of failure, further enhancing the system's distributed characteristics and decentralization, while ensuring the Trusted Center only performs basic root-of-trust functions, thus improving overall system security.

[0087] Figure 3 This is a schematic diagram of the multi-chain architecture and data access interaction based on hierarchical DPoS provided in this embodiment.

[0088] like Figure 3As shown, the core of the multi-chain architecture based on layered DPoS consists of six modules: a trusted center, multiple attribute blockchains, a global verification chain, an IPFS decentralized storage system, data owners, and data accessers. These modules work together to complete the entire process from entity registration to data access and global verification.

[0089] Trusted Center (TCA): The system's only trusted root entity. It does not participate in blockchain consensus or access control. It is responsible for generating public parameters for the system, completing device registration for all entities, and generating unique pseudonym identifiers for each entity to enable anonymous interaction between entities. It is not responsible for generating public and private keys for nodes.

[0090] Multiple attribute blockchains ( ~ Each attribute subdomain corresponds one-to-one with a mutually exclusive subdomain and is maintained by a dedicated attribute committee for each subdomain. It records all data access control transactions within its subdomain, including data hashes, access policies, and access audit records. Consensus confirmation of transactions within the subdomain is achieved through the first layer of a layered DPoS consensus mechanism.

[0091] Global Verification Chain: A cross-domain core consensus chain that communicates and connects with all attribute blockchains. It is used to make final consensus confirmations on the confirmed transactions of each attribute blockchain through the second layer of layered DPoS consensus, synchronously update the state of each subdomain, and maintain the global state consistency across attribute subdomains.

[0092] IPFS decentralized storage system: a dedicated storage carrier for encrypted data, used to store the original IoT data encrypted locally by the data owner, avoiding excessive storage pressure on the blockchain, and at the same time, it is associated with the attribute blockchain through data hash to ensure the security and immutability of data storage.

[0093] Data owners: The main entities are IoT devices (sensors, smart terminals, etc.), who are the primary producers of IoT data. They do not participate in blockchain consensus but are responsible for encrypting the original data locally, uploading the encrypted data to IPFS, submitting the data hash and access control policies to the blockchain of their respective attributes, and completing data integrity verification.

[0094] Data accessers: These can be IoT devices, user terminals, or application services. They are the main users of data and are used to initiate data access requests to the attribute committee, receive and decrypt the re-encrypted key ciphertext, obtain encrypted data from IPFS, and initiate traceability queries of access records.

[0095] The attribute committee is the main body for maintaining the attribute blockchain. It consists of servers / edge computing nodes and is independently responsible for identity management, policy storage, and transaction recording within the subdomain. It also elects verification nodes to complete subdomain consensus and integrates a proxy re-encryption module to perform key re-encryption operations.

[0096] The interaction flow between the various modules is as follows: Identity registration: All IoT devices first complete registration at the Trust Center to obtain a unique pseudonym and system public parameters. Each node independently generates a public-private key pair to complete system initialization.

[0097] On-chain data storage: The data owner encrypts the original data locally, uploads the encrypted data to IPFS, and submits the data hash and access control policy to the relevant attribute blockchain. The attribute blockchain then completes consensus confirmation within the subdomain.

[0098] Initiating an access request: The data accesser sends a data access request to its / nearby attribute committee. The request includes its own pseudonym identifier, the hash of the data to be accessed, and its own attribute information.

[0099] Audit and Re-encryption: The attribute committee conducts multi-dimensional permission audits on visitors based on the on-chain access control policy. After the audit is passed, the integrated proxy re-encryption module is called to re-encrypt the data encryption key and return the re-encrypted key ciphertext to the visitor.

[0100] Global consensus verification: The attribute committee will synchronize the transaction record of this access authorization to the global verification chain. The global verification chain will complete the cross-domain final consensus confirmation and update the global state synchronously.

[0101] Decryption and Data Acquisition: Data access users use their own original key to decrypt the received key ciphertext, and then use the decrypted session key to retrieve the corresponding encrypted data from IPFS, thus completing data access.

[0102] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-chain architecture based on hierarchical DPoS, characterized in that, To support trusted data sharing in an IoT environment, including: Multiple attribute blockchains correspond to mutually exclusive attribute subdomains. Each attribute blockchain is maintained by a corresponding attribute committee to record data access control transactions within the attribute subdomain. Each attribute committee elects a verification node through the first layer of a hierarchical DPoS consensus mechanism. The verification node then confirms the transactions on the attribute blockchain. The global verification chain communicates and connects with blockchains of various attributes. It is used to perform final consensus confirmation on transactions on each attribute blockchain that have been confirmed by the first layer consensus through the second layer of the hierarchical DPoS consensus, and maintain the global state consistency across attribute subdomains.

2. The multi-chain architecture based on hierarchical DPoS according to claim 1, characterized in that, The attribute committee is composed of blockchain nodes with preset computing capabilities and stable network connections, including server nodes or edge computing nodes. Each attribute committee is independently responsible for identity management, access control policy storage, and data access transaction records within its corresponding attribute subdomain.

3. The multi-chain architecture based on hierarchical DPoS according to claim 2, characterized in that, The nodes of the attribute committee elect representative nodes through a voting process, and these representative nodes serve as verification nodes. The attribute chain verification node set, composed of the verification nodes, packages, verifies, and confirms transactions on the attribute blockchain.

4. The multi-chain architecture based on hierarchical DPoS according to claim 1, characterized in that, The consensus nodes of the global verification chain are composed of representative nodes elected by each attribute committee, or are composed of a set of global consensus nodes independent of the attribute committee.

5. The multi-chain architecture based on hierarchical DPoS according to claim 1, characterized in that, Also includes: The Trust Center is used to generate common system parameters, register entities, and generate pseudonyms for each entity, which interact on each chain using the pseudonyms. Decentralized storage systems are used to store encrypted data; The proxy re-encryption module, integrated into the attribute committee, is used to perform re-encryption of the data encryption key in response to data access requests.

6. A data access method, characterized in that, Applied to the hierarchical DPoS-based multi-chain architecture as described in any one of claims 1 to 5, the method includes: The data owner encrypts the data locally, uploads the encrypted data to a decentralized storage system, and submits the data hash and access control policy to the attribute blockchain of the attribute subdomain. The data accessor sends a data access request to the attribute committee of its attribute subdomain; After the attribute committee approves the data access request based on the access control policy, it re-encrypts the data encryption key through proxy re-encryption and returns the re-encrypted key ciphertext to the data accesser. The data access user uses the original key they hold to decrypt the key ciphertext and retrieves the encrypted data from the decentralized storage system.

7. The data access method according to claim 6, characterized in that, The attribute committee also acts as a proxy re-encryption node, responding to data accessors' re-encryption requests and performing re-encryption operations.

8. The data access method according to claim 6, characterized in that, The data owner is an IoT device, which does not participate in blockchain consensus confirmation but is responsible for data encryption and integrity verification.

9. The data access method according to claim 6, characterized in that, Also includes: Generate a hash aggregation traceability index for access authorization events recorded on the attribute blockchain, and compress multiple access authorization evidences into a fixed-length digest; Based on the comparison results between the fixed-length digest and the commitment value, the consistency of the data access records is verified without obtaining the original plaintext data.

10. The data access method according to claim 6, characterized in that, The trusted center does not participate in the node key generation and access control process; it is used for entity registration and pseudonym generation.

Images