Methods of transaction execution, nodes, and blockchain systems

Abstract

The specification provides a transaction execution method, a node and a blockchain system, applied to a first node in a blockchain system, the first node comprising a control process and N computing processes, the method comprising: the control process obtaining M transaction groups, the M transaction groups being obtained by grouping a plurality of transactions in a target block based on respective pre-execution read-write sets of the plurality of transactions, M and N being positive integers; the control process obtaining pre-execution read-write sets of transactions in other blocks in a case where it is determined that there are other blocks in an execution phase, and sending transaction groups irrelevant to the obtained pre-execution read-write sets in the M transaction groups to different computing processes in the N processes respectively; a first computing process executing each transaction in a received transaction group in a case where it receives any transaction group in the M transaction groups.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a transaction execution method, node, and 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 to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Users can participate in blockchain-related transactions through blockchain nodes. For example, multiple blockchain nodes corresponding to different users can perform secure multi-party computation (SMPC) on the private data of a particular node based on privacy technologies such as homomorphic encryption and zero-knowledge proofs. Furthermore, blockchain networks enable transfers between different user accounts; and they can also issue NFTs (Non-Fungible Tokens) representing digital artworks, digital avatars, GIFs, and other digital collectibles, allowing ownership of these digital collectibles to circulate among users on the blockchain network, thereby generating value corresponding to the digital collectibles. Summary of the Invention

[0003] This specification provides a method for executing transactions, nodes, and a blockchain system.

[0004] Specifically, this specification is implemented through the following technical solution:

[0005] According to a first aspect of the embodiments of this specification, a method for executing a transaction is provided, applied to a first node in a blockchain system, the first node including a control process and N computing processes, the method comprising:

[0006] The control process acquires M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the target block, where M and N are positive integers.

[0007] If the control process determines that there are other blocks in the execution phase, it obtains the pre-execution read-write set of the transactions in the other blocks, and sends the transaction groups that are not related to the obtained pre-execution read-write set from the M transaction groups to different computing processes in the N processes respectively.

[0008] Upon receiving any of the M transaction packets, the first computing process executes each transaction within the received transaction packet.

[0009] According to a second aspect of the embodiments of this specification, a method for executing a transaction is provided, applied to a first node in a blockchain system, the first node including a control process and N computing processes, the method comprising:

[0010] The control process determines multiple blocks and obtains the transaction group corresponding to each block. The transaction group is obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the corresponding block.

[0011] The control process generates a set of transaction packets, wherein the transaction packets in the set are from at least two of the plurality of blocks, and each transaction packet is independent of the pre-execution read / write set corresponding to other transaction packets in the set; and sends the transaction packets in the set to different computing processes in the N processes respectively; N is a positive integer;

[0012] Upon receiving any transaction packet, the first computing process executes each transaction within the received transaction packet.

[0013] According to a third aspect of the embodiments of this specification, a first node in a blockchain system is provided, the first node comprising a control process and N computing processes, the method comprising:

[0014] The control process is used to obtain M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the target block, where M and N are positive integers;

[0015] The control process is used to, when it is determined that there are other blocks in the execution phase, obtain the pre-execution read-write set of transactions in the other blocks, and send the transaction groups that are not related to the obtained pre-execution read-write set from the M transaction groups to different computing processes in the N processes respectively.

[0016] The first computing process is used to execute each transaction in the received transaction packet when any of the M transaction packets is received.

[0017] According to a fourth aspect of the embodiments of this specification, a first node in a blockchain system is provided, the first node comprising a control process and N computing processes, wherein:

[0018] The control process determines multiple blocks and obtains the transaction group corresponding to each block. The transaction group is obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the corresponding block.

[0019] The control process generates a set of transaction packets, wherein the transaction packets in the set are from at least two of the plurality of blocks, and each transaction packet is independent of the pre-execution read / write set corresponding to other transaction packets in the set; and sends the transaction packets in the set to different computing processes in the N processes respectively; N is a positive integer;

[0020] Upon receiving any transaction packet, the first computing process executes each transaction within the received transaction packet.

[0021] According to a fifth aspect of the embodiments of this specification, a blockchain system is provided, including a first node, the first node comprising a control process and N computing processes, wherein:

[0022] The control process is used to obtain M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the target block, where M and N are positive integers;

[0023] The control process is used to, when it is determined that there are other blocks in the execution phase, obtain the pre-execution read-write set of transactions in the other blocks, and send the transaction groups that are not related to the obtained pre-execution read-write set from the M transaction groups to different computing processes in the N processes respectively.

[0024] The first computing process is used to execute each transaction in the received transaction packet when any of the M transaction packets is received.

[0025] According to a sixth aspect of the embodiments of this specification, a blockchain system is provided, including a first node, wherein the first node includes a control process and N computing processes, wherein:

[0026] The control process determines multiple blocks and obtains the transaction group corresponding to each block. The transaction group is obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the corresponding block.

[0027] The control process generates a set of transaction packets, wherein the transaction packets in the set are from at least two of the plurality of blocks, and each transaction packet is independent of the pre-execution read / write set corresponding to other transaction packets in the set; and sends the transaction packets in the set to different computing processes in the N processes respectively; N is a positive integer;

[0028] Upon receiving any transaction packet, the first computing process executes each transaction within the received transaction packet.

[0029] According to a seventh aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method as described in any one of the first or second aspects.

[0030] According to an eighth aspect of the embodiments of this specification, a fifth aspect according to one or more embodiments of this specification is provided, which proposes a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in any one of the first or second aspects.

[0031] In the technical solution provided in this specification, the transaction group to be sent to the computing process is determined by obtaining the transaction group of the target block and comparing the relationship between the pre-execution read and write sets of the transaction group and other blocks. This allows transaction groups across multiple blocks to be executed independently, thereby improving the processing efficiency of the execution pipeline for multiple blocks.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0033] 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.

[0034] Figure 1 This is a schematic diagram of a blockchain system provided in an exemplary embodiment;

[0035] Figures 2a-2b This is a schematic diagram of a transaction execution process in a blockchain node provided in an exemplary embodiment;

[0036] Figure 3 This is a flowchart illustrating a method for executing a transaction, as provided in an exemplary embodiment.

[0037] Figure 4 This is a schematic diagram of a DAG graph of multiple transactions in one embodiment;

[0038] Figure 5 This is a schematic diagram of the structure of any two nodes in a blockchain system provided in an exemplary embodiment;

[0039] Figure 6 This is a schematic diagram illustrating parallel execution of transactions across inter-block groups, provided in an exemplary embodiment.

[0040] Figure 7 This is a flowchart of another transaction execution method provided in an exemplary embodiment;

[0041] Figure 8 This is a schematic diagram of the structure of a first node in a blockchain system provided in an exemplary embodiment;

[0042] Figure 9 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. Detailed Implementation

[0043] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification.

[0044] It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the methods may include more or fewer steps than those described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments. It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0045] Figure 1 This is a schematic diagram of a blockchain system provided in an exemplary embodiment. For example... Figure 1As shown, a blockchain system is a distributed network built through multiple nodes. It involves peer-to-peer (P2P) communication between any two nodes at the application layer. For example, any two nodes from n1 to n5 can communicate at the application layer via a P2P network. The blockchain system utilizes a chain-like block structure to construct a decentralized (or multi-centralized) distributed ledger, which is stored on each node (or most nodes, such as consensus nodes) within the distributed blockchain system. Therefore, the blockchain system needs to address the consistency and correctness of the ledger data across these decentralized (or multi-centralized) nodes. Accordingly, each node in the blockchain system runs a blockchain program. Under certain fault-tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions. Transactions are packaged into blocks, and the world state is updated based on the execution results of the same transactions. The current mainstream consensus mechanisms include, but are not limited to: Proof of Work (POW), Proof of Stake (POS), Practical Byzantine Fault Tolerance (PBFT) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.

[0046] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a send field (From), a receive field (To), and a data field (Data). Blockchain transactions can include platform transactions and contract transactions. Platform transactions primarily revolve around platform account operations, including account creation, transfers, account freezing, account unfreezing, asset issuance, and notarization. Contract transactions primarily revolve around contract execution operations, including contract deployment, contract invocation, and contract upgrades.

[0047] For example, in the case of a transfer transaction, the From field represents the account address that initiated the transaction (i.e., initiated the transfer task to another account), the To field represents the account address that received the transaction (i.e., received the transfer), and the Data field includes the transfer amount. In the case of a transaction that invokes a contract, the From field represents the account address that initiated the transaction, the To field represents the account address of the contract invoked by the transaction, and the Data field includes the function name in the invoked contract and the parameters passed to that function, etc., to be used to retrieve and execute the function's code from the blockchain during transaction execution.

[0048] Accounts in a blockchain can generally be divided into two types:

[0049] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code; it can typically only be activated by an external account.

[0050] Externally owned account: The account of a blockchain user.

[0051] In blockchain, a smart contract is a contract that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner. It's important to note that besides users creating smart contracts, the system can also set smart contracts in the genesis block. These contracts are generally called genesis contracts. Typically, the genesis contract can set some blockchain data structures, parameters, attributes, and methods. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts). These system contracts can be used to add data structures for different business operations to the blockchain.

[0052] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1 In the blockchain shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93…" is determined. Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, and saves the contract code in the contract's state storage, thus the contract is successfully created.

[0053] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field "0x6f8ae93…" represents the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0054] Blockchain nodes in the blockchain system can execute blockchain transactions. A blockchain node can include multiple threads, allowing the node to execute transactions concurrently. For example, when there are multiple transactions to be executed, the blockchain node can distribute these transactions to multiple threads, so that each thread can execute (i.e., execute concurrently) the transactions it receives, thereby improving the overall execution efficiency of blockchain transactions.

[0055] In related technologies, blockchain nodes typically distribute the same number of transactions to each process according to the principle of load balancing. However, since the time required to execute different blockchain transactions may vary, this distribution method can easily limit transaction execution efficiency and resource utilization. For example, after thread A finishes executing the transactions it receives, if thread B has not yet finished, the blockchain node needs to wait for thread B to complete before it can submit the execution results of threads A and B together. During this waiting process, thread A cannot execute other transactions or deals. It is evident that this transaction distribution method results in significant differences in the time it takes for each thread to complete its transaction, leading not only to low overall blockchain transaction execution efficiency and affecting the efficiency of uploading execution results to the blockchain, but also wasting the computational resources of threads that finish first.

[0056] To address the aforementioned issues in related technologies and improve the transactions per second (TPS) metric in blockchains, transaction execution speed can be accelerated. Specifically, blockchain nodes can accelerate transaction execution by executing transactions in parallel. Typically, for transfer transactions, blockchain nodes first divide multiple transactions into groups based on the accounts accessed, with each group not accessing the same accounts, thus allowing parallel execution of each group. However, when a smart contract is invoked within a transaction, the variables accessed within that transaction cannot be predicted before execution, making effective grouping of multiple transactions impossible and hindering parallel execution. In one embodiment, the first node in the blockchain (e.g., Figure 1 Node n1 in the blockchain pre-executes multiple transactions, obtaining a pre-execution read / write set for each transaction, and then sends this pre-execution read / write set to other nodes in the blockchain (e.g., [node n1]) through a consensus process with other nodes. Figure 1 (Nodes n2 to n5 in the blockchain). The pre-execution read / write set of a transaction includes, for example, a pre-execution read set and a pre-execution write set. The pre-execution read set includes key-value pairs of variables read during pre-execution, and the pre-execution write set includes key-value pairs of variables written during pre-execution. These variables may include, for example, external accounts in the blockchain or variables defined in a contract account. Other nodes in the blockchain can group multiple transactions according to their pre-execution read / write sets, thereby enabling parallel execution of these multiple transactions based on the grouping results.

[0057] Multiple transactions can be grouped using different algorithms; specific grouping methods will be described in detail below, and therefore will not be elaborated upon here. Of course, those skilled in the art will recognize that the above solutions can only optimize the transaction execution method within the scope of "each block in a blockchain node," thereby shortening the transaction execution efficiency of each block itself. For example, by... Figure 2a The transaction execution flow shown depicts blockchain nodes processing transactions sequentially from block N, block N+1, and block N+2 in a pipeline manner. Parallel execution of each transaction is limited to within block N, block N+1, or block N+2. Therefore, it's evident that blockchain nodes in related technologies cannot optimize the execution efficiency of transactions across different blocks at a higher level (i.e., achieve similar performance). Figure 2b In the transaction execution process shown, blockchain nodes execute transactions between block N and block N+1, or between block N+1 and block N+2, in parallel, thereby improving the overall processing efficiency of the aforementioned pipeline. Therefore, this application provides a new transaction execution method, which is described below in conjunction with... Figure 3 Provide a detailed description of the execution method for a transaction.

[0058] Figure 3 This is a flowchart illustrating a method for executing a transaction, as provided in an exemplary embodiment. Figure 3 As shown, this method is applied to the first node in a blockchain system. The first node can be the node that initiates the consensus proposal (such as a master node), or it can be another blockchain node (such as a slave node). Regardless of whether it is a master node or a slave node in the blockchain system, each node can be implemented as any device, platform, equipment, or cluster of devices with computing / processing capabilities. The aforementioned first node can include a control process and N computing processes. The method includes the following steps:

[0059] Step 302: The control process obtains M transaction groups. The M transaction groups are obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the target block. M and N are positive integers.

[0060] As mentioned earlier, the above transaction grouping can be obtained by grouping multiple transactions using different algorithms.

[0061] In one embodiment, multiple transactions can be grouped using a Directed Acyclic Graph (DAG) algorithm. Specifically, a DAG graph is first drawn based on the dependencies between transactions. For example, assuming a slave node executes multiple transactions according to the order in which the master node pre-executes them, the dependencies between transactions can be determined based on their pre-execution read / write sets and the pre-execution order. If the pre-execution read set of one transaction includes the same key as the pre-execution write set of another transaction, or if the write set of one transaction includes the same key as the write set of another transaction, then the later-executed transaction (e.g., transaction Tx2) depends on the earlier-executed transaction (e.g., transaction Tx1). Therefore, in the DAG graph, transaction Tx1 can be drawn pointing to transaction Tx2. In the case where transaction Tx2 depends on the execution of transaction Tx1, transactions Tx1 and Tx2 are considered conflicting transactions and need to be executed sequentially, i.e., transaction Tx2 is executed after transaction Tx1.

[0062] Figure 4 This is a schematic diagram of a DAG (Directed Acyclic Graph) of multiple transactions in one embodiment. Circles represent nodes in the DAG, numbers within the circles represent transaction numbers, and arrows between nodes represent directed edges connecting them. After obtaining the DAG of multiple transactions, the transactions can be grouped according to the DAG, such that transactions in every two transaction groups are separate nodes in the DAG, meaning that no transaction in one group is connected to any transaction in another group.

[0063] like Figure 6 As shown, multiple transactions connected by arrows (i.e., transactions Tx1 to Tx8) are conflicting transactions and need to be grouped into a transaction group. When executing transactions Tx1 to Tx8, transactions (Tx3, Tx5) and (Tx1, Tx2, Tx4) can be executed in parallel first. Transactions Tx3 and Tx5 are executed sequentially, while transactions Tx1, Tx2, and Tx4 must be executed sequentially. Transaction Tx6 must wait for transactions Tx4 and Tx5 to complete before it can be executed, and transactions Tx7 and Tx8 must wait for transactions Tx5 and Tx6 to complete before they can be executed in parallel. Transactions Tx5 and Tx6 connect three or more nodes and can be called forks. When there are many forks in the DAG graph, subsequent transactions will have longer waiting times for these forks. Furthermore, the DAG algorithm requires a large state space. Therefore, the efficiency of the DAG grouping algorithm decreases when there are many conflicting transactions.

[0064] In another embodiment, multiple transactions can be grouped using a disjoint-set data structure (DAG). A DAG is a tree-like data structure used to handle merging and querying disjoint sets. A DAG typically includes two operations: find, to check if two elements are in the same set; and union, to merge two disjoint sets into one. This algorithm allows two transactions to be merged into the same set when their pre-execution read / write sets contain the same key, resulting in multiple sets where transactions in each set do not access the same key, thus enabling parallel processing of multiple sets. However, because the DAG algorithm does not consider whether a transaction accesses a key for reading or writing, it groups two transactions that access the same key together, potentially resulting in two transactions reading the same key being grouped together. Therefore, compared to the grouping results obtained by the DAG algorithm, the parallelism of the multiple transaction groups obtained by the DAG algorithm is lower.

[0065] Since the number of conflicting transactions in real-world business scenarios is uncertain, using only the DAG algorithm or disjoint-set data structure algorithm for transaction grouping may not be optimal. Therefore, a grouping algorithm can be adaptively determined based on the correlation between multiple transactions to improve efficiency during parallel transaction execution. Specifically, the pre-execution read-write set of the aforementioned transactions may involve contract parameters. In the M transaction groups of the first node, transactions involving contract parameters of different contracts can be assigned to different transaction groups. If the obtained pre-execution read-write set involves the contract parameters of the first contract, the transaction groups among the aforementioned M transaction groups that are unrelated to the obtained pre-execution read-write set can include transaction groups whose contained transactions do not involve the contract parameters of the first contract.

[0066] The world state maintained by the blockchain system corresponds to a state tree. The leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes. The contract account nodes record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes record the state values ​​of different contract parameters in the first contract. Updates to the contract account nodes and the multiple contract parameter nodes do not affect each other. The pre-execution read / write set of transactions involves contract parameters. Wherein:

[0067] In the M transaction groups, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups;

[0068] If the acquired pre-execution read-write set involves any contract parameter of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read-write set include: transaction groups whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

[0069] As mentioned earlier, accounts in the aforementioned blockchain system are typically divided into two types: user accounts / externally owned accounts and contract accounts. Contract accounts store the contract code and related state values ​​of smart contracts, and are generally only activated and accessed through external accounts. The design of external and contract accounts is essentially a mapping from account addresses to account states. Account states typically include, but are not limited to, fields such as Nonce, Balance, Storage_Root, and CodeHash. Nonce and Balance exist in both external and contract accounts, while CodeHash and Storage_Root are usually only valid for contract accounts. Among these fields, Nonce represents a counter; for external accounts, its value represents the number of transactions sent from the account address; for contract accounts, its value represents the number of smart contracts created by the account. The value of Balance represents the amount of digital resources owned by the corresponding external account. Storage_Root represents the hash of the root node of an MPT (Merkle Patricia Tree), which is used to organize the storage of contract account state variables. CodeHash represents the hash value of the contract code. For contract accounts, it is the code of the smart contract that has been hashed and stored. For external accounts, since it does not include the smart contract, it can be an empty string or a string of all zeros.

[0070] MPT is a tree structure that combines Merkle Tree and Patricia Tree (a more space-efficient Trie tree). Merkle Tree algorithms calculate a hash value for each transaction, then concatenate pairs and calculate the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a hexadecimal tree structure, often simply referred to as an MPT tree. The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs representing the storage content for each account in Ethereum. The "key" in the state trie can be a 160-bit identifier (such as an Ethereum account address), distributed across the storage from the root node to the leaf nodes. The "value" in the state trie is generated by encoding the Ethereum account information using Recursive-Length Prefix (RLP) encoding. As mentioned earlier, for external accounts, the values ​​can include Nonce and Balance; for contract accounts, the values ​​can include Nonce, Balance, CodeHash, and Storage_Root, etc.

[0071] In one embodiment, the world state maintained by the blockchain system corresponds to a state tree. The leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes. The contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are used to record the state values ​​of different contract parameters in the first contract. Updates to the contract account nodes and the multiple contract parameter nodes do not affect each other. The pre-execution read / write set of transactions involves contract parameters. Wherein:

[0072] In the M transaction groups, transactions involving different contracts or different contract parameters of the same contract can be divided into different transaction groups. Furthermore, if the acquired pre-execution read / write set involves any contract parameter of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read / write set include: transaction groups whose contained transactions do not involve the first contract or involve the first contract but not any of the contract parameters. Of course, the aforementioned first node also includes a storage process, so that the first computation process can send the state value of any contract parameter to the storage process, and the storage process updates the state value of the contract parameter node record corresponding to any contract parameter in the state tree based on the state value of the contract parameter.

[0073] The world state maintained by the blockchain system described in this solution corresponds to a state tree. The leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes. The contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are used to record the state values ​​of different contract parameters in the first contract. Furthermore, as mentioned earlier, updates to any two of the contract account nodes and contract parameter nodes in the state tree described in this solution are independent of each other; therefore, updates to the contract account node corresponding to the first node and the multiple contract parameter nodes are also independent of each other.

[0074] In one embodiment, the status value of any contract parameter can be recorded in the corresponding contract parameter node according to key-value pairs. The key of any contract parameter can be calculated using the contract information of the first contract and the parameter information of the first contract parameter. For example, the contract information of the first contract may include a contract address or a hash of the contract address. The parameter information of any contract parameter may include a parameter name, parameter number, or its hash. As shown in Figure 2, taking the contract address as the contract information and the parameter name as the parameter information as an example, for parameter A, the account address of account 2 (e.g., "0x00001234…123") and the parameter name of parameter A (e.g., "average order quantity") can be concatenated according to a preset rule to form a parameter identifier (e.g., "0x00001234…123_average order quantity"). Then, the hash value of this parameter identifier is calculated as the key value of parameter A. Of course, other methods can also be used to determine the key, and this embodiment does not limit this. This method allows the contract parameter nodes corresponding to various contract parameters in the same smart contract to be distributed more centrally in the state tree, which facilitates subsequent parameter lookup and state value updates.

[0075] Those skilled in the art will understand that in related technologies, for a single contract account in the state tree, its Storage_Root points to another storage tree of the same MPT form. This storage tree is used to store data of state variables involved in contract execution, and the value of Storage_Root is usually the hash value of the root node of the storage tree. However, since all contract parameters of the same smart contract are recorded in the storage tree corresponding to that contract, after executing a blockchain transaction and generating state data (including contract state data and world state data) for different contract parameters, it is necessary to first submit the contract state data to obtain the Storage_Root of the contract account, then update the Storage_Root of the relevant contract account in the state tree, and then submit the world state data to obtain the State_Root of the state tree. Obviously, in this way, the state values ​​of different contract parameters in the same smart contract need to be updated sequentially, and cannot be updated in parallel, which limits the update efficiency and block generation speed of the state tree. Therefore, the contract account node can choose not to record the value of the Storage_Root field to alleviate the above-mentioned limitations to a certain extent and improve the update efficiency and block generation speed of the state tree.

[0076] The aforementioned transaction packets can be obtained by the control process not only based on packet information from the first node, but also based on packet information from the second node in the blockchain system. This specification does not impose any limitations on this.

[0077] In one embodiment, the control process pre-executes the plurality of transactions and divides them into the M transaction groups based on the obtained pre-execution read-write sets. In another embodiment, the first node further includes a first consensus process; the control process can divide the plurality of transactions into the M transaction groups based on the pre-execution read-write sets of each of the plurality of transactions received by the first consensus process from the second node in the blockchain system. Based on this, the control process can obtain the M transaction groups obtained from the first consensus process. The specific implementation of the above acquisition can be found in the description of the foregoing embodiments, and will not be repeated here.

[0078] In the previous embodiment, the control process can determine the read-write set conflict relationship between the multiple transactions based on their respective pre-execution read-write sets, determine the pre- and post-dependency relationship of at least some of the multiple transactions based on the read-write set conflict relationship, and group the multiple transactions according to the pre- and post-dependency relationship to obtain the M transaction groups.

[0079] Step 304: If the control process determines that there are other blocks in the execution phase, it obtains the pre-execution read-write set of the transactions in the other blocks, and sends the transaction groups that are not related to the obtained pre-execution read-write set from the M transaction groups to different computing processes in the N processes respectively.

[0080] When the control process determines that other blocks are in the execution phase, it can obtain the pre-execution read / write set of transactions in those other blocks. By comparing the obtained pre-execution read / write set with the pre-execution read / write set of the target block, it can identify unrelated transaction groups in the target block and other blocks. These unrelated transaction groups are then sent to the computation process together to achieve parallel processing of a portion of transaction groups from the target block and other blocks, thereby improving the overall processing efficiency for transaction groups in both blocks. The following section combines... Figure 6 To explain this situation, such as Figure 6 As shown, assuming the first node contains contracts a{k1,k2,k3,k4,k5,k6}, b{k1,k2,k4,k5}, and c{k4,k5} (with the contract parameters corresponding to each contract in parentheses), taking transaction groups 0, 1, and 2 in block i and transaction groups 0, 1, and 2 in block j as examples, since the pre-execution read set of transactions in transaction groups 0 and 1 of block j does not involve the pre-execution write set of transactions in any transaction group in block i, but the pre-execution read set of transactions in transaction group 2 of block j is a.k1 (i.e., contract parameter k1 of contract a), then the two transaction groups of block j (i.e., transaction groups 0 and 1) can be regarded as unrelated to the pre-execution read and write sets of block i. At this time, transaction groups 0, 1, and 2 of block i and transaction groups 0 and 1 of block j can be sent to different computing processes in the N processes respectively to achieve parallel processing of the transaction groups in the two blocks.

[0081] Of course, similar methods can be used when sending the above transaction packets. Figure 5 The caching mechanism handles the caching process by pre-setting a parallel processing threshold or parallel processing cycle. This ensures that irrelevant transaction packets are only sent when the number of transaction packets that can be processed in parallel exceeds the threshold or when the earliest determined parallel processing transaction packet is more than the parallel processing cycle. This avoids resource waste caused by frequent sending of transaction packets. Alternatively, the number of transactions for each consensus can be set as early as the consensus phase of the transaction packets to increase the number of transactions in each transaction packet, thereby achieving a similar technical effect to the aforementioned parallel processing threshold or parallel processing cycle.

[0082] For example, when M ≤ N, the control process can send the M transaction packets to M computing processes, where each computing process receives one transaction packet. When M > N, the control process can send the M transaction packets evenly to N computing processes, where the difference in the number of transaction packets received by any two computing processes is no greater than 1. This method ensures that the number of transaction packets received by each computing process is as close as possible, thereby improving the overall execution efficiency of the M transaction packets. Alternatively, the N control processes can compete to obtain the M transaction packets. Each computing process can continue to compete for the next transaction packet after executing all transactions within any given transaction packet, until all M transaction packets have been distributed. In this method, the number of transaction packets obtained by each control process is related to its own transaction execution capacity, thus achieving load balancing among the multiple computing processes to some extent.

[0083] Step 306: When the first computing process receives any of the M transaction packets, it executes each transaction in the received transaction packet.

[0084] When the first computing process receives a transaction packet sent by the control process, it can perform corresponding execution operations on the transactions in the transaction packet. The first computing process can execute the transactions in multiple received transaction packets concurrently through multiple threads, thereby further improving the execution efficiency of the transactions.

[0085] In one embodiment, the blockchain system further includes a second node, which comprises a pre-execution process and a caching process. The caching process stores state data in its memory. The caching process sends the plurality of transactions to the pre-execution process, which is received by the first node and stored in the memory of the caching process. The pre-execution process pre-executes the plurality of transactions and generates a pre-execution read-write set for the plurality of transactions. Specifically, when reading the state value of a first contract parameter during the pre-execution of any of the plurality of transactions, if the state value of the first contract parameter is stored in the memory of the caching process, the pre-execution read-write set for that transaction is generated based on the state value.

[0086] In one embodiment, the caching process is further configured to store a pre-execution read-write set and a pre-execution order of the plurality of transactions in the memory of the caching process, and update the state data stored in the memory based on the pre-execution read-write set of the plurality of transactions.

[0087] 22. The blockchain system according to claim 21, wherein the second node further comprises a second consensus process.

[0088] The caching process is also used to send the pre-execution read-write set and pre-execution order of the multiple transactions to the second consensus process;

[0089] The second consensus process is used to generate a consensus proposal and send the consensus proposal to the first consensus process in the first node. The consensus proposal includes a pre-execution read-write set of the multiple transactions and their consensus order, wherein the consensus order is the pre-execution order.

[0090] Figure 7 This is a flowchart illustrating a method for executing a transaction, as provided in an exemplary embodiment. Figure 7 As shown, this method is applied to the first node in a blockchain system. The first node can be the node that initiates the consensus proposal (such as the master node), or it can be another blockchain node (such as a slave node). The first node can include a control process and N computation processes. The method includes the following steps.

[0091] S702, the control process determines multiple blocks and obtains the transaction group corresponding to each block. The transaction group is obtained by grouping the multiple transactions based on the pre-execution read / write set of each transaction in the corresponding block.

[0092] As mentioned earlier, the pre-execution read / write set of a transaction involves contract parameters; among which:

[0093] Within each block's transaction group, transactions involving contract parameters of different contracts are divided into different transaction groups;

[0094] In the case where the pre-execution read-write set obtained in any block involves the contract parameters of the first contract, the transaction groups in the transaction group set below include: transaction groups corresponding to other blocks besides the aforementioned block, and whose contained transactions do not involve the contract parameters of the first contract.

[0095] As mentioned above, the world state maintained by the blockchain system corresponds to a state tree. The leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes. The contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are used to record the state values ​​of different contract parameters in the first contract. Updates to the contract account nodes and the multiple contract parameter nodes do not affect each other. The pre-execution read / write set of transactions involves contract parameters; wherein:

[0096] Within any block's transaction group, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups;

[0097] If the pre-execution read / write set obtained involves any contract parameter of the first contract, the transaction groups in the transaction group set include: transaction groups that correspond to other blocks besides the first block, and whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

[0098] As mentioned above, the first computing process sends the status value of any of the contract parameters to the storage process;

[0099] The storage process updates the state value of the contract parameter node record corresponding to any contract parameter in the state tree based on the state value of any contract parameter.

[0100] As mentioned above, the state value of any contract parameter is recorded in the corresponding contract parameter node according to key-value pairs, wherein the key of any contract parameter is calculated by the contract information of the first contract and the parameter information of any contract parameter.

[0101] As mentioned earlier, the contract account node does not record the value of the Storage_Root field.

[0102] S704, the control process generates a set of transaction packets, wherein the transaction packets in the set are from at least two of the plurality of blocks, and each transaction packet is independent of the pre-execution read / write set corresponding to other transaction packets in the set; and the transaction packets in the set are sent to different computing processes in the N processes respectively; N is a positive integer.

[0103] As previously stated, the control process obtains the aforementioned transaction packet set based on packet information from a second node in the blockchain system.

[0104] As previously stated, the control process acquires the transaction group set by: pre-executing the plurality of transactions and dividing the plurality of transactions into the aforementioned transaction group set based on the obtained pre-execution read / write set; or,

[0105] The first node further includes a first consensus process; the control process generates a transaction group set, including: the control process divides the multiple transactions into the aforementioned transaction group set according to the pre-execution read-write sets of the multiple transactions received by the first consensus process from the second node in the blockchain system.

[0106] As mentioned above, dividing the multiple transactions into the aforementioned transaction group set includes:

[0107] The control process determines the read-write set conflict relationship between the multiple transactions based on their respective pre-execution read-write sets, determines the pre- and post-dependent relationships of at least some of the multiple transactions based on the read-write set conflict relationship, and groups the multiple transactions according to the pre- and post-dependent relationships to obtain the above-mentioned transaction group set.

[0108] S706, the first computing process executes each transaction in the received transaction packet upon receiving any transaction packet.

[0109] As mentioned above, the first computing process concurrently executes transactions from multiple received transaction groups using multiple threads.

[0110] Figure 8 This is a schematic diagram illustrating the structure of a first node in a blockchain system, provided as an exemplary embodiment. For example... Figure 8 As shown, the first node includes a control process 82 and N computing processes 84. The control process 82 is used to obtain M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the target block, where M and N are positive integers. The control process 82 is also used to obtain the pre-execution read / write sets of transactions in other blocks when it is determined that there are other blocks in the execution phase, and send the transaction groups in the M transaction groups that are not related to the obtained pre-execution read / write sets to different computing processes in the N processes respectively. The first computing process in the computing process 84 is used to execute each transaction in the received transaction group when it receives any of the M transaction groups.

[0111] Optionally, the pre-execution read / write set of the transaction involves contract parameters; wherein:

[0112] Within the M transaction groups, transactions involving contract parameters of different contracts are divided into different transaction groups;

[0113] In the case where the acquired pre-execution read-write set involves the contract parameters of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read-write set include: transaction groups whose transactions do not involve the contract parameters of the first contract.

[0114] Optionally, the world state maintained by the blockchain system corresponds to a state tree. The leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes. The contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are used to record the state values ​​of different contract parameters in the first contract. Updates to the contract account nodes and the multiple contract parameter nodes do not affect each other. The pre-execution read / write set of transactions involves contract parameters. Wherein:

[0115] Among the M transaction groups, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups;

[0116] If the acquired pre-execution read-write set involves any contract parameter of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read-write set include: transaction groups whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

[0117] Optionally, the first node may also include a storage process 88;

[0118] The first computing process is also used to send the status value of any of the contract parameters to the storage process 88;

[0119] The storage process 88 is used to update the state value of the contract parameter node record corresponding to the contract parameter in the state tree based on the state value of the contract parameter.

[0120] Optionally, the state value of any contract parameter is recorded in the corresponding contract parameter node according to key-value pairs, wherein the key of any contract parameter is calculated using the contract information of the first contract and the parameter information of any contract parameter.

[0121] Optionally, the contract account node does not record the value of the Storage_Root field.

[0122] Optionally, the control process 82 is further configured to obtain M transaction packets based on packet information from a second node in the blockchain system.

[0123] Optionally, the control process 82 is further configured to pre-execute the plurality of transactions and divide the plurality of transactions into the M transaction groups according to the obtained pre-execution read / write set; or,

[0124] The first node further includes a first consensus process 86; the control process 82 is further configured to divide the plurality of transactions into the M transaction groups based on the pre-execution read-write sets of the plurality of transactions received from the second node in the blockchain system by the first consensus process 86.

[0125] Optionally, the control process 82 is further configured to determine the read-write set conflict relationship between the plurality of transactions based on their respective pre-execution read-write sets, determine the pre- and post-dependency relationship of at least some of the plurality of transactions based on the read-write set conflict relationship, and group the plurality of transactions according to the pre- and post-dependency relationship to obtain the M transaction groups.

[0126] Optionally, the first computing process is also used to concurrently execute transactions in multiple received transaction packets via multiple threads.

[0127] The specific implementation of the transaction distribution process of the first node can be found in the description of the foregoing embodiments, and will not be repeated here.

[0128] Based on the same concept as the foregoing method embodiments, this specification also provides a blockchain system, which includes a first node, comprising a control process and N computing processes, wherein:

[0129] The control process is used to obtain M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the target block, where M and N are positive integers;

[0130] The control process is used to, when it is determined that there are other blocks in the execution phase, obtain the pre-execution read-write set of transactions in the other blocks, and send the transaction groups that are not related to the obtained pre-execution read-write set from the M transaction groups to different computing processes in the N processes respectively.

[0131] The first computing process is used to execute each transaction in the received transaction packet when any of the M transaction packets is received.

[0132] Optionally, the pre-execution read / write set of the transaction involves contract parameters; where:

[0133] Within the M transaction groups, transactions involving contract parameters of different contracts are divided into different transaction groups;

[0134] In the case where the acquired pre-execution read-write set involves the contract parameters of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read-write set include: transaction groups whose transactions do not involve the contract parameters of the first contract.

[0135] Optionally, the world state maintained by the blockchain system corresponds to a state tree. The leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes. The contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are used to record the state values ​​of different contract parameters in the first contract. Updates to the contract account nodes and the multiple contract parameter nodes do not affect each other. The pre-execution read / write set of transactions involves contract parameters. Wherein:

[0136] Among the M transaction groups, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups;

[0137] If the acquired pre-execution read-write set involves any contract parameter of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read-write set include: transaction groups whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

[0138] Optionally, the first computing process sends the status value of any of the contract parameters to the storage process;

[0139] The storage process is used to update the state value of the contract parameter node record corresponding to any contract parameter in the state tree based on the state value of any contract parameter.

[0140] Optionally, the state value of any contract parameter is recorded in the corresponding contract parameter node according to key-value pairs, wherein the key of any contract parameter is calculated using the contract information of the first contract and the parameter information of any contract parameter.

[0141] Optionally, the contract account node does not record the value of the Storage_Root field.

[0142] Optionally, the control process is used to obtain M transaction packets based on packet information from a second node in the blockchain system.

[0143] Optionally, the control process is further configured to pre-execute the plurality of transactions and divide the plurality of transactions into the M transaction groups based on the obtained pre-execution read / write set; or,

[0144] The first node further includes a first consensus process; the control process is further configured to divide the plurality of transactions into the M transaction groups based on the pre-execution read-write sets of the plurality of transactions received from the second node in the blockchain system by the first consensus process.

[0145] Optionally, the control process is further configured to determine read-write set conflict relationships between the plurality of transactions based on their respective pre-execution read-write sets, determine the pre- and post-dependency relationships of at least some of the plurality of transactions based on the read-write set conflict relationships, and group the plurality of transactions according to the pre- and post-dependency relationships to obtain the M transaction groups.

[0146] Optionally, the first computing process is also used to concurrently execute transactions in multiple received transaction packets via multiple threads.

[0147] Still with Figure 8For example, the first node includes a control process 82 and N computing processes 84. The control process 82 is used to determine multiple blocks and obtain the transaction groups corresponding to each block. The transaction groups are obtained by grouping the multiple transactions based on the pre-execution read-write sets of the multiple transactions in the corresponding block. The control process 82 is also used to generate a transaction group set, in which the transaction groups in the transaction group set come from at least two blocks among the multiple blocks, and each transaction group is independent of the pre-execution read-write sets corresponding to other transaction groups in the transaction group set. The control process 82 also sends the transaction groups in the transaction group set to different computing processes among the N processes, where N is a positive integer. The first computing process in the computing process 84 is used to execute each transaction in the received transaction group when any transaction group is received.

[0148] Optionally, the pre-execution read / write set of the transaction involves contract parameters; where:

[0149] Within each block's transaction group, transactions involving contract parameters of different contracts are divided into different transaction groups;

[0150] In the case where the pre-execution read-write set obtained in any block involves the contract parameters of the first contract, the transaction groups in the transaction group set below include: transaction groups corresponding to other blocks besides the aforementioned block, and whose contained transactions do not involve the contract parameters of the first contract.

[0151] Optionally, the world state maintained by the blockchain system corresponds to a state tree. The leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes. The contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are used to record the state values ​​of different contract parameters in the first contract. Updates to the contract account nodes and the multiple contract parameter nodes do not affect each other. The pre-execution read / write set of transactions involves contract parameters. Wherein:

[0152] Within any block's transaction group, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups;

[0153] If the pre-execution read / write set obtained involves any contract parameter of the first contract, the transaction groups in the transaction group set include: transaction groups that correspond to other blocks besides the first block, and whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

[0154] Optionally, the first computing process sends the status value of any of the contract parameters to the storage process;

[0155] The storage process updates the state value of the contract parameter node record corresponding to any contract parameter in the state tree based on the state value of any contract parameter.

[0156] Optionally, the state value of any contract parameter is recorded in the corresponding contract parameter node according to key-value pairs, wherein the key of any contract parameter is calculated using the contract information of the first contract and the parameter information of any contract parameter.

[0157] Optionally, the contract account node does not record the value of the Storage_Root field.

[0158] Optionally, the control process obtains the aforementioned transaction packet set based on packet information from a second node in the blockchain system.

[0159] Optionally, the control process obtains the transaction group set by: pre-executing the plurality of transactions and dividing the plurality of transactions into the aforementioned transaction group set according to the obtained pre-execution read / write set; or,

[0160] The first node further includes a first consensus process; the control process generates a transaction group set, including: the control process divides the multiple transactions into the aforementioned transaction group set according to the pre-execution read-write sets of the multiple transactions received by the first consensus process from the second node in the blockchain system.

[0161] Optionally, dividing the plurality of transactions into the aforementioned transaction group set includes:

[0162] The control process determines the read-write set conflict relationship between the multiple transactions based on their respective pre-execution read-write sets, determines the pre- and post-dependent relationships of at least some of the multiple transactions based on the read-write set conflict relationship, and groups the multiple transactions according to the pre- and post-dependent relationships to obtain the above-mentioned transaction group set.

[0163] Optionally, the first computing process concurrently executes transactions in multiple received transaction packets using multiple threads.

[0164] The specific implementation of the transaction distribution process of the first node can be found in the description of the foregoing embodiments, and will not be repeated here.

[0165] Based on the same concept as the aforementioned method embodiments, this specification also provides another blockchain system, which includes a first node, comprising a control process and N computing processes, wherein:

[0166] The control process determines multiple blocks and obtains the transaction group corresponding to each block. The transaction group is obtained by grouping the multiple transactions based on their respective pre-execution read / write sets in the corresponding block.

[0167] The control process generates a set of transaction packets, wherein the transaction packets in the set are from at least two of the plurality of blocks, and each transaction packet is independent of the pre-execution read / write set corresponding to other transaction packets in the set; and sends the transaction packets in the set to different computing processes in the N processes respectively; N is a positive integer;

[0168] Upon receiving any transaction packet, the first computing process executes each transaction within the received transaction packet.

[0169] Optionally, the pre-execution read / write set of the transaction involves contract parameters; where:

[0170] Within each block's transaction group, transactions involving contract parameters of different contracts are divided into different transaction groups;

[0171] In the case where the pre-execution read-write set obtained in any block involves the contract parameters of the first contract, the transaction groups in the transaction group set below include: transaction groups corresponding to other blocks besides the aforementioned block, and whose contained transactions do not involve the contract parameters of the first contract.

[0172] Optionally, the world state maintained by the blockchain system corresponds to a state tree. The leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes. The contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are used to record the state values ​​of different contract parameters in the first contract. Updates to the contract account nodes and the multiple contract parameter nodes do not affect each other. The pre-execution read / write set of transactions involves contract parameters. Wherein:

[0173] Within any block's transaction group, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups;

[0174] If the pre-execution read / write set obtained involves any contract parameter of the first contract, the transaction groups in the transaction group set include: transaction groups that correspond to other blocks besides the first block, and whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

[0175] Optionally, the first computing process sends the status value of any of the contract parameters to the storage process;

[0176] The storage process updates the state value of the contract parameter node record corresponding to any contract parameter in the state tree based on the state value of any contract parameter.

[0177] Optionally, the state value of any contract parameter is recorded in the corresponding contract parameter node according to key-value pairs, wherein the key of any contract parameter is calculated using the contract information of the first contract and the parameter information of any contract parameter.

[0178] Optionally, the contract account node does not record the value of the Storage_Root field.

[0179] Optionally, the control process obtains the aforementioned transaction packet set based on packet information from a second node in the blockchain system.

[0180] Optionally, the control process obtains the transaction group set by: pre-executing the plurality of transactions and dividing the plurality of transactions into the aforementioned transaction group set according to the obtained pre-execution read / write set; or,

[0181] The first node further includes a first consensus process; the control process generates a transaction group set, including: the control process divides the multiple transactions into the aforementioned transaction group set according to the pre-execution read-write sets of the multiple transactions received by the first consensus process from the second node in the blockchain system.

[0182] Optionally, dividing the plurality of transactions into the aforementioned transaction group set includes:

[0183] The control process determines the read-write set conflict relationship between the multiple transactions based on their respective pre-execution read-write sets, determines the pre- and post-dependent relationships of at least some of the multiple transactions based on the read-write set conflict relationship, and groups the multiple transactions according to the pre- and post-dependent relationships to obtain the above-mentioned transaction group set.

[0184] Optionally, the first computing process concurrently executes transactions in multiple received transaction packets using multiple threads.

[0185] Figure 9 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. Please refer to... Figure 9At the hardware level, the device includes a processor 902, an internal bus 904, a network interface 906, memory 908, and non-volatile memory 910, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 902 reading the corresponding computer program from the non-volatile memory 910 into memory 908 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0186] 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 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 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.

[0187] 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.

[0188] 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 invention 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.

[0189] 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 the 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.

[0190] 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.

[0191] 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... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0192] 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.

[0193] 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.

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

[0195] 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.

[0196] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, 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 magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible 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.

[0197] 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.

[0198] 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 a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0199] 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.

[0200] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification 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 execution method, applied to a first node in a blockchain system, the first node comprising a control process and N computation processes, the method comprising: The control process acquires M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read-write sets in the target block. M and N are positive integers, and the pre-execution read-write sets of the transactions involve contract parameters. When the control process determines that other blocks are in the execution phase, it obtains the pre-execution read-write set of transactions in those other blocks and sends transaction groups from the M transaction groups that are unrelated to the obtained pre-execution read-write set to different computing processes in the N computing processes, so that the transaction groups sent in the target block are processed in parallel with a portion of the transaction groups in the other blocks; wherein: in the M transaction groups, transactions involving contract parameters of different contracts are divided into different transaction groups; when the obtained pre-execution read-write set involves contract parameters of the first contract, the transaction groups from the M transaction groups that are unrelated to the obtained pre-execution read-write set include: transaction groups whose contained transactions do not involve contract parameters of the first contract; Upon receiving any of the M transaction packets, the first computing process executes each transaction within the received transaction packet.

2. The method according to claim 1, wherein the world state maintained by the blockchain system corresponds to a state tree, the leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes, the contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are respectively used to record the state values ​​of different contract parameters in the first contract, and the updates of the contract account nodes and the multiple contract parameter nodes do not affect each other; the pre-execution read-write set of the transaction involves contract parameters; wherein: In the M transaction groups, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups; If the acquired pre-execution read-write set involves any contract parameter of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read-write set include: transaction groups whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

3. The method according to claim 2, wherein the first node further comprises a storage process; the method further comprises... The first computing process sends the status value of any of the contract parameters to the storage process; The storage process updates the state value of the contract parameter node record corresponding to any contract parameter in the state tree based on the state value of any contract parameter.

4. The method according to claim 2, wherein the state value of any contract parameter is recorded in the corresponding contract parameter node according to key-value pairs, wherein, The Key of any contract parameter is calculated using the contract information of the first contract and the parameter information of any contract parameter.

5. According to the method described in claim 2, the contract account node does not record the value of the Storage_Root field.

6. The method according to claim 1, wherein the control process acquires M transaction packets, comprising: The control process obtains M transaction packets based on packet information from a second node in the blockchain system.

7. The method according to claim 1, The control process acquires M transaction packets, including: The control process pre-executes the multiple transactions and divides the multiple transactions into the M transaction groups based on the obtained pre-execution read / write set; or, The first node also includes the first consensus process; The control process acquires M transaction groups, including: the control process divides the multiple transactions into the M transaction groups based on the pre-execution read / write sets of each of the multiple transactions received from the second node in the blockchain system by the first consensus process.

8. The method according to claim 7, wherein dividing the plurality of transactions into the M transaction groups comprises: The control process determines the read-write set conflict relationship between the multiple transactions based on their respective pre-execution read-write sets, determines the pre- and post-dependency relationship of at least some of the multiple transactions based on the read-write set conflict relationship, and groups the multiple transactions according to the pre- and post-dependency relationship to obtain the M transaction groups.

9. The method according to claim 1, further comprising: The first computing process executes transactions from multiple received transaction groups concurrently through multiple threads.

10. A method for executing a transaction, applied to a first node in a blockchain system, the first node comprising a control process and N computational processes, the method comprising: The control process determines multiple blocks and obtains the transaction group corresponding to each block. The transaction group is obtained by grouping the multiple transactions based on their respective pre-execution read-write sets in the corresponding block. The pre-execution read-write set of the transaction involves contract parameters. The control process generates a set of transaction packets, which contains transaction packets from at least two of the plurality of blocks, and each transaction packet is independent of the pre-execution read / write set corresponding to other transaction packets in the set. Furthermore, the transaction packets in the transaction packet set are sent to different computing processes in the N computing processes, so that transaction packets from different blocks are executed in parallel by the N computing processes; N is a positive integer; Upon receiving any transaction packet, the first computing process executes each transaction within the received transaction packet; Specifically: In the transaction group corresponding to each block, transactions involving contract parameters of different contracts are divided into different transaction groups; when the obtained pre-execution read-write set involves the contract parameters of the first contract, the transaction groups in the transaction group set that are unrelated to the obtained pre-execution read-write set include: transaction groups whose contained transactions do not involve the contract parameters of the first contract.

11. A first node in a blockchain system, the first node comprising a control process and N computation processes, wherein: The control process is used to obtain M transaction groups. The M transaction groups are obtained by grouping the multiple transactions based on their respective pre-execution read-write sets in the target block. M and N are positive integers, and the pre-execution read-write sets of the transactions involve contract parameters. The control process is used to, when it is determined that there are other blocks in the execution phase, obtain the pre-execution read-write set of transactions in the other blocks, and send the transaction groups from the M transaction groups that are not related to the obtained pre-execution read-write set to different computing processes in the N computing processes, so that the transaction groups sent in the target block are processed in parallel with a portion of the transaction groups in the other blocks; wherein: in the M transaction groups, transactions involving contract parameters of different contracts are divided into different transaction groups; when the obtained pre-execution read-write set involves the contract parameters of the first contract, the transaction groups from the M transaction groups that are not related to the obtained pre-execution read-write set include: transaction groups whose contained transactions do not involve the contract parameters of the first contract; The first computing process is used to execute each transaction in the received transaction packet when any of the M transaction packets is received.

12. The first node according to claim 11, the first computing process is further configured to: Transactions in multiple received transaction groups are executed concurrently by multiple threads.

13. The first node according to claim 11, wherein the world state maintained by the blockchain system corresponds to a state tree, the leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes, the contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are respectively used to record the state values ​​of different contract parameters in the first contract, and the updates of the contract account nodes and the multiple contract parameter nodes do not affect each other; the pre-execution read-write set of the transaction involves contract parameters; wherein: In the M transaction groups, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups; If the acquired pre-execution read-write set involves any contract parameter of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read-write set include: transaction groups whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

14. The first node according to claim 13, wherein the first node further comprises a storage process. The first computing process is also used to send the status value of any of the contract parameters to the storage process; The storage process is used to update the state value of the contract parameter node record corresponding to any contract parameter in the state tree based on the state value of any contract parameter.

15. A first node in a blockchain system, the first node comprising a control process and N computation processes, wherein: The control process determines multiple blocks and obtains the transaction group corresponding to each block. The transaction group is obtained by grouping the multiple transactions based on their respective pre-execution read-write sets in the corresponding block. The pre-execution read-write set of the transaction involves contract parameters. The control process generates a set of transaction packets, which contains transaction packets from at least two of the plurality of blocks, and each transaction packet is independent of the pre-execution read / write set corresponding to other transaction packets in the set. Furthermore, the transaction packets in the transaction packet set are sent to different computing processes in the N computing processes, so that transaction packets from different blocks are executed in parallel by the N computing processes; N is a positive integer; Upon receiving any transaction packet, the first computing process executes each transaction within the received transaction packet; Specifically: In the transaction group corresponding to each block, transactions involving contract parameters of different contracts are divided into different transaction groups; when the obtained pre-execution read-write set involves the contract parameters of the first contract, the transaction groups in the transaction group set that are unrelated to the obtained pre-execution read-write set include: transaction groups whose contained transactions do not involve the contract parameters of the first contract.

16. A blockchain system, comprising a first node, wherein the first node includes a control process and N computing processes, wherein: The control process is used to obtain M transaction groups. The M transaction groups are obtained by grouping the multiple transactions based on their respective pre-execution read-write sets in the target block. M and N are positive integers, and the pre-execution read-write sets of the transactions involve contract parameters. The control process is used to, when it is determined that there are other blocks in the execution phase, obtain the pre-execution read-write set of transactions in the other blocks, and send the transaction groups from the M transaction groups that are not related to the obtained pre-execution read-write set to different computing processes in the N computing processes, so that the transaction groups sent in the target block are processed in parallel with a portion of the transaction groups in the other blocks; wherein: in the M transaction groups, transactions involving contract parameters of different contracts are divided into different transaction groups; when the obtained pre-execution read-write set involves the contract parameters of the first contract, the transaction groups from the M transaction groups that are not related to the obtained pre-execution read-write set include: transaction groups whose contained transactions do not involve the contract parameters of the first contract; The first computing process is used to execute each transaction in the received transaction packet when any of the M transaction packets is received.

17. The blockchain system according to claim 16, wherein the world state maintained by the blockchain system corresponds to a state tree, the leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes, the contract account nodes are used to record the contract account of the first contract deployed in the blockchain system, and the multiple contract parameter nodes are respectively used to record the state values ​​of different contract parameters in the first contract, and the updates of the contract account nodes and the multiple contract parameter nodes do not affect each other; the pre-execution read-write set of transactions involves contract parameters; wherein: In the M transaction groups, transactions involving different contracts or different contract parameters of the same contract are divided into different transaction groups; If the acquired pre-execution read-write set involves any contract parameter of the first contract, the transaction groups among the M transaction groups that are unrelated to the acquired pre-execution read-write set include: transaction groups whose transactions do not involve the first contract or involve the first contract but do not involve any of the contract parameters.

18. In the blockchain system according to claim 17, the state value of any contract parameter is recorded in the corresponding contract parameter node according to key-value pairs, wherein, The Key of any contract parameter is calculated using the contract information of the first contract and the parameter information of any contract parameter.

19. The blockchain system according to claim 17, The control process acquires M transaction packets, including: The control process pre-executes the multiple transactions and divides the multiple transactions into the M transaction groups based on the obtained pre-execution read / write set; or, The first node also includes the first consensus process; The control process acquires M transaction groups, including: the control process divides the multiple transactions into the M transaction groups based on the pre-execution read / write sets of each of the multiple transactions received from the second node in the blockchain system by the first consensus process.

20. The blockchain system according to claim 17, further comprising a second node, the second node including a pre-execution process and a caching process, wherein the caching process stores state data in its memory; wherein, The caching process is used to send the multiple transactions to the pre-execution process, and the multiple transactions are received by the first node and stored in the memory of the caching process; The pre-execution process is used to pre-execute the multiple transactions and generate a pre-execution read-write set for the multiple transactions. Specifically, when the state value of the first contract parameter needs to be read during the pre-execution of any of the multiple transactions, if the state value of the first contract parameter is stored in the memory of the cache process, the process receives the state value from the cache process and generates a pre-execution read-write set for any of the transactions based on the state value. The caching process is also used to store the pre-execution read-write set and the pre-execution order of the multiple transactions in the memory of the caching process, and to update the state data stored in the memory based on the pre-execution read-write set of the multiple transactions.

21. The blockchain system according to claim 20, wherein the second node further comprises a second consensus process. The caching process is also used to send the pre-execution read-write set and pre-execution order of the multiple transactions to the second consensus process; The second consensus process is used to generate a consensus proposal and send the consensus proposal to the first consensus process in the first node. The consensus proposal includes a pre-execution read-write set of the multiple transactions and their consensus order, wherein the consensus order is the pre-execution order.

22. A blockchain system, comprising a first node, wherein the first node includes a control process and N computing processes, wherein: The control process determines multiple blocks and obtains the transaction group corresponding to each block. The transaction group is obtained by grouping the multiple transactions based on their respective pre-execution read-write sets in the corresponding block. The pre-execution read-write set of the transaction involves contract parameters. The control process generates a set of transaction packets, which contains transaction packets from at least two of the plurality of blocks, and each transaction packet is independent of the pre-execution read / write set corresponding to other transaction packets in the set. Furthermore, the transaction packets in the transaction packet set are sent to different computing processes in the N computing processes, so that transaction packets from different blocks are executed in parallel by the N computing processes; N is a positive integer; Upon receiving any transaction packet, the first computing process executes each transaction within the received transaction packet; Specifically: In the transaction group corresponding to each block, transactions involving contract parameters of different contracts are divided into different transaction groups; when the obtained pre-execution read-write set involves the contract parameters of the first contract, the transaction groups in the transaction group set that are unrelated to the obtained pre-execution read-write set include: transaction groups whose contained transactions do not involve the contract parameters of the first contract.

23. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-10 by executing the executable instructions.

24. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-10.

Images