Blockchain transaction read-write set generation method and blockchain node

Abstract

A blockchain transaction read-write set generation method and a blockchain node, the method comprising: obtaining transaction data of a first transaction, the transaction data comprising an address of a first contract called by the first transaction, the blockchain storing contract data of the first contract, the contract data comprising a read-write information table, the read-write information table comprising storage location information of state variables requested to be accessed by the first contract; reading the read-write information table from the blockchain; and generating a read-write set of the first transaction according to the storage location information in the read-write information table.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for generating blockchain transaction read / write sets and a blockchain node. Background Technology

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

[0003] The purpose of this invention is to provide a read / write set generation scheme for blockchain transactions to improve the performance of transaction groups in the blockchain.

[0004] This specification provides a method for generating blockchain transaction read / write sets, the method comprising:

[0005] Obtain transaction data for the first transaction, the transaction data including the address of the first contract invoked by the first transaction, the blockchain storing contract data of the first contract, the contract data including a read / write information table, the read / write information table including the storage location information of the state variables requested to be accessed by the first contract;

[0006] Read the read / write information table from the blockchain;

[0007] The read / write set of the first transaction is generated based on the storage location information in the read / write information table.

[0008] The second aspect of this specification provides a blockchain node, including:

[0009] The acquisition unit is used to acquire transaction data of the first transaction. The transaction data includes the address of the first contract called by the first transaction. The blockchain stores the contract data of the first contract. The contract data includes a read / write information table, which includes the storage location information of the state variables requested by the first contract.

[0010] A reading unit is used to read the read / write information table from the blockchain;

[0011] The generation unit is used to generate the read / write set of the first transaction based on the storage location information in the read / write information table.

[0012] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0013] A fourth aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0014] In the solution provided in the embodiments of this specification, by pre-storing the read and write information of the contract in the blockchain when deploying the contract, the read and write set of the transaction can be deduced from the read and write information stored in the blockchain when executing the transaction that calls the contract. This eliminates the need to pre-execute the transaction, saves the computing resources of the blockchain platform, and improves the processing efficiency of the blockchain. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram illustrating the deployment of a smart contract in one embodiment;

[0017] Figure 2 This is a schematic diagram illustrating the invocation of a smart contract in one embodiment;

[0018] Figure 3 This is a schematic diagram of a block storage structure in one embodiment;

[0019] Figure 4 This is a schematic diagram of a block storage structure in one embodiment;

[0020] Figure 5 This is a schematic diagram of the EVM virtual machine module involved in the transaction processing in one embodiment;

[0021] Figure 6 This is a schematic diagram of a slot structure in one embodiment;

[0022] Figure 7 This is a schematic diagram of a slot structure in one embodiment;

[0023] Figure 8 This is a flowchart illustrating a method for deploying a contract in a blockchain, as described in one of the embodiments of this specification.

[0024] Figure 9This is a schematic diagram of the contract invocation relationship in the embodiments of this specification;

[0025] Figure 10 This is a schematic diagram of the contract data in the embodiments of this specification;

[0026] Figure 11 This is a flowchart illustrating the method for generating a transaction read / write set in the embodiments of this specification;

[0027] Figure 12 This is an architecture diagram of a blockchain node in one of the embodiments of this specification. 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] Blockchains are generally classified into three types: public blockchains, private blockchains, and consortium blockchains. In addition, there are various combinations of these types, such as private blockchains + consortium blockchains, consortium blockchains + public blockchains, etc. Public blockchains offer the highest degree of decentralization. Represented by Bitcoin and Ethereum, public blockchains allow participants to read data records on the chain, participate in transactions, and compete for the right to record new blocks. Furthermore, participants (represented by nodes on the blockchain) can freely join and leave the network and perform related operations. Private blockchains, on the other hand, have write permissions controlled by a specific organization or institution, and data read permissions are regulated by that organization. Simply put, a private blockchain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within specific institutions. Consortium blockchains fall between public and private blockchains, achieving "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; participants join the network through authorization and form a consortium of stakeholders to jointly maintain the operation of the blockchain.

[0030] Whether public, private, or consortium blockchains, most can provide smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

[0031] Taking Ethereum as an example, enabling users to create and invoke complex logic within the Ethereum network is the biggest challenge that distinguishes Ethereum from Bitcoin's blockchain technology. At the core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), which can be run by every Ethereum node. The EVM is a Turing-complete virtual machine, meaning that various complex logics can be implemented through it. Users publishing and invoking smart contracts in Ethereum run on the EVM. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). Smart contracts deployed on the blockchain can be in the form of bytecode.

[0032] For example Figure 1 As shown, after Bob sends a transaction containing information about creating a smart contract to the Ethereum network, Node 1's EVM can execute this transaction and generate the corresponding contract instance. In Figure 1, "0x6f8ae93…" represents the address of this contract. The transaction's data field can store bytecode, and the transaction's to field is an empty account. After the nodes reach a consensus through the consensus mechanism, the contract is successfully deployed, and users can subsequently call this contract.

[0033] After a contract is successfully deployed, a contract account corresponding to that smart contract appears on the blockchain, with a specific address. The contract code and account storage are stored in this contract account. The behavior of the smart contract is controlled by the contract code, while the smart contract's account storage preserves the contract's state. In other words, a smart contract enables the creation of a virtual account on the blockchain that contains both contract code and account storage.

[0034] As mentioned earlier, the `data` field of a transaction that creates a smart contract can include the smart contract's bytecode. Bytecode consists of a series of bytes, each byte representing an operation. For reasons of development efficiency and readability, developers can choose to write smart contract code in a high-level language instead of directly writing bytecode. The smart contract code written in a high-level language is compiled by a compiler to generate bytecode, which can then be deployed to the blockchain. Ethereum supports many high-level languages, such as Solidity, Serpent, and LLL.

[0035] Taking Solidity as an example, contracts written in it are very similar to classes in object-oriented programming languages. A contract can declare various members (or objects), including state variables, functions, function modifiers, events, etc. State variables are values ​​stored in the smart contract's account store and are used to save the contract's state.

[0036] The following is a simple code example 1 of a smart contract written in the Solidity language:

[0037]

[0038] Code Example 1. SimpleStorage Code

[0039] In code example 1 above, line 2 declares a string-type state variable `storedData`, and line 3 declares an event that stores the address of the initiator who called the contract and the string `s`. Lines 4-7 define a `set` function, which takes the string `s` as its input parameter. The `set` function performs the following operations: sets the input parameter to the state variable `storedData` and generates an event whose content includes the address of the initiator who called the contract and the string `s`.

[0040] As mentioned earlier, the state variables will ultimately be stored in the database. The generated events generally take the following form:

[0041] [topic1][topic2]...[topicn][data]

[0042] Here, the first topic, topic1, is generally a default value, such as an identifier for the receipt, which could be a hash value obtained by concatenating the event name, event parameter types, etc. The existence of each topic (topic2 to topicn) depends on whether the parameter was modified with the `Indexed` modifier. If it was, the value of that parameter would be a topic in the receipt; otherwise, it would generally be placed in the `data`. In the example code 1 above, when declaring the event in line 3, neither of the two parameters, `address from` and `s`, is modified with the `Indexed` modifier, so they would generally be placed in the `data`. The code in line 6 sets the `data` content of the event [msg.sender, s] using the `stored()` event. Thus, the overall form of the event operated on in line 6 is:

[0043] [topic1:Event identifier][data:msg.sender, s]

[0044] Lines 8-10 define the `get` function. This function returns the value of the queried `storedData`. `returns(string)` indicates the type of the return value, and the `constant` modifier indicates that this function cannot modify the values ​​of state variables in the contract.

[0045] In addition, such as Figure 2As shown, still using Ethereum as an example, after Bob sends a transaction containing information about calling a smart contract to the Ethereum network, the EVM of node 1 can execute this transaction and generate the corresponding contract instance. In Figure 2, the `from` field of the transaction is the address of the account initiating the smart contract call, and "0x6f8ae93" in the `to` field represents the address of the called smart contract. The `data` field of the transaction stores the method and parameters for calling the smart contract. Additionally, it can include a `value` field to represent the value of Ether in the transaction. After calling the smart contract, the value of `storedData` may change. Subsequently, a client can access the transaction through a blockchain node (e.g.,...). Figure 2 Node 6) View the current value of storedData.

[0046] Smart contracts can be executed independently on each node of the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain. Therefore, when such a transaction is completed, the blockchain stores an immutable and unlost transaction certificate.

[0047] As mentioned earlier, `storedData` in the example above is the state variable, which is stored in the smart contract's account storage. In various blockchain networks that introduce smart contracts, such as Ethereum, accounts typically include two types:

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

[0049] Externally owned account: A user's account, such as an Ethereum owner's account.

[0050] The design of external and contract accounts is essentially a mapping from account addresses to account states. Account states typically include fields such as Nonce, Balance, Storage root, and CodeHash. Nonce and Balance exist in both external and contract accounts. CodeHash and Storage root attributes are generally only valid for contract accounts.

[0051] Nonce: A counter. For external accounts, this number can represent the number of transactions sent from the account address; for contract accounts, it can be the number of contracts created by the account.

[0052] Balance: The amount of Ether held by this address.

[0053] Storage root: The hash of the root node of an MPT tree, which organizes the storage of state variables for contract accounts.

[0054] CodeHash: The hash value of the smart contract code. For contract accounts, this is the hash value of the smart contract; for external accounts, since the smart contract is not included, the CodeHash field can generally be an empty string or a string of all zeros.

[0055] MPT stands for Merkle Patricia Tree, a tree structure that combines the features of a Merkle Tree and a Patricia Tree (a compressed prefix tree, a more space-efficient Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins each pair of transactions and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is often simply referred to as an MPT tree.

[0056] The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs (kv) representing the storage content for each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (such as the address of an Ethereum account or part of its hash value, hereinafter referred to as the account address), distributed across storage from the root node to the leaf nodes of the state trie. The "value" in the state trie is generated by encoding the information of the Ethereum account using recursive-length prefix encoding (RLP). As mentioned earlier, for external accounts, the value includes nonce and balance; for contract accounts, the value includes nonce, balance, codehash, and storageroot.

[0057] A contract account is used to store the state of a smart contract. Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has several states defined by state variables within the smart contract, which generate new values ​​when the smart contract executes. A smart contract usually refers to a contract defined in code within a blockchain environment that can automatically execute its terms. Once an event triggers a term in the contract (meeting the execution conditions), the code can execute automatically. In the blockchain, the contract's state is stored in a storage trie. The hash value of the storage trie's root node is stored in the aforementioned storage root, thus locking all the contract's states to this contract account through hashing. The storage trie is also an MPT tree structure, storing a key-value mapping from state addresses to state values. Information from the root node to the leaf node of the storage trie tree is arranged sequentially to store the address of a state, and the leaf node stores the state's value.

[0058] like Figure 3 In some blockchain data storage examples, each block header includes several fields, such as the previous block hash (prev Hash in the diagram), a nonce (in some blockchain systems, this nonce is not random, or the nonce in the block header is not enabled), a timestamp, a block number, a state root hash (State_Root), a transaction root hash (Transaction_Root), and a receipt root hash (Receipt_Root). The Prev Hash in the header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the hash value of the previous block. In this way, the blockchain achieves locking of the previous block by the next block through the block header. State_Root, Transaction_Root, and Receipt_Root lock the state set, transaction set, and receipt set, respectively. The state set, transaction set, and receipt set are organized in a tree structure. Generally, they can be the same tree structure or different tree structures. For example, Ethereum uses the same MPT structure. In some tree structures like Ethereum that include a set of smart contract states, there is a two-level MPT structure: the leaf nodes of the upper-level MPT structure include two types: external accounts and contract accounts; each contract account includes the lower-level MPT structure, and the leaf nodes of the lower-level structure include the values ​​of the state in the contract account.

[0059] Figure 4This is a schematic diagram of a blockchain data storage structure. Taking Ethereum as an example again, it can be combined with... Figure 3 As shown, `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` is an MPT-style state trie. The root node of this MPT tree is generally an extension node or a branch node, and `state_root` typically stores the hash value of this root node. The root node can be connected to one or more extension nodes / branch nodes below it; these multiple levels of tree nodes can be collectively called internal nodes. A portion of the values ​​from each node from the root node to the leaf node in this MPT can be concatenated sequentially to form an account address as the key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. This key can also be a portion of the hash value of the account address (using a hash algorithm such as SHA3), and its stored value can be an RLP (Account) encoding, i.e., the RLP encoding of the account information. The account information is...

[0060] A four-tuple consisting of [nonce, balance, storageRoot, codeHash]. As mentioned earlier, external accounts typically only have the nonce and balance fields, while the storageRoot and codeHash fields default to storing empty strings or strings of all zeros. This means that external accounts do not store contracts or the state variables generated after contract execution. Contract accounts generally include Nonce, Balance, Storage root, and CodeHash. Nonce is the transaction counter for the contract account; Balance is the account balance; Storage root corresponds to another MPT, which links to contract-related state information; and CodeHash is the hash value of the contract code. Whether external or contract accounts, their account information is generally located in a single leaf node. The path from the root node's Extension Node / Branch Node to each account's Leaf Node may involve several branch nodes and extension nodes.

[0061] The state trie can be an MPT-style tree, typically a 16-ary tree, meaning each level can have a maximum of 16 child nodes. An Extension Node, used to store a common prefix, typically has one child node, which can be a Branch Node. A Branch Node can have a maximum of 16 child nodes, potentially including Extension Nodes and / or Leaf Nodes.

[0062] For a contract account within the state trie, its `storage_root` points to another tree, also in MPT form, which stores data related to the contract's execution state variables. This `storage_root` points to an MPT-form tree called the Storage Trie, specifically the hash value of the root node. Generally, this Storage Trie also stores key-value pairs. The key represents the address of the state variable, and its value can be the result of processing the state variable's declaration position (counting from 0) according to certain rules, such as SHA3(state variable declaration position) or SHA3(contract name + state variable declaration position). The value stores the state variable's value (e.g., an RLP-encoded value). A portion of the data stored along the path from the root node through intermediate nodes to the leaf node forms the key, and the leaf node stores the value. As mentioned earlier, this Storage trie can also be an MPT-type tree, typically a 16-ary tree. This means that a Branch Node can have a maximum of 16 child nodes, which may include Extension Nodes and / or Leaf Nodes. An Extension Node typically has one child node, which can be either a Branch Node or a Leaf Node.

[0063] For example Figure 4The Leaf Node Account P in the state trie is a contract account whose Storage Root locks all the states stored in that contract. These states are organized as an MPT tree, with a tree structure like the Storage trie linked by the Storage Root. In this linked Storage trie, taking Leaf Node StateVariable N as an example, if it is the value of storedData from the aforementioned contract code example, then its key can be, but is not limited to, sha3 (the declaration location of storedData), and its value is s (for simplicity, the encoding format of the value is omitted here, such as RLP, and similarly, will not be elaborated further). The key values ​​are distributed sequentially from the root node to the leaf node (i.e., Leaf Node Variable N) of the storage trie.

[0064] For example, Figure 4 In the state Trie, Leaf Node Account C is an external account. Its key is sha3(Address C), which is the hash value of the address of account C (using a hash algorithm such as sha3). Its stored value can be (Account), where the account information Account is a tuple of [nonce, balance]. As mentioned earlier, since Account C is an external account, its account information includes both nonce and balance (excluding codehash and storage root, similarly below). For example, for an external account with a nonce of 20 and a balance of 4550, the leaf node State Variable C will store nonce = 20 and balance = 4550. The address of Account C is the key, and its values ​​are distributed sequentially from the root node to the leaf node (i.e., Leaf Node Variable C) of the state Trie.

[0065] As mentioned above, after the transaction used to create the smart contract is sent to the blockchain, and consensus is reached on the transaction, each node on the blockchain can execute it. At this point, a contract account corresponding to the smart contract appears on the blockchain (including, for example, an account identifier (Identity), a contract hash value (Codehash), and a contract storage root (StorageRoot), and has a specific address. The contract code and account storage can be stored in the contract account's storage, such as... Figure 5As shown. The behavior of a smart contract is controlled by its contract code, while the smart contract's account storage preserves the contract's state. In other words, smart contracts create virtual accounts on the blockchain that contain contract code and account storage. For contract deployment or update transactions, the Codehash value is generated or changed. Subsequently, blockchain nodes can receive transaction requests to invoke the deployed smart contract. These requests can include the address of the invoked contract, the functions within the invoked contract, and the input parameters. Generally, after consensus is reached, each blockchain node can independently execute the specified invoked smart contract.

[0066] Figure 5 The left side shows an example of a smart contract written in Solidity and its compilation and execution process. This smart contract is compiled by a compiler to generate bytecode. `solc` in the diagram is Solidity's command-line compiler. Ethereum smart contracts written in Solidity can be compiled using the parameterized command-line tool `solc` to generate bytecode that can run on the EVM. After the above... Figure 1 The process of deploying a contract involves successfully creating a smart contract on the blockchain. After deployment, a contract account corresponding to the smart contract is generated on the blockchain. This contract account includes, for example, a contract counter (Nonce), an account balance (Balance), a hash value (Codehash) of the contract bytecode, and a storage root (StorageRoot) for contract storage. The contract will have a specific address on the chain, namely the contract address.

[0067] In Ethereum, the contract address is calculated by hashing the address of the external account deploying the contract and its nonce. Specifically, it's done using `sha3(rlp.encode([address_sender, nonce]))` (RLP, as mentioned earlier, is an encoding format; different blockchains can use other encoding formats, or even avoid re-encoding, so RLP will be omitted hereafter). `sha3` is a type of hash algorithm, such as the commonly used Keccak256 algorithm. `rlp`, as mentioned before, represents an encoding format; `rlp.encode([address_sender, nonce])` means performing RLP encoding on the content within the parentheses. The `[address_sender, nonce]` in the parentheses represents concatenating the address (address_sender) and the nonce of the external account deploying the contract in sequence. For example, using the Keccak256 algorithm, a 256-bit hash value can be obtained, from which the address of the deployed contract on the blockchain can be obtained (e.g., taking the first 20 bytes). 256 bits is equivalent to 32 bytes. The account balance can be set to the default value of 0 or [unspecified value] upon deployment. The hash value of the contract bytecode, Codehash, can be calculated by the blockchain platform through hashing the contract bytecode. The root storage location, StorageRoot, can be a default value or a hash value calculated based on the root node of the underlying storage trie. This generally depends on whether the deployed contract performs initialization operations, such as executing the contract's constructor. If the deployed contract includes a constructor, it typically includes initializing some state variables that will eventually be stored in the underlying database; this initialization can be performed in the virtual machine. After initialization, as mentioned above, an MPT tree can be constructed using these state variables, allowing the generation of the root node and its hash value. If the deployed contract does not include a constructor, the blockchain platform can assign a default value to StorageRoot, such as the hash value of empty content, instead of executing the actual function.

[0068] Once deployed, the contract, as mentioned earlier, can be invoked subsequently. Figure 2 As shown, after Bob initiates a transaction to call the smart contract on the Ethereum network, the contract executes, thereby setting the state variable to the string "hello".

[0069] The execution of the contract can be specifically as follows: Figure 5 As shown. For example Figure 2A transaction invoking a contract is sent to the blockchain network, and after consensus is reached, each node can execute the transaction. The `to` field of the transaction indicates the address of the contract being invoked. Any node can find the storage of the contract account based on the contract address, and then read the Codehash from the contract account's storage, thereby finding the corresponding contract bytecode based on the Codehash. The node can load the contract bytecode from storage into the virtual machine. Then, the interpreter interprets and executes it, including parsing the bytecode of the invoked contract (such as parsing Push, Add, SGET, SSTORE, Pop, etc.), obtaining the opcode and function, and storing these opcodes in the memory space allocated by the virtual machine (alloc in the diagram; corresponding to the memory release operation after program execution, Free in the diagram), and also obtaining the jump code of the invoked function in the memory space. Generally, after calculating the Gas required to execute the contract and ensuring sufficient Gas, the system jumps to the corresponding address in Memory to retrieve the OPcode of the called function and begins execution. This involves performing data computation, pushing / popping data from the stack, and other operations to complete the computation. During this process, some contract context information may be needed, such as the block number and information about the initiator of the call; this information can be obtained from the context (using a Get operation). Finally, the resulting state is stored in the database storage by calling the storage interface. It should be noted that during contract creation, certain functions within the contract may also be executed, such as initialization functions. In this case, code parsing, jump instructions, storage in Memory, and stack operations will also occur.

[0070] Through the above process, the virtual machine loads and executes the contract's bytecode, potentially generating and / or retrieving state, thus requiring access to the underlying database. The virtual machine needs convenient access to the underlying key-value (KV) database. Accessing the KV database typically employs pointer-like data access capabilities. For example, in Ethereum, if you need to read the value corresponding to a key from the KV database, you need to know the key of that data before accessing it.

[0071] Each contract typically has its own virtual storage space, the capacity of which can be a very large array, for example, 2^35. 256 An array of n elements, numbered from 0 to 2. 256-1. Each element can occupy a certain length, for example, 32 bytes. Each element is referred to here as a slot. Figure 6 This is a schematic diagram of a slot structure in one embodiment. It should be noted that a total of 2 256 The storage space of a slot is the total capacity of the virtual space. In other words, unused slots do not occupy the actual storage space of the underlying database.

[0072] During the execution of contract bytecode by the virtual machine, the slot position of the same state variable in the aforementioned virtual storage space needs to be fixed to ensure that the key generated by contract execution is consistent. This fixation is generally established after the contract code is finalized. Therefore, the determination of this fixed state variable position is usually made during the compiler compilation phase and is not directly related to the virtual machine.

[0073] The compilation process generally includes steps such as generating an abstract syntax tree (AST), performing lexical / syntactic analysis based on the AST, filling in symbols according to the symbol table, semantic analysis, and code generation. The AST comprises multiple nodes arranged in sequence, each corresponding to a different object declared in the contract. The order of the nodes corresponds to the declaration position of the objects within the contract, and each object includes the first state variable. During the lexical / syntactic analysis step based on the AST, the slot position information for the contract's state variables can be generated. Assume the code for contract C1 is as follows:

[0074]

[0075]

[0076] Code Example 2. Solidity code for Contract C1

[0077] Based on the contract code, the following abstract syntax tree can be generated:

[0078]

[0079]

[0080]

[0081] In the abstract syntax tree shown above, comments are marked with / / ... The storage location in line 11 describes the calculation rules for the slot. From line 3 (nodes) onwards, the abstract syntax tree describes the information of the objects declared in the contract within the abstract syntax tree; information related to one object is placed in one node. These objects include, for example, state variables A and B, and the mapping relationships "tokenOwner" and "ownedTokensCount". Lines 5-19 represent the 0th node for A in the abstract syntax tree, lines 20-34 represent the 1st node for B, lines 35-49 represent the 2nd node for tokenOwner, and lines 50-64 represent the 3rd node for ownedTokensCount. Each node contains further information. Overall, the information within a node can be referred to as the node information of the abstract syntax tree.

[0082] Referring to the abstract syntax tree of contract C1, the two state variables A and B in contract C1 are located at node positions 0 and 1 respectively in the abstract syntax tree, which can be corresponding to... Figure 6 The following two slots are located in the specified positions:

[0083] 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00000000 0000 00000x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00000000 0000 0000 0001

[0084] The two slots above each contain 256 bits, which is 32 bytes in hexadecimal (0x). Each segment after 0x, separated by a space, contains four consecutive hexadecimal numbers representing two bytes, so there are a total of 16 such segments.

[0085] In this way, in the contract bytecode compiled by the compiler, these two positions in the slot can be used to replace the identifiers of the two state variables, such as the two 256 bits mentioned above replacing A and B respectively. Thus, when the data type is a fixed-size value, the compiler can pre-allocate storage locations for each piece of data to be stored according to the field sorting order, which is equivalent to specifying fixed data pointers in advance.

[0086] During the virtual machine's loading and execution of the contract bytecode, operation A corresponds to the operation on the slot position corresponding to 0x000...00 (i.e., slot 0 above, with ellipses replacing the multiple zeros). Similarly, operation B corresponds to the operation on the slot position 0x000...01.

[0087] Figure 7 This is a diagram illustrating operations performed on a slot. (Example) Figure 7 As shown, for example, a transaction calling contract C1 calls the `setA()` function within that contract, with the string "0001" as the input parameter. During the virtual machine's execution of this transaction, the slot at position 0x000...01 stores "0001". Specifically, the virtual machine might push this 32-byte slot (0x000...01) onto the stack, and then push the corresponding value onto the stack as well. During the interpretation and execution process, the OPcode of the called function is retrieved from memory and execution begins. Based on the stack's LIFO (Last-In-First-Out) or LIFO (Last-In-First-Out) characteristics, the value is popped from the stack, and then the slot is popped from the stack, forming a slot-value pair. The contract virtual machine then executes the current OPcode, which means writing the value to the storage at the slot position. Thus, this slot acts as a number, uniquely identifying the contract's state variables during contract execution. In the above process, the stack typically uses 32 bytes as a storage unit, equal to the length of one slot. The corresponding value may be less than, equal to, or greater than 32 bytes, meaning the value may occupy one or more units of the stack.

[0088] Or as Figure 7 As shown, for example, a transaction that calls contract C1 calls the setB() function in that contract with the parameter "36". During the execution of the transaction by the virtual machine, the number 36 will be stored in the slot 0x000...02.

[0089] The results of executing the two contracts mentioned above can be simply represented as follows:

[0090] 0x000...00:0001(1)

[0091] 0x000...01:36(2)

[0092] After the virtual machine finishes execution, the virtual machine or blockchain platform can convert the slot in the two slot-value key-value pairs (1) and (2) into a state key. Specifically, the state key (i.e., the storage key of the state variable in the storage tree) can be obtained by concatenating the contract address and the slot position. For example, the address length of contract C1 is 20 bytes, which is 0x3321 dcaf8911d384 2e14 a7a4 15be 2fb1 a337 f43e. Then, by concatenating the contract address and the slot position,

[0093] (1) The state key of the corresponding state variable A is: 0x3321dcaf8911d3842e14a7a415be2fb1a337f43e0 ...

[0094] (2) The state key of the corresponding state variable B is: 0x3321dcaf8911d3842e14a7a415be2fb1a337f43e0000000000000000000000000000000000000000000000000000000000000000000000000001

[0095] Afterwards, blockchain nodes can store these generated state key-value pairs into the underlying database. Specifically, a blockchain node can include a tree-building module and a state database module. The tree-building module can transform these keys into a format such as... Figure 4 The storage trie tree shown is used to construct the value from the state key-value pair into a leaf node of this MPT tree. It should be noted that, as mentioned earlier, the state key is split into several small segments and stored sequentially in the tree nodes from the root to the leaf node. Which segment of the state key is stored in each tree node depends on the common prefix of that state key with other state keys in the tree. Moving upwards from the leaf node through intermediate nodes to the root node causes a series of hash value changes, and the tree construction module constructs the key-value pairs for these tree nodes. Then, the tree construction module sends these changed key-value pairs to the state database module, which finally stores them in the state database.

[0096] In the process described above, the slot for the state variable is fixed during the compilation phase, determined by the contract address and the slot position of the state variable, as mentioned earlier. The state key can be obtained by concatenating the contract address and the slot. Thus, running the same contract and reading / writing the same state variable will use the same slot and correspond to a fixed state key.

[0097] It should be noted that the state variables A and B in the example above are of type uint256 and bool, respectively. uint256 is 256 bits, or 32 bytes, and bool is 1 byte. The type of these state variables determines that the length of the data is fixed, or constant. In addition, types such as uint, uint8, and uint128 are also constant. An array of a certain number of elements is also constant. For example, uint[2] includes two elements, each of which is a 32-byte uint type. Therefore, uint[2] is 64 bytes in total.

[0098] Besides fixed-length data storage, there is also variable-length data, or data whose size is unpredictable. In this case, the slot position cannot be directly determined during compilation using a fixed-length approach, so a different solution is adopted.

[0099] For example, in contract C1, after state variables A and B, `mappping(uint256=>address)tokenOwner` and `mappping(uint256=>Counter)ownedTokensCount` are defined, which are mapping relationships. A mapping relationship is a data type of indefinite length. Taking `mappping(uint256=>address)tokenOwner` as an example, `tokenOwner` is the name of this mapping relationship.

[0100] The `mint` function in contract C1 is used, for example, to mint NFT resources. Its input parameter `address to` is the recipient account address of the minted NFT resource, and `token id` is the identifier of the minted NFT resource. Within the `mint` function, based on the previously defined mapping relationship, mapping elements `tokenOwner[tokenid] = to`, `ownedTokensCount[to]`, and `increment()` are defined. These mapping elements are state variables and will be stored in the state database. Taking `tokenOwner[tokenid] = to` as an example, `tokenid` and `to` are the two input parameters of the `mint` function. `tokenid` can also be referred to as the key of the mapping relationship `tokenOwner`.

[0101] like Figure 7 As shown, when compiling the contract code, the name tokenOwner of the mapping relationship can be assigned the slot 0x000...02 according to the position of the node corresponding to tokenOwner in the abstract syntax tree (i.e., the second position). Since tokenOwner is not a state variable, there is no value in this slot. Similarly, the slot with the position value 0x000...03 can be assigned to the mapping relationship ownedTokensCount.

[0102] When the virtual machine executes contract C1, it can uniquely determine the slot of the mapping element corresponding to the key based on the key and the slot of the mapping name. This slot is, for example, keccak256(key.slot), where "." is the concatenation symbol, and the slot after "." represents the position of the mapping name. The number of mapping elements in the mapping relationship is uncertain, as are the lengths of the key and value within each element. After contract C1 is called several times, the element of the mapping relationship tokenowner may have two elements:

[0103] tokenowner["nft1"]=Account1;

[0104] tokenowner["nft2"]=Account2;

[0105] The first mapping element in the `tokenOwner` mapping relationship has a key of `nft1` and a value of `Account1`. The corresponding slot position of the mapping element `tokenOwner[nft1]` can be `keccak256("nft1".0x000...02)`, and the value (e.g., the value's data length is greater than 32 bytes) can be stored in one or more consecutive slots starting from this position. Similarly, the second mapping element in the `tokenOwner` mapping relationship has a key of `nft2` and a value of `Account2`. The corresponding slot position of the mapping element `tokenOwner[nft2]` can be `keccak256("nft2".0x000...02)`, and the value (e.g., the value's data length is greater than 32 bytes) can be stored in one or more consecutive slots starting from this position.

[0106] For example, the length of the value of tokenOwner[nft1] is less than 32 bytes, and the length of the value of tokenOwner[nft2] is greater than 32 bytes but less than 64 bytes.

[0107] like Figure 7 As shown, the length of the value of tokenOwner[nft1] is less than 32 bytes, and its value can be stored in one slot. The position of this slot is, for example, the value of keccak256("nft1", 0x000...02), for example:

[0108] 0x000...05

[0109] Assuming the value of tokenOwner[nft2] is longer than 32 bytes and shorter than 64 bytes, its value can be stored in two consecutive slots. The starting positions of these two slots are, for example, the value of keccak256("nft2", 0x000...02). The positions of these two slots are, for example:

[0110] 0x000...07

[0111] 0x000...08.

[0112] Similarly, when the virtual machine executes contract C1, it can uniquely determine the slot of each element based on the key of the mapping element ownedTokensCount[to] and the slot of the mapping relationship ownedTokensCount, i.e., keccak256(“to”.0x000...03).

[0113] For example, such as Figure 7 As shown, the slot for ownedTokensCount[Account1] can be determined as follows:

[0114] 0x5b4d ed6c c162 9f13 8186f4b0 7950 04ad bed7 ec13 374d 15ca 04ec96f1 4913 2460

[0115] The slot for ownedTokensCount[Account2] can be determined as follows:

[0116] 0x9019 1b3f 1d96 c216 c6a6 637b 9c84 98bc 25cc 907a fe24 6d61 1b3a8bf7 27bc 081d

[0117] In other words, for a contract that includes a mapping relationship, once a transaction calls the contract and defines a mapping element, the slot of that mapping element can be uniquely determined based on the key of the mapping element in the transaction and the slot of the mapping relationship.

[0118] In the blockchain technology field, parallel transaction execution is employed to address the ever-increasing transaction volume and improve execution efficiency. To enable parallel execution, multiple transactions need to be grouped before execution. One related technology groups transactions based on their `from` and `to` fields. However, when multiple transactions invoke the same contract, they are grouped together for sequential execution. In practice, these transactions may access different state variables within the contract without causing access conflicts.

[0119] In the second related technique, for multiple transactions that invoke the contract, each transaction is pre-executed to obtain a pre-execution read / write set, and the multiple transactions are then grouped according to these pre-execution read / write sets. However, this scheme of obtaining transaction read / write sets through pre-execution is computationally intensive and consumes a large amount of computing and storage resources.

[0120] Therefore, this specification provides a method for generating transaction read / write sets. By pre-storing the read / write information of the contract in the blockchain when deploying the contract, the read / write set of the transaction can be derived from the read / write information stored in the blockchain when executing the transaction that calls the contract. This eliminates the need to pre-execute the transaction, saves the computing resources of the blockchain platform, and improves the processing efficiency of the blockchain.

[0121] Figure 8 This is a flowchart illustrating a method for deploying a contract in a blockchain, as described in an embodiment of this specification. The method can be executed by any blockchain node. The method includes the following steps S810-S820.

[0122] First, in step S810, the blockchain node receives a transaction Tx1 for deploying contract Contract1. The transaction Tx1 includes contract data of the contract to be deployed, which includes a read / write information table and / or a call information table.

[0123] As mentioned above, contract deployers can use a compiler to compile the Solidity code of Contract1, generating bytecode that can run in a virtual machine (such as EVM). During the compilation process, when Contract1 includes object declarations, the compiler will generate corresponding object identifiers for the declared objects according to preset rules, and convert the name of the declared object into the corresponding object identifier in the generated bytecode.

[0124] The object identifier is, for example, the slot mentioned above. Objects declared in the contract include, for example, state variables, mapping relationships, and other objects. It is understood that the object identifier is not limited to a slot, but can be an identifier generated using other preset rules to uniquely identify the object. For example, the object identifier can be generated based on attributes such as the object's name and length. In one implementation, if the object declared in the contract is a state variable, then the object identifier can be the storage key of the state variable in the state database.

[0125] Taking slot as an example, after the compiler generates the slots of each object declared in the contract, the compiler can generate the storage location information of the state variables accessed by the contract based on the identifier of each object.

[0126] In one scenario, the state variable A accessed by the contract is a fixed-length variable, and its storage location information can be the slot of that state variable included in the contract bytecode.

[0127] In another scenario, the state variable accessed by the contract (e.g., variable B) is a state variable corresponding to a mapping relationship. Its storage location information may include parameter information associated with the mapping relationship, as well as the slot of the mapping relationship in the contract bytecode. This mapping relationship is, for example, associated with the sending account of the transaction or the value of a stored object in the input parameters of the transaction pair contract. Thus, the parameter information is used, for example, to indicate the sending account of the transaction or the input parameters of the transaction pair contract. For example, if Contract1 includes a mapping relationship a[], which maps the sending account of the transaction calling the contract to the state variable a[from], then the storage location information of the state variable a[from] may include: "slot". a ", {index 0}", where slot a For the slot of mapping relationship a, index0 is used to indicate the from field of the transaction.

[0128] Alternatively, the mapping relationship can be associated with a state variable C declared in the contract. The value of state variable C needs to be read from a state database, so the parameter information can be the slot of state variable C. For example, Contract1 includes a mapping relationship b[], which is used to map state variable C to state variable b[C]. Then the storage location information of state variable b[C] can include "slot". b , {slot C}”, where slot b For the slot of mapping relationship b, slot C The slot is for the state variable C.

[0129] During the compilation of contract code, in addition to determining the storage location information of each state variable, the compiler can also determine the access mode of that state variable in the contract based on the contract code. The access modes include, for example, read mode, write mode, and read and write mode. Therefore, the compiler can generate an access information table for the contract, which includes the access mode and storage location information of each object requested for access in the contract.

[0130] In one implementation, the contract includes multiple functions, and the compiler can generate access information tables corresponding to each function. For example, Contract1 includes functions method1, method2, etc., and the compiler can generate access information tables corresponding to function method1 and function method2, respectively.

[0131] When Contract1 calls other contracts, the compiler can also determine the information of the called contracts based on the contract code of Contract1. Specifically, the compiler can generate contract call information corresponding to each function in Contract1. For example, if Contract1 includes functions such as method1 and method2, the compiler can generate call information tables corresponding to function method1 and function method2, respectively.

[0132] Suppose that Contract1's method1 includes, for example Figure 9 The diagram illustrates the call relationship. For example, ... Figure 9As shown, function `method1` in contract `Contract1` calls functions `method3` and `method4` in contract `Contract2`, and function `method3` in contract `Contract2` calls function `method5` in contract `Contract4`. For `method1`, the compiler, based on the contract code of contract `Contract1`, can obtain the contract address of contract `Contract2` called by contract `Contract1`, the function name of function `method3`, and the parameters passed to function `method3` in contract `Contract2`; similarly, it can obtain the contract address of contract `Contract3`, the function name of function `method4`, and the parameters passed to function `method4` in contract `Contract3`. This allows the generation of a call information table for function `method1`. The call information table corresponding to function method1 includes: the contract address of contract Contract2 called by function method1, the function name of function method3 in contract Contract2, and the parameters passed to function method3 in function method1; the contract address of contract Contract3 called by function method1, the function name of function method4 in contract Contract3, and the parameters passed to function method4 in function method1.

[0133] After performing the operations described above, the compiler generates contract data for Contract1. This contract data includes contract bytecode, an access information table, and / or a call information table. Specifically, if Contract1 includes accessed objects but does not include calls to other contracts, the contract data includes contract bytecode and an access information table. If Contract1 does not include accessed objects but includes calls to other contracts, the contract data includes contract bytecode and a call information table. If Contract1 includes both accessed objects and calls to other contracts, the contract data includes contract bytecode, an access information table, and a call information table.

[0134] Specifically, such as Figure 10 The diagram shown here illustrates the contract data in an embodiment of this specification. The contract data may include function data for each function in Contract1. Each function data includes the bytecode, access information table, and call information table corresponding to that function. For example... Figure 10As shown, the contract data of Contract1 includes function data for function method1 and function data for function method2, etc. The function data of function method1 is described as an example. The function data of function method1 includes the bytecode of the function, an access information table, and a call information table. The access information table includes multiple read / write entries, each corresponding to an object requested for access in function method1, and includes access mode and storage location information. The call information table includes multiple call entries, each corresponding to a call to another contract in function method1, and includes the contract address of the contract called by function method1, the function name of the function in the called contract, and the input parameters of function method1 to the called contract function. It is understood that the contract data in the embodiments of this specification is not limited to the following. Figure 10 As shown, for example, depending on the different ways of generating read / write sets, the read / write item may only include storage location information, or the call item may only include the address of the called contract, or the address of the called contract and the function name.

[0135] It is understandable that each contract to be deployed is converted into, before deployment, as shown below. Figure 10 The contract data shown is stored on the blockchain. For example, for Figure 9 The Contract2 shown here includes function data corresponding to function method3. This function data includes a read / write information table and a call information table for function method3. The call information table includes call information for function method5 in Contract4.

[0136] Contract deployers generate, through the compiler, such as Figure 10 Following the contract data shown, a transaction Tx1 can be generated to deploy contract Contract1. The "from" field of transaction Tx1 is the deployer's account, the "to" field is empty, and the "data" field includes, for example,... Figure 10 The contract data is shown below. Afterwards, the contract deployer can send transaction Tx1 to the blockchain, allowing all nodes in the blockchain to receive transaction Tx1.

[0137] In S820, contract data is stored in the blockchain.

[0138] After receiving transaction Tx1, and upon reaching a consensus on transaction Tx1, a blockchain node can execute transaction Tx1, thereby deploying contract Contract1 in the blockchain. Specifically, referring to the description above, the blockchain node determines the contract address of contract Contract1 and stores the contract data of transaction Tx1 in the blockchain in association with that contract address. For example, referring to the above... Figure 4 The description states that state data for Contract1 is created in the state tree. The CodeHash field in this state data records the hash value of the aforementioned contract data, and the contract data is stored in association with its hash value. Thus, the contract data of Contract1 can be read according to the CodeHash, and the bytecode of each function, access information table, or call information table can be read from this contract data.

[0139] Through such Figure 8 As shown in the deployment contract, for transactions that invoke the contract, blockchain nodes can read the contract data stored in the blockchain, and generate a read / write set of the transaction based on the access information table and / or call information table in the contract data, thereby improving the efficiency of transaction grouping.

[0140] Figure 11 This is a flowchart illustrating the method for generating a transaction read / write set in the embodiments of this specification. It is understood that this method can be executed by a blockchain node or by a trusted off-chain device; there is no limitation on either. The following description uses the execution of this method by a blockchain node as an example.

[0141] like Figure 11 As shown, in S110, the transaction data of transaction Tx2 is obtained.

[0142] Transaction Tx2 is a transaction that calls a contract (e.g., Contract1). The transaction data of Tx2 includes the transaction body. As mentioned above, the transaction body includes the from field, the to field, and the data field. The from field is the account that sent the transaction, the to field is the contract address of Contract1, and the data field is the function in Contract1 called by Transaction Tx2 (e.g., function method1) and the parameters passed to that function.

[0143] Blockchain nodes (such as master nodes) can receive transaction Tx2 from clients, thereby obtaining the transaction data of transaction Tx2.

[0144] In S120, the contract data of the transaction Tx2 calling contract is read from the blockchain. This contract data includes the contract's read / write information table and / or call information table.

[0145] After obtaining the transaction data, the blockchain node reads the contract data of Contract1 from the blockchain based on the contract address of Contract1 invoked in transaction Tx2. Specifically, refer to... Figure 4Blockchain nodes can read the state data of contract Contract1 from the state tree based on the contract address of contract Contract1, read the CodeHash from the state data, and then read the data corresponding to the CodeHash, i.e., the contract data of the contract CodeHash. This contract data may include the read / write information table and / or call information table of contract Contract1. For example... Figure 10 As shown, the contract data may include the bytecode, access information table, and call information table of each function in contract Contract1. Blockchain nodes can read the bytecode, access information table, and call information table of function method1 from the contract data.

[0146] In S130, a transaction read / write set is generated based on the read / write information table and / or the call information table.

[0147] If the contract data of Contract1 includes the read / write information table and / or call information table of Contract1, the blockchain node can generate the read / write set of transaction Tx2 based on the read / write information table and / or call information table of Contract1.

[0148] If the contract data of Contract1 includes a read / write information table and / or a call information table for function method1, the blockchain node can generate the read / write set of transaction Tx2 based on the read / write information table and / or call information table of function method1. This scenario will be used as an example in the following description.

[0149] refer to Figure 9 and Figure 10 During the process of deriving the read-write set, if the function data of function method1 includes an access information table, the blockchain node first obtains the access information table of method1. As mentioned above, this access information table may include read and write entries corresponding to each state variable.

[0150] In this case, in one implementation, the blockchain node can obtain each read / write item in the access information table and generate a key_rw for each state variable in the read / write set based on the storage location information in each read / write item.

[0151] In one scenario, suppose the access information table includes read / write entries for state variable A, where state variable A is a fixed-length variable and its storage location information can be the slot of that state variable included in the contract bytecode. For state variable A, a blockchain node can combine the slot from its storage location information with the contract address to obtain the key_rw of state variable A in the read / write set, and add this key_rw to the transaction read / write set. Specifically, as described above, the slot of state variable A can be concatenated with the contract address to calculate the key_rw of state variable A in the read / write set. It's important to understand that key_rw is not equivalent to the storage key of the accessed object in the state database, but rather a key used to group transactions in the read / write set.

[0152] In another scenario, the state variable accessed by the contract (e.g., variable B) is a state variable corresponding to a mapping relationship. Its storage location information may include parameter information associated with the mapping relationship, as well as the slot of the mapping relationship in the contract bytecode. When this parameter information is used to indicate the transaction sending account or transaction input parameters, the blockchain node can calculate the slot of state variable B based on the parameter information in the storage location information and the slot of the mapping relationship, and calculate the key_rw of state variable B in the transaction read / write set based on the slot of state variable B. For example, if state variable B is the aforementioned a[from], its storage location information may include "slot". a {index 0}. The blockchain node obtains the sending account for transaction Tx2 based on "index 0", and then can use the sending account and slot of transaction Tx2 as a basis. a Calculate the slot for state variable a[from], and based on the slot of state variable a[from], calculate the key of state variable a[from] in the read / write set. Blockchain nodes can then select the sending account and slot based on transaction Tx2 according to preset rules. a Calculate the slot for state variable a[from], with the preset rules determined based on the world state model. It is understandable that different world state models may have different preset rules.

[0153] When the parameter associated with the mapping relationship is a state variable declared in the contract, and the value of the state variable C at the time of execution of transaction Tx2 cannot be obtained at present, for example, in the case corresponding to the state variable b[C] above, the blockchain node can use the value obtained by concatenating the slot of the mapping relationship with the contract address as the key_rw of the state variable b[C] in the read-write set for participation in the grouping of transactions.

[0154] After determining the key_rw of the state variable, a blockchain node can record the key_rw into the read set and / or write set of the read-write set according to the access pattern of the state variable in the read-write information table. It is understood that, in one implementation, the access patterns of each state variable may not be distinguished in the read-write set; in this case, the blockchain node may only record the key_rw into the read-write set.

[0155] If the function data of function method1 includes... Figure 9 The call information table corresponding to the call relationship shown includes call items corresponding to Contract2 / method3 and call items corresponding to Contract3 / method4.

[0156] Specifically, for the call items corresponding to Contract3 / method4, the blockchain node reads the contract data of Contract3 from the blockchain, and then reads the function data of function method4 from this contract data, assuming that this function data includes the access information table of function method4. For the access information table of function method4, the blockchain node, similar to the above, adds key_rw to the read / write set of transaction Tx2 based on the read / write entries in the access information table of function method4. Specifically, the blockchain node can add key_rw to the read / write set of transaction Tx2 based on the read / write entries in the access information table of function method4 and the input parameters to function method4 in function method1.

[0157] Specifically, for the call items corresponding to Contract2 / method3, the blockchain node reads the contract data of Contract2 from the blockchain, and then reads the function data of function method3 from this contract data. It is assumed that this function data includes the access information table and call information table for function method3. For the access information table of function method3, the blockchain node, similar to the above, adds key_rw to the read / write set of transaction Tx2 based on the read / write entries in the access information table of function method3. For the call information table of function method3, refer to... Figure 9 The call information table includes call items corresponding to Contract4 / method5. Blockchain nodes can read the contract data of Contract4 based on the call items and update the read / write set of transaction Tx2 based on the contract data.

[0158] In addition, blockchain nodes can add default objects to the read / write set of transaction Tx2, such as the sending account of the transaction.

[0159] In this way, blockchain nodes can recursively obtain all read-write set information for transaction Tx2. This method eliminates the need for pre-executing transactions or analyzing contract bytecode, improving the efficiency of transaction read-write set generation and thus increasing grouping efficiency.

[0160] Figure 12 This is an architecture diagram of a blockchain node in an embodiment of this specification. The blockchain node is used to execute... Figure 8 or Figure 11 The method shown includes:

[0161] The acquisition unit 121 is used to acquire transaction data of the first transaction. The transaction data includes the address of the first contract called by the first transaction. The blockchain stores the contract data of the first contract. The contract data includes a read / write information table. The read / write information table includes the storage location information of the state variables requested to be accessed by the first contract.

[0162] Reading unit 122 is used to read the read / write information table from the blockchain;

[0163] The generation unit 123 is used to generate the read-write set of the first transaction based on the storage location information in the read-write information table.

[0164] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 8 or Figure 11 The method shown.

[0165] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 8 or Figure 11 The method shown.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0180] 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 generating a blockchain transaction read / write set, the method comprising: Obtain transaction data of the first transaction, the transaction data including the address of the first contract called by the first transaction, the blockchain storing the contract data of the first contract, the contract data including a first read-write information table, the first read-write information table including the storage location information of the state variables requested to be accessed by the first transaction when calling the first function in the first contract; Read the first read / write information table from the blockchain; The read / write set of the first transaction is generated based on the storage location information in the first read / write information table.

2. The method according to claim 1, wherein the contract data includes first function data corresponding to the first function, and the first function data includes a first read / write information table.

3. The method according to claim 1 or 2, wherein the storage location information of the state variable includes first information, the first information being obtained based on at least one of the following: the location information of the state variable in the contract code, the name of the state variable, and the length of the state variable.

4. The method according to claim 3, wherein the storage location information includes second information of the storage object associated with the state variable.

5. The method according to claim 4, wherein the second information is used to indicate the third information included in the transaction data; The step of generating the read / write set of the first transaction based on the storage location information in the first read / write information table includes: The read / write set of the first transaction is generated based on the first information and the third information.

6. The method according to claim 2, wherein the first function includes a call to the second contract, the first function data further includes first call information corresponding to the second contract, the first call information including the address of the second contract and the function name of the second function in the second contract, the method further comprising: Read the first call information from the blockchain; The step of generating the read / write set of the first transaction based on the storage location information in the first read / write information table includes: Based on the address of the second contract and the function name of the second function, read the second function data corresponding to the second function from the blockchain. The second function data includes a second read / write information table, which includes the storage location information of the state variables requested by the second contract. The read / write set of the first transaction is generated based on the storage location information in the first read / write information table and the storage location information in the second read / write information table.

7. The method according to claim 6, wherein the first invocation information further includes the input parameters of the first function to the second function. The step of generating the read / write set of the first transaction based on the storage location information in the first read / write information table and the storage location information in the second read / write information table includes: The read / write set of the first transaction is generated based on the storage location information in the first read / write information table, the storage location information in the second read / write information table, and the input parameters.

8. The method according to claim 1 or 2: The step of generating the read / write set of the first transaction based on the storage location information in the first read / write information table includes: Add the identifier of the preset object to the read / write set of the first transaction.

9. The method according to claim 1 or 2, wherein the method is executed by a blockchain node, and the method further comprises: Receive a second transaction, the second transaction being used to deploy the first contract, the second transaction including the first read / write information table; According to the second transaction, the contract data of the first contract is stored in the blockchain, and the contract data includes the first read / write information table.

10. The method according to claim 1 or 2, wherein the first read / write information table further includes the access mode of the state variable requested by the first contract. The step of generating the read / write set of the first transaction based on the storage location information in the first read / write information table includes: The read / write set of the first transaction is generated based on the storage location information in the first read / write information table and the access mode.

11. The method according to claim 4, wherein, The first contract corresponds to a plurality of numbers arranged in ascending order. The first contract includes a first state variable, and the first information of the first state variable includes one of the plurality of numbers. The first number is determined in advance based on the declaration position of the first state variable within the first contract. The step of generating the read / write set of the first transaction based on the storage location information in the first read / write information table includes: Generate a first key for the first state variable based on the first number, and add the first key to the read / write set.

12. The method according to claim 11, wherein the first contract includes a second state variable, the second state variable corresponds to a mapping relationship, the first information of the second state variable includes a second number of the mapping relationship, the second number is determined based on the declaration position of the mapping relationship in the first contract, and the second information of the second state variable is used to indicate the sending account of the first transaction or the input parameters of the first contract in the first transaction; The step of generating the read / write set of the first transaction based on the storage location information in the first read / write information table includes: The third number of the second state variable is determined based on the sending account of the first transaction or the input parameters of the first contract in the first transaction and the second number; A second key is generated based on the third number, and the second key is added to the read / write set of the first transaction.

13. The method according to claim 11, wherein the first contract includes a second state variable and a third state variable, the second state variable corresponds to a mapping relationship, the first information of the second state variable includes a second number of the mapping relationship, the second number is determined based on the declaration position of the mapping relationship in the first contract, and the second information of the second state variable includes a third number of the third state variable. The step of generating the read / write set of the first transaction based on the storage location information in the first read / write information table includes: A second key is generated based on the second number, and the second key is added to the read / write set of the first transaction.

14. A blockchain node, comprising: The acquisition unit is used to acquire transaction data of the first transaction. The transaction data includes the address of the first contract called by the first transaction. The blockchain stores the contract data of the first contract. The contract data includes a first read-write information table. The first read-write information table includes the storage location information of the state variables requested to be accessed by the first transaction when calling the first function in the first contract. The reading unit is used to read the first read / write information table from the blockchain; The generation unit is used to generate the read / write set of the first transaction based on the storage location information in the first read / write information table.

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

Images