An efficient internet of things data processing method based on forest type hierarchical block chain

Abstract

The application discloses a kind of efficient Internet of Things data processing methods based on forest type hierarchical block chain, when the several peer nodes in the forest type hierarchical block chain after initialization are not selected new leader node, leader node term expires or leader node drops offline, election is generated, and leader node is obtained, based on forest type hierarchical block chain consensus algorithm is used, node consensus is realized, and leader node generates consensus distribution;Internet of Things equipment of consensus distribution sends data to node, and node generates multi-fork tree chain block;When leader node drops offline, term is about to end or election fails and new leader node is not selected, the process of leader node generating consensus distribution is repeated.The application reduces chain data in the case of multiple node redundancy, avoids the node too concentrated when data storage selection is layered;Using the tamper-proof traceability characteristics of block chain, when node downtime reconnects or new node joins, block data in the block chain can be restored to the latest forest type hierarchical block chain state.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) data processing technology, and relates to an efficient IoT data processing method based on forest-type hierarchical blockchain. Background Technology

[0002] Currently, conventional blockchain models, both domestically and internationally, struggle to handle the issue of high TPS (Transactions Per Second) data being uploaded to the blockchain. Block generation speeds are too slow, with common blockchain platforms ranging from tens to thousands of data points per second. In contrast, IoT data can reach thousands of data points per second. As the number of IoT devices gradually increases, TPS will also gradually increase, making it difficult for existing blockchain platforms to handle massive amounts of data.

[0003] Meanwhile, given the pain points of the aforementioned blockchain platforms, some existing systems abandon the core consensus algorithm of blockchain. Although the speed of block upload can be improved without the core consensus algorithm, a blockchain model lacking a consensus algorithm cannot truly be called a blockchain, leading to some blockchain models becoming a hybrid, neither fish nor fowl. Furthermore, a difficult problem to solve with blockchain is that all nodes need to back up and store data, resulting in significant data redundancy and consuming substantial hardware storage space.

[0004] Blockchain technology achieves complete transaction transparency and immutability, allowing data to be permanently published in a distributed ledger. The decentralized nature of blockchain means that all nodes in the system have equal rights, and no single party can arbitrarily command others. Furthermore, each party in the blockchain network maintains its own ledger, making it difficult to deceive any party. Due to the transparency and immutability of blockchain, network vulnerabilities are mitigated. Summary of the Invention

[0005] To address the problems of low TPS, time-consuming node competition, and large storage space consumption in traditional blockchains, which make it difficult to efficiently and reliably input IoT system data into the blockchain, this invention proposes an efficient IoT data processing method based on a forest-type layered blockchain. This method retains the inherent characteristics of blockchain while enabling high-TPS IoT data to overcome the limitations of traditional blockchains, achieving secure and efficient data storage into the blockchain system, while reducing the resource waste caused by blockchain data redundancy.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: An efficient IoT data processing method based on a forest-type hierarchical blockchain includes the following steps: Step 1: Initialize the forest-type hierarchical blockchain according to the certificate key authentication mechanism; Step 2: When several peer nodes in the initialized forest-type hierarchical blockchain fail to elect a new leader node, the leader node's term expires, or the leader node goes offline, an election is held to obtain a leader node. The consensus algorithm based on the forest-type hierarchical blockchain is used to achieve node consensus, and then the leader node generates consensus allocation. Step 3: The IoT devices allocated by consensus send data to the nodes. The nodes generate multi-branch tree chain blocks, store them in the branch chain of the corresponding node in the multi-branch tree chain stored locally on the node, and broadcast the multi-branch tree chain blocks to light nodes and full nodes. Light nodes verify the multi-branch tree chain blocks, and full nodes verify and store the multi-branch tree chain blocks and fill in the missing blocks. Step 4: When the leader node goes offline, its term is about to end, or it fails to elect a new leader node, proceed to Step 2.

[0007] Furthermore, the certificate key authentication mechanism is built upon the certificate authority framework.

[0008] Furthermore, the certificate key authentication mechanism includes establishing a Certificate Authority (CA), generating public and private keys, signing with the private key, and verifying the signature using the certificate.

[0009] Furthermore, the specific process of step 2 is as follows: 2.1) Node N in the current forest-type hierarchical blockchain i If it discovers that it has lost contact with the leader node or that the leader node's term has expired, it will send a request to other nodes to run for leader. 2.2) The leader node randomly generates a term of office; 2.3) If the term of office is within the range of term of office Δ, proceed to step 2.4); if the term of office is not within the range of term of office Δ, proceed to step 2.2). 2.4) Node N i Broadcast your campaign request to other nodes; 2.5) Other nodes receive the data from node N. i After broadcasting, determine node N. i If the election request is invalid, the request is replied as invalid; if it is valid, the validity of the request is determined based on whether other nodes are election nodes; if valid, proceed to step 2.6). 2.6) When node N i A request to be approved by more than two-thirds of the nodes in a forest-type hierarchical blockchain indicates that node N has received a response vote. i If the election of a leader is successful, the leader node is obtained, and only node N has a leadership position during the current term. i If there is a leader, proceed to step 2.7; otherwise, it indicates that node N in this round... iIf the election is lost, proceed to step 2.1). 2.7) Node N i At the same time, the consensus allocation is announced, and other nodes are notified of their corresponding consensus allocations and the generation of main chain blocks. Where k represents the block number of the main chain, d represents the term number, and the main chain block... Serves as the entry point for all branches of the multi-branch tree during the current term.

[0010] Furthermore, in step 2.5), the specific process of determining the validity of the request based on whether other nodes are candidates is as follows: a) If other nodes are candidates, determine node N. i If the term of office of the incumbent node is longer than that of the elected node, then node N agrees. i If the person becomes a leader and no longer competes for leadership, the request is invalid if it is equal to or less than that. b) If the other nodes are non-candidate nodes, determine node N. i If the requested term is greater than or equal to that of the candidate node, then the node that agrees is N. i If the amount is less than the threshold, the request is invalid.

[0011] Furthermore, the specific process of step 3 is as follows: 1) The consensus-allocated IoT devices send IoT data to node N. i Node N i Determine if the IoT data is correct. If incorrect, discard the data. If correct, determine if the IoT data comes from the IoT device corresponding to the consensus allocation. If yes, proceed to step 2; otherwise, node N... i Forward the data to the corresponding consensus-assigned node N. i+1 Then the IoT devices send all the data to node N. i+1 ; 2) Node N i The data is placed into the current term multi-branch tree chain block of the forest chain block layer. When the multi-branch tree chain block reaches the threshold, node N... i Generate a Merkle tree for several data entries within the threshold, sign the Merkle root, and then insert the multi-branch tree chain block into the corresponding node N of the multi-branch tree chain. i In the branch chain, and broadcast to full nodes and light nodes; 3) When a full node and a light node receive a broadcast, they calculate the Merkle root of the data, then design the signature to obtain the designed Merkle root. They compare the calculated Merkle root with the designed Merkle root. If they are the same, the data is correct, the light node finishes receiving the broadcast, and the full node jumps to step 4). Otherwise, they notify node N. i The block encountered an error; reception failed. 4) All nodes based on ID i Determine the corresponding node N in the multi-way tree chain stored locally by the full node. i If the branch chain is located at the first block of the branch chain, then the previous block of the multi-branch tree chain block is pointed to the main chain block, and the multi-branch tree chain block is placed at that position; if the position is not the first block position, then the multi-branch tree chain block is placed at that position, and then it is checked whether the previous block of the position is missing. If it is not missing, then the process ends; if it is missing, then the chain block auto-completion mechanism is used to complete the block.

[0012] Furthermore, the specific process of using the chain block auto-completion mechanism for block completion is as follows: a) Set a bitmap and detection marker for each branch of the multi-branch tree chain in the current term of the forest chain block layer; wherein, the bitmap is a binary bit marker, each binary bit represents a block, binary 0 means that the block is missing, and binary 1 means that the block exists; the detection marker is used to record the binary position of the most recently detected block to prevent duplicate searches; b) Every 10 seconds, check the number of blocks in each branch chain from back to front. If the binary of the bitmap is found to be 0, jump to step c). If a marker is detected, end the process and update the marker. c) The node retrieves the block hash of the corresponding position from other nodes based on the bit position, downloads the complete block from other nodes, sets the binary bit of the position to 1, and continues to query the bitmap forward from the position until the marker point is detected, and then updates the marker point.

[0013] Furthermore, when the term of the leader node expires, it generates a secondary chain block of the hierarchical chain block layer. The secondary chain block is divided into light blocks and full blocks, which are used to store the block hashes related to the multi-branch tree chain blocks during the current term.

[0014] Furthermore, the specific process for generating secondary chain blocks is as follows: 1) After the leader node election is completed, the leader node divides all nodes into light nodes and full nodes. Then, after all nodes enter the end of their term Δt time, it begins to prepare to generate secondary chain blocks, which include light blocks and full blocks, and saves them. 2) The full node concatenates the block hashes of all the blocks in each branch chain of the multi-fork chain corresponding to the current term of the forest chain block layer to obtain the hash, signs it using the private key, and sends the data to the light node; 3) The light node designs the signature and collects all the hashes sent by the full nodes. It compares the hashes with the branch chains. When it finds that a hash of a full node is wrong, it hashes its own branch chain in the same way, finds the node with the problem, and notifies the full nodes to complete the chain. If there is no problem, it stores several hashes in the light block and notifies the full nodes. The light node generates the light block. 4) After receiving the notification, if the notification is a completion notification, it will complete the block according to the chain block auto-completion mechanism, and then send it to the light node again, repeating steps 2) and 3); if the notification is not a completion notification, it will directly generate a full block and end.

[0015] Compared with the prior art, the present invention has the following beneficial effects: This invention, based on a novel blockchain architecture, breaks through the bottlenecks of traditional blockchains, resolving the awkward mismatch between the massive amounts of IoT data generated per second and the small amounts of data processed per second in traditional blockchain models. It employs a new forest-based hierarchical blockchain consensus algorithm, shifting from consensus on each block in traditional blockchains to consensus on blockchain nodes. IoT devices are randomly assigned to nodes based on hash values, achieving batch consensus on block data and improving blockchain consensus efficiency. This allows for more seamless integration with IoT, achieving a performance of generating 1500 blocks per second, a performance improvement of at least 50%. The hierarchical chain with randomly assigned nodes reduces data redundancy across multiple nodes and avoids overly concentrated data storage, solving the problem of excessive storage space wasted in traditional blockchains and reducing block storage size by nearly half. Leveraging the inherent tamper-proof and traceable characteristics of blockchain, in the event of node failure and reconnection or the addition of new nodes, the blockchain can be restored to the latest forest-based hierarchical state based on the existing block data. Attached Figure Description

[0016] Figure 1 This is a system overview architecture diagram of the present invention; Figure 2 This is a schematic diagram of the forest-type hierarchical blockchain structure of this invention; Figure 3 This is a diagram illustrating the staggered term iteration of the forest-type hierarchical blockchain of this invention; Figure 4 This is a diagram illustrating the relationship between nodes and chains in the forest-type hierarchical blockchain of this invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] The efficient data processing method based on forest-type hierarchical blockchain of the present invention includes the following steps: Step 1, see Figure 2 The forest-type layered blockchain structure is divided into a layered chain block layer and a forest chain block layer. Only the blocks in the forest chain layer store IoT data, while the blocks in the layered chain block layer store some authentication information to ensure the accuracy and security of the data.

[0019] The hierarchical blockchain consists of a main chain and secondary chains. Each node stores a similar hierarchical blockchain. The only difference between nodes is that in the same term, more than half of the nodes store the full blocks as full nodes, and the remaining nodes store the light blocks as light nodes.

[0020] The forest chain block layer consists of several multi-branch tree chains. Each term corresponds to one multi-branch tree chain, and each multi-branch tree chain has multiple branch chains. Each branch chain represents a block generated by a node, and the first block of each branch chain points to the main chain block of the current term, thus forming a multi-branch tree. Secondly, unlike the blocks in the hierarchical chain block layer, blocks in the multi-branch tree chain are not stored by all nodes. Instead, the storage is determined by the light nodes and full nodes generated during the node consensus process. Each term, light nodes only store the blocks of their own corresponding branch chain, while full nodes store the blocks of the branch chains formed by all nodes.

[0021] Step 2: Adopt an interleaved term iteration structure to ensure that node consensus and block confirmation do not consume normal block generation time. The interleaved term iteration structure is as follows: Figure 3 As shown, the staggered term iteration structure includes multiple terms. Within each term, the work of the nodes mainly consists of three parts: node consensus, block generation, and secondary chain generation. Node consensus occurs at the end of the previous term, block generation is a normal business process in the current term, and secondary chain generation takes place within a time Δt before the end of the current term.

[0022] Step 3: Employ a forest-based hierarchical blockchain consensus algorithm to achieve node consensus; In a forest-type hierarchical blockchain, nodes are divided into the following roles: leader nodes, election nodes, follower nodes, and pending nodes.

[0023] In this system, the leader node is the leader of the current term. At the beginning of each new term, it is responsible for generating the main chain block and issuing the consensus allocation for all nodes in the current system. This consensus allocation serves as the basis for the data allocation received by nodes in the current term. Therefore, nodes can only write the corresponding allocated IoT data into the block, and then store the chain block according to whether they are allocated as a light node or a full node. After the leader node generates the main chain block, it also handles the block consensus task at the same level as the follower nodes. Follower nodes are normal worker nodes, responsible for writing IoT data from the consensus allocation assigned by the current leader node into blocks, and then distributing them to other nodes for verification. Other nodes check whether the block signature is correct and whether it is data sent from the corresponding consensus allocation vehicle-to-everything (V2X) terminal. If everything is correct, it is written into the corresponding tree chain. If there is an error, the corresponding node is notified to request resending. If the error persists after three repetitions, the block is discarded. Election nodes are temporary roles, and any surviving node in the system can act as an election node. When a leader node's term is about to end or after a node goes offline and recovers, the leader node can become an election node to run for leadership again. Follower nodes can also become election nodes and broadcast to other nodes to compete for the leadership position. Although all nodes can become election nodes to run for leadership at the end of their current term, the term has not yet ended, and all nodes still need to continue to verify blocks and upload them to the chain. When a new leader node is elected and begins a new term, nodes update the consensus allocation to receive new data transmitted by the vehicle network system and determine whether they are light nodes or full nodes to store the corresponding blocks. Only election nodes whose term is greater than or equal to the term of the vast majority of nodes in the system are legitimate election nodes. A pending node is a temporary role, usually a newly joined node. It first needs to synchronize with the current blockchain. Only after synchronization is completed can it become an election node in the next term. If it fails, it can only become a follower node.

[0024] The leader node divides all nodes into light nodes and full nodes. Node consensus includes consensus allocation, the purpose of which is to ensure that each node performs its specific function without duplication of work. Consensus allocation is mainly divided into two types: allocation between light nodes and full nodes, and allocation to IoT terminals. These will be explained in detail below: 1) Allocation of light nodes and full nodes The purpose of allocating light nodes and full nodes is to reduce the number of data blocks stored by nodes in the current term, thereby reducing storage space consumption. These nodes are allocated by the current leader through a selection algorithm. After each node generates blocks based on vehicle network data, light nodes only store the blocks generated by their own nodes, while full nodes store the blocks generated by all nodes.

[0025] The core idea of ​​the selection algorithm is to elect more than half of the current number of nodes as full nodes and the remaining nodes as light nodes. Simultaneously, among these nodes, the number of nodes that have previously served as the leader node should be maximized, because the leader node is recognized by other nodes and has the highest credibility. Furthermore, the election of the leader node is random, preventing any single node from remaining the leader indefinitely. The selection algorithm steps are as follows: Starting from the current term, count backwards through the total number of nodes N for the previous 12 terms. This yields the total number of nodes K that have served as leaders within these N nodes.<i,m> , where (i represents the i-th node, and m represents the number of times it has led). For each of these nodes, the node's weight increases by 1 (i.e., m+1).

[0026] If k>= N / 2 +1 indicates that the number of leader nodes is greater than half. These k nodes are sorted in descending order of m, and selected based on the m value in descending order. N / 2 One node is designated as a full node, and the remaining nodes are designated as light nodes.

[0027] If k < N / 2 +1 indicates that the number of leader nodes is less than or equal to half of N nodes, and these k nodes are all considered full nodes. Additionally, nodes are randomly selected from the remaining nodes. N / 2 +1 to k nodes are also treated as full nodes, and the remaining nodes are treated as light nodes.

[0028] 2) Allocation of IoT terminals The newly appointed leader node will distribute the connected vehicle systems evenly across all nodes, including the leader node, based on the current number of nodes in the chain and the number of connected vehicles in the system. This is done by assigning a weighted value to the unique ID of each connected vehicle system, generating a random value, adding the weighted values, and sorting them by size. This ensures the devices are evenly distributed among the nodes in the system. For example, if the system currently has five connected vehicle systems with calculated values ​​of IOV1=100, IOV2=150, IOV3=99, IOV4=56, and IOV5=334, and since the order of each node in the system is fixed, the three nodes will be node1, node2, and node3. The device values, sorted from largest to smallest, would be IOV5, IOV2, IOV1, IOV3, and IOV4. Ultimately, the three nodes will manage the following devices: node1 manages the data for IOV5 and IOV2, node2 manages the data for IOV1 and IOV3, and node3 manages the data for IOV4. The node and connected vehicle system allocation is as follows: Figure 4As shown, after the vehicle-to-everything (V2X) system sends data to the corresponding node, the node will determine whether the device is a device issued within the consensus allocation. The node is only responsible for receiving data from devices within its own consensus allocation. If not, the node will forward the data to the corresponding node and notify the IoT device to send the data to the corresponding node.

[0029] The specific steps to achieve node consensus using a forest-based hierarchical blockchain consensus algorithm are as follows: In a forest-based hierarchical blockchain, the role transformation of nodes is divided into three steps: election, block generation, and leadership innovation.

[0030] Step 1: Establishing a traditional PKI (Public Key Infrastructure) mechanism involves building a Certificate Authority (CA) and subsequently establishing a certificate key authentication mechanism. This mechanism includes establishing a CA, generating public and private keys, signing with the private key, and verifying the signature using the certificate. In establishing a CA, the administrator acts as the root CA, responsible for generating certificates for nodes. Nodes, acting as secondary CAs, are responsible for generating certificates for IoT devices. Public and private keys are generated by each entity itself; the private key is kept secret, while the public key is publicly disclosed. The CA then generates certificates based on these public keys, which are also publicly disclosed. For signing with the private key, each entity encrypts data using its own private key. This encrypted ciphertext is unique and serves as the signature. For verifying the signature using the certificate, the verifying entity uses the public key from the certificate to verify the signature, ensuring the true identity of the signer.

[0031] Based on the certificate-key authentication mechanism, the key is initialized and a forest-based hierarchical blockchain network is established. A term duration Δ is set, and the duration of each random term cannot exceed the maximum value or be less than the minimum value, i.e., it must be within the term duration Δ. The term duration Δ serves as an indicator for leader election. Because the random number of term duration Δ may exceed the limit during the leader election, candidates are not required to recalculate the random number, thus reducing the possibility of multiple candidate nodes simultaneously becoming the leader.

[0032] Step 2: In a forest-type hierarchical blockchain, there are several peer nodes. When several peer nodes fail to elect a new leader node, the leader node's term expires, or the leader node goes offline, an election is held to elect a new leader node. The leader node then generates consensus, distributes resources, and generates main chain blocks. The specific process is as follows: 2.1) Node N in the current forest-type hierarchical blockchain i If a node discovers that it has lost contact with the leader node or that the leader node's term has expired, it will begin preparing to send its own request to run for leader to other nodes.

[0033] 2.2) The leader node randomly generates a term of office; 2.3) If the term duration cannot exceed the maximum value of the term duration range Δ and is not less than the minimum value of the term duration range Δ, i.e., it is within the term duration range Δ, then proceed to step 2.4); if the term duration is not within the term duration range Δ, then proceed to step 2.2). 2.4) Node N i Broadcast your campaign request to other nodes , among which, signature It is composed of node N i Private key identity The signature performed; 2.5) Other nodes receive the data from node N. i After the broadcast, refer to node N. i public key ,sign With the length of term Is it valid, if the public key is... ,sign With the length of term If any item in the form is invalid, the request is invalid and the process ends; otherwise, there are two possible scenarios: a) If other nodes are also candidates, determine node N. i If the term of office of the incumbent node is longer than that of the elected node, then vote to approve node N. i If you are a leader and no longer competing for leadership, and your vote is equal to or less than the leader's, then not voting means disagreeing and replying to the request is invalid. b) If other nodes are not candidates for election, determine node N. i If the requested term is greater than or equal to that of the candidate node, then vote in favor of node N. i If the leader's response is less than the voter's, then the request is invalid and the process ends. 2.6) When node N i A request to be approved by more than two-thirds of the nodes in a forest-type hierarchical blockchain indicates that node N has received a response vote. i If the election of a leader is successful, the leader node is obtained, and only node N has a leadership position during the current term. i If there is a leader, proceed to step 2.7; otherwise, it indicates that node N in this round... i If the election is lost, proceed to step 2.1). 2.7) Node N i Simultaneously, consensus allocation is announced, and other nodes are notified of their respective consensus allocations (including allocations to light nodes, full nodes, and IoT terminals) and the generation of main chain blocks. (Where k represents the k-th block of the main chain, and d represents the d-th term). Main chain blocks The storage nodes contain consensus allocation information and node voting agreement information, serving as the entry point for all branch chains of the multi-branch tree chain during the current term. The block preceding the first block of each branch chain is the main chain block. ; Step 3: In a forest-type hierarchical blockchain, after the leader node election concludes and a new term begins, IoT devices send data to the nodes. The nodes generate multi-branch tree chain blocks and write them to the corresponding branch chains of the multi-branch tree chain in their local storage. The multi-branch tree chain blocks are then broadcast to light nodes and full nodes. Light nodes only verify the block, while full nodes verify and store the block and complete any missing blocks. The specific process is as follows: 1) Internet of Things (IoT) devices To their own Send to node N i Node N i judge If the data is incorrect, discard it; otherwise, evaluate it. Is the data sent by the IoT device corresponding to the consensus allocation? If yes, proceed to step 2; otherwise, node N... i The data will be forwarded to the corresponding consensus-allocated node N. i+1 and notify IoT devices Change the data sending node and send all data to node N. i+1 ; 2) Node N i The data is placed into the current term multi-branch tree chain block TBc of the forest chain block layer. k In the middle, when the multi-branch tree chain block TBc k After reaching the threshold, node N i Generate a Merkle tree for several data points within the threshold, and sign the Merkle root. Node N i This multi-branch tree chain block Insert the corresponding node N into the multi-way tree chain i In the branch chain, and broadcast to full nodes and light nodes; 3) When full nodes and light nodes receive a broadcast, they calculate the Merkle root of the data and then verify the signature. The process involves despelling the Merkle root and obtaining the despelled Merkle root. The calculated Merkle root is then compared with the despelled Merkle root. If they match, the data is correct, and the light node completes its reception; the full node proceeds to step 4. Otherwise, node N is notified. i The block encountered an error; reception failed. 4) All nodes based on ID i Determine the corresponding node N in the multi-way tree chain stored locally by the full node. iThe position of the branch chain; if the position is at the first block of the branch chain, then the multi-branch tree chain block TBc will be... k The previous block points to the main chain block. and the multi-branch tree chain block TBc k Place it at this location; if this location is not the first block location, then only place the multi-branch tree chain block TBc. k Simply place the block at that position, then check if the preceding block is missing. If it is not missing, the process ends; otherwise, perform block completion. The specific completion process is as follows: a) Set a bitmap and a detection marker for each branch of the multi-branch tree chain in the current term of the forest chain block layer. The bitmap is a binary bit marker, where each binary bit represents a block. A binary 0 indicates that the block is missing, and a binary 1 indicates that the block exists. The detection marker is used to record the binary position of the most recently detected block to prevent duplicate searches.

[0034] b) Every 10 seconds, check the number of blocks in each branch chain from back to front. During the bitmap detection process, if the binary value of the bitmap is found to be 0, jump to step 3). If a marker is detected, the process ends and the marker is updated.

[0035] c) The node retrieves the block hash of the corresponding position from other nodes based on the bit position, downloads the complete block from other nodes, sets the binary bit of the position to 1, and continues to query the bitmap forward from the position until the marker point is detected, and then updates the marker point.

[0036] Step 4: If the leader node goes offline, its term is about to end, or it fails to win the election and no new leader node is elected, proceed to Step 2.

[0037] When each leader node's term ends, a secondary chain block is generated within the hierarchical chain block layer. Secondary chain blocks are divided into light blocks and full blocks, both storing the block hashes related to the multi-branch tree chain blocks during the current term. The uniqueness and integrity of the multi-branch tree chain blocks for the current term are guaranteed based on these block hashes. The specific process for generating secondary chain blocks is as follows: 1) After the leader node election is completed, the leader node divides all nodes into light nodes and full nodes. Then, after all nodes enter the end of their term Δt time, it begins to prepare to generate secondary chain blocks, which include light blocks and full blocks, and saves them.

[0038] 2) The full node will concatenate all the block hashes of each branch chain block in the multi-fork chain corresponding to the current term of the forest chain block layer to obtain the hash, sign it with its own private key, and send the data to the light node.

[0039] 3) The light node designs the signature and collects all the hashes sent by the full nodes. It compares the hashes with the branch chains. When it finds that a hash of a full node is wrong, it hashes its own branch chain in the same way, finds the node with the problem, and notifies the full nodes to complete the chain. If there is no problem, it stores several hashes in the light block and notifies the full nodes. The light node generates the light block.

[0040] 4) After receiving the notification, if the notification is a completion notification, it will complete the block according to the chain block auto-completion mechanism, and then send it to the light node again, repeating steps 2) and 3); if the notification is not a completion notification, it will directly generate a full block and end.

[0041] This invention is used for efficient blockchain integration of data from various IoT devices in enterprises. It uses a forest-type hierarchical blockchain to replace the traditional chain-based blockchain model. Each node is a branch in the tree, and all branches constitute the current main chain block. T main chain blocks are layered upwards to reduce data redundancy.

[0042] In this invention, all nodes are servers.

[0043] For example, the enterprises could be car operators or relevant regulatory authorities, the servers would be provided by the operators to deploy the blockchain, and the IoT devices would be various sensor data in the car, such as: safety system sensors, image sensors, C-V2X communication, positioning systems, etc.

[0044] In a forest-type hierarchical blockchain, all chains are stored within every node of the system, which is composed of and maintained by multiple peer nodes with identical functions and status. Consensus distribution is achieved by the newly appointed leader node distributing consensus resources evenly to all follower nodes and itself based on the current number of nodes in the chain.

[0045] Figure 1 This is a physical architecture diagram of the forest-type hierarchical blockchain of the present invention. All nodes have equal status and identity. Each node can act as a leader node, an election node, a follower node, or a pending node, ensuring that all nodes are peers and achieving the idea of ​​decentralization. The efficient IoT data processing method based on the forest-type hierarchical blockchain includes the following steps: Step 1: Initialize the key and forest-type hierarchical blockchain network. The car operator and other participating institutions negotiate to determine the range of Δ term length as needed. This value is only to reduce the possibility of simultaneous leadership elections. Establish a PKI mechanism, with the car operator acting as the certificate authority to ensure that all nodes or smart cars participating in the forest-type hierarchical blockchain have valid identities.

[0046] Step 2: The automotive supplier deploys several servers, or peer nodes, to run the blockchain system. See details below. Figure 1In each node, after the system is running, an election will be held when several peer nodes fail to elect a new leader node, the leader node's term expires, or the leader node goes offline. The specific process is as follows: 1) Node N i The running monitoring thread automatically monitors its current identity, the expiration time and survival status of the leader node, and if there is no leader node, it should send a request to other nodes to run for leader.

[0047] 2) Other nodes check N i Verify the node's identity and the legitimacy of the requested information, and then respond.

[0048] 3) When node N i When node N receives a two-thirds or more of the votes in favor of the participating nodes, it indicates that node N has achieved this. i Once the leader is successfully elected, other nodes and connected vehicle devices are notified to switch to receiving data for the next term. At the same time, a consensus distribution is issued and notified to all nodes.

[0049] 4) All nodes enter a new consensus phase. Once they receive the data allocated in the previous consensus, they will notify the vehicle-to-everything (V2X) device to change its data sender and forward the data to the corresponding node.

[0050] If a node suddenly goes down for a period of time, it can automatically pull the missing block information from the forest-type hierarchical blockchain after it is powered on, based on the latest term of office and the block information. Once the synchronization is complete, it can participate in the election for the next term of leader.

[0051] Figure 2 This is a diagram illustrating a forest-type hierarchical blockchain. Each term corresponds to a main chain block, generated by the leader of that term. This block stores the signatures of all follower nodes' agreement requests and consensus allocation information during that term. Each branch of a multi-way tree in the forest chain connected to this block represents the data of a node. When any node generates block data, other nodes determine the block according to the consensus allocation. Full nodes place the block into the corresponding branch, while light nodes do not store it. Node data does not occupy the same chain, ensuring the sequentiality of all node data and preventing inconsistencies and forks. If data is lost due to a fork, the node's position in the consensus allocation can be located, and data can be retrieved from other nodes or the node that generated the data using multi-threading. This process does not consume the main thread of the forest-type hierarchical blockchain, improving data processing efficiency.

[0052] Figure 4The diagram illustrates the relationship between nodes and the blockchain. All nodes in the blockchain system store a forest-structured, hierarchical blockchain according to the rules described above. Block data generated by nodes is synchronized to their respective nodes. Because nodes are randomly selected for storing full and light blocks, there may be significant differences in data storage volume among nodes during certain terms. However, over time, the storage volume and space usage of all nodes will become similar. Therefore, to simplify the relationship and make the diagram more intuitive, only the main chain and secondary chains are shown. The diagram shows that within the same term, the types of blocks stored on the secondary chain differ among nodes: more than half of the nodes store full blocks, while the remainder store light blocks.

[0053] Reference Figure 1 Each car in the diagram has several IoT devices that need to transmit data to the car operator's server. The sensors then transmit their data via the vehicle's terminal. The data is sent to the chain node, which verifies the device information and determines whether the device is the one allocated by the consensus based on the public key. If it is, the data is put into the block; otherwise, the data is forwarded to the node allocated by the consensus and the vehicle terminal is notified that all subsequent data is sent to the corresponding node.

[0054] Furthermore, once the amount of vehicle-to-everything (V2X) data within a block reaches the required level, a Merkle tree is generated from that data. Simultaneously, the Merkle tree is signed, and a forest chain block layer block is generated. This node then stores the block... It is placed into the branch chain corresponding to its hash and broadcast to other nodes. When other nodes receive the block, they calculate the Merkle root of the data. The signature is designed and compared with the signature. If they are the same, the data is correct. If other nodes are light nodes, only the block is verified. If they are full nodes, the block is downloaded and stored locally.

[0055] This invention discloses a highly efficient IoT data processing method based on a forest-type hierarchical blockchain. It proposes a novel blockchain architecture concept, breaking through the bottlenecks of traditional blockchains and resolving the awkward mismatch between the massive amounts of IoT data generated per second and the small amounts of data processed per second in traditional blockchain models. A new consensus algorithm is adopted, shifting from consensus on each block in traditional blockchains to consensus on blockchain nodes. IoT devices are randomly assigned to nodes according to their hash values, thus achieving batch consensus on block data, improving blockchain consensus efficiency and enabling more seamless integration with IoT. The hierarchical chain with randomly assigned nodes reduces data redundancy across multiple nodes and avoids overly concentrated node selection during layering, solving the problem of excessive storage space wasted in traditional blockchains. Leveraging the inherent tamper-proof and traceable characteristics of blockchain, in case of node failure and reconnection or the addition of new nodes, the blockchain can be restored to the latest forest-type hierarchical blockchain state based on the block data.

Claims

1. A highly efficient IoT data processing method based on a forest-type hierarchical blockchain, characterized in that, Includes the following steps: Step 1: Initialize the forest-type hierarchical blockchain according to the certificate key authentication mechanism; Step 2: When several peer nodes in the initialized forest-type hierarchical blockchain fail to elect a new leader node, the leader node's term expires, or the leader node goes offline, an election is held to obtain a leader node. The consensus algorithm based on the forest-type hierarchical blockchain is used to achieve node consensus: After a node is authenticated by PKI, it initiates an election. If it obtains the consent of more than two-thirds of the nodes, it is elected as the leader node. Then the leader node generates consensus allocation. Step 3: The IoT devices allocated by consensus send data to the nodes. The nodes generate multi-branch tree chain blocks and store them in the branch chain of the corresponding node in the multi-branch tree chain stored locally on the node. The multi-branch tree chain blocks are then broadcast to light nodes and full nodes. Light nodes verify the multi-branch tree chain blocks by verifying the consistency between the Merkle root and the signature. After the full nodes complete the same verification, they store the multi-branch tree chain blocks and fill in the missing blocks through bitmap detection and cross-node hash retrieval. Step 4: When the leader node goes offline, its term is about to end, or it fails to elect a new leader node, proceed to Step 2.

2. The efficient IoT data processing method based on forest-type hierarchical blockchain according to claim 1, characterized in that, The certificate key authentication mechanism is built by the certificate authority.

3. The efficient IoT data processing method based on forest-type hierarchical blockchain according to claim 1, characterized in that, The certificate key authentication mechanism includes establishing a Certificate Authority (CA), generating public and private keys, signing with the private key, and verifying the signature using the certificate.

4. The efficient IoT data processing method based on forest-type hierarchical blockchain according to claim 1, characterized in that, The specific process of step 2 is as follows: 2.1) Node N in the current forest-type hierarchical blockchain i If it discovers that it has lost contact with the leader node or that the leader node's term has expired, it will send a request to other nodes to run for leader. 2.2) The leader node randomly generates a term of office; 2.3) If the term of office is within the range of term of office Δ, proceed to step 2.4); if the term of office is not within the range of term of office Δ, proceed to step 2.2). 2.4) Node N i Broadcast your campaign request to other nodes; 2.5) Other nodes receive the data from node N. i After broadcasting, determine node N. i The campaign request must be valid; if invalid, the response is invalid. If valid, then determine the validity of the request based on whether other nodes are candidates; if valid, proceed to step 2.6). 2.6) When node N i A request to be approved by more than two-thirds of the nodes in a forest-type hierarchical blockchain indicates that node N has received a response vote. i If the election of a leader is successful, the leader node is obtained, and only node N has a leadership position during the current term. i If there is a leader, proceed to step 2.7; otherwise, it indicates that node N in this round... i If the election is lost, proceed to step 2.1). 2.7) Node N i At the same time, the consensus allocation is announced, and other nodes are notified of their corresponding consensus allocations and the generation of main chain blocks. Where k represents the block number of the main chain, d represents the term number, and the main chain block... Serves as the entry point for all branches of the multi-branch tree during the current term.

5. The efficient IoT data processing method based on forest-type hierarchical blockchain according to claim 4, characterized in that, In step 2.5), the specific process of determining the validity of the request based on whether other nodes are candidates is as follows: a) If other nodes are candidates, determine node N. i If the term of office of the incumbent node is longer than that of the elected node, then node N agrees. i If the person becomes a leader and no longer competes for leadership, the request is invalid if it is equal to or less than that. b) If the other nodes are non-candidate nodes, determine node N. i If the requested term is greater than or equal to that of the candidate node, then the node that agrees is N. i If the amount is less than the threshold, the request is invalid.

6. The efficient IoT data processing method based on forest-type hierarchical blockchain according to claim 1, characterized in that, The specific process for step 3 is as follows: 1) The consensus-allocated IoT devices send IoT data to node N. i Node N i Determine if the IoT data is correct. If incorrect, discard the data. If correct, determine if the IoT data comes from the IoT device corresponding to the consensus allocation. If yes, proceed to step 2; otherwise, node N... i Forward the data to the corresponding consensus-assigned node N. i+1 Then the IoT devices send all the data to node N. i+1 ; 2) Node N i The data is placed into the current term multi-branch tree chain block of the forest chain block layer. When the multi-branch tree chain block reaches the threshold, node N... i Generate a Merkle tree for several data entries within the threshold, sign the Merkle root, and then insert the multi-branch tree chain block into the corresponding node N of the multi-branch tree chain. i In the branch chain, and broadcast to full nodes and light nodes; 3) When a full node and a light node receive a broadcast, they calculate the Merkle root of the data, then design the signature to obtain the designed Merkle root. They compare the calculated Merkle root with the designed Merkle root. If they are the same, the data is correct, the light node finishes receiving the broadcast, and the full node jumps to step 4). Otherwise, they notify node N. i The block encountered an error; reception failed. 4) All nodes based on ID i Determine the corresponding node N in the multi-way tree chain stored locally by the full node. i If the branch chain is located at the first block of the branch chain, then the previous block of the multi-branch tree chain block is pointed to the main chain block, and the multi-branch tree chain block is placed at that position; if the position is not the first block position, then the multi-branch tree chain block is placed at that position, and then it is checked whether the previous block of the position is missing. If it is not missing, then the process ends; if it is missing, then the chain block auto-completion mechanism is used to complete the block.

7. The efficient IoT data processing method based on forest-type hierarchical blockchain according to claim 6, characterized in that, The specific process of using the chain block auto-completion mechanism for block completion is as follows: a) Set a bitmap and detection marker for each branch of the multi-branch tree chain in the current term of the forest chain block layer; wherein, the bitmap is a binary bit marker, each binary bit represents a block, binary 0 means that the block is missing, and binary 1 means that the block exists; the detection marker is used to record the binary position of the most recently detected block to prevent duplicate searches; b) Every 10 seconds, check the number of blocks in each branch chain from back to front. If the binary of the bitmap is found to be 0, jump to step c). If a marker is detected, end the process and update the marker. c) The node retrieves the block hash of the corresponding position from other nodes based on the bit position, downloads the complete block from other nodes, sets the binary bit of the position to 1, and continues to query the bitmap forward from the position until the marker point is detected, and then updates the marker point.

8. The efficient IoT data processing method based on forest-type hierarchical blockchain according to claim 1, characterized in that, Within a time interval Δt before the expiration of the leader node's term, secondary chain blocks of the hierarchical chain block layer are generated. The secondary chain blocks are divided into light blocks and full blocks, which are used to store the block hashes related to the multi-branch tree chain blocks during this term.

9. The efficient IoT data processing method based on forest-type hierarchical blockchain according to claim 8, characterized in that, The specific process for generating secondary chain blocks is as follows: 1) After the leader node election is completed, the leader node divides all nodes into light nodes and full nodes. Then, after all nodes enter the end of their term Δt time, it begins to prepare to generate secondary chain blocks, which include light blocks and full blocks, and saves them. 2) The full node concatenates the block hashes of all the blocks in each branch chain of the multi-fork chain corresponding to the current term of the forest chain block layer to obtain the hash, signs it using the private key, and sends the data to the light node; 3) The light node designs the signature and collects the hashes sent by all the full nodes. It compares the hashes with the branch chains. When it finds that the hash of a full node is wrong, it hashes its own branch chain in the same way, finds the node with the problem, and notifies the full nodes to complete the chain. If there are no problems, store several hashes in the light block and notify the full node, and the light node generates the light block; 4) After receiving the notification, if the notification is a completion notification, it will complete the block according to the chain block auto-completion mechanism, and then send it to the light node again, repeating steps 2) and 3); if the notification is not a completion notification, it will directly generate a full block and end.

Images