A transaction data processing method, device and readable storage medium

Abstract

The application discloses a transaction data processing method and device and a readable storage medium. The method comprises the following steps: when an initial transaction is received, performing the initial transaction to obtain an initial transaction execution record corresponding to the initial transaction, adding the initial transaction execution record corresponding to the initial transaction to a first transaction execution data set associated with a first transaction pool of a first consensus node, and adding the initial transaction to the first transaction pool; obtaining a transaction list containing the initial transaction from the first transaction pool, taking the initial transaction execution record corresponding to each transaction in the transaction list and obtained from the first transaction execution data set as to-be-processed transaction data associated with the transaction list; performing packing processing on the transaction list and the to-be-processed transaction data to obtain a proposal block to be subjected to block consensus with a second consensus node in a block chain network, performing block consensus on the proposal block to obtain a block consensus result of the proposal block. By using the application, the throughput of the block chain can be improved.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 202111125184.0, filed with the Chinese Patent Office on September 24, 2021, entitled "A Transaction Data Processing Method, Apparatus and Readable Storage Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of blockchain technology, and in particular to a transaction data processing method, apparatus, and readable storage medium. Background Technology

[0003] With the rapid development of network technology and the increasing emphasis on data security by governments and enterprises, blockchain has been more widely applied. In traditional blockchain networks, consensus nodes periodically obtain a list of transactions to be packaged from the transaction pool, package the obtained transaction list into a proposal block, and then broadcast the proposal block to other consensus nodes in the blockchain network for consensus.

[0004] In existing technologies, consensus nodes typically execute the transaction list contained in the proposed block during the consensus process. After execution, the consensus nodes vote on the transaction execution results. Only after reaching a consensus on the proposed block will the proposed block and the corresponding transaction execution results be written to the ledger. Subsequently, the consensus nodes can obtain another batch of transaction lists from the transaction pool and begin the next round of consensus. Therefore, in existing technologies, because the entire consensus phase requires sequential logic, each round of consensus must go through three stages: proposal, pre-voting, and pre-commit. Furthermore, since transaction execution and the consensus process are coupled, the sequential execution of transactions is interspersed during the consensus process. This inevitably leads to a long consensus duration, resulting in the system resources occupied during the consensus phase not being released for an extended period, thus reducing the overall throughput of the blockchain. Summary of the Invention

[0005] This application provides a transaction data processing method, apparatus, and readable storage medium, which can improve the throughput of blockchain.

[0006] This application provides a transaction data processing method, which is executed by a first consensus node in a blockchain network, including:

[0007] Upon receiving an initial transaction, the initial transaction is executed, resulting in an initial transaction execution record. This initial transaction execution record is then added to the first transaction execution dataset associated with the first transaction pool of the first consensus node, and the initial transaction is also added to the first transaction pool. The first transaction execution dataset is used to record the initial transaction execution record corresponding to each transaction received by the first consensus node.

[0008] Obtain a transaction list containing initial transactions from the first transaction pool, and use the initial transaction execution record corresponding to each transaction in the transaction list obtained from the first transaction execution dataset as the pending transaction data associated with the transaction list;

[0009] The transaction list and pending transaction data are packaged to obtain the proposal block to be consensused with the second consensus node in the blockchain network. The block consensus is then performed on the proposal block to obtain the block consensus result.

[0010] This application provides a transaction data processing method, which is executed by a second consensus node in a blockchain network, including:

[0011] The system receives proposal blocks broadcast by the first consensus node in the blockchain network. A proposal block is obtained by the first consensus node through packaging a transaction list and associated pending transaction data. The transaction list is a list containing initial transactions obtained by the first consensus node from its first transaction pool. The pending transaction data includes the initial transaction execution record corresponding to each transaction in the transaction list within the first transaction execution dataset. The first transaction execution dataset is associated with the first transaction pool and is used to record the initial transaction execution record corresponding to each transaction received by the first consensus node. The initial transaction execution record corresponding to the initial transaction is added to the first transaction execution dataset by the first consensus node, and is obtained by the first consensus node executing the initial transaction upon receiving it.

[0012] The conflict detection strategy is used to detect conflicts in the proposal block, and the second consensus result of the proposal block is obtained. The second consensus result is then returned to the first consensus node.

[0013] One embodiment of this application provides a transaction data processing apparatus, including:

[0014] The execution addition module is used to execute the initial transaction upon receiving it, obtain the initial transaction execution record corresponding to the initial transaction, add the initial transaction execution record corresponding to the initial transaction to the first transaction execution dataset associated with the first transaction pool of the first consensus node, and add the initial transaction to the first transaction pool; the first transaction execution dataset is used to record the initial transaction execution record corresponding to each transaction received by the first consensus node;

[0015] The data acquisition module is used to obtain a transaction list containing initial transactions from the first transaction pool, and to use the initial transaction execution record corresponding to each transaction in the transaction list obtained from the first transaction execution dataset as the transaction data to be processed associated with the transaction list.

[0016] The consensus packaging module is used to package the transaction list and the transaction data to be processed to obtain the proposal block to be consensused with the second consensus node in the blockchain network. The block consensus is then performed on the proposal block to obtain the block consensus result.

[0017] The execution addition module includes:

[0018] The data reading unit is used to obtain the initial business contract for executing the initial transaction when the initial transaction is received, and based on the initial business contract, call the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the blockchain network.

[0019] The transaction execution unit is used to call the virtual machine to execute the initial transaction based on the initial read dataset, obtain the initial transaction execution result corresponding to the initial transaction, write the initial transaction execution result into the initial write dataset corresponding to the initial transaction, and use the initial read dataset and the initial write dataset as the initial transaction read and write set corresponding to the initial transaction.

[0020] The height acquisition unit is used to take the block with the initial maximum generation timestamp obtained from the blockchain network when executing the initial transaction as the first target block, and take the block height of the first target block as the initial block height.

[0021] The record determination unit is used to use the initial transaction execution result, the initial transaction read / write set, and the initial block height as the initial transaction execution record corresponding to the initial transaction.

[0022] The consensus module for packaging includes:

[0023] The hash operation unit is used to treat the transactions in the transaction list as transactions to be verified, perform hash operations on the transactions to be verified and the transaction data to be processed, obtain the transaction hash value associated with the transaction to be verified, and determine the Merkle root corresponding to the transaction to be verified based on the transaction hash value.

[0024] The block generation unit is used to obtain the block with the target maximum generation timestamp from the blockchain network as the second target block, use the block hash value of the second target block as the parent block hash value of the next block of the second target block, generate the next block of the second target block based on the transactions to be verified, the transaction data to be processed, the Merkle root, and the parent block hash value, and use the next block of the second target block as the proposal block to be used for block consensus with the second consensus node in the blockchain network.

[0025] The consensus module for packaging includes:

[0026] The conflict detection unit is used to perform conflict detection on the proposal blocks based on the conflict detection strategy to obtain the first consensus result.

[0027] The block broadcasting unit is used to broadcast the proposal block to the second consensus node, so that the second consensus node can perform conflict detection on the proposal block based on the conflict detection strategy and obtain the second consensus result;

[0028] The consensus determination unit is used to receive the second consensus result returned by the second consensus node and use the first consensus result and the second consensus result as the block consensus result of the proposal block;

[0029] The device also includes:

[0030] The block addition module is used to determine that a consensus has been reached on the proposed block if the block consensus result indicates that the consensus has been successful, and to write the proposed block after the consensus has been reached as the third target block into the corresponding blockchain of the blockchain network.

[0031] The version update module is used to update the account status version number corresponding to the transaction objects associated with the transaction list.

[0032] The device also includes:

[0033] The validity verification module is used to verify the validity of the initial transaction and obtain the validity verification result. If the validity verification result indicates that the transaction is valid, the initial transaction is determined to have passed the validity verification, and the initial transaction that has passed the validity verification is broadcast to the second consensus node so that the second consensus node can execute the initial transaction that has passed the validity verification.

[0034] The effective verification module includes:

[0035] The signature verification unit is used to obtain the transaction signature information of the initial transaction and the device public key of the terminal device that sent the initial transaction, and to perform transaction signature verification on the transaction signature information based on the device public key to obtain the transaction signature verification result; the transaction signature information is obtained by the terminal device signing the initial transaction with the device private key corresponding to the device public key;

[0036] The double-spending verification unit is used to double-spend the initial transaction and obtain the double-spending verification result.

[0037] The result determination unit is used to take the transaction signature verification result and the double-spending verification result as the validity verification result corresponding to the initial transaction; when the transaction signature verification result indicates that the signature verification is successful and the double-spending verification result indicates that there is no double-spending attack, the validity verification result is determined to indicate that the transaction is valid.

[0038] One embodiment of this application provides a transaction data processing apparatus, including:

[0039] The receiving module receives proposal blocks broadcast by the first consensus node in the blockchain network. A proposal block is obtained by the first consensus node through packaging a transaction list and associated pending transaction data. The transaction list is a list containing initial transactions obtained by the first consensus node from its first transaction pool. The pending transaction data includes the initial transaction execution record corresponding to each transaction in the transaction list within the first transaction execution dataset. The first transaction execution dataset is associated with the first transaction pool and records the initial transaction execution record corresponding to each transaction received by the first consensus node. The initial transaction execution record corresponding to the initial transaction is added to the first transaction execution dataset by the first consensus node, and is obtained by the first consensus node executing the initial transaction upon receiving it.

[0040] The detection module is used to detect conflicts in the proposal block based on the conflict detection strategy, obtain the second consensus result of the proposal block, and return the second consensus result to the first consensus node.

[0041] The detection module includes:

[0042] The data acquisition unit is used to take transactions in the transaction list as transactions to be verified, and to take the local transaction execution records corresponding to the transactions to be verified obtained from the second transaction execution dataset as local transaction data associated with the transactions to be verified; the second transaction execution dataset is associated with the second transaction pool of the second consensus node; the second transaction execution dataset is used to record the local transaction records corresponding to each transaction received by the second consensus node; the local transaction execution records corresponding to the transactions to be verified are obtained by the second consensus node executing the transactions to be verified;

[0043] The local verification unit is used to perform local verification on the pending transaction data in the proposal block based on local transaction data, and obtain the local verification result; based on the local verification result, the second consensus result corresponding to the proposal block is determined.

[0044] The pending transaction data includes the execution result of the target transaction corresponding to the pending transaction, the target transaction read / write set, and the first block height; the first block height is the block height of the first block with the first maximum generation timestamp obtained by the first consensus node from the blockchain network when executing the pending transaction; the local transaction data includes the execution result of the local transaction corresponding to the pending transaction, the local transaction read / write set, and the second block height; the second block height is the block height of the second block with the second maximum generation timestamp obtained by the second consensus node from the blockchain network when executing the pending transaction.

[0045] This local verification unit includes:

[0046] The first comparison subunit is used to compare the target transaction execution result with the local transaction execution result to obtain the first comparison result;

[0047] The second comparison subunit is used to compare the first block height with the second block height to obtain a second comparison result if the first comparison result indicates that the target transaction execution result is the same as the local transaction execution result.

[0048] The result determination subunit is used to determine the local verification result corresponding to the proposal block based on the second comparison result.

[0049] Among them, the first maximum generation timestamp is the same as the second maximum generation timestamp;

[0050] The result determines the sub-unit, specifically used to compare the target transaction read / write set with the local transaction read / write set when the second comparison result indicates that the height of the first block is the same as the height of the second block, to obtain the third comparison result; and to determine the local verification result corresponding to the proposal block based on the third comparison result.

[0051] The first maximum generation timestamp is different from the second maximum generation timestamp; the target transaction read / write set includes a first account status version number, which refers to the account status version number associated with the transaction to be verified and having the first maximum update timestamp obtained by the first consensus node from the blockchain network when executing the transaction to be verified; the local transaction read / write set includes a second account status version number, which refers to the account status version number associated with the transaction to be verified and having the second maximum update timestamp obtained by the second consensus node from the blockchain network when executing the transaction to be verified;

[0052] The result determines the sub-unit, specifically used to compare the first account status version number with the second account status version number when the second comparison result indicates that the first block height and the second block height are different, to obtain the fourth comparison result; if the fourth comparison result indicates that the first account status version number and the second account status version number are different, then the third account status version number associated with the transaction to be verified and having the third maximum update timestamp is obtained from the blockchain network, and the first account status version number is compared with the third account status version number to obtain the fifth comparison result; if the fifth comparison result indicates that the third account status version number is lower than the first account status version number, then the transaction to be verified is re-executed to obtain the updated transaction execution result, and the target transaction execution result is compared with the updated transaction execution result to obtain the sixth comparison result; based on the sixth comparison result, the local verification result corresponding to the proposal block is determined.

[0053] The detection module includes:

[0054] The association verification unit is used to perform association verification on the transaction list and obtain the association verification result; based on the association verification result, at least two related transactions with an association relationship are obtained from the transaction list, and the transaction read / write sets corresponding to at least two related transactions are obtained from the transaction data to be processed.

[0055] The read-write detection unit is used to perform read-write set conflict detection on each transaction read-write set based on the transaction execution order corresponding to at least two related transactions, and obtain the read-write set conflict detection result; and determine the second consensus result corresponding to the proposal block based on the read-write set conflict detection result.

[0056] One embodiment of this application provides a computer device, including: a processor and a memory;

[0057] The processor is connected to a memory, which stores a computer program. When the computer program is executed by the processor, it causes the computer device to perform the method provided in the embodiments of this application.

[0058] 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 the processor performs the method provided in this application.

[0059] One embodiment of this application provides a computer program product or computer program, which includes 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 this application embodiment.

[0060] In this embodiment, when the first consensus node in the blockchain network receives an initial transaction, it can first execute the initial transaction to obtain the initial transaction execution record corresponding to the initial transaction. Then, the initial transaction execution record corresponding to the initial transaction can be added to the first transaction execution dataset associated with the first transaction pool of the first consensus node. At the same time, the initial transaction can be added to the first transaction pool. Then, the first consensus node can obtain a transaction list containing the initial transaction from the first transaction pool, and can obtain the initial transaction execution record corresponding to each transaction in the transaction list from the first transaction execution dataset, that is, obtain the pending transaction data associated with the transaction list. Then, the transaction list and the pending transaction data can be packaged to obtain a proposal block. Subsequently, the proposal block can be broadcast to the second consensus node in the blockchain network, so that the second consensus node and the first consensus node can respectively perform block consensus on the proposal block, and finally obtain the block consensus result of the proposal block. Therefore, in this embodiment of the application, for each consensus node in the blockchain network, each time a transaction is received, the transaction can be executed first, and the receipt and execution of the transaction can adopt parallel logic. Only after the transaction is executed is the transaction added to the transaction pool, and the corresponding transaction execution record is added to the transaction execution dataset associated with the transaction pool. Subsequently, the first consensus node packages the transaction to be packaged and the corresponding transaction execution record into a block for consensus. In other words, this embodiment of the application advances the transaction execution process before the transaction is added to the transaction pool, decoupling the transaction execution and consensus processes. This can reduce the consensus time consumed by the consensus process, so as not to occupy system resources for a long time during the consensus phase. At the same time, it can make full use of the characteristics of the consensus node to concurrently receive and execute transactions to improve the utilization rate of system resources, thereby improving the throughput of the blockchain. Attached Figure Description

[0061] 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.

[0062] Figure 1 This is a schematic diagram of the structure of a blockchain node system provided in an embodiment of this application;

[0063] Figure 2 This is a schematic diagram of a transaction data processing scenario provided in an embodiment of this application;

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

[0065] Figure 4 This is a schematic diagram of a scenario for generating a proposal block provided in an embodiment of this application;

[0066] Figure 5 This is a flowchart illustrating a transaction data processing method provided in an embodiment of this application;

[0067] Figure 6 This is a flowchart illustrating a transaction data processing method provided in an embodiment of this application;

[0068] Figure 7 This is an interactive schematic diagram of a blockchain transaction process provided in an embodiment of this application;

[0069] Figure 8 This is a schematic diagram of the structure of a transaction data processing device provided in an embodiment of this application;

[0070] Figure 9 This is a schematic diagram of the structure of a transaction data processing device provided in an embodiment of this application;

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

[0072] 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.

[0073] Please see Figure 1 , Figure 1 This is a schematic diagram of a blockchain node system provided in an embodiment of this application. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is mainly used to organize data in chronological order and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also allows for data verification, storage, and updating. Essentially, a blockchain is a decentralized database where each node stores an identical blockchain record. The blockchain network includes consensus nodes, which are responsible for achieving consensus across the entire blockchain network.

[0074] As can be understood, a block is a data packet that carries transaction data (i.e., transaction business) on a blockchain network. It is a data structure that is marked with a timestamp and the hash value of the previous block. The block is verified and the transactions in the block are confirmed by the network's consensus mechanism.

[0075] It is understandable that a blockchain system can include smart contracts. A smart contract can refer to code that can be understood and executed by all nodes in the blockchain (including consensus nodes), capable of executing arbitrary logic and obtaining results. It should be understood that a blockchain can include one or more smart contracts, which can be distinguished by an identifier (ID) or name. Transaction requests can carry the identifier or name of the smart contract to specify the smart contract that the blockchain needs to run.

[0076] like Figure 1 The blockchain node system shown can correspond to a blockchain network, which may include, but is not limited to, the blockchain network corresponding to a consortium blockchain. A blockchain node system refers to a system used for data sharing between blockchain nodes. This system can include multiple nodes, specifically nodes 10a, 10b, 10c, 10d, ..., 10n. Nodes 10a, 10b, 10c, 10d, ..., 10n can be collectively referred to as blockchain nodes. It is understood that a blockchain node can be a server connected to the blockchain network or a terminal device connected to the blockchain network; the specific form of the blockchain node is not limited here.

[0077] Each node, during normal operation, can receive data sent from the outside world and perform on-chain processing based on the received data, and can also send data to the outside world. To ensure data communication between nodes, data connections can exist between each node. For example, there is a data connection between node 10a and node 10b, a data connection between node 10a and node 10c, and a data connection between node 10b and node 10c.

[0078] It is understood that the above data connection is not limited to the connection method. It can be connected directly or indirectly through wired communication, or directly or indirectly through wireless communication, or through other connection methods. This application does not impose any restrictions on this.

[0079] It is understandable that nodes can transmit data or blocks through the aforementioned data connections. The blockchain network can establish data connections between nodes based on node identifiers. Each node in the blockchain network has a corresponding node identifier, and each node can store the node identifiers of other nodes connected to it. This allows it to broadcast acquired data or generated blocks to other nodes based on their node identifiers. For example, node 10a can maintain a node identifier list as shown in Table 1, which stores the node names and identifiers of other nodes.

[0080] Table 1

[0081] Node Name Node identifier Node 10a 117.114.151.174 Node 10b 117.116.189.145 Node 10c 117.114.151.183 Node 10d 117.117.125.169 … … Node 10n 117.116.189.125

[0082] The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify a node in the blockchain network. Table 1 only uses IP addresses as an example. For instance, node 10a can send information (e.g., a block) to node 10b using node identifier 117.116.189.145, and node 10b can determine that the information was sent by node 10a using node identifier 117.114.151.174.

[0083] It should be noted that the blockchain network in this application embodiment can be a layered structure or a single-layer structure, and this application does not limit the specific structure of the blockchain network.

[0084] Optionally, for blockchain networks with a layered structure, Figure 1The blockchain node system shown may include a first blockchain system, a second blockchain system, and proxy nodes (also known as routing nodes). Both the first and second blockchain systems may include one or more nodes; the number of nodes is not limited here. For example, the first blockchain system may include nodes 10a and 10b, the second blockchain system may include nodes 10c and 10d, and the proxy node may be node 10n. The blockchain network corresponding to the first blockchain system can be called the business network (i.e., the witness network), and the nodes in the business network can be called business nodes. These business nodes are mainly used to execute transaction business to obtain transaction data associated with that transaction business. It is understood that these business nodes do not need to participate in the accounting consensus, but can obtain block header data and partially authorized visible block data from the core consensus network through identity authentication. The blockchain network corresponding to the second blockchain system can be called the core consensus network. The nodes in this core consensus network can be called consensus nodes (i.e., accounting nodes), and these consensus nodes can run blockchain consensus protocols. The proxy node can be used to isolate the aforementioned business network and core consensus network. The proxy node can layer the peer-to-peer (P2P) network to form a layered structure of "business network - core consensus network", thereby improving the confidentiality and security of data on the blockchain.

[0085] Optionally, for blockchain networks with a single-layer structure, Figure 1 The blockchain node system shown can include consensus nodes and non-consensus nodes. Consensus nodes participate in consensus, while non-consensus nodes do not participate in consensus but can help propagate blocks and voting messages, and synchronize states with each other. For example, it can be... Figure 1 Nodes 10a, 10b, 10c, and 10d are designated as consensus nodes, while the remaining nodes are designated as non-consensus nodes.

[0086] It is understood that the transaction data processing method provided in this application embodiment can be executed by computer equipment, which includes, but is not limited to, the consensus node mentioned above (which can be a terminal device or a server). The server mentioned above can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing 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. The terminal device mentioned above can be a smartphone, tablet computer, laptop computer, PDA, smart speaker, mobile internet device (MID), POS (Point of Sales) machine, wearable device (e.g., smartwatch, smart bracelet, etc.).

[0087] It should be understood that in a blockchain, before a block (which may be called a proposal block, suggested block, or block to be added to the chain) is added to the chain, the block must pass consensus among the consensus nodes in the blockchain network. Only after consensus is passed can the block be added to the blockchain. It is understandable that when blockchain is used in some scenarios by government or commercial institutions, not all participating nodes in the blockchain (i.e., the blockchain nodes in the aforementioned blockchain node system) have sufficient resources and necessity to become consensus nodes. For example, in... Figure 1 In the blockchain node system shown, nodes 10a, 10b, 10c, and 10d can be considered as consensus nodes. Consensus nodes participate in consensus, which means reaching an agreement on blocks (containing a batch of transactions), including generating proposal blocks and voting on them. Non-consensus nodes do not participate in consensus but help propagate block and voting messages, and synchronize their states.

[0088] For ease of understanding, in Figure 1 In the blockchain node system shown, this embodiment of the application can use the consensus node used to package and generate the proposal block as the first consensus node (also called the packaging node or proposal node). The first consensus node can broadcast the proposal block to other consensus nodes in the blockchain network, and this embodiment of the application can use other consensus nodes used to achieve block consensus on the proposal block as the second consensus node. It should be noted that the proposal node is also a consensus node and also needs to achieve block consensus on the proposal block. For example, the first consensus node can be... Figure 1 In the blockchain node system shown, node 10a, the second consensus node can be... Figure 1The illustrated blockchain node system includes nodes 10b, 10c, and 10d. Furthermore, both the first and second consensus nodes can execute received transactions, and each consensus node has its own transaction pool for adding transactions to be packaged. Each transaction pool is also associated with a transaction execution dataset, which records the transaction execution records corresponding to each transaction received by the respective consensus node. The transaction execution dataset and the transaction pool can reside in separate storage areas or in the same storage area; this embodiment does not limit this. For example, optionally, the transaction execution dataset can be located within its associated transaction pool. For ease of distinction, in this embodiment, the transaction pool of the first consensus node can be referred to as the first transaction pool, and the transaction execution dataset associated with the first transaction pool can be referred to as the first transaction execution dataset. Similarly, the transaction pool of the second consensus node can be referred to as the second transaction pool, and the transaction execution dataset associated with the second transaction pool can be referred to as the second transaction execution dataset.

[0089] Understandably, in this embodiment, when the first consensus node receives an initial transaction, it can first execute the initial transaction to obtain the initial transaction execution record corresponding to the initial transaction. Then, it can add the initial transaction execution record corresponding to the initial transaction to the first transaction execution dataset associated with the first transaction pool of the first consensus node. At the same time, it can add the initial transaction to the first transaction pool. Then, the first consensus node can obtain a transaction list containing the initial transaction from the first transaction pool, and can obtain the initial transaction execution record corresponding to each transaction in the transaction list from the first transaction execution dataset, that is, obtain the pending transaction data associated with the transaction list. Then, it can package the transaction list and the pending transaction data to obtain a proposal block. Subsequently, it can broadcast the proposal block to the second consensus node so that the second consensus node and the first consensus node can respectively perform block consensus on the proposal block, and finally obtain the block consensus result of the proposal block. Therefore, it can be seen that the embodiment of this application advances the transaction execution process to before the transaction is added to the transaction pool, decoupling the transaction execution and consensus processes. This can reduce the consensus time consumed by the consensus process, so that the consensus phase will not occupy system resources for a long time. At the same time, it can make full use of the characteristics of consensus nodes to concurrently receive and execute transactions to improve the utilization rate of system resources, thereby improving block production efficiency and increasing the throughput of the blockchain.

[0090] For better understanding, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram illustrating a transaction data processing scenario provided in an embodiment of this application. For example... Figure 2As shown, in this embodiment, the consensus node 20A can be a consensus node (i.e., the first consensus node) in the blockchain network used to package and process the transaction list and the transaction data to be processed. This consensus node 20A can be the aforementioned... Figure 1 Any consensus node in the blockchain node system shown, for example, node 10a. In this embodiment, consensus node 20B can be a consensus node (i.e., a second consensus node) in the blockchain network that needs to reach block consensus with the first consensus node. For example, consensus node 20B can be one of the aforementioned... Figure 1 Node 10b in the blockchain node system shown.

[0091] It should be understood that, in this embodiment of the application, before adding a received transaction to the transaction pool, the consensus node in the blockchain network can execute the transaction and save the corresponding transaction execution record. Subsequently, the transaction and its corresponding transaction execution record can be packaged into a proposal block for consensus. A transaction, also known as a transaction request or user request, can be initiated by an application client on a terminal device to indicate the transaction the user wishes to execute. For example, the transaction here could be an asset transfer transaction, which can be used to transfer virtual assets such as game coins, game diamonds, and electronic tickets. The type of virtual asset will not be limited here.

[0092] For ease of understanding and distinction, in this embodiment, any transaction received by the first consensus node can be referred to as the initial transaction. For example, the last transaction received within a packaging cycle can be considered the initial transaction. After executing the initial transaction, the first consensus node can immediately begin packaging the relevant data. The packaging cycle refers to the duration between two consecutive packaging processes. For example, if the packaging cycle is set to 10 seconds, the first consensus node will perform a packaging process every 10 seconds. This embodiment does not limit the specific duration of the packaging cycle.

[0093] like Figure 2As shown, consensus node 20A can continuously and concurrently receive transactions sent by application clients. After successful reception, consensus node 20A can pre-execute these transactions to obtain the initial transaction execution records corresponding to each transaction. Taking transaction 200a as an example, after receiving transaction 200a, consensus node 20A can perform validity verification on transaction 200a and obtain the validity verification result. When the validity verification result indicates that the transaction is valid, that is, when transaction 200a passes the validity verification, consensus node 20A can broadcast transaction 200a to the second consensus node (e.g., consensus node 20B) so that the second consensus node can execute transaction 200a. Simultaneously, consensus node 20A can invoke the virtual machine to execute transaction 200a according to the current ledger state (e.g., remaining assets, i.e., account balance), thereby obtaining transaction execution record 201a corresponding to transaction 200a (i.e., the initial transaction execution record corresponding to the initial transaction). Transaction 200a can then be added to the transaction pool 200 (i.e., the first transaction pool) of consensus node 20A, and transaction execution record 201a can be added to the transaction execution dataset 201 (i.e., the first transaction execution dataset) associated with transaction pool 200. The first transaction execution dataset can be used to record the initial transaction execution record corresponding to each transaction received by the first consensus node. Optionally, the initial transaction execution record corresponding to each transaction can include the transaction execution result, the transaction read / write set, and the latest block height of the ledger at the time of transaction execution (i.e., the block height corresponding to the block with the largest generation timestamp on the blockchain corresponding to the blockchain network where the first consensus node resides).

[0094] Similarly, for other transactions received by consensus node 20A, such as transaction 200b, transaction 200c, ..., transaction 200n, the processing procedure is the same as that for transaction 200a. Ultimately, consensus node 20A can generate and save the initial transaction execution record corresponding to each transaction. It should be understood that consensus node 20B can also pre-execute all received transactions, and its processing procedure is similar to that of consensus node 20A for transaction 200a, which will not be elaborated here. It should be noted that in this embodiment, each consensus node can concurrently receive and execute multiple transactions, thus improving the utilization of CPU (central processing unit) computing resources and I / O (input / output) resources.

[0095] like Figure 2As shown, assuming that consensus node 20A executes transaction 200b and obtains transaction execution record 201b, executes transaction 200c and obtains transaction execution record 201c, ..., executes transaction 200n and obtains transaction execution record 201n, then the current transaction pool 200 contains transaction 200a, transaction 200b, transaction 200c, ..., transaction 200n, and the transaction execution dataset 201 contains transaction execution record 201a, transaction execution record 201b, transaction execution record 201c, ..., transaction execution record 201n. It should be understood that consensus node 20A can periodically obtain a batch of transaction lists to be packaged from transaction pool 200 according to relevant packaging strategies (e.g., a strategy based on transaction time priority or a strategy based on transaction fee priority). For example, it can obtain transaction 200a, transaction 200b, and transaction 200c from transaction pool 200 as transaction list 202 to be packaged. Correspondingly, it can obtain the initial transaction execution record corresponding to each transaction in transaction list 202 (i.e., transaction 200a, transaction 200b, and transaction 200c) from transaction execution dataset 201 as transaction data 203 to be processed associated with transaction list 202. At this time, transaction data 203 to be processed specifically includes transaction execution record 201a, transaction execution record 201b, and transaction execution record 201c.

[0096] Furthermore, consensus node 20A can package the transaction list 202 and the pending transaction data 203 to obtain a proposal block 204 for consensus with a second consensus node (e.g., consensus node 20B). This proposal block 204 can then be broadcast to consensus node 20B. Subsequently, consensus nodes 20A and 20B can jointly reach a consensus on proposal block 204, ultimately obtaining the consensus result for proposal block 204. Each consensus node receiving proposal block 204 can perform conflict detection and voting based on a conflict detection strategy, thus obtaining the final consensus result based on each node's voting results. When the consensus result indicates successful consensus, consensus node 20A can write the consensus-reached proposal block 204 into the blockchain corresponding to the blockchain network where consensus node 20A resides. Proposal block 204 may include block header information and block body. The block header information may include the parent block hash value, block height, version number, timestamp, difficulty value, random number, and Merkel root information of proposal block 204. The block body may include transactions in transaction list 202 packaged into proposal block 204, transaction execution records in pending transaction data 203, and the Merkel path composed of the transaction and the corresponding transaction hash value of the transaction execution record.

[0097] As described above, in this embodiment of the application, for each consensus node in the blockchain network, each time a transaction is received, the transaction can be executed first, and the receipt and execution of the transaction can adopt parallel logic. Only after the transaction is executed is the transaction added to the transaction pool, and the corresponding transaction execution record is added to the transaction execution dataset associated with the transaction pool. Subsequently, the first consensus node packages the transaction to be packaged and the corresponding transaction execution record into a block for consensus. In other words, this embodiment of the application advances the transaction execution process before the transaction is added to the transaction pool, decoupling the transaction execution and consensus processes. This can reduce the consensus time consumed by the consensus process, so as not to occupy system resources for a long time during the consensus phase. At the same time, it can make full use of the characteristics of the consensus node to concurrently receive and execute transactions to improve the utilization rate of system resources and improve the block production efficiency of the consensus node, ultimately improving the throughput of the blockchain.

[0098] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a transaction data processing method provided in an embodiment of this application. Figure 3 As shown, this method can be executed by the first consensus node in the blockchain network. This first consensus node can be a server connected to the blockchain network, or it can be a terminal device connected to the blockchain network; the specific form of the first consensus node is not limited here. The first consensus node can be one of the aforementioned... Figure 1 Any consensus node in the blockchain node system shown, for example, node 10a. The method may include at least the following steps S101-S103:

[0099] Step S101: Upon receiving an initial transaction, execute the initial transaction to obtain the initial transaction execution record corresponding to the initial transaction, add the initial transaction execution record corresponding to the initial transaction to the first transaction execution dataset associated with the first transaction pool of the first consensus node, and add the initial transaction to the first transaction pool.

[0100] Specifically, when the first consensus node receives an initial transaction, it can obtain the initial business contract used to execute that initial transaction. It can then invoke this initial business contract to execute the initial transaction, thereby obtaining the execution result. It can also obtain the initial transaction read / write set obtained after execution, as well as the block height (i.e., the initial block height) corresponding to the block with the largest generation timestamp obtained in the blockchain network during the execution of the initial transaction. Subsequently, the initial transaction execution result, the initial transaction read / write set, and the initial block height can be used as the initial transaction execution record. The initial business contract is a smart contract deployed in the blockchain network, which can be used to execute the initial transaction.

[0101] It should be understood that the initial transaction is a transaction request initiated by an application client on the terminal device. This application client can be a live streaming application, social application, instant messaging application, game application, short video application, video application, music application, shopping application, novel application, payment application, or other client with transaction functionality. Optionally, when the blockchain network where the first consensus node resides has a single-layer structure, the terminal device can directly send the initial transaction to the blockchain network. Nodes in the blockchain network can receive the initial transaction and broadcast it to each other. Ultimately, all consensus nodes in the blockchain network (including the first consensus node) can receive the initial transaction. Therefore, the initial transaction received by the first consensus node may be sent directly by the terminal device or broadcast by other nodes. Optionally, when the blockchain network where the first consensus node resides has a layered structure, the blockchain network can be divided into a business network and a core consensus network. Optionally, the blockchain network may also include a routing network (or proxy network) for network isolation between the business network and the core consensus network. It should be understood that the terminal device initiating the initial transaction can be a business node in the business network, or it can be a terminal independent of the blockchain network; this application embodiment does not limit this. Therefore, business nodes can send the initial transaction directly to the core consensus network, or they can first send the initial transaction to a routing node in the routing network, and then the routing node forwards the initial transaction to the core consensus network. After receiving the initial transaction, the consensus nodes in the core consensus network can broadcast it to each other, and eventually all consensus nodes in the core consensus network (including the first consensus node) will receive the initial transaction. This application does not limit the specific structure of the blockchain network.

[0102] It should be understood that after the first consensus node obtains the initial business contract for executing the initial transaction, it can, based on the initial business contract, call the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the blockchain network. Then, based on the initial read dataset, it can call the virtual machine to execute the initial transaction, thereby obtaining the initial transaction execution result. Subsequently, the initial transaction execution result can be written to the initial write dataset corresponding to the initial transaction. Thus, the initial read dataset and the initial write dataset can be used as the initial transaction read / write set corresponding to the initial transaction. The initial read dataset can be stored in the storage layer of the first consensus node. It should be understood that the storage layer of each node in the blockchain network can include local cache and local storage. Local cache has relatively fast read / write speeds, so blockchain nodes can prioritize read / write operations in the local cache, which can improve the overall performance of the blockchain network. Local storage is used for persistent storage of data (e.g., blocks). Blockchain nodes can first write the data that needs to be stored to the corresponding local cache. However, considering the limitations of local cache (e.g., data loss due to power failure), subsequent asynchronous write operations can be used to gradually write the relevant data to local storage (e.g., a local database) to ultimately ensure data reliability and persistence. Therefore, the first consensus node can first call the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the local cache of the first consensus node based on the initial business contract. If reading from the local cache of the first consensus node fails, it can further try to read the initial read dataset corresponding to the initial transaction from the local storage of the first consensus node.

[0103] Furthermore, the first consensus node can, based on the acquired initial read dataset, invoke its corresponding virtual machine to execute an initial transaction, obtain the execution result of the initial transaction, and then write the execution result into the corresponding initial write dataset. Ultimately, this initial read dataset and the initial write dataset can be used as the initial transaction read / write set corresponding to the initial transaction. The first consensus node can pre-create an empty initial write dataset, and then write the execution result to it when the initial transaction is executed. It should be understood that the initial write dataset can also be stored in the first consensus node's storage layer in association with the initial read dataset. Optionally, based on the first consensus node's local cache, a corresponding transaction read cache and transaction write cache can be created for each transaction received by the first consensus node. One transaction corresponds to one transaction write cache and one transaction read cache. That is, the first consensus node can obtain the initial read dataset corresponding to the initial transaction from the transaction read cache, and then add the initial transaction execution result obtained from executing the initial transaction to the corresponding transaction write cache. The initial write dataset corresponding to the initial transaction is then constructed based on the data stored in the transaction write cache.

[0104] Furthermore, when executing the aforementioned initial transaction, the first consensus node can use the block with the initial maximum generation timestamp obtained from the blockchain network as the first target block, and the block height of the first target block as the initial block height. In other words, the first consensus node can use the latest block height of the ledger read during the execution of the initial transaction as the initial block height. Here, the first target block specifically refers to the block with the maximum generation timestamp read from the first consensus node's local cache when executing the initial transaction. For ease of distinction later, this maximum generation timestamp can be referred to as the initial maximum generation timestamp.

[0105] It should be understood that block height is a block identifier used to measure the distance between a given block and the first block in the blockchain. Block height accurately indicates the position of a block on the chain, essentially assigning it coordinates. For example, suppose the first consensus node stores five blocks in its blockchain. The first block has a block height of 0, the second block has a block height of 1, and so on, with the fifth block having a block height of 4. Since the fifth block has the largest initial generation timestamp at this point, it is the first target block, and its current latest block height (i.e., the initial block height) is 4.

[0106] Optionally, in special circumstances, the blockchain may fork. In such cases, the first consensus node may select the blockchain with the longest branch as the valid blockchain, and data reading (e.g., obtaining the initial block height) will still be performed on the valid blockchain.

[0107] It's important to note that while each consensus node in the blockchain network can retrieve relevant data from the jointly maintained blockchain (or ledger), such as transaction execution results, read datasets, and blocks, data broadcasting is susceptible to network transmission latency. Therefore, there will be a time lag in data updates (e.g., the addition of new blocks) in the storage layer of each consensus node. In other words, advanced consensus nodes with strong computing power and low transmission latency update data quickly, resulting in relatively new data in their storage layer; conversely, less advanced nodes with weaker computing power and higher transmission latency update data slowly, resulting in relatively older data in their storage layer. Consequently, when different consensus nodes execute the same transaction, the latest block heights retrieved from their respective storage layers may differ. For example, for consensus node 1, when executing transaction A, the latest block height read from its local cache is 4. For consensus node 2, when executing transaction A, the latest block height read from its local cache is 3. This shows that consensus node 2's block update lags behind consensus node 1's.

[0108] Furthermore, the first consensus node can use the initial transaction execution result, initial transaction read / write set, and initial block height corresponding to the initial transaction as the initial transaction execution record. Subsequently, it can add this initial transaction execution record to the first transaction execution dataset and add the initial transaction to the first transaction pool of the first consensus node. Optionally, any one or more of the initial transaction execution result, initial transaction read / write set, and initial block height can be used as the initial transaction execution record corresponding to the initial transaction. The first transaction execution dataset is associated with the first transaction pool and is used to record the initial transaction execution record corresponding to each transaction received by the first consensus node. For example, see again... Figure 2 ,like Figure 2As shown, if transaction 200a is taken as the initial transaction, then the transaction execution record 201a obtained by consensus node 20A after executing transaction 200a will be used as the initial transaction execution record corresponding to the initial transaction. The transaction execution record 201a may include the initial transaction execution result corresponding to transaction 200a, the initial transaction read / write set, and the initial block height. Similarly, consensus node 20A can also obtain the corresponding transaction execution records (e.g., transaction execution record 201b, transaction execution record 201c, transaction execution record 201n) after executing other received transactions (e.g., transaction 200b, transaction 200c, transaction 200n, etc.).

[0109] It should be understood that the embodiments in this application only illustrate the execution of the initial transaction as an example. The first consensus node can also receive other transactions, and the processing of these transactions is the same as that of the initial transaction, so it will not be described again here. The first consensus node can concurrently receive and execute multiple transactions. It should be noted that, in addition to the first consensus node, other consensus nodes in the blockchain network (such as the second consensus node) can also concurrently receive and execute multiple transactions. Therefore, by fully utilizing the concurrent transaction reception and processing logic, the utilization rate of CPU computing resources and I / O resources can be improved, thereby improving the overall utilization rate of system resources.

[0110] Step S102: Obtain a transaction list containing initial transactions from the first transaction pool, and use the initial transaction execution record corresponding to each transaction in the transaction list obtained from the first transaction execution dataset as the transaction data to be processed associated with the transaction list;

[0111] Specifically, in addition to the initial transaction, the first transaction pool may also contain other transactions to be packaged. Therefore, the first consensus node can obtain a list of transactions to be packaged from the first transaction pool. This list may include one or more transactions, and the specific number of transactions included in the transaction list is not limited in this embodiment. Optionally, the transaction list may include the initial transaction. Simultaneously, the first consensus node can also obtain the initial transaction execution record corresponding to each transaction in the transaction list from the first transaction execution dataset, and can use these initial transaction execution records as pending transaction data associated with the transaction list.

[0112] It should be understood that since the transaction capacity of a block is limited, when the number of transactions to be packaged in the first transaction pool is too large, resulting in an incomplete block, the first consensus node can obtain a transaction list from the first transaction pool based on a configured packaging strategy. The packaging strategy can be a transaction time-priority strategy, i.e., sorting transactions according to their timestamps, with transactions with smaller timestamps being packaged into the block first; alternatively, the packaging strategy can be a transaction fee-priority strategy, i.e., sorting transactions according to the fees paid by each exchange, with transactions with higher fees being packaged into the block first; alternatively, a combination of transaction time and transaction fees can be used, with transactions ranking higher overall being packaged into the block first. Of course, other packaging strategies can also be used for packaging, and the specific content of the packaging strategy adopted in this embodiment is not limited.

[0113] Step S103: Package the transaction list and the transaction data to be processed to obtain the proposal block to be consensused with the second consensus node in the blockchain network. Perform block consensus on the proposal block to obtain the block consensus result of the proposal block.

[0114] Specifically, the first consensus node can treat transactions in the transaction list as transactions to be verified. It can then perform hash operations on the transactions to be verified and the transaction data to be processed, obtaining a transaction hash value associated with the transaction to be verified. Based on this transaction hash value, it can determine the Merkle root corresponding to the transaction to be verified. Simultaneously, the first consensus node can obtain a block with the target maximum generation timestamp from the blockchain network as the second target block. The hash value of the second target block can be used as the parent block hash value of the next block of the second target block. Subsequently, based on the transaction to be verified, the transaction data to be processed, the Merkle root, and the parent block hash value, the first consensus node can generate the next block of the second target block. This next block is then used as the proposal block for consensus with the second consensus node in the blockchain network. Here, the second target block specifically refers to the block with the maximum generation timestamp read from the corresponding blockchain network when the first consensus node performs packaging processing. This maximum generation timestamp can be called the target maximum generation timestamp. It can be understood that the generation timestamp of the proposal block can be used to update the maximum generation timestamp on the blockchain.

[0115] It should be understood that the second target block and the first target block may be the same block or different blocks.

[0116] It should be noted that the first consensus node can perform a hash operation on the transaction to be verified to obtain a first hash value, and simultaneously perform a hash operation on the transaction data to be processed to obtain a second hash value. Subsequently, it can perform another hash operation on the first and second hash values ​​to obtain the transaction hash value associated with the transaction to be verified. Optionally, the first consensus node can also directly perform hash operations on the transaction to be verified and the transaction data to be processed to obtain the transaction hash value associated with the transaction to be verified. Finally, the first consensus node can determine the Merkle root corresponding to the transaction to be verified based on the transaction hash value.

[0117] Optionally, the first consensus node may also perform hash calculations only on the transaction to be verified to obtain the transaction hash value associated with the transaction to be verified, and then determine the Merkle root corresponding to the transaction to be verified based on the transaction hash value.

[0118] For ease of understanding, please refer to the following: Figure 4 , Figure 4 This is a schematic diagram illustrating a scenario for generating a proposal block, as provided in an embodiment of this application. Figure 4 As shown, in this embodiment, consensus node 40A can be the first consensus node in the blockchain network, and this consensus node 40A can be the aforementioned... Figure 1 Any consensus node in the blockchain node system shown, for example, node 10a.

[0119] It should be understood that, such as Figure 4 The blockchain 4 shown can be the one described above. Figure 1 The blockchain network shown is a blockchain 4, which can be a shared blockchain among all consensus nodes in the blockchain network to which consensus node 40A belongs. Each consensus node can obtain the information stored in blockchain 4. Blockchain 4 includes blocks 40a, 40b, ..., 40m, and block 40a can be called the genesis block of blockchain 4.

[0120] It should be understood that Figure 4 The transaction pool 400 (i.e., the first transaction pool) shown can store multiple transactions received by the consensus node 40A. These multiple transactions can specifically include transaction 1, transaction 2, transaction 3, transaction 4, ..., transaction n, where n is a positive integer. Among them, transaction 2 can be the initial transaction initiated by an application client on a certain terminal device.

[0121] Understandably, before placing a transaction into the transaction pool, consensus node 40A can execute each received transaction, obtain the initial transaction execution record corresponding to each transaction, and add these initial transaction execution records to the transaction execution dataset 401 (i.e., the first transaction execution dataset) associated with transaction pool 400. These initial transaction execution records may specifically include transaction execution record 1 corresponding to transaction 1, transaction execution record 2 corresponding to transaction 2, transaction execution record 3 corresponding to transaction 3, ..., transaction execution record n ​​corresponding to transaction n.

[0122] Furthermore, consensus node 40A can obtain a list of transactions for packaging from transaction pool 400, and treat the transactions in this list as transactions to be verified. For example, transactions 1, 2, 3, and 4 in transaction list 402 can all be collectively referred to as transactions to be verified. Simultaneously, consensus node 40A can obtain the initial transaction execution record corresponding to each transaction in the transaction list from transaction execution dataset 401, and treat these initial transaction execution records as transaction data to be processed associated with the transaction list. For example, transaction execution record 1, transaction execution record 2, transaction execution record 3, and transaction execution record 4 in transaction data to be processed 403 can all be collectively referred to as transaction data to be processed. Furthermore, consensus node 40A can perform hash operations on each transaction in transaction list 402 and the corresponding initial transaction execution record in transaction data to be processed 403 to obtain the corresponding transaction hash value. For example, performing a hash operation on transaction 1 and transaction execution record 1 yields transaction hash value 1; alternatively, a hash operation can be performed on transaction 1 to obtain a first hash value 1, and simultaneously on transaction execution record 1 to obtain a second hash value 1, followed by a hash operation on both hash values ​​to obtain transaction hash value 1; similarly, performing a hash operation on transaction 2 and transaction execution record 2 yields transaction hash value 2; alternatively, a hash operation can be performed on transaction 2 to obtain a first hash value 2, and simultaneously on transaction execution record 2 to obtain a second hash value 2, followed by a hash operation on both hash values ​​to obtain transaction hash value 1. 2; Perform a hash operation on transaction 3 and transaction execution record 3 to obtain transaction hash value 3; Optionally, perform a hash operation on transaction 3 to obtain a first hash value 3, and simultaneously perform a hash operation on transaction execution record 3 to obtain a second hash value 3, and then perform a hash operation on the first hash value 3 and the second hash value 3 to obtain transaction hash value 3; Perform a hash operation on transaction 4 and transaction execution record 4 to obtain transaction hash value 4; Optionally, perform a hash operation on transaction 4 to obtain a first hash value 4, and simultaneously perform a hash operation on transaction execution record 4 to obtain a second hash value 4, and then perform a hash operation on the first hash value 4 and the second hash value 4 to obtain transaction hash value 4.

[0123] Furthermore, consensus node 40A can determine the Merkle root corresponding to the transaction to be verified based on transaction hash value 1, transaction hash value 2, transaction hash value 3, and transaction hash value 4. For example, consensus node 40A can perform a hash operation on transaction hash value 1 and transaction hash value 2 to obtain a path hash value 12 containing these two transaction hash values; perform a hash operation on transaction hash value 3 and transaction hash value 4 to obtain a path hash value 34 containing these two transaction hash values; finally, it can perform a hash operation on path hash value 12 and path hash value 34 to obtain a root hash value 1234 containing these two path hash values, and then use the root hash value 1234 as the Merkle root corresponding to the transaction to be verified.

[0124] Furthermore, consensus node 40A can... Figure 4 On blockchain 4, the block with the target maximum generation timestamp is obtained as the second target block (e.g., block 40m). The block hash value of block 40m can then be used as the parent block hash value of the next block of block 40m. At this point, consensus node 40A can generate the next block of block 40m based on the transactions to be verified, the transaction data to be processed, the Merkle root, and the parent block hash value. The next block of the generated second target block is then used as the proposal block to be written to blockchain 4 (e.g., proposal block 40x). Proposal block 40x can be used to update the maximum generation timestamp on blockchain 4. Figure 4 As shown, the proposal block can include a block header and a block body. The block header can include the parent block hash, version number, timestamp, difficulty value, random number, and Merkel root, etc. The block body can store the transactions to be verified and the transaction data to be processed packaged by consensus node 40A, as well as the Merkel path formed by the transaction hash values ​​obtained from the transactions to be verified and the transaction data to be processed.

[0125] Furthermore, the first consensus node can perform conflict detection on the proposed block based on the conflict detection strategy to obtain the first consensus result. Simultaneously, the first consensus node can broadcast the proposed block to the second consensus node, enabling the second consensus node to perform conflict detection on the proposed block using the same strategy to obtain the second consensus result. Finally, the first consensus node can receive the second consensus result returned by the second consensus node and use both the first and second consensus results as the block consensus result for the proposed block. The specific conflict detection process will be discussed later. Figure 6 The description in the corresponding embodiments.

[0126] As described above, this embodiment advances the transaction execution process before adding the transaction to the transaction pool, decoupling the transaction execution and consensus processes. This reduces the consensus time consumed and fully leverages the concurrent transaction reception and execution capabilities of consensus nodes to improve system resource utilization and increase the efficiency of consensus node block generation. Furthermore, while ensuring consensus data consistency, it reduces the time overhead caused by fully executing all transactions in a block during the consensus process, ultimately increasing the overall throughput of the blockchain network.

[0127] Further, please see Figure 5 , Figure 5 This is a flowchart illustrating a transaction data processing method provided in an embodiment of this application. Figure 5 As shown, this method can be executed by the first consensus node in the blockchain network. This first consensus node can be a server connected to the blockchain network, or it can be a terminal device connected to the blockchain network; the specific form of the first consensus node is not limited here. The first consensus node can be one of the aforementioned... Figure 1 Any consensus node in the blockchain node system shown, for example, node 10a. The method may include at least the following steps:

[0128] Step S201: Upon receiving the initial transaction, perform a validity check on the initial transaction and obtain the validity check result;

[0129] Specifically, the first consensus node can verify the validity of each received transaction. Taking the initial transaction as an example, after receiving the initial transaction, the first consensus node can obtain the transaction signature information of the initial transaction and the device public key of the terminal device that sent the initial transaction. Then, it can verify the transaction signature information based on the device public key to obtain the transaction verification result. The transaction signature information is obtained by the terminal device signing the initial transaction using the device private key corresponding to the device public key.

[0130] Furthermore, the first consensus node can perform double-spending verification (also known as double-spending detection) on the initial transaction to obtain a double-spending verification result. Double-spending verification is used to verify whether the same virtual asset has been reused, i.e., to verify whether a double-spending attack exists. For example, the first consensus node can obtain the transaction timestamp corresponding to the initial transaction, and then search in the first transaction pool for duplicate transactions occurring before that timestamp. If none are found, the search continues in the blocks to be added to the blockchain. If still not found, the search continues in the blockchain until a double-spending verification result is finally obtained.

[0131] Furthermore, the first consensus node can use the transaction signature verification result and the double-spending verification result as the validity verification result corresponding to the initial transaction. When the transaction signature verification result indicates successful verification and the double-spending verification result indicates that there is no double-spending attack, the validity verification result indicates that the transaction is valid. Optionally, when the transaction signature verification result indicates verification failure or the double-spending verification result indicates the existence of a double-spending attack, the validity verification result indicates that the transaction is invalid. In this case, the first consensus node can generate a transaction failure notification and return it to the terminal device that sent the initial transaction.

[0132] Step S202: If the validity verification result indicates that the transaction is valid, then the initial transaction is determined to have passed the validity verification, and the initial transaction that has passed the validity verification is broadcast to the second consensus node so that the second consensus node can execute the initial transaction that has passed the validity verification.

[0133] Specifically, if the validity verification result indicates that the transaction is valid, then the initial transaction has passed the validity verification. Therefore, the first consensus node can broadcast the initial transaction that has passed the validity verification to the second consensus node, so that the second consensus node can execute the initial transaction that has passed the validity verification. It can be understood that the transaction processing process of the second consensus node is consistent with that of the first consensus node. Therefore, the second consensus node can also perform validity verification on the received transactions through the process described in step S201 above.

[0134] Step S203: Execute the initial transaction, obtain the initial transaction execution record corresponding to the initial transaction, add the initial transaction execution record corresponding to the initial transaction to the first transaction execution dataset associated with the first transaction pool of the first consensus node, and add the initial transaction to the first transaction pool;

[0135] Specifically, when the initial transaction passes the validity check, the first consensus node can execute the valid initial transaction. The detailed implementation process can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0136] Step S204: Obtain a transaction list containing initial transactions from the first transaction pool, and use the initial transaction execution record corresponding to each transaction in the transaction list obtained from the first transaction execution dataset as the transaction data to be processed associated with the transaction list;

[0137] The specific implementation process for this step can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0138] Step S205: Package the transaction list and the transaction data to be processed to obtain the proposal block to be used for block consensus with the second consensus node in the blockchain network.

[0139] The specific implementation process for this step can be found above. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0140] Step S206: Perform block consensus on the proposal block to obtain the block consensus result of the proposal block;

[0141] The specific implementation process for this step can be found above. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0142] Step S207: If the block consensus result indicates that the consensus was successful, then it is determined that a consensus has been reached on the proposed block, and the proposed block after the consensus is reached is written into the blockchain corresponding to the blockchain network as the third target block.

[0143] Specifically, if the block consensus result indicates successful consensus, then a consensus has been reached on the proposed block. The first consensus node can then write the consensus-reached proposed block as the third target block into the corresponding blockchain of the blockchain network. For example, see again... Figure 4 ,like Figure 4 As shown, after proposal block 40x passes the block consensus, consensus node 40A can use proposal block 40x as the third target block and write it into blockchain 4. That is, proposal block 40x will be added to blockchain 4 as the next block after block 40m. It can be understood that the proposal block and the corresponding transaction execution result after consensus are reached can be written to the local cache and local storage of each consensus node.

[0144] Optionally, if the block consensus result indicates that consensus has failed, the proposed block can be discarded, and a new consensus node can be selected in the blockchain network as the packaging node (i.e., the first consensus node) for packaging. Then, a new round of block consensus can be started on the newly obtained proposed block.

[0145] Step S208: Update the account status version number corresponding to the transaction object associated with the transaction list.

[0146] Specifically, the first consensus node can update the account status version number corresponding to the transaction object associated with each transaction in the transaction list, that is, update the account status version number corresponding to the relevant transaction objects affected by the transaction to be verified at the ledger layer. It should be noted that when executing a transaction, the first consensus node writes the account status version number corresponding to the transaction object associated with that transaction into the write dataset corresponding to that transaction. It should be understood that a transaction object can refer to a user participating in the transaction, and the account status version number can be used to characterize the account status corresponding to the transaction object. At a certain block height, the account status version number corresponding to the same transaction object is the same. Each time a transaction is successfully executed and the relevant data is uploaded to the chain, the account status version number associated with that transaction needs to be updated. It should be understood that recording the relevant account status version number allows us to know at what state the corresponding transaction was executed (e.g., based on the latest block height in the current blockchain), and therefore conflict detection can be performed based on the recorded account status version number. In this embodiment, each consensus node can obtain the account status version number associated with a transaction before executing it and write it into the write dataset corresponding to that transaction. Optionally, the account status version number can be an incrementing integer, which is incremented by 1 with each update. For example, suppose transaction 1 instructs transaction object A to transfer virtual assets to transaction object B. When the first consensus node (such as node C) executes transaction 1, it will write the account status version number corresponding to both transaction object A and transaction object B into the write dataset corresponding to transaction 1. After subsequent conflict detection, the first consensus node can update both the account status version number corresponding to transaction object A and transaction object B, for example, by incrementing the account status version number corresponding to transaction object A by 1, and simultaneously incrementing the account status version number corresponding to transaction object B by 1.

[0147] As described above, in this embodiment of the application, each consensus node in the blockchain network can execute a transaction upon receiving it. Both transaction reception and execution can be performed in parallel, meaning multiple transactions can be received or executed simultaneously. Only after the transaction execution is complete is the transaction added to the transaction pool, and the corresponding transaction execution record is added to the transaction execution dataset associated with that pool. Subsequently, the first consensus node packages the transactions to be packaged and their corresponding execution records into a block for consensus. In other words, this embodiment advances the transaction execution process before adding the transaction to the transaction pool, decoupling the transaction execution and consensus processes. This reduces the consensus time consumed by the consensus process and fully utilizes the concurrent reception and execution capabilities of consensus nodes to improve system resource utilization, thereby increasing the blockchain's throughput.

[0148] Further, please see Figure 6, Figure 6 This is a flowchart illustrating a transaction data processing method provided in an embodiment of this application. Figure 6 As shown, this method can be jointly executed by a first consensus node and a second consensus node in a blockchain network. These first and second consensus nodes can be servers connected to the blockchain network or terminal devices connected to the blockchain network; the specific forms of the first and second consensus nodes are not limited here. The first consensus node can be one of the aforementioned... Figure 1 The second consensus node can be any consensus node in the blockchain node system shown, for example, node 10a. Figure 1 The illustrated blockchain node system includes a consensus node to be broadcast, for example, node 10b. The method may include at least the following steps:

[0149] Step S301: The first consensus node receives the initial transaction and verifies its validity to obtain the validity verification result. The specific process can be found above. Figure 5 Step S201 in the corresponding embodiment.

[0150] In step S302, if the validity verification result indicates that the transaction is valid, then the initial transaction is determined to have passed the validity verification, and the first consensus node broadcasts the initial transaction that has passed the validity verification to the second consensus node. It can be understood that the first consensus node performs similar processing on other received transactions.

[0151] Step S303: The first consensus node executes the initial transaction, obtaining the initial transaction execution record corresponding to the initial transaction. This initial transaction execution record can then be added to the first transaction execution dataset associated with the first transaction pool of the first consensus node, and the initial transaction is added to the first transaction pool. Further, the transaction list containing the initial transaction and the associated pending transaction data can be packaged to obtain the proposal block to be consensused with the second consensus node in the blockchain network. For details, please refer to the above. Figure 3 Steps S101-S103 in the corresponding embodiments.

[0152] In step S304, the first consensus node broadcasts the proposal block to the second consensus node.

[0153] Step S305: The first consensus node performs conflict detection on the proposed block based on the conflict detection strategy to obtain the first consensus result.

[0154] Specifically, the first consensus node can perform conflict detection on the proposed blocks and vote based on a conflict detection strategy to obtain the first consensus result. Conflict detection can include, but is not limited to, one or more of the following methods: verifying the block signature information of the proposed block, verifying the Merkle root in the proposed block, verifying whether the proposed block conforms to the blockchain chain principle, verifying whether the proposed block conforms to the proposal rules, validating the transaction list in the proposed block, performing local verification of the transaction execution record (i.e., pending transaction data) corresponding to each transaction in the proposed block, verifying the correlation of the transaction list in the proposed block, and detecting read-write set conflicts.

[0155] It is understood that the process of the first consensus node performing conflict detection on the proposal block is the same as the process of the second consensus node performing conflict detection on the proposal block. Therefore, the specific process of this step can be found in step S306 below.

[0156] In step S306, the second consensus node receives the proposal block broadcast by the first consensus node and performs conflict detection on the proposal block based on the conflict detection strategy to obtain the second consensus result.

[0157] Specifically, the second consensus node can receive the proposal block broadcast by the first consensus node in the blockchain network, and then perform conflict detection on the proposal block based on the conflict detection strategy to obtain the second consensus result of the proposal block.

[0158] Optionally, the second consensus node can verify the block signature information of the proposed block. Specifically, the second consensus node can obtain the block signature information of the proposed block, which is obtained by the first consensus node signing the proposed block using its private key. Further, the second consensus node can obtain the public key corresponding to this private key and verify the block signature information based on the public key, obtaining the block signature verification result. Based on the block signature verification result, the second consensus result corresponding to the proposed block can be determined. It can be understood that when the block signature verification result indicates verification failure, i.e., the block signature verification fails, the second consensus node can vote against the proposed block.

[0159] Optionally, the second consensus node can verify the Merkle root in the proposal block, that is, verify whether the Merkle root in the proposal block is calculated from the transactions in the transaction list and the corresponding initial transaction execution records. Specifically, the second consensus node can perform a hash operation on the transactions in the transaction list of the proposal block and the pending transaction data to obtain a hash value to be verified. Then, it can determine the root to be verified based on the hash value. Further, the second consensus node can compare the root to be verified with the Merkle root in the proposal block to obtain a root comparison result, and then determine the second consensus result corresponding to the proposal block based on the root comparison result. It can be understood that when the root comparison result indicates that the root to be verified is different from the Merkle root, the second consensus node can vote against the proposal block.

[0160] Optionally, the second consensus node can verify whether the proposed block conforms to the blockchain's chain principle, that is, verify whether the preceding block of the proposed block is the latest block currently held by the second consensus node. Specifically, the second consensus node can obtain the block hash value of the parent block (i.e., the preceding block) of the proposed block from the blockchain as the target parent block hash value. Then, it can obtain the parent block hash value from the proposed block, compare the target parent block hash value with the parent block hash value, and obtain the hash value comparison result. Based on the hash value comparison result, it can determine the second consensus result corresponding to the proposed block. It can be understood that when the hash value comparison result indicates that the target parent block hash value is different from the parent block hash value, the second consensus node can vote against the proposed block.

[0161] Optionally, the second consensus node can verify whether the proposed block conforms to the proposal rules. For example, it can verify whether the first consensus node is the correct master node (i.e., the proposing node). Based on the obtained node verification results, the second consensus result corresponding to the proposed block can be determined. It can be understood that when the node verification result indicates that the first consensus node is not the correct proposing node, the second consensus node can vote against the proposed block.

[0162] Optionally, the second consensus node can perform validity checks on the transaction list in the proposal block, that is, perform validity checks on each transaction in the transaction list, including transaction signature verification and double-spending verification, thereby obtaining the target validity check result. Based on the target validity check result, the second consensus result corresponding to the proposal block can be determined. See the above for details. Figure 5 The corresponding step S201 in the embodiment. It can be understood that when the target validity verification result indicates that there is a transaction in the transaction list that failed to verify the signature or that there is a transaction that is attacked by double-spending, the second consensus node can vote against the proposal block.

[0163] Optionally, the second consensus node can perform local verification of the initial transaction execution record (i.e., transaction data to be processed) corresponding to each transaction in the proposal block. Since the transactions in the proposal block are broadcast to the second consensus node before execution by the first consensus node, the second consensus node likely already possesses the transaction locally and may have already pre-executed it. Therefore, the second consensus node can compare the data after the relevant transaction execution, such as comparing the transaction execution result, the transaction read / write set after execution, and the latest block height of the ledger at the time of transaction execution. Specifically, the second consensus node can treat transactions in the transaction list as transactions to be verified and use the local transaction execution record corresponding to the transaction to be verified, obtained from the second transaction execution dataset, as the local transaction data associated with the transaction to be verified. The second transaction execution dataset is associated with the second transaction pool of the second consensus node. It can be understood that the second transaction pool can also store transactions to be packaged (including transactions to be verified). The second transaction execution dataset is used to record the local transaction record corresponding to each transaction received by the second consensus node. The local transaction execution record corresponding to the transaction to be verified is obtained by the second consensus node executing the transaction to be verified. It is understandable that due to network transmission latency, the data stored by some consensus nodes may lag behind that of other consensus nodes, which may lead to inconsistencies in transaction execution records obtained by different nodes executing the same transaction. Furthermore, the second consensus node can perform local verification of the pending transaction data in the proposal block based on its local transaction data, obtain the local verification result, and then determine the second consensus result corresponding to the proposal block based on the local verification result.

[0164] For example, suppose a proposal block contains a transaction list including transaction 1, transaction 2, and transaction 3. Transaction 1, transaction 2, and transaction 3 can all be collectively referred to as transactions to be verified. Simultaneously, the initial transaction execution record corresponding to transaction 1 is transaction execution record A1, the initial transaction execution record corresponding to transaction 2 is transaction execution record A2, and the initial transaction execution record corresponding to transaction 3 is transaction execution record A3. Transaction execution records A1, A2, and A3 can all be collectively referred to as transaction data to be processed. These initial transaction execution records are obtained by the first consensus node after executing transactions 1, 2, and 3 respectively. Similarly, after the second consensus node executes transaction 1, it obtains the local transaction execution record corresponding to transaction 1 as transaction execution record B1; after executing transaction 2, it obtains the local transaction execution record corresponding to transaction 2 as transaction execution record B2; and after executing transaction 3, it obtains the local transaction execution record corresponding to transaction 3 as transaction execution record B3. Transaction execution records B1, B2, and B3 can all be collectively referred to as local transaction data. Therefore, the second consensus node can perform local verification on transaction execution record A1 based on transaction execution record B1 to obtain local verification result C1; perform local verification on transaction execution record A2 based on transaction execution record B2 to obtain local verification result C2; and perform local verification on transaction execution record A3 based on transaction execution record B3 to obtain local verification result C3. Finally, the second consensus result corresponding to the proposal block can be determined based on the local verification results C1, C2, and C3.

[0165] In one optional implementation, the transaction data to be processed may include the execution result of the target transaction corresponding to the transaction to be verified, the target transaction read / write set, and a first block height. The first block height is the block height of the first block with a first maximum generation timestamp obtained by the first consensus node from the blockchain network when executing the transaction to be verified. It can be understood that the transaction to be verified includes the initial transaction; therefore, the target transaction execution result includes the initial transaction execution result corresponding to the initial transaction, the target transaction read / write set includes the initial transaction read / write set corresponding to the initial transaction, and the first block height includes the initial block height. Similarly, the local transaction data may include the local transaction execution result corresponding to the transaction to be verified, the local transaction read / write set, and a second block height. The second block height is the block height of the second block with a second maximum generation timestamp obtained by the second consensus node from the blockchain network when executing the transaction to be verified. It should be understood that the second consensus node can compare the target transaction execution result with the local transaction execution result to obtain a first comparison result. If the first comparison result indicates that the execution result of the target transaction is the same as the execution result of the local transaction, then the first block height can be further compared with the second block height to obtain the second comparison result. Then, the local verification result corresponding to the proposal block can be determined based on the second comparison result.

[0166] Optionally, when the first maximum generation timestamp is the same as the second maximum generation timestamp, the second comparison result will indicate that the first block height is the same as the second block height. Then, the second consensus node can further compare the target transaction read / write set with the local transaction read / write set to obtain the third comparison result. Finally, the local verification result corresponding to the proposal block can be determined based on the third comparison result.

[0167] Optionally, when the first maximum generation timestamp differs from the second maximum generation timestamp, the second comparison result will indicate that the first block height and the second block height are not the same. The second consensus node can then further compare the first account state version number with the second account state version number to obtain a fourth comparison result. Further, if the fourth comparison result indicates that the first account state version number and the second account state version number are not the same, a third account state version number associated with the transaction to be verified and having a third maximum update timestamp can be obtained from the blockchain network. The first account state version number can then be compared with the third account state version number to obtain a fifth comparison result. If the fifth comparison result indicates that the third account state version number is lower than the first account state version number, the transaction to be verified can be re-executed to obtain an updated transaction execution result. The target transaction execution result can then be compared with the updated transaction execution result to obtain a sixth comparison result. Finally, the local verification result corresponding to the proposal block can be determined based on the sixth comparison result.

[0168] The target transaction read / write set includes a first account state version number, which refers to the account state version number associated with the transaction to be verified and having a first maximum update timestamp, obtained by the first consensus node from the blockchain network (e.g., the local cache of the first consensus node) when executing the transaction to be verified. Similarly, the local transaction read / write set includes a second account state version number, which refers to the account state version number associated with the transaction to be verified and having a second maximum update timestamp, obtained by the second consensus node from the blockchain network (e.g., the local cache of the second consensus node) when executing the transaction to be verified.

[0169] It should be understood that when the local verification result indicates a failure, the second consensus node can vote against the proposed block. Optionally, when the transaction execution results do not match, i.e., the first comparison result indicates that the target transaction execution result is different from the local transaction execution result, the second consensus node can vote against the proposed block. Optionally, when the latest ledger height is consistent at the time of transaction execution but the transaction read / write set is inconsistent after execution, i.e., the second comparison result indicates that the first block height is the same as the second block height, but the third comparison result indicates that the target transaction read / write set is different from the local transaction read / write set, the second consensus node can vote against the proposed block. Optionally, when the latest ledger height is inconsistent at the time of transaction execution, the account state version number can be compared. If they are inconsistent, the version number in the current second consensus node's local cache can be compared. The system checks whether the latest account status version number (i.e., the third account status version number) matches the account status version number in the proposal block (i.e., the first account status version number). If the relevant account status version number in the local cache is lower than the account status version number in the proposal block, it indicates that the second consensus node is lagging behind the first consensus node. The second consensus node can then re-execute the transaction based on the latest data read from its local cache and compare the result of the re-executed transaction with the result of the transaction in the proposal block. If they are inconsistent (i.e., the sixth comparison result indicates that the target transaction execution result is different from the updated transaction execution result), the second consensus node can vote against the proposal block. It is understandable that data tampering, errors in the running code, and data lag can all cause the target transaction execution result to differ from the updated transaction execution result.

[0170] Optionally, the second consensus node can perform correlation verification and read-write set conflict detection on the transaction list in the proposal block. Specifically, it can perform correlation verification and read-write set conflict detection on the transaction list in the proposal block sequentially. The process can be as follows: The second consensus node can perform correlation verification on the transaction list, obtain the correlation verification result, and then, based on the correlation verification result, obtain at least two related transactions from the transaction list, and obtain the transaction read-write sets corresponding to at least two related transactions from the pending transaction data. Further, based on the transaction execution order corresponding to the at least two related transactions, it can perform read-write set conflict detection on each transaction read-write set, obtain the read-write set conflict detection result, and finally determine the second consensus result corresponding to the proposal block based on the read-write set conflict detection result. It should be understood that when the read-write set conflict detection result indicates a failure, the second consensus node can vote against the proposal block. For example, in transaction list X, transactions 1 and 3 are related. For instance, transaction 1 involves user A transferring the first asset to be transferred (e.g., 100 yuan) from their remaining assets (e.g., 200 yuan) to user B, and transaction 3 involves user A transferring the second asset to be transferred (e.g., 70 yuan) from their remaining assets to user B. Transaction 1 and transaction 3 can be considered related transactions. If the transaction timestamp of transaction 1 is less than that of transaction 3, the write dataset of transaction 1 and the read dataset of transaction 3 can be obtained. The write dataset of transaction 1 and the read dataset of transaction 3 are compared to obtain the read-write set conflict detection result. If the key data is inconsistent, for example, the write dataset of transaction 1 records that user A's remaining assets after executing transaction 1 are 100 yuan, while the read dataset of transaction 3 records that user A's remaining assets read when executing transaction 3 are still 200 yuan as before executing transaction 1, then the related read-write datasets conflict, and the read-write set conflict detection result indicates that the check failed.

[0171] It should be understood that, optionally, the second consensus node can jointly determine the second consensus result corresponding to the proposed block based on the block signature verification result, the root comparison result, the hash value comparison result, the node verification result, the target validity verification result, the local verification result, and the read-write set conflict detection result. In other words, the second consensus node will only vote in favor of the proposed block after all the above verifications have passed.

[0172] The conflict detection in this application embodiment may also include other detection methods, which will not be listed here.

[0173] In step S307, the second consensus node returns the second consensus result to the first consensus node. In other words, the second consensus node can broadcast the voting result.

[0174] Step S308: The first consensus node receives the second consensus result returned by the second consensus node and uses the first consensus result and the second consensus result as the block consensus result of the proposal block.

[0175] Specifically, the first consensus node can use the first consensus result and the second consensus result as the block consensus result for the proposed block. Optionally, the block consensus result can be obtained based on the number of affirmative or negative votes. For example, when the number of affirmative votes is greater than a first voting threshold (e.g., the percentage of affirmative votes exceeds 2 / 3 of the total votes), the block consensus result indicates successful consensus, thus confirming that consensus on the proposed block has been reached. Conversely, if the number of negative votes is greater than a second voting threshold (e.g., the percentage of negative votes exceeds 2 / 3 of the total votes), the block consensus result indicates failed consensus, thus confirming that consensus on the proposed block cannot be reached. The first and second voting thresholds can be set as needed.

[0176] Step S309: Based on the block consensus result, the first consensus node writes the proposed block after consensus is reached into the corresponding blockchain of the blockchain network, and updates the account status version number corresponding to the transaction object associated with the transaction list. For details, please refer to the above. Figure 5 Steps S207-S208 in the corresponding embodiments.

[0177] For further information, please see [link / reference]. Figure 7 , Figure 7 This is an interactive schematic diagram of a blockchain transaction process provided in an embodiment of this application. For example... Figure 7 As shown, application client 70A runs on a terminal device. Application client 70A and server 71 running in consensus node 70B have a data connection. Optionally, application client 70A and server 71 can communicate using the WebSocket protocol. WebSocket is a protocol for full-duplex communication over a single TCP (Transmission Control Protocol) connection. WebSocket simplifies data exchange between the application client and server and allows the server to proactively push data to the client. It should be understood that consensus node 70B can be any consensus node in the blockchain network; for example, it can be any of the following: Figure 1Node 10a is shown. Consensus nodes 70C and 70B are in the same blockchain network and can interact with each other, such as broadcasting blocks or transactions. The internal structure of each consensus node is identical; this embodiment only uses consensus node 70B as an example. When consensus node 70B receives a transaction from application client 70A through server 71, it can verify the transaction's validity, including transaction signature verification and double-spending verification. When the transaction passes the validity verification, consensus node 70B can call virtual machine 74 in execution module 75 to execute the transaction. At this time, virtual machine 74 can read the corresponding data (i.e., read the dataset) from storage module 76 (i.e., storage layer) to execute the transaction, obtaining the corresponding transaction execution record. This transaction execution record can then be added to storage module 76, and the transaction added to transaction pool 72. Furthermore, the consensus module 73 can periodically retrieve a batch of transaction lists to be packaged from the transaction pool 72 according to the consensus rhythm, and retrieve the transaction data to be processed associated with the transaction list from the storage module 76. It can then package the transaction list and the transaction data to be processed into a proposal block and broadcast the proposal block to other consensus nodes (such as consensus node 70C) for consensus. During the consensus process, the consensus nodes will perform conflict detection and voting on the proposal block to obtain the block consensus result. Once consensus is reached on the proposal block, the consensus node can write the proposal block and related transaction execution results into the storage module 76, and then start a new round of packaging and consensus. The log manager 77 can listen for corresponding events from the server 71, transaction pool 72, consensus module 73, and execution module 75.

[0178] Please see Figure 8 This is a schematic diagram of the structure of a transaction data processing apparatus provided in an embodiment of this application. The transaction data processing apparatus can be a computer program (including program code) running on a computer device; for example, the transaction data processing apparatus is an application software. The apparatus can be used to execute corresponding steps in the transaction data processing method provided in the embodiments of this application. Figure 8 As shown, the transaction data processing device 1 can operate on the first consensus node in the blockchain network, and this first consensus node can be the aforementioned Figure 2 The consensus node 20A in the corresponding embodiment. The transaction data processing device 1 may include: an execution adding module 11, a data acquisition module 12, and a packaging consensus module 13;

[0179] The execution addition module 11 is used to execute the initial transaction upon receiving the initial transaction, obtain the initial transaction execution record corresponding to the initial transaction, add the initial transaction execution record corresponding to the initial transaction to the first transaction execution dataset associated with the first transaction pool of the first consensus node, and add the initial transaction to the first transaction pool; the first transaction execution dataset is used to record the initial transaction execution record corresponding to each transaction received by the first consensus node;

[0180] The data acquisition module 12 is used to acquire a transaction list containing initial transactions from the first transaction pool, and to use the initial transaction execution record corresponding to each transaction in the transaction list, which is acquired from the first transaction execution dataset, as the transaction data to be processed associated with the transaction list.

[0181] The consensus packaging module 13 is used to package the transaction list and the transaction data to be processed to obtain the proposal block to be consensused with the second consensus node in the blockchain network. The block consensus is then performed on the proposal block to obtain the block consensus result of the proposal block.

[0182] The specific implementation methods of the execution addition module 11, data acquisition module 12, and packaging consensus module 13 can be found above. Figure 3 The descriptions of steps S101-S103 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0183] Please see again Figure 8 The transaction data processing device 1 may also include: a block addition module 14, a version update module 15, and a validity verification module 16;

[0184] The block addition module 14 is used to determine that a consensus has been reached on the proposed block if the block consensus result indicates that the consensus has been successful, and to write the proposed block after the consensus has been reached as the third target block into the corresponding blockchain of the blockchain network.

[0185] Version update module 15 is used to update the account status version number corresponding to the transaction object associated with the transaction list;

[0186] The validity verification module 16 is used to verify the validity of the initial transaction and obtain the validity verification result. If the validity verification result indicates that the transaction is valid, the initial transaction is determined to have passed the validity verification, and the initial transaction that has passed the validity verification is broadcast to the second consensus node so that the second consensus node can execute the initial transaction that has passed the validity verification.

[0187] The specific implementation methods of the block addition module 14, version update module 15, and validity verification module 16 can be found above. Figure 5The descriptions of steps S207-S208 and S201 in the corresponding embodiments will not be repeated here.

[0188] Please see again Figure 8 The execution addition module 11 may include: a data reading unit 111, a transaction execution unit 112, a height acquisition unit 113, and a record determination unit 114;

[0189] The data reading unit 111 is used to obtain the initial business contract for executing the initial transaction when the initial transaction is received, and based on the initial business contract, call the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the blockchain network.

[0190] The transaction execution unit 112 is used to call the virtual machine to execute the initial transaction based on the initial read dataset, obtain the initial transaction execution result corresponding to the initial transaction, write the initial transaction execution result into the initial write dataset corresponding to the initial transaction, and use the initial read dataset and the initial write dataset as the initial transaction read-write set corresponding to the initial transaction.

[0191] The height acquisition unit 113 is used to take the block with the initial maximum generation timestamp obtained from the blockchain network when executing the initial transaction as the first target block, and take the block height of the first target block as the initial block height.

[0192] The record determination unit 114 is used to use the initial transaction execution result, the initial transaction read / write set, and the initial block height as the initial transaction execution record corresponding to the initial transaction.

[0193] The specific implementation methods of the data reading unit 111, transaction execution unit 112, height acquisition unit 113, and record determination unit 114 can be found above. Figure 3 The description of step S101 in the corresponding embodiments will not be repeated here.

[0194] The consensus module 13 may include: a hash operation unit 131, a block generation unit 132, a conflict detection unit 133, a block broadcasting unit 134, and a consensus determination unit 135.

[0195] The hash operation unit 131 is used to take the transactions in the transaction list as transactions to be verified, perform hash operation on the transactions to be verified and the transaction data to be processed, obtain the transaction hash value associated with the transaction to be verified, and determine the Merkle root corresponding to the transaction to be verified based on the transaction hash value.

[0196] The block generation unit 132 is used to obtain the block with the target maximum generation timestamp from the blockchain network as the second target block, use the block hash value of the second target block as the parent block hash value of the next block of the second target block, generate the next block of the second target block based on the transaction to be verified, the transaction data to be processed, the Merkle root and the parent block hash value, and use the next block of the second target block as the proposal block to be consensused with the second consensus node in the blockchain network.

[0197] The conflict detection unit 133 is used to perform conflict detection on the proposal block based on the conflict detection strategy to obtain the first consensus result.

[0198] Block broadcasting unit 134 is used to broadcast the proposal block to the second consensus node, so that the second consensus node can perform conflict detection on the proposal block based on the conflict detection strategy and obtain the second consensus result;

[0199] The consensus determination unit 135 is used to receive the second consensus result returned by the second consensus node and use the first consensus result and the second consensus result as the block consensus result of the proposal block.

[0200] The specific implementation methods of the hash operation unit 131, block generation unit 132, conflict detection unit 133, block broadcasting unit 134, and consensus determination unit 135 can be found above. Figure 3 The description of step S103 in the corresponding embodiments will not be repeated here.

[0201] The valid verification module 16 may include: a signature verification unit 161, a double-spending verification unit 162, and a result determination unit 163;

[0202] The signature verification unit 161 is used to obtain the transaction signature information of the initial transaction and the device public key of the terminal device that sent the initial transaction, and to perform transaction signature verification on the transaction signature information based on the device public key to obtain the transaction signature verification result; the transaction signature information is obtained by the terminal device signing the initial transaction with the device private key corresponding to the device public key;

[0203] Double-spending verification unit 162 is used to perform double-spending verification on the initial transaction to obtain the double-spending verification result;

[0204] The result determination unit 163 is used to take the transaction signature verification result and the double-spending verification result as the validity verification result corresponding to the initial transaction; when the transaction signature verification result indicates that the signature verification is successful and the double-spending verification result indicates that there is no double-spending attack, the validity verification result is determined to indicate that the transaction is valid.

[0205] The specific implementation methods of the signature verification unit 161, the double-spending verification unit 162, and the result determination unit 163 can be found in the above description. Figure 5 The description of step S201 in the corresponding embodiments will not be repeated here.

[0206] Further, please see Figure 9 This is a schematic diagram of the structure of a transaction data processing apparatus provided in an embodiment of this application. The transaction data processing apparatus can be a computer program (including program code) running on a computer device; for example, the transaction data processing apparatus is an application software. The apparatus can be used to execute corresponding steps in the transaction data processing method provided in the embodiments of this application. Figure 9 As shown, the transaction data processing device 2 can operate as a second consensus node in the blockchain network, and this second consensus node can be the aforementioned Figure 2 The consensus node 20B in the corresponding embodiment. The transaction data processing device 2 may include: a receiving module 21 and a detection module 22;

[0207] The receiving module 21 is used to receive the proposal block broadcast by the first consensus node in the blockchain network. The proposal block is obtained by the first consensus node by packaging the transaction list and the pending transaction data associated with the transaction list. The transaction list refers to the list containing initial transactions obtained by the first consensus node from the first transaction pool of the first consensus node. The pending transaction data includes the initial transaction execution record corresponding to each transaction in the transaction list in the first transaction execution dataset. The first transaction execution dataset is associated with the first transaction pool and is used to record the initial transaction execution record corresponding to each transaction received by the first consensus node. The initial transaction execution record corresponding to the initial transaction is added to the first transaction execution dataset by the first consensus node. The initial transaction execution record corresponding to the initial transaction is obtained by the first consensus node executing the initial transaction when it receives the initial transaction.

[0208] The detection module 22 is used to detect conflicts in the proposal block based on the conflict detection strategy, obtain the second consensus result of the proposal block, and return the second consensus result to the first consensus node.

[0209] The specific implementation methods of the receiving module 21 and the detection module 22 can be found in the above description. Figure 6 The description of step S306 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0210] Please see again Figure 9 The detection module 22 may include: a data acquisition unit 221, a local verification unit 222, an association verification unit 223, and a read / write detection unit 224;

[0211] The data acquisition unit 221 is used to take the transactions in the transaction list as transactions to be verified, and to take the local transaction execution records corresponding to the transactions to be verified obtained from the second transaction execution dataset as local transaction data associated with the transactions to be verified; the second transaction execution dataset is associated with the second transaction pool of the second consensus node; the second transaction execution dataset is used to record the local transaction records corresponding to each transaction received by the second consensus node; the local transaction execution records corresponding to the transactions to be verified are obtained by the second consensus node executing the transactions to be verified;

[0212] The local verification unit 222 is used to perform local verification on the pending transaction data in the proposal block based on local transaction data to obtain the local verification result; and to determine the second consensus result corresponding to the proposal block based on the local verification result.

[0213] The association verification unit 223 is used to perform association verification on the transaction list and obtain the association verification result; based on the association verification result, at least two related transactions with an association relationship are obtained from the transaction list, and at least two transaction read / write sets corresponding to the related transactions are obtained from the transaction data to be processed.

[0214] The read-write detection unit 224 is used to perform read-write set conflict detection on each transaction read-write set based on the transaction execution order corresponding to at least two related transactions, and obtain the read-write set conflict detection result; and determine the second consensus result corresponding to the proposal block based on the read-write set conflict detection result.

[0215] The specific implementation methods of the data acquisition unit 221, local verification unit 222, association verification unit 223, and read / write detection unit 224 can be found above. Figure 6 The description of step S306 in the corresponding embodiment will not be repeated here.

[0216] The pending transaction data includes the execution result of the target transaction corresponding to the pending transaction, the target transaction read / write set, and the first block height; the first block height is the block height of the first block with the first maximum generation timestamp obtained by the first consensus node from the blockchain network when executing the pending transaction; the local transaction data includes the execution result of the local transaction corresponding to the pending transaction, the local transaction read / write set, and the second block height; the second block height is the block height of the second block with the second maximum generation timestamp obtained by the second consensus node from the blockchain network when executing the pending transaction.

[0217] The local verification unit 222 may include: a first comparison subunit 2221, a second comparison subunit 2222, and a result determination subunit 2223;

[0218] The first comparison subunit 2221 is used to compare the target transaction execution result with the local transaction execution result to obtain the first comparison result;

[0219] The second comparison subunit 2222 is used to compare the first block height with the second block height to obtain a second comparison result if the first comparison result indicates that the target transaction execution result is the same as the local transaction execution result;

[0220] The result determination subunit 2223 is used to determine the local verification result corresponding to the proposal block based on the second comparison result.

[0221] Among them, the first maximum generation timestamp is the same as the second maximum generation timestamp;

[0222] The result determines subunit 2223, which is specifically used to compare the target transaction read / write set with the local transaction read / write set when the second comparison result indicates that the height of the first block is the same as the height of the second block, to obtain the third comparison result; and to determine the local verification result corresponding to the proposal block based on the third comparison result.

[0223] The first maximum generation timestamp is different from the second maximum generation timestamp; the target transaction read / write set includes a first account status version number, which refers to the account status version number associated with the transaction to be verified and having the first maximum update timestamp obtained by the first consensus node from the blockchain network when executing the transaction to be verified; the local transaction read / write set includes a second account status version number, which refers to the account status version number associated with the transaction to be verified and having the second maximum update timestamp obtained by the second consensus node from the blockchain network when executing the transaction to be verified;

[0224] The result determines subunit 2223, which is specifically used to compare the first account status version number with the second account status version number when the second comparison result indicates that the first block height is different from the second block height, to obtain the fourth comparison result; if the fourth comparison result indicates that the first account status version number is different from the second account status version number, then the third account status version number associated with the transaction to be verified and having the third maximum update timestamp is obtained from the blockchain network, and the first account status version number is compared with the third account status version number to obtain the fifth comparison result; if the fifth comparison result indicates that the third account status version number is lower than the first account status version number, then the transaction to be verified is re-executed to obtain the updated transaction execution result, and the target transaction execution result is compared with the updated transaction execution result to obtain the sixth comparison result; based on the sixth comparison result, the local verification result corresponding to the proposal block is determined.

[0225] The specific implementation methods of the first comparison subunit 2221, the second comparison subunit 2222, and the result determination subunit 2223 can be found above. Figure 6 The description of step S306 in the corresponding embodiment will not be repeated here.

[0226] Please see Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 10 As shown, 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 enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1004 may be high-speed RAM or non-volatile memory, such as at least one disk drive. The memory 1005 may optionally be at least one storage device located remotely from the processor 1001. Figure 10 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.

[0227] In such Figure 10 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 execute the aforementioned... Figure 3 , Figure 5 , Figure 6 The description of the transaction data processing method in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0228] 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 data processing device 1 or transaction data processing device 2 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 , Figure 6The description of the transaction data processing method 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-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0229] The aforementioned computer-readable storage medium can be an internal storage unit of the transaction data processing apparatus provided in any of the foregoing embodiments or the aforementioned computer device, such as a hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0230] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The 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 aforementioned... Figure 3 , Figure 5 , Figure 6 The method is provided in any of the corresponding embodiments. Furthermore, the beneficial effects of using the same method will not be repeated here. 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.

[0231] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0232] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0233] 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 method for processing transaction data, characterized in that, include: When the first consensus node in the blockchain network receives an initial transaction, it executes the initial transaction, obtains the initial transaction execution record corresponding to the initial transaction, adds the initial transaction execution record corresponding to the initial transaction to the first transaction execution dataset associated with the first transaction pool of the first consensus node, and adds the initial transaction to the first transaction pool. The first transaction execution dataset is used to record the initial transaction execution record corresponding to each transaction received by the first consensus node; The first consensus node obtains a transaction list containing the initial transaction from the first transaction pool, and obtains pending transaction data associated with the transaction list from the first transaction execution dataset; the pending transaction data contains the initial transaction execution record corresponding to each transaction in the transaction list; The first consensus node packages the transaction list and the transaction data to be processed to obtain a proposal block to be consensused with the second consensus node in the blockchain network. The first consensus node performs conflict detection on the proposal block based on the conflict detection strategy to obtain the first consensus result of the proposal block and broadcasts the proposal block to the second consensus node. When the second consensus node receives the proposal block, it performs conflict detection on the proposal block based on the conflict detection strategy, obtains the second consensus result of the proposal block, and returns the second consensus result to the first consensus node. The first consensus node receives the second consensus result returned by the second consensus node, and uses the first consensus result and the second consensus result as the block consensus result of the proposal block.

2. The method according to claim 1, characterized in that, If the blockchain network has a single-layer structure, then the first consensus node is a consensus node in the blockchain network with the single-layer structure, and the initial transaction is sent directly from the terminal device to the blockchain network with the single-layer structure.

3. The method according to claim 1, characterized in that, If the blockchain network has a layered structure, the blockchain network with the layered structure includes a business network, a core consensus network, and a routing network for network isolation between the business network and the core consensus network; the first consensus node is a consensus node in the core consensus network; the initial transaction is sent by the terminal device to the routing node in the routing network and then forwarded by the routing node to the core consensus network; the terminal device belongs to the business node in the business network.

4. The method according to claim 1, characterized in that, When the first consensus node in the blockchain network receives the initial transaction, it executes the initial transaction and obtains the initial transaction execution record corresponding to the initial transaction, including: When the first consensus node in the blockchain network receives an initial transaction, it obtains an initial business contract for executing the initial transaction. Based on the initial business contract, it calls the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the storage layer of the first consensus node. Based on the initial read dataset, the first consensus node calls the virtual machine to execute the initial transaction, obtains the initial transaction execution result corresponding to the initial transaction, writes the initial transaction execution result into the initial write dataset corresponding to the initial transaction, and uses the initial read dataset and the initial write dataset as the initial transaction read-write set corresponding to the initial transaction. The first consensus node takes the block with the initial maximum generation timestamp obtained from the local storage contained in the storage layer of the first consensus node when executing the initial transaction as the first target block, and takes the block height of the first target block as the initial block height. The first consensus node uses the initial transaction execution result, the initial transaction read / write set, and the initial block height as the initial transaction execution record corresponding to the initial transaction.

5. The method according to claim 4, characterized in that, The storage layer of the first consensus node includes the local cache and local storage of the first consensus node; The step of calling the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the storage layer of the first consensus node includes: The first consensus node calls the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the local cache of the first consensus node; If reading from the local cache of the first consensus node fails, the first consensus node calls the virtual machine to read the initial read dataset corresponding to the initial transaction from the local storage of the first consensus node.

6. The method according to claim 5, characterized in that, The local cache of the first consensus node includes a transaction read cache and a transaction write cache corresponding to the initial transaction; The first consensus node invokes the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the local cache of the first consensus node, including: The first consensus node invokes the virtual machine corresponding to the first consensus node to read the initial read dataset corresponding to the initial transaction from the transaction read cache corresponding to the initial transaction; The first consensus node, based on the initial read dataset, calls the virtual machine to execute the initial transaction, obtains the initial transaction execution result corresponding to the initial transaction, writes the initial transaction execution result into the initial write dataset corresponding to the initial transaction, and uses the initial read dataset and the initial write dataset as the initial transaction read / write set corresponding to the initial transaction, including: The first consensus node, based on the initial read dataset, calls the virtual machine to execute the initial transaction and obtains the initial transaction execution result corresponding to the initial transaction; The first consensus node adds the initial transaction execution result to the transaction write cache corresponding to the initial transaction, and constructs the initial write dataset corresponding to the initial transaction based on the data stored in the transaction write cache; The first consensus node uses the initial read dataset and the initial write dataset as the initial transaction read / write set corresponding to the initial transaction.

7. The method according to claim 1, characterized in that, The first consensus node obtains a transaction list containing the initial transaction from the first transaction pool, including: The first consensus node obtains a list of transactions containing the initial transaction from its first transaction pool based on a configured packaging strategy; the packaging strategy includes one or more strategies based on transaction time priority and transaction fee priority.

8. The method according to claim 1, characterized in that, The first consensus node packages the transaction list and the pending transaction data into a proposal block to be agreed upon with the second consensus node in the blockchain network, including: The first consensus node takes the transactions in the transaction list as transactions to be verified, performs a hash operation on the transactions to be verified and the transaction data to be processed, and obtains the transaction hash value associated with the transactions to be verified. The first consensus node generates a proposal block based on the transaction hash value, the transaction to be verified, and the transaction data to be processed, which is to be used for block consensus with the second consensus node in the blockchain network.

9. The method according to claim 8, characterized in that, The step of performing a hash operation on the transaction to be verified and the transaction data to be processed to obtain a transaction hash value associated with the transaction to be verified includes: The first consensus node performs a hash operation on the transaction to be verified to obtain a first hash value; The first consensus node performs a hash operation on the transaction data to be processed to obtain a second hash value; The first consensus node performs a hash operation on the first hash value and the second hash value to obtain a transaction hash value associated with the transaction to be verified.

10. The method according to claim 8, characterized in that, The first consensus node generates a proposal block based on the transaction hash value, the transaction to be verified, and the transaction data to be processed, which is to be used for block consensus with the second consensus node in the blockchain network, including: The first consensus node determines the Merkle root corresponding to the transaction to be verified based on the transaction hash value; The first consensus node obtains the block with the target maximum generation timestamp from the blockchain network as the second target block, uses the block hash value of the second target block as the parent block hash value of the next block of the second target block, and generates block header information based on the Merkle root and the parent block hash value; The first consensus node generates the block body based on the Merkel path formed by the transaction to be verified, the transaction data to be processed, and the transaction hash value; The first consensus node generates the next block of the second target block based on the block header information and the block body, and uses the next block of the second target block as a proposal block to be used for block consensus with the second consensus node in the blockchain network.

11. The method according to claim 1, characterized in that, Also includes: If the number of affirmative votes in the voting results of the first consensus node and the second consensus node is greater than the first voting threshold, the block consensus result indicates that the consensus is successful, and it is determined that a consensus has been reached on the proposed block. The first consensus node writes the proposed block after the consensus is reached into the blockchain corresponding to the blockchain network as the third target block. The first consensus node increments the account status version number corresponding to the transaction object associated with the transaction list by 1.

12. The method according to claim 1, characterized in that, Also includes: The first consensus node performs a validity check on the initial transaction and obtains the validity check result. If the validity verification result indicates that the transaction is invalid, the first consensus node generates a transaction failure notification and returns the transaction failure notification to the terminal device that sent the initial transaction.

13. The method according to claim 12, characterized in that, The first consensus node performs a validity check on the initial transaction and obtains a validity check result, including: The first consensus node obtains the transaction signature information of the initial transaction and the device public key of the terminal device that sent the initial transaction, and performs transaction signature verification on the transaction signature information based on the device public key to obtain the transaction verification result; the transaction signature information is obtained by the terminal device signing the initial transaction using the device private key corresponding to the device public key; The first consensus node performs double-spending verification on the initial transaction to obtain the double-spending verification result. The first consensus node uses the transaction signature verification result and the double-spending verification result as the validity verification result corresponding to the initial transaction; When the transaction verification result indicates that the verification failed, or the double-spending verification result indicates that a double-spending attack exists, the first consensus node determines that the validity verification result indicates that the transaction is invalid.

14. The method according to claim 1, characterized in that, The process of performing conflict detection on the proposal block based on the conflict detection strategy to obtain the second consensus result of the proposal block includes: The second consensus node performs hash operations on the transactions in the transaction list and the pending transaction data in the proposal block to obtain a hash value to be verified, and determines the root of the tree to be verified based on the hash value to be verified. The second consensus node compares the root tree to be verified with the Merkel root tree in the proposal block to obtain the root tree comparison result; The second consensus node determines the second consensus result corresponding to the proposal block based on the tree root comparison result.

15. The method according to claim 1, characterized in that, The process of performing conflict detection on the proposal block based on the conflict detection strategy to obtain the second consensus result of the proposal block includes: The second consensus node obtains the block signature information of the proposal block; the block signature information is obtained by the first consensus node signing the proposal block using the first consensus node's private key; The second consensus node obtains the node public key corresponding to the node private key, and performs block signature verification on the block signature information based on the node public key to obtain the block signature verification result; The second consensus node determines the second consensus result corresponding to the proposal block based on the block signature verification result.

16. The method according to claim 1, characterized in that, The process of performing conflict detection on the proposal block based on the conflict detection strategy to obtain the second consensus result of the proposal block includes: The second consensus node obtains the block hash value of the preceding block of the proposal block and uses the block hash value of the preceding block as the target parent block hash value; The second consensus node compares the hash value of the target parent block with the hash value of the parent block in the proposal block to obtain the hash value comparison result; The second consensus node determines the second consensus result corresponding to the proposal block based on the hash value comparison result.

17. A computer device, characterized in that, include: Processor and memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to invoke the computer program to cause the computer device to perform the method according to any one of claims 1-16.

18. 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-16.

19. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, the computer instructions being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-16.

Images