Fair Byzantine block chain fault-tolerant consensus method
By combining verifiable threshold encryption and consensus protocol in the blockchain consensus protocol, hiding the transaction content and decrypting it during the consensus process, the fairness and security issues of the blockchain consensus protocol are solved, and efficient and secure transaction sorting is achieved.
Patent Information
- Application Number
- CN202510948007.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-10
- Publication Date
- 2025-10-17
AI Technical Summary
Existing blockchain consensus protocols lack fairness, are vulnerable to attacks by malicious nodes, and suffer from the Concedo paradox and unfair transaction ordering problems. Existing timestamp methods rely on globally synchronized clocks and are difficult to achieve fair ordering.
By integrating verifiable threshold encryption with consensus protocols, the transaction content is hidden through a transaction encryption algorithm that combines symmetric encryption and threshold public key encryption, and the transaction is decrypted during the consensus process. A fair consensus algorithm is used to reach transaction consensus, avoiding additional encryption and decryption processes.
It achieves privacy protection of transaction content during the consensus process, avoids malicious attacks, ensures the fairness and security of the system, reduces transaction latency, and improves system performance and scalability.
Smart Images
Figure CN120811656A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application relates to a fair Byzantine fault-tolerant consensus method for a blockchain. BACKGROUND
[0002] A consensus protocol determines the order of transactions in a block by a master node, and lacks fairness. Existing fair ordering consensus protocols are based on the ordering of transactions by a majority of nodes, but cannot achieve strong ordering due to the problem of circular ordering. Some improved methods use timestamps, but are vulnerable to attacks by malicious nodes. Existing blockchain double-layer consensus technologies cannot achieve fair ordering, because the master node can determine the transaction order itself, and the transactions are not protected by encryption, so the system is vulnerable to race attack. SUMMARY
[0003] The application is directed to the fact that existing fair ordering methods rely on the transaction order of each consensus node, are limited by the Condorcet paradox, and have short boards in performance and Byzantine fault tolerance. Existing timestamp methods rely on a global synchronous clock and are vulnerable to attacks by malicious nodes. Existing transaction hiding methods have long delays, high overheads, and poor scalability. The application provides a fair Byzantine fault-tolerant consensus method that directly completes message encryption and decryption in the consensus scheme by fusing verifiable threshold encryption and decryption with the consensus protocol. The method solves the Condorcet paradox faced by existing fair consensus schemes, achieves strong fair ordering, avoids using a global synchronous clock, is more practical, avoids adding additional encryption and decryption processes at the application layer, and directly guarantees the fairness, liveness and security of the protocol at the consensus layer.
[0004] The application is implemented by the following technical solutions:
[0005] The application relates to a fair Byzantine fault-tolerant consensus method, comprising:
[0006] Step 1. In a fair Byzantine fault-tolerant consensus system, all formula nodes perform system initialization to generate all keys used for transaction encryption and decryption in the scheme.
[0007] Step 2. The client executes a transaction encryption algorithm that combines symmetric encryption and threshold public key encryption to hide the transaction content and prevent attackers from launching a race attack on the transaction content.
[0008] Step 3. The consensus nodes run a fair consensus algorithm in consecutive views, and reach agreement on the transaction data through a voting mechanism and simultaneously complete the decryption of the transaction.
[0009] Technical effects
[0010] The application uses a threshold encryption algorithm in a consensus protocol to protect the privacy of a transaction, avoids that a master node obtains the transaction content in a sorting stage, and designs a fusion method of threshold decryption of an encryption algorithm and master node update in a consensus process, so that the consensus block can complete consensus while decrypting the transaction content and designing a threshold encryption method of mixed symmetric encryption and asymmetric encryption, and only needs to run a key generation algorithm once.
[0011] Compared with the prior art, the application encrypts and protects the transaction initiated by the client, and an attacker cannot see the transaction content before the transaction reaches consensus and then initiates a front-running attack according to the content, so that the fairness of the system is guaranteed while the activity and security of the system are guaranteed, the attacker cannot construct a malicious transaction to make the consensus protocol unable to reach consensus, and cannot make the consensus nodes have inconsistent transaction data, and there is no additional decryption delay after the transaction reaches consensus, and the execution efficiency is high. BRIEF DESCRIPTION OF DRAWINGS
[0012] Figure 1 is a flowchart of the application;
[0013] Figure 2 is a system running flowchart;
[0014] Figure 3 is a system initialization flowchart;
[0015] Figure 4 is a transaction encryption flowchart;
[0016] Figure 5 is a fair consensus flowchart;
[0017] Figure 6 is a decryption flowchart in the fair consensus;
[0018] Figure 7 is an execution flowchart in the fair consensus;
[0019] Figure 8 is a view switching flowchart in the fair consensus;
[0020] Figure 9 is a prior art sequential fairness consensus protocol flowchart in the embodiment;
[0021] Figure 10 is a prior art threshold encryption method flowchart in the embodiment. DETAILED DESCRIPTION
[0022] The embodiment relates to a fair Byzantine block chain fault-tolerant consensus system composed of one consensus node as a master node and n consensus nodes as copies, and aims at problems such as Figure 1In the semi-synchronous Byzantine fault-tolerant protocol scenario shown, the client and consensus node are in a peer-to-peer network. The client will need to maintain fair transaction encryption to avoid leaking transaction content before consensus, and send these encrypted transactions to the consensus node. All consensus nodes reach a consensus on the transaction under the coordination of the master node and synchronously complete the decryption to put the transaction content on the chain.
[0023] There is a reliable communication channel between any two nodes in the peer-to-peer network. There are at most 1 / 3 malicious nodes in the consensus nodes, and malicious nodes can arbitrarily carry out malicious behaviors to interfere with the operation of the system. After a global stabilization time, the message transmission between any two correct nodes will be correctly transmitted within the upper limit of the network delay, that is, a semi-synchronous network state.
[0024] like Figure 2 As shown, the fair Byzantine blockchain fault-tolerant consensus method involved in this embodiment includes:
[0025] Step 1: Figure 3 As shown, all formula nodes perform system initialization to generate all the keys used for transaction encryption and decryption in the scheme, including:
[0026] 1.1. The decryption threshold between n consensus nodes is 2 / 3 The initialization algorithm in the verifiable threshold encryption algorithm uses a distributed key generation algorithm to generate each node's own unique private key. , verify the public key and the encrypted public key , specifically: ;
[0027] 1.2. The consensus node will generate the verification key and encrypted public key Recorded to blockchain.
[0028] Step 2: Figure 4 As shown, the client executes a transaction encryption algorithm that combines symmetric encryption and threshold public key encryption to hide the transaction content and prevent attackers from launching front-running attacks on the transaction content. Specifically, it includes:
[0029] 2.1. Whenever a client initiates a transaction When a symmetric key is randomly generated, the symmetric key is used For transactions Use symmetric encryption algorithms Encrypt to obtain the ciphertext of the transaction, specifically: ;
[0030] like Figure 4As shown, the encryption described in step 2.1 above is implemented by a verifiable threshold encryption algorithm, including:
[0031] a) Initialization: generate a verification public key , an encryption public key and n shards of a decryption private key according to a distributed key generation algorithm, each participant obtains a shard , specifically: ;
[0032] b) Encryption: use the encryption public key to asymmetrically encrypt the plaintext to obtain ciphertext, specifically: .
[0033] c) Partial decryption: each participant uses a shard of the decryption private key to decrypt the ciphertext to obtain a decryption share : .
[0034] d) Verification: use the verification public key to verify whether the decryption share is the correct share of the corresponding ciphertext: .
[0035] e) Aggregation: aggregate t correct decryption shares into the corresponding plaintext according to the aggregation algorithm of threshold encryption, specifically: .
[0036] 2.2, the client reuses the threshold encryption public key obtained in the system initialization algorithm , and uses the encryption algorithm of threshold encryption to encrypt the symmetric key to obtain the ciphertext of the symmetric key : .
[0037] 2.3, the client packs and sends the transaction ciphertext and key ciphertext to the consensus node.
[0038] Step 3, as shown in Figure 5 , the consensus nodes run the fair consensus algorithm in the continuous view, reach agreement on the transaction data through the voting mechanism and complete the decryption of the transaction at the same time, specifically including:
[0039] 3.1、In the proposal phase, the leader of the current view proposes a block as a proposal of consensus and broadcasts it to each replica. The leader of the current view first extracts the block with the highest view number from the view switch message and checks the status of the block: when the block has been decrypted, the leader proposes a new block that continues the block and includes a certain number of encrypted transactions; otherwise, the leader re-proposes the block. This strategy ensures that the block that completes the lock will be decrypted.
[0040] 3.2、In the voting phase, consensus nodes reach consensus on the block through multiple rounds of voting. The leader collects the votes of each node and verifies the legality of the signature of the vote. When the leader collects 2 / 3 of the legal votes, it aggregates the vote signatures and broadcasts them to each node to initiate the next round of voting. After receiving the message from the leader, the replica verifies whether the aggregated signature is legal and decides whether to cast its own vote. In the voting phase, first, the consensus nodes will conduct a pre-vote for multiple rounds until the proposed block completes the lock round of voting and is in a locked state.
[0041] 3.3、As shown in Figure 6 , in the submission round after the lock, partial decryption of the symmetric key ciphertext will be completed, and the replica uses its own decryption private key to threshold-decrypt the transactions in the block, i.e. , to obtain the decryption share After that, the decryption share is sent to the leader in the vote of the lock round; after receiving the vote, the leader first uses the threshold encryption verification algorithm to verify the legality of the decryption share in the vote; then extracts 2n / 3 legal decryption shares, runs the threshold encryption aggregation algorithm to recover the corresponding symmetric key, and broadcasts the symmetric key and all received votes to each replica.
[0042] 3.4、As shown in Figure 7 , in the execution phase, the consensus node uses the recovered symmetric key to decrypt the transactions in the block, specifically:
[0043] i) The consensus node verifies the correctness of the decryption share of all received votes, and when all verifications are successful, it runs the threshold encryption aggregation algorithm to recover the symmetric key ; otherwise, it is considered that the decryption of the block has failed.
[0044] ii) For each encrypted transaction in the block, when the key recovered by the leader and the key recovered by itself are consistent, the symmetric decryption algorithm is run on the transaction to decrypt it; otherwise, it is considered that the decryption of the block has failed.
[0045] 3.5, such as Figure 8 As shown in Figure 1, during the view switching phase, the consensus node switches to the next view and begins a new round of consensus. The view switching phase begins when the previous phase times out or completes successfully. Specifically, the consensus node sends the locked block and information about whether the block has been decrypted as view switching information to the leader of the next view. The leader then enters the proposal phase for the next view.
[0046] Through specific practical experiments, the performance of this fair consensus algorithm can be measured by running it across distributed nodes. Consensus algorithm performance is measured by throughput and latency. Throughput represents the number of transactions that can be reached consensus per second, while latency represents the time between a client initiating a transaction and receiving confirmation that the transaction has reached consensus. Higher throughput and lower latency indicate better system performance. The fair consensus algorithm was stress-tested with varying numbers of distributed nodes and block sizes: 4, 8, and 16 nodes were used, and block sizes of 50, 100, 200, and 400 were used. Consensus nodes were distributed across Europe, the Western United States, the Eastern United States, and East Asia, and communication latency between consensus nodes was approximately 100 milliseconds. The experiments employed the AES-256 symmetric encryption algorithm and identity-based threshold encryption. The peak throughput and corresponding latency of the system were measured. Each data point is the average of three replicates, as shown in Tables 1 and 2.
[0047] Table 1
[0048] Table 2
[0049] This invention is used to achieve fair consensus in a blockchain system. During implementation, the blockchain consensus node first executes the system initialization algorithm described in this invention to generate the required keys. During a transaction, the client encrypts the transaction using the transaction encryption algorithm described in this invention and sends it to the blockchain consensus node. The consensus node then executes the consensus algorithm, including the decryption algorithm described in this invention, to confirm and decrypt the user's transaction.
[0050] like Figure 9The figure below compares this method with the sequential fairness consensus protocol Aequitas. Aequitas suffers from the Condorcet paradox, allowing attackers to maliciously construct transaction sets with circular dependencies, preventing the protocol from performing fair sorting. However, this method, through a mechanism that hides transaction content, prevents manipulation of transaction order from the source, ensuring sorting fairness. While Aequitas can only tolerate 1 / 4 malicious nodes, this method's fair consensus protocol can tolerate 1 / 3 malicious nodes, demonstrating improved Byzantine fault tolerance.
[0051] Comparison between this method and the strong fairness approach, Pompe: The Pompe protocol uses a timestamp mechanism to implement transaction sorting, which requires a globally synchronized clock. Maintaining synchronized clocks in a distributed environment is extremely difficult. This method does not rely on a global clock, making it easier to implement. In the Pompe protocol, each transaction collects the timestamps of two-thirds of the nodes and takes the median for sorting. This median timestamp can be manipulated to some extent by malicious nodes, thus affecting the order of transactions. This method, however, uses a transaction hiding mechanism to achieve fair sorting, which is immune to the influence of malicious nodes forging timestamps.
[0052] like Figure 10 The figure below compares this method with the threshold encryption method F3B. In F3B, transactions are encrypted and then consensus is reached by consensus nodes. Once consensus is reached, decryption is performed by decryption nodes. Decryption is a separate process from consensus and incurs additional latency. In contrast, this method decrypts encrypted transactions simultaneously during the consensus process, eliminating the need for additional decryption latency and resulting in better performance.
[0053] Compared with existing technologies, this method improves system performance, reduces transaction latency, and enhances system scalability. The key lies in integrating consensus voting with threshold decryption processes. This allows for simultaneous completion of consensus voting and decryption share exchange within a single round-trip communication delay, eliminating the overhead of an additional round of decryption communication and effectively reducing latency. This reduced latency allows for more efficient communication as the number of nodes increases, optimizing scalability across the network scale.
[0054] The above-mentioned specific implementation can be partially adjusted in different ways by those skilled in the art without departing from the principles and purpose of the present invention. The scope of protection of the present invention shall be based on the claims and shall not be limited by the above-mentioned specific implementation. All implementation schemes within its scope shall be subject to the constraints of the present invention.
Claims
1. A fair Byzantine fault-tolerant blockchain consensus method, characterized by: include: Step 1: In a fair Byzantine blockchain fault-tolerant consensus system, all formula nodes initialize the system to generate all the keys used for transaction encryption and decryption in the scheme; Step 2: The client executes a transaction encryption algorithm that combines symmetric encryption and threshold public key encryption to hide the transaction content and prevent attackers from launching front-running attacks on the transaction content. Step 3: Consensus nodes run a fair consensus algorithm in a continuous view, reach consensus on transaction data through a voting mechanism, and complete the decryption of the transaction at the same time.
2. The fair Byzantine blockchain fault-tolerant consensus method according to claim 1 is characterized in that: The fair Byzantine fault-tolerant blockchain consensus system includes: 1 consensus node as a master node and n consensus nodes as replicas. For the semi-synchronous Byzantine fault-tolerant protocol scenario, the client and the consensus node are in a peer-to-peer network. The client encrypts transactions that need to maintain fairness to avoid leaking transaction content before consensus, and sends these encrypted transactions to the consensus node. All consensus nodes reach consensus on the transaction under the coordination of the master node and simultaneously complete decryption to achieve the transaction content on the chain. There is a reliable communication channel between any two nodes in the peer-to-peer network. There are at most 1 / 3 malicious nodes in the consensus nodes, and the malicious nodes can arbitrarily carry out malicious behaviors to interfere with the operation of the system. After a global stabilization time, the message transmission between any two correct nodes will be correctly transmitted within the upper limit of the network delay, that is, a semi-synchronous network state.
3. The fair Byzantine blockchain fault-tolerant consensus method according to claim 1 or 2, characterized in that: The system initialization specifically includes: 1.
1. The decryption threshold between n consensus nodes is 2 / 3 The initialization algorithm in the verifiable threshold encryption algorithm uses a distributed key generation algorithm to generate each node's own unique private key. , verify the public key and the encrypted public key , specifically: ; 1.
2. The consensus node will generate the verification key and encrypted public key Recorded to blockchain.
4. The fair Byzantine blockchain fault-tolerant consensus method according to claim 1 or 2, characterized in that: The hidden transaction content specifically includes: 2.
1. Whenever a client initiates a transaction When a symmetric key is randomly generated, the symmetric key is used For transactions Use symmetric encryption algorithms Encryption is performed to obtain the ciphertext of the transaction, specifically: ; 2.
2. The client then uses the threshold encryption public key obtained in the system initialization algorithm , using the threshold encryption algorithm to encrypt the symmetric key Encrypt to obtain the ciphertext of the symmetric key : ; 2.3、The client will send the transaction ciphertext and key ciphertext Package and send to consensus node.
5. The fair Byzantine blockchain fault-tolerant consensus method according to claim 4 is characterized in that: The encryption is implemented using a verifiable threshold encryption algorithm, including: a) Initialization: Generate a verification public key according to the distributed key generation algorithm , an encryption public key and n shards of the decrypted private key, one shard per participant , specifically: ; b) Encryption: using public encryption key Plaintext Perform asymmetric encryption to obtain the ciphertext, specifically: ; c) Partial decryption: Each participant uses a shard of the decryption private key Ciphertext Decrypt and get a decryption share : ; d) Verification: Use verification public key Verify that the decrypted share is the correct share for the corresponding ciphertext: ; e) Aggregation: Aggregate t correct decrypted shares Aggregate into the corresponding plaintext according to the aggregation algorithm of threshold encryption, specifically: .
6. The fair Byzantine blockchain fault-tolerant consensus method according to claim 1 or 2, characterized in that: The fair consensus algorithm specifically includes: 3.
1. In the proposal phase, the leader of the current view proposes a block as a consensus proposal and broadcasts it to all replicas. The leader of the current view first extracts the block with the highest view number from the view switch message and checks the status of this block. If the block has been decrypted, the leader proposes a new block that continues the block, including a certain number of encrypted transactions. Otherwise, the leader re-proposes the block. This strategy ensures that the locked block will be decrypted. 3.
2. During the voting phase, consensus nodes reach consensus on the block through multiple rounds of voting. The leader collects votes from each node and verifies the legitimacy of the voting signatures. Once the leader has collected 2 / 3 of the valid votes, it aggregates the voting signatures and broadcasts them to each node, initiating the next round of voting. After receiving the leader's message, the replica verifies the legitimacy of the aggregated signatures and decides whether to cast its own vote. During the voting phase, consensus nodes first conduct multiple rounds of voting until the proposed block completes the locked rounds of voting and is locked. 3.
3. In the submission round after locking, partial decryption of the symmetric key ciphertext will be completed, and the copies will use their own decryption private keys. Perform threshold decryption on transactions in the block, i.e. , get the decryption share After that, the decrypted share is attached to the locked round vote and sent to the leader; after the leader receives the vote, it first uses the threshold encryption verification algorithm To verify whether the decrypted shares in the vote are legal; then extract 2n / 3 legal decrypted shares, run the threshold encryption aggregation algorithm to recover the corresponding symmetric key, and broadcast the symmetric key and all received votes to each replica.
7. The fair Byzantine fault-tolerant blockchain consensus method according to claim 1 or 2, characterized in that: The decryption is specifically as follows: i) The consensus node verifies the correctness of the decrypted shares of all received votes, and runs the threshold encryption aggregation algorithm when all verifications are successful , recover the symmetric key ; Otherwise, the decryption of the block is considered to have failed; ii) For each encrypted transaction in the block, when the key recovered by the leader matches the key recovered by the leader, the symmetric decryption algorithm is run on the transaction. Decryption is performed; otherwise, the decryption of the block is considered to have failed.
8. The fair Byzantine blockchain fault-tolerant consensus method according to claim 1 or 2, characterized in that: During the view switching phase, the consensus node switches to the next view and performs a new round of consensus. When the previous phase times out or is successfully completed, the next view switching phase begins. Specifically, the consensus node sends the locked block and information about whether the block has been decrypted as view switching information to the leader of the next view. The leader then enters the proposal phase for the next view.