Transaction processing method, system, electronic device, and medium

Abstract

The application discloses a transaction processing method, system, electronic equipment and medium, which is applied to a blockchain network including a first node and a second node, and includes the following steps: the first node calls a first interface to obtain an identifier of a transaction set; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the number of transaction operations of the first node, and the identifier of the transaction set is used to indicate the number of transaction operations of the first node; the number of transaction operations is used to represent the number of transactions that can be processed by one operation of the first node on the transactions; the first node determines at least one target transaction in the transaction set according to the identifier of the transaction set; the first node sends the identifier of the at least one target transaction to the second node successively, and the identifier of the at least one target transaction is used to generate a target block; and the interface between a transaction pool and a core engine is unified, so that the core engine does not need to process different transaction pools of multiple types.

Description

Technical Field

[0001] This disclosure generally relates to the field of blockchain technology, and specifically to a transaction processing method, system, electronic device, and medium. Background Technology

[0002] With the development of blockchain technology, it has been widely applied to consensus and ledger recording of transactions. In related technologies, batch transaction pools are added to manage transaction operations at the batch level, enabling concurrent processing of transactions in batches and reducing the time required to acquire transactions. In practical applications, to meet the different transaction needs in various scenarios, batch transaction pools and single / normal transaction pools are typically deployed simultaneously on blockchain nodes for on-demand use.

[0003] The existing nodes use different data interfaces to obtain transactions from the transaction pools based on the granularity of the operations in different transaction pools. However, the different granularity of the obtained transactions greatly increases the logical complexity of the upper-layer scheduling module. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a transaction processing method, system, electronic device and medium that unifies the interface between the transaction pool and the core engine, so that the core engine does not need to process different types of transaction pools differently.

[0005] In a first aspect, embodiments of this application provide a transaction processing method applied to a blockchain network, the blockchain network including a first node and a second node, comprising:

[0006] The first node calls the first interface to obtain the identifier of the transaction set; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the number of transaction operations of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction, and the first node is used to store the transactions of the blockchain network.

[0007] The first node determines at least one target transaction in the transaction set based on the identifier of the transaction set;

[0008] The first node sends the identifier of the at least one target transaction to the second node sequentially, and the identifier of the at least one target transaction is used to generate a target block; the second node is used to schedule the transactions stored in the first node to generate a block.

[0009] The transaction processing method proposed in this application, applied to a blockchain scenario, unifies the interaction rules between various processing modules in a blockchain node and provides a new form of transaction acquisition: transaction sets. When applied to the interaction between a transaction pool and the core engine module (core), the number of transactions in the transaction set is related to the number of transaction operations in the transaction pool. It can be a single transaction or batch transactions, and is compatible with various transaction pool formats. For example, the first node (i.e., the transaction pool) obtains the identifier of the transaction set. After obtaining the identifier, it determines at least one target transaction in the transaction set based on the identifier and sends the identifier of at least one target transaction to the second node (core module) sequentially. This enables the core engine module (core) to obtain the transaction identifier, allowing the subsequent blockchain system to construct blocks based on the obtained transaction identifiers. This application unifies the number of transactions in the interaction between the transaction pool and the core engine module (core). The two can synchronize transaction identifiers based on transaction sets, eliminating the need for different interaction formats for different types of transaction pools. It is compatible with transaction pools with various operational granularities, making information retrieval in the blockchain system more convenient.

[0010] Furthermore, by unifying the interaction rules between the transaction pool and the core engine module, the core engine module is unaware of the number of operations performed on transactions by the transaction pool. Therefore, the transaction pool can be further expanded based on the unified interaction rules to add more transaction pools that can meet the different numbers of operations performed on transactions, thereby effectively improving the scalability of the transaction pool.

[0011] Secondly, embodiments of this application provide a transaction processing method, including:

[0012] The second node acquires the identifier of at least one target transaction sent sequentially by the first node; the identifier of the target transaction is determined based on the identifier of the transaction set, which is acquired by the first node; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the number of transaction operations performed by the first node, the identifier of the transaction set is used to indicate the number of transaction operations performed by the first node, the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction, the first node is used to store transactions of the blockchain network; the second node is used to schedule the transactions stored in the first node to generate blocks.

[0013] A target block is generated based on the identifier of the at least one target transaction.

[0014] Thirdly, embodiments of this application provide a transaction processing system, including a first node and a second node.

[0015] The first node is used to obtain the identifier of a transaction set, determine at least one target transaction in the transaction set based on the identifier of the transaction set, and send the identifier of the at least one target transaction to the second node sequentially; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the number of transaction operations of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction, and the first node is used to store transactions of the blockchain network;

[0016] The second node is used to obtain the identifier of at least one target transaction sent sequentially by the first node, and generate a target block based on the identifier of the at least one target transaction; the second node is used to schedule the transactions stored in the first node to generate a block.

[0017] Fourthly, embodiments of this application provide a transaction processing apparatus, including:

[0018] Storage unit, used to store target transactions;

[0019] An interface unit is used to obtain the identifier of a transaction set, determine at least one target transaction in the transaction set based on the identifier, and send the identifier of the at least one target transaction to the second node sequentially. The identifier of the at least one target transaction is used to generate a target block. The transaction set includes at least one transaction, the number of transactions in the transaction set is related to the transaction operation data of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, and the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation. The first node is used to store transactions of the blockchain network. The second node is used to schedule the transactions stored in the first node to generate blocks.

[0020] Fifthly, embodiments of this application provide a transaction processing apparatus, including:

[0021] An interface unit is used to obtain the identifier of at least one target transaction sent sequentially by the first node; the identifier of the target transaction is determined based on the identifier of the transaction set, which is obtained by the first node calling the first interface; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the transaction operation data of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, and the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction; the first node is used to store transactions of the blockchain network; the second node is used to schedule the transactions stored in the first node to generate blocks.

[0022] The construction unit generates a target block based on the identifier of the at least one target transaction.

[0023] In a sixth aspect, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in embodiments of this application.

[0024] In a seventh aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in embodiments of this application.

[0025] Eighthly, embodiments of this application provide a computer program product, including a computer program, characterized in that, when the computer program is executed by a processor, it implements the method described in embodiments of this application.

[0026] The transaction processing method proposed in this application, applied to a blockchain scenario, unifies the interaction rules between various processing modules in a blockchain node and provides a new form of transaction acquisition: transaction sets. When applied to the interaction between a transaction pool and the core engine module (core), the number of transactions in the transaction set is related to the number of transaction operations in the transaction pool. It can be a single transaction or batch transactions, and is compatible with various transaction pool formats. For example, the first node (i.e., the transaction pool) obtains the identifier of the transaction set. After obtaining the identifier, it determines at least one target transaction in the transaction set based on the identifier and sends the identifier of at least one target transaction to the second node (core module) sequentially. This enables the core engine module (core) to obtain the transaction identifier, allowing the subsequent blockchain system to construct blocks based on the obtained transaction identifiers. This application unifies the number of transactions in the interaction between the transaction pool and the core engine module (core). The two can synchronize transaction identifiers based on transaction sets, eliminating the need for different interaction formats for different types of transaction pools. It is compatible with transaction pools with various operational granularities, making information retrieval in the blockchain system more convenient.

[0027] Furthermore, by unifying the interaction rules between the transaction pool and the core engine module, the core engine module is unaware of the number of operations performed on transactions by the transaction pool. Therefore, the transaction pool can be further expanded based on the unified interaction rules to add more transaction pools that can meet the different numbers of operations performed on transactions, thereby effectively improving the scalability of the transaction pool.

[0028] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0029] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0030] Figure 1 The implementation environment architecture diagram of the transaction processing method provided in the embodiments of this application is shown;

[0031] Figure 2 A schematic flowchart of a transaction processing method provided in an embodiment of this application is shown;

[0032] Figure 3 This diagram illustrates the principle of how the first node synchronizes the identifier of the target transaction with the second node.

[0033] Figure 4 The diagram shows the structure of the initial block and the original block;

[0034] Figure 5 This diagram illustrates the principle behind the execution order of other data in the initial block.

[0035] Figure 6 A schematic diagram illustrating the principle of reconstructing the initial block based on the scheduling execution result is shown;

[0036] Figure 7 A flowchart illustrating a transaction processing method provided in another embodiment of this application is shown;

[0037] Figure 8 This diagram illustrates the principle of restoring the target block synchronized by the third node.

[0038] Figure 9 A flowchart illustrating a transaction processing method provided in yet another embodiment of this application is shown;

[0039] Figure 10 A block diagram of a transaction processing apparatus provided in one embodiment of this application is shown;

[0040] Figure 11 A block diagram of a transaction processing apparatus according to yet another embodiment of this application is shown;

[0041] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing an electronic device or server according to embodiments of this application is shown. Detailed Implementation

[0042] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0043] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0044] For the specific implementation environment of the transaction processing method proposed in this application, please refer to [link / reference needed]. Figure 1 . Figure 1 The implementation environment architecture diagram of the transaction processing method provided in the embodiments of this application is shown.

[0045] like Figure 1 As shown, the implementation environment architecture includes: execution node 10 and request node 20. Execution node 10 is used to store transactions of the blockchain network and provide transaction-related data for constructing blocks to request node 20, as well as operation instructions sent by request node 20 through a unified interface. Request node 20 schedules the transactions stored by execution node 10 according to first node 10 and constructs blocks based on the transaction-related data provided by execution node 10.

[0046] In the specific implementation, before constructing a block, the requesting node 20 can send a transaction retrieval instruction to the execution node 10 to schedule the transactions stored in the execution node 10. The execution node 10 responds to the transaction retrieval instruction to obtain the identifier of the transaction set. The identifier of the transaction set includes the identifier of the target transaction to be synchronized to the requesting node 20. The requesting node 20 can construct a block based on the identifier of the target transaction synchronized by the execution node 10.

[0047] It should be noted that in a blockchain scenario, execution node 10 and request node 20 can be functional modules within a blockchain node. For example, execution node 10 could be the transaction pool module within a blockchain node, and request node 20 could be the core engine module within a blockchain node. The blockchain node constructs the target block to be uploaded to the chain based on the first node 10 and the second node 20, and completes the on-chain operation of the transaction based on the consensus operation of the consensus node.

[0048] Assume the blockchain system includes: a first blockchain node 101 and a second blockchain node 102.

[0049] It should be understood that, regardless of whether it's a consortium blockchain or a public blockchain, the entire blockchain network consists of multiple nodes. These include consensus nodes that ensure data consistency across the entire blockchain system, synchronization nodes that only synchronize data and do not participate in consensus, and light nodes that only synchronize partial data. In this embodiment, both the first blockchain node 101 and the second blockchain node 102 are consensus nodes in the blockchain network. Consensus nodes, synchronization nodes, and light nodes can all receive transactions. However, after receiving a transaction, the synchronization nodes and light nodes will synchronize the transaction to the consensus node, which then constructs a block based on the transaction.

[0050] The first blockchain node 101 and the second blockchain node 102 are each configured with a first node 10. The first node 10 is a transaction pool (MemPool) used to store transactions synchronized to the blockchain nodes by synchronization nodes, light nodes, and clients. The first node 10 broadcasts transactions sent by clients to other consensus nodes. The purpose of broadcasting transactions is to ensure consistency among consensus nodes as much as possible, facilitating rapid verification of the validity of blocks and transactions during subsequent consensus processes.

[0051] In this context, the first node 10 of the first blockchain node 101 and the first node 10 of the second blockchain node 102 can communicate using P2P (Peer-to-Peer) technology. For example, the first node 10 of the first blockchain node 101 can broadcast a transaction to the first node 10 of the second blockchain node 102 via P2P. P2P communication refers to a communication technology that relies on a group of users (peers) to exchange information without relying on a central server.

[0052] The first blockchain node 101 and the second blockchain node 102 are also equipped with a second node 20, which serves as the core engine and plays a central scheduling role. Specifically, when the first blockchain node 101 is the master node and the second blockchain node 102 is the slave node, the consensus module 30 of the first blockchain node 101 notifies the second node 20 to construct a block and execute transactions. The constructed block is then sent to the consensus module 30, which constructs a proposal based on the block and broadcasts it to the second blockchain node 102. After receiving and verifying the proposal, the second blockchain node 102 instructs its second node 20 to verify the block's validity and execute the transactions. If the slave node's transaction execution result matches that of the master node, the block is considered valid.

[0053] In related technologies, the first node 10 can include three types: single, normal, and batch. The internal implementation of the single transaction pool contains only one ConfigTxQueue and CommonTxQueue cache structures. Therefore, broadcasting, retrieving, and deleting transactions are all done at the single transaction level (i.e., the number of operations). The internal implementation of the normal transaction pool contains one ConfigTxQueue and multiple CommonTxQueue cache structures. Therefore, the normal transaction pool broadcasts transactions at the batch level. When retrieving and deleting transactions, operations can be performed concurrently from multiple cache structures, which greatly improves performance. Furthermore, both single and normal transaction pools support block pruning mode, meaning that only the transaction identifier is included in the block, without the need for the complete transaction. The internal implementation of the batch transaction pool includes a ConfigTxBatchQueue and multiple CommonTxBatchQueue cache structures (determined by the number of nodes receiving transactions). All operations in the transaction pool are processed in parallel at the batch level (i.e., the number of operations), which further improves the performance of the transaction pool. Furthermore, the blocks are compressed to the extreme. When constructing a block, only the transaction batch identifier needs to be placed in the block, without the actual transaction, thus improving the overall consensus efficiency.

[0054] As can be seen, the three transaction pools each have their own characteristics, and therefore, they are implemented in three different modes. Since all operations in the batch transaction pool are performed in batches, while the operations in the single and normal transaction pools are performed on a transaction-by-transaction basis, the caching modules within each transaction pool have different data structures and significantly different interface definitions. Furthermore, the content of the block construction based on transactions also differs, requiring the core engine to adapt to different transaction pools, increasing the complexity of the execution logic.

[0055] Based on this, this application proposes a transaction processing method, system, electronic device, and medium to unify the interface between the transaction pool and the core engine, so that the core engine does not need to process different types of transaction pools differently.

[0056] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation instruction steps as shown in the following embodiments or drawings, the method may include more or fewer operation instruction steps based on conventional or non-creative effort. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the device executes the method, it may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0057] Please refer to Figure 2 , Figure 2 A flowchart illustrating a transaction processing method according to an embodiment of this application is shown. The execution entity of this method can be the execution node 10 described above. Figure 2 As shown, the method includes the following steps:

[0058] 201. The first node obtains the identifier of the transaction set. The transaction set includes at least one transaction. The number of transactions in the transaction set is related to the number of transaction operations performed by the first node. The identifier of the transaction set is used to indicate the number of transaction operations performed by the first node. The number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction. The first node is used to store the transactions of the blockchain network.

[0059] It should be noted that a transaction set is a collection of transactions sent from the first node to the second node for the second node to construct a block. The number of transactions in the transaction set is related to the number of transaction operations performed by the first node. For example, when the first node is a single or normal transaction pool, the transaction set contains one transaction; when the first node is a batch transaction pool, the transaction set contains multiple transactions corresponding to a single transaction batch.

[0060] In one feasible embodiment, the identifier of the transaction set can be determined based on the number of operations performed by the first node. For example, the identifier of the transaction (or transaction batch) whose number of operations performed by the first node is determined can be directly used as the identifier of the transaction set, or a new identifier can be constructed based on the identifier of the transaction (or transaction batch) whose number of operations performed by the first node is determined. For example, taking the identifier of the transaction (or transaction batch) whose number of operations performed by the first node is determined as the identifier of the transaction set as an example, when the first node is a single or normal transaction pool, the number of operations performed by the first node is one transaction, so the identifier of the transaction set is the identifier of the transaction, such as txID. When the first node is a batch transaction pool, the number of operations performed by the first node is one transaction batch, so the identifier of the transaction set is the identifier of the transaction batch, such as batchID.

[0061] In this embodiment of the application, before constructing the target block, the second node may request the identifier of the target transaction from the first node. The identifier of the target transaction is the identifier of the transaction used to construct the target block.

[0062] In a feasible embodiment, the first node obtains the transaction acquisition instruction sent by the second node through the sixth interface, and in response to the transaction acquisition instruction, calls the first interface to obtain the identifier of the transaction set.

[0063] In other words, the requesting node (second node) calls the sixth interface to send a transaction retrieval instruction to the executing node (first node). In response to the instruction, the requesting node calls the first interface to retrieve the identifier of the transaction set. In other words, the second node calls the sixth interface to schedule the transactions stored by the first node to obtain the identifier of at least one target transaction used to construct the target block.

[0064] Among them, the first interface, the sixth interface, and other interfaces mentioned below are not limited to hardware interfaces or virtual interfaces; they can also be function wrappers, etc.

[0065] 202. The first node determines at least one target transaction in the transaction set based on the identifier of the transaction set.

[0066] In other words, after obtaining the identifier of the transaction set, the specific target transactions contained within the transaction set can be determined based on the identifier. In other words, it is necessary to determine the transaction identifier (or transaction batch identifier) ​​corresponding to the identifier of the transaction set, thereby determining the target transaction corresponding to the transaction identifier (or at least one target transaction corresponding to the transaction batch identifier).

[0067] It should be understood that when the identifier of the transaction set is the identifier of the transaction granularity handed over by the transaction pool to the core engine, the target transaction can be directly determined based on the transaction identifier or the transaction batch identifier; when the identifier of the transaction set is a new identifier constructed based on the identifier of the transaction granularity handed over by the transaction pool to the core engine, the transaction identifier or the transaction batch identifier is determined by the identifier of the transaction set according to the rules for constructing the new identifier.

[0068] In one feasible embodiment, the identifier of the transaction set includes the transaction identifier of at least one transaction corresponding to the transaction operation data. The first node determines at least one target transaction in the transaction set according to the identifier of the transaction set, including: determining the identifier of the target transaction sent to the second node each time from the at least one transaction identifier based on the storage order of at least one transaction in the first node and the number of transactions included in the target transaction; and determining the transaction in the transaction set corresponding to the target transaction identifier as the target transaction.

[0069] In other words, the identifier of a transaction set is either a transaction identifier or a transaction batch identifier. Therefore, when the identifier of a transaction set is a transaction batch identifier, the identifier of the transaction set includes at least one transaction identifier corresponding to at least one transaction of the transaction batch identifier. For example, when the transaction pool is a batch transaction pool and 1000 transactions are considered as a batch, the transaction batch identifier batch1 corresponding to the identifier of the transaction set can contain 1000 transactions, thus corresponding to transaction identifiers for 1000 transactions. When the transaction pool is a single or normal transaction pool, the identifier of the transaction set corresponds to the transaction identifier of one transaction.

[0070] Furthermore, the target transaction includes the number of transactions synchronized by the transaction pool to the second node through the first interface. In a feasible embodiment, the number of transactions can be all transactions in the transaction set synchronized to the second node, or it can be a portion of the transactions. It should be understood that when the number of transactions is a portion of the transactions in the transaction set synchronized to the second node, it indicates that the first node synchronizes at least one transaction in the transaction set to the second node in multiple batches through the first interface.

[0071] For example, when the first node is a single or normal transaction pool, the identifier of the transaction set corresponds to the transaction identifier tx1 of a transaction, and the number of transactions is one transaction. Then, we can traverse the transaction identifiers corresponding to the identifier of the transaction set to obtain the transaction identifier tx1 of a transaction corresponding to the identifier of the transaction set. Based on the number of transactions included in the target transaction, we determine tx1 as the identifier of the target transaction, and at the same time, we determine that the transaction corresponding to tx1 is the target transaction.

[0072] When the first node is a batch transaction pool, the transaction set identifier corresponds to the identifier batch1 of a transaction batch, and the number of transactions is one transaction. Then the identifier of the transaction set contains at least one transaction identifier of at least one transaction contained in the transaction batch1, for example, 1000 transaction identifiers. Iterate through each of the 1000 transaction identifiers. Based on the storage order of the 1000 transactions in batch 1 and the number of transactions included in the target transaction, determine the identifier of the target transaction to be sent to the second node each time. For example, the 1000 transactions correspond to transactions tx1, tx2, ..., tx1000. When the number of target transactions is 1, determine one transaction as the target transaction from the 1000 transactions each time. That is, the first time, use transaction identifier tx1 from the 1000 transaction identifiers as the identifier of the target transaction and determine the transaction corresponding to tx1 as the target transaction. The second time, use tx2 as the identifier of the target transaction in order and determine the transaction corresponding to tx2 as the target transaction. And so on, until the 1000th time, use tx1000 as the identifier of the target transaction and determine the transaction corresponding to tx1000 as the target transaction.

[0073] Optionally, the number of transactions can also be multiple, such as two. In this case, when the first node is a single or normal transaction pool, the transaction tx1 included in the transaction set is still used as the identifier of the target transaction, and the transaction corresponding to tx1 is determined to be the target transaction. When the first node is a batch transaction pool, the transaction identifiers tx1 and tx2 out of 1000 transaction identifiers are used as the identifiers of the target transaction in the first case, and the transactions corresponding to tx1 and tx2 are determined to be the target transactions. In the second case, tx3 and tx4 are used as the identifiers of the target transaction, and the transactions corresponding to tx3 and tx4 are determined to be the target transactions.

[0074] 203. The first node synchronizes the identifier of at least one target transaction to the second node. The identifier of at least one target transaction is used to generate the target block. The second node is used to schedule the transactions stored in the first node to generate the target block.

[0075] In other words, the first node ultimately synchronizes the identifiers of at least one target transaction to the second node through the first interface. It should be understood that the first interface can synchronize the identifiers of the target transactions corresponding to the number of transactions determined during the process of traversing the at least one transaction identifier included in the transaction set to the second node, or it can synchronize all the identifiers of the target transactions determined together to the second node after the traversal is completed and all the identifiers of the target transactions are obtained.

[0076] It is also important to understand that after the first node calls the first interface to obtain the identifier of the transaction set, the first interface can determine at least one target transaction in the transaction set based on the obtained identifier of the transaction set according to the internally encapsulated execution strategy, and synchronize the identifier of at least one target transaction to the second node.

[0077] In a feasible embodiment, the sixth interface can be Fetch(), and the first interface is []TxSet. The second node calls the sixth interface Fetch() to send a transaction retrieval instruction to the first node. The first node retrieves the identifier of the transaction set by calling the first interface. The identifier of the transaction set can be TxSet(txID) or TxSet(batchID) (or directly txID or batchID). That is, the identifier of the transaction set corresponds to a transaction identifier or a transaction batch identifier based on the operation granularity of the transaction pool. A transaction batch identifier can correspond to multiple transaction identifiers based on the mapping relationship between transaction batch identifiers and transaction identifiers stored in the transaction pool. Then, the first interface TxSet uses the encapsulated iterator to traverse each transaction identifier in at least one transaction identifier, and determines the identifier of the target transaction in at least one transaction based on the number of transactions included in the target transaction, such as tx1, tx2, tx3, and tx4. The transactions corresponding to tx1, tx2, tx3, and tx4 are determined as target transactions, and tx1, tx2, tx3, and tx4 are synchronized to the second node.

[0078] For example, Figure 3 (a) illustrates the process of synchronizing the target transaction identifier to the second node when the first node is a batch transaction pool. Figure 3 (b) illustrates the process of synchronizing the identifier of the target transaction to the second node when the first node is a single or normal transaction pool.

[0079] In one feasible embodiment, the first node can also be another transaction pool with more than one transaction. That is, when a transaction pool with a different number of operations is constructed based on other needs, a first interface (or operation steps corresponding to the first interface) can be configured for the new transaction pool. This allows the new transaction pool to provide the second node with the identifier of the target transaction for constructing the block, without the need to improve the execution logic of the second node.

[0080] The transaction processing method proposed in this application, applied to a blockchain scenario, unifies the interaction rules between various processing modules in a blockchain node and provides a new form of transaction acquisition: transaction sets. When applied to the interaction between a transaction pool and the core engine module (core), the number of transactions in the transaction set is related to the number of transaction operations in the transaction pool. It can be a single transaction or batch transactions, and is compatible with various transaction pool formats. For example, the first node (i.e., the transaction pool) obtains the identifier of the transaction set. After obtaining the identifier, it determines at least one target transaction in the transaction set based on the identifier and sends the identifier of at least one target transaction to the second node (core module) sequentially. This enables the core engine module (core) to obtain the transaction identifier, allowing the subsequent blockchain system to construct blocks based on the obtained transaction identifiers. This application unifies the number of transactions in the interaction between the transaction pool and the core engine module (core). The two can synchronize transaction identifiers based on transaction sets, eliminating the need for different interaction formats for different types of transaction pools. It is compatible with transaction pools with various operational granularities, making information retrieval in the blockchain system more convenient.

[0081] Furthermore, by unifying the interaction rules between the transaction pool and the core engine module, the core engine module is unaware of the number of operations performed on transactions by the transaction pool. Therefore, the transaction pool can be further expanded based on the unified interaction rules to add more transaction pools that can meet the different numbers of operations performed on transactions, thereby effectively improving the scalability of the transaction pool.

[0082] In another embodiment of this application, a specific implementation of constructing a target block is also provided. For example, a first node receives an initial block sent by a second node through a second interface. The initial block includes a first execution result of at least one target transaction and an execution order of at least one target transaction. The first execution result is obtained by the second node executing the target transaction based on the identifier of at least one target transaction. The initial block is parsed, the execution order of at least one target transaction is verified, and a target block is generated based on the verified execution order and the first execution result of at least one target transaction.

[0083] In other words, the second node sends its constructed initial block to the first node through the second interface. For example... Figure 5 As shown, the initial block 50 includes a block header 501, a block body 502, and additional data 503. The block body 502 stores the first execution result of at least one target transaction. The first execution result is obtained by the second node executing the target transaction based on the identifier of the target transaction. The additional data 503 stores the identifiers of each target transaction.

[0084] In a feasible embodiment, after the second node obtains the identifiers of at least one target transaction successively sent by the first node, it can establish an original block. Specifically, the block body 502 can be constructed based on the identifiers of the target transactions. For example, the identifiers of the target transactions are stored in the block body 502. Figure 4 As shown, the original block 51 is constructed by the second node based on the identifier of the received target transaction. At this time, the block body 512 stores the identifier of the target transaction sent by the first node. Then, the second node calls and executes the target transaction from the first node based on the identifier of the target transaction, stores the first execution result corresponding to the identifier of the target transaction in the block body 502 of the initial module 50, and adjusts the storage order of the identifiers of the target transaction in the block body 512 based on the execution order of the target transaction.

[0085] It should be noted that the second node stores a scheduling strategy for scheduling and executing transactions. The second node can schedule target transactions from the first node based on the scheduling strategy and execute the target transactions to obtain the execution result of the first transaction. Since the execution order generated by the scheduling strategy may differ from the order in which transactions are stored in the transaction pool, the identifier of the target transaction stored by the second node according to the execution order may be different from the sequence number of the target transaction identifier sent to the second node by the first node.

[0086] In another feasible embodiment, the first node receives execution status information sent by the second node through a third interface. The execution status information is used to characterize whether the execution time of at least one target transaction has expired. The first node sends the identifier of the transaction whose execution time has expired to the second node.

[0087] In other words, when the second node invokes and executes the target transaction from the first node based on the target transaction's identifier, a scheduling timeout may occur, causing the second node to fail to complete the execution within the preset time. In other words, the target transaction fails to be executed by the second node, and therefore, the second node cannot properly store the first execution result corresponding to the target transaction into the block body. Based on this, the second node sends the execution status information of each target transaction to the first node through a third interface. This execution status information includes, but is not limited to, successful execution and unsuccessful execution, so that the first node can synchronize the identifier of the timed-out target transaction again.

[0088] In a feasible embodiment, when the first node receives the transaction acquisition instruction again through the sixth interface, it can send the identifier of the timed-out target transaction to the second node again through the first interface.

[0089] For example, the second node configures execution status information for each target transaction received based on the first interface. Successfully executed target transactions are marked as "ReBuild," and unsuccessfully executed target transactions are marked as "ReAdd." When the first node receives a transaction retrieval instruction again through the sixth interface, it synchronizes transactions marked with "ReAdd" (unsuccessfully executed) to the second node. Based on this, by identifying the transaction execution status, first nodes at different operational granularities can uniformly handle unsuccessfully executed transactions, improving the overall operating speed of the transaction pool and reducing the complexity of configuring new transaction pools.

[0090] In a feasible embodiment, after receiving the initial block sent by the second node through the second interface, the first node parses the initial block, verifies the execution order of at least one target transaction, and generates a target block based on the verified execution order and the first execution result of at least one target transaction.

[0091] In other words, the first node parses the block body of the initial block to obtain the execution order and first execution result of each target transaction. Then, based on the first execution result of the target transaction, it generates the corresponding execution result hash and stores the target transaction's tag and execution result hash in the other data 503 of the initial block according to the execution order of each target transaction.

[0092] In a feasible embodiment, when the first node is a single or normal transaction pool, the operation granularity of the first node is a single transaction. Therefore, the target transaction's label and execution result hash stored in other data 503 correspond to a single transaction. For example, Figure 5 As shown in (a), the other data 503 of the initial block 50 contains the tags txid_4, txid_2, txid_3 and txid_1 of the target transactions in the same order as in the block body 502, as well as the result hash ResultHash of each target transaction.

[0093] In another embodiment, when the first node is a batch transaction pool, the operation granularity of the first node is the transaction batch. Therefore, the labels and execution result hashes of the target transactions stored in other data 503 correspond to the transaction batches, and the execution order of each target transaction in the transaction batch is indicated by labeling the transaction batches. For example, as shown... Figure 5As shown in (b), the other data 503 of the initial block 50 stores transaction batches containing four target transactions in the order of their identifiers, and the execution order of each target transaction is marked by a number after the arrow. The execution order of each target transaction is indicated by marking its corresponding position within the transaction batch. For example, batch_1 contains target transactions tx1 and tx2, and batch_2 contains target transactions tx3 and tx4. The execution order of the target transactions recorded in block body 502 is tx4, tx2, tx3, and tx1. That is, the execution order of tx1 is 3, the execution order of tx2 is 1, the execution order of tx3 is 2, and the execution order of tx4 is 0. Furthermore, the execution result hashes stored in the other data 503 also correspond to the transaction batches; the execution result hash for batch1 is batch1ResultHash, and the execution result hash for batch2 is batch2ResultHash.

[0094] It should be understood that the execution result hash is obtained by hashing the first execution result of the target transaction. When the first node is a single or normal transaction pool, the execution result hash is obtained by hashing the first execution result corresponding to the target transaction itself. When the first node is a batch transaction pool, the execution result hash corresponding to the transaction batch is calculated based on the first execution results of all target transactions in the transaction batch. Calculating the execution result hash corresponding to the transaction batch based on the first execution results of all target transactions in the transaction batch can be achieved by concatenating the first execution results of all target transactions in the transaction batch to obtain the first execution result corresponding to the transaction batch, and then calculating the execution result hash corresponding to the transaction batch based on the first execution result corresponding to the transaction batch.

[0095] In a feasible embodiment, when the second node constructs the initial block 503, it further constructs other data 503 based on the identifier of at least one target transaction sent by the first node. That is, before sending the initial block to the first node, the other data 503 of the initial block stores data, which is an identifier sent by the second node from the first node that matches the operation granularity, such as the key of the transaction identifier or the key of the transaction batch. When the second node schedules and executes the target transaction based on the identifier of the target transaction, scheduling timeouts are likely to occur, causing the identifier of the target transaction actually stored in the block body of the initial block to be different from the identifier initially based on the target transaction. The other data needs to be constructed based on the synchronized target data. Especially when the first node is a batch transaction pool, the transaction pool may change the correspondence between the identifier of the transaction batch and the transaction due to the failure of some transactions to be executed successfully. If the transaction identifiers stored in the other data are not updated, the first node will be unable to generate the target block based on the parsing of the initial block.

[0096] Based on this, after receiving the execution status information sent by the second node through the third interface, the first node, based on the successfully executed target transactions sent by the second node, for example, resends transactions with the successful execution flag "ReBuild" to the second node, so that the second node can store the updated target transaction identifiers in other data 503. For example, as shown... Figure 6 As shown in (a), when the first node is a single or normal transaction pool, if target transaction tx1 fails to execute successfully during the second node's scheduling execution, the first node resends the identifiers of target transactions tx2, tx3, and tx4 to the second node. The second node then generates other data based on the re-received identifiers of the target transactions. For example... Figure 6 As shown in (b), when the first node does not have a batch transaction pool, if the target transaction tx1 is not successfully executed during the second node's scheduling and execution, the first node generates new transaction batch identifiers batch_3 and batch_4 based on the successfully executed target transactions tx2, tx3 and tx4. Among them, batch_3 only contains the successfully executed target transaction tx2, and batch_4 contains the executed target transactions tx3 and tx4.

[0097] In a feasible embodiment, the second interface is AfterProposing(), and the third interface is RegenerateTxs(ts[]TxSet).

[0098] Therefore, this application enables the first node to perform the operation of generating other data for the target block through a third interface between the second node and the first node. This reduces the difficulty for the second node to generate the target block based on the operation granularity of different transaction pools. At the same time, the unified interface makes the second node unaware of the operation granularity of the transaction pool, thereby improving the scalability of the blockchain node.

[0099] In another feasible embodiment, a specific implementation method is also provided for blockchain nodes to achieve consensus on target blocks as slave nodes. For example, refer to... Figure 7 The method includes the following steps:

[0100] 701, the first node receives the target block synchronized by the third node through the fourth interface; the target block synchronized by the third node is generated by the identifier of at least one target transaction sent by the fourth node to the third node.

[0101] It should be noted that, in this embodiment, the blockchain nodes containing the first and second nodes are slave nodes, used to achieve consensus on the target blocks synchronized by the master node. The third and fourth nodes are nodes in the master node blockchain; the third node is the core engine of the master node blockchain, and the fourth node is the transaction pool of the master node blockchain.

[0102] In one feasible embodiment, within the master node blockchain node, the fourth node obtains the identifier of the transaction set and sequentially sends the identifiers of at least one target transaction to the third node. The third node generates an initial block based on the target transactions and sends the initial block to the fourth node. The fourth node parses the initial block, verifies the execution order of the at least one target transaction recorded in the initial block, and generates a target block based on the verified execution order and the first execution result of the at least one target transaction. The fourth node sends the generated target block to the third node, enabling the third node to broadcast the target block to at least one slave node's second node through the consensus module. The slave node's second node then sends the received target block to the first node through the fourth interface.

[0103] 702, parse the target block synchronized by the third node to obtain the identifier of at least one target transaction to be verified.

[0104] It should be understood that the block body and other data of the target block store the identifier of the target transaction. Therefore, the identifier of the target transaction can be obtained by parsing any part of the block body and other data of the target block.

[0105] In one feasible embodiment, to achieve extreme block compression, and considering that the corresponding transaction data is typically already stored in other consensus nodes, the master node can also delete the data stored in the block body of the target block before broadcasting, thereby reducing the storage of transaction data in the block. Specifically, the fourth node can synchronize the finally generated target block to the third node. Based on compression requirements, the third node prunes the target block, deleting data stored in the block body or other data in the target block. That is, in pruning mode, data stored in the block body of the target block is deleted, and in non-pruning mode, data stored in other data in the target block is deleted.

[0106] In other words, when the target block is a pruned block, the first node parses the other data of the target block to obtain the identifier of at least one target transaction to be verified. When the target block is a non-pruned block, the first node parses the block body of the target block to obtain the identifier of at least one target transaction to be verified.

[0107] 703, Obtain at least one target transaction to be verified based on the identifier of at least one target transaction to be verified.

[0108] It should be noted that, under normal circumstances, after receiving a transaction sent by a client, the transaction pool will broadcast the transaction so that all consensus nodes in the blockchain have the transaction stored in their transaction pools. Therefore, the first node can find the target transaction stored in its own memory based on the identifier of the target transaction and load the found target transaction into the block body of the target block.

[0109] In one feasible embodiment, the first node may fail to store the target transaction to be verified due to a broadcast error. In this case, the first node communicates with the transaction pool of the master node (i.e., the fourth node) to request the target transaction to be verified. Based on the request of the first node, the fourth node sends the target transaction to the first node through broadcast so that the first node can obtain the target transaction to be verified.

[0110] 704. Obtain a consensus block based on the execution result of at least one target transaction to be verified and the target block.

[0111] It should be understood that after the first node obtains at least one target transaction, the second node can execute at least one target transaction, obtain the execution result, and then vote on the target block based on the execution result to obtain the consensus block.

[0112] In a feasible embodiment, obtaining a consensus block based on the execution result of at least one target transaction to be verified and a target block includes: a first node synchronizing the identifier of at least one target transaction to be verified to a second node, enabling the second node to execute at least one target transaction to be verified and obtain a second execution result; the first node receiving the second execution result synchronized by the second node through a fifth interface; the first node performing verification based on the second execution result and the first execution result in the target block synchronized by the third node; and generating a consensus block based on the verification result.

[0113] In other words, after the first node obtains the target transaction to be verified, it can synchronize the identifier of at least one target transaction to be verified to the second node, so that the second node can schedule at least one target transaction from the first node and execute it based on the identifier of at least one target transaction to be verified, obtain the second execution result, and synchronize the second execution result to the first node through the fifth interface.

[0114] In another feasible embodiment, the first node can first store the target transaction in the block body to restore the target block, and then synchronize the restored target block to the second node.

[0115] For example, such as Figure 8 As shown in (a), when the fourth node constructing the target block is a single or normal transaction pool, and the target block is a block in pruning mode, the first node parses the other data of the target block to obtain the identifiers of the target transactions tx4, tx2, tx3 and tx1, and then restores the target transactions tx4, tx2, tx3 and tx1 into the block body of the target block.

[0116] like Figure 8 As shown in (b), when the fourth node constructing the target block is a batch transaction pool and the target block is a block in pruning mode, the first node parses other data of the target block to obtain the identifier of the transaction batch. Then, it can determine the identifiers of the target transactions tx4, tx2, tx3 and tx1 based on the mapping relationship between the transaction batches and transactions stored in its own storage. Alternatively, it can obtain the identifiers of the target transactions tx4, tx2, tx3 and tx1 through communication with the fourth node. Finally, the target transactions tx4, tx2, tx3 and tx1 are restored to the block body of the target block.

[0117] like Figure 8 As shown in (c), when the target block is a block in non-pruning mode, since each target transaction is already stored in the block body, the first node can verify the target transaction through the tag and signature of the target data in the block body to ensure the reliability of each data. If the verification is successful, the target block will be synchronized to the node, or if the verification fails, the target block will be voted against directly.

[0118] It should be understood that in the non-pruning mode, the block body records all the information of the target transaction, including but not limited to the target transaction identifier, the target transaction, the target transaction signature data, the first execution result corresponding to the target transaction, etc., which can be set according to the block verification requirements, and this application does not make specific limitations.

[0119] Furthermore, after obtaining the target block, the second node directly executes the target transaction stored in the block body of the target block to obtain the second execution result.

[0120] In a feasible embodiment, the second node synchronizes the second execution result to the first node through the fifth interface, so that the first node can verify based on the second execution result and the first execution result in the target block synchronized by the third node, and generate a consensus block according to the verification result.

[0121] For example, when the target block synchronized by the third node is a module in pruning mode, the first node can parse the execution result hash stored in other data of the target block to obtain the first execution result, and determine whether the first execution result and the second execution result are consistent. If they are consistent, the first node votes on the target block to generate a consensus block; if they are inconsistent, the first node votes against the target block and deletes the transaction with the inconsistent execution result from its own transaction pool.

[0122] When the target block synchronized by the third node is a module in non-pruning mode, the first node can directly obtain the first execution result of the target transaction from the block body and determine whether the first execution result and the second execution result are consistent. If they are consistent, the first node votes on the target block to generate a consensus block. If they are inconsistent, the first node votes against the target block and deletes the transaction with inconsistent execution result from its own transaction pool.

[0123] It should be understood that, since the execution result hash of other data stored in the target block synchronized by the third node is the execution result hash of the transaction batch when the fourth node is a batch transaction pool, the first execution result and the second execution result are compared on a batch basis.

[0124] In one feasible embodiment, the reason for the inconsistency between the first execution result and the second execution result is usually that the target transaction contains a random function, such as a time function, which makes the time when the third node calculates the first execution result inconsistent with the time when the second node calculates the second execution result, thus causing the first execution result and the second execution result to be inconsistent. Therefore, when the first execution result and the second execution result are inconsistent, the transaction stored in the transaction pool is deleted and the event is broadcast.

[0125] In a feasible embodiment, the second node can also send a command to the first node to restore the execution result through the seventh interface when restoring the target block. This allows the first block to parse the execution result hash stored in the other data of the target block after loading the target transaction, obtain the first execution result, and restore the first execution result to the block body of the target block. This allows the first node to verify the first execution result and the second execution result without having to distinguish whether the target block is a block in pruning mode or a block in non-pruning mode.

[0126] In a feasible implementation, the fourth interface is LaodTxsToBlock(block)error, the fifth interface is FailedTransactions(block,resultMap)[]TxInfo, and the seventh interface is BeforeVerify().

[0127] Therefore, this application can effectively standardize the verification process of target blocks by slave nodes through a unified interface, thereby effectively improving consensus efficiency.

[0128] This application embodiment also provides a transaction processing method, the execution subject of which can be the request node 20 described above. For example... Figure 9 As shown, the method includes the following steps:

[0129] 901, the second node obtains the identifier of at least one target transaction sent sequentially by the first node; the identifier of the target transaction is determined based on the identifier of the transaction set, which is obtained by the first node; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the number of transaction operations of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction, the first node is used to store the transactions of the blockchain network; the second node is used to schedule the transactions stored in the first node to generate blocks.

[0130] It should be noted that a transaction set is a collection of transactions sent from the first node to the second node for the second node to construct a block. The number of transactions in the transaction set is related to the number of transaction operations performed by the first node. For example, when the first node is a single or normal transaction pool, the transaction set contains one transaction; when the first node is a batch transaction pool, the transaction set contains multiple transactions corresponding to a single transaction batch.

[0131] In one feasible embodiment, the identifier of the transaction set can be determined based on the number of operations performed by the first node. For example, the identifier of the transaction (or transaction batch) whose operation granularity is determined by the first node can be directly used as the identifier of the transaction set, or a new identifier can be constructed based on the identifier of the transaction (or transaction batch) whose operation granularity is determined by the first node. For example, taking the identifier of the transaction (or transaction batch) whose operation granularity is determined by the first node as the identifier of the transaction set as an example, when the first node is a single or normal transaction pool, the number of operations performed by the first node is one transaction, so the identifier of the transaction set is the identifier of the transaction, such as txID. When the first node is a batch transaction pool, the number of operations performed by the first node is one transaction batch, so the identifier of the transaction set is the identifier of the transaction batch, such as batchID.

[0132] In this embodiment of the application, before constructing the target block, the second node may request the identifier of the target transaction from the first node. The identifier of the target transaction is the identifier of the transaction used to construct the target block.

[0133] In one feasible embodiment, the second node sends a transaction acquisition instruction to the first node through the sixth node, causing the first node to respond to the transaction acquisition instruction by calling the first interface to synchronize at least one target transaction identifier with the first node.

[0134] In other words, the requesting node (second node) calls the sixth interface to send a transaction retrieval instruction to the executing node (first node). In response to the instruction, the requesting node calls the first interface to retrieve the identifier of the transaction set. In other words, the second node calls the sixth interface to schedule the transactions stored by the first node to obtain the identifier of at least one target transaction used to construct the target block.

[0135] Among them, the first interface, the sixth interface, and other interfaces mentioned below are not limited to hardware interfaces or virtual interfaces; they can also be function wrappers, etc.

[0136] After obtaining the identifier of the transaction set, the specific target transactions contained within the transaction set can be determined based on the identifier. In other words, it is necessary to determine the transaction identifier (or transaction batch identifier) ​​corresponding to the identifier of the transaction set based on the identifier of the transaction set, thereby determining the target transaction corresponding to the transaction identifier (or at least one target transaction corresponding to the transaction batch identifier).

[0137] It should be understood that when the identifier of the transaction set is the identifier of the transaction granularity handed over by the transaction pool to the core engine, the target transaction can be directly determined based on the transaction identifier or the transaction batch identifier; when the identifier of the transaction set is a new identifier constructed based on the identifier of the transaction granularity handed over by the transaction pool to the core engine, the transaction identifier or the transaction batch identifier is determined by the identifier of the transaction set according to the rules for constructing the new identifier.

[0138] In one feasible embodiment, the identifier of the transaction set includes the transaction identifier of at least one transaction corresponding to the transaction operation data. The first node determines at least one target transaction in the transaction set according to the identifier of the transaction set, including: determining the identifier of the target transaction sent to the second node each time from the at least one transaction identifier based on the storage order of at least one transaction in the first node and the number of transactions included in the target transaction; and determining the transaction in the transaction set corresponding to the target transaction identifier as the target transaction.

[0139] In other words, the identifier of a transaction set is either a transaction identifier or a transaction batch identifier. Therefore, when the identifier of a transaction set is a transaction batch identifier, the identifier of the transaction set includes at least one transaction identifier corresponding to at least one transaction of the transaction batch identifier. For example, when the transaction pool is a batch transaction pool and 1000 transactions are considered as a batch, the transaction batch identifier batch1 corresponding to the identifier of the transaction set can contain 1000 transactions, thus corresponding to transaction identifiers for 1000 transactions. When the transaction pool is a single or normal transaction pool, the identifier of the transaction set corresponds to the transaction identifier of one transaction.

[0140] Furthermore, the target transaction includes the number of transactions synchronized by the transaction pool to the second node through the first interface. In a feasible embodiment, the number of transactions can be all transactions in the transaction set synchronized to the second node, or it can be a portion of the transactions. It should be understood that when the number of transactions is a portion of the transactions in the transaction set synchronized to the second node, it indicates that the first node synchronizes at least one transaction in the transaction set to the second node in multiple batches through the first interface.

[0141] For example, when the first node is a single or normal transaction pool, the identifier of the transaction set corresponds to the transaction identifier tx1 of a transaction, and the number of transactions is one transaction. Then, we can traverse the transaction identifiers corresponding to the identifier of the transaction set to obtain the transaction identifier tx1 of a transaction corresponding to the identifier of the transaction set. Based on the number of transactions included in the target transaction, we determine tx1 as the identifier of the target transaction, and at the same time, we determine that the transaction corresponding to tx1 is the target transaction.

[0142] When the first node is a batch transaction pool, the transaction set identifier corresponds to the identifier batch1 of a transaction batch, and the number of transactions is one transaction. Then the identifier of the transaction set contains at least one transaction identifier of at least one transaction contained in the transaction batch1, for example, 1000 transaction identifiers. Iterate through each of the 1000 transaction identifiers. Based on the storage order of the 1000 transactions in batch 1 and the number of transactions included in the target transaction, determine the identifier of the target transaction to be sent to the second node each time. For example, the 1000 transactions correspond to transactions tx1, tx2, ..., tx1000. When the number of target transactions is 1, determine one transaction as the target transaction from the 1000 transactions each time. That is, the first time, use transaction identifier tx1 from the 1000 transaction identifiers as the identifier of the target transaction and determine the transaction corresponding to tx1 as the target transaction. The second time, use tx2 as the identifier of the target transaction in order and determine the transaction corresponding to tx2 as the target transaction. And so on, until the 1000th time, use tx1000 as the identifier of the target transaction and determine the transaction corresponding to tx1000 as the target transaction.

[0143] Optionally, the number of transactions can also be multiple, such as two. In this case, when the first node is a single or normal transaction pool, the transaction tx1 included in the transaction set is still used as the identifier of the target transaction, and the transaction corresponding to tx1 is determined to be the target transaction. When the first node is a batch transaction pool, the transaction identifiers tx1 and tx2 out of 1000 transaction identifiers are used as the identifiers of the target transaction in the first case, and the transactions corresponding to tx1 and tx2 are determined to be the target transactions. In the second case, tx3 and tx4 are used as the identifiers of the target transaction, and the transactions corresponding to tx3 and tx4 are determined to be the target transactions.

[0144] The first node ultimately synchronizes the identifiers of at least one target transaction to the second node through the first interface. It should be understood that the first interface can synchronize the identifiers of the target transactions corresponding to the number of transactions determined during the process of traversing the at least one transaction identifier included in the transaction set to the second node, or it can synchronize all the identifiers of the target transactions determined together to the second node after the traversal is completed and all the identifiers of the target transactions are obtained.

[0145] It is also important to understand that after the first node calls the first interface to obtain the identifier of the transaction set, the first interface can determine at least one target transaction in the transaction set based on the obtained identifier of the transaction set according to the internally encapsulated execution strategy, and synchronize the identifier of at least one target transaction to the second node.

[0146] In a feasible embodiment, the sixth interface can be Fetch(), and the first interface is []TxSet. The second node calls the sixth interface Fetch() to send a transaction retrieval instruction to the first node. The first node retrieves the identifier of the transaction set by calling the first interface. The identifier of the transaction set can be TxSet(txID) or TxSet(batchID) (or directly txID or batchID). That is, the identifier of the transaction set corresponds to a transaction identifier or a transaction batch identifier based on the operation granularity of the transaction pool. A transaction batch identifier can correspond to multiple transaction identifiers based on the mapping relationship between transaction batch identifiers and transaction identifiers stored in the transaction pool. Then, the first interface TxSet uses the encapsulated iterator to traverse each transaction identifier in at least one transaction identifier, and determines the identifier of the target transaction in at least one transaction based on the number of transactions included in the target transaction, such as tx1, tx2, tx3, and tx4. The transactions corresponding to tx1, tx2, tx3, and tx4 are determined as target transactions, and tx1, tx2, tx3, and tx4 are synchronized to the second node.

[0147] For example, Figure 3 (a) illustrates the process of synchronizing the target transaction identifier to the second node when the first node is a batch transaction pool. Figure 3 (b) illustrates the process of synchronizing the identifier of the target transaction to the second node when the first node is a single or normal transaction pool.

[0148] In one feasible embodiment, the first node can also be another transaction pool with an operation granularity greater than that of a transaction. That is, when a transaction pool with a different operation granularity is constructed based on other needs, a first interface can be configured for the new transaction pool, so that the new transaction pool can provide the second node with the identifier of the target transaction for constructing the block, without having to improve the execution logic of the second node.

[0149] 902, Generate a target block based on the identifier of at least one target transaction.

[0150] In one feasible embodiment, generating a target block based on the identifier of at least one target transaction includes: executing at least one target transaction based on the identifier of at least one target transaction to obtain a first execution result of at least one target transaction and an execution order of at least one target transaction; generating an initial block based on the first execution result of at least one target transaction and the execution order of at least one target transaction; and calling a second interface to perform the operation of sending the initial block to a first node, so that the first node generates a target block based on the initial block.

[0151] In other words, after the second node obtains the identifier of at least one target transaction sent by the first node through the first interface, it can establish an original block. Specifically, block body 502 can be constructed based on the identifier of the target transaction. For example, the identifier of the target transaction is stored in block body 502. Figure 4 As shown, the original block 51 is constructed by the second node based on the identifier of the received target transaction. At this time, the block body 512 stores the identifier of the target transaction sent by the first node. Then, the second node calls and executes the target transaction from the first node based on the identifier of the target transaction, stores the first execution result corresponding to the identifier of the target transaction in the block body 502 of the initial module 50, and adjusts the storage order of the identifiers of the target transaction in the block body 512 based on the execution order of the target transaction.

[0152] It should be noted that the second node stores a scheduling strategy for scheduling and executing transactions. The second node can schedule target transactions from the first node based on the scheduling strategy and execute the target transactions to obtain the execution result of the first transaction. Since the execution order generated by the scheduling strategy may differ from the order in which transactions are stored in the transaction pool, the identifiers of the target transactions stored by the second node according to the execution order will be different from the identifier sequence numbers of the target transactions synchronized to the second node by the first node.

[0153] In another feasible embodiment, the second node calls the third interface to perform the operation of sending execution status information to the first node. The execution status information is used to characterize whether the execution time of at least one target transaction has timed out, so that the first node sends the identifier of the transaction whose execution time has timed out to the second node.

[0154] In other words, when the second node invokes and executes the target transaction from the first node based on the target transaction's identifier, a scheduling timeout may occur, causing the second node to fail to complete the execution within the preset time. In other words, the target transaction fails to be executed by the second node, and therefore, the second node cannot properly store the first execution result corresponding to the target transaction in the value block. Based on this, the second node synchronizes the execution status information of each target transaction with the first node through a third interface. This execution status information includes, but is not limited to, successful execution and unsuccessful execution, so that the first node can synchronize the identifier of the timed-out target transaction again.

[0155] In a feasible embodiment, when the first node receives the transaction acquisition instruction again through the sixth interface, it can synchronize the identifier of the timed-out target transaction to the second node again through the first interface.

[0156] For example, the second node configures execution status information for each target transaction received based on the first interface. Successfully executed target transactions are marked as "ReBuild," and unsuccessfully executed target transactions are marked as "ReAdd." When the first node receives a transaction retrieval instruction again through the sixth interface, it synchronizes transactions marked with "ReAdd" (unsuccessfully executed) to the second node. Based on this, by identifying the transaction execution status, first nodes at different operational granularities can uniformly handle unsuccessfully executed transactions, improving the overall operating speed of the transaction pool and reducing the complexity of configuring new transaction pools.

[0157] In a feasible embodiment, after receiving the initial block sent by the second node through the second interface, the first node parses the initial block, verifies the execution order of at least one target transaction, and generates a target block based on the verified execution order and the first execution result of at least one target transaction.

[0158] In other words, the first node parses the block body of the initial block to obtain the execution order and first execution result of each target transaction. Then, based on the first execution result of the target transaction, it generates the corresponding execution result hash and stores the target transaction's tag and execution result hash in the other data 503 of the initial block according to the execution order of each target transaction.

[0159] In a feasible embodiment, when the first node is a single or normal transaction pool, the operation granularity of the first node is a single transaction. Therefore, the target transaction's label and execution result hash stored in other data 503 correspond to a single transaction. For example, Figure 5 As shown in (a), the other data 503 of the initial block 50 contains the tags txid_4, txid_2, txid_3 and txid_1 of the target transactions in the same order as in the block body 502, as well as the result hash ResultHash of each target transaction.

[0160] In another embodiment, when the first node is a batch transaction pool, the operation granularity of the first node is the transaction batch. Therefore, the labels and execution result hashes of the target transactions stored in other data 503 correspond to the transaction batches, and the execution order of each target transaction in the transaction batch is indicated by labeling the transaction batches. For example, as shown... Figure 5As shown in (b), the other data 503 of the initial block 50 stores transaction batches containing four target transactions in the order of their identifiers, and the execution order of each target transaction is marked by a number after the arrow. The execution order of each target transaction is indicated by marking its corresponding position within the transaction batch. For example, batch_1 contains target transactions tx1 and tx2, and batch_2 contains target transactions tx3 and tx4. The execution order of the target transactions recorded in block body 502 is tx4, tx2, tx3, and tx1. That is, the execution order of tx1 is 3, the execution order of tx2 is 1, the execution order of tx3 is 2, and the execution order of tx4 is 0. Furthermore, the execution result hashes stored in the other data 503 also correspond to the transaction batches; the execution result hash for batch1 is batch1ResultHash, and the execution result hash for batch2 is batch2ResultHash.

[0161] It should be understood that the execution result hash is obtained by hashing the first execution result of the target transaction. When the first node is a single or normal transaction pool, the execution result hash is obtained by hashing the first execution result corresponding to the target transaction itself. When the first node is a batch transaction pool, the execution result hash corresponding to the transaction batch is calculated based on the first execution results of all target transactions in the transaction batch. Calculating the execution result hash corresponding to the transaction batch based on the first execution results of all target transactions in the transaction batch can be achieved by concatenating the first execution results of all target transactions in the transaction batch to obtain the first execution result corresponding to the transaction batch, and then calculating the execution result hash corresponding to the transaction batch based on the first execution result corresponding to the transaction batch.

[0162] In a feasible embodiment, when the second node constructs the initial block 503, it further constructs other data 503 based on the identifier of at least one target transaction synchronized by the first node. That is, before synchronizing the initial block to the first node, the other data 503 of the initial block stores data, which is an identifier synchronized by the second node from the first node that matches the operation granularity, such as a transaction identifier or a transaction batch key. When the second node schedules and executes the target transaction based on the identifier of the target transaction, scheduling timeouts are prone to occur, resulting in the identifier of the target transaction actually stored in the block body of the initial block being different from the identifier of the target transaction initially synchronized. The other data needs to be constructed based on the synchronized target data. Especially when the first node is a batch transaction pool, the transaction pool may change the correspondence between the identifier of the transaction batch and the transaction due to the failure of some transactions to be executed successfully. If the transaction identifier stored in the other data is not updated, the first node will be unable to generate the target block based on the parsing of the initial block.

[0163] Based on this, after receiving the execution status information synchronized by the second node through the third interface, the first node, based on the successfully executed target transactions synchronized by the second node, for example, resynchronizes transactions with the successful execution marker "ReBuild" to the second node, so that the second node can store the updated target transaction identifiers in other data 503. For example, as shown... Figure 6 As shown in (a), when the first node is a single or normal transaction pool, if target transaction tx1 fails to execute successfully during the second node's scheduling execution, the first node resynchronizes the identifiers of target transactions tx2, tx3, and tx4 to the second node. The second node then generates other data based on the newly received identifiers of the target transactions. For example... Figure 6 As shown in (b), when the first node does not have a batch transaction pool, if the target transaction tx1 is not successfully executed during the second node's scheduling and execution, the first node generates new transaction batch identifiers batch_3 and batch_4 based on the successfully executed target transactions tx2, tx3 and tx4. Among them, batch_3 only contains the successfully executed target transaction tx2, and batch_4 contains the executed target transactions tx3 and tx4.

[0164] In a feasible embodiment, the second interface is AfterProposing(), and the third interface is RegenerateTxs(ts[]TxSet).

[0165] In a feasible embodiment, the second node calls the fourth interface to perform the operation of synchronizing the target block synchronized by the third node to the first node, so that the first node parses the target block synchronized by the third node to obtain the identifier of at least one target transaction to be verified, and obtains a consensus block based on the execution result of the at least one target transaction to be verified and the target block; wherein, the target block synchronized by the third node is generated based on the identifier of at least one target transaction sent by the fourth node to the third node.

[0166] It should be noted that, in this embodiment, the blockchain nodes containing the first and second nodes are slave nodes, used to achieve consensus on the target blocks synchronized by the master node. The third and fourth nodes are nodes in the master node blockchain; the third node is the core engine of the master node blockchain, and the fourth node is the transaction pool of the master node blockchain.

[0167] In one feasible embodiment, within the master node blockchain node, the fourth node calls the first interface to obtain the identifier of the transaction set, and synchronizes the identifier of at least one target transaction to the third node through the first interface. The third node generates an initial block based on the target transactions and sends the initial block to the fourth node through the second interface. The fourth node parses the initial block, verifies the execution order of the at least one target transaction recorded in the initial block, and generates a target block based on the verified execution order and the first execution result of the at least one target transaction. The fourth node sends the generated target block to the third node, enabling the third node to broadcast the target block to the second node of at least one slave node through the consensus module. The second node of the slave node then sends the received target block to the first node through the fourth interface.

[0168] It should be understood that the block body and other data of the target block store the identifier of the target transaction. Therefore, the identifier of the target transaction can be obtained by parsing any part of the block body and other data of the target block.

[0169] In one feasible embodiment, to achieve extreme block compression, and considering that the corresponding transaction data is typically already stored in other consensus nodes, the master node can also delete the data stored in the block body of the target block before broadcasting, thereby reducing the storage of transaction data in the block. Specifically, the fourth node can synchronize the finally generated target block to the third node. Based on compression requirements, the third node prunes the target block, deleting data stored in the block body or other data in the target block. That is, in pruning mode, data stored in the block body of the target block is deleted, and in non-pruning mode, data stored in other data in the target block is deleted.

[0170] In other words, when the target block is a pruned block, the first node parses the other data of the target block to obtain the identifier of at least one target transaction to be verified. When the target block is a non-pruned block, the first node parses the block body of the target block to obtain the identifier of at least one target transaction to be verified.

[0171] It should be noted that, under normal circumstances, after receiving a transaction sent by a client, the transaction pool will broadcast the transaction so that all consensus nodes in the blockchain have the transaction stored in their transaction pools. Therefore, the first node can find the target transaction stored in its own memory based on the identifier of the target transaction and load the found target transaction into the block body of the target block.

[0172] At the end of a feasible embodiment, the first node may fail to store the target transaction to be verified due to a broadcast error. In this case, the first node communicates with the transaction pool of the master node (i.e., the fourth node) to request the target transaction to be verified. Based on the request of the first node, the fourth node sends the target transaction to the first node through broadcast so that the first node can obtain the target transaction to be verified.

[0173] It should be understood that after the first node obtains at least one target transaction, the second node can execute at least one target transaction, obtain the execution result, and then vote on the target block based on the execution result to obtain the consensus block.

[0174] In a feasible embodiment, the first node obtains a consensus block based on the execution result of the at least one target transaction to be verified and the target block, including:

[0175] The second node obtains the identifier of the at least one target transaction to be verified sent by the first node, and executes the at least one target transaction to be verified based on the identifier of the at least one target transaction to be verified, and obtains a second execution result; it calls the fifth interface to perform the operation of sending the second execution result to the first node, so that the first node performs verification based on the second execution result and the first execution result in the target block sent by the third node, and generates the consensus block according to the verification result.

[0176] In other words, after the first node obtains the target transaction to be verified, it can synchronize the identifier of at least one target transaction to be verified to the second node, so that the second node can schedule at least one target transaction from the first node and execute it based on the identifier of at least one target transaction to be verified, obtain the second execution result, and synchronize the second execution result to the first node through the fifth interface.

[0177] In another feasible embodiment, the first node can first store the target transaction in the block body to restore the target block, and then synchronize the restored target block to the second node.

[0178] For example, such as Figure 8 As shown in (a), when the fourth node constructing the target block is a single or normal transaction pool, and the target block is a block in pruning mode, the first node parses the other data of the target block to obtain the identifiers of the target transactions tx4, tx2, tx3 and tx1, and then restores the target transactions tx4, tx2, tx3 and tx1 into the block body of the target block.

[0179] like Figure 8 As shown in (b), when the fourth node constructing the target block is a batch transaction pool and the target block is a block in pruning mode, the first node parses other data of the target block to obtain the identifier of the transaction batch. Then, it can determine the identifiers of the target transactions tx4, tx2, tx3 and tx1 based on the mapping relationship between the transaction batches and transactions stored in its own storage. Alternatively, it can obtain the identifiers of the target transactions tx4, tx2, tx3 and tx1 through communication with the fourth node. Finally, the target transactions tx4, tx2, tx3 and tx1 are restored to the block body of the target block.

[0180] like Figure 8 As shown in (c), when the target block is a block in non-pruning mode, since each target transaction is already stored in the block body, the first node can verify the target transaction through the tag and signature of the target data in the block body to ensure the reliability of each data. If the verification is successful, the target block will be synchronized to the node, or if the verification fails, the target block will be voted against directly.

[0181] It should be understood that in the non-pruning mode, the block body records all the information of the target transaction, including but not limited to the target transaction identifier, the target transaction, the target transaction signature data, the first execution result corresponding to the target transaction, etc., which can be set according to the block verification requirements, and this application does not make specific limitations.

[0182] Furthermore, after obtaining the target block, the second node directly executes the target transaction stored in the block body of the target block to obtain the second execution result.

[0183] In a feasible embodiment, the second node calls the fifth interface to perform the operation of synchronizing the second execution result to the first node, so that the first node can verify based on the second execution result and the first execution result in the target block synchronized by the third node, and generate a consensus block according to the verification result.

[0184] For example, when the target block synchronized by the third node is a module in pruning mode, the first node can parse the execution result hash stored in other data of the target block to obtain the first execution result, and determine whether the first execution result and the second execution result are consistent. If they are consistent, the first node votes on the target block to generate a consensus block; if they are inconsistent, the first node votes against the target block and deletes the transaction with the inconsistent execution result from its own transaction pool.

[0185] When the target block synchronized by the third node is a module in non-pruning mode, the first node can directly obtain the first execution result of the target transaction from the block body and determine whether the first execution result and the second execution result are consistent. If they are consistent, the first node votes on the target block to generate a consensus block. If they are inconsistent, the first node votes against the target block and deletes the transaction with inconsistent execution result from its own transaction pool.

[0186] It should be understood that, since the execution result hash of other data stored in the target block synchronized by the third node is the execution result hash of the transaction batch when the fourth node is a batch transaction pool, the first execution result and the second execution result are compared on a batch basis.

[0187] In one feasible embodiment, the reason for the inconsistency between the first execution result and the second execution result is usually that the target transaction contains a random function, such as a time function, which makes the time when the third node calculates the first execution result inconsistent with the time when the second node calculates the second execution result, thus causing the first execution result and the second execution result to be inconsistent. Therefore, when the first execution result and the second execution result are inconsistent, the transaction stored in the transaction pool is deleted and the event is broadcast.

[0188] In a feasible embodiment, the second node can also send a command to the first node to restore the execution result through the seventh interface when restoring the target block. This allows the first block to parse the execution result hash stored in the other data of the target block after loading the target transaction, obtain the first execution result, and restore the first execution result to the block body of the target block. This allows the first node to verify the first execution result and the second execution result without having to distinguish whether the target block is a block in pruning mode or a block in non-pruning mode.

[0189] In a feasible implementation, the fourth interface is LaodTxsToBlock(block)error, the fifth interface is FailedTransactions(block,resultMap)[]TxInfo, and the seventh interface is BeforeVerify().

[0190] Therefore, this application can effectively standardize the verification process of target blocks by slave nodes through a unified interface, thereby effectively improving consensus efficiency.

[0191] The transaction processing method proposed in this application, applied to a blockchain scenario, unifies the interaction rules between various processing modules in a blockchain node and provides a new form of transaction acquisition: transaction sets. When applied to the interaction between a transaction pool and the core engine module (core), the number of transactions in the transaction set is related to the number of transaction operations in the transaction pool. It can be a single transaction or batch transactions, and is compatible with various transaction pool formats. For example, the first node (i.e., the transaction pool) obtains the identifier of the transaction set. After obtaining the identifier, it determines at least one target transaction in the transaction set based on the identifier and sends the identifier of at least one target transaction to the second node (core module) sequentially. This enables the core engine module (core) to obtain the transaction identifier, allowing the subsequent blockchain system to construct blocks based on the obtained transaction identifiers. This application unifies the number of transactions in the interaction between the transaction pool and the core engine module (core). The two can synchronize transaction identifiers based on transaction sets, eliminating the need for different interaction formats for different types of transaction pools. It is compatible with transaction pools with various operational granularities, making information retrieval in the blockchain system more convenient.

[0192] Furthermore, by unifying the interaction rules between the transaction pool and the core engine module, the core engine module is unaware of the number of operations performed on transactions by the transaction pool. Therefore, the transaction pool can be further expanded based on the unified interaction rules to add more transaction pools that can meet the different numbers of operations performed on transactions, thereby effectively improving the scalability of the transaction pool.

[0193] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the transaction processing method described in this application embodiment, for example, it can execute... Figure 2 or Figure 9 The steps of the method shown.

[0194] This application provides a computer product that includes instructions that are implemented by a processor at runtime. Figure 2 or Figure 9 The steps of the method shown.

[0195] It should be noted that although the operation of the method of the present invention is described in a specific order in the accompanying drawings, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed in order to achieve the desired result.

[0196] Figure 10 A block diagram of a transaction processing apparatus according to an embodiment of this application is shown. This apparatus can be deployed on an execution node (e.g., the first node described above). Reference Figure 10 The transaction processing device includes a storage unit 11 and an interface unit 12.

[0197] Storage unit 11 is used to store the target transaction;

[0198] Interface unit 12 is used to obtain the identifier of a transaction set, determine at least one target transaction in the transaction set based on the identifier of the transaction set, and send the identifier of the at least one target transaction to the second node sequentially. The identifier of the at least one target transaction is used to generate a target block. The transaction set includes at least one transaction. The number of transactions in the transaction set is related to the number of transaction operations of the first node. The identifier of the transaction set is used to indicate the number of transaction operations of the first node. The number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction. The first node is used to store transactions of the blockchain network. The second node is used to schedule the transactions stored in the first node to generate a block.

[0199] In one embodiment, the identifier of the transaction set includes the transaction identifier of the at least one transaction corresponding to the transaction operation data.

[0200] Interface unit 12 is specifically used for determining at least one target transaction in the transaction set based on the identifier of the transaction set, including:

[0201] Based on the storage order of the at least one transaction in the first node and the number of transactions included in the target transaction, the identifier of the target transaction sent to the second node each time is determined from the at least one transaction;

[0202] The transaction in the transaction set that corresponds to the identifier of the target transaction is identified as the target transaction.

[0203] In one embodiment, the first node calls the first interface to execute the aforementioned method.

[0204] In one embodiment, the interface unit 12 is further configured to receive an initial block sent by a second node through a second interface, the initial block including a first execution result of at least one target transaction and the execution order of the at least one target transaction, wherein the first execution result is obtained by the second node executing the target transaction based on the identifier of the at least one target transaction;

[0205] The initial block is parsed, the execution order of the at least one target transaction is verified, and a target block is generated based on the verified execution order and the first execution result of the at least one target transaction.

[0206] In one embodiment, the interface unit 12 is further configured to receive execution status information sent by the second node through a third interface, wherein the execution status information is used to characterize whether the execution time of the at least one target transaction has timed out.

[0207] The first node sends an identifier indicating that the transaction has timed out to the second node.

[0208] In one embodiment, the interface unit 12 is further configured to receive a target block synchronized by a third node through a fourth interface, wherein the target block sent by the third node is generated based on the identifier of at least one target transaction synchronized by the fourth node to the third node.

[0209] The target block synchronized by the third node is parsed to obtain the identifier of at least one target transaction to be verified;

[0210] The at least one target transaction to be verified is obtained based on the identifier of the at least one target transaction to be verified;

[0211] A consensus block is obtained based on the execution result of at least one target transaction to be verified and the target block.

[0212] In one embodiment, the interface unit 12 is further configured to send the identifier of the at least one target transaction to be verified to the second node, so that the second node executes the at least one target transaction to be verified to obtain a second execution result;

[0213] The first node receives the second execution result sent by the second node through the fifth interface;

[0214] The first node performs verification based on the second execution result and the first execution result in the target block sent by the third node;

[0215] Consensus blocks are generated based on the verification results.

[0216] The transaction processing method proposed in this application, applied to a blockchain scenario, unifies the interaction rules between various processing modules in a blockchain node and provides a new form of transaction acquisition: transaction sets. When applied to the interaction between a transaction pool and the core engine module (core), the number of transactions in the transaction set is related to the number of transaction operations in the transaction pool. It can be a single transaction or batch transactions, and is compatible with various transaction pool formats. For example, the first node (i.e., the transaction pool) obtains the identifier of the transaction set. After obtaining the identifier, it determines at least one target transaction in the transaction set based on the identifier and sends the identifier of at least one target transaction to the second node (core module) sequentially. This enables the core engine module (core) to obtain the transaction identifier, allowing the subsequent blockchain system to construct blocks based on the obtained transaction identifiers. This application unifies the number of transactions in the interaction between the transaction pool and the core engine module (core). The two can synchronize transaction identifiers based on transaction sets, eliminating the need for different interaction formats for different types of transaction pools. It is compatible with transaction pools with various operational granularities, making information retrieval in the blockchain system more convenient.

[0217] Furthermore, by unifying the interaction rules between the transaction pool and the core engine module, the core engine module is unaware of the number of operations performed on transactions by the transaction pool. Therefore, the transaction pool can be further expanded based on the unified interaction rules to add more transaction pools that can meet the different numbers of operations performed on transactions, thereby effectively improving the scalability of the transaction pool.

[0218] Figure 11 A block diagram of a transaction processing apparatus according to another embodiment of this application is shown, which can be deployed on a requesting node (e.g., the second node described above). Reference Figure 11 The transaction processing device includes an interface unit 21 and a construction unit 22.

[0219] Interface unit 21 is used to obtain the identifier of at least one target transaction sent sequentially by the first node; the identifier of the target transaction is determined based on the identifier of the transaction set, which is obtained by the first node calling the first interface; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the transaction operation data of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, and the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction; the first node is used to store transactions of the blockchain network; the second node is used to schedule the transactions stored in the first node to generate blocks.

[0220] Construction unit 22 generates a target block based on the identifier of the at least one target transaction.

[0221] In one embodiment, the construction unit 22 is further configured to execute the at least one target transaction based on the identifier of the at least one target transaction, and obtain a first execution result of the at least one target transaction and the execution order of the at least one target transaction;

[0222] An initial block is generated based on the first execution result of the at least one target transaction and the execution order of the at least one target transaction. A second interface is called to perform the operation of synchronizing the initial block with the first node, so that the first node generates the target block based on the initial block.

[0223] In one embodiment, the interface unit 21 is further configured to have the second node call the third interface to perform the operation of synchronizing execution status information to the first node, wherein the execution status information is used to characterize whether the execution time of the at least one target transaction has timed out, thereby identifying the transaction whose execution time has timed out when the first node synchronizes execution with the second node.

[0224] In one embodiment, the interface unit 21 is further configured to call the fourth interface to perform the operation of synchronizing the target block synchronized by the third node to the first node, so that the first node parses the target block synchronized by the third node to obtain the identifier of at least one target transaction to be verified, and obtains a consensus block based on the execution result of the at least one target transaction to be verified and the target block.

[0225] The target block synchronized by the third node is generated based on the identifier of at least one target transaction sent by the fourth node to the third node.

[0226] In one embodiment, the interface unit 21 is further configured to obtain the identifier of the at least one target transaction to be verified sent by the first node, and execute the at least one target transaction to be verified based on the identifier of the at least one target transaction to be verified, thereby obtaining a second execution result;

[0227] The fifth interface is invoked to send the second execution result to the first node, so that the first node performs verification based on the second execution result and the first execution result in the target block sent by the third node, and generates the consensus block according to the verification result.

[0228] In one embodiment, interface unit 21 is further configured to invoke a sixth node to perform an operation of sending a transaction acquisition instruction to the first node, such that the first node, in response to the transaction acquisition instruction, invokes the first interface to send at least one identifier of a target transaction to the first node.

[0229] The transaction processing method proposed in this application, applied to a blockchain scenario, unifies the interaction rules between various processing modules in a blockchain node and provides a new form of transaction acquisition: transaction sets. When applied to the interaction between a transaction pool and the core engine module (core), the number of transactions in the transaction set is related to the number of transaction operations in the transaction pool. It can be a single transaction or batch transactions, and is compatible with various transaction pool formats. For example, the first node (i.e., the transaction pool) obtains the identifier of the transaction set. After obtaining the identifier, it determines at least one target transaction in the transaction set based on the identifier and sends the identifier of at least one target transaction to the second node (core module) sequentially. This enables the core engine module (core) to obtain the transaction identifier, allowing the subsequent blockchain system to construct blocks based on the obtained transaction identifiers. This application unifies the number of transactions in the interaction between the transaction pool and the core engine module (core). The two can synchronize transaction identifiers based on transaction sets, eliminating the need for different interaction formats for different types of transaction pools. It is compatible with transaction pools with various operational granularities, making information retrieval in the blockchain system more convenient.

[0230] Furthermore, by unifying the interaction rules between the transaction pool and the core engine module, the core engine module is unaware of the number of operations performed on transactions by the transaction pool. Therefore, the transaction pool can be further expanded based on the unified interaction rules to add more transaction pools that can meet the different numbers of operations performed on transactions, thereby effectively improving the scalability of the transaction pool.

[0231] It should be understood that the units or modules described in the transaction processing device are related to the reference. Figure 2 or Figure 9 The steps in the described method correspond to each other. Therefore, the operations and features described above for the method also apply to the transaction processing apparatus and the units contained therein, and will not be repeated here. The transaction processing apparatus can be pre-implemented in the browser or other security applications of an electronic device, or it can be loaded into the browser or other security applications of an electronic device through download or other means. The corresponding units in the transaction processing apparatus can cooperate with the units in the electronic device to implement the solutions of the embodiments of this application.

[0232] The division of modules or units mentioned in the detailed description above is not mandatory. In fact, according to the embodiments of this disclosure, 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.

[0233] It should be noted that for details not disclosed in the transaction processing apparatus of this application embodiments, please refer to the details disclosed in the above embodiments of this application, which will not be repeated here.

[0234] The following is for reference. Figure 12 , Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the embodiments of this application is shown.

[0235] like Figure 12 As shown, the computer system includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1202 or programs loaded from storage section 1208 into random access memory (RAM) 1203. RAM 1203 also stores various programs and data required for the system's operating instructions. CPU 1201, ROM 1202, and RAM 1203 are interconnected via bus 1204. Input / output (I / O) interface 1205 is also connected to bus 1204.

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

[0237] Specifically, according to embodiments of this application, the flowchart above refers to... Figure 2 The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs the functions defined in the system of this application.

[0238] It should be noted that the computer-readable medium shown in 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 or flash memory), optical fiber, portable compact disk 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 computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0239] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing 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 connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0240] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor; for example, a processor can be described as including a storage unit and an interface unit. The names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0241] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments, or may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the transaction processing method described in this application.

[0242] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A transaction processing method applied to a blockchain network, the blockchain network comprising a first node and a second node, characterized in that, include: The first node calls a unified first interface to obtain the identifier of the transaction set; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the number of transaction operations of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction, and the first node is used to store the transactions of the blockchain network. The first node determines at least one target transaction in the transaction set based on the identifier of the transaction set; The first node sends the identifier of the at least one target transaction to the second node sequentially, wherein the identifier of the at least one target transaction is used to generate a target block; the second node is used to schedule the transactions stored in the first node to generate a block.

2. The method according to claim 1, characterized in that, The identifier of the transaction set includes the transaction identifier of the at least one transaction corresponding to the transaction operation data. The step of determining at least one target transaction in the transaction set based on the identifier of the transaction set includes: Based on the storage order of the at least one transaction in the first node and the number of transactions included in the target transaction, the identifier of the target transaction sent to the second node each time is determined from the at least one transaction; The transaction in the transaction set that corresponds to the identifier of the target transaction is identified as the target transaction.

3. The method according to claim 1, characterized in that, Also includes: The first node receives an initial block sent by the second node through the second interface. The initial block includes a first execution result of at least one target transaction and the execution order of the at least one target transaction. The first execution result is obtained by the second node executing the target transaction based on the identifier of the at least one target transaction. The initial block is parsed, the execution order of the at least one target transaction is verified, and a target block is generated based on the verified execution order and the first execution result of the at least one target transaction.

4. The method according to claim 1, characterized in that, Also includes: The first node receives execution status information sent by the second node through a third interface. The execution status information is used to characterize whether the execution time of the at least one target transaction has timed out. The first node sends an identifier indicating that the transaction has timed out to the second node.

5. The method according to claim 1, characterized in that, Also includes: The first node receives the target block synchronized by the third node through the fourth interface. The target block synchronized by the third node is generated based on the identifier of at least one target transaction sent by the fourth node to the third node. The target block synchronized by the third node is parsed to obtain the identifier of at least one target transaction to be verified; The at least one target transaction to be verified is obtained based on the identifier of the at least one target transaction to be verified; A consensus block is obtained based on the execution result of at least one target transaction to be verified and the target block.

6. The method according to claim 5, characterized in that, The step of obtaining a consensus block based on the execution result of at least one target transaction to be verified and the target block includes: The first node sends the identifier of at least one target transaction to be verified to the second node, so that the second node executes the at least one target transaction to be verified and obtains a second execution result; The first node receives the second execution result sent by the second node through the fifth interface; The first node performs verification based on the second execution result and the first execution result in the target block sent by the third node; Consensus blocks are generated based on the verification results.

7. The method according to claim 1, characterized in that, The first node calls the first interface to obtain the identifier of the transaction set, including: The first node obtains the transaction acquisition instruction sent by the second node through the sixth interface, and in response to the transaction acquisition instruction, calls the first interface to obtain the identifier of the transaction set.

8. A transaction processing method, characterized in that, include: The second node obtains the identifier of at least one target transaction sent sequentially by the first node; the identifier of the target transaction is determined based on the identifier of the transaction set, which is obtained by the first node by calling a unified first interface; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the number of transaction operations of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction, and the first node is used to store the transactions of the blockchain network; The second node is used to schedule the transactions stored in the first node to generate blocks; A target block is generated based on the identifier of the at least one target transaction.

9. The method according to claim 8, characterized in that, The step of generating a target block based on the identifier of the at least one target transaction includes: Execute the at least one target transaction based on the identifier of the at least one target transaction, and obtain the first execution result of the at least one target transaction and the execution order of the at least one target transaction; An initial block is generated based on the first execution result of the at least one target transaction and the execution order of the at least one target transaction. The second interface is called to send the initial block to the first node, so that the first node generates the target block based on the initial block.

10. The method according to claim 8, characterized in that, Also includes: The second node calls the third interface to send execution status information to the first node. The execution status information is used to characterize whether the execution time of the at least one target transaction has timed out, so that the first node sends the identifier of the transaction whose execution time has timed out to the second node.

11. The method according to claim 8, characterized in that, Also includes: The second node calls the fourth interface to perform the operation of synchronizing the target block synchronized by the third node to the first node, so that the first node parses the target block synchronized by the third node, obtains the identifier of at least one target transaction to be verified, and obtains a consensus block based on the execution result of the at least one target transaction to be verified and the target block. The target block synchronized by the third node is generated based on the identifier of at least one target transaction sent by the fourth node to the third node.

12. The method according to claim 11, characterized in that, This enables the first node to obtain a consensus block based on the execution result of at least one target transaction to be verified and the target block, including: The second node obtains the identifier of the at least one target transaction to be verified sent by the first node, and executes the at least one target transaction to be verified based on the identifier of the at least one target transaction to be verified, thereby obtaining a second execution result; The fifth interface is invoked to send the second execution result to the first node, so that the first node performs verification based on the second execution result and the first execution result in the target block sent by the third node, and generates the consensus block according to the verification result.

13. The method according to claim 8, characterized in that, The second node obtains the identifier of at least one target transaction sent by the first node through the first interface, including: The second node invokes the sixth node to execute the operation of sending a transaction acquisition instruction to the first node, causing the first node to respond to the transaction acquisition instruction by invoking the first interface to send at least one identifier of a target transaction to the first node.

14. A transaction processing system, characterized in that, Including the first node and the second node, The first node is used to call a unified first interface to obtain the identifier of a transaction set, determine at least one target transaction in the transaction set based on the identifier of the transaction set, and send the identifier of the at least one target transaction to the second node sequentially; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the number of transaction operations of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction, and the first node is used to store transactions of the blockchain network; The second node is used to obtain the identifier of at least one target transaction sent sequentially by the first node, and generate a target block based on the identifier of the at least one target transaction; The second node is used to schedule the transactions stored in the first node to generate blocks.

15. A transaction processing apparatus, characterized in that, Deployed at the first node, the device includes: Storage unit, used to store target transactions; An interface unit is used to call a unified first interface to obtain the identifier of a transaction set, determine at least one target transaction in the transaction set based on the identifier of the transaction set, and send the identifier of the at least one target transaction to a second node sequentially. The identifier of the at least one target transaction is used to generate a target block. The transaction set includes at least one transaction, the number of transactions in the transaction set is related to the transaction operation data of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, and the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction. The first node is used to store transactions of the blockchain network. The second node is used to schedule the transactions stored in the first node to generate blocks.

16. The apparatus according to claim 15, characterized in that, The identifier of the transaction set includes the transaction identifier of the at least one transaction corresponding to the transaction operation data. The interface unit is used to determine at least one target transaction in the transaction set based on the identifier of the transaction set, including: Based on the storage order of the at least one transaction in the first node and the number of transactions included in the target transaction, the identifier of the target transaction sent to the second node each time is determined from the at least one transaction; The transaction in the transaction set that corresponds to the identifier of the target transaction is identified as the target transaction.

17. The apparatus according to claim 15, characterized in that, The interface unit is further configured to receive an initial block sent by a second node through a second interface. The initial block includes a first execution result of at least one target transaction and the execution order of the at least one target transaction. The first execution result is obtained by the second node executing the target transaction based on the identifier of the at least one target transaction. The initial block is parsed, the execution order of the at least one target transaction is verified, and a target block is generated based on the verified execution order and the first execution result of the at least one target transaction.

18. The apparatus according to claim 15, characterized in that, The interface unit is further configured to receive execution status information sent by the second node through a third interface, wherein the execution status information is used to characterize whether the execution time of the at least one target transaction has expired; The first node sends an identifier indicating that the transaction has timed out to the second node.

19. The apparatus according to claim 15, characterized in that, The interface unit is further configured to receive a target block synchronized by a third node through a fourth interface, wherein the target block sent by the third node is generated based on the identifier of at least one target transaction synchronized by the fourth node to the third node. The target block synchronized by the third node is parsed to obtain the identifier of at least one target transaction to be verified; The at least one target transaction to be verified is obtained based on the identifier of the at least one target transaction to be verified; A consensus block is obtained based on the execution result of at least one target transaction to be verified and the target block.

20. The apparatus according to claim 19, characterized in that, The interface unit is further configured to send the identifier of the at least one target transaction to be verified to the second node, so that the second node executes the at least one target transaction to be verified to obtain a second execution result; The first node receives the second execution result sent by the second node through the fifth interface; The first node performs verification based on the second execution result and the first execution result in the target block sent by the third node; Consensus blocks are generated based on the verification results.

21. A transaction processing apparatus, characterized in that, Deployed at a second node, the device includes: An interface unit is used to obtain the identifier of at least one target transaction sent sequentially by the first node; the identifier of the target transaction is determined based on the identifier of the transaction set, which is obtained by the first node by calling a unified first interface; the transaction set includes at least one transaction, the number of transactions in the transaction set is related to the transaction operation data of the first node, the identifier of the transaction set is used to indicate the number of transaction operations of the first node, and the number of transaction operations is used to characterize the number of transactions that the first node can process in one operation on a transaction; the first node is used to store transactions of the blockchain network; the second node is used to schedule the transactions stored in the first node to generate blocks. The construction unit generates a target block based on the identifier of the at least one target transaction.

22. The apparatus according to claim 21, characterized in that, The construction unit is further configured to execute the at least one target transaction based on the identifier of the at least one target transaction, and obtain a first execution result of the at least one target transaction and the execution order of the at least one target transaction; An initial block is generated based on the first execution result of the at least one target transaction and the execution order of the at least one target transaction. A second interface is called to perform the operation of synchronizing the initial block with the first node, so that the first node generates the target block based on the initial block.

23. The apparatus according to claim 21, characterized in that, The interface unit is further configured to allow the second node to call the third interface to perform an operation of synchronizing execution status information to the first node. The execution status information is used to characterize whether the execution time of the at least one target transaction has timed out, thus identifying the transaction whose execution time has timed out when the first node synchronizes execution with the second node.

24. The apparatus according to claim 21, characterized in that, The interface unit is further configured to call the fourth interface to perform the operation of synchronizing the target block synchronized by the third node to the first node, so that the first node parses the target block synchronized by the third node to obtain the identifier of at least one target transaction to be verified, and obtains a consensus block based on the execution result of the at least one target transaction to be verified and the target block. The target block synchronized by the third node is generated based on the identifier of at least one target transaction sent by the fourth node to the third node.

25. The apparatus according to claim 24, characterized in that, The interface unit is further configured to obtain the identifier of at least one target transaction to be verified sent by the first node, and execute the at least one target transaction to be verified based on the identifier of the at least one target transaction to be verified, thereby obtaining a second execution result; The fifth interface is invoked to send the second execution result to the first node, so that the first node performs verification based on the second execution result and the first execution result in the target block sent by the third node, and generates a consensus block based on the verification result.

26. The apparatus according to claim 21, characterized in that, The interface unit is further configured to invoke the sixth node to perform the operation of sending a transaction acquisition instruction to the first node, so that the first node responds to the transaction acquisition instruction by invoking the first interface to send at least one identifier of a target transaction to the first node.

27. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the transaction processing method as described in any one of claims 1-7 or 8-13.

28. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the transaction processing method as described in any one of claims 1-7 or 8-13.

29. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the transaction processing method as described in any one of claims 1-7 or 8-13.

Images