A method and system for constructing an adaptive dynamic sharding blockchain network

Abstract

The present invention discloses a method and system for constructing an adaptive dynamic sharded blockchain network. The present invention uses a verifiable random function to quickly elect a directory committee and a consensus committee. The directory committee generates a committee status table that records the status of the consensus committee, assisting the consensus committee in reaching consensus. The present invention designs a consensus committee quantity adjustment algorithm that adjusts the number of committees based on transaction processing requirements. The present invention designs a weighting mechanism for the consensus committee to achieve an efficient consensus committee call sequence, thereby improving consensus efficiency. A new consensus method is also proposed to reduce duplicate consensus through threshold signatures. The number of shards in the sharded blockchain of the present invention can be dynamically adjusted, thereby improving consensus efficiency and reducing the overhead of duplicate consensus.

Description

Technical Field

[0001] The present invention belongs to the field of network security technology and relates to a blockchain network construction method and system, and specifically to an adaptive dynamic sharding blockchain network construction method and system. Background Art

[0002] As a distributed ledger technology, blockchain networks are being applied in many fields, including data security and decentralized finance, due to their openness, transparency, and immutability. However, as the number of blockchain nodes increases, the network load increases, severely limiting the scalability of existing blockchain systems. This is because every node in a blockchain network participates in every consensus broadcast of these blockchain protocols. A promising solution to this problem is the sharded blockchain approach, which selects one or more committees from among the blockchain nodes to process transactions.

[0003] Sharded blockchain solutions can be categorized into single-committee and multi-committee solutions based on the number of committees. Single-committee solutions elect only one committee to reach consensus on transactions. However, these solutions cannot achieve parallel consensus. Multi-committee solutions elect multiple committees to reach consensus on transactions in parallel. These solutions focus on improving synergy between committees. As a result, they offer better transaction processing performance than single-committee solutions. While existing multi-committee solutions increase blockchain scalability, they still face several challenges. 1) The number of committees is rigid. Due to inefficient committee formation, existing solutions generate all committees at once during the initialization phase, making it impossible to dynamically adjust the number of committees during the consensus process. 2) The consensus process is inefficient. The consensus efficiency of different committees varies, and the order in which multiple committees reach consensus affects the system's consensus efficiency. 3) Duplicate consensus. In current sharded blockchain solutions, transactions that have already passed intra-committee Byzantine consensus must undergo inter-committee Byzantine consensus again, resulting in duplicate Byzantine consensus broadcasts and unnecessary communication overhead. Summary of the Invention

[0004] In order to improve the consensus efficiency of existing sharded blockchains, the present invention proposes an adaptive dynamic sharded blockchain network construction method and system.

[0005] The technical solution adopted by the method of the present invention is: a method for constructing an adaptive dynamic sharding blockchain network, comprising the following steps:

[0006] Step 1: Blockchain network nodes initialize system parameters {Q,m,vsk i ,vpk i ,tnc,w,cond,s,rd,B}; where Q is the number of transactions processed in one round, m is the number of transactions in a batch, (vpki ,vsk i ) is the blockchain node P i The public and private keys generated for VRF calculation; tnc is the number of nodes in the network that have not been selected into the committee; node P i Maintain VRF seed s and committee expected node number w for VRF calculation and committee election, the initial value of s is s0; node P i Maintain the current consensus round number rd, the blockchain B composed of each block B[rd], and the current consensus batch number cond within the round; the committee is composed of the directory committee and the consensus committee;

[0007] Step 2: At the beginning of the consensus round, the blockchain network nodes select nodes to form the Directory Committee through the Directory Committee Election Protocol;

[0008] Step 3: The directory committee generates a committee status table {L, c(l), p(l), identity information, pk l , tnc}; where L is the current number of consensus committees in this round, c(l) is the weight of each consensus committee, and p(l) is the status flag of each consensus committee; pk l The threshold signature public key for each consensus committee is obtained by sending your own public key after the consensus committee is established;

[0009] Step 4: The directory committee generates its threshold signature;

[0010] Step 5: Blockchain network nodes generate a consensus committee based on the dynamic adjustment mechanism;

[0011] Step 6: The consensus committee generates its threshold signature;

[0012] Step 7: The directory committee generates an efficient consensus sequence based on the committee status table;

[0013] The Directory Committee finds the consensus committee with the maximum efficiency weight c(l) among the idle consensus committees in its committee status record table; the Directory Committee sends a notification to the consensus committee corresponding to the maximum efficiency weight found above, instructing the consensus committee to reach a consensus on the batch of m transactions;

[0014] Step 8: The consensus committee runs the Byzantine Fault Tolerance protocol to reach consensus on the assigned transactions;

[0015] Step 9: At the end of the consensus round, all consensus committees threshold-sign the consensus-completed transaction set and send it to the directory committee;

[0016] Step 10: The Directory Committee verifies the threshold signature and packages the transaction into a block, which is then threshold-signed and broadcast to the entire network.

[0017] Step 11: All nodes in the network verify the threshold signature of the received block and upload it to the chain after verification.

[0018] As a preference, in step 1, the blockchain node P i Generate public and private keys (vpk i ,vsk i )←VRF.KeyGen(1 λ ); Blockchain node P i Broadcast your own public key vpk i And record the public keys of other global nodes; Among them, VRF.KeyGen(1 λ ) represents the generation of VRF public and private keys based on the initial security parameter λ;

[0019] Preferably, the specific implementation of step 2 includes the following sub-steps:

[0020] Step 2.1: Blockchain Node P i Generate a pseudo-random number r through VRF i and a proof of π i ,(r i ,π i )←VRF.GER(vsk i ,s), where if rd=1, then s=s0, if rd≥2, then s=H(B[rd-1]); H(B[rd-1]) represents the hash value of the latest block on the chain;

[0021] Step 2.2: Blockchain Node P i Determine the pseudo-random number r generated by yourself i Whether the condition is met, if r i / 2 λ ≤(w / tnc) indicates that the pseudo-random number r i If the conditions are met, the node is selected into the directory committee;

[0022] Step 2.3: Each blockchain node P selected into the directory committee i Broadcast the pseudo-random number r generated by itself i And prove π i ;

[0023] Step 2.4: All nodes in the network receive the data sent by other nodes (r i ,π i ) after verification; first verify the validity of the pseudo-random number 1←VRF.VER(vpk i ,s,r i,π i ), and then verify whether the pseudo-random number meets the condition r i / 2 λ ≤(w / tnc); If both of the above verifications are passed, the node P i Determine whether to join the selected node set {P1,P3,...,P n-2 ,P n};

[0024] Step 2.5: All network nodes use the Byzantine fault-tolerant consensus to select the node set {P1, P3, ..., P n-2 ,P n}Agreement is reached and the nodes included in the set form the directory committee.

[0025] Preferably, the specific implementation of step 4 includes the following sub-steps:

[0026] Step 4.1: The directory committee has w nodes, the threshold is t, t≤w;

[0027] Step 4.2: Nodes in the directory committee negotiate to generate the public key and private key {pk d ,sk i}P i ∈[w]←TS.Gen({1 λ ,w,t}P i ∈[w]); {pk d ,sk i}P i Represents node P i The threshold public key and your own private key;

[0028] Step 4.3: The directory committee sends its threshold signature public key pk d Broadcast to all blockchain nodes;

[0029] Step 4.4: The blockchain node receives the threshold signature public key pk from the directory committee d Then, store it locally.

[0030] Preferably, the specific implementation of step 5 includes the following sub-steps:

[0031] Step 5.1: When the transaction pool reaches m transactions, identify the status of each consensus committee based on the consensus committee weight c(l) and state identifier p(l) recorded in the committee status table;

[0032] Step 5.2: The Directory Committee traverses the committee states and finds an idle consensus committee with the highest weight. If such a committee exists, the Directory Committee assigns m transactions in the transaction pool to that consensus committee for processing. If no idle consensus committee exists, the Directory Committee elects a new consensus committee from the remaining non-committee nodes. If the number of remaining nodes in this round is less than w, no new consensus committee is generated and the Directory Committee must wait for a free consensus committee to process this batch of transactions.

[0033] Step 5.3: Elect a new consensus committee. Blockchain node P that is not in any committee j Generate a pseudo-random number r j and a proof of π j , where (r j ,π j )←VRF.GER(vsk j , s), where if rd=1, s=H(s0+cond), if rd≥2, s=H(B[rd-1]+cond); H() represents a hash operation;

[0034] Step 5.4: Blockchain Node P j Determine the pseudo-random number r generated by yourself j Whether the condition is met, if r j / 2 λ ≤(w / tnc) indicates that the pseudo-random number r j If the conditions are met, the node is selected into the consensus committee;

[0035] Step 5.5: Each blockchain node P selected into the consensus committee j Broadcast the pseudo-random number r generated by itself j And prove π j ;

[0036] Step 5.6: The directory committee node receives the (r j ,π j ) after verification; first verify the validity of the pseudo-random number 1←VRF.VER(vpk j ,s,r j ,π j ), and then verify whether the pseudo-random number meets the condition r j / 2 λ ≤(w / tnc); If both of the above verifications are passed, the node P j Determine whether to join the selected node set {P1,P3,...,P k-2 ,P k};

[0037] Step 5.7: All nodes in the network use the Byzantine fault-tolerant consensus to select the node set {P1, P3, ..., P k-2 ,P k}A consensus is reached and the nodes included in the set form a new consensus committee;

[0038] Step 5.8: Based on the record of committee status in the catalog committee, the consensus committee number generated this time is l = L + 1;

[0039] Step 5.9: Set the efficiency weight c(l)=0 and the status flag P(l)=0 of the newly generated consensus committee.

[0040] Preferably, the specific implementation of step 6 includes the following sub-steps:

[0041] Step 6.1: The consensus committee has w nodes, the threshold is t, t≤w;

[0042] Step 6.2: The nodes in the consensus committee negotiate to generate the public key and private key {pk d ,sk j}P j ∈[w]←TS.Gen({1 λ ,w,t}P j ∈[w]); {pk d ,sk j}P j Represents node P j The threshold public key and your own private key;

[0043] Step 6.3: The consensus committee sends its threshold signature public key pk d broadcast to the Directory Committee;

[0044] Step 6.4: The Directory Committee receives the threshold signature public key pk from the Consensus Committee d Then, store it locally.

[0045] Preferably, the specific implementation of step 9 includes the following sub-steps:

[0046] Step 9.1: At the end of this round of consensus, the consensus committee will complete the consensus transaction set M. l Perform threshold signature and aggregate into complete threshold signature ({M l ,σ l}V)←TS.Sign({sk i ,M l}P i ∈[t]); where σ lRepresents a complete threshold signature; V represents a threshold signature aggregation node, which is automatically assumed by the node that has collected the threshold number of signatures; TS.Sign() represents the node P i For transaction set M l Use your own threshold private key sk i Perform threshold signature; i ,M l}P i Represents node P i For transaction set M l Use your own threshold private key sk i Perform threshold signing;

[0047] Step 9.2: The consensus committee will send transaction set M l and the complete threshold signature σ l Broadcast to the Directory Committee.

[0048] Preferably, the specific implementation of step 10 includes the following sub-steps:

[0049] Step 10.1: The Directory Committee receives the threshold signature σ from the Consensus Committee l and transaction set M l ;

[0050] Step 10.2: The Directory Committee finds the corresponding threshold signature public key pk from the Committee State Record Table l Threshold signature σ l Verify, 1←TS.Verify(pk l ,(M l ,σ l ));

[0051] Step 10.3: The Directory Committee collects the transaction set M sent by the Consensus Committee l Store locally;

[0052] Step 10.4: After the Directory Committee has collected all Q transactions in this round, it will merge the Q transactions into a block B[rd] in ascending order of batch number l.

[0053] Step 10.5: The directory committee performs a threshold signature on B[rd]. In this signature generation protocol, participant P i With its private key sk i and block B[rd] as input, the aggregator V passes ({B[rd],σ d}V)←TS.Sign({sk i ,B[rd]}P i,i ∈[t]) output block B[rd] and complete threshold signature σ d ;

[0054] Step 10.6: The Directory Committee sends block B[rd] and the full threshold signature σ d Broadcast to all blockchain nodes.

[0055] Preferably, the specific implementation of step 11 includes the following sub-steps:

[0056] Step 11.1: The blockchain node receives the threshold signature σ from the directory committee d After the block B[rd], find the corresponding threshold signature public key pk d Verify; Blockchain node check 1←TS.Verify(pk d ,(B[rd],σ d )) whether it is satisfied;

[0057] Step 11.2: After the threshold signature is verified, the blockchain node stores the block B[rd] received from the directory committee locally and then uploads it to the chain.

[0058] The technical solution adopted by the system of the present invention is: an adaptive dynamic sharding blockchain network construction system, including the following modules:

[0059] The initial setting module is used to generate the parameters of the mechanism within the blockchain system, VRF parameters, and threshold signature parameters based on security parameters;

[0060] The committee election module is used to elect the directory committee and consensus committee from the blockchain network nodes based on the VRF algorithm;

[0061] The directory committee module is used to generate and maintain the committee status record table to assist in the subsequent consensus committee election and dynamic adjustment of the number of consensus committees;

[0062] The consensus committee module is used to reach consensus on the assigned transactions and send the agreed transaction set to the directory committee at the end of the consensus round;

[0063] The consensus committee dynamic adjustment module is used to increase or mobilize the consensus committee to reach consensus according to the system transaction processing needs;

[0064] The efficient consensus sequence module is used to select the most efficient consensus committee for consensus based on the idleness and consensus efficiency of the consensus committee, thus forming an efficient consensus sequence;

[0065] The global consensus module uses threshold signatures to enable the directory committee to verify the transaction set sent by the consensus committee.

[0066] Compared with the prior art, the present invention has the following beneficial effects:

[0067] (1) The number of shards (committees) of the sharded blockchain of the present invention can be dynamically adjusted according to the transaction processing demand. When the transaction processing demand in the network is small, the number of consensus committees can be reduced, thereby saving network resources; when the transaction processing demand is high, the number of consensus committees can be increased, thereby increasing the system carrying capacity.

[0068] (2) The shards (committees) of the sharded blockchain of the present invention can reach consensus on transactions in the most efficient order, and can assign the most efficient committee among the currently idle consensus committees to each batch of transactions that require consensus, thereby improving the utilization rate of efficient committees and thus improving the consensus efficiency of the entire consensus process.

[0069] (3) The sharded blockchain of the present invention reduces the need for repeated consensus processes when the sharded consensus transaction results are finally packaged into blocks. The verification of threshold signatures replaces the Byzantine consensus of the directory committee on all transactions agreed upon by the consensus committee, reducing the overall communication overhead of the system and improving the overall consensus speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] The technical solution of the present invention is further illustrated below using embodiments and specific implementation methods. In addition, some drawings are also used in the process of illustrating the technical solution. For those skilled in the art, other drawings and the intention of the present invention can be obtained based on these drawings without making any creative efforts.

[0071] Figure 1 is a flow chart of a method according to an embodiment of the present invention;

[0072] Figure 2 Schematic diagram of the operation flow of an embodiment of the present invention;

[0073] Figure 3 A schematic diagram of the directory committee election process according to an embodiment of the present invention;

[0074] Figure 4 This is a schematic diagram of the consensus committee election process according to an embodiment of the present invention;

[0075] Figure 5 This is a schematic diagram of a consensus mediation committee according to an embodiment of the present invention;

[0076] Figure 6 This is a schematic diagram of the global consensus process of the embodiment of the present invention;

[0077] Figure 7 Schematic diagram of a system model according to an embodiment of the present invention;

[0078] Figure 8 This is a diagram of Dyshard's transaction confirmation delay under different block sizes and bandwidths in this experiment;

[0079] Figure 9 This is a diagram of Dyshard's transaction throughput TPS value under different block sizes and bandwidths in this experiment;

[0080] Figure 10 This is a diagram of Dyshard's transaction confirmation delay under different committee node sizes and different bandwidths in this experiment;

[0081] Figure 11 This is a diagram of the Dyshard transaction throughput TPS value under different committee node sizes and different bandwidths in this experiment;

[0082] Figure 12 Schematic diagram of transaction confirmation delay for Dyshard with the optimal block size and committee size in this experiment;

[0083] Figure 13 This is a comparison diagram of transaction confirmation delays between Dyshard and other solutions at different transaction injection speeds in this experiment;

[0084] Figure 14 This is a comparison diagram of the transaction throughput TPS values ​​of Dyshard and other solutions at different transaction injection speeds in this experiment;

[0085] Figure 15 This is a diagram comparing the committee load at different transaction injection speeds between Dyshard and other schemes in this experiment.

[0086] Figure 16 This is a comparison diagram of the transaction throughput TPS values ​​of Dyshard and Dyshard (unweighted) under different bandwidths in this experiment;

[0087] Figure 17 This is a diagram comparing the transaction confirmation delays of Dyshard and Dyshard (unweighted) at different bandwidths in this experiment. DETAILED DESCRIPTION

[0088] In order to facilitate ordinary technicians in this field to understand and implement the present invention, the present invention is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the implementation examples described herein are only used to illustrate and explain the present invention and are not used to limit the present invention.

[0089] Please see Figure 1 and Figure 2 This embodiment provides a method for constructing an adaptive dynamic sharding blockchain network, which includes the following steps:

[0090] Step 1: The blockchain network nodes generate some parameters for system initialization based on the security parameter λ;

[0091] In one embodiment, the specific implementation of step 1 includes the following sub-steps:

[0092] Step 1.1: Set the initial seed value s0 when the system node runs VRF, and the expected number of nodes w in each committee; the committee consists of the directory committee and the consensus committee; Step 1.2: Each blockchain node P i Generate public and private keys (vpk i ,vsk i )←VRF.KeyGen(1 λ ); among them, 1 λ Represents security parameters, VRF.KeyGen(1 λ ) indicates that the VRF public key and private key are generated according to the initial security parameter λ;

[0093] Step 1.3: Each blockchain node P i Broadcast your own public key vpk i And record the public keys of other global nodes;

[0094] Step 1.4: Each node locally maintains the following information as the node state {Q, m, vski, vpki, tnc, w, cond, s, rd, B}. Where Q is the number of transactions processed in a round, and m is the number of transactions in a batch. When the transaction pool of a blockchain node reaches m transactions, the m transactions are packaged into a batch and a consensus committee is selected to reach consensus on the batch. After reaching consensus on the Q transactions, the round ends. Each consensus committee can only process one batch of transactions at a time. Node P i Need to maintain your own vsk i , and maintain vpk of all nodes i , used for VRF calculation. tnc is the number of nodes in the network that are not elected to the committee. Node P i Maintain VRF seed s (initially s0) and expected number of committee nodes w for VRF calculation and committee election. i Maintain the current consensus round number rd, the blockchain B composed of each block B[rd], and the current consensus batch number cond within the round.

[0095] Step 2: At the beginning of the consensus round, the blockchain network nodes select nodes to form the Directory Committee through the Directory Committee Election Protocol;

[0096] Please see Figure 3 In one embodiment, the specific implementation of step 2 includes the following sub-steps:

[0097] Step 2.1: Each blockchain node P i Generate a pseudo-random number r through VRF iand a proof of π i ,(r i ,π i )←VRF.GER(vsk i ,s), where if rd=1, then s=s0, if rd≥2, then s=H(B[rd-1]); H(B[rd-1]) represents the hash value of the latest block, which is included in the VRF technology;

[0098] Step 2.2: Each blockchain node P i Determine the pseudo-random number r generated by yourself i Whether the condition is met, if r i / 2 λ ≤(w / tnc) indicates that the pseudo-random number r i If the conditions are met, the node is selected into the directory committee;

[0099] Step 2.3: Each blockchain node P selected into the directory committee i Broadcast the pseudo-random number r generated by itself i And prove π i ;

[0100] Step 2.4: All nodes in the network receive the data sent by other nodes (r i ,π i ) after verification; first verify the validity of the pseudo-random number 1←VRF.VER(vpk i ,s,r i ,π i ), and then verify whether the pseudo-random number meets the condition r i / 2 λ ≤(w / tnc); If both of the above verifications are passed, the node P i Determine whether to join the selected node set {P1,P3,...,P n-2 ,P n}; The function VRF.VER() is included in the VRF technology;

[0101] Step 2.5: All nodes in the network use the Byzantine fault-tolerant consensus to select the node set {P1, P3, ..., P n-2 ,P n}Agreement is reached and the nodes included in the set form the directory committee.

[0102] Step 3: The catalog committee generates a committee status table that records the status of the consensus committee;

[0103] In one embodiment, the directory committee establishes a committee status record table {L, c(l), p(l), identity information, pk l, tnc} records the identity information of the consensus committee nodes and other information of the consensus committee. After the directory committee is established, all nodes in the directory committee maintain this state and update the state when receiving changes to the consensus committee or consensus committee nodes. The committee state record table needs to maintain the current number L of consensus committees in this round, and update L in time as the number of consensus committees increases. The committee state record table records the weight c(l) of each consensus committee and updates each weight c(l) in time according to the performance of each consensus committee. Suppose a consensus committee takes time t to reach consensus on a batch of transactions. In this experiment, the weight of the consensus committee is set to c(l) = 1 / t. The committee state record table records the status flag p(l) of each consensus committee. When the consensus committee l is idle, the value of p(l) is updated to 1, otherwise it is updated to 0. The committee state record table records the identity information of the nodes that have been selected into the directory committee or consensus committee. This information is used to assist in the rapid formation of the consensus committee during the committee generation process. The committee state record table records the threshold signature public key pk of each consensus committee l (Wait for the corresponding public key to be sent after the consensus committee is established) to assist in the threshold verification between the consensus committee and the directory committee during the overall consensus process. The committee status record table records the total number of nodes tnc that have not joined the committee (directory committee and consensus committee). Tnc is used in the VRF calculation during the committee generation process to determine whether the node is selected as a committee node. i / 2 λ ≤(w / tnc).

[0104] Step 4: The directory committee generates its threshold signature;

[0105] In one embodiment, the specific implementation of step 4 includes the following sub-steps:

[0106] Step 4.1: The directory committee has w nodes (w is the number of nodes in each committee), and the threshold is t, t≤w;

[0107] Step 4.2: Nodes in the directory committee negotiate to generate the public key and private key {pk d ,sk i}P i ∈[w]←TS.Gen({1 λ ,w,t}P i ∈[w]); Function TS.Gen() is included in the threshold signature technology; {pk d ,sk i}P i Represents node P i The threshold public key pk d and threshold private key sk i ;

[0108] Step 4.3: The directory committee sends its threshold signature public key pk d Broadcast to all blockchain nodes;

[0109] Step 4.4: The blockchain node receives the threshold signature public key pk from the directory committee d Then, store it locally.

[0110] Step 5: Blockchain network nodes generate a consensus committee based on the dynamic adjustment mechanism;

[0111] Please see Figure 14 In one embodiment, the specific implementation of step 5 includes the following sub-steps:

[0112] Step 5.1: When the transaction pool reaches m transactions, the system identifies the status of each consensus committee based on the consensus committee weight c(l) and state identifier p(l) recorded in the committee status table;

[0113] Step 5.2: First, the Directory Committee traverses the committee states and finds an idle consensus committee with the highest weight. Then, if such a committee exists, the Directory Committee assigns m transactions in the transaction pool to that consensus committee for processing. If no idle consensus committee exists, the Directory Committee elects a new consensus committee from the remaining non-committee nodes. If there are insufficient nodes remaining in this round (the number of remaining nodes is less than w), no new consensus committee is generated. The Directory Committee must wait for a free consensus committee to process this batch of transactions.

[0114] Step 5.3: Elect a new consensus committee. Each blockchain node P that is not in any committee j Generate a pseudo-random number r j and a proof of π j , where (r j ,π j )←VRF.GER(vsk j , s), where if rd=1, s=H(s0+cond), if rd≥2, s=H(B[rd-1]+cond); H() represents a hash operation on the data in the brackets;

[0115] Step 5.4: Each blockchain node P j Determine the pseudo-random number r generated by yourself j Whether the condition is met, if r j / 2 λ ≤(w / tnc) indicates that the pseudo-random number r j If the conditions are met, the node is selected into the consensus committee;

[0116] Step 5.5: Each blockchain node P selected into the consensus committee j Broadcast the pseudo-random number r generated by itself j And prove π j ;

[0117] Step 5.6: The directory committee receives the (r j ,π j ) after verification; first verify the validity of the pseudo-random number 1←VRF.VER(vpk j ,s,r j ,π j ), and then verify whether the pseudo-random number meets the condition r j / 2 λ ≤(w / tnc); If both of the above verifications are passed, the node P j Determine whether to join the selected node set {P1,P3,...,P k-2 ,P k};

[0118] Step 5.7: All nodes in the network use the Byzantine fault-tolerant consensus to select the node set {P1, P3, ..., P k-2 ,P k}A consensus is reached and the nodes included in the set form a new consensus committee;

[0119] Step 5.8: Based on the record of committee status in the catalog committee, the consensus committee number generated this time is l = L + 1 (L is the number of existing consensus committees);

[0120] Step 5.9: The system sets the efficiency weight c(l)=0 and the status flag P(l)=0 of the newly generated consensus committee.

[0121] Step 6: The consensus committee generates its threshold signature;

[0122] In one embodiment, the specific implementation of step 6 includes the following sub-steps:

[0123] Step 6.1: The consensus committee has w nodes (w is the number of nodes in each committee), with a threshold of t, t≤w;

[0124] Step 6.2: The nodes in the consensus committee negotiate to generate the public key and private key {pk d ,sk i}P i,i ∈[w]←TS.Gen({1 λ ,w,t}P i,i ∈[w]); Function TS.Gen() is included in the threshold signature technology; {pkd ,sk i}P i Represents node P i The threshold public key pk d and threshold private key sk i ;

[0125] Step 6.3: The consensus committee sends its threshold signature public key pk d broadcast to the Directory Committee;

[0126] Step 6.4: The Directory Committee receives the threshold signature public key pk from the Consensus Committee d Then, store it locally.

[0127] Step 7: The directory committee generates an efficient consensus sequence based on the committee status table;

[0128] Please see Figure 5 In one embodiment, the directory committee finds the consensus committee with the maximum efficiency weight c(l) among the idle consensus committees in its committee status record table; the directory committee sends a notification to the consensus committee corresponding to the maximum efficiency weight found above, instructing the consensus committee to reach a consensus on the batch of m transactions;

[0129] Step 8: The consensus committee runs the Byzantine Fault Tolerance protocol to reach consensus on the assigned transactions;

[0130] Please see Figure 6 In one embodiment, when a consensus committee is selected, it requires a specific consensus algorithm to reach consensus on transactions. The consensus operation within the committee is decoupled from the rest of the solution. Committees (directory committee and consensus committee) can choose different blockchain consensus protocols to reach consensus on signed transactions or committee state changes. For example, the committee can use the Dumbo consensus protocol.

[0131] Step 9: At the end of the consensus round, all consensus committees threshold-sign the consensus-completed transaction set and send it to the directory committee;

[0132] In one embodiment, the specific implementation of step 9 includes the following sub-steps:

[0133] Step 9.1: At the end of this round of consensus, the consensus committee will complete the consensus transaction set M. l Perform threshold signature and aggregate into complete threshold signature ({M l ,σ l}V)←TS.Sign({sk i ,M l}P i,i ∈[t]); where σl Indicates a complete threshold signature. V represents the threshold signature aggregation node, which is automatically assumed by the node that has collected the threshold number of signatures. TS.Sign() represents the node P i For transaction set M l Use your own threshold private key sk i Perform threshold signature. i ,M l}P i Represents node P i For transaction set M l Use your own threshold private key sk i Perform threshold signing.

[0134] Step 9.2: The consensus committee will send transaction set M l and the complete threshold signature σ l Broadcast to the Directory Committee.

[0135] Step 10: The Directory Committee verifies the threshold signature and packages the transaction into a block, which is then threshold-signed and broadcast to the entire network.

[0136] In one embodiment, the specific implementation of step 10 includes the following sub-steps:

[0137] Step 10.1: The Directory Committee receives the threshold signature σ from the Consensus Committee l and transaction set M l ;

[0138] Step 10.2: The Directory Committee finds the corresponding threshold signature public key pk from the Committee State Record Table l Threshold signature σ l Verify, 1←TS.Verify(pk l ,(M l ,σ l )); Function TS.Verify() is included in the threshold signature technology;

[0139] Step 10.3: The Directory Committee collects the transaction set M sent by the Consensus Committee l Store locally;

[0140] Step 10.4: After the Directory Committee has collected all Q transactions in this round, it will merge the Q transactions into a block B[rd] in ascending order of batch number l.

[0141] Step 10.5: The directory committee performs a threshold signature on B[rd]. In this signature generation protocol, participant P i With its private key sk iand block B[rd] as input, the aggregator V passes ({B[rd],σ d}V)←TS.Sign({sk i ,B[rd]}P i,i ∈[t]) output block B[rd] and complete threshold signature σ d ;

[0142] Step 10.6: The Directory Committee sends block B[rd] and the full threshold signature σ d Broadcast to all blockchain nodes.

[0143] Step 11: All nodes in the network verify the threshold signature of the received block and upload it to the chain after verification;

[0144] In one embodiment, the specific implementation of step 11 includes the following sub-steps:

[0145] Step 11.1: The blockchain node receives the threshold signature σ from the directory committee d After the block B[rd], find the corresponding threshold signature public key pk d Verify; Blockchain node check 1←TS.Verify(pk d ,(B[rd],σ d )) whether it is satisfied;

[0146] Step 11.2: After the threshold signature is verified, the blockchain node stores the block B[rd] received from the directory committee locally and then uploads it to the chain.

[0147] Please see Figure 7 This embodiment also provides an adaptive dynamic sharding blockchain system, including the following modules:

[0148] The initial setting module is used to generate the parameters of the mechanism within the blockchain system, VRF parameters, and threshold signature parameters based on security parameters;

[0149] The committee election module is used to elect the directory committee and consensus committee from the blockchain network nodes based on the VRF algorithm;

[0150] The directory committee module is used to generate and maintain the committee status record table to assist in the subsequent consensus committee election and dynamic adjustment of the number of consensus committees;

[0151] The consensus committee module is used to reach consensus on the assigned transactions and send the agreed transaction set to the directory committee at the end of the consensus round;

[0152] The consensus committee dynamic adjustment module is used to increase or mobilize the consensus committee to reach consensus according to the system transaction processing needs;

[0153] The efficient consensus sequence module is used to select the most efficient consensus committee for consensus based on the idleness and consensus efficiency of the consensus committee, thus forming an efficient consensus sequence;

[0154] The global consensus module uses threshold signatures to enable the directory committee to verify the transaction set sent by the consensus committee.

[0155] The present invention is further described below through specific experiments.

[0156] First, experiments were conducted to determine the optimal block size and committee node size for system performance. Dyshard was then experimentally demonstrated to dynamically adjust the number of committees based on demand. Next, the experiment demonstrated that the optimal committee consensus sequence can improve transaction throughput and reduce transaction latency. Finally, the experiment compared Dyshard with ELASTICO, OmniLedger, and RapidChain in terms of transaction throughput per second (TPS) and transaction confirmation latency.

[0157] (1) Experimental configuration

[0158] All experimental systems were developed using Python (version 3.8). The entire blockchain network was deployed on four servers (Intel Xeon processors, 8GB of RAM, and Ubuntu Desktop 16.04-64). Different network ports were used to simulate different blockchain nodes, and the system can accommodate up to 5,000 nodes. Furthermore, this experiment used Dumbo as the committee's internal formula protocol. To simulate the communication latency of blockchain nodes, the transmission delay of each message was set to 100 milliseconds, and the communication bandwidth per node was set to 20 Mbps, similar to Bitcoin Core. Finally, each transaction was configured to be 512 bytes.

[0159] (2) The data indicators used in this experiment;

[0160] Transaction confirmation latency refers to the average time it takes for a transaction to be generated and finally uploaded to the blockchain. Transaction throughput (TPS) is the number of transactions per second that a blockchain system reaches consensus on. This experiment uses TPS as a metric for system transaction throughput. Committee load refers to the rate at which a committee processes transactions, also expressed in TPS.

[0161] (3) Explore the optimal block size and committee size;

[0162] To determine the optimal block size, this experiment measured the impact of different block sizes on Dyshard throughput and latency at different bandwidths. This experiment set the entire network to consist of 2,000 nodes, and set the bandwidth to 5MB, 10MB, 15MB, and 20MB, measuring the transaction throughput (TPS) and transaction confirmation latency corresponding to block sizes from 128KB to 4,096KB at each bandwidth. Figure 8 and Figure 9 As shown in the figure, under different bandwidths, a larger block size can bring higher transaction throughput TPS, but it also brings higher transaction confirmation delay. Figure 8 The analysis shown shows that when the block size is below 2,048KB, the transaction confirmation delay remains below 10 seconds; when the block size is larger than 2,048KB, the transaction confirmation delay increases significantly. Therefore, 2,048KB is the optimal block size.

[0163] This experiment experimentally determined the optimal value w for the number of nodes in a single Dyshard committee. By recording the transaction confirmation delay and transaction throughput TPS under different committee node sizes and bandwidths, this experiment obtained the optimal value for the number of nodes in the committee. This experiment set the node size of the entire network to 2,000 and the bandwidth to 5MB, 10MB, 15MB, and 20MB respectively. Figure 10 and Figure 11 As shown, as the number of committee nodes increases, Dyshard's TPS decreases and its transaction confirmation latency increases. Based on security analysis, when the total number of nodes is 2,000 and the total number of nodes in a committee is greater than 200, the committee is secure. Therefore, 200 is selected as the optimal number of nodes included in each committee.

[0164] Figure 12 The experiment shows how the transaction confirmation delay changes with the transaction generation speed when the block size of Dyshard is 2,048KB and the number of committee nodes is 200. The slow increase in transaction confirmation delay indicates that the optimal parameter setting of this experiment is effective.

[0165] (4) Dynamic adjustments of Dyshard’s committee;

[0166] This experiment varied the transaction injection rate to test the performance of Dyshard, ELASTICO, OmniLedger, and RapidChain, thereby testing the effectiveness of Dyshard's committee dynamic adjustment. This experiment set the total number of nodes in the blockchain network to 2,000, and the number of shards for ELASTICO, Omniledger, and RapidChain to 5. This experiment varied the transaction injection rate and recorded transaction confirmation latency, transaction throughput (TPS), and committee load. The results are shown in Figure 2. Figure 13 、 Figure 14 and Figure 15 As shown in the figure, the transaction confirmation latency of ELASTICO, Omniledger, and RapidChain increases significantly with increasing transaction injection rate. However, the transaction confirmation latency of Dyshard does not increase significantly with increasing transaction injection rate. The transaction throughput (TPS) of ELASTICO, Omniledger, and RapidChain increases less than that of Dyshard. The committee load of Dyshard increases much more slowly than that of other schemes. The results show that Dyshard can dynamically adjust the number of consensus committees based on transaction processing needs, maintaining a stable transaction confirmation latency and increasing its transaction processing speed (TPS) as the transaction injection rate increases.

[0167] (5) optimal committee consensus sequence;

[0168] This experiment tests the effectiveness of the optimal committee consensus sequence. In this experiment, Dyshard without committee weights is called Dyshard (no weight). This experiment sets the total number of nodes in the blockchain network to 2000. This experiment records the transaction throughput TPS and transaction confirmation delay corresponding to Dyshard and Dyshard (no weight) under different bandwidths. The results are as follows Figure 16 and Figure 17 As shown in the figure, after designing the committee weights, Dyshard achieves higher transaction throughput (TPS) and lower transaction confirmation latency than Dyshard (without weights). In summary, the optimal committee formula sequence is effective.

[0169] This invention uses a dynamic sharding blockchain approach to effectively address the aforementioned issues, enabling dynamic adjustment of the number of committees. This allows the number of committees to be dynamically adjusted based on transaction processing needs. This dynamically adjusts the consensus order of committees, improving the efficiency of the consensus process.

[0170] It should be understood that the embodiments described above are only some of the embodiments of the present invention, rather than all of the embodiments. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention may be arbitrarily combined with each other to form a feasible technical solution. Such combination is not restricted by the order of steps and / or structural composition mode, but must be based on the ability of ordinary technicians in this field to implement it. When the combination of technical solutions is mutually inconsistent or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0171] It should be understood that the above description of the preferred embodiment is relatively detailed and cannot be regarded as limiting the scope of protection of the patent of the present invention. Under the guidance of the present invention, ordinary technicians in this field can also make substitutions or modifications without departing from the scope of protection of the claims of the present invention, which all fall within the scope of protection of the present invention. The scope of protection requested by the present invention shall be based on the attached claims.

Claims

1. A method for constructing an adaptive dynamic sharding blockchain network, characterized in that: The following steps are involved: Step 1: Blockchain network nodes initialize system parameters {Q,m,vsk i ,vpk i ,tnc,w,cond,s,rd,B}; where Q is the number of transactions processed in one round, m is the number of transactions in a batch, (vpk i ,vsk i ) is the blockchain node P i The public and private keys generated for VRF calculation; tnc is the number of nodes in the network that have not been selected into the committee; node P i Maintain VRF seed s and committee expected node number w for VRF calculation and committee election, the initial value of s is s0; node P i Maintain the current consensus round number rd, the blockchain B consisting of each block B[rd], and the current consensus batch number cond within the round; Said committee consists of a catalogue committee and a consensus committee; Step 2: At the beginning of the consensus round, the blockchain network nodes select nodes to form the Directory Committee through the Directory Committee Election Protocol; Step 3: The directory committee generates a committee status table {L, c(l), p(l), identity information, pk l , tnc}; where L is the current number of consensus committees in this round, c(l) is the efficiency weight of each consensus committee, and p(l) is the status flag of each consensus committee; pk l The threshold signature public key for each consensus committee is obtained by sending your own public key after the consensus committee is established; Step 4: The directory committee generates its threshold signature; Step 5: Blockchain network nodes generate a consensus committee based on the dynamic adjustment mechanism; The specific implementation of step 5 includes the following sub-steps: Step 5.1: When the transaction pool reaches m transactions, identify the status of each consensus committee based on the consensus committee weight c(l) and state identifier p(l) recorded in the committee status table; Step 5.2: The Directory Committee traverses the committee states and finds an idle consensus committee with the highest weight. If such a committee exists, the Directory Committee assigns m transactions in the transaction pool to that consensus committee for processing. If no idle consensus committee exists, the Directory Committee elects a new consensus committee from the remaining non-committee nodes. If the number of remaining nodes in this round is less than w, no new consensus committee is generated and the Directory Committee must wait for a free consensus committee to process this batch of transactions. Step 5.3: Elect a new consensus committee. Blockchain node P that is not in any committee j Generate a pseudo-random number r j and a proof of π j , where (r j ,π j )←VRF.GER(vsk j , s), where if rd=1, s=H(s0+cond), if rd≥2, s=H(B[rd-1]+cond); H() represents a hash operation; Step 5.4: Blockchain Node P j Determine the pseudo-random number r generated by yourself j Whether the condition is met, if r j / 2 λ ≤(w / tnc) indicates that the pseudo-random number r j If the conditions are met, the node is selected into the consensus committee; Step 5.5: Each blockchain node P selected into the consensus committee j Broadcast the pseudo-random number r generated by itself j And prove π j ; Step 5.6: The directory committee node receives the (r j ,π j ) after verification; first verify the validity of the pseudo-random number 1←VRF.VER(vpk j ,s,r j ,π j ), and then verify whether the pseudo-random number meets the condition r j / 2 λ ≤(w / tnc); If both of the above verifications are passed, the node P j Determine whether to join the selected node set {P1,P3,...,P k-2 ,P k }; Step 5.7: All nodes in the network use the Byzantine fault-tolerant consensus to select the node set {P1, P3, ..., P k-2 ,P k }A consensus is reached and the nodes included in the set form a new consensus committee; Step 5.8: Based on the record of committee status in the catalog committee, the consensus committee number generated this time is l = L + 1; Step 5.9: Set the efficiency weight c(l) of the newly generated consensus committee to 0 and the status flag P(l) to 0; Step 6: The consensus committee generates its threshold signature; Step 7: The directory committee generates an efficient consensus sequence based on the committee status table; The Directory Committee finds the consensus committee with the maximum efficiency weight c(l) among the idle consensus committees in its committee status record table; the Directory Committee sends a notification to the consensus committee corresponding to the maximum efficiency weight found above, instructing the consensus committee to reach a consensus on the batch of m transactions; Step 8: The consensus committee runs the Byzantine Fault Tolerance protocol to reach consensus on the assigned transactions; Step 9: At the end of the consensus round, all consensus committees threshold-sign the consensus-completed transaction set and send it to the directory committee; Step 10: The Directory Committee verifies the threshold signature and packages the transaction into a block, which is then threshold-signed and broadcast to the entire network. Step 11: All nodes in the network verify the threshold signature of the received block and upload it to the chain after verification.

2. The method for constructing an adaptive dynamic sharding blockchain network according to claim 1, characterized in that: In step 1, blockchain node P i Generate public and private keys (vpk i ,vsk i )←VRF.KeyGen(1 λ ); Blockchain node P i Broadcast your own public key vpk i And record the public keys of other global nodes; Among them, VRF.KeyGen(1 λ ) indicates that the VRF public and private keys are generated based on the initial security parameter λ.

3. The method for constructing an adaptive dynamic sharding blockchain network according to claim 1, characterized in that: The specific implementation of step 2 includes the following sub-steps: Step 2.1: Blockchain Node P i Generate a pseudo-random number r through VRF i and a proof of π i ,(r i ,π i )←VRF.GER(vsk i ,s), where if rd=1, then s=s0, if rd≥2, then s=H(B[rd-1]); H(B[rd-1]) represents the hash value of the latest block on the chain; Step 2.2: Blockchain Node P i Determine the pseudo-random number r generated by yourself i Whether the condition is met, if r i / 2 λ ≤(w / tnc) indicates that the pseudo-random number r i If the conditions are met, the node is selected into the directory committee; Step 2.3: Each blockchain node P selected into the directory committee i Broadcast the pseudo-random number r generated by itself i And prove π i ; Step 2.4: All nodes in the network receive the data sent by other nodes (r i ,π i ) after verification; first verify the validity of the pseudo-random number 1←VRF.VER(vpk i ,s,r i ,π i ), and then verify whether the pseudo-random number meets the condition r i / 2 λ ≤(w / tnc); If both of the above verifications are passed, the node P i Determine whether to join the selected node set {P1,P3,...,P n-2 ,P n }; Step 2.5: All network nodes use the Byzantine fault-tolerant consensus to select the node set {P1, P3, ..., P n-2 ,P n }Agreement is reached and the nodes included in the set form the directory committee.

4. The method for constructing an adaptive dynamic sharding blockchain network according to claim 1, characterized in that: The specific implementation of step 4 includes the following sub-steps: Step 4.1: The directory committee has w nodes, the threshold is t, t≤w; Step 4.2: Nodes in the directory committee negotiate to generate the public key and private key {pk d ,sk i }P i ∈[w]←TS.Gen({1 λ ,w,t}P i ∈[w]); {pk d ,sk i }P i Represents node P i The threshold public key and your own private key; Step 4.3: The directory committee sends its threshold signature public key pk d Broadcast to all blockchain nodes; Step 4.4: The blockchain node receives the threshold signature public key pk from the directory committee d Then, store it locally.

5. The method for constructing an adaptive dynamic sharding blockchain network according to claim 1, characterized in that: The specific implementation of step 6 includes the following sub-steps: Step 6.1: The consensus committee has w nodes, the threshold is t, t≤w; Step 6.2: The nodes in the consensus committee negotiate to generate the public key and private key {pk d ,sk j }P j ∈[w]←TS.Gen({1 λ ,w,t}P j ∈[w]); {pk d ,sk j }P j Represents node P j The threshold public key and your own private key; Step 6.3: The consensus committee sends its threshold signature public key pk d broadcast to the Directory Committee; Step 6.4: The Directory Committee receives the threshold signature public key pk from the Consensus Committee d Then, store it locally.

6. The method for constructing an adaptive dynamic sharding blockchain network according to claim 1, characterized in that: The specific implementation of step 9 includes the following sub-steps: Step 9.1: At the end of this round of consensus, the consensus committee will complete the consensus transaction set M. l Perform threshold signature and aggregate into complete threshold signature ({M l ,σ l }V)←TS.Sign({sk i ,M l }P i ∈[t]); where σ l Represents a complete threshold signature; V represents a threshold signature aggregation node, which is automatically assumed by the node that has collected the threshold number of signatures; TS.Sign() represents the node P i For transaction set M l Use your own threshold private key sk i Perform threshold signature; i ,M l }P i Represents node P i For transaction set M l Use your own threshold private key sk i Perform threshold signing; Step 9.2: The consensus committee will send transaction set M l and the complete threshold signature σ l Broadcast to the Directory Committee.

7. The method for constructing an adaptive dynamic sharding blockchain network according to claim 1, characterized in that: The specific implementation of step 10 includes the following sub-steps: Step 10.1: The Directory Committee receives the threshold signature σ from the Consensus Committee l and transaction set M l ; Step 10.2: The Directory Committee finds the corresponding threshold signature public key pk from the Committee State Record Table l Threshold signature σ l Verify, 1←TS.Verify(pk l ,(M l ,σ l )); Step 10.3: The Directory Committee collects the transaction set M sent by the Consensus Committee l Store locally; Step 10.4: After the Directory Committee has collected all Q transactions in this round, it will merge the Q transactions into a block B[rd] in ascending order of batch number l. Step 10.5: The directory committee performs threshold signature on B[rd]; In this signature generation protocol, participant P i With its private key sk i and block B[rd] as input, the aggregator V passes ({B[rd],σ d }V)←TS.Sign({sk i ,B[rd]}P i ,i∈[t]) output block B[rd] and complete threshold signature σ d ; Step 10.6: The Directory Committee sends block B[rd] and the full threshold signature σ d Broadcast to all blockchain nodes.

8. The method for constructing an adaptive dynamic sharding blockchain network according to any one of claims 1 to 7, characterized in that: The specific implementation of step 11 includes the following sub-steps: Step 11.1: The blockchain node receives the threshold signature σ from the directory committee d After the block B[rd], find the corresponding threshold signature public key pk d Verify; Blockchain node check 1←TS.Verify(pk d ,(B[rd],σ d )) whether it is satisfied; Step 11.2: After the threshold signature is verified, the blockchain node stores the block B[rd] received from the directory committee locally and then uploads it to the chain.

9. An adaptive dynamic sharding blockchain network construction system, used to implement the method described in any one of claims 1-8; characterized in that: Includes the following modules: The initial setting module is used to generate the parameters of the blockchain system mechanism, VRF parameters and threshold signature parameters based on security parameters; The committee election module is used to elect the directory committee and consensus committee from the blockchain network nodes based on the VRF algorithm; The catalog committee module is used to generate and maintain the committee status record table to assist in the subsequent consensus committee election and dynamic adjustment of the number of consensus committees; The consensus committee module is used to reach consensus on the assigned transactions and send the agreed transaction set to the directory committee at the end of the consensus round; The consensus committee dynamic adjustment module is used to increase or mobilize the consensus committee to reach consensus according to the system transaction processing needs; The efficient consensus sequence module is used to select the most efficient consensus committee for consensus based on the idleness and consensus efficiency of the consensus committee, thus forming an efficient consensus sequence; The global consensus module uses threshold signatures to enable the directory committee to verify the transaction set sent by the consensus committee.

Images