Blockchain asynchronous network consensus method and computer device

Abstract

The application relates to the technical field of blockchains, and provides a blockchain asynchronous network consensus method and computer equipment, which comprises the following steps: a proposal initiating node reads to-be-processed transaction data from a transaction pool; the proposal initiating node carries out hash processing on the to-be-processed transaction data based on a verifiable delay function, and forms a verifiable delay hash sequence of the to-be-processed transaction data; the proposal initiating node initiates atomic broadcast of a message carrying the verifiable delay hash sequence to participating nodes for message signature verification; after the message signature verification is completed, each participating node carries out consistency verification consensus on the execution result of the to-be-processed transaction data based on the verifiable delay hash sequence. The method can be used to reduce the dependence on threshold encryption, so that the network complexity is low, the network load is low, and the network is anti-examination, and the transaction original text can be obtained without decryption after the completion of the consensus process.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to a blockchain asynchronous network consensus method and computer device. Background Technology

[0002] Asynchronous networks refer to network environments where no upper limit is set on the communication latency between nodes. This can be understood as the network communication latency between two nodes being arbitrarily long. If a Byzantine node exists, it can arbitrarily extend the communication time. To ensure consensus liveness, consistency, finality, and total order of asynchronous transaction submissions by multiple nodes are achieved in scenarios with unknown latency limits. Existing blockchain asynchronous networks have proposed consensus algorithms such as HoneyBadger and Dumbo.

[0003] However, both HoneyBadger and Dumbo, in order to reduce network transmission load, divide node transactions into transaction subsets during the Reliable Broadcast (RBC) consensus phase, and then distribute each transaction subset to other nodes in the asynchronous distributed system (not broadcasting, but each node transmitting a copy of the transaction subset). Simultaneously, considering the issue of malicious nodes resisting censorship, the proposing node uses threshold encryption to encrypt the transaction subsets, and the encrypted subsets are not decrypted until the asynchronous binary agreement (ABA) consensus phase is completed.

[0004] This results in the need to wait until the consensus process is complete before decryption can be performed to obtain the original transaction text. Furthermore, if the transaction subset contains instructions requiring multiple steps to execute, an additional consensus mechanism is needed to ensure that all nodes agree on the execution results of the instructions. If synchronous consensus is introduced, it disrupts the asynchronous network model in the asynchronous distributed system. If asynchronous consensus is introduced, the choice of which asynchronous consensus to use becomes problematic, as currently no asynchronous consensus mechanism can complete instruction execution during the consensus process, and current asynchronous consensus mechanisms all use BA (Binary Agreement) consensus in the final stage to achieve proposal consensus. Summary of the Invention

[0005] Therefore, it is necessary to provide a blockchain asynchronous network consensus method and computer device that can avoid introducing additional consensus mechanisms and reduce reliance on threshold encryption to address the aforementioned technical problems.

[0006] This invention provides a blockchain asynchronous network consensus method, comprising: The proposal initiating node reads the pending transaction data from the transaction pool; The proposal initiating node performs hash processing on the pending transaction data based on a verifiable delay function to form a verifiable delayed hash sequence of the pending transaction data. The proposal initiating node sends an atomic broadcast message carrying the verifiable delayed hash sequence to the participating nodes for message signature verification; After the message signature verification is completed, each participating node performs a consensus on the consistency of the execution result of the pending transaction data based on the verifiable delayed hash sequence.

[0007] In one embodiment, before the proposal node initiating node reads the transaction data to be processed from the transaction pool, the method further includes: A hash loop is established using the hash value of the unique identifier of the consensus node as the closing node; The transaction data in the transaction pool is grouped according to transaction relevance, and the hash value of the group identifier is assigned to the hash loop as a key. On the hash loop, the node closest to the keyword is found according to a pre-defined direction as the nearest node to the keyword; the pre-defined direction includes either a counter-clockwise or clockwise direction. The transaction data corresponding to the keyword is used as the pending transaction data of the nearest node to obtain the pending transaction data of the proposal initiating node.

[0008] In one embodiment, the method further includes: Consensus eras can be divided based on consensus rounds or consensus time. At the beginning of each consensus era, the hash value of each node on the hash loop is updated based on the verifiable delayed hash sequence of the last pending transaction data of each consensus node in the previous consensus era.

[0009] In one embodiment, the method further includes adding virtual nodes in the hash loop.

[0010] In one embodiment, the proposal initiating node sends an atomic broadcast message carrying the verifiable delayed hash sequence to participating nodes for message signature verification, including: The proposal initiating node generates a broadcast message based on a fragment of the verifiable delayed hash sequence and broadcasts it to the participating nodes; After the participating node passes the signature verification of the broadcast message, it generates a reply message broadcast. After receiving 2f+1 broadcast reply messages, the participating node broadcasts a ready message indicating that it is ready to process the transaction; where f represents the number of Byzantine nodes.

[0011] In one embodiment, the participating nodes perform consensus verification on the consistency of the execution results of the pending transaction data based on the verifiable delayed hash sequence, including: A committee node is selected from the participating nodes. The committee node verifies the transaction data to be processed locally based on the verifiable delayed hash sequence, obtains the transaction verification result, and broadcasts it. If the committee node collects 2f+1 identical transaction verification results, it confirms that the transaction verification results have reached a consensus; where f represents the number of Byzantine nodes. After the transaction verification results are agreed upon, the consensus rounds are converged by randomly flipping a coin, and the consensus results are submitted to each of the participating nodes.

[0012] In one embodiment, the method further includes: Consensus nodes are divided to form a chain, and a leader node is elected from the chain. When any of the consensus nodes in a slave chain reach consensus within the chain, the proposal initiating node synchronously distributes the verifiable delayed hash sequence to the leader node of other slave chains; After the intra-chain consensus of the slave chains is completed, the leader nodes of each slave chain conduct main chain consensus based on the verifiable delayed hash sequence.

[0013] In one embodiment, the method further includes: The proposal initiating node slices the verifiable delayed hash sequence of the transaction data to be processed based on the number of CPU or GPU cores.

[0014] In one embodiment, after the participating nodes reach a consensus on the consistency of the execution results of the pending transaction data based on the verifiable delayed hash sequence, the method further includes: storing the pending transaction data after the consensus on the consistency of the execution results on disk, and the proposal initiating node clearing the pending transaction data from the transaction pool.

[0015] The present invention also provides a computer device, the computer device including a processor and a memory, the memory storing a computer program, the processor executing the computer program to implement the steps of the blockchain asynchronous network consensus method described above.

[0016] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the blockchain asynchronous network consensus method described in any of the preceding claims.

[0017] The aforementioned asynchronous blockchain network consensus method and computer equipment combine transaction propagation, identity verification, transaction execution, and consensus, ensuring that transaction propagation and execution are completed during the asynchronous consensus process without introducing additional consensus mechanisms. Simultaneously, by broadcasting a verifiable delayed hash sequence of the transaction instead of distributing a subset of encrypted transactions, the reliance on threshold encryption is reduced during the asynchronous consensus process. This ensures lower network complexity, lower network load, and censorship resistance, while eliminating the need to wait for decryption after the consensus process is complete to obtain the original transaction text. Furthermore, obtaining a verifiable delayed hash sequence based on VDF ensures ordered transaction verification even when the time-series network is attacked or when consensus nodes are subjected to man-in-the-middle attacks. Moreover, by slicing the verifiable delayed hash sequence of the transaction into segments, parallel verification is performed on consensus nodes using multi-core CPUs and multi-core GPUs, accelerating transaction verification speed and improving the throughput of the asynchronous distributed system. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an asynchronous network consensus method for blockchain in one embodiment. Figure 1 ; Figure 2 This is a schematic diagram of a verifiable delayed hash sequence structure in one embodiment. Figure 1 ; Figure 3 This is a schematic diagram of a verifiable delayed hash sequence structure in one embodiment. Figure 2 ; Figure 4 This is a schematic diagram of the consensus process of ERBC and TVA in one embodiment. Figure 1 ; Figure 5 This is a schematic diagram of transaction partitioning based on a consistent hashing closed loop in one embodiment; Figure 6 This is a flowchart illustrating an asynchronous network consensus method for blockchain in one embodiment. Figure 2 ; Figure 7 This is a flowchart illustrating an asynchronous network consensus method for blockchain in one embodiment. Figure 3 . Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] In one embodiment, such as Figure 1 As shown, an asynchronous network consensus method for blockchain is provided, including steps S101-S104.

[0021] S101, the proposal initiating node reads the pending transaction data from the transaction pool.

[0022] In this context, the proposal initiating node is the consensus node that initiates the consensus request. The transaction pool is a storage center used to store transaction data, which is sent from the client. Pending transaction data refers to transaction data waiting to be processed by the proposal initiating node.

[0023] Specifically, the client broadcasts transaction data to the consensus nodes in the asynchronous blockchain network, and this transaction data is written to the transaction pool. When asynchronous consensus is reached, the proposal initiating node reads the corresponding pending transaction data from the transaction pool.

[0024] S102, the proposal initiating node performs hash processing on the transaction data to be processed based on the verifiable delay function, forming a verifiable delayed hash sequence of the transaction data to be processed.

[0025] To address the problem of transaction data being hijacked by a man-in-the-middle during propagation between consensus nodes, allowing the man-in-the-middle to tamper with the timestamps of transaction data and control the transaction order, thus causing transaction concealment and consensus fraud, this application's embodiments are based on Verifiable Delay Functions (VDFs) for transaction verification. VDF-based transaction verification does not rely on timing sources such as BeiDou or GPS.

[0026] Specifically, the proposal initiating node hashes the transaction data to be processed based on VDF, forming a verifiable delayed hash sequence of the transaction data to be processed. For example... Figure 2 As shown, taking SHA256 as an example, this application provides a schematic diagram of a verifiable delayed hash sequence structure.

[0027] Therefore, a verifiable delayed hash sequence is essentially a computational sequence that, through a cryptographic function (SHA256), allows for the verification of the passage of time between two transactions. Furthermore, because a cryptographically secure function is used, either party must complete the transaction before generating the output; the output cannot be predicted based on the input. For hash functions like SHA256, the output is unknown without passing the transaction through the function. Figure 2 The diagram can be understood as a subset of transactions that a consensus node (i.e., the proposal initiating node in this embodiment) should execute and propose in a certain round of consensus. The consensus node runs a cryptographic function starting from a random value, obtains its output, and uses it as the input for the next function execution.

[0028] Figure 2In this context, "Transaction_n_data" represents the transaction data submitted by the client (e.g., parameters of a smart contract method in the blockchain), "HANDLE" represents the function that processes the transaction data (e.g., a smart contract method in the blockchain), and "+" indicates the concatenation of the output of the cryptographic function processed from the previous transaction data with the output of the current transaction data. Figure 2 After n cryptographic function operations, the final output "hashn" of the transaction subset is obtained.

[0029] Therefore, as long as the chosen hash function, such as SHA256, is collision-resistant, this subset of transactions can only be computed sequentially by a single computer thread. This is because the hash value at sequence number n cannot be obtained without performing n actual calculations from the initial value. Thus, this method allows the inference of the time series from sequence number 1 to sequence number n from a verifiable delayed hash sequence. This process does not rely on a trusted time source; even if a transaction encounters a man-in-the-middle attack during propagation, or if a man-in-the-middle attack occurs between the time source and the consensus node, the order of transactions in the verifiable delayed hash sequence cannot be maliciously altered.

[0030] In some embodiments, the proposal initiating node can slice the verifiable delayed hash sequence of the transaction data to be processed based on the number of CPU or GPU cores.

[0031] Specifically, to improve asynchronous consensus throughput and reduce transaction latency, the verifiable delayed hash sequence in this application embodiment can rely on hardware facilities such as CPU and GPU for parallel execution. For example... Figure 3 As shown, Figure 2 The verifiable delayed hash sequence shown can be verified by multi-core computers to ensure the correctness of their transaction execution, and the verification time is less than the time it takes to generate the sequence. That is, depending on the number of CPU or GPU cores, the consensus node that initiates the proposal (i.e., the proposal initiating node) can... Figure 2 The verifiable delayed hash sequence shown is divided into slices equal to the number of cores of the participating verification nodes. Subsequently, the tail hash values ​​from each slice are sent to the participating consensus nodes (i.e., the participating nodes). Upon receiving the slices, the participating consensus nodes can perform parallel verification, thereby improving asynchronous consensus throughput and reducing transaction activation latency. The expected verification time for the transaction subset proposed by the consensus nodes is as follows:

[0032] in, This represents the number of hashes in a verifiable delayed hash sequence. This represents the number of transactions and cryptographic functions that the kernel can execute per second. This represents the number of cores in a consensus node that can be used to verify a verifiable delayed hash sequence, i.e., the number of CPU or GPU cores.

[0033] S103, the proposal initiating node sends an atomic broadcast to the participating nodes, carrying a verifiable delayed hash sequence for message signature verification.

[0034] In this context, participating nodes are the consensus nodes that participate in verifying the consensus. This can be understood as the target node to which the proposal-initiating node initiates the consensus request. For example, when node A initiates consensus with node B, node A is the proposal-initiating node in this embodiment, and node B is a participating node. Atomic broadcasting refers to all nodes in a network receiving the same set of messages in the same order. Atomic broadcasting must satisfy the following properties: Consistency: If any honest node outputs a transaction tx, then every honest node will output transaction tx.

[0035] Total order: If the honest node outputs a sequence of transactions... The other honest node outputs the transaction sequence as follows: ,but .

[0036] Censorship resistance: If a transaction tx is input to Nf honest nodes, then it will eventually be output by each honest node. f is the number of Byzantine nodes.

[0037] Specifically, once the proposal initiating node obtains a verifiable delayed hash sequence based on the VDF, it can initiate message signature verification consensus with the participating nodes based on this verifiable delayed hash sequence. Message signature verification consensus is achieved by the proposal initiating node sending an atomic broadcast to the participating nodes based on the verifiable delayed hash sequence. This atomic broadcast allows the participating nodes to receive the transaction data and prepare for transaction processing.

[0038] In some embodiments, S103 includes: the proposal initiating node generating a broadcast message based on a fragment of a verifiable delayed hash sequence and broadcasting it to the participating nodes; the participating nodes generating a reply message and broadcasting it after the signature verification of the broadcast message is passed; and the participating nodes broadcasting a preparation message indicating that they are ready to process the transaction after receiving 2f+1 broadcast reply messages; where f represents the number of Byzantine nodes.

[0039] The atomic broadcast process in this application embodiment, hereinafter referred to as the ERBC (Efficient and Reliable atomic Broadcast) process, includes three stages: broadcast stage, signature verification stage, and preparation stage. The specific process is as follows: Broadcast Phase: Node P (the proposal initiating node) broadcasts a fragment of the verifiable delayed hash sequence of the transaction subset to other consensus nodes (participating nodes). The broadcast message is as follows: ; in, It's a message signal. This is the current round of asynchronous consensus. It is the node number. This is a hash fragment within a verifiable delayed hash sequence. It should be understood that this hash fragment is an example of a sliced ​​verifiable delayed hash sequence. `j` represents the number of available cores in the participating consensus nodes, i.e., the number of CPU or GPU cores available in the participating nodes. `Sig` represents the number of cores available in the proposal node's input. and The signature. PK is the public key of the node that initiated the proposal.

[0040] Verification phase: Each node (participating node) receives the signature from node P (the proposal initiating node). After sending the message, verify the message signature. If the verification is successful, broadcast an echo (reply) message. The reply message is as follows: ; in, It's a message signal. It is the current round of asynchronous consensus. It is the node number. It is the hash of the tail transaction in the verifiable delayed hash sequence of the current consensus round node P (the proposal initiating node). Sig is the hash of the signature verification node pair. and The signature. PK is the public key of the verification node (the node that verifies the signature of the broadcast message).

[0041] Preparation phase: Each node collects data targeting... Node at After collecting 2f+1 echo messages, it indicates that 2f+1 participating nodes have verified the identity of the proposal initiating node and passed the authentication. Each node then broadcasts a "ready" message to the other nodes. The "ready" message indicates that the node is ready to process the proposal from node P (the proposal initiating node). The preparation message is as follows: ; in, It's a message signal. It is the current round of asynchronous consensus. It is the node number. It is the hash of the tail transaction in the verifiable delayed hash sequence of the current consensus round node P (the proposal initiating node). Sig is the hash of the signature verification node pair. and The signature is PK, which is the public key of this node (the node that sent the ready message). Therefore, after the consensus node (participating node) has received 2f+1 ready messages, it can enter the consensus process of verifying the consistency of the execution result. This consensus process is referred to as TVA (True Value Agreement) in this embodiment of the application.

[0042] S104 After the message signature verification is completed, each participating node performs consensus on the consistency verification of the execution result of the transaction data to be processed based on the verifiable delayed hash sequence.

[0043] Specifically, because traditional asynchronous consensus methods achieve 0 / 1 consensus on the ciphertext of transactions among consensus nodes, after threshold decryption of the transaction, the consensus nodes still need to reach a consensus on the execution result of the transaction. Therefore, in this embodiment, after implementing message signature verification through atomic broadcast, a consensus on the consistency of the execution result is further performed on the transaction data to be processed based on a verifiable delayed hash sequence.

[0044] In some embodiments, S104 includes: selecting a committee node from the participating nodes, having the committee node verify the transaction data to be processed locally based on a verifiable delayed hash sequence, obtaining the transaction verification result and broadcasting it; if the committee node collects 2f+1 identical transaction verification results, then confirming that the transaction verification result has reached a consensus; after the transaction verification result has reached a consensus, after the consensus rounds have converged by randomly flipping a coin, submitting the consensus result to each participating node.

[0045] Specifically, before reaching consensus, a number of committee members, i.e., committee nodes, are selected from all participating nodes to meet the security requirements. Then, the committee nodes conduct consensus verification of the transaction execution results. In this embodiment, the consensus verification of transaction execution results mainly includes a transaction verification execution phase and a transaction verification result consensus phase.

[0046] Transaction verification execution phase: Consensus nodes (i.e., committee nodes) execute the transaction data to be processed locally based on the received verifiable delayed hash sequence. The verification execution result is then broadcast to other consensus nodes (i.e., other committee nodes) via a BVAL message. Furthermore, this process can be executed in parallel using a multi-core mechanism, depending on the segmentation of the verifiable delayed hash sequence. The BVAL message is as follows: ; in, It's a message signal. It is the current round of asynchronous consensus. It is the node number of the node that initiated the proposal. It is the local transaction verification execution node number. It is the hash generated after the verifiable delay sequence of the proposal initiating node in the current consensus round has been verified. Sig is the hash of the current verification execution node. , and The signature. PK is the public key of this verification execution node (the node that sends the bval message).

[0047] Transaction verification result consensus phase: Consensus nodes (committee nodes) collect bval messages. If, in the bval messages of the current consensus round, there are 2f+1 verification execution results for the same proposal initiating node that are identical to the verification execution result of this node (statistics need to be compiled after signature verification is passed), it indicates that all consensus nodes (committee nodes) have reached a consensus on the pending transaction data of the proposal initiating node in this round. Subsequently, the tailHash value is written to the local TVA instance and an AUX message is broadcast. The AUX message is as follows: ; in, It's a message signal. It is the current round of asynchronous consensus. The node number of the node that initiated the proposal. This is the node number of this verification node. It is the hash generated after the verifiable delayed hash sequence of the node that initiated the proposal in the current consensus round has been verified.

[0048] Finally, after the transaction verification results are agreed upon, the Coin (random coin toss) process is executed, which uses random events to bring the TVA truth value instances in each consensus node to final agreement.

[0049] In addition, compared to traditional asynchronous consensus methods, such as the committee election method of Dumbo, the committee election in this application embodiment can generate committee members based on hash closed loop.

[0050] Therefore, in this embodiment of the application, compared with the traditional 0 / 1 consensus, since the ERBC process is already a verifiable hash truth value on the delayed sequence, the TVA process is a truth value consensus process.

[0051] like Figure 4 The diagram shown is a consensus flow diagram of an ERBC process and a TVA process provided in an embodiment of this application.

[0052] refer to Figure 4 During the ERBC process, the request message broadcasts the consensus node's proposal to other nodes. The echo phase verifies the consensus node's signature, and the ready message notifies other consensus nodes that they have received the subset of the proposal transaction. Before the TVA process, a consensus node is generated using a consistent hash ring to meet the security requirements. Figure 4 The CE stage is shown.

[0053] Then, during the TVA process, each committee node locally verifies the transactions in the proposed transaction subset, and broadcasts the verification results to the node via a BVAL message. During the AUX phase, all committee nodes reach a consensus on the verification results, and then the consensus rounds are converged through the Coin phase. Finally, all consensus nodes reach a consensus on the execution results of the proposed transaction subset and its contained transactions. If an overall sorting of transactions within all partitions is required, it can be done based on a trusted time-series source, since the transaction time-series verification has already been completed based on a verifiable delayed hash sequence parallel verification mechanism.

[0054] In this embodiment, the number of communication rounds between nodes is less than that of traditional asynchronous consensus methods such as Dumbo. Furthermore, after a certain number of communication rounds, this embodiment has already reached a consensus on the execution results of the proposal transaction and can guarantee the order of related transactions.

[0055] Furthermore, during the ERBC process, if the following conditions are met... At that time, the network traffic of ERBC is less than that of RBC used by honeypots and Dumbo. Among them, Indicates the length of the hash value. Indicates the signature length. Let represent the public key length, m represent the transaction length, n represent the number of consensus nodes, and b represent the number of transactions in the proposal. Therefore, it can be concluded that if the transaction length is large and the number of transactions in the proposal is high, ERBC's network traffic is less than that of RBC used by honeypots and Dumbo.

[0056] In some embodiments, after S104, the method further includes: storing the pending transaction data after the consensus of the execution result consistency verification, and the proposal initiating node clearing the pending transaction data from the transaction pool.

[0057] Specifically, after the TVA process, all consensus nodes reach an agreement on the TVA instance, meaning that the subset of transactions proposed by each consensus node reaches an agreement. Therefore, to signify that the pending transaction data has taken effect, the pending transaction data can be written to disk and stored, and the corresponding consensus node can clear the relevant transaction data from the transaction pool.

[0058] In summary, compared with existing consensus algorithms such as HoneyBadger and Dumbo, the embodiments of this application have the following advantages: 1. In the asynchronous blockchain network, within the Byzantine environment, transaction propagation, identity verification, transaction execution, and consensus steps are combined to ensure that transaction propagation, execution, and storage are completed during the asynchronous consensus process without the need to introduce additional consensus mechanisms.

[0059] 2. By using the broadcast of verifiable delayed hash sequences of transactions instead of distributing and propagating ciphertext subsets of transactions, the reliance on threshold encryption can be reduced during the asynchronous consensus process. This ensures lower network complexity, lower network load, and resistance to censorship, while eliminating the need to wait for the consensus process to be completed before decryption can be performed to obtain the original transaction text.

[0060] 3. Based on VDF, a verifiable delayed hash sequence is obtained, which can ensure the ordered verification of transactions when the time-series network is attacked or when consensus nodes are attacked by a man-in-the-middle attack. Furthermore, the verifiable delayed hash sequence of the transaction is sliced ​​and segmented, and then parallel verification is performed on the consensus nodes using multi-core CPUs and multi-core GPUs, which accelerates the transaction verification speed and improves the throughput of the asynchronous distributed system.

[0061] In some embodiments, to address the issue of ensuring that different consensus nodes propose different transactions as much as possible, this application introduces a consistent hashing closed loop to partition each transaction data into different consensus nodes, thereby enabling different transaction data to be proposed by only one consensus node.

[0062] Based on this, prior to S101, the process also includes: establishing a hash loop using the hash value of the unique identifier of the consensus node as the closing node; grouping transaction data in the transaction pool according to transaction relevance, and assigning the hash value of the group identifier as the key to the hash loop; on the hash loop, finding the node closest to the key according to a pre-agreed direction as the nearest node of the key; the pre-agreed direction includes counterclockwise or clockwise direction; and using the transaction data corresponding to the key as the pending transaction data of the corresponding nearest node to obtain the pending transaction data of the proposal initiating node.

[0063] like Figure 5 The diagram illustrates a transaction partitioning approach based on a consistent hashing closed loop. Specifically, it can be understood as partitioning transactions using a cryptographic function (...). Figure 5 The hash value calculated using SHA256 in the diagram can be imagined as a ring space. Assuming the asynchronous blockchain network system consists of 4 nodes, the unique identifiers of each of the 4 nodes are hashed using SHA256, and the hash values ​​are then fixed onto the ring. Figure 5 The circles shown represent nodes. Then, a hash value is generated based on the unique identifier of the group (e.g., a unique group code can be generated from the user's unique code, or it could be the contract number of the main smart contract), and the group's hash value is assigned to the ring. Figure 5 The ellipse shown represents the key. Finally, the key is used to find the nearest node in a clockwise or counter-clockwise direction, thus forming a partition. Ultimately, all transactions related to groups within a partition will be executed and proposed by that node. For example, Figure 5Transactions in group1 and group2 will be executed and proposed by node1. Transactions in group3 will be executed and proposed by node2. Transactions in group4 will be executed and proposed by node3. Transactions in group5 will be executed and proposed by node4.

[0064] In this context, a group can be understood as a combination of elements divided according to transaction relevance, specifically depending on the dimension of the partition. If partitioned by the user initiating the transaction request, several users with related transactions constitute a group. If partitioned by smart contracts in the blockchain, several smart contracts with dependencies constitute a group. An element can be understood as the smallest unit constituting a partition, specifically depending on the dimension of the partition. If partitioned by the user initiating the transaction request, an element is a single user. If partitioned by smart contracts in the blockchain, an element is a single smart contract. A partition can be understood as: several groups of transactions are distributed to a node for processing and proposal according to the aforementioned consistent hashing closed-loop method; these groups then constitute a partition.

[0065] In this embodiment, the use of a consistent hashing closed-loop for transaction partitioning gives asynchronous consensus advantages such as balance and scalability. Balance means that keys are distributed across all nodes as much as possible, ensuring that all nodes can be utilized. Scalability means that new nodes can join the distributed asynchronous system at any stage of the asynchronous consensus process, joining the next round of consensus through the consistent hashing ring algorithm without affecting the current round's consensus.

[0066] In some embodiments, such as Figure 6 The diagram shown is a flowchart illustrating an asynchronous blockchain network consensus method provided in an embodiment of this application. Figure 6 The asynchronous network consensus method for blockchain provided in this application will be briefly explained using an example.

[0067] Specifically, after the client writes transaction data to the transaction pool, the transaction data in the pool is partitioned, allowing each consensus node to identify the transaction data to be processed. Then, each proposal initiating node (the consensus node that initiated the proposal consensus) forms a transaction subset based on the corresponding unprocessed transaction data after the transaction partitioning. This transaction subset is a verifiable delayed hash sequence obtained by hashing based on VDF. Next, based on the verifiable delayed hash sequence, the ERBC and TVA processes are initiated. After processing through the EBRC and TVA stages, consensus is reached on the transaction subset. Finally, the agreed-upon transaction is written to disk and removed from the transaction pool.

[0068] In some embodiments, considering that the hash loop distribution may be uneven when there are few nodes in an asynchronous blockchain network, which could lead to transactions being skewed to some nodes, the network as a whole cannot fully utilize the effect of asynchronous parallel proposals from various nodes, thus affecting the system's throughput. Therefore, this problem can be further addressed by using virtual nodes. That is, if the number of consensus nodes is insufficient, virtual nodes can be added to the hash loop.

[0069] In some embodiments, considering the problem that in a hostile environment, if an adversary specifically damages a consensus node, causing some groups' transactions to be unable to execute and proposals to fail, this application can further achieve unpredictability in transaction partition switching by randomly rotating the consistent hash closed loop.

[0070] That is, consensus eras are divided according to consensus rounds or consensus time; at the beginning of each consensus era, the hash values ​​of each node on the hash loop are updated based on the verifiable delayed hash sequence of the last pending transaction data of each consensus node in the previous consensus era.

[0071] Specifically, in an asynchronous blockchain network system, consensus eras can be divided according to the rounds or time periods of consensus. At the beginning of each consensus era, the hash values ​​of the nodes on the hash loop are regenerated using the following formula, and these hash values ​​are then fixed back onto the hash loop, resulting in a new hash loop. Then, the transaction data in the transaction pool is re-partitioned based on the new consistent hash loop. The formula for calculating the hash value update is as follows: ; in, The hash value that the node was fixed to on the ring in the previous generation. This process assigns the fragment hash value of the delayed verification sequence from the last transaction subset of the previous generation's nodes. This is because the node's information is only known at the start of a new generation. Therefore, the hash loop updated in this way is unpredictable, thus ensuring overall security. In this embodiment of the application, all consensus nodes in the asynchronous blockchain network store this hash loop, and all consensus nodes execute the pending transaction data of other nodes, so all consensus nodes will record the hash loop of other nodes. Therefore, this method is feasible.

[0072] In some embodiments, for large-scale asynchronous blockchain network systems, in order to improve the system's TPS (Transactions Per Second) level, this application further employs a sharding mechanism to broadcast transactions in a weakly sharded (slave chain) manner during the ERBC phase, and simultaneously perform strongly sharded (slave chain) intra-consensus during the TVA phase. Furthermore, main chain consensus is performed after the slave chain consensus is completed, thereby effectively improving the system's throughput, and even achieving the optimal TPS level for synchronous consensus.

[0073] Based on this, and building upon the aforementioned asynchronous blockchain consensus method, this embodiment divides consensus nodes into slave chains, and elects leader nodes within these slave chains. Furthermore, when consensus nodes within any slave chain reach consensus within the chain, the proposal initiating the consensus simultaneously distributes the verifiable delayed hash sequence to the leader nodes of other slave chains. After the intra-chain consensus of the slave chains is completed, the leader nodes of each slave chain conduct main chain consensus based on the verifiable delayed hash sequence.

[0074] Specifically, such as Figure 7 The diagram shown is a flowchart illustrating the asynchronous network consensus method for blockchain provided in an embodiment of this application. (Reference) Figure 7 The main components of the asynchronous blockchain network consensus method in this application embodiment include: First, at the start of asynchronous consensus, the consensus nodes are divided into m groups, resulting in m slave chains. Then, a leader node is elected from each slave chain. The leader node can be rotated in each round, and any existing leader node election method can be used to determine it. In this embodiment, the Proof of Stake (POS) algorithm is used to select the leader node for each slave chain.

[0075] Then, consensus proposals for the pending transaction data are generated from various consensus nodes within the chain. Specifically, each consensus node within the chain broadcasts the verifiable delayed hash sequence of the proposed pending transaction data to other consensus nodes within its own chain, and also distributes the verifiable delayed hash sequence of the proposal to the leader nodes of other chains.

[0076] Secondly, the ERBC and TVA processes are performed within the same sub-chain based on a verifiable delayed hash sequence. After the ERBC process, the verifiable delayed hash sequence proposed by the consensus node is reliably distributed to the consensus nodes within the sub-chain and the leader nodes of other sub-chains. It's important to note that during the TVA process, the consensus nodes within the sub-chain only verify transactions proposed by their own consensus nodes. After the TVA process, asynchronous consensus within the sub-chain ends, and the consensus nodes reach an agreement on the transactions proposed by their own sub-chain and their execution results. At this point, the leader node of the sub-chain locally stores the transactions and execution results of its own sub-chain, as well as the transactions from other sub-chains awaiting verification. The details of the ERBC and TVA processes within the sub-chain in this embodiment are the same as described above; please refer to the description of the above embodiments for details, which will not be repeated here.

[0077] Finally, the leader nodes of each slave chain perform asynchronous consensus with the main chain. First, the leader nodes verify the transactions of other slave chains (multi-core technology can be used for parallel verification depending on requirements), and reach consensus among the slave chains on the transactions and results proposed by each slave chain through the TVA process. It should be noted that because the leader nodes of the slave chains have already obtained the verifiable delayed hash sequences and transactions of other slave chains during the ERBC process, the main chain does not need to perform ERBC again; it only needs to verify transactions through TVA.

[0078] Therefore, in the embodiments of this application, in scenarios with high performance requirements, by dividing into slave chains and achieving consensus within the slave chains and then achieving consensus between slave chains on the main chain, the TPS of asynchronous consensus can be effectively brought to the optimal TPS level of synchronous consensus under large-scale networking.

[0079] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0080] In one embodiment, a computer device is provided, which may be a server, including a processor, memory, and a network interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device is used to store data. The network interface of the computer device is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a blockchain asynchronous network consensus method. Exemplarily, the computer program may be divided into one or more modules, one or more of which are stored in memory and executed by the processor to complete the invention. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the computer device. The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the computer device, connecting various parts of the computer device via various interfaces and lines.

[0081] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the computer device by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc.; the data storage area may store data created according to the use of the device, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0082] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0083] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A blockchain asynchronous network consensus method, characterized in that, include: A hash loop is established using the hash value of the unique identifier of the consensus node as the closing node; The transaction data in the transaction pool is grouped according to transaction relevance, and the hash value of the group identifier is assigned as the key to the hash loop. On the hash loop, the node closest to the keyword is found according to a pre-defined direction as the nearest node to the keyword; the pre-defined direction includes either a counter-clockwise or clockwise direction. The transaction data corresponding to the keyword is used as the pending transaction data of the nearest node to obtain the pending transaction data of the proposal initiating node. The proposal initiating node reads the transaction data to be processed from the transaction pool; The proposal initiating node performs hash processing on the pending transaction data based on the verifiable delay function (VDF) to form a verifiable delayed hash sequence of the pending transaction data; the verifiable delayed hash sequence is a computational sequence formed by sequential operation of cryptographic functions, and the hash value of each transaction is generated by concatenating the hash output of the previous transaction with the processing result of the current transaction and then performing a hash operation. The proposal initiating node generates a broadcast message based on a fragment of the verifiable delayed hash sequence, and sends an atomic broadcast carrying the verifiable delayed hash sequence to the participating nodes for message signature verification. The atomic broadcast satisfies consistency, total order, and censorship resistance. After the participating nodes pass the signature verification of the broadcast message, they generate a reply message broadcast, and broadcast a preparation message after receiving 2f+1 of the reply messages, where f is the number of Byzantine nodes. After message signature verification is completed, each participating node performs consensus on the consistency of the execution result of the pending transaction data based on the verifiable delayed hash sequence. The verification consensus is achieved by selecting committee nodes to execute transactions locally and broadcasting verification results. After collecting 2f+1 identical results, a consensus is confirmed without the need to introduce an additional consensus mechanism. The method further includes: Consensus nodes are divided to form a chain, and a leader node is elected from the chain. When any of the consensus nodes in the slave chain reach consensus within the chain, the proposal initiating node synchronously distributes the verifiable delayed hash sequence to the leader node of other slave chains; After the intra-chain consensus of the slave chains is completed, the leader nodes of each slave chain conduct main chain consensus based on the verifiable delayed hash sequence; The proposal initiating node slices the verifiable delayed hash sequence of the transaction data to be processed based on the number of CPU or GPU cores.

2. The method according to claim 1, characterized in that, The method further includes: Consensus eras can be divided based on consensus rounds or consensus time. At the beginning of each consensus era, the hash value of each node on the hash loop is updated based on the verifiable delayed hash sequence of the last pending transaction data of each consensus node in the previous consensus era.

3. The method according to claim 1, characterized in that, The method further includes adding virtual nodes in the hash loop.

4. The method according to claim 1, characterized in that, The proposal initiating node sends an atomic broadcast message carrying the verifiable delayed hash sequence to the participating nodes for message signature verification, including: The proposal initiating node generates a broadcast message based on a fragment of the verifiable delayed hash sequence and broadcasts it to the participating nodes; After the participating node passes the signature verification of the broadcast message, it generates a reply message broadcast. After receiving 2f+1 broadcast reply messages, the participating node broadcasts a ready message indicating that it is ready to process the transaction; where f represents the number of Byzantine nodes.

5. The method according to claim 1, characterized in that, The participating nodes perform consensus verification on the consistency of the execution results of the pending transaction data based on the verifiable delayed hash sequence, including: A committee node is selected from the participating nodes. The committee node verifies the transaction data to be processed locally based on the verifiable delayed hash sequence, obtains the transaction verification result, and broadcasts it. If the committee node collects 2f+1 identical transaction verification results, it confirms that the transaction verification results have reached a consensus; where f represents the number of Byzantine nodes. After the transaction verification results are agreed upon, the consensus rounds are converged by randomly flipping a coin, and the consensus results are submitted to each of the participating nodes.

6. The method according to any one of claims 1-5, characterized in that, After the participating nodes reach a consensus on the consistency of the execution results of the pending transaction data based on the verifiable delayed hash sequence, the method further includes: storing the pending transaction data after the consistency of the execution results is verified on disk, and the proposal initiating node clears the pending transaction data from the transaction pool.

7. A computer device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, The processor is used to implement the blockchain asynchronous network consensus method according to any one of claims 1-6 when executing the computer program.

Images