A Tendermint-based hierarchical sharding consensus method for blockchain

Abstract

This invention provides a Tendermint-based layered sharding consensus method for blockchain, relating to the field of blockchain system technology. The invention first establishes a layered sharding structure for the Tendermint blockchain network, then divides the Tendermint blockchain network into several epochs. Nodes in the Tendermint blockchain network are added to shards, and the roles of nodes within each shard are defined. Different shards generate non-consensus blocks. Then, layered sharding consensus is achieved through a layered sharding consensus algorithm: specifically, intra-shard consensus is performed first; after intra-shard processing is completed, cross-shard consensus is performed. Layered sharding of nodes in the blockchain network is implemented within the underlying framework of the Tendermint system, and a corresponding layered sharding consensus technology is designed, achieving efficient cross-sharding while ensuring the consistency of data across multiple related shards during data updates, and guaranteeing the atomicity of transaction processing.

Description

Technical Field

[0001] This invention relates to the field of blockchain system technology, and in particular to a blockchain layered sharding consensus method based on Tendermint. Background Technology

[0002] The Tendermint blockchain network is a distributed ledger platform based on a consensus algorithm, designed to provide secure, scalable, and high-performance blockchain solutions.

[0003] This blockchain system employs a mechanism called the Practical Byzantine Fault-Tolerant Consensus Protocol, an algorithm that enables consensus among nodes even if some nodes malfunction or engage in malicious behavior. This ensures that transactions and state transitions in the Tendermint blockchain network are correctly verified and confirmed. Furthermore, this consensus algorithm features high throughput and fast confirmation, capable of handling large volumes of transactions and achieving near real-time finality.

[0004] This blockchain system manages and maintains the network using a set of validators. These validators are responsible for proposing and confirming blocks, ensuring that all nodes reach consensus during the consensus process. Within the system, applications run independently, interacting with the Tendermint core engine through the ABCI (Application Blockchain Interface).

[0005] Tendermint also provides a secure P2P network layer for communication and data transmission between nodes. This network layer supports encrypted connections and mechanisms to prevent Byzantine faults, ensuring the confidentiality and integrity of data.

[0006] Overall, the Tendermint blockchain network system, with its powerful consensus algorithm, high-performance transaction processing capabilities, and flexible application programming interface (API), provides developers and enterprises with a solution for building secure and scalable distributed applications. It has broad application prospects in fields such as finance, supply chain, and digital assets.

[0007] Traditional blockchain networks, such as early blockchains like Bitcoin and Ethereum, require each node to store complete blockchain data and verify all transactions. Full node consensus means that every full node in the network participates in the generation and confirmation of new blocks according to the same consensus rules. This model also introduces scalability bottlenecks because each node must process all transactions on the network, limiting the blockchain's transaction processing capacity. This results in low transaction throughput (TPS) and long confirmation times, restricting the large-scale application of blockchain technology.

[0008] Blockchain sharding technology borrows the concept of traditional database sharding, dividing the blockchain network into multiple shards for parallel processing. Each shard is responsible for processing its own portion of transactions and states, thereby achieving parallel processing and improving overall processing capacity. Existing blockchain sharding technologies can be divided into three types: network sharding, transaction sharding, and state sharding.

[0009] Network sharding divides the nodes of a blockchain network into different shards. Each shard acts as a relatively independent processing unit, capable of processing transactions in the network in parallel. This sharding method increases the network's parallel processing capability, thereby improving transaction processing speed. Network sharding primarily involves the allocation of nodes, i.e., determining which nodes belong to which shard. Random algorithms are typically used to ensure the fairness and security of shard distribution.

[0010] Transaction sharding refers to distributing transactions across different shards for processing. Each shard is responsible for verifying and recording the transactions within its own shard. This allows multiple transactions to be processed simultaneously, reducing the burden on individual nodes or shards and improving system throughput. The key to transaction sharding lies in ensuring correct transaction routing and the ability to handle cross-shard transactions—that is, how to effectively and efficiently coordinate the interactions between shards when a transaction affects the state of multiple shards.

[0011] State sharding is the most complex and thorough form of sharding. It not only shards the transaction processing process but also the entire blockchain state (i.e., the balances of all accounts, the state of smart contracts, etc.). This means that each shard maintains its own unique state information, significantly reducing the amount of data that a single node needs to store and improving system scalability. The challenge of state sharding lies in handling cross-shard state access and updates, ensuring data consistency and integrity, and designing efficient cross-shard communication protocols.

[0012] To maximize the performance and scalability of blockchains, most existing blockchain sharding methods employ state sharding. This reduces data storage, as consensus messages only need to be propagated within each shard, alleviating network transmission pressure. Simultaneously, by processing transactions on different shards in parallel, state sharding can significantly improve transaction processing speed and network throughput.

[0013] However, in practical applications, most transactions involve multiple shards and must be executed synchronously across multiple shards using a cross-shard consensus protocol. Common approaches include cross-shard locks and two-phase commit. These approaches require multiple rounds of consensus, and the relevant data becomes unavailable before the transaction is committed, resulting in low throughput and high latency in the blockchain system. Therefore, efficiently resolving cross-shard transactions has become a key focus.

[0014] Existing sharding technology can increase system scalability and improve system throughput. Each shard does not share data and processes block packaging and transaction execution concurrently. However, in practical applications, most transactions involve multiple shards and must be executed synchronously across multiple shards through cross-shard consensus protocols. Common practices include cross-shard locks and two-phase commit. These practices require multiple rounds of consensus, and the relevant data becomes unavailable before the transaction is committed, resulting in low throughput and high latency in the blockchain system. Summary of the Invention

[0015] To address the shortcomings of existing technologies, this invention provides a blockchain layered sharding consensus method based on the Tendermint blockchain network. This method improves the efficiency of cross-shard transaction processing while ensuring blockchain security, thereby increasing the overall throughput of the blockchain, reducing blockchain latency, achieving efficient cross-sharding, and ensuring the consistency of data across multiple related shards during data updates, thus guaranteeing the atomicity of transaction processing.

[0016] A Tendermint-based blockchain hierarchical sharding consensus method includes the following steps:

[0017] Step 1: Establish a hierarchical sharding structure for the Tendermint blockchain network, where the hierarchical sharding consensus involves shards and their subordinate nodes;

[0018] The fragmentation is divided into lower fragmentation and upper fragmentation. The fragmentation adopts a bipartite graph topology structure. The upper fragmentation is called fragment B and the lower fragmentation is called fragment I. Fragment B has adjacent edges only with fragment I.

[0019] The subordinate nodes are as follows: trusted nodes with a core count greater than a set threshold are added to participate in the B-shard consensus, and the remaining nodes participate in the I-shard consensus; the data stored between I shards do not overlap with each other, and B-shard nodes do not store data separately, but store the data of all the lower-level shards they bridge; all B-shards and I-shards are randomly numbered in decimal.

[0020] Step 2: Divide the Tendermint blockchain network into several epochs;

[0021] Specifically, the entire Tendermint blockchain network is divided into several epochs. After a certain number of consensus rounds, the blockchain enters the next epoch. Each epoch has a unique epoch number. At the beginning of each epoch, a new leader for the Tendermint blockchain network is selected to be responsible for proposing blocks and collecting transactions within the set time.

[0022] For each node, before joining the consensus of an epoch, a new proof-of-work puzzle is randomly generated based on its epoch number, public key, and IP address information. In order to participate in the consensus, a node needs to solve the proof-of-work puzzle generated in that epoch. After successfully solving the puzzle, it obtains a valid identity to participate in the consensus. The difficulty of the proof-of-work puzzle in each epoch is adjusted according to the number of identities in the previous epoch to maintain a stable number of nodes.

[0023] Step 3: Nodes in the Tendermint blockchain network join a shard;

[0024] A performance threshold for blockchain nodes is set in the Tendermint blockchain network. Nodes exceeding this threshold are given priority to join the B shard. Simultaneously, the Tendermint blockchain network allows for arbitrary sharding, designing an arbitrary number of I shard nodes and B shard nodes. The entire Tendermint blockchain network has b B shards and i I shards. Each node identifier is a hexadecimal string calculated using the SHA-256 algorithm.

[0025] First, convert the node identity to a decimal integer, with a value in the range [0, 2]. 256 -1], then perform a modulo operation on the node identity integer to divide the shard into i+b shards. Then, if a node above the performance threshold is assigned to shard I, it will be swapped with a node in shard B, and finally the node sharding is completed.

[0026] Step 4: Assign roles to nodes within a shard;

[0027] The nodes within each shard are divided into two types: leader nodes and validator nodes. The leader node of shard I is responsible for packaging transactions within the shard, while the leader node of shard B is responsible for packaging cross-shard transactions and the data required for cross-shard transactions. The validator nodes of shard B endorse the cross-shard data packaged by the leader nodes.

[0028] In a sharded bipartite graph topology, if several B shards share the same I shard neighbors, these B shards are called second-order nearest neighbor B shards. If a B shard is adjacent to an I shard, it means that the B shard has the responsibility of storing the adjacent I shard data and modifying the adjacent I shard data through cross-shard transactions. Therefore, the blocks submitted by these two shards may have a partial order dependency relationship. If two B shards are second-order nearest neighbors, it indicates that there is overlapping data between them, and they may simultaneously operate on the same data through cross-shard transactions. Therefore, the blocks submitted by these two shards may have an indirect partial order dependency relationship.

[0029] Step 5: Different shards generate blocks without consensus;

[0030] The leader node of shard I directly submits blockchain transactions based on the cross-shard data stored on the shard B chain, without needing to communicate with other shards across shards. If a shard has no transactions to submit in a round, that shard will generate an empty block to participate in cross-shard consensus with neighboring shards.

[0031] The leader node of shard I collects the transactions submitted within its shard in this round and generates a block, which is then broadcast to all relevant shards based on the consensus of the transactions within the shard. Each block in shard I contains a block header and a block body. The block header stores hash pointers linking to the previous blocks in this shard, as well as hash pointers of all adjacent blocks in shard B from the previous round. These hash pointers are ordered lexicographically.

[0032] The leader node of shard B collects the cross-shard transactions submitted in this round and generates a block, which is then broadcast to all relevant shards through the cross-shard commit phase. Since the commit status of cross-shard transactions cannot be deterministically derived from the data state of any shard, the commit status of relevant cross-shard blocks from the previous round is always stored in the blocks of shards I and B to ensure the immutability of the cross-shard transaction execution results. The final block structure is generated; each block structure consists of a block header and a block body. The block body contains a list of all verified transactions, as well as a relation structure `Relation`, which stores the hash values ​​of the previous blocks in other shards associated with the current block, and proof of the success of the transactions submitted in the previous round. Furthermore, a label indicating the shard position is added to the block header, and a relation root `RelationRoot` is introduced, which uses a Merkle hash root generated based on the relation field to represent blocks with a partial order dependency on the current block.

[0033] Step 6: Perform layered sharding consensus using a layered sharding consensus algorithm;

[0034] Step 6.1: Perform consensus within the shard;

[0035] Step 6.1.1: Transaction collection;

[0036] The leader node of shard I collects transactions submitted by users to its shard, and adds valid transactions belonging to its shard and recognized by the user-defined format to the transaction pool. It then broadcasts these transactions to other nodes within the shard using a practical Byzantine fault-tolerant consensus protocol. The leader node of shard B collects cross-shard transactions between adjacent shards I and includes cross-shard data in the block.

[0037] Step 6.1.2: Pre-execution of B-shard transactions;

[0038] The leader node of shard B collects transactions, and other validator nodes verify and approve the cross-shard data provided by the leader node. Then, the blocks and approval results are synchronized through the practical Byzantine fault-tolerant consensus protocol. The pre-execution of cross-shard transactions within shard B is completed by the leader node within the shard. The leader node pre-executes the collected cross-shard transactions into memory based on the data stored locally, and includes the data required to execute cross-shard transactions in the transaction list within the block body of the block.

[0039] Step 6.1.3: Intra-shard transaction consensus;

[0040] In the hierarchical sharding consensus mechanism, each I-shard continuously receives transactions submitted by users and adds valid transactions to the transaction pool. Valid transactions refer to those belonging to this shard and identified through a user-defined format. In each epoch, the I-shard continues to execute the consensus process within the shard. In each round of consensus, the leader node of the I-shard selects a portion of transactions from the transaction pool in chronological order, packages them into blocks within the shard, and completes the consensus within the shard through a practical Byzantine fault-tolerant consensus protocol.

[0041] B-shard validator nodes endorse cross-shard data through a practical Byzantine fault-tolerant consensus protocol: After receiving a proposal message from the leader node, the validator nodes in B-shard also simulate cross-shard transactions and consensus in memory to verify whether the pre-executed cross-shard data is consistent with the data provided in the block.

[0042] Step 6.2: After processing within a shard is complete, perform cross-shard consensus.

[0043] First, based on the hierarchical sharding structure of the blockchain network nodes, the nodes first broadcast the data block to the neighboring shards; after the block broadcast is completed, the lower-level I shard nodes enter the I shard cross-shard receiving phase, while the upper-level B shard nodes enter the B shard cross-shard proposal phase.

[0044] The I-shard cross-shard reception phase specifically involves the following steps: After collecting all blocks generated by adjacent B-shards, the lower-level I-shard node first sorts the collected B-shard blocks according to their corresponding B-shard numbers. Then, it pre-executes these blocks sequentially according to the sorting results and replies to the corresponding B-shards via cross-shard reception messages. After broadcasting the cross-shard reception messages to all adjacent B-shards, the I-shard node executes the cross-shard commit phase.

[0045] The cross-shard proposal phase for B shards specifically involves: B shard nodes waiting for cross-shard receive messages from all adjacent I shards. Whenever more than two-thirds of the nodes in an I shard receive the same cross-shard receive votes, the B shard node aggregates these votes into a cross-shard receive vote set for that I shard. After collecting the cross-shard receive vote sets from all adjacent I shards, the B shard node records them in a cross-shard commit message and sends it to all adjacent I shards, then executes the cross-shard commit phase.

[0046] The cross-shard commit phase specifically includes two types: I-shard cross-shard commit and B-shard cross-shard commit;

[0047] During the cross-shard commit process of the I-shard, all leader nodes and validator nodes within the I-shard will collect the following data:

[0048] (1) Blocks submitted in this round for this shard;

[0049] (2) All adjacent B shards' blocks submitted in this round and the corresponding cross-shard submission messages;

[0050] Once the above conditions are met, the I-shard node executes the block execution phase;

[0051] During the cross-shard commit phase of the B-shard, the B-shard node in the cross-shard commit phase will collect the following data:

[0052] (1) Blocks submitted in this round for this shard and their cross-shard submission messages;

[0053] (2) All adjacent I-shards' blocks submitted in this round;

[0054] (3) All blocks submitted in this round by the B-shard of the second-order nearest neighbors and the corresponding cross-shard submission messages;

[0055] Once the above conditions are met, the B shard node executes the block execution phase;

[0056] The block execution phase is divided into cross-shard block execution and intra-shard block execution;

[0057] During the execution of blocks within the segment, in order to speed up the processing, data blocks from different I-segments are allocated to multiple processors for simultaneous execution;

[0058] During the cross-shard block execution, when two upper-level B shards are second-order adjacent and their respective datasets overlap, the latest data state of the adjacent I shards must be synchronized. The B shard must execute not only its own blocks and those of the adjacent I shards, but also the blocks of all second-order adjacent B shards. The upper-level B shards are executed in a determined order according to the shard decimal number. In order to minimize the transaction termination rate, I shard blocks should be executed after B shard blocks.

[0059] The beneficial effects of adopting the above technical solution are as follows:

[0060] This invention provides a Tendermint-based layered sharding consensus method for blockchain. This method implements layered sharding of nodes in the blockchain network within the Tendermint system framework and designs corresponding layered sharding consensus technology. It achieves efficient cross-sharding while ensuring the consistency of data across multiple related shards during data updates, guaranteeing the atomicity of transaction processing. Compared with existing technologies, the proposed solution utilizes a layered sharding node structure to transform cross-sharding transactions into intra-sharding transactions, accelerating cross-sharding transaction processing, improving the overall blockchain throughput and scalability, and reducing transaction processing latency. The proposed consensus method guarantees the consistency, atomicity, and isolation of blockchain data. Simultaneously, a new block organization structure is designed to ensure the non-repudiation and recoverability of the blockchain. In summary, this invention, while prioritizing security, improves the overall throughput of the blockchain, reduces blockchain latency, and increases blockchain scalability. Attached Figure Description

[0061] Figure 1 This is a diagram of a typical sharding node structure in an embodiment of the present invention.

[0062] Figure 2 This is a diagram of the layered and segmented node structure in an embodiment of the present invention.

[0063] Figure 3 This is a flowchart of the layered and sharded consensus process in an embodiment of the present invention.

[0064] Figure 4 This is a block structure diagram in an embodiment of the present invention. Detailed Implementation

[0065] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0066] A Tendermint-based blockchain hierarchical sharding consensus method is proposed. In this embodiment, the node structure of a normal shard is as follows: Figure 1 As shown, the optimized hierarchical and sharded node structure is as follows: Figure 2 As shown, the lower-level shard is called shard I, responsible for consensus on transactions within that shard. The upper-level shard is called shard B, responsible for handling cross-shard transaction consensus for neighboring shards I. Each shard has a corresponding decimal number. In the diagram, shard B1 is adjacent to shards I1 and I2, and is responsible for handling their cross-shard transactions. Shard B2 is adjacent to shards I2 and I3, and is responsible for handling their cross-shard transactions. The specific steps include:

[0067] Step 1: Establish a hierarchical sharding structure for the Tendermint blockchain network;

[0068] To bridge different shards and achieve low-latency cross-shard transaction submission and execution, this method proposes a hierarchical sharding node structure.

[0069] The hierarchical sharding consensus mechanism involves two types of shards and their subordinate nodes: lower-level shards and upper-level shards. Nodes in the Tendermint blockchain network can arbitrarily join any shard. Lower-level shards conduct intra-shard consensus, responsible for maintaining the transaction history and state of their respective shards, with participating nodes reaching a consensus on the transaction history occurring on that shard. Upper-level shards conduct cross-shard consensus, responsible for maintaining the history and state of cross-shard transactions. The shards adopt a bipartite graph topology, where the upper-level shard is called shard B, and the lower-level shard is called shard I. Shard B is adjacent only to shard I.

[0070] The subordinate nodes are: trusted nodes with a core count greater than a set threshold are added to participate in the B-shard consensus. In this embodiment, trusted nodes with stronger machine hardware capabilities (more cores, stronger core performance) are selected, and the remaining nodes participate in the I-shard consensus. The data stored between I-shards does not overlap. B-shard nodes do not store data separately, but rather store data from all the lower-level shards they bridge. Based on the above design, B-shards have the ability to independently execute cross-shard transactions between all their adjacent I-shards. All B-shards and I-shards are randomly numbered using decimal.

[0071] Step 2: Divide the Tendermint blockchain network into several epochs;

[0072] To ensure the security of the entire Tendermint blockchain network, the entire Tendermint blockchain network is divided into several epochs. After a certain number of consensus rounds, the blockchain enters the next epoch. Each epoch has a unique epoch number. At the beginning of each epoch, a new leader of the Tendermint blockchain network is elected to be responsible for proposing blocks and collecting transactions within the set time.

[0073] For each node, before joining the consensus of an epoch, a new proof-of-work puzzle is randomly generated based on its epoch number, public key, and IP address information. In order to participate in the consensus, a node needs to solve the proof-of-work puzzle generated in that epoch. After successfully solving the puzzle, it obtains a valid identity to participate in the consensus. The difficulty of the proof-of-work puzzle in each epoch is adjusted according to the number of identities in the previous epoch to maintain a stable number of nodes.

[0074] Step 3: Nodes in the Tendermint blockchain network join a shard;

[0075] The Tendermint blockchain network sets a performance threshold for blockchain nodes, which is related to factors such as the node's memory, number of cores, and network environment. Nodes exceeding this threshold are given priority to join the B shard. Simultaneously, the Tendermint blockchain network allows for arbitrary sharding, designing any number of I-shard nodes and B-shard nodes; the entire Tendermint blockchain network has b B-shards and i I-shards; each node's identifier is a hexadecimal string calculated using the SHA-256 algorithm.

[0076] First, convert the node identity to a decimal integer, with a value in the range [0, 2]. 256 -1], then perform a modulo operation on the node identity integer to divide the shard into i+b shards. Then, if a node above the performance threshold is assigned to shard I, it will be swapped with a node in shard B, and finally the node sharding is completed.

[0077] Step 4: Assign roles to nodes within a shard;

[0078] The nodes within each shard are divided into two types: leader nodes and validator nodes. The leader node of shard I is responsible for packaging transactions within the shard, while the leader node of shard B is responsible for packaging cross-shard transactions and the data required for cross-shard transactions. The validator nodes of shard B endorse the cross-shard data packaged by the leader nodes.

[0079] In a sharded bipartite graph topology, if several B shards share the same I shard neighbors, these B shards are called second-order nearest neighbor B shards. If a B shard is adjacent to an I shard, it means that the B shard has the responsibility of storing the adjacent I shard data and modifying the adjacent I shard data through cross-shard transactions. Therefore, the blocks submitted by these two shards may have a partial order dependency relationship. If two B shards are second-order nearest neighbors, it indicates that there is overlapping data between them, and they may simultaneously operate on the same data through cross-shard transactions. Therefore, the blocks submitted by these two shards may have an indirect partial order dependency relationship.

[0080] Step 5: Combine the different shards to generate blocks to form a blockchain;

[0081] The leader node of shard I directly submits blockchain transactions based on the cross-shard data stored on the shard B chain, without needing to communicate with other shards across shards. If a shard has no transactions to submit in a round, that shard will generate an empty block to participate in cross-shard consensus with neighboring shards.

[0082] Each I-shard block contains a block header and a block body. The block header stores hash pointers that link to the blocks in the previous round within this I-shard. It also stores hash pointers of all adjacent B-shard blocks from the previous round. These hash pointers are sorted lexicographically.

[0083] Shard B collects the transactions submitted in this round by its own shard through cross-shard consensus and generates a block. This block is then broadcast to all relevant shards through a cross-shard submission proof phase. Since the submission status of cross-shard transactions cannot be deterministically derived from the data state of any shard, the submission status of relevant cross-shard blocks from the previous round is always stored in the blocks of shards I and B to ensure the immutability of the cross-shard transaction execution results. The final generated block is as follows: Figure 4 The block structure shown is similar to the fragmented structure. Figure 2 In the scenario shown, the blockchain network comprises shards I1, I2, I3, B1, and B2. Each I and B shard generates multiple blocks of height h in each consensus round, with the height incremented by 1 for each subsequent consensus round. Each block consists of a block header and a block body. The block body contains a list of all verified transactions, as well as a relation structure called Relation, which stores the hash values ​​of the previous blocks from other shards associated with the current block, and proofs of successful transactions from the previous round. This mechanism ensures the ordered and consistent execution of operations between shards during block recovery. Furthermore, a label indicating the shard's position is added to the block header, and a relation root (RelationRoot) is introduced. A Merkle hash root is generated based on the relation field to represent blocks with partial order dependencies on the current block. The use of the Merkle hash root guarantees the correctness and immutability of transaction execution.

[0084] Step 6: Perform layered sharding consensus using a layered sharding consensus algorithm. In this embodiment, to meet the requirements of transaction atomicity and isolation for the layered sharding bipartite graph structure of the blockchain node network mentioned above, a layered sharding consensus mechanism is proposed. The layered sharding consensus improves upon the existing Practical Byzantine Fault-Tolerant Consensus Protocol of the Tendermint blockchain network as the intra-sharding consensus step, while also designing a new cross-sharding consensus step.

[0085] Step 6.1: Perform consensus within the shard;

[0086] Step 6.1.1: Transaction collection;

[0087] The leader node of shard I collects transactions submitted by users to its shard, and adds valid transactions belonging to its shard and recognized by the user-defined format to the transaction pool. It then broadcasts these transactions to other nodes within the shard using a practical Byzantine fault-tolerant consensus protocol. The leader node of shard B collects cross-shard transactions between adjacent shards I and includes cross-shard data in the block.

[0088] Step 6.1.2: Pre-execution of B-shard transactions;

[0089] The leader node of shard B collects transactions, and other validator nodes verify and approve the cross-shard data provided by the leader node. Then, the blocks and approval results are synchronized through the practical Byzantine fault-tolerant consensus protocol. The pre-execution of cross-shard transactions within shard B is completed by the leader node within the shard. The leader node pre-executes the collected cross-shard transactions into memory based on the data stored locally, and includes the data required to execute cross-shard transactions in the transaction list within the block body, thereby eliminating an additional round of cross-shard data exchange.

[0090] Step 6.1.3: Intra-shard transaction consensus;

[0091] In the hierarchical sharding consensus mechanism, each I-shard continuously receives transactions submitted by users and adds valid transactions to the transaction pool. Valid transactions refer to those belonging to this shard and identified through a user-defined format. In each epoch, the I-shard continues to execute the consensus process within the shard. In each round of consensus, the leader node of the I-shard selects a portion of transactions from the transaction pool in chronological order, packages them into blocks within the shard, and completes the consensus within the shard through a practical Byzantine fault-tolerant consensus protocol.

[0092] B-shard validator nodes endorse cross-shard data through a practical Byzantine fault-tolerant consensus protocol: After receiving a proposal message from the leader node, the validator nodes in B-shard also simulate cross-shard transactions and consensus in memory to verify whether the pre-executed cross-shard data is consistent with the data provided in the block.

[0093] Step 6.2: After processing within a shard is complete, perform cross-shard consensus; such as... Figure 3 As shown;

[0094] First, based on the hierarchical sharding structure of the blockchain network nodes, nodes first broadcast data blocks to neighboring shards. After the block broadcast is completed, the lower-level I-shard nodes enter the I-shard cross-shard receiving phase, while the upper-level B-shard nodes enter the B-shard cross-shard proposal phase. Specifically, this includes the following steps:

[0095] The I-shard cross-shard reception phase specifically involves the following steps: After collecting all blocks generated by adjacent B-shards, the lower-level I-shard node first sorts the collected B-shard blocks according to their corresponding B-shard numbers. Then, it pre-executes these blocks sequentially according to the sorting results and replies to the corresponding B-shards via cross-shard reception messages. After broadcasting the cross-shard reception messages to all adjacent B-shards, the I-shard node executes the cross-shard commit phase.

[0096] The cross-shard proposal phase for B shards specifically involves: B shard nodes waiting for cross-shard receive messages from all adjacent I shards. Whenever more than two-thirds of the nodes in an I shard receive the same cross-shard receive votes, the B shard node aggregates these votes into a cross-shard receive vote set for that I shard. After collecting the cross-shard receive vote sets from all adjacent I shards, the B shard node records them in a cross-shard commit message and sends it to all adjacent I shards, then executes the cross-shard commit phase.

[0097] The cross-shard commit phase specifically includes two types: I-shard cross-shard commit and B-shard cross-shard commit;

[0098] During the cross-shard commit process of the I-shard, all leader nodes and validator nodes within the I-shard will collect the following data:

[0099] (1) Blocks submitted in this round for this shard;

[0100] (2) All adjacent B shards' blocks submitted in this round and the corresponding cross-shard submission messages;

[0101] Once the above conditions are met, the I-shard node executes the block execution phase;

[0102] During the cross-shard commit phase of the B-shard, the B-shard node in the cross-shard commit phase will collect the following data:

[0103] (1) Blocks submitted in this round for this shard and their cross-shard submission messages;

[0104] (2) All adjacent I-shards' blocks submitted in this round;

[0105] (3) All blocks submitted in this round by the B-shard of the second-order nearest neighbors and the corresponding cross-shard submission messages;

[0106] Once the above conditions are met, the B shard node executes the block execution phase;

[0107] The block execution phase is divided into cross-shard block execution and intra-shard block execution;

[0108] During the execution of blocks within a shard, because there is no data overlap between different lower-level I shards, blocks generated by different I shards can be executed concurrently. To speed up processing, data blocks from different I shards are allocated to multiple processors for simultaneous execution.

[0109] During cross-shard block execution, when two upper-level B shards are second-order adjacent and their respective datasets overlap, the latest data state of the adjacent I shards must be synchronized. A B shard must execute not only its own blocks and those of its adjacent I shards, but also the blocks of all second-order adjacent B shards. To ensure compliance with data consistency, isolation, and atomicity requirements, upper-level B shards execute in a predetermined order based on their shard decimal numbers. To minimize transaction termination rates, I shard blocks should be executed after B shard blocks.

[0110] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A layered sharding consensus method for blockchain based on Tendermint, characterized in that, Includes the following steps: Step 1: Establish a hierarchical sharding structure for the Tendermint blockchain network, where the hierarchical sharding consensus involves shards and their subordinate nodes; Step 2: Divide the Tendermint blockchain network into several epochs; Step 3: Nodes in the Tendermint blockchain network join a shard; Step 4: Assign roles to nodes within a shard; Step 5: Different shards generate blocks without consensus; Step 6: Perform layered sharding consensus using a layered sharding consensus algorithm; Step 6.1: Perform consensus within the shard; Step 6.2: After processing within a shard is complete, perform cross-shard consensus. The partitioning in step 1 is divided into lower-level partitions and upper-level partitions. The partitioning adopts a bipartite graph topology. Let the upper-level partition be called B-parts and the lower-level partition be called I-parts. B-parts only have adjacent edges with I-parts. The subordinate nodes are as follows: trusted nodes with a core count greater than a set threshold are added to participate in the B-shard consensus, and the remaining nodes participate in the I-shard consensus; the data stored between I shards do not overlap with each other, and B-shard nodes do not store data separately, but store the data of all the lower-level shards they bridge; all B-shards and I-shards are randomly numbered in decimal. Step 2 specifically involves dividing the entire Tendermint blockchain network into several epochs. After a certain number of consensus rounds, the blockchain enters the next epoch. Each epoch has a unique epoch number. At the beginning of each epoch, a new leader for the Tendermint blockchain network is selected to be responsible for proposing blocks and collecting transactions within the set timeframe. For each node, before joining the consensus of an epoch, a new proof-of-work puzzle is randomly generated based on its epoch number, public key, and IP address information. In order to participate in the consensus, a node needs to solve the proof-of-work puzzle generated in that epoch. After successfully solving the puzzle, it obtains a valid identity to participate in the consensus. The difficulty of the proof-of-work puzzle in each epoch is adjusted according to the number of identities in the previous epoch to maintain a stable number of nodes. Step 3 specifically involves: setting a performance threshold for blockchain nodes in the Tendermint blockchain network; prioritizing nodes with performance exceeding this threshold for inclusion in the B shard; simultaneously, the Tendermint blockchain network assigns shards based on user preferences, designing an arbitrary number of I shard nodes and B shard nodes; the entire Tendermint blockchain network contains b B shards and i I shards; each node identifier is a hexadecimal string calculated using the SHA-256 algorithm. First, convert the node identity to a decimal integer, with a value in the range [0, 2]. 256 - 1], then perform a modulo operation on the node identity integer to divide the shard into i+b shards. Then, if a node above the performance threshold is assigned to shard I, it will be swapped with a node in shard B, and finally the node sharding is completed. Step 4 specifically involves the following: Nodes within each shard are divided into two types: leader nodes and validator nodes. The leader node of shard I is responsible for packaging transactions within the shard, while the leader node of shard B is responsible for packaging cross-shard transactions and the data required for cross-shard transactions. The validator nodes of shard B endorse the cross-shard data packaged by the leader node; In a partitioned bipartite graph topology, if several B partitions have the same I partition neighbors, these B partitions are called second-order nearest neighbor B partitions. If a B shard is adjacent to an I shard, it means that the B shard has the responsibility of storing the data of the adjacent I shard and can modify the data of the adjacent I shard through cross-shard transactions. Therefore, the blocks submitted by these two shards may have a partial order dependency relationship; if two B shards are second-nearest neighbors, it indicates that there is overlapping data between them, and they may simultaneously operate on the same data through cross-shard transactions. Therefore, the blocks submitted by these two shards may have an indirect partial order dependency relationship. Step 5 specifically involves the I-shard leader node directly submitting blockchain transactions based on the cross-shard data stored on the B-shard chain, without needing to communicate across shards with other I-shards. If a shard has no transactions to commit in a round, that shard will generate an empty block to participate in cross-shard consensus with neighboring shards. The leader node of shard I collects the transactions submitted within its shard in this round and generates a block, which is then broadcast to all relevant shards through consensus on the transactions within the shard. Each I-shard block contains a block header and a block body. The block header stores hash pointers that link to the blocks in the previous round within this I-shard. It also stores hash pointers of all adjacent B-shard blocks from the previous round. These hash pointers are sorted lexicographically. The leader node of shard B collects the cross-shard transactions submitted in this round for its shard and generates a block, which is then broadcast to all relevant shards through the cross-shard submission phase. Since the commit status of cross-shard transactions cannot be deterministically derived from the data state of any shard, the commit status of the relevant cross-shard blocks in the previous round is always stored in the I-shard and B-shard blocks to ensure the immutability of the execution results of cross-shard transactions; and finally, the block structure is generated. Each block structure consists of a block header and a block body; The block body contains a list of all verified transactions, as well as a relation structure called Relation, which stores the hash values ​​of the previous block on other shards associated with the current block, and proof of the success of the transactions committed in the previous round. In addition, a label indicating the shard position is added to the block header, and a relation root RelationRoot is introduced, which uses a Merkle hash root generated based on the relation field to represent blocks that have a partial order dependency relationship with the current block. Step 6.1 specifically includes the following steps: Step 6.1.1: Transaction collection; The leader node of shard I collects transactions submitted by users to its shard, adds valid transactions belonging to its shard and recognized by the user-defined format to the transaction pool, and broadcasts them to other nodes within the shard using a practical Byzantine fault-tolerant consensus protocol. The leader node of shard B collects cross-shard transactions between adjacent shards I and includes cross-shard data in the block. Step 6.1.2: Pre-execution of B-shard transactions; The leader node of shard B collects transactions, and other validator nodes verify and approve the cross-shard data provided by the leader node. Then, the blocks and approval results are synchronized through the practical Byzantine fault-tolerant consensus protocol. The pre-execution of cross-shard transactions within shard B is completed by the leader node within the shard. The leader node pre-executes the collected cross-shard transactions into memory based on the data stored locally, and includes the data required to execute cross-shard transactions in the transaction list within the block body of the block. Step 6.1.3: Intra-shard transaction consensus; In the hierarchical sharding consensus mechanism, each I-shard continuously receives transactions submitted by users and adds valid transactions to the transaction pool. Valid transactions refer to those belonging to this shard and identified through a user-defined format. In each epoch, the I-shard continues to execute the consensus process within the shard. In each round of consensus, the leader node of the I-shard selects a portion of transactions from the transaction pool in chronological order, packages them into blocks within the shard, and completes the consensus within the shard through a practical Byzantine fault-tolerant consensus protocol. B-shard validator nodes endorse cross-shard data through a practical Byzantine fault-tolerant consensus protocol: After receiving a proposal message from the leader node, the validator nodes in B-shard also simulate cross-shard transactions and consensus in memory to verify whether the pre-executed cross-shard data is consistent with the data provided in the block. Step 6.2 specifically includes the following steps: First, based on the hierarchical sharding structure of the blockchain network nodes, the nodes first broadcast the data block to the neighboring shards; after the block broadcast is completed, the lower-level I shard nodes enter the I shard cross-shard receiving stage, while the upper-level B shard nodes enter the B shard cross-shard proposal stage. The I-shard cross-shard reception phase is as follows: After collecting all blocks generated by adjacent B-shards, the lower-level I-shard node first sorts the collected B-shard blocks according to their corresponding B-shard numbers, then pre-executes these blocks in order according to the sorting results, and replies to the corresponding B-shards through cross-shard reception messages; after the I-shard node completes the broadcast of cross-shard reception messages to all adjacent B-shards, it executes the cross-shard commit phase; The specific steps of the B-shard cross-shard proposal phase are as follows: B-shard nodes wait for cross-shard receive messages from all adjacent I-shards; whenever more than two-thirds of the nodes of an I-shard receive the same cross-shard receive votes, the B-shard node aggregates them into a cross-shard receive vote set for that I-shard; after collecting the cross-shard receive vote sets of all adjacent I-shards, the B-shard node records them in the cross-shard commit message and sends them to all adjacent I-shards, and then executes the cross-shard commit phase; The cross-shard commit phase specifically includes two types: I-shard cross-shard commit and B-shard cross-shard commit; During the cross-shard commit process of the I-shard, all leader nodes and validator nodes within the I-shard will collect the following data: (1) The blocks submitted in this round for this shard; (2) All adjacent B shards' blocks submitted in this round and the corresponding cross-shard submission messages; After collecting the above data (1) and (2), the I shard node executes the block execution phase; During the cross-shard commit phase of the B-shard, the B-shard node in the cross-shard commit phase will collect the following data: (1) The blocks committed in this round for this shard and their cross-shard commit messages; (2) All adjacent I-shard blocks submitted in this round; (3) All blocks submitted in this round by the B-shard of the second-order nearest neighbors and the corresponding cross-shard submission messages; After collecting the above data (1), (2), and (3), the B shard node executes the block execution phase; The block execution phase is divided into cross-shard block execution and intra-shard block execution; During the execution of blocks within the segment, in order to speed up the processing, data blocks from different I-segments are allocated to multiple processors for simultaneous execution; During the cross-shard block execution, when two upper-level B shards are second-order adjacent and their respective datasets overlap, the latest data state of the adjacent I shards must be synchronized. The B shard must execute not only its own blocks and those of the adjacent I shards, but also the blocks of all second-order adjacent B shards. The upper-level B shards are executed in a determined order according to the shard decimal number. In order to minimize the transaction termination rate, I shard blocks should be executed after B shard blocks.

Images