License fragment block chain node rotation and state synchronization optimization method

Abstract

The invention discloses a permission fragmentation block chain node rotation and state synchronization optimization method, which comprises the following steps of: 1, generating an on-chip random number and a node swap-out set and completing global synchronization, 2, calculating a global random number and a node swap-in set which is globally consistent, and step 3, swapping in nodes, synchronizing state data in parallel, finally initiating a connection request and adding a target fragment. According to the round-robin node calculation method based on the node deterministic sequence, a globally constructed Merkel tree root is adopted as a global random number, and globally consistent round-robin node distribution can be completed locally in combination with the Hash sequence of swapped-out node IDs and fragment IDs. Moreover, the parallel state transition mechanism assisted by the high-reputation node can enable the swap-in node to obtain the state snapshot and the block data only through a point-to-point mode, and the state synchronization process and the consensus process can be completely parallel, thereby greatly reducing or even eliminating the consensus pause caused by the state synchronization process of the new node.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to an optimization method for node rotation and state synchronization in a permissioned sharded blockchain. Background Technology

[0002] In recent years, blockchain technology has been widely used in finance, logistics, healthcare, and the Internet of Things (IoT) due to its decentralized, immutable, and traceable characteristics. However, as blockchain technology matures and its application scenarios expand, single-chain architectures, limited by constraints in throughput, latency, and scalability, are increasingly unable to meet the demands of large-scale practical applications. To overcome the bottlenecks in throughput and scalability of single-chain systems, sharding technology has been proposed and deployed in several sharded consortium blockchains. The core of sharding technology lies in dividing all network nodes into multiple independent groups according to certain rules, with each group responsible for handling transactions and data maintenance within its scope.

[0003] To prevent malicious nodes from concentrating on a particular shard for extended periods, a node rotation mechanism is often introduced. This involves rotating some nodes from the current shard and redistributing them to other shards within a fixed or dynamic time period to participate in consensus and oversight, thereby ensuring the randomness and balance of node composition across shards. As a crucial mechanism for maintaining system security and high-performance operation, the implementation methods and specific details of node rotation and state synchronization have a significant impact on the overall system performance. The following section details the current implementation status of node rotation and state synchronization in various typical systems in the prior art.

[0004] During the node rotation phase, shards need to reach a globally consistent consensus on the results of the node rotation, that is, each shard obtains a globally consistent set of incoming and outgoing nodes.

[0005] Represented by OmniLedger, each node generates a random value based on a Verifiable Random Function (VRF) before the end of each epoch, along with a corresponding proof. Each node broadcasts its VRF proof to the entire network, and all nodes jointly confirm the final rotation list through multiple rounds of consensus. In this process, each node not only sends its own proof but also must wait for messages from other nodes across the network, and only after all messages reach a consensus can it determine which nodes need to be swapped out.

[0006] In RapidChain's proposed scheme, each shard first undergoes local full communication, with all nodes propagating their generated rotation identifier information within their shard. Next, one or more leader nodes are selected from each shard. These leader nodes are responsible for aggregating the rotation data within their shard and exchanging information across shards with other shard leader nodes. During the cross-shard phase, leader nodes synchronize their respective shard's swap-out node set, random number, and signature data through targeted broadcasts, ultimately forming a unified global rotation rule through multiple rounds of consensus.

[0007] After node rotation, newly added nodes need to complete state synchronization, that is, quickly obtain the latest chain state from other existing nodes.

[0008] Traditional methods typically require new nodes to download the entire historical ledger or all blocks within a relatively long time period before joining a shard to obtain complete state information. While this approach ensures the integrity of the state data, in scenarios with frequent transactions and large block sizes, the large amount of data downloaded and the long transmission time can easily prevent new nodes from participating in real-time consensus for extended periods, leading to system performance degradation and consensus pauses.

[0009] To reduce the amount of data to be synchronized, some systems (such as some improved sharded chains) have introduced snapshot technology. In this scheme, each shard periodically generates a database snapshot or state block, and new nodes only need to download the most recent snapshot data and the blocks after that snapshot, so as to complete state synchronization in a shorter time.

[0010] In existing permissioned sharded blockchains, most implementations rely on network-wide broadcasting or hierarchical leader nodes to coordinate multiple rounds of message synchronization during node rotation. This approach requires all participating nodes to complete message exchange before the next round of consensus can be initiated, causing the entire network to wait for multiple confirmation rounds during rotation, resulting in significant consensus pauses. Furthermore, even with high-trust nodes assisting during node rotation, centralized verification and confirmation of all exchanged information are still necessary in cross-shard communication, making global synchronization between shards still time-consuming.

[0011] During state synchronization, new or switched-in nodes must download complete state data or snapshots from the target shard and exchange data with all nodes in the target shard to ensure state consistency. This full or incremental synchronization method, even with snapshot and targeted synchronization strategies in some systems, still requires new nodes to wait for all data transmission and verification to complete before participating in the next epoch's consensus, leading to additional consensus pauses and significant network overhead and data transmission pressure.

[0012] In summary, existing technologies generally suffer from two major drawbacks in node rotation message synchronization and state synchronization: first, consensus pauses are caused by multiple rounds of network-wide or cross-shard message exchanges; second, the synchronization process for new nodes requires communication with a large number of nodes, resulting in large data transmission volumes and heavy network loads. Therefore, this invention aims to solve these problems by employing a parallel message synchronization and targeted state update scheme, effectively shortening consensus pause times and reducing network overhead during state synchronization, thereby improving the overall real-time performance and operational efficiency of the system. Summary of the Invention

[0013] Based on the shortcomings and deficiencies of existing systems in the node rotation phase, this invention proposes an optimization method for node rotation and state synchronization in permissioned sharded blockchains. The overall idea is to significantly reduce consensus pause time and network overhead caused by node rotation and state synchronization without affecting system security and distributed consensus stability by pre-synchronizing globally consistent node rotation sets in parallel and introducing high-reputation nodes to synchronize data in parallel.

[0014] The technical solution to achieve the objective of this invention is: a method for optimizing node rotation and state synchronization in a permissioned sharded blockchain, comprising the following steps: Step 1: After initiating the node rotation phase, each shard initiates a round of intra-shard consensus in parallel to determine the random number r of this epoch for this shard. i (Each shard contains a set of high-trust nodes) and then based on r i Calculate the node swap set (Set) for this segment and this epoch within each node. out Finally, the high-reputation node will be r i and Set out Along with the local shard ID, it is synchronized to the global shard after multiple rounds of message passing using the Gossip communication scheme;

[0015] Step 2: After receiving synchronization messages from all other shards, first construct a Merkle tree using the random numbers of all shards as leaf nodes, and use the root of the Merkle tree as a globally consistent global random number; then use the global random number to sort the global node swap-out set of this epoch to obtain the global node deterministic order, and sort all shard IDs to obtain the global shard deterministic order. Based on these two deterministic orders and the number of swap-out node set elements of each shard, calculate the swap-in node set of this shard in this epoch.

[0016] Step 3: After obtaining the globally synchronized node exchange set, the switching-out node begins requesting state data and block data from the high-reputation nodes of the target shard, while simultaneously continuing to participate in the consensus of its current shard. Upon completing state synchronization and entering the next epoch, the switching-out node can send a switch-in request to the high-reputation nodes of the target shard. After successfully establishing a connection, it can join the consensus of the target shard. The high-reputation nodes of the target shard, while participating in the consensus of their current shard normally, simultaneously send synchronization data to the switch-in nodes and process switch-in requests from new nodes. After a new node completes its connection establishment, the switching-out nodes of the current shard are deleted proportionally until all new nodes have joined the consensus of the current shard.

[0017] Preferably, in step one, after entering the round-robin phase, the high-reputation node in each shard needs to determine the random number for this epoch of its shard and synchronize it with all other shards. The specific steps are as follows:

[0018] S101: Within a shard, a consensus round is initiated in parallel on top of the normal consensus process. This round of consensus requires consensus on the localRandom random number within the shard and the current epoch. This random number is the key input for constructing a globally consistent random source.

[0019] S102: Concatenate the node ID of each node within the shard with the localRandom random number within the shard, then calculate its hash value using the system-predefined hash function H, and finally use the maximum value V of the hash function. max Dividing by this hash value yields the intra-slice hash value V for each node. i；

[0020] S103: Convert the intra-chip hash value V of each node... i Compare the hash value with the swap out probability swapP of this shard in this epoch. Nodes with hash values ​​less than swapP are placed in the swapOutMap set of the entire shard. The key is the node identifier nodeId and the value is the shard identifier shardId, indicating that the node is selected as the swap out node of this shard in this epoch.

[0021] The process of sending S104 and receiving S105 synchronization messages in parallel is completed. Each node continuously listens for Msg data from all shards until the core structure ShardInfo, which is used to store and propagate key information in the rotation phase, has covered all shards in the system. This is considered as the node completing the global synchronization of rotation information.

[0022] Preferably, the random number generation process is as follows: Each segment generates a Merkle tree by hashing two types of information, and obtains the root of the tree as a local random value; the two types of information include:

[0023] The root hash of the block in the previous epoch, rootHashLastEpoch;

[0024] The aggregate signature (aggSignature) of the current epoch and this shard;

[0025] Construct a Merkle tree using both as leaf nodes. Through structural determinism and hash collision resistance, ensure that random numbers are unpredictable and verifiable. Use the Merkle tree root as localRandom to achieve intra-slice consensus through this round of consensus.

[0026] As a preferred embodiment, in S104, the message sending process is as follows: the epoch, the swapout node set swapOutMap, the local random number localRandom, and the local shard identifier shardId are packaged into a synchronization message Msg; a cross-shard broadcast mechanism is triggered by a high-trust node, using the Gossip protocol, to continuously transmit the local Msg message to other shard nodes until the local node confirms that it has received Msg messages from all shards in the entire network.

[0027] Preferably, in S105, the message receiving process is as follows: After receiving the synchronization message Msg from other shards, the epoch field is first extracted and the integrity verification and field checks of the message structure are completed. Then, the fields swapOutMap, localRandom, and shardId are extracted from Msg. Each field in swapOutMap is traversed and compared with the swapOutMap in the local ShardInfo. Data that is not recorded locally is added to the locally stored swapOutMap. The localRandom and shardId in the message are filled into the receivedRandomMap field in the local ShardInfo as value and key, respectively, to collect the intra-shard random numbers of the current epoch of other shards.

[0028] Preferably, in step two, the calculation steps for generating the set of swapped-in nodes are as follows:

[0029] S201: Each node constructs a Global Merkle Tree (GlobalMerkleTree) by taking the random numbers stored in the receivedRandomMap field of the local data structure ShardInfo and the random number localRandom of the current shard as leaf nodes according to the shard identifier shardId, and calculates its root, which is the global random number R.

[0030] S202: Each node retrieves all swapped-out nodes from the swapOutMap field of ShardInfo, concatenates the global random number R with each node identifier nodeId, calculates the hash value sortKey of the concatenation result, and fills the data pairs <sortKey, nodeId> into the sortNodeMap field of ShardInfo; sorts nodeSetOut in ascending order of key to generate a definite global sorted sequence of swapped-out nodes nodeL=[nodeId1, nodeId2,……, nodeId k Since the entire network has the same R and swapOutMap, the sorting L is also globally consistent throughout the system.

[0031] S203: Perform the operations in S202 on all fragment identifiers, and pair the data...<sortKey, shardId> Fill in the sortShardMap field in ShardInfo. sortShardMap is used to globally sort all shards. Sort sortShardMap in ascending order of key to generate a specific global shard sort sequence shardL=[shardId1,shardId2,……,shardId] k Similarly, this sequence is also globally consistent.

[0032] S204: Nodes in nodeL are allocated according to the shardL order. The number of nodes allocated to a shard is equal to the number of data items whose value in the swapOutMap field of ShardInfo is the shard identifier. When calculating the swap-in node allocation for this shard, the data pairs...<nodeId, shardId> Add the swapInMap field to the ShardInfo's swap-in node set field; finally, set the isSwapInCalculated field in ShardInfo to true to indicate that the information exchange between the rotating nodes is complete, and the system can then proceed to the next stage.

[0033] As a preferred approach, in step three, the node being swapped out leaves its original shard; the node being swapped in establishes a connection with the target shard and synchronizes its state. The specific steps for these two processes, which are carried out in parallel with consensus, are as follows:

[0034] S301: The swapping node reads the target shard it is about to swap into from the swapInMap field of ShardInfo stored locally, then obtains the shard object corresponding to the shard identifier through shardToObjectMap, and then extracts the set of high trust value nodes in the target shard from the object.

[0035] S302: While remaining in the original shard to participate in consensus, each swapped-out node will proactively send a state synchronization request to one or more high-trust nodes in the target shard.

[0036] S303: After the high-trust node determines that the isSwapInCalculated field in ShardInfo is true, it begins to construct the synchronization data message StateSnapshot. The high-trust node initiates a round of consensus within the shard, attempting to reach a consensus on the current account state tree snapshot and the block hash from the start of this epoch to the current height and collect signatures. It then packages these two pieces of data and the collected aggregate signatures into a StateSnapshot.

[0037] S304: After receiving a state synchronization request, the high-trust node first compares the request with the swapOutMap and swapInMap fields in its local ShardInfo to determine the validity of the request. If the request is valid, it will send the StateSnapshot to the requesting node. At the same time, the high-trust node will run its current state synchronization service in parallel with its daily consensus tasks without pausing local consensus.

[0038] S305: After receiving the StateSnapshot from the high-trust node of the target shard, the swapping node first verifies the signature, block hash and aggregate signature in the state snapshot; on the premise that the data is legal, it uses the snapshot data to restore the logical state copy in the target shard, and generates an account database and state machine consistent with the target shard locally; after completing the synchronization, it updates the syncStatus of the local ShardInfo to true, indicating that the state synchronization is complete.

[0039] S306: After the current epoch ends and the state is synchronized, the node that is switched out will actively initiate a connection establishment request to the high trust value node of the target shard. At this time, the high trust value node of the target shard will include the request in the next round of consensus initialization of this shard and update the member node set of this shard after receiving the connection from the node that was switched out.

[0040] S307: After confirming that the new node's state synchronization is complete and the connection is successfully established, the high-trust node of the target shard includes it in the consensus round of the next epoch. Once the swapped-out node successfully participates in the new round of consensus for the target shard, it will clear the local state cache of the old shard and initialize the running context of the new shard. At the same time, according to the swap-out ratio, the high-trust node will cancel the original swapped-out node of this shard, delete the relevant information from ShardInfo and cut off the communication connection with it. After all new nodes have successfully joined, all nodes in the shard have completed node rotation.

[0041] Preferably, in S302, the specific content of the state synchronization request actively sent by each swapping-out node to one or more high-trust nodes within the target shard includes:

[0042] This node is identified by its nodeId;

[0043] The original shard's sourceShardId;

[0044] The target shard Id will be replaced soon;

[0045] Current epoch number: epochIndex;

[0046] Request synchronization type: RequestType = "StateSnapshot"

[0047] The purpose of this request is to allow the high-trust node of the target shard to identify the external node to be added and to prepare to send compressed snapshot data of the current state of the shard to that node.

[0048] The present invention has the following beneficial effects by adopting the above technical solution: (1) The present invention designs a round-robin node calculation method based on node deterministic order, uses a globally constructed Merkle tree root as a global random number, and combines the hash sorting of the swap-out node ID and the shard ID to achieve a globally consistent round-robin node allocation locally; and completes the global synchronization of the node round-robin set through multi-round message synchronization that can be completed in parallel. All nodes can calculate a globally consistent node migration scheme locally based only on the swap-out set and random number in the ShardInfo data structure, without the need for additional communication to confirm the swap-in order or consensus rounds, which significantly reduces the consensus pause time and communication load during the round-robin period. It solves the technical problem in existing technologies such as RapidChain, where node round-robin is often completed through full node communication, committee consensus negotiation, etc., which involves multiple rounds of cross-shard communication and consensus processes that cannot be parallelized, which easily causes consensus pauses, communication delay accumulation, etc.

[0049] (2) This invention introduces a parallel state synchronization mechanism assisted by high-reputation nodes, proposing that the incoming node only needs to obtain state snapshots and block data through a point-to-point method, and the state synchronization process and the consensus process can be completely parallel, significantly reducing or even eliminating consensus pauses caused by the state synchronization process of new nodes. After the outgoing node completes the confirmation of the incoming shard target, it initiates a snapshot subscription request and establishes a point-to-point connection with the high-reputation node of the target shard, without waiting for the end of the current epoch. This parallel execution of consensus and state synchronization significantly reduces the bandwidth overhead of the target shard and the consensus pause time caused by state synchronization. It solves the technical problems in existing technologies such as OmniLedger, where new nodes need to pull state data from multiple consensus nodes and complete consistency verification through full shard synchronization before joining the target shard. This not only leads to complex communication and high overhead, but also often requires the system to wait for the state synchronization to be completed before starting the next round of consensus, causing system throughput pauses, block height stagnation, and increased transaction response delays. Attached Figure Description

[0050] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings, wherein...

[0051] Figure 1 This is a flowchart illustrating the execution process of the present invention during the node rotation phase.

[0052] Figure 2 The flowchart for calculating the globally consistent node exchange set;

[0053] Figure 3 This is a flowchart illustrating the communication process between the swapping-in node and the target shard's high-reputation node during the state synchronization phase. Detailed Implementation

[0054] Before introducing the specific steps of this invention, the applicable scenario of this invention is described as follows: The applicable scenario of this invention consists of a certain number of nodes and shards. Each node can only belong to one shard at any given time, and a shard can contain several nodes. Shards are distributed using a state-based sharding method, that is, a node belonging to a certain shard only stores the data required by that shard, not all the data. Nodes use the data of their shard to participate in the consensus of their shard and cross-shard transaction consensus. Furthermore, to ensure security, shards will exchange several nodes every epoch.

[0055] In the permissioned sharded blockchain system involved in this invention, for the sake of balancing performance, security, and distributed management, each shard has a set of high-trust-value nodes. These nodes are typically controlled by real-world entities with long-term identity authentication, stable operation capabilities, and high reputation, such as companies, schools, and hospitals participating in the system. High-trust-value nodes are characterized by high security, long-term fixed identities, more core responsibilities, and publicly available service capabilities during system operation. This role design aims to solve the latency problem caused by the need for incoming nodes to broadcast communication with all nodes in the target shard in traditional systems. It transforms the state synchronization process from many-to-many to a one-to-one or one-to-many directed, parallel, and efficient interaction model, thereby effectively reducing consensus pause time and network data transmission load during node rotation.

[0056] Given the above background conditions, the present invention includes the following steps:

[0057] Step 1: After the node rotation phase, each shard initiates a round of intra-shard consensus in parallel to determine the random number r for this epoch of this shard. i Subsequently based on r i Calculate the node swap set (Set) for this segment and this epoch within each node. out Finally, the high-reputation node will be r i and Set out Along with the local shard ID, it is synchronized to the global shard after multiple rounds of message passing using the Gossip communication scheme.

[0058] Step Two: After receiving synchronization messages from all other shards, first construct a Merkle tree using the random numbers from all shards as leaf nodes, and use the root of the Merkle tree as a globally consistent global random number. Then, use the global random number to sort the global node swap-out set for this epoch to obtain a global node deterministic order, and sort all shard IDs to obtain a global shard deterministic order. Based on these two deterministic orders and the number of elements in the swap-out node set of each shard, calculate the swap-in node set for this shard in this epoch.

[0059] Step 3: After obtaining the globally synchronized node exchange set, the switching-out node begins requesting state data and block data from the high-reputation nodes of the target shard, while simultaneously continuing to participate in the consensus of its current shard. Upon completing state synchronization and entering the next epoch, the switching-out node can send a switch-in request to the high-reputation nodes of the target shard. After successfully establishing a connection, it can join the consensus of the target shard. The high-reputation nodes of the target shard, while participating normally in the consensus of their current shard, concurrently send synchronization data to the switch-in nodes and process switch-in requests from new nodes. After a new node completes its connection establishment, the switching-out node is proportionally removed from the current shard's consensus until all new nodes have joined the consensus of the current shard.

[0060] The following provides further explanation: each node needs to initialize its local ShardInfo data structure when joining the system. ShardInfo is the core structure in this invention used to store and propagate key information during the rotation phase. The data fields that must be initialized include:

[0061] nodeId: The unique identifier of the current node;

[0062] shardId: The shard number to which the current node belongs; i.e., the identifier of this shard.

[0063] epoch: The current cycle number being executed;

[0064] height: The current block height of this node;

[0065] rootHashLastEpoch: The block hash digest of this shard in the previous epoch;

[0066] aggSignature: The aggregate signature generated by all consensus nodes in this shard under the current epoch;

[0067] localRandom: The local random number generated within this slice, used to generate global random numbers; that is, intra-slice random numbers.

[0068] swapP: The probability of a node being swapped out in this epoch of this partition;

[0069] receivedRandomMap: Used to store random numbers synchronized from other shards;

[0070] swapOutMap: Used to store the set of swap-out nodes for the entire shard;

[0071] swapInMap: Used to store the set of swap-in nodes for this shard;

[0072] sortNodeMap: Used to perform global sorting on all swapped-out nodes;

[0073] sortShardMap: Used to perform global sorting on all shards;

[0074] isSwapInCalculated: Used to indicate whether the node swap set calculation is complete;

[0075] syncStatus: Used to indicate whether the synchronization status of the swapped-out node is complete;

[0076] shardToObjectMap / objectToShardMap: A mapping between shard identifiers and their specific data objects;

[0077] nodeToObjectMap / objectToNodeMap: A mapping between node identifiers and their specific data objects.

[0078] Furthermore, in step one, after entering the round-robin phase, the high-reputation nodes within each shard need to determine the random number for this epoch of their shard and synchronize it with all other shards. The specific steps are as follows:

[0079] S101: Within each shard, a consensus round is initiated in parallel on top of the normal consensus process. This round of consensus requires reaching an intra-shard consensus on the localRandom random number within the current epoch of this shard. This random number is the key input for constructing a globally consistent random source. The generation process of this random number is further explained as follows: Each shard generates a Merkle tree by hashing two types of information, obtaining the root of the tree as a local random value. The two types of information include:

[0080] The root hash of the block in the previous epoch, rootHashLastEpoch;

[0081] The aggregate signature (aggSignature) of the current epoch and this segment.

[0082] Construct a Merkle tree using both as leaf nodes. Through structural determinism and hash collision resistance, ensure that random numbers are unpredictable and verifiable. Use the Merkle tree root as localRandom to achieve intra-slice consensus through this round of consensus.

[0083] S102: Concatenate the node ID of each node within the shard with the localRandom random number within the shard, then calculate its hash value using the system-predefined hash function H, and finally use the maximum value V of the hash function. max Dividing by this hash value yields the intra-slice hash value V for each node. i .

[0084] S103: Convert the intra-chip hash value V of each node... i The hash value of a node is compared with the swapP of the current epoch of this shard. Nodes with hash values ​​less than swapP are added to the swapOutMap set of the entire shard. The key is the node ID nodeId and the value is the shard ID shardId, indicating that the node is selected as the swapout node of this epoch of this shard.

[0085] The next two steps, S104 and S105, are the processes of sending and receiving synchronization messages for each shard, and therefore are completed in parallel. Each node continuously listens for Msg data from all shards until its local ShardInfo structure's receivedRandomMap and swapOutMap have covered all shards in the system, at which point the node is considered to have completed global synchronization of the rotation information.

[0086] S104: The message sending process is as follows: The epoch, the swapOutMap set of swapped nodes, the localRandom number within the shard, and the shardId of this shard are packaged into a synchronization message Msg. A cross-shard broadcast mechanism is triggered by a high-trust node, using the Gossip protocol to continuously transmit the local Msg message to other shard nodes until this node confirms that it has received Msg messages from all shards in the entire network.

[0087] S105: The message receiving process is as follows: After receiving a synchronization message Msg from other shards, first extract the epoch field and perform integrity verification and field checks on the message structure. Then, extract the fields swapOutMap, localRandom, and shardId from the Msg. Iterate through each field in swapOutMap and compare it with the swapOutMap in the local ShardInfo. Add any data that is not recorded locally to the locally stored swapOutMap. Use the localRandom and shardId from the message as the value and key respectively to fill the receivedRandomMap field in the local ShardInfo, which is used to collect intra-shard random numbers for this epoch of other shards.

[0088] The following is a detailed explanation of step two. In step one, all nodes synchronized the network-wide shard rotation information through an asynchronous message passing mechanism, including the local random numbers for each shard and the set of swapping-out nodes. The main objective of this step is to calculate, based on this synchronized information, which swap-in nodes should be received by each shard in the current epoch, i.e., to generate the swapInSet set of swap-in nodes. The specific steps are as follows:

[0089] S201: Each node constructs a Global Merkle Tree (GMR) by using the shardId as the shard identifier, and takes the random numbers stored in the receivedRandomMap field of ShardInfo from other shards and the random number localRandom of the current shard as leaf nodes. The root of the tree is then calculated, which is the global random number R.

[0090] S202: Each node retrieves all swapped-out nodes from the `swapOutMap` field of `ShardInfo`, concatenates a global random number `R` with each node's identifier `nodeId`, calculates the hash value `sortKey` on the concatenation result, and fills the data pairs `<sortKey, nodeId>` into the `sortNodeMap` field of `ShardInfo`. `nodeSetOut` is sorted in ascending order by key, generating a definite global sorted sequence of swapped-out nodes: `nodeL = [nodeId1, nodeId2, ..., nodeId]`. k Since the entire network has the same R and swapOutMap synchronized, the sorting L is also globally consistent throughout the system.

[0091] S203: Perform the operations in S202 on all fragment identifiers, and pair the data...<sortKey, shardId> Fill in the sortShardMap field in ShardInfo. Sort sortShardMap in ascending order of key to generate a fixed global sorted sequence of shards: shardL=[shardId1, shardId2, ..., shardId... k Similarly, this sequence is also globally consistent.

[0092] S204: Nodes in nodeL are allocated according to the shardL order. The number of nodes allocated to a shard is equal to the number of data items whose value in the swapOutMap field of ShardInfo is the shard identifier. When calculating the swap-in node allocation for this shard, the data pairs...<nodeId, shardId> Add the swapInMap field to the ShardInfo's swap-in node set field. Finally, set the isSwapInCalculated field in ShardInfo to true to indicate that the information exchange between the rotating nodes is complete, and the system can proceed to the next stage.

[0093] The following is a detailed explanation of step three. In step two, each node has completed the global synchronization of ShardInfo. The next step is a bidirectional transition process: the node being swapped out leaves its original shard; the node being swapped in establishes a connection with the target shard and synchronizes its state. These two processes can be performed in parallel with consensus to avoid consensus pauses and improve system throughput and activity. The specific steps are as follows:

[0094] S301: The swapping node reads the target shard it is about to swap into from the swapInMap field of the ShardInfo stored locally, then obtains the shard object corresponding to the shard identifier through shardToObjectMap, and then extracts the set of high trust value nodes in the target shard from the object.

[0095] S302: While remaining in the original shard to participate in consensus, each swapped-out node will proactively send a state synchronization request to one or more high-trust nodes in the target shard. The specific content includes:

[0096] This node is identified by its nodeId;

[0097] The original shard's sourceShardId;

[0098] The target shard Id will be replaced soon;

[0099] Current epoch number: epochIndex;

[0100] Request synchronization type: RequestType = "StateSnapshot".

[0101] The purpose of this request is to allow the high-trust node of the target shard to identify the external node to be added and to prepare to send compressed snapshot data of the current state of the shard to that node.

[0102] S303: After determining that the isSwapInCalculated field in ShardInfo is true, the high-trust node begins to construct the synchronization data message StateSnapshot. The high-trust node initiates a round of consensus within the shard, attempting to reach consensus on the current account state tree snapshot and the block hash from the start of this epoch to the current height, and collects signatures. These two pieces of data, along with the collected aggregate signatures, are packaged into a StateSnapshot.

[0103] S304: Upon receiving a state synchronization request, the high-trust node first determines the validity of the request by comparing it with the `swapOutMap` and `swapInMap` fields in its local `ShardInfo`. If the request is valid, it sends the `StateSnapshot` to the requesting node. Simultaneously, the high-trust node runs its current state synchronization service in parallel with its daily consensus tasks, without pausing local consensus.

[0104] S305: Upon receiving the StateSnapshot from the high-trust node of the target shard, the swapping node first verifies the signature, block hash, and aggregate signature in the state snapshot. Assuming the data is valid, it uses the snapshot data to restore a copy of the logical state within the target shard and generates an account database and state machine locally that are consistent with the target shard. After synchronization is complete, it updates the local ShardInfo's syncStatus = true, indicating that state synchronization is complete.

[0105] S306: After the current epoch ends and the state is synchronized, the node that was switched out will proactively initiate a connection establishment request to the high-trust node of the target shard. At this time, the high-trust node of the target shard will include this request as part of the consensus initialization of this shard in the next round, and update the member node set of this shard after receiving the connection from the node that was switched out.

[0106] S307: After confirming that the new node's state synchronization is complete and the connection is successfully established, the high-trust node of the target shard includes it in the consensus round of the next epoch. Once the swapped-out node successfully participates in the new round of consensus for the target shard, it clears the old shard's local state cache and initializes the new shard's runtime context. Simultaneously, according to the swap-out ratio, the high-trust node deregisters the original swapped-out nodes in its shard, deleting relevant information from ShardInfo and severing communication connections with them. After all new nodes have successfully joined, all nodes within the shard have completed node rotation.

[0107] The specific implementation of the present invention will be described in detail below with reference to specific embodiments, including the complete process and detailed data flow of the present invention.

[0108] This invention provides an optimization mechanism for node rotation and state synchronization in a sharded consortium blockchain environment. Its core objective is to reduce the pause in global consensus caused by node rotation and to lower the data transmission overhead and waiting time during new node state synchronization. The specific implementation consists of three steps: generating intra-shard random numbers and a node swap-out set and completing global synchronization; calculating a globally random number and a globally consistent node swap-in set; and having swap-in nodes synchronize state data in parallel, ultimately initiating a connection request and joining the target shard. The overall flow of the three steps is as follows: Figure 1 As shown, all three steps can be completed in parallel with blockchain consensus.

[0109] like Figure 2As shown, this embodiment of the invention deploys three shards in the system: shard A, shard B, and shard C. Each shard contains four logical nodes, numbered 1 to 4. These nodes collectively maintain the ledger state of their respective shards and participate in the consensus process. Node 1 of each shard is designated as a "high-reputation node," possessing characteristics such as high stability and good communication quality, and is responsible for the cross-shard synchronization task of rotating data. The remaining nodes are ordinary consensus nodes, capable of participating in verification and block production.

[0110] Step 1: After the system enters the epoch rotation phase, it enters the rotation state. Each shard independently generates the random numbers required for rotation and determines the set of nodes to be swapped out based on these random numbers. After completing the local calculations, the shards exchange their generated random numbers and swap-out set information via the Gossip protocol, ultimately constructing a consistent mapping of the complete set of swap-out nodes and shard random numbers locally on each node. Further, this is illustrated below with reference to an example:

[0111] S101: To ensure the unpredictability and fairness of the rotation results, each shard must generate a local random number r based solely on the historical information of its own shard. i This is used to guide the determination of whether a node is swapped out in the current round. Specifically, it is generated as follows: using the Merkle root hash `rootHashLastEpoch` of the last block produced in the previous epoch of this shard and the aggregate signature `aggSignature` of the node set during the consensus process of the current epoch as input, a Merkle tree of depth 1 is constructed, and its root node hash value is used as a local random number. Taking shard A as an example, the formula for calculating its intra-shard random number is: Similarly, random numbers within fragments B and C are also calculated. and .

[0112] S102: After obtaining its own random number, each shard must perform a swap-out check on all ordinary nodes within that shard. Further, taking shard A as an example, the specific process is as follows:

[0113] SS1: High-reputation node 1 traverses the ordinary nodes within the shard. The node identifier nodeId is combined with an intra-chip random number. By splicing, each node gets .

[0114] SS2: Calculate the hash value of all results obtained in SS1 to get... .

[0115] SS3: Divide all results obtained in SS2 by the maximum value of the hash function to obtain... This process normalizes the hash value of each node and maps it to a real number in the interval [0,1]. .

[0116] SS4: Read the swap probability swapP for this epoch of this shard from the local ShardInfo, where swapP is of type float, and Each Compared with swapP, if Then the node will be added to the set of nodes to be swapped out, that is, the data item will be removed from the set.<nodeId, shardId> Store it in the swapOutMap field of the local ShardInfo.

[0117] like Figure 2 As shown in the embodiment: Node 4 in shard A, Nodes 2 and 3 in shard B, and Node 3 in shard C are marked as the swapout nodes in this round. At this time, the swapOutMap field in the local ShardInfo of the nodes in the three shards is different, and only the swapout node data item of this shard is filled in.

[0118] S103: Next, the high-reputation nodes of each shard need to complete message synchronization. Since this step is performed in parallel with normal shard consensus, to avoid excessive communication load affecting normal consensus, this invention uses an asynchronous distributed Gossip protocol for data synchronization between shards in this step. Taking shard A as an example, the high-reputation node (i.e., node 1) is responsible for synchronizing the messages between shards. The epoch, shardId, and swapOutMap are used to construct a synchronization message and broadcast it to high-reputation nodes in other shards.

[0119] , .

[0120] Upon receiving this message, other shards write it to the `receivedRandomMap` and `swapOutMap` fields of their local `ShardInfo` data structure. After multiple rounds, all nodes in the network gradually complete the construction of the following synchronization view:

[0121]

[0122]

[0123]

[0124] Furthermore, step two is completed through the following specific process:

[0125] S201: As Figure 2As shown, all nodes generate a system-wide consistent global random number R by uniformly constructing a Merkle tree of all local random numbers from all shards. This global random number serves as the "global seed" in the allocation process of the swapped-in nodes, possessing tamper-resistance and verifiability. Specifically, it is constructed as follows:

[0126] SS1: A fixed fragment order is obtained by sorting all fragment identifiers: In this embodiment, it is assumed that the fixed fragmentation order is ABC.

[0127] SS2: Following a fixed fragmentation order, the random numbers within each fragment are used as leaf nodes to fill the Merkle tree's generation function. The resulting Merkle tree root is used as the global random number. .

[0128] S202: As Figure 2 As shown, taking shard A as an example, all nodes use the following process to construct a globally unified node order:

[0129] SS1: Traversing the local ShardInfo The field concatenates a global random number R with each node identifier nodeId, and then calculates a hash value from the concatenation result. Fill the sortNodeMap field in ShardInfo with the data pair <sortKey, nodeId>:

[0130]

[0131]

[0132] SS2: Yes Sort the keys in ascending order and store the sorted values ​​to obtain a globally consistent order of the swapped-out nodes. For example... Figure 3 As shown, the final list is as follows: .

[0133] S203: Perform the same steps as in S202 on all shard identifiers. First, concatenate them with a global random number R, then calculate the hash value, and finally sort the hash values ​​to obtain a globally unified shard order. Why isn't the result obtained in S201 used in this step? The following explanation is provided: The sharding order is fixed and does not change as the system runs. This fixed structure may become a vulnerability for malicious nodes to attack. Malicious nodes can slowly penetrate and learn this fixed sharding order to achieve their subsequent attack objectives. However, the shardL calculated in this step is not fixed in each node rotation phase because the calculation process involves a global random number R. Therefore, it is less likely to be attacked by malicious nodes.

[0134] S204: Count the number of nodes swapped out for each shard recorded in the swapOutMap field of the local ShardInfo, and construct the same number of swap-in tasks, i.e.:

[0135]

[0136] S205: According to the swap-in task from According to shard The swapped-out nodes are assigned to each shard in sequence, and the results are written to the swapInMap field in the local ShardInfo:

[0137]

[0138]

[0139] After completing this step, set isSwapInCalculated in the local ShardInfo to true.

[0140] Furthermore, such as Figure 3 As shown, taking the communication process between node 4 (the swapping-out node) of shard A and node 1 (the high-reputation node) of shard B as an example, this demonstrates the communication process between the swapping-in node and the high-reputation node of the target shard in step three. The communication process of other nodes can be compared analogously. The specific steps are as follows:

[0141] S301: After the allocation of the incoming node set is completed, each outgoing node can determine its target shard and begin the state transition process. For example... Figure 3 As shown, node A4 was originally a consensus node belonging to shard A and has been selected as the node to be swapped out in this round, with shard B as the target shard. Node B1 is a high-reputation node within shard B, possessing complete state data and responsible for handling state requests from the swapping-in node. After node A4 obtains that isSwapInCalculated is true in its local ShardInfo, it first retrieves the state data from swapInMap[shardId]. B The target shard is confirmed to be shard B, and the shard object corresponding to shard B is obtained through shardToObjectMap. BThis allows for the extraction of a set of high-trust-value nodes within the target shard. ].

[0142] S302: As Figure 3 As shown, node A4 sends a status data request to all nodes in the high-trust node set of the target shard:

[0143]

[0144]

[0145] S303: As Figure 3 As shown, after receiving the request, node B1 first verifies the message's validity. It then determines that the node's identity is valid and matches the `swapInMap[shardId]` value in its local ShardInfo. B After processing the content, the pre-prepared StateSnapshot message is sent back to A4. The StateSnapshot message is started after the high reputation value determines that isSwapInCalculated in the local ShardInfo is true. It contains a snapshot of the account state at the time of packaging, the blocks from the start of this epoch to the current height, and the signature of node B1.

[0146] S304: As Figure 3 As shown, after receiving the returned StateSnapshot, node A4 first verifies the signature. After ensuring its validity, it builds an additional account state database for the target shard in its local database based on the account state snapshot and stores the blocks contained in the message.

[0147] S305: After completing the local environment construction for the StateSnapshot message, node A4 sends a message subscription request (NewBlockRequest) to node B1. Upon receiving the request, node B1 periodically packages blocks of a certain height for the current epoch and places the packaged data into the channel subscribed to by node A4. In this way, node A4 can synchronize the block messages of the target shard in the current epoch that are currently undergoing consensus in parallel, without having to wait until entering the next epoch to start synchronization.

[0148] S306: Provided that the next epoch has been entered and the state synchronization has been completed, A4 actively initiates a JoinRequest to all high reputation nodes B1 of the target shard B, including the next epoch sequence number (e+1), A4's node identifier, the target shard B identifier, the block hash of the last height of the previous epoch, and the current account state tree root.

[0149] S307: After receiving the JoinRequest, node B1 first verifies whether the node source and target shard match its local ShardInfo. Then, it verifies whether the block hash of the last height of the previous epoch and the current account state tree root are correct. If correct, it means that node A4 has completed all state synchronization for the previous epoch and can join the consensus of the next epoch of this shard. After verification, a consensus round is initiated within this shard, updating the consensus member set of all shard nodes. While adding the new node A4, a node in this shard (e.g., B2) is removed from the consensus by the swapOutMap field in the ShardInfo, and the consensus member set is updated. .

[0150] S308: After node A4 completes the consensus joining of the target shard in the next epoch, it will update the local database, delete the relevant data of the source shard, and update the ShardInfo structure. From this point on, A4 becomes the official consensus node of shard B, completing the entire rotation process from A to B.

[0151] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for optimizing node rotation and state synchronization in a permissioned sharded blockchain, characterized in that: Includes the following steps: Step 1: After the node rotation phase, each shard initiates a round of intra-shard consensus in parallel to determine the random number r for this epoch of this shard. i Each shard contains a set of high-trust nodes, and then based on r i Calculate the node swap set (Set) for this segment and this epoch within each node. out Finally, the high-reputation node will be r i and Set out Along with the local shard ID, it is synchronized to the global shard after multiple rounds of message passing using the Gossip communication scheme; Step 2: After receiving synchronization messages from all other shards, first construct a Merkle tree using the random numbers of all shards as leaf nodes, and use the root of the Merkle tree as a globally consistent global random number; then use the global random number to sort the global node swap-out set of this epoch to obtain the global node deterministic order, and sort all shard IDs to obtain the global shard deterministic order. Based on these two deterministic orders and the number of swap-out node set elements of each shard, calculate the swap-in node set of this shard in this epoch. Step 3: After obtaining the globally synchronized node exchange set, the switching-out node begins to request state data and block data from the high-reputation node of the target shard, while continuing to participate in the consensus of this shard in parallel; when the state synchronization is completed and the next epoch is entered, the switching-out node can send a switch-in request to the high-reputation node of the target shard, and after successfully establishing a connection, it can join the consensus of the target shard. The high-reputation nodes in the target shard, while participating in the consensus of this shard normally, send synchronization data to the swap-in nodes in parallel and process the swap-in requests of new nodes. After the new nodes complete the connection establishment, the swap-out nodes of this shard are deleted proportionally until all new nodes join the consensus of this shard.

2. The method for optimizing node rotation and state synchronization in a permissioned sharded blockchain according to claim 1, characterized in that: In step one, after entering the round-robin phase, the high-reputation nodes in each shard need to determine the random number for this epoch of their shard and synchronize it with all other shards. The specific steps are as follows: S101: Within a shard, a consensus round is initiated in parallel on top of the normal consensus process. This round of consensus requires consensus on the localRandom random number within the shard and the current epoch. This random number is the key input for constructing a globally consistent random source. S102: Concatenate the node ID of each node within the shard with the localRandom random number within the shard, then calculate its hash value using the system-predefined hash function H, and finally use the maximum value V of the hash function. max Dividing by this hash value yields the intra-slice hash value V for each node. i； S103: Convert the intra-chip hash value V of each node... i Compare the hash value with the swap out probability swapP of this shard in this epoch. Nodes with hash values ​​less than swapP are placed in the swapOutMap set of the entire shard. The key is the node identifier nodeId and the value is the shard identifier shardId, indicating that the node is selected as the swap out node of this shard in this epoch. The process of sending S104 and receiving S105 synchronization messages in shards is completed in parallel. Each node continuously listens for Msg data from all shards until the core structure ShardInfo, which is used to store and propagate key information in the rotation phase, has covered all shards in the system. This is considered as the node completing the global synchronization of rotation information.

3. The method for optimizing node rotation and state synchronization in a permissioned sharded blockchain according to claim 2, characterized in that: The random number generation process is as follows: Each slice generates a Merkle tree by hashing two types of information, and obtains the root of the tree as a local random value; the two types of information include: The root hash of the block in the previous epoch, rootHashLastEpoch; The aggregate signature (aggSignature) of the current epoch and this shard; Construct a Merkle tree using both as leaf nodes. Through structural determinism and hash collision resistance, ensure that random numbers are unpredictable and verifiable. Use the Merkle tree root as localRandom to achieve intra-slice consensus through this round of consensus.

4. The method for optimizing node rotation and state synchronization in a permissioned sharded blockchain according to claim 2, characterized in that: In S104, the message sending process is as follows: the epoch, the swapout node set swapOutMap, the local random number localRandom, and the local shard identifier shardId are packaged into a synchronization message Msg; a cross-shard broadcast mechanism is triggered by a high-trust node, using the Gossip protocol to continuously transmit the local Msg message to other shard nodes until the local node confirms that it has received Msg messages from all shards in the entire network.

5. The method for optimizing node rotation and state synchronization in a permissioned sharded blockchain according to claim 2, characterized in that: In S105, the message receiving process is as follows: After receiving the synchronization message Msg from other shards, the epoch field is first extracted and the integrity verification and field checks of the message structure are completed. Then, the fields swapOutMap, localRandom, and shardId are extracted from Msg. Each field in swapOutMap is traversed and compared with the swapOutMap in the local ShardInfo. Data that is not recorded locally is added to the locally stored swapOutMap. The localRandom and shardId in the message are filled into the receivedRandomMap field in the local ShardInfo as the value and key, respectively, to collect the intra-shard random numbers of the current epoch of other shards.

6. The method for optimizing node rotation and state synchronization in a permissioned sharded blockchain according to claim 1, characterized in that: In step two, the calculation steps for generating the set of swapped-in nodes are as follows: S201: Each node constructs a Global Merkle Tree (GlobalMerkleTree) by taking the random numbers stored in the receivedRandomMap field of the local data structure ShardInfo and the random number localRandom of the current shard as leaf nodes according to the shard identifier shardId, and calculates its root, which is the global random number R. S202: Each node retrieves all swapped-out nodes from the `swapOutMap` field of `ShardInfo`, concatenates the global random number `R` with the node identifier `nodeId` of each node, calculates the hash value `sortKey` on the concatenation result, and then stores the data...<sortKey, nodeId> Fill in the sortNodeMap field in ShardInfo; sort nodeSetOut in ascending order by key to generate a global sorted sequence of swapped-out nodes: nodeL=[nodeId1, nodeId2, ..., nodeId...] k Since the entire network has the same R and swapOutMap, the sorting L is also globally consistent throughout the system. S203: Perform the operations in S202 on all fragment identifiers, and then pair the data...<sortKey, shardId> Fill in the sortShardMap field in ShardInfo. sortShardMap is used to globally sort all shards. Sort sortShardMap in ascending order of key to generate a specific global shard sort sequence shardL=[shardId1,shardId2,……,shardId] k Similarly, this sequence is also globally consistent. S204: Nodes in nodeL are allocated according to the shardL order. The number of nodes allocated to a shard is equal to the number of data items whose value in the swapOutMap field of ShardInfo is the shard identifier. When calculating the swap-in node allocation for this shard, the data pairs...<nodeId, shardId> Add the swapInMap field to the ShardInfo's swap-in node set field; finally, set the isSwapInCalculated field in ShardInfo to true to indicate that the information exchange between the rotating nodes is complete, and the system can then proceed to the next stage.

7. The method for optimizing node rotation and state synchronization in a permissioned sharded blockchain according to claim 1, characterized in that: In step three, the node being swapped out leaves its original shard; the node being swapped in establishes a connection with the target shard and synchronizes its state. The specific steps of these two processes, which are carried out in parallel with consensus, are as follows: S301: The swapping node reads the target shard it is about to swap into from the swapInMap field of ShardInfo stored locally, then obtains the shard object corresponding to the shard identifier through shardToObjectMap, and then extracts the set of high trust value nodes in the target shard from the object. S302: While remaining in the original shard to participate in consensus, each swapped-out node will proactively send a state synchronization request to one or more high-trust nodes in the target shard. S303: After the high-trust node determines that the isSwapInCalculated field in ShardInfo is true, it begins to construct the synchronization data message StateSnapshot. The high-trust node initiates a round of consensus within the shard, attempting to reach a consensus on the current account state tree snapshot and the block hash from the start of this epoch to the current height and collect signatures. It then packages these two pieces of data and the collected aggregate signatures into a StateSnapshot. S304: After receiving a state synchronization request, the high-trust node first compares the request with the swapOutMap and swapInMap fields in its local ShardInfo to determine the validity of the request. If the request is valid, it will send the StateSnapshot to the requesting node. At the same time, the high-trust node will run its current state synchronization service in parallel with its daily consensus tasks without pausing local consensus. S305: After receiving the StateSnapshot from the high-trust node of the target shard, the swapping node first verifies the signature, block hash and aggregate signature in the state snapshot; on the premise that the data is legal, it uses the snapshot data to restore the logical state copy in the target shard, and generates an account database and state machine consistent with the target shard locally; after completing the synchronization, it updates the syncStatus of the local ShardInfo to true, indicating that the state synchronization is complete. S306: After the current epoch ends and the state is synchronized, the node that is switched out will actively initiate a connection establishment request to the high trust value node of the target shard. At this time, the high trust value node of the target shard will include the request in the next round of consensus initialization of this shard and update the member node set of this shard after receiving the connection from the node that was switched out. S307: Once the high-trust node of the target shard confirms that the new node's state synchronization is complete and the connection is successfully established, it will be included in the consensus round of the next epoch. Once a node that has been swapped out successfully participates in a new round of consensus for the target shard, it will clear the local state cache of the old shard and initialize the running context of the new shard. At the same time, according to the swap-out ratio, high-trust nodes will deregister the original swap-out nodes in this shard, delete the relevant information from ShardInfo and cut off the communication connection with them. After all new nodes have successfully joined, all nodes in the shard have completed node rotation.

8. The method for optimizing node rotation and state synchronization in a permissioned sharded blockchain according to claim 7, characterized in that: In S302, the specific content of each swapping-out node actively sending a state synchronization request to one or more high-trust nodes within the target shard includes: This node is identified by its nodeId; The original shard's sourceShardId; The target shard Id will be replaced soon; Current epoch number: epochIndex; Request synchronization type: RequestType = "StateSnapshot" The purpose of this request is to allow the high-trust node of the target shard to identify the external node to be added and to prepare to send compressed snapshot data of the current state of the shard to that node.

Images