Data processing method and device of block chain network, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a data processing method and device of a block chain network, electronic equipment and a storage medium, and the method comprises the steps that a first consensus node obtains votes of each consensus node for a target block, and the votes are transaction execution results of a plurality of transactions contained in the target block after the transaction execution results are verified; generating according to the verification result; if the consensus of the target block is determined to be failed according to the obtained votes, screening out opposite votes from the obtained votes, and calculating the number of consensus nodes which fail to verify the candidate transactions according to the screened opposite votes, the opposite votes being generated according to the candidate transactions which fail to verify; and if it is determined that the candidate transactions are to-be-deleted target transactions according to the number of the consensus nodes, deleting the locally stored target transactions, sending an anti-pairing message to the second consensus node, and deleting the locally stored target transactions by the second consensus node according to the anti-pairing message. According to the technical scheme, resources can be saved, and the block output efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and specifically, to a data processing method and device, electronic device, storage medium, and program product of a blockchain network. Background Art

[0002] With the development of blockchain technology, blockchain technology has been applied to more and more fields. The blockchain system is a distributed system, and the consensus mechanism is the basis for ensuring the normal operation of the blockchain system.

[0003] In the related art, after executing multiple transactions and generating a block based on the transaction execution results of the multiple transactions, if the consensus of the block fails, the multiple transactions included in the block are usually added back to the transaction pool, so that the multiple transactions included in the block are re-executed, the transaction execution results are packaged into the block and consensus is reached, so that the transactions are repeatedly executed and consensus is reached, which not only wastes resources but also affects the efficiency of block generation. Summary of the invention

[0004] The embodiments of the present application provide a data processing method and device, electronic device, storage medium, and program product for a blockchain network, which can save resources and improve block production efficiency.

[0005] According to one aspect of an embodiment of the present application, a data processing method of a blockchain network is provided, wherein the blockchain network includes a first consensus node and a second consensus node, and the method is executed by the first consensus node, and the method includes:

[0006] Obtaining votes of each consensus node on the target block for consensus; the votes are generated according to the verification results after verifying the transaction execution results of multiple transactions included in the target block respectively;

[0007] If it is determined that the consensus of the target block fails based on the obtained votes, then a negative vote is screened out from the obtained votes; the negative vote is generated based on the candidate transaction that failed verification;

[0008] Based on the screened negative votes, calculate the number of consensus nodes that failed to verify the candidate transaction;

[0009] If the candidate transaction is determined to be a target transaction to be deleted based on the number of consensus nodes, the locally stored target transaction is deleted, and an objection message instructing the second consensus node to delete the target transaction is sent.

[0010] According to one aspect of the embodiments of the present application, a data processing method for a blockchain network is provided.

[0011] The blockchain network includes a first consensus node and a second consensus node, and the method is performed by the second consensus node, and the method includes:

[0012] Receive a proposal message of a target block to be agreed upon, and verify multiple transaction execution results contained in the target block according to the proposal message;

[0013] Generate a negative vote for the target block based on the candidate transaction that failed verification;

[0014] Sending the negative vote to the first consensus node, so that after the first consensus node determines that the consensus of the target block fails according to the vote of the target block, the first consensus node calculates the number of consensus nodes that fail to verify the candidate transaction according to the negative vote, and if the candidate transaction is determined to be the target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted, and a negative message is generated;

[0015] Receive the objection message sent by the first consensus node, and delete the locally stored target transaction according to the objection message.

[0016] According to one aspect of an embodiment of the present application, a data processing device of a blockchain network is provided, wherein the blockchain network includes a first consensus node and a second consensus node, and the device is configured at the first consensus node, and the device includes:

[0017] An acquisition module is configured to acquire votes of each consensus node on the target block for consensus; the votes are generated according to the verification results after the transaction execution results of multiple transactions included in the target block are verified respectively;

[0018] A screening module, configured to screen out opposing votes from the obtained votes if it is determined that the consensus of the target block fails according to the obtained votes; the opposing votes are generated according to the candidate transactions that failed verification;

[0019] A calculation module, configured to calculate the number of consensus nodes that failed to verify the candidate transaction based on the screened negative votes;

[0020] The deletion module is configured to delete the locally stored target transaction if the candidate transaction is determined to be a target transaction to be deleted based on the number of consensus nodes, and send an objection message to the second consensus node indicating the deletion of the target transaction.

[0021] In an exemplary embodiment, based on the aforementioned scheme, the device also includes a determination module, configured to: if the number of consensus nodes is greater than or equal to a first quantity threshold, determine that the candidate transaction is a target transaction; wherein the first quantity threshold is positively correlated with the total number of consensus nodes included in the blockchain network.

[0022] In an exemplary embodiment, based on the aforementioned scheme, the determination module is specifically configured to: search for the target smart contract used to execute the candidate transaction, and obtain the first quantity threshold corresponding to the target smart contract; wherein the first quantity threshold corresponding to different smart contracts is different; if the number of consensus nodes is greater than or equal to the first quantity threshold corresponding to the target smart contract, the candidate transaction is determined to be the target transaction.

[0023] In an exemplary embodiment, based on the aforementioned scheme, the device also includes a threshold calculation module, configured to: find the number of historical target transactions corresponding to the target smart contract; calculate the first quantity threshold corresponding to the target smart contract based on the number of historical target transactions; wherein the first quantity threshold corresponding to the target smart contract is negatively correlated with the number of historical target transactions.

[0024] In an exemplary embodiment, based on the aforementioned scheme, the screening module is specifically configured to: calculate the number of screened out dissenting votes; if the calculated number of dissenting votes is greater than or equal to a second quantity threshold, calculate the number of consensus nodes that failed to verify the candidate transaction; wherein the second quantity threshold is greater than or equal to the first quantity threshold.

[0025] In an exemplary embodiment, based on the aforementioned scheme, the deletion module is specifically configured as follows: generating the objection message according to the target transaction, and extracting multiple transactions from a transaction pool for storing transactions to be executed; executing the extracted multiple transactions respectively, and generating a block to be chained whose block height matches the block height of the target block according to the transaction execution results obtained and the previous block of the target block; generating a proposal message for the block to be chained, and adding the objection message to the proposal message of the block to be chained; sending the proposal message of the block to be chained to the second consensus node, so that the second consensus node deletes the locally stored target transaction according to the objection message contained in the proposal message of the block to be chained.

[0026] In an exemplary embodiment, based on the aforementioned scheme, under the condition that the voting includes an approval vote generated after the consensus node successfully verifies the transaction execution results of multiple transactions included in the target block, the device also includes a sending module, configured to: if the number of approval votes in the acquired voting is greater than or equal to a third quantity threshold, then generate an approval message for the target block according to the approval vote, and extract multiple transactions from the transaction pool; execute the extracted multiple transactions respectively, and generate the next block of the target block according to the transaction execution results obtained and the target block; generate a proposal message for the next block, and add the approval message to the proposal message of the next block; send the proposal message of the next block to the second consensus node, so that the second consensus node determines that the consensus of the target block is successful based on the approval message contained in the proposal message of the next block, and then adds the target block to the blockchain.

[0027] In an exemplary embodiment, based on the aforementioned scheme, the device also includes an adding module, configured to: receive proposal messages of other blocks except the target block, and obtain approval messages of associated blocks from the proposal messages of the other blocks; wherein the block height of the associated block is greater than the block height of the target block, and the approval vote of the associated block is generated after the transaction execution results of multiple transactions contained in the associated block are successfully verified, and the approval message of the previous block of the associated block is successfully verified; if approval messages corresponding to a set number of associated blocks are obtained, and the block heights of the set number of associated blocks and the target block are continuous, it is determined that the consensus of the target block is successful, and the target block is added to the blockchain.

[0028] In an exemplary embodiment, based on the aforementioned scheme, the acquisition module is specifically configured to: receive a proposal message of the target block, and verify the transaction execution results of multiple transactions included in the target block according to the proposal message; generate a vote for the target block according to the verification result obtained by the verification, and determine the target time period according to the generation time; receive the vote for the target block sent by the second consensus node within the target time period.

[0029] According to one aspect of an embodiment of the present application, a data processing device of a blockchain network is provided, wherein the blockchain network includes a first consensus node and a second consensus node, and the device is configured at the second consensus node, and the device includes:

[0030] A verification module, configured to receive a proposal message of a target block to be agreed upon, and to verify the multiple transaction execution results contained in the target block respectively according to the proposal message;

[0031] A generation module, configured to generate a negative vote for the target block based on the candidate transaction that failed verification;

[0032] a sending module configured to send the objection vote to the first consensus node, so that after the first consensus node determines that the consensus of the target block fails according to the vote of the target block, the first consensus node calculates the number of consensus nodes that fail to verify the candidate transaction according to the objection vote, and if the candidate transaction is determined to be a target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted, and an objection message is generated;

[0033] A deletion module is configured to receive the objection message sent by the first consensus node and delete the locally stored target transaction according to the objection message.

[0034] In an exemplary embodiment, based on the aforementioned scheme, the device also includes an adding module, configured to: if any block is added to the blockchain, obtain the block height of the any block; if the block height of the any block is greater than or equal to the block height of the target block, add other transactions among the multiple transactions except the target transaction to the set of transactions to be agreed upon.

[0035] In an exemplary embodiment, based on the aforementioned scheme, the verification module is specifically configured to: execute each of the multiple transactions according to the proposal message; compare the transaction execution result of each transaction obtained by execution with the transaction execution result of each transaction contained in the target block; if the transaction execution result of each transaction obtained by execution does not match the transaction execution result of each transaction contained in the target block, it is determined that the verification of each transaction has failed.

[0036] According to one aspect of an embodiment of the present application, there is provided an electronic device, including:

[0037] one or more processors;

[0038] The storage device is used to store one or more computer programs, and when the one or more computer programs are executed by the one or more processors, the electronic device implements the method as described above.

[0039] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor of an electronic device, the electronic device implements the method as described above.

[0040] According to one aspect of an embodiment of the present application, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the method as described above is implemented.

[0041] In the technical solution provided in the embodiments of the present application, the blockchain network includes a first consensus node and a second consensus node. The first consensus node can obtain the votes of each consensus node on the target block to be agreed upon, wherein the votes are generated according to the verification results after the transaction execution results of multiple transactions included in the target block are verified respectively; if it is determined that the consensus of the target block fails according to the obtained votes, the opposing votes are screened out from the obtained votes, and the number of consensus nodes that failed to verify the candidate transaction is calculated according to the screened opposing votes, wherein the opposing votes are generated based on the candidate transactions that failed to be verified; if the candidate transaction is determined to be a target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted, and an opposing message instructing the deletion of the target transaction is sent to the second consensus node, so that the second consensus node deletes the locally stored target transaction according to the opposing message, so that transactions that cannot reach a consensus can be deleted in time, avoiding the situation where transactions are repeatedly executed and consensus is reached, thereby saving resources and improving block production efficiency.

[0042] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 is a schematic diagram of an implementation environment shown in an exemplary embodiment of the present application;

[0044] Figure 2 is a flowchart of a data processing method of a blockchain network shown in an exemplary embodiment of the present application;

[0045] Figure 3 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0046] Figure 4 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0047] Figure 5 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0048] Figure 6 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0049] Figure 7 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0050] Figure 8is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0051] Fig. 9 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0052] Fig.10 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0053] Fig.11 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0054] Fig.12 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0055] Fig.13 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application;

[0056] Fig.14 is a processing flow chart of a slave node shown in an exemplary embodiment of the present application;

[0057] Fig.15 is another exemplary embodiment of the present application showing a processing flow chart of a slave node;

[0058] Fig.16 is a flowchart of processing a proposal message according to another exemplary embodiment of the present application;

[0059] Fig.17 It is a structural schematic diagram of a data processing device of a blockchain network shown in an exemplary embodiment of the present application;

[0060] Fig.18 is a schematic diagram of the structure of a data processing device of a blockchain network shown in another exemplary embodiment of the present application;

[0061] Fig.19 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0062] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0063] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0064] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0065] It should also be noted that the "multiple" mentioned in this application refers to two or more than two. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship.

[0066] The technical solution of the embodiment of the present application relates to the field of blockchain technology. Before introducing the technical solution of the embodiment of the present application, a brief introduction to blockchain technology is first given.

[0067] Blockchain technology is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0068] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational detection. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and the maintenance of the correspondence between the user's real identity and the blockchain address (authority management), etc., and, under authorization, supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. The operation detection module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarm, network status detection, node equipment health status detection, etc.

[0069] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0070] The technical solution of the embodiment of the present application specifically relates to blockchain technology. The technical solution of the embodiment of the present application is described in detail below:

[0071] In the related art, after executing multiple transactions and generating a block based on the transaction execution results of multiple transactions, if the consensus of the block fails, the multiple transactions contained in the block are usually added back to the transaction pool to re-execute the multiple transactions contained in the block, package the transaction execution results into the block and reach a consensus, so that some transactions that cannot reach a consensus (for example, transactions that use random numbers during execution) are repeatedly executed and consensus is reached, which not only wastes resources, but also affects the efficiency of block generation. Based on this, the embodiments of the present application provide a data processing method and device, electronic device, storage medium, and program product for a blockchain network, which can save resources, improve block generation efficiency, and reduce transaction costs.

[0072] See also Figure 1 , Figure 1It is a schematic diagram of an implementation environment involved in the present application, which includes a client 110 and a blockchain network 120. The blockchain network includes multiple consensus nodes, and the multiple consensus nodes can transmit data based on a point-to-point protocol (or other communication protocols); wherein the client 110 can be deployed in a terminal device or a server, and the consensus node can also be deployed in a terminal device or a server. The terminal device can include but is not limited to a smart phone, a tablet, a laptop, a computer, an intelligent voice interaction device, a smart home appliance, a vehicle terminal, an aircraft, a remote driving terminal, etc.; the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network) and big data and artificial intelligence platforms. The specific forms of terminal devices and servers are not limited here.

[0073] Based on the status of the consensus node, the consensus node can be divided into a first consensus node 121 and multiple second consensus nodes 122. The client can initiate a transaction to the blockchain network. The consensus node can generate a target block to be agreed upon based on the transaction execution results of multiple transactions. After each consensus node obtains the proposal message of the target block, it can verify the multiple transaction execution results contained in the target block according to the proposal message, and generate a vote for the target block according to the verification result. The first consensus node 121 can obtain the votes of each consensus node on the target block. If it is determined that the consensus of the target block fails according to the obtained votes, the opposing votes are screened out from the obtained votes, wherein the opposing votes are generated according to the candidate transactions that failed to be verified; then, according to the screened opposing votes, the number of consensus nodes that failed to verify the candidate transactions is calculated. If the candidate transaction is determined to be a target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted, and an opposing message indicating the deletion of the target transaction is sent to the second consensus node corresponding to the first consensus node, so that the second consensus node deletes the locally stored target transaction, so that the transactions that cannot reach a consensus can be deleted in time, avoiding the situation where the transaction is repeatedly executed and consensus is reached, thereby saving resources and improving the efficiency of block generation.

[0074] It should be noted that this application involves transactions, transaction execution results and other user-related data. When the methods of this application are applied to specific products or technologies, the user's permission or consent must be obtained, and the extraction, use and processing of relevant data must comply with local security standards and local laws and regulations.

[0075] See also Figure 2 , Figure 2This is a flowchart of a data processing method for a blockchain network shown in an exemplary embodiment of the present application. This method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown is executed. It should be noted that the blockchain network contains multiple consensus nodes. Based on the status of the consensus nodes, the consensus nodes are divided into the first consensus node and the second consensus node. The first consensus node and the second consensus node are only used to indicate the status of the consensus node. The status of the consensus node can change when the view changes. For example, in a certain view, consensus node A is the first consensus node, and in the next view, consensus node A is not the first consensus node. Among them, the view is the basic unit of consensus. A view can reach a consensus at most once, and it is monotonically increasing. Each view gradually rotates to promote consensus.

[0076] like Figure 2 As shown, in an exemplary embodiment, the data processing method of the blockchain network may include steps S210-S240, which are described in detail as follows:

[0077] Step S210, obtaining the votes of each consensus node on the target block to be consensused; the votes are generated according to the verification results after the transaction execution results of multiple transactions included in the target block are verified respectively.

[0078] First of all, it should be noted that the target block refers to any block that needs to be put on the chain through consensus. The target block contains the transaction execution results of multiple transactions, and the transaction execution results may include the read-write set (i.e., read-write data) during the transaction execution process. Optionally, the target block may also contain multiple transactions. The proposal message of the target block is used to initiate a vote for the target block, which includes the target block.

[0079] The proposal node in the blockchain network can generate a target block and a proposal message of the target block, and broadcast the proposal message of the target block in the blockchain network so that each consensus node can obtain the proposal message of the target block. Among them, the proposal node is a consensus node in the blockchain network. In the process of generating the target block, the proposal node can extract multiple transactions from the set of transactions to be agreed upon, and execute multiple transactions respectively, obtain the transaction execution results corresponding to the multiple transactions, and package the transaction execution results of the multiple transactions into blocks, thereby obtaining the target block. It should be noted that each consensus node contains a set of transactions to be agreed upon, and the set of transactions to be agreed upon can be stored in a transaction pool. Among them, the proposal node for generating the target block and the first consensus node can be the same node, or the first consensus node can be a proposal node for generating the next block to be identified corresponding to the target block.

[0080] After obtaining the proposal message of the target block, each consensus node (including the first consensus node and the second consensus node) in the blockchain network can verify the multiple transaction execution results contained in the target block according to the proposal message, and generate a vote for the target block according to the verification result, wherein the types of votes include approval votes and disapproval votes. Optionally, if the verification result indicates that there are candidate transactions that fail to be verified among multiple transactions, a disapproval vote can be generated based on the candidate transaction, and if the verification result indicates that multiple transactions are successfully verified, a approval vote can be generated. Each vote may include at least one of the identification information of the consensus node that generates the vote, the signature data of the consensus node, and the identification information of the block corresponding to the vote, so that the first consensus node determines the consensus node that generates the vote and the block corresponding to the vote according to the vote. The signature data of the consensus node can be generated based on the private key of the consensus node.

[0081] The first consensus node can obtain the votes of each consensus node in the blockchain network for the target block, and the acquisition methods include but are not limited to the following two: the first consensus node receives the vote of the target block sent by the second consensus node; the second is that the first consensus node also receives the proposal message of the target block, verifies the multiple transaction execution results included in the target block according to the proposal message, and generates the vote of the target block according to the verification results. That is to say, the first consensus node can obtain the vote of the target block generated by itself.

[0082] Step S220: If it is determined that the consensus of the target block fails based on the obtained votes, the opposing votes are screened out from the obtained votes; the opposing votes are generated based on the candidate transactions that failed verification.

[0083] Candidate transactions are transactions that have failed verification.

[0084] After obtaining the votes for the target block, the first consensus node can determine whether each consensus node has failed to reach a consensus on the target block based on the obtained votes. If so, the first consensus node can filter out the opposing votes from the obtained votes.

[0085] Among them, the specific method of determining whether the consensus of the target block has failed can be flexibly set according to actual needs. Optionally, the consensus failure of the target block can be determined under the condition that the number of obtained approval votes is small (for example, the number of obtained approval votes is less than the subsequent third quantity threshold); or, the consensus failure of the target block can be determined under the condition that the number of obtained disapproval votes is large (for example, the number of obtained disapproval votes is greater than or equal to the subsequent second quantity threshold, or greater than or equal to the difference between the total number of consensus nodes included in the blockchain network and the third quantity threshold).

[0086] Optionally, if each vote contains identification information and signature data of the consensus node that generated the vote, the first consensus node can verify the signature data contained in each acquired vote, and determine whether the consensus of the target block has failed based on the successfully verified votes, wherein, if the signature data of the consensus node is generated based on the private key of the consensus node, the signature data of the consensus node can be verified based on the public key of the consensus node.

[0087] Step S230, based on the screened negative votes, calculate the number of consensus nodes that failed to verify the candidate transaction.

[0088] The negative vote of the target block is generated according to the candidate transactions that failed to be verified after the consensus node verifies the transaction execution results of multiple transactions contained in the target block. Therefore, the first consensus node can determine the candidate transaction based on the screened negative votes and calculate the number of consensus nodes that failed to verify the candidate transaction. Among them, the consensus node that failed to verify the candidate transaction means that the consensus node failed to verify the candidate transaction during the process of verifying the transaction execution results of multiple transactions contained in the target block. For example, assuming that consensus node 1 fails to verify transactions 1 and 2, consensus node 2 fails to verify transactions 2 and 3, and consensus node 3 fails to verify transactions 2 and 6, then after obtaining the negative votes of consensus nodes 1-3, transactions 1, 2, 3, and 6 are determined as candidate transactions, the number of consensus nodes that failed to verify transaction 1 is 1, the number of consensus nodes that failed to verify transaction 2 is 3, the number of consensus nodes that failed to verify transaction 3 is 1, and the number of consensus nodes that failed to verify transaction 6 is 1.

[0089] S240: If the candidate transaction is determined to be the target transaction to be deleted based on the number of consensus nodes, the locally stored target transaction is deleted, and an objection message instructing the second consensus node to delete the target transaction is sent.

[0090] The target transaction is the transaction that needs to be deleted.

[0091] The first consensus node can determine whether the candidate transaction is the target transaction based on the number of consensus nodes corresponding to each candidate transaction. If the candidate transaction is the target transaction, the first consensus node can delete the locally stored target transaction and send an objection message to the second consensus node, so that the second consensus node deletes the locally stored target transaction after receiving the objection message. Optionally, the first consensus node can broadcast the objection message in the blockchain network to send the objection message to the second consensus node. The objection message contains the identification information of the target transaction. Optionally, the objection message can also contain the signature data of the consensus node corresponding to the objection vote. After the second consensus node successfully verifies the signature data contained in the objection message, it deletes the locally stored target transaction. Optionally, the objection message can be an objection certificate (RejectQc) generated based on the objection vote and the target transaction.

[0092] Among them, considering that the larger the number of consensus nodes that fail to verify the transaction, the higher the probability that the transaction is a transaction that cannot be successfully agreed upon, the probability that the candidate transaction is the target transaction may be positively correlated with the number of consensus nodes corresponding to the candidate transaction. That is to say, the larger the number of consensus nodes corresponding to the candidate transaction, the higher the probability that the candidate transaction is the target transaction.

[0093] The target transaction stored locally at the consensus node refers to the target transaction contained in the consensus node, including but not limited to the target transaction in the target block contained in the consensus node, the target transaction in the storage area for storing transactions such as the transaction pool, etc.

[0094] exist Figure 2 In the illustrated embodiment, the first consensus node may obtain votes of each consensus node on the target block to be consensused, wherein the votes are generated based on the verification results after the transaction execution results of multiple transactions included in the target block are verified respectively; if it is determined that the consensus of the target block has failed based on the obtained votes, then the opposing votes are screened out from the obtained votes, and the number of consensus nodes that failed to verify the candidate transaction is calculated based on the screened opposing votes, wherein the opposing votes are generated based on the candidate transactions that failed to be verified; if the candidate transaction is determined to be a target transaction to be deleted based on the number of consensus nodes, then the locally stored target transaction is deleted, and an opposing message instructing the deletion of the target transaction is sent to the second consensus node, so that the second consensus node deletes the locally stored target transaction based on the opposing message, so that transactions that cannot reach consensus can be deleted in a timely manner, thereby avoiding the situation where transactions are repeatedly executed and consensus is reached, thereby saving resources and improving block production efficiency.

[0095] In an exemplary embodiment, see Figure 3 , Figure 3 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown executes.

[0096] like Figure 3 As shown, the method includes steps S210 to S230, step S310, and step S240, wherein step S310 is described in detail as follows:

[0097] Step S310: If the number of consensus nodes is greater than or equal to a first quantity threshold, the candidate transaction is determined to be a target transaction; wherein the first quantity threshold is positively correlated with the total number of consensus nodes included in the blockchain network.

[0098] The first quantity threshold is used to determine whether a candidate transaction is a target transaction. If the number of consensus nodes corresponding to the candidate transaction is greater than or equal to the first quantity threshold, the candidate transaction is determined to be a target transaction. For example, assuming that the candidate transactions include transactions 1, 2, and 3, and the corresponding numbers of consensus nodes are 10, 15, and 20, respectively, if the first quantity threshold is 13, then transactions 2 and 3 are target transactions.

[0099] Among them, the first quantity threshold is positively correlated with the total number of consensus nodes included in the blockchain network, that is, the higher the total number of consensus nodes included in the blockchain network, the larger the first quantity threshold, and the first quantity threshold is less than or equal to the total number of consensus nodes. In order to avoid deleting transactions that can reach consensus, the first quantity threshold is greater than the fault tolerance rate corresponding to the consensus algorithm and the total number of consensus nodes included in the blockchain network. For example, if the fault tolerance rate of the consensus algorithm is 33% and the total number of consensus nodes is 3f+1, then the first quantity threshold needs to be greater than f, that is, the first quantity threshold is at least f+1. Among them, the specific value of the first quantity threshold can be flexibly set according to actual needs. For example, in an optional example, it can be 20%, 30%, 50% of the total number of consensus nodes, etc. In another optional example, considering that different transaction types implement different functions, the probability that the corresponding transactions are transactions that cannot reach a consensus is different. Therefore, different first quantity thresholds can be set for different transaction types. If the number of consensus nodes corresponding to the candidate transaction is greater than or equal to the first quantity threshold corresponding to the transaction type to which the candidate transaction belongs, the candidate transaction is determined to be the target transaction; wherein the transaction type and the first quantity threshold corresponding to the transaction type can be pre-set. For example, the first quantity threshold corresponding to the transaction type can be determined according to whether the transaction corresponding to the transaction type adopts a random number or a parameter that changes in real time (for example, system time) during the execution process. Since different consensus nodes execute transactions at different times, the generated random numbers are different. Therefore, if the transaction corresponding to the transaction type adopts a random number or a parameter that changes in real time during the execution process, the probability that the transaction is a transaction that cannot reach a consensus is high, and the corresponding first quantity threshold can be relatively low, thereby improving the consensus efficiency. For another example, the first quantity threshold corresponding to the transaction type can be negatively correlated with the number of historical target transactions corresponding to the transaction type (that is, transactions used as target transactions in the historical consensus process), that is, the higher the number of historical target transactions corresponding to the transaction type, the lower the first quantity threshold corresponding to the transaction type. In another optional example, considering that the greater the number of transactions to be agreed upon, the greater the processing pressure on the consensus node, the greater the need to improve block production efficiency, therefore, the first quantity threshold can be dynamically updated according to the number of transactions to be agreed upon contained in the consensus node, wherein the first quantity threshold is negatively correlated with the number of transactions to be agreed upon.

[0100] Optionally, after determining that the number of consensus nodes corresponding to the candidate transaction is greater than or equal to the first number threshold, the number of consensus failures corresponding to the candidate transaction can also be obtained. If the number of consensus failures is greater than or equal to the number threshold, the candidate transaction is determined to be the target transaction; if the number of consensus failures is less than the number threshold, the candidate transaction is determined not to be the target transaction, thereby improving the judgment accuracy. The number threshold can be set to 2, 3, etc.

[0101] It should be noted that Figure 3 The specific implementation details of steps S210 to S240 shown in FIG. Figure 2 Steps S210 to S240 shown are not repeated here.

[0102] exist Figure 3 In the illustrated embodiment, if the number of consensus nodes is greater than or equal to a first quantity threshold, the candidate transaction is determined to be a target transaction, and the first quantity threshold is positively correlated with the total number of consensus nodes included in the blockchain network, so that transactions that cannot reach consensus can be more accurately found and deleted.

[0103] In an exemplary embodiment, see Figure 4 , Figure 4 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown executes.

[0104] like Figure 4 As shown, the method includes steps S210 to S230, steps S410 to S420, and step S240, wherein steps S410 to S420 are described in detail as follows:

[0105] Step S410, searching for a target smart contract for executing the candidate transaction, and obtaining a first quantity threshold corresponding to the target smart contract; wherein different smart contracts correspond to different first quantity thresholds.

[0106] In this embodiment, taking into account that different smart contracts execute different transactions and have different requirements, different first quantity thresholds are set for different smart contracts. Therefore, after determining the candidate transaction, the first consensus node can search for the target smart contract corresponding to the candidate transaction and obtain the first quantity threshold corresponding to the target smart contract.

[0107] Among them, the specific setting method of the first quantity threshold corresponding to the smart contract can be flexibly set according to actual needs. In an optional example, the first quantity threshold corresponding to the smart contract can be determined according to whether random numbers or real-time changing parameters are used in the process of executing transactions by the smart contract. If random numbers or real-time changing parameters are used in the process of executing transactions by the smart contract, the corresponding first quantity threshold is lower; if no random numbers or real-time changing parameters are used in the process of executing transactions by the smart contract, the corresponding first quantity threshold is higher.

[0108] Step S420: If the number of consensus nodes is greater than or equal to the first quantity threshold corresponding to the target smart contract, the candidate transaction is determined to be the target transaction.

[0109] If the number of consensus nodes corresponding to the candidate transaction is greater than or equal to the first quantity threshold corresponding to the target smart contract used to execute the candidate transaction, the candidate transaction is determined to be the target transaction.

[0110] It should be noted that Figure 4 The specific implementation details of steps S210 to S240 can be referred to Figure 2 Steps S210 to S240 shown are not repeated here.

[0111] exist Figure 4 In the illustrated embodiment, different first quantity thresholds are set for different smart contracts. A candidate transaction is determined to be a target transaction only when the number of consensus nodes corresponding to the candidate transaction is greater than or equal to the first quantity threshold corresponding to the target smart contract used to execute the candidate transaction, thereby improving the accuracy of judgment.

[0112] In an exemplary embodiment, see Figure 5 , Figure 5 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown executes.

[0113] like Figure 5 As shown, the method includes steps S510-step S520, steps S210-step S230, steps S410-step S420, and step S240, wherein steps S510-step S520 are described in detail as follows:

[0114] Step S510, find the number of historical target transactions corresponding to the target smart contract.

[0115] The historical target transaction corresponding to the target smart contract refers to the transaction that serves as the target transaction in the historical transactions corresponding to the target smart contract.

[0116] The number of historical target transactions corresponding to the target smart contract can represent the probability of whether the transaction corresponding to the target smart contract is a transaction that cannot reach a consensus. Therefore, the number of historical target transactions corresponding to the target smart contract can be counted.

[0117] Step S520, calculating a first quantity threshold corresponding to the target smart contract based on the number of historical target transactions; wherein the first quantity threshold corresponding to the target smart contract is negatively correlated with the number of historical target transactions.

[0118] The higher the number of historical target transactions corresponding to the target smart contract, the higher the probability that the transaction corresponding to the target smart contract is a transaction on which consensus cannot be reached. Therefore, the first quantity threshold corresponding to the target smart contract can be relatively low; the lower the number of historical target transactions corresponding to the target smart contract, the lower the probability that the transaction corresponding to the target smart contract is a transaction on which consensus cannot be reached. Therefore, the first quantity threshold corresponding to the target smart contract can be relatively high.

[0119] It should be noted that Figure 5 The specific implementation details of steps S210 to S240 shown in FIG. Figure 2 Steps S210 to S240 are shown. Figure 5 The specific implementation details of steps S410 to S420 shown in FIG. Figure 4 Steps S410 to S420 shown are not repeated here.

[0120] exist Figure 5 In the illustrated embodiment, the first quantity threshold corresponding to the target smart contract is calculated based on the number of historical target transactions corresponding to the target smart contract, so that the first quantity threshold is reasonably set, which can improve the judgment accuracy and consensus efficiency.

[0121] In an exemplary embodiment, see Figure 6 , Figure 6 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown executes.

[0122] like Figure 6 As shown, the method includes steps S210-step S220, steps S610-step S620, step S310, and step S240, wherein steps S610-step S620 are described in detail as follows:

[0123] Step S610, calculating the number of screened out opposing votes.

[0124] Under the condition that the target transaction is a candidate transaction whose corresponding number of verification failure nodes is greater than or equal to the first quantity threshold, before calculating the number of verification failure nodes corresponding to the candidate transaction, the first consensus node may first calculate the number of screened out opposing votes.

[0125] Step S620, if the calculated number of opposing votes is greater than or equal to a second quantity threshold, then the number of consensus nodes that failed to verify the candidate transaction is calculated; wherein the second quantity threshold is greater than or equal to the first quantity threshold.

[0126] The second quantity threshold is used to determine whether to calculate the number of consensus nodes corresponding to the candidate transaction, wherein, if the number of screened out negative votes is greater than or equal to the second quantity threshold, it indicates that the number of consensus nodes that voted against the target block is greater than or equal to the second quantity threshold, that is, the negative votes corresponding to the target block are high, and therefore, the number of consensus nodes corresponding to the candidate transaction can be calculated. Optionally, if the number of screened out negative votes is less than the second quantity threshold, the number of consensus nodes corresponding to the candidate transaction is not calculated, thereby saving computing resources.

[0127] Among them, considering that only when the number of screened out opposing votes is greater than the first quantity threshold, there will be a number of failed verification nodes corresponding to the candidate transaction greater than the first quantity threshold, therefore, the second quantity threshold is greater than or equal to the first quantity threshold. Of course, in other embodiments, the second quantity threshold may also be less than the first quantity threshold. The specific value of the second quantity threshold can be flexibly set according to actual needs. For example, the second quantity threshold can be 110%, 120%, etc. of the first quantity threshold; or, the second quantity threshold can be greater than or equal to x, where, in, It is a round-up function. For example, assuming that the fault tolerance rate is 33% and the total number of consensus nodes is 3f+1, the second quantity threshold may be 2f+1.

[0128] Optionally, if the calculated number of opposing votes is greater than or equal to the second number threshold, an opposing message may be generated first, and then after the target transaction is determined, identification information of the target transaction may be added to the opposing message.

[0129] It should be noted that Figure 6 The specific implementation details of steps S210-S220 and step S240 shown in FIG. Figure 2 Steps S210 to S220, and step S240 are shown. Figure 6 The specific implementation details of step S310 shown can be referred to Figure 3 The step S310 shown is not repeated here.

[0130] exist Figure 6 In the illustrated embodiment, the number of consensus nodes that failed to verify the candidate transaction is calculated only when the number of opposing votes corresponding to the target block is greater than or equal to a second quantity threshold, thereby saving computing resources.

[0131] In an exemplary embodiment, see Figure 7 , Figure 7 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown executes.

[0132] like Figure 7 As shown, the method includes steps S210 to S230, and steps S710 to S740, wherein steps S710 to S740 are described in detail as follows:

[0133] Step S710: If the candidate transaction is determined to be the target transaction to be deleted based on the number of consensus nodes, the locally stored target transaction is deleted, an objection message is generated based on the target transaction, and multiple transactions are extracted from the set of transactions to be agreed upon.

[0134] After determining the target transaction, the first consensus node may generate an objection message indicating deletion of the target transaction according to the target transaction, and send the objection message to the second consensus node.

[0135] Since the consensus of the target block fails, the first consensus node can also serve as a proposal node to generate the next block to be agreed upon and the consensus message of the block. Each consensus node can contain a set of transactions to be agreed upon. In the process of generating a block, the first consensus node can extract multiple transactions from its own set of transactions to be agreed upon. The set of transactions to be agreed upon can be stored in a transaction pool.

[0136] Step S720, respectively execute the extracted multiple transactions, and generate a to-be-chained block whose block height matches the block height of the target block according to the transaction execution results obtained and the previous block of the target block.

[0137] The first consensus node executes the extracted multiple transactions respectively, obtains the transaction execution results of the multiple transactions, and searches for the previous block of the target block (that is, the block height of the previous block is less than the block height of the target block, and the difference in block height is 1). Then, based on the transaction execution results of the multiple transactions and the previous block, a block to be chained is generated whose block height matches the block height of the target block, that is, the previous block is also the previous block of the block to be chained; wherein, the block header of each block usually contains the hash value of its previous block, therefore, the hash value of the previous block of the target block can be calculated, the transaction execution results of the multiple transactions are added to the block body of the block to be chained, and the hash value of the previous block is added to the block header of the block to be chained, thereby obtaining the block to be chained.

[0138] Step S730, generating a proposal message for the block to be chained, and adding the objection message to the proposal message for the block to be chained.

[0139] After generating the block to be chained, the first consensus node may generate a proposal message for the block to be chained, and add the objection message of the target block to the proposal message of the block to be chained; that is, the proposal message of the block to be chained includes the objection message of the target block and the block to be chained.

[0140] Step S740, sending the proposal message of the block to be chained to the second consensus node, so that the second consensus node deletes the locally stored target transaction according to the objection message included in the proposal message of the block to be chained.

[0141] The first consensus node can send the proposal message of the block to be chained to the second consensus node; after receiving the proposal message of the block to be chained, the second consensus node can extract the objection message of the target block from it, thereby deleting the locally stored target transaction according to the objection message of the target block, and verifying and voting on the block to be chained.

[0142] Optionally, the first consensus node may broadcast a proposal message of the block to be chained in the blockchain network to send the proposal message of the block to be chained to the second consensus node corresponding to the first consensus node.

[0143] It should be noted that Figure 7 The specific implementation details of steps S210 to S230 shown in FIG. Figure 2 Steps S210 to S230 shown are not repeated here.

[0144] exist Figure 7 In the illustrated embodiment, the first consensus node sends the proposal message of the target block along with the proposal message of the block to be chained to the second consensus node, which can save network resources.

[0145] In an exemplary embodiment, see Figure 8 , Figure 8 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown executes.

[0146] like Figure 8 As shown, under the condition that the voting includes a consensus node successfully verifying the transaction execution results of multiple transactions included in the target block and generating an approval vote, the method includes steps S210-step S240, and steps S810-step S840, wherein the detailed description of steps S810-step S840 is as follows:

[0147] Step S810: If the number of approval votes in the obtained votes is greater than or equal to the third quantity threshold, an approval message of the target block is generated according to the approval votes, and multiple transactions are extracted from the set of transactions to be agreed upon.

[0148] The third quantity threshold is used to determine whether the target block has failed to reach consensus in this round of voting. If the number of votes in favor of the target block obtained is less than the third quantity threshold, it indicates that the consensus of the target block has failed; if the number of votes in favor of the target block obtained is greater than or equal to the third quantity threshold, it indicates that the consensus of the target block has succeeded. Among them, the specific value of the third quantity threshold can be flexibly set according to actual needs. Optionally, the third quantity threshold can be less than the total number of consensus nodes in the blockchain network and is positively correlated with the total number of consensus nodes. For example, the third quantity threshold can be 50%, 70%, etc. of the total number of consensus nodes, or the third quantity threshold can be x. For example, if the total number of consensus nodes is 3f+1, the third quantity threshold is 2f+1; the third quantity threshold can be the same as the second quantity threshold or different.

[0149] If the number of approved votes of the target block obtained is greater than or equal to the third threshold number, it indicates that in this round of voting, at least the third threshold number of consensus nodes have reached a consensus on the content of the target block, and the first consensus node can generate an approval message of the target block based on the approved votes of the target block obtained, and send the approval message to the second consensus node, so that the second consensus node determines that at least the third threshold number of consensus nodes have reached a consensus on the target block. Optionally, the approval message may include identification information and signature data of the consensus node corresponding to the approval vote, and the approval message may be an approval certificate (Qc, Quorum Certificate).

[0150] In order to save network resources, the first consensus node can generate the next block to be agreed upon, and send the approval message of the target block along with the proposal message of the next block to be agreed upon to the second consensus node corresponding to the first consensus node. In the process of generating blocks, the first consensus node can extract multiple transactions from the set of transactions to be agreed upon.

[0151] Step S820, respectively executing the extracted multiple transactions, and generating the next block of the target block according to the transaction execution results and the target block obtained by executing.

[0152] The first consensus node executes the extracted multiple transactions respectively, and generates the next block of the target block according to the transaction execution results obtained by execution and the target block, that is, the previous block of the generated block is the target block, and the block height of the generated block is greater than the block height of the target block, and the difference is 1. Optionally, the block header of each block usually contains the hash value of its previous block, so the hash value of the target block can be added to the block header of the next block, and the transaction execution results obtained by execution are added to the block header of the next block, so as to obtain the next block.

[0153] Step S830, generate a proposal message for the next block, and add the approval message to the proposal message for the next block.

[0154] After generating the next block, the first consensus node may add the approval message of the target block to the proposal message of the next block, that is, the proposal message of the next block includes the approval message of the target block and the next block.

[0155] Step S840, sending the proposal message of the next block to the second consensus node, so that the second consensus node determines that the consensus of the target block is successful based on the approval message included in the proposal message of the next block, and then adds the target block to the blockchain.

[0156] The first consensus node sends the proposal message of the next block to the second consensus node corresponding to the first consensus node. After receiving the proposal message of the next block, the second consensus node can verify and vote on the next block according to the proposal message of the next block, and can determine whether the consensus on the target block is successful according to the approval message of the target block contained in the proposal message of the next block. If so, the target block is added to the blockchain.

[0157] Among them, the specific way in which the consensus node determines whether the consensus on the target block is successful based on the approval message of the target block can be determined according to the consensus algorithm adopted.

[0158] It should be noted that Figure 8 The specific implementation details of steps S210 to S240 shown in FIG. Figure 2 Steps S210 to S240 shown are not repeated here.

[0159] exist Figure 8 In the illustrated embodiment, the first consensus node sends the approval message of the target block along with the proposal message of the next block of the target block to the second consensus node corresponding to the first consensus node, which can save network resources.

[0160] In an exemplary embodiment, see Fig. 9 , Fig. 9 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown executes.

[0161] like Fig. 9 As shown, the method includes steps S210 to S240, steps S810 to S840, and steps S910 to S920, wherein steps S910 to S920 are described in detail as follows:

[0162] Step S910, receiving proposal messages of other blocks except the target block, and obtaining the approval message of the associated block from the proposal messages of other blocks; wherein the block height of the associated block is greater than the block height of the target block, and the approval vote of the associated block is generated after the transaction execution results of multiple transactions included in the associated block are successfully verified, and the approval message of the previous block of the associated block is successfully verified.

[0163] Therefore, after generating the approval message of the target block according to the approval vote, the first consensus node can receive proposal messages of other blocks except the target block, and obtain the approval message of the associated block from the proposal messages of other blocks.

[0164] Among them, the associated block refers to a block whose block height is greater than the target block. The proposal message of the associated block may include the associated block and the approval message of the previous block of the associated block. The approval vote of the associated block may be generated after the transaction execution results of multiple transactions included in the associated block are successfully verified and the approval message of the previous block of the associated block is successfully verified.

[0165] Step S920: If approval messages corresponding to the set number of associated blocks are obtained, and the block heights of the set number of associated blocks and the target block are continuous, it is determined that the consensus of the target block is successful, and the target block is added to the blockchain.

[0166] It should be noted that the set number is determined according to the consensus algorithm used. If the consensus algorithm needs to go through n (where n is an integer greater than or equal to 1) rounds of voting for the consensus process of a block, the set number can be n-1. For example, if the HotStuff consensus algorithm is used, the consensus of the block includes 4 stages, namely the preparation stage (prepare stage), the pre-commit stage (pre-commit stage), the commit stage (commit stage) and the decision stage (decide stage). Among them, in the preparation stage (prepare stage), the pre-commit stage (pre-commit stage) and the commit stage (commit stage), it is necessary to vote on the block, that is, the consensus process of the block includes 3 rounds of voting, then the set number is 2, and the aforementioned votes generated according to the generated results after verifying the transaction execution results of multiple transactions contained in the target block are the votes in the preparation stage, that is, prepare votes. In a chained consensus algorithm (e.g., the chained HotStuff consensus algorithm), the proposal message of any block contains the approval message of the block and the previous block corresponding to the block. The approval vote of any block is generated after the transaction execution results of multiple transactions contained in the block are successfully verified, and the approval message of the previous block of the block is successfully verified. Under this condition, the j-th round of approval vote of any block can be regarded as the j+1-th round of approval vote of the previous block of any block, and the j+2-th round of approval vote of the previous block of the previous block; for example, in the HotStuff consensus algorithm, the consensus node generates a block 1. After the prepare vote, the approval message of block 1 can be synthesized based on the approval prepare votes of at least the third threshold number of block 1s, and the approval message of block 1 can be added to the proposal message of block 2. After the consensus node obtains the proposal message of block 2, if the approval message of block 1 is successfully verified and the verification of block 2 is successful, an approval prepare vote for block 2 is generated. The approval prepare vote can also represent the approval vote in the pre-submission stage of block 1. Correspondingly, the approval prepare vote of block 3 can represent the vote in the submission stage of block 1 and the vote in the pre-submission stage of block 2.

[0167] Therefore, under the condition that the approval vote of the associated block is generated after the transaction execution results of multiple transactions included in the associated block are successfully verified, and the approval message of the previous block of the associated block is successfully verified, if the approval messages corresponding to the set number of associated blocks are obtained, and the block heights of the set number of associated blocks and the target block are continuous, it means that n rounds of voting have been carried out on the target block, and the voting results of the n rounds of voting are all verified successfully, therefore, the target block is added to the blockchain.

[0168] Optionally, other consensus nodes may also determine whether consensus on the target block is successful according to steps S910-S920. For example, other consensus nodes may determine that consensus on the target block is reached and add the target block to the blockchain upon obtaining the approval message of the target block and the approval messages corresponding to a set number of associated blocks, respectively, and the block heights of the set number of associated blocks and the target block are continuous.

[0169] It should be noted that Fig. 9 The specific implementation details of steps S210 to S240 shown in FIG. Figure 2 Steps S210 to S240 are shown. Fig. 9 The specific implementation details of steps S810 to S840 shown in FIG. Figure 8 Steps S810 to S840 shown are not repeated here.

[0170] exist Fig. 9 In the illustrated embodiment, proposal messages of other blocks except the target block are received, and approval messages of associated blocks are obtained from the proposal messages of other blocks; wherein the block height of the associated block is greater than the block height of the target block, and the approval vote of the associated block is generated after the transaction execution results of multiple transactions contained in the associated block are successfully verified, and the approval message of the previous block of the associated block is successfully verified; if approval messages corresponding to a set number of associated blocks are obtained, and the block heights of the set number of associated blocks and the target block are continuous, it is determined that the consensus of the target block is successful, and the target block is added to the blockchain, which can save network resources.

[0171] In an exemplary embodiment, see Fig.10 , Fig.10 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The first consensus node 121 in the implementation environment shown executes.

[0172] like Fig.10 As shown, the method includes steps S1010 to S1030, and steps S220 to S240, wherein steps S1010 to S1030 are described in detail as follows:

[0173] Step S1010, receiving a proposal message of a target block, and verifying the transaction execution results of multiple transactions included in the target block respectively according to the proposal message.

[0174] As a consensus node, the first consensus node may also receive a proposal message of the target block generated by the proposal node, and verify the transaction execution results of multiple transactions included in the target block according to the proposal message. The specific verification method can be found in subsequent records and will not be repeated here.

[0175] Step S1020, generating a vote for the target block according to the verification result obtained by verification, and determining the target time period according to the generation time.

[0176] The first consensus node can generate a vote for the target block based on the verification result of the target block obtained by itself, and determine the target time period based on the generation time of the vote. The method of generating the vote can refer to the above record and will not be repeated here.

[0177] The target time period is determined based on the generation time, and the specific determination method can be flexibly set according to actual needs. In one example, the target time period can be a time period whose corresponding time is earlier than or equal to the target moment. The target moment is the moment obtained by adding the set duration to the generation moment. For example, assuming the set duration is 5 minutes and the generation time is 15:03:40, the target time period is the period before 15:08:40.

[0178] Step S1030, receiving a vote for the target block sent by the second consensus node within the target time period.

[0179] If the current time is within the target time period, the first consensus node receives the vote for the target block sent by the second consensus node; if the current time is beyond the target time period, the first consensus node no longer receives the vote for the target block from the second consensus node.

[0180] Optionally, after the first consensus node generates a vote for the target block based on the verification result obtained by verification, the first consensus node can set a timer for timing, and if the timing obtained does not exceed the set time, the vote for the target block sent by the second consensus node is received; if the timing obtained exceeds the set time, the vote for the target block sent by the second consensus node is rejected.

[0181] It should be noted that Fig.10 The specific implementation details of steps S220 to S240 shown in FIG. Figure 2 Steps S220 to S240 shown are not repeated here.

[0182] exist Fig.10 In the illustrated embodiment, the consensus efficiency can be improved by receiving the vote for the target block sent by the second consensus node within the target time period without obtaining the vote of each consensus node.

[0183] In an exemplary embodiment, see Fig.11 , Fig.11 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The second consensus node 122 in the implementation environment shown executes.

[0184] like Fig.11 As shown, the method includes steps S1110 to S1140, which are described in detail as follows:

[0185] Step S1110, receiving a proposal message of a target block to be agreed upon, and verifying multiple transaction execution results contained in the target block according to the proposal message.

[0186] After obtaining the proposal message of the target block, the second consensus node can extract the target block from the proposal message and verify the multiple transaction execution results contained in the target block respectively.

[0187] Step S1120, generating a negative vote for the target block based on the candidate transaction that failed verification.

[0188] If the second consensus node fails to verify the transaction execution result of the transaction, the transaction will be used as a candidate transaction and a dissenting vote will be generated based on the candidate transaction.

[0189] Among them, the negative vote may include the identification information of the target block, the identification information of the consensus node and the signature data of the consensus node, wherein the signature data may be generated based on the private key of the consensus node.

[0190] Step S1130, sending the dissenting vote to the first consensus node, so that after the first consensus node determines that the consensus of the target block fails according to the vote of the target block, the number of consensus nodes that failed to verify the candidate transaction is calculated according to the dissenting vote. If the candidate transaction is determined to be the target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted and a dissenting message is generated.

[0191] The second consensus node can send the opposing vote to the first consensus node. After the first consensus node obtains the votes of each consensus node on the target block, if it is determined that the consensus on the target block fails based on the votes of the target block, the number of consensus nodes that failed to verify the candidate transaction is calculated based on the opposing votes of the target block. If the candidate transaction is determined to be the target transaction to be deleted based on the number of consensus nodes, the locally stored target transaction is deleted, and an opposing message indicating the deletion of the target transaction is generated. For details, please refer to the introduction of the aforementioned embodiment, which will not be repeated here. The first consensus node can be the first consensus node of the current view or the first consensus node of the next view.

[0192] Step S1140, receiving an objection message sent by the first consensus node, and deleting the locally stored target transaction according to the objection message.

[0193] The second consensus node may receive an objection message of the target block sent by the first consensus node, and delete the locally stored target transaction according to the objection message.

[0194] After receiving the objection message sent by the first consensus node, it indicates that the consensus of the target block has failed. Therefore, other transactions except the target transaction in the multiple transactions corresponding to the target block can be re-added to the set of transactions to be agreed upon, and the set of transactions to be agreed upon can be a transaction pool. Among them, other transactions can be added to the set of transactions to be agreed upon through subsequent steps S1110-S1120, or, after receiving the objection message sent by the first consensus node, other transactions can be directly added to the set of transactions to be agreed upon according to the objection message, so that other transactions can be re-consensused. Optionally, the first consensus node can also add other transactions to the set of transactions to be agreed upon in the manner described herein.

[0195] exist Fig.11 In the illustrated embodiment, the second consensus node receives a proposal message of a target block to be agreed upon, and verifies the execution results of multiple transactions contained in the target block respectively according to the proposal message; generates a negative vote for the target block according to the candidate transaction that failed verification; sends the negative vote to the first consensus node, so that the first consensus node determines that the consensus of the target block has failed according to the vote of the target block, and then calculates the number of consensus nodes that failed to verify the candidate transaction according to the negative vote. If the candidate transaction is determined to be a target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted and a negative message is generated; the negative message sent by the first consensus node is received, and the locally stored target transaction is deleted according to the negative message, thereby avoiding the situation where the consensus failed transaction is repeatedly re-executed and consensused, saving resources and improving block production efficiency.

[0196] In an exemplary embodiment, see Fig.12 , Fig.12 is a flowchart of a data processing method of a blockchain network shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The second consensus node 122 in the implementation environment shown executes.

[0197] like Fig.12 As shown, the method includes steps S1110 to S1140, and steps S1210 to S1220, wherein steps S1210 to S1220 are described in detail as follows:

[0198] Step S1210: If any block is added to the blockchain, the block height of any block is obtained.

[0199] After determining that any block consensus has been passed, the second consensus node can obtain the block height of any block.

[0200] Step S1220: If the block height of any block is greater than or equal to the block height of the target block, then other transactions except the target transaction in the multiple transactions are added to the set of transactions to be agreed upon.

[0201] If the block height of any block is greater than or equal to the block height of the target block, it indicates that the consensus of the target block has failed. Therefore, the second consensus node can add other transactions except the target transaction among the multiple transactions corresponding to the target block to the set of transactions to be agreed upon. In this way, the proposal node can extract other transactions from the set of transactions to be agreed upon to generate blocks and reach consensus.

[0202] It should be noted that Fig.12 The specific implementation details of steps S1110 to S1140 shown in FIG. Fig.11 Steps S1110 to S1140 shown are not repeated here.

[0203] exist Fig.12 In the illustrated embodiment, if any block is added to the blockchain, the block height of any block is obtained; if the block height of any block is greater than or equal to the block height of the target block, the target block needs to be abandoned, and in order to enable other transactions in the target block except the target transaction to be re-consensused, other transactions are added to the set of transactions to be agreed upon, thereby improving the success rate of transaction execution.

[0204] See also Fig.13 , Fig.13 This is a flowchart of a data processing method for a blockchain network shown in an exemplary embodiment of the present application. This method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The second consensus node 122 in the implementation environment shown executes.

[0205] like Fig.13 As shown, in an exemplary embodiment, the data processing method of the blockchain network may include steps S1310-S1330, and S1120-step S1140, wherein steps S1310-S1330 are described in detail as follows:

[0206] Step S1310, receiving a proposal message of a target block to be agreed upon sent by a proposal node, and executing each of the multiple transactions according to the proposal message.

[0207] The target block contains transaction execution results obtained by executing multiple transactions corresponding to the target transaction in the proposal block. In order to verify the transaction execution results contained in the target block, the second consensus node can execute each of the multiple transactions corresponding to the target block.

[0208] Step S1320, comparing the transaction execution result of each transaction obtained by execution with the transaction execution result of each transaction included in the target block.

[0209] The second consensus node compares the transaction execution result of each transaction executed by the consensus node with the transaction execution result of the transaction contained in the target block.

[0210] Step S1330: If the transaction execution result of each transaction obtained by execution does not match the transaction execution result of each transaction included in the target block, it is determined that each transaction verification fails.

[0211] If the transaction execution result of each transaction executed by the consensus node does not match the transaction execution result of the transaction contained in the target block, the second consensus node determines that the verification of the transaction has failed; if they match, it determines that the verification of the transaction has succeeded.

[0212] It should be noted that Fig.13 The specific implementation details of steps S1120 to S1140 shown in FIG. Fig.11 Steps S1120 to S1140 shown are not repeated here.

[0213] exist Fig.13 In the illustrated embodiment, after executing each of the multiple transactions, if the second consensus node determines that the transaction execution result of each transaction obtained by execution does not match the transaction execution result of each transaction included in the target block, then each transaction is determined to have failed verification, thereby improving the verification success rate.

[0214] In an exemplary embodiment, the first consensus node is a master node in the consensus node set, and the second consensus node is a slave node. The data processing method of the blockchain network may include steps 1.1 to 1.2, which are described in detail as follows:

[0215] Step 1.1, the master node 1 of the current view generates block i and the proposal message of block i, and broadcasts the proposal message of block i.

[0216] Where i refers to the block height, and block i refers to any block that needs to be agreed upon. In the preparation phase of block i, master node 1 is the master node of the current view, which can be any consensus node in the blockchain network. Master node 1 can extract multiple transactions from the transaction pool and execute them, obtain read-write set 1 of multiple transactions, generate block i containing multiple transactions and read-write set 1 of multiple transactions, and broadcast the proposal message of block i.

[0217] 1.2. Consensus on block i is reached based on the proposal message of block i.

[0218] In the consensus process, after the first slave node of master node 1 (which is also the slave node of the next view, i.e., the slave node of master node 2) receives the proposal message of block i, it can execute Fig.14 The steps S1401 to S1405 shown in FIG. 1 are described in detail as follows:

[0219] Step S1401, receiving the proposal message of block i sent by master node 1.

[0220] The first slave node receives the proposal message for block i.

[0221] Step S1402, execute multiple transactions in block i to obtain a read-write set 1' of multiple transactions.

[0222] The first slave node executes multiple transactions in block i and obtains a read-write set of multiple transactions, which is recorded as read-write set 1'.

[0223] Step S1403, determine whether the read-write set 1' matches the read-write set 1 included in block i, if so, go to step S1404, if not, go to step S1405.

[0224] The read-write set containing multiple transactions in block i is denoted as read-write set 1.

[0225] The first slave node determines whether read-write set 1' matches read-write set 1.

[0226] Step S1404, sending the approval vote of block i to master node 2.

[0227] If read-write set 1' matches read-write set 1, the first slave node generates an approval vote and sends it to the master node of the next view, that is, master node 2.

[0228] Step S1405, sending the negative vote of block i to master node 2, where the negative vote contains the identification number of the candidate transaction that failed verification.

[0229] If read-write set 1′ does not match read-write set 1, the first slave node searches for the unmatched transaction, adds the identification number (ID) of the found transaction to the negative vote, and sends the negative vote to master node 2.

[0230] During the consensus process, after the second slave node of master node 1 (which is also the master node of the next view, master node 2) receives the proposal message of block i, it can execute Fig.15 The steps shown in step S1501 to step S1518 in the embodiment are described in detail as follows:

[0231] Step S1501, receiving the proposal message of block i sent by master node 1.

[0232] Masternode 2 receives the proposal message for block i.

[0233] Step S1502, execute multiple transactions in block i to obtain a read-write set 1' of multiple transactions.

[0234] Step S1503, determine whether the read-write set 1' matches the read-write set 1 included in block i, if so, go to step S1504, if not, go to step S1505.

[0235] Among them, step S1502-step S1503 are similar to the aforementioned step S1402-step S1403, and will not be repeated here.

[0236] Step S1504, sending the approval vote for block i to master node 2.

[0237] Masternode 2 generates an approval vote for block i and sends it to itself.

[0238] Step S1505, sending the negative vote of block i to master node 2, where the negative vote includes the transaction identification number of the failed verification.

[0239] Masternode 2 generates a negative vote for block i and sends it to itself.

[0240] Step S1506, obtain the votes of block i and set a timer.

[0241] After generating the vote, Master Node 2 can set a timer.

[0242] Step S1507, determine whether 2f+1 approval votes for block i are obtained before the timer times out. If so, go to step S1508; if not, go to step S1512.

[0243] Step S1508, synthesize the obtained approval votes of block i into an approval certificate.

[0244] Among them, the number of consensus nodes included in the blockchain network is 3f+1. If 2f+1 approval votes for block i are obtained before the timer expires, the master node 2 will synthesize the approval votes for block i into an approval certificate.

[0245] Step S1509: Generate block i+1 based on block i, and add the approval certificate of block i to the proposal message of block i+1.

[0246] Master node 2 can generate block i+1 and add the approval certificate of block i to the proposal message of block i+1. The specific method of master node 2 generating block i+1 can be found in the above record and will not be repeated here.

[0247] Step S1510, broadcast the proposal message of block i+1.

[0248] Master node 2 can broadcast the proposal message of block i+1 in the blockchain network, so that each consensus node continues to reach consensus on the target block based on the proposal message of block i+1.

[0249] Step S1511, if block i is submitted, delete multiple transactions contained in the locally stored block i.

[0250] In the subsequent consensus process, if block i is submitted to the blockchain, master node 2 can delete multiple transactions contained in the locally stored block i. Optionally, if the chained HotStuff consensus algorithm is adopted, each consensus node can verify block i+1 and the approval certificate of block i, and send the generated vote to the master node of the next view (master node 3) according to the verification result, and so on. If each subsequent consensus node obtains the approval certificates corresponding to block i, block i+1, and block i+2, it means that the consensus of block i has passed and is submitted.

[0251] Step S1512, determine whether 2f+1 negative votes for block i are obtained before the timer times out. If not, go to step S1513; if so, go to step S1514.

[0252] Step S1513, generate block i' and generate a proposal message for block i'.

[0253] Since no 2f+1 votes in favor of block i were obtained before the timer expired, and no 2f+1 votes against block i were obtained, it indicates that the consensus of block i has failed. Therefore, master node 2 can regenerate a block with a block height of i, recorded as block i', and broadcast the proposal message of block i'.

[0254] Step S1514, synthesize the objection certificate based on the obtained objection vote of block i.

[0255] If 2f+1 votes in favor of block i are not obtained before the timer times out, but 2f+1 votes against block i are obtained, master node 2 can synthesize a certificate of disapproval based on the votes against block i.

[0256] Step S1515, based on the negative votes of block i, calculate the number of consensus nodes that failed to verify the candidate transaction, and add the identification information of the target transaction with a number of consensus nodes greater than or equal to f+1 to the negative certificate.

[0257] Step S1516, deleting the target transaction in the local transaction pool.

[0258] Master node 2 can delete the target transaction contained in the local transaction pool.

[0259] Step S1517: Generate block i' based on the previous block of block i, add the objection certificate of block i to the proposal message of block i', and broadcast the proposal message of block i'.

[0260] Master node 2 can generate a regenerated block with a block height of i, recorded as block i', and add the objection certificate of block i to the proposal message of block i'.

[0261] Step S1518: If block i' is submitted, the transactions in block i that have not been deleted are added to the transaction pool.

[0262] If block i' is submitted in the subsequent consensus process, master node 2 can add the transactions that have not been deleted in block i to the transaction pool. Optionally, if block i' is submitted, the slave node corresponding to master node 2 can also add the transactions that have not been deleted in block i to the transaction pool.

[0263] It should be noted that, under the condition of generating an opposition certificate, any consensus node can perform the following operations in addition to the above operations after receiving the proposal message of a new block: Fig.16 Steps S1601 to S1606 are described in detail as follows:

[0264] Step S1601, receiving a proposal message of any block.

[0265] Any consensus node can receive the proposal message of any block.

[0266] Step S1602, determine whether the proposal message contains an objection certificate, if so, go to step S1603.

[0267] Step S1603: verify the objection certificate.

[0268] Any consensus node can verify the objection certificate contained in the proposal message of any block.

[0269] Step S1604, determine whether the verification is successful, if so, go to step S1605, if not, go to step S1606.

[0270] Step S1605: Delete the transaction corresponding to the transaction identifier contained in the objection certificate from the transaction pool.

[0271] If the verification is successful, any consensus node can delete the transaction corresponding to the transaction identifier contained in the objection certificate.

[0272] Step S1606, abandon the block.

[0273] If the verification fails, any consensus node can abandon any block.

[0274] It should be noted that Figure 14-16 The steps in the above embodiments have been described in detail and will not be repeated here.

[0275] The solution provided in this embodiment can save resources and improve block production efficiency.

[0276] See also Fig.17 , Fig.17 1 is a block diagram of a data processing device of a blockchain network shown in an exemplary embodiment of the present application. The blockchain network includes a first consensus node and a second consensus node, and the device is configured at the first consensus node. Fig.17 As shown, the device comprises:

[0277] The acquisition module 1701 is configured to obtain votes of each consensus node on the target block of the consensus; the votes are generated according to the verification results after the transaction execution results of multiple transactions included in the target block are verified respectively;

[0278] The screening module 1702 is configured to screen out opposing votes from the obtained votes if it is determined that the consensus of the target block fails according to the obtained votes; the opposing votes are generated according to the candidate transactions that failed verification;

[0279] A calculation module 1703 is configured to calculate the number of consensus nodes that failed to verify the candidate transaction based on the screened negative votes;

[0280] The deletion module 1704 is configured to delete the locally stored target transaction if the candidate transaction is determined to be the target transaction to be deleted based on the number of consensus nodes, and send an objection message to the second consensus node indicating the deletion of the target transaction.

[0281] In an exemplary embodiment, based on the aforementioned scheme, the device also includes a determination module configured to: if the number of consensus nodes is greater than or equal to a first quantity threshold, determine the candidate transaction as a target transaction; wherein the first quantity threshold is positively correlated with the total number of consensus nodes included in the blockchain network.

[0282] In an exemplary embodiment, based on the aforementioned scheme, the determination module is specifically configured as follows: searching for a target smart contract for executing a candidate transaction, and obtaining a first quantity threshold corresponding to the target smart contract; wherein the first quantity thresholds corresponding to different smart contracts are different; if the number of consensus nodes is greater than or equal to the first quantity threshold corresponding to the target smart contract, the candidate transaction is determined to be the target transaction.

[0283] In an exemplary embodiment, based on the aforementioned scheme, the device also includes a threshold calculation module, configured to: find the number of historical target transactions corresponding to the target smart contract; calculate the first quantity threshold corresponding to the target smart contract based on the number of historical target transactions; wherein the first quantity threshold corresponding to the target smart contract is negatively correlated with the number of historical target transactions.

[0284] In an exemplary embodiment, based on the aforementioned scheme, the screening module 1702 is specifically configured to: calculate the number of screened out opposing votes; if the calculated number of opposing votes is greater than or equal to a second quantity threshold, then calculate the number of consensus nodes that failed to verify the candidate transaction; wherein the second quantity threshold is greater than or equal to the first quantity threshold.

[0285] In an exemplary embodiment, based on the aforementioned scheme, the deletion module 1704 is specifically configured as follows: generating an objection message according to the target transaction, and extracting multiple transactions from the transaction pool for storing transactions to be executed; executing the extracted multiple transactions respectively, and generating a block to be chained whose block height matches the block height of the target block according to the transaction execution results obtained and the previous block of the target block; generating a proposal message for the block to be chained, and adding the objection message to the proposal message of the block to be chained; sending the proposal message of the block to be chained to the second consensus node, so that the second consensus node deletes the locally stored target transaction according to the objection message contained in the proposal message of the block to be chained.

[0286] In an exemplary embodiment, based on the aforementioned scheme, under the condition that the voting includes an approval vote generated after the consensus node successfully verifies the transaction execution results of multiple transactions included in the target block, the device also includes a sending module, which is configured to: if the number of approval votes in the acquired voting is greater than or equal to a third quantity threshold, then generate an approval message of the target block according to the approval vote, and extract multiple transactions from the transaction pool; execute the extracted multiple transactions respectively, and generate the next block of the target block according to the transaction execution results obtained by execution and the target block; generate a proposal message for the next block, and add the approval message to the proposal message of the next block; send the proposal message of the next block to the second consensus node, so that the second consensus node determines that the consensus of the target block is successful based on the approval message contained in the proposal message of the next block, and then add the target block to the blockchain.

[0287] In an exemplary embodiment, based on the aforementioned scheme, the device also includes an adding module, configured to: receive proposal messages of other blocks except the target block, and obtain approval messages of associated blocks from the proposal messages of other blocks; wherein the block height of the associated block is greater than the block height of the target block, and the approval vote of the associated block is generated after the transaction execution results of multiple transactions contained in the associated block are successfully verified, and the approval message of the previous block of the associated block is successfully verified; if approval messages corresponding to a set number of associated blocks are obtained, and the block heights of the set number of associated blocks and the target block are continuous, it is determined that the consensus of the target block is successful, and the target block is added to the blockchain.

[0288] In an exemplary embodiment, based on the aforementioned scheme, the acquisition module 1701 is specifically configured to: receive a proposal message of the target block, and verify the transaction execution results of multiple transactions included in the target block according to the proposal message; generate a vote for the target block according to the verification result obtained by the verification, and determine the target time period according to the generation time; receive the vote for the target block sent by the second consensus node within the target time period.

[0289] It should be noted that Fig.17 The data processing device of the blockchain network provided belongs to the same concept as the data processing method of the blockchain network corresponding to the first consensus node provided in the above embodiment, and the specific manner in which each module and unit performs operations has been described in detail in the method embodiment and will not be repeated here.

[0290] See also Fig.18 , Fig.18 1 is a block diagram of a data processing device of a blockchain network shown in an exemplary embodiment of the present application. The blockchain network includes a first consensus node and a second consensus node, and the device is configured at the second consensus node. Fig.18 As shown, the device comprises:

[0291] Verification module 1801 is configured to receive a proposal message of a target block to be agreed upon, and verify the multiple transaction execution results contained in the target block respectively according to the proposal message;

[0292] A generation module 1802 is configured to generate a negative vote for a target block based on the candidate transaction that failed verification;

[0293] The sending module 1803 is configured to send the negative vote to the first consensus node, so that after the first consensus node determines that the consensus of the target block fails according to the vote of the target block, the number of consensus nodes that fail to verify the candidate transaction is calculated according to the negative vote. If the candidate transaction is determined to be the target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted, and a negative message is generated;

[0294] The deletion module 1804 is configured to receive an objection message sent by the first consensus node, and delete the locally stored target transaction according to the objection message.

[0295] In an exemplary embodiment, based on the aforementioned scheme, the device also includes an adding module, which is configured to: if any block is added to the blockchain, obtain the block height of any block; if the block height of any block is greater than or equal to the block height of the target block, then add other transactions in multiple transactions except the target transaction to the set of transactions to be agreed upon.

[0296] In an exemplary embodiment, based on the aforementioned scheme, the verification module 1801 is specifically configured to: execute each of the multiple transactions according to the proposal message; compare the transaction execution result of each transaction obtained by execution with the transaction execution result of each transaction included in the target block; if the transaction execution result of each transaction obtained by execution does not match the transaction execution result of each transaction included in the target block, it is determined that the verification of each transaction has failed.

[0297] It should be noted that Fig.18 The data processing device of the blockchain network provided and the data processing method of the blockchain network corresponding to the second consensus node provided in the above embodiment belong to the same concept, and the specific manner in which each module and unit performs operations has been described in detail in the method embodiment and will not be repeated here.

[0298] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more computer programs, wherein when the one or more computer programs are executed by one or more processors, the electronic device implements the data processing method of the blockchain network provided in the above-mentioned embodiments.

[0299] Fig.19 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0300] It should be noted that Fig.19 The computer system 1900 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0301] like Fig.19As shown, the computer system 1900 includes a central processing unit (CPU) 1901, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1902 or a computer program loaded from a storage part 1908 to a random access memory (RAM) 1903, such as executing the data processing method of the blockchain network in the above embodiment. In RAM 1903, various computer programs and data required for system operation are also stored. CPU 1901, ROM 1902, and RAM 1903 are connected to each other via a bus 1904. An input / output (I / O) interface 1905 is also connected to bus 1904.

[0302] In some embodiments, the following components are connected to the I / O interface 1905: an input section 1906 including a keyboard, a mouse, etc.; an output section 1907 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 1908 including a hard disk, etc.; and a communication section 1909 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1909 performs communication processing via a network such as the Internet. A drive 1910 is also connected to the I / O interface 1905 as needed. A removable medium 1911, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1910 as needed, so that a computer program read therefrom is installed into the storage section 1908 as needed.

[0303] In particular, according to an embodiment of the present application, a computer program for implementing a data processing method of a blockchain network may be carried on a computer-readable medium, and the computer program may be downloaded and installed from a network through the communication part 1909 , and / or installed from a removable medium 1911 .

[0304] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a computer program, which may be used by an instruction execution system, device or device or used in combination with it. The computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried, and the propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer program contained in the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, etc., or any suitable combination of the foregoing.

[0305] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and a computer program.

[0306] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0307] Another aspect of the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor of an electronic device, enables the electronic device to implement the data processing method of the blockchain network as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiments, or may exist independently without being assembled into the electronic device.

[0308] Another aspect of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the data processing method of the blockchain network provided in each of the above embodiments. Among them, the computer program can be stored in a computer-readable storage medium. The computer program product can be a computer program as a product, for example, an APP (Application, mobile application software), a web page, a small program, etc.; or, the computer program product can also be a storage medium, a device, a terminal, a virtual machine, etc. containing a computer program.

[0309] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person skilled in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A data processing method for a blockchain network, characterized in that: The blockchain network includes a first consensus node and a second consensus node, and the method is performed by the first consensus node. The method includes: Obtaining votes of each consensus node on the target block for consensus; the votes are generated according to the verification results after verifying the transaction execution results of multiple transactions included in the target block respectively; If it is determined that the consensus of the target block fails based on the obtained votes, then a negative vote is screened out from the obtained votes; the negative vote is generated based on the candidate transaction that failed verification; Based on the screened negative votes, calculate the number of consensus nodes that failed to verify the candidate transaction; If the candidate transaction is determined to be a target transaction to be deleted based on the number of consensus nodes, the locally stored target transaction is deleted, and an objection message instructing the second consensus node to delete the target transaction is sent.

2. The method according to claim 1, characterized in that The method further comprises: If the number of consensus nodes is greater than or equal to a first quantity threshold, the candidate transaction is determined to be a target transaction; wherein the first quantity threshold is positively correlated with the total number of consensus nodes included in the blockchain network.

3. The method according to claim 2, characterized in that If the number of the consensus nodes is greater than or equal to a first number threshold, determining the candidate transaction as a target transaction includes: Find a target smart contract for executing the candidate transaction, and obtain a first quantity threshold corresponding to the target smart contract; wherein the first quantity thresholds corresponding to different smart contracts are different; If the number of consensus nodes is greater than or equal to the first quantity threshold corresponding to the target smart contract, the candidate transaction is determined to be the target transaction.

4. The method according to claim 3, characterized in that The method further comprises: Find the number of historical target transactions corresponding to the target smart contract; According to the number of the historical target transactions, a first quantity threshold corresponding to the target smart contract is calculated; wherein the first quantity threshold corresponding to the target smart contract is negatively correlated with the number of the historical target transactions.

5. The method according to claim 2, characterized in that The step of calculating the number of consensus nodes that failed to verify the candidate transaction based on the screened negative votes includes: Count the number of negative votes that were screened out; If the calculated number of opposing votes is greater than or equal to a second quantity threshold, then the number of consensus nodes that failed to verify the candidate transaction is calculated; wherein the second quantity threshold is greater than or equal to the first quantity threshold.

6. The method according to claim 1, characterized in that The sending an objection message to the second consensus node indicating deletion of the target transaction includes: Generate the objection message according to the target transaction, and extract multiple transactions from the set of transactions to be agreed upon; Execute the extracted multiple transactions respectively, and generate a to-be-chained block whose block height matches the block height of the target block according to the transaction execution results obtained and the previous block of the target block; Generate a proposal message for the block to be chained, and add the objection message to the proposal message for the block to be chained; The proposal message of the block to be chained is sent to the second consensus node, so that the second consensus node deletes the locally stored target transaction according to the objection message included in the proposal message of the block to be chained.

7. The method according to claim 1, characterized in that The vote includes an approval vote generated by the consensus node after successfully verifying the transaction execution results of multiple transactions included in the target block; The method further comprises: If the number of approval votes in the obtained votes is greater than or equal to a third quantity threshold, generating an approval message of the target block according to the approval votes, and extracting multiple transactions from the set of transactions to be agreed upon; Execute the extracted multiple transactions respectively, and generate the next block of the target block according to the transaction execution results obtained by executing and the target block; Generate a proposal message for the next block, and add the approval message to the proposal message for the next block; The proposal message of the next block is sent to the second consensus node, so that the second consensus node determines that the consensus of the target block is successful based on the approval message included in the proposal message of the next block, and then adds the target block to the blockchain.

8. The method according to claim 7, characterized in that After generating an approval message of the target block according to the approval vote, the method further includes: Receive proposal messages of other blocks except the target block, and obtain approval messages of associated blocks from the proposal messages of the other blocks; wherein the block height of the associated block is greater than the block height of the target block, and the approval vote of the associated block is generated after the transaction execution results of multiple transactions included in the associated block are successfully verified and the approval message of the previous block of the associated block is successfully verified; If approval messages corresponding to a set number of associated blocks are obtained, and the block heights of the set number of associated blocks and the target block are continuous, it is determined that the consensus of the target block is successful, and the target block is added to the blockchain.

9. The method according to claim 1, characterized in that The step of obtaining votes of each consensus node on the target block of the consensus includes: receiving a proposal message of the target block, and verifying the transaction execution results of multiple transactions included in the target block respectively according to the proposal message; Generate a vote for the target block according to the verification result obtained by verification, and determine the target time period according to the generation time; A vote for the target block is received from the second consensus node within the target time period.

10. A data processing method for a blockchain network, characterized in that: The blockchain network includes a first consensus node and a second consensus node, and the method is performed by the second consensus node, and the method includes: Receive a proposal message of a target block to be agreed upon, and verify multiple transaction execution results contained in the target block according to the proposal message; Generate a negative vote for the target block based on the candidate transaction that failed verification; Sending the negative vote to the first consensus node, so that after the first consensus node determines that the consensus of the target block fails according to the vote of the target block, the first consensus node calculates the number of consensus nodes that fail to verify the candidate transaction according to the negative vote, and if the candidate transaction is determined to be the target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted, and a negative message is generated; Receive the objection message sent by the first consensus node, and delete the locally stored target transaction according to the objection message.

11. The method according to claim 10, characterized in that After receiving the objection message sent by the first consensus node, the method further includes: If any block is added to the blockchain, the block height of the block is obtained; If the block height of any of the blocks is greater than or equal to the block height of the target block, then other transactions among the multiple transactions except the target transaction are added to the set of transactions to be agreed upon.

12. The method according to claim 10, characterized in that The verifying the multiple transaction execution results included in the target block according to the proposal message respectively includes: executing each of the plurality of transactions according to the proposal message; Comparing the transaction execution result of each transaction obtained by execution with the transaction execution result of each transaction included in the target block; If the transaction execution result of each transaction obtained by execution does not match the transaction execution result of each transaction included in the target block, it is determined that the verification of each transaction has failed.

13. A data processing device for a blockchain network, characterized in that: The blockchain network includes a first consensus node and a second consensus node, the device is configured at the first consensus node, and the device includes: An acquisition module is configured to acquire votes of each consensus node on the target block for consensus; the votes are generated according to the verification results after the transaction execution results of multiple transactions included in the target block are verified respectively; A screening module, configured to screen out opposing votes from the obtained votes if it is determined that the consensus of the target block fails according to the obtained votes; the opposing votes are generated according to the candidate transactions that failed verification; A calculation module, configured to calculate the number of consensus nodes that failed to verify the candidate transaction based on the screened negative votes; The deletion module is configured to delete the locally stored target transaction if the candidate transaction is determined to be a target transaction to be deleted based on the number of consensus nodes, and send an objection message to the second consensus node indicating the deletion of the target transaction.

14. A data processing device for a blockchain network, characterized in that: The blockchain network includes a first consensus node and a second consensus node, the device is configured at the second consensus node, and the device includes: A verification module, configured to receive a proposal message of a target block to be agreed upon, and to verify the multiple transaction execution results contained in the target block respectively according to the proposal message; A generation module, configured to generate a negative vote for the target block based on the candidate transaction that failed verification; a sending module configured to send the objection vote to the first consensus node, so that after the first consensus node determines that the consensus of the target block fails according to the vote of the target block, the first consensus node calculates the number of consensus nodes that fail to verify the candidate transaction according to the objection vote, and if the candidate transaction is determined to be a target transaction to be deleted according to the number of consensus nodes, the locally stored target transaction is deleted, and an objection message is generated; A deletion module is configured to receive the objection message sent by the first consensus node and delete the locally stored target transaction according to the objection message.

15. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more computer programs, which, when executed by the one or more processors, enables the electronic device to implement the method described in any one of claims 1 to 12.

16. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor of an electronic device, the electronic device is enabled to implement the method according to any one of claims 1 to 12.

17. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 12 when being executed by a processor.

Images