Block chain transaction processing method and device, computer equipment and storage medium

Abstract

The invention discloses a block chain transaction processing method and device, computer equipment and a storage medium. The method comprises the following steps: in response to a cleaning instruction of a first transaction set, determining a to-be-cleaned target block from the first transaction set; wherein the first transaction set is a transaction set corresponding to a to-be-packaged queue in a transaction pool corresponding to the node; respectively obtaining transactions from the target blocks; and when the current time meets the expiration time of the transaction, deleting the corresponding expired transaction from the first transaction set, and when the current time does not meet the expiration time of the transaction, adding the non-expired transaction into a second transaction set of the transaction pool until the transaction in the target block is processed. According to the embodiment of the invention, the operation efficiency of the block chain system can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, apparatus, computer device, storage medium and computer program product for processing blockchain transactions. Background Art

[0002] With the development of blockchain technology, more and more business systems are beginning to use blockchain technology. Due to the characteristics of decentralization, transparency and traceability, blockchain provides security for transactions in the blockchain. After the transaction is generated by the client, it generally goes through the stages of transaction broadcast, transaction verification, transaction packaging, block consensus, block broadcast, and blockchain update.

[0003] In the related art, before the block consensus is performed, a specified number of transactions are first obtained from the general queue of the transaction pool, stored in the queue to be packaged, and these transactions are packaged into a block, and then the block is proposed for consensus. In the related art, the transaction pool is often in a saturated state, which affects the overall operating efficiency of the blockchain system. Summary of the invention

[0004] Based on this, it is necessary to provide a method, device, computer equipment, computer-readable storage medium and computer program product for processing blockchain transactions that can improve system operation efficiency in response to the above-mentioned technical problems.

[0005] In a first aspect, the present application provides a method for processing blockchain transactions. The method comprises:

[0006] In response to a cleaning instruction of a first transaction set, determining a target block to be cleaned from the first transaction set; wherein the first transaction set is a transaction set corresponding to a queue to be packaged in a transaction pool corresponding to the node;

[0007] Respectively obtain transactions from the target block;

[0008] When the current time meets the expiration time of the transaction, the corresponding expired transaction is deleted from the first transaction set; when the current time does not meet the expiration time of the transaction, the non-expired transaction is added to the second transaction set of the transaction pool until the transactions in the target block are processed, thereby obtaining an updated second transaction set; wherein the second intersection set is the transaction set corresponding to the ordinary queue in the transaction pool; and the updated second transaction set is used to provide a preset number of transactions to the queue to be packaged when the block is packaged, so as to generate a new block.

[0009] In a second aspect, the present application also provides a blockchain transaction processing device. The device includes:

[0010] A target block determination module, configured to determine a target block to be cleaned from the first transaction set in response to a cleaning instruction of the first transaction set; wherein the first transaction set is a transaction set corresponding to a queue to be packaged in a transaction pool corresponding to the node;

[0011] A transaction acquisition module, used to acquire transactions from the target block respectively;

[0012] The first transaction processing module is used to delete the corresponding expired transaction from the first transaction set when the current time meets the expiration time of the transaction, and add the non-expired transaction to the second transaction set of the transaction pool when the current time does not meet the expiration time of the transaction, until the transactions in the target block are processed, and an updated second transaction set is obtained; wherein the second intersection set is the transaction set corresponding to the ordinary queue in the transaction pool; the updated second transaction set is used to provide a preset number of transactions to the queue to be packaged when the block is packaged, so as to generate a new block.

[0013] In one embodiment, the target block determination module is further configured to:

[0014] Obtaining the consensus identifier currently stored by the consensus component, and obtaining the consensus identifier of each block from the first transaction set; wherein the consensus identifier includes block height information and consensus round information; the consensus component is used to update the consensus identifier based on the consensus status of the block in the blockchain node;

[0015] The target block to be cleaned is determined to be a block in each block that is inconsistent with at least one information of the stored consensus identifier.

[0016] In one embodiment, the target block determination module is further configured to:

[0017] Receive blocks sent by other nodes in the blockchain;

[0018] Obtaining the node height and consensus round from the proposal information of the block;

[0019] A consensus identifier is obtained based on the node height and the consensus round, and the consensus identifier is added to the corresponding block.

[0020] In one embodiment, the device further comprises:

[0021] A master node confirmation module, configured to obtain a consensus identifier currently stored in a consensus component in response to the node being confirmed as a master node, and to obtain a consensus identifier of each block from the first transaction set;

[0022] The cleaning instruction generation module is used to generate a cleaning instruction for the first transaction set when there is at least one information in the consensus identifier of each block that is inconsistent with the stored consensus identifier.

[0023] In one embodiment, the target block determination module is further configured to:

[0024] Get the block, and set the corresponding first timer for the block;

[0025] Adding the block to which the first timer has been added to the first transaction set; wherein the block includes the block proposed by the node and the blocks proposed by other nodes;

[0026] In response to a first timer triggering instruction, it is determined that the target block to be cleaned is the block corresponding to the first timer.

[0027] In one embodiment, the target block determination module is further configured to:

[0028] In response to a first timer trigger instruction, obtaining a block corresponding to the first timer;

[0029] Obtain the consensus identifier corresponding to the block and the consensus identifier currently stored by the consensus component;

[0030] When the consensus identifier corresponding to the block is inconsistent with at least one information of the stored consensus identifier, it is determined that the target block to be cleaned is the block corresponding to the first timer.

[0031] In one embodiment, the blockchain transaction processing device further includes:

[0032] A first transaction receiving module, configured to receive a transaction and set a second timer for the received transaction; wherein the transaction includes a transaction sent by a client and / or a transaction broadcasted by other nodes;

[0033] A queue status acquisition module, configured to acquire the queue status of the received transaction in the transaction pool in response to a trigger instruction of the second timer; wherein the queue status includes a queue to be packaged and a common queue;

[0034] The first transaction cleaning module is used to delete the received transaction from the second transaction set in the transaction pool to obtain an updated second transaction set when the queue state is a common queue and the current time meets the expiration time of the received transaction.

[0035] In one embodiment, the transaction receiving module is further used to:

[0036] Receive transactions and the total amount of transactions in the transaction pool;

[0037] When the total transaction amount does not reach the capacity threshold of the transaction pool, a second timer is set for the received transaction.

[0038] In one embodiment, the blockchain transaction processing device further includes:

[0039] The second transaction processing module is used to reset the trigger time or time interval of the second timer when the queue state is a queue to be packaged.

[0040] In one embodiment, the blockchain transaction processing device further includes:

[0041] A second transaction receiving module, configured to receive a transaction and determine a sender of the received transaction; wherein the sender includes a client and / or other nodes;

[0042] A transaction identification acquisition module, used to acquire the transaction identification of the received transaction when the sender is a blockchain node;

[0043] The third transaction processing module is used to discard the transaction when the received transaction identifier is found in the filter preset in the memory.

[0044] In one embodiment, the third transaction processing module is further configured to:

[0045] If the received transaction identifier is not found in the filter preset in the memory, obtaining the total transaction amount in the transaction pool;

[0046] When the total transaction amount does not reach the capacity threshold, the received transaction is added to the second transaction set of the transaction pool to obtain an updated second transaction set.

[0047] In one embodiment, the third transaction processing module is further configured to:

[0048] When the total transaction amount reaches the capacity threshold, the transaction identifier of the received transaction is added to the filter; wherein the filter includes a data structure of a key-value pair, wherein the key in the key-value pair corresponds to the stored transaction identifier.

[0049] In one embodiment, the transaction processing module is further configured to:

[0050] Obtaining a transaction from the updated second transaction set;

[0051] When the current time meets the expiration time of the transaction, deleting the corresponding expired transaction from the second transaction set;

[0052] When the current time does not meet the expiration time of the transaction, the corresponding transaction is added to the first transaction set until the number of added transactions reaches a preset number, thereby obtaining an updated first transaction set.

[0053] In a third aspect, the present application further provides a computer device, wherein the computer device comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method described in any one of the embodiments of the present disclosure is implemented.

[0054] In a fourth aspect, the present application further provides a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the method described in any one of the embodiments of the present disclosure is implemented.

[0055] In a fifth aspect, the present application further provides a computer program product, wherein the computer program product comprises a computer program, and when the computer program is executed by a processor, the method described in any one of the embodiments of the present disclosure is implemented.

[0056] The above-mentioned blockchain transaction processing method, device, computer equipment, storage medium and computer program product, in the above-mentioned blockchain transaction processing method, after receiving the cleaning instruction, by determining the target block to be cleaned in the first transaction set, the block that has existed in the first transaction set for a long time is used as the target block. The expiration time of the transaction in the target block is judged, and the expired transactions in the waiting group are deleted in time, so as to release the storage space in the transaction pool in time, and provide the possibility for the addition of new transactions. Since the packaging of blocks depends on a certain number of unexpired transactions, if there is no timely addition of new transactions, the transactions in the ordinary queue may not be packaged because of expiration. Therefore, the embodiment of the present disclosure facilitates the rapid generation of new blocks by adding new transactions in time, thereby improving the overall operation efficiency of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 This is an application environment diagram of a method for processing blockchain transactions in one embodiment;

[0058] Figure 2 A schematic diagram of the structure of a block in an embodiment;

[0059] Figure 3 A schematic diagram of a block generation process in one embodiment;

[0060] Figure 4 A flowchart of a method for processing blockchain transactions in one embodiment;

[0061] Figure 5 A flowchart of a method for processing blockchain transactions in one embodiment;

[0062] Figure 6 A flowchart of a method for processing blockchain transactions in one embodiment;

[0063] Figure 7 A schematic diagram of the connection between the queue to be packaged and the ordinary queue in a transaction pool in one embodiment;

[0064] Figure 8 A flowchart of a method for processing blockchain transactions in one embodiment;

[0065] Fig. 9 A flowchart of a method for processing blockchain transactions in one embodiment;

[0066] Fig.10 A flowchart of a method for processing blockchain transactions in one embodiment;

[0067] Fig.11 A schematic diagram of filter transaction deduplication in one embodiment;

[0068] Fig.12 A flowchart of a method for processing blockchain transactions in one embodiment;

[0069] Fig.13 It is a structural block diagram of a processing device for blockchain transactions in one embodiment;

[0070] Fig.14 is an internal structure diagram of a computer device in one embodiment;

[0071] Fig.15 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0072] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with 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.

[0073] In order to facilitate those skilled in the art to understand the technical solution provided by the embodiments of the present disclosure, the technical environment in which the technical solution is implemented is described below.

[0074] In the blockchain system, the transaction pool is a commonly used component. The main functions of the transaction pool include receiving transactions sent by the client, and then adding the transactions to the memory, waiting for consensus. When a block is in consensus, first obtain a specified number of transactions from the transaction pool, package these specified number of transactions into a block, and then reach consensus on the block. On the one hand, if the consensus is successfully completed, the transactions corresponding to the block will be deleted; on the other hand, if the consensus fails, the transactions corresponding to the block may be returned to the transaction pool. From the analysis of the above process, it can be seen that the main function of the transaction pool is to temporarily store transactions. Correspondingly, the transaction pool has a capacity limit, otherwise the transaction pool will occupy a large amount of system memory, making the entire program unavailable.

[0075] If there are many transactions in a blockchain system and the client frequently sends transactions, the transactions in the transaction pool will quickly fill up the transaction pool. When the transaction pool reaches the capacity threshold, for the sake of system security, the transaction pool generally does not accept other transactions. At this time, the client's transaction may not be packaged into a block. Correspondingly, the node where the transaction pool is located does not have a consensus on the block that should have been successfully agreed upon for some reason, and the transactions in the corresponding block will not be cleaned. In other words, these transactions will continue to remain in the transaction pool, causing the number of transactions in the transaction pool to remain at the capacity threshold. As a result, there may be no new transactions added, resulting in not enough transactions to generate new blocks when the node is packaging the block, thus affecting the overall performance. In addition, when new transactions are received and duplicate checking is performed on new transactions, it is easy to penetrate the underlying database layer, resulting in reduced system performance.

[0076] Based on the actual technical requirements similar to those described above, this application provides a method, device, computer equipment, storage medium and computer program product for processing blockchain transactions. This application can automatically clean up transactions in the transaction pool, so that when nodes are packaged, there will not be too few transactions due to expired transactions occupying the transaction pool. Combined with the filter model, it will not cause query penetration when checking for duplicate transactions, thereby improving the overall performance of the system.

[0077] See also Figure 1The blockchain system shown, the blockchain system 100 refers to a system for sharing data between nodes, and the blockchain system may include multiple nodes 101, and the multiple nodes 101 may refer to each client or server in the data sharing system. Each node 101 can receive transactions during normal operation, and maintain the shared data in the blockchain system based on the received transactions. In order to ensure the information exchange within the blockchain system, there may be a data connection between each node in the blockchain system, and the nodes can transmit data through the above data connection. For example, when any node in the blockchain system receives a block, other nodes in the blockchain system obtain the block according to the consensus algorithm, and store the block as data in the blockchain, so that the data stored on all nodes in the data sharing system are consistent.

[0078] Each node in the blockchain system has a corresponding node identifier, and each node in the data sharing system can store the node identifiers of other nodes in the blockchain system, so that the generated blocks can be broadcast to other nodes in the blockchain system according to the node identifiers of other nodes. Each node can maintain a node identifier list as shown in the following table, and store the node name and node identifier in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. Table 1 only uses the IP address as an example for illustration.

[0079] Node Name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0080] Each node in the blockchain system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 2 The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores transaction feature values, version numbers, timestamps, and difficulty values, and the block body stores transactions. The next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the transaction feature values ​​of the current block, the block header feature values, version numbers, timestamps, and difficulty values ​​of the parent block, and so on. This ensures that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of transactions in the block.

[0081] When generating each block in the blockchain, see Figure 3When a node in the blockchain receives a transaction, it verifies the transaction. After verification, it stores the transaction in the memory pool and updates the hash tree used to record the transaction. After that, it updates the update timestamp to the time when the transaction is received, tries different random numbers, and calculates the eigenvalues ​​multiple times so that the calculated eigenvalues ​​can satisfy the following formula:

[0082] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the transaction; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0083] In this way, when the random number that satisfies the above formula is calculated, the transaction can be stored accordingly, the block header and block body can be generated, and the current block can be obtained. Subsequently, the node where the blockchain is located sends the newly generated block to other nodes in the blockchain system according to the node identification of other nodes in the blockchain system. Other nodes verify the newly generated block and add the newly generated block to the blockchain stored in them after completing the verification.

[0084] In one embodiment, Figure 4 As shown, a method for processing blockchain transactions is provided, and the method is applied to Figure 1 Taking node 101 in the example as an example, the following steps are included:

[0085] Step S401, in response to a cleaning instruction of a first transaction set, determining a target block to be cleaned from the first transaction set; wherein the first transaction set is a transaction set corresponding to a queue to be packaged in a transaction pool corresponding to the node.

[0086] Among them, the transaction pool is used to store transactions, occupying part of the memory space of the blockchain node. The transaction pool includes a pending queue and a normal queue. Among them, a queue is a data structure that manages the elements in the queue according to the first-in-first-out principle. In the embodiment of the present disclosure, a transaction newly added to the queue can be added to the end of the queue, and a transaction can be removed from the queue starting from the head of the queue. It can be understood that the blockchain system includes multiple nodes, each of which has a corresponding transaction pool.

[0087] The transaction is created by the participants, and the transaction may include information such as the sender, the receiver, and the transaction amount. In the disclosed embodiment, there is no restriction on the application scenario of the transaction, such as transactions in the financial field, transactions in the supply chain field, transactions in the Internet of Things field, transactions in the medical field, etc.

[0088] In the disclosed embodiment, the first transaction set is a transaction set corresponding to the queue to be packaged in the transaction pool, and the second transaction set is a transaction set corresponding to the ordinary queue in the transaction pool. Specifically, when a node receives a transaction sent by a client or a transaction sent by other nodes in the blockchain, it can verify the transaction and continue to broadcast the transaction to other nodes. In an exemplary embodiment, if the verification fails, the above transaction is discarded. In another exemplary embodiment, if the verification passes, the total amount of transactions in the transaction pool is obtained. In an exemplary embodiment, if the total amount of transactions reaches the capacity threshold, the above transaction is discarded. In another exemplary embodiment, if the total amount of transactions does not reach the capacity threshold, the transaction is added to the second transaction set of the transaction pool.

[0089] In one embodiment, when a node is confirmed as a master node, a preset number of transactions are obtained from the second transaction set. For example, starting from the earliest transaction entered in the second transaction set, a preset number of transactions are obtained in sequence. Specifically, a transaction is obtained from the second transaction set, and the expiration time of the transaction is judged. For example, if the current time meets the expiration time of the transaction, the transaction is discarded. For another example, if the current time does not meet the expiration time of the transaction, the transaction is added to the first transaction set until the number of transactions added to the first transaction set reaches a preset number, and a batch of transactions is obtained. This batch of transactions is used to package and generate blocks. In another embodiment, the node receives blocks to be agreed upon sent by other nodes in the blockchain, and adds the blocks to be agreed upon to the first transaction set.

[0090] It is understandable that the first transaction set may include transactions corresponding to blocks generated by the node where the first transaction set is located, and may also include transactions in blocks to be consensus received from other nodes. Among them, the target blocks to be cleaned may include blocks that have existed in the first transaction set for a long time. For example, consensus has not been reached and continues to exist in the first transaction set. For another example, consensus has not been completed and continues to exist in the first transaction set. Among them, the reasons for the incomplete consensus may include multiple aspects, such as network reasons, transaction priority, insufficient transaction fees, etc.

[0091] Step S403, respectively obtaining transactions from the target block.

[0092] In an exemplary embodiment, the memory addresses of each transaction in the target block can be obtained respectively, and based on the memory addresses, the transactions in the memory unit corresponding to the memory addresses can be obtained. In another exemplary embodiment, the corresponding transaction can be first searched from the cache based on the identifier of the transaction in the target block, and if the corresponding transaction does not exist in the cache, the transaction can be obtained from the memory unit. In a specific implementation, each time a transaction is obtained from the target block, the expiration time of the transaction can be verified.

[0093] Step S405, when the current time meets the expiration time of the transaction, delete the corresponding expired transaction from the first transaction set; when the current time does not meet the expiration time of the transaction, add the non-expired transaction to the second transaction set of the transaction pool until the transactions in the target block are processed, and obtain an updated second transaction set; wherein the second intersection set is the transaction set corresponding to the ordinary queue in the transaction pool; the updated second transaction set is used to provide a preset number of transactions to the queue to be packaged when proposing a block to generate a new block.

[0094] The expiration time of the transaction may include the time set by the sender of the transaction in the transaction. The current time may include the current system time of the node. The current time meeting the expiration time of the transaction may include the current time reaching the expiration time or the current time being later than the expiration time. For example, if the transaction expiration time is 10:15:20 am on August 12, 2023, and the current system time is 10:16:12 am on August 12, 2023, then the transaction corresponding to the above expiration time is considered an expired transaction.

[0095] In an exemplary embodiment, when the current time meets the expiration time of the transaction, the corresponding expired transaction is deleted from the first transaction set. In another exemplary embodiment, when the current time does not meet the expiration time of the transaction, the unexpired transaction is added to the second transaction set of the transaction pool. In the process of adding the unexpired transaction to the transaction pool, one-by-one or collective addition can be adopted. For the one-by-one addition method, for example: if transaction A in the target block is not expired, transaction A is added to the second transaction set; if transaction B in the target block is not expired, transaction B is added to the second transaction set; if transaction C in the target block is not expired, transaction C is added to the second transaction set, and so on, until all the unexpired transactions in the target block are added, and an updated second transaction set is obtained. For the collective addition method, for example: by comparing the current time with the expiration time corresponding to each transaction, it is obtained that transaction A, transaction B and transaction C are not expired, then transaction A, transaction B and transaction C are added to the second transaction set together to obtain an updated second transaction set. In the disclosed embodiment, there is no restriction on the position of adding to the common queue corresponding to the second transaction set. For example, the transaction can be added to the head of the common queue or the tail of the common queue. It is understandable that when a transaction is added to the head of the common queue, the transaction can be obtained first when the transaction is packaged.

[0096] In the disclosed embodiment, the updated second transaction set is used to provide a preset number of transactions to the queue to be packaged when the block proposal is packaged. Specifically, for example, when an instruction to package a block is received, a preset number of transactions are obtained from the updated second transaction set. The expiration time of the transaction is judged. For example, if the current time meets the expiration time of the transaction, the transaction is discarded. For another example, if the current time does not meet the expiration time of the transaction, the transaction is added to the first transaction set until the number of transactions added to the first transaction set reaches a preset number, and a new batch of transactions is obtained. The new batch of transactions is packaged to generate a new block. The new block is sent to other nodes in the blockchain to enter the consensus process.

[0097] In the above-mentioned blockchain transaction processing method, after receiving the cleaning instruction, by determining the target block to be cleaned in the first transaction set, the block that has existed in the first transaction set for a long time is used as the target block. The expiration time of the transaction in the target block is judged, and the expired transactions in the waiting group are deleted in time, so as to release the storage space in the transaction pool in time and provide the possibility for the addition of new transactions. Since the packaging of blocks depends on a certain number of unexpired transactions, if there is no timely addition of new transactions, the transactions in the ordinary queue may not be packaged due to expiration. Therefore, the embodiment of the present disclosure facilitates the rapid generation of new blocks by timely adding new transactions, thereby improving the overall operation efficiency of the system.

[0098] In one embodiment, determining a target block to be cleaned from the first transaction set includes:

[0099] Obtaining the consensus identifier currently stored by the consensus component, and obtaining the consensus identifier of each block from the first transaction set; wherein the consensus identifier includes block height information and consensus round information; the consensus component is used to update the consensus identifier based on the consensus status of the block in the blockchain node;

[0100] The target block to be cleaned is determined to be a block in each block that is inconsistent with at least one information of the stored consensus identifier.

[0101] Among them, the consensus component is used to maintain the blocks packaged by the node and the blocks received by the node, and the consensus component stores the consensus identifier of the block currently being consensused. Specifically, based on the consensus algorithm, each node may need multiple rounds in the consensus process, wherein the consensus round information and block height information can reflect the current consensus status of each node, wherein the block height includes the position of the block in the blockchain. Generally speaking, the block height is calculated from the genesis block, and the block height increases every time a new block is added to the blockchain. Different blockchain systems have different ways of expressing the block height, for example, a self-increasing integer can be used to represent the block height, or a hash value can be used to represent the block height. There may be many rounds under the same block height, so in an exemplary embodiment, the block currently being consensused can be determined by obtaining the consensus identifier in the consensus component. The embodiment of the present disclosure does not limit the consensus algorithm, for example, Byzantine Fault Tolerance (BFT algorithm), distributed consistency algorithm (Raft algorithm), etc. can be used.

[0102] In a specific implementation, each block in the queue to be packaged corresponds to a consensus identifier. In an exemplary embodiment, for the consensus identifier of each block, the block height information in the consensus identifier can be compared with the block height information in the consensus identifier stored in the consensus component. If the block height information in the consensus identifier of the block is inconsistent with the block height information stored in the consensus component, the block can be used as a target block to be cleaned. Optionally, in another exemplary embodiment, if the block height information in the consensus identifier of the block is consistent with the block height information stored in the consensus component, the consensus round information in the consensus identifier of the block can be compared with the consensus round information stored in the consensus component. If the consensus round information in the block is inconsistent with the consensus round information stored in the consensus component, the block can be used as a target block to be cleaned.

[0103] The above-mentioned blockchain transaction processing method compares the consensus identifiers of each block with the consensus identifiers stored in the consensus component. When at least one of the information in the consensus identifiers of the two is inconsistent, the block that is different from the consensus block in the current blockchain is determined as the target block to be cleaned. Through the above-mentioned method, blocks that have existed in the first transaction set for a long time due to various reasons can be effectively characterized, so as to clean such blocks, add new transactions in time, improve the efficiency of transaction packaging, and improve the overall operation efficiency of the system.

[0104] In one embodiment, the obtaining of the consensus identifier of the transaction further includes:

[0105] Receive blocks sent by other nodes in the blockchain.

[0106] The block height information and consensus round information are obtained from the proposal information of the block.

[0107] A consensus identifier is obtained based on the block height information and the consensus round information, and the consensus identifier is added to the corresponding block.

[0108] Among them, other nodes in the blockchain may include nodes other than the current node in the blockchain. For example, when other nodes serve as master nodes, the master node obtains and packages the transactions in the second transaction set in its transaction pool, generates a block, broadcasts the proposal of the new block to the nodes in the blockchain, and enters the block consensus link. Among them, the proposal information may include information related to the block, such as the block header, transaction set, difficulty target, proposer identification information, etc. In an exemplary embodiment, after the node receives the block sent by other nodes and the corresponding proposal information, the block height information and consensus round information are parsed from the proposal information. Based on the block height information and consensus round information, it is added to the corresponding block. In an exemplary embodiment, the consensus identifier can be added to the additional data of the block. In another exemplary embodiment, the consensus identifier can also be added to the transactions of the preset number of bits in the block, for example, the consensus identifier is added to the first transaction in the block, or the consensus identifier is added to the third transaction in the block.

[0109] In the specific implementation process, for blocks in the queue to be processed, if the block is successfully agreed upon, the consensus component will delete the block from the queue to be processed, and the block will be stored in the database as a ledger. If the block is not successfully agreed upon or the consensus is not completed for a long time, the consensus component will reach a consensus on the new block and update the corresponding consensus identifier.

[0110] Through this embodiment, the block height information and the consensus round information are obtained from the proposal information of the block. Since the block height information and the consensus round information are already included in the proposal information of the block, this solution does not need to obtain additional information to represent the consensus identifier, thereby improving operability, saving system programs, and improving the operating efficiency of the system.

[0111] In one embodiment, in response to the cleaning instruction of the first transaction set, determining the target block to be cleaned from the first transaction set also includes:

[0112] In response to the node being confirmed as the master node, a consensus identifier currently stored in the consensus component is obtained, and a consensus identifier of each block is obtained from the first transaction set.

[0113] When the consensus identifier of each block is inconsistent with at least one information of the stored consensus identifier, a cleaning instruction for the first transaction set is generated.

[0114] Among them, the master node is a node with special permissions and functions in the blockchain system. The functions of the master node may be different in different blockchain systems. In an exemplary embodiment, the master node can be responsible for generating new blocks and adding them to the blockchain. At the same time, the master node also verifies the blocks generated by other nodes to ensure that they comply with the rules and consensus algorithm of the network. Optionally, the master node can participate in the operation of the consensus algorithm. In an exemplary embodiment, the master node can be generated by voting or random selection.

[0115] The consensus component stores the consensus identifier of the block currently being consensused. Specifically, based on the consensus algorithm, each node may need multiple rounds in the consensus process, where the consensus round information and block height information can reflect the current consensus status of each node, where there may be many rounds under the same block height. Therefore, in an exemplary embodiment, the block currently being consensused can be determined by obtaining the consensus identifier in the consensus component.

[0116] In a specific implementation, each block in the queue to be packaged corresponds to a consensus identifier. In an exemplary embodiment, for the consensus identifier of each block, the block height information in the consensus identifier can be compared with the block height information in the consensus identifier stored in the consensus component. If the block height information in the consensus identifier of the block is inconsistent with the block height information stored in the consensus component, it can be determined that there are target blocks to be cleaned in the first transaction set, and a cleaning instruction for the first transaction set is generated. Optionally, in another exemplary embodiment, if the block height information in the consensus identifier of the block is consistent with the block height information stored in the consensus component, the consensus round information in the consensus identifier of the block can be compared with the consensus round information stored in the consensus component. If the consensus round information in the block is inconsistent with the consensus round information stored in the consensus component, it can be determined that there are target blocks to be cleaned in the first transaction set, and a cleaning instruction for the first transaction set is generated.

[0117] In the above-mentioned blockchain transaction processing method, when a node is confirmed as a master node, before the master node is ready to package the transactions in the transaction pool into blocks, it will judge the transactions in the queue to be packaged to determine whether there is a target block that has been in the queue to be packaged for a long time without consensus. If there is a target block, the target block is cleaned. The space occupied by expired transactions in the queue to be packaged can be released in time.

[0118] In a specific embodiment, reference Figure 5As shown, based on the calculation method of the master node, when it is determined that this node is the master node, it is determined whether there is a target block to be cleaned in the first transaction set. Among them, the master node is a node with special permissions and functions in the blockchain system. In different block systems, the functions of the master node may be different. When it is determined that this node is not the master node, wait for blocks sent by other nodes. Among them, it can be determined whether there is a target block to be cleaned in the first transaction set in the following way. For example: obtain the consensus identifier currently stored by the consensus component, and obtain the consensus identifier of each block from the first transaction set. When there is at least one information inconsistency between the consensus identifier of each block and the stored consensus identifier, it is determined that there is a target block to be cleaned in the first transaction set.

[0119] Further, the target block is obtained, and transactions are obtained from the target block respectively. The memory addresses of each transaction in the target block can be obtained respectively, and based on the memory addresses, the transactions in the memory unit corresponding to the memory addresses are obtained. In another exemplary embodiment, the corresponding transaction can be first searched from the cache based on the identifier of the transaction in the target block, and then the transaction is obtained from the memory unit when the corresponding transaction does not exist in the cache. In a specific implementation, each time a transaction is obtained from the target block, the expiration time of the transaction can be verified. When the current time meets the expiration time of the transaction, the corresponding expired transaction is deleted from the first transaction set (pending queue to be packaged), and when the current time does not meet the expiration time of the transaction, the unexpired transaction is added to the second transaction set (ordinary queue queue) of the transaction pool until the transactions in the target block are processed and an updated second transaction set is obtained.

[0120] Further, a preset number of transactions are obtained from the second transaction set. For example, starting from the earliest transaction in the second transaction set, a preset number of transactions are obtained in sequence. Specifically, a transaction is obtained from the second transaction set, and the expiration time of the transaction is determined. For example, if the current time meets the expiration time of the transaction, the transaction is discarded. For another example, if the current time does not meet the expiration time of the transaction, the transaction is added to the first transaction set until the number of transactions added to the first transaction set reaches a preset number, thereby obtaining a batch of transactions. The batch of transactions is used to package and generate a new block.

[0121] Furthermore, in the consensus process, the blocks in the first transaction set are in a state of waiting for consensus or in the process of consensus. When a block is successfully reached by consensus, the block is deleted from the second transaction set.

[0122] In the above-mentioned method for processing blockchain transactions, when a node is confirmed as a master node, before the master node is ready to package the transactions in the transaction pool into blocks, it will judge the transactions in the queue to be packaged to determine whether there is a target block that has been in the queue to be packaged for a long time without consensus. The disclosed embodiment can delete expired transactions in the queue to be packaged in a timely manner, thereby releasing storage space in the transaction pool in a timely manner, providing the possibility for the addition of new transactions. Since the packaging of blocks depends on a certain number of non-expired transactions, if there is no timely addition of new transactions, the transactions in the ordinary queue may not be packaged due to expiration. Therefore, the disclosed embodiment facilitates the rapid generation of new blocks by adding new transactions in a timely manner, thereby improving the overall operating efficiency of the system.

[0123] In one embodiment, reference Figure 6 As shown, the cleaning instruction of the first transaction set includes a trigger instruction of the first timer, and in response to the cleaning instruction of the first transaction set, the target block to be cleaned is determined from the first transaction set, and the above also includes:

[0124] Step S601, obtaining a block, and setting a corresponding first timer for the block.

[0125] Step S603, adding the block to which the first timer is added to the first transaction set; wherein the block includes the block proposed by the node and the blocks proposed by other nodes.

[0126] Among them, the timer is a common tool in the computer system, which is used to trigger an event or perform a task within a certain time interval. The timer can be provided by computer hardware, or it can be implemented through a program interface provided by a programming language or an operating system. In the embodiment of the present disclosure, the first timer can be set to delay execution, for example, triggering a cleaning operation on the target block in the first transaction set after a period of time. Optionally, the first timer can also be set to execute at a fixed time, for example, repeatedly executing the operation of determining whether the block corresponding to the first timer can be used as the target block to be cleaned within a fixed time interval.

[0127] In a specific implementation, blocks and corresponding first timers can be stored in pairs in the first transaction set of the queue to be packaged, such as block a, first timer a; block b, first timer b; block c, first timer c. The time settings in the first timers corresponding to each block can be the same or different. For example, the time of the corresponding first timer is set according to the number of transactions in the block and the processing difficulty.

[0128] In the disclosed embodiment, a block may include a block proposed by a node. For example, when a node is confirmed as a master node, a preset number of transactions are packaged from a common queue, and the packaged transactions are stored as a block in a first transaction set. In another exemplary embodiment, a block may also include a block proposed by other nodes. For example, when other nodes are confirmed as master nodes, other nodes package a preset number of transactions from a corresponding common queue to form a block, and broadcast the block to nodes in the blockchain. After receiving the block from other nodes, the node stores the block in the first transaction set.

[0129] In response to the cleaning instruction of the first transaction set, determining the target block to be cleaned from the first transaction set includes:

[0130] Step S605 , in response to the first timer triggering instruction, determining that the target block to be cleaned is the block corresponding to the first timer.

[0131] For example, the first transaction set includes: block a, first timer a; block b, first timer b; block c, first timer c. At a certain time, the first timer b is triggered, then the block b corresponding to the first timer b can be used as the target block to be cleaned, and the expiration time of the transaction in the target block is judged. If the transaction is expired, the transaction is discarded; if the transaction is not expired, the transaction can be added to the second transaction set.

[0132] In the above embodiment, by setting a first timer for a block, when the first timer is triggered, it is determined that the target block to be cleaned is the block corresponding to the first timer. When the blockchain network is relatively large, if a round of consensus is not completed, it may take a long time for the node to package next time. Therefore, the above timer setting can regularly clean up the blocks in the first transaction set that have not been successfully agreed upon, regardless of whether the node is a master node, and can release space in the transaction pool in a timely manner.

[0133] In one embodiment, in response to a first timer trigger instruction, determining that a target block to be cleaned is a block corresponding to the first timer includes:

[0134] In response to a first timer triggering instruction, a block corresponding to the first timer is obtained.

[0135] Obtain the consensus identifier corresponding to the block and the consensus identifier currently stored by the consensus component.

[0136] When the consensus identifier corresponding to the block is inconsistent with at least one information of the stored consensus identifier, it is determined that the target block to be cleaned is the block corresponding to the first timer.

[0137] Specifically, the blocks in the first transaction set can pre-set the first timer and the consensus identifier. When the first timer is triggered, the block corresponding to the first timer is determined. Further, the consensus identifier in the block is obtained. The consensus identifier is compared with the consensus identifier currently stored in the consensus component. In an exemplary embodiment, when the consensus identifier corresponding to the block is inconsistent with at least one information of the stored consensus identifier, the block corresponding to the first timer can be used as the target block to be cleaned. In another exemplary embodiment, when the consensus identifier corresponding to the block is consistent with at least one information of the stored consensus identifier, the block corresponding to the first timer is not cleaned.

[0138] The above-mentioned blockchain transaction processing method, the first timer combined with the consensus identification mechanism, can not only effectively realize the timely cleaning of expired transactions in the first intersection set, but also ensure that the block where the transaction is located is not the block under consensus in the blockchain while cleaning.

[0139] In a specific embodiment, reference Figure 7 As shown, the first transaction set is the transaction set corresponding to the pending queue (pending) in the transaction pool, and the second transaction set is the transaction set corresponding to the ordinary queue (queue) in the transaction pool. Specifically, when a node receives a transaction sent by a client or a transaction sent by other nodes in the blockchain, it can verify the transaction and continue to broadcast the transaction to other nodes. In an exemplary embodiment, if the verification fails, the above transaction is discarded. In another exemplary embodiment, if the verification passes, the total amount of transactions in the transaction pool is obtained. In an exemplary embodiment, if the total amount of transactions reaches the capacity threshold, the above transaction is discarded. In another exemplary embodiment, if the total amount of transactions does not reach the capacity threshold, the transaction is added to the second transaction set of the transaction pool. For example, in Figure 7 In the second transaction set, transactions Tx1, Tx2, Tx3, and Tx4 are stored.

[0140] Furthermore, after entering the consensus phase, a preset number of transactions are obtained from the second transaction set. For example, starting from the earliest transaction in the second transaction set, a preset number of transactions are obtained in sequence. Specifically, a transaction is obtained from the second transaction set, and the expiration time of the transaction is determined. For example, if the current time meets the expiration time of the transaction, the transaction is discarded. For another example, if the current time does not meet the expiration time of the transaction, the transaction is added to the first transaction set until the number of transactions added to the first transaction set reaches the preset number, thereby obtaining a batch of transactions. For example, in Figure 7 In the first transaction set, transactions Tx1 and Tx2 are packaged into a block, waiting to be proposed for consensus.

[0141] refer to Figure 7 As shown, some blocks in the first transaction set are agreed upon by consensus, and the blocks that have successfully reached consensus can be deleted at this time; some blocks that have not reached consensus continue to exist in the first transaction set; some consensus is not completed, for example, due to network reasons, resulting in incomplete consensus, and continue to exist in the first transaction set. For blocks that continue to exist in the first transaction set, in an exemplary embodiment, when the master node packages a new block again, the target block to be cleaned can be determined from the first transaction set, and transactions can be obtained from the target block respectively; if the current time meets the expiration time of the transaction, the corresponding expired transaction is deleted from the first transaction set, and if the current time does not meet the expiration time of the transaction, the non-expired transaction is added to the second transaction set of the transaction pool until the transactions in the target block are processed and an updated second transaction set is obtained.

[0142] In another exemplary embodiment, when the first timer is triggered, the block corresponding to the first timer can be determined. Further, the consensus identifier in the block is obtained. The consensus identifier is compared with the consensus identifier currently stored by the consensus component. In an exemplary embodiment, when the consensus identifier corresponding to the block is inconsistent with at least one information of the stored consensus identifier, the block corresponding to the first timer can be used as the target block to be cleaned. In another exemplary embodiment, when the consensus identifier corresponding to the block is consistent with at least one information of the stored consensus identifier, the block corresponding to the first timer is not cleaned. Among them, the timer is a common tool in a computer system, which is used to trigger an event or perform a task within a certain time interval. The timer can be provided by computer hardware, or it can be implemented through a program interface provided by a programming language or an operating system. In the embodiment of the present disclosure, the first timer can be set to delay execution, for example, triggering a cleaning operation on the target block in the first transaction set after a period of time. Optionally, the first timer can also be set to execute at a fixed time, for example, repeatedly executing the operation of determining whether the block corresponding to the first timer can be used as the target block to be cleaned within a fixed time interval.

[0143] In the above embodiment, when the master node is packaging the block, the target block in the first transaction set is cleaned, and at the same time, by setting a first timer for the block, when the first timer is triggered, it is determined that the target block to be cleaned is the block corresponding to the first timer. When the blockchain network is relatively large, if a round of consensus is not completed, the next packaging of the node may take a long time. Therefore, the mechanism of double-trigger cleaning instructions can release space in the transaction pool more timely and improve the operating efficiency of the system.

[0144] In one embodiment, reference Figure 8 As shown, the method for processing blockchain transactions also includes:

[0145] Step S801, receiving a transaction, and setting a second timer for the received transaction; wherein the transaction includes a transaction sent by a client and / or a transaction broadcasted by other nodes.

[0146] In the disclosed embodiment, the nodes in the blockchain continuously receive transactions, some of which may come from transactions sent by the client, and some of which may come from transactions broadcast by other nodes. When the client sends a transaction to a node in the blockchain, it may choose to send it to one or more nodes in the blockchain. After receiving the transaction from the client, the node may verify the transaction, and after the verification is passed, the transaction may be broadcast to other nodes to achieve data sharing.

[0147] In an exemplary embodiment, when a node receives a transaction, a second timer may be set for the transaction. Optionally, the second timer may include a software timer and a hardware timer. In the disclosed embodiment, the second timer may be set to delay execution, for example, triggering a deletion operation on the corresponding transaction in the second transaction set after a period of time. Optionally, the setting time of the second timer of the transaction may be the same as the expiration time of the transaction. In another exemplary embodiment, the second timer may also be set to execute at a fixed time, for example, a fixed timing time is uniformly set for the received transactions, wherein the timing time is a preset time relative to the time when the transaction is received. Then, the judgment on whether the corresponding transaction is expired is repeated within a fixed time interval, and if the corresponding transaction is expired, the transaction is deleted.

[0148] Step S803, in response to the trigger instruction of the second timer, obtaining the queue status of the received transaction in the transaction pool; wherein the queue status includes a queue to be packaged and a common queue.

[0149] The queue status will be characterized by corresponding identification information. When the queue status of a transaction in the transaction pool is the waiting queue, it means that the received transaction has been packaged into a block and entered the first transaction set. When the queue status of a transaction in the transaction pool is the ordinary queue, it indicates that the received transaction has not been packaged and is in the second transaction set.

[0150] Step S805 , when the queue state is a common queue and the current time satisfies the expiration time of the received transaction, the received transaction is deleted from the second transaction set in the transaction pool to obtain an updated second transaction set.

[0151] In an exemplary embodiment, the second timer can be set to delay execution, and a fixed time can be set for the received transaction, wherein the time is a preset time relative to the time when the transaction is received. When the second timer is triggered, the expiration time of the transaction is judged, and when the current time meets the corresponding expiration time, the received transaction is deleted from the second transaction set in the transaction pool to obtain an updated second transaction set.

[0152] The above-mentioned blockchain transaction processing method, on the basis of cleaning the expired transactions in the first transaction set corresponding to the queue to be packaged in the transaction pool, cleans the expired transactions in the ordinary queue in the transaction pool by setting a second timer, further releasing space in the transaction pool, providing the possibility for the addition of new transactions, and improving the operation efficiency of the system.

[0153] In one embodiment, receiving a transaction and setting a second timer for the received transaction includes:

[0154] Receives transactions and the total amount of transactions in the transaction pool.

[0155] When the total transaction amount does not reach the capacity threshold of the transaction pool, a second timer is set for the received transaction.

[0156] The method of receiving transactions is the same as the above embodiment, and may include transactions sent by the client and transactions sent by other nodes. The total amount of transactions in the transaction pool may include the sum of the number of transactions in the second transaction set in the common queue and the number of transactions in the first transaction set in the queue to be packaged. The capacity threshold may include the upper limit of the capacity in the transaction pool.

[0157] In an exemplary embodiment, when the total transaction amount does not reach the transaction pool capacity threshold, a second timer is set for the received transaction. In another exemplary embodiment, when the total transaction amount reaches the transaction pool capacity threshold, the received transaction can be discarded.

[0158] In the above-mentioned blockchain transaction processing method, the second timer is set for the transaction only when the total transaction amount does not reach the transaction pool capacity threshold. The disclosed embodiment avoids setting the second timer when the total transaction amount reaches the capacity threshold by adding a comparison between the total transaction amount and the capacity threshold, and adds the above-mentioned comparison process to ensure the system memory security.

[0159] In one embodiment, after obtaining the queue status of the transaction in the transaction pool, the method further includes:

[0160] When the queue state is a queue to be packaged, the triggering time or time interval of the second timer is reset.

[0161] The second timer can be set to delay execution, for example, triggering the deletion of the corresponding transaction in the second transaction set after a period of time. At this time, the time interval of the delay is set in the timer. Optionally, the second timer can also be set to execute at a specific time, for example, at 6:20:15 am on September 20, 2023.

[0162] In the above embodiments, the present disclosure has set a variety of cleaning strategies for transactions in the queue to be packaged. On this basis, to avoid repeated settings, when the second timer is triggered, if the transaction corresponding to the second timer is in the first transaction set of the queue to be packaged, the transaction will no longer be cleaned. In an exemplary embodiment, the trigger time or time interval of the second timer is reset. In order to avoid the corresponding transaction not being successfully agreed upon again, after returning to the ordinary queue, the transaction can be cleaned again.

[0163] In a specific embodiment, reference Fig. 9 As shown, the nodes in the blockchain continuously receive network messages of transactions, and convert them into transaction objects that can be processed internally by deserializing the network messages. Among them, deserializing network messages is the process of converting binary data received from the network into an operable data structure or object. In the disclosed embodiment, the nodes in the blockchain continuously receive transactions, wherein some transactions may come from transactions sent by the client, and some transactions may also come from transactions broadcast by other nodes. Among them, when the client sends a transaction to a node in the blockchain, it can choose to send it to one or more nodes in the blockchain. After the node receives the transaction from the client, it can verify the transaction. After the verification is passed, the transaction can be broadcast to other nodes to achieve data sharing. After the verification fails, the transaction is discarded.

[0164] Furthermore, when the verification is passed, the total amount of transactions in the transaction pool is obtained, and when the total amount of transactions is greater than the capacity threshold, the transaction is deleted. When the total amount of transactions does not reach the capacity threshold, a second timer is set for the received transaction, and the transaction is placed in the transaction pool. In response to the trigger instruction of the second timer, the queue state of the received transaction in the transaction pool is obtained; wherein the queue state includes a queue to be packaged and a common queue; when the queue state is a common queue and the current time meets the expiration time of the received transaction, the received transaction is deleted from the second transaction set in the transaction pool to obtain an updated second transaction set.

[0165] Optionally, the second timer may include a software timer and a hardware timer. In the embodiment of the present disclosure, the second timer may be set to delay execution, for example, triggering the deletion operation of the corresponding transaction in the second transaction set after a period of time. Optionally, the setting time of the second timer of the transaction may be the same as the expiration time of the transaction. In another exemplary embodiment, the second timer may also be set to execute at a fixed time, for example, a fixed timing time is uniformly set for the received transactions, wherein the timing time is a time relative to a preset time after the transaction moment is received. Then, the corresponding transaction is repeatedly executed within a fixed time interval to determine whether it is expired, and if the corresponding transaction is expired, the transaction is deleted. In another exemplary embodiment, the second timer may be set to delay execution, and a fixed timing time may be set for the received transaction, wherein the timing time is a time relative to a preset time after the transaction moment is received. When the second timer is triggered, the expiration time of the transaction is judged, and if the current time meets the corresponding expiration time, the received transaction is deleted from the second transaction set in the transaction pool to obtain an updated second transaction set.

[0166] The above-mentioned blockchain transaction processing method, on the basis of cleaning the expired transactions in the first transaction set corresponding to the queue to be packaged in the transaction pool, cleans the expired transactions in the ordinary queue in the transaction pool by setting a second timer, further releasing space in the transaction pool, providing the possibility for the addition of new transactions, and improving the operation efficiency of the system.

[0167] In one embodiment, reference Fig.10 As shown, the method for processing blockchain transactions also includes:

[0168] Step S1001, receiving a transaction, and determining the sender of the received transaction; wherein the sender includes a client and / or other nodes.

[0169] In the disclosed embodiment, the nodes in the blockchain continuously receive transactions. On the one hand, the transactions may come from transactions sent by the client. On the other hand, the transactions may also come from transactions broadcast by other nodes. Therefore, after receiving the transaction, the node can identify the sender of the transaction.

[0170] Step S1003: When the sender is a blockchain node, obtain the transaction identifier of the received transaction.

[0171] In the data structure corresponding to the transaction, the transaction identifier, such as the transaction hash value, can be loaded. Information such as input, output, signature, expiration time, etc. can also be loaded. After receiving the transaction sent by the blockchain node, the transaction can be repeatedly verified in the following way, that is, whether the received transaction exists in the verification node.

[0172] Step S1005: when the received transaction identifier is found in the filter preset in the memory, the transaction is discarded.

[0173] Specifically, when the received transaction identifier is queried from the preset filter in the memory, it indicates that the node has received the transaction before. Combined with the fact that the sender of the transaction is sent to this node by other block nodes, the transaction is likely to have been added to the transaction pool by other nodes. In order to reduce the system consumption caused by repeated addition, the received transaction is deleted.

[0174] In the disclosed embodiment, a filter is set in the memory to intercept transactions that are repeatedly sent to this node. Compared with the prior art, when a transaction is received and the repeatability of the transaction is verified, if the received transaction cannot be found in the memory, considering that the transaction may be agreed upon by other nodes, it is necessary to query the database of the node, resulting in a large system overhead. Among them, transactions that have successfully reached consensus are generally stored in the database of the node. In the disclosed embodiment, the repeatability verification of the sent transactions can be realized only in the filter of the memory, further improving the system operation efficiency.

[0175] In one embodiment, after obtaining the received transaction identifier of the transaction, the method further includes:

[0176] When the received transaction identifier is not found in the filter preset in the memory, the total transaction amount in the transaction pool is obtained.

[0177] When the total transaction amount does not reach the capacity threshold, the received transaction is added to the second transaction set of the transaction pool to obtain an updated second transaction set.

[0178] Specifically, in an exemplary embodiment, when the received transaction is not found in the filter preset in the memory, the total amount of transactions in the transaction pool can be further obtained, and when the total amount of transactions does not reach the capacity threshold, the received transaction is added to the second transaction set. In another exemplary embodiment, the repeatability verification of the transaction can be further enhanced. For example, when the received transaction identifier is not found in the filter preset in the memory, it is queried from the transactions in the transaction pool whether the above transaction exists. When the above transaction does not exist in the transaction pool, it is determined whether the total amount of transactions reaches the capacity threshold. When the total amount of transactions does not reach the capacity threshold, the received transaction is added to the second transaction set of the transaction pool.

[0179] In the disclosed embodiment, when repeat verification is performed on received transactions, there is no need to query and verify the database, thereby improving the operating efficiency of the system.

[0180] In one embodiment, after obtaining the total transaction amount in the transaction pool, the method further includes:

[0181] When the total transaction amount reaches the capacity threshold, the transaction identifier of the received transaction is added to the filter; wherein the filter includes a data structure of a key-value pair, wherein the key in the key-value pair corresponds to the stored transaction identifier.

[0182] In the embodiment of the present disclosure, when a node receives a transaction, it queries whether there is a transaction identifier of the transaction in the filter preset in the memory. When the transaction identifier of the received transaction exists in the filter, it means that the node has received the transaction before. Among them, the reason for receiving again may be that when the transaction is first sent to the node, the total amount of transactions in the node transaction pool reaches the capacity threshold, resulting in the transaction not being placed in the transaction pool. Based on the gossip protocol or retransmission mechanism, the transaction arrives at this node again. Another reason may be that when the transaction is first sent to the node, the total amount of transactions in the node transaction pool reaches the capacity threshold, resulting in the transaction not being placed in the transaction pool. Although the transaction is not placed in the transaction pool of this node, it may be packaged by other nodes and stored in the database of this node after consensus is completed. For the second reason, the present disclosure discards the transaction sent by the blockchain node when there is a transaction identifier in the filter. In an exemplary embodiment, if the transaction identifier is not found in the filter, it means that the transaction may be received by the node for the first time, and it is further determined whether the total amount of transactions reaches the capacity threshold. If the total amount of transactions reaches the capacity threshold, the transaction identifier of the transaction is added to the filter.

[0183] In a specific implementation, the filter may adopt a key-value pair data structure, wherein the key in the key-value pair corresponds to the stored transaction identifier, and the value in the key-value pair may be traded or not stored. Optionally, when only the transaction identifier is stored in the filter, it helps to save memory space and improve the operating efficiency of the system.

[0184] In a specific embodiment, reference Fig.11As shown, for the prior art, the transaction pool stores transactions or blocks sent by the client or other nodes of the blockchain. And the total amount of transactions in the transaction pool 1101 reaches the capacity threshold of the transaction pool. At this time, a new transaction Tx4 is received, and the new transaction Tx4 cannot be put in because the transaction pool is full. The new transaction Tx4 may be packaged by other nodes in the blockchain and reach a consensus block 1105. The consensus block 1105 is stored in the database of each node as a blockchain ledger. Receive transaction Tx4 again, even if the number of transactions in the transaction pool 1107 at this time does not reach the capacity threshold, transaction Tx4 cannot enter the transaction pool 1107. Specifically, the node needs to compare the transaction Tx4 received again with the transaction in the consensus block 1105 stored in the database, and determine that the transaction Tx4 has been hit by consensus, so the transaction Tx4 received again is discarded. The above-mentioned transaction deduplication needs to penetrate the underlying database, resulting in reduced system performance.

[0185] In the present application scheme, transaction Tx4 is received again. Even if the number of transactions in transaction pool 1107 at this time does not reach the capacity threshold, transaction Tx4 cannot enter transaction pool 1107. The specific method includes: receiving a transaction, determining the sender of the received transaction; wherein the sender includes a client and / or other nodes; in the case where the sender is a blockchain node, obtaining the transaction identifier of the received transaction; in the case where the received transaction identifier is queried in the filter preset in the memory, discarding the transaction. In the case where the total amount of transactions reaches the capacity threshold, the transaction identifier of the received transaction is added to the filter; wherein the filter includes a data structure of a key-value pair, wherein the key in the key-value pair corresponds to the stored transaction identifier.

[0186] In a specific implementation, the filter may adopt a key-value pair data structure, wherein the key in the key-value pair corresponds to the stored transaction identifier, and the value in the key-value pair may be traded or not stored. Optionally, when only the transaction identifier is stored in the filter, it helps to save memory space and improve the operating efficiency of the system.

[0187] In the disclosed embodiment, a filter is set in the memory to intercept transactions that are repeatedly sent to this node. Compared with the prior art, when a transaction is received and the repeatability of the transaction is verified, if the received transaction cannot be found in the memory, considering that the transaction may be agreed upon by other nodes, it is necessary to query the database of the node, resulting in a large system overhead. Among them, transactions that have successfully reached consensus are generally stored in the database of the node. In the disclosed embodiment, the repeatability verification of the sent transactions can be realized only in the filter of the memory, further improving the system operation efficiency.

[0188] In one embodiment, reference Fig.12As shown, the method for processing blockchain transactions also includes:

[0189] Step S1201: Acquire transactions from the updated second transaction set.

[0190] Step S1203: when the current time meets the expiration time of the transaction, delete the corresponding expired transaction from the second transaction set.

[0191] Step S1205: When the current time does not satisfy the expiration time of the transaction, the corresponding transaction is added to the first transaction set until the number of added transactions reaches a preset number, thereby obtaining an updated first transaction set.

[0192] Specifically, a preset number of transactions are obtained from the second transaction set. For example, starting from the earliest transaction in the second transaction set, a preset number of transactions are obtained in sequence. Specifically, a transaction is obtained from the second transaction set, and the expiration time of the transaction is determined. For example, if the current time meets the expiration time of the transaction, the transaction is discarded. For another example, if the current time does not meet the expiration time of the transaction, the transaction is added to the first transaction set until the number of transactions added to the first transaction set reaches a preset number, thereby obtaining a batch of transactions. The batch of transactions is used to package and generate a new block.

[0193] In a specific implementation, the present application method can be applied to the application scenario of transfer transactions. Among them, the transfer transaction may include the sender, the receiver, and the transfer amount. In the prior art, when the number of transactions in the transaction pool corresponding to the blockchain node reaches the capacity threshold, new transactions cannot be added, and the original transactions may not be used due to expiration, resulting in low overall operating efficiency of the blockchain system. The present application method can add new transactions in a timely manner, facilitate the rapid generation of new blocks, and thus improve the overall operating efficiency of the system.

[0194] When the trigger condition 1 of the cleaning instruction is met, the first transaction set is cleaned: wherein the trigger condition 1 is that the node is confirmed as the master node, and there is a target block to be cleaned in the queue to be packaged. For example, the node is confirmed as the master node, the consensus identifier currently stored in the consensus component is obtained, and the consensus identifier of each block is obtained from the first transaction set. In the case that there is at least one information inconsistency between the consensus identifier of each block and the stored consensus identifier, a cleaning instruction for the first transaction set is generated. Among them, the master node is a node with special permissions and functions in the blockchain system, and the functions of the master node may be different in different block systems. In an exemplary embodiment, the master node can be responsible for generating new blocks and adding them to the blockchain. At the same time, the master node also verifies the blocks generated by other nodes to ensure that they comply with the rules and consensus algorithm of the network. Optionally, the master node can participate in the operation of the consensus algorithm. In an exemplary embodiment, the master node can be generated by voting or random selection. The consensus identifier of the block currently being consensused is stored in the consensus component. Specifically, based on the consensus algorithm, each node may need multiple rounds in the consensus process, wherein the consensus round information and block height information can reflect the current consensus status of each node, wherein there may be many rounds under the same block height. Therefore, in an exemplary embodiment, the block currently in consensus can be determined by obtaining the consensus identifier in the consensus component. In a specific implementation, each block in the queue to be packaged corresponds to a consensus identifier. In an exemplary embodiment, for the consensus identifier of each block, the block height information in the consensus identifier can be compared with the block height information in the consensus identifier stored in the consensus component. If the block height information in the consensus identifier of the block is inconsistent with the block height information stored in the consensus component, it can be determined that there is a target block to be cleaned in the first transaction set, and a cleaning instruction for the first transaction set is generated. Optionally, in another exemplary embodiment, if the block height information in the consensus identifier of the block is consistent with the block height information stored in the consensus component, the consensus round information in the consensus identifier of the block can be compared with the consensus round information stored in the consensus component. If the consensus round information in the block is inconsistent with the consensus round information stored in the consensus component, it can be determined that there is a target block to be cleaned in the first transaction set, and a cleaning instruction for the first transaction set is generated.

[0195] When the trigger condition 2 of the cleaning instruction is met, the trigger condition 2 is that the current time meets the trigger time set by the first timer. The process of cleaning the first transaction set: in response to the first timer trigger instruction, determine that the target block to be cleaned is the block corresponding to the first timer. For example, the first transaction set includes: block a, first timer a; block b, first timer b; block c, first timer c. At a certain time, the first timer b is triggered, then the block b corresponding to the first timer b can be used as the target block to be cleaned, and the expiration time of the transaction in the target block is judged. If the transaction is expired, the transaction is discarded; if the transaction is not expired, the transaction can be added to the second transaction set. Further, the consensus identifier in the block is obtained. The consensus identifier is compared with the consensus identifier currently stored by the consensus component. In an exemplary embodiment, when the consensus identifier corresponding to the block is inconsistent with at least one information of the stored consensus identifier, the block corresponding to the first timer can be used as the target block to be cleaned. In another exemplary embodiment, when the consensus identifier corresponding to the block is consistent with at least one information of the stored consensus identifier, the block corresponding to the first timer is not cleaned.

[0196] Processing process of cleaning the second transaction set: The nodes in the blockchain continue to receive transactions, wherein some transactions may come from transactions sent by the client, and some transactions may also come from transactions broadcast by other nodes. Among them, when the client sends a transaction to a node in the blockchain, it can choose to send it to one or more nodes in the blockchain. After the node receives the transaction from the client, it can verify the transaction, and after the verification is passed, the transaction can be broadcast to other nodes to achieve data sharing. In an exemplary embodiment, when the node receives the transaction, a second timer can be set for the transaction. Optionally, the second timer can include a software timer and a hardware timer. In the embodiment of the present disclosure, the second timer can be set to delay execution, for example, triggering a deletion operation of the corresponding transaction in the second transaction set after a period of time. Optionally, the setting time of the second timer of the transaction can be the same as the expiration time of the transaction. In another exemplary embodiment, the second timer can also be set to execute at a fixed time, for example, a fixed timer is uniformly set for the received transactions, wherein the timer is a preset time relative to the time when the transaction is received. Then, the corresponding transaction is repeatedly executed within a fixed time interval to determine whether it is expired, and the transaction is deleted if the corresponding transaction is expired. In response to the trigger instruction of the second timer, the queue status of the received transaction in the transaction pool is obtained. When the queue status of the transaction in the transaction pool is a queue to be packaged, it means that the received transaction has been packaged into a block and entered the first transaction set. When the queue status of the transaction in the transaction pool is a normal queue, it indicates that the received transaction has not been packaged and is in the second transaction set. In an exemplary embodiment, the second timer can be set to delay execution, and a fixed timing time can be set for the received transaction, wherein the timing time is a preset time relative to the time when the transaction is received. When the second timer is triggered, the expiration time of the transaction is judged, and when the current time meets the corresponding expiration time, the received transaction is deleted from the second transaction set in the transaction pool to obtain an updated second transaction set.

[0197] A process for performing repeatability verification on repeatedly sent transactions using filters: receiving a transaction, determining the sender of the received transaction; wherein the sender includes a client and / or other nodes. In the case where the sender is a blockchain node, obtaining a transaction identifier of the received transaction. In the case where the received transaction identifier is queried in the filter preset in the memory, the transaction is discarded. In the case where the received transaction identifier is not queried in the filter preset in the memory, obtaining the total amount of transactions in the transaction pool. In the case where the total amount of transactions does not reach the capacity threshold, adding the received transaction to the second transaction set of the transaction pool to obtain an updated second transaction set. In the case where the total amount of transactions reaches the capacity threshold, adding the transaction identifier of the received transaction to the filter; wherein the filter includes a data structure of a key-value pair, wherein the key in the key-value pair corresponds to the stored transaction identifier.

[0198] In the above-mentioned blockchain transaction processing method, after receiving the cleaning instruction, by determining the target block to be cleaned in the first transaction set, the block that has existed in the first transaction set for a long time is used as the target block. The expiration time of the transaction in the target block is judged, and the expired transactions in the waiting group are deleted in time, so as to release the storage space in the transaction pool in time and provide the possibility for the addition of new transactions. Since the packaging of blocks depends on a certain number of unexpired transactions, if there is no timely addition of new transactions, the transactions in the ordinary queue may not be packaged due to expiration. Therefore, the embodiment of the present disclosure facilitates the rapid generation of new blocks by timely adding new transactions, thereby improving the overall operation efficiency of the system.

[0199] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0200] Based on the same inventive concept, the embodiment of the present application also provides a blockchain transaction processing device for implementing the blockchain transaction processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the one or more blockchain transaction processing device embodiments provided below can refer to the limitations of the blockchain transaction processing method above, and will not be repeated here.

[0201] In one embodiment, Fig.13 As shown, a blockchain transaction processing device is provided, including:

[0202] The target block determination module 1301 is used to determine the target block to be cleaned from the first transaction set in response to the cleaning instruction of the first transaction set; wherein the first transaction set is the transaction set corresponding to the to-be-packaged queue in the transaction pool corresponding to the node;

[0203] The transaction acquisition module 1303 is used to respectively acquire transactions from the target block;

[0204] The first transaction processing module 1305 is used to delete the corresponding expired transaction from the first transaction set when the current time meets the expiration time of the transaction, and add the non-expired transaction to the second transaction set of the transaction pool when the current time does not meet the expiration time of the transaction, until the transactions in the target block are processed, and an updated second transaction set is obtained; wherein the second intersection set is the transaction set corresponding to the ordinary queue in the transaction pool; the updated second transaction set is used to provide a preset number of transactions to the queue to be packaged when the block is packaged, so as to generate a new block.

[0205] In one embodiment, the target block determination module is further configured to:

[0206] Obtaining the consensus identifier currently stored by the consensus component, and obtaining the consensus identifier of each block from the first transaction set; wherein the consensus identifier includes block height information and consensus round information; the consensus component is used to update the consensus identifier based on the consensus status of the block in the blockchain node;

[0207] The target block to be cleaned is determined to be a block in each block that is inconsistent with at least one information of the stored consensus identifier.

[0208] In one embodiment, the target block determination module is further configured to:

[0209] Receive blocks sent by other nodes in the blockchain;

[0210] Obtaining the node height and consensus round from the proposal information of the block;

[0211] A consensus identifier is obtained based on the node height and the consensus round, and the consensus identifier is added to the corresponding block.

[0212] In one embodiment, the device further comprises:

[0213] A master node confirmation module, configured to obtain a consensus identifier currently stored in a consensus component in response to the node being confirmed as a master node, and to obtain a consensus identifier of each block from the first transaction set;

[0214] The cleaning instruction generation module is used to generate a cleaning instruction for the first transaction set when there is at least one information in the consensus identifier of each block that is inconsistent with the stored consensus identifier.

[0215] In one embodiment, the target block determination module is further configured to:

[0216] Get the block, and set the corresponding first timer for the block;

[0217] Adding the block to which the first timer has been added to the first transaction set; wherein the block includes the block proposed by the node and the blocks proposed by other nodes;

[0218] In response to a first timer triggering instruction, it is determined that the target block to be cleaned is the block corresponding to the first timer.

[0219] In one embodiment, the target block determination module is further configured to:

[0220] In response to a first timer trigger instruction, obtaining a block corresponding to the first timer;

[0221] Obtain the consensus identifier corresponding to the block and the consensus identifier currently stored by the consensus component;

[0222] When the consensus identifier corresponding to the block is inconsistent with at least one information of the stored consensus identifier, it is determined that the target block to be cleaned is the block corresponding to the first timer.

[0223] In one embodiment, the blockchain transaction processing device further includes:

[0224] A first transaction receiving module, configured to receive a transaction and set a second timer for the received transaction; wherein the transaction includes a transaction sent by a client and / or a transaction broadcasted by other nodes;

[0225] A queue status acquisition module, configured to acquire the queue status of the received transaction in the transaction pool in response to a trigger instruction of the second timer; wherein the queue status includes a queue to be packaged and a common queue;

[0226] The first transaction cleaning module is used to delete the received transaction from the second transaction set in the transaction pool to obtain an updated second transaction set when the queue state is a common queue and the current time meets the expiration time of the received transaction.

[0227] In one embodiment, the transaction receiving module is further used to:

[0228] Receive transactions and the total amount of transactions in the transaction pool;

[0229] When the total transaction amount does not reach the capacity threshold of the transaction pool, a second timer is set for the received transaction.

[0230] In one embodiment, the blockchain transaction processing device further includes:

[0231] The second transaction processing module is used to reset the trigger time or time interval of the second timer when the queue state is a queue to be packaged.

[0232] In one embodiment, the blockchain transaction processing device further includes:

[0233] A second transaction receiving module, configured to receive a transaction and determine a sender of the received transaction; wherein the sender includes a client and / or other nodes;

[0234] A transaction identification acquisition module, used to acquire the transaction identification of the received transaction when the sender is a blockchain node;

[0235] The third transaction processing module is used to discard the transaction when the received transaction identifier is found in the filter preset in the memory.

[0236] In one embodiment, the third transaction processing module is further configured to:

[0237] If the received transaction identifier is not found in the filter preset in the memory, obtaining the total transaction amount in the transaction pool;

[0238] When the total transaction amount does not reach the capacity threshold, the received transaction is added to the second transaction set of the transaction pool to obtain an updated second transaction set.

[0239] In one embodiment, the third transaction processing module is further configured to:

[0240] When the total transaction amount reaches the capacity threshold, the transaction identifier of the received transaction is added to the filter; wherein the filter includes a data structure of a key-value pair, wherein the key in the key-value pair corresponds to the stored transaction identifier.

[0241] In one embodiment, the transaction processing module is further configured to:

[0242] Obtaining a transaction from the updated second transaction set;

[0243] When the current time meets the expiration time of the transaction, deleting the corresponding expired transaction from the second transaction set;

[0244] When the current time does not meet the expiration time of the transaction, the corresponding transaction is added to the first transaction set until the number of added transactions reaches a preset number, thereby obtaining an updated first transaction set.

[0245] Each module in the above-mentioned blockchain transaction processing device can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0246] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.14 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to 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 processing data of blockchain transactions. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for processing blockchain transactions is implemented.

[0247] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Fig.15As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are 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 and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless method can be implemented through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a method for processing blockchain transactions is implemented. The display unit of the computer device is used to form a visually visible image, and can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer covered on the display screen, or a button, trackball or touchpad set on the computer device casing, or an external keyboard, touchpad or mouse, etc.

[0248] Those skilled in the art will understand that Fig.15 The structure shown in the figure is only a block diagram of a part of the structure 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 certain components, or have a different arrangement of components.

[0249] It should be noted that the client information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this 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 must comply with relevant laws, regulations and standards of relevant countries and regions.

[0250] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and 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-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. 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. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0251] The technical features of the above embodiments may be arbitrarily combined. To make the description concise, 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, they should be considered to be within the scope of this specification.

[0252] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for processing blockchain transactions, characterized in that: Applied to a node in a blockchain, the method comprises: In response to a cleaning instruction of a first transaction set, determining a target block to be cleaned from the first transaction set; wherein the first transaction set is a transaction set corresponding to a queue to be packaged in a transaction pool corresponding to the node; Respectively obtain transactions from the target block; When the current time meets the expiration time of the transaction, the corresponding expired transaction is deleted from the first transaction set; when the current time does not meet the expiration time of the transaction, the non-expired transaction is added to the second transaction set of the transaction pool until the transactions in the target block are processed, thereby obtaining an updated second transaction set; wherein the second intersection set is the transaction set corresponding to the ordinary queue in the transaction pool; the updated second transaction set is used to provide a preset number of transactions to the queue to be packaged when proposing a block, so as to generate a new block.

2. The method according to claim 1, characterized in that Determining a target block to be cleaned from the first transaction set includes: Obtaining the consensus identifier currently stored by the consensus component, and obtaining the consensus identifier of each block from the first transaction set; wherein the consensus identifier includes block height information and consensus round information; the consensus component is used to update the consensus identifier based on the consensus status of the block in the blockchain node; The target block to be cleaned is determined to be a block in each block that is inconsistent with at least one information of the stored consensus identifier.

3. The method according to claim 2, characterized in that The step of obtaining the consensus identifier of the transaction further includes: Receive blocks sent by other nodes in the blockchain; Obtaining block height information and consensus round information from the proposal information of the block; A consensus identifier is obtained based on the block height and the consensus round, and the consensus identifier is added to the corresponding block.

4. The method according to claim 1, characterized in that: The step of determining a target block to be cleaned from the first transaction set in response to the cleaning instruction of the first transaction set also includes: In response to the node being confirmed as a master node, obtaining a consensus identifier currently stored by a consensus component, and obtaining a consensus identifier of each block from the first transaction set; When the consensus identifier of each block is inconsistent with at least one information of the stored consensus identifier, a cleaning instruction for the first transaction set is generated.

5. The method according to claim 1, characterized in that The cleaning instruction of the first transaction set includes a trigger instruction of a first timer, and in response to the cleaning instruction of the first transaction set, a target block to be cleaned is determined from the first transaction set, and the method also includes: Get the block, and set the corresponding first timer for the block; Adding the block to which the first timer has been added to the first transaction set; wherein the block includes the block proposed by the node and the blocks proposed by other nodes; In response to the cleaning instruction of the first transaction set, determining the target block to be cleaned from the first transaction set includes: In response to a first timer triggering instruction, it is determined that the target block to be cleaned is the block corresponding to the first timer.

6. The method according to claim 5, characterized in that In response to a first timer trigger instruction, determining that a target block to be cleaned is a block corresponding to the first timer includes: In response to a first timer trigger instruction, obtaining a block corresponding to the first timer; Obtain the consensus identifier corresponding to the block and the consensus identifier currently stored by the consensus component; When the consensus identifier corresponding to the block is inconsistent with at least one information of the stored consensus identifier, it is determined that the target block to be cleaned is the block corresponding to the first timer.

7. The method according to claim 1, characterized in that Also includes: Receiving a transaction, and setting a second timer for the received transaction; wherein the transaction includes a transaction sent by a client and / or a transaction broadcasted by other nodes; In response to a trigger instruction of the second timer, obtaining a queue state of the received transaction in the transaction pool; wherein the queue state includes a queue to be packaged and a common queue; When the queue state is a common queue and the current time satisfies the expiration time of the received transaction, the received transaction is deleted from the second transaction set in the transaction pool to obtain an updated second transaction set.

8. The method according to claim 7, characterized in that Receiving a transaction, and setting a second timer for the received transaction, including: Receive transactions and the total amount of transactions in the transaction pool; When the total transaction amount does not reach the capacity threshold of the transaction pool, a second timer is set for the received transaction.

9. The method according to claim 7, characterized in that: After obtaining the queue status of the transaction in the transaction pool, the method further includes: When the queue state is a queue to be packaged, the triggering time or time interval of the second timer is reset.

10. The method according to claim 1, characterized in that Also includes: Receiving a transaction, and determining a sender of the received transaction; wherein the sender includes a client and / or other nodes; When the sender is a blockchain node, obtaining a transaction identifier of the received transaction; When the received transaction identifier is found in the filter preset in the memory, the transaction is discarded.

11. The method according to claim 10, characterized in that After obtaining the transaction identifier of the received transaction, the method further includes: If the received transaction identifier is not found in the filter preset in the memory, obtaining the total transaction amount in the transaction pool; When the total transaction amount does not reach the capacity threshold, the received transaction is added to the second transaction set of the transaction pool to obtain an updated second transaction set.

12. The method according to claim 10, characterized in that After obtaining the total transaction amount in the transaction pool, the method further includes: When the total transaction amount reaches the capacity threshold, the transaction identifier of the received transaction is added to the filter; wherein the filter includes a data structure of a key-value pair, wherein the key in the key-value pair corresponds to the stored transaction identifier.

13. The method according to claim 1, characterized in that The updated second transaction set further includes: Obtaining a transaction from the updated second transaction set; When the current time meets the expiration time of the transaction, deleting the corresponding expired transaction from the second transaction set; When the current time does not satisfy the expiration time of the transaction, the corresponding transaction is added to the first transaction set until the number of added transactions reaches a preset number, thereby obtaining an updated first transaction set.

14. A blockchain transaction processing device, characterized in that: Applied to a node in a blockchain, the device comprises: A target block determination module, configured to determine a target block to be cleaned from the first transaction set in response to a cleaning instruction of the first transaction set; wherein the first transaction set is a transaction set corresponding to a queue to be packaged in a transaction pool corresponding to the node; A transaction acquisition module, used to acquire transactions from the target block respectively; The first transaction processing module is used to delete the corresponding expired transaction from the first transaction set when the current time meets the expiration time of the transaction, and add the non-expired transaction to the second transaction set of the transaction pool when the current time does not meet the expiration time of the transaction, until the transactions in the target block are processed, and an updated second transaction set is obtained; wherein the second intersection set is the transaction set corresponding to the ordinary queue in the transaction pool; the updated second transaction set is used to provide a preset number of transactions to the queue to be packaged when the block is packaged, so as to generate a new block.

15. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method for processing blockchain transactions described in any one of claims 1 to 13 are implemented.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method for processing blockchain transactions described in any one of claims 1 to 13 are implemented.

17. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method for processing blockchain transactions described in any one of claims 1 to 13 are implemented.

Images