A lightweight Byzantine fault-tolerant consensus method and system

Abstract

This invention discloses a lightweight Byzantine fault-tolerant consensus method and system. The method proceeds as follows: Step 1: In a consortium blockchain application scenario, the consensus master node sends heartbeat packets to the node cluster, confirming the number of nodes based on the number of responses within a fixed time period; Step 2: The client generates a request and transmits the request message to the consensus master node; Step 3: After the master node verifies the request message, consensus enters a three-stage voting phase; after voting, the three-stage voting messages are stored in the node's message pool using a two-level replication method. This invention optimizes Byzantine fault-tolerant consensus, reducing the amount of communication data and storage space.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, specifically relating to a new Byzantine fault-tolerant method and system that is lightweight in terms of storage and communication bandwidth, which uses a hierarchical replica replication method to solve the message replication problem in consensus. Background Technology

[0002] Practical Byzantine Fault Tolerance (PBT) is a distributed consensus protocol that can tolerate malicious behavior from nodes. In a PBT, to tolerate malicious behavior from any f nodes, at least N = 3f + 1 nodes are needed; simply put, Byzantine nodes do not exceed one-third of the total number of nodes. Furthermore, current practical PBT protocols typically include three phases, two of which involve full-node broadcast communication, thus their communication overhead is O(N^2). 2 The corresponding storage cost is also N times the original data volume. In distributed storage scenarios, the number of nodes is even larger, and the storage capacity reaches hundreds of petabytes or even exabytes.

[0003] Traditional practical Byzantine fault-tolerant protocols employ a full-replica replication mechanism for consistency: when the original file size is M bits, the amount of data exchanged in the system is at least M times N. Even with only three-stage voting messages, the communication data volume is 2N. 2 The number of messages in the consensus mechanism is a multiple of N-1; based on the publication of the request file, the amount of communication data is a multiple of N. Therefore, the number of messages in the consensus mechanism is positively correlated with the number of nodes. Traditional Byzantine fault-tolerant protocols have significant fault-tolerance advantages in terms of malicious node behavior, but they are complex and lack flexibility. Summary of the Invention

[0004] To address the aforementioned issues, this invention employs a hierarchical replication method to optimize Byzantine consensus, providing a low-bandwidth, low-storage Byzantine fault-tolerant consensus method and system.

[0005] The present invention adopts the following technical solution:

[0006] A lightweight Byzantine fault-tolerant consensus method is proposed, which proceeds in the following steps:

[0007] Step 1: In a consortium blockchain application scenario, the master node sends heartbeat packets to the node cluster, and the number of nodes N is confirmed based on the number of responses from nodes within a fixed time period. Parameters k and m will be adjusted according to the formula k + m = N;

[0008] Step 2: The client generates a request and sends the request message to the consensus master node. <request>This includes information such as the client ID, client signature, and the specific request M;

[0009] Step 3: Master Node Verification <request>After that, the consensus will enter the three-stage voting stage; after the voting, the three-stage voting messages will be stored in the node's message pool through a two-level replication method.

[0010] Preferably, in step 3, the node generates different message files, including <pre-prepare> 、 <prepare>and

[0011] <commit>Before broadcasting a message, the node iterates through the message to determine different replication methods. If the message file is represented as X, the determination method is as follows: Record the file message that does not contain the request as A, otherwise as B;

[0012] Step 3.1: If X = A, the node adopts the first-level replica replication method so that the target node contains the same content as the source node;

[0013] Step 3.2: If X = B, the node traverses the replicas, decoupling M from the other contents of the replicas. The remaining messages are replicated using a first-level replica method, while M is replicated using a second-level replica method.

[0014] Preferably, step 3.1 is as follows:

[0015] Step 3.1.1: The source node uses a data backup or data copying method to create multiple copies of the X file;

[0016] Step 3.1.2: The source node transmits a complete copy to the target node sequentially;

[0017] Step 3.1.3: If the replica signature is verified as valid by the target node, it is placed in the message pool and awaits confirmation.

[0018] Preferably, step 3.2 is as follows:

[0019] Step 3.2.1: Fill the source node with the length of M until it is a multiple of N; write part of the data of M into N empty files in sequence to obtain an N×1 message block matrix; N is the number of nodes;

[0020] Step 3.2.2: The source node multiplies the encoding matrix on the left before the message block matrix, generating k original data blocks and m redundant blocks; if N = 256, M will be divided into 256 data blocks, and the encoding representation of M is as follows:

[0021]

[0022] {D1,D2,…,D 256 The data blocks are divided into segments. Multiplying them by a 256×(256+X) encoding matrix on the left yields the data blocks {D1,D2,…,D} to be distributed. 256 C1, C2, ..., C X };

[0023] Step 3.2.3: The source node will {D1,D2,…,D…} 256 C1, C2, ..., C X The data blocks and message headers are combined and then distributed to various nodes;

[0024] Step 3.2.4: The target node receives and checks the replica. Data blocks that pass the check are stored in the message pool and await confirmation.

[0025] Preferably, in step 3, if more than a set number of nodes reach a consensus vote, this result is taken as the consensus result, and all nodes confirm all data related to this request; otherwise, if the consensus fails, the data in the message pool is deleted.

[0026] Preferably, step 4 is also included: when a view switch occurs, the system needs to re-select a master node. The new master node needs to repair any incompletely confirmed requests, ensuring that the master node has a complete copy of the request in any view. This guarantees that request messages are fully repairable when the old master node is available. The repair by the new master node includes two methods: first, requesting direct repair from the old master node; second, calling valid coded block erasure repair from the slave node. Specifically:

[0027] Step 4.1: If the old master node has not left the consensus cluster and is available, the new master node requests a replica from the old master node. The old master node sends snapshot data to the new master node, allowing the new master node to obtain valid data from the old master node and thus achieve repair.

[0028] Step 4.2: If the old master node is unavailable, method two is used to repair the replica. The master node collects any k encoded blocks with the same request sequence number and view number, and restores the replica through the decoding matrix;

[0029] Step 4.3: After completing the above steps, the new master node has a complete copy of the request file. All nodes re-establish consensus. If the repair fails, the new master node notifies other nodes to delete the data blocks and logs related to this request.

[0030] Preferably, step 4.2 is as follows:

[0031] Step 4.2.1: The new master node sends a message requesting the collection of coded blocks, finds the corresponding coded blocks locally on the online and honest slave node, and transmits the coded blocks to the new master node in response;

[0032] Step 4.2.2: If the encoded blocks collected by the new master node are at least {D1, D2, ..., D...} 256 C1, C2, ..., C X The presence of k blocks in the sequence indicates that the number of lost coded blocks has not exceeded the repair threshold, and the repair can be successful. The new master node sorts the collected coded blocks by their sequence number, multiplies them by the decoding matrix on the right side of each block, and obtains the fully repaired data block. The repair of the request message is calculated according to the following formula:

[0033]

[0034] Then write the data blocks into a blank file one by one to obtain a complete copy of the file.

[0035] This invention also discloses a system based on the above-mentioned Byzantine fault-tolerant consensus method, which includes the following modules:

[0036] Heartbeat sending module: In consortium blockchain application scenarios, the consensus master node sends heartbeat packets to the node cluster, and the number of nodes is confirmed based on the number of node responses within a fixed time.

[0037] Request generation module: The client generates a request and sends this request message to the consensus master node, which contains the specific request content;

[0038] Voting Module: After the master node verifies the request message, consensus enters a three-phase voting process. All messages use a tiered replica replication method to achieve lightweight transmission.

[0039] Consensus Result Judgment Module: The three-stage voting message is stored in the node's message pool through a two-level replication method; if more than a set number of nodes reach a consensus voting result, this result is taken as the consensus result, and all nodes confirm all data related to this request.

[0040] Furthermore, it also includes a repair module: when a view switch occurs, the new master node repairs any unconfirmed request messages, ensuring that the master node has a complete copy of the request in any view.

[0041] This invention employs a tiered replication method, determining the replication method based on whether a request file exists within the message. If no request file exists, a first-level replication method is used, completely replicating the message to the node's storage space. If the message contains request content, it is decoupled into two categories: a message header and a request file. The message header includes the view number, request sequence number, and message digest, while the request file represents the operation to be executed by the client. The first-level replication method is still applied to the message header, but a second-level replication method is applied to the request file; thus optimizing Byzantine fault-tolerant consensus and reducing communication data volume and storage space requirements. Attached Figure Description

[0042] Figure 1 This is a flowchart of a lightweight Byzantine fault-tolerant consensus method according to a preferred embodiment.

[0043] Figure 2 This is a flowchart of the first-level copy replication method.

[0044] Figure 3 This is a flowchart of the two-level copy replication method.

[0045] Figure 4 This is a diagram showing the decoupling of the message header and request M.

[0046] Figure 5 It calls the repair module from the slave node.

[0047] Figure 6 This is a block diagram of a lightweight Byzantine fault-tolerant consensus system according to a preferred embodiment. Detailed Implementation

[0048] The present invention will be further described in detail below with reference to the preferred embodiments and accompanying drawings.

[0049] To address the aforementioned problems in existing technologies, this invention presents a lightweight Byzantine fault-tolerant consensus method and system that reduces bandwidth consumption and storage space requirements.

[0050] This invention applies erasure coding technology to consensus technology. By decoupling consensus messages and applying different replication methods to different message types, it reduces the bandwidth and storage resource consumption of consensus. This invention relates to a two-level replica replication method.

[0051] In the Byzantine Fault Tolerant Consensus, most messages are established in a many-to-many format, with one node N... i It broadcasts its state to all other nodes in the cluster, so the number of messages is squared as the number of nodes. Node N i The message contains basic information such as its view number, node number, message sequence number, and message digest. This basic information is much smaller than the request and needs to be compared promptly when verified by other nodes. Therefore, the integrity of this hot data must be maintained. For this message portion, the first-level replication method in a two-level replication approach is adopted; some nodes N i The message also contains a large amount of original request files. The request replicas play a backup role in the consensus process and do not require real-time verification. Therefore, the second-level replication method in the two-level replication method is adopted to store the request in blocks in the nodes to reduce the storage pressure of the entire system.

[0052] In summary, this embodiment applies a two-level replica replication method to consensus to achieve practicality and lightweight consensus, such as... Figure 1 As shown, a lightweight Byzantine fault-tolerant consensus method has the following steps:

[0053] Step 1: In a consortium blockchain application scenario, the consensus master node sends heartbeat packets to the node cluster, and the number of nodes N is confirmed based on the number of responses from nodes within a fixed time period. Parameters k and m will be adjusted according to the formula k + m = N;

[0054] Step 2: The client generates a request and sends the request message to the consensus master node. <request>This includes the specific request content, denoted as M;

[0055] Step 3: Master Node Verification <request>Afterwards, consensus will proceed to a three-stage voting process. Nodes will generate different message files, including... <pre-prepare> 、 <prepare>and <commit>Before broadcasting a message, the node iterates through the message to determine different replication methods. If the message file is represented as X, the determination method is as follows: Files that do not contain a request file message are designated as A; otherwise, they are designated as B.

[0056] Step 3.1: If X = A, the node uses the first-level replica replication method, and the target node contains the same content as the source node;

[0057] Step 3.1.1: The source node uses a data backup or data copying method to create multiple copies of the X file;

[0058] Step 3.1.2: The source node transmits a complete copy to the target node sequentially;

[0059] Step 3.1.3: If the replica signature is verified as valid by the target node, it is placed in the message pool and awaits confirmation.

[0060] Step 3.2: If X = B, traverse the replicas from the source node, decoupling M from the other content of the replicas, such as... Figure 4 As shown. The remaining message headers are still replicated using a single-level replication method, while M is replicated using a two-level replication method;

[0061] Step 3.2.1: Fill the source node with the length of M until it becomes a multiple of N. Write portions of M into N empty files sequentially to obtain an N×1 message block matrix;

[0062] Step 3.2.2: The source node multiplies the encoding matrix on the left before the message block matrix, generating k original data blocks and m redundant blocks. If N = 256, M will be divided into 256 data blocks, and the encoding of file M can be represented as:

[0063]

[0064] {D1,D2,…,D 256 The data blocks are divided into segments. Multiplying them by a 256×(256+X) encoding matrix on the left yields the data blocks {D1,D2,…,D} to be distributed. 256 C1, C2, ..., C X };

[0065] Step 3.2.3: The source node will {D1,D2,…,D…} 256 C1, C2, ..., C X The data blocks and message headers are combined and then distributed to various nodes;

[0066] Step 3.2.4: The target node receives and inspects the replica. Data blocks that pass the inspection will be stored in the message pool, awaiting confirmation.

[0067] After voting, the three-phase voting messages are stored in the node's message pool using a two-level replication method. If more than two-thirds of the nodes can reach a consensus vote, this result is taken as the final consensus result, and all nodes confirm all data related to this request; if consensus fails, the data cached in the message pool is deleted.

[0068] Step 4: When a view switch occurs, the new master node repairs any incompletely acknowledged request messages, ensuring that the master node has a complete copy of the request in any view. This guarantees that request messages can be fully repaired when the master node is responsive. The new master node's repair includes two methods: first, requesting direct repair from the old master node; second, calling valid coded block erasure repair from the slave node.

[0069] Step 4.1: If the old master node has not left the consensus cluster and can respond, the new master node requests a replica from the old master node. The old master node sends snapshot data to the new master node, allowing the new master node to obtain valid data from the old master node and thus achieve repair.

[0070] Step 4.2: If the old master node is unavailable, this embodiment uses method two to repair the replica. Figure 4 As shown;

[0071] Step 4.2.1: Since the number of encoded blocks is equal to the number of nodes, the new master node must possess one of the requested encoded blocks. Therefore, the new master node sends a message requesting the collection of encoded blocks. Online and honest slave nodes find the corresponding local encoded block based on elements such as the view number and request number in the message, and transmit the encoded block to the new master node in response.

[0072] Step 4.2.2: If the encoded blocks collected by the new master node are at least {D1, D2, ..., D...} 256 C1, C2, ..., C X The presence of k blocks in the sequence indicates that the number of lost coded blocks has not exceeded the repair threshold, and repair can be successful. The new master node sorts the collected coded blocks by their sequence number, multiplies them by the decoding matrix on the right side of each block, and obtains the fully repaired data block. The repair of the request message is calculated according to the following formula:

[0073]

[0074] Then, write the data content of the data blocks into a blank file in sequence to obtain a complete copy file;

[0075] Step 4.3: After completing the above steps, the new master node has a complete copy of the request file. All nodes re-establish consensus. If the repair fails, the new master node notifies other nodes to delete the data blocks and logs related to this request.

[0076] like Figure 6 As shown, this embodiment discloses a system based on the above-described Byzantine fault-tolerant consensus method, which includes the following modules:

[0077] Heartbeat sending module: In consortium blockchain application scenarios, the consensus master node sends heartbeat packets to the node cluster, and the number of nodes is confirmed based on the number of node responses within a fixed time.

[0078] Request generation module: The client generates a request and sends this request message to the consensus master node, which contains the specific request content;

[0079] Voting Module: After the master node verifies the request message, consensus enters a three-phase voting process. All messages use a tiered replica replication method to achieve lightweight transmission.

[0080] Consensus Result Judgment Module: The three-stage voting message is stored in the node's message pool through a two-level replication method; if more than a set number of nodes reach a consensus voting result, this result is taken as the consensus result, and all nodes confirm all data related to this request;

[0081] Repair module: When a view switch occurs, the new master node repairs any unconfirmed request messages, ensuring that the master node has a complete copy of the request in any view.

[0082] The above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.< / commit> < / prepare> < / pre-prepare> < / request> < / request> < / commit> < / prepare> < / pre-prepare> < / request> < / request>

Claims

1. A lightweight Byzantine fault-tolerant consensus method, characterized by: Follow these steps: Step 1: In consortium blockchain application scenarios, the consensus master node sends heartbeat packets to the node cluster, and confirms the number of nodes based on the number of node responses within a fixed time period. Step 2: The client generates a request and sends the request message to the consensus master node; Step 3: After the master node verifies the request message, the consensus process enters the three-stage voting phase. After the voting process, the three-stage voting messages are stored in the node's message pool using a two-level replication method. In step 3, nodes generate different message files; before broadcasting a message, the node traverses the message files to determine different replication methods; let the message file be represented as X, and the determination method is as follows: The message file that does not contain a request file is denoted as A, otherwise it is denoted as B; M is the specific request file contained in the message file; Step 3.1: If X = A, the node uses the first-level replica replication method to completely copy the message file to the node's storage space, and the target node contains the same content as the source node; Step 3.2: If X = B, the source node traverses the message file and decouples M from the other contents of the message file into: message header and request file M; the message header is copied using a first-level replica to completely copy the message header to the node storage space, while the request is copied using a second-level replica to store the request in blocks in the node.

2. The lightweight Byzantine fault-tolerant consensus method as described in claim 1, characterized in that: Step 3.1 is as follows: Step 3.1.1: The source node uses a data backup or data copying method to create multiple copies of the X file; Step 3.1.2: The source node transmits a complete copy to the target node sequentially; Step 3.1.3: If the replica signature is verified as valid by the target node, it is placed in the message pool and awaits confirmation.

3. The lightweight Byzantine fault-tolerant consensus method as described in claim 2, characterized in that: Step 3.2 is as follows: Step 3.2.1: Fill the source node with the length of M until it is a multiple of N; write part of the data of M into N empty files in sequence to obtain an N×1 message block matrix; N is the number of nodes; Step 3.2.2: The source node multiplies the encoding matrix on the left before the message block matrix to generate k original data blocks and m redundant blocks; If N = 256, M will be divided into 256 data blocks, and the encoding of M is as follows: {D1,D2,…,D 256 The data blocks are divided into segments. Multiplying them by a 256×(256+X) encoding matrix on the left yields the data blocks {D1,D2,…,D} to be distributed. 256 C1, C2, ..., C X }; Step 3.2.3: The source node will {D1,D2,…,D…} 256 C1, C2, ..., C X The data blocks and message headers are combined and then distributed to various nodes; Step 3.2.4: The target node receives and checks the replica. Data blocks that pass the check are stored in the message pool and await confirmation.

4. A lightweight Byzantine fault-tolerant consensus method as described in any one of claims 1-3, characterized in that: In step 3, if more than a set number of nodes reach a consensus vote, this result is taken as the consensus result, and all nodes confirm all data regarding this request. Otherwise, if consensus fails, the data cached in the message pool will be deleted.

5. A lightweight Byzantine fault-tolerant consensus method as described in any one of claims 1-3, characterized in that: It also includes step 4: when a view switch occurs, the new master node repairs the request messages that have not been fully confirmed, so that the master node has a complete copy of the request in any view.

6. The lightweight Byzantine fault-tolerant consensus method as described in claim 5, characterized in that: Step 5 is as follows: Step 4.1: If the old master node has not left the consensus cluster and can respond, the new master node requests a replica from the old master node; the old master node sends snapshot data to the new master node, so that the new master node can obtain the valid data on the old master node and achieve repair. Step 4.2: If the old master node is unavailable, use the valid coded block erasure repair method to call the slave node to repair the replica; Step 4.3: The new master node has a complete copy of the requested file; All nodes re-establish consensus; If the repair fails, the new master node will notify other nodes to delete the data blocks and logs related to this request.

7. A lightweight Byzantine fault-tolerant consensus method as described in claim 6, characterized in that: Step 4.2 is as follows: Step 4.2.1: The new master node sends a message requesting the collection of coded blocks, finds the corresponding coded blocks locally on the online and honest slave node, and transmits the coded blocks to the new master node in response; Step 4.2.2: If the encoded blocks collected by the new master node are at least {D1, D2, ..., D...} 256 C1, C2, ..., C X The presence of k blocks in the sequence indicates that the number of lost coded blocks has not exceeded the repair threshold, and the repair can be successful. The new master node sorts the collected coded blocks by their sequence number, multiplies them by the decoding matrix on the right side of each block, and obtains the fully repaired data block. The repair of the request message is calculated according to the following formula: Then write the data blocks into a blank file one by one to obtain a complete copy of the file.

8. A system based on the Byzantine fault-tolerant consensus method according to any one of claims 1-7, characterized in that: Includes the following modules: Heartbeat sending module: In consortium blockchain application scenarios, the consensus master node sends heartbeat packets to the node cluster, and the number of nodes is confirmed based on the number of node responses within a fixed time. Request generation module: The client generates a request and sends a request message to the consensus master node, which contains the specific request content; Voting module: After the master node verifies the request message, consensus enters a three-stage voting phase; all messages use a tiered replica replication method to achieve lightweight transmission; Consensus Result Judgment Module: The messages from the three-stage voting are stored in the node's message pool using a two-level replication method.

9. The system as described in claim 8, characterized in that: It also includes a repair module: when a view switch occurs, the new master node repairs any unconfirmed request messages, ensuring that the master node has a complete copy of the request in any view.

Images