Transaction state query method and device in block chain, and computer equipment

Abstract

The invention relates to a transaction state query method and device in a block chain, computer equipment, a storage medium and a computer program product. The method can be applied to the fields of block chains and smart traffic, and comprises the following steps: receiving a transaction state query request carrying a transaction identifier initiated by a client; querying a first transaction state matched with the transaction identifier in the abnormal transaction queue; when the first transaction state is not queried, a second transaction state matched with the transaction identifier is queried from a transaction set, and the transaction set is used for storing the transaction task to be packaged and the corresponding transaction state or is used for storing the transaction task in a consensus and the corresponding transaction state; and when the second transaction state is not queried, querying a third transaction state representing that the second transaction state is linked on the home terminal node from the database, and returning the third transaction state to the client after the third transaction state is queried. By adopting the method, the query efficiency of the transaction state in the block chain can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a method, apparatus, computer device, storage medium, and computer program product for querying transaction status in a blockchain. Background Art

[0002] A blockchain is a new type of decentralized distributed ledger technology that can securely store transactions or other data. The feature is that the information stored on the blockchain cannot be forged or tampered with. The blockchain consensus algorithm drives each node on the blockchain to participate in the verification process of transactions, ensuring that the transactions on the blockchain are all confirmed and trustworthy.

[0003] However, in the current methods for querying transaction status in a blockchain, for example, both in the Ethereum and Chang'an Chain transaction pools, a query function for the transaction pool status is provided, which can query how many transactions there are in the transaction pool and the transaction identifiers of each transaction in the transaction pool, but it is unable to follow the entire life cycle of each transaction. Therefore, when a user wants to query the transaction status, it is easy to encounter a situation where the query fails or cannot be performed, resulting in a low query efficiency for the transaction status. Summary of the Invention

[0004] Based on this, in order to solve the above technical problems, there is a need to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for querying transaction status in a blockchain, which can effectively improve the query efficiency of transaction status in the blockchain and at the same time improve the processing performance of the entire blockchain.

[0005] In a first aspect, this application provides a method for querying transaction status in a blockchain. The method includes: receiving a transaction status query request carried with a transaction identifier initiated by a client; querying a first transaction status matching the transaction identifier in an abnormal transaction queue; when the first transaction status is not queried, querying a second transaction status matching the transaction identifier from a transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; when the second transaction status is not queried, querying a third transaction status indicating that the transaction has been chained on the local node from a database, and after querying the third transaction status, returning the third transaction status to the client.

[0006] In a second aspect, the present application also provides a transaction status query device in a blockchain. The device includes: a receiving module, configured to receive a transaction status query request carrying a transaction identifier initiated by a client; a query module, configured to query a first transaction status matching the transaction identifier in an abnormal transaction queue; when the first transaction status is not queried, query a second transaction status matching the transaction identifier from a transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; a returning module, configured to, when the second transaction status is not queried, query a third transaction status indicating that the transaction has been chained on the local node from a database, and after the third transaction status is queried, return the third transaction status to the client.

[0007] In a third aspect, the present application also provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the following steps are implemented: receiving a transaction status query request carrying a transaction identifier initiated by a client; querying a first transaction status matching the transaction identifier in an abnormal transaction queue; when the first transaction status is not queried, query a second transaction status matching the transaction identifier from a transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; when the second transaction status is not queried, query a third transaction status indicating that the transaction has been chained on the local node from a database, and after the third transaction status is queried, return the third transaction status to the client.

[0008] In a fourth aspect, the present application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, and when the computer program is executed by a processor, the following steps are implemented: receiving a transaction status query request carrying a transaction identifier initiated by a client; querying a first transaction status matching the transaction identifier in an abnormal transaction queue; when the first transaction status is not queried, query a second transaction status matching the transaction identifier from a transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; when the second transaction status is not queried, query a third transaction status indicating that the transaction has been chained on the local node from a database, and after the third transaction status is queried, return the third transaction status to the client.

[0009] Fifth aspect, the present application also provides a computer program product. The computer program product includes a computer program which, when executed by a processor, implements the following steps: receiving a transaction status query request carrying a transaction identifier initiated by a client; querying a first transaction status matching the transaction identifier in an abnormal transaction queue; when the first transaction status is not queried, querying a second transaction status matching the transaction identifier from a transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; when the second transaction status is not queried, querying a third transaction status indicating that the transaction has been chained on the local node from a database, and after querying the third transaction status, returning the third transaction status to the client.

[0010] The above-mentioned transaction status query method, device, computer device, storage medium and computer program product in the blockchain receive a transaction status query request carrying a transaction identifier initiated by a client, and query a first transaction status matching the transaction identifier in an abnormal transaction queue; when the first transaction status is not queried, query a second transaction status matching the transaction identifier from a transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; when the second transaction status is not queried, query a third transaction status indicating that the transaction has been chained on the local node from a database, and after querying the third transaction status, return the third transaction status to the client. Since different types of abnormal transaction tasks are stored in the abnormal transaction queue, when receiving a transaction status query request carrying a transaction identifier initiated by a client, it is possible to first query the first transaction status, i.e., the abnormal status, matching the transaction identifier in the abnormal transaction queue; when the first transaction status is not queried, then query the second transaction status matching the transaction identifier from the transaction set, and when the second transaction status is not queried, finally query the third transaction status indicating that the transaction has been chained on the local node from the database, enabling the client (user) to query the transaction status of all transactions, following the entire life cycle transfer process of a transaction, effectively improving the query efficiency of the transaction status in the blockchain while also improving the processing performance of the entire blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 FIG. 9 is an optional structural schematic diagram of a distributed system 100 applied to a blockchain system in an embodiment;

[0012] Figure 2 FIG. 13 is an optional schematic diagram of a block structure in an embodiment;

[0013] Figure 3 It is an application environment diagram of a transaction status query method in a blockchain in an embodiment;

[0014] Figure 4 It is a schematic diagram of a transaction status query based on RPC in an embodiment;

[0015] Figure 5 It is a schematic structural diagram of a circular queue in an embodiment;

[0016] Figure 6 It is a schematic flowchart of adding abnormal transactions and transaction statuses in a circular queue in an embodiment;

[0017] Figure 7 It is an interaction flowchart between a transaction pool and other modules in an embodiment;

[0018] Figure 8 It is a transaction status definition diagram in an embodiment;

[0019] Figure 9 It is a structural block diagram of a transaction status query device in a blockchain in an embodiment;

[0020] Figure 10 It is an internal structural diagram of a computer device in an embodiment. Specific Embodiments

[0021] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0022] It should be noted that in the following descriptions, the terms "first, second, and third" only distinguish similar objects and do not represent a specific order for the objects. Understandably, "first, second, and third" can be interchanged with a specific order or sequence when allowed, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein.

[0023] The system involved in the embodiments of the present invention can be a distributed system formed by connecting a client and multiple nodes (any form of computing device accessing the network, such as a server, user terminal) through network communication.

[0024] Taking the distributed system as a blockchain system as an example, see Figure 1 , Figure 1FIG. 0 is an optional schematic structural diagram of the distributed system 100 provided by an embodiment of the present invention applied to a blockchain system, which is formed by multiple nodes (any form of computing device accessing the network, such as a server, a user terminal) and a client. A peer-to-peer (Peer To Peer) network is formed among the nodes. The Peer To Peer protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine such as a server or a terminal can join and become a node. A node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0025] Refer to Figure 1 the functions of each node in the illustrated blockchain system. The functions involved include:

[0026] 1) Routing, which is a basic function of a node and is used to support communication between nodes.

[0027] In addition to the routing function, a node can also have the following functions:

[0028] 2) Application, which is used to be deployed in the blockchain, implement specific services according to actual business requirements, record the data related to the implemented functions to form record data, carry a digital signature in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes verify the source and integrity of the record data successfully, the record data is added to the temporary block.

[0029] For example, the services implemented by the application include:

[0030] 2.1) Wallet, which is used to provide the function of conducting electronic currency transactions, including initiating a transaction (that is, sending the transaction record of the current transaction to other nodes in the blockchain system. After other nodes verify successfully, as a response to acknowledging the validity of the transaction, the record data of the transaction is deposited into the temporary block of the blockchain; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0031] 2.2) Shared ledger, which is used to provide functions such as storage, query, and modification of account data. The record data of the operations on the account data is sent to other nodes in the blockchain system. After other nodes verify its validity, as a response to acknowledging the validity of the account data, the record data is deposited into the temporary block, and a confirmation can also be sent to the node that initiated the operation.

[0032] 2.3) Smart contract, a computerized protocol that can execute the terms of a certain contract, implemented by code deployed on a shared ledger for execution when certain conditions are met. According to actual business requirements, the code is used to complete automated transactions, such as querying the logistics status of the goods purchased by the buyer and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts for processing received information.

[0033] 3) Blockchain, including a series of blocks (Block) that are sequentially connected in the order of generation. Once a new block is added to the blockchain, it will not be removed again. The block records the record data submitted by nodes in the blockchain system.

[0034] See Figure 2 , Figure 2 is an optional schematic diagram of the block structure provided by an embodiment of the present invention. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through hash values to form a blockchain. In addition, the block may also include information such as the timestamp when the block is generated. Blockchain, essentially a decentralized database, is a string of data blocks generated by using cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0035] In one embodiment, as Figure 3 shown, a method for querying the transaction status in a blockchain is provided. Taking the example that this method is applied to the node cluster in the Figure 1 blockchain system, the method includes the following steps:

[0036] Step 302, receive a transaction status query request carried by the client and initiated by the client.

[0037] Among them, the client, also known as the user terminal, refers to a program that provides local services corresponding to the server. Except for some applications that only run locally, it is generally installed on ordinary client machines and needs to cooperate with the server to run. For example, the client in this application may include different user terminals.

[0038] The transaction identifier is used to identify a unique transaction task. A transaction task refers to a transaction task generated by the client. In some cases, the transaction task in this application can also be referred to as a transaction. The transaction tasks generated by the client can include different types of transaction tasks. For example, the transaction tasks generated by the client include, but are not limited to, transaction tasks for installing (deploying) contracts, transaction tasks for business transfers, etc.

[0039] The transaction status query request refers to a request used to query the status of a transaction task. For example, the transaction (transaction task) status in this application includes but is not limited to: pending packaging status, in consensus status, on-chain status, transaction expiration cleared status, double-spending cleared status, and malicious transaction cleared status, etc.

[0040] Step 304, query the first transaction status that matches the transaction identifier in the abnormal transaction queue.

[0041] Among them, the abnormal transaction queue refers to a structure used to store abnormal transactions. For example, the abnormal transaction queue in this application can be a pre-constructed circular queue. It can be understood that in addition to storing abnormal transactions, the abnormal transaction queue in this application can also store the transaction status corresponding to the abnormal transactions. For example, when a node in the node cluster detects that a transaction has expired, the expired transaction and the transaction status will be stored in the failedTxs circular queue.

[0042] The first transaction status refers to a specific status of a transaction task. For example, the first transaction status in this application can be an abnormal status, and the abnormal status can include at least one of the expired transaction cleared status, double-spending cleared status, or malicious transaction cleared status.

[0043] Specifically, after a newly created blockchain is started, when the node cluster in the blockchain system receives a transaction status query request carrying a transaction identifier initiated by a client, the node cluster can verify the transaction status query request to obtain a corresponding verification result. For example, it can verify the permission of the user who sends the transaction status query request. When the verification result indicates that the verification is passed, each node in the node cluster can query whether there is a transaction task corresponding to the transaction identifier from the local transaction pool maintained by itself based on the transaction identifier carried in the transaction status query request, and determine the transaction status of the transaction task corresponding to the transaction identifier. That is, each node in the node cluster can call the transaction pool module and first query the first transaction status that matches the transaction identifier carried in the transaction status query request from the abnormal transaction queue maintained by itself through the transaction pool module.

[0044] For example, take node A in the node cluster of the blockchain system as an example for illustration. As Figure 4 shown, it is a schematic diagram of transaction status query based on RPC, and the transaction status can include such as Figure 4For the 6 states shown, different clients (user terminals) can initiate a request to query the transaction status from the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request carrying transaction identifier A initiated by client A through RPC, node A can call the transaction pool module and, through the transaction pool module, first query whether there is a transaction task A corresponding to the transaction identifier A in the FailedTxs circular queue as shown in Figure 4 to check whether the transaction task A corresponding to the transaction identifier A is an abnormal transaction. Suppose node A queries through the transaction pool module and finds that there is a transaction task A corresponding to the transaction identifier A in the FailedTxs circular queue as shown in Figure 4 then node A can further obtain the status of the transaction task A corresponding to the transaction identifier A from the FailedTxs circular queue as shown in Figure 4 as the expired transaction clearing status, that is, the transaction task A corresponding to the transaction identifier A is an expired transaction that has been cleared.

[0045] In addition, in some cases, when node A in the node cluster receives a transaction status query request carrying transaction identifier A initiated by client A through RPC, node A can determine whether the transaction task A corresponding to the transaction identifier A has been chained (stored in the database) in other nodes of the blockchain through communication with other nodes in the blockchain. If the transaction task A corresponding to the transaction identifier A has not been chained (not stored in the database) in other nodes of the blockchain, then node A can first query whether there is a transaction task A corresponding to the transaction identifier A in the FailedTxs circular queue as shown in Figure 4 If the transaction task A corresponding to the transaction identifier A has been chained (stored in the database) in other nodes of the blockchain, then node A can first query whether there is a transaction task A corresponding to the transaction identifier A in the database as shown in Figure 4 Here, a transaction being chained means that after block consensus is completed, when each node submits the block to be stored in the database, it will store each transaction contained in the block in the database and delete these transactions from the transaction pool. At this time, the transaction status is the chained status.

[0046] Step 306: When the first transaction status is not queried, query the second transaction status that matches the transaction identifier from the transaction set. The transaction set is used to store the transaction tasks to be packaged and the corresponding transaction statuses, or is used to store the transaction tasks in the consensus process and the corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory.

[0047] Among them, the transaction set refers to the set contained in the transaction pool for storing transaction tasks. The transaction set can be different types of transaction sets in the transaction pool. For example, the transaction set in this application can include a first transaction set and a second transaction set. The first transaction set can be a Queue. This Queue set is used to store the transaction tasks to be packaged. That is, when the transaction pool module receives a transaction and verifies that the transaction is valid, the transaction pool module will cache the transaction into the Queue. At this time, the transactions in the Queue are waiting to be packaged and chained, and the status of the transactions in the Queue at this time is waiting to be packaged. The second transaction set can be Pending. This Pending set is used to store the transaction tasks in consensus. For example, when the core module of the primary node grabs a batch of transactions from the transaction pool to construct a block, the transaction pool (module) will move this batch of transactions from the Queue to Pending. The transactions moved into Pending indicate that these transactions are in the process of consensus.

[0048] The second transaction status refers to a certain specific status of the transaction task. For example, the second transaction status in this application can be at least one of the status of waiting to be packaged or the status in consensus.

[0049] The transaction set and the abnormal transaction queue running in memory means that: the transaction set and the abnormal transaction queue run in the memory area storing the transaction pool, that is, it can be understood that: the transaction pool can include the transaction set and the abnormal transaction queue.

[0050] Specifically, after the node cluster queries the first transaction status that matches the transaction identifier carried in the transaction status query request from the abnormal transaction queue maintained by itself, when the first transaction status is not queried, the node cluster can further query the second transaction status that matches the transaction identifier from the transaction set. For example, when the first transaction status is not queried, the node cluster can further query the second transaction status that matches the transaction identifier from the Queue set or the Pending set. Among them, the Queue set is used to store the transaction tasks to be packaged and the corresponding transaction status, and the Pending set is used to store the transaction tasks in consensus and the corresponding transaction status; the Queue set, the Pending set, and the abnormal transaction queue all run in memory.

[0051] For example, take node A in the node cluster of the blockchain system as an example for illustration. As Figure 4 shown, it is a schematic diagram of querying the transaction status based on RPC. The transaction status can include Figure 4Among the 6 states shown, different clients (user terminals) can initiate a request to query the transaction status to the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request carrying transaction identifier A initiated by client A through RPC, node A can first query in the FailedTxs circular queue as shown in Figure 4 whether there is a transaction task A corresponding to the transaction identifier A, that is, to check whether the transaction task A corresponding to the transaction identifier A belongs to an abnormal transaction.

[0052] When node A does not query that there is a transaction task A corresponding to the transaction identifier A in the FailedTxs circular queue as shown in Figure 4 that is, when node A does not query an abnormal status matching the transaction identifier A in the abnormal transaction queue, node A can further query the to-be-packaged status matching the transaction identifier A from the Queue set as shown in Figure 4 After not querying the to-be-packaged status, node A can further query the in-consensus status matching the transaction identifier A from the Pending set as shown in Figure 4 After querying the in-consensus status, node A can return the status of the transaction task A corresponding to the transaction identifier A as the in-consensus status to client A. Among them, the in-consensus status means that when the core module of the primary node grabs a batch of transactions from the transaction pool to construct a block, the transaction pool will move this batch of transactions from the Queue to the Pending, and the transactions moved into the Pending indicate that these transactions are in the process of consensus.

[0053] Step 308, when the second transaction status is not queried, query the third transaction status representing the on-chain status from the database, and after querying the third transaction status, return the third transaction status to the client.

[0054] Among them, the third transaction status refers to a certain specific status of the transaction task. For example, the third transaction status in this application can be the status representing on-chain at the local node, that is, the on-chain status.

[0055] Specifically, after the node cluster queries the second transaction status that matches the transaction identifier carried in the transaction status query request from the transaction set it maintains, when the second transaction status is not queried, the node cluster can further query the third transaction status indicating that the transaction has been chained on the local node from the database, and after querying the third transaction status, return the third transaction status to the client. That is, in the case where the transaction task A corresponding to the transaction identifier carried in the transaction status query request has not been chained on other nodes of the blockchain (not stored in the database), the node cluster can first query whether there is a transaction status that matches the transaction identifier from the memory of the storage transaction pool. If the transaction status that matches the transaction identifier is not queried from the memory area of the storage transaction pool, the node cluster then queries the transaction status indicating that the transaction has been chained on the local node from the database.

[0056] For example, taking node A in the node cluster of the blockchain system as an example for illustration. As Figure 4 shown, it is a schematic diagram of the transaction status query based on RPC. The transaction status can include the 6 states as Figure 4 shown. Different clients (user terminals) can initiate a request to query the transaction status to the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request carried with transaction identifier A initiated by client A through RPC, node A can first query whether there is a transaction task A corresponding to the transaction identifier A in the FailedTxs circular queue as Figure 4 shown, that is, check whether the transaction task A corresponding to the transaction identifier A belongs to an abnormal transaction.

[0057] When node A does not query that there is a transaction task A corresponding to the transaction identifier A in the FailedTxs circular queue as Figure 4 shown, that is, when node A does not query an abnormal status that matches the transaction identifier A in the abnormal transaction queue, node A can further query the to-be-packaged status that matches the transaction identifier A from the Queue set as Figure 4 shown. After not querying the to-be-packaged status, node A can further query the in-consensus status that matches the transaction identifier A from the Pending set as Figure 4 shown. After not querying the in-consensus status, node A can query the chained status indicating that the transaction has been chained on the local node from the database, and after querying the third transaction status, that is, the chained status, return the status of the transaction task A corresponding to the transaction identifier A as the chained status to client A.

[0058] In this embodiment, by receiving a transaction status query request carrying a transaction identifier initiated by a client and querying for a first transaction status that matches the transaction identifier in the abnormal transaction queue; when the first transaction status is not queried, query for a second transaction status that matches the transaction identifier from the transaction set, where the transaction set is used to store transaction tasks to be packaged and their corresponding transaction statuses, or is used to store transaction tasks in consensus and their corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; when the second transaction status is not queried, query for a third transaction status indicating that the transaction has been chained on the local node from the database, and after the third transaction status is queried, return the third transaction status to the client. Since different types of abnormal transaction tasks are stored in the abnormal transaction queue, when receiving a transaction status query request carrying a transaction identifier initiated by a client, it is possible to first query for a first transaction status (i.e., the abnormal status) that matches the transaction identifier in the abnormal transaction queue; when the first transaction status is not queried, then query for a second transaction status that matches the transaction identifier from the transaction set, and when the second transaction status is not queried, finally query for a third transaction status indicating that the transaction has been chained on the local node from the database, enabling the client (user) to query the transaction status of all transactions, follow the entire life cycle transfer process of a transaction, effectively improving the query efficiency of transaction statuses in the blockchain while also improving the processing performance of the entire blockchain, and taking different business-side operations according to different stages of the transaction, providing more convenient operations for users.

[0059] In one embodiment, the abnormal transaction queue is an abnormal transaction circular queue; before receiving a transaction status query request carrying a transaction identifier initiated by a client, the method further includes:

[0060] Construct an abnormal transaction circular queue based on an array of a preset length; the initial index value of the abnormal transaction circular queue is a first value;

[0061] When an abnormal transaction task is detected, determine a target index value based on the first value, a preset value, and the preset length;

[0062] Based on the target index value, store the abnormal transaction task in the abnormal transaction circular queue.

[0063] Among them, the abnormal transaction circular queue refers to a structure for storing abnormal transactions that is a circular queue structure. For example, as Figure 5 shown, it is a schematic diagram of the structure of a circular queue, Figure 5 where head represents the head pointer in Figure 5 The abnormal transaction circular queue in this application can be the circular queue structure shown in

[0064] An array with a preset length refers to an array with a fixed length set in advance. For example, the preset length in this application can be len = 12.

[0065] The initial index value refers to the index value for initializing the head pointer (head). For example, the initial index value index = -1 in this application can also be expressed as head = -1.

[0066] The preset value refers to a specific preset value. For example, the preset value in this application can be 1.

[0067] The target index value refers to the index value of the head pointer (head) calculated based on a preset function or strategy. For example, the calculation method of the target index value in this application can be shown as the following formula (1):

[0068] Index1=(index + 1) % len (1)

[0069] Among them, Index1 represents the target index value, index represents the initial index value, which can be -1, len is the length of the array, and % represents the modulo operation.

[0070] Specifically, after a newly created blockchain is started, before the node cluster in the blockchain system receives a transaction status query request carrying a transaction identifier initiated by the client, the node cluster can construct an abnormal transaction circular queue as shown in Figure 5 and initialize the initial index value of the head pointer of the abnormal transaction circular queue as shown in Figure 5 to index = -1; further, when each node in the node cluster detects an abnormal transaction task, each node in the node cluster can determine the target index value Index1 of the head pointer based on index = -1, the preset value 1, and the preset length len, that is, each node in the node cluster can calculate the target index value Index1 of the head pointer in the manner shown in the above formula (1), and deposit the abnormal transaction task into the abnormal transaction circular queue as shown in Figure 5 based on the target index value Index1.

[0071] For example, take node A in the node cluster of the blockchain system as an example for illustration. Before node A in the node cluster receives a transaction status query request carrying transaction identifier A initiated by client A through RPC, assuming the preset length of the array len = 12, node A can construct an abnormal transaction circular queue as shown in Figure 5 and initialize it as shown in Figure 5The initial index value of the head pointer of the abnormal transaction circular queue shown is index = -1; further, when node A detects abnormal transaction task A, node A can determine the target index value Index1 of the head pointer based on index = -1, a preset value of 1, and a preset length len = 12, that is, node A can calculate the target index value Index1 of the head pointer in the manner shown in the above formula (1), Index1 = (index + 1) % len = (-1 + 1) % 12 = 0, and based on the target index value Index1 = 0 of the head pointer, deposit abnormal transaction task A into Figure 5 the "0 array position" in the abnormal transaction circular queue corresponding to the head pointer shown in. This enables, by constructing an abnormal transaction caching mechanism based on a circular queue, the transaction pool to quantitatively cache transactions that are cleared due to expiration, double-spending of transactions, or deletion due to malicious behavior such as random function types. It can cache these abnormal transactions while occupying a fixed amount of memory, ensuring that users can perceive these abnormal transactions, and further enabling users to query the transaction status of all transactions, be able to follow the entire life cycle transfer process of a transaction, and effectively improve the query efficiency of transaction status in the blockchain.

[0072] In one embodiment, the step of depositing an abnormal transaction task into the abnormal transaction circular queue based on the target index value includes:

[0073] Search for the storage location corresponding to the target index value in the abnormal transaction circular queue;

[0074] When the storage location is empty, clear the transaction task at the storage location and deposit the abnormal transaction task into the storage location after clearing the transaction task;

[0075] When the storage location is not empty, deposit the abnormal transaction task into the storage location.

[0076] Among them, the storage location corresponding to the target index value refers to the array storage location corresponding to the index value of the head pointer (head). For example, as Figure 5 shown, the storage location corresponding to the index value of the head pointer (head) is: the storage location of array 0.

[0077] Specifically, take node A in the node cluster of the blockchain system as an example for illustration. Before node A in the node cluster receives a transaction status query request carrying transaction identifier A initiated by client A through RPC, as Figure 6 shown, it is a schematic flow diagram of adding abnormal transactions and transaction status to the circular queue. Assuming the preset length of the array is len = 12, node A can construct an abnormal transaction circular queue as Figure 5 shown based on the array with a preset length of len = 12 and initialize asFigure 5 The initial index value of the head pointer of the abnormal transaction circular queue shown is index = -1; further, as Figure 6 shown in the process, node A can determine the target index value Index1 of the head pointer based on index = -1, a preset value of 1, and a preset length len = 12, that is, node A can calculate the target index value Index1 of the head pointer in the manner shown in the above formula (1), Index1=(index + 1) % len = (-1 + 1) % 12 = 0. When node A detects the abnormal transaction task A, node A can, based on the target index value Index1 = 0 of the head pointer, find the storage location corresponding to the target index value Index1 = 0 of the head pointer in the abnormal transaction circular queue as shown in Figure 5 : array 0. Further, node A can determine whether the storage location corresponding to the index value Index1 = 0 of the head pointer, that is, in array 0, is empty. When this storage location, that is, array 0, is empty, it means that data has been stored in this array 0. Node A can clear the transaction task already stored in this storage location, that is, array 0, and store the newly added abnormal transaction task A in this storage location, that is, array 0, after clearing the transaction task; or,

[0078] when this storage location, that is, array 0, is not empty, it means that no data has been stored in this array 0. Node A can directly store the newly added abnormal transaction task A in this storage location, that is, array 0, of the abnormal transaction circular queue as shown in Figure 5 : array 0.

[0079] In this embodiment, by constructing an abnormal transaction caching mechanism based on a circular queue, the transaction pool can quantitatively cache transactions whose expiration has been cleared, double-spending transactions have been cleared, and malicious transactions such as those of the random function type have been deleted. It can cache these abnormal transactions while occupying a fixed amount of memory, ensuring that users can perceive these abnormal transactions, and thus enabling users to query the transaction status of all transactions, and be able to follow the entire life cycle transfer process of a transaction, effectively improving the query efficiency of transaction status in the blockchain.

[0080] In one embodiment, the abnormal transaction queue includes an abnormal transaction circular queue; the step of querying the first transaction status matching the transaction identifier in the abnormal transaction queue includes:

[0081] Querying the first transaction status matching the transaction identifier in the abnormal transaction circular queue, where the first transaction status includes at least one of an expired transaction clearing status, a double-spending transaction clearing status, or a malicious transaction clearing status.

[0082] Among them, the expired transaction clearing status refers to the status where the transaction task has expired and been cleared. There are two sources for this type of transaction status. On the one hand, when the main node constructs a block and fetches transactions from the transaction pool, the transaction pool will check whether the transaction has expired. If the transaction has expired, the transaction pool will move the transaction and the transaction status into the failedTxs circular queue as shown in Figure 4 ; on the other hand, when the node restarts, the node will reload the transactions saved during shutdown (dump). At this time, the node will also check whether the transaction has expired. If the transaction has expired, the node will also deposit the transaction and the transaction status into the failedTxs circular queue as shown in Figure 4 .

[0083] The double-spending transaction clearing status refers to: when the main node fetches transactions and when the secondary node obtains transactions from the transaction pool, the transaction pool will perform anti-duplication checks on the transactions. When it is found that the transaction has already been stored in the database, the transaction pool will also deposit the transaction and the transaction status into the failedTxs circular queue as shown in Figure 4 . Among them, double spending means double payment. A transaction cannot be executed twice. Double-spending verification requires three aspects of verification:

[0084] (1) The transaction task is not on the chain, that is, it does not exist in the database;

[0085] (2) The transaction task is not in the transaction pool, that is, it is not in the transaction pool of this node;

[0086] (3) Anti-duplication of transaction tasks among the blocks being consensus, that is, verifying that the transaction tasks in the verified block are not in other blocks that are being consensus but have not yet been stored in the database;

[0087] That is, when each node in the node cluster verifies the validity of the transaction task, it also needs to verify whether the transaction task is double-spending, that is, verify whether the transaction task is in other blocks that are in the consensus state but have not yet been stored in the database. For example, when each node in the node cluster performs anti-duplication checks on the transaction task, it can compare the transaction task with the transaction tasks in the pre-consensus blocks of the same branch of the new block to obtain a comparison result; when the comparison result indicates that there is a duplicate transaction task, the verification result of the double-spending verification is not passed; when the comparison result indicates that there is no duplicate transaction task, the verification result of the double-spending verification is passed.

[0088] The malicious transaction clearing status refers to the status where malicious transactions such as random function types have been cleared. For example, when executing a transaction task, it is found that there is a random function operation in the contract of the transaction task, which will cause the execution results of each node to be inconsistent, and ultimately the execution result of the transaction task will not reach an agreement. At this time, after one round of consensus, the transaction containing the random function operation will be regarded as a random function type transaction and cleared. When clearing, the transaction and the transaction status will also be deposited into asFigure 4 in the failedTxs circular queue shown in

[0089] Specifically, take node A in the node cluster of the blockchain system as an example for illustration. As Figure 4 shown, it is a schematic diagram of querying the transaction status based on RPC. The transaction status can include Figure 4 the 6 states shown in Figure 4 Different clients (user terminals) can initiate a request to query the transaction status to the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request carrying transaction identifier A initiated by client A through RPC, node A can call the transaction pool module and first query whether there is a transaction task A corresponding to the transaction identifier A in the Figure 4 FailedTxs circular queue shown in Figure 4 that is, check whether the transaction task A corresponding to the transaction identifier A is an abnormal transaction. Assume that node A queries through the transaction pool module and finds that there is a transaction task A corresponding to the transaction identifier A in the Figure 4 FailedTxs circular queue shown in Figure 4 then node A can further obtain the status of the transaction task A corresponding to the transaction identifier A from the

[0090] FailedTxs circular queue shown in Figure 4 When the transaction task A corresponding to the transaction identifier A is stored in the Figure 4In the database shown in , it is queried whether there is a transaction task A corresponding to the transaction identifier A. Therefore, by constructing an abnormal transaction caching mechanism based on a ring queue, the transaction pool can quantitatively cache transactions that have been cleared due to expiration, double-spending transactions, and random function types that have been deleted for malicious purposes, and can cache these abnormal transactions while occupying a fixed amount of memory to ensure that users can perceive these abnormal transactions, thereby enabling users to query the transaction status of all transactions, and can follow the entire life cycle of a transaction, effectively improving the query efficiency of the transaction status in the blockchain.

[0091] In one embodiment, the transaction set includes a first transaction set; a second transaction status matching the transaction identifier is queried from the transaction set, and the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or to store transaction tasks in consensus and corresponding transaction statuses, including:

[0092] Querying the to-be-packaged status that matches the transaction identifier from the first transaction set; wherein the first transaction set is used to store the to-be-packaged transaction tasks and the corresponding to-be-packaged status;

[0093] The method further includes: after the to-be-packaged state is queried, returning the to-be-packaged state to the client.

[0094] Among them, the first transaction set refers to the set contained in the transaction pool for storing transaction tasks. For example, the first transaction set in the present application can be a Queue. The Queue is used to store transaction tasks to be packaged. That is, when the transaction pool module receives the transaction and verifies that the transaction is valid, the transaction pool module will cache the transaction in the Queue. At this time, the transactions in the Queue are waiting to be packaged and put on the chain. At this time, the status of the transactions in the Queue is waiting for packaging.

[0095] Specifically, take node A in the node cluster of the blockchain system as an example. Figure 4 As shown in FIG. 1 , a schematic diagram of a transaction status query based on RPC is shown. The transaction status may include: Figure 4 In the 6 states shown in the figure, different clients (user terminals) can initiate a request to query the transaction status to the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request with transaction identifier A initiated by client A through RPC, node A can query the transaction status through the transaction pool module. Figure 4 Whether there is a transaction task A corresponding to the transaction identifier A in the FailedTxs circular queue shown in , that is, checking whether the transaction task A corresponding to the transaction identifier A is an abnormal transaction.

[0096] When node A does not find Figure 4When there is a transaction task A corresponding to the transaction identifier A in the FailedTxs ring queue shown in , that is, when node A does not find an abnormal state matching the transaction identifier A in the abnormal transaction queue, node A can further Figure 4 The queue collection shown in the figure queries the pending packaging status that matches the transaction identifier A. After querying the pending packaging status, node A can return the status of transaction task A corresponding to the transaction identifier A as the pending packaging status to client A. As a result, by constructing an abnormal transaction query mechanism based on RPC, an abnormal transaction query module is added to the node, so that users can query all transaction statuses, follow the entire life cycle of a transaction, and take different business-end operations for different stages, providing users with more convenient operations.

[0097] In one embodiment, the transaction set includes a second transaction set; a second transaction status matching the transaction identifier is queried from the transaction set, and the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or to store transaction tasks in consensus and corresponding transaction statuses, including:

[0098] After the to-be-packaged state is not found, the consensus state matching the transaction identifier is searched from the second transaction set; wherein the second transaction set is used to store the transaction tasks in consensus and the corresponding consensus state;

[0099] The method further includes: after querying the consensus state, returning the consensus state to the client.

[0100] Among them, the second transaction set refers to the set for storing transaction tasks contained in the transaction pool. For example, the second transaction set in the present application can be Pending. The Pending set is used to store transaction tasks that are in consensus. For example, when the core module of the master node grabs a batch of transactions from the transaction pool for constructing a block, the transaction pool (module) will move this batch of transactions from the Queue to Pending. Transactions moved into Pending indicate that these transactions are in consensus.

[0101] Specifically, take node A in the node cluster of the blockchain system as an example. Figure 4 As shown in FIG. 1 , a schematic diagram of a transaction status query based on RPC is shown. The transaction status may include: Figure 4 In the 6 states shown in the figure, different clients (user terminals) can initiate a request to query the transaction status to the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request with transaction identifier A initiated by client A through RPC, node A can query the transaction status through the transaction pool module. Figure 4Whether there is a trading task A corresponding to the trading identifier A in the FailedTxs circular queue shown in the figure, that is, to check whether the trading task A corresponding to the trading identifier A belongs to an abnormal transaction.

[0102] When node A fails to query that there is a trading task A corresponding to the trading identifier A in the FailedTxs circular queue as shown in Figure 4 When there is a trading task A corresponding to the trading identifier A in the FailedTxs circular queue as shown in the figure, that is, when node A fails to query an abnormal status matching the trading identifier A in the abnormal transaction queue, node A can further query the to-be-packaged status matching the trading identifier A from the Queue set as shown in Figure 4 In the figure. After failing to query the to-be-packaged status, node A can further query the in-consensus status matching the trading identifier A from the Pending set as shown in Figure 4 In the figure. After querying the in-consensus status, node A can return the status of the trading task A corresponding to the trading identifier A as the in-consensus status to client A.

[0103] In addition, in some cases, when node A fails to query that there is a trading task A corresponding to the trading identifier A in the FailedTxs circular queue as shown in Figure 4 When there is a trading task A corresponding to the trading identifier A in the FailedTxs circular queue as shown in the figure, that is, when node A fails to query an abnormal status matching the trading identifier A in the abnormal transaction queue, node A can also further query the in-consensus status matching the trading identifier A from the Pending set as shown in Figure 4 In the figure. After failing to query the in-consensus status, node A can further query the to-be-packaged status matching the trading identifier A from the Queue set as shown in Figure 4 In the figure.

[0104] In this embodiment, by constructing an RPC-based abnormal transaction query mechanism and adding an abnormal transaction query module in the node, users can query all transaction statuses, follow the full life cycle transfer process of a transaction, and take different business-side operations for different stages, providing more convenient operations for users.

[0105] In one embodiment, the method further includes:

[0106] Determine the expired trading tasks in the trading cleanup tree maintained by itself;

[0107] Grab a preset number of target trading tasks from the first trading set;

[0108] Generate a proposal message for the to-be-consensus block based on the expired trading tasks and the target trading tasks; the proposal message carries the identification information of the expired trading tasks, so that other nodes can conduct consensus on the to-be-consensus block and perform data cleanup based on the identification information after reaching consensus.

[0109] Among them, the transaction cleanup tree refers to a structure for storing the identification information of expired transaction tasks that need to be cleaned up. For example, the transaction cleanup tree in this application can be a prefix tree structure, and a prefix tree is a multi-way tree structure.

[0110] An expired transaction task refers to a transaction task that meets a preset expiration time. In some cases, the transaction tasks in this application can also be referred to as transactions, and expired transaction tasks are called expired transactions. For example, a user can set an expiration time (either an absolute time or a relative time) for each transaction task. When the expiration time arrives, the transaction task becomes an expired transaction task. For example, if the expiration time T set for transaction task A is 13:30 on July 16, 2023, then when this time T arrives, for example, if the current time is 13:31 on July 16, 2023, then transaction task A is an expired transaction task.

[0111] The preset quantity refers to the number of transaction tasks to be encapsulated in a new block. For example, the preset quantity can be 100.

[0112] The target transaction task refers to the transaction task selected by the master node from the transaction pool. For example, the target transaction task in this application can be the transaction task selected by the master node from the queue set of the transaction pool in the order of decreasing processing priority corresponding to the contracts of the transaction tasks.

[0113] The identification information refers to the identification information corresponding to the expired transaction task. The identification information corresponding to the expired transaction task in this application can include at least two types of identification information. For example, the identification information corresponding to the expired transaction task in this application can include an expired transaction identification set and an expired transaction hash value.

[0114] Specifically, taking node A in the node cluster of the blockchain system as an example. For instance, after node A determines itself as the primary node, the primary node generates a block. Node A can obtain the expired transaction tasks from the transaction cleanup tree it maintains and grab a preset number of target transaction tasks from the queue set in the local transaction pool. Node A can generate a proposal message 1 for the block to be consensus Block (100) based on the expired transaction tasks and the target transaction tasks, and broadcast the proposal message 1 to other nodes in the blockchain. The proposal message 1 carries the identification information of the expired transaction tasks, so that other nodes can conduct consensus on the block to be consensus Block (100) based on the target transaction tasks in the proposal message 1, and perform data cleanup based on the identification information of the expired transaction tasks after reaching consensus. Since the proposal message of the block to be consensus is generated based on the expired transaction tasks and the target transaction tasks, after the block to be consensus reaches consensus, data cleanup can be automatically performed based on the identification information of the expired transaction tasks carried in the proposal message. The entire data cleanup process is consensus-based and will be written in the blockchain, enabling the data cleanup process to be completed while conducting consensus, with high security and traceability. At the same time, the data cleanup level in the blockchain can be controlled to the transaction level, so that even if different services share the same chain, it is still okay, achieving the technical effect of effectively improving the performance of the entire blockchain while ensuring the security of the entire blockchain.

[0115] In one embodiment, the step of determining the expired transaction tasks in the transaction cleanup tree maintained by itself includes:

[0116] When constructing the block to be consensus, obtain the first time;

[0117] Based on the first time, determine the expired transaction tasks in the transaction cleanup tree maintained by itself.

[0118] Wherein, the first time refers to the block generation time, which can also be called the proposal time. For example, when the primary node constructs a new block, the primary node can obtain the timestamp of the current moment as t1, and t1 is the first time.

[0119] Specifically, under the blockchain underlying model based on BFT consensus, after a certain node (Node A) in the node cluster determines itself as the primary node, the primary node generates a block and initiates the current round of consensus, that is, the primary node is responsible for generating a proposal for the block to be consensus. When the primary node (Node A) constructs a new block (the block to be consensus), the primary node (Node A) can obtain the timestamp at the current moment as t1: 12-01-01:01, and based on t1, search for expired transaction tasks that match this time t1 in the transaction cleaning tree maintained by itself. That is, the primary node can search in the transaction cleaning tree maintained by itself for the identification information of the transaction tasks to be cleaned up to this time t1, which at least includes: Tx(1) and Tx(n). This enables the determination of the expired transaction tasks to be cleaned according to the proposal time, and can achieve the control of the blockchain data cleaning level to the transaction level. In this way, even if different services share the same chain, it is no problem, effectively improving the accuracy of data cleaning.

[0120] In one embodiment, the step of querying the first transaction status that matches the transaction identifier in the abnormal transaction queue includes:

[0121] When the target transaction task corresponding to the transaction identifier has not been chained on other nodes of the blockchain, query the first transaction status that matches the transaction identifier in the abnormal transaction queue;

[0122] The method further includes: when the target transaction task corresponding to the transaction identifier has been chained on other nodes of the blockchain, query the third transaction status indicating that it has been chained from the database based on the transaction identifier;

[0123] After querying the third transaction status, return the third transaction status to the client.

[0124] Wherein, other nodes refer to the nodes in the node cluster of the blockchain system except the local node. For example, if the local node is Node A, then other nodes refer to the nodes in the node cluster of the blockchain system except Node A.

[0125] Specifically, taking Node A in the node cluster of the blockchain system as an example for illustration. As Figure 4 shown, it is a schematic diagram of querying the transaction status based on RPC. The transaction status can include, for example, Figure 4For the 6 states shown, different clients (user terminals) can initiate a request to query the transaction status to the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request carrying transaction identifier A initiated by client A through RPC, node A can, through communication with other nodes in the blockchain, determine whether the transaction task A corresponding to the transaction identifier A has been uploaded to the blockchain (has been stored in the database). If the transaction task A corresponding to the transaction identifier A has not been uploaded to other nodes in the blockchain (has not been stored in the database), then node A can first query whether there is a transaction task A corresponding to the transaction identifier A in the FailedTxs circular queue as shown in Figure 4 ; if the transaction task A corresponding to the transaction identifier A has been uploaded to other nodes in the blockchain (has been stored in the database), then node A can first query whether there is a transaction task A corresponding to the transaction identifier A in the database as shown in Figure 4 . That is, when the transaction task A corresponding to the transaction identifier A has been uploaded to other nodes in the blockchain, node A can directly query the transaction status indicating that it has been uploaded from the database as shown in Figure 4 , and after querying the transaction status indicating that it has been uploaded, node A returns the status of the transaction task A corresponding to the transaction identifier A as the uploaded status to client A. Thus, by constructing an exception transaction query mechanism based on RPC and adding an exception transaction query module in the node, users can query all transaction statuses, follow the entire life cycle transfer process of a transaction, and take different business-side operations for different stages, providing more convenient operations for users.

[0126] In one embodiment, after querying the third transaction status indicating that it has been uploaded from the database based on the transaction identifier, the method further includes:

[0127] After not querying the third transaction status, query the first transaction status with a matching transaction identifier from the exception transaction queue;

[0128] When the first transaction status is queried, return the first transaction status to the client; wherein, the first transaction status includes at least one of an expired transaction clearance status, a double-spending transaction clearance status, or a malicious transaction clearance status.

[0129] Specifically, take node A in the node cluster of the blockchain system as an example for illustration. As shown in Figure 4 , it is a schematic diagram of transaction status query based on RPC, and the transaction status can include as shown in Figure 4Among the 6 states shown, different clients (user terminals) can initiate a request to query the transaction status to the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request carrying transaction identifier A initiated by client A through RPC, node A can determine whether the transaction task A corresponding to the transaction identifier A has been chained (stored in the database) in other nodes of the blockchain through communication with other nodes in the blockchain. If the transaction task A corresponding to the transaction identifier A has been chained in other nodes of the blockchain, then node A can preferentially query whether there is a transaction task A corresponding to the transaction identifier A in the database as shown in Figure 4 That is, when the transaction task A corresponding to the transaction identifier A has been chained in other nodes of the blockchain, node A can directly query the transaction status indicating chaining based on the transaction identifier A from the database as shown in Figure 4 After that, and if no transaction status indicating chaining is found, node A can further query the first transaction status matching the transaction task A corresponding to the transaction identifier A from the FailedTxs circular queue as shown in Figure 4 When the matching first transaction status is found, node A returns the status of the transaction task A corresponding to the transaction identifier A as the first transaction status to client A; wherein, the first transaction status includes at least one of an expired transaction clearing status, a double-spending transaction clearing status, or a malicious transaction clearing status. For example, node A can further query the first transaction status matching the transaction task A corresponding to the transaction identifier A from the FailedTxs circular queue as shown in Figure 4 If the first transaction status matching the transaction task A corresponding to the transaction identifier A is the double-spending transaction clearing status, then node A returns the status of the transaction task A corresponding to the transaction identifier A as the double-spending transaction clearing status to client A. Thus, by constructing an exception transaction query mechanism based on RPC and adding an exception transaction query module in the node, users can query all transaction statuses, follow the full life cycle process of a transaction, and take different business-side operations for different stages, providing more convenient operations for users.

[0130] In one embodiment, after querying the first transaction status matching the transaction identifier from the exception transaction queue, the method further includes:

[0131] When the first transaction status is not found, query the second transaction status matching the transaction identifier from the transaction set, where the transaction set is used to store the transaction tasks to be packaged and the corresponding transaction statuses, or is used to store the transaction tasks in consensus and the corresponding transaction statuses; the transaction set and the exception transaction queue run in memory.

[0132] Specifically, take node A in the node cluster of the blockchain system as an example for illustration. As Figure 4As shown, it is a schematic diagram of querying transaction status based on RPC. The transaction status can include, for example, Figure 4 the six states shown in Figure 4 . Different clients (user terminals) can initiate a request to query the transaction status to the nodes in the node cluster through RPC. For example, when node A in the node cluster receives a transaction status query request carried with transaction identifier A initiated by client A through RPC, node A can determine whether the transaction task A corresponding to the transaction identifier A has been uploaded to the chain (has been stored in the database) in other nodes of the blockchain through communication with other nodes in the blockchain. If the transaction task A corresponding to the transaction identifier A has been uploaded to the chain (has been stored in the database) in other nodes of the blockchain, then node A can preferentially query whether there is a transaction task A corresponding to the transaction identifier A in the database as shown in Figure 4 Figure 4 . That is, when the transaction task A corresponding to the transaction identifier A has been uploaded to the chain in other nodes of the blockchain, node A can directly query the transaction status indicating that it has been uploaded to the chain based on the transaction identifier A from the database as shown in Figure 4 Figure 4 . And after not querying the transaction status indicating that it has been uploaded to the chain, node A can further query the first transaction status matching the transaction task A corresponding to the transaction identifier A from the FailedTxs circular queue as shown in Figure 4 Figure 4 . When the first transaction status is not queried, node A can further query the second transaction status matching the transaction task A corresponding to the transaction identifier A from the transaction set in the transaction pool as shown in Figure 4 Figure 4 . For example, node A can further query the to-be-packed status matching the transaction identifier A from the queue set as shown in Figure 4 Figure 4 . After not querying the to-be-packed status, node A can further query the in-consensus status matching the transaction identifier A from the pending set as shown in Figure 4 Figure 4 . After querying the in-consensus status, node A can return the status of the transaction task A corresponding to the transaction identifier A as the in-consensus status to client A. Thus, by constructing an abnormal transaction query mechanism based on RPC and adding an abnormal transaction query module in the node, users can query all transaction statuses, follow the entire life cycle transfer process of a transaction, and take different business-side operations for different stages, providing more convenient operations for users.

[0133] In one embodiment, the present application further provides an application scenario, and this application scenario applies the method for querying transaction status in the above blockchain. Specifically, the application of the method for querying transaction status in the blockchain in this application scenario is as follows:

[0134] When a user wants to query the transaction status at different exchanges, the above-mentioned transaction status query method in the blockchain can be adopted. That is, in the blockchain system, each node in the node cluster can receive in real time a transaction status query request carrying a transaction identifier initiated by a client, and query the first transaction status matching the transaction identifier in the abnormal transaction queue; when the first transaction status is not queried, each node in the node cluster can query the second transaction status matching the transaction identifier from the transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; when the second transaction status is not queried, each node in the node cluster can query the third transaction status indicating that the transaction has been chained on the local node from the database, and after the third transaction status is queried, return the third transaction status to the client. Thus, through the optimized solution of abnormal transaction monitoring and state perceptibility in the transaction pool proposed in this application, first, the entire life cycle of the transaction is sorted out, the transaction is classified into 6 states, and it can be perceptible externally through the RPC service. Secondly, for abnormal transactions deleted by the underlying chain, such as double-spending transactions, transactions containing random function types, and expired transactions, quantitative caching is performed. Through the cache structure based on the circular queue, these abnormal transactions can be cached on the basis of occupying limited memory space, facilitating external query of the transaction status. Finally, a transaction status query service module is constructed in the blockchain node, and the status of the transaction can be directly queried through the RPC, enabling users to quickly and accurately follow the entire life cycle of the transaction operation. That is, the solution for querying the transaction status in the blockchain proposed in this application can effectively improve the query efficiency of the transaction status in the blockchain and at the same time improve the processing performance of the entire blockchain.

[0135] The method provided in the embodiments of this application can be applied to various blockchain scenarios. Taking the blockchain scenario of the blockchain underlying model based on the BFT consensus as an example, the transaction processing method in the blockchain provided in the embodiments of this application will be described below.

[0136] Among them, the primary node: a role of the consensus nodes in the blockchain. The consensus nodes are the key to maintaining the data consistency of the entire blockchain network. The main responsibility of the primary node is to package transactions to construct a block in a round of consensus and broadcast the block to other secondary nodes. Therefore, the primary node plays a key role in a round of consensus. If the primary node acts maliciously, packages invalid transactions, or the block structure is incorrect, no consensus will be reached on any block in this round of consensus.

[0137] Follower Node: A role of consensus nodes in the blockchain. Its main function is to verify the validity of a block after receiving it from the leader node and execute transactions. When the block is invalid or the transaction execution results are inconsistent, it will not vote for or vote against the block. When the block is valid after verification and the transaction execution results are consistent, it will vote for the block.

[0138] Consensus Engine: A module in the consensus node. This module mainly includes a consensus algorithm module and a peer-to-peer network module. The consensus algorithm module can include various specific consensus algorithms, including the fault-tolerant Raft consensus algorithm and Byzantine fault-tolerant PBFT, Tendermint, HotStuff, etc. Different consensus algorithms have different applicable scenarios. The peer-to-peer network module is responsible for broadcasting and receiving proposal and voting messages.

[0139] Core Engine Module: The core scheduling module in the consensus node. This module mainly plays a central scheduling role. When the consensus node is the leader node, the consensus engine module of the leader node will notify the core engine module to construct a block and execute transactions. Finally, the constructed block will be given to the consensus engine module. Subsequently, the consensus engine module will construct a proposal based on the block and broadcast the proposal to other follower nodes. After the follower nodes receive the proposal and verify its validity, they will let their own core engine module verify the validity of the block and execute the transactions. If the transaction execution results of the follower nodes are consistent with those of the leader node, the block is considered valid.

[0140] Transaction Pool Module: The role of the transaction pool module is to receive transactions sent by other consensus nodes and transactions directly sent by clients. In the transaction pool module, transactions sent by clients will be broadcast to other consensus nodes. The purpose of broadcasting transactions is to ensure the consistency of transactions among consensus nodes as much as possible, facilitating the quick verification of the validity of blocks and transactions in subsequent consensus processes.

[0141] Peer-to-Peer Network Module: Also known as peer-to-peer technology, peer-to-peer network communication refers to a communication technology that does not rely on a centralized server but relies on a user group (peers) to exchange information. Nodes in the blockchain include a peer-to-peer network module, and the main function of this module is to send and broadcast messages. In this application, transactions will be broadcast to other consensus nodes.

[0142] The transaction pool is a basic module in the blockchain system. The transaction pool is mainly responsible for receiving and verifying transactions sent by clients, broadcasting valid transactions to other nodes, and providing a batch of transactions for block construction when the core engine module constructs a block.

[0143] As Figure 7 shown, it is the interaction flow chart between the transaction pool and other modules. Figure 7The TxPool in it is the transaction pool, which can also be called the transaction pool module. In Figure 7 The transaction pool shown in

[0144] contains two sets for storing transaction tasks, namely: Queue and Pending. Among them, the transactions in Queue are transactions to be packaged, and the transactions in Pending are transactions that have been packaged and are in the consensus block. When the master node constructs a block, it grabs transactions from the Queue of the transaction pool for packaging, and at this time the transaction pool moves the transactions from Queue to Pending.

[0145] The slave node moves the transactions from Queue to Pending only after verifying that the block is valid. The purpose of moving them into Pending is to avoid duplicate packaging of transactions. After the block is finally submitted, the transaction pool needs to be notified to delete the transactions in the block. If these transactions are not deleted, it will eventually cause a memory overflow.

[0146] First, for the master node, when it needs to construct a block, the core module of the master node will grab a batch of transactions from the transaction pool for block construction, and at the same time move these transactions from Queue to Pending. Subsequently, the core module of the master node sends the constructed block to the slave node, and the slave node calls GetTxs to obtain these transactions from the transaction pool it maintains to restore the block. When the slave node verifies that the block is valid, it calls PendingTxs to move the transactions from Queue to Pending to prevent duplicate packaging. When a round of consensus is completed, the master node and the slave node will remove the transactions in the block that has reached consensus at this height from the transaction pool, and put the transactions in the side branches at the same height back into the transaction pool.

[0147] According to the normal operation logic, all transactions in the transaction pool will eventually be on the chain without any abnormal situations. However, in the actual operation process, there will be some abnormal transactions, and these abnormal transactions will be deleted by the transaction pool module or other modules. After these transactions are deleted, users (clients) cannot perceive it. These transactions are neither on the chain nor notified to users that they have been deleted, so it will cause the client not to know how to proceed with the next step.

[0148] In the traditional method, the query function of the transaction pool status is provided in Ethereum and Chang'an Chain, but it can only query how many transactions are in the transaction pool in total, which transactions' txIds are in Queue and Pending in total, or provide three types of query functions for transactions according to the transaction txId (transaction identifier). It is impossible to follow the entire life cycle of the transaction, nor can it query the abnormal transaction information cleared by the underlying chain, and it is easy to have situations where queries cannot be made or query failures occur, thus resulting in low query efficiency of the transaction status.

[0149] The disadvantages of the traditional technical solution include:

[0150] 1. Users cannot follow the entire life cycle process of the transaction and cannot perceive whether the transaction has been executed or is waiting to be packaged, which is not conducive to users to perform different processing for different transaction states;

[0151] 2. For the transactions cleared due to abnormalities, the transaction pool and the underlying chain directly clear them, and users cannot perceive the final state of the transaction. Users perceive that the transaction disappears out of thin air, making users not know how to handle the next step of the business logic.

[0152] Therefore, to solve the above problems, this application proposes an optimized solution for monitoring abnormal transactions and perceiving the status in the transaction pool to solve them. First, sort out the entire life cycle of the transaction, classify the transaction into 6 states, and make it externally perceivable through the RPC service. Secondly, quantitatively cache the abnormal transactions deleted by the underlying chain, such as double-spending transactions, transactions containing random function types, and expired transactions, and through a cache structure based on a circular queue, these abnormal transactions can be cached on the basis of occupying limited memory space, facilitating external query of the transaction status. Finally, a transaction status query service module is built in the blockchain node, and the status of the transaction can be directly queried through the RPC, enabling users to follow the entire life cycle of the transaction operation.

[0153] The innovations of the technical solution provided by this application include:

[0154] 1. Based on the entire life cycle of the transaction, sort out each state in the transaction operation, enabling users to clarify the current state of the transaction, including waiting to be packaged, being in consensus, having been on the chain, the transaction being cleared due to expiration, the transaction being cleared due to double spending, malicious transactions such as random function types, etc.

[0155] 2. Based on the abnormal transaction cache mechanism of the circular queue, the transaction pool can quantitatively cache the transactions cleared due to expiration, the transactions cleared due to double spending, and the maliciously deleted transactions such as random function types, etc. It can cache these abnormal transactions while occupying a fixed amount of memory, ensuring that users can perceive these abnormal transactions.

[0156] 3. The RPC-based abnormal transaction query mechanism adds an abnormal transaction query module in the node, enabling users to query all transaction statuses, follow the entire life cycle of a transaction, and perform different business-side operations at different stages, providing more convenient operations for users.

[0157] On the product side, the method provided in this application can be used as an optimized solution for monitoring abnormal transactions and perceiving status in the transaction pool, for appropriate publicity externally, and can be implemented at the code level according to the solution in this application to optimize the corresponding blockchain underlying code, which can be applied to the actual development of blockchain underlying software and can also be used as a publicity method externally.

[0158] On the technical side, the problems that can be solved and the functions of the technical solution provided in this application are as follows:

[0159] 1. A transaction status definition based on the entire life cycle of a transaction is constructed, enabling users to clearly understand the status of the current transaction, including waiting for packaging, in the consensus process, already on the chain, the transaction expired and cleared, the transaction double-spent and cleared, malicious transactions of the random function type, etc.

[0160] 2. An abnormal transaction caching mechanism based on a circular queue is constructed, enabling the transaction pool to quantitatively cache transactions that have expired and been cleared, double-spent and cleared, or deleted due to malicious behavior such as the random function type. It can cache these abnormal transactions while occupying a fixed amount of memory, ensuring that users can perceive these abnormal transactions.

[0161] 3. The RPC-based abnormal transaction query mechanism adds an abnormal transaction query module in the node, enabling users to query all transaction statuses, follow the entire life cycle of a transaction, and perform different business-side operations at different stages, providing more convenient operations for users.

[0162] Transaction status definition based on the entire life cycle of a transaction:

[0163] As Figure 8 shown, it is a transaction status definition diagram. As Figure 8 shown in

[0164] Waiting for packaging: When the transaction pool receives a transaction sent through RPC and verifies that the transaction is valid, the transaction pool caches the transaction in the Queue. At this time, the transaction is waiting to be packaged and put on the chain, and the status is waiting for packaging.

[0165] In consensus: When the core module of the master node fetches a batch of transactions from the transaction pool for block construction, the transaction pool will move this batch of transactions from the Queue to the Pending. The transactions moved to the Pending indicate that these transactions are in the consensus process;

[0166] On the chain: After the block consensus is completed and each node submits the block to the database, the transactions will be stored in the database at this time, and these transactions will be deleted from the transaction pool. At this time, the transaction status is on the chain;

[0167] Transactions expired and cleared: There are two sources for this transaction status. On the one hand, when the master node fetches transactions from the transaction pool during block construction, the transaction pool will check whether the transaction has expired. If the transaction has expired, the transaction and the transaction status will be moved into the failedTxs circular queue. On the other hand, when the node restarts, the node will reload the transactions stored during shutdown. At this time, the node will check whether the transaction has expired. If the transaction has expired, the transaction and the transaction status will be put into the failedTxs circular queue;

[0168] Double-spending transactions cleared: When the master node fetches transactions and when the slave node obtains transactions from the transaction pool, the transaction pool will perform a duplicate check on the transactions. When it is found that the transaction has been stored in the database, the transaction and the transaction status will be put into the failedTxs circular queue;

[0169] Malicious transactions such as random function types cleared: If during the execution of the transaction, it is found that there are random function operations in the contract, resulting in inconsistent execution results on each node and ultimately no consensus can be reached. At this time, after one round of consensus, this type of transaction will be regarded as a random function type transaction and then cleared. When clearing, the transaction and the transaction status will also be put into the failedTxs circular queue;

[0170] After the above classification, based on the full life cycle of the transaction, the transaction status is clearly defined, and users can perceive various transaction statuses.

[0171] Abnormal transaction caching mechanism based on circular queue:

[0172] There are various types of abnormal transactions in the blockchain system. The transaction pool needs to cache these transactions, and in order to avoid system memory overflow, quantitative caching is required. For example, only the latest 1000 abnormal transactions are cached.

[0173] To achieve quantitative caching, the solution provided in the embodiment of this application constructs a failedTxs structure based on a circular queue in the transaction pool to cache such abnormal transactions. The circular queue structure is as Figure 5 shown. Among them, the process of the node adding abnormal transactions and transaction statuses to the failedTxs circular queue is as Figure 6As shown in , the key point is that the array length of the circular queue is fixed. When the circular queue is full, the newly added abnormal transactions will be overwritten. In this way, the number of cached transactions will be limited, and only a fixed number of abnormal transactions will be cached.

[0174] Abnormal transaction query mechanism based on RPC:

[0175] In order to allow users to obtain transaction status more conveniently, this solution builds an abnormal transaction query mechanism based on RPC, such as Figure 4 As shown in the figure, the user initiates a request to query the transaction status to the node through RPC. After receiving the request, the node will call the transaction pool module. In order to consider performance, the transaction pool module will first query the FailedTxs ring queue to see if the transaction is an abnormal transaction; if it is not an abnormal transaction, it will query the Queue. If it is found, it indicates that the transaction is waiting to be packaged; if it is not found, the Pending structure will be queried. If it is found, it indicates that it is a transaction in consensus, and the result will be returned to the client; if it is not found, it will eventually query the database. If it can be found, it means that the transaction has been on the chain.

[0176] The beneficial effects of the technical solution of this application include:

[0177] 1. A transaction status definition based on the entire life cycle of the transaction has been constructed, which enables users to clearly understand the current status of the exchange, including waiting for packaging, consensus, already on the chain, transactions expired and cleared, double-spending transactions cleared, random function types and other malicious transactions.

[0178] 2. An abnormal transaction caching mechanism based on a ring queue is built, so that the transaction pool can quantitatively cache transactions that have expired and been cleared, double-spending transactions that have been cleared, random function types that have been deleted for malicious purposes, etc. These abnormal transactions can be cached while occupying a fixed amount of memory to ensure that users can perceive these abnormal transactions.

[0179] 3. An abnormal transaction query mechanism based on RPC has been built, and an abnormal transaction query module has been added to the node, so that users can query all transaction statuses, follow the entire life cycle of a transaction, and take different business-end operations for different stages, providing users with more convenient operations.

[0180] It should be understood that although the steps in the flowcharts involved in the above-described embodiments are sequentially shown as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless specifically stated herein, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, at least some of the steps in the flowcharts involved in the above-described embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in rotation with at least some of the steps or stages in other steps or other steps.

[0181] Based on the same inventive concept, an embodiment of the present application further provides a transaction status query device in a blockchain for implementing the transaction status query method in the blockchain involved above. The solution for solving the problem provided by this device is similar to the solution described in the above method. Therefore, the specific limitations in one or more embodiments of the transaction status query device in the blockchain provided below can refer to the limitations on the transaction status query method in the blockchain above, and will not be elaborated here.

[0182] In one embodiment, as Figure 9 shown, a transaction status query device in a blockchain is provided, including: a receiving module 902, a query module 904, and a returning module 906, where:

[0183] The receiving module 902 is configured to receive a transaction status query request carried by a client and initiated by the client.

[0184] The query module 904 is configured to query a first transaction status matching the transaction identifier in the abnormal transaction queue; when the first transaction status is not queried, query a second transaction status matching the transaction identifier from the transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory.

[0185] The returning module 906 is configured to, when the second transaction status is not queried, query a third transaction status indicating that the transaction has been chained on the local node from the database, and after querying the third transaction status, return the third transaction status to the client.

[0186] In one embodiment, the abnormal transaction queue is an abnormal transaction circular queue; the apparatus further includes: a construction module, a determination module, and a storage module. The construction module is configured to construct the abnormal transaction circular queue based on an array with a preset length; an initial index value of the abnormal transaction circular queue is a first value; the determination module is configured to determine a target index value based on the first value, a preset value, and the preset length when detecting an abnormal transaction task; the storage module is configured to store the abnormal transaction task into the abnormal transaction circular queue based on the target index value.

[0187] In one embodiment, the abnormal transaction queue is an abnormal transaction circular queue; the apparatus further includes: a search module and a clearing module. The search module is configured to search for a storage location corresponding to the target index value in the abnormal transaction circular queue; the clearing module is configured to clear a transaction task located at the storage location when the storage location is empty; the storage module is further configured to store the abnormal transaction task into the storage location after clearing the transaction task; when the storage location is not empty, store the abnormal transaction task into the storage location.

[0188] In one embodiment, the abnormal transaction queue includes an abnormal transaction circular queue; the query module is further configured to query a first transaction status matching the transaction identifier in the abnormal transaction circular queue, where the first transaction status includes at least one of an expired transaction clearing status, a double-spending transaction clearing status, or a malicious transaction clearing status.

[0189] In one embodiment, the transaction set includes a first transaction set; the query module is further configured to query a to-be-packaged status matching the transaction identifier from the first transaction set; where the first transaction set is used to store to-be-packaged transaction tasks and corresponding to-be-packaged statuses; the return module is further configured to return the to-be-packaged status to the client after querying the to-be-packaged status.

[0190] In one embodiment, the transaction set includes a second transaction set; the query module is further configured to query a consensus-in-progress status matching the transaction identifier from the second transaction set after not querying the to-be-packaged status; where the second transaction set is used to store transaction tasks in consensus and corresponding consensus-in-progress statuses; the return module is further configured to return the consensus-in-progress status to the client after querying the consensus-in-progress status.

[0191] In one embodiment, the device further includes: a determination module, a grasping module, and a generating module. The determination module is configured to determine the expired transaction tasks in the transaction cleaning tree maintained by itself; the grasping module is configured to grasp a preset number of target transaction tasks from the first transaction set; the generating module is configured to generate a proposal message for a block to be consensus-based on the expired transaction tasks and the target transaction tasks; the identification information of the expired transaction tasks is carried in the proposal message, so that other nodes perform consensus on the block to be consensus, and perform data cleaning based on the identification information after reaching consensus.

[0192] In one embodiment, the device further includes: an obtaining module, configured to obtain a first time when constructing the block to be consensus; the determination module is further configured to determine the expired transaction tasks in the transaction cleaning tree maintained by itself based on the first time.

[0193] In one embodiment, the query module is further configured to query a first transaction status matching the transaction identifier in the abnormal transaction queue when the target transaction task corresponding to the transaction identifier has not been chained on other nodes of the blockchain; when the target transaction task corresponding to the transaction identifier has been chained on other nodes of the blockchain, query a third transaction status indicating being chained from the database based on the transaction identifier; the return module is further configured to return the third transaction status to the client after querying the third transaction status.

[0194] In one embodiment, the query module is further configured to query the first transaction status matching the transaction identifier from the abnormal transaction queue after not querying the third transaction status; the return module is further configured to return the first transaction status to the client when the first transaction status is queried; wherein the first transaction status includes at least one of an expired transaction clearing status, a double-spending transaction clearing status, or a malicious transaction clearing status.

[0195] In one embodiment, the query module is further configured to query a second transaction status matching the transaction identifier from the transaction set when the first transaction status is not queried, where the transaction set is used to store the transaction tasks to be packaged and the corresponding transaction status, or is used to store the transaction tasks in consensus and the corresponding transaction status; the transaction set and the abnormal transaction queue run in the memory.

[0196] Each module in the above blockchain transaction status query device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor of the computer device in hardware form or be independent of it, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0197] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in Figure 10 shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O), and a communication interface. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store transaction status data in the blockchain. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals through a network connection. When the computer program is executed by the processor, it implements a method for querying transaction status in a blockchain.

[0198] Those skilled in the art can understand that Figure 10 the structure shown in is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0199] In one embodiment, a computer device is provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0200] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by the processor, the steps in the above method embodiments are implemented.

[0201] In one embodiment, a computer program product is provided, including a computer program. When the computer program is executed by the processor, the steps in the above method embodiments are implemented.

[0202] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions.

[0203] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logic devices, data processing logics based on quantum computing, etc., without limitation.

[0204] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0205] The above-described embodiments only represent several implementation manners of the present application. The description is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A method for querying transaction status in a blockchain, characterized in that, The method includes: Receiving a transaction status query request carrying a transaction identifier initiated by a client; Querying a first transaction status matching the transaction identifier in an abnormal transaction queue; When the first transaction status is not queried, querying a second transaction status matching the transaction identifier from a transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; When the second transaction status is not queried, querying a third transaction status indicating that the transaction has been chained on the local node from a database, and after querying the third transaction status, returning the third transaction status to the client.

2. The method according to claim 1, wherein The abnormal transaction queue is an abnormal transaction circular queue; before receiving the transaction status query request carrying the transaction identifier initiated by the client, the method further includes: Constructing the abnormal transaction circular queue based on an array of a preset length; the initial index value of the abnormal transaction circular queue is a first value; When an abnormal transaction task is detected, determining a target index value based on the first value, a preset value, and the preset length; Based on the target index value, storing the abnormal transaction task into the abnormal transaction circular queue.

3. The method according to claim 2, wherein The storing the abnormal transaction task into the abnormal transaction circular queue based on the target index value includes: Searching for a storage location corresponding to the target index value in the abnormal transaction circular queue; When the storage location is empty, clearing the transaction task at the storage location and storing the abnormal transaction task into the storage location after clearing the transaction task; When the storage location is not empty, storing the abnormal transaction task into the storage location.

4. The method according to claim 1, characterized in that, The abnormal transaction queue includes an abnormal transaction circular queue; The querying the first transaction status matching the transaction identifier in the abnormal transaction queue includes: Querying the first transaction status matching the transaction identifier in the abnormal transaction circular queue, where the first transaction status includes at least one of an expired transaction clearing status, a double-spending transaction clearing status, or a malicious transaction clearing status.

5. The method according to claim 1, characterized in that, The transaction set includes a first transaction set; the querying the second transaction status matching the transaction identifier from the transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses, includes: Querying a to-be-packaged status matching the transaction identifier from the first transaction set; where the first transaction set is used to store transaction tasks to be packaged and corresponding to-be-packaged statuses; The method further includes: after querying the to-be-packaged status, returning the to-be-packaged status to the client.

6. The method according to claim 1 or 5, characterized in that, The transaction set includes a second transaction set; the querying the second transaction status matching the transaction identifier from the transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses, includes: After failing to query the to-be-packed status, query the in-consensus status that matches the transaction identifier from the second transaction set; wherein, the second transaction set is used to store transaction tasks in consensus and the corresponding in-consensus statuses. The method further includes: after querying the in-consensus status, return the in-consensus status to the client.

7. The method according to claim 5, wherein The method further includes: Determine the expired transaction tasks in the transaction cleaning tree maintained by itself. Fetch a preset number of target transaction tasks from the first transaction set. Generate a proposal message for the to-be-consensus block based on the expired transaction tasks and the target transaction tasks; the proposal message carries the identification information of the expired transaction tasks, so that other nodes can conduct consensus on the to-be-consensus block and perform data cleaning based on the identification information after reaching consensus.

8. The method according to claim 7, wherein The determining the expired transaction tasks in the transaction cleaning tree maintained by itself includes: When constructing the to-be-consensus block, obtain a first time. Based on the first time, determine the expired transaction tasks in the transaction cleaning tree maintained by itself.

9. The method according to claim 1, characterized in that The querying the first transaction status that matches the transaction identifier in the abnormal transaction queue includes: When the target transaction task corresponding to the transaction identifier has not been chained on other nodes of the blockchain, query the first transaction status that matches the transaction identifier in the abnormal transaction queue. The method further includes: when the target transaction task corresponding to the transaction identifier has been chained on other nodes of the blockchain, query the third transaction status indicating being chained from the database based on the transaction identifier. After querying the third transaction status, return the third transaction status to the client.

10. The method according to claim 9, characterized in that After the querying the third transaction status indicating being chained from the database based on the transaction identifier, the method further includes: After failing to query the third transaction status, query the first transaction status that matches the transaction identifier from the abnormal transaction queue. When the first transaction status is queried, return the first transaction status to the client; wherein, the first transaction status includes at least one of an expired transaction clearing status, a double-spending transaction clearing status, or a malicious transaction clearing status.

11. The method according to claim 10, characterized in that, After the querying the first transaction status that matches the transaction identifier from the abnormal transaction queue, the method further includes: When the first transaction status is not queried, query the second transaction status that matches the transaction identifier from the transaction set, where the transaction set is used to store to-be-packed transaction tasks and the corresponding transaction statuses, or is used to store transaction tasks in consensus and the corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory.

12. A transaction status query device in a blockchain, characterized in that, The device includes: A receiving module, configured to receive a transaction status query request carrying a transaction identifier initiated by a client. A query module, configured to query a first transaction status that matches the transaction identifier in the abnormal transaction queue; when the first transaction status is not queried, query a second transaction status that matches the transaction identifier from a transaction set, where the transaction set is used to store transaction tasks to be packaged and corresponding transaction statuses, or is used to store transaction tasks in consensus and corresponding transaction statuses; the transaction set and the abnormal transaction queue run in memory; A return module, configured to query a third transaction status indicating that the transaction has been chained on the local node from a database when the second transaction status is not queried, and return the third transaction status to the client after the third transaction status is queried.

13. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

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

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

Images