Data cleaning method and apparatus for blockchain, computer device and storage medium

Abstract

A data cleaning method for a blockchain, executed by a computer device which maintains a first node in a blockchain system. The method comprises: when a new block is generated in a blockchain, acquiring a transaction term tree maintained by the first node itself, and determining expired transaction tasks in the transaction term tree (S302); extracting a preset number of transaction tasks from a transaction pool of the blockchain, so as to obtain a preset number of target transaction tasks (S304); on the basis of the expired transaction tasks and the target transaction tasks, generating a proposal message of the new block, the proposal message carrying transaction identification information of the expired transaction tasks (S306); and broadcasting the proposal message to a second node in the blockchain, the second node being used for performing consensus on the new block on the basis of the target transaction tasks, and after a consensus is reached, clearing the expired transaction tasks on the basis of the transaction identification information (S308).

Description

Blockchain data cleaning method, device, computer equipment, and storage medium

[0001] Related applications

[0002] This application claims priority to Chinese patent application number 2023109302896, filed on July 26, 2023, entitled “Blockchain data cleaning method, device, computer equipment, and storage medium,” the entire text of which is hereby incorporated by reference. Technical Field

[0003] The present application relates to the field of computer technology, and in particular to a blockchain data cleaning method, apparatus, computer equipment, storage medium, and computer program product. Background Art

[0004] Blockchain is a new decentralized distributed ledger technology that securely stores transactions and other data. Its key characteristic is that information stored on the blockchain cannot be forged or tampered with. The blockchain consensus algorithm drives every node on the blockchain to participate in the transaction verification process, ensuring that transactions on the blockchain are verified and authentic. Blockchain is essentially a distributed storage system, with each node storing data. This data storage is data-based. As data volumes increase, the need for storage increases, and performance for non-distributed data naturally degrades. Because blockchain is inherently distributed storage, each node typically uses a non-distributed database, which can negatively impact performance. Therefore, outdated data needs to be cleaned up.

[0005] However, the current method for cleaning up blockchain data is usually to have the blockchain system administrator send a command to all blockchain nodes (the command is also sent to the blockchain in the form of a transaction). This command usually specifies the data archiving height, and the blockchain node will archive (clean up) all transaction data before the data archiving height, thereby reducing the amount of data. However, this process requires manual intervention. In other words, when the amount of data stored in the blockchain is huge, the above data cleaning method requires manual participation. Moreover, this data cleaning method is a single-point behavior. In other words, for the entire blockchain system, if the data in a certain node is manually cleaned, it may affect the subsequent processing flow of other businesses and may also cause inconsistent execution status of each node, which in turn leads to security issues for the entire blockchain after data cleaning.

[0006] Summary of the Invention

[0007] According to an embodiment of the present application, a blockchain data cleaning method, apparatus, computer device, computer-readable storage medium, and computer program product are provided.

[0008] In a first aspect, the present application provides a method performed by a computer device maintaining a first node in a blockchain system, the method comprising:

[0009] When a new block is generated in the blockchain, the transaction deadline tree maintained by the first node is obtained, and expired transaction tasks in the transaction deadline tree are determined;

[0010] Grab a preset number of transaction tasks from the transaction pool of the blockchain to obtain a preset number of target transaction tasks;

[0011] Based on the expired transaction task and the target transaction task, generating a proposal message for the new block, wherein the proposal message carries transaction identification information of the expired transaction task; and

[0012] The proposal message is broadcast to a second node in the blockchain, and the second node is used to reach a consensus on the new block based on the target transaction task, and clear the expired transaction task based on the transaction identification information after reaching a consensus.

[0013] In a second aspect, the present application further provides a blockchain data cleaning device, the device comprising:

[0014] a determination module, configured to, when a new block is generated in the blockchain, obtain a transaction deadline tree maintained by the first node itself and determine expired transaction tasks in the transaction deadline tree;

[0015] A capture module, configured to capture a preset number of transaction tasks from the transaction pool of the blockchain to obtain a preset number of target transaction tasks;

[0016] a generating module, configured to generate a proposal message for the new block based on the expired transaction task and the target transaction task, wherein the proposal message carries transaction identification information of the expired transaction task; and

[0017] A broadcast module is configured to broadcast the proposal message to a second node in the blockchain, where the second node is configured to reach a consensus on the new block based on the target transaction task, and to clear the expired transaction task based on the transaction identification information after reaching a consensus.

[0018] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores computer-readable instructions, and the processor implements the methods of the various embodiments of the present application when executing the computer-readable instructions.

[0019] In a fourth aspect, the present application further provides a computer-readable storage medium having computer-readable instructions stored thereon, which implement the methods of the various embodiments of the present application when the computer-readable instructions are executed by a processor.

[0020] In a fifth aspect, the present application also provides a computer program product, comprising computer-readable instructions, which, when executed by a processor, implement the methods of the various embodiments of the present application.

[0021] The details of one or more embodiments of the present application are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the present application will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the conventional technology, the following briefly introduces the drawings required for use in the embodiments or the conventional technology descriptions. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the disclosed drawings without any creative work.

[0023] FIG1 is a schematic diagram of an optional structure of a distributed system applied to a blockchain system in one embodiment;

[0024] FIG2 is a schematic diagram of an optional block structure in one embodiment;

[0025] FIG3 is a schematic diagram of a flowchart of a method for clearing blockchain data in one embodiment;

[0026] FIG4 is a schematic diagram of the structure of a transaction deadline tree in one embodiment;

[0027] FIG5 is a schematic diagram of a master node proposal process in one embodiment;

[0028] FIG6 is a schematic diagram of information carried by a transaction task in one embodiment;

[0029] FIG7 is a schematic diagram of a process for creating a transaction deadline tree in one embodiment;

[0030] FIG8 is a schematic diagram of information carried in a proposal message according to an embodiment;

[0031] FIG9 is a schematic diagram of the verification process after a slave node receives a proposal message in one embodiment;

[0032] FIG10 is a schematic diagram of a consensus process based on a BFT consensus algorithm in one embodiment;

[0033] FIG11 is a flowchart of clearing expired data in one embodiment;

[0034] FIG12 is a schematic diagram of data cleaning in a traditional manner according to an embodiment;

[0035] FIG13 is a block diagram of a data cleaning device for a blockchain according to an embodiment;

[0036] FIG14 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0038] It should be noted that in the following description, the terms "first, second and third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first, second and third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0039] The system involved in the embodiments of the present invention can be a distributed system including a client and multiple nodes. Multiple nodes and nodes and clients can communicate via a network. The nodes can be maintained by a server or a user terminal. That is, the functional modules of the nodes can be deployed on the server or user terminal, and the server or user terminal implements the functions of the nodes.

[0040] Taking a blockchain system as an example, Figure 1 shows an exemplary distributed system 100, as applied to a blockchain system. The system comprises multiple nodes and clients, forming a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol that runs on top of the Transmission Control Protocol (TCP). In a distributed system, any machine, such as a server or terminal, can join to form a new node. A node comprises a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0041] Referring to Figure 1, the functions of each node in the blockchain system include:

[0042] 1) Routing: A basic function of a node, used to support communication between nodes.

[0043] In addition to the routing function, nodes can also have the following functions:

[0044] 2) Applications, deployed in the blockchain, implement specific services based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

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

[0046] 2.1) Wallet: This provides functions for conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. Upon successful verification by other nodes, the transaction record data is stored in a temporary block of the blockchain as a response to acknowledge the transaction validity). Of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0047] 2.2) Shared ledgers are used to store, query, and modify account data. Records of operations on account data are sent to other nodes in the blockchain system. After verification, other nodes acknowledge the validity of the account data by storing the recorded data in a temporary block. They can also send confirmation to the node that initiated the operation.

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

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

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

[0051] In one embodiment, as shown in FIG3 , a method for clearing blockchain data is provided. This method is described by applying it to the first node in the blockchain system in FIG1 . The first node can be any node in the blockchain system. The method specifically includes the following steps:

[0052] In step 302, when a new block is generated in the blockchain, the transaction deadline tree maintained by the first node itself is obtained, and the expired transaction tasks in the transaction deadline tree are determined.

[0053] A blockchain is a chain of blocks. Each block contains information, connected in chronological order. This chain is stored across all servers, and as long as at least one server in the system is functioning, the entire blockchain remains secure. These servers, called nodes in the blockchain system, provide storage and computing power for the entire system. Modifying information in the blockchain requires the consent of more than half of the nodes and the modification of information across all nodes. These nodes are typically controlled by different entities, making tampering with blockchain information extremely difficult. Compared to traditional networks, blockchains possess two core characteristics: data tampering is difficult, and decentralization is essential. These two characteristics make the information recorded in blockchains more authentic and reliable, helping to address distrust. Blockchains can be classified into public, consortium, and private blockchains. The blockchain system in this application may be a consortium blockchain system.

[0054] After a newly created blockchain is started, when a new block is generated in the blockchain, the master node in the node cluster is responsible for generating a proposal message for the new block and broadcasting the proposal message so that each slave node can verify the proposal message and confirm whether the new block in the proposal message can reach a consensus. When the new block reaches a consensus, each node in the node cluster can add the new block to the local ledger, that is, store the new block. The consensus environment of the blockchain in this application can be a blockchain underlying model based on BFT consensus. Under the blockchain underlying model based on BFT consensus, there are usually master nodes and slave nodes. The master node is responsible for generating a proposal for a new block, which is verified by the slave nodes to confirm whether the block in the proposal can reach a consensus. Among them, BFT (Byzantine Fault Tolerance), that is, Byzantine Fault Tolerance, is a consensus mechanism.

[0055] A new block refers to a newly generated block in the blockchain. For example, if blockchain 1 contains a genesis block and block 1, the new block may be block 1 in blockchain 1.

[0056] A transaction deadline tree is a structure used to store transaction identification information for expired transactions that require clearing. For example, the transaction deadline tree in this application can be a prefix tree structure, which is a multi-branch tree structure. For example, Figure 4 shows a schematic diagram of the transaction deadline tree structure, indicating that the transaction deadline tree in this application can have the structure shown in Figure 4. The transaction deadline tree can include a root node, intermediate nodes, and leaf nodes. The root node is the first-level node in the transaction deadline tree, the leaf node is the last-level node in the transaction deadline tree, and the intermediate node is the node between the first and last levels in the transaction deadline tree. The root node can be based on a daily cycle, with each day corresponding to a transaction deadline tree. The intermediate nodes further divide the time layer by layer, for example, the intermediate nodes can include second-level nodes with hourly granularity and third-level nodes with minute-granularity. The root node and intermediate nodes can represent a target time, which represents the time limit for transaction task expiration. Each target time corresponds to a leaf node, which contains the transaction identification information of the target transaction task that expired at that target time.

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

[0058] Specifically, after a newly created blockchain is started, when a new block is generated in the blockchain and consensus is required, the first node in the node cluster, which serves as the master node, can grab a preset number of transaction tasks from the transaction pool, encapsulate the captured transaction tasks into a proposal message for the new block, and broadcast the proposal message to the slave nodes in the blockchain, so that the slave nodes can reach consensus on the new block based on the transaction tasks in the proposal message.

[0059] In this application, the first node, acting as the master node, can package a preset number of captured transaction tasks into a proposal and broadcast the proposal to all slave nodes in the blockchain in the form of a message. When each slave node receives the proposal message, it can verify all transaction tasks in the proposal message and obtain a verification result. When the verification result indicates that at least one of the transaction tasks in the proposal message is illegal, the slave node generates a voting message that disapproves of the new block consensus. At the same time, the slave node can receive voting messages broadcast by other nodes. When the number of voting messages in favor of the new block consensus meets a preset condition, the new block can reach a consensus, that is, the new block can be added to the blockchain, and each node can also add the new block to its local ledger.

[0060] When the first node, acting as the master node, constructs a new block, it may first determine the expired transaction tasks in the transaction deadline tree it maintains. That is, each node in the node cluster in this application maintains a transaction cleanup tree, which stores the transaction identification information of the expired transaction tasks to be cleaned up. For example, when the first node, acting as the master node, constructs a new block, it may obtain the current time as t1, and based on time t1, search for expired transaction tasks that match the time t1 from the transaction deadline tree it maintains. That is, the first node, acting as the master node, may search for the transaction identification information of the transaction tasks to be cleaned up as of time t1 from the transaction deadline tree it maintains.

[0061] For example, in a blockchain underlying model based on a BFT consensus, after a newly created blockchain is started, when a new block is generated in the newly created blockchain, each node in the node cluster can determine whether it is the first node. For example, each node in the node cluster can determine whether the block generation conditions are met based on the parameters in the block it maintains. When a node determines that it meets the block generation conditions, the node becomes the first node as the master node. The block generation condition refers to the condition used to trigger the block generation. For example, the block generation condition in this application can be set to a height value greater than a preset threshold, and the preset threshold can be 1. The node that generates the block is qualified to encapsulate the transaction task into a proposal message for the block to be consensus.

[0062] Furthermore, after a node (the first node, Node 1) in the node cluster determines itself as the master node, the first node as the master node generates a block and starts a new round of consensus. That is, the first node as the master node is responsible for generating proposals for the new block. As shown in Figure 4, it is a structural diagram of the transaction deadline tree. Assuming that the transaction deadline tree maintained by the first node (Node 1) as the master node is as shown in Figure 4, when the first node (Node 1) as the master node constructs a new block, it can obtain the current time as t1: 12-01-01:01 and search for expired transaction tasks that meet the time t1 from the transaction deadline tree maintained by itself as shown in Figure 4. That is, the first node as the master node can search for the transaction identification information of the transaction tasks to be cleared as of the time t1 from the transaction deadline tree maintained by itself, which includes at least: Tx(1) and Tx(n).

[0063] Step 304: Capture a preset number of transaction tasks from the transaction pool of the blockchain to obtain a preset number of target transaction tasks.

[0064] Among them, the transaction pool is used to receive transaction tasks sent by nodes and transaction tasks sent by clients. The transaction pool has the function of verifying the validity of transaction tasks. In addition to basic verification of whether the transaction tasks are expired and whether the format of the transaction task signature is correct, it is also necessary to verify whether there is double spending in the transaction tasks.

[0065] The preset number refers to the number of transaction tasks that need to be encapsulated in a new block. For example, the preset number may be 100.

[0066] The target transaction task refers to the transaction task selected from the transaction pool by the first node as the master node. For example, the target transaction task in this application can be the transaction task selected from the transaction pool by the first node as the master node according to the processing priority corresponding to the contract of the transaction task from high to low.

[0067] Step 306: Generate a proposal message for a new block based on the expired transaction task and the target transaction task. The proposal message carries the transaction identification information of the expired transaction task.

[0068] Among them, the proposal message is a communication message used when communicating between nodes in the blockchain. For example, the communication message can also include consensus messages, voting messages, etc. The proposal message in this application refers to a message carrying a proposal. For example, a proposal message carries Proposal 1, and Proposal 1 is generated for the newly generated block 1.

[0069] Transaction identification information refers to the transaction identification information corresponding to the expired transaction task. The transaction identification information corresponding to the mid-term transaction task of this application may include at least two types of transaction identification information. For example, the transaction identification information corresponding to the mid-term transaction task of this application may include an expired transaction identification set and an expired transaction hash value.

[0070] The expired transaction identification set refers to a set of transaction identifications of expired transaction tasks. For example, the expired transaction identification set in this application can be an expired transaction ID set. The expired transaction identification set can also be called ExpireTxIDs, which contains a list of transaction task IDs that need to be eliminated.

[0071] The expired transaction hash value refers to the MerkleRoot of the expired transaction identifier set. The expired transaction hash value can also be called ExpireTxRoot.

[0072] Step 308: broadcast the proposal message to the second node in the blockchain. The second node is used to reach a consensus on the new block based on the target transaction task, and clear expired transaction tasks based on the transaction identification information after reaching a consensus.

[0073] The second node refers to a node in the node cluster other than the current node (the first node as the master node). For example, the second node in this application can be each slave node in the node cluster.

[0074] Consensus refers to the consensus on the newly generated new block. Only when the newly generated new block is verified by the nodes and consensus is reached, the new block can be uploaded to the blockchain, and each node can store the new block that has reached consensus in the local ledger.

[0075] Data cleanup refers to the operation of clearing expired data. For example, data cleanup in this application is performed at the transaction task level, clearing the stored data related to expired transaction tasks. For example, for a certain expired transaction task, the state data of the expired transaction task is stored in the state database, and the block data of the expired transaction task is stored in the block database. In actual application scenarios, you can choose to clear only the block data stored in the block database for the expired transaction task, or you can choose to clear both the block data stored in the block database and the state data stored in the state database for the expired transaction task. It is understood that the data cleanup operations in this application include, but are not limited to, deletion, compression, archiving, and backup operations.

[0076] Specifically, when the first node as the master node in the node cluster constructs a new block, after the first node as the master node determines the expired transaction tasks in the transaction deadline tree maintained by itself, the first node as the master node can grab a preset number of transaction tasks from the transaction pool, obtain a preset number of target transaction tasks, and generate a proposal message for the new block based on the expired transaction tasks and the target transaction tasks. The proposal message carries the transaction identification information of the expired transaction tasks, that is, the first node as the master node in this application can package the captured preset number of target transaction tasks into a proposal, and at the same time, the first node as the master node can add the transaction identification information of the expired transaction tasks to the proposal, and broadcast the proposal to all slave nodes in the blockchain in the form of a message.

[0077] Furthermore, when each slave node receives the proposal message, each slave node can verify the transaction identification information of the target transaction task and the expired transaction task in the proposal message to obtain a verification result. The slave node generates an approval message or a disapproval message based on the verification result. At the same time, the slave node can receive voting messages broadcast by other nodes. When the number of approval votes in the voting message meets the preset conditions, the new block can reach a consensus, that is, the new block can be added to the blockchain, and each node can also add the new block to the local ledger; after the new block reaches a consensus, each node can perform a data cleanup step based on the transaction identification information of the expired transaction task carried in the proposal message.

[0078] For example, in the underlying model of a blockchain based on a BFT consensus, as shown in FIG5 , there is a schematic diagram of the proposal process of the first node as the master node. After a newly created blockchain is started, when a new block is generated in the newly created blockchain, each node in the node cluster can determine whether it is the first node as the master node. For example, each node in the node cluster can determine whether the block generation conditions are met based on the parameters in the block it maintains. When a node determines that it meets the block generation conditions, the node becomes the master node. The block generation condition refers to the condition used to trigger the block generation. For example, the block generation condition in this application can be set to a height value greater than a preset threshold, and the preset threshold can be 1. The node that generates the block is qualified to encapsulate the transaction task into a proposal message for the block to be consensus.

[0079] Furthermore, when a certain node (the first node, node 1) in the node cluster determines itself as the first node serving as the master node, the first node serving as the master node generates a block and starts a new round of consensus. The first node serving as the master node is responsible for generating proposals for the new block. That is, when the first node serving as the master node in the node cluster constructs a new block, the first node serving as the master node can obtain the current time t1: 12-01-01:01, and based on time t1, search for expired transaction tasks that meet the time t1 from the transaction deadline tree maintained by itself as shown in FIG4. After that, the first node serving as the master node can grab a preset number of transaction tasks from the transaction pool, obtain a preset number of target transaction tasks, and generate a proposal message for a new block based on the expired transaction tasks and the target transaction tasks. The proposal message carries the transaction identification information of the expired transaction task, that is, the first node serving as the master node in this application. The first node of the point can package a preset number of target transaction tasks that it has captured into a proposal. At the same time, the first node as the master node can add the transaction identification information of the expired transaction task to the proposal. For example, when generating a block, the first node as the master node will add the expired transaction hash value (ExpireTxRoot) to the block header of the new block. The expired transaction hash value (ExpireTxRoot) is the MerkleRoot calculated by the first node as the master node based on the expired transaction ID set, and the proposal will be broadcast to all slave nodes in the blockchain in the form of a message.

[0080] Furthermore, when a slave node receives a proposal message broadcast by the first node as the master node, the slave node can deserialize the proposal message to obtain the processed proposal structure information, and obtain the proposal time and transaction identification information of the expired transaction task from the proposal structure information; the slave node can determine whether the proposal time is legal. When it is determined that the proposal time is legal, the slave node can obtain the local expired transaction task that meets the proposal time from the transaction deadline tree maintained by itself, and compare the transaction identification information of the local expired transaction task with the transaction identification information of the expired transaction task carried in the proposal message to obtain a comparison result.

[0081] Furthermore, when the comparison result indicates that the transaction identification information of the local expired transaction task is consistent with the transaction identification information of the expired transaction task carried in the proposal message, the slave node can further verify the target transaction task in the proposal message, that is, the slave node executes all target transaction tasks contained in the proposal message, obtains the execution result, and determines whether the execution result obtained by itself is consistent with the execution result of the target transaction task carried in the proposal message.

[0082] When the slave node determines that the execution result obtained by itself is consistent with the execution result of the target transaction task carried in the proposal message, the slave node generates an affirmative vote and broadcasts the affirmative vote to other nodes in the form of a message; when the slave node determines that the execution result obtained by itself is inconsistent with the execution result of the target transaction task carried in the proposal message, the slave node generates a negative vote and broadcasts the negative vote to other nodes in the form of a message.

[0083] At the same time, the slave node can receive voting messages broadcast by other nodes. When the number of affirmative votes in the voting message meets the preset conditions, the new block can reach a consensus, that is, the new block can be added to the blockchain, and each node can also add the new block to the local ledger; after the new block reaches a consensus, each node can perform data cleanup steps based on the transaction identification information of the expired transaction task carried in the proposal message.

[0084] For example, in the embodiment of the present application, the step of performing data cleaning can be to perform a data deletion operation based on the transaction identification information of the expired transaction task carried in the proposal message. Among them, the preset condition refers to the pre-set condition for the block to reach a consensus. For example, the preset condition can be set to 2f+1, and f refers to the maximum number of malicious nodes tolerated in this environment. In the Byzantine consensus, it is a 3f+1 model. For example, if there are 4 nodes in the entire environment (blockchain system), then f=1 nodes are allowed to be malicious nodes, and no more. 2f+1 is the number of correct nodes. That is, when the number of affirmative votes in the voting message meets the number 2f+1, the block can reach a consensus.

[0085] Furthermore, if the number of affirmative votes in the voting message does not meet the preset condition (2f+1), the new block cannot reach consensus. That is, if the new block does not reach consensus, the slave nodes will not perform the data cleanup step. In other words, the transaction tasks cleaned in this application must be those in the ledger. This means that the transaction tasks for which data cleanup is performed in this application are those for which consensus has been reached. This effectively avoids cleaning transaction tasks for which consensus has not been reached, and also effectively prevents inconsistent execution status.

[0086] In this embodiment, when constructing a new block, the blockchain determines expired transaction tasks in its own transaction expiration tree; extracts a preset number of transaction tasks from the transaction pool, obtains a preset number of target transaction tasks, and generates a proposal message for the new block based on the expired transaction tasks and the target transaction tasks. The proposal message carries the transaction identification information of the expired transaction tasks; and the proposal message is broadcast to a second node in the blockchain, so that the second node reaches consensus on the new block based on the target transaction tasks. After reaching consensus, the expired transaction tasks are cleared based on the transaction identification information. Because the proposal message for the new block is generated based on the expired transaction tasks and the target transaction tasks, after reaching consensus on the new block, the expired transaction tasks can be automatically cleared based on the transaction identification information of the expired transaction tasks carried in the proposal message. The entire data clearing process is consensus-based and recorded in the blockchain, allowing the data clearing process to be completed simultaneously with consensus, providing high security and traceability. Furthermore, the level of data clearing in the blockchain can be controlled to the transaction level, so that even if different businesses share the same chain, it can be handled without any problems. This ensures the security of the entire blockchain while effectively improving the performance of the entire blockchain.

[0087] In one embodiment, determining expired transaction tasks in the transaction deadline tree includes: obtaining the time of constructing a new block to obtain a first time; and determining expired transaction tasks from the transaction deadline tree based on the first time.

[0088] The first time refers to the time when a new block is generated, which can also be called the proposal time. For example, when the first node as the master node constructs a new block, the first node as the master node can obtain the current timestamp as t1, and t1 is the first time.

[0089] Specifically, under the underlying blockchain model based on BFT consensus, when a node (node ​​1) in the node cluster determines itself as the first node as the master node, the first node as the master node generates a block and starts a new round of consensus. That is, the first node as the master node is responsible for generating proposals for the new block. Assuming that the transaction deadline tree maintained by the first node (node ​​1) as the master node is as shown in Figure 4, when the first node (node ​​1) as the master node constructs a new block, the first node (node ​​1) as the master node can obtain the current time stamp as t1: 12-01-01:01, and based on t1, search for expired transaction tasks that meet the time t1 from the transaction deadline tree maintained by itself as shown in Figure 4. That is, the first node as the master node can search for the transaction identification information of the transaction tasks to be cleared as of the time t1 from the transaction deadline tree maintained by itself, which includes at least: Tx(1) and Tx(n). As a result, the expired transaction tasks to be cleaned can be determined based on the proposal time, and the level of blockchain data cleaning can be controlled to the transaction level. This way, there is no problem even if the same chain is shared between businesses, effectively improving the accuracy of data cleaning.

[0090] In one embodiment, the preset number is at least two, and the blockchain data cleaning method also includes: when a consensus is reached on the new block, obtaining the blockchain identifier, transaction identifier information and transaction expiration time carried by at least two target transaction tasks; based on the blockchain identifier, transaction identifier information and transaction expiration time, generating a transaction deadline tree, the leaf node of the transaction deadline tree contains the transaction identifier information of the target transaction task; when the transaction expiration time of at least two target transaction tasks is the same, storing the transaction identifier information of the at least two target transaction tasks in the same leaf node.

[0091] In one embodiment, when the blockchain is started, the computer device may create a transaction deadline tree; when a consensus is reached on the new block, a root node, an intermediate node, and a leaf node are created in the transaction deadline tree based on the blockchain identifier, transaction identification information, and transaction expiration time carried by at least two target transaction tasks; wherein the leaf node contains the transaction identification information of the target transaction task to be cleared; when the transaction expiration time of at least two target transaction tasks is the same, the transaction identification information of the at least two target transaction tasks is stored in the same leaf node.

[0092] Among them, the blockchain identifier is used to distinguish multiple chains, and can also be called the chain identifier (ChainID). For example, the chain identifier of blockchain 1 is Chain1.

[0093] The transaction identification information refers to the transaction identification of the target transaction task, which may also be referred to as the transaction ID (TxID). For example, the transaction identification of a target transaction task is Tx1.

[0094] The transaction expiration time refers to the pre-set expiration time, which can be a relative time or an absolute time. If it is a relative time, the time starts from the time when the transaction task is created. For example, the expiration time of a target transaction task is: 12-01-01:01 (absolute time).

[0095] The root node refers to the first-level node in the transaction deadline tree. In this application, the root node in the transaction deadline tree can be created based on a time period. For example, a root node with a period of days is created in the transaction deadline tree.

[0096] An intermediate node refers to a node used to represent time information. The intermediate nodes in this application may include second-level nodes and third-level nodes. For example, after creating a root node with a period of days in the transaction period tree, a second-level node with a granularity of hours and a third-level node with a granularity of minutes are created in the transaction period tree.

[0097] The leaf node is used to store the transaction identification information of the transaction tasks to be cleared. For example, the third-level node in this application is the smallest level node, then each third-level node corresponds to a leaf node, which contains the transaction identification information of the transaction tasks to be cleared by the target time represented by the third-level node.

[0098] Specifically, Figure 6 shows a schematic diagram of the information carried by a transaction task. In the basic transaction configuration shown in Figure 6, in order to allow the transaction task to be processed when it expires, an expiration time must be defined in the basic transaction configuration. This expiration time can be relative or absolute. If relative, the timer starts counting from the time the transaction task was created. The basic transaction configuration shown in Figure 6 includes at least: a chain identifier (ChainID), a transaction ID (TxID), a transaction timestamp (Timestamp), a transaction expiration time (ExpirationTime), and contract information.

[0099] When the blockchain is started, a transaction deadline tree is created. That is, after the blockchain is started, each node in the node cluster can locally create a transaction deadline tree as shown in Figure 4. When a new block in the blockchain reaches a consensus, each node can create a root node, intermediate nodes and leaf nodes in the transaction deadline tree maintained by itself based on the blockchain identifier, transaction identifier information and transaction expiration time carried by at least two target transaction tasks contained in the new block. That is, the node can store the transaction identifier information of each transaction task in the transaction deadline tree in the chronological order of the transaction expiration time based on the transaction expiration time of each transaction task. When the transaction expiration time of at least two transaction tasks is the same, the node can store the transaction identifier information of at least two transaction tasks in the same leaf node. That is, the leaf node of the transaction deadline tree as shown in Figure 4 contains a list of transaction IDs to be cleared by the target time corresponding to the leaf node.

[0100] It can be understood that the transaction deadline tree maintained by each node in this application is dynamically changing, that is, as long as a new block in the blockchain reaches a consensus, each node can create a corresponding branch node in the transaction deadline tree maintained by itself based on the blockchain identifier, transaction identifier information and transaction expiration time carried by the target transaction task contained in the new block. It should be noted that when there is no data to be cleaned at a certain time, there is no need to create a corresponding branch node, so as to save memory usage. As a result, the expired transaction tasks to be cleaned can be determined according to the proposal time, and the transaction identifier information of the expired transaction tasks to be cleaned can be stored using the prefix tree structure. The level of blockchain data cleaning can be controlled to the transaction level, so that even if the same chain is shared between businesses, there is no problem, which effectively improves the accuracy of data cleaning; and, by combining the prefix tree structure and the timestamp, the transaction deadline tree structure that each node needs to dynamically maintain is defined, so that the entire cleaning process does not require human participation and is automatically triggered and executed, thereby effectively improving the processing efficiency of the entire blockchain.

[0101] In one embodiment, a transaction deadline tree includes a root node and intermediate nodes, the intermediate nodes include second-level nodes and third-level nodes, and a transaction deadline tree is generated based on a blockchain identifier, transaction identification information, and transaction expiration time, including: based on the blockchain identifier, transaction identification information, and transaction expiration time, creating a root node with a period of days, a second-level node with a granularity of hours, a third-level node with a granularity of minutes, and a leaf node corresponding to a target time represented by the third-level node; wherein the leaf node includes transaction identification information of a target transaction task that expires at the target time.

[0102] Among them, the root node refers to the first-level node in the transaction deadline tree. In this application, the root node in the transaction deadline tree can be created based on a time period. For example, a root node with a period of days is created in the transaction deadline tree.

[0103] An intermediate node refers to a node used to represent time information. The intermediate nodes in this application may include second-level nodes and third-level nodes. For example, after creating a root node with a period of days in the transaction period tree, a second-level node with a granularity of hours and a third-level node with a granularity of minutes are created in the transaction period tree.

[0104] The leaf node is used to store the transaction identification information of the transaction tasks to be cleared. For example, the third-level node in this application is the smallest level node, then each third-level node corresponds to a leaf node, which contains the transaction identification information of the transaction tasks to be cleared by the target time represented by the third-level node.

[0105] Specifically, as shown in Figure 7, it is a schematic diagram of the process of creating a transaction deadline tree. When the new block 1 reaches a consensus, assuming that the target transaction tasks contained in the new block 1 are the transaction tasks shown on the left side of Figure 7: Tx(1):12-01:01:00:50, Tx(2):12-01:01:00:31, Tx(3):12-01:01:05:05, Tx(4):12-01:23:10:11, Tx(5):12-02:04:30:21, then when the new block 1 reaches a consensus, each node can follow The expiration time sequence of each transaction task included in the new block 1 is used to construct the branch nodes of each transaction task in the transaction deadline tree as shown in FIG7 , that is, each node in the node cluster can create a root node with a period of days, a second-level node with a granularity of hours, a third-level node with a granularity of minutes, and a target time (01 :00:50), and store the transaction identification information of the first transaction task Tx(1):12-01:01:00:50 in the leaf node, and you can get the branch node shown in Figure 7 1; similarly, the node can be based on Tx(2):12-01:01:00:31, Tx(3):12-01:01:05:05, Tx(4):12-01:23:10:11, Tx(5):12-02:04:30: 21 carries the transaction expiration time. In this transaction deadline tree, a root node with a period of days, a second-level node with a granularity of hours, a third-level node with a granularity of minutes, and leaf nodes corresponding to the target times represented by the third-level nodes (01:00:31, 01:05:05, 23:10:11, 04:30:21) are created. The transaction identification information of each transaction task is stored in the corresponding leaf node, resulting in the branch nodes shown in 2, 3, and 4 in Figure 7. It can be understood that in the structure of the transaction deadline tree shown in Figure 7, the root node represents days, the second-level node represents hours, the third-level node represents minutes, and the last leaf node contains a list of transaction IDs to be cleared as of the target time corresponding to the leaf node.

[0106] As shown in FIG4 , in order to improve processing performance, it is generally recommended to perform relationship maintenance on the next day's transaction deadline tree near the end of the day, that is, when the time length from the current end reaches the preset time length, for example, there is still 1 hour from the end.

[0107] In addition, it should be noted that the expiration time of the transaction task sent by the user is not allowed to be a historical time, and it is best to reserve a certain time error range.

[0108] In this embodiment, the expired transaction tasks to be cleaned can be determined according to the proposal time, and the transaction identification information of the expired transaction tasks to be cleaned can be stored using the prefix tree structure, so that the level of blockchain data cleaning can be controlled to the transaction level. In this way, there is no problem even if the same chain is shared between businesses, which effectively improves the accuracy of data cleaning; and, by combining the prefix tree structure and the timestamp, the transaction deadline tree structure that each node needs to dynamically maintain is defined, so that the entire cleaning process does not require human participation and is automatically triggered and executed, thereby effectively improving the processing efficiency of the entire blockchain.

[0109] In one embodiment, the transaction identification information includes an expired transaction hash value, and a proposal message for a new block is generated based on the expired transaction task and the target transaction task, including: determining an expired transaction identification set based on the expired transaction task; determining an expired transaction hash value based on the expired transaction identification set; adding the expired transaction hash value to a block header of a new block; and generating a proposal message for a new block based on the block header and the target transaction task.

[0110] In one embodiment, the transaction identification information includes an expired transaction identification set, and generating a proposal message for a new block based on the expired transaction task and the target transaction task includes: determining the expired transaction identification set based on the expired transaction task; adding the expired transaction identification set to the block header of the new block; and generating a proposal message for the new block based on the block header and the target transaction task.

[0111] Specifically, when the first node as the master node in the node cluster constructs a new block, after the first node as the master node determines the expired transaction tasks in the transaction deadline tree maintained by itself, the first node as the master node can grab a preset number of transaction tasks from the transaction pool, obtain a preset number of target transaction tasks, and package the grabbed preset number of target transaction tasks into a proposal. At the same time, the first node as the master node can add the transaction identification information of the expired transaction tasks to the proposal, and broadcast the proposal to all slave nodes in the blockchain in the form of a message.

[0112] The transaction identification information may be at least one of an expired transaction identification set or an expired transaction hash value. The expired transaction hash value is a hash value obtained by performing a hash operation on the expired transaction identification set.

[0113] The first node, serving as the master node, can determine expired transaction tasks from the transaction deadline tree maintained by itself, add the transaction identifier of each expired transaction task to the expired transaction identifier set, and calculate the expired transaction hash value based on the expired transaction identifier set.

[0114] Furthermore, the first node serving as the master node may add the expired transaction hash value to the block header of the new block, thereby generating a proposal message for the new block based on the block header and the target transaction task, so that the transaction identification information of the expired transaction task carried in the proposal message of the new block is the expired transaction hash value.

[0115] The first node as the master node can also directly add the expired transaction identifier set to the block header of the new block, and generate a proposal message for the new block based on the block header and the target transaction task, so that the transaction identifier information of the expired transaction task carried in the proposal message of the new block is the expired transaction identifier set.

[0116] For example, in the underlying blockchain model based on BFT consensus, when the first node as the master node in the node cluster constructs a new block, after determining the expired transaction tasks in the transaction deadline tree maintained by itself, the first node as the master node can grab a preset number of transaction tasks from the transaction pool, obtain a preset number of target transaction tasks, and package the grabbed preset number of target transaction tasks into a proposal. At the same time, the first node as the master node can add the transaction identification information of the expired transaction tasks to the proposal, and broadcast the proposal to all slave nodes in the blockchain in the form of a message.

[0117] Figure 8 shows a schematic diagram of the information carried in a proposal message. The transaction identification information of an expired transaction task, as shown in Figure 8, may include: an expired transaction identification set (ExpireTxIDs) and an expired transaction hash value (ExpireTxRoot). Some proposal messages carry the expired transaction identification set (ExpireTxIDs), while others do not. Therefore, when the first node as the master node in the node cluster constructs a new block, the first node as the master node can store the expired transaction task ID obtained from the transaction deadline tree maintained by itself into the expired transaction identification set, calculate the MerkleRoot of the expired transaction identification set, and use the calculated MerkleRoot of the expired transaction identification set as the expired transaction hash value (ExpireTxRoot); further, the first node as the master node can add the expired transaction hash value (ExpireTxRoot) to the block header of the new block, so that the transaction identification information of the expired transaction task carried in the proposal message of the new block is the expired transaction hash value (ExpireTxRoot); or,

[0118] The first node as the master node can also directly add the expired transaction identification set (ExpireTxIDs) to the block header of the new block, so that the transaction identification information of the expired transaction task carried in the proposal message of the new block is the expired transaction identification set (ExpireTxIDs). That is, the first node as the master node in this application needs to add the cleaned (archived) transaction ID to the proposal when proposing. The proposal is generally a block + node signature, which means that the first node as the master node in this application needs to add the transaction ID set to be cleaned to the new block when constructing the new block. Among them, the expired transaction hash value (ExpireTxRoot) and the proposal time (ProposalTime) are two required fields. The former is the Merkle root calculated for the transaction ID set that needs to be cleaned, and the latter is mainly used to determine the time range for processing. Therefore, by combining the transaction term tree structure and timestamp, the level of blockchain data cleaning can be controlled to the transaction level, so that there is no problem even if the same chain is shared between businesses, which effectively improves the accuracy of data cleaning; and the entire cleaning process does not require human participation and is automatically triggered and executed, thereby effectively improving the processing efficiency of the entire blockchain.

[0119] In one embodiment, the transaction identification information includes an expired transaction identification set and an expired transaction hash value. Based on the expired transaction task and the target transaction task, a proposal message for a new block is generated, including: determining an expired transaction identification set based on the expired transaction task; determining an expired transaction hash value based on the expired transaction identification set; adding the expired transaction identification set and the expired transaction hash value to a block header of a new block; and generating a proposal message for a new block based on the block header and the target transaction task.

[0120] The first node serving as the master node may also add the expired transaction identification set and the expired transaction hash value to the block header of the new block, and generate a proposal message for the new block based on the block header and the target transaction task, so that the transaction identification information of the expired transaction task carried in the proposal message of the new block is the transaction identification information including the expired transaction identification set and the expired transaction hash value.

[0121] Specifically, as shown in Figure 8, which is a schematic diagram of the information carried in a proposal message, the transaction identification information of an expired transaction task as shown in Figure 8 may include: an expired transaction identification set (ExpireTxIDs) and an expired transaction hash value (ExpireTxRoot). Some proposal messages may also carry an expired transaction identification set (ExpireTxIDs) and an expired transaction hash value (ExpireTxRoot). Therefore, when the first node as the master node in the node cluster constructs a new block, the first node as the master node can store the expired transaction task ID obtained from the transaction deadline tree maintained by itself into the expired transaction identification set (ExpireTxIDs), calculate the MerkleRoot of the expired transaction identification set, and use the calculated MerkleRoot of the expired transaction identification set as the expired transaction hash value (ExpireTxRoot); further, the first node as the master node can add both the expired transaction hash value (ExpireTxRoot) and the expired transaction identification set (ExpireTxIDs) to the block header of the new block, so that the transaction identification information of the expired transaction task carried in the proposal message of the new block includes the expired transaction hash value (ExpireTxRoot) and the expired transaction identification set (ExpireTxIDs).

[0122] It's important to note that the proposal message in this application can carry ExpireTxIDs, which contains a list of transaction IDs to be removed after consensus is reached. It's also optional to not carry ExpireTxIDs. Generally, blockchain systems that don't carry ExpireTxIDs have a TPS of minutes, meaning each proposal is sent at least minutes apart to accommodate the transaction expiration tree maintained by each node in this application. If the blockchain system has a higher TPS, ExpireTxIDs must be carried to clearly identify the set of transaction IDs to be cleared.

[0123] In this embodiment, by combining the transaction deadline tree structure and timestamp, the expired transaction tasks to be cleaned up can be determined according to the proposal time, and the level of blockchain data cleaning can be controlled to the transaction level. In this way, there is no problem even if the same chain is shared between businesses, which effectively improves the accuracy of data cleaning; and the entire cleaning process does not require human participation and is automatically triggered and executed, thereby effectively improving the processing efficiency of the entire blockchain.

[0124] In one embodiment, the proposal message carries a first time and an expired transaction hash value, where the first time is the time when a new block is constructed. The second node is also used to deserialize the proposal message to obtain the processed proposal structure information, and obtain the first time from the proposal structure information. When the first time is legal and the expired transaction identifier set is not obtained, the local expired transaction task that meets the first time is obtained from the transaction deadline tree maintained by the second node, the hash value corresponding to the local expired transaction task is determined, and the hash value is compared with the expired transaction hash value to obtain a comparison result. When the comparison result indicates that the hash value is inconsistent with the expired transaction hash value, a dissenting vote information is generated and the dissenting vote information is broadcast to other nodes. The other nodes are nodes other than the second node in the blockchain system.

[0125] Among them, the step of reaching consensus on the new block based on the target transaction task includes: deserializing the proposal message to obtain the processed proposal structure information, obtaining the first time from the proposal structure information, when the first time is legal and the expired transaction identifier set is not obtained, obtaining the local expired transaction task that meets the first time from the transaction deadline tree maintained by the second node, determining the hash value corresponding to the local expired transaction task, comparing the hash value with the expired transaction hash value to obtain a comparison result, when the comparison result indicates that the hash value is inconsistent with the expired transaction hash value, generating dissenting vote information, and broadcasting the dissenting vote information to other nodes, which are nodes in the blockchain system other than the second node.

[0126] Specifically, as shown in Figure 9, it is a schematic diagram of the verification process after the slave node receives the proposal message. After the first node as the master node broadcasts the proposal message carrying the first time (proposal time) and the expired transaction hash value to each slave node in the blockchain, when the slave node receives the proposal message, the process of the slave node verifying the proposal message is shown in Figure 9, that is, the slave node can deserialize the proposal message to obtain the processed proposal structure information, and obtain the first time and expired transaction identifier set from the proposal structure information, that is, the proposal structure contains a field for indicating the proposal time, and a field for indicating the expired transaction identifier set; further, the slave node can determine whether the first time (that is, the proposal time) is legal, and if If the transaction is legal at the first time, the slave node will further determine whether the expired transaction identifier set is an empty set. If the expired transaction identifier set is an empty set, the slave node can obtain the local expired transaction task that meets the first time from the transaction deadline tree maintained by itself, and calculate the hash value corresponding to the local expired transaction task; further, the slave node can compare the hash value calculated by itself with the expired transaction hash value carried in the proposal message to obtain a comparison result; when the comparison result indicates that the hash value calculated by itself is inconsistent with the expired transaction hash value carried in the proposal message, the slave node can generate a dissenting vote message and broadcast the dissenting vote message to other nodes. As a result, the entire data cleaning process is based on consensus and will be written in the blockchain, which has high security and traceability.

[0127] In one embodiment, the second node is further configured to obtain a target transaction task from the proposal structure information and execute the target transaction task when the comparison result indicates that the hash value is consistent with the expired transaction hash value, and obtain an execution result corresponding to the target transaction task. When the execution result is consistent with the execution result carried in the proposal message, an approval vote message is generated and the approval vote message is broadcast to other nodes.

[0128] Among them, after the second node compares the hash value with the expired transaction hash value and obtains the comparison result, when the comparison result indicates that the hash value is consistent with the expired transaction hash value, it obtains the target transaction task from the proposal structure information, executes the target transaction task, and obtains the execution result corresponding to the target transaction task; when the execution result is consistent with the execution result carried in the proposal message, it generates an approval vote message and broadcasts the approval vote message to other nodes.

[0129] Specifically, as shown in Figure 9, it is a schematic diagram of the verification process after the slave node receives the proposal message. After the first node as the master node broadcasts the proposal message carrying the first time (proposal time) and the expired transaction hash value to each slave node in the blockchain, when the slave node receives the proposal message, the process of the slave node verifying the proposal message is shown in Figure 9, that is, the slave node can deserialize the proposal message to obtain the processed proposal structure information, and obtain the first time and expired transaction identification set from the proposal structure information, that is, the proposal structure contains a field for indicating the proposal time, and a field for indicating the expired transaction identification set; further, the slave node can determine whether the first time (that is, the proposal time) is legal. If the first time is legal, the slave node further determines whether the expired transaction identification set is an empty set. If the expired transaction identification set is an empty set, the slave node can obtain the full transaction identification set from the transaction deadline tree maintained by itself. The slave node can complete the local expired transaction tasks in the first place and calculate the hash value corresponding to the local expired transaction tasks; further, the slave node can compare the hash value calculated by itself with the expired transaction hash value carried in the proposal message to obtain a comparison result; when the comparison result indicates that the hash value calculated by itself is consistent with the expired transaction hash value carried in the proposal message, the slave node can continue to verify the target transaction tasks in the proposal message, that is, the slave node can obtain all the target transaction tasks contained in the proposal from the proposal structure information, and execute each target transaction task to obtain the execution result corresponding to each target transaction task; when the execution results of each target transaction task obtained by itself are consistent with the execution results of each target transaction task carried in the proposal message, a vote of approval message is generated and broadcast to other nodes. As a result, the entire data cleaning process is through consensus and will be written in the blockchain, with high security and traceability.

[0130] In one embodiment, the second node is further configured to obtain, from the transaction deadline tree maintained by the second node, a local expired transaction task that meets the first time, if the first time is legal and the expired transaction identifier set is obtained, verify the expired transaction identifier set based on the local expired transaction task, and when the verification passes, execute the step of determining the hash value corresponding to the local expired transaction task.

[0131] Among them, after the second node obtains the first time from the proposal structure information, when the first time is legal and the expired transaction identifier set is obtained, the second node obtains the local expired transaction task that meets the first time from the transaction deadline tree maintained by the second node; the expired transaction identifier set is verified based on the local expired transaction task; when the verification passes, the step of determining the hash value corresponding to the local expired transaction task is executed.

[0132] Specifically, FIG9 is a schematic diagram of the verification process after a slave node receives a proposal message. After the first node, acting as the master node, broadcasts a proposal message carrying the first time and the hash value of the expired transaction to each slave node in the blockchain, when the slave node receives the proposal message, the process of verifying the proposal message by the slave node is shown in FIG9 . That is, the slave node can deserialize the proposal message to obtain the processed proposal structure information, and obtain the first time and the set of expired transaction identifiers from the proposal structure information. Furthermore, the slave node can determine whether the first time (i.e., the proposal time) is valid. If the first time is valid, the slave node further determines whether the set of expired transaction identifiers is an empty set. If the set of expired transaction identifiers is not an empty set, the slave node can obtain a local expired transaction task that meets the first time from the transaction deadline tree maintained by itself, and verify the set of expired transaction identifiers based on the local expired transaction task. That is, the slave node can compare the transaction IDs of each expired transaction task in the set of expired transaction identifiers with the transaction IDs of the local expired transaction task. If the comparison results are consistent, it indicates that the verification has passed, and the slave node can proceed to the step of determining the hash value corresponding to the local expired transaction task. As a result, the entire data cleaning process is reached through consensus and will be written into the blockchain, making it highly secure and traceable.

[0133] In one embodiment, the second node is further configured to generate a negative vote message when the first time is not within a time threshold range, and broadcast the negative vote message to other nodes.

[0134] Among them, after the second node obtains the first time from the proposal structure information, when the first time is not within the time threshold range, it generates a negative vote message; and broadcasts the negative vote message to other nodes.

[0135] Specifically, as shown in Figure 9, it is a schematic diagram of the verification process after the slave node receives the proposal message. After the first node, as the master node, broadcasts the proposal message carrying the first time and the expired transaction hash value to each slave node in the blockchain, when the slave node receives the proposal message, the process of verifying the proposal message by the slave node is shown in Figure 9, that is, the slave node can deserialize the proposal message to obtain the processed proposal structure information, and obtain the first time and expired transaction identifier set from the proposal structure information; further, the slave node can determine whether the first time (i.e., the proposal time) is legal, that is, the slave node can determine whether the first time (i.e., the proposal time) meets the preset time threshold range. If the first time (i.e., the proposal time) is within the preset time threshold range, it indicates that the first time is legal; if the first time (i.e., the proposal time) is not within the preset time threshold range, that is, the first time (i.e., the proposal time) does not meet the preset time threshold range, it indicates that the first time is illegal. That is, when the first time is illegal, the slave node can generate a negative vote message and broadcast the negative vote message to other nodes. As a result, the entire data cleaning process is consensus-based and will be written in the blockchain, with high security and traceability.

[0136] In one embodiment, the second node is further configured to determine the first voting message based on the first initial voting message and the second initial voting message of the second node itself when receiving the second initial voting message broadcast by other nodes, and determine that a consensus has been reached on the new block based on the first voting message and the second voting message when receiving the second voting message broadcast by other nodes, and write the target transaction task and the execution result of the target transaction task into the local ledger. When the block header of the new block carries an expired transaction identifier set, the corresponding transaction task is obtained according to the expired transaction identifier set, the execution result corresponding to the obtained transaction task is obtained from the block database, and the status data corresponding to the transaction task obtained at the current moment is obtained from the status database. When the execution result is consistent with the status data, the status data corresponding to the transaction task is deleted from the status database, and the task data corresponding to the transaction task in the block database is deleted.

[0137] Among them, reaching consensus on the new block based on the target transaction task, and clearing expired transaction tasks based on the transaction identification information after reaching consensus includes: when the second node receives the second initial voting message broadcast by other nodes, the second node determines the first voting message based on its own first initial voting message and the second initial voting message; when the second node receives the second voting message broadcast by other nodes, it determines that the new block has reached consensus based on the first voting message and the second voting message, and writes the target transaction task and the execution result of the target transaction task into the local account book; when the block header of the new block carries an expired transaction identification set, obtaining the corresponding transaction task according to the expired transaction identification set; when the transaction task is in state data deletion mode, obtaining the execution result corresponding to the transaction task from the block database, and obtaining the state data corresponding to the transaction task at the current moment from the state database; comparing the execution result with the state data to obtain a comparison result; when the comparison result indicates that the execution result is consistent with the state data, deleting the state data corresponding to the transaction task from the state database, and deleting the task data corresponding to the transaction task in the block database.

[0138] Among them, the first initial voting message and the first voting message are only used to distinguish the voting messages of different rounds of the current node. For example, the first initial voting message refers to the voting message of the first round of the current node, and the first voting message refers to the voting message of the second round of the current node.

[0139] The second initial voting message and the second voting message are only used to distinguish voting messages of different rounds of other nodes. For example, the second initial voting message refers to the voting message of the first round of other nodes, and the second voting message refers to the voting message of the second round of other nodes.

[0140] It can be understood that the first initial voting message, the second initial voting message, the first voting message, and the second voting message in this application are only used to distinguish the voting messages broadcast by different nodes in different rounds.

[0141] Specifically, as shown in Figure 10, it is a schematic diagram of the consensus process based on the BFT consensus algorithm. Under the underlying model of the blockchain based on the BFT consensus as shown in Figure 10, after a node (Node1) in the node cluster determines that it is the first node (Leader) as the master node, the first node as the master node produces a block and starts a new round of consensus. The first node as the master node can broadcast the proposal message to the slave nodes (Node2, Node3, Node4) in the blockchain, so that the slave nodes (Node2, Node3, Node4) can reach a consensus on the new block based on the transaction tasks in the proposal message; as shown in Figure 10, when a slave node (Node4) in the node cluster receives the proposal message broadcast by the first node as the master node, the slave node (Node4) can execute the verification process shown in Figure 9 to generate a first initial voting message (Prevote vote); when the slave node receives the second initial voting message (Prevote vote) broadcast by other nodes, the slave node can, based on its own first The initial voting message (Prevote vote) and the second initial voting message (Prevote vote) generate a first voting message (PreCommit vote); when the slave node receives the second voting message (PreCommit vote) broadcast by other nodes, the slave node can determine whether the block corresponding to the block identifier in the proposal message can reach a consensus based on the first voting message (PreCommit vote) and the second voting message (PreCommit vote). For example, when the number of voting messages in the first voting message and the second voting message that support the consensus of the block meets the preset condition (the number 2f+1), the slave node can determine that the new block has reached a consensus and submit the account book; or when the number of voting messages in the first voting message and the second voting message that support the consensus of the block does not meet the preset condition (the number 2f+1), the slave node can determine that the new block has not reached a consensus, and can enter the next round of consensus processing.

[0142] Furthermore, as shown in Figure 11, there is a flowchart for clearing expired data. In Figure 11, i represents the transaction number, and i++ indicates that after i participates in the operation, the value of i is incremented by 1. Len (ETxIDs) in Figure 11 represents the number of transaction IDs in the expired transaction ID set ETxIDs. When the slave node determines that the new block has reached consensus and submitted the ledger, if there is an expired transaction ID in the expired transaction identification set (ExpireTxIDs) carried in the block header of the new block, the slave node needs to clean up the corresponding expired data. The processing flow is shown in Figure 11. As shown in the processing flow in Figure 11, when the block header of the new block carries an expired transaction identifier set and an expired transaction ID exists in the expired transaction identifier set (ExpireTxIDs), the slave node can obtain the corresponding transaction information based on the expired transaction ID in the expired transaction identifier set and determine whether the transaction information is in state data deletion mode (StateDB deletion mode); when the transaction information is in state data deletion mode, the slave node can obtain the execution result (key-value pair information) corresponding to the transaction task from the block database (blockDB), and obtain the state data (key-value pair information) corresponding to the transaction task at the current moment from the state database (StateDB), and compare the execution result (key-value pair information) with the state data (key-value pair information) to obtain a comparison result; when the comparison result indicates that the execution result (key-value pair information) is consistent with the state data (key-value pair information), the slave node can delete the state data (key-value pair information) corresponding to the transaction task from the state database and delete the transaction content corresponding to the transaction task in the block database. As a result, the entire data cleaning process is subject to consensus and will be written in the blockchain. The data cleaning process can be completed at the same time as consensus, with high security and traceability. At the same time, the level of data cleaning in the blockchain can be controlled to the transaction level, so that there is no problem even if the same chain is shared between businesses. In addition, the state data in the state database can be cleaned to a certain extent, and more data can be cleaned than in traditional methods, achieving the goal of ensuring the security of the entire blockchain while effectively improving the performance of the entire blockchain.

[0143] In one embodiment, the second node is further configured to delete the task data corresponding to the transaction task in the block database when the execution result is inconsistent with the status data.

[0144] Specifically, Figure 11 shows a flowchart for clearing expired data. When the slave node determines that the new block has reached consensus and is committed to the ledger, if there is an expired transaction ID in the expired transaction identifier set (ExpireTxIDs) carried in the block header of the new block, the slave node needs to clear the corresponding expired data. The processing flow is shown in Figure 11. As shown in the processing flow in Figure 11, when the block header of the new block carries an expired transaction identifier set and an expired transaction ID exists in the expired transaction identifier set (ExpireTxIDs), the slave node can obtain the corresponding transaction information based on the expired transaction ID in the expired transaction identifier set, and determine whether the transaction information is in state data deletion mode (StateDB deletion mode); when the transaction information is in state data deletion mode, the slave node can obtain the execution result (key-value pair information) corresponding to the transaction task from the block database, and obtain the state data (key-value pair information) corresponding to the transaction task at the current moment from the state database, and compare the execution result (key-value pair information) with the state data (key-value pair information) to obtain a comparison result; when the comparison result indicates that the execution result (key-value pair information) is inconsistent with the state data (key-value pair information), the slave node can delete the transaction content corresponding to the transaction task in the block database. That is, when the comparison result indicates that the execution result (key-value pair information) is inconsistent with the state data (key-value pair information), the slave node will not delete the state data corresponding to the transaction task in the state database. That is, the blockchain system in this application can provide two modes of whether to delete StateDB. Because StateDB needs to be used in subsequent contract executions, if the data in StateDB is deleted without considering any other relationships, it may cause problems for the entire business. Therefore, it is not deleted by default, but it can be deleted in some special scenarios, such as the evidence storage scenario where the key does not conflict. Because the key does not conflict, it will not affect subsequent business and can be deleted.

[0145] In this embodiment, to ensure security, in the deletable mode of StateDB, each node in the blockchain system also needs to determine whether the value corresponding to the current key is the value written at the time. If it is, it will be deleted. If not, the data in StateDB will not be deleted. This can ensure a certain degree of security, thereby achieving the goal of ensuring the security of the entire blockchain while effectively improving the performance of the entire blockchain.

[0146] In one embodiment, the present application further provides an application scenario, in which the above-mentioned blockchain data cleaning method is applied. Specifically, the application of the blockchain data cleaning method in this application scenario is as follows:

[0147] When you want to complete the cleaning of expired data at the same time as consensus, you can use the above-mentioned blockchain data cleaning method, that is, in the blockchain system, when the first node as the master node in the node cluster produces a block, when the first node as the master node constructs a new block, the first node as the master node determines the expired transaction tasks in the transaction deadline tree maintained by itself, and grabs a preset number of transaction tasks from the transaction pool. After obtaining the preset number of target transaction tasks, the first node as the master node can generate a proposal message for a new block based on the expired transaction tasks and the target transaction tasks; the proposal message carries the transaction identification information of the expired transaction task; the first node as the master node broadcasts the proposal message carrying the transaction identification information of the expired transaction task to the slave nodes in the blockchain, so that the slave nodes reach a consensus on the new block based on the target transaction task, and after reaching a consensus, clean up the expired transaction tasks based on the transaction identification information of the expired transaction task carried in the proposal message. Since the entire data cleaning process is reached through consensus and will be written in the blockchain, the data cleaning process can be completed at the same time as consensus, which has high security and traceability. At the same time, the level of data cleaning in the blockchain can be controlled to the transaction level, so there is no problem even if the same chain is shared between businesses. This ensures the security of the entire blockchain while effectively improving the performance of the entire blockchain.

[0148] The method provided in the embodiments of this application can be applied to various blockchain consensus scenarios. The following uses a blockchain consensus scenario in a BFT-type consensus environment as an example to illustrate the blockchain data cleaning method provided in the embodiments of this application.

[0149] With the development of technology, blockchain technology has become increasingly mature. Due to the open and transparent nature of blockchain itself, more and more systems are moving their businesses directly to the blockchain.

[0150] Blockchain is essentially a distributed storage system. Each node stores data, and the nodes' storage is data-based. As data volume increases, more and more data needs to be stored. Naturally, the storage performance of some non-distributed data will become increasingly lower. Because blockchain is inherently distributed storage, each node typically uses a non-distributed database, which naturally affects performance.

[0151] In order to improve the overall processing performance, considering that not all data will be needed in the future, combined with the current industry solutions, this application proposes a data cleaning solution based on timestamps that can be accurate to the transaction level. This solution also effectively reduces storage, and most importantly, the cleaning process is automatically executed and agreed upon.

[0152] Figure 12 shows a schematic diagram of traditional data cleansing. The traditional approach is generally called "data archiving," where the blockchain system administrator sends a command to all blockchain nodes (the command is also sent to the blockchain as a transaction). This command typically specifies the height of the archive block, and the blockchain nodes archive all transaction data before that height, thereby reducing the amount of data.

[0153] The archiving method shown in Figure 12 only archives data in blockDB, but not data in stateDB. blockDB is the database that stores the original transaction information, and stateDB is the database that stores the status. The so-called status is the key-value pair operated during the transaction execution process. stateDB handles duplicate keys in an overwriting manner.

[0154] The reason why the data in StateDB is not archived is that there is no way to distinguish the information of the key in StateDB before the specified height (because its value is overwritten); secondly, because the data in StateDB will be needed during the transaction execution process, it cannot be archived arbitrarily.

[0155] The defects of the traditional method are as follows:

[0156] 1. Archiving cannot be done automatically and must be triggered manually by a person, usually an administrator, which is an action that affects the data.

[0157] 2. Archived content cannot be distinguished at the transaction level, but only at the block level. This is not friendly to transactions that are partially available but happen to be within the archive range. In addition, if multiple business systems are in the same chain, archiving behavior may affect other businesses.

[0158] 3. Archiving is a single-point behavior and consensus cannot be reached (or manual consensus is required). Because there is no consensus, inconsistent execution status may occur.

[0159] 4. Data in stateDB cannot be archived.

[0160] Therefore, in order to solve the above problems, this application provides an optimization solution, that is, a method for blockchain data cleaning. In this optimization solution, users can set an expiration time for each transaction. When the expiration time is reached, the blockchain system will delete the corresponding transaction (even including the data in StateDB) through consensus. Therefore, the granularity of its archiving is the transaction level, and because it is a consensus behavior, it is the result of reaching a consensus.

[0161] On the product side, the method provided in this application can be applied to the actual development of blockchain underlying software, and can also be used as a method of external publicity. It can also be implemented at the code level according to the solution of this application to optimize the corresponding blockchain underlying code.

[0162] On the technical side,

[0163] 1.1 Transaction Processing

[0164] In order for a transaction to be processed when it expires, it is necessary to define an expiration time in the transaction. This expiration time can be relative or absolute. If it is relative, it starts from the time the transaction was created, as shown in Figure 6. That is, the transactions archived in this application must be transactions in the ledger. In order to handle the transaction archiving problem more efficiently, this application combines the prefix tree structure with the timestamp to define the transaction maintenance structure shown in Figure 4 - the transaction expiration tree structure. In the structure shown in Figure 4, the root node represents the day, the second-level node represents the hour, the third-level node represents the minute, and the last leaf node contains a list of transaction IDs that need to be cleared as of the time of the third-level node corresponding to the leaf node.

[0165] In order to improve processing performance, it is generally recommended to perform relationship maintenance on the next day's transaction deadline tree near the end of the day (for example, 1 hour before the end).

[0166] The process of creating a transaction deadline tree in this application is shown in FIG7 . It can be understood that branch nodes that do not have data are not created in order to save memory usage.

[0167] 1.2 Transaction Clearance Process

[0168] The consensus algorithm in the embodiment of the present application refers to a BFT consensus algorithm, which generally has several stages as shown in Figure 10.

[0169] The core of the method provided by this application is that the master node needs to add the cleaned (archived) transaction IDs to the proposal when proposing. The so-called proposal is generally a block + node signature, which means that the cleaned transaction ID set needs to be added to the block. The proposal message shown in Figure 8 carries two required fields: ExpireTxRoot and ProposalTime. The former is the Merkle tree root calculated for the set of all transaction IDs that need to be cleaned, and the latter is mainly used to determine the processing time range.

[0170] It is understood that the proposal message shown in Figure 8 may also include ExpireTxIDs, which contains a list of transaction IDs to be removed after consensus is reached. The proposal message does not need to include ExpireTxIDs. Generally, the TPS of blockchain systems that do not include ExpireTxIDs is at the minute level, meaning that each proposal is separated by at least one minute, to accommodate the transaction expiration tree created in this application. If the system's TPS is relatively high, ExpireTxIDs must be included to clearly identify the set of transaction IDs that need to be cleared.

[0171] The proposal process of the master node is adjusted as shown in Figure 5. The core of the process shown in Figure 5 is to add information such as ExpireTxRoot, ProposalTime, and ExpireTxIDs to the blockchain.

[0172] When a slave node receives a proposal, its verification process is shown in Figure 9. The following points need to be noted in the process shown in Figure 9:

[0173] 1) Because the clocks of each node are different, a certain time difference is allowed, but this time difference needs to be within a certain range, such as within 1 minute.

[0174] 2) If the block contains a set of expired transaction IDs, each expired transaction ID must be verified to be valid, that is, to determine if it is a transaction to be cleared. If the block does not contain a set of expired transaction IDs, the proposal time is used as the benchmark, and each slave node calculates the deadline based on the transaction deadline tree maintained in its memory.

[0175] In the third phase of the BFT consensus, after receiving enough PreCommit votes, the node will operate on the current consensus to confirm whether to abandon the operation or commit. When confirming that the new block has reached consensus and is submitted, if there is content in ExpireTxIDs, the node needs to clean up. The processing flow is shown in Figure 11. There are several points to note in the process shown in Figure 11:

[0176] 1) The blockchain system in this application can provide two modes: whether to delete StateDB. Because StateDB needs to be used in subsequent contract execution, if StateDB is deleted without considering any other relationships, it will cause problems for the entire business. Therefore, it is not deleted by default. However, it can be deleted in some special scenarios, such as the evidence storage scenario where the key does not conflict. Since the key does not conflict, it will not affect subsequent business and can be deleted.

[0177] 2) To ensure security, even in the deletable mode of StateDB, the blockchain system needs to determine whether the value corresponding to the current key is the value written at the time. If it is, it will be deleted. This can ensure a certain degree of security, although ABA situations may still exist.

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

[0179] 1. The level of blockchain data cleanup can be controlled to the transaction level, so there is no problem even if the same blockchain is shared between businesses;

[0180] 2. The entire data cleaning process is agreed upon and recorded in the blockchain, ensuring high security and traceability.

[0181] 3. The cleaning process does not require manual participation, improving overall efficiency;

[0182] 4. It can clean up the data in StateDB to a certain extent, and clean up more data than traditional methods.

[0183] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0184] Based on the same inventive concept, embodiments of the present application also provide a blockchain data cleansing device for implementing the aforementioned blockchain data cleansing method. The implementation solution provided by this device is similar to the implementation solution described in the aforementioned method. Therefore, the specific limitations of the one or more blockchain data cleansing device embodiments provided below can be found in the above-mentioned limitations of the blockchain data cleansing method and will not be repeated here.

[0185] In one embodiment, as shown in FIG13 , a data cleaning device for a blockchain is provided, comprising: a determination module 1302 , a capture module 1304 , a generation module 1306 , and a broadcast module 1308 , wherein:

[0186] The determination module 1302 is configured to obtain a transaction deadline tree maintained by the first node when a new block is generated in the blockchain, and determine expired transaction tasks in the transaction deadline tree.

[0187] The capture module 1304 is used to capture a preset number of transaction tasks from the transaction pool of the blockchain to obtain a preset number of target transaction tasks.

[0188] The generation module 1306 is used to generate a proposal message for a new block based on the expired transaction task and the target transaction task, where the proposal message carries the transaction identification information of the expired transaction task.

[0189] The broadcast module 1308 is used to broadcast the proposal message to the second node in the blockchain. The second node is used to reach a consensus on the new block based on the target transaction task and clear expired transaction tasks based on the transaction identification information after reaching a consensus.

[0190] In one embodiment, the device further includes: an acquisition module for acquiring the time of constructing a new block to obtain a first time; and the determination module is further used to determine the expired transaction task from the transaction deadline tree based on the first time.

[0191] In one embodiment, the preset number is at least two; the apparatus further comprises: a creation module and a storage module, the creation module being configured to obtain, after consensus is reached on the new block, blockchain identifiers, transaction identifier information, and transaction expiration times carried by at least two target transaction tasks;

[0192] Based on the blockchain identifier, transaction identification information and transaction expiration time, a transaction deadline tree is generated, and the leaf nodes of the transaction deadline tree contain the transaction identification information of the target transaction task; the storage module is used to store the transaction identification information of at least two target transaction tasks in the same leaf node when the transaction expiration time of at least two target transaction tasks is the same.

[0193] In one embodiment, the transaction deadline tree includes a root node and intermediate nodes, the intermediate nodes include second-level nodes and third-level nodes, and the creation module is further used to create a root node with a period of days, a second-level node with a granularity of hours, a third-level node with a granularity of minutes, and a leaf node corresponding to the target time represented by the third-level node based on the blockchain identifier, transaction identification information, and transaction expiration time; wherein the leaf node includes the transaction identification information of the target transaction task that expires at the target time.

[0194] In one embodiment, the transaction identification information includes an expired transaction hash value, and the generation module 1306 is further used to determine an expired transaction identification set based on the expired transaction task; determine an expired transaction hash value based on the expired transaction identification set; add the expired transaction hash value to the block header of the new block; and generate a proposal message for the new block based on the block header and the target transaction task.

[0195] In one embodiment, the transaction identification information includes an expired transaction identification set, and the generation module 1306 is further used to determine the expired transaction identification set based on the expired transaction task; add the expired transaction identification set to the block header of the new block; and generate a proposal message for the new block based on the block header and the target transaction task.

[0196] In one embodiment, the transaction identification information includes an expired transaction identification set and an expired transaction hash value. The generation module 1306 is further used to determine the expired transaction identification set based on the expired transaction task; determine the expired transaction hash value based on the expired transaction identification set; add the expired transaction identification set and the expired transaction hash value to the block header of the new block; and generate a proposal message for the new block based on the block header and the target transaction task.

[0197] In one embodiment, the proposal message carries a first time and an expired transaction hash value, where the first time is the time when a new block is constructed. The second node is also used to deserialize the proposal message to obtain the processed proposal structure information, and obtain the first time from the proposal structure information. When the first time is legal and the expired transaction identifier set is not obtained, the local expired transaction task that meets the first time is obtained from the transaction deadline tree maintained by the second node, the hash value corresponding to the local expired transaction task is determined, and the hash value is compared with the expired transaction hash value to obtain a comparison result. When the comparison result indicates that the hash value is inconsistent with the expired transaction hash value, a dissenting vote information is generated and the dissenting vote information is broadcast to other nodes. The other nodes are nodes other than the second node in the blockchain system.

[0198] In one embodiment, the second node is further configured to obtain the target transaction task from the proposal structure information and execute the target transaction task when the comparison result indicates that the hash value is consistent with the expired transaction hash value, and obtain the execution result corresponding to the target transaction task. When the execution result is consistent with the execution result carried in the proposal message, an approval vote message is generated and the approval vote message is broadcast to other nodes.

[0199] In one embodiment, the second node is further used to obtain a local expired transaction task that meets the first time from the transaction deadline tree maintained by the second node, if the first time is legal and the expired transaction identifier set is obtained, and verify the expired transaction identifier set based on the local expired transaction task. When the verification passes, determine the hash value corresponding to the local expired transaction task.

[0200] In one embodiment, the second node is further configured to generate a negative vote message when the first time is not within a time threshold range, and broadcast the negative vote message to other nodes.

[0201] The second node is also used to determine the first voting message based on the first initial voting message and the second initial voting message of the second node itself when receiving the second initial voting message broadcast by other nodes, and determine that a consensus has been reached on the new block based on the first voting message and the second voting message when receiving the second voting message broadcast by other nodes, and write the target transaction task and the execution result of the target transaction task into the local account book. When the block header of the new block carries an expired transaction identifier set, the corresponding transaction task is obtained according to the expired transaction identifier set, the execution result corresponding to the obtained transaction task is obtained from the block database, and the status data corresponding to the transaction task obtained at the current moment is obtained from the status database. When the execution result is consistent with the status data, the status data corresponding to the transaction task is deleted from the status database, and the task data corresponding to the transaction task in the block database is deleted.

[0202] In one embodiment, the second node is further configured to delete the task data corresponding to the transaction task in the block database when the execution result is inconsistent with the status data.

[0203] Each module in the blockchain data cleansing device described above can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a computer device memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0204] In one embodiment, a computer device is provided, which may be a server. A diagram of its internal structure may be shown in Figure 14. The computer device includes a processor, memory, an input / output (I / O) interface, and a communication interface. The processor, memory, and I / O interface are connected via a system bus, and the communication interface is connected to the system bus via the I / O interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer-readable instructions, and a database. The internal memory provides an environment for the operation of the operating system and computer-readable instructions in the non-volatile storage medium. The database of the computer device stores blockchain block data and status data. The I / O interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals via a network connection. When executed by the processor, the computer-readable instructions implement a blockchain data cleanup method.

[0205] Those skilled in the art will understand that the structure shown in FIG14 is merely a block diagram of a portion 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 shown in the figure, or combine certain components, or have a different arrangement of components.

[0206] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores computer-readable instructions, and the processor implements the steps in the above-mentioned method embodiments when executing the computer-readable instructions.

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

[0208] In one embodiment, a computer program product is provided, comprising computer-readable instructions, which implement the steps in the above-mentioned method embodiments when executed by a processor.

[0209] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data 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 the relevant laws, regulations and standards of relevant countries and regions.

[0210] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through computer-readable instructions. The computer-readable instructions can be stored in a non-volatile computer-readable storage medium. When the computer-readable instructions are executed, they can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0211] The technical features of the above embodiments can be combined arbitrarily. 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.

[0212] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A method for cleaning blockchain data, performed by a computer device maintaining a first node in a blockchain system, the method comprising: When a new block is generated in the blockchain, the transaction deadline tree maintained by the first node itself is obtained, and the expired transaction tasks in the transaction deadline tree are determined; Capturing a preset number of transaction tasks from the transaction pool of the blockchain to obtain a preset number of target transaction tasks; Based on the expired transaction task and the target transaction task, a proposal message of the new block is generated, wherein the proposal message carries the transaction identification information of the expired transaction task; and The proposal message is broadcast to a second node in the blockchain, and the second node is used to reach a consensus on the new block based on the target transaction task, and clean up the expired transaction task based on the transaction identification information after reaching a consensus.

2. The method according to claim 1, wherein determining the expired transaction tasks in the transaction deadline tree comprises: Obtaining the time of constructing the new block to obtain the first time; Based on the first time, an expired transaction task is determined from the transaction deadline tree.

3. The method according to claim 1 or 2, wherein the preset number is at least two, and the method further comprises: When the new block reaches a consensus, the blockchain identifier, transaction identifier information and transaction expiration time carried by at least two of the target transaction tasks are obtained; Based on the blockchain identifier, the transaction identifier information and the transaction expiration time, a transaction deadline tree is generated, wherein a leaf node of the transaction deadline tree includes the transaction identifier information of the target transaction task; When the transaction expiration times of at least two target transaction tasks are the same, the transaction identification information of the at least two target transaction tasks are stored in the same leaf node.

4. The method according to claim 3, wherein the transaction deadline tree comprises a root node and an intermediate node, wherein the intermediate node comprises a second-level node and a third-level node, and wherein generating the transaction deadline tree based on the blockchain identifier, the transaction identifier information and the transaction expiration time comprises: Based on the blockchain identifier, the transaction identifier information and the transaction expiration time, create a root node with a period of days, a second-level node with a granularity of hours, a third-level node with a granularity of minutes, and a leaf node corresponding to the target time represented by the third-level node; The leaf node includes transaction identification information of a target transaction task that expires at the target time.

5. According to the method according to any one of claims 1 to 4, the transaction identification information includes an expired transaction hash value, and the generating of the proposal message of the new block based on the expired transaction task and the target transaction task comprises: Determine an expired transaction identifier set based on the expired transaction task; Determine an expired transaction hash value according to the expired transaction identifier set; Adding the expired transaction hash value to the block header of the new block; A proposal message for the new block is generated according to the block header and the target transaction task.

6. According to the method according to any one of claims 1 to 4, the transaction identification information includes an expired transaction identification set, and the generating of the proposal message of the new block based on the expired transaction task and the target transaction task comprises: Determine an expired transaction identifier set based on the expired transaction task; Adding the expired transaction identifier set to the block header of the new block; A proposal message for the new block is generated according to the block header and the target transaction task.

7. According to the method according to any one of claims 1 to 4, the transaction identification information includes an expired transaction identification set and an expired transaction hash value, and the generating the proposal message of the new block based on the expired transaction task and the target transaction task comprises: Determine an expired transaction identifier set based on the expired transaction task; Determine an expired transaction hash value according to the expired transaction identifier set; Adding the expired transaction identifier set and the expired transaction hash value to the block header of the new block; A proposal message for the new block is generated according to the block header and the target transaction task.

8. According to the method described in any one of claims 1 to 7, the proposal message carries a first time and an expired transaction hash value, the first time is the time for constructing the new block, the second node is also used to deserialize the proposal message to obtain the processed proposal structure information, obtain the first time from the proposal structure information, when the first time is legal and the expired transaction identifier set is not obtained, obtain the local expired transaction task that meets the first time from the transaction deadline tree maintained by the second node, determine the hash value corresponding to the local expired transaction task, compare the hash value with the expired transaction hash value to obtain a comparison result, when the comparison result indicates that the hash value is inconsistent with the expired transaction hash value, generate negative vote information, and broadcast the negative vote information to other nodes, the other nodes are nodes in the blockchain system other than the second node.

9. According to the method described in claim 8, the second node is also used to obtain the target transaction task from the proposal structure information and execute the target transaction task when the comparison result indicates that the hash value is consistent with the expired transaction hash value, and obtain the execution result corresponding to the target transaction task. When the execution result is consistent with the execution result carried in the proposal message, an approval vote message is generated and the approval vote message is broadcast to the other nodes.

10. According to the method described in claim 8 or 9, the second node is also used to obtain local expired transaction tasks that meet the first time from the transaction deadline tree maintained by the second node when the first time is legal and the expired transaction identifier set is obtained, and verify the expired transaction identifier set based on the local expired transaction task, and when the verification passes, execute the step of determining the hash value corresponding to the local expired transaction task.

11. According to the method according to any one of claims 8 to 10, the second node is further used to generate a negative vote message when the first time is not within a time threshold range, and broadcast the negative vote message to the other nodes.

12. According to the method described in any one of claims 1 to 11, the second node is also used to determine the first voting message based on the first initial voting message of the second node itself and the second initial voting message when receiving the second initial voting message broadcast by other nodes, and when receiving the second voting message broadcast by the other nodes, determine that the new block has reached a consensus based on the first voting message and the second voting message, and write the target transaction task and the execution result of the target transaction task into the local account book; when the block header of the new block carries an expired transaction identifier set, obtain the corresponding transaction task according to the expired transaction identifier set, obtain the execution result corresponding to the obtained transaction task from the block database, and obtain the status data corresponding to the obtained transaction task at the current moment from the status database; when the execution result is consistent with the status data, delete the status data corresponding to the transaction task from the status database, and delete the task data corresponding to the transaction task in the block database.

13. According to the method of claim 12, the second node is also used to delete the task data corresponding to the transaction task in the block database when the execution result is inconsistent with the status data.

14. A data cleaning device for a blockchain, the device comprising: A determination module, configured to obtain a transaction deadline tree maintained by the first node itself and determine expired transaction tasks in the transaction deadline tree when a new block is generated in the blockchain; A capture module, used to capture a preset number of transaction tasks from the transaction pool of the blockchain to obtain a preset number of target transaction tasks; A generating module, configured to generate a proposal message of the new block based on the expired transaction task and the target transaction task, wherein the proposal message carries transaction identification information of the expired transaction task; and A broadcast module is used to broadcast the proposal message to a second node in the blockchain, and the second node is used to reach a consensus on the new block based on the target transaction task, and clean up the expired transaction task based on the transaction identification information after reaching a consensus.

15. A computer device, comprising a memory and a processor, wherein the memory stores computer-readable instructions, and the processor implements the method according to any one of claims 1 to 13 when executing the computer-readable instructions.

16. A computer-readable storage medium having computer-readable instructions stored thereon, wherein the computer-readable instructions implement the method according to any one of claims 1 to 13 when executed by a processor.

17. A computer program product, comprising computer readable instructions, which implement the method according to any one of claims 1 to 13 when executed by a processor.

Images