Method, node and blockchain system for submitting state data

Abstract

A state data submission method, node and blockchain system. The method is applied to a first node in a blockchain system. Leaf nodes of a state tree of a world state include a contract account node and a plurality of contract parameter nodes. The plurality of contract parameter nodes are used to record state values of different contract parameters in a first contract respectively. The contract account node is not affected by updates of the plurality of contract parameter nodes. The first node includes a control process and N computing processes. The method includes: the control process obtaining M transaction groups by grouping a plurality of transactions based on respective pre-execution read-write sets of the plurality of transactions; sending transaction groups involving different contract parameters of the first contract to different computing processes respectively; and a first computing process executing each transaction in the received transaction group involving any contract parameter, and submitting an obtained state value of the any contract parameter to update a contract parameter node corresponding to the any contract parameter.

Description

Technical Field

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

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked 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] The purpose of this invention is to provide a method for submitting state data, a node, and a blockchain system.

[0004] Firstly, a method for submitting state data is provided, applied to the first node in a blockchain system. 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 of the contract account nodes and the multiple contract parameter nodes do not affect each other. The first node includes a control process and N computation processes. The method includes:

[0005] The control process acquires M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read-write sets. M and N are both positive integers, and the pre-execution read-write sets involve several contract parameters.

[0006] The control process sends the transaction groups involving different contract parameters of the first contract in the M transaction groups to different computing processes in the N processes respectively;

[0007] Upon receiving a transaction group involving any contract parameter in the first contract, the first computing process executes each transaction in the received transaction group, obtains the status value of the any contract parameter, and submits it to update the status value of the any contract parameter recorded in the corresponding contract parameter node in the state tree.

[0008] Secondly, a first node is provided in a blockchain system. 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 first node includes a control process and N computation processes, wherein:

[0009] 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. M and N are both positive integers, and the pre-execution read-write sets involve several contract parameters.

[0010] The control process is used to send the transaction groups involving different contract parameters of the first contract in the M transaction groups to different computing processes in the N processes respectively;

[0011] The first computing process is used to execute each transaction in the received transaction group when it receives a transaction group involving any contract parameter in the first contract, obtain the status value of the any contract parameter and submit it, so as to update the status value of the any contract parameter recorded in the contract parameter node corresponding to the any contract parameter in the status tree.

[0012] Thirdly, a blockchain system is provided, wherein the world state maintained by the blockchain system corresponds to a state tree, and 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 a 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, and the updates of the contract account nodes and the multiple contract parameter nodes do not affect each other; the blockchain system includes a first node and a second node, wherein the first node contains a control process and N computation processes, wherein:

[0013] The second node is used to send pre-execution read-write sets of multiple transactions to the first node, and the pre-execution read-write sets involve several contract parameters.

[0014] The first node is used to obtain M transaction groups through the control process. The M transaction groups are obtained by grouping the multiple transactions based on their respective pre-execution read-write sets, where M and N are both positive integers, and the pre-execution read-write sets involve several contract parameters. The control process sends the transaction groups involving different contract parameters of the first contract among the M transaction groups to different computing nodes in the N processes. When the first computing process receives a transaction group involving any contract parameter of the first contract, it executes each transaction in the received transaction group, obtains the status value of the any contract parameter, and submits it to update the status value of the any contract parameter recorded in the corresponding contract parameter node in the status tree.

[0015] According to a fourth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0016] processor;

[0017] Memory used to store processor-executable instructions;

[0018] The processor implements the method as described in any one of the first aspects by executing the executable instructions.

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

[0020] Through the above embodiments, the state values ​​of different contract parameters in the first smart contract are recorded separately by different contract parameter nodes in the state tree. Furthermore, the updates of the contract account node corresponding to the first contract and the contract parameter nodes corresponding to each of its various contract parameters are independent of each other, thus allowing the state values ​​of different contract parameters within the same contract to be updated separately without affecting each other. Based on this, transactions in transaction groups involving different contract parameters in the first contract are executed by different computing processes. This not only allows multiple transactions calling the same smart contract to be executed concurrently by different computing processes, thereby improving transaction execution efficiency, but also ensures that the execution processes of different transactions calling the same first contract are independent of each other. The two execution processes do not generate state data for the same contract parameters, allowing multiple computing processes to submit state values ​​for different contract parameters within the same contract in parallel, which helps to accelerate the generation speed of blocks containing multiple transactions calling the same contract. Attached Figure Description

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

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

[0023] Figure 2 This is a schematic diagram of a storage structure for blockchain data provided in an exemplary embodiment.

[0024] Figure 3 This is a schematic diagram of the structure of any two nodes in a blockchain system provided as an exemplary embodiment.

[0025] Figure 4 This is a flowchart of a method for submitting status data provided in an exemplary embodiment.

[0026] Figure 5 This is a schematic diagram of the structure of the first node in a blockchain system provided in an exemplary embodiment.

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

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

[0029] 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 from 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) in the distributed blockchain network. 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.

[0030] Accounts in a blockchain system are typically categorized 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 can usually only be activated and accessed through external accounts. The design of external and contract accounts essentially maps 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 Balance value 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.

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

[0032] A contract account is used to store the state of a smart contract. Once a smart contract is deployed in a blockchain system, a corresponding contract account is assigned to it. This contract account typically has several states, defined by state variables within the smart contract and updated with new values ​​during the contract's creation and execution. The smart contracts described in this specification generally refer to contracts defined digitally in a blockchain environment that can automatically execute their terms. Once an event triggers a clause in the contract (meeting the execution conditions), the code can execute automatically.

[0033] In related technologies, for a single contract account in the state tree, its Storage_Root points to another storage tree of the same MPT (Multi-Level Transmission) format. This storage tree stores data related to state variables involved in contract execution, and the value of Storage_Root is typically 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 finally submit the world state data to obtain the State_Root of the state tree. Clearly, in this approach, the state values ​​of different contract parameters within the same smart contract need to be updated sequentially, rather than in parallel, limiting the update efficiency and block generation speed of the state tree.

[0034] To address this, this specification modifies the aforementioned state tree by creating contract parameter nodes within the state tree, each corresponding to different contract parameters within the same smart contract. Each contract parameter node records the state value of its respective contract parameter. The system and its corresponding data submission scheme are described below with reference to the accompanying diagram.

[0035] The world state maintained by the blockchain system described in this specification corresponds to a state tree. The storage tree is also an MPT tree structure, storing key-value mappings from state addresses to state values. From the root node to the leaf node, the storage tree stores the address of a state; each leaf node stores the value of a state. The relevant states of smart contracts can be recorded in this state tree. Specifically, the leaf nodes of the state tree can include at least two types of nodes: contract account nodes and contract parameter nodes. Any contract account node can be used to record the contract account of a smart contract deployed in the blockchain system, and a contract parameter node can be used to record the state value of a contract parameter in any smart contract. It should be noted that any smart contract deployed in the blockchain system can contain one or more contract parameters, where any contract parameter can correspond to a contract parameter node in the state tree; if the contract contains multiple contract parameters, each contract parameter can correspond to a different contract parameter node. In other words, the contract parameters contained in the smart contracts deployed in the blockchain system can correspond one-to-one with the contract parameter nodes in the state tree. This method allows contract parameters in any smart contract to be recorded as a separate leaf node in the state tree, enabling independent updates to these parameters subsequently. This facilitates parallel updates of multiple contract parameters belonging to the same or different smart contracts, improving the update efficiency of the state tree. It is evident that updates to any two nodes in the state tree described in this solution—the contract account node and the contract parameter node—are independent of each other.

[0036] In addition to contract account nodes and contract parameter nodes, the leaf nodes of the state tree can also include external account nodes. These nodes can be used to record account information of external accounts created in the blockchain system, such as the account address, account balance, and other account information of an external account. Of course, if any external account contains at least one external account parameter, an account parameter node can also be created in the state tree to record each external account parameter, which will not be elaborated further.

[0037] Figure 2 This is a schematic diagram illustrating a blockchain data storage structure as provided in an exemplary embodiment. The block header of a single block may contain several fields, such as... Figure 2As shown, the block header of block N may contain the previous block hash (Previous_Hash in the diagram, or parent hash), a nonce (in some blockchain systems this nonce is not random, or the nonce in the block header is not enabled in some blockchain systems), a timestamp, a block number, a transaction root hash (Transaction_Root), a state root hash (State_Root), and a receipt root hash (Receipt_Root), etc. The Prev Hash in the block header of the subsequent block (e.g., block N) points to the previous block (e.g., block N-1), and the Prev Hash is the hash value of the previous block. In this way, the blockchain achieves the anchoring of the subsequent block to the previous block through the block header.

[0038] It's important to note that `State_Root` is the hash value of the root of the MPT tree composed of the states of all accounts in the current block. In other words, pointing to `State_Root` forms an MPT-style state tree. The root node of this state tree can be an extension node or a branch node, and the value of `State_Root` can be the hash value of this root node. Concatenating a portion of the values ​​from each node from the root node to the leaf node in sequence forms the account address, which serves as the key. The account information stored in the leaf nodes is the value corresponding to this account address, thus forming a key-value pair. The key can be sha3 (Address), i.e., the hash value of the account address (using a hash algorithm such as sha3), and the stored value can be rlp (Account), i.e., the rlp encoding of the account information. The account information can be a four-tuple consisting of [Nonce, Balance, CodeHash, Storage_Root].

[0039] As mentioned earlier, external accounts typically only have two fields: Nonce and Balance, while the Storage_Root and CodeHash fields store empty strings or strings of all zeros by default. Contract accounts, on the other hand, can include Nonce, Balance, CodeHash, Storage_Root, etc. Furthermore, regardless of whether it's an external or contract account, its account information is generally located in a single leaf node. The path from the root node's extension / branch nodes to each account's leaf node may involve several branch nodes and extension nodes.

[0040] like Figure 2As shown, Account 1 is an external account, and the corresponding external account node records the values ​​of the Nonce and Balance fields for Account 1. Account 2 is a contract account, and the corresponding contract account node records the values ​​of the Nonce, Balance, CodeHash, and other fields for Account 2. Furthermore, the contract account node described in this specification can also record the value of the Storage_Root field (e.g., ...). Figure 2 The `Storage_Root` field is shown in the dashed box. Alternatively, to conserve storage space for contract account nodes, the `Storage_Root` field may not be recorded. Assuming account 2 contains at least two contract parameters, A and B, then parameters A and B correspond to different contract parameter nodes in the state tree. Each contract parameter's corresponding node records its state value; for example, parameter A and its corresponding node record the state value of parameter A, and parameter B and its corresponding node record the state value of parameter B. Figure 2 As shown, the state value of any contract parameter can be stored in the form of key-value pairs, which will not be elaborated further.

[0041] A portion of the data stored along the path from the root node to the leaf node is concatenated to form the key, and the leaf node stores the value. In any smart contract, if the state value of any contract parameter is recorded as a key-value pair in the corresponding contract parameter node, the key of that contract parameter can be calculated using the contract information of the smart contract and the parameter information of that contract parameter. Furthermore, contract parameter nodes corresponding to different contract parameters within the same smart contract can share the same parent node as the contract account node of that smart contract. For example, the contract parameter nodes corresponding to parameters A and B, and the contract account node corresponding to account 2, are both connected to the same branch node.

[0042] For blockchain transactions that invoke smart contracts, the state data obtained by each blockchain node in the blockchain system through executing such transactions may include the state values ​​of the contract parameters in the smart contract. The blockchain node can then submit its own state values ​​to the contract parameter node in the state tree corresponding to the relevant contract parameter. The blockchain transaction described in this specification can be a transaction for creating a contract, which can be used to issue NFTs in the blockchain network; or, the blockchain transaction can be a transfer transaction, which can be used to purchase at least one NFT. The following explanation uses the first node in the blockchain system as an example to illustrate the transaction execution and data submission scheme.

[0043] Figure 3This is a schematic diagram of the structure of any two nodes in a blockchain system provided as an exemplary embodiment. Figure 3 Nodes n1 and n2 shown are the first and second nodes described in this scheme, respectively. Node n2 can be the master node in the blockchain system, and node n1 can be a slave node. Multiple processes can run on nodes n1 and n2 to provide various services, such as... Figure 3 As shown, nodes n1 and n2 each run an access process (such as access process 1 running in node n1 and access process 2 running in node n2; the process numbering below is similar and will not be repeated) for providing access services, a caching process for providing caching services, a pre-execution process for providing pre-execution services, a network process for providing network services, a consensus process for providing consensus services, a control process for providing block management services, and a storage process for providing storage services. In addition, node n1, as a slave node, can also run multiple computing processes for providing computing services, such as computing process 11, computing process 12, and computing process 13.

[0044] In this specification, a process refers to a running activity of a program with a certain independent function in an application regarding a data set. That is, a process is a procedure in a computer performed by the CPU sequentially executing instructions in an application, and each process is allocated its own memory address space upon creation. Multiple processes in any node can be multiple processes in multiple computing devices or virtual computing nodes. Furthermore, it should be noted that the solutions provided in the embodiments of this specification are not limited to master-slave blockchain systems; in other words, node n1 and node n2 in this solution can be any two blockchain nodes in the blockchain system.

[0045] The access process can be used to receive transactions from user devices, and then the access process can call the caching process to add the received transactions to the pending transaction queue for caching.

[0046] Node n2's pre-execution process 2 can call cache process 2 to sequentially read cached transactions from the pending transaction queue and verify them, such as verifying the user equipment's signature on the transaction, and then return the verified transactions to cache process 2. Furthermore, node n2 can also broadcast verified transactions stored in its cache process 2 to the network processes of other nodes through its network process 2; thus, transactions received by node n1 from node n2 through its network process 1 can be cached by its cache process 1 and added to the pending transaction queue. Therefore, the pending transaction queue cached in node n1's cache process 1 includes not only transactions received through its access process 1, but also transactions received through its network process 1 from other nodes (such as node n2).

[0047] The pre-execution process 2 of node n2 can also call the caching process 2 to sequentially read its cached transactions from the pending transaction queue and verify at least the transactions from user devices connected to node n2. Furthermore, the pre-execution process 2 of node n2 can pre-execute the transactions it receives sequentially from the caching process 2 to obtain pre-execution information for the transactions. This pre-execution information may include a pre-execution read set, a pre-execution write set, and resource consumption information (characterizing the amount of digital / computing resources consumed to execute the transaction). The pre-execution read / write set described in this specification includes the pre-execution read set and / or the pre-execution write set. Moreover, after completing the pre-execution of each batch of transactions, the pre-execution process 2 of node n2 can return the pre-execution information of that batch of transactions to the caching process 2 for caching in the pending consensus transaction queue.

[0048] In one embodiment, the cache process 2 of node n2 may also cache some state data in its memory. For any transaction pre-executed by the pre-execution process 2 of node n2, during the pre-execution of any transaction, the pre-execution process 2 may first call the cache process 2 to query whether its cached state data includes the state value of the first contract parameter to be read. If yes, the state value of the contract parameter returned by the cache process 2 is obtained. If no, the pre-execution process 2 may call the storage process 2 to query the state value of the contract parameter from the state data submitted to the state database.

[0049] Furthermore, since the pre-execution process 2 of node n2 returns the pre-execution information of its pre-executed transactions to the caching process 2, the caching process 2 can also update the cached state data based on the received pre-execution read / write set. It should also be noted that, since the pre-execution process 2 can sequentially read transactions from the pending transaction queue cached by the caching process 2 and pre-execute them, the caching process 2 can also cache the pre-execution order of multiple transactions pre-executed by the pre-execution process 2 in its memory based on its cached pending transaction queue. These multiple transactions are those that need to be packaged to generate the current block.

[0050] The pre-execution read set may contain several unique keys, and may also include key-value pairs corresponding to the aforementioned keys read from the committed world state. The pre-execution write set also contains several unique keys, and may also include key-value pairs corresponding to the aforementioned keys that are expected to be committed. Furthermore, if a transaction deletes a key from the world state, the pre-execution write set will record a corresponding marker for the deleted key. It is important to note that if the pre-executed transaction is a contract call transaction used to invoke a smart contract, its pre-execution read / write set may contain not only state parameters related to external accounts, but may also include several contract parameters related to the smart contract's contract state.

[0051] The following exemplifies the process by which node n2 pre-executes transactions Tx1 through Tx5 sequentially. It is assumed that transactions Tx1 and Tx2 are contract call transactions initiated by external accounts A1 and A2 respectively to invoke smart contract C1, and that smart contract C1 corresponds to contract account B1. Furthermore, it is assumed that transaction Tx3 is a transfer transaction initiated by external account A1 to external account A3, transaction Tx4 is a transfer transaction initiated by external account A4 to external account A5, and transaction Tx5 is a transfer transaction initiated by external account A6 to external account A7. Node n2 obtains a pre-execution read / write set by pre-executing transactions Tx1 through Tx5 through its pre-execution process 2. For example, the pre-execution read / write sets for each of transactions Tx1 through Tx5 can be found in Table 1 below.

[0052] Table 1

[0053] trade Pre-execution read set Pre-execution write set Trading Tx1 k1 = v11, k2 = v21 k1 = v12, k2 = v22 Trading Tx2 k3 = v31, k4 = v41 k3 = v32, k4 = v42 Trading Tx3 k1 = v12, k5 = v51 k1 = v13, k5 = v52 Trading Tx4 k6 = v61, k7 = v71 k6 = v62, k7 = v72 Trading Tx5 k8 = v81, k9 = v91 k8 = v82, k9 = v92

[0054] For the parameters provided in Table 1 above, for example, k1 represents the key of the balance of external account A1, k2 represents the key of a certain state parameter under contract account B1, k3 represents the key of the balance of external account A2, k4 represents the key of a certain state parameter under contract account B1, and k5 to k9 represent the keys of the balance of external accounts A3 to A7 respectively. v11, v12, v13, and v21 to v92 respectively represent the values ​​of their corresponding keys. It should be noted that since transaction Tx3 is executed after transaction Tx1, the value of k1 in the pre-execution read set of transaction Tx3 is the value of k1 in the pre-execution write set of transaction Tx1. Therefore, transactions Tx1 and Tx2 respectively call the same contract (i.e., smart contract C1), and the execution processes of the two transactions involve different contract parameters within this contract (i.e., transaction Tx1 involves the contract parameters represented by k2, and transaction Tx2 involves the contract parameters represented by k4).

[0055] The consensus process 2 of node n2 can invoke its cache process 2 to sequentially read multiple transactions and their related data from the queue of transactions awaiting consensus to generate a consensus proposal. This consensus proposal may include, for example, pre-execution information corresponding to each of the multiple transactions, the consensus order of the multiple transactions (the consensus order of the multiple transactions is the same as the pre-execution order of the multiple transactions), and indication information for each of the multiple transactions (e.g., the digest value of each of the multiple transactions). It should be noted that the conditions for node n2's consensus process 2 to invoke its cache process 2 may include, but are not limited to, invoking the cache process 2 at fixed time steps, invoking the cache process 2 when the amount of transaction data cached by the cache process 2 reaches a predetermined size, or invoking the cache process 2 when the number of pre-executed transactions cached by the cache process 2 reaches a predetermined number, etc. Furthermore, node n2's consensus process 2 can also send the consensus proposal to the respective network processes of other nodes (e.g., node n1) participating in the consensus process through its network process 2, so that the consensus proposal generated by its consensus process 2 can reach a consensus with the respective consensus processes of the other nodes. Furthermore, it should be noted that node n2 can also calculate the grouping information corresponding to the multiple transactions indicated by the consensus proposal based on their respective pre-execution information, and carry the grouping information in the consensus proposal so that other nodes participating in the consensus proposal can group the aforementioned multiple transactions based on the grouping information.

[0056] After consensus is reached on the consensus proposal, since the transactions received by nodes n1 and n2 from the user equipment they are connected to are added to the transaction queue to be processed by the caching process 2 of node n2 in the order of receipt, and the pre-execution process 2 of node n2 pre-executes each transaction in the transaction queue to be processed in the order, the consensus process 2 of node n2 can send the pre-execution information of the aforementioned multiple transactions to its control process 2 in the order of pre-execution / consensus of the aforementioned multiple transactions. The control process 2 submits part or all of the pre-execution information of the aforementioned multiple transactions as the state data of the corresponding block to the storage service 2, thereby obtaining the state root for generating the corresponding block and generating a block containing the state root and the aforementioned multiple transactions.

[0057] Node n1, for example, during the consensus process of the consensus proposal generated by node n2, or after reaching consensus on the consensus proposal generated by node n2, can read the pre-execution information of each of the aforementioned multiple transactions from the consensus proposal through its consensus process 1 and / or control process 1, and then group the multiple transactions based on the pre-execution information to obtain M (M is an integer greater than 1) transaction groups; or it can read the grouping information of the aforementioned multiple transactions from the consensus proposal and group the aforementioned multiple transactions based on the grouping information to obtain M transaction groups. For example, if the pre-execution information includes pre-execution read-write sets, the consensus process 1 can receive the pre-execution read-write sets of each of the multiple transactions from the second node in the blockchain system, determine the read-write set conflict relationship between the multiple transactions based on the pre-execution read-write sets, and determine the sequential 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 sequential dependency relationship to obtain the M transaction groups. Afterwards, the consensus process 1 can send the M transaction groups to the control process 1. For example, consensus process 1 can also calculate grouping information based on the pre-execution information of each of the aforementioned transactions, and send the grouping information, the aforementioned transactions, and their respective pre-execution read / write sets to control process 1 of node n1; then control process 1 divides the aforementioned transactions into M transaction groups based on the grouping information. After obtaining the M transaction groups, control process 1 can schedule tasks for the N computing processes 1 in node n1.

[0058] In obtaining the aforementioned M transaction groups, it is necessary to ensure that any two transactions within any two transaction groups do not conflict with each other. Specifically, "any two transactions do not conflict" means that no two transactions fall into one of the following categories: either the pre-execution read set of one transaction contains the same key as the pre-execution write set of another transaction, or the pre-execution write set of one transaction contains the same key as the pre-execution write set of another transaction. For any two conflicting transactions, they must be assigned to the same transaction group. In other words, if the pre-execution write sets of any two transactions contain the same key, it is considered that the two conflicting transactions accessed the same parameter and therefore conflict, and these two transactions must be assigned to the same transaction group; if the pre-execution read set of one of the two transactions contains the same key as the pre-execution write set of the other transaction, it is considered that the two transactions accessed the same parameter and therefore conflict, and these two transactions must be assigned to the same transaction group.

[0059] In another possible implementation, to efficiently determine the grouping information of the aforementioned multiple transactions, or to efficiently divide the aforementioned multiple transactions into M transaction groups, the aforementioned multiple transactions can typically be grouped according to the requirement that any two transactions in any two different transaction groups do not access the same parameters (i.e., do not contain the same key). Thus, for transactions Tx1 to Tx5 in the aforementioned example, their grouping can be seen in Table 2 below:

[0060] Table 2

[0061] trade Trading Groups Trading Tx1 and Trading Tx3 Trading Group 1 Trading Tx2 Trading Group 2 Trading Tx4 Trading Group 3 Trading Tx5 Trading Group 4

[0062] As can be seen, transactions that invoke the same contract (i.e., smart contract C1) but involve different contract parameters within that contract will be grouped into different transaction groups. For example, transaction Tx1 (involving the contract parameter represented by k2) is grouped into transaction group 1, while transaction Tx2 (involving the contract parameter represented by k4) is grouped into transaction group 2. It should be noted that any transaction involving any contract parameter may include reading or modifying the state value of that contract parameter during the transaction's execution. When any transaction involves any contract parameter, and the transaction is grouped into a particular transaction group, that transaction group can be considered as involving that specific contract parameter.

[0063] Node n1 can be divided into M transaction groups, and its N running computing processes can execute multiple transactions in parallel within these M transaction groups, thereby achieving group-level transaction execution. However, if any two transactions executed in parallel by any two computing processes involve the same contract account / smart contract, the state data obtained from executing these two transactions may involve different contract parameters. For example, the two transactions may generate read / write set data for parameters A and B, respectively. Based on the contract parameter nodes in the aforementioned state tree that correspond to different contract parameters within the same smart contract, different computing processes in the first node can execute the transactions within their respective transaction groups, and each computing process can submit state values ​​for different contract parameters, thus achieving parallel submission of state values ​​for different contract parameters within the same smart contract.

[0064] Figure 4 This is a flowchart illustrating a method for submitting status data, as provided in an exemplary embodiment. Figure 3 As shown, this method is applied to the first node in a blockchain system. As previously mentioned, the first node can be any blockchain node in the blockchain system; for example, the first node can be any blockchain node (slave node) other than the consensus proposal node (master 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.

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

[0066] In one embodiment, the state value of any contract parameter can be recorded in the corresponding contract parameter node as 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 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. Figure 2 As shown, 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. In this way, the contract parameter nodes corresponding to various contract parameters in the same smart contract can be distributed more centrally in the state tree, which facilitates subsequent parameter lookup and state value update.

[0067] The following text will primarily focus on the collaboration between node n2 (the master node) and node n1 (the slave node), with node n1 implementing the various method steps through its multiple processes, to describe in detail the implementation of a blockchain node. Figure 4 The method shown is a process where the first node contains a control process and N computation processes, and the method includes the following steps 402-406:

[0068] Step 402: 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. M and N are both positive integers. The pre-execution read-write sets involve several contract parameters.

[0069] In one embodiment, the control process can obtain M transaction groups based on grouping information from a second node in the blockchain system. In another embodiment, the first node may further include a first consensus process. The first consensus process can receive pre-execution read-write sets for each of the plurality of transactions from the second node in the blockchain system. Then, it determines read-write set conflict relationships between the plurality of transactions based on the pre-execution read-write sets, and determines the sequential dependencies of at least some of the transactions based on the read-write set conflict relationships. Furthermore, it can group the plurality of transactions according to the sequential dependencies to obtain M transaction groups. Based on this, the control process can obtain the M transaction groups obtained from the first consensus process. Specific implementation methods for the above acquisition can be found in the descriptions of the foregoing embodiments, and will not be repeated here.

[0070] Step 404: The control process sends the transaction groups involving different contract parameters of the first contract in the M transaction groups to different computing processes in the N processes respectively.

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

[0072] The first contract described in this specification can be any smart contract deployed in a blockchain system, and this contract contains multiple contract parameters. Based on the aforementioned transaction grouping results, transactions involving different contract parameters in the first contract can be divided into different transaction groups. After division, there may be one or more transaction groups involving the same contract parameter. For example, in the transactions shown in Table 1, transaction Tx1 and transaction Tx2 involve contract parameters represented by parameters k2 and k4 in smart contract C1, respectively. As shown in Table 2, they are respectively divided into transaction group 1 and transaction group 2. Therefore, the first node can send transaction group 1 and transaction group 2 to different computing processes for execution. Figure 3As shown, node n1 can send transaction packet 1 to computing process 11 and transaction packet 2 to computing process 12, so that the two processes can execute each transaction in the transaction packet they received.

[0073] It is understandable that, since transaction groups involving different contract parameters are sent to different computation processes for execution, for the first contract, each computation process can concurrently execute transactions involving different contract parameters within that contract and obtain corresponding state values. Therefore, this scheme, through the aforementioned transaction grouping scheme and the corresponding transaction group distribution (i.e., sending to different computation processes) scheme, ensures that different transactions involving different contract parameters within the first contract are executed concurrently by different computation processes, achieving process-level concurrent execution of transactions. This improves the execution efficiency of each transaction corresponding to the current block and helps to accelerate block generation. For example, the sending status of each transaction group shown in Table 2 can be seen in Table 3 below:

[0074] Table 3

[0075]

[0076]

[0077] As can be seen, transaction groups that call the same contract (i.e., smart contract C1) but involve different contract parameters within that contract will be sent to different computation processes. For example, transaction group 1, which belongs to transaction Tx1 (involving contract parameters represented by k2), is sent to computation process 11, while transaction group 2, which belongs to transaction Tx2 (involving contract parameters represented by k4), is sent to computation process 12.

[0078] Additionally, it should be noted that for transactions Tx4 and Tx5 that do not involve contract parameters in the smart contract, node n1 can send transaction group 3 to which transaction Tx4 belongs and transaction group 4 to which transaction Tx5 belongs to the corresponding computing process. Therefore, any computing process may receive transaction groups involving any contract parameters, as well as transaction groups containing irrelevant transactions (i.e., transactions that do not involve the first contract, such as transactions that do not involve any contract or transactions that involve other contracts). In this case, the computing process can normally execute the transactions in each transaction group it receives. This solution does not focus on the execution and status data submission process of the aforementioned irrelevant transactions.

[0079] Step 406: When the first computing process receives a transaction group involving any contract parameter in the first contract, it executes each transaction in the received transaction group, obtains the status value of the any contract parameter, and submits it to update the status value of the any contract parameter recorded in the corresponding contract parameter node in the state tree.

[0080] The first computing process can be any of the aforementioned different computing processes (receiving transaction groups distributed by the control process). The first computing process may receive one or more transaction groups involving any contract parameter in the first contract. The computing process can execute the transactions in each received transaction group serially. For example, computing process 11 can sequentially execute transactions Tx1 and Tx2 in transaction group 1 and transaction group 2 using a single worker thread. Alternatively, the computing process can execute the transactions in each received transaction group concurrently using multiple threads to complete the execution of the transactions in each received transaction group more quickly. For example, when receiving multiple of the aforementioned transaction groups involving any contract parameter in the first contract, the computing process can concurrently execute the transactions in each transaction group using multiple threads. For example, in computation process 11, worker threads thread1 and thread2 can run concurrently. Thread1 sequentially executes the state data of smart contract C1 related to transactions Tx1 and Tx3 in transaction group 11. This contract state data includes, for example, the state values ​​of contract parameters represented by k2 in smart contract C1. Thread2 executes transactions Tx2 and Tx4 in transaction group 2 to obtain another set of contract state data related to smart contract C1. This set of contract state data includes, for example, the state values ​​of contract parameters represented by k4 in smart contract C1. In this way, the first computation process can concurrently execute transactions in each transaction group, realizing in-process (thread-level) concurrent execution of transactions, further improving the execution efficiency of each transaction corresponding to the current block.

[0081] Transactions involving different contract parameters within the same smart contract are executed by different computation processes. Therefore, the state data obtained by each computation process (after receiving a group of transactions involving different contract parameters in the first contract) will not contain state values ​​for the same contract parameter. Consequently, each computation process can submit its obtained state value in parallel without affecting the others. Specifically, the first computation process, acting as any computation process, can submit the state value of the contract parameter it obtained after executing a transaction in a received group of transactions involving any contract parameter, thereby updating the state value of that contract parameter recorded in the corresponding contract parameter node in the state tree.

[0082] In one embodiment, the first computing process, upon executing each transaction in the transaction group involving any contract parameter, obtains the execution read-write set of each transaction. It can determine whether the execution read-write set is consistent with the pre-execution read-write set corresponding to each transaction. If it is determined that the execution read-write set of each transaction in the transaction group with any contract parameter is consistent with its pre-execution read-write set, it submits the status value of the contract parameter. For example, after completing the execution of any transaction, the first computing process can obtain the execution read-write set of that transaction and further determine whether it is consistent with the pre-execution read-write set of that transaction (obtained from the second node). Based on the above comparison, if the execution read-write set of each transaction in the transaction group is consistent with its pre-execution read-write set, the first computing process can update the status value recorded in the contract parameter node corresponding to the contract parameter based on the status value of the contract parameter. Alternatively, if the execution read-write set of a transaction in the transaction group is inconsistent with its pre-execution read-write set, the master node of the blockchain system can be replaced, and the execution of the multiple transactions can be re-initiated through a process similar to the aforementioned.

[0083] Through the above embodiments, the state values ​​of different contract parameters in the first smart contract are recorded separately by different contract parameter nodes in the state tree. Furthermore, the updates of the contract account node corresponding to the first contract and the contract parameter nodes corresponding to each of its various contract parameters are independent of each other, thus allowing the state values ​​of different contract parameters within the same contract to be updated separately without affecting each other. Based on this, transactions involving different contract parameters in the first contract are executed by different computing processes. This not only allows multiple transactions calling the same smart contract to be executed concurrently by different computing processes, thereby improving transaction execution efficiency, but also ensures that the execution processes of different transactions calling the same first contract are independent of each other. The two execution processes do not generate state data for the same contract parameters, allowing multiple computing processes to submit state values ​​for different contract parameters within the same contract in parallel, which helps to accelerate the generation speed of blocks containing multiple transactions calling the same contract.

[0084] Based on the same concept as the aforementioned method embodiments, this specification also provides a first node in a blockchain system. 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. The updates of the contract account nodes and the multiple contract parameter nodes do not affect each other.

[0085] Figure 5This is a schematic diagram illustrating the structure of a first node in a blockchain system, provided as an exemplary embodiment. For example... Figure 5 As shown, the first node includes a control process 52 and N computing processes 54. Specifically: the control process 52 is used to acquire M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read / write sets, where M and N are both positive integers, and the pre-execution read / write sets involve several contract parameters; the control process 52 is also used to send transaction groups involving different contract parameters of the first contract from the M transaction groups to different computing processes among the N processes; the first computing process among the N computing processes 54 is used to, upon receiving a transaction group involving any contract parameter of the first contract, execute each transaction in the received transaction group, obtain the status value of the any contract parameter, and submit it to update the status value of the any contract parameter recorded in the corresponding contract parameter node in the state tree.

[0086] In one possible implementation, the first computing process is further configured to: upon receiving multiple transaction groups involving any contract parameter in the first contract, concurrently execute transactions in each transaction group via multiple threads.

[0087] In one possible implementation, the first node further includes a storage process 58.

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

[0089] The storage process 58 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.

[0090] In one possible implementation, the first node further includes a first consensus process 56, for:

[0091] The system receives pre-execution read / write sets for each of the plurality of transactions from a second node in the blockchain system, determines read / write set conflict relationships among the plurality of transactions based on the pre-execution read / write sets, and determines the sequential dependencies of at least some of the plurality of transactions based on the read / write set conflict relationships; and groups the plurality of transactions according to the sequential dependencies to obtain the M transaction groups.

[0092] Based on the same concept as the aforementioned method embodiments, this specification also provides a blockchain system in this 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 a 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. The updates of the contract account nodes and the multiple contract parameter nodes do not affect each other. The blockchain system includes a first node and a second node. The first node contains a control process and N computation processes, wherein:

[0093] The second node is used to send pre-execution read-write sets of multiple transactions to the first node, and the pre-execution read-write sets involve several contract parameters.

[0094] The first node is used to obtain M transaction groups through the control process. The M transaction groups are obtained by grouping the multiple transactions based on their respective pre-execution read-write sets, where M and N are both positive integers, and the pre-execution read-write sets involve several contract parameters. The control process sends the transaction groups involving different contract parameters of the first contract among the M transaction groups to different computing nodes in the N processes. When the first computing process receives a transaction group involving any contract parameter of the first contract, it executes each transaction in the received transaction group, obtains the status value of the any contract parameter, and submits it to update the status value of the any contract parameter recorded in the corresponding contract parameter node in the status tree.

[0095] In one possible implementation, the state values ​​recorded by the contract parameter node are stored as key-value pairs, and the key of any contract parameter is calculated using the contract information of the first contract and the parameter information of the any contract parameter.

[0096] In one possible implementation, the first node further includes a first consensus process for:

[0097] The system receives pre-execution read / write sets for each of the plurality of transactions from a second node in the blockchain system, determines read / write set conflict relationships among the plurality of transactions based on the pre-execution read / write sets, and determines the sequential dependencies of at least some of the plurality of transactions based on the read / write set conflict relationships; and groups the plurality of transactions according to the sequential dependencies to obtain the M transaction groups.

[0098] In one possible implementation, the first computation process is further used for:

[0099] For each transaction in the transaction group involving any of the contract parameters received by itself, determine whether the execution read-write set is consistent with the pre-execution read-write set corresponding to each transaction;

[0100] If the execution read / write set of each transaction in the transaction group that determines any of the contract parameters is consistent with its pre-execution read / write set, submit the status value of any of the contract parameters.

[0101] In one possible implementation, the second node includes a pre-execution process and a caching process, wherein the caching process stores state data in its memory; wherein,

[0102] 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;

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

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

[0105] In one possible implementation, the second node also includes a second consensus process.

[0106] 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;

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

[0108] Figure 6 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. Please refer to... Figure 6At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, memory 608, and non-volatile memory 610, 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 602 reading the corresponding computer program from the non-volatile memory 610 into memory 608 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.

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

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

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

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

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

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

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

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

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

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

[0119] 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 method for submitting state data, applied to a first node in a blockchain system, wherein the world state maintained by the blockchain system corresponds to a state tree, and the leaf nodes of the state tree include contract account nodes and multiple contract parameter nodes, wherein 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 first node contains a control process and N computation processes, and the method includes: The control process acquires M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read-write sets. M and N are both positive integers, and the pre-execution read-write sets involve several contract parameters. The control process sends the transaction groups involving different contract parameters of the first contract in the M transaction groups to different computing processes in the N processes respectively; Upon receiving a transaction group involving any contract parameter in the first contract, the first computing process executes each transaction in the received transaction group, obtains the status value of the any contract parameter, and submits it to update the status value of the any contract parameter recorded in the corresponding contract parameter node in the state tree.

2. The method according to claim 1, 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.

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

4. According to the method of claim 1, the contract account node corresponding to the first contract and the contract parameter nodes corresponding to at least some of the contract parameters in the first contract have the same parent node.

5. 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.

6. The method according to claim 1, wherein the first node further comprises a first consensus process, and the method further comprises: The first consensus process receives the pre-execution read-write sets of each of the multiple transactions from the second node in the blockchain system, determines the read-write set conflict relationship between the multiple transactions based on the pre-execution read-write sets, and determines the sequential dependency relationship of at least some of the multiple transactions based on the read-write set conflict relationship. Furthermore, the multiple transactions are grouped according to the aforementioned dependencies to obtain the M transaction groups.

7. The method according to claim 6, Also includes: The first computing process executes the execution read-write set of each transaction in the transaction group involving any of the contract parameters received by itself, and determines whether the execution read-write set is consistent with the pre-execution read-write set corresponding to each transaction. The first computation process submits the status value of any contract parameter, including: the first computation process submits the status value of any contract parameter when the execution read-write set of each transaction in the transaction group of the determined contract parameter is consistent with its pre-execution read-write set.

8. The method according to claim 1, further comprising: Upon receiving multiple transaction groups involving any contract parameter in the first contract, the first computation process concurrently executes the transactions in each transaction group using multiple threads.

9. The method according to claim 1, wherein the first node further comprises a storage process. The first computation process submits the status value of any of the contract parameters, including: The first computation 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.

10. A first node in a blockchain system, 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 a 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 first node includes a control process and N computing processes, the first node includes a processor and a memory, and the processor is used to run the control process and the N computing processes; wherein: 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. M and N are both positive integers, and the pre-execution read-write sets involve several contract parameters. The control process is used to send the transaction groups involving different contract parameters of the first contract in the M transaction groups to different computing processes in the N processes respectively; The first computing process is used to execute each transaction in the received transaction group when it receives a transaction group involving any contract parameter in the first contract, obtain the status value of the any contract parameter and submit it, so as to update the status value of the any contract parameter recorded in the contract parameter node corresponding to the any contract parameter in the status tree.

11. The first node according to claim 10, the first computing process is further configured to: When multiple transaction groups involving any contract parameter in the first contract are received, the transactions in each transaction group are executed concurrently by multiple threads.

12. The first node according to claim 10, further comprising 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.

13. A blockchain system, 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 a 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 blockchain system includes a first node and a second node, the first node includes a control process and N computation processes, wherein: The second node is used to send pre-execution read-write sets of multiple transactions to the first node, and the pre-execution read-write sets involve several contract parameters. The first node is used to obtain M transaction groups through the control process. The M transaction groups are obtained by grouping the multiple transactions based on their respective pre-execution read-write sets. M and N are both positive integers. The pre-execution read-write sets involve several contract parameters. The control process sends transaction groups involving different contract parameters of the first contract among the M transaction groups to different calculators in the N processes respectively; and, when the first calculation process receives a transaction group involving any contract parameter in the first contract, it executes each transaction in the received transaction group, obtains the status value of the any contract parameter and submits it, so as to update the status value of the any contract parameter recorded in the corresponding contract parameter node in the status tree.

14. In the blockchain system according to claim 13, the state value recorded by the contract parameter node is stored as a key-value pair, and the key of any contract parameter is calculated by the contract information of the first contract and the parameter information of the any contract parameter.

15. The blockchain system according to claim 13, wherein the first node further comprises a first consensus process, configured to: The system receives pre-execution read / write sets for each of the plurality of transactions from a second node in the blockchain system, determines read / write set conflict relationships among the plurality of transactions based on the pre-execution read / write sets, and determines the sequential dependencies of at least some of the plurality of transactions based on the read / write set conflict relationships; and groups the plurality of transactions according to the sequential dependencies to obtain the M transaction groups.

16. In the blockchain system according to claim 15, the first computing process is further configured to: For each transaction in the transaction group involving any of the contract parameters received by itself, determine whether the execution read-write set is consistent with the pre-execution read-write set corresponding to each transaction; If the execution read / write set of each transaction in the transaction group that determines any of the contract parameters is consistent with its pre-execution read / write set, submit the status value of any of the contract parameters.

17. The blockchain system according to claim 13, wherein the second node includes a pre-execution process and a caching process, and 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.

18. The blockchain system according to claim 17, wherein the second node further includes 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.

19. 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-9 by executing the executable instructions.

20. 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-9.

Images