Transaction processing method in a blockchain system and blockchain node

Abstract

A transaction processing method and a blockchain node in a blockchain system for processing a plurality of transactions belonging to a same block, each of the transactions including a first resource quantity allowed to be consumed and a resource payment account. The method comprises: grouping the plurality of transactions, wherein the resource payment accounts included in each of the plurality of transactions are not utilized; for any jth resource payment account among the resource payment accounts included in the plurality of transactions, determining a plurality of transactions including the jth resource payment account from the plurality of transactions according to an arrangement order of the plurality of transactions; when a sum of the first resource quantities included in the first k transactions among the plurality of transactions is greater than a current quantity of a target resource held by the jth resource payment account, and a sum of the first resource quantities included in the first k-1 transactions is not greater than the current quantity, marking a transaction located after the k-1th transaction with a preset label; and executing the transactions not marked with the preset label concurrently according to the grouping result of the plurality of transactions.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a transaction processing method and a blockchain node in a blockchain system. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a transaction processing method and a blockchain node in a blockchain system.

[0004] Firstly, a transaction processing method in a blockchain system is provided for processing multiple transactions belonging to the same block. For any i-th transaction among the multiple transactions, it includes a first resource quantity allowing the i-th transaction to consume target resources, and a resource payment account for paying the i-th transaction for consuming target resources. The method includes: grouping the multiple transactions, wherein the resource payment accounts included in each of the multiple transactions are not utilized; for any j-th resource payment account among the resource payment accounts included in the multiple transactions, determining a plurality of transactions including the j-th resource payment account according to the order of the multiple transactions; when the sum of the first resource quantities included in the first k transactions among the plurality of transactions is greater than the current quantity of target resources held by the j-th resource payment account, and the sum of the first resource quantities included in the first k-1 transactions among the plurality of transactions is not greater than the current quantity of target resources held by the j-th resource payment account, marking each transaction after the k-1 transaction among the plurality of transactions with a preset label; and concurrently executing the transactions among the multiple transactions that are not marked with the preset label according to the grouping result of the multiple transactions.

[0005] Secondly, a blockchain node in a blockchain system is provided for processing multiple transactions belonging to the same block. For any i-th transaction among the multiple transactions, it includes a first resource quantity allowing the i-th transaction to consume target resources, and a resource payment account for paying for the i-th transaction's consumption of target resources. The blockchain node includes: a transaction grouping unit configured to group the multiple transactions, wherein the resource payment accounts included in each of the multiple transactions are not utilized; and a transaction determination unit configured to, for any j-th resource payment account among the multiple resource payment accounts included in the multiple transactions, determine the transaction from the order of the multiple transactions. The plurality of transactions are identified to include the j-th resource payment account; a transaction marking unit is configured to mark each transaction after the (k-1)-th transaction with a preset label when the sum of the first resource quantities included in the first k transactions of the plurality of transactions is greater than the current quantity of target resources held by the j-th resource payment account, and the sum of the first resource quantities included in the first k-1 transactions of the plurality of transactions is not greater than the current quantity of target resources held by the j-th resource payment account; a transaction processing unit is configured to concurrently execute the transactions that are not marked with the preset label in the plurality of transactions according to the grouping result of the plurality of transactions.

[0006] Thirdly, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method provided in the first aspect.

[0007] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, wherein when the computer program is executed in a computing device, the computing device performs the method provided in the first aspect.

[0008] In the technical solution provided in the embodiments of this specification, for any resource payment account among several resource payment accounts involved in multiple transactions, by using the first resource quantity allowed to be consumed by several transactions including that resource payment account, and the current quantity of target resources held by that resource payment account, transactions that are ranked later and may fail to execute due to insufficient target resources can be identified and marked from among the several transactions. For the unmarked transactions among the several transactions, the resource payment account must hold enough target resources to execute them according to its allowed first resource quantity, without the need to execute the unmarked transactions in this part of the transactions serially, and therefore the process of grouping multiple transactions does not require analysis and use of their respective included resource payment accounts. Accordingly, the blockchain node only needs to execute the unmarked transactions concurrently according to the grouping results of multiple transactions, which can improve the parallelism of transaction execution while ensuring the fairness of transaction execution. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is an example architecture diagram of a blockchain system provided in the embodiments of this specification;

[0011] Figure 2 This is a flowchart illustrating a transaction processing method in a blockchain system provided in the embodiments of this specification;

[0012] Figure 3 This is a schematic diagram of a transaction data structure provided as an example in the embodiments of this specification;

[0013] Figure 4 This is a schematic diagram illustrating the process of concurrently processing multiple transactions in a blockchain node, as exemplarily provided in the embodiments of this specification.

[0014] Figure 5 This is a schematic diagram of the structure of a blockchain node provided in the embodiments of this specification. Detailed Implementation

[0015] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0016] Figure 1 This is an exemplary architecture diagram of a blockchain system provided in the embodiments of this specification. The blockchain system may include N blockchain nodes, wherein... Figure 1 The example shows eight blockchain nodes, numbered 1 through 8. The lines connecting the nodes schematically represent connections between nodes, such as Transmission Control Protocol (TCP) connections used to support data transfer between different nodes.

[0017] In a blockchain system, the system data that needs to be persistently stored can be divided into two parts: block data and state data.

[0018] Block data includes one or more blocks in ascending order of block height (or block number). A single block may include a block header and a block body. The block header may include the previous block's block hash (or parent hash), timestamp, block number (BlockNum), state root hash (State_Root), transaction root hash (Transaction_Root), and receipt root hash (Receipt_Root), etc. The block body may include a set of transactions and a set of receipts.

[0019] A transaction in a blockchain system refers to a unit of task executed and recorded within the blockchain system. A single transaction typically includes a From field, a To field, and a Data field. The From field includes the account that initiated the transaction (i.e., the sender account), and the To field may include another account involved in / pointed to by the transaction.

[0020] For any k-th block, based on the state data with block height (or block number) k-1, execute multiple transactions in the sequentially ordered set of transactions belonging to the k-th block, and obtain the execution results of these transactions. Then, update the state data with block height k-1 based on the execution results of these transactions to obtain the state data with block height k.

[0021] The consensus mechanism in a blockchain system is the mechanism by which blockchain nodes reach a consensus across the entire network on block information, ensuring that the latest obtained blocks are accurately stored. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. Among these algorithms, consensus is typically reached when a predetermined number of consensus nodes agree on the data to be agreed upon. For example, in the PBFT algorithm, assuming at most f nodes fail, if there are at least 3f+1 nodes, security and liveness are guaranteed throughout the blockchain system.

[0022] After receiving a transaction from a connected client or other blockchain node, a blockchain node can verify the transaction. Verified transactions are added to the corresponding transaction pool / transaction cache pool as transactions awaiting consensus. A blockchain node can also select multiple transactions belonging to any k-th block from the transaction pool to generate a corresponding consensus proposal. This proposal indicates the multiple transactions belonging to the k-th block and their order within that block. The blockchain node then reaches consensus on this proposal using the aforementioned consensus mechanisms. Once consensus is reached, the blockchain node executes the multiple transactions and removes them from the transaction pool after execution.

[0023] Some blockchain systems support parallel processing to improve performance. In a typical example, after consensus is reached on any k-th block's consensus proposal, a blockchain node can perform read / write conflict analysis on multiple transactions belonging to that k-th block. Based on the analysis results, these transactions are divided into M transaction groups, and the corresponding M transaction groups are scheduled to the M computing processes or M computing threads within the blockchain node. These M processes or threads then process the transactions within the M groups in parallel. It's important to note that a process is a single execution of a program on a set of data in a computer; it is the basic unit of resource allocation in a system and forms the foundation of the operating system architecture. The M computing threads can serve as execution threads for a computing engine, which may comprise several computing processes, and a single computing process may contain several computing processes.

[0024] When a blockchain node executes a transaction, the execution result includes the read-write set corresponding to that transaction. The read-write set may include a read set and / or a write set. The read set contains several unique keys, as well as key-value pairs read from the committed world state corresponding to the aforementioned keys. The write set also contains several unique keys, as well as key-value pairs expected to be committed corresponding to the aforementioned keys; furthermore, if a transaction deletes a key from the world state, the write set will also record a corresponding marker for the deleted key. For contract call transactions used to invoke smart contracts, their write sets may not only contain state parameters related to external accounts, but may also involve several contract parameters related to the smart contract's contract state. In summary, the aforementioned keys can correspond to an account or a field under an account in the blockchain system.

[0025] When dividing multiple transactions into M transaction groups, it is usually necessary to ensure that any two transactions within any two transaction groups do not conflict with each other. Specifically, this means that no two transactions fall into one of the following categories: the read set of one transaction contains the same key as the write set of another transaction; or the write set of one transaction contains the same key as the write set of another transaction. For any two transactions that do conflict, they need to be grouped into the same transaction group. In other words, if the write sets of any two transactions contain the same key, it is considered that the two conflicting transactions accessed the same parameter and therefore conflict, and these two transactions need to be grouped into the same transaction group; if the read set of one of the two transactions contains the same key as the write set of the other transaction, it is considered that the two transactions accessed the same parameter and therefore conflict, and these two transactions need to be grouped into the same transaction group. In another possible implementation, in order to efficiently determine the grouping information of the aforementioned multiple transactions or to efficiently divide the aforementioned multiple transactions into M transaction groups, the aforementioned multiple transactions can usually be grouped according to the requirement that any two transactions located in any two different transaction groups do not access the same parameters (i.e., do not contain the same key).

[0026] When a computing process or thread within a blockchain node executes transactions included in its corresponding transaction group, it consumes the blockchain node's computing resources. This is especially true for transactions requesting the deployment or invocation of smart contracts, where the blockchain node may need to execute a large number of instructions. Correspondingly, a target resource can be defined within the blockchain system. This target resource could be, for example, a token or other digital resource. The blockchain node can then deduct a corresponding amount of this target resource from the resource payment account designated by the transaction, according to its own predefined rules, as a resource usage fee paid for the transaction's use of the blockchain system's computing resources.

[0027] For example, during the execution of a transaction, the computing process or thread of a blockchain node can, based on the transaction's consumption instructions or the amount of data processed during the execution of the transaction, calculate the amount of target resources consumed during the execution of the transaction in real time, and then deduct the target resources held by the designated resource payment account according to the amount of resources consumed. If the target resources held by the designated resource payment account are insufficient to pay for the target resources consumed in the transaction, that is, the current amount of target resources held by the resource payment account is less than the amount of resources consumed in the transaction, the computing process or thread can terminate the execution of the transaction, the transaction fails, and the target resources held by the resource payment account are cleared to zero.

[0028] A single transaction may designate an account other than its own sender and receiver accounts as the resource payment account for that transaction, and some transactions belonging to the same block may designate the same resource payment account. If the current amount of target resources held by the same resource payment account is insufficient to pay for the target resources required to successfully execute that part of the transaction, then some of the transactions in that part will fail to execute successfully.

[0029] In one possible implementation, to ensure fairness in transaction execution, for transactions specifying the same resource payment account, this same resource payment account needs to be used as the conflict key for these transactions, and these transactions are grouped into the same transaction group. Correspondingly, the corresponding computing process or thread needs to execute these transactions sequentially according to their position in the overall transaction sequence. This ensures that transactions ranked earlier in the sequence are less likely to fail due to insufficient target resources held by their specified resource payment account. This implementation will affect the parallelism of transaction execution.

[0030] This specification provides at least one transaction processing method and blockchain node in a blockchain system. For any i-th transaction among multiple transactions belonging to the same block, it includes a first resource quantity allowing the i-th transaction to consume target resources, and a resource payment account used to pay for the i-th transaction's consumption of target resources. The blockchain node can first group the multiple transactions, without utilizing the resource payment accounts included in each transaction during the grouping process; then, for any j-th resource payment account among the resource payment accounts included in the multiple transactions, several transactions including the j-th resource payment account are determined from the multiple transactions according to the order of the multiple transactions; when the sum of the first resource quantities included in the first k transactions of the several transactions is greater than the current quantity of target resources held by the j-th resource payment account, and the sum of the first resource quantities included in the first k-1 transactions of the several transactions is not greater than the current quantity of target resources held by the j-th resource payment account, each transaction after the k-1 transaction in the several transactions is marked with a preset label; finally, according to the grouping result of the multiple transactions, the transactions among the multiple transactions that are not marked with preset labels are executed concurrently.

[0031] In the embodiments of this specification, for any resource payment account among several resource payment accounts involved in multiple transactions, by using the first resource quantity allowed to be consumed by several transactions including that resource payment account, and the current quantity of target resources held by that resource payment account, transactions that are ranked later and may fail to execute due to insufficient target resources can be identified and marked from among the several transactions. For the unmarked transactions among the several transactions, the resource payment account must hold enough target resources to execute them according to its allowed first resource quantity, without the need to strictly implement serial execution of the unmarked transactions in this part of the transactions. Therefore, the process of grouping multiple transactions does not require analyzing and using their respective included resource payment accounts. Accordingly, the blockchain node only needs to execute the unmarked transactions concurrently according to the grouping results of multiple transactions, which can improve the parallelism of transaction execution while ensuring the fairness of transaction execution.

[0032] Figure 2 This is a flowchart of a transaction processing method in a blockchain system provided in the embodiments of this specification.

[0033] This method can be executed by blockchain nodes in a blockchain system to process multiple transactions belonging to the same block. For example, after reaching a consensus on a consensus proposal corresponding to any k-th block, a blockchain node can, according to the instructions of that consensus proposal, determine multiple transactions belonging to the k-th block and arranged in order from the transaction pool or other locations.

[0034] For any i-th transaction among multiple transactions (denoted as transaction ) This includes allowing transactions. The first resource quantity of the target resource for consumption (denoted as resource quantity) ), and used for payment transactions The resource payment account for the target resources consumed.

[0035] trade The system can specify either the sender's account or the receiver's account as its resource payment account, or it can specify an account other than the sender's account and receiver's account as its resource payment account.

[0036] trade This includes the transaction ontology, which includes the sender account, receiver account, resource payment account, and the entity that allows the transaction. Quantity of resources for the target consumption The transaction The transaction also includes the sender's account's first signature on the transaction entity. When the resource payment account differs from the sender's account, the transaction... It also includes a second signature of the resource payment account on the transaction ontology.

[0037] For example, see Figure 3 As shown. User U1, who holds account C1, can first construct a transaction in client A1. The transaction ontology, wherein the From field of the transaction ontology includes the sender account C1, the To field includes the receiver account C2, and the Data field includes the resource payment account C3 declared through a specific subfield such as target, and the resource quantity declared through a specific subfield such as gas limit. Next, the private key of account C1 can be used to sign the transaction entity to obtain a signature. And provide the transaction ontology and signature to client A3 corresponding to user U3 who holds account C3. Furthermore, when user U3 agrees to conduct transactions through their account C3... When paying for the target resource, the transaction entity can be signed using the private key of account C3 to obtain a signature. Finally, the transaction entity and signature. and signature Combining transactions This is sent by client A1 or client A3 to a specific blockchain node in the blockchain system. Figure 3 Example of a transaction The structure is merely an example; for instance, a transaction can also be declared separately in the transaction ontology using other specific fields alongside the Data field. Designated resource payment account C3 and permitted transactions Quantity of resources for the target consumption .

[0038] Allow transactions The quantity of the target resources consumed It can be customized by the user.

[0039] When trading The resource payment account specified in the transaction is different from the transaction account. When the sender's account is involved in the transaction This includes a second signature of the resource payment account on the transaction entity, which is then received and verified by the blockchain nodes. During the process, it is necessary not only to verify the transaction The first signature corresponding to the sender's account also needs to be verified for the transaction. The second signature corresponding to the resource payment account.

[0040] Reference Figure 2 As shown, the method may include, but is not limited to, some or all of the following steps S201 to S209.

[0041] Step S201: Group the multiple transactions, where the resource payment accounts included in each of the multiple transactions are not utilized.

[0042] When grouping multiple transactions, it is necessary to ensure that any two transactions in any two transaction groups do not have read / write conflicts with each other for their unique keys in the read / write set, excluding resource payment accounts.

[0043] A blockchain node can include a pre-execution service, which can pre-execute multiple transactions to obtain pre-execution read-write sets for each transaction; subsequently, the multiple transactions can be grouped according to these pre-execution read-write sets. During the pre-execution process, it is not necessary to follow the transaction. The designated resource payment account can read and write the target resources held by that account; thus, when the transaction... When the resource payment account included differs from its included sender and receiver accounts, the transaction... The pre-execution read / write set does not include the resource payment accounts included in the i-th exchange.

[0044] Blockchain nodes may also group multiple transactions without requiring pre-execution and ensure that each transaction is properly stored.

[0045] Without using multiple transaction resource payment accounts to group multiple transactions, the number of transaction groups obtained is relatively higher compared to grouping multiple transactions using multiple transaction resource payment accounts. The following example illustrates this by grouping transactions Tx1 to Tx5, arranged sequentially as shown in Table 1.

[0046] trade Sender account Recipient Account Resource payment account Tx1 K01 K02 K00 Tx2 K03 K04 K00 Tx3 K05 K06 K00 Tx4 K07 K08 K09 Tx5 K08 K10 K11

[0047] Table 1

[0048] See Table 1 for examples of transaction Tx1 to transaction Tx5, which each include the sender account, receiver account, and resource payment account.

[0049] If the resource payment accounts in transactions Tx1 to Tx5 are used to group transactions Tx1 and Tx5, then K00 is the conflicting key for transactions Tx1 to Tx3, and transactions Tx1 to Tx3 need to be assigned to the same transaction group; K08 is the conflicting key for transactions Tx4 and Tx5, and transactions Tx4 and Tx5 need to be assigned to the same transaction group; that is, transactions Tx1 to Tx5 will be divided into 2 transaction groups, and the parallelism of transaction execution is 2.

[0050] If the resource payment accounts in transactions Tx1 through Tx5 are not used to group transactions Tx1 and Tx5, then K00 will not be a conflicting key for transactions Tx1 through Tx3, and transactions Tx1 through Tx3 can be divided into 3 different transaction groups. K08 is not a resource payment account for transactions Tx4 and Tx5, but it will still be a conflicting key for transactions Tx4 and Tx5, and transactions Tx4 and Tx5 need to be divided into the same transaction group. That is, transactions Tx1 through Tx5 will be divided into 4 transaction groups, and the parallelism of transaction execution is 4.

[0051] Step S203: For any j-th resource payment account among the resource payment accounts included in the multiple exchanges, determine the transactions that include the j-th resource payment account from the multiple transactions according to the order of the multiple transactions.

[0052] Taking multiple transactions including transactions Tx1 to Tx5 from the aforementioned example as an example, the resource payment accounts included are K00, K09, and K11. For resource payment account K00, the transactions specifically including transactions Tx1 to Tx3 can be determined from transactions Tx1 to Tx5 according to their order. Similarly, the transactions corresponding to K09 and K11 can be determined in the same way.

[0053] Step S205: For a number of transactions including the j-th resource payment account, if the sum of the first resource quantities included in the first k transactions of the number of transactions is greater than the current quantity of target resources held by the j-th resource payment account, and the sum of the first resource quantities included in the first k-1 transactions of the number of transactions is not greater than the current quantity of target resources held by the j-th resource payment account, a preset label is assigned to each transaction after the k-1 transaction of the number of transactions.

[0054] For example, for transactions Tx1 through Tx3 that include resource payment account K00, if the sum of the first resource quantities included in the first three transactions (Tx1 through Tx3) is greater than the current quantity of target resources held by resource payment account K00, while the sum of the first resource quantities included in the first two transactions (Tx1 and Tx2) is not greater than the current quantity of target resources held by resource payment account K00, then this indicates that, to ensure fairness and prevent transactions from failing to execute due to insufficient target resources held by their designated resource payment accounts, the target resources held by resource payment account K00 may be insufficient to support the successful execution of transaction Tx3 by the blockchain node. Correspondingly, a preset label can be set for transaction Tx3 to indicate that the relevant computation process or thread in the blockchain node does not need to execute transaction Tx3 in subsequent processes.

[0055] See Figure 4 As shown, preset tags for transactions can be set using bit sequences corresponding to multiple transactions. For example, for five transactions Tx1 to Tx5 arranged in sequence, a bit sequence of length 5 can be maintained. Starting from the high / low bit of the bit sequence, if any q-th transaction among Tx1 to Tx5 needs to be set with a preset tag, the value of the q-th bit in that bit sequence can be set to the preset tag, for example, 1; otherwise, the value of the q-th bit can be set to a non-preset tag, for example, 0. Obviously, preset tags for transactions can also be set in other ways, which will not be elaborated here.

[0056] In one possible implementation, for a number of transactions including the j-th resource payment account, the first resource quantities included in the first k transactions can be summed sequentially according to the order of the transactions to obtain the cumulative resource quantities corresponding to the first k transactions; when the cumulative resource quantity is greater than the current quantity of the target resource held by the j-th resource payment account, a preset label is set for each transaction after the (k-1)-th transaction.

[0057] In one possible implementation, for a plurality of transactions including the j-th resource payment account, the current quantity of the target resource held by the j-th resource payment account is obtained from the state data; the current quantity is cached in a predetermined area as a variable that allows blockchain nodes to modify and is independent of the state data; according to the order of the plurality of transactions, the k-th transaction among the plurality of transactions is executed sequentially: determining whether the current quantity cached in the predetermined area reaches the first resource quantity included in the k-th transaction; if so, the first resource quantity included in the k-th transaction is deducted from the current quantity in the predetermined area; otherwise, a preset label is marked on each transaction after the (k-1)-th transaction among the plurality of transactions.

[0058] Step S207: Based on the grouping results of multiple transactions, concurrently execute the transactions that are not marked with a preset label among the multiple transactions.

[0059] Transactions belonging to different groups can be scheduled to different computing processes or threads within the blockchain node, and these processes or threads will handle the transactions in their respective groups. If a transaction in a particular group is marked with a preset tag, the corresponding computing process or thread can be provided with information indicating that a transaction in that group has been marked with a preset tag.

[0060] See Figure 4 As shown, continuing to assume that transaction Tx1 is assigned to transaction group 1, transaction Tx2 to transaction group 2, transaction Tx3 to transaction group 3, and transactions Tx4 and Tx5 to transaction group 4, then these four transaction groups (1 to 4) can be respectively scheduled to the four computing threads (1, 2, 3, and 4) within the blockchain node. Furthermore, assuming transaction Tx3 is marked with a preset tag, computing thread 3 can be provided with indication that transaction Tx3 is marked with a preset tag, such as providing a 5-bit sequence corresponding to transactions Tx1 to Tx5 in the previous example.

[0061] For any p-th transaction within any n-th transaction group, the n-th computation process or thread can first determine whether the p-th transaction is marked with a preset tag; for example, by querying the value of the bit corresponding to the p-th transaction from the aforementioned bit sequence to determine whether the p-th transaction is marked with a preset tag. If the p-th transaction is not marked with a preset tag, the n-th computation process or thread executes the p-th transaction and obtains the execution result of the p-th transaction. Conversely, if the p-th transaction is marked with a preset tag, the n-th computation process or thread can directly generate an execution result indicating that the p-th transaction failed to execute.

[0062] For a transaction executed by the nth computation process or the nth computation thread, the nth computation process or the nth computation thread does not need to change the amount of target resources held in the resource payment account specified by the exchange based on the resource payment account specified by the exchange and the second quantity of target resources consumed by the transaction.

[0063] For a transaction executed by the nth computation process or the nth computation thread, the transaction will generally not fail due to insufficient target resources included in the specified resource payment account; regardless of whether the transaction is successfully executed by the blockchain node, the execution result of the transaction includes the resource payment account specified by the transaction and the second quantity of the target resources consumed by the transaction.

[0064] For a transaction executed by the nth computation process or the nth computation thread, the nth computation process or the nth computation thread may also return its corresponding resource payment account and a second quantity of the target resource to a specific process in the blockchain node, such as the block management process, so that the block management process can deduct the target resource held by the transaction from the relevant resource payment account in subsequent processes. For example, the nth computation process or the nth computation thread may return the execution results of all transactions in its corresponding transaction group to the block management process.

[0065] Step S209: For several transactions including the j-th resource payment account, based on the execution results of the first k transactions, obtain the second resource quantity of each transaction that consumes the target resource, and deduct the target resource held by the j-th resource payment account from the sum of the second resource quantities.

[0066] Continuing from the previous example, a blockchain node can, through its block management process, obtain the second resource quantity of the target resource consumed by the first k transactions from the execution results of several transactions that specify the j-th resource payment account as its resource payment account, and deduct the target resource held by the j-th resource payment account from the sum of the second resource quantities consumed by the first k transactions.

[0067] Based on the same concept as the aforementioned method embodiments, this specification also provides a blockchain node 500 in a blockchain system for processing multiple transactions belonging to the same block. For any i-th transaction among the multiple transactions, it includes a first resource quantity that the i-th transaction is allowed to consume target resources, and a resource payment account for paying for the target resources consumed by the i-th transaction. (Refer to...) Figure 5As shown, the blockchain node 500 includes: a transaction grouping unit 501, configured to group the plurality of transactions, wherein the resource payment accounts included in each of the plurality of transactions are not utilized; a transaction determination unit 503, configured to, for any j-th resource payment account among the plurality of resource payment accounts included in the plurality of transactions, determine a plurality of transactions including the j-th resource payment account according to the order of the plurality of transactions; a transaction marking unit 505, configured to, when the sum of the first resource quantities included in the first k transactions among the plurality of transactions is greater than the current quantity of target resources held by the j-th resource payment account, and the sum of the first resource quantities included in the first k-1 transactions among the plurality of transactions is not greater than the current quantity of target resources held by the j-th resource payment account, mark each transaction after the (k-1)-th transaction among the plurality of transactions with a preset label; and a transaction processing unit 507, configured to concurrently execute the transactions among the plurality of transactions that are not marked with the preset label according to the grouping result of the plurality of transactions.

[0068] In one possible implementation, the blockchain node 500 further includes a resource management unit 509, configured to obtain the second resource quantity of each of the first k transactions based on the execution results of the first k transactions, and deduct the target resource held by the j-th resource payment account according to the sum of the second resource quantities.

[0069] In one possible implementation, the transaction grouping unit 501 is configured to determine a pre-execution read / write set for each of the plurality of transactions, wherein the pre-execution read / write set of the i-th transaction does not include the resource payment account included in the i-th transaction when the resource payment account included in the i-th transaction is different from the sender account and receiver account included therein; and to group the plurality of transactions according to the pre-execution read / write set.

[0070] In one possible implementation, the grouping result of the multiple transactions includes multiple transaction groups, which correspond to multiple computing processes or multiple computing threads in the blockchain node; wherein, the transaction processing unit 507 is configured to, for any p-th transaction in any n-th transaction group, execute in the n-th computing process or n-th computing thread: determine whether the p-th transaction is marked with a preset tag; if the p-th transaction is not marked with a preset tag, execute the p-th transaction to obtain the execution result of the p-th transaction.

[0071] In one possible implementation, the transaction processing unit 507 is further configured to execute in the nth computation process or the nth computation thread: when the pth transaction is marked with a preset tag, generate an execution result indicating that the pth transaction failed to execute.

[0072] In one possible implementation, the transaction marking unit 505 is configured to sum the first resource quantities included in the first k transactions in the order of the plurality of transactions to obtain the cumulative resource quantity corresponding to the first k transactions; when the cumulative resource quantity is greater than the current quantity of target resources held by the j-th resource payment account, a preset label is set for each transaction in the plurality of transactions located after the (k-1)-th transaction.

[0073] In one possible implementation, the transaction marking unit 505 is configured to obtain the current quantity of the target resource held by the j-th resource payment account from the status data; cache the current quantity in a predetermined area; and, according to the order of the plurality of transactions, sequentially perform the following on the k-th transaction among the plurality of transactions: determine whether the current quantity cached in the predetermined area reaches the first resource quantity included in the k-th transaction; if yes, deduct the first resource quantity included in the k-th transaction from the current quantity in the predetermined area; if no, preset a label for each transaction marked after the (k-1)-th transaction among the plurality of transactions.

[0074] This specification also provides a computer-readable storage medium storing a computer program / instruction, which, when executed in a computing device, causes the computing device to execute a transaction processing method in a blockchain system provided in any embodiment of this specification.

[0075] This specification also provides a computing device in its embodiments, including a memory and a processor. The memory stores computer programs / instructions, and when the processor executes the computer programs / instructions, it implements a transaction processing method in a blockchain system provided in any embodiment of this specification.

[0076] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0077] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0078] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0079] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0080] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0081] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0082] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0083] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0084] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0085] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0086] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information that can be used by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0087] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0088] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0089] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0090] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A transaction processing method in a blockchain system, used to process multiple transactions belonging to the same block, wherein for any i-th transaction among the multiple transactions, the method includes a first resource quantity allowing the i-th transaction to consume a target resource, and a resource payment account for paying the i-th transaction for consuming the target resource; the method includes: The multiple transactions are grouped, wherein the resource payment accounts included in each of the multiple transactions are not utilized, such that the unique keys in the read and write sets of any two transactions belonging to different transaction groups, excluding the resource payment accounts, do not conflict with each other. For any j-th resource payment account among the resource payment accounts included in the plurality of transactions, determine a plurality of transactions including the j-th resource payment account from the plurality of transactions according to the order of the plurality of transactions; When the sum of the first resource quantities included in the first k transactions of the plurality of transactions is greater than the current quantity of target resources held by the j-th resource payment account, and the sum of the first resource quantities included in the first k-1 transactions of the plurality of transactions is not greater than the current quantity of target resources held by the j-th resource payment account, a preset label is set for each transaction in the plurality of transactions that is after the k-1 transaction. Based on the grouping results of the multiple transactions, concurrently execute the transactions that are not marked with a preset label among the multiple transactions.

2. The method according to claim 1, further comprising: Based on the execution results of the first k transactions, obtain the second resource quantity of the target resource consumed by each of the first k transactions, and deduct the target resource held by the j-th resource payment account according to the sum of the second resource quantities.

3. The method according to claim 1, wherein grouping the plurality of transactions comprises: Determine the pre-execution read-write set for each of the plurality of transactions, wherein when the resource payment account included in the i-th transaction is different from the sender account and receiver account included therein, the pre-execution read-write set of the i-th transaction does not include the resource payment account included in the i-th transaction; The multiple transactions are grouped according to the pre-execution read / write set.

4. The method according to claim 1, wherein the grouping result of the multiple transactions includes multiple transaction groups, and the multiple transaction groups correspond to multiple computing threads in the blockchain node; in, The step of concurrently executing transactions that are not marked with a preset label according to the grouping results of the multiple transactions includes: for any p-th transaction in any n-th transaction group, the n-th calculation thread determines whether the p-th transaction is marked with a preset label; when the p-th transaction is not marked with a preset label, the n-th calculation thread executes the p-th transaction and obtains the execution result of the p-th transaction.

5. The method according to claim 4, further comprising: When the p-th transaction is marked with a preset label, the n-th calculation thread generates an execution result indicating that the p-th transaction failed to execute.

6. The method according to claim 1, wherein when the sum of the first resource quantities included in the first k transactions of the plurality of transactions is greater than the current quantity of the target resource held by the j-th resource payment account, and the sum of the first resource quantities included in the first k-1 transactions of the plurality of transactions is not greater than the current quantity of the target resource held by the j-th resource payment account, a preset label is set for each transaction in the plurality of transactions after the k-1 transaction, including: According to the order of the transactions, the first resource quantity included in the first k transactions is summed to obtain the cumulative resource quantity corresponding to the first k transactions. When the cumulative amount of resources is greater than the current amount of target resources held by the j-th resource payment account, a preset label is set for each transaction after the (k-1)-th transaction among the plurality of transactions.

7. The method according to claim 1, wherein when the sum of the first resource quantities included in the first k transactions of the plurality of transactions is greater than the current quantity of the target resource held by the j-th resource payment account, and the sum of the first resource quantities included in the first k-1 transactions of the plurality of transactions is not greater than the current quantity of the target resource held by the j-th resource payment account, a preset label is set for each transaction in the plurality of transactions located after the k-1 transaction, comprising: Obtain the current quantity of the target resource held by the j-th resource payment account from the status data; Cache the current quantity in a predetermined area; According to the order of the transactions, the following steps are performed on the kth transaction in sequence: determine whether the current quantity of the cached area reaches the first resource quantity included in the kth transaction; if yes, deduct the first resource quantity included in the kth transaction from the current quantity in the cached area; if no, pre-label each transaction after the (k-1)th transaction in the transaction.

8. A blockchain node in a blockchain system for processing multiple transactions belonging to the same block, wherein for any i-th transaction among the multiple transactions, it includes a first amount of resource that allows the i-th transaction to consume target resources, and a resource payment account for paying the target resources consumed by the i-th transaction; The blockchain nodes include: The transaction grouping unit is configured to group the plurality of transactions, wherein the resource payment accounts included in each of the plurality of transactions are not utilized, such that the unique keys in the read and write sets of any two transactions belonging to different transaction groups, excluding the resource payment accounts, do not conflict with each other in read and write. The transaction determination unit is configured to, for any j-th resource payment account among the plurality of resource payment accounts included in the plurality of transactions, determine a plurality of transactions including the j-th resource payment account from the plurality of transactions according to the order of the plurality of transactions; The transaction marking unit is configured to pre-label each transaction after the (k-1)th transaction in the plurality of transactions when the sum of the first resource quantities included in the first k transactions is greater than the current quantity of the target resource held by the jth resource payment account, and the sum of the first resource quantities included in the first k-1 transactions is not greater than the current quantity of the target resource held by the jth resource payment account. The transaction processing unit is configured to concurrently execute transactions that are not marked with a preset label among the multiple transactions according to the grouping results of the multiple transactions.

9. The blockchain node according to claim 8, further comprising: The resource management unit is configured to obtain the second resource quantity of each of the first k transactions that consumed the target resource based on the execution results of the first k transactions, and deduct the target resource held by the j-th resource payment account according to the sum of the second resource quantities.

10. The blockchain node according to claim 8, wherein the transaction grouping unit is configured to determine a pre-execution read / write set for each of the plurality of transactions, wherein when the resource payment account included in the i-th transaction is different from the sender account and receiver account included therein, the pre-execution read / write set of the i-th transaction does not include the resource payment account included in the i-th transaction; and to group the plurality of transactions according to the pre-execution read / write set.

11. The blockchain node according to claim 8, wherein the grouping result of the plurality of transactions includes a plurality of transaction groups, and the plurality of transaction groups correspond to a plurality of computing threads in the blockchain node; wherein, The transaction processing unit is configured to, for any p-th transaction in any n-th transaction group, execute the following on the nth calculation thread: determine whether the p-th transaction is marked with a preset label; if the p-th transaction is not marked with a preset label, the n-th calculation thread executes the p-th transaction and obtains the execution result of the p-th transaction.

12. The blockchain node according to claim 11, wherein the transaction processing unit is further configured to generate an execution result representing the failure of the p-th transaction in the n-th computing thread when the p-th transaction is marked with a preset tag.

13. The blockchain node according to claim 8, wherein the transaction marking unit is configured to sum the first resource quantities included in the first k transactions in the plurality of transactions according to the order of the plurality of transactions, to obtain the cumulative resource quantity corresponding to the first k transactions; when the cumulative resource quantity is greater than the current quantity of the target resource held by the j-th resource payment account, a preset label is set for each transaction in the plurality of transactions located after the (k-1)-th transaction.

14. The blockchain node according to claim 8, wherein the transaction marking unit is configured to obtain the current quantity of the target resource held by the j-th resource payment account from the state data; cache the current quantity in a predetermined area; and, according to the order of the plurality of transactions, sequentially perform the following on the k-th transaction among the plurality of transactions: determine whether the current quantity cached in the predetermined area reaches the first resource quantity included in the k-th transaction; if yes, deduct the first resource quantity included in the k-th transaction from the current quantity in the predetermined area; if no, pre-label each transaction after the (k-1)-th transaction among the plurality of transactions.

15. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-7.

16. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed in a computing device, the computing device implements the method of any one of claims 1-7.

Images