A blockchain-based data processing method, device and readable storage medium

Abstract

The application discloses a data processing method and device based on a block chain and a readable storage medium. The method comprises the following steps: obtaining a target transaction containing a target execution sequence identifier; if the target transaction is in a prepared state, adding the target transaction and the target execution sequence identifier to a target account preparation queue to obtain a transition account preparation queue; in the target account waiting queue, adding execution sequence identifiers which can constitute a sequence identifier continuous sequence with the target execution sequence identifier as upgrade execution sequence identifiers, and adding the upgrade execution sequence identifiers and the waiting transactions corresponding to the upgrade execution sequence identifiers in sequence to the transition account preparation queue to obtain an upgrade account preparation queue; and adding the target transaction in the upgrade account preparation queue and the waiting transactions corresponding to the upgrade execution sequence identifiers to a total preparation queue. The transactions in the total preparation queue are packed into a candidate block in the order of transaction insertion time. The application can improve the success rate of block chaining.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, device and readable storage medium based on blockchain. Background Technology

[0002] During transaction execution, the txNonce (Transaction Number once, the number of unique transactions) corresponding to the transaction and the accountNonce (Account Number once, the number of unique accounts) corresponding to the blockchain account that sent the transaction must be equal; otherwise, the transaction is invalid. If even one transaction in a block is invalid, the block will fail to reach consensus and cannot be added to the blockchain. The txNonce identifies the desired execution order of the transaction among the transactions sent by the blockchain account, incrementing from 0; the accountNonce identifies the number of transactions that the blockchain account has already executed in the current world state, also incrementing from 0.

[0003] Currently, in blockchain networks, after a blockchain node receives a transaction, it places the transaction in a transaction pool for caching, and then packages a portion of the transactions in the pool to generate a block. However, due to network fluctuations or user errors, transactions with different txNonces under the same blockchain account may not arrive at the blockchain node in exactly the ascending order. This can cause the transaction to be incorrectly considered illegitimate and unable to be accepted by the transaction pool. The blockchain system has a low fault tolerance rate. Even if a transaction is accepted by the transaction pool, there may be a mismatch between the txNonce of the transaction included in the block and the accountNonce of the account that sent the transaction in the current world state, resulting in the block failing to reach consensus and thus failing to be added to the blockchain. Summary of the Invention

[0004] This application provides a data processing method, device, and readable storage medium based on blockchain, which can enhance the fault tolerance of the blockchain system and improve the success rate of block uploading.

[0005] One embodiment of this application provides a blockchain-based data processing method, including:

[0006] Retrieve the target transaction sent by the target account, and retrieve the target account preparation queue and target account waiting queue corresponding to the target account; the target transaction contains a target execution order identifier; the target account preparation queue is used to store the prepared transactions in the prepared state, and the execution order identifiers that are mapped to the prepared transactions; the target account waiting queue is used to store the waiting transactions in the unprepared state, and the execution order identifiers that are mapped to the waiting transactions.

[0007] If the target transaction is in the ready state, the target transaction and the target execution order identifier are added to the target account preparation queue to obtain the transition account preparation queue.

[0008] In the target account waiting queue, the execution order identifier that can form a continuous sequence of order identifiers with the target execution order identifier is used as the upgrade execution order identifier. The upgrade execution order identifier and the waiting transaction corresponding to the upgrade execution order identifier are added to the transition account preparation queue in order to obtain the upgrade account preparation queue.

[0009] The target transaction and the waiting transaction corresponding to the upgrade execution order identifier in the upgrade account preparation queue are added to the total preparation queue; the transactions in the total preparation queue will be packaged into candidate blocks in the order of transaction insertion time.

[0010] One embodiment of this application provides a blockchain-based data processing device, including:

[0011] The acquisition module is used to acquire target transactions sent by the target account, and to acquire the target account preparation queue and target account waiting queue corresponding to the target account. The target transaction contains a target execution order identifier. The target account preparation queue is used to store the prepared transactions in the prepared state and the execution order identifiers that are mapped to the prepared transactions. The target account waiting queue is used to store the waiting transactions in the unprepared state and the execution order identifiers that are mapped to the waiting transactions.

[0012] The transaction transition module is used to add the target transaction and the target execution order identifier to the target account preparation queue if the target transaction is in the ready state, thus obtaining the transition account preparation queue.

[0013] The transaction upgrade module is used to select execution order identifiers that can form a continuous sequence of sequence identifiers with the target execution order identifier in the target account waiting queue, and use them as upgrade execution order identifiers. The upgrade execution order identifiers and the waiting transactions corresponding to the upgrade execution order identifiers are then migrated to the transition account preparation queue in order to obtain the upgrade account preparation queue.

[0014] The transaction addition module is used to add the target transaction and the waiting transaction corresponding to the upgrade execution order identifier in the upgrade account preparation queue to the main preparation queue; the transactions in the main preparation queue will be packaged into candidate blocks in the order of transaction insertion time.

[0015] The aforementioned data processing device further includes:

[0016] The first state determination module is used to compare the target execution order identifier with the target account's currently executed transaction identifier if the target account's preparation queue is empty.

[0017] The first state determination module is also used to determine that the target transaction is in the ready state if the target execution order identifier is the same as the currently executed transaction identifier of the target account.

[0018] The first state determination module is also used to determine that the target transaction is in an unprepared state if the target execution order identifier and the target account's currently executed transaction identifier are different, and to add the target transaction and the target execution order identifier to the target account's waiting queue.

[0019] The aforementioned data processing device further includes:

[0020] The second state determination module is used to determine the identification relationship between the target execution order identifier and the largest execution order identifier in the target account preparation queue if the target account preparation queue is not empty.

[0021] The second state determination module is also used to determine that the target transaction is in a ready state if the identification relationship satisfies the sequential continuity relationship.

[0022] The second state determination module is also used to determine that the target transaction is in an unprepared state if the identification relationship does not satisfy the sequential continuity relationship, and to add the target transaction and the target execution order identifier to the target account waiting queue.

[0023] The aforementioned data processing device further includes:

[0024] The traversal module is used to traverse the target account preparation queue and the target account waiting queue according to the target execution order identifier, and obtain the traversal result for the target transaction;

[0025] The conflict determination module is also used to determine the transactions with target execution order identifiers in the pending queue as conflicting transactions if the traversal result indicates that there are transactions with target execution order identifiers in the pending queue; the pending queue is either the target account preparation queue or the target account waiting queue.

[0026] The first overlay module is used to overlay the conflicting transaction based on the target transaction if the conflicting transaction and the conflicting transaction meet the conflict overlay conditions.

[0027] The second overlay module is used to call the transaction transition module to execute the following steps if the target transaction and the conflicting transaction do not meet the conflict overlay conditions: if the target transaction is in a ready state, add the target transaction and the target execution order identifier to the target account preparation queue to obtain the transition account preparation queue.

[0028] The aforementioned data processing device further includes:

[0029] The coverage determination module is used to obtain the transaction execution cost of the target transaction and the transaction execution cost of conflicting transactions.

[0030] The coverage determination module is also used to determine whether the target transaction and the conflicting transaction meet the conflict coverage condition if the transaction execution cost of the target transaction is greater than the transaction execution cost of the conflicting transaction.

[0031] The coverage determination module is also used to determine that the target transaction and the conflicting transaction do not meet the conflict coverage condition if the transaction execution cost of the target transaction is less than or equal to the transaction execution cost of the conflicting transaction, and to send a transaction coverage failure error message to the target user.

[0032] The first coverage module includes:

[0033] The first replacement unit is used to replace the conflicting transaction with the target transaction in the target account preparation queue if the queue to be processed is the target account preparation queue, and to replace the conflicting transaction with the target transaction in the total preparation queue.

[0034] The second replacement unit is used to replace the conflicting transaction with the target transaction in the target account waiting queue if the queue to be processed is the target account waiting queue.

[0035] The aforementioned data processing device further includes:

[0036] The first transaction processing module is used to obtain the upper limit threshold for the number of transactions in an account.

[0037] The first transaction processing module is also used to send a transaction limit error message to the target account if the sum of the number of ready transactions in the target account's preparation queue and the number of waiting transactions in the target account's waiting queue is equal to the account's transaction limit threshold.

[0038] The first transaction processing module is also used to call the transaction transition module to perform the step of adding the target transaction and the target execution order identifier to the target account preparation queue if the sum of the number of prepared transactions and the number of waiting transactions is less than the account transaction limit.

[0039] The aforementioned data processing device further includes:

[0040] The second transaction processing module is used to obtain the number of currently executed transactions for the target account;

[0041] The second transaction processing module is also used to send a transaction expired error message to the target account if the target expected execution order identifier is less than the number of currently executed transactions;

[0042] The second transaction processing module is also used to call the transaction transition module to perform the step of adding the target transaction and the target execution order identifier to the target account preparation queue if the target execution order identifier is greater than or equal to the number of currently executed transactions, thus obtaining the transition account preparation queue.

[0043] The aforementioned data processing device further includes:

[0044] The third transaction processing module is used to obtain the transaction execution cost of the target transaction and query the account resources of the target account;

[0045] The third transaction processing module is also used to send a resource shortage error message to the target account if the account resources are less than the transaction execution cost.

[0046] The third transaction processing module is also used to call the transaction transition module to perform the step of adding the target transaction and the target execution order identifier to the target account preparation queue if the account balance is greater than or equal to the transaction execution cost, thus obtaining the transition account preparation queue.

[0047] The aforementioned data processing device further includes:

[0048] The transaction packaging module is used to package transactions in the total preparation queue into candidate blocks according to the order of transaction insertion time; the number of transactions in a block is less than or equal to the block transaction count threshold;

[0049] The queue update module is used to perform consensus processing on candidate blocks, obtain new blocks, traverse the new blocks, and obtain the maximum execution order identifier of the target account.

[0050] The queue update module is also used to obtain, in the target account preparation queue, a preparation transaction that has a mapping relationship with the first execution order identifier to be deleted, as the preparation transaction to be deleted; the first execution order identifier to be deleted is the execution order identifier in the target account preparation queue that is less than or equal to the maximum execution order identifier;

[0051] The queue update module is also used to delete the pending transaction and the first pending execution order identifier from the target account preparation queue to obtain the updated account preparation queue.

[0052] The queue update module is also used to delete pending transactions from the total preparation queue, thereby updating the total preparation queue.

[0053] The queue update module is also used to obtain, in the target account waiting queue, a waiting transaction that has a mapping relationship with the second execution order identifier to be deleted, as a waiting transaction to be deleted; the second execution order identifier to be deleted is the execution order identifier in the target account waiting queue that is less than or equal to the maximum execution order identifier;

[0054] The queue update module is also used to delete pending transactions and second pending execution order identifiers from the target account waiting queue to obtain the updated account waiting queue.

[0055] The aforementioned data processing device further includes:

[0056] The queue optimization module is used to obtain the minimum execution order identifier in the update account waiting queue;

[0057] The queue optimization module is also used to generate optimized execution order identifiers based on the maximum execution order identifier;

[0058] The queue optimization module is also used to, if the minimum execution order identifier is equal to the optimized execution order identifier, in the target account waiting queue, take the execution order identifier that can form a continuous sequence of order identifiers with the minimum execution order identifier as the optimized upgrade execution order identifier, and migrate the minimum execution order identifier, the waiting transactions corresponding to the minimum execution order identifier, the optimized upgrade execution order identifier, and the waiting transactions corresponding to the optimized upgrade execution order identifier to the update account preparation queue in order to obtain the optimized upgrade account preparation queue;

[0059] The queue optimization module is also used to add the minimum execution order identifier, the waiting transactions corresponding to the minimum execution order identifier, the optimization and upgrade execution order identifier, and the waiting transactions corresponding to the optimization and upgrade execution order identifier to the update total preparation queue in sequence, so as to obtain the optimization and upgrade total preparation queue.

[0060] The aforementioned data processing device further includes:

[0061] The queue deletion module is used to obtain the preparation transaction corresponding to the minimum execution order identifier in the update account preparation queue, and use it as the preparation transaction to be judged.

[0062] The queue deletion module is also used to obtain the transaction execution cost of the transaction to be judged and to query the account resources of the target account;

[0063] The queue deletion module is also used to delete the pending transaction and the minimum execution order identifier from the updated account preparation queue and delete the pending transaction from the updated total preparation queue if the execution cost of the pending transaction exceeds the account resources.

[0064] The queue deletion module is also used to take the execution order identifier that is greater than the minimum execution order identifier as the downgrade execution order identifier in the updated account preparation queue after deletion, and migrate the downgrade execution order identifier and the preparation transaction corresponding to the downgrade execution order identifier to the updated account waiting queue to obtain the downgraded account waiting queue.

[0065] The queue deletion module is also used to remove the downgrade execution order identifier and the corresponding prepared transaction from the deleted update account prepared queue;

[0066] The queue deletion module is also used to remove the downgrade execution order identifier and the corresponding prepared transaction from the deleted update total prepared queue.

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

[0068] The processor is connected to the memory and the network interface. The network interface is used to provide a data communication network element, the memory is used to store a computer program, and the processor is used to call the computer program to execute the method in the embodiments of this application.

[0069] One aspect of this application provides a computer-readable storage medium storing a computer program adapted for loading by a processor and executing the methods described in this application.

[0070] One aspect of this application provides a computer program product or computer program that 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 described in this application.

[0071] In this embodiment, the prepared transactions of the target account in the prepared state and the execution order identifiers mapped to the prepared transactions are stored in the target account prepared queue. The waiting transactions of the target account in the unprepared state and the execution order identifiers mapped to the waiting transactions are stored in the target account waiting queue. Then, when a target transaction containing the target execution order identifier is received from the target account, if the target transaction is in the prepared state, the target transaction and the target execution order identifier are added to the target account prepared queue to obtain the transition account prepared queue. Subsequently, in the target account waiting queue, the execution order identifiers that can form a continuous sequence of order identifiers with the target execution order identifier are used as upgrade execution order identifiers. The upgrade execution order identifiers and the waiting transactions corresponding to the upgrade execution order identifiers are added to the transition account prepared queue in sequence to obtain the upgrade account prepared queue. At the same time, the target transactions and the waiting transactions corresponding to the upgrade execution order identifiers in the upgrade account prepared queue are all added to the total prepared queue. The transactions in the total prepared queue are packaged into candidate blocks according to the transaction insertion time order. The method provided in this application stores all ready transactions of the target account in the target account's ready queue, and only ready transactions of the target account can be added to the total ready queue. This ensures that no unprepared waiting transactions will appear in the candidate blocks generated based on the transactions in the total ready queue, thus improving the success rate of block uploading. Furthermore, unprepared transactions sent by the target account will not be rejected but will be temporarily stored in the target account's waiting queue. Whenever a new ready transaction is added to the target account's ready queue, the waiting queue is upgraded, and eligible waiting transactions are added to the target account's ready queue, and then further added to the total ready queue to await packaging, thereby enhancing the fault tolerance of the blockchain system. Attached Figure Description

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

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

[0074] Figure 2 This is a schematic diagram illustrating a data processing scenario based on blockchain, provided in an embodiment of this application.

[0075] Figure 3This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application;

[0076] Figure 4 This is a schematic diagram of queue construction for transaction pool management provided in an embodiment of this application;

[0077] Figure 5 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application;

[0078] Figure 6 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application;

[0079] Figure 7 This is a flowchart illustrating a transaction receiving method provided in an embodiment of this application;

[0080] Figure 8 This is a schematic diagram of a process for refreshing a transaction pool provided in an embodiment of this application;

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

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

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

[0084] Blockchain is the carrier and organizational method for running blockchain technology. Blockchain technology (BT), also known as distributed ledger technology, is an internet database technology characterized by decentralization and transparency, allowing everyone to participate in database recording. Blockchain technology utilizes a block-chain data structure to verify and store data, distributed node consensus algorithms to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script code to program and manipulate data—a distributed infrastructure and computing method.

[0085] To facilitate understanding, the following will explain blockchain and related concepts:

[0086] Blockchain: Blockchain is a new 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 the same blockchain. The blockchain network can distinguish between consensus nodes and business nodes, with the consensus node responsible for achieving consensus across the entire network. The process of writing transaction data into the ledger in a blockchain network can be described as follows: the client sends transaction data to a business node, which then relays this data among the business nodes in the blockchain network until the consensus node receives it. The consensus node then packages the transaction data into a block and reaches a consensus with other consensus nodes. After consensus is reached, the block containing the transaction data is written into the ledger.

[0087] 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 transactions in the block are verified and confirmed by the network's consensus mechanism.

[0088] Hash value: Also known as information feature value or characteristic value, a hash value is generated by converting input data of arbitrary length into cryptographic data and producing a fixed output through a hash algorithm. The original input data cannot be retrieved by decrypting the hash value; it is a one-way cryptographic function. In a blockchain, each block (except the initial block) contains the hash value of its predecessor block, which is called the parent block of the current block. The hash value is a core and crucial aspect of blockchain technology, preserving the authenticity of recorded and viewed data, as well as the integrity of the blockchain as a whole.

[0089] A blockchain account is uniquely identified by its account address. It contains a balance representing the account's digital resources in the current world state. Each blockchain account has a corresponding `accountNonce`, which records the number of transactions executed by that account in the current world state. The initial value of `accountNonce` is 0, and it increments by 1 after each transaction executed under that account. It should be noted that the accounts mentioned in subsequent embodiments of this application refer to blockchain accounts, and will not be elaborated upon further.

[0090] A transaction is a transaction sent by a blockchain account. It contains a transaction hash as a unique identifier, an account address identifying the blockchain account that sent the transaction, and a txNonce indicating the desired execution order of the transaction in the current world state. For example, the blockchain account might want the first executed transaction to have a txNonce of 0, the second executed transaction to have a txNonce of 1, and so on. Therefore, the txNonce of a transaction must be equal to the accountNonce of the blockchain account before the transaction was executed in the current world state; otherwise, the transaction is invalid. If at least one transaction in a block is invalid, the block will fail to reach consensus and cannot be added to the blockchain. The transaction also includes a txFee (transaction fee) field, representing the cost that the blockchain account must pay to the blockchain system to execute the transaction. For different blockchain types, the txFee field may be calculated from certain fields according to predetermined rules, such as value (transfer amount) + gas (consumption) * gasPrice (consumption unit price).

[0091] On-chain: Each block contains several transactions. The process of inserting a block into the blockchain data structure of each blockchain node after consensus is called on-chain.

[0092] World state: A view comprised of the persistent data held by all accounts within the blockchain. Since transaction execution modifies some of the persistent data of several accounts, each transaction within a block generates a new world state after execution. Furthermore, each block's inclusion on the blockchain updates the world state of every blockchain node. Once the same block is included, the world state of every blockchain node must be consistent.

[0093] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a blockchain node system provided in an embodiment of this application. For example... Figure 1The 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 blockchain nodes, specifically blockchain node 10a, blockchain node 10b, blockchain node 10c, blockchain node 10d, ..., blockchain node 10n. Each blockchain node, during normal operation, can receive data sent from the outside world and perform block-up processing based on the received data, and can also send data to the outside world. To ensure data interoperability between blockchain nodes, data connections can exist between each blockchain node. For example, there is a data connection between blockchain node 10a and blockchain node 10b, a data connection between blockchain node 10a and blockchain node 10c, and a data connection between blockchain node 10b and blockchain node 10c.

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

[0095] Table 1

[0096] 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

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

[0098] In blockchain, before a block is added to the chain, it must pass consensus among the consensus nodes in the blockchain network. Only after consensus is reached can the block be added to the blockchain. Understandably, when blockchain is used in scenarios involving 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 the necessity to become consensus nodes. For example, in... Figure 1 In the blockchain node system shown, blockchain 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 blocks and voting on them. Non-consensus nodes do not participate in consensus but help propagate block and voting messages, and synchronize states with each other.

[0099] It is understood that the above-mentioned 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.

[0100] It is understood that the data processing method provided in this application embodiment can be executed by a computer device, which includes, but is not limited to, the aforementioned blockchain node (which can be a server or a terminal). The aforementioned server 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 aforementioned terminal can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited to these.

[0101] It is understood that the embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0102] It is understood that, in the specific embodiments of this application, the transaction data and other related data involved need to obtain user permission or consent when the above embodiments of this application are applied to specific products or technologies, and the collection, use and processing of related data need to comply with the relevant laws, regulations and standards of relevant countries and regions.

[0103] A blockchain node can contain the following modules:

[0104] Transaction pool: Stores transactions known in the blockchain network but not yet included in the blockchain. Blockchain nodes cache received transactions through the transaction pool and submit transactions whose txNonce equals the accountNonce of the blockchain account in the current world state, along with subsequent consecutive txNonces, to the consensus module for packaging and block generation. When a new block is reached and inserted into the blockchain structure, a transaction pool refresh operation is triggered, deleting transactions already included in the blockchain.

[0105] Consensus module: Packages transactions to generate candidate blocks, and reaches a consensus among various blockchain nodes based on the consensus algorithm to generate new blocks.

[0106] Blockchain structure: A chain-like structure consisting of all blocks linked together, storing all transactions in the blockchain system.

[0107] World State: The set of data for all accounts after the transactions in the latest block of the current blockchain structure have been executed.

[0108] Configuration module: Configurations related to the total limit of the storage transaction pool, the limit of a single account, and the limit of the number of block transactions.

[0109] like Figure 1 As shown, transactions sent by a blockchain account are broadcast to all blockchain nodes. However, due to network latency and long transmission distances, blockchain nodes do not necessarily receive transactions belonging to the same blockchain account in ascending order of execution order identifiers (i.e., txNonce). In this case, among the transactions cached in the transaction pool, there may be issues such as the smallest execution order identifier corresponding to a transaction sent by a blockchain account not being equal to the number of currently executed transactions (i.e., accountNonce) of that blockchain account in the current world state, or the execution order identifiers corresponding to a transaction sent by a blockchain account being discontinuous. In this case, blockchain nodes in the blockchain node system can perform fine-grained management of the transactions cached in the transaction pool.

[0110] Specifically, blockchain nodes can manage transactions in the transaction pool according to account dimensions. Further, transactions sent by the same account are divided into an account preparation queue and an account waiting queue. Taking a target account as an example, it corresponds to a target account preparation queue and a target account waiting queue. The target account preparation queue stores transactions sent by the target account that are in a prepared state, along with execution order identifiers mapped to these transactions. The target account waiting queue stores transactions sent by the target account that are not in a prepared state, along with execution order identifiers mapped to these transactions. The execution order identifiers corresponding to transactions in a prepared state must satisfy a sequential continuity relationship, and the smallest execution order identifier in the target account preparation queue must be the same as the number of currently executed transactions for that target account in the current world state. Transactions in the target account preparation queue are added to the total preparation queue simultaneously with their addition to the target account preparation queue. Furthermore, transactions in a prepared state sent by other accounts in the blockchain network are also added to the total preparation queue when added to their respective account preparation queues. Transactions in the total preparation queue are then packaged into candidate blocks according to their insertion time. At this point, all transactions packaged into the candidate block can be executed in the order indicated by their execution order identifier, increasing the probability of consensus passing for the candidate block.

[0111] Therefore, when a blockchain node receives a new target transaction from a target account, it can first determine whether the target transaction is in a ready state. If the target transaction is in a ready state, the target transaction and its corresponding target execution order identifier are added to the target account's preparation queue, resulting in a transition account preparation queue. Then, the blockchain node can perform transaction upgrade processing on the target account's waiting queue. That is, in the target account's waiting queue, the execution order identifier that can form a continuous sequence with the target execution order identifier is used as the upgrade execution order identifier. The upgrade execution order identifier and the waiting transactions corresponding to the upgrade execution order identifier are migrated to the transition account preparation queue in sequence, resulting in an upgrade account preparation queue. Finally, the blockchain node can add the target transaction and the waiting transactions corresponding to the upgrade execution order identifier in the upgrade account preparation queue to the main preparation queue to await packaging.

[0112] To better understand the process by which blockchain nodes process target transactions sent to the target account, please also refer to... Figure 2 , Figure 2 This is a schematic diagram illustrating a blockchain-based data processing scenario provided in an embodiment of this application. Wherein, as... Figure 2 The blockchain node 20 shown can be the above Figure 1 Any blockchain node in the blockchain node system of the corresponding embodiment, such as blockchain node 20, can be blockchain node 10a.

[0113] like Figure 2 As shown, blockchain node 20 contains blockchain 21, which contains multiple blocks, such as block 211, block 212, etc. Each block can contain multiple transactions sent by different accounts. For example, block 211 contains transaction A2, transaction B1, etc.; block 212 contains transaction A1, etc. Transaction A2 and transaction A1 are transactions sent by account A, and transaction B1 is a transaction sent by account B. Blockchain node 20 also contains execution data 22 in the current world state. The current world state refers to the world state of the blockchain network after block 211 is added to blockchain 21. The world state of the blockchain network refers to the view composed of the persistent data owned by each account in the blockchain network. Since the execution of transactions can change the account resources corresponding to an account, the world state changes whenever a new block is added to blockchain 21. That is, the world state of the blockchain network is different when different blocks are added to blockchain 21. Execution data 22 contains the number of currently executed transactions for each account in the blockchain network. All transactions in the blocks that have been uploaded to the chain have been executed. Therefore, transactions A2, A1, and B1 have all been executed. Assuming that no other blocks in blockchain 21 contain transactions sent by accounts A and B, execution data 22 will record that the number of currently executed transactions for account A is 2 and the number of currently executed transactions for account B is 1.

[0114] like Figure 2As shown, blockchain node 20 also includes a transaction pool 23. Transaction pool 23 is used to cache transactions received by blockchain node 20 that have not yet been uploaded to blockchain 21. Suppose that blockchain node 20 receives transaction A5 from account A, which contains an execution order identifier 4. Execution order identifier 4 indicates that account A expects transaction A5 to be the fifth transaction executed in the blockchain network. If the execution order of transaction A5 in the blockchain network does not meet the execution order indicated by execution order identifier 4, transaction A5 will be considered an invalid transaction, and the upload of the block containing transaction A5 will fail. After receiving transaction A5, blockchain node 20 will temporarily store it in transaction pool 23. To ensure that transaction A5 can be the fifth transaction sent by account A to be executed in the blockchain, blockchain node 20 will obtain the account preparation queue 231 and the account waiting queue 232 corresponding to account A. The account preparation queue 231 stores transactions in a prepared state. Assume that account preparation queue 231 contains transaction A3 and its corresponding execution order identifier 2, and transaction A4 and its corresponding execution order identifier 3. It can be understood that the execution order of transactions in a prepared state on the blockchain will be the same as the execution order indicated by their corresponding execution order identifiers. This is because transactions A3 and A4 in account preparation queue 231 will be added to the main preparation queue 230 based on their execution order identifiers from smallest to largest. The main preparation queue 230 stores transactions in the account preparation queues corresponding to all accounts in the blockchain network. Blockchain node 20 will package transactions into blocks from the main preparation queue 230 according to their insertion time order. Therefore, during block execution, transactions will also be executed according to their insertion time order. In other words, during the process of packaging and uploading blocks to the blockchain after blockchain node 20, transaction A3 will be executed first, followed by transaction A4. Since blockchain node 20 has already executed transactions A1 and A2 sent by account A, transaction A3 will be the third transaction executed for account A in the blockchain network. The execution order of transaction A3 is the same as the execution order indicated by execution order identifier 2, so transaction A3 is a ready-to-go transaction. Similarly, transaction A4 will be the fourth transaction executed for account A in the blockchain network. The execution order of transaction A4 is the same as the execution order indicated by execution order identifier 3, and transaction A4 is also a ready-to-go transaction.The account waiting queue 232 is used to store pending transactions that are in an unprepared state. Assuming that the account preparation queue 231 contains transaction A6 and the execution order identifier 5 corresponding to transaction A6, it can be seen that account A wants transaction A6 to be the sixth transaction to be executed in the blockchain network. However, if transaction A3, transaction A4 and transaction A6 are packaged into a block at this time, transaction A6 will be the fifth transaction to be executed in the blockchain network for account A. The execution order of transaction A6 is different from the execution order indicated by the executable incident identifier 5 corresponding to transaction A6. Therefore, transaction A6 is a pending transaction in an unprepared state.

[0115] like Figure 2 As shown, blockchain node 20 determines whether transaction A5 is in a ready state. Blockchain node 20 queries account preparation queue 231 and determines that the largest execution order identifier contained therein is execution order identifier 3. Execution order identifier 3 and execution order identifier 4 corresponding to transaction A5 satisfy a sequential relationship. If transaction A5 is executed after transaction A4, transaction A5 will be the fifth transaction of account A to be executed in the blockchain network. Therefore, blockchain node 20 can determine that the execution order of transaction A5 is the same as the execution order indicated by its corresponding execution order identifier 4, and thus transaction A5 is in a ready state. Therefore, blockchain node 20 will... Transaction A5 and its corresponding execution order identifier 4 are added together to account A's account preparation queue 231, resulting in a transitional account preparation queue (not shown in the diagram). After adding transaction A5 and its corresponding execution order identifier 4 to account A's account preparation queue 231, blockchain node 20 can upgrade the transactions in account waiting queue 232. Specifically, it checks whether there are any transactions that can be executed according to their corresponding execution order identifiers if transaction A5 is to be executed as the fifth transaction for account A in the blockchain network. If so, the transaction is moved from account waiting queue 232 to account preparation queue 231. Figure 2 As shown, the execution order identifier 6 corresponding to transaction A6 and the execution order identifier 5 corresponding to transaction A5 can form a continuous sequence of sequence identifiers. Therefore, blockchain node 20 will migrate transaction A6 and its corresponding execution order identifier 5 to the transition account preparation queue, resulting in upgrade account preparation queue 233 and upgrade account waiting queue 235. Finally, blockchain node 20 will add transaction A5 and transaction A6 to the total account preparation queue 230.

[0116] The data processing method provided in this application embodiment allows for refined management of transactions temporarily stored in the transaction pool by blockchain nodes according to the account dimension. This ensures that the execution order of transactions packaged into blocks is the same as the execution order indicated by the execution order identifier contained therein, thereby increasing the probability of block consensus and thus improving the success rate of block on-chain.

[0117] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The method can be implemented using blockchain nodes (e.g., the aforementioned...). Figure 1 The method is executed by any blockchain node in the blockchain node system of the corresponding embodiment. The following description will use the execution of this method by a blockchain node as an example, wherein the blockchain-based data processing method may include at least the following steps S101-S104:

[0118] Step S101: Obtain the target transaction sent by the target account, and obtain the target account preparation queue and target account waiting queue corresponding to the target account; the target transaction contains a target execution order identifier; the target account preparation queue is used to store the prepared transactions in the prepared state and the execution order identifiers that have a mapping relationship with the prepared transactions; the target account waiting queue is used to store the waiting transactions in the unprepared state and the execution order identifiers that have a mapping relationship with the waiting transactions.

[0119] Specifically, the execution order identifier refers to the txNonce corresponding to the transaction, which is used to identify the order in which the account sending the transaction wants the transaction to be executed among the transactions sent by the account. It starts from 0 and increments. For example, if the execution order identifier corresponding to transaction C3 sent by account C is 2, then account C wants transaction C3 to be the third transaction to be executed in the blockchain network. After transaction C3 is executed, the current number of executed transactions of account C will be 3. Therefore, it can be understood that the next transaction to be executed by account C should be transaction C4 with the execution order identifier of 3.

[0120] Specifically, transactions received by blockchain nodes but not yet included in blocks are stored in a transaction pool. Blockchain nodes can cache transactions by account. For example, transactions of a target account can be further divided into ready transactions (in a prepared state) and pending transactions (in a non-prepared state). Ready transactions and their corresponding execution order identifiers are then added to the target account's ready queue, and pending transactions and their corresponding execution order identifiers are added to the target account's pending queue. A ready transaction means that if all transactions of the target account in the transaction pool are executed in ascending order of their execution order identifiers, their execution order among all transactions sent from the target account to the blockchain network (including transactions in the transaction pool and transactions already on the chain) will be the same as the execution order indicated by their corresponding execution order identifier. A pending transaction means that if all transactions of the target account in the transaction pool are executed in ascending order of their execution order identifiers, their execution order among all transactions sent from the target account to the blockchain network (including transactions in the transaction pool and transactions already on the chain) will be different from the execution order indicated by their corresponding execution order identifier. Of course, transactions in a blockchain node need to be packaged into a candidate block, and only after the candidate block passes consensus can the transactions in the candidate block be executed.

[0121] Specifically, when packaging transactions, blockchain nodes retrieve transactions from the main preparation queue in the order of their insertion time and then package them to generate candidate blocks. The main preparation queue contains all transactions in the account preparation queues corresponding to all accounts in the blockchain network. However, transactions within the same account are added to the main preparation queue based on their execution order identifiers in their respective account preparation queues. Therefore, a blockchain node only needs to ensure that the transactions in the target account's preparation queue are arranged in ascending order of their execution order identifiers, and that the smallest execution order identifier in the target account's preparation queue equals the number of currently executed transactions for the target account in the current world state (i.e., the target account's `accountNonce`). This guarantees that when a transaction is packaged into a candidate block and executed, its execution order among all transactions sent from the target account to the blockchain network will be the order indicated by its execution order identifier. For example, if accountNonce of account D is 3, it means that account D has already had 3 transactions executed by the blockchain nodes. At this time, the account preparation queue corresponding to account D contains transaction D4 and its corresponding execution order identifier 3, transaction D5 and its corresponding execution order identifier 4. The blockchain nodes will add transaction D4 and transaction D5 to the total preparation queue in ascending order of execution order identifiers. Then, according to the order of transaction insertion time, the blockchain nodes will first package transaction D4 into the candidate block, and then package transaction D5 into the candidate block. Subsequently, the blockchain nodes will execute transaction D4 and transaction D5 in sequence. At this time, transaction D4 will be the fourth transaction of account D to be executed, and transaction D5 will be the fifth transaction of account D to be executed. The execution order of transaction D4 and transaction D5 both conforms to the execution order indicated by their corresponding execution order identifiers.

[0122] Step S102: If the target transaction is in the prepared state, the target transaction and the target execution order identifier are added to the target account preparation queue to obtain the transition account preparation queue.

[0123] Specifically, upon receiving a target transaction, the blockchain node can determine whether the target transaction is in a ready state based on the relationship between the number of currently executed transactions in the target account, the execution order identifier of the target transaction, and the execution order identifier in the target account's preparation queue. If the target transaction is in a ready state, the target transaction and its corresponding execution order identifier are directly added to the target account's preparation queue, thus creating a transitional account preparation queue. If the target transaction is not in a ready state, the target transaction and its execution order identifier are added to the target account's waiting queue.

[0124] Optionally, when the target account's preparation queue does not contain any prepared transactions (i.e., the target account's preparation queue is empty), a feasible process for determining whether the target transaction is in a prepared state can be as follows: compare the target execution order identifier with the current number of executed transactions of the target account; if the target execution order identifier and the current number of executed transactions of the target account are the same, then the target transaction is determined to be in a prepared state; if the target execution order identifier and the current number of executed transactions of the target account are different, then the target transaction is determined to be in an unprepared state, and the target transaction and the target execution order identifier are added to the target account's waiting queue. For example, when account E's accountNonce is 3 and the account preparation queue corresponding to account E is empty, the blockchain node receives transaction D5 sent by account E containing execution order identifier 4, indicating that account E wants transaction D5 to be its fifth transaction to be executed. If transaction D5 is added to the account preparation queue at this time, transaction D5 will become account E's fourth transaction to be executed, which is inconsistent with the execution order desired by account E. Therefore, transaction D5 is a waiting transaction in an unprepared state and should be added to the account waiting queue to await upgrade.

[0125] Optionally, when the target account preparation queue contains prepared transactions, i.e., the target account preparation queue is a non-empty queue, a feasible process for determining whether the target transaction is in a prepared state can be as follows: If the target account preparation queue is a non-empty queue, determine the identification relationship between the target execution order identifier and the largest execution order identifier in the target account preparation queue; if the identification relationship satisfies the sequential continuity relationship, determine that the target transaction is in a prepared state; if the identification relationship does not satisfy the sequential continuity relationship, determine that the target transaction is in an unprepared state, and add the target transaction and the target execution order identifier to the target account waiting queue. It is understandable that all the transactions in the target account's preparation queue are in a ready state, meaning that all the transactions can be executed in the order indicated by their execution order identifiers. If the largest execution order identifier in the target account's preparation queue is execution order identifier 5, then the transaction corresponding to execution order identifier 5 will be the sixth transaction to be executed in the target account. The target transaction is then added to the target account's preparation queue and will become the seventh transaction to be executed in the target account. Therefore, the execution order identifier of the target transaction should be execution order identifier 6. In other words, the execution order identifier of the target transaction should be sequentially related to execution order identifier 5 so that the target transaction can be executed in the order indicated by its execution order identifier.

[0126] Step S103: In the target account waiting queue, the execution order identifier that can form a continuous sequence of sequence identifiers with the target execution order identifier is used as the upgrade execution order identifier. The upgrade execution order identifier and the waiting transactions corresponding to the upgrade execution order identifier are migrated to the transition account preparation queue in sequence to obtain the upgrade account preparation queue.

[0127] Specifically, after a target transaction is added to the account preparation queue to form a transition account preparation queue, the largest execution order identifier in the transition account preparation queue becomes the target execution order identifier corresponding to the target transaction. At this point, the blockchain node can query the target account waiting queue and select the execution order identifier that can form a continuous sequence of sequence identifiers with the target execution order identifier as the upgrade execution order identifier. The upgrade execution order identifier and the waiting transactions corresponding to the upgrade execution order identifier are then migrated to the transition account preparation queue in sequence to obtain the upgrade account preparation queue. It can be understood that the execution order identifiers in the upgrade account preparation queue at this point can form a continuous sequence of sequence identifiers starting with the number of currently executed transactions of the target account.

[0128] Step S104: Add the target transaction and the waiting transaction corresponding to the upgrade execution order identifier in the upgrade account preparation queue to the total preparation queue; the transactions in the total preparation queue will be packaged into candidate blocks in the order of transaction insertion time.

[0129] Specifically, a blockchain network contains at least two accounts, each with its own account preparation queue and account waiting queue. Blockchain nodes add new transactions to the overall preparation queue simultaneously with the transaction being added to the account preparation queue of a given account. When packaging candidate blocks, blockchain nodes retrieve transactions from the overall preparation queue according to their insertion time order. The transaction insertion time order refers to the order in which transactions were added to the overall preparation queue.

[0130] Optionally, a blockchain node may also include a total transaction queue. This queue records all transactions in the transaction pool, meaning it can contain prepared and pending transactions for all accounts in the blockchain network, facilitating overall query and management of the transaction pool by the blockchain node. Furthermore, a blockchain node may also include hash maps for account preparation queues and account waiting queues. The account preparation queue hash map is used by the blockchain node to find the account preparation queue corresponding to an account; the account waiting queue hash map is used by the blockchain node to find the account waiting queue corresponding to an account.

[0131] For ease of understanding, please refer to the following: Figure 4 , Figure 4 This is a schematic diagram illustrating the construction of a queue for transaction pool management, provided in an embodiment of this application. Figure 4 As shown, based on the transactions in the transaction pool, blockchain nodes can construct a general queue containing all transactions in the entire transaction pool, and a general preparation queue for storing all transactions in the ready state for all accounts. They can also construct an account preparation queue and an account waiting queue for each account, and establish hash mappings from account addresses to account preparation queues and from account addresses to account waiting queues. Here, the account address is a unique address for the account.

[0132] like Figure 4 As shown, the total transaction queue can contain transactions and transaction hashes that are mapped to those transactions. Therefore, the total transaction queue can use a HashMap (hash table) hash mapping structure that maps transaction hashes to transactions. Here, the transaction hash is a unique identifier for the transaction. The HashMap is a key-value mapping structure, and its traversal order is random. The total preparation queue can also contain transactions and transaction hashes that are mapped to those transactions, and allows blockchain nodes to store and traverse transactions according to their insertion time. Therefore, the total preparation queue can use a LinkedHashMap (linked hash table) structure that maps transaction hashes to transactions, and stores transactions according to their insertion time. The LinkedHashMap is a key-value mapping structure that maintains the insertion time order for sorted storage and traversal. The account preparation queue needs to contain prepared transactions and txNonces that map to these transactions. The account waiting queue needs to contain waiting transactions and txNonces that map to them. Blockchain nodes are allowed to store and iterate transactions in txNonce order. Therefore, both the account preparation queue and the account waiting queue can use a TreeMap structure that maps txNonces to transactions, sorting and storing transactions in ascending order of the txNonce field. Here, TreeMap is a key-value mapping structure that sorts and iterates transactions according to their keys. The hash mapping for the account preparation queue can use a HashMap structure that maps account addresses to the account preparation queue, and the hash mapping for the account waiting queue can use a HashMap structure that maps account addresses to the account waiting queue. According to... Figure 4The list shown allows blockchain nodes to quickly locate a specific transaction in the account preparation queue or account waiting queue, provided they know the txNonce of the target transaction and the account address of the account sending the target transaction. It should be noted that the same transaction may logically appear simultaneously in the total transaction queue, the total preparation queue, or the account preparation list or account waiting queue. However, physically, this refers to the memory pointer of the transaction, while the transaction data is only stored once in memory to save memory. Therefore, whenever this embodiment describes a transaction in a queue, it can refer to the memory pointer of the transaction being in the queue; this will not be elaborated further below.

[0133] The method provided in this application stores all ready transactions of the target account in the target account's ready queue. Only ready transactions of the target account can be added to the total ready queue. This ensures that no unprepared waiting transactions will appear in the candidate blocks generated based on the transactions in the total ready queue, thus improving the success rate of block uploading. Furthermore, unprepared transactions sent by the target account are not rejected but are temporarily stored in the target account's waiting queue. Whenever a new ready transaction is added to the target account's ready queue, the queue is upgraded, and eligible waiting transactions are added to the target account's ready queue, and then further added to the total ready queue to await packaging. This enhances the fault tolerance of the blockchain system.

[0134] Further, please see Figure 5 , Figure 5 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The method can be implemented using blockchain nodes (e.g., the aforementioned...). Figure 1 This method is executed by any blockchain node in the blockchain node system of the corresponding embodiment. The following description will use the execution of this method by a blockchain node as an example, wherein the blockchain-based data processing method may include at least the following steps 201-S207:

[0135] Step S201: Obtain the target transaction sent by the target account and determine the cache verification result of the target transaction; the target transaction contains a target execution order identifier.

[0136] Specifically, after receiving a target transaction from a target account, the blockchain node can first determine the cache verification result of the target transaction. If the blockchain node determines that the cache verification result of the target transaction is a valid cache result, it can cache the target transaction into the transaction pool. If the blockchain node determines that the cache verification result of the target transaction is an invalid cache result, the blockchain node can directly return an error message to the target account.

[0137] Specifically, a feasible implementation method for determining the cache verification result of a target transaction can be: obtaining the total number of transactions in the total transaction queue; obtaining the upper limit threshold for the total number of transactions; if the total number of transactions equals the upper limit threshold, returning a transaction limit error message to the target account; if the total number of transactions is less than the upper limit threshold, determining the cache verification result of the target transaction as a valid cache result. Here, the total number of transactions refers to the number of transactions contained in the total transaction queue, which is also the number of transactions cached in the transaction pool at this time. It should be understood that the transaction pool has a limited capacity. When the cached transactions in the transaction pool reach their limit, the blockchain node cannot add the target transaction to the transaction pool, and at this time, the blockchain node can only send a transaction limit error message to the target account. Furthermore, the upper limit of the transaction pool capacity can be configured through the configuration module of the blockchain node.

[0138] Specifically, a feasible implementation method for determining the cache verification result of a target transaction can be: obtaining the account transaction quantity limit threshold; if the sum of the number of ready transactions in the target account's preparation queue and the number of waiting transactions in the target account's waiting queue equals the account transaction quantity limit threshold, then a transaction limit error message is sent to the target account; if the sum of the number of ready transactions and the number of waiting transactions is less than the account transaction quantity limit, then the cache verification result of the target transaction is determined to be a valid cache result. Here, the account transaction quantity limit threshold refers to the maximum number of transactions that a target account can cache in the transaction pool, which can be configured through the blockchain node's configuration module. It should be understood that the transactions cached by the target account in the transaction pool include ready transactions and waiting transactions. When the target account reaches the transaction limit in the transaction pool, even if the transaction pool of the blockchain node has not yet reached its limit, the blockchain node will still not cache the target transaction sent by the target account, but will instead return a transaction limit error message to the target account.

[0139] Specifically, a feasible implementation method for determining the cache verification result of a target transaction can be: obtaining the number of currently executed transactions of the target account; if the target expected execution order identifier is less than the number of currently executed transactions, sending a transaction expired error message to the target account; if the target execution order identifier is greater than or equal to the number of currently executed transactions, determining the cache verification result of the target transaction as a valid cache result. It can be understood that when the number of currently executed transactions of the target account is greater than the target expected execution order identifier of the target transaction, the target transaction cannot be executed according to the execution order indicated by the target expected execution order identifier, and the blockchain node no longer needs to store and execute the target transaction.

[0140] Specifically, a feasible implementation method for determining the cache verification result of a target transaction can be as follows: obtain the transaction execution cost of the target transaction and query the account resources of the target account; if the account resources are less than the transaction execution cost, send a resource shortage error message to the target account; if the account balance is greater than or equal to the transaction execution cost, then determine that the cache verification result of the target transaction is a valid cache result. Here, the transaction execution cost refers to the digital resources that the target account is willing to provide for executing the transaction, and the account resources refer to the digital resources that the target account possesses in the blockchain network.

[0141] It should be noted that a blockchain node can simultaneously apply the aforementioned feasible implementation methods to a target transaction to determine the cache verification result of the target transaction. In this case, the target transaction needs to satisfy the verification of multiple feasible implementation methods at the same time before the blockchain node can determine that the cache verification result of the target transaction is a valid cache result.

[0142] Step S202: If the cache verification result of the target transaction is a valid cache result, then obtain the target account preparation queue and the target account waiting queue corresponding to the target account; the target account preparation queue is used to store the prepared transactions in the prepared state and the execution order identifier that has a mapping relationship with the prepared transactions; the target account waiting queue is used to store the waiting transactions in the unprepared state and the execution order identifier that has a mapping relationship with the waiting transactions.

[0143] Specifically, the implementation of step S202 can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0144] Step S203: Traverse the target account preparation queue and the target account waiting queue according to the target execution order identifier to obtain the traversal result for the target transaction.

[0145] Specifically, after a target account sends a transaction carrying an execution order identifier, there is a time lag between the transaction being packaged into a candidate block and the target account wanting other transactions to execute in the order indicated by the execution order identifier. During this time, the target account can send a transaction containing the same execution order identifier to the blockchain node. The blockchain node may then receive multiple transactions with the same execution order identifier. However, the blockchain node will only select the optimal transaction or the transaction most desired by the target account from among the multiple transactions with the same execution order identifier for execution; the remaining transactions will be discarded. Therefore, after receiving the target transaction, the blockchain node needs to determine whether the target account's preparation queue already contains a preparation transaction with the target execution order identifier, or whether the target account's waiting queue already contains a waiting transaction with the target execution order identifier.

[0146] Step S204: When the traversal result indicates that there is a transaction with the target execution order identifier in the queue to be processed, the transaction with the target execution order identifier in the queue to be processed is identified as a conflicting transaction. If the target transaction and the conflicting transaction meet the conflict coverage condition, the conflicting transaction is covered based on the target transaction. The queue to be processed is the target account preparation queue or the target account waiting queue.

[0147] Specifically, conflicting transactions and target transactions have the same target execution order identifier. Blockchain nodes need to determine whether the target transaction and conflicting transactions meet the conflict coverage condition. If the target transaction and conflicting transaction meet the conflict coverage condition, the conflicting transaction is overridden based on the target transaction. If the target transaction and conflicting transaction do not meet the conflict coverage condition, the blockchain node will discard the target transaction.

[0148] Specifically, a feasible implementation method for blockchain nodes to determine whether a target transaction and a conflicting transaction meet the conflict coverage condition can be as follows: Obtain the transaction execution cost of the target transaction and the transaction execution cost of the conflicting transaction; if the transaction execution cost of the target transaction is greater than that of the conflicting transaction, then the conflict coverage condition is met; if the transaction execution cost of the target transaction is less than or equal to that of the conflicting transaction, then the conflict coverage condition is not met, and a transaction coverage failure error message is sent to the target user. Here, the transaction execution cost refers to the digital resources that the target account is willing to provide for the blockchain network to execute the transaction. Therefore, a transaction with a higher execution cost is naturally a transaction that the target account is more willing to execute. In this case, the blockchain node will use the target transaction to cover the conflicting transaction.

[0149] Specifically, a feasible implementation method for overriding conflicting transactions based on the target transaction is as follows: if the queue to be processed is the target account preparation queue, then the conflicting transaction is replaced with the target transaction in the target account preparation queue, and the conflicting transaction is replaced with the target transaction in the overall preparation queue; if the queue to be processed is the target account waiting queue, then the conflicting transaction is replaced with the target transaction in the target account waiting queue. Furthermore, blockchain nodes can delete the conflicting transaction from the transaction pool.

[0150] Step S205: When the traversal result indicates that there is no transaction with the target execution order identifier in the queue to be processed, if the target transaction is in the prepared state, the target transaction and the target execution order identifier are added to the target account preparation queue to obtain the transition account preparation queue.

[0151] Step S206: In the target account waiting queue, the execution order identifier that can form a continuous sequence of order identifiers with the target execution order identifier is used as the upgrade execution order identifier. The upgrade execution order identifier and the waiting transactions corresponding to the upgrade execution order identifier are migrated to the transition account preparation queue in sequence to obtain the upgrade account preparation queue.

[0152] Step S207: Add the target transaction and the waiting transaction corresponding to the upgrade execution order identifier in the upgrade account preparation queue to the total preparation queue; the transactions in the total preparation queue will be packaged into candidate blocks in the order of transaction insertion time.

[0153] Specifically, the implementation process of steps S205-S207 can be found above. Figure 3 Steps S102-S104 in the corresponding embodiments will not be described again here.

[0154] Using the method provided in this application, after a target account sends a transaction with a target execution order identifier, it can send a target transaction with the same target execution order identifier with higher transaction execution overhead to overwrite the previously sent transactions, thereby improving the flexibility of blockchain use. Furthermore, replacing the previously sent transactions with the target transaction in a queue containing previously sent transactions will not disrupt the execution order of other transactions, thus improving the effectiveness of transaction packaging.

[0155] Further, please see Figure 6 , Figure 6 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The method can be implemented using blockchain nodes (e.g., the aforementioned...). Figure 1 This method is executed by any blockchain node in the blockchain node system of the corresponding embodiment. The following description uses the execution of this method by a blockchain node as an example, wherein the blockchain-based data processing method may include at least the following steps 301-S306:

[0156] Step S301: Obtain candidate blocks.

[0157] Specifically, candidate blocks can be generated by blockchain nodes or generated by other blockchain nodes and then broadcast to other blockchain nodes. When a blockchain node has block-producing permission, it can retrieve transactions from the total preparation queue in order of transaction insertion time, and then package them sequentially to generate candidate blocks. The number of transactions in a block must be less than or equal to the block transaction count threshold, which is the maximum number of transactions that a block can contain, and can be configured through the configuration module.

[0158] Step S302: Perform consensus processing on the candidate blocks to obtain new blocks, traverse the new blocks, and obtain the maximum execution order identifier of the target account.

[0159] Specifically, blockchain nodes can reach a consensus on a candidate block together with other consensus nodes. Once consensus is reached, the candidate block is executed, meaning all transactions within the candidate block are executed, resulting in a new block containing all transactions and their corresponding execution results. This new block is then inserted into the existing blockchain structure, creating a new blockchain. The account resources corresponding to accounts in the new blockchain will also change, resulting in a new world state.

[0160] Specifically, transactions that have been executed and written to the blockchain should be deleted from the transaction pool, and correspondingly, removed from the account preparation queue and account waiting queue corresponding to the account that sent the transaction. Blockchain nodes can still delete transactions at the account level; that is, based on the transactions in the block, they determine the maximum execution order identifier for each account, and then delete the preparation and waiting transactions for each account. Taking the target account as an example, suppose the blockchain node traverses the blocks and obtains the maximum execution order identifier for the target account.

[0161] Step S303: In the target account preparation queue, obtain the preparation transaction that has a mapping relationship with the first execution order identifier to be deleted, and use it as the preparation transaction to be deleted; the first execution order identifier to be deleted is the execution order identifier in the target account preparation queue that is less than or equal to the maximum execution order identifier.

[0162] Specifically, a blockchain node can obtain the target account preparation queue corresponding to the target account, and then search for an execution order identifier less than or equal to the maximum execution order identifier in the target account preparation queue. This found execution order identifier is then used as the first execution order identifier to be deleted. Next, the blockchain node can use the preparation transactions in the target account preparation queue that have a mapping relationship with the first execution order identifier to be deleted as the preparation transactions to be deleted.

[0163] Step S304: In the target account preparation queue, delete the transaction to be deleted and the first execution order identifier to be deleted to obtain the updated account preparation queue; delete the transaction to be deleted in the total preparation queue to obtain the updated total preparation queue.

[0164] Specifically, after identifying the transaction to be deleted, the blockchain node can delete the transaction to be deleted and the first execution order identifier in the target account's preparation queue to obtain an updated account preparation queue; and delete the transaction to be deleted in the total preparation queue to obtain an updated total preparation queue.

[0165] Step S305: In the target account waiting queue, obtain the waiting transaction that has a mapping relationship with the second execution order identifier to be deleted, and use it as the waiting transaction to be deleted; the second execution order identifier to be deleted is the execution order identifier in the target account waiting queue that is less than or equal to the maximum execution order identifier.

[0166] Specifically, a blockchain node can obtain the target account waiting queue corresponding to the target account, and then search for an execution order identifier less than or equal to the maximum execution order identifier in the target account waiting queue. This found execution order identifier is then used as the second execution order identifier to be deleted. Next, the blockchain node can treat the waiting transactions in the target account waiting queue that have a mapping relationship with the second execution order identifier to be deleted as waiting transactions to be deleted.

[0167] Step S306: Delete the pending transaction and the second pending execution order identifier from the target account waiting queue to obtain the updated account waiting queue.

[0168] Specifically, after identifying the transaction to be deleted, the blockchain node can remove the transaction to be deleted and the second execution order identifier from the target account's waiting queue, thus obtaining an updated account waiting queue.

[0169] Optionally, after deleting executed transactions, the blockchain node can upgrade the update account waiting queue. This involves determining whether the preparation status of waiting transactions in the update account waiting queue has changed, and migrating transactions whose preparation status has changed to "ready" from the update account waiting queue to the update account preparation queue. One feasible implementation method for this upgrade process is as follows: The blockchain node obtains the minimum execution order identifier in the update account waiting queue; generates an optimized execution order identifier based on the maximum execution order identifier; if the minimum execution order identifier equals the optimized execution order identifier, then in the target account waiting queue, the execution order identifiers that form a continuous sequence with the minimum execution order identifier are used as optimized upgrade execution order identifiers. The minimum execution order identifier, the corresponding waiting transactions, the optimized upgrade execution order identifier, and the corresponding waiting transactions are then migrated sequentially to the update account preparation queue, resulting in the optimized upgrade account preparation queue; finally, the minimum execution order identifier, the corresponding waiting transactions, the optimized upgrade execution order identifier, and the corresponding waiting transactions are added sequentially to the overall update preparation queue, resulting in the overall optimized upgrade preparation queue. The process of generating an optimized execution order identifier based on the maximum execution order identifier is as follows: Increment the maximum execution order identifier by one to obtain the optimized execution order identifier. For ease of understanding, assume that the maximum execution order identifier of account A in the new block is execution order identifier 6, then the optimized execution order identifier is execution order identifier 7. Assume that after the blockchain node deletes execution order identifiers and their corresponding transactions that are not greater than the maximum execution order identifier from the account waiting queue, the resulting updated account waiting queue contains transaction 7 and its corresponding execution order identifier 7, transaction 8 and its corresponding execution order identifier 8, and transaction 10 and its corresponding execution order identifier 10. It is evident that the execution order identifier corresponding to transaction 7, the optimized execution order identifier, and execution order identifier 7 and execution order identifier 8 can form a continuous sequence of order identifiers. Therefore, the blockchain node will use execution order identifier 8 as the optimized execution order identifier, and then migrate transaction 7, its corresponding execution order identifier 7, transaction 8, and its corresponding execution order identifier 8 sequentially to the updated account preparation queue.

[0170] Optionally, after deleting executed transactions, blockchain nodes can delete preparation transactions with insufficient balances. Specifically, a blockchain node can obtain the preparation transaction corresponding to the minimum execution order identifier in the updated account preparation queue as a pending preparation transaction; then obtain the transaction execution cost of the pending preparation transaction; query the account resources of the target account; if the transaction execution cost of the pending preparation transaction is greater than the account resources, then delete the pending preparation transaction and the minimum execution order identifier from the updated account preparation queue, and delete the pending preparation transaction from the updated total preparation queue; in the updated account preparation queue after deletion, execution order identifiers greater than the minimum execution order identifier are used as downgraded execution order identifiers, and the downgraded execution order identifiers and their corresponding preparation transactions are migrated to the updated account waiting queue, resulting in the downgraded account waiting queue; the downgraded execution order identifiers and their corresponding preparation transactions are deleted from the updated account preparation queue after deletion; and the downgraded execution order identifiers and their corresponding preparation transactions are deleted from the updated total preparation queue after deletion. Because when the transactions in the updated account preparation queue are packaged into the candidate block next time, the preparation transaction corresponding to the minimum execution order identifier will be the first transaction executed for the target account in the candidate block. If the target account's digital resources are insufficient to support the transaction execution overhead required by the preparation transaction corresponding to the minimum execution order identifier, the candidate block will fail to reach consensus. Therefore, the blockchain node can first determine the preparation transaction corresponding to the minimum execution order identifier. If the target account balance is insufficient, the preparation transaction corresponding to the minimum execution order identifier will be deleted. At this time, if other transactions in the updated account preparation queue are packaged into the candidate block, they cannot be executed according to the execution order indicated by their corresponding execution order identifiers. Therefore, the blockchain node can first migrate other transactions in the updated account preparation queue back to the account waiting queue to wait.

[0171] Using the method provided in this application embodiment, the time consumed by refreshing the transaction pool when adding a new block is not affected by the size of the transaction pool, but only by the size of the block, thus improving the efficiency of the transaction pool refresh operation.

[0172] For further details, please see Figure 7 , Figure 7 This is a flowchart illustrating a transaction receiving method provided in an embodiment of this application. The transaction receiving method can be executed by a blockchain node (e.g., the one described above). Figure 1 This is executed by any blockchain node in the blockchain node system of the corresponding embodiment. The blockchain node may include the aforementioned... Figure 1 The corresponding embodiment describes the transaction pool, consensus module, blockchain structure, world state, and configuration module. Furthermore, blockchain nodes can build upon the transaction pool to access the aforementioned components. Figure 4The corresponding embodiments describe the account preparation queue hash mapping, account waiting queue hash mapping, account preparation queue, account waiting queue, total preparation queue, and total transaction queue. For example... Figure 7 As shown, after a blockchain node receives a target transaction from a target account, it will perform the following operations:

[0173] Step S701: Verify whether the total number of transactions has reached the upper limit.

[0174] Specifically, the blockchain node can determine whether the number of transactions in the total transaction queue has exceeded the limit based on the total upper limit of the transaction pool in the configuration module. If it has, an error is reported to the target account and the target transaction is not cached; if it has not exceeded the limit, step S702 is executed.

[0175] Step S702: Verify whether the account's transaction limit has been reached.

[0176] Specifically, the blockchain node can obtain the account address in the target transaction based on the single account limit in the configuration module. Then, based on the account preparation queue hash mapping and the account waiting queue hash mapping, it finds the account preparation queue and the account waiting queue corresponding to the target account and determines whether the sum of the number of transactions contained in the two queues exceeds the single account limit. If it does, an error is reported to the target account and the target transaction is not cached; otherwise, step S703 is executed.

[0177] Step S703: Verify whether the transaction is outdated.

[0178] Specifically, the blockchain node needs to verify whether the target transaction is outdated. If the txNonce of the target transaction is not less than the accountNonce of the target account in the current world state, the transaction is determined to be not outdated, and step S704 is continued; otherwise, the transaction is determined to be outdated, an error is reported to the target account, and the target transaction is not cached.

[0179] Step S704: Verify whether the account balance is sufficient.

[0180] Specifically, a blockchain node can query the account balance of the target account in the current world state based on the account address carried by the target transaction. If the account balance is less than the txFee of the target transaction, an error is reported to the target account and the transaction is not cached; if the account balance is not less than the txFee of the transaction, step S705 is executed.

[0181] Step S705: Determine if there is a transaction conflict.

[0182] Specifically, the blockchain node can obtain the account preparation queue and account waiting queue corresponding to the target account based on the account address carried by the target transaction. Then, the blockchain node will determine whether there are transactions with the same txNonce in the account preparation queue and account waiting queue corresponding to the target account. If there are transactions with the same txNonce, they are identified as conflicting transactions, and step S706 is executed. If there are no transactions with the same txNonce, step S712 is executed.

[0183] Step S706: Determine whether the transaction is covered.

[0184] Specifically, the blockchain node can obtain the txFee of the target transaction and the txFee of the conflicting transaction. If the txFee of the target transaction is not greater than the txFee of the conflicting transaction, an error is reported and the target transaction is not cached; if the txFee of the target transaction is not greater than the txFee of the conflicting transaction, step S707 is executed.

[0185] Step S707: Verify whether the transaction is ready.

[0186] Specifically, the blockchain node checks whether there is a transaction with the same txNonce in the account preparation queue and the account waiting queue corresponding to the target account based on the account address contained in the target transaction. If it is found in the account preparation queue, it is determined that the target transaction is ready and step S708 is executed; if it is found in the account waiting queue, it is determined that the target transaction is not ready and step S710 is executed.

[0187] Step S708: Overwrite conflicting transactions in the account preparation queue.

[0188] Specifically, the blockchain node deletes conflicting transactions from the account preparation queue corresponding to the target account based on the account address and txNonce contained in the target transaction, adds the target transaction to the account preparation queue, and then executes step S709.

[0189] Step S709: Cover conflicting transactions in the total preparation queue.

[0190] Specifically, a blockchain node can delete the conflicting transaction and its transaction hash from the total preparation queue based on the transaction hash of the conflicting transaction, add the target transaction and its transaction hash to the total preparation queue, and then execute step S711.

[0191] Step S710: Overwrite conflicting transactions in the account waiting queue.

[0192] Specifically, the blockchain node deletes conflicting transactions from the account waiting queue corresponding to the target account based on the account address and txNonce contained in the target transaction, adds the target transaction to the account waiting queue, and then executes step S711.

[0193] Step S711: Cover conflicting transactions in the overall transaction queue.

[0194] Specifically, based on the transaction hash of the conflicting transaction, the blockchain node deletes the conflicting transaction and its transaction hash from the total transaction queue, adds the target transaction and its transaction hash to the total transaction queue, and the process ends once the target transaction is received.

[0195] Step S712: Verify whether the transaction is ready.

[0196] Specifically, the blockchain node searches the account preparation queue corresponding to the target account based on the account address included in the target transaction. A transaction is considered ready if: the account preparation queue is empty, and the txNonce of the target transaction equals the accountNonce of the target account in the current world state; or, the account preparation queue is not empty, and the txNonce of the target transaction equals the txNonce of the last transaction in the account preparation queue plus 1. If the target transaction is ready, proceed to step S713; if the target transaction is not ready, proceed to step S716.

[0197] Step S713: Add the target transaction to the account preparation queue.

[0198] Specifically, the blockchain node adds the target transaction and its corresponding txNonce to the tail of the account preparation queue. In other words, the target transaction becomes the last transaction in the account preparation queue, and then step S714 is executed.

[0199] Step S714: Locate the transactions in the account waiting queue that can be upgraded and upgrade them.

[0200] Specifically, the blockchain node checks if there are any upgradable transactions in the account waiting queue, and then upgrades those transactions. Upgrading involves moving the transaction from the account waiting queue to the account preparation queue. The blockchain node then proceeds to step S715.

[0201] Specifically, a feasible method for blockchain nodes to determine whether there are transactions that can be upgraded and to upgrade them is as follows: blockchain nodes can start looping from the first transaction in the account waiting queue, and determine whether the txNonce of the transaction is equal to the txNonce of the last transaction in the account preparation queue plus 1. If so, the transaction is deleted from the account preparation queue and added to the account preparation queue (becoming the last transaction in the account preparation queue), and the upgraded transaction is recorded.

[0202] Specifically, a feasible method for blockchain nodes to determine whether there are upgradable transactions and to upgrade them is as follows: when the transactions in the account waiting queue are arranged in ascending order according to the txNonce corresponding to the transaction, the blockchain node can determine whether the txNonce of the first transaction in the account waiting queue is equal to the txNonce of the last transaction in the account preparation queue plus 1. If so, all transactions corresponding to txNonces that can form a sequential sequence with the txNonce corresponding to the first transaction in the account waiting queue are determined as upgrade transactions and added to the account preparation queue.

[0203] Step S715: Add the target transaction and the upgraded transaction to the overall preparation queue.

[0204] Specifically, the blockchain node adds the target transaction and the upgraded transaction to the total preparation queue, and then executes step S717.

[0205] Step S716: Add the target transaction to the account waiting queue.

[0206] Specifically, the blockchain node adds the target transaction and its corresponding txNonce to the account waiting queue, and then executes step S717.

[0207] Step S717: Add the target transaction to the overall transaction queue.

[0208] Specifically, the process of receiving a target transaction ends once the blockchain node adds the target transaction to the overall transaction queue.

[0209] The method provided in this application can effectively receive and cache transactions whose txNonce is not ready, and then package the transaction normally once the txNonce is ready. This improves the fault tolerance of the blockchain system and ensures a valid match between the txNonce and accountNonce of the transactions packaged when generating candidate blocks, thus increasing the success rate of block generation. Furthermore, it supports sending transaction requests from the same account with a higher txFee, covering transactions with the same nonce in the transaction pool, thereby increasing the flexibility for users to utilize the blockchain.

[0210] In a blockchain node system, a blockchain node with block-producing authority can start from the first transaction in the main preparation queue and package each subsequent transaction into a candidate block, but the final number of transactions packaged cannot exceed the maximum number of block transactions configured in the module. Whenever a candidate block passes consensus and becomes a new official block, after being inserted into the blockchain data structure, each blockchain node in the system can perform a transaction pool refresh operation. For easier understanding, please refer to [link to relevant documentation]. Figure 8 , Figure 8This is a schematic diagram illustrating a process for refreshing a transaction pool, as provided in an embodiment of this application. Figure 8 As shown, the process of refreshing the trading pool includes:

[0211] Step S801: Calculate the maximum execution order identifier for each account within the new block.

[0212] Specifically, a blockchain node can traverse each transaction in a new block, find the maximum txNonce for each account, establish a hash mapping from the account address to the maximum txNonce, traverse the hash mapping, and for each account address and its maximum txNonce, execute steps S802 to S805 respectively.

[0213] Step S802: Clean up outdated transactions.

[0214] Specifically, the blockchain node looks up the account preparation queue and the account waiting queue corresponding to the account based on the account address, deletes the transactions whose txNonce is not greater than the account's maximum txNonce, deletes the transactions in the total preparation queue and the total queue based on the transaction hash of the deleted transactions, and continues to execute step S803.

[0215] Step S803, upgrade to prepare for transaction.

[0216] Specifically, a blockchain node can look up the corresponding account waiting queue based on the account address, determine whether the txNonce of the first transaction in the account waiting queue is equal to the account's maximum txNonce plus 1, and if they are equal, then upgrade the transaction and a series of subsequent transactions with consecutive txNonces in the account waiting queue. Upgrading means deleting the transaction from the account waiting queue and adding it to the account preparation queue and the total preparation queue, and then continuing to execute step S804.

[0217] Step S804: Delete the pre-transaction with insufficient balance.

[0218] Specifically, a blockchain node can look up the corresponding account preparation queue based on the account address, determine whether the txFee of the first transaction in the account preparation queue is greater than the account balance of the account to which it belongs in the current world state, and if it is greater, delete the transaction from the account preparation queue, the total preparation queue and the total queue, and continue to execute step S805.

[0219] Step S805, downgraded unprepared transaction.

[0220] Specifically, for the accounts whose transactions were deleted due to insufficient balance, the blockchain node downgrades all transactions in their account preparation queue. Downgrading means removing the transactions from the total preparation queue and the account preparation queue, and adding them to the account waiting queue. The process is then complete.

[0221] Using the method provided in this application embodiment, the time consumed by refreshing the transaction pool when adding a new block is not affected by the size of the transaction pool, but only by the size of the block, thus improving the efficiency of the transaction pool refresh operation.

[0222] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of this application. The data processing apparatus can be a computer program (including program code) running on a computer device; for example, the data processing apparatus is application software. The apparatus can be used to execute corresponding steps in the data processing method provided in the embodiments of this application. Figure 9 As shown, the data processing device 1 may include: an acquisition module 101, a transaction transition module 102, a transaction upgrade module 103, and a transaction addition module 104.

[0223] The acquisition module 101 is used to acquire target transactions sent by the target account, and to acquire the target account preparation queue and target account waiting queue corresponding to the target account; the target transaction contains a target execution order identifier; the target account preparation queue is used to store the prepared transactions in the prepared state and the execution order identifiers that have a mapping relationship with the prepared transactions; the target account waiting queue is used to store the waiting transactions in the unprepared state and the execution order identifiers that have a mapping relationship with the waiting transactions.

[0224] The transaction transition module 102 is used to add the target transaction and the target execution order identifier to the target account preparation queue if the target transaction is in the ready state, so as to obtain the transition account preparation queue.

[0225] The transaction upgrade module 103 is used to take the execution order identifier that can form a continuous sequence of sequence identifiers with the target execution order identifier as the upgrade execution order identifier in the target account waiting queue, and migrate the upgrade execution order identifier and the waiting transactions corresponding to the upgrade execution order identifier to the transition account preparation queue in order to obtain the upgrade account preparation queue.

[0226] The transaction addition module 104 is used to add the target transaction and the waiting transaction corresponding to the upgrade execution order identifier in the upgrade account preparation queue to the total preparation queue; the transactions in the total preparation queue will be packaged into candidate blocks in the order of transaction insertion time.

[0227] The specific implementation methods of the acquisition module 101, transaction transition module 102, transaction upgrade module 103, and transaction addition module 104 can be found above. Figure 3 The descriptions of steps S101-S104 in the corresponding embodiments will not be repeated here.

[0228] Please see again. Figure 9The aforementioned data processing device 1 further includes: a first state determination module 105.

[0229] The first state determination module 105 is used to compare the target execution order identifier with the target account's currently executed transaction identifier if the target account's preparation queue is empty.

[0230] The first state determination module 105 is also used to determine that the target transaction is in a ready state if the target execution order identifier is the same as the currently executed transaction identifier of the target account.

[0231] The first state determination module 105 is also used to determine that the target transaction is in an unprepared state if the target execution order identifier and the target account's currently executed transaction identifier are different, and to add the target transaction and the target execution order identifier to the target account's waiting queue.

[0232] The specific implementation of the first state determination module 105 can be found above. Figure 3 The description of step S102 in the corresponding embodiments will not be repeated here.

[0233] Please see again. Figure 9 The aforementioned data processing device 1 further includes a second state determination module 106.

[0234] The second state determination module 106 is used to determine the identification relationship between the target execution order identifier and the largest execution order identifier in the target account preparation queue if the target account preparation queue is not empty.

[0235] The second state determination module 106 is also used to determine that the target transaction is in a ready state if the identification relationship satisfies the sequential continuity relationship.

[0236] The second state determination module 106 is also used to determine that the target transaction is in an unprepared state if the identification relationship does not satisfy the sequential continuity relationship, and to add the target transaction and the target execution order identifier to the target account waiting queue.

[0237] The specific implementation of the second state determination module 106 can be found in the above description. Figure 3 The description of step S102 in the corresponding embodiments will not be repeated here.

[0238] Please see again. Figure 9 The aforementioned data processing device 1 further includes: a traversal module 107, a conflict determination module 108, a first coverage module 109, and a second coverage module 110.

[0239] Traversal module 107 is used to traverse the target account preparation queue and the target account waiting queue according to the target execution order identifier to obtain the traversal result for the target transaction;

[0240] The conflict determination module 108 is also used to determine the transaction with the target execution order identifier in the queue as a conflicting transaction if the traversal result indicates that there is a transaction with the target execution order identifier in the queue to be processed; the queue to be processed is the target account preparation queue or the target account waiting queue.

[0241] The first coverage module 109 is used to cover the conflicting transaction based on the target transaction if the conflicting transaction and the conflicting transaction meet the conflict coverage conditions.

[0242] The second coverage module 110 is used to call the transaction transition module to perform the following steps if the target transaction and the conflicting transaction do not meet the conflict coverage conditions: if the target transaction is in a ready state, add the target transaction and the target execution order identifier to the target account preparation queue to obtain the transition account preparation queue.

[0243] The specific implementation methods of the traversal module 107, the conflict determination module 108, the first coverage module 109, and the second coverage module 110 can be found above. Figure 5 The descriptions of steps S203-S205 in the corresponding embodiments will not be repeated here.

[0244] Please see again. Figure 9 The aforementioned data processing device 1 further includes: a coverage determination module 111.

[0245] The coverage determination module 111 is used to obtain the transaction execution cost of the target transaction and the transaction execution cost of the conflicting transactions;

[0246] The coverage determination module 111 is also used to determine that the target transaction and the conflicting transaction meet the conflict coverage condition if the transaction execution cost of the target transaction is greater than the transaction execution cost of the conflicting transaction.

[0247] The coverage determination module 111 is also used to determine that the target transaction and the conflicting transaction do not meet the conflict coverage condition if the transaction execution cost of the target transaction is less than or equal to the transaction execution cost of the conflicting transaction, and to send a transaction coverage failure error message to the target user.

[0248] The specific implementation of the coverage determination module 111 can be found in the above description. Figure 5 The description of step S204 in the corresponding embodiments will not be repeated here.

[0249] Please see again. Figure 9 The first coverage module 109 includes: a first replacement unit 1091 and a second replacement unit 1092.

[0250] The first replacement unit 1091 is used to replace the conflicting transaction with the target transaction in the target account preparation queue and in the total preparation queue if the queue to be processed is the target account preparation queue.

[0251] The second replacement unit 1092 is used to replace the conflicting transaction with the target transaction in the target account waiting queue if the queue to be processed is the target account waiting queue.

[0252] The specific implementation methods of the first replacement unit 1091 and the second replacement unit 1092 can be found in the above description. Figure 5 The description of step S204 in the corresponding embodiments will not be repeated here.

[0253] Please see again. Figure 9 The aforementioned data processing device 1 further includes: a first transaction processing module 112.

[0254] The first transaction processing module 112 is used to obtain the upper limit threshold of the number of transactions in an account;

[0255] The first transaction processing module 112 is also used to send a transaction limit error message to the target account if the sum of the number of transactions to be prepared in the target account's preparation queue and the number of transactions to be waited in the target account's waiting queue is equal to the account's transaction limit threshold.

[0256] The first transaction processing module 112 is also used to call the transaction transition module to perform the step of adding the target transaction and the target execution order identifier to the target account preparation queue if the sum of the number of prepared transactions and the number of waiting transactions is less than the account transaction limit, thereby obtaining the transition account preparation queue.

[0257] The specific implementation of the first transaction processing module 112 can be found in the above description. Figure 5 The description of step S201 in the corresponding embodiments will not be repeated here.

[0258] Please see again. Figure 9 The aforementioned data processing device 1 further includes: a second transaction processing module 113.

[0259] The second transaction processing module 113 is used to obtain the number of currently executed transactions of the target account;

[0260] The second transaction processing module 113 is also used to send a transaction expired error message to the target account if the target expected execution order identifier is less than the number of currently executed transactions;

[0261] The second transaction processing module 113 is also used to call the transaction transition module to perform the step of adding the target transaction and the target execution order identifier to the target account preparation queue if the target execution order identifier is greater than or equal to the number of currently executed transactions, so as to obtain the transition account preparation queue.

[0262] The specific implementation of the second transaction processing module 113 can be found in the above description. Figure 5 The description of step S201 in the corresponding embodiments will not be repeated here.

[0263] Please see again. Figure 9 The aforementioned data processing device 1 further includes: a third transaction processing module 114.

[0264] The third transaction processing module 114 is used to obtain the transaction execution cost of the target transaction and query the account resources of the target account;

[0265] The third transaction processing module 114 is also used to send a resource shortage error message to the target account if the account resources are less than the transaction execution cost;

[0266] The third transaction processing module 114 is also used to call the transaction transition module to perform the step of adding the target transaction and the target execution order identifier to the target account preparation queue if the account balance is greater than or equal to the transaction execution cost, so as to obtain the transition account preparation queue.

[0267] The specific implementation of the third transaction processing module 114 can be found in the above description. Figure 5 The description of step S201 in the corresponding embodiments will not be repeated here.

[0268] Please see again. Figure 9 The aforementioned data processing device 1 further includes: a transaction packaging module 115 and a queue update module 116.

[0269] The transaction packaging module 115 is used to package the transactions in the total preparation queue into candidate blocks according to the transaction insertion time order; the number of transactions in a block is less than or equal to the block transaction number threshold.

[0270] The queue update module 116 is used to perform consensus processing on candidate blocks to obtain new blocks, traverse the new blocks, and obtain the maximum execution order identifier of the target account.

[0271] The queue update module 116 is also used to obtain, in the target account preparation queue, a preparation transaction that has a mapping relationship with the first execution order identifier to be deleted, as a preparation transaction to be deleted; the first execution order identifier to be deleted is an execution order identifier in the target account preparation queue that is less than or equal to the maximum execution order identifier;

[0272] The queue update module 116 is also used to delete the pending transaction and the first pending execution order identifier in the target account preparation queue to obtain the updated account preparation queue.

[0273] The queue update module 116 is also used to delete pending transactions in the total preparation queue to obtain an updated total preparation queue.

[0274] The queue update module 116 is also used to obtain, in the target account waiting queue, a waiting transaction that has a mapping relationship with the second execution order identifier to be deleted, as a waiting transaction to be deleted; the second execution order identifier to be deleted is the execution order identifier in the target account waiting queue that is less than or equal to the maximum execution order identifier;

[0275] The queue update module 116 is also used to delete the pending transaction and the second pending execution order identifier in the target account waiting queue to obtain the updated account waiting queue.

[0276] The specific implementation methods of the transaction packaging module 115 and the queue update module 116 can be found in the above description. Figure 6 The descriptions of steps S301-S306 in the corresponding embodiments will not be repeated here.

[0277] Please see again. Figure 9 The aforementioned data processing device 1 further includes a queue optimization module 117.

[0278] Queue optimization module 117 is used to obtain the minimum execution order identifier in the update account waiting queue;

[0279] The queue optimization module 117 is also used to generate an optimized execution order identifier based on the maximum execution order identifier;

[0280] The queue optimization module 117 is also used to, if the minimum execution order identifier is equal to the optimized execution order identifier, in the target account waiting queue, take the execution order identifier that can form a continuous sequence of order identifiers with the minimum execution order identifier as the optimized upgrade execution order identifier, and migrate the minimum execution order identifier, the waiting transactions corresponding to the minimum execution order identifier, the optimized upgrade execution order identifier, and the waiting transactions corresponding to the optimized upgrade execution order identifier to the update account preparation queue in order to obtain the optimized upgrade account preparation queue;

[0281] The queue optimization module 117 is also used to add the minimum execution order identifier, the waiting transaction corresponding to the minimum execution order identifier, the optimization and upgrade execution order identifier, and the waiting transaction corresponding to the optimization and upgrade execution order identifier to the update total preparation queue in sequence, so as to obtain the optimization and upgrade total preparation queue.

[0282] The specific implementation of the queue optimization module 117 can be found in the above description. Figure 6 The optional embodiments described in the corresponding examples will not be repeated here.

[0283] Please see again. Figure 9 The aforementioned data processing device 1 further includes a queue deletion module 118.

[0284] The queue deletion module 118 is used to obtain the preparation transaction corresponding to the minimum execution order identifier in the update account preparation queue, and use it as the preparation transaction to be judged.

[0285] The queue deletion module 118 is also used to obtain the transaction execution cost of the transaction to be judged and to query the account resources of the target account;

[0286] The queue deletion module 118 is also used to delete the pending transaction and the minimum execution order identifier from the updated account preparation queue and delete the pending transaction from the updated total preparation queue if the transaction execution cost of the pending transaction exceeds the account resources.

[0287] The queue deletion module 118 is also used to, in the deleted update account preparation queue, take the execution order identifier that is greater than the minimum execution order identifier as the downgrade execution order identifier, migrate the downgrade execution order identifier and the preparation transaction corresponding to the downgrade execution order identifier to the update account waiting queue, and obtain the downgrade account waiting queue;

[0288] The queue deletion module 118 is also used to delete the downgrade execution order identifier and the corresponding preparation transaction from the deleted update account preparation queue;

[0289] The queue deletion module 118 is also used to delete the downgrade execution order identifier and the corresponding preparation transaction from the deleted update total preparation queue.

[0290] The specific implementation of the queue deletion module 118 can be found in the above description. Figure 6 The descriptions of the optional embodiments in the corresponding examples will not be repeated here.

[0291] Please see Figure 10 , 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 above, Figure 9The data processing device 1 in the corresponding embodiment can be applied to a computer device 1000, which 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 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also 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.

[0292] In such Figure 10 In the computer device 1000 shown, the network interface 1004 provides network communication elements; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0293] Retrieve the target transaction sent by the target account, and retrieve the target account preparation queue and target account waiting queue corresponding to the target account; the target transaction contains a target execution order identifier; the target account preparation queue is used to store the prepared transactions in the prepared state, and the execution order identifiers that are mapped to the prepared transactions; the target account waiting queue is used to store the waiting transactions in the unprepared state, and the execution order identifiers that are mapped to the waiting transactions.

[0294] If the target transaction is in the ready state, the target transaction and the target execution order identifier are added to the target account preparation queue to obtain the transition account preparation queue.

[0295] In the target account waiting queue, the execution order identifier that can form a continuous sequence of order identifiers with the target execution order identifier is used as the upgrade execution order identifier. The upgrade execution order identifier and the waiting transaction corresponding to the upgrade execution order identifier are added to the transition account preparation queue in order to obtain the upgrade account preparation queue.

[0296] The target transaction and the waiting transaction corresponding to the upgrade execution order identifier in the upgrade account preparation queue are added to the total preparation queue; the transactions in the total preparation queue will be packaged into candidate blocks in the order of transaction insertion time.

[0297] It should be understood that the computer device 1000 described in the embodiments of this application can perform the data processing method described in any of the preceding embodiments, and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0298] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing a computer program executed by the aforementioned data processing apparatus 1. This computer program includes program instructions, which, when executed by the processor, can perform the data processing method described in any of the preceding embodiments. Therefore, further details will not be repeated here. Additionally, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application.

[0299] The aforementioned computer-readable storage medium can be an internal storage unit of the data processing apparatus or computer device provided in any of the foregoing embodiments, 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 and external storage units 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.

[0300] 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 4 The method provided in any of the corresponding embodiments.

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

[0302] 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 composition and steps of each example have been generally described in the foregoing description as a network element. Whether these network elements are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described network elements using different methods for each specific application, but such implementation should not be considered beyond the scope of this application.

[0303] 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 data processing method based on blockchain, characterized in that, include: Obtain the target transaction sent by the target account, and obtain the target account preparation queue and target account waiting queue corresponding to the target account; The target transaction includes a target execution order identifier; The target account preparation queue is used to store transactions that are in a ready state and execution order identifiers that are mapped to the transactions. The target account waiting queue is used to store pending transactions in an unprepared state, as well as execution order identifiers that are mapped to the pending transactions; If the target transaction is in the prepared state, then the target transaction and the target execution order identifier are added to the target account preparation queue to obtain the transition account preparation queue; In the target account waiting queue, the execution order identifier that can form a continuous sequence of order identifiers with the target execution order identifier is used as the upgrade execution order identifier. The upgrade execution order identifier and the waiting transactions corresponding to the upgrade execution order identifier are migrated to the transition account preparation queue in order to obtain the upgrade account preparation queue. The target transaction and the waiting transaction corresponding to the upgrade execution order identifier in the upgrade account preparation queue are added to the total preparation queue; the transactions in the total preparation queue are packaged into candidate blocks in the order of transaction insertion time.

2. The method according to claim 1, characterized in that, Also includes: If the target account preparation queue is empty, then the target execution order identifier and the current number of executed transactions of the target account are compared. If the target execution order identifier is the same as the number of currently executed transactions of the target account, then the target transaction is determined to be in the ready state; If the target execution order identifier is different from the number of currently executed transactions of the target account, then the target transaction is determined to be in the unprepared state, and the target transaction and the target execution order identifier are added to the target account's waiting queue.

3. The method according to claim 1, characterized in that, Also includes: If the target account preparation queue is a non-empty queue, then determine the identification relationship between the target execution order identifier and the largest execution order identifier in the target account preparation queue; If the identification relationship satisfies the sequential continuity relationship, then the target transaction is determined to be in the ready state; If the identification relationship does not satisfy the sequential continuity relationship, then the target transaction is determined to be in the unprepared state, and the target transaction and the target execution order identifier are added to the target account waiting queue.

4. The method according to claim 1, characterized in that, Also includes: Based on the target execution order identifier, traverse the target account preparation queue and the target account waiting queue to obtain the traversal result for the target transaction; When the traversal result indicates that there is a transaction with the target execution order identifier in the queue to be processed, the transaction with the target execution order identifier in the queue to be processed is identified as a conflicting transaction; the queue to be processed is the target account preparation queue or the target account waiting queue. If the target transaction and the conflicting transaction meet the conflict coverage condition, then the conflicting transaction is covered based on the target transaction; When the traversal result indicates that there is no transaction with the target execution order identifier in the queue to be processed, the step of adding the target transaction and the target execution order identifier to the target account preparation queue if the target transaction is in the prepared state is executed to obtain the transition account preparation queue.

5. The method according to claim 4, characterized in that, Also includes: Obtain the transaction execution cost of the target transaction, and obtain the transaction execution cost of the conflicting transaction; If the execution cost of the target transaction is greater than the execution cost of the conflicting transaction, then the conflict coverage condition is determined to be met between the target transaction and the conflicting transaction. If the transaction execution cost of the target transaction is less than or equal to the transaction execution cost of the conflicting transaction, it is determined that the conflict coverage condition is not met between the target transaction and the conflicting transaction, and a transaction coverage failure error message is sent to the target user.

6. The method according to claim 4, characterized in that, Then, based on the target transaction, the conflicting transactions are overridden, including: If the queue to be processed is the target account preparation queue, then in the target account preparation queue, the conflicting transaction is replaced with the target transaction, and in the total preparation queue, the conflicting transaction is replaced with the target transaction. If the queue to be processed is the target account waiting queue, then in the target account waiting queue, the conflicting transaction is replaced with the target transaction.

7. The method according to claim 1, characterized in that, Also includes: Get the account transaction limit threshold; If the sum of the number of transactions to be prepared in the target account's preparation queue and the number of transactions to be waited in the target account's waiting queue is equal to the account's transaction limit threshold, then a transaction limit error message is sent to the target account. If the sum of the number of transactions to be prepared and the number of transactions to be waited for is less than the account transaction limit, then the step of adding the target transaction and the target execution order identifier to the target account preparation queue to obtain the transition account preparation queue is executed if the target transaction is in the prepared state.

8. The method according to claim 1, characterized in that, Also includes: Obtain the current number of executed transactions for the target account; If the target expected execution order identifier is less than the number of currently executed transactions, then a transaction expired error message is sent to the target account; If the target execution order identifier is greater than or equal to the number of currently executed transactions, then the step of adding the target transaction and the target execution order identifier to the target account preparation queue to obtain the transition account preparation queue if the target transaction is in the ready state is executed.

9. The method according to claim 1, characterized in that, Also includes: Obtain the transaction execution cost of the target transaction and query the account resources of the target account; If the account resources are less than the transaction execution cost, then a resource shortage error message is sent to the target account; If the account balance is greater than or equal to the transaction execution cost, then the step of adding the target transaction and the target execution order identifier to the target account preparation queue to obtain the transition account preparation queue is executed if the target transaction is in the prepared state.

10. The method according to claim 1, characterized in that, Also includes: The transactions in the total preparation queue are packaged into candidate blocks according to the order of their insertion time; The number of transactions in the block is less than or equal to the block transaction number threshold; Consensus processing is performed on the candidate blocks to obtain new blocks. The new blocks are then traversed to obtain the maximum execution order identifier of the target account. In the target account preparation queue, a preparation transaction that has a mapping relationship with the first execution order identifier to be deleted is obtained as a preparation transaction to be deleted; the first execution order identifier to be deleted is the execution order identifier in the target account preparation queue that is less than or equal to the maximum execution order identifier; In the target account preparation queue, delete the transaction to be deleted and the first execution order identifier to be deleted to obtain the updated account preparation queue; delete the transaction to be deleted in the total preparation queue to obtain the updated total preparation queue. In the target account waiting queue, a waiting transaction that has a mapping relationship with the second execution order identifier to be deleted is obtained as a waiting transaction to be deleted; the second execution order identifier to be deleted is the execution order identifier in the target account waiting queue that is less than or equal to the maximum execution order identifier; The pending transaction to be deleted and the second pending execution order identifier are deleted from the target account waiting queue to obtain the updated account waiting queue.

11. The method according to claim 10, characterized in that, Also includes: Obtain the minimum execution order identifier in the updated account waiting queue; Generate an optimized execution order identifier based on the maximum execution order identifier; If the minimum execution order identifier is equal to the optimized execution order identifier, then in the target account waiting queue, the execution order identifier that can form a continuous sequence of order identifiers with the minimum execution order identifier is used as the optimized upgrade execution order identifier. The minimum execution order identifier, the waiting transaction corresponding to the minimum execution order identifier, the optimized upgrade execution order identifier, and the waiting transaction corresponding to the optimized upgrade execution order identifier are migrated to the update account preparation queue in sequence to obtain the optimized upgrade account preparation queue. The minimum execution order identifier, the waiting transactions corresponding to the minimum execution order identifier, the optimization and upgrade execution order identifier, and the waiting transactions corresponding to the optimization and upgrade execution order identifier are added to the total update preparation queue in sequence to obtain the total optimization and upgrade preparation queue.

12. The method according to claim 10, characterized in that, Also includes: Obtain the preparation transaction corresponding to the minimum execution order identifier in the updated account preparation queue, and use it as the preparation transaction to be judged; Obtain the transaction execution cost of the transaction to be determined; query the account resources of the target account; If the transaction execution cost of the pending transaction exceeds the account resources, then the pending transaction and the minimum execution order identifier are removed from the updated account preparation queue, and the pending transaction is also removed from the updated total preparation queue. In the updated account preparation queue after deletion, the execution order identifier that is greater than the minimum execution order identifier is used as the downgrade execution order identifier. The downgrade execution order identifier and the preparation transaction corresponding to the downgrade execution order identifier are migrated to the updated account waiting queue to obtain the downgraded account waiting queue. Remove the downgrade execution order identifier and the corresponding prepared transaction from the deleted update account prepared queue; The downgrade execution order identifier and the corresponding prepared transaction are deleted from the total update prepared queue after deletion.

13. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1-12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method of any one of claims 1-12.

15. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, the method described in any one of claims 1-12 is performed.

Images