WO2023231338A1 - Procédé de soumission de données d'état, nœud et système de chaîne de blocs - Google Patents

Procédé de soumission de données d'état, nœud et système de chaîne de blocs Download PDF

Info

Publication number
WO2023231338A1
WO2023231338A1 PCT/CN2022/135279 CN2022135279W WO2023231338A1 WO 2023231338 A1 WO2023231338 A1 WO 2023231338A1 CN 2022135279 W CN2022135279 W CN 2022135279W WO 2023231338 A1 WO2023231338 A1 WO 2023231338A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
transaction
node
execution
transactions
Prior art date
Application number
PCT/CN2022/135279
Other languages
English (en)
Chinese (zh)
Inventor
林鹏
Original Assignee
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2023231338A1 publication Critical patent/WO2023231338A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G06F16/2386—Bulk updating operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and particularly relate to a state data submission method, a node and a blockchain system.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.
  • the purpose of the present invention is to provide a state data submission method, node and blockchain system.
  • a state data submission method is provided, which is executed by a first node in a blockchain system, where the first node includes a control process and N computing processes.
  • the method includes: 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 and write sets, wherein M is greater than N, and the pre-execution read and write sets are obtained by grouping the multiple transactions.
  • Executing the read-write set involves several contract parameters;
  • the control process sends P first transaction groups involving contract parameters of the first contract among the M transaction groups to the first process among the N processes;
  • the first process executes each transaction in the P first transaction groups to obtain P groups of contract status data of the first contract.
  • Each group of contract status data includes one or more contract parameters of the first contract.
  • the status value of the contract status of the first contract is submitted based on the contract status data of the P group.
  • a first node in a blockchain system where the first node includes a control process and N computing processes.
  • the control process obtains M transaction groups, and the M transaction groups are obtained by grouping the multiple transactions based on their respective pre-execution read and write sets, where M is greater than N, and the pre-execution The read-write set involves several contract parameters;
  • the control process sends the P first transaction groups involving the contract parameters of the first contract among the M transaction groups to the first process among the N processes;
  • the A process executes each transaction in the P first transaction groups to obtain P groups of contract status data of the first contract.
  • Each group of contract status data includes one or more contract parameters of the first contract. The status value is used to submit the contract status of the first contract based on the P group contract status data.
  • a blockchain system including a first node and a second node.
  • the second node is used to send the pre-execution read and write sets of multiple transactions to the first node, and the pre-execution read and write sets involve several contract parameters;
  • the first node controls the process based on the The respective pre-execution read-write sets of the multiple transactions are grouped to obtain M transaction groups, and the P first transaction groups involving the contract parameters of the first contract among the M transaction groups are sent.
  • the set contract status data includes respective status values of one or more contract parameters of the first contract, and the contract status of the first contract is submitted based on the P set of contract status data.
  • transactions involving the same contract account are executed by the same calculation process, so that any two calculation processes that execute multiple transactions belonging to a certain block in parallel will not generate contract status data involving the same contract account, thus
  • This allows multiple computing processes to submit their respective contract status data in parallel, which is conducive to faster generation of blocks containing multiple transactions.
  • a single computing process can concurrently execute each transaction in its corresponding multiple transaction groups, and can more quickly complete the execution of the transactions in each transaction group it receives, thereby accelerating the generation of blocks.
  • Figure 1 is a schematic diagram of a blockchain system provided as an example in the embodiment of this specification.
  • Figure 2 is a schematic structural diagram of blockchain data storage provided as an example in the embodiment of this specification.
  • Figure 3 is a schematic structural diagram of any two nodes in the blockchain system provided as an example in the embodiment of this specification;
  • Figure 4 is a flow chart of a method for submitting status data provided in the embodiment of this specification
  • Figure 5 is a schematic structural diagram of a blockchain node provided in the embodiment of this specification.
  • FIG. 1 is a schematic diagram of an exemplary blockchain system provided in the embodiment of this specification.
  • the blockchain system is a distributed network established through multiple nodes (Node), which includes communication between any two nodes at the application layer through a peer-to-peer (P2P) network. Connection, for example, any two nodes among the nodes n1 to n5 contained therein can realize communication connection at the application layer through the P2P network.
  • the blockchain system uses a decentralized (or multi-centered) distributed ledger constructed by a chain block structure, which is stored on each node (or most nodes, such as consensus) in the distributed blockchain network.
  • each node of the blockchain system runs a blockchain program.
  • the consensus mechanism is used to ensure that all loyal nodes have the same transactions, thereby ensuring that all loyal nodes have the same If the execution results of the transaction are consistent, the transaction is packaged into blocks and the world state is updated based on the execution results of the same transaction.
  • 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 and so on.
  • POW Proof of Work
  • POS Proof of Stake
  • PBFT Practical Byzantine Fault Tolerance
  • HoneyBadgerBFT Honey Badger Byzantine Fault Tolerance
  • Accounts in the blockchain system are usually divided into two types: user account/externally owned account (Externally owned account) and contract account (contract account); the contract account is used to store smart contract code and the values of related states in the smart contract code. , which can usually only be activated by calling an external account.
  • the design of external accounts and contract accounts is actually the mapping of account addresses to account status.
  • the status of an account can usually include, but is not limited to, nonce, balance, storage_Root, codeHash and other fields. Nonce and balance exist in both external accounts and contract accounts, while the codeHash and storage_Root attributes are usually only valid on contract accounts. Among the aforementioned fields, nonce represents the counter.
  • For external accounts it represents the number of transactions sent from the account address; for contract accounts, it represents the number of contracts created by the account.
  • Balance represents the number of digital resources owned by the corresponding external account.
  • storage_Root represents the hash of the root node of an MPT (Merkle Patricia Tree) tree. The MPT is used to organize the storage of state variables of contract accounts.
  • codeHash represents the hash value of the smart contract code.
  • contract accounts it is the hashed and stored code of the smart contract.
  • For external accounts it does not include smart contracts, so it can be an empty string/all 0 characters. string.
  • MPT is a tree structure that combines Merkle Tree (Merkle Tree) and Patricia Tree (Compressed Prefix Tree, a more space-saving Trie tree, dictionary tree).
  • Merkle Tree the Merkle tree algorithm calculates a Hash value for each transaction, and then connects the two to calculate the Hash again, all the way to the top-level Merkle root.
  • Ethereum uses an improved MPT tree, such as a 16-fork tree structure, which is usually referred to as an MPT tree.
  • the data structure of the Ethereum MPT tree includes a state trie.
  • the state tree contains the key and value pair corresponding to the storage content of each account in Ethereum.
  • the "key" in the state tree can be a 160bits identifier (the address of an Ethereum account).
  • This account address is distributed in the storage starting from the root node of the state tree to the leaf nodes.
  • the "values" in the state tree are generated by encoding the Ethereum account information (using the Recursive-Length Prefix encoding (RLP) method).
  • RLP Recursive-Length Prefix encoding
  • the values include nonce and balance; for contract accounts, the values include nonce, balance, codehash, storage_Root, etc.
  • Contract accounts are used to store status related to smart contracts. After the smart contract is deployed in the blockchain system, a corresponding contract account will be generated. This contract account generally has some states, which are defined by the state variables in the smart contract and generate new values when the smart contract is created and executed.
  • the smart contract usually refers to a contract defined in digital form in a blockchain environment that can automatically execute terms. Once an event triggers a clause in the contract (execution conditions are met), the code can be executed automatically.
  • the relevant status of the contract is stored in the storage trie, and the hash value of the root node of the storage tree is stored in the above-mentioned storage_Root, thereby locking all the status of the contract to the contract account through hash.
  • the storage tree is also an MPT tree structure, which stores the key-value mapping from state addresses to state values.
  • the address of a state is stored from the root node of the storage tree to the leaf nodes, and the value of a state is stored in a leaf node.
  • the block header of a single block can include several fields, such as the previous block hash previous_Hash (PrevHash in the figure, or called the parent hash), the random number Nonce (in some blockchain systems This Nonce is not a random number, or the Nonce in the block header is not enabled in some blockchain systems), timestamp Timestamp, block number BlockNum, state root hash State_Root, transaction root hash Transaction_Root, receipt root hash Receipt_Root, etc. .
  • the PrevHash in the block header of the next block (such as block N+1) points to the previous block (such as block N), which is the hash value of the previous block.
  • state_root is the hash value of the root of the MPT tree composed of the status of all accounts in the current block, that is, the point pointing to state_root is a state tree in the form of MPT.
  • the root node of this MPT tree can be an extension node (Extension Node) or a branch node (Branch Node).
  • Extension Node Extension Node
  • Branch Node branch node
  • What is stored in state_root is generally the hash value of this root node.
  • a part of the value of each node from the root node of this MPT to the leaf node can be concatenated in order to form an account address and serve as a key.
  • the account information stored in the leaf node is the value corresponding to the account address, thus forming a key-value Key-value pairs.
  • the key can be sha3 (Address), which is the hash value of the account address (the hash algorithm uses the sha3 algorithm, for example), and its stored value value can be rlp (Account), which is the rlp encoding of the account information.
  • the account information can be a four-tuple consisting of [nonce, balance, storage_root, codeHash]. As mentioned before, for external accounts, there are generally only two items, nonce and balance, and the storage_root and codeHash fields store empty strings/all 0 strings by default. For contract accounts, contract accounts can include nonce, balance, storage_root, codeHash, etc.
  • Leaf Node From the extension node/branch node of the root node to the leaf node of each account, there may be several branch nodes and extension nodes in the middle.
  • this storage_Root points to another tree in the form of MPT, which stores the data of state variables involved in contract execution.
  • the tree in MPT form pointed to by this storage_Root is a storage tree, that is, the hash value of the root node of the storage tree.
  • this storage tree also stores key-value pairs.
  • a part of the data stored on the path from the root node to the leaf node is connected to form the key, and the value is stored in the leaf node.
  • this storage tree can also be a tree in the form of MPT, which can generally be a 16-fork tree, that is, for a branch node, it can have up to 16 child nodes, which may include extension nodes and/or leaf nodes.
  • For an extension node it generally can have one child node, which can be a branch node.
  • This storage tree can be up to 64 levels deep.
  • the status data generated after nodes in the blockchain system complete the execution of multiple transactions belonging to a certain block may include Contract status data related to the storage trie and world state data related to the state trie. Therefore, when a node submits state data, it usually needs to submit the contract state data first to obtain the storage_root of the contract account, then update the storage_root of the relevant contract account in the state trie, and submit the obtained world state data to obtain the state_root of the state tree.
  • Figure 3 is a schematic structural diagram of any two nodes (for example, node n1 as the master node/second node and node n2 as the slave node/first node) in the blockchain system provided as an example in the embodiment of this specification. Both node n1 and node n2 can run multiple processes to provide multiple services. For example, as shown in Figure 3, node n1 and node n2 can each run access processes for providing access services and caching services.
  • the process refers to a running activity of a program with certain independent functions in the application on a data collection. That is, a process is a process in the computer that is carried out by the CPU sequentially executing instructions in the application program, and each process is created when it is created. Allocate its own memory address space.
  • the multiple processes in node n1 may be multiple processes in multiple computing devices or virtual computing nodes, and the multiple processes in node n2 may be multiple processes in multiple computing devices or virtual computing nodes.
  • the solutions provided by the embodiments of this specification are not limited to the master-slave architecture blockchain system.
  • the access process can be used to receive transactions from the user device, and then the access process calls the cache process to add the received transactions to the pending transaction queue for caching.
  • the pre-execution process of node n2 can call the cache process to read its cached transactions in order from the pending transaction queue and verify the transaction, such as verifying the signature of the user device on the transaction and sending the verified transaction Returned to the cache process.
  • node n2 can broadcast the verified transactions stored in its cache process to the network processes of other nodes through its network process; furthermore, the transactions from node n1 received by node n1 through its network process can be added to the waiting list by its cache process cache. in the transaction queue for processing. Therefore, the pending transaction queue cached by the cache process of node n1 through its memory includes not only transactions received through its access process, but also transactions received from other nodes through its network process.
  • the pre-execution process of node n1 can also call the cache process to sequentially read its cached transactions from the pending transaction queue, and at least verify transactions from user devices connected to node n1.
  • the pre-execution process of node n2 can also pre-execute the transactions it receives in sequence from the cache process to obtain the pre-execution information of the transaction.
  • the pre-execution information includes, for example, the pre-execution read set, the pre-execution write set and the execution of the transaction.
  • the amount of digital resources/computing resources that need to be consumed i.e. resource consumption information).
  • the pre-execution process of node n1 can also return the pre-execution information of this batch of transactions to the cache process after each completion of the pre-execution of a batch of transactions, so that it can be cached in the transaction queue to be agreed upon. It should be noted that part of the status data can also be cached in the memory of the cache process of node n1; for any transaction pre-executed by the pre-execution process of node n1, during the process of pre-execution of any transaction , the pre-execution process can first call the cache process to query whether its cached status data includes the status value of any variable to be read. If so, obtain the status value of the arbitrary variable returned by the cache process.
  • the pre-execution process can Call the stored procedure to query the state value of this arbitrary variable from the state data submitted to the state database.
  • its cache process can also update the cache based on the pre-execution read and write set it receives. Process cached state data.
  • the pre-execution process can sequentially read transactions from the pending transaction queue cached by the cache process and pre-execute them, the cache process can also pre-execute them based on its cached pending transactions.
  • the queue caches in its memory the pre-execution sequence of multiple transactions pre-executed by the pre-execution process.
  • the pre-execution read set contains several unique keys (keys), and also includes the key values (values) corresponding to each of the aforementioned keys read from the submitted world state.
  • the pre-execution write set also contains a number of unique keys (keys), as well as the key values (values) corresponding to each of the aforementioned keys that are expected to be submitted; in addition, if a transaction deletes a certain key in the world state, the pre-execution write set will Executing the write set will also record the corresponding mark for the deleted key.
  • the pre-executed transaction is a contract call transaction used to call a smart contract
  • its pre-execution read and write set may not only contain state parameters related to external accounts, but may also involve contracts related to the smart contract. Several contract parameters related to the status.
  • node n1 sequentially pre-executes transactions Tx1 ⁇ transaction Tx5.
  • transactions Tx1 and transaction Tx2 are contract call transactions for calling smart contract C1 initiated by external account A1 and external account A2 respectively.
  • smart contract C1 corresponds to contract account B1;
  • transaction Tx3 is a transfer transaction initiated by external account A1 and directed to external account A3
  • transaction Tx4 is a transfer transaction initiated by external account A4 and directed to external account A5
  • transaction Tx5 is an external account A transfer transaction initiated by A6 to external account A7.
  • Node n1 pre-executes transactions Tx1 to Tx5 through its pre-execution process, and may obtain the respective pre-execution information of transactions Tx1 to Tx5 as shown in Table 1 below.
  • k1 represents the key of the balance of the external account A1
  • k2 represents the key of a certain state parameter under the contract account B1
  • k3 represents the key of the balance of the external account A2
  • k4 represents the contract.
  • the key of a certain state parameter under account B1, k5 ⁇ k9 in turn represent the keys of the balance under external account A3 ⁇ external account A7.
  • v11, v12, v13 and v21 ⁇ 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.
  • the consensus process of node n1 can call its cache process to sequentially read multiple transactions and their related data from the transaction queue to be agreed upon to generate a consensus proposal, where the consensus proposal can include, for example, the corresponding predetermined data of the multiple transactions.
  • Execution information, 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 the multiple transactions or the respective instruction information of the multiple transactions (for example, the multiple transactions their respective summary values).
  • the conditions for the consensus process of node n1 to call its cache process may include but are not limited to calling the cache process according to a fixed time step, calling the cache process when the amount of transaction data cached by the cache process reaches a predetermined size, or The cache process is called when a predetermined number of pre-executed transactions cached by the cache process reaches a predetermined number, and so on.
  • the consensus process of node n1 can also send consensus proposals to the respective network processes of other nodes (such as node n2) participating in consensus on the consensus proposal through its network process, so as to communicate with the respective consensus processes of other nodes through its consensus process.
  • the consensus proposals it generates are subject to consensus.
  • node n1 can also calculate the grouping information corresponding to the multiple transactions based on the pre-execution information of each of the multiple transactions indicated by the consensus proposal, and carry the grouping information in the consensus proposal in order to participate in the consensus proposal.
  • Other nodes that propose consensus can group the aforementioned multiple transactions based on this grouping information.
  • the control process submits part or all of the pre-execution information of each of the aforementioned multiple transactions to the storage service as the state data of the corresponding block, and then obtains the state root used to generate the corresponding block and generates a state root containing the state root and the aforementioned multiple Transaction block.
  • node n2 may, during the process of consensus on the consensus proposal generated by node n1, or after reaching consensus on the consensus proposal generated by node n1, read the aforementioned plurality of consensus proposals from the consensus proposal through its consensus process and/or control process. Pre-execution information of each transaction, and then group the multiple transactions based on the pre-execution information of each transaction to obtain M transaction groups (M is greater than 1); or read the grouping of the aforementioned multiple transactions from the consensus proposal information and group the aforementioned multiple transactions based on the grouping information to obtain M transaction groups.
  • the consensus process of node n2 can calculate the grouping information based on the pre-execution information of each of the aforementioned multiple transactions, and send the grouping information, the aforementioned multiple transactions and their respective corresponding pre-execution read and write sets to the node n2. control process; then the control process of node n2 divides the aforementioned multiple transactions into M transaction groups based on the grouping information, and the control process of node n2 performs task scheduling on the N computing processes in node n2.
  • any two transactions in any two transaction groups do not conflict with each other. Any two transactions do not conflict with each other. Specifically, any two transactions do not have one of the following situations: the pre-execution read set of one transaction and the pre-execution write set of another transaction include the same key, the pre-execution write set of one transaction and Another transaction's pre-execution write set includes the same key. For any two transactions that conflict, they need to be divided into 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 any two transactions Conflict transactions access the same parameters and conflict exists.
  • any two transactions need to be divided into the same transaction group; if the pre-execution read set of one of the two transactions is included in the pre-execution write set of the other transaction,
  • the same key means that any two transactions are considered to have accessed the same parameters and there is a conflict.
  • the any two transactions need to be divided into the same transaction group.
  • the aforementioned multiple transactions can be divided into M transaction groups. Usually, the grouping information can be determined according to the location of any two different transactions.
  • the aforementioned multiple transactions are grouped by the requirement that any two transactions in the group do not access the same parameters (that is, do not contain the same key).
  • the grouping situation may include, for example: transaction Tx1 and transaction Tx3 are divided into transaction group 1, transaction Tx2 is divided into transaction group 2, and transaction Tx4 and transaction Tx5 are divided respectively. Go to transaction group 3 and transaction group 4.
  • node n2 can be grouped into M transactions and execute multiple transactions in the M transaction groups in parallel through the N computing processes it runs. However, if any two transactions executed in parallel by any two computing processes involve the same contract account/smart contract, then when node n2 submits the status data generated in the process of generating the block, in view of the The status data may involve contract parameters of the same smart contract. A single computing process cannot submit the status data it obtains independently and needs to merge and submit the status data obtained by each of the N computing processes.
  • FIG 4 is a flow chart of a status data submission method provided in the embodiment of this specification.
  • This method can be executed by any blockchain node in the blockchain system, for example, by other blockchain nodes (slave nodes) that are not serving as consensus proposal nodes (master nodes), whether as master nodes or
  • the blockchain nodes of the slave nodes can each be implemented as any device, platform, device or device cluster with computing/processing capabilities.
  • the blockchain node will be described in detail by mainly taking the node n1 as the master node and the node n2 as the slave node to cooperate, so that the node n2 specifically implements each method step in the method through the multiple processes it contains.
  • the process of implementing the method is shown in Figure 4.
  • the status data submission method executed by node n2 currently serving as a slave node may include but is not limited to the following steps 42 to 46.
  • Step 42 The control process obtains M transaction groups.
  • M transaction groups can be obtained by grouping multiple transactions based on their respective pre-execution read and write sets. M is usually greater than N and the pre-execution read and write sets of at least some of the multiple transactions are Executing read and write sets may each involve several contract parameters related to one or more smart contracts.
  • the various ways in which the control process obtains the aforementioned M transaction groups can be found in the previous section and will not be described again here.
  • Step 44 The control process sends the P first transaction packets involving the contract parameters of the first contract among the M transaction packets to the first process among the N processes.
  • the control process sends the P first transaction packets involving the contract parameters of the first contract among the M transaction packets to the first process among the N processes.
  • the control process of node n2 can, for example, send two transaction packets such as transaction group 1 and transaction group 2 as the aforementioned P first transaction groups to the calculation process 1 (i.e., the first process) of node n2, and transfer the transaction Group 3 is sent to calculation process 2, and transaction group 4 is sent to calculation process 3, so that calculation process 1 to calculation process 3 execute the transactions in the transaction groups they respectively received in parallel.
  • step 46 the first process executes each transaction in the P first transaction groups and obtains P sets of contract status data of the first contract.
  • Each set of contract status data includes one or more contract parameters of the first contract. respective status values, and submit the contract status of the first contract based on the P group contract status data.
  • the computing process can serially execute the transactions in each transaction group it receives.
  • the computing process 1 can sequentially execute the transactions Tx1, transaction Tx2, and transaction Tx3 in the transaction group 1 and transaction group 2 it receives through a single worker thread.
  • the computing process can concurrently execute the transactions in each transaction group it receives through multiple threads in order to complete the execution of the transactions in each transaction group it receives more quickly; for example, computing process 1 can run worker threads 1 and 1 concurrently.
  • Working thread 2 and working thread 1 sequentially execute transaction Tx1 and transaction Tx3 in transaction group 1 to obtain a set of status data involving smart contract C1.
  • This set of contract status data includes, for example, the status of the contract parameters represented by k2 in smart contract C1.
  • the worker thread 2 executes the transaction Tx2 in the transaction group 2 to obtain another set of contract status data related to the smart contract C1.
  • the set of contract status data includes, for example, the status value of the contract parameter represented by k4 in the smart contract C1.
  • the computing process can collect the status data obtained by executing the transactions in each transaction group it receives through the same storage object; for example, the computing process 1 can collect the transaction Tx1 it executes through the same storage object.
  • the execution read-write set specifically includes execution read set and execution write set.
  • the execution write set of transaction Tx1 ⁇ transaction Tx3 is the status data obtained by computing process 1 when executing transaction Tx1 ⁇ transaction Tx3. .
  • the state data obtained by the calculation process may include world state data related to the state tree and contract state data related to the storage tree.
  • the key-value pairs k2-v21 and k4-v41 are obtained by calculation process 1.
  • the contract status data, specifically the key-value pairs k2-v21 and k4-v41 are the contract status data of smart contract C1/contract account B1 obtained by calculation process 1.
  • the state data obtained by the calculation process only includes world state data related to the state tree, it can directly submit the world state data it obtained; if the state data obtained by the calculation process contains both world state data and involves at least one The contract status data of the smart contract, then the computing process needs to first submit the contract status of at least one smart contract it obtains, for example, send the P group of status data it obtains to the storage process, and the storage process updates the P group of status data based on the P group of status data.
  • the contract state tree i.e., storage tree
  • the contract state tree i.e., storage tree
  • the stored process corresponds to updating some state parameters in the state tree.
  • the computing process After the computing process completes the execution of any first transaction among the P first transaction groups it receives, it can correspondingly obtain the execution read-write set of the first transaction, and further determine the execution read-write set of the first transaction and Whether the pre-execution read and write sets of the first transaction are consistent.
  • the calculation process can update the contract status of the first contract based on the P groups of contract status data it obtains. .
  • the master node of the blockchain system can be replaced and then reinitiated through a process similar to the above. Execution of multiple transactions mentioned above.
  • control process can also call the storage process to submit the updated status tree and each storage tree to complete the status tree. is updated and obtained for the state root, and then the control process generates the corresponding block based on the state root and the aforementioned multiple transactions.
  • transactions involving the same contract account are executed by the same calculation process, so that any two calculation processes that execute multiple transactions belonging to a certain block in parallel will not generate contract status data involving the same contract account.
  • This allows multiple computing processes to submit their respective contract status data in parallel, which is conducive to faster generation of blocks containing multiple transactions.
  • a single computing process can concurrently execute each transaction in its corresponding multiple transaction groups, and can more quickly complete the execution of the transactions in each transaction group it receives, thereby accelerating the generation of blocks.
  • the embodiments of this specification also provide a first node in the blockchain system.
  • the first node includes a control process 52 and N calculation processes 54 .
  • the control process 52 obtains M transaction groups, which are obtained by grouping the multiple transactions based on their respective pre-execution read and write sets, where M is greater than N, and the pre-execution read and write sets are obtained by grouping the multiple transactions.
  • Executing the read-write set involves several contract parameters; the control process 52 sends the P first transaction packets involving the contract parameters of the first contract among the M transaction packets to the first process among the N processes; so The first process executes each transaction in the P first transaction groups and obtains P sets of contract status data of the first contract.
  • Each set of contract status data includes one or more contract parameters of the first contract.
  • Respective status values submit the contract status of the first contract based on the P group contract status data.
  • the first process concurrently executes each of the transactions in the P first transaction groups according to the P first transaction groups.
  • the first node also includes a storage process 56; the first process sends the P group contract status data to the storage process 56, so that the storage process 56 is based on the P sets of contract status data update the contract status tree of the first contract.
  • control process 52 obtains M transaction packets based on the packet information from the second node in the blockchain system.
  • the first node also includes a first consensus process 58; the first consensus process 58 receives the respective predetermined values of the multiple transactions from the second node in the blockchain system. Execute a read-write set, and group the multiple transactions based on the pre-execution read-write set to obtain the M transaction groups.
  • the first process after executing any first transaction in the P first transaction groups, the first process obtains the executed read-write set of the first transaction and determines the Whether the execution read-write set of a transaction is consistent with the pre-execution read-write set of the first transaction; the first process determines whether the execution read-write set of each transaction in the P first transaction groups is consistent with its pre-execution read-write set. In the case where the execution read and write sets are consistent, the contract status of the first contract is updated based on the P group contract status data.
  • the embodiments of this specification also provide a blockchain system, including a first node and a second node, wherein: the second node is used to send a message to the first node.
  • Pre-execution read and write sets of multiple transactions respectively, the pre-execution read and write sets involve several contract parameters; the first node uses its control process to perform pre-execution read and write sets of the multiple transactions based on the respective pre-execution read and write sets of the multiple transactions.
  • Transactions are grouped to obtain M transaction groups, and P first transaction groups involving contract parameters of the first contract among the M transaction groups are sent to the first process among its N processes, where M is greater than N;
  • the first process executes each transaction in the P first transaction groups to obtain P groups of contract status data of the first contract.
  • Each group of contract status data includes one or more of the first contract. respective status values of the contract parameters, and submit the contract status of the first contract based on the P group contract status data.
  • the second node includes a pre-execution process and a cache process
  • the cache process stores stateful data in its memory
  • the plurality of transactions include the first transaction.
  • the cache 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 cache process.
  • the pre-execution process is used to pre-execute the multiple transactions and generate pre-execution read and write sets of the multiple transactions, specifically for reading the status of the first variable during the process of pre-executing the first transaction. value, in the case where the memory of the cache process stores the first state value of the first variable, the first state value is received from the cache process, and the first state value is generated based on the first state value.
  • a pre-execution read-write set of a transaction is also used to store the pre-execution read-write set of the multiple transactions and the pre-execution sequence of the multiple transactions in the memory of the cache process, based on the A pre-execution read-write set of multiple transactions updates the state data stored in the cache process' memory.
  • the second node further includes a second consensus process.
  • the cache process is also used to send the pre-execution read-write sets and pre-execution sequences 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 the pre-execution read and write sets of the multiple transactions and their Consensus order, the consensus order is the pre-execution order.
  • These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions
  • the device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device.
  • Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information.
  • Information may be computer-readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • Magnetic tape magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de soumission de données d'état, un nœud et un système de chaîne de blocs. Le procédé est exécuté par un premier nœud dans un système de chaîne de blocs, le premier nœud comprenant un processus de commande et N processus informatiques. Le procédé comprend les étapes suivantes : le processus de commande acquiert M groupes de transactions, les M groupes de transactions étant obtenus par regroupement d'une pluralité de transactions sur la base d'ensembles de lecture-écriture de pré-exécution respectifs de la pluralité de transactions, M étant supérieur à N, et les ensembles de lecture-écriture de pré-exécution se rapportant à une pluralité de paramètres de contrat ; le processus de commande transmet à un premier processus des N processus P des premiers groupes de transactions relatifs à des paramètres de contrat d'un premier contrat dans les M groupes de transactions ; le premier processus exécute chaque transaction dans les P premiers groupes de transactions pour obtenir P groupes de données d'état de contrat du premier contrat, chaque groupe de données d'état de contrat comprenant des valeurs d'état respectives d'un ou plusieurs paramètres de contrat du premier contrat ; et sur la base des P groupes de données d'état de contrat, l'état de contrat du premier contrat est soumis.
PCT/CN2022/135279 2022-05-30 2022-11-30 Procédé de soumission de données d'état, nœud et système de chaîne de blocs WO2023231338A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210602795.8A CN115129727A (zh) 2022-05-30 2022-05-30 状态数据的提交方法、节点和区块链***
CN202210602795.8 2022-05-30

Publications (1)

Publication Number Publication Date
WO2023231338A1 true WO2023231338A1 (fr) 2023-12-07

Family

ID=83377180

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135279 WO2023231338A1 (fr) 2022-05-30 2022-11-30 Procédé de soumission de données d'état, nœud et système de chaîne de blocs

Country Status (2)

Country Link
CN (1) CN115129727A (fr)
WO (1) WO2023231338A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117422468A (zh) * 2023-12-18 2024-01-19 安徽中科晶格技术有限公司 基于dag模型的合约链合约并行化方法、设备及存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115129727A (zh) * 2022-05-30 2022-09-30 蚂蚁区块链科技(上海)有限公司 状态数据的提交方法、节点和区块链***
CN116308772B (zh) * 2022-12-16 2023-10-13 蚂蚁区块链科技(上海)有限公司 交易分发方法、节点和区块链***

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200052884A1 (en) * 2018-08-13 2020-02-13 International Business Machines Corporation Parallel transaction validation and block generation in a blockchain
CN111932257A (zh) * 2020-08-18 2020-11-13 工银科技有限公司 一种区块链并行化处理方法及装置
US20210318859A1 (en) * 2020-04-13 2021-10-14 International Business Machines Corporation Optimization of execution of smart contracts
CN113743950A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链节点和区块链
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN113743943A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN115129727A (zh) * 2022-05-30 2022-09-30 蚂蚁区块链科技(上海)有限公司 状态数据的提交方法、节点和区块链***

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200052884A1 (en) * 2018-08-13 2020-02-13 International Business Machines Corporation Parallel transaction validation and block generation in a blockchain
US20210318859A1 (en) * 2020-04-13 2021-10-14 International Business Machines Corporation Optimization of execution of smart contracts
CN111932257A (zh) * 2020-08-18 2020-11-13 工银科技有限公司 一种区块链并行化处理方法及装置
CN113743950A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链节点和区块链
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN113743943A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN115129727A (zh) * 2022-05-30 2022-09-30 蚂蚁区块链科技(上海)有限公司 状态数据的提交方法、节点和区块链***

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117422468A (zh) * 2023-12-18 2024-01-19 安徽中科晶格技术有限公司 基于dag模型的合约链合约并行化方法、设备及存储介质
CN117422468B (zh) * 2023-12-18 2024-03-29 安徽中科晶格技术有限公司 基于dag模型的合约链合约并行化方法、设备及存储介质

Also Published As

Publication number Publication date
CN115129727A (zh) 2022-09-30

Similar Documents

Publication Publication Date Title
WO2023231338A1 (fr) Procédé de soumission de données d'état, nœud et système de chaîne de blocs
Fu et al. A fair comparison of message queuing systems
US9460185B2 (en) Storage device selection for database partition replicas
WO2023231339A1 (fr) Procédé et nœud d'exécution de transaction dans système de chaîne de blocs, et système de chaîne de blocs
US9489443B1 (en) Scheduling of splits and moves of database partitions
Armbrust et al. Scads: Scale-independent storage for social computing applications
CN111338766A (zh) 事务处理方法、装置、计算机设备及存储介质
US10146814B1 (en) Recommending provisioned throughput capacity for generating a secondary index for an online table
US10102230B1 (en) Rate-limiting secondary index creation for an online table
Esteves et al. Quality-of-service for consistency of data geo-replication in cloud computing
US9875270B1 (en) Locking item ranges for creating a secondary index from an online table
US10158709B1 (en) Identifying data store requests for asynchronous processing
US10635650B1 (en) Auto-partitioning secondary index for database tables
US10747739B1 (en) Implicit checkpoint for generating a secondary index of a table
US10013449B1 (en) Validating and non-validating secondary indexes for a table in a non-relational data store
WO2023231336A1 (fr) Procédé d'exécution de transaction et nœud de chaîne de blocs
CN104298598A (zh) 分布式环境下rdfs本体的调试方法
CN112162846A (zh) 事务处理方法、设备及计算机可读存储介质
Le et al. Dynastar: Optimized dynamic partitioning for scalable state machine replication
US20220300323A1 (en) Job Scheduling Method and Job Scheduling Apparatus
US11132367B1 (en) Automatic creation of indexes for database tables
Vilaça et al. A correlation-aware data placement strategy for key-value stores
Matri et al. Týr: blob storage meets built-in transactions
Nurain et al. An in-depth study of map reduce in cloud environment
CN116737370A (zh) 一种多资源调度方法、***、存储介质及终端

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22944639

Country of ref document: EP

Kind code of ref document: A1