Block consensus method, synchronization method, device, electronic equipment and storage medium

Abstract

This application provides a block consensus method, synchronization method, apparatus, electronic device, and storage medium, relating to the blockchain field. The method is applied to any node in a blockchain system and includes: obtaining multiple voting results within a preset time period, each voting result being a verification result generated by a slave node in the blockchain system for a first block to be consensused; when a voting result is a first voting result indicating that there are failed verification transactions in the first block, the first voting result also includes the transaction identifier of the failed verification transaction in the first block; if it is determined that the consensus of the first block has failed based on the multiple voting results, then a preset local transaction pool is cleaned up according to the transaction identifiers of the failed verification transactions included in each of the multiple voting results. This application embodiment achieves that transactions that have generally failed verification will not be repackaged during a change of ownership, thus advancing the consensus process and improving consensus efficiency.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a block consensus method, synchronization method, device, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] Smart contracts are an important part of blockchain systems. They are computer protocols designed to disseminate, verify, or execute contracts in an informational manner. Smart contracts allow for trusted transactions without the need for a third party, and these transactions are queryable and irreversible.

[0003] Blockchain is a deterministic state machine, requiring all nodes in the blockchain system to agree on the execution results of transactions in order to achieve consensus; otherwise, consensus fails. To support this determinism, most publicly available smart contracts intentionally shield themselves from random functions such as random numbers and timestamps from their inception.

[0004] However, with the current development of blockchain, more and more widely used languages ​​are being applied to blockchain. These widely used languages ​​usually support random functions such as random numbers, which brings hidden dangers to the blockchain system. Summary of the Invention

[0005] This application provides a block consensus method, synchronization method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can solve the above-mentioned problems of the prior art. The technical solution is as follows:

[0006] According to one aspect of the embodiments of this application, a block consensus method is provided, applied to any node in a blockchain system, wherein the any node is a master node or a slave node, the method comprising:

[0007] Multiple voting results are obtained within a preset time period. Each voting result is a verification result generated by a slave node in the blockchain system for the first block to be consensused. The first block includes the transaction identifier of at least one transaction. The voting result is used to indicate whether there is a transaction that failed to be verified in the first block. When the voting result is a first voting result indicating that there is a transaction that failed to be verified in the first block, the first voting result also includes the transaction identifier of the transaction that failed to be verified in the first block.

[0008] If the consensus of the first block fails based on multiple voting results, the preset local transaction pool is cleaned up according to the transaction identifier of the failed transaction included in each of the multiple voting results.

[0009] The transaction pool includes transactions corresponding to the transaction identifiers in the first block.

[0010] As an optional embodiment, based on the transactions that failed verification included in each of the multiple voting results, a preset local transaction pool is cleaned up, including:

[0011] Determine the number of times each failed verification transaction appears in all first-vote results;

[0012] Transactions that fail verification more times than the number of malicious nodes in the blockchain are removed from the transaction pool.

[0013] As an optional embodiment, when any of the nodes is a slave node, the method further includes:

[0014] Obtain the first block sent by the master node;

[0015] The first block is verified and voted on to obtain the voting results, which are then sent to multiple other nodes in the blockchain system.

[0016] As an optional embodiment, if it is determined that the first block consensus has failed based on multiple voting results, the process further includes:

[0017] Perform the operation to replace the master node.

[0018] As an optional embodiment, when any of the nodes is a slave node, the operation of changing the master node further includes:

[0019] If any of the nodes is determined to be the new master node, the transactions in the cleaned transaction pool will be packaged into a second block awaiting consensus.

[0020] The second block is broadcast to other nodes in the blockchain system to achieve block consensus.

[0021] As an optional implementation, determining that the first block consensus has failed based on multiple voting results includes:

[0022] If the number of the first voting results among the multiple voting results is greater than the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed; or

[0023] If, among the multiple voting results, the number of the first voting results is not greater than the number of malicious nodes in the blockchain, and the number of the second voting results is not greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed.

[0024] The second voting result is used to indicate that there are no failed verification transactions in the first block.

[0025] As an optional embodiment, the voting results are obtained within a preset time period, and then the process further includes:

[0026] If, among the multiple voting results, the number of second voting results is greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to be successful, and the transaction corresponding to the transaction identifier in the first block is written into the ledger.

[0027] As an optional embodiment, the first block also includes the execution results of the master node for each transaction corresponding to the transaction identifier;

[0028] The verification voting on the first block to obtain the voting result includes:

[0029] Execute the transaction corresponding to each transaction identifier in the first block. If it is determined that there is a transaction whose execution result is inconsistent with the execution result of the master node, the transaction that failed to be verified is obtained, and the first voting result is obtained.

[0030] If it is determined that there are no transactions whose execution results are inconsistent with those of the master node, then the second voting result is obtained.

[0031] According to another aspect of the embodiments of this application, a block synchronization method is provided, applied to a node executing the block consensus method provided in the first aspect, the block synchronization method comprising:

[0032] Obtain the third block to be synchronized from at least one other node in the blockchain system;

[0033] The third block is verified by not executing the verification of the transactions in the third block;

[0034] If the verification passes, the transactions in the third block will be synchronized to the local ledger.

[0035] As an optional embodiment, the verification method includes verifying the legal node count certificate or block hash of the third block.

[0036] According to another aspect of the embodiments of this application, a block consensus device is provided, applied to any node in a blockchain system, wherein the any node is a master node or a slave node, the device comprising:

[0037] The voting result acquisition module is used to obtain multiple voting results within a preset time period. Each voting result is a verification result generated by a slave node in the blockchain system for a first block to be consensused. The first block includes the transaction identifier of at least one transaction. The voting result is used to indicate whether there is a transaction that failed verification in the first block. When the voting result is a first voting result indicating that there is a transaction that failed verification in the first block, the first voting result also includes the transaction identifier of the transaction that failed verification in the first block.

[0038] The transaction cleanup module is used to clean up a preset local transaction pool if the consensus of the first block fails based on multiple voting results, according to the transaction identifier of the failed transaction included in each of the multiple voting results.

[0039] The transaction pool includes transactions corresponding to the transaction identifiers in the first block.

[0040] As an optional embodiment, the transaction clearing module includes:

[0041] The frequency counting unit is used to determine the number of times each failed verification transaction appears in all the first voting results;

[0042] The transaction clearing unit is used to remove transactions that have failed verification more than the number of malicious nodes in the blockchain from the transaction pool.

[0043] As an optional embodiment, when any of the nodes is a slave node, the block consensus device includes:

[0044] A block receiving module is used to obtain the first block sent by the master node;

[0045] The verification voting module is used to verify the voting on the first block, obtain the voting results, and send the voting results to multiple other nodes in the blockchain system.

[0046] As an optional embodiment, the block consensus device further includes:

[0047] The master node replacement module is used to replace the master node if the consensus of the first block fails based on multiple voting results.

[0048] As an optional embodiment, the block consensus device further includes:

[0049] The block packaging module is used to package the transactions in the cleaned transaction pool into a second block to be reached for consensus if any of the nodes is determined to be the new master node.

[0050] The block broadcasting module is used to broadcast the second block to other nodes in the blockchain system for block consensus.

[0051] As an optional embodiment, the block consensus device includes:

[0052] The block consensus module is configured to determine that the first block consensus has failed if the number of the first voting results among the multiple voting results is greater than the number of malicious nodes in the blockchain; or

[0053] If, among the multiple voting results, the number of the first voting results is not greater than the number of malicious nodes in the blockchain, and the number of the second voting results is not greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed.

[0054] The second voting result is used to indicate that there are no failed verification transactions in the first block.

[0055] As an optional implementation, the block consensus module is also used for:

[0056] If, among the multiple voting results, the number of second voting results is greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to be successful, and the transaction corresponding to the transaction identifier in the first block is written into the ledger.

[0057] As an optional embodiment, the first block also includes the execution results of the master node for each transaction corresponding to the transaction identifier;

[0058] The vote verification module is specifically used for:

[0059] Execute the transaction corresponding to each transaction identifier in the first block. If it is determined that there is a transaction whose execution result is inconsistent with the execution result of the master node, the transaction that failed to be verified is obtained, and the first voting result is obtained.

[0060] If it is determined that there are no transactions whose execution results are inconsistent with those of the master node, then the second voting result is obtained.

[0061] According to another aspect of the embodiments of this application, a block synchronization device is provided, applied to a node performing the method as described above, the device comprising:

[0062] The block acquisition module is used to obtain a third block to be synchronized from at least one other node in the blockchain system.

[0063] The verification module is used to verify the third block in a manner that does not execute the verification of transactions in the third block;

[0064] The synchronization module is used to synchronize the transactions in the third block to the local ledger if the verification passes.

[0065] As an optional embodiment, the verification method includes verifying the legal node count certificate or block hash of the third block.

[0066] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the methods provided in the above aspects.

[0067] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the methods provided in the above aspects.

[0068] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the methods provided in the above aspects.

[0069] The beneficial effects of the technical solutions provided in this application are:

[0070] By obtaining multiple voting results within a preset time period, each voting result is a verification result generated by a slave node in the blockchain system for the first block to be consensused. The first block includes the transaction identifier of at least one transaction. The voting results are used to indicate whether there are any failed verification transactions in the first block. When the voting result is the first voting result indicating that there are failed verification transactions in the first block, the first voting result also includes the transaction identifier of the failed verification transactions in the first block. If it is determined that the consensus of the first block has failed based on multiple voting results, the preset local transaction pool is cleaned up according to the transaction identifier of the failed verification transactions included in each of the multiple voting results. Subsequently, when switching leaders, transactions that have generally failed verification will not be repackaged, thereby advancing the consensus progress and improving consensus efficiency. Attached Figure Description

[0071] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0072] Figure 1 A schematic diagram of an optional structure of a distributed system applied to a blockchain system, as provided in an embodiment of this application;

[0073] Figure 2 A schematic diagram of a block structure provided in an embodiment of this application;

[0074] Figure 3 This is a diagram illustrating the problems that related technologies face when dealing with timestamp random functions.

[0075] Figure 4 This is a diagram illustrating another problem that related technologies face when dealing with timestamp random functions;

[0076] Figure 5 A flowchart illustrating a block consensus method provided in an embodiment of this application;

[0077] Figure 6 A schematic diagram illustrating the composition of a first voting result provided in an embodiment of this application;

[0078] Figure 7 A schematic diagram of a donation interface of a public welfare donation client according to an embodiment of this application;

[0079] Figure 8 This is a flowchart illustrating a block consensus method according to an embodiment of this application;

[0080] Figure 9 This is a flowchart illustrating a block consensus method after a change of ownership, according to one embodiment of this application.

[0081] Figure 10 This is a flowchart illustrating the block consensus method according to an embodiment of this application;

[0082] Figure 11 This is a schematic diagram illustrating the interaction between the master node and slave node in the block consensus process according to an embodiment of this application.

[0083] Figure 12 A schematic diagram illustrating a specific scenario of applying the block consensus method of this application embodiment;

[0084] Figure 13 This is a flowchart illustrating the block synchronization method according to an embodiment of this application;

[0085] Figure 14 This is a flowchart illustrating a block synchronization method according to another embodiment of this application;

[0086] Figure 15 This is a schematic diagram of the block consensus device provided in the embodiments of this application;

[0087] Figure 16 This is a schematic diagram of the block synchronization device provided in the embodiments of this application;

[0088] Figure 17 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0089] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0090] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0091] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0092] First, let's introduce and explain several terms used in this application:

[0093] 1) Byzantine Fault: A malicious node that sends inconsistent information to other nodes in order to obstruct the transmission of true information and the achievement of effective consistency. The ability to handle Byzantine faults is called Byzantine Fault Tolerance (BFT).

[0094] 2) Practical Byzantine Fault Tolerance (PBFT) algorithm: The core of PBFT is majority rule. For example, when the number of nodes is greater than or equal to 4, the existence of one invalid node will not affect message transmission. Generalizing, when there are n invalid nodes, as long as the total number of nodes exceeds 3n, the correctness of message transmission can be guaranteed. This is the fault tolerance rate of the Byzantine algorithm.

[0095] The technical solutions of this application and their effects are described below through several exemplary embodiments. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0096] The solution proposed in this application can be applied to blockchain systems, specifically to scenarios where clients within a blockchain system conduct transactions. Using this solution, the client sends a transaction to connectable nodes in the blockchain system. These nodes then synchronize the transaction to all nodes. Each node receiving the transaction stores it in a transaction pool. The master node then packages the transaction into a block to be verified. The master node broadcasts this block to all slave nodes in the blockchain system. Each slave node performs consensus on the block and broadcasts the voting results to other nodes in the blockchain system (including the master node). When a slave node determines that a verification has been successful, the corresponding voting result also includes the transaction identifier of the failed verification transaction. Each node can then determine whether the block has achieved consensus based on the received voting results. If consensus is successful, the pre-defined local transaction pool can be cleaned up based on the transaction identifiers of the failed verification transactions included in each of the multiple voting results. This avoids the risk of repackaging failed verification transactions during subsequent changes in master node ownership.

[0097] The blockchain system involved in this invention can be a distributed system formed by connecting clients and multiple nodes (any form of computing device in the network, such as servers and user terminals) through network communication.

[0098] See Figure 1 , Figure 1 This is an optional structural diagram of the distributed system 100 provided in this embodiment of the invention applied to a blockchain system. It consists of multiple nodes (any form of computing device in the network, such as servers or user terminals) and clients, forming a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0099] See Figure 1 The functions of each node in the blockchain system shown include:

[0100] 1) Routing: A basic function of nodes used to support communication between nodes.

[0101] In addition to routing capabilities, nodes can also have the following functions:

[0102] 2) Applications are deployed in the blockchain to implement specific business needs. They record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0103] For example, the business logic implemented by the application includes:

[0104] 2.1) A wallet is used to provide the function of trading virtual assets, including initiating a transaction (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After the other nodes successfully verify the transaction, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining virtual assets in the virtual asset address.

[0105] 2.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain system. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0106] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's virtual assets to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0107] 3) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks contain the data submitted by the nodes in the blockchain system.

[0108] See Figure 2 , Figure 2This is an optional schematic diagram of the block structure provided in this embodiment of the invention. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through their hash values ​​to form a blockchain. Additionally, the block may include information such as a timestamp when it was generated. A blockchain is essentially a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0109] The related technologies have the following drawbacks:

[0110] Defect 1: When nodes reach a consensus, there may still be f (f is the number of malicious nodes) nodes that have not reached a consensus. These nodes cannot reach a consensus with other nodes at that time, so they will synchronize through the synchronization module. However, the synchronization process requires the execution of transactions, which will still produce inconsistencies, so they will never catch up with the whole chain.

[0111] Defect 2: If a node is newly added to the blockchain system or restarts after a crash, it needs to synchronize data from other nodes. Because it needs to execute transactions, inconsistent execution results will also be generated due to the random function, so it will never be able to catch up with the entire chain (this problem is the same as 1).

[0112] Please see Figure 3 The diagram illustrates the problems that related technologies face when dealing with timestamp random functions. As shown in the figure, the transaction processed by each node in the blockchain system is "getting the current local time". Since the local clocks of different nodes may be inconsistent, this transaction can be understood as a transaction based on a timestamp random function. The blockchain system in the figure has 4 nodes. The number of malicious nodes in the system is set to 1 in advance. Since the local time of nodes 1 to 3 is consistent, only the local time of node 4 is inconsistent with the local time of the other 3 nodes. In this case, node 4 of the related technology cannot reach a consensus because it can never reach a consensus with the other nodes.

[0113] Thirdly, when nodes cannot reach a consensus, because it is unknown which transaction was caused by a random function, that transaction cannot be removed. This leads to the risk that even if the master node is changed, the transaction will still be packaged, resulting in continued inconsistency and affecting the overall use of the blockchain system.

[0114] Please see Figure 4The diagram illustrates another problem that the related technology faces when dealing with timestamp random functions. As shown in the figure, the blockchain system includes 4 nodes, with the number of malicious nodes set to 1 in advance. The transaction processed by each node in the blockchain system is "get the current local time". Since there are two types of time obtained by all nodes, and each type of time corresponds to 2 nodes, it is impossible to reach a consensus. Even if the master node is changed, a consensus will still not be reached.

[0115] The block consensus method, block synchronization method, device, electronic device, computer-readable storage medium, and computer program product provided in this application are intended to solve the above-mentioned technical problems of the prior art.

[0116] It is understood that the solution proposed in this application can be used in the aforementioned blockchain system for the process of clients initiating transactions and various blockchain nodes conducting transactions. The technical solution provided in this application will be described in detail below with reference to specific implementation methods.

[0117] This application provides a block consensus method, such as... Figure 5 As shown, the method includes:

[0118] S101. Obtain multiple voting results within a preset time period.

[0119] It should be noted that each voting result is a verification result generated by a slave node in the blockchain system for the first block to be consensus. The block consensus method of this application embodiment is applicable to any node, that is, it can be either a master node or a slave node. Therefore, when the method is applied to a master node, the voting results obtained by the master node are all the voting results generated by each slave node. When the method is applied to a slave node, the obtained voting results may include the voting results generated by the slave node itself for the first block.

[0120] This application can start a timer of a preset duration, and only receive voting results sent by other nodes during the timer's countdown period. This application does not specifically limit the timing of starting the timer; for example, the timer can be started when the first voting result is obtained.

[0121] The first block in this embodiment includes transaction identifiers for at least one transaction. As an optional embodiment, the first block may also include transactions for the slave node receiving the first block to execute and generate voting results. As an optional embodiment, when the first block does not include any transactions, the slave node can search its own transaction pool based on the transaction identifiers in the first block and execute the searched transactions to generate voting results.

[0122] The voting result in this embodiment indicates whether there are any failed verification transactions in the first block. That is, the voting result represents two verification results: either there are failed verification transactions (not limited to one or more) in the first block, or there are no failed verification transactions in the first block. When the voting result is a first voting result indicating that there are failed verification transactions in the first block, the first voting result also includes the transaction identifier of the failed verification transaction in the first block. By adding the transaction identifier of the failed verification transaction to the first voting result, this embodiment enables the node receiving the voting result to know what anomalies other nodes have made in their judgments of the transactions in the block.

[0123] Please see Figure 6 The figure illustrates a schematic diagram of the composition of the first voting result of an embodiment of this application. As shown in the figure, the first voting result includes a voting identifier for indicating that there is a transaction that failed to be verified and a transaction identifier for the transaction that failed to be verified. In the figure, Nil Block Hash is a voting identifier used to indicate that there is a transaction that failed to be verified. It is an empty value, indicating that no consensus has been reached on the block hash. Tx1 and Tx5 are the transaction identifiers of two transactions that failed to be verified.

[0124] As an optional embodiment, the voting identifier indicating that there is a failed verification transaction can be represented by an empty value. The first block also includes the block hash generated by the master node performing a hash operation on the first block. If the block hash generated by the slave node is inconsistent with the block hash carried in the first block, it uses an empty value as the voting identifier. In this way, when other nodes receive the voting result, they can know that the slave node that sent the voting result has determined that the first block is abnormal.

[0125] S102. If the consensus of the first block fails based on multiple voting results, the preset local transaction pool is cleaned up according to the transaction identifier of the failed transaction included in each of the multiple voting results.

[0126] Based on Byzantine consensus, the success of the first block consensus can be determined by multiple voting results. If the first block consensus fails, this application further cleans up a pre-defined local transaction pool based on the transaction identifiers of the failed transactions included in each of the first voting results. Specifically, transactions with a certain number of failed verifications can be removed from the transaction pool. Since consensus failure triggers a change of master (node) operation, if the node is subsequently identified as the new master node, it will not repackage transactions with widespread failed verifications when packaging transactions from the transaction pool, thereby advancing the consensus process and improving consensus efficiency.

[0127] In some embodiments, when a client needs to upload a transaction to the blockchain, it can first send the transaction to one or more connected nodes, which then broadcast the transaction to all nodes in the blockchain system. This allows each node to store the transaction to be verified in its local transaction pool. Subsequently, the master node packages the transaction into a block and sends it to each slave node for verification. The packaged block may include the transaction itself or only the transaction identifier. When only the transaction identifier is included, the node can determine the corresponding transaction from its local transaction pool.

[0128] The block consensus method of this application embodiment is applied to a master node or slave node in a blockchain system. This method obtains multiple voting results, each generated by a slave node in the blockchain system for a first block to be consensused. The first block includes transaction identifiers of at least one transaction. The voting results indicate whether there are any failed verification transactions in the first block. When the voting result is a first voting result indicating the presence of failed verification transactions in the first block, the first voting result also includes the transaction identifiers of the failed verification transactions in the first block. If the consensus of the first block fails based on the multiple voting results, a preset local transaction pool is cleaned up according to the transaction identifiers of the failed verification transactions included in each of the first voting results. This prevents the repackaging of commonly failed verification transactions during subsequent master node changes, thereby advancing the consensus process and improving consensus efficiency.

[0129] Based on the above embodiments, as an optional embodiment, the preset local transaction pool is cleaned up according to the failed verification transactions included in each of the first voting results among the multiple voting results, including:

[0130] Determine the number of times each failed verification transaction appears in all first-vote results;

[0131] Transactions that fail verification more times than the number of malicious nodes in the blockchain are removed from the transaction pool.

[0132] When a node determines that consensus has failed based on the received voting results, it means that the number of first voting results in each voting result is greater than the number of malicious nodes in the blockchain. Since the first voting result includes the transaction identifier of at least one failed verification transaction, this application can count the number of times each failed verification transaction appears in each first voting result. If the number is greater than the number of malicious nodes in the blockchain, it means that at least one honest node has failed to verify the transaction. Therefore, the transaction can be considered to be an abnormal transaction and needs to be removed from the transaction pool.

[0133] Based on the above embodiments, as an optional embodiment, when the embodiments of this application are applied to a slave node, the method further includes:

[0134] S201, Obtain the first block sent by the master node;

[0135] S202. Verify and vote on the first block to obtain the voting results, and send the voting results to multiple other nodes in the blockchain system.

[0136] In addition to receiving voting results from other nodes, the slave nodes in this application must also generate their own voting results and broadcast them to other nodes in the blockchain system (including the master node). Specifically, the master node sends the first block to each slave node. The slave nodes that receive the first block verify and vote on the first block, obtain the voting results, and broadcast them to other nodes.

[0137] In some embodiments, transactions need to be uploaded by the transactor through a client. This application does not specifically limit the application scenario of the client. For example, it can be a client for realizing charitable donations. The donor (i.e., the transactor) enters the specific donated items on the charitable donation client. When the donation is completed, the charitable donation client generates a transaction based on the relevant information of the donated items, such as the donor, the donation project, and the donation time. The transaction is uploaded to some nodes in the blockchain, and then some nodes broadcast the transaction to all nodes. After receiving the transaction, the master node packages the transaction into the first block and broadcasts it to each slave node.

[0138] Please see Figure 7 The illustration shows a schematic diagram of the donation interface of the charitable donation client according to an embodiment of this application. When the charitable donation client is running, this interface is displayed. Donors can click on the controls on the interface to select different donation projects. After selecting a donation project, they can enter the amount in the input box and perform the payment operation to complete the charitable donation. When the payment is completed, the charitable donation client will generate a transaction and send it to some nodes of the blockchain system.

[0139] Please see Figure 8The figure illustrates a flowchart of a block consensus method according to an embodiment of this application. As shown, the blockchain system of this embodiment includes four nodes. Assuming one of the four nodes is malicious, the master node is node 0, and the slave nodes are nodes 1 to 3. The master node sends a block to be consensused to each slave node. This block includes four transactions, tx1 to tx4, where tx1 to tx3 are abnormal transactions. Nodes 1 to 3 all verify the failed transactions, therefore, nodes 1 to 3 broadcast the first voting results to the other nodes. Specifically, node 1 verifies the failed transactions as tx1 and tx2, node 2 verifies the failed transactions as tx1, tx2, and tx3, and node 3 verifies the failed transactions as tx2 and tx3.

[0140] It should be understood that a node can obtain a block consensus result as long as it receives more than twice the number of malicious nodes. Therefore, in this embodiment, each node only needs to receive two votes to obtain a block consensus result. For the master node, it needs to obtain votes from at least two slave nodes to obtain a block consensus result, while for a slave node, since it has generated one vote, it only needs to obtain one more vote from another slave node to obtain a block consensus result.

[0141] In this embodiment, node 0, acting as the master node, receives the voting results from nodes 1 and 2. Since tx1 and tx2 appear twice in both votes (greater than the number of malicious nodes), while tx3 appears once (not greater than the number of malicious nodes), tx1 and tx2 are removed from the local transaction pool. Similarly, node 1, based on the votes received from nodes 2 and 3, determines to remove tx1, tx2, and tx3 from its local transaction pool. Node 2, based on the votes received from node 1 and its own generated vote, determines to remove tx1 and tx2 from its local transaction pool. Node 3, based on the votes received from node 2 and its own generated vote, determines to remove tx2 and tx3 from its local transaction pool.

[0142] As can be seen from the above embodiments, this deletion method may not be able to delete all disapproved transactions at once, due to two key points: First, not all nodes execute inconsistencies with the master node; for example, with timestamp random functions, slave nodes are more likely to be consistent with the master node. Second, a node has fault tolerance; it only needs to receive more than 2f votes to proceed to the next stage, and these votes do not specify which nodes broadcast them from. Figure 7In the illustrated embodiment, three transactions, tx1, tx2, and tx3, are all abnormal. However, only node 1 detected all the abnormal transactions; nodes 0 and 2 did not detect abnormal transaction 3, and node 3 did not detect abnormal transaction 1. Therefore, based on the above embodiments, as an optional embodiment, if the consensus of the first block fails according to multiple voting results, the process further includes:

[0143] Perform the operation to replace the master node.

[0144] It should be understood that when one node fails to reach consensus on a block, it means that all nodes will fail to reach consensus on that block, and therefore all nodes will perform a master node replacement operation. Clearly, all nodes will follow the same master node replacement process and select the same new master node.

[0145] This application does not limit the specific method of changing the master node. For example, all nodes can be numbered in advance, and each time it is determined to change the master node, the next node to be changed from the current master node number can be used as the new master node.

[0146] Specifically, when a new node joins the blockchain system, it obtains its own identification information, the identification information of the current master node, and the rules of the next master node. It receives the block sent by the master node, verifies and votes on it, obtains the voting results, and sends the voting results to multiple other nodes in the blockchain system. The node also receives the voting results of other nodes and performs block consensus on the first block based on the voting results. If consensus fails, the operation of changing the master node is executed. Since the identification information of the current master node is predetermined, the new master node is determined to be the node whose identification number is one after the original master node's number. Block consensus is performed based on the new master node.

[0147] Based on the above embodiments, as an optional embodiment, when any node is a slave node, the operation of changing the master node further includes:

[0148] If any of the nodes is determined to be the new master node, the transactions in the cleaned transaction pool will be packaged into a second block awaiting consensus.

[0149] The second block is broadcast to other nodes in the blockchain system to achieve block consensus.

[0150] It should be noted that if a slave node in this application embodiment is determined to be the new master node after performing a master node replacement operation, it will package the transactions in the cleaned transaction pool into a second block to be reached through consensus. By broadcasting the second block to other nodes, the other nodes can verify the transactions in the second block until consensus is reached.

[0151] Please see Figure 9 This example illustrates a flowchart of a block consensus method after a change of ownership, according to one embodiment of this application. Figure 8 The subsequent process based on the illustrated embodiment involves changing the master node. Node 2 is then determined as the new master node. Since Node 2 has previously removed transactions tx1 and tx2 from the traffic pool, it is only necessary to package transactions tx3 and tx4 in the transaction pool into a block and broadcast it to other nodes. Nodes 0, 1, and 3 verify the transactions. Node 0 determines that transaction 3 is a failed verification transaction, and Node 1 also determines that transaction 3 is a failed verification transaction. Both Node 0 and Node 1 broadcast the first voting result. Node 3 does not find any failed verification transactions, so it broadcasts the second voting result.

[0152] For node 0, it receives the voting results from nodes 1 and 3. Since node 0 itself determines that transaction tx3 failed to be verified, and node 1's first voting result also records that transaction tx3 failed to be verified, the number of times tx3 failed to be verified is 2, which is greater than the number of malicious nodes, 1. Therefore, it can be determined that tx3 should be removed from the transaction pool.

[0153] For node 1, after receiving the voting results from nodes 2 and 3, since node 1 itself determined that transaction tx3 failed to be verified, and node 2's first voting result also recorded that transaction tx3 failed to be verified, the number of times tx3 failed to be verified was 2, which is greater than the number of malicious nodes (1). Therefore, it can be determined to remove tx3 from the transaction pool. However, since tx3 has already been removed in the previous round of voting, it does not need to be removed again this time.

[0154] For node 2, it receives the voting results from node 0 and node 1. Since both node 1 and node 0 determine that transaction tx3 failed verification, and the number of times tx3 failed verification is 2, which is greater than the number of malicious nodes (1), it can be determined that tx3 should be removed from the transaction pool.

[0155] For node 3, it receives the voting results from nodes 0 and 1. Since both nodes 1 and 0 have determined that transaction tx3 failed to be verified, and the number of times tx3 failed to be verified is 2, which is greater than the number of malicious nodes (1), it can be determined that tx3 should be removed from the transaction pool. However, since transaction tx3 has already been removed in the previous transaction, it does not need to be removed.

[0156] Thus, after the second round of voting, all nodes have cleared the abnormal transactions in the transaction pool. After another change of master node, since the new master node will only package the transaction tx4 in the transaction pool, and none of the nodes have verified that the transaction tx4 is abnormal, the third round of voting will reach a consensus.

[0157] Based on the above embodiments, as an optional embodiment, determining the first block consensus failure based on multiple voting results includes:

[0158] If the number of the first voting results among the multiple voting results is greater than the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed.

[0159] This application's embodiments draw on the idea of ​​Byzantine fault tolerance. If the number of votes received by a node that belong to the first vote is greater than the number of malicious nodes in the blockchain, it indicates that at least one honest node has determined that the block is abnormal, and therefore the block consensus has failed.

[0160] As an optional embodiment, if the number of the first voting results is not greater than the number of malicious nodes in the blockchain, and the number of the second voting results is not greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed.

[0161] In other words, if the number of voting results received by the node in this application embodiment is small within a preset time period, such that the number of first voting results is not greater than the number of malicious nodes in the blockchain, and the number of second voting results (used to indicate that there are no failed verification transactions in the first block) is not greater than twice the number of malicious nodes in the blockchain, then the block consensus will also be determined to have failed.

[0162] Based on the above embodiments, as an optional embodiment, after obtaining the voting results within a preset time period, the method further includes:

[0163] If, among multiple voting results, the number of second voting results is greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to be successful, and the transaction corresponding to the transaction identifier in the first block is written into the ledger.

[0164] It should be noted that if the second vote among multiple votes is greater than that of the malicious node, it means that at least all normal nodes have not identified any node that failed to verify in the first block. Therefore, it can be determined that the consensus of the first block was successful, and the next step is to write the transaction corresponding to the transaction identifier in the first block into the ledger.

[0165] Please see Figure 10 The figure illustrates a flowchart of the block consensus method of this application embodiment. As shown in the figure, the block consensus method of this application embodiment includes four stages: proposal stage, pre-voting stage, pre-commit stage, and commit stage.

[0166] During the proposal phase, the leader generates a block and broadcasts it to all the peer nodes in the blockchain system. The diagram shows three peer nodes, namely peer nodes 1 to 3.

[0167] During the prevote phase, each slave node votes on the verification of a block, resulting in two types of votes. The first vote indicates that there are transactions in the first block that failed verification. This first vote includes an identifier indicating verification failure (represented as NilBlockHash in the diagram) and the transaction identifier of the failed transaction in the first block. This allows the node to know which nodes have identified anomalies in the transactions within the block. The second vote indicates that there are no failed verification transactions in the first block. This second vote includes an identifier indicating successful verification (represented as BlockHash in the diagram).

[0168] During the PreCommit phase, each node determines whether the consensus of the first block is successful or not based on the received voting results, and shares the consensus result with other nodes.

[0169] During the commit phase, if all nodes reach a consensus, the transactions in the block are written to the ledger; if no consensus is reached, the preset local transaction pool is cleaned up according to the transaction identifiers of the failed verification transactions included in the first vote result among the multiple voting results.

[0170] Based on the above embodiments, as an optional embodiment, the first block also includes the execution results of the master node for each transaction corresponding to the transaction identifier.

[0171] The first block is verified and voted on, and the voting results are as follows:

[0172] Execute the transaction corresponding to each transaction identifier in the first block. If it is determined that there is a transaction whose execution result is inconsistent with the execution result of the master node, the transaction that failed to be verified is obtained, and the first voting result is obtained.

[0173] If it is determined that there are no transactions whose execution results are inconsistent with those of the master node, then the second voting result is obtained.

[0174] After receiving the first block, the slave node of this application will execute the transactions involved in the first block and obtain the execution result. Then, it will compare the execution result obtained by itself with the execution result obtained by the master node. If they are inconsistent, the transaction verification is determined to have failed; otherwise, if they are consistent, the transaction verification is determined to have succeeded.

[0175] Please see Figure 11 The figure illustrates, exemplarily, the interaction between the master node and slave node in the block consensus process according to an embodiment of this application. As shown in the figure, the interaction process includes:

[0176] The master node packages transactions from its local transaction pool, generates blocks, and broadcasts the blocks to all slave nodes in the blockchain system.

[0177] For any slave node that receives the block pending consensus, all transactions in the block are executed one by one to obtain the execution result of each transaction;

[0178] The slave node compares the execution result obtained by itself with the execution result obtained by the master node to determine whether the two are consistent. If the execution results of all transactions are consistent, a second voting result is generated. The second voting result is used to indicate that all transactions in the block have passed verification. Specifically, it can be represented by the hash value of the block. If the execution results of at least one transaction are inconsistent, a first voting result is generated. The first voting result can include the transaction identifier of the failed verification transaction and an empty hash value.

[0179] When the master node gathers the voting results received from each slave node within a preset time period, it determines whether the block consensus has failed based on the voting results. Specifically, if the number of second voting results is greater than twice the number of malicious nodes in the blockchain, the first block consensus is determined to be successful, and the transaction corresponding to the transaction identifier in the first block is written into the ledger.

[0180] There are two ways to determine if consensus has failed:

[0181] Method 1: If the number of first voting results is greater than the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed.

[0182] Method 2: If the number of first voting results is not greater than the number of malicious nodes in the blockchain, and the number of second voting results is not greater than twice the number of malicious nodes in the blockchain, then the block consensus is determined to have failed.

[0183] When block consensus fails, the number of times each failed transaction appears in all first voting results is determined. Transactions with a number greater than the number of malicious nodes in the blockchain are removed from the transaction pool. Transactions with a number of failures not greater than the number of malicious nodes are left unprocessed. After the transaction pool is cleaned up, the operation of changing the master node is performed.

[0184] For each slave node, it is also necessary to collect the voting results received from each slave node within a preset time period, and determine whether the block consensus has failed based on the voting results. Specifically, if the number of second voting results is more than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to be successful, and the transaction corresponding to the transaction identifier in the first block is written into the ledger.

[0185] There are two ways to determine if consensus has failed:

[0186] Method 1: If the number of first voting results is greater than the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed.

[0187] Method 2: If the number of first voting results is not greater than the number of malicious nodes in the blockchain, and the number of second voting results is not greater than twice the number of malicious nodes in the blockchain, then the block consensus is determined to have failed.

[0188] When block consensus fails, the number of times each failed transaction appears in all first voting results is determined. Transactions with a number greater than the number of malicious nodes in the blockchain are removed from the transaction pool. Transactions with a number of failures not greater than the number of malicious nodes are left unprocessed. After the transaction pool is cleaned up, the operation of changing the master node is performed.

[0189] Figure 12 The figure shows a specific scenario diagram of the blockchain consensus method of this application embodiment. The scenario is a public welfare donation supervision scenario, which includes a user terminal, a public welfare platform server, a blockchain system, and a public welfare supervision platform server.

[0190] The user terminal can communicate with the public welfare platform server through the network. The user terminal in this application embodiment can be the terminal of any public welfare person who wants to make a donation or query donation information.

[0191] This application does not specifically limit the type of public welfare application running on the user terminal. For example, it can be a public welfare application that needs to be downloaded and installed by the user, a cloud-based public welfare application, or a public welfare application in a mini-program. When the public welfare application is running, the user terminal initiates a public welfare project acquisition request to the public welfare platform server through the network. The public welfare platform server returns public welfare projects that can accept donations to the user terminal, so that the user terminal can display the public welfare projects. Public welfare participants can select public welfare projects and initiate donations. After confirming that the donation has been received, the public welfare platform server generates a transaction based on the relevant donation information (such as donor, donation time, donation amount, etc.) and then sends the transaction to some nodes in the blockchain system. Some nodes broadcast the transaction to other nodes in the blockchain system. Each node stores the received transaction in its local transaction pool.

[0192] The nodes on the blockchain need to reach a consensus on donation information. This requires each node to record the time when the consensus is reached. The master node packages its local time and donation information into a block and sends it to each slave node. Each slave node needs to verify whether the master node's packaging time is correct. This application embodiment does not involve how the slave nodes verify the master node's packaging time through a random function, but it needs to be emphasized that this verification action is necessary because the local time itself has a certain degree of randomness. Therefore, this can lead to inconsistent verification results from different nodes.

[0193] For each transaction in a block, the slave node executes it. If it is determined that there is a transaction whose execution result is inconsistent with that of the master node, the transaction that failed verification is obtained, and the first voting result is obtained. The first voting result also includes the transaction identifier of the transaction that failed verification in the first block. If it is determined that there is no transaction whose execution result is inconsistent with that of the master node, the second voting result is obtained.

[0194] Each node broadcasts its own voting results to other nodes in the blockchain system and receives voting results from other nodes. Each node receives multiple voting results within a preset time and determines whether the block consensus succeeds or fails based on the received voting results. Specifically,

[0195] 1) If the number of the first voting results among the multiple voting results is greater than the number of malicious nodes in the blockchain, then the block consensus is determined to have failed;

[0196] 2) If, among the multiple voting results, the number of the first voting results is not greater than the number of malicious nodes in the blockchain, and the number of the second voting results is not greater than twice the number of malicious nodes in the blockchain, then the consensus of the block is determined to have failed.

[0197] 3) If the number of second voting results among the multiple voting results is greater than twice the number of malicious nodes in the blockchain, then the block consensus is determined to be successful;

[0198] If the block consensus fails, the number of times each failed transaction appears in all first voting results is determined. Transactions with a number greater than the number of malicious nodes in the blockchain are removed from the transaction pool, and each node performs the operation of changing the master node.

[0199] If any of the nodes is determined to be the new master node, the transactions in the cleaned transaction pool will be packaged into a second block to be consensused, and the second block will be broadcast to other nodes in the blockchain system for block consensus, and multiple rounds of voting will be conducted until consensus is reached.

[0200] When consensus is reached, each node in the blockchain system writes the transactions involved in the consensus block into the ledger. Furthermore, the consensus block remains on the blockchain, and the blockchain system feeds back the block identifier information of the consensus block to the donation and charity platform, and also feeds back the block identifier information and the transactions (donation information) within the consensus block to the charity supervision platform server for storage.

[0201] The donation platform further sends the block identifier to the user terminal. The user terminal can query the donation information on the blockchain by obtaining the block identifier information. Specifically, the user terminal communicates with the public welfare supervision platform server through the network and sends a verification request to the public welfare supervision platform server. The verification request includes the block identifier. The public welfare supervision platform queries the corresponding donation information based on the block identifier and feeds it back to the terminal for public welfare participants to view.

[0202] Please see Figure 13 The figure illustrates a flowchart of a block synchronization method according to an embodiment of this application. This block synchronization method can be applied to nodes in the above embodiments, including master nodes and slave nodes. As shown in the figure, the method includes:

[0203] S301. Obtain the third block to be synchronized from at least one other node in the blockchain system;

[0204] S302. Verify the third block by not executing the verification of the transactions in the third block;

[0205] S303. If the verification is successful, the transactions in the third block will be synchronized to the local ledger.

[0206] It should be noted that when a node joins or rejoins a blockchain system for the first time, it needs to synchronize the consensus-reached blocks on the blockchain to its local ledger to ensure block consistency. However, for smart contracts with random functions, re-executing transactions can lead to synchronization failures due to inconsistent execution results. Therefore, this application adopts a method of verifying blocks without executing transactions to prevent the node requiring synchronization from failing to obtain a consistent result when other nodes have reached consensus on a block, thus avoiding the problem of being unable to catch up.

[0207] Based on the above embodiments, as an optional embodiment, the verification method for not executing transactions adopted in this application embodiment includes verifying the quorum certificate (QC) or block hash of the third block.

[0208] When a block gains the approval of a majority of nodes in the blockchain system, it can carry a QC certificate. Nodes waiting to synchronize can then determine whether the verification is successful based on whether the block carries a QC certificate. If it does, the QC certificate is verified. If the QC certificate is verified correctly, the verification is successful. If it does not carry a QC certificate, the verification fails.

[0209] Block hashing, which calculates the hash value of the entire block, does not involve the execution of transactions and is therefore not affected by random functions.

[0210] Please see Figure 14 The figure illustrates a flowchart of a block synchronization method according to another embodiment of this application. As shown, the process includes:

[0211] First, the node obtains the blocks to be synchronized from other nodes. In this embodiment of the application, the number of other nodes providing the blocks to be synchronized is not limited; there can be one or more. The node verifies the blocks to be synchronized by verifying QC or verifying the block hash. If the verification is successful, the transactions in the block are synchronized to the local ledger, and the process ends.

[0212] This application provides a block consensus device, applied to any node in a blockchain system, wherein the node is either a master node or a slave node, such as... Figure 15 As shown, the block consensus device may include: a voting result acquisition module 101 and a transaction cleanup module 102, wherein,

[0213] The voting result acquisition module 101 is used to acquire multiple voting results within a preset time period. Each voting result is a verification result generated by a slave node in the blockchain system for a first block to be consensused. The first block includes the transaction identifier of at least one transaction. The voting result is used to indicate whether there is a transaction that failed verification in the first block. When the voting result is a first voting result indicating that there is a transaction that failed verification in the first block, the first voting result also includes the transaction identifier of the transaction that failed verification in the first block.

[0214] The transaction cleanup module 102 is used to clean up the preset local transaction pool if the consensus of the first block is determined to have failed based on multiple voting results, according to the transaction identifier of the failed transaction included in each of the multiple voting results.

[0215] The transaction pool includes the transaction identifiers corresponding to the transactions in the first block.

[0216] The apparatus in this application embodiment can execute the method provided in this application embodiment. The implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0217] As an optional embodiment, the transaction clearing module includes:

[0218] The frequency counting unit is used to determine the number of times each failed verification transaction appears in all the first voting results;

[0219] The transaction clearing unit is used to remove transactions that have failed verification more than the number of malicious nodes in the blockchain from the transaction pool.

[0220] As an optional embodiment, when any of the nodes is a slave node, the block consensus device includes:

[0221] A block receiving module is used to obtain the first block sent by the master node;

[0222] The verification voting module is used to verify the voting on the first block, obtain the voting results, and send the voting results to multiple other nodes in the blockchain system.

[0223] As an optional embodiment, the block consensus device further includes:

[0224] The master node replacement module is used to replace the master node if the consensus of the first block fails based on multiple voting results.

[0225] As an optional embodiment, the block consensus device further includes:

[0226] The block packaging module is used to package the transactions in the cleaned transaction pool into a second block to be reached for consensus if any of the nodes is determined to be the new master node.

[0227] The block broadcasting module is used to broadcast the second block to other nodes in the blockchain system for block consensus.

[0228] As an optional embodiment, the block consensus device includes:

[0229] The block consensus module is configured to determine that the first block consensus has failed if the number of the first voting results among the multiple voting results is greater than the number of malicious nodes in the blockchain; or

[0230] If, among the multiple voting results, the number of the first voting results is not greater than the number of malicious nodes in the blockchain, and the number of the second voting results is not greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed.

[0231] The second voting result is used to indicate that there are no failed verification transactions in the first block.

[0232] As an optional implementation, the block consensus module is also used for:

[0233] If, among the multiple voting results, the number of second voting results is greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to be successful, and the transaction corresponding to the transaction identifier in the first block is written into the ledger.

[0234] As an optional embodiment, the first block also includes the execution results of the master node for each transaction corresponding to the transaction identifier;

[0235] The vote verification module is specifically used for:

[0236] Execute the transaction corresponding to each transaction identifier in the first block. If it is determined that there is a transaction whose execution result is inconsistent with the execution result of the master node, the transaction that failed to be verified is obtained, and the first voting result is obtained.

[0237] If it is determined that there are no transactions whose execution results are inconsistent with those of the master node, then the second voting result is obtained.

[0238] This application provides a block synchronization device, such as... Figure 16 As shown, the block synchronization device is applied to the nodes in the above embodiments. The device may include: a block acquisition module 201, a verification module 202, and a synchronization module 203, wherein...

[0239] The block acquisition module 201 is used to obtain a third block to be synchronized from at least one other node in the blockchain system.

[0240] Verification module 202 is used to verify the third block in a manner that does not execute the verification of transactions in the third block;

[0241] The synchronization module 203 is used to synchronize the transactions in the third block to the local ledger if the verification is successful.

[0242] The block synchronization device of this application embodiment can execute the block synchronization method provided in this application embodiment. The implementation principle is similar. The actions performed by each module in the block synchronization device of each embodiment of this application correspond to the steps in the block synchronization method of each embodiment of this application. For detailed functional descriptions of each module of the device, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0243] Based on the above embodiments, as an optional embodiment, the verification method includes verifying the legal node number certificate or block hash of the third block.

[0244] This application provides an electronic device including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the block consensus method and block synchronization method of the above embodiments. Compared with related technologies, it can achieve the following: by obtaining multiple voting results, each voting result is a verification result generated by a slave node in the blockchain system for a first block to be consensused. The first block includes the transaction identifier of at least one transaction. The voting result is used to indicate whether there are any failed verification transactions in the first block. When the voting result is a first voting result indicating that there are failed verification transactions in the first block, the first voting result also includes the transaction identifier of the failed verification transactions in the first block. If it is determined that the first block consensus has failed based on the multiple voting results, the preset local transaction pool is cleaned up according to the transaction identifier of the failed verification transactions included in each of the multiple voting results. Subsequently, when switching owners, transactions that have generally failed verification will not be repackaged, thereby advancing the consensus progress and improving consensus efficiency.

[0245] In one alternative embodiment, an electronic device is provided, such as Figure 17 As shown, Figure 17 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0246] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0247] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 17 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0248] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0249] The memory 4003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 4001. The processor 4001 executes the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0250] This application provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program can implement the steps and corresponding content of the aforementioned method embodiments. By obtaining multiple voting results, each voting result is a verification result generated by a slave node in the blockchain system for a first block to be consensused. The first block includes transaction identifiers of at least one transaction. The voting results indicate whether there are any failed verification transactions in the first block. When the voting result is a first voting result indicating the presence of failed verification transactions in the first block, the first voting result also includes the transaction identifiers of the failed verification transactions in the first block. If the consensus of the first block fails based on the multiple voting results, a preset local transaction pool is cleaned up according to the transaction identifiers of the failed verification transactions included in each of the multiple voting results. This prevents the repackaging of generally failed verification transactions during subsequent leader changes, thereby advancing the consensus process and improving consensus efficiency.

[0251] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments. By obtaining multiple voting results, each voting result is a verification result generated by a slave node in the blockchain system for a first block to be consensused. The first block includes transaction identifiers of at least one transaction. The voting results are used to indicate whether there are any failed verification transactions in the first block. When the voting result is a first voting result indicating that there are failed verification transactions in the first block, the first voting result also includes the transaction identifiers of the failed verification transactions in the first block. If the consensus of the first block fails based on the multiple voting results, then according to the transaction identifiers of the failed verification transactions included in each of the multiple voting results, a preset local transaction pool is cleaned up. This prevents the repackaging of generally failed verification transactions during subsequent leader changes, thereby advancing the consensus process and improving consensus efficiency.

[0252] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0253] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0254] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A block consensus method, characterized in that, The method, applied to any node in a blockchain system, wherein the node is a master node or a slave node, includes: Multiple voting results are obtained within a preset time period. Each voting result is a verification result generated by a slave node in the blockchain system for the first block to be consensused. The first block includes the transaction identifier of at least one transaction. The voting result is used to indicate whether there is a transaction that failed to be verified in the first block. When the voting result is a first voting result indicating that there is a transaction that failed to be verified in the first block, the first voting result also includes the transaction identifier of the transaction that failed to be verified in the first block. If the consensus of the first block fails based on multiple voting results, the preset local transaction pool is cleaned up according to the transaction identifier of the failed transaction included in each of the multiple voting results. The transaction pool includes transactions corresponding to the transaction identifiers in the first block; The step of cleaning up the preset local transaction pool based on the failed verification transactions included in each of the multiple voting results includes: Determine the number of times each failed verification transaction appears in all first-vote results; Transactions that fail verification more times than the number of malicious nodes in the blockchain are removed from the transaction pool.

2. The method according to claim 1, characterized in that, When any of the nodes is a slave node, the method further includes: Obtain the first block sent by the master node; The first block is verified and voted on to obtain the voting results, which are then sent to multiple other nodes in the blockchain system.

3. The method according to claim 1, characterized in that, If the consensus of the first block fails based on multiple voting results, the following steps are also included: Perform the operation to replace the master node.

4. The method according to claim 3, characterized in that, When any of the nodes is a slave node, the operation of changing the master node further includes: If any of the nodes is determined to be the new master node, the transactions in the cleaned transaction pool will be packaged into a second block awaiting consensus. The second block is broadcast to other nodes in the blockchain system to achieve block consensus.

5. The method according to claim 1, characterized in that, The determination that the first block consensus failed based on multiple voting results includes: If the number of the first voting results among the multiple voting results is greater than the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed; or If, among the multiple voting results, the number of the first voting results is not greater than the number of malicious nodes in the blockchain, and the number of the second voting results is not greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to have failed. The second voting result is used to indicate that there are no failed verification transactions in the first block.

6. The method according to claim 1, characterized in that, After obtaining the voting results within a preset time period, the process further includes: If the number of second voting results among the multiple voting results is greater than twice the number of malicious nodes in the blockchain, then the consensus of the first block is determined to be successful, and the transaction corresponding to the transaction identifier in the first block is written into the ledger. The second voting result is used to indicate that there are no failed verification transactions in the first block.

7. The method according to claim 2, characterized in that, The first block also includes the execution results of the master node for each transaction corresponding to the transaction identifier; The verification voting on the first block to obtain the voting result includes: Execute the transaction corresponding to each transaction identifier in the first block. If it is determined that there is a transaction whose execution result is inconsistent with the execution result of the master node, the transaction that failed to be verified is obtained, and the first voting result is obtained. If it is determined that there are no transactions whose execution results are inconsistent with those of the master node, then the second voting result is obtained.

8. A block synchronization method, characterized in that, Applied to a node performing the method as described in any one of claims 1-7, the method comprising: Obtain the third block to be synchronized from at least one other node in the blockchain system; The third block is verified by not executing the verification of the transactions in the third block; If the verification passes, the transactions in the third block will be synchronized to the local ledger.

9. The method according to claim 8, characterized in that, The verification method includes verifying the legal node number certificate or block hash of the third block.

10. A block consensus device, characterized in that, The device is applied to any node in a blockchain system, wherein the node is a master node or a slave node, and the device includes: The voting result acquisition module is used to obtain multiple voting results within a preset time period. Each voting result is a verification result generated by a slave node in the blockchain system for a first block to be consensused. The first block includes the transaction identifier of at least one transaction. The voting result is used to indicate whether there is a transaction that failed verification in the first block. When the voting result is a first voting result indicating that there is a transaction that failed verification in the first block, the first voting result also includes the transaction identifier of the transaction that failed verification in the first block. The transaction cleanup module is used to clean up a preset local transaction pool if the consensus of the first block fails based on multiple voting results, according to the transaction identifier of the failed transaction included in each of the multiple voting results. The transaction pool includes transactions corresponding to the transaction identifiers in the first block; The transaction cleanup module cleans up a preset local transaction pool based on the failed verification transactions included in each of the multiple voting results, including: Determine the number of times each failed verification transaction appears in all first-vote results; Transactions that fail verification more times than the number of malicious nodes in the blockchain are removed from the transaction pool.

11. A block synchronization device, characterized in that, The apparatus, applied to a node performing the method as described in any one of claims 1-7, comprises: The block acquisition module is used to obtain a third block to be synchronized from at least one other node in the blockchain system. The verification module is used to verify the third block in a manner that does not execute the verification of transactions in the third block; The synchronization module is used to synchronize the transactions in the third block to the local ledger if the verification passes.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-9.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-9.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-9.

Images