Transaction processing method and apparatus in blockchain network, device, and medium

Abstract

Embodiments of the present application provide a transaction processing method and device in a blockchain network, equipment and medium. The method comprises: obtaining a target proposal sent by a master node; determining Y transaction groups of a target node in X transaction groups contained in the target proposal, obtaining a second execution result of the Y transaction groups by the target node, Y≤X; adding a transaction group with a first execution result different from the second execution result to an opposed transaction set, generating first voting information of the target node according to the second execution result and the opposed transaction set; obtaining the number of opposed nodes corresponding to X transaction groups according to the first voting information corresponding to N nodes; and determining that the second voting information of the target node is a favorable vote if the number of opposed nodes of the X transaction groups is less than or equal to a first quantity threshold. The embodiments of the present application can reduce the number of transaction executions in the blockchain network, thereby reducing resource consumption.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a transaction processing method, apparatus, device, and medium in a blockchain network. Background Technology

[0002] In a blockchain system, transaction execution is one of the most important and core processes. For example, during block consensus, when a blockchain node receives a block sent by a proposing node, it needs to execute all the transactions contained in that block, obtain the execution result for each transaction, and then conduct two rounds of voting to reach consensus. In other words, all nodes in the blockchain network need to execute all the transactions in the block to confirm the validity of the block packaged by the proposing node. However, when executing transactions, blockchain nodes need to call virtual machine programs through contract information, which consumes a significant amount of device resources (memory, central processing unit, etc.), resulting in resource waste. Summary of the Invention

[0003] This application provides a transaction processing method, apparatus, device, and medium in a blockchain network, which can reduce the number of transactions executed in the blockchain network, thereby reducing resource consumption.

[0004] This application provides a transaction processing method in a blockchain network, including:

[0005] Obtain the target proposal sent by the master node in the blockchain network; the target proposal includes a data block and the first execution result of the master node on X transaction groups contained in the data block, where X is a positive integer;

[0006] Determine the Y transaction groups corresponding to the target node from the X transaction groups contained in the data block, and obtain the second execution result of the target node on the Y transaction groups; Y is a positive integer less than X;

[0007] Transactions with different first and second execution results are grouped and added to the target node's set of opposing transactions. Based on the second execution result and the target node's set of opposing transactions, the target node's first voting information is generated.

[0008] Based on the first vote information corresponding to N nodes in the blockchain network, obtain the number of opposing nodes corresponding to X transaction groups respectively; N nodes include the main node and the target node, and N is a positive integer;

[0009] If the number of opposing nodes in X transaction groups is less than or equal to the first quantity threshold, then the second voting information of the target node on the data block is determined to be a positive vote; the positive vote is used to determine the consensus result of the data block in the blockchain network.

[0010] This application provides a transaction processing device in a blockchain network, comprising:

[0011] The proposal acquisition module is used to acquire target proposals sent by master nodes in the blockchain network. The target proposal includes a data block and the first execution result of the master node on X transaction groups contained in the data block, where X is a positive integer.

[0012] The transaction execution module is used to determine the Y transaction groups corresponding to the target node from the X transaction groups contained in the data block, and obtain the second execution result of the target node on the Y transaction groups; Y is a positive integer less than X;

[0013] The first voting module is used to group transactions whose first execution results and second execution results are different and add them to the target node's set of opposing transactions. Based on the second execution result and the target node's set of opposing transactions, the first voting information of the target node is generated.

[0014] The voting statistics module is used to obtain the number of opposing nodes corresponding to each of the X transaction groups based on the first voting information of N nodes in the blockchain network; the N nodes include the main node and the target node, and N is a positive integer;

[0015] The second voting module is used to determine the target node's second voting information for the data block as a positive vote if the number of opposing nodes in X transaction groups is less than or equal to the first quantity threshold; the positive vote is used to determine the consensus result of the data block in the blockchain network.

[0016] The device also includes:

[0017] The signature acquisition module is used to acquire the digital signature of the target proposal from the master node;

[0018] The decryption module is used to obtain the node public key corresponding to the master node, and decrypt the digital signature based on the node public key to obtain the first digest information;

[0019] The hash operation module is used to perform hash operations on data blocks using a hash algorithm to obtain the second digest information corresponding to the data blocks;

[0020] The validity determination module is used to determine that the target proposal is valid if the first digest information and the second digest information are the same.

[0021] The transaction execution module includes:

[0022] The node execution number determination unit is used to obtain the upper limit of the number of illegal nodes in the blockchain network, and determine the number of nodes to be executed for each transaction group in X transaction groups based on the upper limit of the number of illegal nodes.

[0023] The transaction allocation unit is used to allocate a set of transactions to be executed to N nodes in the blockchain network based on the number of nodes to be executed and the X transaction groups contained in the data block; one node corresponds to one transaction set, and the transaction sets corresponding to different nodes contain different transaction groups;

[0024] The aforementioned transaction allocation unit is also used to obtain a first transaction set that matches the target node from among N transaction sets based on the node identifier corresponding to the target node; the first transaction set includes Y transaction groups.

[0025] The transaction execution module includes:

[0026] The contract information acquisition unit is used to obtain the i-th transaction group from the Y transaction groups corresponding to the target node, and to obtain the contract information corresponding to the i-th transaction group; i is a positive integer less than or equal to Y;

[0027] The virtual machine program invocation unit is used to invoke the virtual machine program corresponding to the target node based on the contract name in the contract information, run the virtual machine program according to the input parameters and methods in the contract information, and obtain the second execution result corresponding to the i-th transaction group.

[0028] The device also includes:

[0029] The voting broadcast module is used to broadcast the first vote information of the target node in the blockchain network, so that the other nodes in the blockchain network, excluding the target node, can determine the number of opposing nodes corresponding to each of the X transaction groups based on the received first vote information.

[0030] The N nodes in the blockchain network include node a;

[0031] The device also includes:

[0032] The first transaction identifier acquisition module is used to receive the first voting information broadcast by node a and obtain the first transaction identifier indicated by the execution result in the first voting information of node a;

[0033] The second transaction identifier acquisition module is used to obtain the second transaction set allocated to node a from X transaction groups, and to obtain the second transaction identifier corresponding to the transaction group in the second transaction set;

[0034] The transaction legality verification module is used to determine the legality of node a's first voting information if the first transaction identifier is the same as the second transaction identifier.

[0035] The aforementioned transaction legality verification module is also used to determine that the first voting information of node a is not legal if the first transaction identifier and the second transaction identifier are different, and to delete the first voting information of node a.

[0036] The voting statistics module includes:

[0037] The transaction traversal unit is used to traverse the X transaction groups contained in the data block and obtain the j-th transaction group among the X transaction groups; j is a positive integer less than or equal to X;

[0038] The opposition quantity statistics unit is used to determine the statistical quantity of the opposition transaction set containing the j-th transaction group from the opposition transaction set contained in the first voting information of N nodes, and to determine the statistical quantity as the number of opposition nodes of the j-th transaction group.

[0039] The device also includes:

[0040] The opposing vote determination module is used to determine the second voting information of the target node on the data block as an opposing vote if the number of opposing nodes in any of the X transaction groups is greater than a first quantity threshold.

[0041] The aforementioned voting broadcasting module is also used to broadcast the second voting information of the target node in the blockchain network, so that the other nodes in the blockchain network, excluding the target node, can determine the number of affirmative votes corresponding to the data block based on the received second voting information.

[0042] The device also includes:

[0043] The "Affirmative Votes" module is used to obtain the second voting information of N nodes on a data block and to count the number of "Affirmative Votes" in the second voting information of N nodes.

[0044] The consensus module is used to determine that if the number of votes in favor is greater than or equal to a second threshold, the consensus result of the data block in the blockchain network is successful, and the data block is added to the blockchain.

[0045] The device also includes:

[0046] The consensus failure module is used to determine that the consensus result of the data block in the blockchain network is a consensus failure if the number of votes in favor is less than a second threshold, and then delete the target proposal.

[0047] The master node selection module is used to re-determine the master node for generating the consensus proposal from N nodes; the block height corresponding to the consensus proposal is the same as the block height of the data block.

[0048] One aspect of this application provides a computer device, including a memory and a processor. The memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method provided in one aspect of this application.

[0049] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having a processor performs the method provided in one aspect of this application.

[0050] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in the above aspect.

[0051] In this embodiment, when a node in the blockchain network receives a target proposal sent by the master node, it can determine the Y transaction groups corresponding to the target node from the X transaction groups contained in the target proposal, and execute the Y transaction groups to obtain the second execution result of the target node on the Y transaction groups, where Y is a positive integer less than X. If the execution results of the target node and the master node on the same transaction group are different, it means that the target node opposes the transaction group and adds the transaction group to the opposition transaction set. Based on the second execution result and the opposition transaction set, the first voting information of the target node can be generated. The target node can collect the first voting information of all nodes in the blockchain network and obtain the number of opposing nodes corresponding to the X transaction groups based on the collected first voting information. If the number of opposing nodes is less than or equal to a first quantity threshold, the target node can vote in favor of the data block in the target proposal (i.e., vote in favor), and determine the consensus result of the data block by counting the number of votes in favor. It is evident that when processing the data blocks in the target proposal for consensus, the target node only needs to execute a portion of the transactions in the data block, rather than all of them. That is, the X transaction groups contained in the data block can be distributed and executed across N nodes, which can reduce the number of transactions executed in the blockchain network and thus reduce resource consumption. Attached Figure Description

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

[0053] Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0054] Figure 2 This is a schematic diagram of a block consensus processing method provided in an embodiment of this application;

[0055] Figure 3 This is a flowchart illustrating a transaction processing method in a blockchain network provided in an embodiment of this application;

[0056] Figure 4 This is a schematic diagram of a transaction grouping provided in an embodiment of this application;

[0057] Figure 5 This is a flowchart illustrating another transaction processing method in a blockchain network provided in an embodiment of this application;

[0058] Figure 6 This is a schematic diagram illustrating the allocation of transaction packets in a data block according to an embodiment of this application;

[0059] Figure 7 This is a schematic diagram of the structure of a first voting information provided in an embodiment of this application;

[0060] Figure 8 This is a flowchart of a proposal consensus processing procedure in a blockchain network provided in an embodiment of this application;

[0061] Figure 9 This is a flowchart illustrating a consensus processing procedure in a blockchain network provided in an embodiment of this application;

[0062] Figure 10 This is a schematic diagram of the structure of a transaction processing device in a blockchain network provided in an embodiment of this application;

[0063] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0064] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0065] This application relates to blockchain technology. Blockchain is a decentralized infrastructure with distributed storage characteristics. Specifically, it is a data structure that organizes blocks in chronological order using a linked list-like manner. It can securely store data with sequential relationships that can be verified within the system, and uses cryptography to ensure that the data is immutable and unforgeable. Blockchain can be considered a distributed ledger, and the information data contained in each block on the blockchain is the ledger data of this distributed ledger.

[0066] The underlying blockchain platform can include processing modules such as basic services, smart contracts, and operation management. The basic service module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic service first performs interface adaptation parsing and authentication (interface adaptation), then encrypts the business information using a consensus algorithm (consensus management), and transmits it completely and consistently to the shared ledger (network communication) for recording and storage. The smart contract module is responsible for contract registration, publication, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, execution is triggered by calling keys or other events to complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation management module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization during product launch, such as alarms, network status management, and node device health status management.

[0067] Please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. The network architecture may include a blockchain network, which may consist of multiple blockchain nodes. This application does not limit the number of blockchain nodes included in the blockchain network. Figure 1 Taking six blockchain nodes as an example, the blockchain nodes in the network are networked in a P2P (Peer-to-Peer) manner, and the blockchain nodes can communicate with each other according to the P2P protocol. All blockchain nodes in the network jointly follow the broadcast mechanism and consensus mechanism to ensure the immutability and forgery resistance of data on the blockchain, while realizing the decentralized and trustless characteristics of the blockchain.

[0068] In this application, blockchain nodes in the blockchain network can be user terminals, servers, or a system composed of user terminals and servers; no limitation is made in this regard. User terminals can include, but are not limited to, electronic devices such as PCs (Personal Computers), smartphones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches and smart bracelets), smart voice interaction devices, smart home appliances (such as smart TVs), and in-vehicle devices.

[0069] A server can be a standalone physical server, 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 communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0070] A blockchain, jointly maintained by blockchain nodes in a blockchain network, can consist of a series of blocks, also known as data blocks. After a block is created, consensus processing needs to be performed in the blockchain network. Only when consensus on the block is successful can the block be added to the blockchain (i.e., the distributed ledger). Blocks in the blockchain can be linked together in a chain structure according to their creation timestamps from smallest to largest.

[0071] Consensus processing in a blockchain network is the process of ensuring consistency between the distributed ledgers of all blockchain nodes. All or some of the blockchain nodes in a blockchain system can participate in the consensus processing. These participating blockchain nodes collectively form the consensus committee of the blockchain network, and each participating blockchain node is a member of the consensus committee. In other words, the consensus committee of a blockchain network consists of multiple participating blockchain nodes, and the consensus processing in the blockchain network is executed by the blockchain nodes within the consensus committee.

[0072] Specifically, the consensus processing in a blockchain network can be implemented based on a consensus algorithm, which may include, but is not limited to, Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. This application does not limit the specific algorithms used. Each blockchain node in the consensus committee can execute the corresponding process of the consensus processing by running the consensus algorithm.

[0073] It's important to note that at a certain block height in a blockchain, one or more consensus processes are required to reach agreement among the various blockchain nodes in the consensus committee. Block height represents the number of blocks connected to the blockchain; it's a marker indicating the block's position within the blockchain. The default block height for the genesis block is 0. The first block after the genesis block has a block height of 1 (referred to as block 1), the second block after the genesis block has a block height of 2 (referred to as block 2), and so on. For example, if the current block height of a blockchain is 100 (referred to as block 100), this means that 100 blocks have been stacked on top of the genesis block, resulting in 101 blocks on the blockchain from the genesis block to block 100.

[0074] The consensus process at a specific block height in a blockchain refers to the process of reaching a consensus on blocks awaiting inclusion in the blockchain network when the blockchain is at that particular block height. If the consensus on the block to be included is successful, the block is added to the blockchain, and the block height is incremented by 1. For example, the consensus process at block height 10 refers to the process of reaching a consensus on blocks awaiting inclusion in the blockchain network when the blockchain is at block height 10. If the consensus on the block is successful, the block is added to the blockchain, changing the block height from 10 to 11.

[0075] A consensus process can be divided into three phases in sequence: the proposal phase, the first round of voting (also known as the pre-voting phase), and the second round of voting (also known as the pre-commit phase). The multiple blockchain nodes participating in the same consensus process within the consensus committee include two types: master nodes (also known as proposal nodes) and non-master nodes (also known as non-proposal nodes). A master node is a blockchain node elected by multiple blockchain nodes in the consensus committee. The master node is responsible for both generating blocks to be agreed upon during the proposal phase of the consensus process and broadcasting these blocks to other blockchain nodes in the consensus committee for consensus processing; it is also responsible for processing these blocks. Non-master nodes are only responsible for processing the blocks to be agreed upon. These blocks to be agreed upon can be new blocks created by the master node.

[0076] The consensus process includes a first round of voting and a second round of voting. The first round of voting occurs during the first voting phase, and the second round occurs during the second voting phase. The first round of voting refers to the process of whether to agree on the validity of the block. In this embodiment, the validity of the block can be determined by counting the number of dissenting nodes (i.e., opposing nodes) for each transaction in the block to be agreed upon. The second round of voting refers to the process of whether to agree to submit the block to be agreed upon. If the submission of the block to be agreed upon is agreed upon, it means confirming agreement to add the block to the blockchain.

[0077] Optionally, during multiple consensus processes at the same block height, the blockchain nodes participating in the consensus process may change each time the consensus process is changed, that is, the members of the consensus committee may change each time the consensus process is changed; the master node may change each time the consensus process is changed, and the blocks to be consensus may also change.

[0078] Please see Figure 2 , Figure 2 This is a schematic diagram of a block consensus processing method provided in an embodiment of this application. For example... Figure 2 As shown, assuming the current block height of the blockchain is M-1 (M is a positive integer greater than 1), the consensus committee of the blockchain network takes 4 blockchain nodes as an example, as shown in node set 20d, which can specifically include the master node, node A, node B and node D; the master node is a blockchain node elected by the 4 blockchain nodes in the consensus committee.

[0079] In the consensus processing of a blockchain network, the master node can select a batch of transactions (e.g., transactions TX0, TX1, and TX2) from its own transaction pool and encapsulate the selected batch of transactions into a block M awaiting consensus. Each blockchain node in the network can correspond to a transaction pool, which can be used to cache transactions received by the blockchain node. These transactions are all legitimate and not stored on the blockchain. The master node can select multiple transactions from its own transaction pool according to transaction selection rules, such as selecting transactions based on their timestamps or transaction fees, etc. This application does not limit the specific rules.

[0080] Block M can consist of a block header and a block body. The block header includes the digest value (i.e., the hash of the previous block) corresponding to the block with the highest block height (M-1) in the blockchain, and can also include the digest value of the current block M and the Merkle root of the current block M. The block body stores the complete transaction information of the current block M, such as the transaction data itself of the aforementioned transactions TX0, TX1, and TX2; or, the block body can store a Merkle tree (a binary tree) containing complete transaction information, the basic data of which is the hash value of the aforementioned transactions TX0, TX1, and TX2.

[0081] The master node can execute all transactions stored in the block body of block M, obtaining an execution result set 20b. This execution result set 20b can include the execution result of each transaction in block M by the master node. For example, executing transaction TX0 yields execution result r0, executing transaction TX1 yields execution result r1, executing transaction TX2 yields execution result r2, and so on. Furthermore, the master node can generate a proposal 20a based on block M and execution result 20b, and broadcast this proposal 20a throughout the blockchain network. This allows the remaining blockchain nodes in the consensus committee (including nodes A, B, and C) to access the proposal 20a and conduct two rounds of voting to reach consensus.

[0082] For ease of description, the following uses node A as an example to describe the two rounds of voting for proposal 20a. After obtaining proposal 20a, node A needs to determine the set of transactions 20c it needs to execute from the multiple transactions contained in block M. For example, the set of transactions 20c can only contain transactions TX0, TX1, and TX2 stored in block M; in other words, the other nodes in the consensus committee, except for the master node, only need to execute a portion of the transactions in block M during the consensus process, which can reduce resource consumption.

[0083] In this context, different blockchain nodes can execute different transactions for members of the consensus committee, and the number of transactions executed may also vary. That is, each blockchain node in the consensus committee needs to distribute the execution of multiple transactions in block M and ensure that each transaction can be executed by no less than a second number threshold. This second number threshold is determined by the consensus algorithm used in the consensus process. This second number threshold can also be used as one of the conditions for judging whether block M has reached a consensus.

[0084] Node A can execute transactions in transaction set 20c and obtain execution result set 20e. Execution result set 20e can include the execution result t0 of node A for transaction TX0, the execution result t1 of node A for transaction TX1, and the execution result t2 of node A for transaction TX2.

[0085] Furthermore, execution result sets 20b and 20e can be compared. If the execution results of the master node and node A for the same transaction are the same, it indicates that node A agrees with the transaction. If the execution results of the master node and node A for the same transaction are different, it indicates that node A does not agree with the transaction. For example, if execution result t0 is different from execution result r0, it means that node A does not agree with transaction TX0 in blockchain M. In this case, transaction TX0 and execution result t0 can be added to the set of opposing transactions (which may include transactions that node A does not agree with and their execution results). Through this set of opposing transactions, the first voting information 1 of node A in the first round of voting can be generated. It can be understood that if execution result t0 in execution result set 20e is the same as execution result r0 in execution result set 20b, execution result t1 is the same as execution result r1, and execution result t2 is the same as execution result r2, it indicates that node A does not have any transactions it does not agree with, and the set of opposing transactions is empty.

[0086] After generating the first vote information 1, node A can broadcast it throughout the blockchain network so that the other blockchain nodes in the consensus committee can access it. Similarly, the other blockchain nodes can also broadcast their first vote information after generating it in the first round of voting. Therefore, node A can collect the first vote information from each blockchain node in the consensus committee during the first round of voting, such as the first vote information 0 from the master node (since the master node is the blockchain node that generated proposal 20a, the set of opposing transactions in first vote information 0 can be considered empty), the first vote information 1 from node A, the first vote information 2 from node B, the first vote information 3 from node C, etc.

[0087] Node A can use the collected first voting information from various blockchain nodes to count the number of opposing nodes for each transaction in block M, i.e., the number of nodes in the consensus committee that disagree with the transaction. For example, if both the first voting information 1 and the first voting information 2 include transaction TX0, it indicates that the number of opposing nodes for transaction TX0 is 2. Based on the number of opposing nodes for each transaction, Node A can generate second voting information 1 for the second round of voting. This second voting information 1 also needs to be broadcast in the blockchain network. Second voting information 1 indicates whether Node A agrees to submit block M. If it agrees, second voting information 1 is a vote in favor; if it disagrees, it is a vote against. Similarly, after generating second voting information for the second round of voting, other blockchain nodes also need to broadcast it so that Node A can collect the second voting information from various blockchain nodes in the consensus committee during the second round of voting, such as the master node's second voting information 0, Node A's second voting information 1, Node B's second voting information 2, Node C's second voting information 3, etc.

[0088] Node A can count the number of affirmative votes from all the collected second voting information. If the number of affirmative votes meets the consensus condition, such as being greater than or equal to the aforementioned second threshold, then the consensus for block M is passed, and block M can be written into the blockchain. This completes the full consensus processing for proposal 20a. In this embodiment, the other blockchain nodes in the consensus committee, excluding the master node, only need to execute a portion of the transactions in the block to be consensused during the consensus processing, which reduces the number of transaction executions and thus reduces resource consumption.

[0089] Please see Figure 3 , Figure 3 This is a flowchart illustrating a transaction processing method in a blockchain network provided in an embodiment of this application. It can be understood that this method can be executed by blockchain nodes participating in consensus (e.g., a target node) in the blockchain network. Figure 3 As shown, the transaction processing method in this blockchain network may include at least the following steps S101-S103:

[0090] Step S101: Obtain the target proposal sent by the master node in the blockchain network; the target proposal includes a data block and the first execution result of the master node on the X transaction groups contained in the data block, where X is a positive integer.

[0091] Specifically, during the consensus process, the consensus committee in the blockchain network can elect a blockchain node as the master node. This master node can select batches of transactions from its own transaction pool and package them into data blocks to be agreed upon (e.g., Figure 3The corresponding block M in the embodiment), and generate a target proposal for the data block (e.g., Figure 3 In the corresponding embodiment, proposal 20a) is then broadcast so that all blockchain nodes in the consensus committee, except the master node, can obtain the target proposal and execute subsequent consensus processing procedures. In other words, all blockchain nodes except the master node can receive the target proposal and perform similar consensus processing operations on it after obtaining it. For ease of understanding, any blockchain node other than the master node can be selected as the target node, and the description will be based on the target node as an example.

[0092] Understandably, before executing step S101, the target node needs the master node to generate a target proposal and broadcast it in the blockchain network. The generation process of the target proposal may include: the master node can select a batch of transactions from its own transaction pool, package them into data blocks, and group the batch of transactions to form a transaction DAG (Directed Acyclic Graph). This transaction DAG represents the grouping of transactions with collaborative relationships within the batch, where transactions within a group have collaborative relationships, while transactions between groups do not. This allows for the serial execution of transactions within collaborative groups and the parallel execution of transactions in groups without collaborative relationships. The transaction DAG can divide the batch of transactions packaged by the master node into X transaction groups, each of which can include at least one transaction. That is, the number of transactions in the batch can be greater than or equal to X, where X is a positive integer, such as 1, 2, ...

[0093] The master node can execute all X transaction groups divided by the transaction DAG once, obtaining the execution result corresponding to each transaction group. In this embodiment, the execution result of the master node on the X transaction groups can be referred to as the first execution result. Then, based on the data block and the first execution results of each transaction group, a target proposal can be generated and broadcast in the blockchain network. In other words, the target proposal can include the data block and the first execution results of the master node on the X transaction groups contained in the data block.

[0094] Please see Figure 4 , Figure 4 This is a schematic diagram of a transaction grouping provided in an embodiment of this application. For example... Figure 4 As shown, the transaction set in the data block packaged by the master node can include transaction TX0, transaction TX1, transaction TX2, transaction TX3, transaction TX4, and transaction TX5. This transaction set can include a batch of transactions selected by the master node from the transaction pool, that is, a total of 6 transactions.

[0095] The master node can obtain the set of keys involved in each transaction in the transaction set. For example, the key set involved in transaction TX0 includes k1, k2, and k3; the key set involved in transaction TX1 includes k4 and k5; the key set involved in transaction TX2 includes k1 and k3; the key set involved in transaction TX3 includes k3; the key set involved in transaction TX4 includes k4; and the key set involved in transaction TX5 includes k6. Since transactions TX0, TX2, and TX3 all involve k3, it indicates that transactions TX0, TX2, and TX3 have a collaborative relationship. Therefore, transactions TX0, TX2, and TX3 can be divided into a transaction group, denoted as transaction group 30a. Similarly, transactions TX1 and TX4 can be divided into the same transaction group, denoted as transaction group 30b, and transaction TX5 can be divided into transaction group 30c. Transactions within the same transaction group must be executed serially. Transactions in different transaction groups can be executed in parallel or serially; this application does not impose any restrictions on this.

[0096] Step S102: Determine the Y transaction groups corresponding to the target node from the X transaction groups contained in the data block, and obtain the second execution result of the target node on the Y transaction groups; Y is a positive integer less than X.

[0097] Specifically, after receiving the target proposal broadcast by the master node, the target node can determine the Y transaction groups it needs to execute from the X transaction groups contained in the data block, and execute the Y transaction groups once to obtain the execution results corresponding to the Y transaction groups. In this embodiment, the execution results of the target node on the Y transaction groups can be referred to as the second execution result. The number of transaction groups executed by the target node is less than the number of transaction groups contained in the data block, i.e., Y is a positive integer less than X.

[0098] In the consensus processing, a transaction decentralization algorithm can be used to determine the transaction groups that the remaining blockchain nodes in the consensus committee, excluding the master node, need to execute. This ensures that different blockchain nodes can execute different transaction groups (i.e., decentralization of transaction group execution), and each transaction group can be executed by a certain number (e.g., a second threshold number) of blockchain nodes. This certain number can be determined by the consensus algorithm used in the blockchain network.

[0099] For example, when the consensus processing of a blockchain network uses the practical Byzantine algorithm, the number of blockchain nodes included in the consensus committee can be N, where N is a positive integer. In this case, N can satisfy N≥3f+1, where f represents the number of malicious nodes allowed in the practical Byzantine algorithm, also known as the upper limit of illegal nodes. Then, each transaction group in the data block needs to be executed by at least 2f+1 blockchain nodes.

[0100] In other words, the aforementioned transaction decentralization execution algorithm needs to simultaneously satisfy the following two conditions: ① ensuring that the blockchain nodes in the consensus committee decentralize the execution of transaction packets; ② ensuring that each transaction packet is executed by at least 2f+1 blockchain nodes. In each consensus process of the blockchain network, after the master node generates the target proposal, the transaction packets that each blockchain node in the consensus committee needs to execute can be determined based on the transaction decentralization execution algorithm. Therefore, based on this algorithm, the Y transaction packets that the target node needs to execute can be determined from the X transaction packets contained in the data block.

[0101] It is understood that the embodiments of this application do not limit the consensus algorithm and transaction distributed execution algorithm used in the consensus processing process. The transaction distributed execution algorithm only needs to satisfy the aforementioned two conditions at the same time. For ease of understanding, the embodiments of this application are described using the practical Byzantine algorithm as an example.

[0102] Step S103: Group the transactions whose first execution result and second execution result are different, add them to the target node's opposing transaction set, and generate the target node's first voting information based on the second execution result and the target node's opposing transaction set.

[0103] Specifically, after executing the aforementioned Y transaction groups, the target node can compare the first and second execution results. If the target node and the master node have the same execution result for the same transaction group, it indicates that the target node agrees with the transaction group. If the target node and the master node have different execution results for the same transaction group, it indicates that the target node does not agree with the transaction group, and can then add the disagreed transaction group to the target node's set of opposed transactions. Based on the target node's second execution result for the Y transaction groups and the target node's set of opposed transactions, the target node's first voting information in the first round of voting can be generated.

[0104] Optionally, the target node can add the transaction groups it disagrees with from the Y transaction groups, along with the corresponding second execution results, to its set of opposing transactions. This set of opposing transactions then generates the target node's first voting information. If the target node's second execution results for the Y transaction groups are identical to the master node's first execution results for the same Y transaction groups, it indicates that the target node agrees with the Y transaction groups, and in this case, the target node's set of opposing transactions is empty. In other words, the target node's set of opposing transactions can include transaction groups it disagrees with, or it can include transaction groups it disagrees with and their corresponding second execution results. The transaction groups included in the set of opposing transactions can be the transaction identifiers corresponding to those groups, rather than the transaction data itself. This reduces the amount of data transmitted when the generated first voting information is broadcast.

[0105] It should be noted that after generating the first vote, the target node can broadcast the first vote in the blockchain network so that other blockchain nodes (including the master node) in the consensus committee can obtain the target node's first vote and continue to execute the subsequent consensus processing. For example, each blockchain node can determine the number of opposing nodes corresponding to X transaction groups based on the received first vote.

[0106] Optionally, after generating the first voting information in the first voting phase, the blockchain nodes other than the target node in the consensus committee can also broadcast it. That is, in addition to receiving its own first voting information in the first voting phase, the target node can also collect the first voting information of the other blockchain nodes in the first voting phase. The first voting information involved in this application embodiment can refer to the voting information of each blockchain node in the consensus committee in the first voting phase of the consensus processing.

[0107] Step S104: Based on the first voting information corresponding to N nodes in the blockchain network, obtain the number of opposing nodes corresponding to each of the X transaction groups; N nodes include the main node and the target node, and N is a positive integer.

[0108] Specifically, after collecting the first vote information from each blockchain node in the consensus committee of the blockchain network, the target node can obtain the number of opposing nodes corresponding to each transaction group in the data block based on the first vote information of each blockchain node. When the consensus committee includes N blockchain nodes, the target node can count the number of opposing nodes corresponding to each transaction group based on the first vote information of the N nodes. Here, the N nodes can include the target node and the master node.

[0109] Optionally, in the actual consensus processing process, due to network failures or node anomalies, the target node may be unable to collect the first voting information of all nodes. In this case, the target node can enter the subsequent consensus processing process when it has collected 2f+1 first voting information; or it can collect the first voting information of each node within a pre-set time range, and enter the subsequent consensus processing process after the time range is exceeded.

[0110] Step S105: If the number of opposing nodes in X transaction groups is less than or equal to the first quantity threshold, then the second voting information of the target node on the data block is determined to be a positive vote; the positive vote is used to determine the consensus result of the data block in the blockchain network.

[0111] Specifically, a first quantity threshold can be obtained for the consensus algorithm (e.g., the Practical Byzantine Fault Tolerance algorithm) in the first round of voting during the consensus process. This first quantity threshold can be the upper limit of the number of illegitimate nodes. For example, the upper limit of the number of malicious nodes allowed by the Practical Byzantine Fault Tolerance algorithm can be denoted as f. The remaining nodes among N nodes, excluding illegitimate nodes, can be called legitimate nodes (or honest nodes). Therefore, the lower limit of the number of legitimate nodes can be 2f+1. In other words, the consensus committee can include at most f illegitimate nodes and at least 2f+1 legitimate nodes.

[0112] If the number of opposing nodes for all X transaction groups is less than or equal to the first threshold, it indicates that all legitimate nodes among the N nodes agree with the X transaction groups contained in the data block. The target node can generate its second voting information in the second round of voting, and this second voting information is a vote in favor. The target node's vote in favor can be used to indicate that the target node confirms its agreement to submit the data block.

[0113] If the number of opposing nodes for any of the X transaction groups is greater than the first threshold, it indicates that at least one legitimate node among the N nodes does not agree with the transaction group. The target node can generate a second voting message in the second round of voting, and the second voting message at this time is an opposing vote. The opposing vote of the target node can be used to indicate that the target node confirms its disapproval of submitting the data block.

[0114] It should be noted that the target node's second vote information in the second round of voting, whether it is a vote for or against, can be broadcast in the blockchain network. This allows the other nodes in the consensus committee of the blockchain network, excluding the target node, to obtain the target node's second vote information and execute subsequent consensus processing procedures. For example, based on all the collected second vote information, the number of votes for a data block can be determined, and this number of votes can be used to determine the final consensus result of the data block.

[0115] Understandably, after generating the second voting information in the second voting phase, blockchain nodes other than the target node in the consensus committee can also broadcast it. That is, the target node can not only receive its own second voting information in the second voting phase, but also collect the second voting information from other blockchain nodes in the second voting phase. The second voting information involved in this application embodiment can refer to the voting information of each blockchain node in the consensus committee during the second voting phase of the consensus processing.

[0116] In this embodiment, when a target node receives a target proposal from a master node, it can determine the Y transaction groups it needs to execute from the X transaction groups contained in the target proposal, and obtain the second execution result of the target node for the Y transaction groups. If the execution results of the target node and the master node for the same transaction group are different, it indicates that the target node opposes the transaction group and adds it to the set of opposing transactions. Based on the second execution result and the set of opposing transactions, the target node's first voting information can be generated. The target node can obtain the number of opposing nodes corresponding to each of the X transaction groups based on the first voting information collected from all nodes. If the number of opposing nodes is less than or equal to a first threshold, the target node can vote in favor of the data block in the target proposal (i.e., vote in favor), and determine the consensus result of the data block by counting the number of votes obtained. It can be seen that when performing consensus processing on the data block in the target proposal, the target node only needs to execute some of the transactions in the data block, rather than all of them. That is, the X transaction groups contained in the data block can be distributed and executed among N nodes, which can reduce the number of transaction executions in the blockchain network, thereby reducing resource consumption and improving the performance of the blockchain.

[0117] Please see Figure 5 , Figure 5 This is a flowchart illustrating another transaction processing method in a blockchain network provided in this application embodiment. It can be understood that this method can be executed by blockchain nodes participating in consensus (e.g., a target node) in the blockchain network. Figure 5As shown, the transaction processing method in this blockchain network may include at least the following steps S201-S211:

[0118] Step S201: Obtain the target proposal sent by the master node in the blockchain network; the target proposal includes a data block and the first execution result of the master node on the X transaction groups contained in the data block, where X is a positive integer.

[0119] For details on the implementation of step S201, please refer to [link / reference]. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0120] Step S202: Obtain the upper limit of the number of illegal nodes in the blockchain network, and determine the number of nodes to execute for each transaction group in the X transaction groups based on the upper limit of the number of illegal nodes.

[0121] Before executing step S202, the target node can also perform validity verification on the target proposal (e.g., signature verification process). This validity verification process may include: obtaining the digital signature of the target proposal from the master node; obtaining the node public key corresponding to the master node, decrypting the digital signature based on the node public key to obtain the first digest information; performing a hash operation on the data block using a hash algorithm to obtain the second digest information corresponding to the data block; if the first digest information and the second digest information are the same, then the target proposal is determined to be valid.

[0122] In other words, to prevent the target proposal from being maliciously tampered with during transmission, each master node in the blockchain network needs to generate a key pair (including the master node's private key and public key) before generating a proposal (e.g., the target proposal). The private key is managed by the master node itself, and the public key can be shared with all blockchain nodes in the blockchain network. When generating the target proposal, the master node can use its own private key to encrypt the block hash corresponding to the data block, generating a digital signature of the target proposal. The master node can then broadcast the target proposal carrying the digital signature throughout the blockchain network.

[0123] After obtaining the target proposal, the target node can acquire the digital signature of the target proposal from the master node and decrypt it using the master node's public key to obtain the first digest information corresponding to the digital signature. Then, it can use a hash algorithm (i.e., the hash algorithm used by the master node when generating block hashes) to perform a hash operation on the data block in the target proposal to obtain the second digest information corresponding to the data block. This second digest information can also be considered as the block hash of the data block recalculated by the target node. Optionally, since the block header of the data block contains the block hash of the current data block, the target node can also directly read the block hash of the current data block from the block header and use this block hash as the aforementioned second digest information. This way, the target node does not need to perform a hash operation on the data block again, saving resources and reducing time consumption.

[0124] If the first digest information is the same as the second digest information, it means that the target proposal sent by the master node to the target node is not a maliciously modified proposal, and the target proposal is valid. If the first digest information is different from the second digest information, it means that the target proposal sent by the master node to the target node may be a maliciously modified proposal, and the target proposal can be discarded.

[0125] It should be understood that before broadcasting the target proposal, the master node has already notified all blockchain nodes in the blockchain network (including the target node) of its node public key and the hash algorithm used to generate the data block. If the target proposal is tampered with, the digital signature received by the target node is not the original digital signature generated by the master node. Therefore, when the target node tries to decrypt the digital signature using the master node's node public key, it will be unable to solve the problem. The hash algorithm can include, but is not limited to, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.

[0126] If the target proposal obtained by the target node is valid, the transaction decentralization execution algorithm can be used to determine the transaction groups that each blockchain node in the consensus committee needs to execute. Specifically, the target node can obtain the upper limit of the number of illegitimate nodes in the blockchain network, that is, the number of nodes that can act maliciously in the consensus committee allowed by the consensus algorithm used by the blockchain network. For example, in the practical Byzantine algorithm, the upper limit of the number of illegitimate nodes is f, and the number of nodes participating in the consensus is N, and N satisfies N≥3f+1. N can also be expressed as the number of blockchain nodes included in the consensus committee. Usually, the number of nodes N participating in the consensus in the blockchain network is known, and the specific value of the upper limit of the number of illegitimate nodes can be determined by the aforementioned N≥3f+1; in other words, the upper limit of the number of illegitimate nodes can also be determined by the actual number of nodes N participating in the consensus in the blockchain network and the consensus algorithm.

[0127] The number of nodes executing each transaction group in a data block can be determined based on the maximum number of illegal nodes. For example, the number of nodes executing can be represented as 2f+1, which means that each transaction group must be executed by at least 2f+1 nodes.

[0128] Step S203: Based on the number of nodes to be executed and the X transaction groups contained in the data block, assign a set of transactions to be executed to each of the N nodes in the blockchain network; one node corresponds to one set of transactions, and the transaction sets corresponding to different nodes contain different transaction groups.

[0129] Specifically, based on the number of nodes executing and the X transaction groups contained in the data block, a set of transactions to be executed can be assigned to each of the N nodes in the consensus committee. The transaction sets corresponding to different nodes need to meet the condition of distributed execution, that is, the transaction sets corresponding to different nodes contain different transaction groups. Each node corresponds to one transaction set. The master node's transaction set includes all transaction groups in the data block, i.e., X transaction groups. The number of transaction groups in the transaction sets of the other N nodes (excluding the master node) is less than X, and the number of transaction groups contained in the transaction sets corresponding to different nodes may also differ.

[0130] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating the allocation of transaction groups within a data block, as provided in an embodiment of this application. Figure 6 The TX1 to TX8 shown can represent transactions contained in a data block, or they can be transaction groups that can be executed in parallel. Different transaction groups do not affect each other, in which case the number of transaction groups contained in the data block X = 8; for example Figure 6 The node A shown is the master node that generates the target proposal. The set of transactions that node A needs to execute includes TX1 to TX8, which means that all transaction groups in the data block need to be executed once.

[0131] When the number of nodes participating in consensus is 4 (N is 4 by default), the maximum number of illegal nodes, f, can be 1. This means that at most one illegal node is allowed out of the four nodes. It can be determined that each transaction group (transaction) in TX1 to TX8 can be executed by three nodes, thus allowing each node to be assigned a set of transactions to be executed. For example... Figure 6 As shown, the transaction set that node B needs to execute includes TX1, TX3, TX4, TX6, and TX7; the transaction set that node C needs to execute includes TX1, TX2, TX4, TX5, TX7, and TX8; and the transaction set that node D needs to execute includes TX2, TX3, TX5, TX6, and TX8. Figure 6The empty boxes shown indicate that the node does not need to execute the transaction group. For example, the transaction groups that node B does not need to execute are TX2, TX5, and TX8, and the transaction groups that node B does not need to execute are TX3, TX6, etc.

[0132] Optionally, when the number of nodes participating in consensus is 7 (N is 7 by default), the maximum number of illegal nodes, f, can be 2, meaning that a maximum of 2 illegal nodes are allowed out of 7 nodes. It can be determined that each transaction group (transaction) from TX1 to TX8 can be executed by 5 nodes. Therefore, the transaction set to be executed by node B includes TX1, TX4, TX5, TX6, and TX7; the transaction set to be executed by node C includes TX1, TX2, TX5, TX6, TX7, and TX8; the transaction set to be executed by node D includes TX1, TX2, TX3, TX6, TX7, and TX8; the transaction set to be executed by node E includes TX1, TX2, TX3, TX4, TX7, and TX8; the transaction set to be executed by node F includes TX2, TX3, TX4, TX5, and TX8; and the transaction set to be executed by node G includes TX3, TX4, TX5, and TX6.

[0133] As can be seen, all nodes other than the master node can execute fewer transaction groups, thus reducing the number of transaction executions. The transaction groups executed by different nodes are different, meaning that X transaction groups in a data block can be executed collaboratively by N nodes, which can improve the collaboration capabilities between blockchain nodes.

[0134] It should be noted that, Figure 6 The transaction group allocation method in the corresponding embodiment is only one example in the embodiments of this application. This application may also involve other allocation methods, for example, Figure 6 The application does not limit the scope of the transaction sets that need to be executed by nodes B and C shown in the figure, such as replacement.

[0135] Step S204: Based on the node identifier corresponding to the target node, obtain the first transaction set that matches the target node from the N transaction sets; the first transaction set includes Y transaction groups.

[0136] Specifically, based on the node identifier corresponding to the target node, a first transaction set matching the node identifier can be obtained from the transaction sets corresponding to the N nodes respectively. The first transaction set includes Y transaction groups, that is, the Y transaction groups in the first transaction set are the transaction groups that the target node needs to execute.

[0137] like Figure 6As shown, assuming node F among the 7 nodes is the target node, the first transaction set corresponding to the target node includes TX2, TX3, TX4, TX5, and TX8. That is, the target node only needs to execute 5 transaction groups. Compared with the master node (node ​​A), it executes 3 fewer transaction groups, which can reduce resource consumption.

[0138] Step S205: Obtain the i-th transaction group from the Y transaction groups corresponding to the target node, and obtain the contract information corresponding to the i-th transaction group; call the virtual machine program corresponding to the target node based on the contract information to obtain the second execution result corresponding to the i-th transaction group; i is a positive integer less than or equal to Y.

[0139] Specifically, after determining the Y transaction groups that the target node needs to execute, the target node can execute the Y transaction groups in parallel or serially. Transaction execution usually involves executing the contract information reflected in the transaction payload, which may include information such as contract name, method, and input parameters. The transaction execution process is usually carried out by calling a virtual machine program.

[0140] Specifically, for any one of the Y transaction groups corresponding to the target node (such as the i-th transaction group, where i is a positive integer less than or equal to Y), the contract information corresponding to the i-th transaction group can be obtained. Based on the contract name in the contract information, the virtual machine program corresponding to the target node can be called. According to the input parameters and methods in the contract information, the virtual machine program is run to obtain the second execution result corresponding to the i-th transaction group.

[0141] Step S206: Group the transactions whose first execution result and second execution result are different, add them to the target node's set of opposing transactions, and generate the target node's first voting information based on the second execution result and the target node's set of opposing transactions.

[0142] Specifically, if the execution result of the target node on Y transaction groups (the second execution result) differs from the execution result of the master node on Y transaction groups (the first execution result), it indicates that the target node disagrees with at least one of the Y transaction groups. The transaction groups that the target node disagrees with can be added to the target node's set of objected transactions. In other words, transaction groups whose first and second execution results differ can be considered as transaction groups that the target node disagrees with, and these disagreed transaction groups all need to be added to the target node's set of objected transactions. Based on the target node's set of objected transactions and the second execution result corresponding to the disagreed transaction groups, the target node's first voting information in the first round of voting is generated. Optionally, the second execution result corresponding to the disagreed transaction groups can also be added to the target node's set of objected transactions, thereby generating the target node's first voting information in the first round of voting based on the target node's set of objected transactions.

[0143] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a first voting information provided in an embodiment of this application. For example... Figure 7 As shown, in the first round of voting in the consensus process, the block hash of the data block can be adjusted into a special voting structure. This structure can reflect the target node's execution of Y transaction groups. For example, the target node's first voting information may include: the block hash of the data block in the target proposal actually received by the target node, the digital signature of the master node on the target proposal (the signature obtained by encrypting the block hash using the master node's private key), and the target node's set of transactions it does not agree with (i.e., the set of transactions it opposes).

[0144] The inclusion of block hashes and digital signatures in the first voting information prevents the master node from maliciously sending different proposals to different nodes, thus preventing malicious actions by the master node. The set of transactions not agreed upon can include the transaction identifiers (transaction IDs) of the transaction groups that the target node does not agree upon, as well as the local execution results corresponding to the unacknowledged transaction groups (i.e., the execution results of the target node on the unacknowledged transaction groups, i.e., the second execution result). It should be noted that... Figure 7 The structure of the first voting information shown is merely an example in the embodiments of this application, and this application does not limit the structural form of the first voting information.

[0145] In one or more embodiments, during the consensus processing of the target proposal, in addition to executing Y transaction packets and determining the difference between the second execution result of the target node on the Y transaction packets and the first execution result of the master node on the Y transaction packets, the target node also needs to perform one or more of the following verification processes on the target proposal: verifying the validity of the master node, verifying the validity of the digital signature carried by the target proposal (the correctness of the digital signature can be verified by the master node's public key, and the specific process can be referred to the relevant description in the aforementioned step S201, which will not be repeated here), verifying the validity of the Merkle tree root in the block header of the data block, and verifying the validity of each transaction contained in the data block, etc.

[0146] Specifically, when the master node belongs to the consensus committee and is a blockchain node elected by the consensus committee during the current consensus process, it is considered a valid master node. When the master node no longer belongs to the consensus committee, or is not a blockchain node elected by the consensus committee during the current consensus process, it is considered an invalid master node. The target node recalculates the Merkle root corresponding to the data block. If the recalculated Merkle root is the same as the Merkle root in the block header, it indicates that the Merkle root in the block header is valid; if the recalculated Merkle root is different from the Merkle root in the block header, it indicates that the Merkle root in the block header is invalid. All the verification results described above can be added to the target node's first voting information.

[0147] Step S207: Traverse the X transaction groups contained in the data block and obtain the j-th transaction group among the X transaction groups; j is a positive integer less than or equal to X.

[0148] Specifically, the target node can collect the first voting information from N nodes in the blockchain network during the first round of voting. When the number of first voting information collected by the target node reaches the number of nodes to be executed (2f+1), it can enter the subsequent consensus processing flow, such as traversing the X transaction groups contained in the data block, obtaining the j-th transaction group among the X transaction groups, and counting the number of opposing nodes corresponding to the j-th transaction group from the set of opposing transactions contained in the collected first voting information, where j is a positive integer less than or equal to X.

[0149] In one or more embodiments, when a target node collects first voting information, it needs to verify the legality of the first voting information received from each node. For example, when the target node receives the first voting information broadcast by node a, it can obtain the first transaction identifier indicated by the execution result in node a's first voting information; obtain the second transaction set allocated to node a from X transaction groups; obtain the second transaction identifier corresponding to the transaction group in the second transaction set; if the first transaction identifier and the second transaction identifier are the same, then it is determined that node a's first voting information is legal; if the first transaction identifier and the second transaction identifier are different, then it is determined that node a's first voting information is not legal, and the first voting information of node a is deleted.

[0150] In this context, node a can be any blockchain node out of the N nodes, excluding the target node and the master node. The second transaction set can include transaction groups assigned to node a using a transaction decentralization execution algorithm. The target node can verify whether the transaction group actually executed by node a is the same as the transaction group in the pre-assigned second transaction set. If they are the same, it indicates that node a's first voting information is legitimate, and it is cached. If they are different, it indicates that node a did not have the authority to execute a certain transaction group but executed it, and it can be determined that node a's first voting information is illegitimate.

[0151] Step S208: In the set of opposing transactions contained in the first voting information of N nodes, determine the statistical number of the set of opposing transactions containing the j-th transaction group, and determine the statistical number as the number of opposing nodes of the j-th transaction group.

[0152] Specifically, the target node can determine the statistical number of the set of opposing transactions containing the j-th transaction group from the set of opposing transactions included in the first voting information collected, and determine the statistical number as the number of opposing nodes of the j-th transaction group.

[0153] After obtaining the number of opposing nodes for the j-th transaction group, we can continue to count the number of opposing nodes for the next transaction group in the X transaction groups, until we obtain the number of opposing nodes for each of the X transaction groups.

[0154] Step S209: If the number of opposing nodes in X transaction groups is less than or equal to the first quantity threshold, then the second voting information of the target node for the data block is determined to be a positive vote.

[0155] For details on the implementation of step S209, please refer to [link / reference]. Figure 3 Step S105 in the corresponding embodiment will not be described again here.

[0156] Optionally, if the number of opposing nodes in any of the X transaction groups exceeds a first threshold, then the target node's second vote on the data block is determined to be an opposing vote. Since the number of opposing nodes in the X transaction groups is obtained in traversal order, once the number of opposing nodes in a certain transaction group is found to be greater than the first threshold, it is unnecessary to count the opposing nodes in subsequent transaction groups and determine the target node's second vote on the data block as an opposing vote.

[0157] Step S210: Obtain the second voting information of N nodes on the data block, and count the number of positive votes in the second voting information of N nodes.

[0158] Specifically, the target node can collect the second voting information of N nodes in the blockchain network on the data block. That is, the target node can collect the second voting information of each node in the second round of voting. When the number of second voting information collected by the target node reaches the number of nodes executed (2f+1), it can enter the subsequent consensus processing process, such as counting the number of positive votes in the collected second voting information.

[0159] Step S211: If the number of votes in favor is greater than or equal to the second threshold, the consensus result of the data block in the blockchain network is determined to be successful, and the data block is added to the blockchain.

[0160] Specifically, if the number of votes in favor is greater than or equal to the second threshold (2f+1), the consensus result of the data block in the blockchain network can be determined as a successful consensus, that is, the data block has reached a consensus in the consensus committee and can be added to the blockchain.

[0161] Optionally, if the number of votes in favor is less than a second threshold, the consensus result of the data block in the blockchain network is determined to be a consensus failure, meaning the data block has not reached a consensus in the consensus committee, and the target proposal can be deleted. Then, a new master node can be determined from N nodes to generate the proposal to be agreed upon, and the block height corresponding to this proposal is the same as the block height of the data block. The newly determined master node can be the same as or different from the master node that generated the target proposal. After the new master node is determined, another consensus process is required for the same block height.

[0162] Please see Figure 8 , Figure 8 This is a flowchart illustrating the proposal consensus processing in a blockchain network, as provided in an embodiment of this application. Figure 8As shown, the blockchain nodes participating in the proposal consensus processing in the blockchain network include the master node, node 1, node 2, and node 3, that is, the consensus committee includes the above four blockchain nodes. This embodiment of the application describes the proposal consensus processing process using the Practical Byzantine Fault Tolerance (PBT) algorithm as an example. The PBT consensus processing process may include the following steps:

[0163] Step S11: Pack the blocks and generate the transaction DAG and transaction execution results.

[0164] Specifically, in the proposal consensus processing of the blockchain network, the consensus committee can first select a blockchain node as the master node. This master node can select batch transactions from its own transaction pool, package the selected batch transactions into blocks (the aforementioned data blocks), and generate a transaction DAG and transaction execution results (i.e., the first execution result) for all transactions contained in the block. The transaction DAG can be used to indicate how to divide all transactions in the block into multiple transaction groups, such as X transaction groups, and obtain the master node's transaction execution result for each transaction group.

[0165] The master node can generate a proposal (i.e., the target proposal) to be reached for consensus based on the packaged blocks, transaction DAG, and transaction execution results, and broadcast the proposal in the blockchain network so that the other blockchain nodes participating in the consensus (e.g., node 1, node 2, and node 3) can receive the proposal.

[0166] Step S12: Based on the algorithm, determine the set of transactions executed by the current node and verify the transactions.

[0167] Specifically, after receiving the proposal broadcast by the master node, nodes 1, 2, and 3 can perform the same operations. For example, they can determine the set of transactions they need to execute based on the transaction distribution execution algorithm and verify the transaction groups contained in that set (e.g., Y transaction groups that the target node needs to execute). The number of transaction groups in the transaction sets that nodes 1, 2, and 3 need to execute is less than the number of transaction groups contained in the block.

[0168] Taking Node 1 of the three nodes mentioned above as an example, after determining the set of transactions it needs to execute based on the transaction distributed execution algorithm, Node 1 can execute the transaction groups in the transaction set and obtain the local execution result of Node 1 for the transaction groups in the transaction set (e.g., the second execution result). When the local execution result of Node 1 for the transaction set is the same as the transaction execution result of the master node for the transaction set, it means that the transaction set has been verified, that is, Node 1 agrees with the transaction set. When the local execution result of Node 1 for the transaction set is different from the transaction execution result of the master node for the transaction set, the transaction groups whose local execution results are different from the transaction execution results of the master node, and their local execution results can be combined into an opposing transaction set. Based on the opposing transaction set, the first round of voting (i.e., the first voting information) of Node 1 in the consensus processing process can be generated.

[0169] After generating their respective first-round votes, nodes 1, 2, and 3 can broadcast their first-round votes, allowing each node to not only hold its own first-round vote but also collect the first-round votes from other nodes. The broadcast content of the first-round votes can include whether the node approves of its own transaction group and the set of transactions it disapproves of (the set of opposing transactions). In this embodiment, "approval" has the same meaning as the aforementioned "recognition."

[0170] Step S13: Collect votes and determine whether there are f+1 or more dissenting votes for each group of transactions.

[0171] Specifically, the master node, node 1, node 2, and node 3 can all collect the first round of votes from each node and count the opposing votes (i.e., the number of opposing nodes) for each group of transactions in the block. If the number of opposing votes for each group of transactions is less than f+1 (equivalent to less than or equal to f, where f can be the first quantity threshold), then the node can generate a second round of votes (second voting information) in the consensus process as a vote in favor. If there is a group of transactions with more than or equal to f+1 opposing votes, then the node can generate a second round of votes in the consensus process as a vote in favor.

[0172] After generating their respective second-round votes, the master node, node 1, node 2, and node 3 can broadcast their second-round votes. This allows these four nodes to not only hold their own second-round votes but also collect votes from the other nodes. The broadcast content can include each node's vote on whether they approve or disapprove of the block.

[0173] Step S14: Collect votes and determine whether the voting information satisfies the rule greater than 2f.

[0174] Specifically, the master node, node 1, node 2, and node 3 can all collect the second round of votes from each node. When the number of affirmative votes in the second round of voting is greater than 2f (equivalent to greater than or equal to 2f+1, where 2f+1 can be the second threshold), it means that the block consensus has been passed.

[0175] If the number of affirmative votes in the second round of voting is less than or equal to 2f, it means that the block consensus has not been passed and the proposal can be deleted.

[0176] Step S15: Write the block to the ledger.

[0177] Specifically, once the block consensus is passed, the block can be written into the blockchain.

[0178] In this embodiment of the application, after collecting the first round of votes from each node during the consensus processing, instead of simply judging them, the execution status of each transaction group is summarized, and the opposing votes are aggregated. Only when it is confirmed that at least one legitimate node has voted against it can a vote be cast against the block. This consensus processing reduces the number of transactions executed by each node, thus lowering resource consumption.

[0179] Please see Figure 9 , Figure 9 This is a flowchart illustrating a consensus processing procedure in a blockchain network, as provided in an embodiment of this application. Figure 9 As shown, taking any blockchain node participating in the consensus processing process in the blockchain network as an example, the consensus processing process is described. It is assumed that the consensus algorithm used in the consensus processing process is the practical Byzantine algorithm. The consensus processing process can be implemented through the following steps S301 to S319.

[0180] Step S301: Enter a new height consensus processing process (or a new round of consensus at the same height). After completing one consensus processing cycle, any blockchain node in the consensus committee of the blockchain network can enter a new height consensus processing process, or a new round of consensus at the same height.

[0181] When a block consensus in the blockchain network is successful, it means that the current consensus processing flow is complete and the process can proceed to a new consensus processing flow at the same height. When a block consensus in the blockchain network fails, it means that the current consensus processing flow is complete and the process can proceed to a new round of consensus at the same height.

[0182] If the current node (any blockchain node in the consensus committee, such as the target node) is the master node, then proceed to the next steps S302-S305; if the current node is not the master node, then proceed to the next steps S306-S309.

[0183] Step S302: Obtain batch transactions.

[0184] Step S303: Batch transaction generation DAG execution, and block generation.

[0185] Step S304: Package the block into a proposal and broadcast it to other nodes.

[0186] Step S305: Wait for the collection of voting information, which has reached 2f+1.

[0187] If the current node is the master node, it can obtain batch transactions from its own transaction pool, generate a transaction DAG based on the obtained batch transactions, execute each transaction group indicated by the transaction DAG, and obtain the transaction execution result corresponding to each transaction group.

[0188] The current node can also package the acquired batch transactions into blocks (i.e., the data blocks mentioned above). Based on the packaged blocks and the transaction execution results of each transaction group, a proposal (target proposal) awaiting consensus can be generated. In this blockchain network, the current node can broadcast the proposal awaiting consensus to other nodes so that other nodes can receive the proposal broadcast by the current node.

[0189] After the current node broadcasts the proposal to other nodes, it can wait to collect voting information from each participating node. This voting information can be understood as the first round of voting (first voting information) by each node in the consensus process. Before the current node has collected 2f+1 votes, it cannot continue to execute the subsequent consensus process. In other words, only when the current node has collected 2f+1 votes can it enter the subsequent consensus process.

[0190] Step S306: Wait for the master node to send the proposal.

[0191] Step S307: Calculate the set of transactions that need to be verified according to the algorithm.

[0192] Step S308: Execute the transaction set and generate the execution result.

[0193] Step S309: Generate voting information and broadcast the voting information.

[0194] If the current node is not the master node, it can wait for the master node to send a proposal. When the master node broadcasts its generated proposal to other nodes, the current node can receive the proposal sent by the master node. Based on the transaction distribution execution algorithm, the set of transactions that the current node needs to verify can be determined. For example, from the X transaction groups contained in the block of the proposal, the current node can determine Y transaction groups that it needs to verify, where Y is a positive integer less than X. That is, the transaction groups that the current node needs to verify are only a part of the transaction groups contained in the block, not all of them.

[0195] Furthermore, the current node can execute transaction groups within the transaction set, generating an execution result (second execution result, also known as a local execution result) for each transaction group in the transaction set. Based on the master node's transaction execution results and the current node's execution results for the transaction set, transaction groups that are not agreed upon by the current node can be identified. Using these disagreed transaction groups and their execution results, the current node's voting information can be generated—its first round of voting in the consensus process. The current node can broadcast its generated voting information so that all participating nodes can collect it.

[0196] Optionally, the current node can also receive voting information broadcast by other nodes (first round of voting). Upon receiving voting information from other nodes, it needs to determine whether the voting information is valid. If the voting information is valid, it can be cached, and step S305 can continue. If the voting information is invalid, it can be discarded. The validity verification of the voting information refers to whether the other nodes that generated the voting information have the authority to verify the transaction group indicated by the voting information.

[0197] Step S310: Traverse the transaction groups.

[0198] When the number of votes collected by the current node in the first round reaches 2f+1, the current node can traverse the transaction groups contained in the block. For any transaction group in the block, it can determine whether the number of dissenting nodes (opposing nodes) of the transaction group is greater than f. If the number of dissenting nodes of the transaction group is less than or equal to f, then continue to execute steps S311-S313; if the number of dissenting nodes of the transaction group is greater than f, then continue to execute steps S314 and S313.

[0199] Step S311: The entire group approves.

[0200] Step S312: All votes are in favor, generating voting information (votes in favor).

[0201] Step S313: Broadcast voting information.

[0202] If the number of nodes disagreeing with a transaction group is less than or equal to f, it means that all nodes participating in the consensus have accepted the master node's execution result for that transaction group; that is, all nodes participating in the consensus approve the transaction group, and the process can continue to traverse the transaction groups contained in the block. When all transaction groups in a block have received unanimous approval from the nodes participating in the consensus, the current node's voting information (approval vote) can be generated, which is the second round of voting by the current node in the consensus process. The current node can broadcast its generated approval vote so that all nodes participating in the consensus can collect the current node's approval vote.

[0203] Step S314: Generate voting information (no votes).

[0204] If the number of dissenting nodes in the transaction group is greater than f, it means that at least one legitimate node among the consensus participants has voted against it (a dissenting vote). This generates the current node's voting information (a dissenting vote, i.e., a dissenting vote). This dissenting vote is still the current node's second round of voting in the consensus process. The current node can broadcast its generated dissenting vote so that all participating nodes can collect it.

[0205] Step S315: Wait for the number of votes collected to reach 2f+1.

[0206] Step S316: Write the block to the ledger.

[0207] Step S317: Enter the new height consensus processing flow.

[0208] Step S318: Abandon this proposal.

[0209] Step S319: Continue the next consensus processing flow for this height.

[0210] When the current node collects 2f+1 votes in the second round, it can count the number of affirmative votes (the number of affirmative votes) and determine if the number of affirmative votes is greater than or equal to 2f+1. If the number of affirmative votes is greater than or equal to 2f+1, it indicates that the block consensus is successful, and the block can be written to the ledger (i.e., the blockchain) and enter the new height consensus processing flow. If the number of affirmative votes is less than 2f+1, it indicates that the block consensus has failed, the proposal is abandoned, and the next consensus processing flow continues at the current height.

[0211] In this embodiment, when the target node receives the target proposal sent by the master node, it can determine the Y transaction groups that the target node needs to execute from the X transaction groups contained in the target proposal, and obtain the second execution result of the target node for the Y transaction groups. If the execution results of the target node and the master node for the same transaction group are different, it means that the target node opposes the transaction group and adds the transaction group to the opposition transaction set. Based on the second execution result and the opposition transaction set, the first voting information of the target node can be generated. The target node can obtain the number of opposing nodes corresponding to the X transaction groups based on the first voting information of all nodes collected. If the number of opposing nodes is less than or equal to the first quantity threshold, the target node can vote in favor of the data block in the target proposal (i.e., vote in favor), and determine the consensus result of the data block by counting the number of votes in favor. It is evident that when processing the data blocks in the target proposal for consensus, the target node only needs to execute a portion of the transactions in the data block, rather than all of them. That is, the X transaction groups contained in the data block can be distributed and executed among N nodes, which can reduce the number of transactions executed in the blockchain network, thereby reducing resource consumption and improving the performance of the blockchain. In addition, by distributing the execution of the X transaction groups in the data block among N nodes, the collaboration ability between nodes can be improved.

[0212] It is understood that in the specific implementation of this application, relevant information in the transaction (transaction account, account balance, etc.) may be involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from relevant users is required, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0213] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a transaction processing device in a blockchain network provided in an embodiment of this application. It can be understood that the transaction processing device 1 in this blockchain network can be applied to any blockchain node participating in block consensus within the blockchain network; such as... Figure 10 As shown, the transaction processing device 1 in the blockchain network may include: a proposal acquisition module 11, a transaction execution module 12, a first voting module 13, a voting statistics module 14, and a second voting module 15;

[0214] The proposal acquisition module 11 is used to acquire the target proposal sent by the master node in the blockchain network; the target proposal includes a data block and the first execution result of the master node on the X transaction groups contained in the data block, where X is a positive integer;

[0215] The transaction execution module 12 is used to determine the Y transaction groups corresponding to the target node from the X transaction groups contained in the data block, and obtain the second execution result of the target node on the Y transaction groups; Y is a positive integer less than X;

[0216] The first voting module 13 is used to group transactions whose first execution results and second execution results are different, add them to the target node's set of opposing transactions, and generate the target node's first voting information based on the second execution result and the target node's set of opposing transactions.

[0217] The voting statistics module 14 is used to obtain the number of opposing nodes corresponding to each of the X transaction groups based on the first voting information corresponding to N nodes in the blockchain network; the N nodes include the main node and the target node, and N is a positive integer;

[0218] The second voting module 15 is used to determine the target node's second voting information for the data block as a positive vote if the number of opposing nodes in X transaction groups is less than or equal to the first quantity threshold; the positive vote is used to determine the consensus result of the data block in the blockchain network.

[0219] The specific implementation methods of the proposal acquisition module 11, transaction execution module 12, first voting module 13, voting statistics module 14, and second voting module 15 can be found in [reference needed]. Figure 3 Steps S101-S105 in the corresponding embodiments will not be described again here.

[0220] In one or more embodiments, the transaction processing device 1 in the blockchain network further includes: a signature acquisition module 16, a decryption module 17, a hash calculation module 18, and a validity determination module 19;

[0221] The signature acquisition module 16 is used to acquire the digital signature of the target proposal by the master node.

[0222] Decryption module 17 is used to obtain the node public key corresponding to the master node, and decrypt the digital signature based on the node public key to obtain the first digest information;

[0223] Hash operation module 18 is used to perform hash operation on data blocks using a hash algorithm to obtain the second digest information corresponding to the data blocks;

[0224] The validity determination module 19 is used to determine that the target proposal is valid if the first summary information and the second summary information are the same.

[0225] The specific implementation methods of the signature acquisition module 16, decryption module 17, hash operation module 18, and validity determination module 19 can be found in [reference needed]. Figure 5 The relevant descriptions of step S201 in the corresponding embodiments will not be repeated here.

[0226] In one or more embodiments, the transaction execution module 12 includes: a node execution quantity determination unit 121, a transaction allocation unit 122, a contract information acquisition unit 123, and a virtual machine program invocation unit 124;

[0227] The node execution number determination unit 121 is used to obtain the upper limit of the number of illegal nodes in the blockchain network, and determine the number of nodes to be executed for each transaction group in X transaction groups based on the upper limit of the number of illegal nodes.

[0228] The transaction allocation unit 122 is used to allocate a set of transactions to be executed to N nodes in the blockchain network according to the number of nodes to be executed and the X transaction groups contained in the data block; one node corresponds to one transaction set, and the transaction sets corresponding to different nodes contain different transaction groups;

[0229] The transaction allocation unit 122 is further configured to obtain a first transaction set that matches the target node from among N transaction sets based on the node identifier corresponding to the target node; the first transaction set includes Y transaction groups.

[0230] The contract information acquisition unit 123 is used to acquire the i-th transaction group from the Y transaction groups corresponding to the target node, and to acquire the contract information corresponding to the i-th transaction group; i is a positive integer less than or equal to Y;

[0231] The virtual machine program calling unit 124 is used to call the virtual machine program corresponding to the target node based on the contract name in the contract information, run the virtual machine program according to the input parameters and methods in the contract information, and obtain the second execution result corresponding to the i-th transaction group.

[0232] The specific implementation methods of the node execution quantity determination unit 121, transaction allocation unit 122, contract information acquisition unit 123, and virtual machine program invocation unit 124 can be found in [reference needed]. Figure 5 Steps S202-S205 in the corresponding embodiments will not be described again here.

[0233] In one or more embodiments, the transaction processing device 1 in the blockchain network further includes: a voting broadcasting module 20;

[0234] The voting broadcast module 20 is used to broadcast the first voting information of the target node in the blockchain network, so that the other nodes in the blockchain network, excluding the target node, can determine the number of opposing nodes corresponding to each of the X transaction groups based on the received first voting information.

[0235] Optionally, the N nodes in the blockchain network include node a;

[0236] The transaction processing device 1 in the blockchain network also includes: a first transaction identifier acquisition module 21, a second transaction identifier acquisition module 22, and a transaction legality verification module 23;

[0237] The first transaction identifier acquisition module 21 is used to receive the first voting information broadcast by node a and acquire the first transaction identifier indicated by the execution result in the first voting information of node a;

[0238] The second transaction identifier acquisition module 22 is used to acquire the second transaction set allocated to node a from X transaction groups, and to acquire the second transaction identifier corresponding to the transaction group in the second transaction set;

[0239] The transaction legality verification module 23 is used to determine that the first voting information of node a is legal if the first transaction identifier is the same as the second transaction identifier;

[0240] The aforementioned transaction legality verification module 23 is also used to determine that the first voting information of node a is not legal if the first transaction identifier is different from the second transaction identifier, and to delete the first voting information of node a.

[0241] The specific implementation of the voting broadcast module 20 can be found in [link to relevant documentation]. Figure 3 For the specific functional implementation of step S103 in the corresponding embodiment, the first transaction identifier acquisition module 21, the second transaction identifier acquisition module 22, and the transaction legality verification module 23 can be found in [reference needed]. Figure 5 Step S207 in the corresponding embodiment will not be described again here.

[0242] In one or more embodiments, the voting statistics module 14 includes: a transaction traversal unit 141 and an opposition count statistics unit 142;

[0243] Transaction traversal unit 141 is used to traverse the X transaction groups contained in the data block and obtain the j-th transaction group among the X transaction groups; j is a positive integer less than or equal to X;

[0244] The opposition quantity statistics unit 142 is used to determine the statistical quantity of the opposition transaction set containing the j-th transaction group in the opposition transaction set contained in the first voting information of N nodes, and to determine the statistical quantity as the number of opposition nodes of the j-th transaction group.

[0245] The specific implementation methods of the transaction traversal unit 141 and the objection count counting unit 142 can be found in [reference]. Figure 5 Steps S207 to S208 in the corresponding embodiments will not be described again here.

[0246] In one or more embodiments, the transaction processing device 1 in the blockchain network further includes: a module for determining opposing votes 24, a module for counting the number of affirmative votes 25, a consensus passing module 26, a consensus failure module 27, and a master node selection module 28;

[0247] The opposing vote determination module 24 is used to determine the second voting information of the target node on the data block as an opposing vote if the number of opposing nodes in any of the X transaction groups is greater than the first quantity threshold.

[0248] The aforementioned voting broadcast module 20 is also used to broadcast the second voting information of the target node in the blockchain network, so that the other nodes in the blockchain network, excluding the target node, can determine the number of votes in favor of the data block based on the received second voting information.

[0249] The "Affirmative Votes" counting module 25 is used to obtain the second voting information of N nodes on the data block and count the number of "Affirmative Votes" in the second voting information of N nodes.

[0250] The consensus mechanism, through module 26, determines that if the number of votes in favor is greater than or equal to a second threshold, the consensus result of the data block in the blockchain network is successful, and the data block is added to the blockchain.

[0251] Consensus failure module 27 is used to determine that the consensus result of the data block in the blockchain network is a consensus failure if the number of votes in favor is less than the second threshold, and to delete the target proposal.

[0252] The master node selection module 28 is used to re-determine the master node for generating the consensus proposal from N nodes; the block height corresponding to the consensus proposal is the same as the block height of the data block.

[0253] The specific implementation methods of the following modules can be found in: Module 24 for determining the opposition vote, Module 25 for counting the number of affirmative votes, Module 26 for consensus passage, Module 27 for consensus failure, and Module 28 for master node selection. Figure 5 Steps S209-S211 in the corresponding embodiments will not be described again here.

[0254] In this embodiment, when the target node receives the target proposal sent by the master node, it can determine the Y transaction groups that the target node needs to execute from the X transaction groups contained in the target proposal, and obtain the second execution result of the target node for the Y transaction groups. If the execution results of the target node and the master node for the same transaction group are different, it means that the target node opposes the transaction group and adds the transaction group to the opposition transaction set. Based on the second execution result and the opposition transaction set, the first voting information of the target node can be generated. The target node can obtain the number of opposing nodes corresponding to the X transaction groups based on the first voting information of all nodes collected. If the number of opposing nodes is less than or equal to the first quantity threshold, the target node can vote in favor of the data block in the target proposal (i.e., vote in favor), and determine the consensus result of the data block by counting the number of votes in favor. It is evident that when processing the data blocks in the target proposal for consensus, the target node only needs to execute a portion of the transactions in the data block, rather than all of them. That is, the X transaction groups contained in the data block can be distributed and executed among N nodes, which can reduce the number of transactions executed in the blockchain network, thereby reducing resource consumption and improving the performance of the blockchain. In addition, by distributing the execution of the X transaction groups in the data block among N nodes, the collaboration ability between nodes can be improved.

[0255] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 11 As shown, the computer device 1000 can be a user terminal or a server; this is not a limitation. For ease of understanding, this application takes the computer device as a user terminal as an example. The computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk storage device. The memory 1005 may optionally be at least one storage device located remotely from the aforementioned processor 1001. Figure 11 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0256] The network interface 1004 in the computer device 1000 can also provide network communication functions, and the optional user interface 1003 can also include a display screen and a keyboard. Figure 11 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0257] Obtain the target proposal sent by the master node in the blockchain network; the target proposal includes a data block and the first execution result of the master node on X transaction groups contained in the data block, where X is a positive integer;

[0258] Determine the Y transaction groups corresponding to the target node from the X transaction groups contained in the data block, and obtain the second execution result of the target node on the Y transaction groups; Y is a positive integer less than X;

[0259] Transactions with different first and second execution results are grouped and added to the target node's set of opposing transactions. Based on the second execution result and the target node's set of opposing transactions, the target node's first voting information is generated.

[0260] Based on the first vote information corresponding to N nodes in the blockchain network, obtain the number of opposing nodes corresponding to X transaction groups respectively; N nodes include the main node and the target node, and N is a positive integer;

[0261] If the number of opposing nodes in X transaction groups is less than or equal to the first quantity threshold, then the second voting information of the target node on the data block is determined to be a positive vote; the positive vote is used to determine the consensus result of the data block in the blockchain network.

[0262] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 , Figure 5 as well as Figure 9 The description of the transaction processing method in the blockchain network in any of the corresponding embodiments can also be executed as described above. Figure 10 The description of the transaction processing device 1 in the blockchain network in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0263] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the transaction processing device 1 in the blockchain network mentioned above. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 5 as well as Figure 9 The description of the transaction processing method in the blockchain network in any corresponding embodiment is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed and executed on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network. These multiple computing devices distributed across multiple locations and interconnected via a communication network can constitute a blockchain system.

[0264] Furthermore, it should be noted that this application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, causing the computer device to perform the aforementioned actions. Figure 3 , Figure 5 as well as Figure 9 The description of the transaction processing method in the blockchain network in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0265] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0266] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0267] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0268] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0269] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A transaction processing method in a blockchain network, characterized in that, include: Retrieve the target proposal sent by the master node in the blockchain network; The target proposal includes a data block and the first execution result of the master node on the X transaction groups contained in the data block, where X is a positive integer; Obtain the maximum number of illegal nodes in the blockchain network, and determine the number of nodes to execute for each of the X transaction groups based on the maximum number of illegal nodes; Based on the number of nodes to be executed and the X transaction groups contained in the data block, a set of transactions to be executed is assigned to each of the N nodes in the blockchain network; one node corresponds to one set of transactions, and the transaction sets corresponding to different nodes contain different transaction groups; Based on the node identifier corresponding to the target node, obtain the first transaction set that matches the target node from the N transaction sets, and obtain the second execution result of the target node for the Y transaction groups included in the first transaction set; Y is a positive integer less than X; Transactions whose first execution result and second execution result are different are grouped together and added to the opposing transaction set of the target node. Based on the second execution result and the opposing transaction set of the target node, the first voting information of the target node is generated. Based on the first voting information corresponding to N nodes in the blockchain network, obtain the number of opposing nodes corresponding to each of the X transaction groups; the N nodes include the main node and the target node, and N is a positive integer; If the number of opposing nodes in the X transaction groups is less than or equal to the first quantity threshold, then the second voting information of the target node for the data block is determined to be a vote in favor. The affirmative vote is used to determine the consensus result of the data block in the blockchain network.

2. The method according to claim 1, characterized in that, Also includes: Obtain the digital signature of the target proposal from the master node; Obtain the node public key corresponding to the master node, and decrypt the digital signature based on the node public key to obtain the first digest information; A hash algorithm is used to perform a hash operation on the data block to obtain the second digest information corresponding to the data block; If the first summary information and the second summary information are the same, then the target proposal is determined to be valid.

3. The method according to claim 1, characterized in that, The step of obtaining the second execution result of the target node for the Y transaction groups included in the first transaction set includes: Obtain the i-th transaction group from the Y transaction groups included in the first transaction set, and obtain the contract information corresponding to the i-th transaction group; i is a positive integer less than or equal to Y; Based on the contract name in the contract information, the virtual machine program corresponding to the target node is invoked. According to the input parameters and methods in the contract information, the virtual machine program is run to obtain the second execution result corresponding to the i-th transaction group.

4. The method according to claim 1, characterized in that, Also includes: The first voting information of the target node is broadcast in the blockchain network so that the remaining nodes in the blockchain network other than the target node can determine the number of opposing nodes corresponding to the X transaction groups based on the received first voting information.

5. The method according to claim 1, characterized in that, The N nodes in the blockchain network include node a; The method further includes: Receive the first voting information broadcast by node a, and obtain the first transaction identifier indicated by the execution result in the first voting information of node a; Obtain the second transaction set allocated to node a from the X transaction groups, and obtain the second transaction identifier corresponding to the transaction group in the second transaction set; If the first transaction identifier is the same as the second transaction identifier, then the first voting information of node a is determined to be legitimate; If the first transaction identifier is different from the second transaction identifier, then the first voting information of node a is determined to be invalid, and the first voting information of node a is deleted.

6. The method according to claim 1, characterized in that, The step of obtaining the number of opposing nodes corresponding to each of the X transaction groups based on the first voting information corresponding to N nodes in the blockchain network includes: Traverse the X transaction groups contained in the data block to obtain the j-th transaction group among the X transaction groups; j is a positive integer less than or equal to X; In the set of opposing transactions contained in the first voting information of the N nodes, determine the statistical number of the set of opposing transactions containing the j-th transaction group, and determine the statistical number as the number of opposing nodes of the j-th transaction group.

7. The method according to claim 1, characterized in that, Also includes: If the number of opposing nodes in any of the X transaction groups is greater than the first quantity threshold, then the second voting information of the target node for the data block is determined to be an opposing vote; The second voting information of the target node is broadcast in the blockchain network so that the remaining nodes in the blockchain network other than the target node can determine the number of affirmative votes corresponding to the data block based on the received second voting information.

8. The method according to claim 1, characterized in that, Also includes: Obtain the second voting information of the N nodes for the data block, and count the number of affirmative votes in the second voting information of the N nodes; If the number of votes in favor is greater than or equal to the second threshold, the consensus result of the data block in the blockchain network is determined to be a successful consensus, and the data block is added to the blockchain.

9. The method according to claim 8, characterized in that, Also includes: If the number of votes in favor is less than the second threshold, the consensus result of the data block in the blockchain network is determined to be a consensus failure, and the target proposal is deleted. A new master node is determined from the N nodes to generate the consensus proposal; the block height corresponding to the consensus proposal is the same as the block height of the data block.

10. A transaction processing device in a blockchain network, characterized in that, include: The proposal acquisition module is used to acquire target proposals sent by master nodes in the blockchain network. The target proposal includes a data block and the first execution result of the master node on the X transaction groups contained in the data block, where X is a positive integer; The transaction execution module is used to obtain the maximum number of illegal nodes in the blockchain network, and determine the number of nodes to be executed for each of the X transaction groups based on the maximum number of illegal nodes. The transaction execution module is further configured to allocate a set of transactions to be executed to each of the N nodes in the blockchain network based on the number of nodes to be executed and the X transaction groups contained in the data block; one node corresponds to one set of transactions, and the set of transactions corresponding to different nodes contains different transaction groups; The transaction execution module is further configured to obtain a first transaction set matching the target node from N transaction sets based on the node identifier corresponding to the target node, and obtain a second execution result of the target node on Y transaction groups included in the first transaction set; where Y is a positive integer less than X. The first voting module is used to add the transaction group whose first execution result and second execution result are different to the opposing transaction set of the target node, and generate the first voting information of the target node based on the second execution result and the opposing transaction set of the target node; The voting statistics module is used to obtain the number of opposing nodes corresponding to each of the X transaction groups based on the first voting information corresponding to N nodes in the blockchain network; the N nodes include the main node and the target node, and N is a positive integer; The second voting module is used to determine that the target node's second voting information for the data block is a positive vote if the number of opposing nodes in the X transaction groups is less than or equal to the first quantity threshold. The affirmative vote is used to determine the consensus result of the data block in the blockchain network.

11. A computer device, characterized in that, Including memory and processor; The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to invoke the computer programs so that the computer device performs the method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-9.

13. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the method described in any one of claims 1-9.

Images