Byzantine consensus method and device

Abstract

The invention discloses a Byzantine consensus method and device, and relates to the technical field of block chains, and the method comprises the steps: allowing transactions of each replica node and the sequence information of the transactions to be perceived by other replica nodes in advance, and achieving the sorting and submission of all transactions in a consensus round in combination with a weight-recursive transaction sorting algorithm, the block chain consensus method has the advantages that acknowledgement delay is remarkably reduced, consistency and fairness of transaction sequences are improved, transaction verification and communication overhead is reduced by compressing transaction hash and simplifying transaction sorting based on the transaction ID mapping table, the whole consensus process has the advantages of high performance and low communication overhead, and consensus reliability in the block chain is improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and more particularly to a Byzantine consensus method and apparatus. Background Technology

[0002] Traditional blockchain consensus algorithms suffer from the difficulty of effectively preventing malicious nodes from manipulating the transaction order. To address this, solutions have been proposed that weaken the transaction ordering ability of block proposers (i.e., leader nodes)—namely, censorship-resistant protocols—and optimize the consensus mechanism to achieve fairness in transaction ordering. Specifically: In the first solution, censorship-resistant protocols prevent malicious block proposers from ordering only transactions from which they can profit. Some protocols rely on encrypted transactions or reputation to resist unfair censorship; however, attackers can still use client IP attacks to censor specific transactions. Other protocols prevent malicious leader nodes through round-robin elections, periodic changes, or random selection; however, the current leader node can still manipulate transaction ordering undetected. Therefore, in censorship-resistant protocols… The proposed solution lacks a fair ordering model and transaction detection mechanism. In the second solution, transaction ordering fairness requires that the execution and submission order of transactions be the same as the receiving order of most nodes, such as using the median timestamp of transactions from all nodes to achieve fair order under a synchronized clock. However, the Byzantine leader node can now censor specific transactions to prevent their submission and manipulate the timestamps of certain transactions. To address this, a scheme to construct a directed graph to ensure the correctness of transaction ordering has been proposed. However, Byzantine behavior and network latency can easily lead to transaction order cycles in the directed graph, making it impossible to order transactions in a timely manner. Therefore, the delayed ordering mechanism used in these schemes that optimize consensus mechanisms will bring high performance overhead and usually requires transactions to wait for multiple rounds of consensus confirmation, increasing the latency of transaction confirmation.

[0003] In summary, existing blockchain consensus algorithms need to improve their consensus reliability. Summary of the Invention

[0004] This invention provides a Byzantine consensus method and apparatus that improves consensus reliability in blockchain.

[0005] The first aspect of this invention provides a Byzantine consensus method, comprising:

[0006] Once the view change is complete, the replica node sends a New-View message to the leader node. The New-View message includes the OrderQC or PrepareQC of the highest view and a list of local transactions proposed according to a preset number of transactions.

[0007] When the leader node receives at least nf New-View messages, it determines the HighQC, the transaction ID mapping table, and the current transaction ID set based on the verified New-View messages, encapsulates them into a Tx-Sync message, and forwards it to each replica node; where n is the total number of nodes and f' is the number of allowed faulty nodes.

[0008] Any replica node verifies the received Tx-Sync message. If the verification is successful, it determines the local ordering of the transaction based on the transaction ID mapping table and the current transaction ID set, constructs a signature, and combines HighQC with the local ordering of the transaction to construct a Sort-Vote message, which is then sent to the remaining replica nodes and the leader node.

[0009] When the leader node receives at least nf Sort-Vote messages, it aggregates the signatures of the verified Sort-Vote messages to generate OrderQC, combines the local sorting of each transaction to generate OrderingMap, and then packages OrderQC and OrderingMap into Prepare message and broadcasts it to each replica node.

[0010] Any replica node verifies the received Prepare message by combining the received Sort-Vote message. If the verification is successful, it performs a local update according to OrderQC, builds a signature, generates a Prepare-Vote message, and sends it to the leader node.

[0011] Once the leader node receives at least nf Prepare-Vote messages, the leader node and the replica nodes will perform interactive signature verification until the replica nodes construct the signature and generate the corresponding Commit-Vote message and send it to the leader node.

[0012] When the leader node receives at least nf Commit-Vote messages, it merges the signatures in the verified Commit-Vote messages to generate a CommitQC and then updates it locally. If there is no consensus linear transaction order in the Commit-Vote messages, it performs weight-recursive transaction sorting based on the local sorting of each transaction and outputs the consensus linear transaction order. The CommitQC and the consensus linear transaction order are then constructed into a Decide message and broadcast to each replica node.

[0013] Each replica node verifies the received Decide message, and if the verification is successful, it submits the block in the consensus linear transaction order.

[0014] Optionally, determining the local order of transactions based on the transaction ID mapping table and the current transaction ID set includes:

[0015] Check whether all local transactions in the current transaction ID set exist in the transaction ID mapping table.

[0016] If both exist, the local transaction list will be sorted locally as the transaction list.

[0017] If any transaction in the local transaction list does not exist in the current transaction ID set, it is determined to be a missing transaction and a missing transaction message is sent to the remaining replica nodes;

[0018] When fewer than f+1 missing transaction messages are received, the local transaction list is adjusted based on the missing transactions to determine the local order of transactions;

[0019] When at least f+1 missing transaction messages are received, a view replacement is triggered.

[0020] Optionally, after verifying the received Prepare message in conjunction with the received Sort-Vote message, any replica node includes:

[0021] If any transaction that exists in at least nf transactions in the local ordering does not exist in the OrderingMap, then a view change is triggered.

[0022] Optionally, the step of performing weighted-recursive transaction sorting based on the local sorting of each transaction to output a consensus linear transaction order includes:

[0023] The weights of each transaction are assigned based on its position in the local sorting of each transaction, and the weight value of each transaction is determined and the total weight value of each transaction is calculated accordingly.

[0024] Sort each transaction in ascending order according to its total weight, and sort transactions with the same total weight in ascending order according to their binary transaction IDs in the transaction ID mapping table to determine the order of intermediate linear transactions.

[0025] The intermediate linear transaction sequence is divided into a front sequence and a back sequence based on the median transaction at the middle position. The target front sequence and target back sequence are determined by merging and sorting based on the total weight and binary transaction ID in the front sequence and back sequence respectively. The target front sequence, median transaction and target back sequence are combined to form the consensus linear transaction sequence.

[0026] Optionally, it also includes:

[0027] Once the view is changed, each replica node calculates the transaction ratio based on the number of node transactions in the previous view and the total number of block transactions, and sends it to the leader node.

[0028] The leader node selects the highest transaction ratio from the multiple received transaction ratios and notifies the corresponding replica nodes to increase the number of transactions to update the preset number of transactions.

[0029] Optionally, the calculation process of the weight values ​​includes:

[0030] ;

[0031] In the formula, For weight values, For weighted fairness parameters, For transaction position parameters.

[0032] A second aspect of the present invention provides a Byzantine consensus device, comprising:

[0033] The view replacement module is used to send a New-View message to the leader node after the view replacement is completed. The New-View message includes the OrderQC or PrepareQC of the highest view and a list of local transactions proposed according to a preset number of transactions.

[0034] The leader node proposal module is used when the leader node receives at least nf New-View messages. Based on the verified New-View messages, the leader node determines the HighQC, the transaction ID mapping table, and the current transaction ID set, encapsulates them into a Tx-Sync message, and forwards it to each replica node. Here, n is the total number of nodes, and f' is the number of allowed faulty nodes.

[0035] The replica node proposal module is used by any replica node to verify the received Tx-Sync message. If the verification is successful, the local ordering of the transaction is determined according to the transaction ID mapping table and the current transaction ID set. A signature is constructed and combined with HighQC and the local ordering of the transaction to form a Sort-Vote message, which is then sent to the other replica nodes and the leader node.

[0036] The leader node preparation module is used to generate OrderQC by aggregating and verifying the signatures of the Sort-Vote messages after the leader node receives at least nf Sort-Vote messages, and then combining the local sorting of each transaction to generate OrderingMap. Finally, the OrderQC and OrderingMap are packaged into a Prepare message and broadcast to each replica node.

[0037] The replica node preparation module is used by any replica node to verify the received Prepare message by combining the received Sort-Vote message. If the verification is successful, it performs local updates according to OrderQC, builds a signature, generates a Prepare-Vote message, and sends it to the leader node.

[0038] The node commit module is used to enable the leader node and replica nodes to perform interactive signature verification after the leader node receives at least nf Prepare-Vote messages, until the replica nodes construct the signature and generate the corresponding Commit-Vote message and send it to the leader node.

[0039] The leader node decision module is used to merge the signatures in the verified Commit-Vote messages when the leader node receives at least nf Commit-Vote messages, generate a CommitQC, and then update it locally. If there is no consensus linear transaction order in the Commit-Vote messages, the leader node performs weight-recursive transaction sorting based on the local sorting of each transaction and outputs the consensus linear transaction order. The CommitQC and the consensus linear transaction order are constructed into a Decide message and broadcast to each replica node.

[0040] The replica node decision module is used by any replica node to verify the received Decide message. If the verification is successful, the block is submitted in the consensus linear transaction order.

[0041] A computer device provided in a third aspect of the present invention includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the Byzantine consensus method as described in any of the preceding claims.

[0042] The fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements the Byzantine consensus method as described in any of the preceding claims.

[0043] The fifth aspect of the present invention provides a computer program product comprising a computer program / instructions that, when executed by a processor, implement the Byzantine consensus method as described in any of the preceding claims.

[0044] As can be seen from the above technical solutions, the present invention has the following advantages:

[0045] The above-described scheme of the present invention provides a Byzantine consensus method, comprising: after a view change is completed, a replica node sends a New-View message to the leader node, wherein the New-View message includes the OrderQC or PrepareQC of the highest view and a list of local transactions proposed according to a preset number of transactions; when the leader node receives at least nf New-View messages, the leader node determines the HighQC, the transaction ID mapping table, and the current transaction ID set based on the verified New-View messages, encapsulates them into a Tx-Sync message, and forwards it to each replica node; wherein n is the total number of nodes, and f' is the number of allowed faulty nodes; any replica node verifies the received Tx-Sync message, and if the verification is successful, it determines the local transaction ordering based on the transaction ID mapping table and the current transaction ID set, constructs a signature, and combines the HighQC and the local transaction ordering to construct a Sort-Vote message, which is then sent to the remaining replica nodes and the leader node; when the leader node receives at least nf Sort-Vote messages, the leader node aggregates the signatures of the verified Sort-Vote messages to generate an OrderQC, and combines the local transaction orderings to generate an OrderingMap, and then assigns the OrderQC to the leader node. C and OrderingMap are packaged into a Prepare message and broadcast to each replica node. Each replica node verifies the received Prepare message by combining it with the received Sort-Vote message. If the verification is successful, it updates locally according to OrderQC, builds a signature, and generates a Prepare-Vote message to send to the leader node. When the leader node receives at least nf Prepare-Vote messages, it interacts with the replica nodes to verify the signatures until the replica nodes build a signature and generate a corresponding Commit-Vote message to send to the leader node. When the leader node receives at least nf Commit-Vote messages, it merges the signatures in the verified Commit-Vote messages to generate a CommitQC and updates locally. If there is no consensus linear transaction order in the Commit-Vote message, it performs a weighted-recursive transaction sorting based on the local sorting of each transaction to output the consensus linear transaction order. The CommitQC and the consensus linear transaction order are constructed into a Decide message and broadcast to each replica node. Each replica node verifies the received Decide message. If the verification is successful, it submits the block according to the consensus linear transaction order.Based on the above scheme, the New-View message enables other replica nodes to perceive the transaction and order information of each replica node in advance, and the weight-recursive transaction sorting algorithm completes the sorting and submission of all transactions within one consensus round, which significantly reduces confirmation latency and improves the consistency and fairness of transaction order. Based on the transaction ID mapping table, transaction verification and communication overhead are reduced by compressing transaction hashes and simplifying transaction sorting. Therefore, the entire consensus process has the advantages of high performance and low communication overhead, which improves the consensus reliability in the blockchain. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 A flowchart illustrating the steps of a Byzantine consensus method provided in an embodiment of the present invention;

[0048] Figure 2 A schematic diagram of the consensus phase provided in an embodiment of the present invention;

[0049] Figure 3 A pseudocode diagram illustrating the general message assistance tool provided in the embodiments of the present invention;

[0050] Figure 4 A pseudocode diagram illustrating the multi-functional view switching mechanism provided in an embodiment of the present invention;

[0051] Figure 5 A pseudocode diagram illustrating the sequential proposal stage and preparation stage provided in an embodiment of the present invention;

[0052] Figure 6 Pseudocode diagrams illustrating the pre-submission stage, submission stage, and decision stage provided in embodiments of the present invention;

[0053] Figure 7 An example diagram of weight-recursive transaction sorting provided in an embodiment of the present invention;

[0054] Figure 8 This is a structural block diagram of a Byzantine consensus device provided in an embodiment of the present invention. Detailed Implementation

[0055] This invention provides a Byzantine consensus method and apparatus to address the technical problem of how to improve the reliability of consensus in blockchain.

[0056] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0057] Terminology Explanation:

[0058] Blockchain: A shared database containing data or information that is "unforgeable", "fully traceable", "transparent", and "collectively maintained".

[0059] Account: A ledger in the blockchain that stores related states; transaction: A record of account operations performed in the blockchain.

[0060] Block creation: In a blockchain, a new block is generated periodically to update the account states within the blockchain. The process of generating a new block is called block creation. A block contains multiple transactions.

[0061] Consensus Protocol / Mechanism / Algorithm: A mechanism in a distributed system used to reach consensus among multiple nodes. In blockchain, the main purpose of a consensus protocol is to ensure that all nodes agree on the order and content of block additions, thereby guaranteeing the immutability and transparency of data.

[0062] Transaction order fairness: In a blockchain system, it is ensured that transactions are processed in an order that conforms to some fair rule, typically based on the time order in which transactions arrive at the network. This fairness aims to prevent malicious nodes (such as validators) from manipulating the transaction order to gain undue advantage or influence the system's behavior.

[0063] Please see Figure 1 , Figure 1 A flowchart illustrating the steps of a Byzantine consensus method provided in an embodiment of the present invention.

[0064] This embodiment provides a Byzantine consensus method applied to a blockchain system. The blockchain system includes multiple nodes, which perform tasks such as maintaining the ledger, verifying transactions, and participating in consensus. Among the nodes participating in consensus, they can be divided into leader nodes and replica nodes based on their responsibilities. Figure 2As shown, the Byzantine consensus method in this embodiment proposes a multi-functional view replacement (VVC) mechanism and a consistent order consensus (CSC) framework, involving the view replacement phase, order proposal phase, preparation phase, pre-commit phase, commit phase, and decision phase. The multi-functional view replacement (VVC) mechanism enables the consensus to start normally and allows replica nodes to propose transactions and their order information in advance. The consistent order consensus (CSC) framework ensures that the fair order of all transactions and global transactions is consistent among all replica nodes through mutual verification and cooperation among replica nodes. Therefore, overall, on the one hand, the Byzantine consensus method allows multiple nodes to propose transactions and their order, increasing the number of block transactions that can be proposed in a single consensus and the number of transactions with a fair order that can be determined, greatly improving the throughput of a single consensus. On the other hand, when the consensus is successfully executed, the Byzantine consensus method can ensure that the order of all transactions is fairly determined within a consensus round, thereby ensuring consistency and liveness, without the need for additional consensus round information or update delays to supplement the ordering messages, reducing the consensus latency of transaction confirmation and commit. In specific implementation, the method includes:

[0065] Step 101: After the view is changed, the replica node sends a New-View message to the leader node. The New-View message includes the OrderQC or PrepareQC of the highest view and a list of local transactions proposed according to the preset number of transactions.

[0066] It should be noted that, as Figure 4 As shown, in the view-change phase, a view change is triggered when each round of view starts or when the leader node fails, and a new leader node is randomly elected to start the view. This embodiment proposes a multi-functional view change (VVC) mechanism. This mechanism inherits the characteristics and methods of the existing view change mechanism and expands the view change function by integrating functions to clarify the intention of the secondary node for the transaction and its ordering.

[0067] In practice, once the view has been changed, all replica nodes are responsible for submitting a New-View message, such as... Figure 4As shown, the New-View message can be constructed using the MSG function, including the view number (ViewNumber), the local transaction list (txs), and some quorum certificates (QC, qc) conforming to the threshold signature scheme. In this embodiment, the QC in the New-View message can be set to the highest OrderQC or PrepareQC in its own state tree as described in the CSC framework, which can be understood as the OrderQC or PrepareQC of the highest view. The local transaction list is a list of transactions with a specified preset number of transactions constructed by the replica node based on its own local transaction pool. At this time, the local transaction list can be determined by the transaction timestamp to determine the transaction order. The local transaction pool is used to temporarily store transactions that have not yet been confirmed and added to the blockchain. The preset number of transactions specifies the number of transactions that should be included when building a local transaction list each time. The local transaction list of each replica node can be the same as or different from that of other replica nodes. In this embodiment, the information of the replica node on the local transactions and their specific order is added to the New-View message, so that the transaction and order information of each replica node can be perceived by other replica nodes in the network in advance, thereby allowing replica nodes to propose transactions and their order in advance. This new view replacement mechanism can effectively adopt a pipeline structure to confirm multiple batches of transactions in parallel in a fair order. However, the existing representative ordering fairness mechanism is either incompatible with the consensus pipeline or cannot effectively utilize the pipeline, because if there is not enough transaction and ordering information, they may be blocked for a long time at a certain stage.

[0068] Understandably, in situations like Figure 3 As shown, the MSG function is used to construct a consensus message. It accepts input parameters including message type (type), node information (node), and quorum certificate (qc). It sets the message type attribute (m.type) of message m to the input type, sets the view number attribute (m.ViewNumber) of message m to the current view number (curView), sets the node information attribute (m.node) of message m to the input node, and sets the quorum certificate attribute (m.justify) of message m to the input qc, thereby returning the constructed consensus message m.

[0069] Step 102: When the leader node receives at least nf New-View messages, the leader node determines the HighQC, the transaction ID mapping table, and the current transaction ID set based on the verified New-View messages, encapsulates them into a Tx-Sync message, and forwards it to each replica node; where n is the total number of nodes and f' is the number of allowed faulty nodes.

[0070] It should be noted that, as Figure 5As shown, during the Order-Propose Phase, when the leader node receives no less than nf New-View messages, where n is the total number of nodes and f' is the allowed number of failed nodes, ... Figure 2 For example, with n = 5 and f = 1, the leader node verifies the New-View message. This verification may include using the CHECKMSG function to check the message type and view number. For instance, if the message type and view number are not the expected New-View and the current view number, the New-View message is considered invalid. From the verified New-View message, the highest QC among the received OrderQC or PrepareQC is calculated according to a preset rule and called HighQC. It is understood that this preset rule is set with reference to existing technologies (such as view number, node weight, etc.). For example, the OrderQC or PrepareQC with the largest view number is taken as HighQC. If there are multiple OrderQCs or PrepareQCs with the same largest view number, HighQC is determined according to the corresponding largest node weight. It is understood that when the view number is 1, the replica node QC is empty and is ⊥. For this part of the signature, viewNumber = 1. After the leader node receives no less than nf of these empty QCs, viewNumber is set to 1, and HighQC is constructed. For details, please refer to existing technologies.

[0071] Because the continuous consensus phase requires processing a large number of transactions from replica nodes, increasing communication overhead, this embodiment designs a dynamic transaction compression mechanism to effectively compress transactions in each round of consensus, thereby reducing consensus communication overhead and simplifying the transaction verification process: First, the leader node constructs a transaction ID mapping table that maps unique dynamic transaction hash values ​​to binary transaction IDs based on the received transactions that need to reach consensus. Second, this table is forwarded to all nodes, enabling them to easily verify the existence of transactions and convert between transaction hash values ​​and IDs. The construction of this mapping table involves compressing each 256-bit transaction hash value into an incremental binary ID of only a few bits in size. This method greatly simplifies and compresses local sorting, especially in the case of a large number of nodes and transactions, thereby significantly reducing communication overhead. Finally, when the leader node constructs the final block and nodes perform tasks such as cleaning up the transaction pool, they can use the dynamic mapping table to perform transaction mapping, ensuring that the recovery process is convenient and lossless.

[0072] Therefore, after the leader node verifies the local transaction list received from the replica nodes, it constructs the corresponding transaction ID mapping table and uses binary transaction IDs to combine the transactions in the local transaction list into a transaction set represented by curTxs, i.e., the current transaction ID set. curTxs can select transactions proposed by no less than nf replica nodes, which also demonstrates a certain degree of transaction selection flexibility. Finally, HighQC, the transaction ID mapping table, and the current transaction ID set are further encapsulated into a Tx-Sync message through the MSG function and forwarded to each replica node.

[0073] Understandably, in practice, a new leaf node (curProposal) can also be created using the CREATELEAF procedure with HighQC.node and curTxs; for example... Figure 3 As shown, the CREATELEAF procedure is used to progressively build the state tree, assigning the parent node information (parent) and transaction information (tx) to the b.pparent and b.tx properties of the new leaf node b, respectively, and finally returning the constructed leaf node b. In the example... Figure 3 As shown, the CHECKMSG function is used to check the message type and correctness. Based on the message type attribute m.type and the view number attribute m.ViewNumber of message m in the received input parameters, it checks whether they are both equal to the expected message type and the expected view number, and returns the judgment result.

[0074] Step 103: Any replica node verifies the received Tx-Sync message. If the verification is successful, it determines the local ordering of the transaction based on the transaction ID mapping table and the current transaction ID set, constructs a signature, and combines HighQC with the local ordering of the transaction to construct a Sort-Vote message, which is then sent to the remaining replica nodes and the leader node.

[0075] In one specific implementation of this embodiment, determining the local order of transactions based on the transaction ID mapping table and the current transaction ID set includes:

[0076] Check whether the local transaction list exists in the current transaction ID set based on the transaction ID mapping table;

[0077] If both exist, the local transaction list will be sorted locally as the transaction list.

[0078] If any transaction in the local transaction list does not exist in the current transaction ID set, it is determined to be a missing transaction and a missing transaction message is sent to the remaining replica nodes;

[0079] When fewer than f+1 missing transaction messages are received, the local transaction list is adjusted based on the missing transactions to determine the local order of transactions;

[0080] When at least f+1 missing transaction messages are received, a view replacement is triggered.

[0081] It should be noted that, as Figure 5 As shown, during the Order-Propose Phase, replica nodes verify the received Tx-Sync messages to determine their validity. This verification may include using the CHECKMSG function to check the message type and view number, as well as node security checks. For example, if the message type or view number is not the expected Tx-Sync or the current view number, or if the security node check fails, the Tx-Sync message is considered invalid. Specific details of the node security check can be found in existing technologies. For verified Tx-Sync messages, the local transaction order is determined based on the transaction ID mapping table and the current transaction ID set. During this process, a step of checking for missing transactions is performed, i.e., the replica node uses the dynamic transaction hash value of each transaction tx in the local transaction list to map the transaction IDs. The system searches the mapping table to determine if all transactions (tx) exist in the current transaction ID set. If no transactions are missing, the local transaction list is used as the local ordering. If a transaction is missing, it is identified. If more than f+1 nodes report that a transaction is not in the current transaction ID set, it indicates that the leader node has acted maliciously, triggering a view change. Otherwise, the system adjusts the local transaction list based on the missing transactions to establish its own local ordering. For example, the current replica node deletes the missing transaction from its local transaction list before determining the local ordering. Then, the VOTEMSG function is used for signature voting, and HighQC and the local ordering are combined to construct Sort-Vote information, which is sent to the leader node and the remaining replica nodes.

[0082] It is understandable that, such as Figure 5 As shown, node security checks can include confirming that the node in the confirmation message is an extension of m.justify.node and has passed the SAFENODE secure node check, such as... Figure 3 As shown, the SAFENODE function is used to determine whether a node is an extension of LockedQC.node, and whether the view number qc.ViewNumber of the certificate qc is greater than LockedQC.ViewNumber. For details, please refer to existing technologies for further understanding. Missing transactions can be viewed using the CHECKTX function. The CHECKTX function determines whether the number of times the transaction tx to be checked does not appear in the current transaction ID set curTxs exceeds f+1, and then returns the result.

[0083] Step 104: When the leader node receives at least nf Sort-Vote messages, the leader node aggregates and verifies the signatures of the Sort-Vote messages to generate OrderQC, and combines the local sorting of each transaction to generate OrderingMap. Then, the leader node packages the OrderQC and OrderingMap into a Prepare message and broadcasts it to each replica node.

[0084] It should be noted that, as Figure 5 As shown, during the Prepare Phase, when the leader node receives no less than nf Sort-Vote messages, it verifies these messages. This verification may include checking the message type and view number using the CHECKMSG function, collecting the signatures from the verified Sort-Vote messages, merging them using the QC function to generate a new signature called OrderQC, and simultaneously merging all LocalOrderings to form an OrderingMap. The transaction order in the OrderingMap is also sorted according to the binary transaction ID to ensure consistency. These transactions, along with the merged signature, are then packaged together with the MSG function to form a Prepare message for broadcast to all replica nodes.

[0085] It is understandable that, such as Figure 3 As shown, the QC function is used to construct the quorum certificate QC. It extracts the message type attribute m.type, view number attribute m.ViewNumber, and node information attribute m.node of message m from the verified valid message set V and assigns them to the corresponding attributes of qc. Then, it combines the relevant attributes and the signature of message m based on the tcombine operation to form a signature, and finally returns the constructed qc.

[0086] Step 105: Any replica node verifies the received Prepare message by combining the received Sort-Vote message. If the verification is successful, it performs a local update according to OrderQC, builds a signature, generates a Prepare-Vote message, and sends it to the leader node.

[0087] In one specific implementation of this embodiment, after any replica node verifies the received Prepare message in conjunction with the received Sort-Vote message, it includes:

[0088] If any transaction that exists in at least nf transactions in the local ordering does not exist in the OrderingMap, then a view change is triggered.

[0089] It should be noted that, as Figure 5 As shown, during the Prepare Phase, replica nodes verify the received Prepare messages to determine their validity. This verification can include checking the message type and view number using the CHECKMSG function, node security checks, and OrderingMap missing transaction checks. Specifically, the OrderingMap missing transaction check determines whether all transactions in the local ordering of each transaction exist in the OrderingMap based on the received Sort-Vote message. If all transactions exist in the OrderingMap, or if any transaction tx0 that does not exist in the OrderingMap exists in fewer than nf local orderings, the verification is successful. If nf or more local orderings contain transaction tx0, but the OrderingMap does not contain this transaction, it indicates an error in the leader node, and the verification fails, triggering a view replacement. If the verification passes, the local OrderQC is updated accordingly, and the Prepare message is signed using the VOTEMSG function to construct the Prepare-Vote message. Message signing is performed during the construction of the voting message.

[0090] It is understandable that, such as Figure 3 As shown, the VOTEMSG function is used to construct voting messages. It is a further operation based on the MSG function, including: first calling the MSG function to construct message m, and then using tsign... r The function performs a message signature on the m.type, m.ViewNumber, and m.node properties of message m to obtain m.partialSig, and then returns the signed voting message m.

[0091] Step 106: After the leader node receives at least nf Prepare-Vote messages, the leader node and the replica nodes perform interactive signature verification until the replica nodes construct the signature and generate the corresponding Commit-Vote message and send it to the leader node.

[0092] Step 106 includes the following sub-steps:

[0093] When the leader node receives at least nf Prepare-Vote messages, it extracts the signature from the verified Prepare-Vote message, generates PrepareQC, performs local updates, packages it into a Precommit message, and broadcasts it to all replica nodes.

[0094] Any replica node verifies the received Precommit message. If the verification is successful, it performs a local update according to PrepareQC, builds a signature, generates a Precommit-Vote message, and sends it to the leader node.

[0095] When the leader node receives at least nf Precommit-Vote messages, it extracts the signatures from the verified Precommit-Vote messages, aggregates them to generate a PrecommitQC, updates it locally, constructs it into a Commit message, and broadcasts it to each replica node.

[0096] Any replica node verifies the received Commit message. If the verification is successful, it updates the PrecommitQC to LockedQC, builds a signature, generates a Commit-Vote message, and sends it to the leader node.

[0097] It should be noted that, as Figure 6 As shown, in the PreCommit Phase: When the leader node receives at least nf Prepare-Vote messages, it verifies the Prepare-Vote messages. This verification may include calling the CHECKMSG function to check the message type and view number, collecting the signatures from the verified Prepare-Vote messages and merging them into a PrepareQC using the QC function, storing it locally, and broadcasting the PrepareQC as part of the Precommit message to the replica nodes based on the MSG function. The replica nodes verify the received Precommit messages. This verification includes checking the message type and view number of the QC using the CHECKQC function. That is, if the message type (qc.type) and view number (qc.ViewNumber) of the PrepareQC are not the expected message type Precommit and the current view number, the Precommit message is considered invalid. If the verification passes, the replica nodes update locally using the PrepareQC, construct a voting message based on the Precommit message using the VOTEMSG function to obtain the Precommit-Vote message, and reply to the leader node. The message signature is performed in the constructed voting message.

[0098] like Figure 6As shown, in the Commit Phase: When the leader node receives no less than nf Precommit-Vote messages, it verifies the Precommit-Vote messages. This verification may include checking the message type and view number using the CHECKMSG function, collecting the signatures from the verified Precommit-Vote messages and merging them into a PrecommitQC using the QC function for local updating, and constructing a Commit message based on the PrecommitQC using the MSG function and broadcasting it to each replica node. After receiving the Commit message, the replica node verifies the PrecommitQC in the received Commit message. This verification includes checking the message type and view number of the QC using the CHECKQC function. If the verification is successful, it updates the LockedQC to PrecommitQC, and constructs a voting message based on the Commit message by calling the VOTEMSG function to obtain a Commit-Vote message to reply to the leader node. The message signature is performed in the constructed voting message.

[0099] It is understandable that, such as Figure 3 As shown, the CHECKQC function is used to verify the type and correctness of the quorum certificate (QC). It returns the judgment result based on whether the message type (qc.type) and view number (qc.ViewNumber) of the input qc are both equal to the expected message type and the expected view number.

[0100] In a more specific implementation of this embodiment, when the leader node receives at least nf Precommit-Vote messages, the leader node extracts the signature aggregation from the verified Precommit-Vote messages to generate a PrecommitQC, performs local updates, performs weighted recursive transaction sorting based on the local order of each transaction to output the consensus linear transaction order, constructs a Commit message based on the PrecommitQC and the consensus linear transaction order, and broadcasts it to each replica node.

[0101] It should be noted that during the commit phase, the system will remain locked. In order to speed up the consensus confirmation process, the leader node can use a weighted recursive transaction ordering fairness strategy (deterministic fair ordering component) to pre-calculate the transaction order, which is called the consensus linear transaction order. In this way, the block can be quickly committed after receiving enough commit-vote messages and decree messages during the decision phase.

[0102] More specifically, a consensus linear transaction order is output based on the weighted recursive transaction sorting according to the local sorting of each transaction, including:

[0103] The weights of each transaction are assigned based on its position in the local sorting of each transaction, and the weight value of each transaction is determined and the total weight value of each transaction is calculated accordingly.

[0104] Sort each transaction in ascending order according to its total weight, and sort transactions with the same total weight in ascending order according to their binary transaction IDs in the transaction ID mapping table to determine the order of intermediate linear transactions.

[0105] The intermediate linear transaction sequence is divided into a front sequence and a back sequence based on the median transaction at the middle position. The target front sequence and target back sequence are determined by merging and sorting based on the total weight and binary transaction ID in the front sequence and back sequence respectively. The target front sequence, median transaction and target back sequence are combined to form the consensus linear transaction sequence.

[0106] In a more specific embodiment of this example, the calculation process of the weight value includes:

[0107] ;

[0108] In the formula, For weight values, For weighted fairness parameters, For transaction position parameters.

[0109] It should be noted that this embodiment proposes a two-stage sorting fairness strategy to handle the local transaction order of each replica node. It deterministically performs a fair linear sorting of transactions and verifies the consistency and fairness of the transaction order. By doing so, a block can be built and submitted within a consensus view to fairly determine the order of all transactions. This weight-based sorting strategy abandons traditional graph sorting algorithms and avoids the cycle problem in the sorting graph. This method can generate transaction orders more efficiently, ensuring that the sorting result conforms to the receiving order of the majority of nodes, thereby achieving strict sorting fairness. Figure 7 As shown, an example of a two-stage sorting is given:

[0110] 1) The weighted sorting phase aims to obtain a relatively fair transaction sorting sequence based on the linearization of the total weight value, thereby helping to reduce the number of transaction comparisons in the final sorting phase and further accelerating the process of fair transaction sorting: First, all replica nodes have reached a consensus on the weight allocation method, such as the weight value calculation process, in the aforementioned consensus phase and included it in the local transaction sorting, and determined the weight fairness parameters that reflect the fairness level of the current stage. ( (Can be set to a fixed value of 1 / 2) and a parameter representing the specific position of each transaction in the local transaction ordering on the replica node. The value of the transaction order is determined to synchronize the replica nodes and generate a fair transaction order. Secondly, each transaction in the local transaction order (i.e., the local transaction sorting) is converted into a weight value, and the total weight of each transaction is calculated. This calculation process constructs a specific total weight value for each transaction relative to its position in the local transaction sorting of the replica nodes. Finally, the transactions are sorted in ascending order of their total weight values. If two transactions have the same total weight value, they are further sorted in ascending order of their binary transaction IDs. This process ultimately produces a linearized list of transactions related to their original positions, called the intermediate linear transaction order. Figure 7 As shown in “0-2-1-3-4-5”;

[0111] 2) Final sorting stage: First, select the transaction in the middle position from the intermediate linear transaction sequence, called the median transaction; second, using the median transaction as the boundary, divide the transactions in the intermediate linear transaction sequence before the median transaction into the front sequence and the transactions after the median transaction into the back sequence. Then, perform a merge sorting recursion in the front sequence and the back sequence respectively, until each subsequence in the middle of the recursion contains only one transaction. Similar to the weighted sorting stage, sort and merge based on the total weight value and binary transaction ID to determine the target front sequence and target back sequence. Then merge the target front sequence, median transaction and target back sequence together to finally obtain a deterministic and fair consensus linear transaction sequence.

[0112] Understandably, the process of determining the median transaction includes: if the length of the intermediate linear transaction sequence is odd, then the transaction in the middle position of the intermediate linear transaction sequence is taken as the median transaction; if the length of the intermediate linear transaction sequence is even, then the transaction that appears earlier among the two transactions in the middle position of the intermediate linear transaction sequence is taken as the median transaction. For example... Figure 7 As shown, the length of the intermediate linear transaction sequence is even. Transaction "1" is selected as the median transaction from transaction "1" and transaction "3" which are in the middle position.

[0113] Step 107: When the leader node receives at least nf Commit-Vote messages, the leader node merges the signatures in the verified Commit-Vote messages to generate a CommitQC and then updates it locally. If there is no consensus linear transaction order in the Commit-Vote message, the leader node performs weighted recursive transaction sorting based on the local sorting of each transaction to output the consensus linear transaction order. The leader node then constructs the CommitQC and the consensus linear transaction order into a Decide message and broadcasts it to each replica node.

[0114] It should be noted that, as Figure 6As shown, in the Decide Phase, when the leader node receives no less than nf Commit-Vote messages, it verifies the Commit-Vote messages. This verification may include using the CHECKMSG function to check the message type and view number, merging the signatures in the verified Commit-Vote messages into a QC function and storing it locally as a CommitQC. At the same time, if the consensus linear transaction order has not yet been determined, a weighted recursive transaction sort is performed based on the local sorting of each transaction to output the consensus linear transaction order. Based on the CommitQC and the consensus linear transaction order, a Decide message is constructed using the MSG function and broadcast to all replica nodes. If the consensus linear transaction order exists in the Commit-Vote messages, the CommitQC and the consensus linear transaction order are constructed into a Decide message and broadcast to each replica node.

[0115] Step 108: Any replica node verifies the received Decide message. If the verification is successful, the block is submitted in the consensus linear transaction order.

[0116] It should be noted that, as Figure 6 As shown, in the Decide Phase, the replica node verifies the CommitQC in the received Decide message. This verification includes checking the message type and view number of the QC through the CHECKQC function. If the verification passes, the block is submitted in the consensus linear transaction order in the Decide message, thus completing one round of consensus.

[0117] In one specific embodiment of this example, it further includes:

[0118] Once the view is changed, each replica node calculates the transaction ratio based on the number of node transactions in the previous view and the total number of block transactions, and sends it to the leader node.

[0119] The leader node selects the highest transaction ratio from the multiple received transaction ratios and notifies the corresponding replica nodes to increase the number of transactions to update the preset number of transactions.

[0120] It should be noted that in the above fair consensus design, all replica nodes are responsible for proposing their own transactions and their local ordering, which helps improve order fairness. To increase transaction throughput, this embodiment proposes an adjustable transaction proposal strategy to increase the number of transactions committed in a single consensus. The main idea of ​​this strategy is to leverage the parallelism of consensus, increasing the proportion of different transactions proposed by each replica node in each round without affecting latency, thereby increasing the number of consensus proposal transactions and achieving relatively high transaction throughput. First, in the first round of consensus, the preset number of transactions proposed by each replica node in the View-Change phase can be adaptively set, such as keeping it consistent. Subsequently, in... In the next round, the leader node and replica nodes can determine the replica node with the highest transaction ratio in this round based on the transaction situation in the consensus block of the previous round. Thus, in the View-Change phase of the next round, the replica node with the highest transaction ratio will propose more transactions in the next round. That is, the preset number of transactions for that replica node is randomly increased and updated to obtain a new preset number of transactions. This method increases the number of different transactions in each round, thereby improving the transaction throughput of consensus. In specific implementation, the transaction ratio is the ratio of the number of node transactions to the total number of transactions in the block. The number of node transactions refers to the number of transactions proposed by each replica node, and the total number of transactions in the block refers to the total number of transactions executed in the block.

[0121] In this embodiment of the invention, a novel consensus mechanism is proposed to address the transaction fairness issues caused by transaction manipulation attacks and the consensus transaction submission delay issues caused by delayed ordering mechanisms in current blockchains. This mechanism aims to provide a good balance between blockchain order fairness and high performance. By enabling other replica nodes in the network to perceive the transaction and order information of each replica node in advance through the New-View message, and by using a weight-recursive transaction ordering algorithm to complete the ordering and submission of all transactions within a single consensus round, the mechanism significantly reduces confirmation delay and improves the consistency and fairness of transaction order. The combination of the consensus process and the fair ordering strategy also achieves censorship resistance. Based on transaction ID mapping... The table-based consensus mechanism reduces transaction verification and communication overhead by compressing transaction hashes and simplifying local sorting. Its adjustable transaction proposal strategy allows for more transactions to be submitted within a single consensus round, fully utilizing network bandwidth and increasing throughput. In summary, this consensus mechanism offers the advantages of high performance and low communication overhead, aiming to ensure fair transaction order during blockchain transaction processing, prevent malicious manipulation of transaction order, protect the rights of transaction participants, and improve system transparency, thereby enhancing system security and user trust. Furthermore, its performance degradation is significantly less than existing protocols when the network scales up, demonstrating a clear advantage in scalability. It is suitable for large-scale blockchain systems and exhibits good flexibility and scalability.

[0122] Please see Figure 8, Figure 8 This is a structural block diagram of a Byzantine consensus device provided in an embodiment of the present invention.

[0123] This embodiment provides a Byzantine consensus device, comprising:

[0124] The view replacement module 801 is used to send a New-View message to the leader node after the view replacement is completed. The New-View message includes the OrderQC or PrepareQC of the highest view and a list of local transactions proposed according to a preset number of transactions.

[0125] The leader node proposal module 802 is used to determine the HighQC, the transaction ID mapping table, and the current transaction ID set based on the verified New-View messages when the leader node receives at least nf New-View messages, and encapsulate them into a Tx-Sync message and forward it to each replica node; where n is the total number of nodes and f' is the number of allowed faulty nodes.

[0126] The replica node proposal module 803 is used by any replica node to verify the received Tx-Sync message. If the verification is successful, the local ordering of the transaction is determined according to the transaction ID mapping table and the current transaction ID set. A signature is constructed and combined with HighQC and the local ordering of the transaction to form a Sort-Vote message, which is then sent to the other replica nodes and the leader node.

[0127] The leader node preparation module 804 is used to generate OrderQC by aggregating the signatures of the Sort-Vote messages after the leader node receives at least nf Sort-Vote messages, and after combining the local sorting of each transaction to generate OrderingMap, the leader node packages the OrderQC and OrderingMap into a Prepare message and broadcasts it to each replica node.

[0128] The replica node preparation module 805 is used by any replica node to verify the received Prepare message by combining the received Sort-Vote message. If the verification is successful, it performs local updates according to OrderQC, builds a signature, generates a Prepare-Vote message, and sends it to the leader node.

[0129] The node commit module 806 is used to perform interactive signature verification between the leader node and the replica node after the leader node receives at least nf Prepare-Vote messages, until the replica node constructs the signature and generates the corresponding Commit-Vote message and sends it to the leader node.

[0130] The leader node decision module 807 is used to merge the signatures in the verified Commit-Vote messages when the leader node receives at least nf Commit-Vote messages, generate a CommitQC and update it locally. If there is no consensus linear transaction order in the Commit-Vote messages, the leader node performs weight-recursive transaction sorting according to the local sorting of each transaction and outputs the consensus linear transaction order. The CommitQC and the consensus linear transaction order are constructed into a Decide message and broadcast to each replica node.

[0131] The replica node decision module 808 is used by any replica node to verify the received Decide message. If the verification is successful, the block is submitted in the consensus linear transaction order.

[0132] Furthermore, the local ordering of transactions is determined based on the transaction ID mapping table and the current transaction ID set, including:

[0133] Check whether all local transactions in the current transaction ID set exist in the transaction ID mapping table.

[0134] If both exist, the local transaction list will be sorted locally as the transaction list.

[0135] If any transaction in the local transaction list does not exist in the current transaction ID set, it is determined to be a missing transaction and a missing transaction message is sent to the remaining replica nodes;

[0136] When fewer than f+1 missing transaction messages are received, the local transaction list is adjusted based on the missing transactions to determine the local order of transactions;

[0137] When at least f+1 missing transaction messages are received, a view replacement is triggered.

[0138] Furthermore, after any replica node verifies the received Prepare message in conjunction with the received Sort-Vote message, it includes:

[0139] If any transaction that exists in at least nf transactions in the local ordering does not exist in the OrderingMap, then a view change is triggered.

[0140] Furthermore, based on the local sorting of each transaction, a weighted-recursive transaction sorting is performed to output a consensus linear transaction order, including:

[0141] The weights of each transaction are assigned based on its position in the local sorting of each transaction, and the weight value of each transaction is determined and the total weight value of each transaction is calculated accordingly.

[0142] Sort each transaction in ascending order according to its total weight, and sort transactions with the same total weight in ascending order according to their binary transaction IDs in the transaction ID mapping table to determine the order of intermediate linear transactions.

[0143] The intermediate linear transaction sequence is divided into a front sequence and a back sequence based on the median transaction at the middle position. The target front sequence and target back sequence are determined by merging and sorting based on the total weight and binary transaction ID in the front sequence and back sequence respectively. The target front sequence, median transaction and target back sequence are combined to form the consensus linear transaction sequence.

[0144] Furthermore, it also includes:

[0145] Once the view is changed, each replica node calculates the transaction ratio based on the number of node transactions in the previous view and the total number of block transactions, and sends it to the leader node.

[0146] The leader node selects the highest transaction ratio from the multiple received transaction ratios and notifies the corresponding replica nodes to increase the number of transactions to update the preset number of transactions.

[0147] Furthermore, the calculation process for the weight values ​​includes:

[0148] ;

[0149] In the formula, For weight values, For weighted fairness parameters, For transaction position parameters.

[0150] This invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program; when the computer program is executed by the processor, the processor performs the steps of the Byzantine consensus method as described in any of the above embodiments.

[0151] This invention also provides a computer-readable storage medium storing a computer program / instructions thereon, which, when executed by a processor, implement the steps of the Byzantine consensus method as described in any of the above embodiments.

[0152] This invention also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the Byzantine consensus method as described in any of the above embodiments.

[0153] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0154] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0155] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0156] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0157] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0158] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A Byzantine consensus method, characterized in that, include: Once the view change is complete, the replica node sends a New-View message to the leader node. The New-View message includes the OrderQC or PrepareQC of the highest view and a list of local transactions proposed according to a preset number of transactions. When the leader node receives at least nf New-View messages, it determines the HighQC, the transaction ID mapping table, and the current transaction ID set based on the verified New-View messages, encapsulates them into a Tx-Sync message, and forwards it to each replica node; where n is the total number of nodes and f' is the number of allowed faulty nodes. Any replica node verifies the received Tx-Sync message. If the verification is successful, it determines the local ordering of the transaction based on the transaction ID mapping table and the current transaction ID set, constructs a signature, and combines HighQC with the local ordering of the transaction to construct a Sort-Vote message, which is then sent to the remaining replica nodes and the leader node. When the leader node receives at least nf Sort-Vote messages, it aggregates the signatures of the verified Sort-Vote messages to generate OrderQC, combines the local sorting of each transaction to generate OrderingMap, and then packages OrderQC and OrderingMap into Prepare message and broadcasts it to each replica node. Any replica node verifies the received Prepare message by combining the received Sort-Vote message. If the verification is successful, it performs a local update according to OrderQC, builds a signature, generates a Prepare-Vote message, and sends it to the leader node. Once the leader node receives at least nf Prepare-Vote messages, the leader node and the replica nodes will perform interactive signature verification until the replica nodes construct the signature and generate the corresponding Commit-Vote message and send it to the leader node. When the leader node receives at least nf Commit-Vote messages, it merges the signatures in the verified Commit-Vote messages to generate a CommitQC and then updates it locally. If there is no consensus linear transaction order in the Commit-Vote messages, it performs weight-recursive transaction sorting based on the local sorting of each transaction and outputs the consensus linear transaction order. The CommitQC and the consensus linear transaction order are then constructed into a Decide message and broadcast to each replica node. Each replica node verifies the received Decide message, and if the verification is successful, it submits the block in the consensus linear transaction order.

2. The Byzantine consensus method according to claim 1, characterized in that, The step of determining the local order of transactions based on the transaction ID mapping table and the current transaction ID set includes: Check whether all local transactions in the current transaction ID set exist in the transaction ID mapping table. If both exist, the local transaction list will be sorted locally as the transaction list. If any transaction in the local transaction list does not exist in the current transaction ID set, it is determined to be a missing transaction and a missing transaction message is sent to the remaining replica nodes; When fewer than f+1 missing transaction messages are received, the local transaction list is adjusted based on the missing transactions to determine the local order of transactions; When at least f+1 missing transaction messages are received, a view replacement is triggered.

3. The Byzantine consensus method according to claim 1, characterized in that, After any replica node verifies the received Prepare message in conjunction with the received Sort-Vote message, it includes: If any transaction that exists in at least nf transactions in the local ordering does not exist in the OrderingMap, then a view change is triggered.

4. The Byzantine consensus method according to claim 1, characterized in that, The step of weighting and recursively sorting transactions based on their local ordering to output a consensus linear transaction order includes: The weights of each transaction are assigned based on its position in the local sorting of each transaction, and the weight value of each transaction is determined and the total weight value of each transaction is calculated accordingly. Sort each transaction in ascending order according to its total weight, and sort transactions with the same total weight in ascending order according to their binary transaction IDs in the transaction ID mapping table to determine the order of intermediate linear transactions. The intermediate linear transaction sequence is divided into a front sequence and a back sequence based on the median transaction at the middle position. The target front sequence and target back sequence are determined by merging and sorting based on the total weight and binary transaction ID in the front sequence and back sequence respectively. The target front sequence, median transaction and target back sequence are combined to form the consensus linear transaction sequence.

5. The Byzantine consensus method according to claim 1, characterized in that, Also includes: Once the view is changed, each replica node calculates the transaction ratio based on the number of node transactions in the previous view and the total number of block transactions, and sends it to the leader node. The leader node selects the highest transaction ratio from the multiple received transaction ratios and notifies the corresponding replica nodes to increase the number of transactions to update the preset number of transactions.

6. The Byzantine consensus method according to claim 4, characterized in that, The calculation process for the weight values ​​includes: ； In the formula, For weight values, For weighted fairness parameters, For transaction position parameters.

7. A Byzantine consensus device, characterized in that, include: The view replacement module is used to send a New-View message to the leader node after the view replacement is completed. The New-View message includes the OrderQC or PrepareQC of the highest view and a list of local transactions proposed according to a preset number of transactions. The leader node proposal module is used when the leader node receives at least nf New-View messages. Based on the verified New-View messages, the leader node determines the HighQC, the transaction ID mapping table, and the current transaction ID set, encapsulates them into a Tx-Sync message, and forwards it to each replica node. Here, n is the total number of nodes, and f' is the number of allowed faulty nodes. The replica node proposal module is used by any replica node to verify the received Tx-Sync message. If the verification is successful, the local ordering of the transaction is determined according to the transaction ID mapping table and the current transaction ID set. A signature is constructed and combined with HighQC and the local ordering of the transaction to form a Sort-Vote message, which is then sent to the other replica nodes and the leader node. The leader node preparation module is used to generate OrderQC by aggregating and verifying the signatures of the Sort-Vote messages after the leader node receives at least nf Sort-Vote messages, and then combining the local sorting of each transaction to generate OrderingMap. Finally, the OrderQC and OrderingMap are packaged into a Prepare message and broadcast to each replica node. The replica node preparation module is used by any replica node to verify the received Prepare message by combining the received Sort-Vote message. If the verification is successful, it performs local updates according to OrderQC, builds a signature, generates a Prepare-Vote message, and sends it to the leader node. The node commit module is used to enable the leader node and replica nodes to perform interactive signature verification after the leader node receives at least nf Prepare-Vote messages, until the replica nodes construct the signature and generate the corresponding Commit-Vote message and send it to the leader node. The leader node decision module is used to merge the signatures in the verified Commit-Vote messages when the leader node receives at least nf Commit-Vote messages, generate a CommitQC, and then update it locally. If there is no consensus linear transaction order in the Commit-Vote messages, the leader node performs weight-recursive transaction sorting based on the local sorting of each transaction and outputs the consensus linear transaction order. The CommitQC and the consensus linear transaction order are constructed into a Decide message and broadcast to each replica node. The replica node decision module is used by any replica node to verify the received Decide message. If the verification is successful, the block is submitted in the consensus linear transaction order.

8. A computer device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the Byzantine consensus method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the Byzantine consensus method as described in any one of claims 1-6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the Byzantine consensus method as described in any one of claims 1-6.

Images