BFT protocol expandability optimization method based on committee sampling

Abstract

A BFT protocol expandability optimization method based on committee sampling comprises the following steps: consensus is carried out on a block by a current committee member in each view, a consensus result is transmitted to all nodes, a verifiable random function (VRF) is utilized to select a node as a candidate of a next committee in each view, and the candidate of the next committee is sent to the current committee member; a leader of a current committee selects k nodes from all candidates as members of a next committee and packages identity information of the members into a block, and when consensus of the block is completed, the committee is alternated. According to the method, the consensus of the block is completed by utilizing the continuously alternate committee, and meanwhile, the alternate of the committee is embedded into the consensus process, so that the security of the alternate of the committee is ensured. In addition, in the scheme, the work of the committee member and the work of the non-committee member are strictly distinguished, so that the communication complexity of the protocol is reduced. The number of nodes supported by most existing BFT protocols is expanded from hundred level to thousand level.

Description

Technical Field

[0001] The present invention relates to a technology in the field of blockchain, and specifically to a method for optimizing the scalability of the BFT protocol based on committee sampling. Background Art

[0002] At present, the BFT protocol has been widely used in consortium blockchains. However, compared with permissionless blockchains such as Bitcoin and Ethereum that can support a large number of nodes to participate simultaneously, existing BFT protocols generally face scalability problems (only supporting up to two or three hundred nodes). This is mainly because the BFT protocol generally uses qualified certificates (QCs) to advance the protocol, and the size of QCs often increases linearly with the increase of the scale n of nodes. Therefore, both the communication overhead and the computing overhead of the BFT protocol will increase significantly with the increase of n, resulting in a serious degradation of its performance. Summary of the Invention

[0003] In view of the deficiencies that existing sharding technologies rely on strong security assumptions, cross-shard transactions incur additional overhead, and existing committee sampling technologies lack generality, the present invention proposes a method for optimizing the scalability of the BFT protocol based on committee sampling. While using a continuously rotating committee to complete the consensus on blocks, the rotation of the committee is embedded in the consensus process to ensure the security of committee rotation. In addition, the work of committee members and non-committee members is strictly distinguished in this scheme to reduce the communication complexity of the protocol. The number of nodes that most existing BFT protocols can support is extended from the hundreds level to the thousands level.

[0004] The present invention is realized through the following technical solutions:

[0005] The present invention relates to a method for optimizing the scalability of the BFT protocol based on committee sampling. In each view, the current committee members perform consensus on the block and convey the consensus result to all nodes. At the same time, after using a verifiable random function (VRF) to select a part of the nodes as candidates for the next committee in each view, the leader of the current committee selects κ nodes from all candidates as members of the next committee and packs the identity information of the members into the block. When the consensus on this block is completed, the committee is rotated.

[0006] The present invention relates to a system for implementing the above method, including: a committee election module, an M-Π BFT protocol module, and a state transmission module, where: the committee election module generates a committee election command cmd M , as the input of the M-Π BFT protocol module; the M-Π BFT protocol module then uses a regular command cmd R and the committee election command cmdM As input, valid commands are packaged into blocks, and consensus is performed on the blocks. Finally, a single chain is output, and the final order of all blocks is determined by this chain. The state transfer module helps lagging nodes synchronize to the latest state based on the block and certificate information during the consensus operation to ensure the continuous operation of the protocol. Technical Effects

[0007] Compared with the existing VRF-based committee election scheme, the present invention utilizes the properties of the consensus protocol itself to ensure the security of committee rotation, can use the properties of the consensus protocol to ensure that the number of nodes included in the elected committee is fixed, and ensure that all nodes can perceive the rotation of the committee and switch to the new committee. Therefore, it provides strong security guarantees and finally safely expands the number of nodes that the existing BFT protocol can support from the hundreds level to the thousands level at a lightweight cost. Description of the Drawings

[0008] Figure 1 It is a schematic diagram of the principle of the present invention;

[0009] Figure 2 It is a flowchart of an embodiment;

[0010] Figure 3 It is a schematic diagram of the effect of an embodiment. Detailed Embodiment

[0011] As Figure 2 shown, this embodiment relates to a method for optimizing the scalability of a BFT protocol based on committee sampling, including:

[0012] Step 1: The node calls the VRF generation function to generate a random number ρ and the corresponding proof π to form a committee election command cmd M , when the value of the random number is less than the preset value R, the node sends cmd M to the leader node of the current view. At the same time, the client broadcasts the generated regular BFT protocol command cmd R to the nodes in the system;

[0013] As Figure 2 shown, assume that there are a total of 20 nodes in the system, the committee contains 4 nodes, and the current committee is the mth committee. In the vth view, each node calls the VRF generation function to generate <ρ i , π i >, but only ρ 16 , ρ 17 , ρ 18 , ρ 19 , ρ 20 values are less than R. Therefore, only these five nodes will send their cmdM Sent to the primary node Select the four commands with the smallest random value from these five messages, pack them into a block, and conduct consensus on this block. When the consensus on this block is completed, committee rotation occurs, and it is composed of Form the (m + 1)-th committee and take over the work of the current committee.

[0014] Step 2. When a committee member receives different commands cmd M and cmd R , call the VRF verification function to verify the validity of cmd M and conduct consensus on the block;

[0015] The so-called consensus specifically includes:

[0016] 2.1 Block construction and verification: Compared with the original BFT protocol (Π BFT ), in the modified BFT protocol (M-Π BFT ), in addition to including the regular command cmd R , it also includes the member command cmd M . During the verification process, in addition to verifying cmd BFT like Π R , M-Π BFT also calls the VRF verification function to verify cmd M . In addition, when verifying the block, the following two situations are distinguished: (a) This block and its parent block are proposed by the same committee; (b) This block is proposed by a new committee. The verification of the former is almost exactly the same as that of Π BFT , while the verification of the latter uses the information provided by the previous committee to ensure that the newly delivered block is a direct extension of the previous latest block.

[0017] 2.2 Block delivery:

[0018] A) When delivering any block, each node executes all the regular commands cmd R contained in the block and sends the execution result to the client. When the block exactly contains κ member requests cmd M , all nodes will update the current committee;

[0019] B) When the delivery of any block is completed, the committee node conveys the delivery proof of this block to all non-committee nodes;

[0020] C) When committee rotation occurs, the committee node synchronizes the necessary QC and the latest block information for running M-Π BFT to the members of the next committee.

[0021] 2.3 Chasing Mechanism: The members of each committee synchronize all the blocks delivered by the committee. That is, when any node has not synchronized the latest block status, it will send a message to the currently latest committee recorded by itself to request synchronization to the latest status; this committee will synchronize all the blocks it has delivered and the relevant proofs.

[0022] Step 3. The committee members run the M-Π BFT protocol to reach a consensus on block B and convey the consensus result to all non-committee members. When block B only contains the regular BFT protocol command cmd R at this time, the committee does not rotate, and the current committee continues the next round of consensus and repeats the above process until exactly κ cmd are included in the latest block for which the consensus has been completed M , then the nodes corresponding to the commands will form the (m + 1)-th committee, and after completing the synchronization, they will replace the m-th committee and start running the M-Π BFT protocol and deliver new blocks.

[0023] Preferably, let κ' represent the number of random numbers that actually meet the requirements. When κ' ≥ κ, the leader only needs to select the smallest κ numbers; if κ' < κ, then the newly proposed block will not contain cmd M , and this block will still be delivered, but the committee will not rotate.

[0024] The following status synchronization is carried out between the described committee and non-committee nodes in each view:

[0025] i) In the M-Π BFT protocol, the leader in each view proposes a block in a broadcast manner;

[0026] ii) After the delivery of any block is completed, all committee nodes will send the delivery proof of this block to all non-committee nodes;

[0027] iii) When any non-committee node receives no less than 2t + 1 proofs, it will deliver the corresponding block, where: t is the number of Byzantine nodes, and κ = 3t + 1.

[0028] The following status synchronization is carried out between the current committee and the next committee when the committee switches:

[0029] i) The current committee members synchronize the information (e.g., some QCs) necessary for running the M-Π BFT to the members of the next committee to handle the temporary out-of-sync problem caused by network fluctuations;

[0030] ii) When a member of any next committee receives no less than 2t + 1 synchronous messages, the latest block will be delivered and its M-Π will be updated. BFT The relevant states required by the module.

[0031] Through specific experiments, the above-mentioned scalable BFT protocol based on the committee sampling technology was implemented in Golang and deployed and tested on the m5.xlarge server of Amazon EC2: 10 nodes were run on each server, and the performance of the protocol with the changes of the network scale n and the batch size b was evaluated under the wide area network, and compared with the existing protocol HotStuff. Each command is defaulted to 250 bytes, which is consistent with the size of a typical Bitcoin transaction. In all experiments, the committee size of the extended protocol was 200.

[0032] As Figure 3 shown, the latency of both HotStuff and the present invention increases with the increase of the network scale n, but the growth rate of HotStuff is significantly higher than that of the present invention. In addition, HotStuff can support at most about 400 nodes, while the present invention can easily support up to 1000 nodes under the same server configuration, and the performance only drops slightly.

[0033] Table 1 Raw data of latency under different network scales n when Batchsize = 2500

[0034] Compared with the prior art, the present invention uses VRF to select the committee, and ensures the randomness of the elected committee through the randomness of VRF, so as to prevent an adversary from launching an attack against any specific committee in advance. In addition, compared with the prior art, the present invention innovatively embeds the rotation of the committee into the consensus process, and uses the security of the consensus protocol to enable the nodes in the system to reach an agreement on the elected committee, so as to ensure that the number of nodes included in each elected committee is fixed. This enables the present invention to better be compatible with the existing consensus protocols and avoid some possible security defects.

[0035] The above specific implementation can be locally adjusted in different ways by those skilled in the art without departing from the principles and purposes of the present invention. The protection scope of the present invention is subject to the claims and is not limited by the above specific implementation, and all implementation solutions within its scope are subject to the present invention.

Claims

1. A method for optimizing the scalability of a BFT protocol based on committee sampling, characterized in that: In each view, the current committee members reach consensus on the block and communicate the consensus results to all nodes. At the same time, a verifiable random function (VRF) is used to select a portion of nodes in each view as candidates for the next committee. The leader of the current committee selects κ nodes from all candidates as members of the next committee and packages the members' identity information into the block. When the consensus of the block is completed, the committee is rotated.

2. The method for optimizing the scalability of a BFT protocol based on committee sampling according to claim 1 is characterized in that: include: Step 1: The node calls the VRF generation function to generate a random number ρ and the corresponding proof π, forming the committee election command cmd M , when the value of the random number is less than the preset value R, the node will cmd M At the same time as sending it to the leader node of the current view, the client will generate the regular BFT protocol command cmd R Broadcast to nodes in the system; Step 2: When committee members receive different commands cmd M and cmd R After that, call the VRF verification function to verify cmd M The validity of the blockchain and consensus on the blocks; Step 3: Committee members run M-Π BFT The protocol completes the consensus on block B and communicates the consensus result to all non-committee members. When block B contains only the regular BFT protocol command cmd R When , the committee does not rotate, and the current committee continues to carry out the next round of consensus. The above process is repeated until the latest block that has reached consensus contains exactly κ cmd M , then the nodes corresponding to the command form the m+1th committee, and after completing the synchronization, they take over the mth committee to start running M-Π BFT Agree on and deliver new blocks.

3. The method for optimizing the scalability of a BFT protocol based on committee sampling according to claim 1 or 2, characterized in that: The consensus mentioned above specifically includes: 2.1 Block construction and verification: Compared with the original BFT protocol (Π BFT ), the modified BFT protocol (M-Π BFT ) contains the regular command cmd R In addition, it also contains member commands cmd M , in the verification process, except for BFT Same verification cmd R Outside, M-Π BFT Also calls the VRF verification function to cmd M To verify; 2.2 Block Delivery: A) When delivering any block, each node executes all the regular commands cmd contained in the block R And send the execution result to the client. When the block contains exactly κ members request cmd M , then all nodes will update the current committee; B) After completing the delivery of any block, the committee node communicates the delivery proof of the block to all non-committee nodes; C) When a committee rotation occurs, the committee node runs M-Π synchronously with the next committee member. BFT The necessary QC and the latest block information, 2.3 Catch-up mechanism: Each committee member synchronizes all blocks delivered by the committee, that is, when any node When the latest block status is not synchronized, It will send a message to the latest committee in its records to request synchronization with the latest status; the committee will Synchronize all blocks and related proofs it delivers.

4. The method for optimizing the scalability of a BFT protocol based on committee sampling according to claim 3 is characterized in that When verifying a block, we distinguish between the following two cases: (a) the block and its parent block are proposed by the same committee; (b) the block is proposed by a new committee, and the verification of the former is the same as that of the parent block. BFT The two committees are almost identical, and verification of the latter uses information provided by the previous committee to ensure that the newly delivered block is a direct extension of the previous latest block.

5. The method for optimizing the scalability of a BFT protocol based on committee sampling according to claim 3 is characterized in that: Let κ' represent the number of random numbers that actually meet the requirements. When κ'≥κ, the leader only needs to select the minimum number of κ; if κ'<κ, the newly proposed block will not contain cmd M , the block will still be delivered, but no committee rotation will occur.

6. The method for optimizing the scalability of a BFT protocol based on committee sampling according to claim 1 or 2, characterized in that: The following states are synchronized between the committee and non-committee nodes in each view: i)M-Π BFT The leader of each view in the protocol proposes the block by broadcasting; ii) After completing the delivery of any block, all committee nodes will send the delivery proof of the block to all non-committee nodes; iii) When any non-committee node Received no less than 2t+1 certifications, The corresponding block will be delivered, where: t is the number of Byzantine nodes, κ=3t+1.

7. The method for optimizing the scalability of a BFT protocol based on committee sampling according to claim 1 or 2, characterized in that: The following status synchronization is performed between the current committee and the next committee when a committee switch occurs: i) Current committee members will run M-Π BFT The necessary information is synchronized to the next committee members to handle the temporary asynchrony caused by network fluctuations; ii) When any next committee member receives no less than 2t+1 synchronization messages, it will deliver the latest block and update its own M-Π BFT The relevant state required by the module.

8. A BFT protocol scalability optimization system based on committee sampling that implements any of the methods described in claims 1-7, characterized in that: include: Committee election module, M-Π BFT Protocol module and state transfer module, where the committee election module generates the committee election command cmd according to VRF M , as M-Π BFT Input of the protocol module; M-Π BFT The protocol module uses the regular command cmd R and the committee election command cmd M As input, valid commands are packaged into blocks, and consensus is reached on the blocks, and finally a single chain is output. The chain determines the final order of all blocks. The state transfer module helps lagging nodes synchronize to the latest status based on the block and certificate information during the consensus operation to ensure the continuous operation of the protocol.

Images