An Optimization Method for Node Rotation and State Synchronization in Permissioned Sharded Blockchain

Abstract

This invention discloses an optimized method for node rotation and state synchronization in a permissioned sharded blockchain, comprising the following steps: Step 1: generating intra-shard random numbers and a node swap-out set and completing global synchronization; Step 2: calculating a global random number and a globally consistent node swap-in set; Step 3: the swap-in node synchronizes state data in parallel and finally initiates a connection request and joins the target shard. The rotating node calculation method of this invention, based on node deterministic order, uses a globally constructed Merkle tree root as the global random number, combined with the hash sorting of the swap-out node ID and shard ID, to achieve globally consistent rotating node allocation locally. Furthermore, its parallel state migration mechanism assisted by high-reputation nodes allows swap-in nodes to obtain state snapshots and block data only through peer-to-peer methods, and the state synchronization process and consensus process can be completely parallelized, significantly reducing or even eliminating consensus pauses caused by the state synchronization process of new nodes.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of blockchain technology, and particularly relates to a permissioned sharding blockchain node rotation and state synchronization optimization method. BACKGROUND

[0002] In recent years, blockchain technology has been widely applied in the fields of finance, logistics, medical treatment, Internet of Things, etc. due to its characteristics of decentralization, non-tamperability and traceability. With the continuous maturity of blockchain technology and the continuous expansion of application scenarios, the single-chain architecture gradually fails to meet the needs of large-scale practical applications due to its limitations in throughput, delay and scalability. In order to break through the bottleneck of single-chain system in throughput and scalability, sharding technology is proposed and has been practically deployed in multiple sharding consortium chains. The core of sharding technology is to divide all network nodes into multiple independent groups according to certain rules, and each group is responsible for processing transactions and maintaining data within its scope.

[0003] In order to prevent malicious nodes from gathering in a certain shard for a long time, a node rotation mechanism is often introduced, that is, part of the nodes are removed from the current shard and allocated to other shards to participate in consensus and supervision within a fixed or dynamic time period, so as to ensure the randomness and balance of the nodes in each shard. As a key mechanism to maintain system security and high-performance operation, the implementation method and specific details of node rotation and state synchronization have a crucial impact on the overall performance of the system. The following will detail the implementation status of each typical system in the node rotation and state synchronization in the prior art.

[0004] In the node rotation phase, the nodes between the shards need to reach a global consensus on the results of the node rotation, that is, each shard obtains a globally consistent set of nodes to be replaced and a set of nodes to be replaced.

[0005] OmniLedger is taken as an example. Each node generates a random value according to a verifiable random function VRF before the end of each epoch, and attaches the 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 needs to send its own proof, but also needs to wait for messages from other nodes in the network, and can only determine which nodes need to be replaced after all messages reach a consensus.

[0006] In the solution proposed by RapidChain, local full communication is first performed within each shard, and all nodes propagate the rotating identification information generated by themselves within the shard. Then, one or more leader nodes are selected from each shard, which are responsible for summarizing the rotating data within the shard and exchanging information with other shard leader nodes across the shards. In the cross-shard stage, the leader nodes synchronize the out-of-shard node set, random number and signature data of each shard through directional broadcast, and finally form a unified global rotation rule through multiple rounds of consensus.

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

[0008] Traditional methods usually require new nodes to download the entire history ledger or all block data within a long period of time before joining the shard, so as to obtain complete state information. Although this method ensures the integrity of the state data, in the scenario of frequent transactions and large block volume, the amount of data to be downloaded is large, and the transmission time is long, which can easily cause the new nodes to be unable to participate in real-time consensus for a long time, thereby causing system performance degradation and consensus pause.

[0009] In order to reduce the amount of synchronization data, some systems (such as some improved sharding chains) introduce snapshot technology. In this solution, each shard generates a database snapshot or state block periodically, and the new node only needs to download the latest snapshot data and the blocks after the snapshot in order to complete the state synchronization in a short time.

[0010] In the node rotation link of the existing permissioned sharding blockchain, most implementations rely on network-wide broadcast or hierarchical leader node coordination for multiple rounds of message synchronization. This method requires all participating nodes to complete message exchange before the end of each epoch, and then start the next round of consensus, so that the entire network must wait for multiple confirmation rounds during rotation, resulting in a significant consensus pause phenomenon. At the same time, during node rotation, even with the assistance of high-trust nodes, centralized verification and confirmation of all out-of-shard information is still required in cross-shard communication, and global synchronization between shards still takes a long time.

[0011] In the state synchronization link, the new node or the node that has been added to the shard must download the complete state data or snapshot from the target shard, and exchange data with all nodes in the target shard to ensure state consistency. Although some systems have adopted snapshot and directional synchronization strategies, the new node still needs to wait for all data transmission and verification to be completed before participating in the consensus of the next epoch, resulting in additional consensus pause and causing large 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 Three 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 permissioned sharded blockchain node rotation and state synchronization optimization, the method comprising: Comprising 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 two: After receiving the synchronization messages from all other shards, first construct a Merkle tree with the random numbers of all shards as leaf nodes, and take the Merkle tree root as the globally consistent global random number; then use the global random number to sort the global node replacement set of the current epoch to obtain the global node determination sequence, and sort all shard ids to obtain the global shard determination sequence, based on the two determination sequences and the number of replacement node set elements of each shard, calculate the replacement node set of the current epoch of the current shard; Step three: After the replacement node receives the global synchronized node exchange set, it starts to request state data and block data from the target shard high reputation value node, while participating in the consensus of the current shard in parallel; when the state synchronization is completed and the next epoch is entered, the replacement node can send a replacement request to the target shard high reputation value node, and after the connection is successfully established, it can join the consensus of the target shard; The high reputation value node of the target shard sends synchronization data to the replacement node in parallel on the basis of normally participating in the consensus of the current shard, and processes the replacement request of the new node, and deletes the replacement nodes of the current shard in proportion after the new node completes the connection establishment, until all new nodes join the consensus of the current shard. 2.The method of claim 1, wherein: In step one, after entering the rotation stage, the high reputation nodes in each shard need to determine the random number of the current epoch of the current shard, and synchronize it to all other shards, the specific steps are as follows: S101: On the basis of normally participating in the consensus, start a round of consensus in parallel, this round of consensus needs to reach a consensus on the local random of the current epoch of the current shard, which is a key input for constructing a globally consistent random source; S102: Concatenate the node ID of each node within the shard with the intra-shard random number localRandom, then calculate its hash value using the system predefined hash function H, and then use the maximum value V of the hash function max Divide by this hash value, so the intra-shard hash value V of each node is obtained i； S103: Obtain the in-chip hash value V of each node i In comparison with the swap-out probability swapP of the current shard and the current epoch, the nodes corresponding to the hash values less than swapP are put into the swap-out node set swapOutMap of the whole shard, where 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 the current shard and the current epoch. Parallelly complete the shard sending S104 and shard receiving S105 synchronization message process, each node continuously listens to Msg data from all shards, until the received random number receivedRandomMap and the replacement node set swapOutMap in the core structure body ShardInfo structure used to store and propagate the key information of the rotation stage are covered all shards in the system, and it is considered that the node completes the global synchronization of the rotation information. 3.The method of claim 2, wherein: The generation process of the random number is as follows: each shard generates a Merkle tree by hashing two types of information, and obtains the tree root as a local random value; the two types of information include: The block root hash rootHashLastEpoch of the last epoch; The aggregation signature aggSignature of the current epoch of the current shard; Build a Merkle tree with the two as leaf nodes, and guarantee that the random number is unpredictable and verifiable through structural determinacy and hash collision resistance, and take the Merkle tree root as localRandom to reach a consensus within the shard through this round of consensus. 4.The method of claim 2, wherein: In S104, the sending message process is as follows: the epoch, the swapOutMap, the localRandom, and the shardId are packaged into a synchronization message Msg; the cross-shard broadcast mechanism is triggered by the high-trust value node, the Gossip protocol is adopted, and the local Msg message is continuously transmitted to other shard nodes until the node confirms that it has received the Msg message from all shards in the network.

5. The method of claim 2, wherein: In S105, the receiving message process is as follows: after receiving the synchronization message Msg sent by other shards, the epoch field is extracted first, and the integrity check and field check of the message structure are completed, then the swapOutMap, the localRandom, and the shardId are extracted from the Msg; each field in the swapOutMap is compared with the swapOutMap in the local ShardInfo, and the data not recorded in the local is added to the swapOutMap in the local storage; the localRandom and the shardId in the message are filled into the receivedRandomMap field in the local ShardInfo as the value and the key respectively, which are used to collect the intra-shard random number of other shards in the current epoch.

6. The method of claim 1, wherein: In step two, the generation and calculation of the swapInMap are as follows: S201: the nodes construct a global Merkle tree GlobalMerkleTree by taking the intra-shard random number of other shards stored in the receivedRandomMap field in the local data structure ShardInfo and the intra-shard random number localRandom of the current shard as leaf nodes in the order of the shard identifier shardId, and calculate the tree root, which is the global random number R; S202: Each node takes all the swap-out nodes from the swapOutMap field of the ShardInfo, concatenates the global random number R with each node identifier nodeId, then calculates the hash value sortKey of the concatenated result, and fills the data pair <sortKey, nodeId> into the sortNodeMap field in the ShardInfo; arranges nodeSetOut in ascending order according to the key, and generates a determined global ordering sequence of swap-out nodes nodeL = [nodeId1, nodeId2, …, nodeId k ]; Since the entire network has the same R and swapOutMap, the ordering L is also globally consistent in the system; S203: Perform the operation in S202 on all shard identifiers, fill the data pair <sortKey, shardId> into the sortShardMap field in the ShardInfo, and sort the sortShardMap in ascending order of the key to generate a determined global shard sorting sequence shardL=[shardId1, shardId2, …, shardId k ]; similarly, the sequence is also globally consistent; S204: the nodes in nodeL are distributed according to the order of shardL, and the number of nodes allocated to a shard is equal to the number of data items with the shard identifier as the value in the swapOutMap field of ShardInfo; when calculating the swapInMap of the current shard, the data pair is added to the swapInMap field of ShardInfo; finally, the isSwapInCalculated field in ShardInfo is set to true, indicating that the rotation node exchange information is completed, and the system can enter the next phase.

7. The method of claim 1, wherein: In step three, the swapOut node exits from the original shard, and the swapIn node establishes a connection with the target shard and synchronizes the state, and the specific steps of the two processes are as follows: S301: the swapOut node reads the target shard to which it will be swapped in from the swapInMap field in the local storage ShardInfo, then obtains the shard object corresponding to the shard identifier through shardToObjectMap, and further extracts the high-trust value node set in the target shard from the object; S302: While still participating in consensus in the original shard, each swap-out node actively sends a state synchronization request to one or more high-trust value nodes in the target shard; S303: After judging that the isSwapInCalculated field in the ShardInfo is true, the high-trust value node starts to construct the synchronization data message StateSnapshot; the high-trust value node initiates a round of consensus in the shard, tries to reach a consensus on the current account state tree snapshot and the block hash from the beginning of the current epoch to the current height, and collects signatures, and packs the two data and the collected aggregate signature as StateSnapshot; S304: After receiving the state synchronization request, the high-trust value node first compares the swapOutMap and swapInMap fields in the local ShardInfo to determine the legitimacy of the request; if the request is legitimate, the high-trust value node will send the StateSnapshot to the requesting swap-out node; at the same time, the high-trust value node will perform its current state synchronization service operation in parallel with its daily consensus task, without pausing the local consensus; S305: After receiving the StateSnapshot from the high-trust value node in the target shard, the swap-out node first verifies the signatures, block hash, and aggregate signature in the state snapshot; on the premise of confirming the legitimacy of the data, the swap-out node recovers the logical state replica in the target shard using the snapshot data, and generates the account database and state machine consistent with the target shard locally; after completing the synchronization, the local ShardInfo is updated to syncStatus = true, indicating that the state synchronization is complete; S306: After the end of the current epoch and the completion of the state synchronization, the swap-out node initiates a connection establishment request to the high-trust value node in the target shard; at this time, the high-trust value node in the target shard includes the request in the next round of consensus initialization in the shard, and updates the member node set of the shard after receiving the connection of the swap-out node; S307: After confirming that the new node has completed state synchronization and the connection is successful, the high-trust value node in the target shard includes it in the next round of consensus in the next epoch; Once the swap-out node successfully participates in the new round of consensus in the target shard, it will clear the local state cache in the old shard, initialize the running context of the new shard; at the same time, according to the swap-out swap-in ratio, the high-trust value node performs the logout operation on the original swap-out node in the shard, deletes the related information from the ShardInfo, and cuts off the communication connection with it; after all the new nodes are successfully connected, all the nodes in the shard complete the node rotation. 8.The method for permissioned sharded blockchain node rotation and state synchronization optimization of claim 7, wherein: In S302, the specific content of the state synchronization request sent by each swap-out node to one or more high-trust value nodes in the target shard includes: node identifier nodeId; the original shard sourceShardId to which the node belongs; the target shard targetShardId to which the node will be swapped in; current epoch number epochIndex; RequestType = "StateSnapshot", The purpose of this request is to let the high-trust value node of the target shard identify the external node to be joined and prepare to send the compressed snapshot data of the current state of the shard to the node.

Images