An efficient asynchronous consensus algorithm suitable for public chains and consortium chains

Abstract

The application discloses a high-efficiency asynchronous consensus algorithm suitable for public chains and alliance chains. 3 ) to the gradually optimal O(n 2 ), adopts a block producer active triggering model, and removes an asynchronous binary consensus phase in a traditional asynchronous consensus algorithm. In the asynchronous consensus algorithm, any node can propose a transaction request, which is consistent with the heterogeneous execution mode of the public chain. The asynchronous consensus algorithm adopts the heterogeneous transaction execution mode to fully release the concurrent execution capability of the system, and therefore the asynchronous consensus algorithm is also suitable for the alliance chain. The application improves the system throughput and reduces the transaction confirmation delay of the system.

Description

Technical Field

[0001] The present invention relates to the field of blockchain consensus algorithms, and more specifically to an efficient asynchronous consensus algorithm suitable for public and consortium chains. Background Art

[0002] Blockchain technology, a distributed ledger technology with decentralized infrastructure and tamper-proof information, is gaining increasing attention across various industries. It has garnered significant attention from government agencies, financial institutions, technology companies, and the capital market. Efficiently reaching consensus in blockchain systems is a key issue hindering their development and application. Asynchronous Byzantine Fault Tolerance (BFT) algorithms are gaining increasing attention due to their better fit with real-world network environments and leaderless model. However, semi-synchronous BFT protocols lose viability in unstable network environments. Asynchronous BFT algorithms, however, maintain viability and superior performance in these conditions, making them ideal for public and consortium blockchains. However, existing asynchronous BFT algorithms suffer from excessively high threshold signature verification overhead. Furthermore, the widely used asynchronous binary consensus protocol requires multiple rounds of interaction to reach consensus, severely hindering their performance. Summary of the Invention

[0003] This paper aims to provide an efficient asynchronous consensus algorithm suitable for public and consortium chains, which can solve the problems of low throughput and high latency in asynchronous Byzantine fault-tolerant protocols.

[0004] In order to solve the above technical problems, the specific solution adopted by the present invention is an efficient asynchronous consensus algorithm applicable to public chains and consortium chains, which includes the following steps:

[0005] S1: The client broadcasts the transaction to the nearest execution node based on the proximity principle;

[0006] S2: Each execution node broadcasts the transaction requests it receives from different clients. After receiving the transactions broadcast from other execution nodes, each execution node concurrently executes and verifies the transactions.

[0007] S3: Each execution node broadcasts the executed transaction sequence to all nodes;

[0008] S4: A lottery strategy is used to select a block producer from all execution nodes;

[0009] S5: All execution nodes evaluate whether the block producer has the right to record accounts. If the block producer has the right to record accounts, all nodes construct blocks according to the transaction order executed by the block producer; otherwise, the lottery stage of S4 is repeated.

[0010] As a further optimization of the high-efficiency asynchronous consensus algorithm suitable for public chains and consortium chains of the present application: each execution node in S2 initiates a block request asynchronously; the nodes adopt heterogeneous transaction execution modes.

[0011] As a further optimization of the high-efficiency asynchronous consensus algorithm suitable for public chains and consortium chains of the present application: each execution node in S3 first broadcasts the transaction order vector executed by itself to all nodes.

[0012] As a further optimization of the high-efficiency asynchronous consensus algorithm suitable for public chains and consortium chains of the present application: in the transaction order vector broadcast phase in S3, each execution node only verifies the proofs that have not been verified by itself when verifying the proofs in the transaction order vector, thereby reducing the threshold signature verification overhead.

[0013] As a further optimization of the high-efficiency asynchronous consensus algorithm suitable for public chains and consortium chains of the present application: the threshold signature verification overhead of the traditional asynchronous consensus algorithm is reduced from O(n 3 ) to the asymptotically optimal O(n 2 ) in the transaction broadcast phase and the vector broadcast phase.

[0014] As a further optimization of the high-efficiency asynchronous consensus algorithm suitable for public chains and consortium chains of the present application: after selecting the block producer, the block producer broadcasts its transaction order again to convince other execution nodes to construct blocks in the same order, thereby removing the asynchronous binary consensus phase in the traditional asynchronous consensus algorithm.

[0015] As a further optimization of the high-efficiency asynchronous consensus algorithm suitable for public chains and consortium chains of the present application: all nodes finally submit homogeneous blocks in S5.

[0016] As a further optimization of the high-efficiency asynchronous consensus algorithm suitable for public chains and consortium chains of the present application: each execution node in S5 determines whether the block producer has the right to record according to the transaction order broadcast in S3.

[0017] Advantages

[0018] In the asynchronous consensus algorithm of the present application, the nodes adopt heterogeneous transaction execution modes, which fully releases the concurrent execution capability of the system. Each execution node in the asynchronous consensus algorithm can broadcast the transaction order to determine whether the block producer is an honest node, which can prevent the block producer from being malicious. By reducing the threshold signature verification overhead of the traditional asynchronous consensus algorithm from O(n 3 ) to the asymptotically optimal O(n 2 ), the throughput of the system is improved. The asynchronous consensus algorithm adopts a block producer-initiated triggering model, removes the asynchronous binary consensus phase in the traditional asynchronous consensus algorithm, and reduces the transaction determination delay of the system. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 is the overall structure diagram of the asynchronous consensus algorithm of the present application;

[0020] Figure 2 is the overall flow pseudocode of the asynchronous consensus algorithm of the present application;

[0021] Figure 3 is the transaction broadcast phase pseudocode of the asynchronous consensus algorithm of the present application;

[0022] Figure 4 is the vector broadcast phase pseudocode of the asynchronous consensus algorithm of the present application;

[0023] Figure 5 is the block producer drawing and decision phase pseudocode of the asynchronous consensus algorithm of the present application; DETAILED DESCRIPTION

[0024] An efficient asynchronous consensus algorithm suitable for public chains and consortium chains, the asynchronous consensus algorithm model is: the number of nodes in the system is n = 3f + 1, and the network communication between nodes is composed of point-to-point and reliable channels. Attackers can delay messages of any channel, but messages sent by honest nodes will eventually reach other nodes through the channel. The asynchronous consensus algorithm adopts a (f+1, n) threshold signature strategy, and implements threshold signature using the BLS signature algorithm, and the number of Byzantine fault-tolerant nodes is at most f. The asynchronous consensus algorithm adopts a threshold coin flipping scheme and generates a block producer, and all nodes construct a total signature by broadcasting partial signatures, and the algorithm uses the sha256 algorithm to perform hash operation on the total signature to maintain the randomness of the block producer.

[0025] As shown in Figure 1 , the execution flow of the asynchronous consensus algorithm includes three stages of transaction broadcast, vector broadcast, and block producer drawing and decision. The three stages include the following steps:

[0026] S1: As shown in Figure 2 , each node obtains a transaction request from the nearest client, and broadcasts the transaction request asynchronously. The node adopts a heterogeneous transaction execution mode, and broadcasts the transaction to the nearest execution node. If the node adopts a homogeneous transaction execution mode, the consensus time will be increased and the consensus efficiency will be reduced.

[0027] S2: As shown in Figure 3As shown, each node can initiate transaction requests asynchronously, fully unleashing the system's concurrent execution capabilities. After receiving transaction requests broadcast from other execution nodes, each execution node heterogeneously verifies and executes the transactions. For each transaction request initiated by a proposer, the node votes for the proposer, who then collects the votes and broadcasts the results. By having the proposer collect votes, votes are avoided from being broadcast between nodes, reducing the verification overhead of threshold signatures.

[0028] S3: Each executing node first broadcasts the order of transactions it has executed to all other nodes. Each node then broadcasts the transaction execution order to all other nodes via a vector. The transaction order vector is distributed to all nodes by containing the voting results of the transaction, rather than the specific transaction content. Broadcasting the voting results of transactions can prevent Byzantine attacks and duplicate transaction broadcasts.

[0029] S4: As Figure 4 As shown in the figure, after receiving the transaction sequence vector broadcast by other nodes, the node will verify the legitimacy of the voting results of all transactions in the vector. During the verification, the node only verifies the voting results that have not been verified. If all transactions are legal transactions, the node will generate a partial signature and return the partial signature to the proposer. The partial signature of the proposer avoids broadcasting the partial signature between nodes and reduces the verification cost of the threshold signature. Moreover, the verification cost of the threshold signature is reduced from O(n 3 ) is reduced to the asymptotically optimal O(n 2 ), which improves the system throughput.

[0030] S5: If Figure 5 As shown, a lottery strategy is used to randomly select a block producer from all execution nodes to prevent a monopoly on block producers. All nodes participate in the lottery phase, and each node broadcasts a partial signature. When a node receives enough partial signatures, it calculates the total signature based on the partial signatures. The calculated total signature is hashed to ensure randomness. Even if the block producer is a Byzantine node, the system can still correctly identify the block producer and re-draw lots to ensure system security and liveness.

[0031] S6: After the block producer completes the lottery phase, an active trigger model is adopted to remove the asynchronous binary consensus phase in the traditional asynchronous consensus algorithm, reducing the system's transaction confirmation delay. The block producer broadcasts the voting results obtained in the vector broadcast phase. Other nodes will evaluate and determine whether the block producer has honest nodes based on the voting results. Each execution node can determine whether the block producer has honest nodes based on the transaction order broadcast by the block producer in S3 to prevent the block producer from doing evil. Figure 2If the block proposer is honest, all nodes submit the same block according to the order of transactions executed by the block proposer. Otherwise, the block proposer is reselected.

[0032] The specific embodiments of the present application are as follows: first, each node obtains transaction requests from the nearest client and broadcasts the transaction requests asynchronously. When each node receives the transaction requests from the proposer, the execution and verification of the transactions are performed concurrently. If all the transactions are legal, the node generates a partial signature and returns the partial signature to the proposer.

[0033] Second, each node broadcasts the execution order of the transactions to all other nodes through a vector, and directly broadcasts the voting results of the transactions during the broadcasting. After receiving the transaction order vector broadcast by other nodes, the node verifies the legality of the voting results of all the transactions, and the node only needs to verify the voting results that have not been verified before.

[0034] Finally, all nodes participate in the lottery phase, each node broadcasts a partial signature, and when receiving more partial signatures, the total signature is calculated according to the partial signatures. Then, the block proposer is randomly obtained by hashing calculation and taking the remainder. Then, the block proposer broadcasts its voting results obtained in the vector broadcasting phase, and other nodes judge whether they have the right to record according to the voting results. If the block proposer has the right to record, the block is constructed according to the order of transactions executed by the block proposer. Otherwise, the block proposer is reselected.

Claims

1. An efficient asynchronous consensus method applicable to public and consortium chains, characterized by: The following steps are involved: S1: The client broadcasts the transaction to the nearest execution node based on the proximity principle; S2: Each execution node broadcasts the transaction requests it receives from different clients. After receiving the transactions broadcast from other execution nodes, each execution node concurrently executes and verifies the transactions. S3: Each execution node broadcasts the order of executed transactions to all nodes. After receiving the transaction sequence vector broadcast by other nodes, the node verifies the legitimacy of the voting results of all transactions in the vector. During verification, the node only verifies the voting results that have not been verified. If all transactions are legal, the node generates a partial signature and returns the partial signature to the proposer. S4: A lottery strategy is used to select a block producer from all execution nodes. After the block producer is selected, the block producer broadcasts its transaction sequence again to convince other execution nodes to build blocks in the same order, eliminating the asynchronous binary consensus stage in traditional asynchronous consensus algorithms. S5: All execution nodes evaluate whether the block producer has the right to record accounts. If the block producer has the right to record accounts, all nodes construct blocks according to the transaction order executed by the block producer; otherwise, the lottery stage of S4 is repeated.

2. The efficient asynchronous consensus method applicable to public and consortium chains according to claim 1, characterized in that: Each execution node in S2 initiates block requests asynchronously; the nodes adopt a heterogeneous transaction execution mode.

3. The efficient asynchronous consensus method applicable to public and consortium chains according to claim 1 is characterized in that : Each execution node in S3 first broadcasts the transaction sequence vector it executes to all nodes.

4. The efficient asynchronous consensus method applicable to public and consortium chains according to claim 1, characterized in that: All nodes in S5 eventually submit isomorphic blocks.

5. The efficient asynchronous consensus method applicable to public and consortium chains according to claim 1, characterized in that: Each execution node in S5 determines whether the block producer has the right to record accounts based on the transaction order broadcast in S3.

Images