Blockchain-based transaction processing method, device, equipment, and storage medium

Abstract

The embodiments of the present application disclose a transaction processing method, apparatus, device, and storage medium based on blockchain. The method includes: obtaining a transaction to be processed; if it is determined that the transaction does not exist in the transaction pool and the blockchain database, encapsulating the current latest block height of the blockchain into the transaction to obtain a packaged transaction, and storing the packaged transaction in the transaction pool; taking the packaged transaction from the transaction pool, and performing transaction deduplication judgment on the packaged transaction in a preset memory, wherein the preset memory stores information about adjacent blocks on the blockchain, and the block height of the adjacent block is greater than the block height contained in the packaged transaction; if it is determined that the packaged transaction is not a duplicate transaction in the preset memory, then generating a block based on the packaged transaction. The present application can reduce the use of I / O resources for the blockchain database while ensuring the deduplication effect.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and specifically to a transaction processing method, apparatus, device, and storage medium based on blockchain. Background Art

[0002] In blockchain systems, transactions are not allowed to be duplicated. Therefore, all blockchain systems perform deduplication operations to ensure that no transaction is duplicated. Transaction deduplication generally requires verifying the existence of transactions in the blockchain database. To ensure effective deduplication, the blockchain database deduplication operation is typically performed at least twice, from the time a transaction is deposited into the transaction pool to the time it is retrieved from the transaction pool to generate a complete block. However, the I / O (Input / Output) performance of the blockchain database significantly affects the efficiency of deduplication operations, severely impacting the overall performance of the blockchain system.

[0003] Based on this, how to simultaneously ensure the deduplication effect of transactions and the overall performance of the blockchain system is a technical issue that technicians in this field need to continue to study. Summary of the Invention

[0004] To solve the above technical problems, the embodiments of the present application provide a blockchain-based transaction processing method and device, an electronic device, a computer-readable storage medium, and a computer program product.

[0005] According to one aspect of an embodiment of the present application, a blockchain-based transaction processing method is provided, comprising: obtaining a transaction to be processed; if it is determined that the transaction does not exist in a transaction pool and a blockchain database, encapsulating the current latest block height of the blockchain into the transaction to obtain a packaged transaction, and storing the packaged transaction in the transaction pool; taking the packaged transaction from the transaction pool, and performing transaction deduplication judgment on the packaged transaction in a preset memory, wherein the preset memory stores information of adjacent blocks on the blockchain, and the block height of the adjacent blocks is greater than the block height included in the packaged transaction; if it is determined that the packaged transaction is not a duplicate transaction in the preset memory, generating a block based on the packaged transaction.

[0006] According to one aspect of an embodiment of the present application, a blockchain-based transaction processing device is provided, including: a transaction acquisition module, configured to acquire a transaction to be processed; a first deduplication processing module, configured to, if it is determined that the transaction does not exist in both the transaction pool and the blockchain database, encapsulate the current latest block height of the blockchain into the transaction to obtain a packaged transaction, and store the packaged transaction in the transaction pool; a second deduplication processing module, configured to take out the packaged transaction from the transaction pool, and perform transaction deduplication judgment on the packaged transaction in a preset memory, wherein the preset memory stores information of adjacent blocks on the blockchain, and the block height of the adjacent block is greater than the block height included in the packaged transaction; a block generation module, configured to, if it is determined that the packaged transaction is not a duplicate transaction in the preset memory, generate a block based on the packaged transaction.

[0007] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: 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 implements the blockchain-based transaction processing method as described above.

[0008] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor of a computer, the computer executes the blockchain-based transaction processing method as described above.

[0009] According to one aspect of an embodiment of the present application, a computer program product is also provided, including a computer program, which, when executed by a processor, implements the blockchain-based transaction processing method as described above.

[0010] In the technical solution provided by the embodiments of the present application, on the one hand, transaction deduplication operations are performed respectively in the process of storing transactions into the transaction pool and in the process of taking transactions out of the transaction pool to generate blocks, that is, two deduplication operations are performed on the transactions to be uploaded to the chain, thereby ensuring the deduplication effect of the transactions; on the other hand, although the present application performs two deduplication operations on the transactions, the latter deduplication operation is not based on the deduplication performed on the blockchain database, but based on the deduplication performed in the memory, that is, in the two deduplication operations provided by the present application, only one deduplication is performed in the blockchain database, which can reduce the I / O resource usage of the blockchain database while ensuring the deduplication effect, thereby improving the overall performance of the blockchain system.

[0011] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and it is clear that a person of ordinary skill in the art can derive other drawings based on these drawings without inventive effort.

[0013] Figure 1 This is a schematic diagram of the structure of a blockchain system shown in an exemplary embodiment;

[0014] Figure 2 This is a schematic diagram of an exemplary blockchain architecture;

[0015] Figure 3 This is a schematic diagram of an exemplary transaction on-chain process;

[0016] Figure 4 This is a schematic diagram of an exemplary transaction deduplication process;

[0017] Figure 5 This is a flowchart of a blockchain-based transaction processing method shown in an exemplary embodiment of the present application;

[0018] Figure 6 This is a schematic diagram of an exemplary process of storing received transactions into a transaction pool;

[0019] Figure 7 This is a schematic diagram of an exemplary subsequent processing flow for extracting packaged transactions from the transaction pool;

[0020] Figure 8 is a flowchart of a blockchain-based transaction processing method shown in another exemplary embodiment of the present application;

[0021] Figure 9 yes Figure 8 A detailed flowchart of a transaction processing method based on blockchain is shown;

[0022] Figure 10 is a flowchart of a blockchain-based transaction processing method shown in another exemplary embodiment of the present application;

[0023] Figure 11 This is a schematic diagram of an exemplary storage structure of adjacent blocks in a preset memory;

[0024] Figure 12 yes Figure 10 A detailed flowchart of a transaction processing method based on blockchain is shown;

[0025] Figure 13is a flowchart of a blockchain-based transaction processing method shown in another exemplary embodiment of the present application;

[0026] Figure 14 is based on Figure 10 A flowchart of another blockchain-based transaction processing method proposed in the illustrated embodiment;

[0027] Figure 15 This is a schematic diagram of an exemplary process of adaptively adjusting the capacity of a preset memory;

[0028] Figure 16 This is a block diagram of a blockchain-based transaction processing device shown in an exemplary embodiment of the present application;

[0029] Figure 17 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0030] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

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

[0032] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0033] In this application, "plurality" refers to two or more. "And / or" describes the relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0034] First of all, it should be noted that the embodiments of the present application involve blockchain technology. Blockchain technology is a new distributed infrastructure and computing method that uses a block chain data structure to verify and store data, a distributed node consensus algorithm to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script code to program and operate data. Blockchain refers to a decentralized infrastructure with distributed storage characteristics. Specifically, it is a data structure that organizes data blocks in a chronological order in a manner similar to a linked list. It can securely store data that has a sequential relationship and can be verified within the system, and uses cryptography to ensure that the data cannot be tampered with or forged. Simply put, blockchain is a decentralized distributed ledger, and each chain is equivalent to an independent ledger.

[0035] Figure 1 This is a schematic structural diagram of a blockchain system shown in an exemplary embodiment. Figure 1 The blockchain system 100 shown may include node devices 10a, 10b, 10c, and 10d. Node devices 10a, 10b, 10c, and 10d are all Figure 1 The blockchain nodes (referred to as nodes for short) in the blockchain system 100 shown may be any form of computing device connected to the blockchain system 100, such as a server, a user terminal, etc. Figure 1 The node devices 10a, 10b, 10c, and 10d shown can also be connected through network communication to form a blockchain system 100.

[0036] Figure 1 The types of blockchains involved in the illustrated blockchain system 100 architecture may include: public blockchain, private blockchain, and consortium blockchain. The types of blockchains employed in different blockchain application scenarios may vary and are not limited here. A public blockchain is a publicly accessible blockchain that anyone can join and access. Blockchains on a public blockchain are viewable, anyone can initiate transactions, and anyone can participate in the public blockchain's consensus process at any time. A private blockchain is designed for use within a private organization. Read, write, and account-keeping permissions on the blockchain can be determined according to the organization's rules. These blockchains are typically used for internal enterprise data management and auditing. A consortium blockchain is a blockchain where members' read, write, and account-keeping permissions are determined according to the consortium's rules. These blockchains are typically used for inter-institutional transactions, settlement, or clearing.

[0037] Each node in the blockchain system 100 has a corresponding node identifier, and each node in the blockchain system 100 can store the node identifiers of other nodes in the blockchain system 100, so that the generated blocks can be broadcast to other nodes in the blockchain system 100 based on the node identifiers of other nodes.

[0038] Each node in the blockchain system 100 stores an identical blockchain (see Figure 1 The blockchain consists of multiple blocks, see Figure 2 Each block in the blockchain contains the hash value of the transaction records stored in that block (the current block's hash value) and the hash value of the previous block. Blocks are connected by hash values ​​to form a blockchain, ensuring the security of the information entered into the blocks. Blocks may also include information such as the timestamp of block generation, version number, and difficulty value, which are not listed here.

[0039] It is worth mentioning that the block can also include information about the block height. The block height is the number of blocks linked to the main chain, that is, the number of blocks linked to the blockchain. Therefore, the block height is one of the identifiers of the block. Another identifier of the blockchain is the hash value of the block. The block height can also be the number of blocks between the block in the blockchain and the genesis block. Each subsequent block on the blockchain that is stored above the genesis block is one position higher than the previous block in the blockchain. Therefore, the height of each block stored above the genesis block is 1 higher than the height of the previous block. See also Figure 2 Block 1 is the genesis block on the blockchain, and its height is 0. Block 2 and block 3 are both blocks stored above the genesis block. Block 2 is the previous block of block 3. The height of block 2 is 1, and the height of block 3 is 2. In this way, the height of each linked block on the blockchain is passed down, so that the blockchain height becomes one of the identifiers that can identify different blocks on the blockchain.

[0040] As can be seen from the above, the blocks stored on the blockchain are linked in sequence according to the order of block height. Based on this point, the embodiments of the present application will provide a technical solution that can simultaneously ensure the deduplication effect of transactions and the overall performance of the blockchain system. For detailed technical details, please refer to the records of subsequent embodiments and will not be repeated here.

[0041] Figure 3 This is a schematic diagram of an exemplary transaction on-chain process. Figure 3As shown, in blockchain systems, transactions are typically stored in a transaction pool before being uploaded to the blockchain. These transactions in the transaction pool serve as the data foundation for the consensus module to package transactions and the synchronization module to broadcast transactions. It should be understood that the transaction pool is essentially the memory provided by the node, the consensus module is essentially the program configured in the node to perform consensus functions, and the synchronization module is the program configured in the node to perform synchronization functions.

[0042] After receiving a transaction, the transaction pool needs to ensure its legitimacy, so it verifies the legitimacy of the transaction. This verification can include verifying the validity of the signature, verifying that the transaction is not a duplicate transaction in the transaction pool, and verifying that the transaction is not already on the blockchain. Only after successful legitimacy verification is the transaction stored in the transaction pool. In some practical application scenarios, it is also possible to set a limit on the capacity of the transaction pool. If the number of transactions in the transaction pool exceeds the capacity limit, the transaction pool can refuse to accept new transactions.

[0043] During the on-chain phase of transactions in the transaction pool, the consensus module retrieves valid transactions from the transaction pool, packages them into blocks, and broadcasts them to other consensus nodes in the blockchain system. After receiving the packaged blocks, other consensus nodes verify the signatures of each transaction within the block to ensure its legitimacy. Once all signatures of transactions within the block have been verified, the consensus node broadcasts the verification results to the blockchain system. If all or a majority of consensus nodes in the blockchain system verify the transactions within the block, consensus has been reached. Once consensus is reached, the block can be on-chain and stored in the blockchain database. In some practical applications, given that transaction signature verification is a time-consuming operation and the high probability that transactions to be verified in the block will be found in the transaction pools of other nodes, to improve consensus verification efficiency, only the signatures of transactions in the blockchain that are not found in the local transaction pool can be verified.

[0044] The consensus module extracts transactions from the transaction pool according to specified rules and generates a batch. Therefore, a block is equivalent to a batch of transactions. There are multiple ways to trigger the consensus module to extract transactions from the transaction pool. The two most common triggering methods are: time triggering, which specifies that the interval between each trigger for the consensus module to generate a block is pre-set. When the timer exceeds the pre-set interval, the transaction is triggered to be extracted from the transaction pool. The second is quantity triggering, which specifies that the number of transactions cached in the transaction pool reaches a specified value, which triggers the extraction of transactions from the transaction pool.

[0045] Based on the above block chain process, it can be seen that in a relatively stable blockchain system, the time interval from the stage of storing a transaction in the transaction pool to the stage of it being taken out and packaged by the consensus module to generate a block is usually very short. Within this short time interval, the number of blocks generated by the blockchain system should also be limited, and the maximum number of blocks generated by the blockchain system can also be estimated. In order to provide a technical solution that can simultaneously ensure the deduplication effect of transactions and the overall performance of the blockchain system, the embodiments of this application also refer to this technical point. The details of the technical solution provided by this application are still described in the subsequent embodiments and will not be repeated here.

[0046] As mentioned in the background technology, transactions in the blockchain system are not allowed to be repeated. Therefore, the blockchain system will perform deduplication operations on transactions to ensure that each transaction on the chain is not repeated. Figure 4 This is a diagram of an exemplary transaction deduplication process, where Push refers to the process of receiving transactions and storing them in the transaction pool, and Fetch refers to the process of the consensus module taking multiple transactions from the transaction pool and packaging them into a block. Considering that the verification of the absence of a transaction in the blockchain database during the Push phase does not necessarily mean that the transaction does not exist, it is also possible that the transaction is in the process of being processed, such as the consensus process or the critical state of storage. However, when the transaction reaches the Fetch phase, its previous block has completed the storage process on the chain and will exist in the blockchain database. Therefore, in order to ensure the deduplication effect of transactions, Figure 4 The illustrated process performs a blockchain database deduplication operation in both the Push and Fetch phases. This deduplication operation verifies that transactions are indeed on-chain. However, the I / O performance of the blockchain database significantly impacts the efficiency of transaction deduplication. Performing at least two deduplication operations can severely impact the overall performance of the blockchain system. Furthermore, performing deduplication in the Fetch phase can also reduce the system's block generation performance.

[0047] To address the above technical issues, the embodiments of this application provide a blockchain-based transaction processing method, apparatus, electronic device, computer-readable storage medium, and computer program product, respectively, to simultaneously ensure transaction deduplication and the overall performance of the blockchain system. These embodiments are described in detail below.

[0048] See also Figure 5 , Figure 5 This is a flowchart of a transaction processing method based on blockchain, which is shown in an exemplary embodiment of the present application. This method can be executed by a node in a blockchain system. The node in the blockchain system can be a terminal device or a server device, which is not limited here. Figure 5 The transaction processing method based on blockchain includes steps S510 to S540, which are described in detail as follows:

[0049] Step S510: Obtain the transaction to be processed.

[0050] For nodes in a blockchain system, transactions to be processed are typically passed in by clients, enabling them to implement the client's requested business applications based on the distributed storage capabilities provided by the blockchain system. For example, a client sends a transaction to a node instructing account A to transfer a resource to account B. The node processes the transaction and stores it on the blockchain.

[0051] It should be understood that in different application scenarios, the way a node obtains pending transactions may also be different. For example, pending transactions may also be forwarded by other nodes, and this embodiment does not limit this. In addition, for a blockchain system, a transaction is essentially a digital record.

[0052] In step S520, if it is determined that the transaction does not exist in the transaction pool and the blockchain database, the current latest block height of the blockchain is encapsulated into the transaction to obtain a packaged transaction, and the packaged transaction is stored in the transaction pool.

[0053] As mentioned above, in the process of depositing a transaction into the transaction pool, the transaction is verified for legitimacy after it is received. The legitimacy verification includes verifying whether the transaction is a duplicate transaction in the transaction pool and whether the transaction is a transaction that has been put on the chain. This verification process is also the transaction deduplication operation performed in the Push phase mentioned above. If the transaction is verified to be legal, it will be deposited into the transaction pool.

[0054] In order to ensure both the deduplication effect of transactions and the overall performance of the blockchain system, in the technical solution provided in this embodiment, when storing transactions in the transaction pool, for each received transaction, if it is verified that the transaction does not exist in both the transaction pool and the blockchain database, the transaction is not directly stored in the transaction pool. Instead, the current latest block height of the blockchain is encapsulated into the transaction to obtain the corresponding encapsulated transaction, and then the encapsulated transaction is stored in the transaction pool.

[0055] For example, see Figure 6 For an example transaction N, after determining that transaction N does not exist in the transaction pool and blockchain database, it means that transaction N is not a duplicate transaction and needs to be stored in the transaction pool to wait for it to be taken out to generate a block. If the current latest block height of the blockchain is represented as "Block Height" and the current latest block height is encapsulated into transaction N, the encapsulated transaction [N] is obtained. It should also be understood that Figure 6Similarly, the encapsulated transaction [A] stored in the transaction pool shown here refers to the encapsulated transaction corresponding to transaction A. The block height contained in encapsulated transaction [A] is the current latest block height of the blockchain obtained when transaction A is received and it is determined that transaction A does not exist in the transaction pool and blockchain database. It should also be noted that since new blocks are typically generated continuously on the blockchain, the current latest block height on the blockchain is usually dynamic. Therefore, the block height contained in different encapsulated transactions in the transaction pool may be different.

[0056] In addition, Figure 6 As shown in the figure, since each transaction is encapsulated with the current latest block height on the blockchain after the transaction deduplication operation is performed in the Push phase, the block height "Block Height" contained in each encapsulated transaction can also be called the block height that has been verified to be non-existent. In layman's terms, the block height contained in each encapsulated transaction cannot be the block height of the real block corresponding to the encapsulated transaction. Therefore, the block height information contained in each encapsulated transaction in the transaction pool will not affect the normal operation of the blockchain system.

[0057] This embodiment provides that during the process of storing each transaction in the transaction pool, after verifying that the transaction is not a duplicate transaction in the transaction pool and the blockchain database, the current latest block height of the blockchain is encapsulated into the transaction, and the resulting encapsulated transaction is stored in the transaction pool. This is essentially a process optimization of the Push phase, and its purpose is to use the block height information contained in the encapsulated transaction to act on step S530. For detailed information on the action process, please refer to the relevant records in step S530.

[0058] Step S530: extract the packaged transaction from the transaction pool and perform transaction deduplication judgment on the packaged transaction in a preset memory, wherein the preset memory stores information of adjacent blocks on the blockchain, and the block height of the adjacent block is greater than the block height included in the packaged transaction.

[0059] As mentioned above, the process of extracting multiple transactions from the transaction pool to generate a block in the blockchain field is usually called the Fetch phase, see Figure 4 In the conventional Fetch phase, the blockchain database will also perform deduplication operations on each transaction taken out of the transaction pool to ensure the deduplication effect of the transaction. However, the two blockchain deduplication operations will affect the I / O performance in the blockchain database, thereby affecting the overall performance of the blockchain system. In addition, performing blockchain database deduplication operations in the Fetch phase will also reduce the block generation performance of the blockchain system.

[0060] To address this issue, this embodiment optimizes the Fetch phase based on the block height information contained in the packaged transaction stored in the transaction pool in step S520. This not only ensures transaction deduplication but also improves the overall performance of the blockchain system. This optimization is possible because, as previously mentioned, in a relatively stable blockchain system, the time interval between a transaction in the Push phase and its packaging and block generation in the Fetch phase is typically very short. During this short interval, the blocks generated by the blockchain system are predictable, making this approach effectively applicable in the technical solution provided by this embodiment.

[0061] This embodiment sets a preset memory for the transaction deduplication operation in the Fetch stage. After the packaged transaction is retrieved from the transaction pool, the Fetch stage only needs to perform transaction deduplication judgment in the preset memory for the retrieved packaged transaction, that is, to determine whether the retrieved packaged transaction exists in the preset memory, without having to perform a blockchain database deduplication operation again. This reduces the loss of I / O resources for blockchain data and improves the overall performance of the blockchain system.

[0062] The preset memory refers to the memory space preset in the node. In computer equipment, the memory is generally used to temporarily store computational data in the CPU (Central Processing Unit). In this embodiment, the preset memory set in the node is used to cache information of adjacent blocks on the blockchain. Adjacent blocks refer to blocks on the blockchain whose block height is greater than the block height contained in the extracted packaged transaction. The information of adjacent blocks includes, for example, the unique identifier of each transaction used to form the block, the specific data of each transaction, etc., which are not limited here.

[0063] See also Figure 7 The preset memory is equivalent to a block cache of the blockchain database, that is, the information of the adjacent blocks corresponding to the packaged transactions stored on the blockchain database is encapsulated in the preset memory for caching. Therefore, it can be seen that this embodiment performs a full blockchain database deduplication operation on transactions in the Push phase, and in the Fetch phase, only the newly added blocks on the blockchain are used to achieve another transaction deduplication, which is equivalent to an incremental deduplication operation, rather than another full blockchain database deduplication.

[0064] In step S540 , if it is determined that the packaged transaction is not a duplicate transaction in the preset memory, a block is generated according to the packaged transaction.

[0065] If the deduplication process for the retrieved encapsulated transaction in the preset memory determines that the encapsulated transaction is not a duplicate transaction in the preset memory, that is, the encapsulated transaction does not exist in the preset memory, then the encapsulated transaction is not duplicated on the blockchain and can therefore be used for block generation in the Fetch phase, i.e., generating a corresponding block based on the encapsulated transaction. Thus, this embodiment still performs two deduplication operations on the transactions to be uploaded to the blockchain, which can ensure transaction deduplication effectiveness. However, these two deduplication operations essentially only include one full blockchain database deduplication operation. The other deduplication operation is an incremental transaction deduplication operation performed in the preset memory based on the information of newly added blocks on the blockchain. This reduces the time consumed when generating blocks in the Fetch phase and the I / O resource usage of the blockchain database. This reduces the I / O resource consumption of the blockchain database while ensuring the deduplication effect, thereby improving the overall performance of the blockchain system and the block generation capacity of the entire blockchain system, thereby resolving the problems existing in the prior art.

[0066] Figure 8 This is a flowchart of a transaction processing method based on blockchain, shown in another exemplary embodiment of the present application. Figure 8 As shown in the method Figure 5 Based on the flowchart shown, the following steps are also included:

[0067] Step S610, searching the transaction pool for the existence of the transaction based on the unique identifier of the transaction;

[0068] Step S620: If it is determined that the transaction does not exist in the transaction pool, obtain the latest block height of the blockchain and determine whether the transaction exists in the blockchain database;

[0069] In step S630, if it is determined that the transaction does not exist in the blockchain database, it is determined that the transaction is not a duplicate transaction in the transaction pool and the blockchain database.

[0070] First, it should be noted that the unique identifier of a transaction is information used to uniquely identify the transaction. For example, it can be the transaction ID (Identity Document), usually represented as "TxID", or the hash value obtained by hashing the transaction ID, or the hash value obtained by hashing the transaction content. As long as it can be used to uniquely identify each transaction, there is no limitation here. It should be understood that a hash operation is an operation method that receives an input of unlimited length and returns an output of fixed length, mapping a binary value of arbitrary length to a shorter binary value of fixed length. The resulting fixed binary value is also called a hash value.

[0071] In the above process, the transaction pool is first deduplicated because the transactions in the transaction pool are stored in memory. Therefore, deduplication based on the transaction pool is faster. Deduplication can quickly determine whether the received transaction is an illegal duplicate transaction, which can improve the overall performance of the blockchain system to a certain extent.

[0072] Furthermore, to further expedite deduplication, a hash table can be used to store the unique identifiers of transactions in the transaction pool. A hash table, also known as a hash table, is a data structure that is directly accessed based on a key-value pair. In layman's terms, a hash table accesses records by mapping a key value to a location in the table, accelerating lookups. This mapping function is called a hash function, and the array that stores the records is called a hash table. Based on this, this exemplary embodiment uses the unique identifier of a transaction as the key to determine whether there are duplicate transactions in the transaction pool.

[0073] If it is determined that the current transaction does not exist in the transaction pool, the latest block height of the blockchain is obtained and further determination is made as to whether the transaction exists in the blockchain database. If it is determined that the transaction does not exist in the blockchain database, it can be determined that the transaction does not exist in either the transaction pool or the blockchain database and is not a duplicate transaction in either the transaction pool or the blockchain database. Therefore, the process of encapsulating the latest block height of the blockchain into the transaction and storing the resulting encapsulated transaction in the transaction pool is continued as disclosed in step S510.

[0074] If the transaction is determined to be a duplicate transaction in the transaction pool or a duplicate transaction in the blockchain database in the above process, the transaction is discarded and the same deduplication judgment is performed on the next received transaction. This is not repeated here.

[0075] For ease of understanding, the above process can also be expressed as Figure 9 As shown in the judgment process. Figure 9 As shown, for each received transaction, the unique identifier of the transaction is used as the key to determine whether the transaction exists in the transaction pool, obtaining a first judgment result. If the first judgment result indicates that the transaction exists in the transaction pool, the transaction is discarded. If the first judgment result indicates that the transaction does not exist in the transaction pool, the current latest block height h of the blockchain is obtained and a second judgment result is obtained to determine whether the transaction exists in the blockchain database. If the second judgment result indicates that the transaction exists in the blockchain database, the transaction is discarded. If the second judgment result indicates that the transaction does not exist in the blockchain database, the block height h is encapsulated in the transaction and the corresponding encapsulated transaction is stored in the transaction pool.

[0076] As can be seen from the above, the method provided in this embodiment fully reveals the deduplication operation process of transactions in the Push phase. The blockchain node performs transaction deduplication in the Push phase according to the above process for each transaction received, which can ensure high deduplication efficiency.

[0077] Figure 10 This is a flowchart of a transaction processing method based on blockchain, shown in another exemplary embodiment of the present application. Figure 5 Based on the method shown, the Figure 5 The process of determining the existence of the extracted packaged transaction in the preset memory disclosed in step S530 includes the following steps:

[0078] Step S5311, obtaining the block height and unique identifier contained in the packaged transaction;

[0079] Step S5312: Obtain information about adjacent blocks corresponding to the packaged transaction from the blockchain, and cache the information about the adjacent blocks in a preset memory;

[0080] Step S5313: Determine whether the packaged transaction exists in the preset memory based on the unique identifier.

[0081] In the above process, the block height and unique identifier contained in the retrieved encapsulated transaction are first obtained. As previously mentioned, the block height contained in the encapsulated transaction is the current latest block height on the blockchain at the time the corresponding transaction passes deduplication verification during the Push phase. Then, based on the block height contained in the encapsulated transaction, information about adjacent blocks with a block height greater than the block height contained in the encapsulated transaction is retrieved from the current blockchain and cached in a pre-set memory. As can be seen, the pre-set memory caches information about blocks newly added to the blockchain during the interval between the Push phase and the Fetch phase of the encapsulated transaction. Finally, based on the unique identifier of the encapsulated transaction, it is determined whether the retrieved encapsulated transaction exists in the pre-set memory. This allows for rapid deduplication of transactions during the Fetch phase, significantly improving the block generation performance of the blockchain system and the overall performance of the blockchain system.

[0082] In order to further speed up the deduplication judgment of transactions, a hash table can be used to store each transaction contained in adjacent blocks in a preset memory, where the unique identifier of each transaction contained in the adjacent blocks is used as the key code. Figure 11 As shown, for the exemplary adjacent block n, the unique identifier "TxID" of each transaction contained in the adjacent block n can be stored in the hash table as the key code Key. The detailed principle has been recorded in the aforementioned embodiment and will not be repeated here.

[0083] It should be noted that the number of packaged transactions taken out from the transaction pool at one time during the Fetch phase is generally multiple and specified. Therefore, each packaged transaction taken out must be processed as follows: Figure 10 The process shown performs existence judgment based on the preset memory, that is, deduplication judgment based on the preset memory, so that each transaction on the chain is deduplicated in the Push phase and the Fetch phase, thereby ensuring the deduplication effect of the transaction.

[0084] In addition, based on the above process, we can also get Figure 12 The flowchart of the Fetch phase is shown in the figure. First, a specified number of packaged transactions are extracted from the transaction pool, that is, a batch of packaged transactions are extracted from the transaction pool. Deduplication is performed on each packaged transaction based on the preset memory. Specifically, the TxID and block height h contained in each extracted packaged transaction are obtained. Then, information about adjacent blocks with a block height greater than h on the current blockchain is loaded into the preset memory. A determination is made as to whether the previously obtained TxID already exists in the preset memory, and a third determination result is obtained. If the third determination result indicates that it exists in the preset memory, the packaged transaction is discarded. If the third determination result indicates that it does not exist in the preset memory, deduplication is performed on all packaged transactions in the batch. After completing the deduplication judgment of all packaged transactions contained in the retrieved batch, it is further judged whether the number of packaged transactions in the batch that do not exist in the preset memory meets the preset quantity condition. For example, if the number reaches M, if it is judged as yes, a block is generated based on these M packaged transactions that meet the conditions; if it is judged as no, it is necessary to re-retrieve the packaged transactions from the transaction pool as a supplement. The supplementary packaged transactions still need to be deduplicated according to the above process until the packaged transactions that meet the preset quantity condition are obtained to act as a block.

[0085] As can be seen from the above, the process provided by this embodiment contains at least two key points. The first is to determine the existence of encapsulated transactions. The transaction information contained in the adjacent blocks corresponding to the encapsulated block needs to be loaded into the memory. The second point is that there may be a situation where the number of transactions does not meet the requirements for generating a block after the encapsulated transactions are discarded. The corresponding number of encapsulated transactions needs to be obtained from the transaction pool to fill the gap. This ensures that the Fetch phase can operate completely and correctly.

[0086] Figure 13 This is a flowchart of a transaction processing method based on blockchain shown in another exemplary embodiment of the present application. Figure 13 In the illustrated embodiment, the capacity of the preset memory may be a preset fixed value, hereinafter referred to as the preset capacity, which is determined by the following steps:

[0087] Step S5321, obtaining performance parameters of the blockchain;

[0088] Step S5322, determining a corresponding performance level according to the performance parameters;

[0089] Step S5323: Calculate the preset capacity size corresponding to the preset memory according to the determined performance level.

[0090] In the above process, the performance parameters of the blockchain are used to characterize the performance of the blockchain system and are also key indicators for measuring blockchain performance. For example, they include at least one of blockchain node indicators, P2P (Peer To Peer) subsystem indicators, and system node indicators. There is no restriction here, and specific performance parameter information can be obtained according to actual needs.

[0091] Blockchain node metrics include, for example, the number of blocks produced, the number of transactions processed, processing time, and completion time. In some embodiments, blockchain node metrics may also be a comprehensive metric calculated based on the above metrics, such as TPS (Transactions Per Second) and TPMC (Transactions Per Minute).

[0092] P2P subsystem metrics are indicators corresponding to the P2P layer in a blockchain system. The P2P protocol is an application-layer protocol that runs on top of the Transmission Control Protocol. The P2P network formed between nodes in a blockchain system is the architectural foundation of the blockchain system and should not be ignored as a middle layer of the blockchain system. For example, when the number of consensus nodes or verification nodes in a blockchain system is small, the blockchain system can operate normally and quickly. However, consensus nodes and verification nodes are geographically distributed, which makes network packet loss more likely, thus affecting the overall performance of the blockchain system. Therefore, P2P subsystem metrics need to be included in the blockchain system's performance indicators. Exemplary P2P subsystem metrics include the number of hit and miss requests, the number of active users, and the amount and structure of P2P traffic.

[0093] System node metrics are used to measure the overall performance of a blockchain system. Examples include CPU parameters, memory parameters, storage parameters, and network parameters. CPU parameters indicate the amount of computation performed by the processor. These can be broken down into more detailed metrics to better characterize performance, such as the amount of time the CPU spends in kernel code, time spent in user processes, and the amount of time waiting for I / O resources from slow external devices. Insufficient memory load can also increase blockchain data limits or maximum transaction complexity within a blockchain system. Therefore, it is important to include memory parameters in performance metrics. These parameters include traffic volume, the number of network packets sent and received, and packet loss rate. The disk subsystem is one of the slowest components of any service and often leads to significant performance issues. These issues, such as excessive logging, unplanned backups, awkward read / write patterns, and large block counts, can significantly slow down a node or place excessive demands on hardware. Therefore, storage parameters are also important performance metrics to consider.

[0094] Based on these performance parameters, the performance of the blockchain system can be determined, and thus the corresponding performance level can be determined. For example, it can be determined whether the performance level of the blockchain system is the first level or the second level, where the first level represents better performance and the second level represents worse performance.

[0095] If the default memory capacity is determined to be the first level, the default memory capacity can be set to the storage capacity of one block. This can be calculated by multiplying the number of transactions contained in a block by the storage capacity of each transaction. This is because, in a blockchain system with good performance, the number of blocks generated in the short interval between the Push and Fetch phases is generally one. Therefore, the default memory capacity can be set to the storage capacity required for one block.

[0096] If the system is determined to be at the second level, indicating poor blockchain system performance and a tendency for transactions to accumulate in the transaction pool, the preset memory capacity should be set to a preset multiple of the transaction pool's storage capacity. This multiple should be greater than 1, ensuring that the preset memory capacity is larger than the transaction pool's storage capacity. For example, the preset memory capacity can be set to 1.1-1.5 times the transaction pool's storage capacity. This setting can be adjusted based on actual application requirements and is not a limitation here.

[0097] It can be concluded that the method provided in this embodiment determines the preset capacity size corresponding to the preset memory according to the performance parameters of the blockchain, so that the determined preset capacity size will not be too large and will not waste memory space, and can also meet performance requirements, thereby ensuring that the blockchain system has good overall performance.

[0098] It should also be mentioned that since the capacity of the preset memory is limited, in the process of caching the information of adjacent blocks into the preset memory, if it is found that the capacity of the preset memory is full, it means that the capacity of the preset memory is insufficient to store the information of the adjacent blocks. It is necessary to delete the information of the block with the smallest block height from the preset memory and store the information of the newly loaded adjacent blocks into the preset memory. However, this may lead to the problem that the transaction deduplication effect in the Fetch phase cannot be guaranteed by the blocks cached in the preset memory. For example, after the block information is deleted from the preset memory, it will result in the inability to perform complete incremental transaction deduplication during the deduplication operation in the Fetch phase, that is, it is impossible to perform deduplication judgment of transactions based on the deleted blocks, making the transaction deduplication process imperfect and unable to guarantee the transaction deduplication effect.

[0099] The above problem is also caused by insufficient preset memory capacity. Furthermore, it is also possible that the preset memory capacity may be set too large, resulting in a certain degree of waste of memory resources and hindering the overall performance of the blockchain system. Based on this, another exemplary embodiment of the present application proposes a technical solution that supports adaptive adjustment of the preset memory capacity.

[0100] For details, see Figure 14 The process of the transaction processing method based on blockchain is shown in Figure 10 Based on the method shown, the process of determining the existence of a packaged transaction in a preset memory further illustrates a process of adaptively adjusting the capacity of the preset memory. The process includes the following steps:

[0101] Step S5331: Add one to the block height included in the extracted packaged transaction to obtain a reference block height;

[0102] Step S5332: determining whether there is information of a neighboring block corresponding to the reference block height in the preset memory, and adaptively adjusting the capacity of the preset memory according to the result information obtained;

[0103] Step S5333: Update the information stored in the preset memory according to the adaptively adjusted capacity.

[0104] In the above process, considering that the number of blocks generated during the time interval between the Push phase and the Fetch phase of a transaction is generally at least one, step S5231 adds one to the block height included in the extracted packaged transaction to obtain a reference block height, so as to further decide whether to shrink or expand the preset memory based on the reference block height.

[0105] In step S5332, if it is determined that the result information obtained indicates that there is no information of adjacent blocks corresponding to the reference block height in the preset memory, the number of blocks that need to be cached in the preset memory is calculated, and the preset memory is expanded according to the number of blocks that need to be cached; if it is determined that the result information obtained indicates that there is information of adjacent blocks corresponding to the reference block height in the preset memory, it is determined whether the number of blocks cached in the preset memory exceeds a preset threshold; if it is determined that the number of blocks cached in the preset memory does not exceed the preset threshold, the preset memory is reduced in capacity, wherein the preset threshold represents the preset capacity size corresponding to the preset memory.

[0106] In step S5333, after the capacity of the preset memory is adaptively adjusted, the information of the blocks stored in the preset memory should also be updated accordingly to perform subsequent transaction deduplication operations based on the preset memory, which will not be elaborated here.

[0107] As can be seen from the above, the above process provided by this embodiment can ensure the transaction deduplication effect in the Fetch stage by setting an adaptive adjustment strategy for the capacity of the preset memory so that the information of adjacent blocks cached in the preset memory can be guaranteed.

[0108] For example, if the result information obtained indicates that the preset memory does not contain information about adjacent blocks corresponding to the reference block height, this indicates that the capacity of the preset memory is very small and is insufficient to support the transaction deduplication judgment based on the preset memory during the Fetch phase. Therefore, the preset memory needs to be expanded. For ease of understanding, if the block height contained in the retrieved encapsulated transaction is 5, and the corresponding reference block height is 6, if the preset memory only stores information about adjacent blocks with block heights of 7, 8, and 9, this indicates that due to the small capacity of the preset memory, when loading the information about adjacent blocks from the blockchain into the preset memory, the information about the adjacent block with a block height of 6 was deleted due to insufficient storage capacity. Therefore, the preset memory needs to be expanded.

[0109] The process of calculating the number of blocks to be cached in the pre-set memory involves obtaining the current latest block height H on the blockchain and the block height h contained in the current encapsulated transaction, calculating the difference between block height H and block height h, and using the resulting difference as the number of blocks to be cached in the pre-set memory. This calculation is based on the fact that the pre-set memory only caches information about newly added blocks on the blockchain, and the difference between block height H and block height h indicates the number of newly added blocks on the blockchain.

[0110] From the above, it can be concluded that after the expansion of the preset memory, the capacity of the preset memory can be increased, and all incremental adjacent blocks on the blockchain can be cached in the preset memory without missing adjacent blocks. Therefore, the deduplication effect can be guaranteed during the transaction deduplication judgment process based on the preset memory in the Fetch phase.

[0111] In another example, if the result information obtained indicates that there is information of an adjacent block corresponding to the reference block height in the preset memory, this means that the capacity of the preset memory is appropriate or too large, but further judgment is needed to determine which case it is.

[0112] Specifically, it is necessary to further determine whether the number of blocks cached in the preset memory exceeds a preset threshold value. The preset threshold value represents the number of blocks that can be stored in the preset capacity size corresponding to the preset memory. The value of the number of blocks is usually 1, but it may also be other values ​​in different application scenarios, such as 2 or 3, which is not restricted here. If it is determined that the number of blocks cached in the preset memory does not exceed the preset threshold value, the preset memory is scaled down. Still taking the block height of 5 contained in the extracted packaged transaction and the corresponding reference block height of 6 as an example, if the preset memory stores information of adjacent blocks with block heights of 6 and 7 respectively, it can be seen that the number of blocks cached in the preset memory is 2, which does not exceed the preset threshold value of 4. Therefore, it means that the capacity of the preset memory is too large and needs to be scaled down. Generally, the capacity of the preset memory after scaling is the storage capacity corresponding to the number of blocks currently cached in the preset memory.

[0113] If it is determined that the number of blocks cached in the preset memory is equal to the preset threshold, then the preset capacity is appropriate and no further processing can be performed on the preset memory capacity. However, since the preset capacity of the preset memory is pre-set, the situation where the number of blocks cached in the preset memory exceeds the preset threshold is generally unlikely, and therefore will not be considered or explained herein.

[0114] After the expansion of the preset memory, the capacity of the preset memory can be reduced, saving unnecessary memory resource overhead, while ensuring the deduplication effect in the Fetch stage, which is beneficial to improving the overall performance of the blockchain system.

[0115] The above adaptive adjustment process can also be expressed as Figure 15 See the process shown. Figure 15, first, it is necessary to determine whether the block corresponding to the reference block height h+1 corresponding to the extracted packaged transaction exists in the preset memory, and obtain the fourth judgment result. If the fourth judgment result indicates that it does not exist, then calculate the number of blocks that need to be cached in the preset memory: the current latest block height H on the blockchain-the block height h contained in the current packaged transaction, and then update the capacity of the preset memory according to the number of blocks that need to be cached, that is, the number of blocks that can be stored in the updated preset memory is the difference of Hh, thereby achieving the expansion of the preset memory. If the fourth judgment result indicates that it exists, then further determine whether the number of blocks cached in the preset memory exceeds the preset threshold, and obtain the judgment status. If the judgment status indicates that it does not exceed, then update the capacity of the preset memory to the storage capacity corresponding to the block of the preset threshold. Usually, the judgment status indication does not exceed.

[0116] Based on the above process, it can be seen that the adaptive adjustment strategy of setting the capacity of the preset memory proposed in this embodiment can ensure that the information of adjacent blocks cached in the preset memory can ensure the transaction deduplication effect in the Fetch stage without wasting memory resources, which greatly promotes the overall performance improvement of the blockchain system.

[0117] It should also be noted that in another exemplary embodiment, consideration should be given to the need for caution in reducing the capacity of the preset memory. For example, consideration should be given to whether the capacity of the preset memory after reduction is sufficient to meet the deduplication efficiency of other packaged transactions during the Fetch phase. Consequently, a method is proposed for collecting statistics on packaged transactions that are determined to require reduction of the preset memory. Specifically, statistics are collected to determine which packaged transactions require reduction of the preset memory, and the statistical results are used to determine whether to reduce the preset memory.

[0118] For example, if the number of packaged transactions corresponding to the statistical result is greater than or equal to a preset threshold, it indicates that a large number of packaged transactions indicate that the preset memory needs to be reduced, so the decision is to reduce the preset memory. If the number of packaged transactions corresponding to the statistical result is less than the preset threshold, it indicates that only a small number of packaged transactions indicate that the preset memory needs to be reduced. If reducing the preset memory will affect the deduplication judgment of other packaged transactions, the decision is not to reduce the preset memory, and the current capacity of the preset memory remains unchanged. Alternatively, the above statistical result can also be the number of packaged transactions that are continuously determined to need to be reduced. The selection can be based on actual needs and is not limited here.

[0119] like Figure 16As shown, another exemplary embodiment of the present application provides a blockchain-based transaction processing device. This exemplary blockchain-based transaction processing device 1600 can be configured on a blockchain node and specifically includes:

[0120] The transaction acquisition module 1610 is configured to obtain a transaction to be processed; the first deduplication processing module 1620 is configured to, if it is determined that the transaction does not exist in both the transaction pool and the blockchain database, encapsulate the current latest block height of the blockchain into the transaction to obtain a packaged transaction, and store the packaged transaction in the transaction pool; the second deduplication processing module 1630 is configured to take the packaged transaction from the transaction pool and perform transaction deduplication judgment on the packaged transaction in a preset memory, wherein the preset memory stores information of adjacent blocks on the blockchain, and the block height of the adjacent block is greater than the block height included in the packaged transaction; the block generation module 1640 is configured to, if it is determined that the packaged transaction is not a duplicate transaction in the preset memory, generate a block based on the packaged transaction.

[0121] On the one hand, the device performs transaction deduplication operations in the process of storing transactions in the transaction pool and in the process of taking transactions out of the transaction pool to generate blocks, that is, two deduplication operations are performed on the transactions to be uploaded to the chain, thereby ensuring the deduplication effect of the transactions; on the other hand, although the device performs two deduplication operations on the transactions, the latter deduplication operation is not based on the blockchain database, but based on the memory, that is, of the two deduplication operations provided by this application, only one deduplication is actually performed in the blockchain database, which can reduce the I / O resource usage of the blockchain database while ensuring the deduplication effect, thereby improving the overall performance of the blockchain system.

[0122] In another exemplary embodiment, the second deduplication processing module 1630 includes:

[0123] The transaction information acquisition unit is configured to obtain the block height and unique identifier contained in the encapsulated transaction; the adjacent block cache unit is configured to obtain the information of the adjacent blocks corresponding to the encapsulated transaction from the blockchain and cache the information of the adjacent blocks in the preset memory; the transaction deduplication judgment unit is configured to judge whether there is an encapsulated transaction in the preset memory based on the unique identifier.

[0124] In another exemplary embodiment, the neighboring block cache unit includes:

[0125] The transaction cache judgment processing subunit is configured to, during the process of caching the information of adjacent blocks into the preset memory, if the capacity of the preset memory is full, delete the information of the block with the smallest block height from the preset memory, and store the information of the adjacent blocks corresponding to the encapsulated transaction into the preset memory.

[0126] In another exemplary embodiment, the neighboring block cache unit includes:

[0127] The hash processing subunit is configured to store each transaction included in the adjacent blocks in a preset memory in a hash table manner, wherein the unique identifier of each transaction included in the adjacent blocks is used as a key code.

[0128] In another exemplary embodiment, the second deduplication processing module 1630 further includes:

[0129] The reference block height acquisition unit is configured to add one to the block height included in the extracted package transaction to obtain the reference block height; the capacity adaptive adjustment unit is configured to determine whether there is information of an adjacent block corresponding to the reference block height in the preset memory, and adaptively adjust the capacity of the preset memory according to the result information obtained by the determination; the cache information update unit is configured to update the information stored in the preset memory according to the adaptively adjusted capacity.

[0130] In another exemplary embodiment, the capacity adaptive adjustment unit includes:

[0131] The capacity expansion processing subunit is configured to calculate the number of blocks that need to be cached in the preset memory if the result information indicates that there is no information of adjacent blocks corresponding to the reference block height in the preset memory, and expand the preset memory according to the number of blocks that need to be cached.

[0132] In another exemplary embodiment, the capacity adaptive adjustment unit further includes:

[0133] The capacity reduction processing subunit is configured to, if the result information indicates that there is information of an adjacent block corresponding to the reference block height in the preset memory, determine whether the number of blocks cached in the preset memory exceeds a preset threshold; if it is determined that the number of blocks cached in the preset memory does not exceed the preset threshold, perform capacity reduction processing on the preset memory, wherein the preset threshold represents the number of blocks that can be stored in the preset capacity size corresponding to the preset memory.

[0134] In another exemplary embodiment, the capacity adaptive adjustment unit further includes:

[0135] The transaction statistics subunit is configured to count the packaged transactions determined to perform shrinking processing on the preset memory, so as to decide whether to perform shrinking processing on the preset memory according to the obtained statistical results.

[0136] In another exemplary embodiment, the second deduplication processing module 1630 further includes:

[0137] The performance level determination unit is configured to determine the corresponding performance level according to the performance parameters of the blockchain; the capacity calculation unit is configured to calculate the preset capacity size corresponding to the preset memory according to the determined performance level.

[0138] In another exemplary embodiment, the blockchain-based transaction processing device further includes:

[0139] The transaction supplement module is configured to discard the encapsulated transaction if it is determined that there is an encapsulated transaction in the preset memory, and re-take the encapsulated transaction from the transaction pool as a supplement, so that the block to be generated contains a specified number of encapsulated transactions.

[0140] In another exemplary embodiment, the blockchain-based transaction processing device further includes:

[0141] The transaction pool detection module is configured to search for the existence of a transaction in the transaction pool according to the unique identifier of the transaction during the process of storing the transaction in the transaction pool; the block height acquisition and database judgment module is configured to obtain the current latest block height of the blockchain and judge whether the transaction exists in the blockchain database if it is determined that the transaction does not exist in the transaction pool. If it is determined that the transaction does not exist in the blockchain database, it is determined that the transaction is not a duplicate transaction in the transaction pool and the blockchain database.

[0142] In another exemplary embodiment, the blockchain-based transaction processing device further includes:

[0143] The transaction discard processing module is configured to discard the transaction if it is determined that the transaction exists in the transaction pool or the transaction exists in the blockchain database.

[0144] It should be noted that the apparatus provided in the above embodiments and the methods provided in the above embodiments are based on the same concept. The specific manner in which the various modules and units perform their operations has been described in detail in the method embodiments and will not be repeated here. In actual applications, the apparatus provided in the above embodiments can, as needed, allocate the above functions to different functional modules, i.e., divide the internal structure of the apparatus into different functional modules to perform all or part of the functions described above. This is not a limitation herein.

[0145] An embodiment of the present application also provides an electronic device, comprising: one or more processors; 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 implements the blockchain-based transaction processing method provided in the above-mentioned embodiments.

[0146] Figure 17 The following is a schematic diagram showing the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application. Figure 17 The computer system 1700 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0147] like Figure 17 As shown, the computer system includes a central processing unit (CPU) 1701, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1702 or the program loaded from the storage part 1708 to the random access memory (RAM) 1703, such as executing the method described in the above embodiment. Various programs and data required for system operation are also stored in the RAM 1703. The CPU 1701, ROM 1702 and RAM 1703 are connected to each other via a bus 1704. An input / output (I / O) interface 1705 is also connected to the bus 1704.

[0148] The following components are connected to the I / O interface 1705: an input section 1706 including a keyboard, a mouse, and the like; an output section 1707 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 1708 including a hard disk; and a communication section 1709 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 1709 performs communication processing via a network such as the Internet. A drive 1710 is also connected to the I / O interface 1705 as needed. Removable media 1711, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1710 as needed, so that computer programs read from the removable media can be installed in the storage section 1708 as needed.

[0149] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1709, and / or installed from a removable medium 1711. When the computer program is executed by the central processing unit (CPU) 1701, the various functions defined in the system of the present application are executed.

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

[0151] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0152] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. In some cases, the names of these units do not constitute limitations on the units themselves.

[0153] Another aspect of the present application provides a computer-readable storage medium having a computer program stored thereon. When executed by a processor, the computer program implements the aforementioned blockchain-based transaction processing method. The computer-readable storage medium may be included in the electronic device described in the above embodiments, or may exist independently and not be incorporated into the electronic device.

[0154] Another aspect of the present application provides a computer program product or computer program, 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 blockchain-based transaction processing method provided in each of the above embodiments.

[0155] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. Ordinary technicians in this field can easily make corresponding changes or modifications based on the main ideas and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A transaction processing method based on blockchain, characterized in that: The method comprises: Get pending transactions; If it is determined that the transaction does not exist in the transaction pool and the blockchain database, the current latest block height of the blockchain is encapsulated into the transaction to obtain a packaged transaction, and the packaged transaction is stored in the transaction pool; Retrieving the packaged transaction from the transaction pool, and performing transaction deduplication determination on the packaged transaction in a preset memory, wherein the preset memory stores information of adjacent blocks on the blockchain, and the block height of the adjacent block is greater than the block height included in the packaged transaction; If it is determined that the packaged transaction is not a repeated transaction in the preset memory, a block is generated according to the packaged transaction.

2. The method according to claim 1, characterized in that The extracting the packaged transaction from the transaction pool and performing transaction deduplication judgment on the packaged transaction in a preset memory includes: Obtaining the block height and unique identifier contained in the packaged transaction; Obtaining information of adjacent blocks corresponding to the packaged transaction from the blockchain, and caching the information of the adjacent blocks in the preset memory; It is determined whether the packaged transaction exists in the preset memory based on the unique identifier.

3. The method according to claim 2, characterized in that The method further comprises: Add one to the block height included in the packaged transaction to obtain a reference block height; Determining whether information of a neighboring block corresponding to the height of the reference block exists in the preset memory, and adaptively adjusting the capacity of the preset memory according to the result information obtained by the determination; The information stored in the preset memory is updated according to the adaptively adjusted capacity.

4. The method according to claim 3, characterized in that The determining whether there is information of an adjacent block corresponding to the height of the reference block in the preset memory, and adaptively adjusting the capacity of the preset memory according to the result information obtained by the determination, includes: If the result information indicates that there is no information of adjacent blocks corresponding to the reference block height in the preset memory, calculating the number of blocks that need to be cached in the preset memory; The preset memory is increased in capacity according to the number of blocks that need to be cached.

5. The method according to claim 3, characterized in that The determining whether there is information of an adjacent block corresponding to the height of the reference block in the preset memory, and adaptively adjusting the capacity of the preset memory according to the result information obtained by the determination, includes: If the result information indicates that information of a neighboring block corresponding to the reference block height exists in the preset memory, determining whether the number of blocks cached in the preset memory exceeds a preset threshold; If it is determined that the number of blocks cached in the preset memory does not exceed the preset threshold, the preset memory is scaled down, wherein the preset threshold represents the number of blocks that can be stored in the preset capacity corresponding to the preset memory.

6. The method according to claim 5, characterized in that Before performing the shrinking process on the preset memory, the method further includes: The number of package transactions for performing the shrinking process on the preset memory is determined by counting, so as to decide whether to perform the shrinking process on the preset memory according to the obtained statistical result.

7. The method according to claim 2, characterized in that The method further comprises: Determining a corresponding performance level based on the performance parameters of the blockchain; The preset capacity size corresponding to the preset memory is calculated according to the determined performance level.

8. The method according to claim 2, characterized in that The obtaining, from the blockchain, information of adjacent blocks corresponding to the packaged transaction and caching the information of the adjacent blocks in the preset memory includes: In the process of caching the information of the adjacent blocks into the preset memory, if the capacity of the preset memory is full, deleting the information of the block with the smallest block height from the preset memory; The information of the adjacent blocks corresponding to the packaged transaction is stored in the preset memory.

9. The method according to claim 2, characterized in that The obtaining, from the blockchain, information of adjacent blocks corresponding to the packaged transaction and caching the information of the adjacent blocks in the preset memory includes: Each transaction included in the adjacent block is stored in the preset memory in a hash table manner, wherein the unique identifier of each transaction included in the adjacent block is used as a key code.

10. The method according to claim 1, characterized in that The method further comprises: If it is determined that the packaged transaction exists in the preset memory, the packaged transaction is discarded, and other packaged transactions are taken out from the transaction pool as supplements, so that the block to be generated contains a specified number of packaged transactions.

11. The method according to claim 1, wherein The method further comprises: Searching the transaction pool for the existence of the transaction according to the unique identifier of the transaction; If it is determined that the transaction does not exist in the transaction pool, obtain the latest block height of the blockchain and determine whether the transaction exists in the blockchain database. If it is determined that the transaction does not exist in the blockchain database, it is determined that the transaction is not a duplicate transaction in the transaction pool and the blockchain database.

12. The method according to claim 10, characterized in that The method further comprises: If it is determined that the transaction exists in the transaction pool, or if it is determined that the transaction exists in the blockchain database, the transaction is discarded.

13. A transaction processing device based on blockchain, characterized in that: The device comprises: a transaction acquisition module configured to acquire pending transactions; A first deduplication processing module is configured to, if it is determined that the transaction does not exist in both the transaction pool and the blockchain database, encapsulate the current latest block height of the blockchain into the transaction to obtain a packaged transaction, and store the packaged transaction in the transaction pool; a second deduplication processing module configured to retrieve the packaged transaction from the transaction pool and perform transaction deduplication determination on the packaged transaction in a preset memory, wherein the preset memory stores information of adjacent blocks on the blockchain, and the block height of the adjacent block is greater than the block height included in the packaged transaction; The block generation module is configured to generate a block according to the encapsulated transaction if it is determined that the encapsulated transaction is not a duplicate transaction in the preset memory.

14. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that Computer-readable instructions are stored thereon, and when the computer-readable instructions are executed by a processor of a computer, the computer is caused to execute the method according to any one of claims 1 to 12.

16. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 12 is implemented.

Images