Self-adaptive dynamic fragmentation block chain network construction method and system

Abstract

The invention discloses an adaptive dynamic fragmentation block chain network construction method and system. A verifiable random function is used to quickly elect a directory committee and a consensus committee. And the directory committee generates a committee state table for recording the state of the consensus committee, and assists the consensus committee in consensus. The invention designs a consensus committee number adjustment algorithm to adjust the number of committees according to transaction processing requirements. According to the method, a weighting mechanism is designed for the consensus committee, so that the efficient consensus committee calling sequence is realized, and the consensus efficiency is improved. The invention also provides a new consensus method for reducing repeated consensus through threshold signature. The fragment number of the fragment block chain can be dynamically adjusted, the consensus efficiency is improved, and the expenditure of repeated consensus is reduced.

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 used in many fields such as data security protection and decentralized finance due to their openness, transparency, and immutability. However, as the number of blockchain nodes increases, the network load becomes larger, which seriously limits the scalability of existing blockchain systems. This is because every node in the blockchain network participates in each consensus broadcast of these blockchain protocols. A promising solution to the above problem is the sharding blockchain solution, which selects one or more committees from the blockchain nodes to process transactions.

[0003] According to the number of committees, sharded blockchain schemes can be divided into single-committee schemes and multi-committee schemes. Single-committee schemes only elect one committee to reach transaction consensus. However, these schemes cannot perform parallel consensus. Multi-committee schemes elect multiple committees to reach transaction consensus in parallel. These schemes focus on improving the synergy between committees. Therefore, these schemes have better performance in processing transactions than single-committee schemes. Although existing multi-committee schemes increase the scalability of blockchains, there are still some problems. 1) The number of committees is rigid. Due to the inefficiency of committee formation, existing solutions generate all committees at once in the initialization phase and cannot dynamically adjust the number of committees during the consensus process. 2) Inefficient consensus process. There are differences in the consensus efficiency of different committees, and the consensus order of multiple committees affects the consensus efficiency of the system. 3) Repeated consensus. In the current sharded blockchain scheme, transactions that have passed the intra-committee Byzantine consensus need to pass the inter-committee Byzantine consensus again, which leads to repeated broadcasts of the Byzantine consensus and increases unnecessary communication load. Summary of the invention

[0004] In order to improve the consensus efficiency of the existing sharded blockchain, 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 a directory committee and a 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: The blockchain network nodes generate a consensus committee based on the dynamic adjustment mechanism;

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

[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-tolerant 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, then signs the threshold and broadcasts it to the entire network;

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

[0018] As a preference, 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 generating 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 that π 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 Broadcasts 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 ) and then verify; 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 the node to be added to the selected node set {P1,P3,...,P n-2 ,P n};

[0024] Step 2.5: All nodes in the network use the Byzantine fault-tolerant consensus to select the set of nodes {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: The nodes in the directory committee negotiate to generate the public key and private key {pk d ,sk i} i ∈[w]←TS.Gen({1 λ ,w,t}P i ∈[w]); {pk d ,sk i} 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) already recorded in the committee status table;

[0032] Step 5.2: The Directory Committee traverses the committee status and finds the idle consensus committee with the largest weight. Then, if the above committee exists, the Directory Committee will hand over the m transactions in the transaction pool to the consensus committee for processing. If there is no idle consensus committee, the Directory Committee will elect 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 will be generated. The Directory Committee must wait for a consensus committee to be idle and let this consensus committee 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 that π 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 Broadcasts 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 ) and then verify; 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 the node to be added to 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: According to 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 state 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} j ∈[w]←TS.Gen({1 λ ,w,t}P j ∈[w]); {pk d ,sk j} 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 a complete threshold signature ({M l ,σ l}V)←TS.Sign({sk i ,M l} 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} 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 Status Record Table l For 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 collected into a block B[rd] in order of batch number l from small to large;

[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 verification is passed, 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 according to the security parameters;

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

[0061] 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;

[0062] The consensus committee module is used to reach consensus on the assigned transactions and send the consensus 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 implement verification of the transaction set sent by the consensus committee by the directory committee.

[0066] Compared with the prior art, the beneficial effects achieved by the present invention include:

[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 in the currently idle consensus committee 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 shard consensus transaction results of the sharded blockchain of the present invention are finally packaged into blocks, which reduces the repeated consensus process. The verification of threshold signatures replaces the Byzantine consensus of the directory committee on all transactions collected 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 described below using embodiments and specific implementation methods. In addition, in the process of describing the technical solution, some drawings are also used. For those skilled in the art, other drawings and the intention of the present invention can also be obtained based on these drawings without paying creative work.

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

[0072] Figure 2 This is a schematic diagram of the operation flow of an embodiment of the present invention;

[0073] Figure 3 A schematic diagram of a 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 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 A schematic diagram of a system model of 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] Fig. 9 This is a diagram of the transaction throughput TPS value of Dyshard under different block sizes and bandwidths in this experiment;

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

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

[0082] Fig.12 Schematic diagram of transaction confirmation delay of Dyshard with the best block size and committee size in this experiment;

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

[0084] Fig.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] Fig.15 This is a schematic diagram comparing the committee load of Dyshard and other solutions at different transaction injection speeds in this experiment;

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

[0087] Fig.17 The following is a comparison diagram of the transaction confirmation delay of Dyshard and Dyshard (without weight) under different bandwidths in this experiment. DETAILED DESCRIPTION

[0088] In order to facilitate ordinary technicians in the field to understand and implement the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. 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 The present embodiment provides a method for constructing an adaptive dynamic sharding blockchain network, which is characterized by comprising the following steps:

[0090] Step 1: The blockchain network node generates 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 a directory committee and a 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 generating VRF public key and private key 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 maintains the following information locally as the node state {Q, m, vski, vpki, tnc, w, cond, s, rd, B}. Q is the number of transactions processed in one round, and m is the number of transactions in a batch. When the transaction pool of the blockchain node reaches m transactions, the m transactions are packaged into a batch and a consensus committee is selected to reach a consensus on the batch of transactions. After reaching a consensus on Q transactions, this 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 the vpk of all nodes i , used for VRF calculation. tnc is the number of nodes in the network that have not been elected to the committee. i Maintains the VRF seed s (initialized as s0) and the 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 implementation, 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 that π 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 Broadcasts 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 ) and then verify; 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 the node to be added to the selected node set {P1,P3,...,P n-2 ,P n}; Function VRF.VER() is included in VRF technology;

[0101] Step 2.5: All nodes in the network use the Byzantine fault-tolerant consensus to select the set of nodes {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 the status and update the status when receiving changes to the consensus committee or consensus committee nodes. The committee status record table needs to maintain the current number L of the consensus committee in this round, and update L in time as the consensus committee increases. The committee status 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. Assume that a consensus committee takes time t to reach a consensus on a batch of transactions. In this experiment, the weight of the consensus committee is set to c(l) = 1 / t. The committee status 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 status 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 a consensus committee during the committee generation process. The committee status record table records the threshold signature public key pk of each consensus committee l (Wait for the consensus committee to be established and send the corresponding public key to obtain it) 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 committee generation process to determine whether the node is selected as a committee node through VRF calculation formula r i / 2 λ ≤(w / tnc).

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

[0105] In one implementation, 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 contained in each committee), and the threshold is t, t≤w;

[0107] Step 4.2: The nodes in the directory committee negotiate to generate the public key and private key {pk d ,sk i} i ∈[w]←TS.Gen({1 λ ,w,t}P i ∈[w]); the function TS.Gen() is included in the threshold signature technology; {pk d ,sk i} 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: The blockchain network nodes generate a consensus committee based on the dynamic adjustment mechanism;

[0111] Please see Fig.14 In one implementation, 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 status identifier p(l) already recorded in the committee status table;

[0113] Step 5.2: First, the Directory Committee traverses the committee status and finds the idle consensus committee with the largest weight. Then, if the above committee exists, the Directory Committee will hand over the m transactions in the transaction pool to the consensus committee for processing. If there is no idle consensus committee, the Directory Committee elects a new consensus committee from the remaining non-committee nodes. If there are not enough remaining nodes in this round (the number of remaining nodes is less than w), no new consensus committee will be generated. The Directory Committee must wait for a consensus committee to be idle and let this consensus committee 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 that π 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() means to perform hash operation on the data in 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 Broadcasts the pseudo-random number r generated by itself j And prove π j ;

[0117] Step 5.6: The directory committee receives the (r j ,π j ) and then verify; 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 the node to be added to 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: According to the record of the 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 the threshold signature of the committee;

[0122] In one implementation, 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), and the threshold is 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} i,i ∈[w]←TS.Gen({1 λ ,w,t}P i,i ∈[w]); the function TS.Gen() is included in the threshold signature technology; {pkd ,sk i} 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 implementation, 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-tolerant protocol to reach consensus on the assigned transactions;

[0130] Please see Figure 6 In one embodiment, when a consensus committee is selected for consensus, it requires a specific consensus algorithm to reach consensus on transactions. The consensus running within the committee is decoupled from the rest of the scheme. Committees (directory committees and consensus committees) 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 implementation, 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 a complete threshold signature ({M l ,σ l}V)←TS.Sign({sk i ,M l} i,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 node P i For transaction set M l Use your own threshold private key sk i Perform threshold signature. i ,M l} 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, then signs the threshold and broadcasts it 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 Status Record Table l For 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 collected into a block B[rd] in order of batch number l from small to large;

[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 implementation, 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 verification is passed, 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 according to the security parameters;

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

[0150] 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;

[0151] The consensus committee module is used to reach consensus on the assigned transactions and send the consensus 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 implement verification of the transaction set sent by the consensus committee by the directory committee.

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

[0156] First, we conducted experiments to find the optimal block size and committee node size for system performance, and then proved that Dyshard can dynamically adjust the number of committees according to demand. Next, we experimentally proved that the optimal committee consensus sequence can improve transaction throughput and reduce transaction latency. Finally, we compared Dyshard with ELASTICO, OmniLedger, and RapidChain in terms of transaction throughput TPS and transaction confirmation latency.

[0157] (1) Experimental configuration

[0158] This experiment uses Python (version 3.8) to develop all experimental systems. The blockchain network of the entire system is deployed on four servers (Intel Xeon processor, 8GB RAM, Ubuntu Desktop 16.04-64 system). This experiment uses different network ports to simulate different nodes of the blockchain in the system. The system can accommodate up to 5,000 nodes. In addition, this experiment uses Dumbo as the internal formula protocol of the committee. In order to simulate the communication delay of the blockchain nodes, this experiment sets the transmission delay of each message to 100 milliseconds and the communication bandwidth of each node to 20Mbps. Similar to Bitcoin Core. Finally, this experiment configures each transaction to 512 bytes.

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

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

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

[0162] In order 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 contain 2,000 nodes, and set the bandwidth to 5MB, 10MB, 15MB, and 20MB, and measured the transaction throughput TPS and transaction confirmation latency corresponding to block sizes from 128KB to 4,096KB at each bandwidth. Figure 8 and Fig. 9 As shown in the figure, under different bandwidths, a larger block size can bring higher transaction throughput TPS, but it will also bring 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 set the bandwidth to 5MB, 10MB, 15MB, and 20MB respectively. Fig.10 and Fig.11 As shown in the figure, as the number of committee nodes increases, Dyshard's TPS value decreases and Dyshard's transaction confirmation delay increases. Combined with the 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 safe. Therefore, 200 is selected as the optimal value for the number of nodes included in each committee.

[0164] Fig.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 committee node size is 200. The transaction confirmation delay increases slowly, indicating that the optimal parameter setting of this experiment is effective.

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

[0166] This experiment changes the transaction injection speed and tests the performance of Dyshard, ELASTICO, OmniLedger, and RapidChain, so as to test the dynamic adjustment effect of Dyshard's committee. This experiment sets the total number of nodes in the blockchain network to 2,000, and the number of shards of ELASTICO, Omniledger, and RapidChain to 5. This experiment adjusts the transaction injection speed and records the transaction confirmation delay, transaction throughput TPS, and committee load. The results are as follows: Fig.13 , Fig.14 and Fig.15 As shown in the figure. The transaction confirmation delay of ELASTICO, Omniledger and RapidChain increases significantly with the increase of transaction injection speed. The transaction confirmation delay of Dyshard does not increase significantly with the increase of transaction injection speed. The transaction throughput TPS value growth of ELASTICO, Omniledger and RapidChain is smaller than that of Dyshard. The committee load of Dyshard increases much slower than other schemes. The results show that Dyshard can dynamically adjust the number of consensus committees according to transaction processing needs, so that Dyshard's transaction confirmation delay remains stable, and Dyshard's transaction processing speed TPS increases with the increase of transaction injection speed.

[0167] (5) optimal committee consensus sequence;

[0168] This experiment is conducted to test the effectiveness of the optimal committee consensus sequence. In this experiment, Dyshard without committee weight 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 of Dyshard and Dyshard (no weight) under different bandwidths. The results are as follows Fig.16 and Fig.17 As shown in the figure. After the committee weight design, Dyshard has higher transaction throughput TPS and lower transaction confirmation delay than Dyshard (without weight). In summary, the optimal committee formula sequence is effective.

[0169] The present invention adopts a dynamic sharding blockchain method to effectively solve the above problems and realize the dynamic adjustment of the number of committees. The number of committees can be dynamically adjusted according to transaction processing requirements. The consensus order of the committees can be dynamically adjusted to improve the efficiency of the consensus process.

[0170] It should be understood that the embodiments described above are part of the embodiments of the present invention, rather than all of the embodiments. In addition, the technical features in the various embodiments or single embodiments provided by the present invention can be combined with each other arbitrarily to form a feasible technical solution. Such combination is not restricted by the sequence of steps and / or the structural composition mode, but must be based on the ability of ordinary technicians in the field to implement. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the protection scope required 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 patent protection of the present invention. Under the enlightenment 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 for 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 composed of each block B[rd], and the current consensus batch number cond within the round; Said committee consisted 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 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 a threshold signature of the committee; Step 5: The blockchain network nodes generate a consensus committee based on the dynamic adjustment mechanism; Step 6: The consensus committee generates the threshold signature of the committee; 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-tolerant 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, then signs the threshold and broadcasts it to the entire network; Step 11: All nodes in the entire 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 according to 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 that π 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 Broadcasts 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 ) and then verify; 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 the node to be added to the selected node set {P1,P3,...,P n-2 ,P n }; 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.

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: The nodes in the directory committee negotiate to generate the public key and private key {pk d ,sk i } i ∈[w]←TS.Gen({1 λ ,w,t}P i ∈[w]); {pk d ,sk i } 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 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) already recorded in the committee status table; Step 5.2: The Directory Committee traverses the committee status and finds the idle consensus committee with the largest weight; then, if the above committee exists, the Directory Committee will hand over the m transactions in the transaction pool to the consensus committee for processing; If there is no idle consensus committee, 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 will be generated, and the Directory Committee must wait for a consensus committee to be idle and let this consensus committee 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 that π 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 Broadcasts the pseudo-random number r generated by itself j And prove π j ; Step 5.6: The directory committee node receives the (r j ,π j ) and then verify; 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 the node to be added to 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: According to 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)=0 and the state flag P(l)=0 of the newly generated consensus committee.

6. 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 } j ∈[w]←TS.Gen({1 λ ,w,t}P j ∈[w]); {pk d ,sk j } 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.

7. 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 a complete threshold signature ({M l ,σ l }V)←TS.Sign({sk i ,M l } 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 } 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.

8. 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 Status Record Table l For 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 collected into a block B[rd] in order of batch number l from small to large; 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.

9. The method for constructing an adaptive dynamic sharding blockchain network according to any one of claims 1 to 8, 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 verification is passed, the blockchain node stores the block B[rd] received from the directory committee locally and then uploads it to the chain.

10. An adaptive dynamic sharding blockchain network construction system, used to implement the method described in any one of claims 1-9; characterized in that: Includes the following modules: The initial setting module is used to generate the parameters of the mechanism within the blockchain system, VRF parameters and threshold signature parameters according to the security parameters; The committee election module is used to elect the directory committee and consensus committee from the blockchain network nodes according to 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 consensus 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 implement verification of the transaction set sent by the consensus committee by the directory committee.

Images