A blockchain consensus method and system based on fragmentation in an internet of things

Abstract

The application provides a blockchain consensus method based on fragmentation in an Internet of Things, transaction load is distributed to different fragments through network fragmentation, each fragment only processes transactions or transactions related to the fragment; considering the busy degree of each node, the block right is allocated according to the number of cached transactions and the state ranking in the node message receiving module on the premise of realizing fair competition. The application distributes the data request of the Internet of Things terminal to the corresponding fragment through network fragmentation, avoids the high load risk of the main node processing all requests in the traditional distributed protocol and the bottleneck problem caused thereby, and simultaneously improves the scalability of the system and adapts to more application scenarios. According to the data priority and busy degree of different fragments, the block right is reasonably and quickly allocated, so that the submission delay of important data can be reduced. In addition, all nodes maintain consistent blockchain data, which provides a simple and unified data view and avoids the influence of frequent cross-fragment data reading operations on delay-sensitive application scenarios.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, specifically relating to a sharding-based blockchain consensus method and system in IoT. Background Technology

[0002] The Internet of Things (IoT) has a completely different architecture from the internet, extending network connectivity and computing power to objects with limited computing capabilities, and allowing these devices to generate, exchange, and consume data with minimal human intervention. Cloud services built on the internet have been widely adopted for processing and storing massive amounts of IoT data. However, due to the centralized data processing and storage model, the reliability, integrity, and availability of IoT data cannot be guaranteed when cloud services suffer from network attacks, single points of failure, and other issues. At the same time, users are concerned about the data security of cloud services, as cloud service administrators may arbitrarily tamper with user data or sell sensitive information for profit. Furthermore, because cloud services are located far from the IoT field, terminal devices need to go through multiple network devices to upload data or request historical data, and the time overhead of data transmission is highly detrimental to latency-sensitive applications. Building a distributed data storage and management system close to the gateway or IoT host near the sensing devices provides a solution for the IoT.

[0003] In recent years, blockchain has been considered an effective approach to addressing the security challenges of the Internet of Things (IoT). Blockchain is a distributed, tamper-proof database. Unlike traditional systems, blockchain achieves consensus among geographically dispersed participants without requiring a trusted third-party centralized authority for authorization and management. Multiple transactions within a blockchain network are linked sequentially in a block-based organization, ensuring data traceability and immutability. All nodes in the blockchain network collectively maintain consistent and unique blockchain data, making blockchain a reliable and trustworthy system in a distributed environment.

[0004] Popular blockchain systems like Bitcoin and Ethereum are typical public blockchain systems. This means that participants can freely join and leave without strict identity verification, and the network size can reach tens of thousands. However, this also brings other limitations. Bitcoin's proof-of-work mechanism is extremely computationally intensive, resulting in wasted electricity, and the system's overall transaction processing capacity is completely insufficient to meet the massive data demands of the Internet of Things (IoT). In the consortium blockchain field, such as Hyperledger, most use traditional distributed consensus protocols, suitable for small-scale networks, while IoT systems involve hundreds of millions of terminal devices.

[0005] Existing research still has shortcomings, and the improvements made in this invention have better results, for example, compared with the following existing solutions:

[0006] Patent application CN110570202A proposes a shard-based hybrid consensus method employing a two-layer consensus group. The first layer consists of sub-consensus groups for each shard, using the PoS consensus method; the second layer is the main chain consensus group composed of representative nodes from each shard, using the PBFT consensus method. This patent also employs a two-layer consensus group (intra-shard consensus and coordination committee consensus), but uses a different consensus method to improve the Raft method and reduce the load on the main nodes in the consensus group. Furthermore, this patent deals with cross-shard transactions in a financial scenario, which differs from the IoT field of this patent.

[0007] Patent application CN110868434A proposes a multi-layered sharding architecture for blockchain consensus methods and systems, which reduces communication overhead by sharding to reduce consensus groups. However, it still uses the PoW consensus method, consuming a large amount of computer resources for repeated hash calculations, making it unsuitable for IoT scenarios where computing resources are limited.

[0008] Patent application CN112910965A proposes a method and system for submitting cross-shard transactions in a sharded blockchain, achieving an efficient cross-shard transaction processing mechanism. This patent pertains to a financial application scenario and does not detail the intra-shard and global consensus methods and processes.

[0009] Patent application CN112968942A proposes a secure blockchain data storage framework and method. This patent divides the data storage network into multiple groups using a sharding-like mechanism, with each group maintaining its own independent blockchain using the Raft consensus method. While this patent also uses sharding, it still maintains globally consistent single-chain data, and its improved Raft method reduces the message load on the leader node.

[0010] Patent application CN113411376A proposes a sensor data processing method and apparatus based on blockchain sharded storage. This patent uses a single-layer, multi-sub-consensus group model, where each shard maintains an independent blockchain, reducing the overall system reliability; a single shard failure leads to the complete loss of all data in that shard. In contrast, this patent uses a multi-layer consensus model and maintains a globally consistent single blockchain.

[0011] Patent application CN113422805A proposes a sharding consensus method based on a verifiable random function. This patent shards the network randomly, unlike the method used in this patent, which shards the network based on network adjacency. Furthermore, this patent does not elaborate on state sharding and consensus content.

[0012] Patent application CN113570357A proposes a dynamic, hierarchical, and efficient PBFT method. This patent uses an average random method for network sharding, unlike the method used in this patent which shards networks based on network adjacency. Furthermore, it employs the PBFT consensus method both within shards and globally, resulting in higher communication complexity compared to the improved Raft method in this patent. Additionally, the high message load of the proxy nodes described in this patent becomes a system bottleneck.

[0013] The patent application with publication number CN114124410A proposes an improved POA consensus method for multi-party verification in supply chain scenarios. This patent uses an average distribution method for network sharding, maintains consistent blockchain data globally, uses the PBFT consensus method with high communication complexity within shards, and uses the PoA consensus method globally. The consensus process suffers from the problem of synchronous blocking between shard consensus and global consensus. Summary of the Invention

[0014] To address the issues of low throughput and lack of scalability in existing blockchain technologies within the Internet of Things (IoT) field, this invention provides a sharding-based blockchain consensus method and system for IoT, applicable to blockchain-based IoT data storage management platforms, enabling efficient and reliable storage of IoT data.

[0015] This invention provides a sharding-based blockchain consensus method in the Internet of Things. By sharding the network, the transaction load is distributed to different shards, and each shard only processes transactions or affairs related to its own shard. Considering the busyness of each node, and under the premise of achieving fair competition, the block generation right is allocated according to the number of cached transactions and their status ranking in the node message receiving module.

[0016] Moreover, it includes the following steps,

[0017] Step 1: After system initialization, nodes in the blockchain system start up according to the initial configuration of the node status module;

[0018] Step 2: Divide the blockchain system into multiple shards through network sharding. Within each shard, maintain a unique master node through an intra-shard consensus protocol, while other nodes are intra-shard slave nodes.

[0019] Step 3: All master nodes within the slice form a coordinator committee and elect a single global master node within the committee.

[0020] Step 4: The global master node assigns the master node within each shard to serve as the global coordinating node according to the busyness of each shard.

[0021] Step 5: The global coordination node coordinates with other slave nodes within the same shard to pre-submit one or more blocks in sequence according to their busyness level;

[0022] Step six: After completing the block pre-commit, the global coordinating node triggers the election of the next global coordinating node in step four; at the same time, the formal block submission begins, and after the block submission is completed, the IoT terminal is notified to complete the request.

[0023] Moreover, nodes in a blockchain system have five different roles: intra-segment slave node, intra-segment master node, global master node, anchor node, and global coordinator node.

[0024] After initialization, a node defaults to being a slave node within the same slice, waiting for messages to be sent by other nodes.

[0025] Within the same shard, slave nodes maintain a unique master node through the shard consensus protocol. The master node maintains its role by periodically sending heartbeats to other slave nodes, preventing other slave nodes from initiating a new election due to heartbeat timeouts. Simultaneously, when a slave node receives a heartbeat reply, it receives a confirmation message from the master node, which includes the number and status of cached messages in the node's message receiving module. The master node continuously updates the ranking of slave nodes in the state management module.

[0026] All shard master nodes form a coordinator committee. This committee maintains a single global master node through an internal consensus protocol. The global master node maintains its role within the coordinator committee by periodically sending heartbeats to other committee members, preventing other shard master nodes from initiating new elections due to heartbeat timeouts. The global master node is assigned to coordinator committee members in sequence according to the shard's workload.

[0027] The global coordination node allocates block production rights in order of the ranking of intra-slice slave nodes in its state management module. The intra-slice slave nodes that obtain block production rights pre-submit new blocks.

[0028] Once all new blocks have been pre-committed during the term of the global coordinating node, the global coordinating node sends a pre-commit completion message to the next global coordinating node and begins the work of the next global coordinating node.

[0029] Once the pre-commit of a new block is completed during the global coordinating node's term, the formal commit of the new block begins. The formal commit process includes the global coordinating node synchronizing the new block data with other nodes within its shard and sending a formal commit message to the anchor node.

[0030] Furthermore, nodes in a blockchain system include the following modules:

[0031] The status management module is used to manage the status data of nodes in order to maintain system functionality;

[0032] The role management module is used to manage the roles that nodes play in the system and the transitions between different roles, thereby enabling protocol functions and providing external services;

[0033] The message receiving module is used to verify and cache pending requests from IoT terminals, and to verify and transmit messages between nodes to the message processing module.

[0034] The message processing module is used by nodes to process inter-node messages transmitted from the message receiving module according to the protocol.

[0035] The message sending module is used to send messages to be sent from the message processing module, as well as the periodic heartbeat information of the master node within the chip;

[0036] The data management module is used to manage blockchain data and provide read and write services to external parties.

[0037] Furthermore, the blockchain system is divided into multiple shards through network sharding, with each shard handling data requests from IoT terminals within its own shard.

[0038] Moreover, through a two-layer consensus protocol, multiple shards are coordinated to submit new blocks in turn to maintain consistent blockchain data; during message exchange, the timeout period for nodes to wait for messages is matched according to the actual project and needs.

[0039] Moreover, the node workload is matched according to the actual project and needs, and is implemented by the number and status of data requests from different types of IoT terminals cached by the nodes.

[0040] On the other hand, the present invention also provides a sharded blockchain consensus system for the Internet of Things, for implementing the sharded blockchain consensus method for the Internet of Things as described above.

[0041] Furthermore, it includes a processor and a memory, the memory being used to store program instructions, and the processor being used to invoke the stored instructions in the memory to execute a sharded blockchain consensus method in the Internet of Things as described above.

[0042] Alternatively, it may include a readable storage medium on which a computer program is stored, which, when executed, implements a sharded blockchain consensus method in the Internet of Things as described above.

[0043] Compared with the prior art, the technical advantages of the present invention are mainly as follows:

[0044] Advantage 1: This patent uses the network interconnection principle for network sharding (based on the communication latency between nodes, low-latency nodes are divided into the same shard), ensuring good network communication between nodes within a shard, which is superior to other random averaging methods.

[0045] Secondly, in the consensus process of this patent, all nodes synchronize the same block at the end, achieving globally consistent single blockchain data maintenance. This results in low latency performance in the IoT field, where data read operation latency is sensitive, because the data is closer to the user. Other patents with multiple sub-chains suffer from high latency in cross-shard read / write operations and low system fault tolerance.

[0046] Thirdly, this patent adopts a staggered serial consensus process, which ensures that multiple block submissions are very close in time, while other methods are synchronous and blocking, that is, they need to wait for all nodes to complete all operations in one round of consensus before the next consensus can begin.

[0047] Fourthly, this patent employs an improved Raft consensus method. It refines the existing Raft consensus method, where the master node within the consensus group primarily coordinates block submissions and does not need to receive and process all transactions, reducing message complexity for the master node and improving system performance. Other patents use PBFT, which has high communication complexity, hindering system scalability, and centralizing message load. Attached Figure Description

[0048] Figure 1 This is a schematic diagram of the blockchain system node network topology provided in an embodiment of the present invention;

[0049] Figure 2 This is a schematic diagram of a node module in the Internet of Things provided in an embodiment of the present invention;

[0050] Figure 3 This is a schematic diagram of node role transformation in the Internet of Things provided by an embodiment of the present invention;

[0051] Figure 4 This is a schematic diagram of a sharding-based blockchain consensus method in the Internet of Things provided by an embodiment of the present invention;

[0052] Figure 5 This is a schematic diagram of the coordinator committee consensus process provided in an embodiment of the present invention;

[0053] Figure 6 This is a schematic diagram of the on-chip consensus process provided in an embodiment of the present invention.

[0054] Figure 7 This is a schematic diagram of the basic process of the system according to an embodiment of the present invention. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be described below with reference to the accompanying drawings. Obviously, the one or more embodiments described are only a part of the embodiments described in this specification, used to illustrate and explain the invention, and are not intended to limit the invention.

[0056] This invention distributes transaction load across different shards through network sharding. Each shard processes only transactions or affairs related to its own shard, reducing the bottlenecks and risks associated with traditional distributed consensus protocols that concentrate transaction load on a single master node. Simultaneously, it improves system scalability; as the number of participants increases, the system's ability to process transactions does not significantly decrease as in traditional distributed consensus protocols. Furthermore, considering the workload of each node, block creation rights are allocated based on the number and status ranking of cached transactions in the node's message receiving module, while ensuring fair competition. This consensus method reduces node resource consumption, maintains consistent single blockchain data, and improves the response speed of data read operations to support latency-sensitive applications.

[0057] Furthermore, the blockchain system is divided into multiple shards through network sharding, with each shard handling data requests from IoT terminals within its own shard.

[0058] Furthermore, through a two-layer consensus protocol, multiple shards are coordinated to submit new blocks in turn to maintain consistent blockchain data; during message exchange, the timeout period for nodes to wait for messages is matched according to the actual project and needs.

[0059] Furthermore, node activity levels are matched to actual projects and needs, implemented by the number and status of data requests from different types of IoT terminals cached by the nodes.

[0060] In this embodiment, the blockchain system consists of multiple IoT hosts distributed across different areas of the IoT system. Each IoT host receives data requests from nearby IoT terminals. Hosts adjacent to each other on the network are grouped into a shard, and data requests from IoT terminals are processed within that shard. Each shard maintains a unique master node through an intra-shard consensus algorithm, and these master nodes form a coordinator committee. The coordinator committee allocates block-producing rights to multiple shards in turn based on their data priority and workload. Shards with block-producing rights continuously submit multiple new blocks, and all nodes maintain a consistent blockchain. By distributing IoT terminal data requests to corresponding shards through network sharding, the high load risk and bottleneck problems associated with master nodes handling all requests in traditional distributed protocols are avoided; simultaneously, the system's scalability is improved, adapting to more application scenarios. Reasonably and quickly allocating block-producing rights according to the data priority and workload of different shards can reduce the submission delay of important data. Furthermore, maintaining consistent blockchain data across all nodes provides a simple and unified data view while avoiding the impact of frequent cross-shard data read operations on latency-sensitive application scenarios.

[0061] This invention provides a blockchain-based data storage system in the Internet of Things (IoT), such as... Figure 1As shown, in an IoT system, multiple data acquisition terminals (e.g., IoT sensors) in the same area connect to the same gateway or IoT host via network devices. These gateways or IoT hosts then interconnect via the internet. These gateways or IoT hosts form a sharded blockchain data storage system within the IoT. This system consists of n peer nodes (gateways or IoT hosts) N1, N2, ..., N n Composed of, denoted as set N n ={N1,N2,…,N n A fragment is formed by multiple nodes connected to the same network device. Let the system be divided into m fragments Z1, Z2, ..., Zn. m Let Z be the set. m ={Z1,Z2,…,Z m Each shard contains an odd number of nodes. The number of nodes in different shards can vary depending on the application scenario, but must be at least three. For example... Figure 1 The data is divided into shard 1, shard 2, shard 3, shard 4...

[0062] Each node receives data requests uploaded by IoT terminals connected to it. These requests are temporarily stored in the node's transaction pool in the form of transactions. Nodes perform different identity transformations according to the protocol (identity as intra-chip slave node, intra-chip master node, global master node, anchor node, or global coordinating node), listen for messages sent by other nodes, and process different messages according to the protocol to jointly maintain the blockchain-based IoT data storage system.

[0063] After initialization, a node defaults to being a slave node within the same slice, waiting for messages to be sent by other nodes.

[0064] Within the same shard, slave nodes maintain a unique master node through the shard consensus protocol. The master node maintains its role by periodically sending heartbeats to other slave nodes, preventing other slave nodes from initiating a new election due to heartbeat timeouts. Simultaneously, when a slave node receives a heartbeat reply, it receives a confirmation message from the master node, which includes the number and status of cached messages in the node's message receiving module. The master node continuously updates the ranking of slave nodes in the state management module.

[0065] All shard master nodes form a coordinator committee. The committee maintains a single global master node through an internal consensus protocol. The global master node maintains its role in the coordinator committee by periodically sending heartbeats to other members of the committee, preventing other shard master nodes from initiating a new election due to heartbeat timeouts. The global master node is assigned to members of the coordinator committee in order of their busyness level.

[0066] The global coordination node allocates block production rights in order of the ranking of intra-slice slave nodes in its state management module. The intra-slice slave nodes that obtain block production rights pre-submit new blocks.

[0067] Once all new blocks have been pre-committed during the term of the global coordinating node, the global coordinating node sends a pre-commit completion message to the next global coordinating node and begins the work of the next global coordinating node.

[0068] Once the pre-commit of a new block is completed during the term of the global coordinating node, the formal commit of the new block begins. The formal commit process includes the global coordinating node synchronizing the new block data with other nodes in this shard and sending a formal commit message to the anchor node.

[0069] Furthermore, in one embodiment, as Figure 2 As shown, each node includes the following modules:

[0070] The state management module 201 manages node state data to maintain system functionality. This includes the local node address (composed of shard ID and intra-shard node ID), addresses of other nodes within the shard, anchor node address, addresses of other intra-shard master nodes, intra-shard Term number, global Term number, global coordination Term number, node role flag, stage flag, intra-shard master node candidates, global master node candidates, the node's highest known block hash and height, and intra-shard slave node ranking. The Term represents the number of each consensus process round, monotonically increasing, defined in time units.

[0071] The Role Management Module 202 manages the roles of nodes within the system and the transitions between different roles. There are five roles for nodes in the system: intra-shard slave node, intra-shard master node, global master node, anchor node, and global coordinator node. The intra-shard slave node is the initial role for each node, responsible for receiving data requests from IoT terminals and responding to messages from other nodes according to the protocol. Each shard elects one intra-shard master node (elected jointly by all nodes within each shard, using a method similar to Raft master election). This node periodically sends heartbeats to other members of the same shard to maintain its role and competes with other intra-shard master nodes for the global coordinator node position. Compared to intra-shard slave nodes, anchor nodes need to store complete blockchain data and participate in the block production process according to the protocol (anchor nodes do not have the other functions of intra-shard slave nodes; they only maintain complete blockchain data and do not participate in shard election voting, but they provide historical block data so that the newly elected intra-shard master node is aware of the latest block information). This is because when an intra-shard master node experiences network isolation or failure, the newly elected intra-shard master node needs to know the information related to the last block produced by the previous intra-shard master node. The global coordinating node is rotated among all the master nodes within the shard, with the order determined by the real-time busy status of the master nodes. Nodes that have already won do not participate in the next round of competition. The global coordinating node is responsible for coordinating the other members of its shard to produce blocks in turn. The term of office for the global coordinating node is determined by the number of blocks produced, and is matched according to the specific implementation. The global master node is elected by a coordinator committee composed of all the master nodes within the shard. This node periodically sends heartbeats to other members of the coordinator committee to maintain its role and leads the election of the global coordinating node. The role transition relationships are as follows: Figure 3 As shown.

[0072] The message receiving module 203 is used to verify and cache pending requests from IoT terminals, and to verify and transmit messages between nodes to the message processing module. Since nodes take turns producing blocks according to the protocol, pending requests from IoT terminals need to be cached in the message receiving module first. At the time point that conforms to the protocol, the node packages the cached requests to generate a new block.

[0073] The message processing module 204 is used to process inter-node messages transmitted from the message receiving module. Nodes process and respond to the corresponding messages according to the protocol.

[0074] The message sending module 205 is used to send messages to be sent from the message processing module, as well as periodic heartbeat information from the master node within the chip. Since the system has multiple shards, different messages have different reception ranges, and messages are sent to different node groups based on different message types and node status data.

[0075] The data management module 206 is used to manage block status. Blocks are divided into pre-commit and committed states. New blocks initially received by a node are in the pre-commit state, and they transition to the committed state after receiving a block commit message. The data management module also provides a query function for committed block data.

[0076] See Figure 7 This invention also provides a sharding-based blockchain consensus method in the Internet of Things, which includes the following steps:

[0077] Step 1: After system initialization, nodes in the blockchain system start up according to the initial configuration of the node status module;

[0078] Step 2: Divide the blockchain system into multiple shards through network sharding. Within each shard, maintain a unique master node through an intra-shard consensus protocol, while other nodes are intra-shard slave nodes.

[0079] Step 3: All master nodes within the slice form a coordinator committee and elect a single global master node within the committee.

[0080] Step 4: The global master node assigns the master node within each shard to serve as the global coordinating node according to the busyness of each shard.

[0081] Step 5: The global coordination node coordinates with other slave nodes within the same shard to pre-submit one or more blocks in sequence according to their busyness level;

[0082] Step Six: After completing the block pre-commit, the global coordinating node triggers the election of the next global coordinating node (as stated in Step Four). Simultaneously, the formal block commit begins, and upon completion, the IoT terminal is notified of the completion request.

[0083] In this embodiment, the system is divided into m fragments Z using the network fragmentation method described above. m ={Z1,Z2,…,Z m The sharding uses the Raft consensus protocol to maintain a unique master node within each shard. Unlike traditional Raft methods, this invention proposes that when a master node sends a heartbeat to other slave nodes, the slave nodes must reply with acknowledgment information. This acknowledgment information includes the number and status of messages cached in the slave node's message receiving module. After receiving the acknowledgment message, the master node updates the slave node ranking in its status management module.

[0084] All master nodes within a shard maintain a coordinator committee, which elects a global coordinator to begin generating and committing new blocks. Unlike the traditional Raft method, this invention proposes that master nodes within a shard do not have block-producing rights when they are not serving as the global coordinator; that is, they cannot process IoT terminal requests received by other nodes in their shard. Requests can be collected and temporarily stored in memory, and processed immediately upon gaining block-producing rights.

[0085] The coordinator committee consists of m shards and their respective master nodes L. m ={L1,L2,…,L m The system consists of a coordinator committee that uses the Raft consensus protocol to maintain a single global master node within the committee. Unlike traditional Raft methods, this invention proposes that the global master node does not accept pending transactions forwarded by other nodes, and periodically elects a global coordinator node. To reduce communication overhead, the global master node randomly selects two coordinator committee members and compares their busy levels; the member with the higher busy level is elected as the global coordinator node. The elected global coordinator node begins coordinating block production for its assigned shard and notifies the global master node to conduct the next round of global coordinator node election. This process is repeated, and the system continuously generates global coordinators for block production.

[0086] Furthermore, once a master node within a shard is appointed as the global coordinator, it waits for the previous global coordinator to send a pre-commit completion message. Upon receiving this message, the master node allocates pre-commit blocks to its slave nodes sequentially based on their ranking within the shard. At any given time, only one slave node is pre-committing a new block. The term of the master node as the global coordinator ends after all new blocks have been fully committed. The length of the term is positively correlated with the number of new blocks; the more new blocks, the longer the term, and the longer the waiting time for other shards. Therefore, the number of new blocks during the global coordinator's term is matched to the application instance.

[0087] Furthermore, when a slave node within a slice pre-commits a new block, it broadcasts the new block hash to other slave nodes within the slice, and simultaneously broadcasts the complete new block data to all anchor nodes. If the master node within the slice receives confirmation messages from more than half of the other slave nodes within the slice or more than half of the anchor nodes, then the pre-commit for that round is complete, and the block-producing right is allocated to the next slave node within the slice. This pre-commit process is repeated until the last block pre-commit of the current global coordinator node's term is completed. Then, the current global coordinator node triggers the next global coordinator node to begin pre-committing a new block, with the trigger message containing the hash of the last pre-committed block.

[0088] Furthermore, after the global coordinating node completes the pre-commit of all new blocks, it begins the formal submission of new blocks. In one embodiment, the intra-chip master node and anchor nodes are located on the same IoT host (after the intra-chip master node is elected, it can delegate itself as the anchor node). The intra-chip master node synchronizes complete new blocks to the intra-chip slave nodes that do not yet have complete new blocks, and simultaneously sends block submission messages to all anchor nodes. The intra-chip master node completes the formal submission of the new block and replies to the IoT terminal requesting completion after receiving confirmation messages from more than half of the intra-chip slave nodes or more than half of the anchor nodes.

[0089] It's important to note that if a block is committed without confirmation messages from any of the slave nodes or more than half of the anchor nodes, and assuming all the nodes that completed the commit are down, all other nodes that haven't committed will fail. Downed nodes include the master node, leading to the creation of a new master node. When the new master node consults half of the slave nodes or anchor nodes, the latest block information it retrieves may not include the recently committed blocks from the downed machines, resulting in data loss.

[0090] like Figure 3 The diagram shown is a schematic representation of node role transformation in an embodiment of this specification. The role transformation process is as follows:

[0091] Node set N n ={N1,N2,…,N n There are five node roles in the}: intra-slice slave node, intra-slice master node, global master node, anchor node, and global coordinator node. The node role conversion process is illustrated below;

[0092] Step 301: After node initialization, it defaults to the role of an intra-slice slave node;

[0093] Step 302: Within the same shard, any slave node that receives more than half of the votes in a single election round can be promoted to the shard master node. Each slave node can only vote for one slave node in a single election round.

[0094] If a node within a segment does not receive enough votes, it retains its role as a node within the segment.

[0095] Step 303: In the election process of the intra-chip slave nodes in step 302, an anchor node also needs to be selected. In specific implementations, additional anchor nodes can be set according to different scenarios. In one embodiment, to reduce election complexity, the intra-chip master node and the anchor node are the same IoT host. Once the intra-chip master node is generated, it automatically assumes the role of the anchor node.

[0096] Step 304: The coordinator committee, composed of master nodes within the block, periodically assigns a global coordinator node within the committee to undertake the work of submitting new blocks;

[0097] Step 305: After the global coordinating node completes the new block submission, it becomes the intra-segment master node to continue maintaining the coordinator committee.

[0098] Step 306: A coordinator committee composed of intra-shard master nodes elects a global master node through a round of elections. This global master node then coordinates and assigns committee members to serve as global coordinators in turn. This achieves cyclical block production.

[0099] The role-switching method in this embodiment of the invention enables different IoT hosts to assume corresponding roles according to the protocol, and achieves high transaction processing capabilities of the system through intra-chip and global message interaction. Different roles reach consensus through a consensus method, the specific process of which is as follows: Figure 4 As shown.

[0100] like Figure 4 The diagram shown is a schematic representation of a sharding-based blockchain consensus method in an embodiment of this specification. The consensus method may include the following steps:

[0101] Step 401: Node set N n ={N1,N2,…,N n Each node in the node initializes according to the initial configuration of the node state module.

[0102] Step 402: The system is divided into m fragments Z using the network fragmentation method described above. m ={Z1,Z2,…,Z m Within the same shard, slave nodes form a consensus group, which elects a unique master node within the shard through an election process.

[0103] Within a shard, the Raft consensus protocol is used to elect and maintain a unique master node. The master node maintains its role by periodically sending heartbeats to other slave nodes, preventing them from initiating new elections due to heartbeat timeouts. Simultaneously, the master node queries the anchor node for the existence of blocks in a pre-commit state related to its shard; that is, newly elected master nodes check the blockchain's state. In one embodiment, this timeout period is 10 times the heartbeat cycle, which is configured based on network conditions. Furthermore, slave nodes receiving heartbeats must reply with a confirmation message to the master node, containing the number and status of cached messages in the node's message receiving module. The master node continuously updates the slave node ranking in the state management module.

[0104] Step 403: The m intra-slice master nodes form a coordinator committee and elect a unique global master node through an election process;

[0105] Similar to the election of intra-slice master nodes in step 402, a unique global master node is elected using the Raft consensus protocol. The global master node maintains its role in the coordinator committee by periodically sending heartbeats to other committee members, preventing other intra-slice master nodes from initiating new elections due to heartbeat timeouts. In one embodiment, this timeout period is 10 times the heartbeat cycle, which is configured based on network conditions. Because message transmission between intra-slice master nodes spans multiple network devices, the global master node heartbeat cycle in step 403 is longer than the intra-slice master node heartbeat cycle in step 402. Furthermore, similar to Raft, intra-slice master nodes in the coordinator committee do not need to reply to the global master node's heartbeat messages.

[0106] Step 404: The global master node elects members from the coordinator committee to serve as the global coordinator node;

[0107] To reduce communication overhead, the global master node randomly selects two fragment master nodes from the committee for election. The fragment master node with higher activity level wins the election and becomes the global coordinating node, coordinating the submission of new blocks within its fragment and triggering the next round of global coordinating node election. Nodes selected in the previous round do not participate in the next round of election.

[0108] Step 405: The global coordinating node allocates block production rights according to the ranking of intra-slice slave nodes in its state management module, and the intra-slice slave nodes that obtain block production rights pre-submit new blocks;

[0109] Once all new blocks have been pre-committed during the term of the global coordinating node, the global coordinating node sends a pre-commit completion message to the next global coordinating node and begins the work of the next global coordinating node.

[0110] Step 406: After the pre-commit of a new block is completed during the global coordinating node's term, the formal commit of the new block begins. The global coordinating node synchronizes the new block data with other nodes in its shard and sends a formal commit message to the anchor node, as the anchor node needs to constantly synchronize the latest block data.

[0111] In this embodiment of the invention, the coordinator committee assigns its members to serve as global coordinator nodes sequentially through the global master node. For example... Figure 5 As shown. Each global coordinating node is elected in step 501, and then steps 502 (block pre-commit) and 503 (block commit) are implemented. These three steps constitute a complete term.

[0112] Unlike a completely sequential process, in this embodiment of the invention, the complete process for each term is staggered and parallel. After step 501 of the previous term ends, step 501 of the next term begins. Step 502 of the next term must wait for step 502 of the previous term to end. The block submission processes (steps 502 and 503) of different terms are highly coherent operations, reducing node synchronization blocking caused by a completely sequential process and minimizing waiting time between block submissions.

[0113] In this embodiment of the invention, the global coordination node allocates intra-slice slave nodes to perform block pre-commit sequentially according to the intra-slice slave node ranking in its state management module. The specific process is as follows: Figure 6 As shown.

[0114] Step 601: The global coordinating node selects an intra-slice slave node to pre-commit a new block based on the intra-slice slave node ranking in its state management module. The global coordinating node then sends a start block production message to the target intra-slice slave node. For example, the intra-slice master node of slice 1 acts as the current global coordinating node and selects an intra-slice slave node in slice 1 to pre-commit a new block.

[0115] Step 602: After receiving the start-of-block message from the global coordinating node in Step 601, the target intra-slice slave node packages the pending transactions from the cache of its message receiving module to generate a new block, and pre-commits the new block locally. Then, it sends the hash of the new block to other intra-slice slave nodes;

[0116] Step 603: The intra-segment slave node that pre-committed the new block in step 602 must also send the completed new block data to all anchor nodes and the intra-segment master node of the segment where that node resides, for example... Figure 6 Mid-segment 2-anchor node, segment 3-anchor node, etc.;

[0117] Step 604: The intra-slice slave nodes that received the new block hash and the anchor nodes that received the complete block data reply with confirmation messages to the global coordinating node described in step 601. After the global coordinating node receives half of the confirmation messages from the anchor nodes, the block pre-commit is completed. Since the global coordinating node pre-commits multiple new blocks in batches during its term, step 601 continues until the upper limit of the number of pre-committed blocks during its term is reached, and then proceeds to step 605;

[0118] Step 605: The global coordinating node sends a batch formal block commit message to all anchor nodes. The intra-slice slave nodes that only obtained the pre-committed block hash in step 602 synchronize with the global coordinating node through step 606.

[0119] Step 606: In step 606, the intra-slice slave node completes block data synchronization and commits. The data synchronization operation in step 605 refers to compressing and packaging the complete data of the pre-committed blocks during the term and synchronizing it to the intra-slice slave node that only obtained the hash of the pre-committed blocks in step 602;

[0120] Initially, only the hash is transmitted to reduce the sender's load and bandwidth consumption, and to shorten transmission time. The complete data is then synchronized later, and by the time synchronization begins, the next round has already started.

[0121] Step 607: The anchor node that received the batch formal commit message in Step 605 will commit the pre-committed block and reply with a confirmation message to the global coordinator node. The intra-slice slave nodes that completed block data synchronization and committed in Step 606 reply with a confirmation message to the global coordinator node. The global coordinator node completes the block commit when it receives confirmation messages from half of the intra-slice slave nodes or half of the anchor nodes.

[0122] The working principle of the above technical solution is as follows: Blockchain provides data traceability and tamper-proofing for the Internet of Things (IoT). Based on the sharding-based blockchain consensus method, load balancing is achieved, reducing the load pressure on the master node in traditional distributed consensus methods and improving system scalability.

[0123] In specific implementation, the method proposed in the technical solution of this invention can be automatically executed by those skilled in the art using computer software technology. System devices for implementing the method, such as computer-readable storage media storing the corresponding computer program of the technical solution of this invention and computer equipment including the computer program running the corresponding computer program, should also be within the protection scope of this invention.

[0124] In some possible embodiments, a sharded blockchain consensus system for the Internet of Things (IoT) is provided, including a processor and a memory. The memory is used to store program instructions, and the processor is used to call the stored instructions in the memory to execute a sharded blockchain consensus method for the IoT as described above.

[0125] In some possible embodiments, a sharded blockchain consensus system for the Internet of Things (IoT) is provided, including a readable storage medium on which a computer program is stored, which, when executed, implements a sharded blockchain consensus method for the IoT as described above.

[0126] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. The present invention is not limited to the above embodiments; the embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A sharding-based blockchain consensus method for the Internet of Things, characterized in that: Network sharding distributes transaction load across different shards, with each shard handling only transactions or events relevant to its own shard. Considering the workload of each node, and ensuring fair competition, block creation rights are allocated based on the number and status of cached transactions in the node's message receiving module. All master nodes within a shard form a coordinator committee, which elects and maintains a single global master node within the committee. The global master node is assigned to a master node within a shard according to the busyness of each shard. The global coordinator coordinates other slave nodes within the same shard to pre-submit one or more blocks according to their busyness. Each global coordinating node is elected in the first step of the global coordinating node election, and then the second step of block pre-commit and the third step of block commit are implemented. The three steps constitute a complete term. Unlike a completely sequential process, the complete process of each term is staggered and parallel; after the first step of the previous term is completed, the first step of the next term is triggered; the second step of the next term must wait for the second step of the previous term to be completed; the second and third steps of the block submission process in different terms are consecutive operations, reducing node synchronization blocking caused by a completely sequential term and reducing the waiting time between block submission processes. The intra-shard slave node that pre-commits a new block must also send the completed new block data to all anchor nodes and the intra-shard master node of the shard to which the node belongs. Compared with the intra-shard slave node, the anchor node needs to store the complete blockchain data and participate in the block production process according to the protocol. The anchor node does not have the other functions of the intra-shard slave node, maintains the complete blockchain data, does not participate in shard election voting, but will provide block history data so that the new intra-shard master node knows the latest block information.

2. The blockchain consensus method based on sharding in the Internet of Things as described in claim 1, characterized in that: Includes the following steps, Step 1: After system initialization, nodes in the blockchain system start up according to the initial configuration of the node status module; Step 2: Divide the blockchain system into multiple shards through network sharding. Within each shard, maintain a unique master node through an intra-shard consensus protocol, while other nodes are intra-shard slave nodes. Step 3: All master nodes within the slice form a coordinator committee and elect a single global master node within the committee. Step 4: The global master node assigns the master node within each shard to serve as the global coordinating node according to the busyness of each shard. Step 5: The global coordination node coordinates with other slave nodes within the same shard to pre-submit one or more blocks in sequence according to their busyness level; Step six: After completing the block pre-commit, the global coordinating node triggers the election of the next global coordinating node in step four; at the same time, the formal block submission begins, and after the block submission is completed, the IoT terminal is notified to complete the request.

3. The blockchain consensus method based on sharding in the Internet of Things as described in claim 1, characterized in that: In a blockchain system, nodes have five different roles: intra-segment slave node, intra-segment master node, global master node, anchor node, and global coordinator node. After initialization, a node defaults to being a slave node within the same slice, waiting for messages to be sent by other nodes. Within the same shard, slave nodes maintain a unique master node through the shard consensus protocol. The master node maintains its role by periodically sending heartbeats to other slave nodes, preventing other slave nodes from initiating a new election due to heartbeat timeouts. Simultaneously, when a slave node receives a heartbeat reply, it receives a confirmation message from the master node, which includes the number and status of cached messages in the node's message receiving module. The master node continuously updates the ranking of slave nodes in the state management module. All shard master nodes form a coordinator committee. The committee maintains a single global master node through an internal consensus protocol. The global master node maintains its role in the coordinator committee by periodically sending heartbeats to other members of the committee, preventing other shard master nodes from initiating a new election due to heartbeat timeouts. The global master node is assigned to members of the coordinator committee in order of their busyness level. The global coordination node allocates block production rights in order of the ranking of intra-slice slave nodes in its state management module. The intra-slice slave nodes that obtain block production rights pre-submit new blocks. Once all new blocks have been pre-committed during the term of the global coordinating node, the global coordinating node sends a pre-commit completion message to the next global coordinating node and begins the work of the next global coordinating node. Once the pre-commit of a new block is completed during the term of the global coordinating node, the formal commit of the new block begins. The formal commit process includes the global coordinating node synchronizing the new block data with other nodes in this shard and sending a formal commit message to the anchor node.

4. The blockchain consensus method based on sharding in the Internet of Things as described in claim 1, characterized in that: A node in a blockchain system includes the following modules: The status management module is used to manage the status data of nodes in order to maintain system functionality; The role management module is used to manage the roles that nodes play in the system and the transitions between different roles, thereby enabling protocol functions and providing external services; The message receiving module is used to verify and cache pending requests from IoT terminals, and to verify and transmit messages between nodes to the message processing module. The message processing module is used by nodes to process inter-node messages transmitted from the message receiving module according to the protocol. The message sending module is used to send messages to be sent from the message processing module, as well as the periodic heartbeat information of the master node within the chip; The data management module is used to manage blockchain data and provide read and write services to external parties.

5. A sharding-based blockchain consensus method in the Internet of Things according to claim 1, 2, or 3, characterized in that: The blockchain system is divided into multiple shards through network sharding, and each shard processes data requests from IoT terminals within its own shard.

6. A sharding-based blockchain consensus method in the Internet of Things according to claim 1, 2, or 3, characterized in that: Through a two-layer consensus protocol, multiple shards are coordinated to submit new blocks in turn to maintain consistent blockchain data; during message exchange, the timeout period for nodes to wait for messages is matched according to the actual project and needs.

7. A sharding-based blockchain consensus method in the Internet of Things according to claim 1, 2, or 3, characterized in that: The node workload is matched according to the actual project and needs, and is implemented by the number and status of data requests from different types of IoT terminals cached by the node.

8. A sharded blockchain consensus system for the Internet of Things, characterized in that: It includes a processor and a memory, the memory being used to store program instructions, and the processor being used to invoke the stored instructions in the memory to execute a sharded blockchain consensus method in the Internet of Things as described in any one of claims 1-7.

9. The sharding-based blockchain consensus system in the Internet of Things according to claim 8, characterized in that: It includes a readable storage medium on which a computer program is stored, and when the computer program is executed, it implements a sharding-based blockchain consensus method in the Internet of Things as described in any one of claims 1-7.

Images