Double-block-chain node layering and block optimization method for Internet of Things

Abstract

The invention discloses a double-block-chain node layering and block optimization method for the Internet of Things, and the method comprises the steps: constructing an index chain based on a Merkle tree, and associating the index chain with a transaction chain through a hash pointer; performing hierarchy division on the Internet of Things equipment to obtain three hierarchies of a full node, a sub-node and a light node; and performing double-chain block optimization on two types of hierarchical nodes, namely the sub-nodes and the light nodes, unloading irrelevant blocks in the transaction chain, and storing a hash path required for verifying the integrity of the transaction chain in an index chain to realize double-block-chain node layering and block optimization. According to the method, a double-chain structure is adopted, so that the storage overhead of the data is reduced, meanwhile, the sequence of the whole network block chains is maintained, the system safety is ensured, and the query verification efficiency is remarkably improved. Through double-chain block optimization, on the premise of ensuring data integrity and verifiability, the storage overhead is effectively reduced, and the problem of insufficient equipment performance under the scene of the Internet of Things is solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of the Internet of Things, and particularly relates to a method for double blockchain node stratification and block optimization for the Internet of Things. Background Art

[0002] With its characteristics of decentralization, immutability, traceability, openness and transparency, blockchain technology provides an effective solution for the security and trust issues in the field of the Internet of Things. Although the potential of blockchain technology in data management and protection has been widely recognized, it currently faces a major challenge of storage inflation caused by continuous data growth. With the expansion of the application scope, blockchain needs to store complex information including electronic health records, industrial data and video data, which poses a major challenge to the Internet of Things terminal devices limited by computing power, storage space and network bandwidth.

[0003] Therefore, there is an urgent need for an innovative storage optimization scheme to address the problem of device performance limitations faced in blockchain data storage and query verification in Internet of Things applications. Summary of the Invention

[0004] To solve the above technical problems, the present invention proposes a method for double blockchain node stratification and block optimization for the Internet of Things to solve the problems existing in the above prior art.

[0005] To achieve the above object, the present invention provides a method for double blockchain node stratification and block optimization for the Internet of Things, including:

[0006] Constructing an index chain based on a Merkle tree and associating the index chain with a transaction chain through a hash pointer;

[0007] Dividing Internet of Things devices into levels to obtain three levels: full nodes, sub-nodes and light nodes;

[0008] Performing double-chain block optimization on the two types of hierarchical nodes, namely the sub-nodes and the light nodes, unloading irrelevant blocks in the transaction chain and storing the hash paths required to verify the integrity of the transaction chain in the index chain, so as to achieve double blockchain node stratification and block optimization.

[0009] Optionally, the process of constructing an index chain based on a Merkle tree includes: when the number of the latest blocks in the transaction chain accumulates to a preset threshold, merging the block headers of the latest blocks into an index block, and obtaining an index chain based on a plurality of merged index blocks; wherein the genesis block in the transaction chain does not perform block header merging.

[0010] Optionally, the index block includes the Merkle root hash path of the block header, pointers to the leftmost transaction chain block and the rightmost transaction chain block before the block header is merged with the previous index block.

[0011] Optionally, the IoT devices are hierarchically divided according to their computing and storage capabilities;

[0012] The full nodes store the complete transaction chain and index chain and participate in the consensus process of the blockchain;

[0013] The sub-nodes store the complete index chain and partial transaction chain data and participate in the consensus process of the blockchain;

[0014] The light nodes store key index chain information and are responsible for submitting transactions to the full nodes and sub-nodes.

[0015] Optionally, the process of obtaining the index chain further includes: adding the merged index block to the end of the index chain. If the merged index block is the first generated index block, the genesis block of the transaction chain is used as the latest index block; and generating a set of hash value sets to update the index chain; wherein, the hash value combination includes the hash result of the previous index block and the leftmost block hash value and the rightmost block hash value of the newly merged block.

[0016] Optionally, the two hierarchical nodes, namely the sub-nodes and the light nodes, divide the transaction chain blocks into potential blocks and useless blocks respectively based on their own resource conditions and requirements; wherein, the interaction frequency is used as the division basis.

[0017] Optionally, the double-chain block optimization includes unloading irrelevant blocks and merging the light node index blocks.

[0018] Optionally, the process of unloading the irrelevant blocks in the transaction chain and storing the hash path required to verify the integrity of the transaction chain in the index chain includes:

[0019] If the number of potential blocks in a single index block is zero, the root hash path is not stored; if the number of potential blocks is one, the opposite subtree path is stored; if the number of potential blocks on the transaction chain exceeds half of the preset threshold, the hash result of the useless block is stored.

[0020] Optionally, the process of re-merging the light node index blocks includes: if the heights of two adjacent index blocks are the same, the block header Merkle trees of the corresponding index blocks are merged as the left and right subtrees to obtain a new index block; obtaining the hash path set of the new index block according to the hash path sets stored in the two index blocks, and updating the hash value set and the sequence number of the new index block.

[0021] Compared with the prior art, the present invention has the following advantages and technical effects:

[0022] The present invention proposes a modified design based on the Merkle tree, which uses a set of block header information to generate a tree instead of individual transactions. It integrates multiple block headers in the transaction chain into a single index block, optimizes the data organization structure by constructing an index chain, and the synergistic effect of the index chain and the transaction chain ensures the sequentiality and immutability of blockchain data, enhances system security, significantly reduces the storage burden of nodes, and improves data verification efficiency.

[0023] The present invention classifies IoT nodes into three levels according to their computing and storage capabilities, namely full nodes, sub-nodes, and light nodes. This hierarchical classification can effectively allocate system resources.

[0024] In the double-chain block optimization process of the present invention, each hierarchical node can selectively retain or unload system transaction chain blocks according to requirements. Under specific conditions, nodes can also merge index chain blocks to adapt to different application scenarios. The model adopts a double-chain structure, namely a transaction chain and an index chain, which not only reduces the storage overhead of data, but also maintains the sequentiality of the entire network blockchain, ensures system security, and significantly improves the efficiency of query verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings constituting a part of this application are used to provide a further understanding of this application. The schematic embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation of this application. In the drawings:

[0026] Figure 1 is a schematic diagram of the double-chain structure of an embodiment of the present invention;

[0027] Figure 2 is a schematic diagram of the node hierarchical architecture of an embodiment of the present invention;

[0028] Figure 3 is a sequential flowchart of DBOM of an embodiment of the present invention;

[0029] Figure 4 is a schematic diagram of index block re-merging of an embodiment of the present invention;

[0030] Figure 5 is a comparison chart of storage overhead with x = 4 of an embodiment of the present invention;

[0031] Figure 6 is a comparison chart of storage overhead with x = 8 of an embodiment of the present invention;

[0032] Figure 7 is a comparison chart of query verification with x = 4 of an embodiment of the present invention;

[0033] Figure 8 is a comparison chart of query verification with x = 8 of an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0034] It should be noted that, without conflict, the embodiments in this application and the features in the embodiments may be combined with each other. The following will describe this application in detail with reference to the accompanying drawings and in combination with the embodiments.

[0035] It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0036] Embodiment 1

[0037] As Figure 1-8 shown, this embodiment provides a method for double blockchain node layering and block optimization for the Internet of Things, including:

[0038] (1) IoT double-chain layering model

[0039] (1) Merkle tree

[0040] The version number in the block header is an identifier of the Bitcoin protocol, which can identify and process blocks of different versions; the previous block hash connects the current block with the previous block in the chain, forming an immutable chain structure; the Merkle root, as the root node of the transaction hashes, can verify the integrity of all transactions in the block and ensure the credibility of the data. The timestamp records the creation time of the block, while the difficulty target indicates the difficulty level of the block's proof of work, and this mechanism is crucial for ensuring the security and stability of the blockchain. The nonce is used for the calculation of the proof of work. By continuously adjusting the nonce value, the node can find the correct hash value that meets the difficulty target, thus completing the creation of the block. The block header not only supports the functions of quick verification and indexing, but also serves as the glue of the entire blockchain, firmly connecting each block together and ensuring the stable operation of the entire network and the integrity of the data.

[0041] The Merkle root in the block header is derived from the hash calculation of the transaction data within the block body, and these transaction data form the leaf nodes of the Merkle tree. The Merkle tree calculates the hash values of each node and its children recursively until the final root hash is obtained. Its structural feature is that even if the data of a single leaf node changes, it will affect the hash values of all upper-level ancestor nodes, thus enabling the rapid detection of data changes and the effective verification of data integrity. For example, in a compressed transaction, if there is only one transaction a left, its integrity can still be verified through the use of the Merkle path. In the Bitcoin blockchain, by checking whether the calculated Merkle root matches the Merkle root recorded in the block header, it is possible to effectively confirm whether the transactions within the block are complete and have not been tampered with, significantly enhancing the security and scalability of the blockchain.

[0042] In this embodiment, a Block Head Merkle Tree (BHMT) is constructed to improve the maintenance efficiency and scalability of the blockchain and meet the requirements of the Internet of Things for efficient blockchain technology. A specific number n c The block headers are merged as leaf nodes into a new type of Merkle tree. As the transaction chain blocks continue to accumulate, whenever the number of blocks accumulates to an integer multiple of n c (n c = 2 n , n = 1, 2, 3,...), the system will merge the latest n c block headers to generate the BHMT. As a key component of the index chain block, it not only compresses the key block header information but also ensures the ability to effectively verify the integrity of the transaction chain even after the transaction chain blocks are missing, thereby enhancing the scalability and operational flexibility of the system.

[0043] (2) Double-chain structure

[0044] In the field of blockchain technology, although traditional linear blockchains perform well in maintaining network consistency and security, their limitations in efficiency and retrieval speed gradually become apparent when dealing with the large-scale data streams of the IoT. IoT devices generate data frequently and in large quantities, and traditional blockchain models are difficult to quickly respond to this data processing requirement. To solve this problem, this embodiment proposes a new type of double-chain blockchain structure, which optimizes data management and improves data retrieval efficiency by introducing an auxiliary index chain, and is particularly suitable for the IoT environment with high-frequency data streams and real-time processing requirements.

[0045] The double-chain structure is as Figure 1 shown. In the figure, the transaction chain cumulative blocks satisfy the system-set n cWhen it is equal to 4, the block headers are merged to generate a new index block, and the length of the index chain increases correspondingly as the number of accumulated blocks in the transaction chain increases. The transaction chain is responsible for recording standard transaction and event data, maintaining the basic operation of the system and data integrity. The newly designed index chain uses BHMT to perform periodic index integration on the block headers of the transaction chain. Whenever the number of unintegrated blocks in the transaction chain increases to the preset threshold n c , the system automatically starts a block integration process to form an index chain block containing detailed information. It should be noted that the genesis block does not participate in the block header merger. The index block includes the BHMT and the Block Head Merkle Path (bhmp) merged from n c block headers, as well as pointers to its previous index block and the leftmost and rightmost transaction chain blocks integrated, which can significantly improve the ability to quickly access and verify any transaction chain block. The application of the index chain not only speeds up data retrieval but also improves the overall security of the system through centralized verification. In the Internet of Things environment, the double-chain blocks continue to accumulate, which may reach the storage limit of the node, resulting in storage crashes and affecting the system operation.

[0046] DBOM can effectively manage the node storage space and prevent storage overflow through the unloading of transaction chain blocks and the re-merging operation of index chain blocks. The node divides the transaction chain blocks into potential blocks and useless blocks according to demand. Those with frequent interactions are classified as potential blocks, and irrelevant data is defined as useless blocks. Through the BHMT block root hash path of the index chain, not only can the data integrity of potential blocks be verified, but useless blocks can also be safely removed.

[0047] In addition, the light node re-merges the index chain blocks directionally to generate new index chain blocks, which significantly reduces the problem of excessive block accumulation and ensures the continuous and stable function of the index chain. During the process of index block re-merging, the system not only maintains the original structural characteristics but also flexibly adjusts the block index range of the transaction chain and updates the block root hash path information in real time by increasing the height of the tree and updating the hash value of the tree root to ensure the strict verification of the integrity of the transaction chain. The verification of the integrity of the chain. The specific method implementation can be detailedly referred to the content described in (2) DBOM.

[0048] (3) Resource stratification

[0049] In the system architecture of this embodiment, the nodes are designed into three levels: full nodes, sub-nodes, and light nodes to adapt to the resource heterogeneity of devices. The node architectures of each level are as Figure 2As shown. A full node can be a device equipped with advanced computing resources and large-capacity storage, such as a supercomputer and a high-performance server, which is mainly responsible for storing a complete double-chain ledger, including a transaction chain and an index chain. The full node is the center of the network, fully participating in the consensus process to ensure the integrity and security of the network. A sub-node is suitable for devices with relatively limited resources but stable performance, such as mobile phones and tablets. Although its computing and storage capabilities are limited, it still maintains complete access to the entire index chain and stores part of the transaction chain data, and can fully participate in the system consensus to maintain the robustness of the network.

[0050] A light node is mainly applied to resource-constrained devices, such as sensors and smart home systems, which only store key double-chain ledger information and support basic transaction verification and data query functions. Limited by its various capabilities, a light node cannot participate in the system consensus process and can only rely on connecting to a full node or a sub-node to submit transaction requests. By adopting a hierarchical node design, the system can efficiently allocate and manage blockchain data, thereby improving the network operation efficiency and optimizing resource utilization. The hierarchical architecture optimizes the data processing flow, provides a reliable foundation for the deployment of Internet of Things devices in the blockchain network, and demonstrates the key role and broad potential of blockchain technology in the field of the Internet of Things.

[0051] (2) DBOM

[0052] (1) Overall process

[0053] The goal of DBOM is to reduce the storage overhead of the blockchain and only retain the storage content required by each level of nodes. DBOM includes four steps: header merging, chain update, block unloading, and re-merging. Different from other steps, re-merging is an additional process only executed when the light node index blocks are sufficiently accumulated to meet the re-merging requirements. Figure 3 Shows the sequential flow chart of DBOM. During the merging process, the newly accumulated n c transaction block headers are compressed into a new index block. The sub-node and the light node respectively verify potential independent blocks and unload useless blocks to reduce the storage burden of the system. Finally, when the index blocks accumulate to a certain extent, the light node executes the re-merging process to combine old blocks, thereby reducing the accumulation of index blocks. In the whole process, the transaction chain and the index chain are described in detail. The set of transaction chain blocks B = {B 1 , B 2 , B 3 , …, Bn} contains the blocks B i on the chain, where i is the block number, excluding the latest block waiting for confirmation, and the genesis block B 0 does not participate in the block header merging and is not in the set; the set of index chain blocks C = {C 1 , C 2 , C 3 , …, Cm , including the on-chain block C m , where m is the block number, m * n c ≤n, the new set generated by the light node executing the index block recombination operation Iterated from the set C by recombination, it compresses the accumulated index block set into a smaller index block set, m * ≤m.

[0054] idx m = [L m , R m = [n - n c + 1, n] (1)

[0055]

[0056] The head recombination is shown in equations (1)-(2): n c transaction block headers are combined into a new index block, L m and R m are the leftmost and rightmost block numbers in the index block BHMT respectively. h is the Merkle root hash result of the corresponding transaction block, root m is the set of hash paths of n c transaction blocks, storing the hashes of the Merkle tree roots of all block headers. By inputting the block headers into the BHMT function, the relevant hash paths are returned. idx m is the block number range corresponding to n c transaction blocks, used to quickly determine the corresponding recombination block range.

[0057] C m = {hashes m , idx m , root m} (3)

[0058]

[0059] The chain update is shown in equations (3)-(4): The newly recombined C m will be appended to the back end of the latest index C m-1 . If this index block is generated for the first time in the index chain, the transaction chain genesis block is regarded as the latest index block, that is, B 0 = C 0 . hashes m is a set of hash values, including the hash value H(C m-1 ) of the previous index block and the hashes of the leftmost and rightmost blocks of n c recombined blocks and Used to determine the merged block range and verify the block integrity.

[0060] (2) Block unloading

[0061] When a new index block is appended to the index chain, the chain update operation is completed. Full nodes with rich capabilities regularly merge the block headers of the transaction chain, update the index chain, and maintain the integrity of the double-chain ledger without dividing the blocks in the transaction chain into potential blocks and useless blocks. However, in contrast, sub-nodes and light nodes have limited resources and cannot guarantee the complete storage of the block ledgers of the double-chain. When adding a new index block, the merged blocks in the previous index block are divided into potential blocks and useless blocks. Subsequently, the set B of useless blocks u will be removed from the set B of transaction chain blocks, that is B * = B - B u . During the block unloading process, the node retains r potential blocks of the transaction chain according to its own needs, combines the BHMT and the root hash path to verify the integrity of the chain after block unloading, and at the same time, the block headers retained in the index chain can replace the unloaded useless blocks to ensure the realization of the consensus algorithm for resource-constrained nodes and full nodes.

[0062] The process of transaction block unloading is as follows:

[0063]

[0064] The resource-constrained node retains the potential block r according to its own needs, stores the relevant root hash paths respectively, and combines the potential blocks to calculate the root hash value of BHMT. Compare it with the root hash value stored in the index chain block to verify the integrity of the n c blocks in the transaction chain. Therefore, the r potential blocks distributed on m index blocks are expressed as follows:

[0065]

[0066] In formula (5), 0 ≤ r i ≤ n c , r i is the number of potential blocks existing in the index block C i However, the block root hash paths that the node needs to store are determined by r iDetermined by the quantity. Suppose that r blocks are concentrated and distributed on the transaction chain, that is, when most data blocks are concentrated in the BHMT of a few index blocks, the number of block root hash paths will decrease because the number of bits required to represent these data blocks in the path decreases. In addition, if the data blocks are concentrated on the left or right side of the BHMT of a certain index block, the required stored hash path will be greatly reduced, and the integrity of the block can be repeatedly verified by recording the hash value of the opposite subtree root. Therefore, different distribution situations of potential blocks on the transaction chain will directly affect the size of the block root hash path. When the potential block r is evenly distributed on the transaction chain, the overhead of the required stored root hash path is the largest.

[0067] Represents index block C i Next n c = 2 x The number of block root hash paths of potential block r in i the n merged blocks, and its value is the sum of the potential blocks evenly distributed within the index block. If an index block C i inside, C i = 0, then that is, there is no need to store the root hash path. In addition, if only one potential block is retained under the index block, then the required stored Since the left or right subtree hash path is fixed, only the opposite subtree path needs to be recorded to verify the potential block. Finally, if there are multiple potential blocks on the transaction chain, it will cause the values of the required block root hash paths to overlap. At this time, the method of storing the hash values of useless blocks instead of hash paths can effectively improve the path processing efficiency. In formula (6) If the number of potential blocks retained in the transaction chain exceeds then storing the hash results of sibling blocks (useless blocks) is more efficient in terms of storage capacity. Multiple block root hash paths can reuse the hash value without including the sum of individual paths. The expression is as follows:

[0068]

[0069] (3) Re-merge

[0070] Sub-nodes and light nodes play different key roles in the system. Sub-nodes have a stable network environment and relatively sufficient storage capacity, can interact with full nodes and participate in system consensus; light nodes are mostly resource-constrained Internet of Things terminal devices, do not directly participate in system consensus, and are only responsible for submitting transactions to full nodes and sub-nodes. To optimize the storage of light nodes, re-merge is a unique storage optimization operation that can further improve storage efficiency and the overall performance of the system.

[0071] Index block re - merge operation for lightweight nodes, that is, the merge of BHMT within the block. The new merged tree takes the BHMTs in two index blocks as the left and right sub - trees, and requires the same height of the left and right sub - trees to complete the merge. Therefore, two adjacent index blocks C are required when executing the index chain re - merge process m and C m-1 to have the same height. The heights of adjacent index blocks are obtained through idx m and idx m-1 .

[0072] After re - merge, the new index block will replace the original index block as Figure 4 shown. According to the root m-1 and root m stored in the two merged index blocks, a new is calculated and the hashes and idx in the new index block are updated. The implementation process of the index chain update method is as follows:

[0073] The lightweight node index chain update process is as follows:

[0074]

[0075]

[0076] The lightweight node index block re - merge process is as follows:

[0077]

[0078] The goal of re - merge is to reduce the number of index blocks. The system continuously repeats the re - merge process until BHMTs with different heights are generated. When a new index block is appended to the chain, the system immediately starts a new round of re - merge. In addition, since BHMTs are continuously merged during the re - merge process, the BHMTs that were re - merged earlier will have a higher height. Therefore, a node can decide the generation of subsequent re - merge based on whether it can generate a BHMT with a specific height.

[0079]

[0080] In the above formula, b j is a binary variable used to indicate whether an optimized re - merge index chain can be constructed based on m index blocks. f represents the maximum possible height of the BHMT that can be constructed from these m index blocks. When there is an index block with a height of j - 1, the corresponding b j is set to 1. This series of b j values must satisfy the equation where the value of b j is 0 or 1. In fact, this set of b j is related to n cis the same as the reverse order of the binary number.

[0081]

[0082] is the number of potential blocks under the re - merged index block, where and

[0083] [L j ,R j This symbol represents which original index blocks the re - merged index block is composed of, and the range of transaction chain blocks corresponding to these index blocks. When the re - merged index block satisfies b j = 1, the number of transaction block headers contained in the block is n c ×2 j-1 , The range is Based on formula (6), we can obtain the expression, and and y = x + j - 1

[0084]

[0085] Detailed explanation of re - merging with a simple example. Suppose there are 160 blocks on the transaction chain, and a new index block is generated every 8 transaction blocks. Therefore, there are 20 index blocks in the index chain without re - merging. Through the re - merging process, the original index blocks are merged into two re - merged index blocks. The specific merging method is binary calculation 20 = 0×2 0 +0×2 1 +1×2 2 +0×2 3 +1×2 4 = 10100 (2) , where f = 5. This indicates that the two re - merged index blocks are composed of 4 (b 3 = 1) and 16 (b 5 = 1) initial index blocks respectively. Assuming the number of existing potential blocks is 60, considering the worst - case distribution condition, that is, the potential blocks are evenly distributed in 20 index blocks, calculate That is, there are two potential blocks in each index block, and we can obtain and To verify the integrity of 60 potential blocks, we need to perform calculations and store the results. The total of the two index blocks bhmp is 80.

[0086] By merging multiple index blocks, the storage efficiency and verification ability of the lightweight node double chain are significantly improved. DBOM enables the system to reduce data accumulation, relieve storage pressure and optimize performance, ensuring that nodes at all levels can operate efficiently even in an environment with limited resources.

[0087] Experimental simulation analysis

[0088] (1) Environment and parameter settings

[0089] To verify the feasibility and effectiveness of the double-chain hierarchical model proposed in this paper, a simulation experiment was designed and written using the Python language. The experimental environment was configured as a computer with 16GB of memory and a 2.50GHz processor, running the Windows 11 operating system, and the program code was written with the help of the PyCharm platform. For the detailed environment configuration, see Table 1.

[0090] Table 1

[0091]

[0092] The comparison schemes include: Mapchain (a dual-blockchain architecture that combines the anti-tampering property of blockchain and the efficient storage of DHT); LNPB (a public blockchain with a constant-size storage); Hash-slot (a method that maps each data to a slot, and the slot is stored in a specific node); DBOM * (A sub-node that only performs transaction chain block unloading). The above block optimization schemes improve the blockchain in various ways, and their common goal is to achieve the efficient application of lightweight blockchains while ensuring the overall security and stability of the blockchain system. The simulation experiment adopts a clustering comparison thinking, and different block optimization schemes are used in each cluster to fully compare the overall performance of each scheme. For example, by setting the number of nodes at different levels within the cluster, the experimental simulation analysis mainly evaluates the performance of each scheme from two aspects: storage overhead and query verification. In blockchain technology, for example, query schemes based on Merkle trees have been proposed to improve query performance and reduce query overhead.

[0093] For storage overhead, for the same cluster, under the same total number of blocks in the transaction chain, compare the overall storage overhead of the cluster; for query verification, within each cluster, when lightweight nodes are under the same storage threshold, compare the proportion of query verification of each scheme. To simulate a real blockchain system, some parameters are centrally defined. The specific parameter settings in the simulation experiment are shown in Table 2.

[0094] Table 2

[0095]

[0096] (2) Result analysis

[0097] (a) Storage overhead

[0098] Storage overhead refers to the cost or expense incurred in a blockchain system for storing data or performing related operations. We calculate and compare the storage overhead of each storage optimization scheme based on the amount of data to be stored, so as to conduct an intuitive numerical analysis.

[0099] DBOM needs to store potential blocks, index blocks, and block root hash paths. The storage overhead V DBOM is expressed as follows:

[0100]

[0101] In Equation (10), they respectively represent the storage overhead of the sum of the index chain and the transaction chain, where 3m * represents the hash pointer values of three respectively pointing to the previous index block and the transaction block within the index block. Since the genesis block is not within the comparison scope, it is not considered.

[0102] Compared with DBOM, the DBOM that only performs transaction chain block unloading * , without performing index block re-merging, has a completely different block root hash path from that stored in DBOM. The storage overhead V DBOM* has the following expression:

[0103]

[0104] In the comparison scheme Mapchain, the data chain is maintained by a DHT network composed of base stations, which is responsible for storing the data collected by IoT nodes. Each base station is only responsible for storing some data blocks, and the storage location is determined by the DHT key, so as to make full use of the large storage and computing capabilities of the base stations and improve the overall efficiency. The index chain, as a lightweight blockchain, mainly stores the description and reference information of data, and these information are distributed among the base stations and consumers. Since it does not contain sensitive information, it can be transmitted securely. At the same time, it also supports users to perform local retrieval and preliminary search, and further improves the efficiency and distribution of the system by dispersing the computing tasks to edge devices. The storage overhead V Mapchain has the following expression:

[0105]

[0106] In the comparison scheme LNPB, two new parameters, the latest block digest (S n ) and the RSA modulus (N), are introduced, and a constant-size transaction verification is realized by using the RSA cryptographic accumulator.

[0107]

[0108] In Equation (12), S i is the digest of the i-th block, blkri is the MHT root of the i-th block. If the blockchain contains n blocks, the digest of the latest block is S n .

[0109]

[0110] In the verification of this scheme, each block requires proof from other nodes. In Equation (13), is used to prove that a transaction is on a given block i, is used to prove that block i is on the blockchain. The new attribute N = pq is embedded in each block header, where p and q are two large random prime numbers and are not easily determined, thus ensuring the security of its RSA-based scheme. In summary, the storage overhead V LNPB has the following expression:

[0111] V LNPB = S n + n(S + p (2) ) (15)

[0112] The hash slot allocation algorithm accurately allocates the data to be stored to specific slots according to preset rules. Subsequently, each slot follows the established mapping strategy to bind to a single node in the system. The routing table of each node details the corresponding information between the slots and the nodes, facilitating quickly locking the target node during data access or query.

[0113]

[0114] In Equation (16), the capacity available for block storage at node j is denoted as C j , the total number of hash slots is denoted as N slots , and the total number of nodes is denoted as n nodes. Then the number of slots allocated to each node j is SN(j). The system retains the block header for query verification, and the storage overhead V Hash-slot is as follows:

[0115] V Hash-slot = (S + 2 × S hash ) × SN(J) + n × S head (17)

[0116] Figure 5 And Figure 6Shows the comparison of storage overheads for different storage schemes. Among these schemes, the cluster configuration assumes that the total number of full nodes is 2, while the number of lightweight nodes in Mapchain, LNPB, Hash-slot, and DBOM* is set to 8, and DBOM adopts a configuration with 6 sub-nodes and 2 lightweight nodes. This configuration choice reflects that in a Kubernetes (K8S) environment, an increase in the number of nodes can improve the redundancy and computing power of the system, but at the same time, it may also bring challenges such as increased management complexity and cost. The horizontal axis is the total number of blocks in the transaction chain, and the vertical axis is the storage overhead of each scheme. The comparison process includes different preset merged blocks, namely x = 4 and x = 8. Additionally, to enhance the authenticity of the simulation experiment, DBOM and DBOM* are respectively configured with different ratios of potential blocks, 0.1n and 0.25n. These ratios represent the maximum potential block ratios of lightweight nodes and sub-nodes in the hierarchical structure. At the same time, we assume that each potential block is evenly distributed on the data chain to calculate the peak storage overhead under the same total number of blocks. In this experiment, the total number of blocks is incremented from 0 by 400 blocks each time until 2000 blocks. As Figure 5 and Figure 6 shown, as the total number of blocks increases, the storage overhead of each optimized scheme also increases continuously. Compared with the optimized schemes Mapchain, LNPB, and Hash-slot, in the Figure 5 case shown (when x = 4), DBOM reduces the storage overhead by 85.13%, 84.26%, and 66.81% on average respectively; while in the Figure 6 case shown (when x = 8), DBOM reduces the storage overhead by 86.27%, 84.93%, and 67.82% on average respectively. However, compared with DBOM, DBOM* reduces by 58.55% on average when x = 4 and 59.06% on average when x = 8.

[0117] In summary, DBOM is effective in terms of storage overhead. The data shows that lower storage overhead can be obtained under the same total number of blocks, and it increases slightly as the total number of blocks increases. It is worth noting that observing the preset block merge numbers x = 4 and x = 8, there is not much difference in the storage overhead between DBOM and DBOM * . Thus, it can be seen that the block merge number has little impact on the storage overhead of this model.

[0118] (b) Query verification

[0119] The query verification ability refers to the ability of users to query blockchain data through nodes while ensuring that this data is complete and accurate. Under the condition of the same storage threshold of nodes, the data query verification abilities of each optimized scheme for the blockchain are compared. The comparison process is as Figure 7 and Figure 8As shown, the horizontal axis represents the storage threshold of the nodes, and the vertical axis shows the ratio of the actual block capacity that the optimized nodes can maintain to the storage threshold, which is defined as the data verification ability of the nodes. For example, the storage threshold of node A is 100M. After optimization, the maximum block capacity that node A can maintain is 80M. Therefore, the verification ability of node A is defined as the ratio of 80M to 100M, that is, 0.8. This means that node A can effectively process and verify 80% of the block capacity within its maximum storage threshold compared to its maximum allowable storage capacity. Nodes with stronger verification ability can manage more blocks. Although traditional linear blockchains can verify a series of blocks, it is difficult to extract any arbitrary block. In contrast, the existing and the proposed solutions in this paper can selectively maintain and verify blocks, thus improving the efficiency and flexibility of the system.

[0120] In the initial experiment settings, the total number of blockchain blocks n was set to 2000. As the storage threshold continued to increase, the query verification ability of each optimization solution also increased. Compared with the optimization solutions Mapchain, LNPB, and Hash-slot, in Figure 7 the shown case (when x = 4), DBOM improved the average performance of query verification by 23.3%, 33.86%, and 27.6% respectively. In Figure 8 the shown case (when x = 8), DBOM increased the average performance of query verification by 28.5%, 37.81%, and 31.35% respectively. The results show that after using the index chain, DBOM does not need to rely on other nodes to frequently submit its own verification, and the number of index blocks can be significantly reduced after the index blocks are merged again, ultimately achieving a stronger blockchain verification ability. Comparing different block merge numbers, when x increases from 4 to 8, the query verification ability of DBOM and DBOM * shows an obvious upward trend, increasing by 5.83% and 4.89% respectively. It can be seen that increasing the block merge number can also significantly improve the node query verification ability.

[0121] Based on the comprehensive analysis of the experimental results and combined with the hierarchical architecture proposed in this paper, considering that lightweight nodes have limited resources, low storage thresholds, and limited query verification ability in practical applications, DBOM is mainly applicable to low-end IoT devices such as lightweight nodes. At the same time, DBOM* not only effectively reduces the storage overhead of the nodes but also maintains excellent query verification ability, thus ensuring the stable operation of sub-node devices in blockchain applications. In addition, considering the differences in the data types processed by different devices, setting an appropriate preset number of blocks n c in the system can further improve the overall performance of the system.

[0122] The above are only the preferred specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present application should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A dual blockchain node layering and block optimization method for the Internet of Things, characterized in that: The following steps are involved: Build an index chain based on the Merkle tree and associate the index chain with the transaction chain through a hash pointer; The IoT devices are divided into three levels: full nodes, sub-nodes and light nodes; The dual-chain block optimization is performed on the two hierarchical nodes, the sub-node and the light node, to unload irrelevant blocks in the transaction chain and store the hash path required to verify the integrity of the transaction chain in the index chain, thereby realizing dual blockchain node stratification and block optimization.

2. The dual blockchain node layering and block optimization method for the Internet of Things according to claim 1 is characterized in that: The process of building an index chain based on the Merkle tree includes: when the number of the latest blocks in the transaction chain accumulates to a preset threshold, the block headers of the latest group of blocks are merged into an index block, and an index chain is obtained based on the merged index blocks; the genesis block in the transaction chain does not undergo block header merging.

3. The dual blockchain node layering and block optimization method for the Internet of Things according to claim 2 is characterized in that: The index block includes the Merkle tree root hash path of the block header, and pointers to the leftmost transaction chain block and the rightmost transaction chain block before the previous index block is merged with the block header.

4. The dual blockchain node layering and block optimization method for the Internet of Things according to claim 1 is characterized in that: Divide IoT devices into different levels according to computing and storage capabilities; The full node saves the complete transaction chain and index chain and participates in the consensus process of the blockchain; The sub-node stores the complete index chain and part of the transaction chain data, and participates in the consensus process of the blockchain; The light node stores key index chain information and is responsible for submitting transactions to full nodes and sub-nodes.

5. The dual blockchain node layering and block optimization method for the Internet of Things according to claim 2 is characterized in that: The process of obtaining the index chain also includes: adding the merged index block to the end of the index chain, and if the merged index block is the first generated index block, taking the genesis block of the transaction chain as the latest index block; and generating a set of hash value sets to update the index chain; wherein the hash value combination includes the hash result of the previous index block and the leftmost block hash value and the rightmost block hash value of the newly merged block.

6. The dual blockchain node layering and block optimization method for the Internet of Things according to claim 5 is characterized in that: The sub-nodes and light nodes are two types of hierarchical nodes that divide the transaction chain blocks into potential blocks and useless blocks based on their own resource conditions and needs; wherein the blocks are divided based on the interaction frequency.

7. The dual blockchain node layering and block optimization method for the Internet of Things according to claim 6 is characterized in that: The dual-chain block optimization includes unloading irrelevant blocks and remerging them with light node index blocks.

8. The dual blockchain node layering and block optimization method for the Internet of Things according to claim 7 is characterized in that: The process of unloading irrelevant blocks from the transaction chain and storing the hash path required to verify the integrity of the transaction chain in the index chain includes: If the number of potential blocks in a single index block is zero, the root hash path is not stored; if the number of potential blocks is one, the opposite subtree path is stored; if the number of potential blocks on the transaction chain exceeds half of the preset threshold, the hash result of the useless block is stored.

9. The dual blockchain node layering and block optimization method for the Internet of Things according to claim 7 is characterized in that: The process of remerging light node index blocks includes: if two adjacent index blocks have the same height, the block header Merkle trees of the corresponding index blocks are merged as left and right subtrees to obtain a new index block; the hash path set of the new index block is obtained according to the hash path sets stored in the two index blocks, and the hash value set and serial number of the new index block are updated.

Images