Committee-sampling based bft protocol scalability optimization method

Abstract

A committee sampling-based BFT protocol scalability optimization method, in each view, the current committee members reach consensus on blocks, and at the same time, the consensus results are conveyed to all nodes, and the nodes are selected as candidates for the next committee in each view by using a verifiable random function (VRF), and then 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, and when the consensus of the block is completed, the committee is rotated. The application uses a continuously rotating committee to complete the consensus of the block while embedding the rotation of the committee into the consensus process to ensure the security of the rotation of the committee. In addition, the work of the committee members and the non-committee members is strictly distinguished in the scheme to reduce the communication complexity of the protocol. The number of nodes supported by most existing BFT protocols is expanded from hundreds to thousands.

Description

Technical Field

[0001] This invention relates to a technology in the field of blockchain, specifically a BFT protocol scalability optimization method based on committee sampling. Background Technology

[0002] Currently, BFT protocols have been widely adopted in consortium blockchains. However, compared to permissionless blockchains like Bitcoin and Ethereum, which can support a large number of nodes participating simultaneously, existing BFT protocols generally face scalability issues (supporting only a maximum of two to three hundred nodes). This is mainly because BFT protocols typically use Qualified Certificates (QCs) to advance the protocol, and the size of the QC tends to increase linearly with the number of nodes, n. Therefore, the communication and computational overhead of BFT protocols increases significantly with increasing n, causing severe performance degradation. Summary of the Invention

[0003] This invention addresses the shortcomings of existing sharding technologies, which rely on strong security assumptions, incur additional overhead for cross-shard transactions, and lack universality in existing committee sampling techniques. It proposes a committee sampling-based scalability optimization method for BFT protocols. This method utilizes a continuously rotating committee to achieve block consensus while embedding committee rotation into the consensus process, ensuring the security of committee rotation. Furthermore, this scheme strictly distinguishes between the work of committee members and non-committee members to reduce protocol communication complexity. It expands the number of nodes supported by most existing BFT protocols from hundreds to thousands.

[0004] This invention is achieved through the following technical solution:

[0005] This invention relates to a BFT protocol scalability optimization method based on committee sampling. In each view, the current committee members reach consensus on the block and transmit the consensus result to all nodes. At the same time, a portion of the nodes in each view are selected as candidates for the next committee using a verifiable random function (VRF). The leader of the current committee then selects κ nodes from all candidates as members of the next committee and packages the members' identity information into the block. When consensus on the block is completed, the committee is rotated.

[0006] This invention relates to a system for implementing the above method, comprising: a committee election module, and an M-Π. BFT The protocol module and the status transmission module include: the committee election module generates the committee election command (cmd) based on the VRF. M As M-Π BFT Input to the protocol module; M-Π BFT The protocol module uses the standard command cmd. R and committee election command cmdM As input, valid commands are packaged into blocks, and consensus is reached on these blocks, ultimately outputting a single chain that determines the final order of all blocks. The state transmission module then uses block and certificate information from the consensus process to help lagging nodes synchronize to the latest state, ensuring the continuous operation of the protocol.

[0007] Technical effect

[0008] Compared to existing VRF-based committee election schemes, this invention utilizes the inherent properties of the consensus protocol to ensure the security of committee rotation. It leverages the nature of the consensus protocol to guarantee that the number of nodes included in the elected committee is fixed, and ensures that all nodes can detect the committee rotation and switch to the new committee. Therefore, it provides strong security guarantees and ultimately securely expands the number of nodes supported by the existing BFT protocol from hundreds to thousands at a lightweight cost. Attached Figure Description

[0009] Figure 1 This is a schematic diagram illustrating the principle of the present invention;

[0010] Figure 2 This is a flowchart of an implementation example;

[0011] Figure 3 This is a schematic diagram illustrating the effect of an example. Detailed Implementation

[0012] like Figure 2 As shown, this embodiment relates to a BFT protocol scalability optimization method based on committee sampling, including:

[0013] 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... M Simultaneously, the client sends the generated standard BFT protocol command cmd to the leader node of the current view. R Broadcast to nodes in the system;

[0014] like Figure 2 As shown, assume the system contains a total of 20 nodes, each committee contains 4 nodes, and the current committee is the m-th committee. In the v-th view, each node... Calling the VRF generation function generates <ρ i ,π i >, but only ρ 16 ,ρ 17 ,ρ 18 ,ρ 19 ,ρ 20the value of R, so only these five nodes will send their cmd M to the primary node From these five messages, the four commands with the smallest random number values are selected, packaged into a block, and consensus is reached on the block. When the consensus on the block is complete, committee rotation occurs, and the m+1th committee is formed and takes over the work of the current committee.

[0015] Step 2: When committee members receive different commands cmd M and cmd R , they call the VRF verification function to verify the validity of cmd M and reach consensus on the block.

[0016] The consensus, in particular, includes:

[0017] 2.1 Block construction and verification: Compared to the original BFT protocol (Π BFT ), the modified BFT protocol (M-Π BFT ) contains not only regular commands cmd R but also member commands cmd M . In the verification process, in addition to verifying cmd R as in Π BFT , M-Π BFT also calls the VRF verification function to verify cmd M . In addition, when verifying the block, 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. The verification of the former is almost identical to Π BFT , while the verification of the latter uses information provided by the last committee to ensure that the newly delivered block is a direct extension of the latest block in the sequence.

[0018] 2.2 Block delivery:

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

[0020] B) After completing the delivery of any block, the committee nodes convey the proof of delivery of the block to all non-committee nodes.

[0021] C) When committee rotation occurs, the committee nodes synchronize the running of M-Π BFTThe necessary QC and the latest block information.

[0022] 2.3 Catch-up mechanism: every committee member synchronizes all blocks delivered by the committee, i.e. when any node is not synchronized with the latest block state, it sends a message to the current committee recorded by itself to request synchronization to the latest state; the committee sends synchronizes all blocks delivered and the related proof.

[0023] Step 3, the committee member runs M-Π BFT The protocol completes the consensus of block B, and the consensus result is conveyed to all non-committee members. When block B only contains regular BFT protocol commands cmd R , the committee does not rotate, and the current committee continues to the next round of consensus, and the above process is repeated until the latest block that has completed the consensus contains exactly κ cmd M , then the (m+1)th committee is composed of the nodes corresponding to the commands, and after synchronization, it replaces the mth committee to start running M-Π BFT protocol and deliver new blocks.

[0024] Preferably, κ' represents the number of random numbers that actually meet the requirements. When κ'≥κ, the leader only selects the smallest κ numbers; if κ'<κ, the newly proposed block does not contain cmd M , the block will still be delivered, but no committee rotation will occur.

[0025] The committee and non-committee nodes synchronize the following states in each view:

[0026] i) In the M-Π BFT protocol, the leader of each view proposes a block by broadcasting;

[0027] ii) After completing the delivery of any block, all committee nodes send the delivery proof of the block to all non-committee nodes;

[0028] 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.

[0029] The current committee and the next committee synchronize the following states when the committee switches:

[0030] i) The current committee member runs M-Π BFTThe necessary information (e.g., some QC) is synchronized to the members of the next committee to handle the temporary out-of-sync problem caused by network fluctuations;

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

[0032] Through specific experiments, the above-mentioned scalable BFT protocol based on committee sampling technology is implemented on Golang, and is deployed and tested on Amazon EC2 m5.xlarge servers: 10 nodes are run on each server, and the performance of the protocol is evaluated under a wide area network as the network size n and the batch size b change, and is compared with the existing protocol HotStuff. Each command is 250 bytes by default, which is consistent with the size of a typical Bitcoin transaction. In all experiments, the committee size of the scalable protocol is 200.

[0033] As Figure 3 shown, the delays of HotStuff and the present application both increase as the network size n increases, but the growth rate of HotStuff is significantly higher than that of the present application. In addition, HotStuff can at most support about 400 nodes, while the present application can easily support up to 1000 nodes under the same server configuration, with only a slight decrease in performance.

[0034] Table 1 Delay raw data under different network sizes n when Batchsize = 2500

[0035]

[0036] Compared with the prior art, the present application uses VRF to select the committee, and the randomness of VRF ensures the randomness of the selected committee, thereby avoiding the possibility that an adversary can initiate an attack against any specific committee in advance. In addition, compared with the prior art, the present application 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 selected committee, thereby ensuring that the number of nodes included in each selected committee is fixed. This makes the present application better compatible with existing consensus protocols and can avoid some possible security defects.

[0037] The above specific embodiments can be adjusted in different ways by those skilled in the art without departing from the principles and purposes of the present application, and the protection scope of the present application is subject to the claims and is not limited by the above specific embodiments, and each implementation scheme within the scope is subject to the constraints of the present application.

Claims

1. A method for optimizing the scalability of a BFT protocol based on committee sampling, characterized in that, include: Step 1: Each node calls the VRF generation function to generate a random number. With corresponding proof Forming a committee election order When the value of the random number is less than the preset value Then the node will Simultaneously, the generated standard BFT protocol command will be sent to the leader node of the current view. Broadcast to nodes in the system; Step 2, when committee members receive different orders and Then, the VRF verification function is called to verify. The validity of the blocks and the consensus on them include: 2.1 Block Construction and Verification: Compared to the original BFT protocol The modified BFT protocol In addition to regular commands, it also contains In addition, it also includes member commands. During the verification process, in addition to things like Same verification outside, It also calls the VRF verification function to verify... Verification is required; 2.2 Block Delivery: A) When delivering any block, each node executes all the regular commands contained in the block. When the block contains Member request Then all nodes will update the current committee; B) Once the delivery of any block is completed, the committee node will transmit the delivery proof of that block to all non-committee nodes. C) When a committee rotation occurs, the committee node synchronizes with the members of the next committee. The necessary QC and the latest block information, 2.3 Catch-up Mechanism: Each committee member synchronizes all blocks delivered by that committee, i.e., when any node... When the latest block state is not synchronized, It will send a message to the committee that it has the latest record of to request synchronization to the latest state; the committee will then send... Synchronize all blocks it delivers and their associated proofs; Step 3: When committee members run the modified BFT protocol After consensus is reached on a block, the consensus result is communicated to all non-committee members, provided that the block contains only regular BFT protocol commands. If this happens, the committee will not rotate; the current committee will continue the next round of consensus, repeating the above process until the latest block that has reached consensus contains exactly this. indivual Then, the nodes corresponding to the commands form the first... The committee will take over from the previous one after synchronization is completed. The committee began operating. The agreement is reached and a new block is delivered.

2. The BFT protocol scalability optimization method based on committee sampling according to claim 1, characterized in that, When verifying a block, the following two cases are distinguished: (a) the block and its parent block were proposed by the same committee; (b) the block was proposed by a new committee, and the verification of the former is the same as that of the latter. They are almost identical, but the verification of the latter utilizes information provided by the previous committee to ensure that the newly delivered block is a direct extension of the latest preceding block.

3. The BFT protocol scalability optimization method based on committee sampling according to claim 1, characterized in that, use This represents the actual number of random numbers that meet the requirements. Then the leader will only select the smallest one. The number is sufficient; if The newly proposed block will not contain The block will still be delivered, but there will be no committee rotation.

4. The BFT protocol scalability optimization method based on committee sampling according to claim 1, characterized in that, The following state synchronization is performed between committee and non-committee nodes in each view: i) Modified BFT Protocol The leader of each view proposes a block via broadcast; ii) Once the delivery of any block is completed, all committee nodes will send the delivery proof of that block to all non-committee nodes; iii) When any non-committee node Received no less than One proof, The corresponding block will be delivered, where: The number of Byzantine nodes. .

5. The BFT protocol scalability optimization method based on committee sampling according to claim 1, characterized in that, When a committee switch occurs, the current committee and the next committee will synchronize their states as follows: i) Current committee members will implement the modified BFT protocol. The necessary information is synchronized with the next committee members to address temporary desynchronization issues caused by network fluctuations; ii) When any member of the next committee receives not less than When a synchronization message is sent, the latest block will be delivered and its own will be updated. The relevant states required by the module, including: This represents the number of Byzantine nodes.

Images