Efficient double-link block chain consensus method and device, equipment and storage medium

Abstract

The invention discloses an efficient double-link block chain consensus method and device, equipment and a storage medium, and belongs to the field of information security. The method comprises an initialization stage, an input stage, a coding stage, a broadcasting stage and a consensus stage. According to the invention, the parallel design of a coding broadcast link and a consensus confirmation link is adopted, so that the occurrence frequency of transaction congestion is reduced; the integrity required by the asynchronous Byzantine consensus process is realized through three-step broadcasting, the updating problem of the post-quantum component does not need to be considered, and the security is higher; an asynchronous network and a Byzantine opponent model are adopted, so that malicious node attacks which do not exceed the total number of nodes can be tolerated on the premise of not setting a network time delay upper limit; in the encoding stage, the generation of the redundancy share through the RS erasure code can be realized by adopting preprocessing, the data redundancy expansion multiple in the broadcasting stage is far smaller than that of the same type of protocol, and the original transaction can be recovered by collecting part of effective shares in the consensus stage, so that the system time delay is effectively reduced, and the system throughput is improved.

Description

Technical Field

[0001] This invention belongs to the field of information security, and specifically relates to an efficient dual-link blockchain consensus method, device, equipment, and storage medium. Background Technology A blockchain is a distributed ledger maintained by multiple mutually distrustful nodes, primarily relying on consensus protocols to ensure that all nodes on the network agree on the validity of transactions and the order of block generation. Currently, public blockchain protocols pursuing high network scalability generally use Proof-of-Work or Proof-of-Stake and their variants to build the consensus layer. In contrast, the consortium blockchain scenario focused on in this invention prioritizes forkless, high-speed transmission and commonly employs various Byzantine fault-tolerant protocols to implement the consensus mechanism. Based on differences in their network timing assumptions, existing Byzantine fault-tolerant consensus can be divided into three models: synchronous, semi-synchronous, and asynchronous. Among them, asynchronous Byzantine consensus, due to its complete independence from time assumptions, exhibits the strongest robustness and performs exceptionally well against malicious nodes and network uncertainties, and is considered a key cornerstone of next-generation highly fault-tolerant distributed systems.

[0002] The HoneyBadger protocol is the first practical asynchronous Byzantine consensus protocol. It achieves consensus by parallelizing asynchronous reliable broadcast instances and asynchronous binary protocol instances. The total communication complexity of the protocol is O(n log n). .in The length of the batch transaction, For safety parameters, The high communication complexity makes the HoneyBadger protocol difficult to balance throughput and latency, and also difficult to apply to large-scale distributed systems. Currently, the most successful modification of the asynchronous Byzantine consensus protocol is the Dumbo-NG protocol, which adopts a dual-link design. This protocol divides the bandwidth-sensitive message propagation part (broadcast phase) and the relatively fixed-latency consensus achievement part (consensus phase) into different links that run concurrently, and uses threshold signature technology to simplify the response backhaul of network nodes. This not only reduces the communication complexity of the protocol, but also avoids the resource waste caused by the inability to utilize bandwidth during the consensus achievement period in single-link protocols.

[0003] However, despite the efforts of scholars in recent years to reduce the latency of such blockchain consensus and improve its security, existing research solutions, including Dumbo-NG, still face two problems in practical applications.

[0004] The first issue is network tidal flow. Transaction broadcast requests in blockchain consensus exhibit significant temporal imbalance, with sudden traffic spikes during peak business periods such as financial clearing and sparse requests during off-peak periods. This dynamic load can render the system's static resource allocation ineffective, leading to slow consensus phase operations. The root cause lies in the distributed network's inability to unify the order in which nodes schedule messages. Consequently, too many instances are blocked for extended periods, waiting for other instances to complete their business logic, hindering the theoretical effectiveness of efficient message propagation chains in protocols like Dumbo-NG.

[0005] The second issue is quantum security. Dumbo-NG-like protocols using threshold signatures generally employ traditional assumptions based on discrete logarithms, which are incompatible with the next-generation international standards for quantum-resistant network security. Currently, quantum-resistant threshold signatures are still in the early stages of research internationally. Existing solutions are insufficient to meet the practical needs of blockchain networks in terms of node scalability, and their security lacks long-term application verification and practical support. Therefore, directly deploying existing asynchronous Byzantine protocols as blockchain consensus carries the risk of component updates being difficult and incompatible with new standards. Summary of the Invention

[0006] To address the aforementioned issues, the main objectives of this invention are: first, to reduce the impact of network tidal problems on blockchain consensus throughput and reduce the response latency of blockchain consensus; second, to replace threshold signatures with a variant of the asynchronous reliable broadcast protocol, thereby fundamentally solving the problem that existing protocol threshold signature components are difficult to update and cannot meet quantum security requirements.

[0007] To achieve the above-mentioned technology, this invention proposes an efficient dual-link blockchain consensus method, apparatus, device, and storage medium, the technical solution of which is shown below.

[0008] The entities involved in this invention are nodes: all nodes collectively constitute the participants in the consensus system, responsible for broadcasting their own proposal values, driving the consensus protocol, and outputting a globally consistent transaction sequence. Each node is connected to others via physical or logical peer-to-peer channels, with a fault tolerance ratio of [missing information]. It supports purely asynchronous network communication with no upper limit on message latency.

[0009] The framework of this invention includes: 1) an encoded broadcast link: responsible for the fragmentation encoding, broadcasting, and verification of transactions, employing... The erase code divides the transaction into multiple shares and distributes them to network nodes; 2) Consensus confirmation link: Global consensus is achieved through the Multi-Valued Validated Asynchronous Byzantine Agreement (MVBA), synchronizing the delivery progress of each node and restoring the complete transaction. The two links run in parallel, realizing the pipelined processing of transactions, which can lock the output sequence faster than traditional solutions, while effectively alleviating the problem of uneven bandwidth utilization in the blockchain network.

[0010] An efficient dual-link blockchain consensus method is proposed, achieving efficient dual-link blockchain consensus through five stages: initialization, input, encoding, broadcasting, and consensus. The initialization, input, and encoding stages do not involve message transmission; the broadcasting stage operates on the encoding-broadcasting link; and the consensus stage operates on the consensus confirmation link. The specific steps of the scheme are as follows: S1. Initialization Phase: The initialization phase completes the initialization of variables and data structures required for consensus, and defines the predicate conditions for consensus validity verification. The steps are as follows: S1.1 Variable initialization, i.e., initializing the core parameters of the participating nodes, including: local proposal counter. Consensus Round Counter Message sending status indicator ; S1.2 Data structure initialization, including: building a transaction buffer pool to store transactions to be processed, building a message channel to store messages to be broadcast, storing vector commitments, storing shares, a counter to record the number of messages received, a delivery status array (marking whether a transaction has been delivered, storing the restored shares, storing the final transaction), and a delivery progress array (recording local progress and global progress). The method for constructing a transaction buffer pool to store pending transactions is as follows: Node The transaction buffer pool is initialized, as shown below. (Empty set), the buffer pool is used to store transactions to be processed, and is implemented using a byte string first-in-first-out queue structure; The method for constructing a message channel to store messages to be broadcast is as follows: Node The message channel initialization is represented as (Empty set) The message channel is used to store RS-encoded messages to be broadcast, and is implemented using a tuple vector first-in-first-out queue structure; The vector commitment storage method is as follows: the vector commitment storage array is initialized, represented as... (Initialization), initially empty, implemented using a two-dimensional array of byte strings; The method of share storage is as follows: the share storage array is initialized, indicating... (Initialization), initially empty, implemented using a two-dimensional array of tuples; The counter records the number of messages received in the following ways: Echo message counter (Empty set), initially empty, implemented using a two-dimensional array of mappings; Ready message counter (Empty set), initially empty, implemented using a two-dimensional array of mappings; The delivery status array can be initialized in the following ways: Transaction delivery status array (Boolean type not completed), implemented using a two-dimensional array of Boolean type; Transaction recovery share array (Initialize to empty values), initially empty, implemented using a two-dimensional array of tuple vectors; Final transaction storage array (Initialize to empty value), initially empty, implemented using a two-dimensional array of byte strings; The delivery schedule array is initialized as follows: Local delivery progress array Initially, it is a zero vector; Global consensus progress array Initialized as a zero vector, the local delivery progress array and the global consensus progress array are implemented using integer arrays; S1.3 Definition and checking of predicate constraints; The steps for defining and checking predicate constraints include: S1.3.1 Define the predicate constraints required for the consensus phase. The input vector that records the local delivery progress of each node. The delivery progress of each node was recorded; S1.3.2, Settings The inspection conditions include: Vector length verification : The vector length is equal to the total number of nodes in the system. ; Progress verification There exists at least Different nodes ,satisfy ,Right now A sufficient number of nodes in the process have local delivery schedules that are ahead of the global schedule. This represents the maximum number of malicious nodes the system can tolerate. Transaction delivery status verification For all nodes and progress within the scope ,Right now , ; S1.3.3, Let the comprehensive verification result ,return In other words, if all three conditions are met, the return value is... .

[0011] S2. Input Phase: The input phase is responsible for processing the external transaction inputs received by the node, and after completing the legality verification, temporarily storing them in the buffer pool as input for the encoding phase. The steps are as follows: External transaction input processing: When node Received external transaction push request At that time, check Does it conform to the preset transaction format specifications? (Call) Transactions that will soon conform to the preset transaction format specifications Store it in the local buffer pool and trigger the encoding phase.

[0012] S3. Encoding Phase: The encoding phase fragments and encodes the transactions in the buffer pool, generating proposal messages containing verification information. This provides a securely propagable share of transaction data for the subsequent broadcast phase. The steps are as follows: S3.1 Transaction extraction and sharding; The node retrieves the transaction data to be processed from the local transaction buffer pool, segments it, and converts it into vector form, ensuring that the fragments can be used as encoding input, including: S3.1.1, Retrieve transactions from the buffer pool, if If not empty, a transaction will pop up. , represented as: in, This indicates an operation to pop an element from a stack or queue; S3.1.2, Perform transaction sharding, and Divided into Each segment is of equal length and converted into a vector form; S3.2, Erasure code encoding generates shares; The RS erasure code encoding algorithm is used to process the segmented transaction fragments, generating transaction shares equal to the total number of system nodes. These shares have fault-tolerant recovery characteristics; even if some shares are lost or tampered with, they can still be retrieved from any number of nodes. The complete original transaction data was recovered from the effective shares of each entity; The method for generating shares through erasure code encoding is as follows: the vector form of the fragmented transactions is generated using RS encoding. Individual shares , represented as: S3.3, Verification information generation; The verification information is generated in the following way: node The fragmented transactions generate verification information, namely the vector commitment of the transactions. and for each node Generate open information , represented as: ; ; S3.4, Proposal message construction; The methods for constructing proposal messages include: S3.4.1 Construct proposal messages for each node. Generate proposal message and summarize all To the Proposal Message Collection , represented as: in, Indicates the identification node The One proposal; Represents a node For nodes The generated share of transaction data; S3.4.2, will Store in message channel ,Right now and update the counter. .

[0013] S4. Broadcast Phase: The broadcast phase implements the broadcasting and interactive verification of the proposal message. Multiple rounds of message confirmation ensure the legality of the transaction shares. The steps are as follows: S4.1, Original message broadcast; The original message broadcast method is: node exist The following steps are executed in a loop: S4.1.1, Retrieve messages from the message channel, if If not empty, pop up And disable message sending status indicator , represented as: S4.1.2, To each node send The corresponding proposal message ; S4.2 Message Reception and Processing, including: S4.2.1 Processing Proposals information; When node Received from node Upon receiving the proposal message, ,in, Represents a node The local proposal count number, Represents a node For nodes The generated transaction data share (generated via RS encoding). Indicates a transaction vector commitment. This represents the open proof of a vector commitment; the validity of the transaction shares is verified using a validation algorithm, if the vector commitment... Verification successful, that is Then store commitments and shares, i.e. , and broadcast confirmation information ; S4.2.2 Confirmation Message processing; Specifically, when the node receive At that time, if The parameter is initialized to 1 on the first reception, and incremented otherwise. ;like ,in, This represents the floor function, i.e., receiving a value greater than the floor function. Take the integer number of identical values ​​upwards. Message, and has not been sent. The message is broadcast. ; S4.2.3, Ready message processing; When node receive At that time, if The initial value is 1 upon first reception, otherwise it is incremented. ; like , that is, received The same And nodes Not sent yet The message is broadcast. ; like That is, if the number of confirmations meets the fault tolerance requirement, then update. ,as well as ,at this time: If the source of the message is a node It itself has Then reset the message sending status flag. This allows the S4.1 original message broadcaster to continue broadcasting the next message; If the corresponding component of the local delivery progress array The counter for this message All transactions between them have been included in the transaction delivery status array. If recorded in the middle, then Set as ; S5. Consensus Phase: This phase achieves global consensus through the MVBA protocol, synchronizes the delivery progress of each node, and recovers the complete transaction from the share based on RS decoding, ensuring that all nodes output a consistent sequence. The steps are as follows: S5.1 Consensus Triggering and Execution; node Perform the following operations in a loop: S5.1.1, If ​​it exists Different nodes Its local delivery progress array and global consensus progress array The corresponding components on satisfy If a sufficient number of nodes have local progress ahead, then the MVBA protocol is initiated and the call is made. And wait for the result. ;in, Indicating consensus rounds MVBA output results; This indicates a predicate for verifying the legitimacy of the consensus. S5.1.2, For each node Collect the shares corresponding to this consensus transaction: in, Indicates the set of recovery messages; Represents a share storage array; S5.1.3, Update the global delivery schedule, i.e. ,node Broadcast resumed and update the consensus round. ;in, This indicates a message broadcast during the consensus phase, containing a set of transaction shares awaiting recovery; S5.2, Resume message processing and output; Resuming message processing and output includes the following steps: S5.2.1, Processing Message: When node receive When this happens, first wait for the corresponding MVBA protocol to return a result. In and If the output does not match, ignore it. Once delivery is complete, i.e., all items in the queue are confirmed. tuples in satisfy ;in, This represents a set of key-value pairs, recording the transaction shares that need to be recovered. S5.2.2 After confirmation, for those in Each component in If the final transaction storage array is still empty, that is... And the vector commitment verification passed, that is Then the shares will be stored in the transaction recovery share array. ; S5.2.3, Decode and recover transactions using the OEC online decoding algorithm with RS erasure codes: If sufficient shares are available, i.e. Then call Perform RS decoding. If at least one exists Individual shares In polynomials If the above is true, it is considered that the decoding and recovery are correct; among them, Represents the decoding polynomial. This represents the polynomial interpolation point corresponding to the share. The specific data value representing the share; S5.2.4 Extracting Polynomials The coefficients are concatenated into a byte string as the transaction. ,make ;when When neither is empty, press The order of outputting the globally consistent transaction sequence, where, Indicates from polynomial The complete transaction data is obtained by splicing together the coefficients.

[0014] An efficient dual-link blockchain consensus device includes: an initialization module, an input module, an encoding module, a broadcast module, and a consensus module; The initialization module is used to execute the steps of the S1 initialization phase. The input module is used to execute the steps of the S2 input phase. The encoding module is used to execute the steps and flow of the S3 encoding stage; The broadcast module is used to execute the steps of the S4 broadcast phase. The consensus module is used to execute the steps and procedures of the S5 consensus phase.

[0015] A high-efficiency dual-link blockchain consensus device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement methods for an initialization phase, an input phase, an encoding phase, a broadcast phase, and a consensus phase.

[0016] A high-efficiency dual-link blockchain consensus storage medium is provided, which is deployed on a memory and stores a computer program. The computer program implements methods for the initialization phase, input phase, encoding phase, broadcast phase, and consensus phase.

[0017] Beneficial effects of the present invention This invention reduces the impact of network surges. It employs a parallel design of an "encoded broadcast link" and a "consensus confirmation link," utilizing transaction fragmentation and vector commitment to pre-lock consensus outputs when network load is low, accelerating the response capability of the encoded broadcast link to instantaneous request peaks, and evenly distributing bandwidth in the consensus confirmation link to restore the original transaction, thus reducing the frequency of transaction blocking. This invention meets the requirements of quantum security. Instead of using threshold signatures, it achieves the holistic nature required for an asynchronous Byzantine consensus process through a three-step broadcast, eliminating the need to consider the update issues of post-quantum components. This results in weaker security assumptions and stronger security. This invention exhibits strong fault tolerance. Employing asynchronous networks and a Byzantine adversary model, the system can tolerate a maximum number of nodes without setting a network latency cap. Even if some nodes send incorrect shares or fail to respond maliciously, honest nodes can still recover the complete transaction with a sufficient number of valid shares, and the consensus result can meet the requirements of orderliness, consistency and liveness. This invention features high throughput and low network latency. In the encoding phase, redundant shares are generated through RS erasure codes, which can be achieved through preprocessing. In the broadcast phase, the data redundancy expansion factor is much smaller than that of similar protocols. In the consensus phase, collecting a portion of the valid shares is sufficient to restore the original transaction, effectively reducing system latency and increasing system throughput. Attached Figure Description

[0018] Figure 1 This is a schematic diagram illustrating the stages of the present invention; Figure 2 This is a network structure diagram of the present invention. Detailed Implementation

[0019] The following section, with reference to the accompanying drawings, details a high-efficiency dual-link blockchain consensus method, apparatus, device, and storage medium. It is assumed that the number of nodes in the consensus network is... ( ,in (The maximum number of malicious nodes the system can tolerate), each node is an integer. Unique identifier, among which Each node can invoke the RS erasure code encoding algorithm. Decoding algorithm In these operations, each node communicates asynchronously via a point-to-point channel. Unless otherwise specified, the following implementation methods all operate on a single node. The operation on it.

[0020] The variables involved in this application and the meaning of each variable are shown in Table 1: Table 1: Variables and the meaning of each variable The execution logic and key steps of this application are shown in Table 2; Table 2: Logic and Key Steps like Figure 1 and Figure 2 As shown, an efficient dual-link blockchain consensus method includes the following steps: S1. Initialization Phase: The initialization phase completes the initialization of variables and data structures required for consensus, and defines the predicate conditions for consensus validity verification. The steps are as follows: S1.1 Variable initialization, i.e., initializing the core parameters of the participating nodes, including: local proposal counter. Consensus Round Counter Message sending status indicator ; S1.2 Data structure initialization, including: building a transaction buffer pool to store transactions to be processed, building a message channel to store messages to be broadcast, storing vector commitments, storing shares, a counter to record the number of messages received, a delivery status array (marking whether a transaction has been delivered, storing the restored shares, storing the final transaction), and a delivery progress array (recording local progress and global progress). The method for constructing a transaction buffer pool to store pending transactions is as follows: Node The transaction buffer pool is initialized, as shown below. (Empty set), the buffer pool is used to store transactions to be processed, and is implemented using a byte string first-in-first-out queue structure; The method for constructing a message channel to store messages to be broadcast is as follows: Node The message channel initialization is represented as (Empty set) The message channel is used to store RS-encoded messages to be broadcast, and is implemented using a tuple vector first-in-first-out queue structure; The vector commitment storage method is as follows: the vector commitment storage array is initialized, represented as... (Initialize to empty value), initially empty, implemented using a two-dimensional array of byte strings; The method of share storage is as follows: the share storage array is initialized, indicating... (Initialize to empty value), initially empty, implemented using a two-dimensional array of tuples; The counter records the number of messages received in the following ways: Echo message counter (Empty set), initially empty, implemented using a two-dimensional array of mappings; Ready message counter (Empty set), initially empty, implemented using a two-dimensional array of mappings; The delivery status array can be initialized in the following ways: Transaction delivery status array (Boolean type is complete), implemented using a two-dimensional array of Boolean type; Transaction recovery share array (Initialize to empty values), initially empty, implemented using a two-dimensional array of tuple vectors; Final transaction storage array (Initialize to empty value), initially empty, implemented using a two-dimensional array of byte strings; The delivery schedule array is initialized as follows: Local delivery progress array Initially, it is a zero vector; Global consensus progress array Initialized as a zero vector, the local delivery progress array and the global consensus progress array are implemented using integer arrays; S1.3, Definition and Checking of Predicate Constraints: The purpose of defining predicate constraints is to ensure that input values ​​submitted by other nodes to the Multi-Valued Validated Asynchronous Byzantine Agreement (MVBA) also meet the local node's validity requirements for inputs, preventing adversaries from forging inputs and compromising the termination capability of the protocol. On the consensus confirmation link, only inputs that satisfy the predicate constraints are considered valid inputs and can continue to propagate and become candidate outputs randomly selected by the MVBA protocol. The steps for defining and checking predicate constraints include: S1.3.1 Define the predicate constraints required for the consensus phase. The input vector that records the local delivery progress of each node. The delivery progress of each node was recorded; S1.3.2, Settings The inspection conditions include: Vector length verification : The vector length is equal to the total number of nodes in the system. ; Progress verification There exists at least Different nodes ,satisfy ,Right now A sufficient number of nodes in the process have local delivery schedules that are ahead of the global schedule. This represents the maximum number of malicious nodes the system can tolerate. Transaction delivery status verification For all nodes and progress within the scope ,Right now , ; S1.3.3, Let the comprehensive verification result ,return Obviously, if all three conditions are met, the return value is... .

[0021] S2. Input Phase: The input phase is responsible for processing the external transaction inputs received by the node, and after completing the legality verification, temporarily storing them in the buffer pool as input for the encoding phase. The steps are as follows: External transaction input processing: When node Received external transaction push request At that time, check Does it conform to the preset transaction format specifications? (Call) Transactions that will soon conform to the preset transaction format specifications Store it in the local buffer pool and trigger the encoding phase.

[0022] S3. Encoding Phase: The encoding phase fragments and encodes the transactions in the buffer pool, generating proposal messages containing verification information. This provides a securely propagable share of transaction data for the subsequent broadcast phase. The steps are as follows: S3.1 Transaction extraction and sharding; The node retrieves the transaction data to be processed from the local transaction buffer pool, segments it, and converts it into vector form, ensuring that the fragments can be used as encoding input, including: S3.1.1, Retrieve transactions from the buffer pool, if If not empty, a transaction will pop up. , represented as: in, This indicates an operation to pop an element from a stack or queue; S3.1.2, Perform transaction sharding, and Divided into Each segment is of equal length and converted into a vector form; S3.2, Erasure code encoding generates shares; The RS erasure code encoding algorithm is used to process the segmented transaction fragments, generating transaction shares equal to the total number of system nodes. These shares have fault-tolerant recovery characteristics; even if some shares are lost or tampered with, they can still be retrieved from any... The complete original transaction data is recovered from the effective shares of each, and is represented as follows: The method for generating shares through erasure code encoding is as follows: the vector form of the fragmented transactions is generated using RS encoding. Individual shares ; S3.3, Verification information generation; To ensure the legitimacy of the transaction shares, the nodes generate vector commitments for the original transaction data and generate corresponding open proofs for each node in the network, which are used by the receiving nodes to verify the consistency between the acquired shares and the original transaction. The verification information is generated in the following way: node The fragmented transactions generate verification information, namely the vector commitment of the transactions. and for each node Generate open information , represented as: ; ; S3.4, Proposal message construction; Each node generates a proposal message for each node in the network. Each message includes the message type, the sending node identifier and proposal sequence number, the target node identifier, the corresponding transaction share, the vector commitment and the open proof. Then, the node aggregates all proposal messages for different target nodes into a message set, stores it in the local message channel to wait for broadcast, and updates the local proposal counter to prepare for processing the next transaction. The methods for constructing proposal messages include: S3.4.1 Construct proposal messages for each node. Generate proposal message and summarize all To the Proposal Message Collection , represented as: in, Indicates the identification node The One proposal; Represents a node For nodes The generated share of transaction data; S3.4.2, will Store in message channel ,Right now and update the counter. .

[0023] S4. Broadcast Phase: The broadcast phase implements the broadcasting and interactive verification of the proposal message. Multiple rounds of message confirmation ensure the legality of the transaction shares. The steps are as follows: S4.1, Original message broadcast; When a node is in the allowed sending state, it retrieves the set of proposal messages to be broadcast from the local message channel, turns off the sending switch to avoid duplicate sending, and sends the corresponding proposal message, including transaction share, vector commitment and proof information, to each node in the network through a reliable transmission protocol. The original message broadcast method is: node exist The following steps are executed in a loop: S4.1.1, Retrieve messages from the message channel, if If not empty, pop up And disable message sending status indicator , represented as: S4.1.2, To each node send The corresponding proposal message ; S4.2 Message Reception and Processing, including: S4.2.1 Processing Proposals information; Processing proposals The message delivery method is as follows: after receiving a proposal message from other nodes, a node verifies the legality of the transaction share using a verification algorithm; if the verification passes, the node stores the share and its vector commitment, and broadcasts a confirmation message to notify other nodes that the legal share has been received. Specifically, when the node Received from node Upon receiving the proposal message, ,in, Represents a node The local proposal count number, Represents a node For nodes The generated transaction data share (generated via RS encoding). Indicates a transaction vector commitment. This represents the open proof of a vector commitment; the validity of the transaction shares is verified using a validation algorithm, if the vector commitment... Verification successful, that is Then store commitments and shares, i.e. , and broadcast confirmation information ; S4.2.2 Confirmation Message processing; confirm The message processing method is as follows: the node maintains an Echo message counter to record the number of confirmation messages received for the same transaction. When the number of confirmation messages reaches the threshold set by the system and the node has not yet sent a ready message, it broadcasts a ready message to further confirm the legality of the transaction. Specifically, when the node receive At that time, if The parameter is initialized to 1 on the first reception, and incremented otherwise. ;like ,in, This represents the floor function, i.e., receiving a value greater than the floor function. Take the integer number of identical values ​​upwards. Message, and has not been sent. The message is broadcast. ; S4.2.3, Ready message processing; The Ready message processing method is as follows: Nodes maintain a Ready message counter to record the number of ready messages. When the count reaches the threshold set by the system, ready messages are broadcast in relay to accelerate consensus. When the count reaches the final threshold, the node marks the transaction as delivered and updates the local transaction processing progress. Specifically, when the node receive At that time, if The initial value is 1 upon first reception, otherwise it is incremented. ; like , that is, received The same And nodes Not sent yet The message is broadcast. ; like That is, if the number of confirmations meets the fault tolerance requirement, then update. ,as well as ,at this time: If the source of the message is a node It itself has Then reset the message sending status flag. This allows the S4.1 original message broadcaster to continue broadcasting the next message; If the corresponding component of the local delivery progress array The counter for this message All transactions between them have been included in the transaction delivery status array. If recorded in the middle, then Set as .

[0024] S5. Consensus Phase: This phase achieves global consensus through the MVBA protocol, synchronizes the delivery progress of each node, and recovers the complete transaction from the share based on RS decoding, ensuring that all nodes output a consistent sequence. The steps are as follows: S5.1 Consensus Triggering and Execution: When the value of a node's local delivery progress array exceeds the current global consensus progress array in most components, the node will start an MVBA protocol instance. The instance takes the local progress information of each node as input and processes it through the set predicate constraints. After the protocol is executed, the node constructs a message containing the transaction shares to be restored based on the output results and broadcasts it to the entire network. At the same time, it updates the global consensus progress array and the current consensus round. Specifically, nodes Perform the following operations in a loop: S5.1.1, If ​​it exists Different nodes Its local delivery progress array and global consensus progress array The corresponding components on satisfy If a sufficient number of nodes have local progress ahead, then the MVBA protocol is initiated and the call is made. And wait for the result. ;in, Indicating consensus rounds MVBA output results; This indicates a predicate for verifying the legitimacy of the consensus. S5.1.2, For each node Collect the shares corresponding to this consensus transaction: in, Indicates the set of recovery messages; Represents a share storage array; S5.1.3, Update the global delivery schedule, i.e. ,node Broadcast resumed and update the consensus round. ;in, This indicates a message broadcast during the consensus phase, containing a set of transaction shares awaiting recovery; S5.2 Recovery Message Processing and Output: After receiving a recovery message from other nodes, the node first verifies the consistency between the message content and the MVBA output result to ensure that the transaction to be recovered has been locally delivered and confirmed. For valid transaction shares, the node stores them in a temporary storage area. When the number of valid shares of the same transaction reaches the fault tolerance threshold set by the system, the node recovers the original polynomial from these shares through the RS decoding algorithm and verifies that a sufficient number of shares are located on the polynomial to ensure the accuracy of the recovery. Finally, the node extracts the polynomial coefficients as complete transaction data and sorts them according to the MVBA output result to form a globally consistent transaction sequence, which is output as the unified proposal value for this round of consensus. Resuming message processing and output includes the following steps: S5.2.1, Processing Message: When node receive When this happens, first wait for the corresponding MVBA protocol to return a result. In and If the output does not match, ignore it. Once delivery is complete, i.e., all items in the queue are confirmed. tuples in satisfy ;in, This represents a set of key-value pairs, recording the transaction shares that need to be recovered. S5.2.2 After confirmation, for those in Each component in If the final transaction storage array is still empty, that is... And the vector commitment verification passed, that is Then the shares will be stored in the transaction recovery share array. ; S5.2.3, Use the OEC online decoding algorithm to decode and recover transactions: If you have sufficient shares, i.e. Then call Perform RS decoding. If at least one exists Individual shares In polynomials If the above is true, it is considered that the decoding and recovery are correct; among them, Represents the decoding polynomial. This represents the polynomial interpolation point corresponding to the share. The specific data value representing the share; S5.2.4 Extracting Polynomials The coefficients are concatenated into a byte string as the transaction. ,make ;when When neither is empty, press The order of outputting the globally consistent transaction sequence, where, Indicates from polynomial The complete transaction data is obtained by splicing together the coefficients.

[0025] An efficient dual-link blockchain consensus device includes: an initialization module, an input module, an encoding module, a broadcast module, and a consensus module; The initialization module is used to execute the steps of the S1 initialization phase. The input module is used to execute the steps of the S2 input phase. The encoding module is used to execute the steps and flow of the S3 encoding stage; The broadcast module is used to execute the steps of the S4 broadcast phase. The consensus module is used to execute the steps and procedures of the S5 consensus phase.

[0026] A high-efficiency dual-link blockchain consensus device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement methods for an initialization phase, an input phase, an encoding phase, a broadcast phase, and a consensus phase.

[0027] A high-efficiency dual-link blockchain consensus storage medium is provided, which is deployed on a memory and stores a computer program. The computer program implements methods for the initialization phase, input phase, encoding phase, broadcast phase, and consensus phase.

[0028] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A high-efficient double-link blockchain consensus method, characterized in that, The method comprises the following stages: S1, initialization stage: the initialization stage completes the initialization of variables and data structures required for consensus, and defines the predicate condition of consensus legality verification; S2, input stage: the input stage is responsible for processing the external transaction input received by the node, and temporarily stores it in the buffer pool after completing the legality verification as the input of the encoding stage; S3, encoding stage: the encoding stage performs sharding processing and encoding on the transactions in the buffer pool to generate proposal messages containing verification information, providing safe propagation transaction data shares for the subsequent broadcast stage; S4, broadcast stage: the broadcast stage realizes the broadcast and interactive verification of the proposal message, and ensures the legality of the transaction share through multiple rounds of message confirmation; S5, consensus stage: this stage reaches global consensus through the asynchronous multi-element verifiable Byzantine agreement (MVBA) protocol, synchronizes the delivery progress of each node, and restores the complete transaction from the share based on RS decoding, ensuring that all nodes output a consistent sequence and completing the construction of the method. 2.The efficient double-link blockchain consensus method of claim 1, wherein, The steps of the initialization stage include: S1.1, variable initialization; The variable initialization is as follows: the participating node initializes core parameters, including: local proposal counter , consensus round counter , message sending state identifier ; S1.2, data structure initialization, including: A transaction buffer pool is constructed to store pending transactions: the node The transaction buffer pool is initialized, denoted as The buffer pool is used to store pending transactions and is implemented in a byte string first-in-first-out queue structure. The message channel stores the messages to be broadcast: node The message channel is initialized, denoted as The message channel is used to store the RS encoded messages to be broadcast, and is implemented by using the first-in first-out queue structure of the tuple vector; wherein, Denotes an empty set; Vector commitment storage: The vector commitment storage array is initialized, denoted as , which is initially empty and implemented as a two-dimensional array of byte strings; Share storage: the share storage array is initialized to represent , which is initially empty and implemented as a two-dimensional array of tuples; wherein represents an initialized null value; The way the counter records the number of message receptions includes: Acknowledgement Echo message counter is initially empty and is implemented as a two-dimensional array of mappings; Ready message counter is initially empty and implemented as a mapped two-dimensional array; The initialization way of the delivery state array includes: Transaction delivery status array is implemented as a two-dimensional array of Boolean type; wherein indicates a Boolean type of complete; The transaction recovery share array is initially empty and is implemented as a two-dimensional array of tuple vectors; Final transaction storage array , initially empty, implemented as a two-dimensional array of byte strings; The initialization way of the delivery progress array is: The local delivery progress array is initially a zero vector; global consensus progress array The local delivery progress array and the global consensus progress array are implemented by integer arrays, initially as zero vectors. S1.3, predicate constraint condition definition and check, including the following steps S1.3.1, predicate constraints required for defining consensus phase where the input vector recording the local delivery progress of each node records the delivery progress of each node; S1.3.2, setting the inspection conditions, including: Vector length check : , the vector length is the total number of nodes in the system ; Progress verification : there are at least different nodes satisfying that local delivery progress of enough nodes is ahead of global, where is the maximum number of malicious nodes that the system can tolerate; Transaction delivery status check : for all nodes and ranges i.e. , ; S1.3.3, let the comprehensive check result , return ; obviously, if all three are satisfied, the return value is . 3.The efficient dual-link blockchain consensus method of claim 1, wherein, The input phase: The input phase is responsible for processing the external transaction inputs received by the node, and after completing the legality verification, temporarily storing them in a buffer pool as input for the encoding phase. The external transaction input is processed as follows: when the node... Received external transaction push request At that time, check Does it conform to the preset transaction format specifications? (Call) Transactions that conform to the preset transaction format specifications Store it in the local buffer pool and trigger the encoding phase. 4.The efficient dual-link blockchain consensus method of claim 1, wherein, The steps of the encoding stage include: S3.1, transaction extraction and sharding; The node extracts the transaction data to be processed from the local transaction buffer pool, divides and converts it into a vector form to ensure that the fragment can be used as an encoding input, including: S3.1.

1. Extract the transaction from the buffer pool, if not empty, pop the transaction is denoted as: wherein, represents a pop element operation from a stack or queue; S3.1.2, transactional sharding, to split into equal-length segments and converted into vector form; S3.2, erasure code encoding to generate shares; The way to encode the shares of the erasure code is to generate the shares by RS encoding the vector-form transaction after sharding ;​ S3.3, verification information generation; The way of generating the verification information is that the node generates the verification information of the fragmented transaction, that is, the vector commitment of the transaction , and generates opening information for each node , which is represented as​ ； ； S3.4, proposal message construction; The way of proposal message construction includes: S3.4.1, Construct proposal messages, one for each node Generate proposal messages , and aggregate all into a set of proposal messages , denoted as: wherein, represents an identification node of a first proposal; represents a node generating a transaction data share for the node ; S3.4.2, to depositing the message in the channel i.e. and updating the counter. 5.The efficient dual-link blockchain consensus method of claim 1, wherein, The steps of the broadcast stage are as follows: S4.1, original message broadcast; The original message is broadcast in the following way: the node In The following steps are executed in a loop: S4.1.1, remove the message from the message channel, if not empty, pop and close the message sending state flag , denoted as: S4.1.2, to each node sending the corresponding proposal message in the ; S4.2, message reception and processing, including: S4.2.1, Processing a Proposal message; Processing proposals The message format is as follows: when the node Received from node Upon receiving the proposal message, ,in, Represents a node The local proposal count number, Represents a node For nodes The generated transaction data share Indicates a transaction vector commitment. This represents the open proof of a vector commitment; the validity of the transaction shares is verified using a validation algorithm, if the vector commitment... Verification successful, that is Then store commitments and shares, i.e. , and broadcast confirmation information ; S4.2.2, Acknowledgement Message processing; confirm The message processing method is as follows: when the node receive At that time, if The parameter is initialized to 1 on the first reception, and incremented otherwise. ;like ,in, This represents the floor function, i.e., receiving a value greater than the floor function. Take the integer number of identical values ​​upwards. Message, and has not been sent. The message is broadcast. ; S4.2.3, Ready message processing; The Ready message is handled as follows: when a node... receive At that time, if The initial value is 1 upon first reception, otherwise it is incremented. ; If , i.e. if , i.e. if , and if the node has not sent the message yet, broadcast ; If i.e. the number of acknowledgements is satisfied for fault tolerance, then update and at this time: If the source of the message is the node itself, i.e. has then the message sending state flag is reset for the S4.1 original message broadcast to continue broadcasting the next message; If the corresponding component of the local delivery progress array to the message's counter has been recorded in the transaction delivery status array , then the is set to .

6. The high-efficient dual-link blockchain consensus method of claim 1, wherein, The steps of the consensus stage include: S5.1, Consensus Trigger and Execution, Node The following operations are performed in a loop: S5.1.

1. If there exists a different node whose corresponding components on the local delivery progress array and the global consensus progress array satisfy , initiate an asynchronous multi-party verifiable Byzantine agreement (MVBA) protocol, call , and wait for the return result ; wherein, denotes the consensus round thMVBA output result; denotes the consensus legality verification predicate; S5.1.2, for each node , collect the share corresponding to the current consensus transaction: wherein, represents a set of recovery messages; represents a shares storage array; S5.1.3, update global delivery progress, i.e. , node broadcasts a recovery message , and updates the consensus round ; wherein, represents the message broadcast in the consensus phase, containing the set of transaction shares to be recovered; S5.2, recovery message processing and output, including the following steps: S5.2.1, Processing Message: When node receive When this happens, first wait for the corresponding MVBA protocol to return a result. In and If the output does not match, ignore it. Once delivery is complete, i.e., all items in the queue are confirmed. tuples in satisfy ;in, This represents a set of key-value pairs, recording the transaction shares that need to be recovered. S5.2.2 After confirmation, for those in Each component in If the final transaction storage array is still empty, that is And the vector commitment verification passed, that is Then the shares will be stored in the transaction recovery share array. ; S5.2.3, decode the recovered transaction using the OEC online decoding algorithm: that is then call to perform RS decoding, ; if there are at least shares on the polynomial , then it is considered that the decoding recovery is correct; wherein, denotes the decoding polynomial, denotes the polynomial interpolation point corresponding to the share, denotes the specific data value of the share; S5.2.4, extracting the coefficients of the polynomial and concatenating as a byte string as a transaction , let ; when are not empty, output the globally unified transaction sequence in the order of , where represents the complete transaction data completed by concatenating the coefficients of the polynomial .

7. A high-efficient dual-link blockchain consensus device, characterized in that, including: an initialization module, an input module, an encoding module, a broadcast module, and a consensus module; The initialization module is used to execute the step process of S1, the initialization stage; The input module is used to execute the step process of S2, the input stage; The encoding module is used to execute the step process of S3, the encoding stage; The broadcast module is used to execute the step process of S4, the broadcast stage; The consensus module is used to execute the step process of S5, the consensus stage.

8. A high-efficient dual-link blockchain consensus device, characterized in that, A storage medium is disposed on the memory, and the computer program is stored on the storage medium, and the computer program is used to implement the method according to any one of claims 1-6.

9. A high-efficient dual-link blockchain consensus storage medium, characterized in that, A storage medium is disposed on the memory, and the computer program is stored on the storage medium, and the computer program is used to implement the method according to any one of claims 1-6.

Images