Transaction information processing method and device applied to blockchain, medium and equipment

Abstract

Embodiments of the present application provide a transaction information processing method and device applied to a blockchain, a medium and equipment. A local transaction pool of a blockchain node contains a first transaction queue and a second transaction queue, the first transaction queue is used to store transaction information to be packed into a block, and the second transaction queue is used to store transaction information contained in a block to be chained. The transaction information processing method comprises: obtaining a first block to be verified, and performing verification processing on the first block; if the first block is verified, adding transaction information contained in the first block to the second transaction queue, and deleting the transaction information contained in the first block from the first transaction queue; if the first block is submitted to chain, deleting the transaction information contained in the first block from the second transaction queue. The technical scheme of the embodiments of the present application can improve the management effectiveness of transaction information, thereby ensuring the efficient and correct operation of the blockchain consensus mechanism.

Description

Technical Field

[0001] This application relates to the fields of computer and communication technology, and more specifically, to a method, apparatus, medium, and device for processing transaction information applied to blockchain. Background Technology

[0002] In blockchain technology, if a transaction is repeatedly packaged into blocks at different heights, when the preceding block in memory is confirmed and uploaded to the chain, subsequent blocks uploaded to the chain will become invalid again because the same transaction already exists on the chain, and on-chain consensus will no longer be possible.

[0003] Therefore, newly generated blocks are not allowed to contain transaction information already included in previous blocks that have been uploaded to the chain or cached. However, due to consensus mechanisms, multiple blocks may exist at a certain height, but only one block will be committed to the chain. The transaction information in the discarded block needs to be added back to the transaction pool to avoid losing valid transaction information. Thus, it is evident that effectively managing transaction information and ensuring the efficient and correct operation of the consensus mechanism are pressing technical problems that need to be solved in blockchain technology. Summary of the Invention

[0004] The embodiments of this application provide a method, apparatus, medium, and device for processing transaction information applied to blockchain, which can at least to some extent improve the effectiveness of transaction information management and ensure the efficient and correct operation of the blockchain consensus mechanism.

[0005] According to one aspect of the embodiments of this application, a transaction information processing method applied to blockchain is provided. The local transaction pool of a blockchain node includes a first transaction queue and a second transaction queue. The first transaction queue is used to store transaction information to be packaged into a block, and the second transaction queue is used to store transaction information contained in a block to be uploaded to the blockchain. The transaction information processing method includes: obtaining a first block to be verified, and verifying the first block; if the verification of the first block is successful, adding the transaction information contained in the first block to the second transaction queue and deleting the transaction information contained in the first block from the first transaction queue; if the first block is submitted to the blockchain, deleting the transaction information contained in the first block from the second transaction queue.

[0006] According to one aspect of the embodiments of this application, a transaction information processing device applied to a blockchain is provided. The local transaction pool of a blockchain node includes a first transaction queue and a second transaction queue. The first transaction queue is used to store transaction information to be packaged into a block, and the second transaction queue is used to store transaction information contained in a block to be uploaded to the blockchain. The transaction information processing device includes: an acquisition unit configured to acquire a first block to be verified; a verification unit configured to verify the first block; a first processing unit configured to, if the verification of the first block is successful, add the transaction information contained in the first block to the second transaction queue and delete the transaction information contained in the first block from the first transaction queue; and a second processing unit configured to, if the first block is submitted to the blockchain, delete the transaction information contained in the first block from the second transaction queue.

[0007] In some embodiments of this application, based on the foregoing scheme, the verification unit is configured to: obtain the block height corresponding to the transaction information contained in the first block in the local transaction pool; if the block height corresponding to the transaction information contained in the first block in the local transaction pool is less than the block height of the first block, then it is determined that the verification of the first block has failed.

[0008] In some embodiments of this application, based on the foregoing scheme, the verification unit is configured to: obtain the block height in the local transaction pool corresponding to the transaction information contained in the first block from the second transaction queue in the local transaction pool.

[0009] In some embodiments of this application, based on the foregoing scheme, the verification unit is further configured to: if the transaction information contained in the first block does not exist in the second transaction queue, then determine that the block height corresponding to the transaction information contained in the first block in the local transaction pool is not less than the block height of the first block.

[0010] In some embodiments of this application, based on the foregoing scheme, the first processing unit is further configured to: if the block height corresponding to the transaction information contained in the first block in the local transaction pool is less than the block height of the first block, then delete the transaction information in the first block whose corresponding block height in the local transaction pool is less than the block height of the first block from the first transaction queue of the local transaction pool.

[0011] In some embodiments of this application, based on the foregoing scheme, the verification unit is further configured to: if the block height corresponding to the transaction information contained in the first block in the local transaction pool is not less than the block height of the first block, or if the transaction information contained in the first block is in the first transaction queue in the local transaction pool, then detect whether the transaction information contained in the first block already exists in the blockchain; if the transaction information contained in the first block does not exist in the blockchain, then determine that the first block has passed verification.

[0012] In some embodiments of this application, based on the foregoing scheme, the verification unit is further configured to: if the transaction information contained in the first block already exists in the blockchain, determine that the verification of the first block has failed, and delete the transaction information in the first block that already exists in the blockchain from the first transaction queue of the local transaction pool.

[0013] In some embodiments of this application, based on the foregoing scheme, the first processing unit is further configured to: when adding the transaction information contained in the first block to the second transaction queue, record the block height of the first block as the block height corresponding to the transaction information contained in the first block in the local transaction pool.

[0014] In some embodiments of this application, based on the foregoing scheme, the verification unit is further configured to: before verifying the first block, if the first block contains target transaction information that does not exist in the local transaction pool, then verify the signature of the target transaction information; after the signature verification of the target transaction information is passed, add the target transaction information to the first transaction queue of the local transaction pool.

[0015] In some embodiments of this application, based on the foregoing scheme, the second processing unit is further configured to: if the first block is submitted to the chain, delete the transaction information contained in the first block from the first transaction queue.

[0016] In some embodiments of this application, based on the foregoing scheme, the transaction information processing device further includes: a generation unit configured to, if selected as a proposal node, obtain transaction information to be packaged into a block from the first transaction queue and generate a second block based on the obtained transaction information; and a third processing unit configured to transmit the second block to a consensus node in the blockchain network for consensus processing and move the transaction information contained in the second block from the first transaction queue to the second transaction queue.

[0017] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the transaction information processing method applied to blockchain as described in the above embodiments.

[0018] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the transaction information processing method applied to blockchain as described in the above embodiments.

[0019] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the transaction information processing method applied to blockchain provided in the various optional embodiments described above.

[0020] In some embodiments of this application, the technical solutions provide that by setting up a first transaction queue and a second transaction queue in the local transaction pool of a blockchain node, the first transaction queue stores transaction information to be packaged into a block, and the second transaction queue stores transaction information to be uploaded to the blockchain. This allows for effective management of transaction information in different states (i.e., to be packaged into a block and to be uploaded to the blockchain) through the two transaction queues. Furthermore, by adding the transaction information contained in the first block to the second transaction queue after the first block has been verified and deleting it from the first transaction queue, and by deleting the transaction information contained in the first block from the second transaction queue after the first block has been submitted to the blockchain, the transaction information stored in the local transaction pool can be managed according to the processing progress of the transaction information (e.g., whether verification has passed or whether it has been submitted to the blockchain). This improves the effectiveness of transaction information management and ensures the efficient and correct operation of the blockchain consensus mechanism.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0023] Figure 1 A schematic diagram of the blockchain network structure is shown;

[0024] Figure 2 This diagram illustrates the connection relationships between blocks in a blockchain.

[0025] Figure 3 A schematic diagram of a node broadcast block according to an embodiment of this application is shown;

[0026] Figure 4 The flowchart illustrating the verification of newly generated blocks in a blockchain is shown.

[0027] Figure 5 A schematic diagram of a blockchain network structure is shown.

[0028] Figure 6 A flowchart illustrating a transaction information processing method applied to a blockchain according to an embodiment of this application is shown;

[0029] Figure 7 A flowchart illustrating a transaction information processing method applied to a blockchain according to an embodiment of this application is shown;

[0030] Figure 8 A block diagram of a transaction information processing apparatus applied to a blockchain according to an embodiment of this application is shown;

[0031] Figure 9 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0032] Exemplary embodiments will now be described in a more comprehensive manner with reference to the accompanying drawings. However, the exemplary embodiments can be implemented in various forms and should not be construed as limited to these examples; rather, these embodiments are provided so that this application will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art.

[0033] Furthermore, the features, structures, or characteristics described in this application can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to provide a full understanding of the embodiments of this application. However, those skilled in the art will recognize that when implementing the technical solutions of this application, not all the detailed features in the embodiments may be used, one or more specific details may be omitted, or other methods, elements, devices, steps, etc., may be employed.

[0034] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0036] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0037] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks (i.e., blocks) linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block. A blockchain can include an underlying platform, a platform product and service layer, and an application service layer.

[0038] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Furthermore, under authorization, it monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information through a consensus algorithm (consensus management). After encryption, the data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the key or other events are invoked to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product release, such as alarms, monitoring network conditions, and monitoring the health status of node devices.

[0039] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0040] As mentioned above, a blockchain is essentially a decentralized database, and it is maintained collaboratively by nodes within a blockchain network. For example, in... Figure 1 The illustrated blockchain network may include multiple nodes 101, which can be various clients forming the blockchain network. Each node 101, in its normal operation, receives input information and maintains shared data within the blockchain network based on this information. To ensure interoperability within the blockchain network, information connections can exist between each node, allowing for information transmission. For example, when any node in the blockchain network receives input information, other nodes in the network obtain this input information according to a consensus algorithm and store it as shared data, ensuring data consistency across all nodes in the blockchain network.

[0041] Each node in a blockchain network has a corresponding node identifier, and each node can store the node identifiers of other nodes. This allows for the broadcast of generated blocks to other nodes in the blockchain network based on their node identifiers. Each node can maintain a list of node identifiers, storing the node name and its corresponding node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0042] Each node in a blockchain network stores the same blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 2 As shown, a blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information features, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information features of the current block, the block header features of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0043] In a blockchain network, each node can be a server or a terminal device. A server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Terminal devices can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart home devices, in-vehicle terminals, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0044] Another crucial technology in blockchain is the consensus mechanism, which is fundamental to ensuring the normal operation of the blockchain system. Consensus means reaching an agreement. Each node in a blockchain system stores its own copy of the distributed ledger (i.e., the blockchain itself). The consensus process is the process of ensuring consistency between these distributed ledgers across all nodes. Some or all nodes in the blockchain system can participate in the consensus process. This process is typically based on a consensus algorithm, with participating nodes executing the corresponding steps of the consensus process by running the algorithm. PoS (Proof of Work), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) are some examples of suitable consensus algorithms.

[0045] Typically, at a certain block height in a blockchain, one or more rounds of consensus processes are required to reach agreement among the participating node devices. Block height represents the number of blocks connected to the blockchain. It acts as a marker, indicating the block's position within the blockchain. For example, the default block height for the genesis block is 0, the first block after the genesis block has a block height of 1 (this first block can be simply referred to as block 1), the second block after the genesis block has a block height of 2 (this second block can be simply referred to as block 2), and so on.

[0046] For example, if the current block height of a blockchain is 300 (referred to as block 300), this means that 300 blocks have been stacked on top of the genesis block, resulting in 301 blocks on the blockchain from the genesis block to block 300. The consensus process at a specific block height refers to the process of reaching consensus on the blocks to be added to the blockchain when the blockchain is at that height. If the consensus is successful, the block is added to the blockchain, and the block height is incremented by 1. For instance, the consensus process at block height 10 refers to the process of reaching consensus on the blocks to be added to the blockchain when the blockchain is at block height 10. If the consensus is successful, the block is added to the blockchain, increasing the block height from 10 to 11.

[0047] Generally, a consensus process can be divided into three phases in sequence: the proposal phase, the pre-voting phase, and the pre-commit phase. The multiple nodes participating in the same consensus process include two types: proposal nodes and non-proposal nodes. A proposal node is a node elected by the participating nodes. This node is responsible for both generating the block to be agreed upon during the proposal phase and broadcasting it to the other participating nodes for consensus processing; it is also responsible for processing the block itself. Non-proposal nodes, on the other hand, only process the blocks to be agreed upon.

[0048] Consensus processing includes pre-voting and pre-committing. Pre-voting occurs during the pre-voting phase, while pre-committing occurs during the pre-committing phase. Pre-voting refers to the process of agreeing to pre-vote on a block to be included in the consensus framework. A pre-vote indicates agreement to add the block to the blockchain. Pre-committing refers to the process of agreeing to pre-commit a block to be included in the consensus framework. A pre-commit indicates confirmation of agreement to add the block to the blockchain. In multiple rounds of consensus at the same block height, the participating node devices may change in different rounds. Specifically, the node devices participating in each round may change, the proposing nodes may change, and the blocks awaiting consensus may also change.

[0049] The following example illustrates the specific process of the Ni-th consensus round at block height H of the blockchain in this application embodiment, where H, N, and i are all positive integers, and i is less than N. Taking i=1 as an example, in the (N-1)-th consensus round at block height H of the blockchain, a total of 4 node devices participate in the consensus process. Figure 3 This illustration shows a block broadcasting diagram of a consensus node according to an embodiment of this application; as shown Figure 3 As shown, the node devices participating in the consensus process in the blockchain system are node device A, node device B, node device C, and node device D. In the (N-1)th round of consensus at block height H, node device B is the proposing node, and node devices A, C, and D are non-proposing nodes. The specific process of the (N-1)th round of consensus at block height H includes:

[0050] I. Proposal Stage:

[0051] First, node device B (i.e., the proposing node) generates a target block Block-X to be reached for consensus. This Block-X can be a new block created by node device B. Then, node device B broadcasts the target block Block-X to node devices A, C, and D.

[0052] II. Pre-voting stage:

[0053] Due to network failures, equipment malfunctions, or other reasons, some nodes may fail to receive Block-X broadcast by node B in the first instance. For example, if node A does not receive Block-X broadcast by node B in the first instance, while nodes C and D do receive it, then during the pre-voting phase, nodes B, C, and D will all use Block-X as the target block for consensus and perform pre-voting processing to obtain their respective pre-voting information. This pre-voting information includes the identifier of the block for which pre-voting processing has been performed. For example, if node C performs pre-voting processing on Block-X to generate its own pre-voting information, this information includes the identifier of Block-X, indicating that node C agrees to pre-vote on Block-X, meaning it agrees to add Block-X to the blockchain. Block-X thus receives node C's pre-vote.

[0054] Understandably, if node device C does not generate its pre-voting information, it means that node device C has not pre-voted for Block-X; if node device C's pre-voting information does not include the identifier of Block-X, it means that node device C does not agree to pre-vote for Block-X, i.e., it does not agree to add Block-X to the blockchain. Since node device A did not receive Block-X in the first instance, it can identify the empty block emptyBlock as the target block to be reached for consensus and pre-vote for emptyBlock to obtain node device A's pre-voting information, which includes the identifier of emptyBlock. The "first instance" can be set according to actual needs, such as 1 minute, 3 minutes, etc.

[0055] Node devices A, B, C, and D each broadcast their own pre-voting information. Due to network failures, device malfunctions, or other reasons, some node devices may not receive the pre-voting information broadcast by other node devices in the second time. Therefore, when the second time arrives, each node device participating in the consensus process counts the number of pre-votes obtained by the target block to be reached during the pre-voting phase based on the pre-voting information received in the second time, and confirms whether the number of pre-votes exceeds the threshold. This threshold can be set according to the actual situation; for example, the threshold can be 50% of the number of node devices participating in the consensus process, or 2 / 3 of the number of node devices participating in the consensus process. The second time can also be set according to actual needs, such as 1 minute, 3 minutes, etc.; the second time can be the same as or different from the first time.

[0056] For example: Assume the threshold is 2. Since node A only pre-votes for emptyBlock, its pre-voting information includes the emptyBlock identifier. Nodes B, C, and D all pre-vote for Block-X, and their pre-voting information all includes the Block-X identifier. Simultaneously, assume node A only receives pre-voting information from node B. Combining this with node A's own pre-voting information, we find that Block-X received 1 pre-vote, confirming that the number of pre-votes received by Block-X did not exceed the threshold of 2. Now, suppose node B receives pre-voting information from nodes A, C, and D. Combining this with node B's own pre-voting information, we find that Block-X received 3 pre-votes, confirming that the number of pre-votes received by Block-X exceeded the threshold of 2. Similarly, suppose node C receives three pre-vote messages from nodes A, B, and D. Combining these with its own pre-vote information, it calculates that Block-X received 3 pre-votes, confirming that Block-X's pre-vote count exceeds the threshold of 2. Similarly, suppose node D also receives three pre-vote messages from nodes A, B, and C. Combining this with its own pre-vote information, it calculates that Block-X received 3 pre-votes, confirming that Block-X's pre-vote count exceeds the threshold of 2.

[0057] III. Pre-submission stage:

[0058] Node devices B, C, and D all identify Block-X as the target block for consensus, and therefore each performs pre-commit processing on Block-X to obtain its own pre-commit information. This pre-commit information includes the identifier of the block to which pre-commit processing was performed. For example, node device C performs pre-commit processing on Block-X to generate node device C's pre-commit information. This pre-commit information includes the identifier of Block-X, and it indicates that node device C agrees to pre-commit Block-X, that is, confirms its agreement to add Block-X to the blockchain. Block-X thus receives node device C's pre-commit.

[0059] Understandably, if node device C does not generate its pre-commit information, it means that node device C has not pre-committed Block-X; if node device C's pre-commit information does not include the identifier of Block-X, it means that node device C does not agree to pre-commit Block-X, that is, it does not agree to add Block-X to the blockchain. Node device A, having identified the empty block emptyBlock as the target block for consensus, performs pre-commit processing on emptyBlock, resulting in node device A's pre-commit information, which includes the identifier of emptyBlock.

[0060] Node devices A, B, C, and D each broadcast their own pre-commit information. Due to network failures, device failures, or other reasons, some node devices may not receive the pre-commit information broadcast by other node devices within the third time period. Upon arrival of the third time period, each participating node device calculates the number of pre-commits received during the pre-commit phase of the target block to be reached for consensus based on the pre-commit information received within the third time period, and confirms whether this number of pre-commits exceeds the commit threshold. This commit threshold can be set according to actual conditions; for example, it could be 50% of the number of participating node devices or 2 / 3 of the number of participating node devices. The third time period can also be set according to actual needs, such as 1 minute, 3 minutes, etc.; the third time period can be the same as or different from the second time period; similarly, the third time period can be the same as or different from the first time period.

[0061] For example: Suppose the commit threshold is 2. Since node device A only performs pre-commit processing on emptyBlock, its pre-commit information includes the emptyBlock identifier. Node devices B, C, and D all perform pre-commit processing on Block-X, and their pre-commit information all includes the Block-X identifier. Simultaneously, suppose node device B receives pre-commit information from nodes A and C, and based on its own pre-commit information, calculates that Block-X obtained 2 pre-commits during the pre-commit phase, confirming that the number of pre-commits obtained by Block-X does not exceed (or is not greater than) the commit threshold of 2. Similarly, suppose node device C receives pre-commit information from nodes A and C, and based on its own pre-commit information, calculates that Block-X obtained 2 pre-commits, confirming that the number of pre-commits obtained by Block-X does not exceed (or is not greater than) the commit threshold of 2. Similarly, suppose node A receives three pre-commit messages from nodes B, C, and D. Combining this with node A's own pre-commit information, the pre-commit count obtained by Block-X is calculated to be 3, confirming that the pre-commit count obtained by Block-X exceeds the commit threshold of 2. Suppose node D also receives three pre-commit messages from nodes A, B, and C. Combining this with node D's own pre-commit information, the pre-commit count obtained by Block-X is calculated to be 3, confirming that the pre-commit count obtained by Block-X exceeds the commit threshold of 2.

[0062] After the three consensus phases described above, if the number of pre-votes received by the target block to be reached exceeds the threshold, and the number of pre-commits received also exceeds the commit threshold, then the target block to be reached successfully and can be added to the blockchain; otherwise, the consensus fails and it cannot be added to the blockchain. Following the example above, node device A confirms that the number of pre-commits received by Block-X exceeds the commit threshold, but the number of pre-votes received does not exceed the threshold, therefore, Block-X consensus is considered to have failed. Node device B confirms that the number of pre-votes received by Block-X exceeds the threshold, but the number of pre-commits received does not exceed the commit threshold, therefore, Block-X consensus is considered to have failed. Node device C confirms that the number of pre-votes received by Block-X exceeds the threshold, but the number of pre-commits received does not exceed the commit threshold, therefore, Block-X consensus is considered to have failed. Node device D confirms that the number of pre-votes received by Block-X exceeds both the threshold and the commit threshold, therefore, Block-X consensus is considered to have succeeded, and node device D adds Block-X to the blockchain stored locally on node device D.

[0063] In summary, during the (N-1)th round of consensus at block height H of the blockchain, node devices A, B, and C did not reach a consensus on Block-X and did not write Block-X into their respective distributed ledgers (i.e., add it to their local blockchain storage). However, node device D reached a consensus on Block-X and wrote Block-X into its own distributed ledger. Therefore, the block height of the blockchain stored locally by node device D becomes H+1. During the Nth round of consensus at block height H of the blockchain, node device D will no longer participate in the consensus, and the node devices participating in the consensus will change to node devices A, B, and C.

[0064] It should be noted that when conducting the Nth round of consensus process at block height H of the blockchain, the proposing node may change. For example, in the above example, the proposing node in the (N-1)th round of consensus process at block height H of the blockchain is node device B, but in the Nth round of consensus process at block height H of the blockchain, it may change to node device C. Then, the above three consensus phases are re-executed to complete the Nth round of consensus process at block height H of the blockchain.

[0065] Most consensus algorithms currently used (such as PoW and Raft) employ a block-by-block upload mechanism. This means that once a new block is verified by a consensus node, it is immediately uploaded to the blockchain. Furthermore, in these algorithms, each node's transaction pool maintains only one queue of transactions to be packaged, and when verifying a new block, only the conflict between the new block and existing on-chain data is checked. Specifically... Figure 4 The process of generating and verifying a new block mainly includes the following steps:

[0066] In step S401, after selecting a node as the proposer, the proposer obtains transaction information from the local transaction pool to generate a new block.

[0067] In step S402, the proposing node transmits the generated new block to the verifier node, also known as the consensus node, via the network.

[0068] Step S403: The verification node verifies whether the transactions in the new block conflict with the on-chain data. If there is no conflict, the verification is successful, and the data can then be processed on the chain.

[0069] The optimized consensus algorithm HotStuff proposes a View-based consensus protocol. A View represents a consensus unit, and the consensus process is composed of a series of Views. Within a View, a definite Leader (master node) governs the consensus protocol, and consensus is reached through a three-phase voting process. Then, the process switches to the next View to continue the consensus process. If an abnormal situation occurs and a View times out and fails to reach consensus, the process also switches to the next View to continue the consensus process.

[0070] Meanwhile, the QC (Quality of Consensus) set of the current block is collected by the leader node of the next View and included in the next block. When a consensus node receives the next block, it verifies the validity of the current block and also verifies the validity of the QC of the previous block, that is, it verifies whether it contains votes from 2f+1 consensus nodes, indicating whether the previous block has been confirmed by a majority of nodes. In other words, the process of reaching consensus on the block is included in the process of generating the next new block. Here, f is the largest integer less than (N-1) / 3, N is the number of consensus nodes in the blockchain network, and f is the number of malicious consensus nodes in the blockchain network that the algorithm can tolerate.

[0071] HotStuff, as an optimized three-phase BFT protocol, requires each block to be confirmed three times by consensus nodes on the chain before it can be submitted to the chain. Therefore, when a block of height H is generated and submitted to the chain, it will be confirmed sequentially at blocks of heights H+1, H+2, and H+3. During the waiting period for confirmation, the nodes will cache blocks of heights H, H+1, and H+2 in their memory.

[0072] However, newly generated blocks are not allowed to contain transaction information that is already on-chain or cached in previous blocks, to prevent the same transaction information from being uploaded to the chain repeatedly. If a transaction is repeatedly packaged into blocks at different heights, then when a previous block in memory is confirmed and uploaded to the chain, subsequent blocks uploaded to the chain will become invalid again because the same transaction information already exists on the chain, and on-chain consensus will no longer be possible. Therefore, when generating a new block, it is necessary not only to remove transaction information already existing on the chain, but also to remove transaction information contained in blocks cached by nodes. Furthermore, due to consensus mechanisms, multiple blocks may exist at a certain height, but only one block will be committed to the chain. Transaction information in the discarded block needs to be added back to the transaction pool to avoid losing valid transaction information. It is evident that effective management of transaction information is the foundation for ensuring the efficient and correct operation of the consensus mechanism. However, most current consensus algorithms only maintain a queue of transactions to be packaged during implementation and cannot support other optimized consensus algorithms. This is obviously difficult to meet the actual needs of blockchain projects that provide multiple distributed consensus mechanisms, such as Chainmake.

[0073] Based on this, the embodiments of this application provide a new transaction information processing scheme applied to blockchain, which can not only support the consensus mechanism of block-by-block on-chain, but also the consensus mechanism of the HotsSuff algorithm.

[0074] Specifically, such as Figure 5 As shown, this example uses a blockchain network with 5 nodes (node ​​1, node 2, node 3, node 4, and node 5). Each node's local transaction pool contains a first transaction queue and a second transaction queue. The first transaction queue stores transaction information to be packaged into a block, and the second transaction queue stores transaction information to be included in the block to be uploaded to the chain.

[0075] If a node is selected as a proposal node, such as node 1, then node 1 can obtain the transaction information to be packaged into a block from the first transaction queue of the local transaction pool, generate a new block based on the obtained transaction information, transmit the generated new block to other nodes for consensus processing, and move the transaction information contained in the generated new block from the first transaction queue to the second transaction queue.

[0076] If a node obtains a block to be verified, it can verify the block. After successful verification, the node adds the transaction information contained in the block to the second transaction queue and removes the transaction information from the first transaction queue. If the block to be verified is committed to the blockchain, the transaction information contained in the block is removed from the second transaction queue.

[0077] As can be seen, the technical solution of this application embodiment enables the management of transaction information stored in the local transaction pool according to the processing progress of transaction information (such as whether the verification is successful or whether it is submitted to the chain), thereby improving the management effectiveness of transaction information and ensuring the efficient and correct operation of the blockchain consensus mechanism.

[0078] The following details the various implementation details of the technical solutions in the embodiments of this application:

[0079] Figure 6 A flowchart illustrating a transaction information processing method applied to a blockchain according to an embodiment of this application is shown. The local transaction pool of a blockchain node includes a first transaction queue and a second transaction queue. The first transaction queue stores transaction information to be packaged into a block, and the second transaction queue stores transaction information to be included in blocks to be uploaded to the blockchain. Figure 6 The transaction information processing method shown can be executed by blockchain nodes.

[0080] Specifically, refer to Figure 6 As shown, the transaction information processing method applied to blockchain includes at least steps S610 to S630, which are described in detail below:

[0081] In step S610, the first block to be verified is obtained, and the first block is verified.

[0082] Optionally, the first block to be verified can be a block broadcast by the proposing node to the blockchain network that requires consensus processing before being uploaded to the blockchain. Specifically, the proposing node can obtain the transaction information to be packaged from the local transaction pool, then package the obtained transaction information to generate a block, and then broadcast the generated new block in the blockchain network for consensus processing before uploading to the blockchain.

[0083] In one embodiment of this application, when verifying the first block, the block height corresponding to the transaction information contained in the first block in the local transaction pool can be obtained. If the block height corresponding to the transaction information contained in the first block in the local transaction pool is less than the block height of the first block, it is determined that the verification of the first block has failed.

[0084] Optionally, the block heights corresponding to each transaction information contained in the first block in the local transaction pool can be obtained separately. If the block height corresponding to one or more of the transaction information in the local transaction pool is less than the block height of the first block, it can be determined that the verification of the first block has failed.

[0085] Specifically, if the transaction information contained in the first block has a block height in the local transaction pool that is less than the block height of the first block, it means that the transaction information contained in the first block has already been packaged into the block before the first block. In order to avoid the transaction information being packaged repeatedly, further processing of the first block can be stopped. At this time, it can be determined that the verification of the first block has failed.

[0086] Optionally, since the second transaction queue stores transaction information from the pre-packaged blocks to be added to the blockchain, the block height corresponding to the transaction information contained in the first block in the local transaction pool can be obtained from the second transaction queue of the local transaction pool.

[0087] Meanwhile, if the transaction information contained in the first block does not exist in the second transaction queue, it means that the transaction information contained in the first block may exist in the first transaction queue or may not exist in the local transaction pool. The first transaction queue stores the transaction information to be packaged into a block. Therefore, in this case, it can be determined that the block height corresponding to the transaction information contained in the first block in the local transaction pool is not less than the block height of the first block. That is, the transaction information contained in the first block has not been packaged into the block before the first block.

[0088] In one embodiment of this application, if the transaction information contained in the first block corresponds to a block height in the local transaction pool that is less than the block height of the first block, it indicates that the transaction information contained in the first block has already been packaged into a block preceding the first block. In this case, in addition to confirming the failure of verifying the first block, to avoid packaging duplicate transaction information onto the chain, transaction information in the first block whose corresponding block height in the local transaction pool is less than the block height of the first block can be deleted from the first transaction queue of the local transaction pool. This also ensures that transaction information in the first block whose corresponding block height in the local transaction pool is not less than the block height of the first block can be repackaged to avoid missing unpackaged transaction information.

[0089] In one embodiment of this application, if the transaction information contained in the first block corresponds to a block height in the local transaction pool that is not less than the block height of the first block, or if the transaction information contained in the first block is in the first transaction queue in the local transaction pool, then it is checked whether the transaction information contained in the first block already exists in the blockchain. If the transaction information contained in the first block does not exist in the blockchain, then it is determined that the first block has passed verification. That is, in this embodiment, in addition to verifying the block height corresponding to the transaction information in the first block in the local transaction pool (i.e., verifying whether the transaction information in the first block has been packaged before), it is also necessary to verify whether this transaction information already exists in the blockchain. Only if the transaction information in the first block has not been packaged before and does not exist in the blockchain can it be determined that the first block has passed verification.

[0090] Optionally, if the transaction information contained in the first block already exists in the blockchain, the verification of the first block can be determined to have failed, and the transaction information already existing in the blockchain in the first block can be deleted from the first transaction queue of the local transaction pool. This can also ensure that the transaction information in the first block that does not exist in the blockchain can be repackaged later to avoid missing unpackaged transaction information.

[0091] Similarly, when verifying whether the transaction information contained in the first block exists in the blockchain, each transaction in the first block can be verified individually. If one or more of the transactions already exist in the blockchain, the verification of the first block fails. Only when none of the transactions in the first block exist in the blockchain can the verification of the first block be considered successful.

[0092] In one embodiment of this application, before verifying the first block, it can be detected whether the transaction information contained in the first block exists in the local transaction pool. If the first block contains target transaction information that does not exist in the local transaction pool, it means that the target transaction information was not previously stored in the local transaction pool. Then, the signature of the target transaction information can be verified. After the signature verification of the target transaction information is successful, the target transaction information can be added to the first transaction queue of the local transaction pool, and then the verification process of the first block can be performed.

[0093] In step S620, if the first block is verified, the transaction information contained in the first block is added to the second transaction queue and the transaction information contained in the first block is deleted from the first transaction queue.

[0094] Specifically, if the first block passes verification, it means that the first block is a block that can be added to the chain. At this time, the transaction information contained in the first block can be added to the second transaction queue, and can be deleted from the first transaction queue.

[0095] Optionally, when the first block is verified and the transaction information contained in the first block is added to the second transaction queue, the block height of the first block can be recorded as the block height corresponding to the transaction information contained in the first block in the local transaction pool, which is beneficial for verifying the transaction information contained in subsequent blocks to be verified.

[0096] Continue to refer to Figure 6 As shown, in step S630, if the first block is submitted to the chain, the transaction information contained in the first block is deleted from the second transaction queue.

[0097] Optionally, after the first block is verified, the transaction information contained in the first block is added to the second transaction queue and deleted from the first transaction queue. However, due to network latency or slow deletion speed, the transaction information in the first block may still be stored in the first transaction queue after the first block is submitted to the chain. Therefore, the transaction information contained in the first block can be deleted from the first transaction queue after the first block is submitted to the chain. This ensures that after the first block is submitted to the chain, neither of the two queues in the local transaction pool (i.e., the first transaction queue and the second transaction queue) stores the transaction information contained in the first block.

[0098] In one embodiment of this application, if a blockchain node is selected as a proposal node, the proposal node can obtain transaction information to be packaged into a block from a first transaction queue, generate a second block based on the obtained transaction information, and then transmit the second block to the consensus nodes in the blockchain network for consensus processing. The transaction information contained in the second block is then moved from the first transaction queue to the second transaction queue. Optionally, after the proposal node transmits the generated second block to the consensus nodes in the blockchain network, these consensus nodes can verify the second block and perform on-chain processing according to the technical solutions of the foregoing embodiments of this application.

[0099] As can be seen, the technical solution of this application embodiment can manage the transaction information stored in the local transaction pool according to the processing progress of the transaction information (such as whether the verification is successful or whether it is submitted to the chain), which improves the management effectiveness of the transaction information and thus ensures the efficient and correct operation of the blockchain consensus mechanism.

[0100] The following uses the aforementioned first transaction queue as a regular queue (storing transaction information to be packaged into a block) and the second transaction queue as a queue to be deleted (storing transaction information already included in a block and awaiting to be added to the chain) as an example to elaborate on the implementation details of the technical solution of this application embodiment:

[0101] In summary, the technical solution of this application mainly involves maintaining a regular queue and a queue to be deleted in the local transaction pool of the blockchain node. Since the queue to be deleted stores transaction information that has already been included in a block, the queue to be deleted can maintain the block height of each transaction (for ease of distinction, this block height is recorded as the transaction height). When a proposing node generates a new block, it can retrieve transaction information from the regular queue to fill the new block and move this batch of transaction information to the queue to be deleted.

[0102] When a validator node verifies a new block, it can check if the transaction information in the new block exists in the transaction pool. If it does, it returns the block height where the transaction information is located (i.e., the transaction height). If the transaction height is less than the new block height, it can be determined that the transaction information has already been packaged into the preceding block of the new block, and the new block verification fails. It should be noted that when the transaction information in the new block is in the ordinary queue, it means that the transaction information has not yet been packaged into the block, and it can be determined that the transaction information has not been packaged into the preceding block of the new block.

[0103] If the block containing the transaction information in the new block has a height at least equal to the block height of the new block, and the transaction information in the new block does not exist in the blockchain, then the new block can be considered verified. When the new block is verified, the blockchain node can add the transaction information within the new block to the deletion queue and simultaneously delete the transactions contained in the block from the regular queue. When the new block is committed to the blockchain, the blockchain node can delete the transaction information within the new block from both queues in the local transaction pool.

[0104] The specific process is as follows: Figure 7 As shown, it includes the following steps:

[0105] In step S701, after selecting a node as the proposer, the proposer obtains transaction information from the local transaction pool to generate a new block.

[0106] Optionally, a consensus module can be set up in the blockchain network. The consensus module can detect whether the current node has been selected as a proposal node (the proposal node needs to generate a new block at a specified height) at the current height of the blockchain. If it is a proposal node, it notifies the core engine module to extract transactions from the ordinary queue of the local transaction pool, generate a new block, and update the local transaction pool status of the proposal node, that is, to move the transaction information used to generate a new block from the ordinary queue to the queue to be deleted.

[0107] In step S702, the proposing node transmits the generated new block to the verification node, also known as the consensus node, through the network so that the consensus node can verify the new block and process it for consensus on the blockchain.

[0108] In step S703, the consensus node, acting as a validator, obtains the status of the transaction information contained in the new block generated by the proposal node in the local transaction pool. Specifically, it obtains whether the transaction information contained in the new block exists in the local transaction pool. If it exists in the deletion queue in the local transaction pool, it obtains the height information (i.e., transaction height) of the transaction information in the new block in the local transaction pool.

[0109] In step S704, after obtaining the height information of the transaction information in the new block within its local transaction pool, the consensus node determines whether the transaction information in the new block conflicts with the transaction information in the deletion queue of the local transaction pool. Specifically, it determines whether the transaction height of the transaction information in the new block is less than the block height of the new block. If the transaction height of the transaction information in the new block is less than the block height of the new block, it indicates a conflict between the transaction information in the new block and the transaction information in the deletion queue of the local transaction pool, and the verification of the new block fails.

[0110] Step S705: If the transaction height of the transaction information in the new block is not less than the block height of the new block, it means that the transaction information in the new block does not conflict with the transaction information in the queue to be deleted in the local transaction pool of the consensus node. At this time, it can be determined that the first step of verification has passed.

[0111] Step S706: The consensus node obtains the status of the transaction information in the new block on the chain, i.e., whether it exists on the chain.

[0112] In step S707, after obtaining the on-chain state of the transaction information in the new block, the consensus node determines whether the transaction information in the new block conflicts with the on-chain state. That is, it determines whether the transaction information in the new block already exists on the chain. If the transaction information in the new block does not exist on the chain, it means that the transaction information in the new block does not conflict with the on-chain state. If the transaction information in the new block already exists on the chain, it means that the transaction information in the new block conflicts with the on-chain state, indicating that the transaction information in the new block has been uploaded to the chain. At this point, the verification of the new block is deemed to have failed.

[0113] Step S708: If the transaction information in the new block does not conflict with the on-chain state, then the second step of verification is confirmed to be successful.

[0114] In step S709, if both the first and second steps of the new block are verified, the consensus node moves the transaction information contained in the new block from the normal queue to the queue to be deleted in the local transaction pool.

[0115] If a consensus node submits a new block to the chain, all transaction information in the new block can be deleted from the two queues in the local transaction pool.

[0116] The reason why the two queues (i.e., the ordinary queue and the queue to be deleted) in the local transaction pool are updated at each step of block processing (generation, verification, and submission) in this embodiment is that the consensus nodes in the blockchain network adopt a mechanism of taking turns producing blocks. At each block height, a consensus node is selected to generate a block, and other consensus nodes receive the block generated by the proposal node at that height and verify it. Therefore, when a block is generated at a certain block height, the proposal node will operate on the ordinary queue and the queue to be deleted in the local transaction pool in advance. After receiving the block, other consensus nodes also need to use the data of the block to update the two queues in their own local transaction pool. When submitting a block, for the purpose of defensive programming (for example, due to network latency or slow deletion speed, the ordinary queue may still store the transaction information of the block after it is submitted to the chain), not only is the queue to be deleted deleted, but the ordinary queue is also cleared again.

[0117] The technical solution of this application uses a dual-queue implementation, enabling the node's local transaction pool to support both blockchain projects employing block-by-block confirmation mechanisms (such as PoW and Raft) and BFT consensus mechanisms optimized with cached state (such as HotStuff). It also unifies the processing flow under different consensus algorithms and records transaction data within cached blocks in the local transaction pool instead of other modules, achieving a highly cohesive data state for the node. Furthermore, it improves the effectiveness of transaction information management, thereby ensuring the efficient and correct operation of the blockchain consensus mechanism.

[0118] The following describes an apparatus embodiment of this application, which can be used to execute the transaction information processing method applied to blockchain described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the above embodiments of the transaction information processing method applied to blockchain described in this application.

[0119] Figure 8The diagram illustrates a block diagram of a transaction information processing apparatus for a blockchain according to an embodiment of this application. The local transaction pool of a blockchain node includes a first transaction queue and a second transaction queue. The first transaction queue stores transaction information to be packaged into a block, and the second transaction queue stores transaction information to be included in blocks to be uploaded to the blockchain. Figure 8 The transaction information processing device shown can be installed within a blockchain node.

[0120] Reference Figure 8 As shown, a transaction information processing device 800 for blockchain according to an embodiment of this application includes: an acquisition unit 802, a verification unit 804, a first processing unit 806, and a second processing unit 808.

[0121] The acquisition unit 802 is configured to acquire the first block to be verified; the verification unit 804 is configured to perform verification processing on the first block; the first processing unit 806 is configured to add the transaction information contained in the first block to the second transaction queue and delete the transaction information contained in the first block from the first transaction queue if the first block is verified successfully; the second processing unit 808 is configured to delete the transaction information contained in the first block from the second transaction queue if the first block is submitted to the chain.

[0122] In some embodiments of this application, based on the foregoing scheme, the verification unit 804 is configured to: obtain the block height corresponding to the transaction information contained in the first block in the local transaction pool; if the block height corresponding to the transaction information contained in the first block in the local transaction pool is less than the block height of the first block, then it is determined that the verification of the first block has failed.

[0123] In some embodiments of this application, based on the foregoing scheme, the verification unit 804 is configured to: obtain the block height in the local transaction pool corresponding to the transaction information contained in the first block from the second transaction queue in the local transaction pool.

[0124] In some embodiments of this application, based on the foregoing scheme, the verification unit 804 is further configured to: if the transaction information contained in the first block does not exist in the second transaction queue, then determine that the block height corresponding to the transaction information contained in the first block in the local transaction pool is not less than the block height of the first block.

[0125] In some embodiments of this application, based on the foregoing scheme, the first processing unit 806 is further configured to: if the block height corresponding to the transaction information contained in the first block in the local transaction pool is less than the block height of the first block, then delete the transaction information in the first block whose corresponding block height in the local transaction pool is less than the block height of the first block from the first transaction queue of the local transaction pool.

[0126] In some embodiments of this application, based on the foregoing scheme, the verification unit 804 is further configured to: if the block height corresponding to the transaction information contained in the first block in the local transaction pool is not less than the block height of the first block, or if the transaction information contained in the first block is in the first transaction queue in the local transaction pool, then detect whether the transaction information contained in the first block already exists in the blockchain; if the transaction information contained in the first block does not exist in the blockchain, then determine that the first block has been verified.

[0127] In some embodiments of this application, based on the foregoing scheme, the verification unit 804 is further configured to: if the transaction information contained in the first block already exists in the blockchain, determine that the verification of the first block has failed, and delete the transaction information in the first block that already exists in the blockchain from the first transaction queue of the local transaction pool.

[0128] In some embodiments of this application, based on the foregoing scheme, the first processing unit 806 is further configured to: when adding the transaction information contained in the first block to the second transaction queue, record the block height of the first block as the block height corresponding to the transaction information contained in the first block in the local transaction pool.

[0129] In some embodiments of this application, based on the foregoing scheme, the verification unit 804 is further configured to: before verifying the first block, if the first block contains target transaction information that does not exist in the local transaction pool, then verify the signature of the target transaction information; after the signature verification of the target transaction information is passed, add the target transaction information to the first transaction queue of the local transaction pool.

[0130] In some embodiments of this application, based on the foregoing scheme, the second processing unit 808 is further configured to: if the first block is submitted to the chain, delete the transaction information contained in the first block from the first transaction queue.

[0131] In some embodiments of this application, based on the foregoing scheme, the transaction information processing device 800 further includes: a generation unit configured to, if selected as a proposal node, obtain transaction information to be packaged into a block from the first transaction queue and generate a second block based on the obtained transaction information; and a third processing unit configured to transmit the second block to a consensus node in the blockchain network for consensus processing and move the transaction information contained in the second block from the first transaction queue to the second transaction queue.

[0132] Figure 9 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0133] It should be noted that, Figure 9 The computer system 900 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0134] like Figure 9 As shown, the computer system 900 includes a Central Processing Unit (CPU) 901, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 902 or programs loaded from storage portion 908 into Random Access Memory (RAM) 903, such as performing the methods described in the above embodiments. The RAM 903 also stores various programs and data required for system operation. The CPU 901, ROM 902, and RAM 903 are interconnected via a bus 904. An Input / Output (I / O) interface 905 is also connected to the bus 904.

[0135] The following components are connected to I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to I / O interface 905 as needed. Removable media 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 910 as needed so that computer programs read from them can be installed into storage section 908 as needed.

[0136] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 909, and / or installed from removable medium 911. When the computer program is executed by central processing unit (CPU) 901, it performs various functions defined in the system of this application.

[0137] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0138] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0139] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0140] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0141] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0142] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0143] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0144] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for processing transaction information applied to blockchain, characterized in that, The local transaction pool of a blockchain node contains a first transaction queue and a second transaction queue. The first transaction queue stores transaction information to be packaged into a block, and the second transaction queue stores transaction information contained in a block to be uploaded to the blockchain. The transaction information processing method includes: Obtain the first block to be verified and perform verification processing on the first block; If the first block is verified, the transaction information contained in the first block is added to the second transaction queue, and the transaction information contained in the first block is deleted from the first transaction queue. If the first block is submitted to the chain, the transaction information contained in the first block will be deleted from the second transaction queue. The verification process for the first block includes: Obtain the block height corresponding to the transaction information contained in the first block in the local transaction pool; If the transaction information contained in the first block corresponds to a block height in the local transaction pool that is less than the block height of the first block, then the verification of the first block is determined to have failed, and the transaction information in the first block whose corresponding block height in the local transaction pool is less than the block height of the first block is deleted from the first transaction queue of the local transaction pool.

2. The transaction information processing method applied to blockchain according to claim 1, characterized in that, Obtaining the block height corresponding to the transaction information contained in the first block in the local transaction pool includes: Obtain the block height corresponding to the transaction information contained in the first block in the local transaction pool from the second transaction queue of the local transaction pool.

3. The transaction information processing method applied to blockchain according to claim 2, characterized in that, The transaction information processing method further includes: If the transaction information contained in the first block does not exist in the second transaction queue, then it is determined that the block height corresponding to the transaction information contained in the first block in the local transaction pool is not less than the block height of the first block.

4. The transaction information processing method applied to blockchain according to claim 1, characterized in that, The verification process for the first block also includes: If the block height corresponding to the transaction information contained in the first block in the local transaction pool is not less than the block height of the first block, or if the transaction information contained in the first block is in the first transaction queue of the local transaction pool, then it is detected whether the transaction information contained in the first block already exists in the blockchain. If the transaction information contained in the first block does not exist in the blockchain, then the first block is determined to have passed verification.

5. The transaction information processing method applied to blockchain according to claim 4, characterized in that, The transaction information processing method further includes: If the transaction information contained in the first block already exists in the blockchain, then the verification of the first block is determined to be unsuccessful, and the transaction information already existing in the blockchain in the first block is deleted from the first transaction queue of the local transaction pool.

6. The transaction information processing method applied to blockchain according to claim 1, characterized in that, The transaction information processing method further includes: When adding the transaction information contained in the first block to the second transaction queue, the block height of the first block is recorded as the block height corresponding to the transaction information contained in the first block in the local transaction pool.

7. The transaction information processing method applied to blockchain according to claim 1, characterized in that, Before verifying the first block, the transaction information processing method further includes: If the first block contains target transaction information that does not exist in the local transaction pool, then the signature of the target transaction information is verified. After the signature verification of the target transaction information is successful, the target transaction information is added to the first transaction queue of the local transaction pool.

8. The transaction information processing method applied to blockchain according to claim 1, characterized in that, The transaction information processing method further includes: If the first block is submitted to the blockchain, the transaction information contained in the first block is deleted from the first transaction queue.

9. The transaction information processing method applied to blockchain according to any one of claims 1 to 8, characterized in that, The transaction information processing method further includes: If selected as a proposal node, the transaction information to be packaged into a block is obtained from the first transaction queue, and a second block is generated based on the obtained transaction information. The second block is transmitted to the consensus nodes in the blockchain network for consensus processing, and the transaction information contained in the second block is moved from the first transaction queue to the second transaction queue.

10. A transaction information processing device applied to blockchain, characterized in that, The local transaction pool of a blockchain node contains a first transaction queue and a second transaction queue. The first transaction queue is used to store transaction information to be packaged into a block, and the second transaction queue is used to store transaction information contained in the block to be uploaded to the chain. The transaction information processing device includes: The acquisition unit is configured to acquire the first block to be verified. The verification unit is configured to perform verification processing on the first block; The first processing unit is configured to, if the first block passes verification, add the transaction information contained in the first block to the second transaction queue and delete the transaction information contained in the first block from the first transaction queue. The second processing unit is configured to delete the transaction information contained in the first block from the second transaction queue if the first block is submitted to the chain. The verification unit is further configured to: obtain the block height corresponding to the transaction information contained in the first block in the local transaction pool; if the block height corresponding to the transaction information contained in the first block in the local transaction pool is less than the block height of the first block, then determine that the verification of the first block has failed. The first processing unit is further configured to: if the block height corresponding to the transaction information contained in the first block in the local transaction pool is less than the block height of the first block, then delete the transaction information in the first block whose corresponding block height in the local transaction pool is less than the block height of the first block from the first transaction queue of the local transaction pool.

11. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the transaction information processing method applied to blockchain as described in any one of claims 1 to 9.

12. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the transaction information processing method applied to a blockchain as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads and executes the computer instructions from the computer-readable storage medium, causing the computer device to perform the transaction information processing method applied to the blockchain as described in any one of claims 1 to 9.

Images