Methods for obtaining transaction read / write sets in blockchain and blockchain nodes

Abstract

This specification provides a method for obtaining transaction read / write sets in a blockchain and a blockchain node. The method is executed by the blockchain node and includes: receiving multiple first transactions and obtaining transaction data corresponding to each of the multiple first transactions; the multiple first transactions are transactions that call contracts; based on each contract called by the multiple first transactions, obtaining read / write behavior information corresponding to each of the multiple first transactions from the metadata of each contract; the read / write behavior information corresponding to any first transaction includes information on access to state data in the contract methods involved in the first transaction; and determining the read / write set corresponding to each of the multiple first transactions based on the read / write behavior information and the transaction data corresponding to each of the multiple first transactions.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology in one or more embodiments, and particularly to a method for obtaining transaction read / write sets in a blockchain 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, data blocks are sequentially linked together in a chain-like data structure, and cryptographic methods are used to ensure the immutability and forgery resistance of these data blocks. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] This specification provides one or more embodiments of a method for obtaining transaction read / write sets in a blockchain and a blockchain node.

[0004] According to the first aspect, a method for obtaining a transaction read / write set in a blockchain is provided, the method being executed by a blockchain node, the method comprising:

[0005] Receive multiple first transactions and obtain the transaction data corresponding to each of the multiple first transactions; the multiple first transactions are transactions that invoke a contract;

[0006] Based on the contracts invoked by each of the multiple first transactions, read and write behavior information corresponding to each of the multiple first transactions is obtained from the metadata of each contract; the read and write behavior information corresponding to any first transaction includes information on accessing state data in the contract methods involved in the first transaction;

[0007] Based on the read / write behavior information and transaction data corresponding to each of the plurality of first transactions, the read / write set corresponding to each of the plurality of first transactions is determined.

[0008] According to the second aspect, a blockchain node is provided, comprising:

[0009] A receiving unit is configured to receive multiple first transactions and obtain transaction data corresponding to each of the multiple first transactions; the multiple first transactions are transactions that invoke a contract;

[0010] The acquisition unit is used to acquire read and write behavior information corresponding to each of the multiple first transactions from the metadata of each of the contracts invoked by each of the multiple first transactions; the read and write behavior information corresponding to any first transaction includes information on access to state data in the contract methods involved in the first transaction;

[0011] The determining unit is used to determine the read / write set corresponding to each of the plurality of first transactions based on the read / write behavior information corresponding to each of the plurality of first transactions and the transaction data corresponding to each of the plurality of first transactions.

[0012] According to a third aspect, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the method described in any one of the first aspects above.

[0013] According to a sixth aspect, a computing device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any one of the first aspects above.

[0014] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0015] The embodiments of this specification provide a method for obtaining transaction read / write sets in a blockchain and a blockchain node. By obtaining the transaction data corresponding to each of the multiple received transactions, obtaining the read / write behavior information corresponding to each transaction, and then determining the read / write sets corresponding to multiple first transactions based on the read / write behavior information and the transaction data corresponding to each transaction, the efficiency of obtaining transaction read / write sets is improved.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0018] Figure 1 This is a diagram of the blockchain architecture used in the embodiments of this specification;

[0019] Figure 2 This is a flowchart illustrating a method for obtaining a transaction read / write set in a blockchain according to an exemplary embodiment;

[0020] Figure 3A This is a schematic diagram of a method for obtaining a transaction read / write set in a blockchain, as described in an embodiment of this specification.

[0021] Figure 3B This is a schematic diagram of another method for obtaining the transaction read / write set in a blockchain, as illustrated in the embodiments of this specification.

[0022] Figure 4 This is a schematic diagram of another method for obtaining the transaction read / write set in a blockchain, as illustrated in the embodiments of this specification.

[0023] Figure 5 This specification illustrates a block diagram of a blockchain node according to an exemplary embodiment. Detailed Implementation

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

[0025] 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 blockchain + consortium blockchain, consortium blockchain + public blockchain, etc. Public blockchains offer the highest degree of decentralization. Participants in a public blockchain can 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 internal 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 shared interest alliance to jointly maintain the operation of the blockchain.

[0026] like Figure 1 The diagram shown is a blockchain architecture diagram used in the embodiments of this specification.

[0027] Figure 1In a blockchain, for example, there are six nodes, from node 1 to node 6. Each node can be implemented as any device, server, or cluster of devices with computing and processing capabilities. The lines connecting the nodes schematically represent the connections between nodes and are used to transfer data between them. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain can produce the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database.

[0028] Specifically, in the blockchain field, a transaction refers to a task unit executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. In the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract on the blockchain, the From field represents the account address initiating the transaction, the To field represents the account address of the contract called by the transaction, and the Data field includes the function name in the called contract and the parameters passed to that function, which is used to retrieve and execute the function's code from the blockchain during transaction execution.

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

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

[0031] In a contract invocation scenario, for example, Bob sends a transaction to the blockchain to invoke a smart contract. The `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field "0x6f8ae93…" represents the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract and updating its own maintained state database based on the execution of the contract.

[0032] 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` field (the address of the transaction initiator's account) and `to` field (the address of the invoked smart contract). For example, when multiple transactions invoke the same contract, they can be grouped together and executed sequentially. However, in practice, these transactions may access different state variables within the contract without causing access conflicts. Executing transactions without access conflicts sequentially would be inefficient.

[0033] In another related technique, for multiple transactions invoking a contract, each transaction is pre-executed to obtain a pre-execution read / write set, and the multiple transactions are then grouped based on these pre-execution read / write sets. The pre-execution read / write sets of each transaction include key-value pairs of state variables accessed by the transaction during pre-execution. While grouping the multiple transactions using their pre-execution read / write sets can significantly improve execution efficiency, this method of obtaining transaction read / write sets through pre-execution is computationally intensive and consumes substantial computational and storage resources.

[0034] Therefore, this specification provides a method for obtaining transaction read / write sets in a blockchain. This method involves acquiring transaction data corresponding to multiple received transactions, obtaining read / write behavior information for each transaction, and then determining the read / write sets corresponding to each transaction based on the read / write behavior information and the transaction data. This eliminates the need for pre-executing individual transactions, allowing for transaction grouping, reducing computational load and storage resource consumption, improving the rationality of transaction grouping, and enhancing the parallelism of transaction execution.

[0035] The solutions provided in this specification will be described in detail below with reference to specific embodiments.

[0036] like Figure 2 As shown, Figure 2 This is a flowchart illustrating a method for obtaining a transaction read / write set in a blockchain according to an exemplary embodiment. The blockchain includes multiple blockchain nodes, and the method is executed by any one of these blockchain nodes. The blockchain node can be implemented as any device, platform, server, or device cluster with computing and processing capabilities. The method may include the following steps:

[0037] First, in step 201, the blockchain node can obtain multiple first transactions. These first transactions can be transactions that invoke contracts, and they can belong to the same block. It should be noted that any contract can include at least one contract method, and any transaction invoking that contract can involve any one or more of the contract methods included in that contract. Next, the blockchain node can obtain the transaction data corresponding to each of these multiple first transactions. The transaction data corresponding to any first transaction can at least include the contract address of the contract invoked by the first transaction and the method name of the contract method involved in the first transaction.

[0038] Then, in step 203, the blockchain node can obtain the read / write behavior information corresponding to each of the multiple first transactions from the metadata of each contract, based on the contracts invoked by each of the multiple first transactions. The read / write behavior information corresponding to any first transaction includes the read / write behavior information corresponding to at least one contract method involved in the first transaction, and the read / write behavior information corresponding to any contract method can include information on accessing state data in that contract method.

[0039] Specifically, the metadata of any contract can pre-store read / write behavior information corresponding to at least one contract method included in the contract. For example, a method table can be stored in the metadata of each contract, containing multiple contract method entries. Each contract method entry contains read / write behavior information corresponding to a contract method, which can specifically be a read / write behavior table. The read / write behavior information can be obtained by the compiler through static analysis of the contract code during the contract deployment phase. During the contract deployment and creation process, the read / write behavior information corresponding to at least one contract method included in the contract can be stored in the contract's metadata. It should be noted that the contract's metadata can be stored in the blockchain or outside the blockchain. If the contract's metadata is stored in the blockchain, then the contract's metadata can be stored in the global state tree of the world state.

[0040] Therefore, based on the contract address of the contract invoked by the first transaction and the method name of the contract method involved in the first transaction, the read and write behavior information corresponding to the contract method involved in the first transaction can be obtained from the metadata of the contract invoked by the first transaction.

[0041] Finally, in step 205, the blockchain node can determine the read-write set corresponding to each of the multiple first transactions based on the read-write behavior information and transaction data corresponding to each of the multiple first transactions. The transaction data corresponding to any one first transaction may further include transaction parameter information, sender information (e.g., the sender's account), and receiver information (e.g., the receiver's account). The read-write set corresponding to any one first transaction can be a set of read-write addresses accessing the storage object when executing the first transaction. It should be noted that the read-write set corresponding to any transaction can be represented by a read-write key and a read-write label. The read-write key is the address specified when accessing the state storage during the transaction execution process, and the read-write key can be used as an attribute when grouping transactions. The read-write label can indicate the read-write category (e.g., whether the read-write category is read or write), and the read-write label can be recorded in the read-write behavior information (e.g., a read-write behavior table).

[0042] Specifically, we can first obtain auxiliary information corresponding to each of the multiple first transactions based on their respective transaction data. This auxiliary information can be multiple auxiliary tables. For example, for any given transaction, we can generate a transaction execution context list based on the sender information included in the transaction data. Based on the transaction parameter information included in the transaction data, we can generate a transaction parameter list corresponding to the transaction. Based on the contract address of the contract invoked by the transaction and the name of the contract method involved in the transaction, we can obtain a list of contract constants corresponding to the transaction from the metadata of the contract invoked by the transaction. We then use these auxiliary tables (transaction execution context table, transaction parameter table, and contract constant table) as the auxiliary information corresponding to the transaction.

[0043] Then, based on the read / write behavior information and auxiliary information corresponding to each of the multiple first transactions, the read / write sets corresponding to each of the multiple first transactions are determined. On one hand, the read / write behavior information (e.g., a read / write behavior table) corresponding to any first transaction can include record entries for multiple read / write behaviors corresponding to that first transaction. Each record entry for a read / write behavior records the auxiliary table type and the index value within the auxiliary table corresponding to that read / write behavior. On the other hand, the auxiliary table records the index value, encoding type, and path component within the auxiliary table corresponding to the read / write behavior.

[0044] Specifically, for any first transaction, the read / write behavior information corresponding to the first transaction can be, for example, the respective read / write behavior tables corresponding to at least one contract method involved in the first transaction. Based on the record entries of at least one read / write behavior included in each read / write behavior table, the auxiliary table type and the index value within the auxiliary table can be determined for each record entry of the at least one read / write behavior. The auxiliary table type can, for example, indicate the type of the transaction execution context table, the type of the transaction parameter table, and the type of the contract constant table, and the index value within the auxiliary table can be the index value recorded in the auxiliary table.

[0045] Then, based on the auxiliary table type recorded in the record entries for each read / write action, the corresponding auxiliary table is retrieved from the auxiliary information. Using the index value within the auxiliary table, the path component corresponding to each read / write action, and the encoding type corresponding to each path component, are obtained from the corresponding auxiliary table. The path components can then be encoded according to their respective encoding types to obtain the read / write sets corresponding to multiple first transactions.

[0046] For example, a blockchain system may include blockchain node A. The following example illustrates how blockchain node A executes this method. Blockchain node A can obtain transactions Tx1-Txn belonging to block B1. Taking transaction Tx1 as an example, transaction Tx1 calls contract C, which includes contract methods M1, M2, and M3. Transaction Tx1 involves contract method M1 within contract C. The transaction data S1 corresponding to transaction Tx1 may include, but is not limited to, the contract address D1 of contract C called by transaction Tx1, the method name of contract method M1, the transaction parameter information corresponding to transaction Tx1, and the sender information.

[0047] On one hand, blockchain node A can find the metadata corresponding to contract C based on the contract address D1 included in transaction data S1. It should be noted that the metadata corresponding to contract C stores read / write behavior tables T1, T2, and T3 for contract methods M1, M2, and M3, respectively. During contract C deployment, the compiler performs static analysis on the contract code of contract C to obtain read / write behavior tables T1, T2, and T3, and stores these tables in association with the method names of their respective contract methods in the metadata corresponding to contract C. Therefore, blockchain node A can further find the read / write behavior table T1 corresponding to contract method M1 from the metadata corresponding to contract C based on the method name of contract method M1.

[0048] like Figure 3A As shown, for example, the read / write behavior table T1 may include multiple record entries corresponding to each read / write behavior (e.g., record entry 101, record entry 102, etc.), with each read / write behavior corresponding to one record entry; for example, record entry 101 corresponds to read / write behavior X1. Each record entry in the read / write behavior table T1 may correspond to multiple fields, which may include, but are not limited to, a record entry index field (Index), a read / write flag field (Read / Write Flag), and a path component key field (Key Components). The path component key field further includes a component index field (ComponentIndex), a table type field (Table Type), and an in-table index field (In-Table Index). This path component key field is used to determine the path component of the path stored in the contract for each record entry.

[0049] Taking record entry 301 as an example, record entry 301 contains the record entry index value 0 corresponding to read / write behavior X1, read / write label W (for example, indicating that read / write behavior X1 is write data), component index values ​​0-4, auxiliary table types Context, Constant, and arg, and auxiliary table internal index values ​​0, 1, 0, 1, and 3.

[0050] On the other hand, blockchain node A can obtain auxiliary information corresponding to transaction Tx1 based on transaction data S1. This auxiliary information may include, for example, a transaction execution context table (Context Table), a transaction parameter table (ArgTable), and a contract constant table (Constant Table). Figure 3AAs shown, the Context Table, Arg Table, and Constant Table can all correspond to the Index field, Type field, and Value field within the table, and each can include multiple record entries.

[0051] For example, record entry 303 contains an index value of 0, an encoding type of address, and a path component value of Call.sender. As another example, record entry 304 contains an index value of 1, an encoding type of address, and a path component value of Call.contract.

[0052] Specifically, blockchain node A can construct a transaction execution context table (Context Table) based on the sender information and contract address D1 included in transaction data S1; construct a transaction parameter table (Arg Table) based on the transaction parameter information included in transaction data S1; and retrieve a pre-stored contract constant table (Constant Table) from the metadata corresponding to contract C based on the contract address D1 and the method name of contract method M1 included in transaction data S1. The contract constant table can be generated and stored during the contract's compiler.

[0053] Next, blockchain node A can determine the read / write set corresponding to transaction Tx1 based on the read / write behavior table T1, the transaction execution context table, the transaction parameter table Arg Table, and the contract constant table Constant Table. Specifically, based on the above auxiliary tables, the path component values ​​corresponding to each record entry in the read / write behavior table T1 can be determined according to the index order in the read / write behavior table T1 (e.g., the order of record entry indexes and the order of component indexes).

[0054] For example, taking record entry 301 in the read / write behavior table T1 as an example, we can first look up the auxiliary table type and auxiliary table index value corresponding to component index value 0 in the read / write behavior table T1, which are Context and 0 respectively. Then, based on the auxiliary table type Context, we select the transaction execution context table Context Table, and based on the auxiliary table index value 0, we look up record entry 303 corresponding to auxiliary table index value 0 in the transaction execution context table Context Table. Then we obtain the encoding type address and path component value Call.sender corresponding to record entry 303. Similarly, based on the read / write behavior table T1, we can also look up record entry 304 corresponding to auxiliary table index value 1 in the transaction execution context table Context Table, and obtain the encoding type address and path component value Call.contract corresponding to record entry 304. By analogy, based on the read / write behavior table T1, we can look up record entry 306 corresponding to auxiliary table index value 2 in the contract constant table Constant Table, and obtain the encoding type str and path component value foo corresponding to record entry 306. Based on the read / write behavior table T1, find record entry 307 corresponding to index value 3 in the auxiliary table from the contract constant table, and obtain the encoding type str and path component value bar corresponding to record entry 307. Based on the read / write behavior table T1, find record entry 305 corresponding to index value 4 in the auxiliary table from the transaction parameter table Arg table, and obtain the encoding type str and path component value Some_nft_id corresponding to record entry 305.

[0055] Finally, after determining the path components and encoding types corresponding to each record entry in the read / write behavior table T1, blockchain node A can encode each path component according to its respective encoding type, thereby obtaining the set of read / write keys corresponding to transaction Tx1 (i.e., the set of read / write addresses accessing the state storage object when executing transaction Tx1). Furthermore, it can obtain the set of read / write targets corresponding to transaction Tx1 based on the read / write target field values ​​in the read / write behavior table T1, thus obtaining the read / write set corresponding to transaction Tx1. For example, taking the read / write behavior table T1 as an example, the table includes a read / write target field. When the read / write target field value is W, it indicates that the read / write category corresponding to the target is "write"; when the read / write target field value is R, it indicates that the read / write category corresponding to the target is "read".

[0056] The following pseudocode example of a smart contract illustrates the solution in this embodiment: Below is a simple pseudocode example of a smart contract named Test:

[0057]

[0058] Referring to the pseudocode above, in the smart contract Test, the state variables involved are "asset1_to_asset2_rate:u32" and "asset1_balances: map".<address, u64> "and asset2_balances: map<address,u64> Furthermore, the smart contract Test includes the methods "Swap4Asset2" (hereinafter referred to as Method 1) and "AdjustRate" (hereinafter referred to as Method 2). During the compilation phase of the smart contract Test, for each method, a table of read / write behaviors and a table of contract constants corresponding to the smart contract Test can be generated. These read / write behavior tables and the contract constant table are then stored in the metadata of the smart contract Test.

[0059] like Figure 3B As shown, the contract constant table can include records corresponding to the variable names "asset1_to_asset2_rate", "asset1_balances", and "asset2_balances" involved in the smart contract Test. The record for the variable name "asset1_to_asset2_rate" records the auxiliary table index value (e.g., 0), encoding type (e.g., str), and path component value (e.g., asset1_to_asset2_rate) corresponding to that variable name. The record for the variable name "asset1_balances" records the auxiliary table index value (e.g., 1), encoding type (e.g., str), and path component value (e.g., asset1_balances) corresponding to that string. The record for the variable name "asset2_balances" records the auxiliary table index value (e.g., 2), encoding type (e.g., str), and path component value (e.g., asset2_balances) corresponding to that string.

[0060] Regarding the read / write behavior table, taking Method 1 as an example, based on the state variables involved in the smart contract Test, the read / write behavior table corresponding to Method 1 includes record entry 1a corresponding to read / write behavior X1 (the read / write behavior of self.state.asset1_to_asset2_rate in line 9 of the pseudocode), record entry 1b corresponding to read / write behavior X2 (the read / write behavior of self.state.asset1_balances[sender] in line 11 of the pseudocode), and record entry 1c corresponding to read / write behavior X3 (the read / write behavior of self.state.asset2_balances[sender] in line 12 of the pseudocode). Among these, the read / write label field value of record entry 1a is R (indicating read-only), and the component index value includes 0. The auxiliary table type corresponding to component index value 0 is a contract constant table, and the index value within the auxiliary table is 0. The read / write label field value of record entry 1b is W (indicating write), and the component index value includes 0 and 1. The auxiliary table type corresponding to component index value 0 is a contract constant table, and the index value within the auxiliary table is 1. The auxiliary table type corresponding to component index value 1 is a transaction execution context table, and the index value within the auxiliary table is 0. The read / write label field value of record entry 1c is W, and the component index value includes 0 and 1. The auxiliary table type corresponding to component index value 0 is a contract constant table, and the index value within the auxiliary table is 2. The auxiliary table type corresponding to component index value 1 is a transaction execution context table, and the index value within the auxiliary table is 0.

[0061] Once a blockchain node receives a transaction TX that invokes the smart contract Test (e.g., transaction TX involves method 1), it can generate a transaction execution context table and a transaction parameter table based on the transaction content of TX. The transaction execution context table includes two records with index values ​​of 0 and 1 respectively from the auxiliary table. The record with index value 0 has an encoding type of, for example, address, and a path component value of, for example, AAA (representing the sender's account, which can be determined based on the transaction content of TX). The record with index value 1 has an encoding type of, for example, address, and a path component value of, for example, BBB (representing the contract address of smart contract Test, which can also be determined based on the transaction content of TX). The transaction parameter table includes one record with an index value of 0 from the auxiliary table. This record has an encoding type of, for example, str, and a path component value of, for example, the value n of the independent variable asset2_amount in TX (which can be determined based on the transaction content).

[0062] Next, the blockchain node can obtain the read / write behavior table corresponding to Method 1. Based on record entry 1a, it obtains the path component value "asset1_to_asset2_rate" corresponding to read / write behavior X1. Based on record entry 1b, it obtains the path component values ​​"asset1_balances" and "AAA" corresponding to read / write behavior X2. Based on record entry 1c, it obtains the path component values ​​"asset2_balances" and "AAA" corresponding to read / write behavior X3.

[0063] Finally, based on the path component values ​​corresponding to each of the above read and write operations and the encoding types corresponding to each path component value, the read and write addresses (i.e., read and write sets) corresponding to each read and write operation can be derived. For example... Figure 4 As shown, Figure 4 The tree structure shown represents a portion of the contract state tree corresponding to the smart contract Test. Node 1 is the root of the contract state tree. Based on the path component value "asset1_to_asset2_rate" corresponding to read / write action X1, node 2 can be located in the contract state tree. Node 2 stores the state value corresponding to "asset1_to_asset2_rate". Based on the path component values ​​"asset1_balances" and "AAA" corresponding to read / write action X2, node 3 can be located in the contract state tree. Node 3 stores the state value corresponding to "asset1_balances" for account AAA. Based on the path component values ​​"asset2_balances" and "AAA" corresponding to read / write action X3, node 4 can be located in the contract state tree. Node 4 stores the state value corresponding to "asset2_balances" for account AAA.

[0064] It should be noted that this pseudocode example does not use the Arg Table for transaction parameters. However, in some cases, such as when the transaction parameters include an account, the Arg Table is necessary. Specifically, in some scenarios, if account A transfers funds to account B, the transaction parameters will include account B's address. When updating account B's balance status, the Arg Table is used to retrieve the path component corresponding to account B.

[0065] In some embodiments, after obtaining the read / write sets corresponding to transactions Tx1-Txn, blockchain node A can further group transactions Tx1-Txn based on the read / write set corresponding to transaction Tx1, resulting in multiple transaction groups for parallel execution. For example, based on the read / write sets corresponding to each of transactions Tx1-Txn, transactions with dependencies can be grouped into the same group, thus obtaining multiple transaction groups. The read / write sets of the multiple dependent transactions include at least one read / write key with the same address, and at least one of these read / write keys with the same address is a write key.

[0066] Specifically, firstly, read / write keys corresponding to the read / write category "read" can be removed from each read / write set corresponding to each of transactions Tx1-Txn. Then, based on the updated read / write sets of transactions Tx1-Txn, at least one set of multiple transactions with the same address read / write key (i.e., multiple transactions with a dependency relationship) can be grouped into the same group to complete the grouping of these transactions.

[0067] This specification provides a method for obtaining transaction read / write sets in a blockchain. By acquiring transaction data corresponding to multiple received transactions, and then obtaining read / write behavior information for each transaction, a read / write set corresponding to each of the multiple first transactions is determined based on the read / write behavior information and the transaction data, thereby improving the efficiency of obtaining the transaction read / write set. Furthermore, the transactions can be grouped according to their respective read / write sets, further reducing the computational load and storage resources required for transaction grouping, improving the rationality of transaction grouping, and contributing to increased parallelism in transaction execution.

[0068] It should be noted that although the operations of the methods of the embodiments of this specification are described in a specific order in the above embodiments, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowcharts may be executed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0069] Corresponding to the aforementioned embodiments of the transaction read / write set acquisition method in blockchain, this specification also provides embodiments of blockchain nodes.

[0070] like Figure 5 As shown, Figure 5 This specification illustrates a block diagram of a blockchain node according to an exemplary embodiment. The blockchain node may include: a receiving unit 501, an obtaining unit 503, and a determining unit 505.

[0071] The receiving unit 501 is used to receive multiple first transactions and obtain the transaction data corresponding to each of the multiple first transactions, wherein the multiple first transactions are transactions that call the contract.

[0072] The acquisition unit 503 is used to acquire read / write behavior information corresponding to each of the multiple first transactions from the metadata of each contract, based on the contracts invoked by each of the multiple first transactions. The read / write behavior information corresponding to any first transaction includes information on access to state data in the contract methods involved in that first transaction.

[0073] The determining unit 505 is used to determine the read and write sets corresponding to each of the multiple first transactions based on the read and write behavior information and the transaction data corresponding to each of the multiple first transactions.

[0074] In some implementations, the read / write set corresponding to any first transaction includes a set of read / write addresses of the state storage object accessed when the first transaction is executed.

[0075] In other implementations, the blockchain node may also include: a grouping unit (not shown in the figure).

[0076] The grouping unit is used to group the multiple first transactions into multiple transaction groups based on the read / write sets corresponding to each of the multiple first transactions, so as to execute the multiple transaction groups in parallel.

[0077] In other implementations, the transaction data corresponding to any first transaction includes the contract address of the contract invoked by the first transaction and the method name of the contract method involved in the first transaction.

[0078] Specifically, the acquisition unit 503 can obtain the read / write behavior information corresponding to any first transaction in the following manner: based on the contract address of the contract called by the first transaction and the method name of the contract method involved in the first transaction, it obtains the read / write behavior information corresponding to the contract method involved in the first transaction from the metadata of the contract called by the first transaction. The read / write behavior information corresponding to the contract method is obtained in advance based on static analysis of the contract code by the compiler.

[0079] In other embodiments, the determining unit includes an acquisition subunit and a determining subunit (not shown in the figure).

[0080] The acquisition sub-unit is used to acquire auxiliary information corresponding to each of the multiple first transactions based on the transaction data corresponding to each of the multiple first transactions. The auxiliary information includes at least the following auxiliary tables: transaction execution context table, transaction parameter table, and contract constant table.

[0081] The determination subunit is used to determine the read / write set corresponding to each of the multiple first transactions based on the read / write behavior information and auxiliary information corresponding to each of the multiple first transactions.

[0082] In other implementations, the transaction data corresponding to any first transaction includes the contract address of the contract invoked by the first transaction, the method name of the contract method involved in the first transaction, the transaction parameter information and sender information corresponding to the first transaction.

[0083] The acquisition subunit is configured to: generate a list of transaction execution contexts corresponding to each of the multiple first transactions based on the sender information included in the transaction data; generate a list of transaction parameters corresponding to each of the multiple first transactions based on the transaction parameter information included in the transaction data; and obtain a list of contract constants corresponding to each of the multiple first transactions from the metadata of the contracts called by each of the multiple first transactions, based on the contract addresses and contract method names involved in the contracts called by each of the multiple first transactions.

[0084] In other embodiments, the read / write behavior information corresponding to any first transaction includes record entries for multiple read / write behaviors corresponding to the first transaction. Each record entry for a read / write behavior records the auxiliary table type and the index value within the auxiliary table corresponding to that read / write behavior. The auxiliary table is used to record the index value, encoding type, and path component within the auxiliary table corresponding to the read / write behavior in a related manner.

[0085] The determining subunit is configured to: determine, based on the read / write behavior information corresponding to each of the multiple first transactions, the record entries for each read / write behavior corresponding to each of the multiple first transactions, the auxiliary table type recorded for each entry, and the auxiliary table index value corresponding to that auxiliary table type; based on the auxiliary table type recorded for each read / write behavior and the auxiliary table index value corresponding to that auxiliary table type, find the path component corresponding to each read / write behavior and the encoding type corresponding to each path component from the auxiliary information; and based on the path component corresponding to each read / write behavior and the encoding type corresponding to each path component, determine the read / write set corresponding to each of the multiple first transactions.

[0086] In other embodiments, the grouping unit is configured to: group multiple first transactions that have a dependency relationship into the same group based on the read and write sets corresponding to each of the multiple first transactions, thereby obtaining multiple transaction groups.

[0087] In other implementations, the read / write set corresponding to any first transaction includes read / write categories, and the grouping unit groups the first transactions with dependencies into the same group in the following manner: removing read-only read / write keys from the multiple read / write sets corresponding to multiple first transactions, and grouping the multiple transactions based on the updated read / write sets of the multiple transactions.

[0088] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of one or more embodiments of this specification, depending on actual needs. Those skilled in the art can understand and implement this without creative effort.

[0089] This specification also provides one or more embodiments of a computer-readable storage medium storing a computer program that can be used to perform the above-described actions. Figure 2 The embodiment provides a method for obtaining transaction read / write sets in a blockchain.

[0090] One or more embodiments of this specification also provide a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the above-described... Figure 2 The transaction read / write set acquisition method provided in any embodiment.

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

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

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

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

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

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

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

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

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

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

[0101] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic 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.

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

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

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

[0105] 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 obtaining a transaction read / write set in a blockchain, the method being executed by a blockchain node, the method comprising: Receive multiple first transactions and obtain the transaction data corresponding to each of the multiple first transactions; The multiple first transactions are transactions that invoke contracts; Based on the contracts invoked by each of the multiple first transactions, read and write behavior information corresponding to each of the multiple first transactions is obtained from the metadata of each contract; the read and write behavior information corresponding to any first transaction includes information on accessing state data in the contract methods involved in the first transaction; Based on the read / write behavior information and transaction data corresponding to each of the plurality of first transactions, the read / write set corresponding to each of the plurality of first transactions is determined.

2. The method of claim 1, wherein, The read / write set corresponding to any first transaction includes the set of read / write addresses of the state storage object accessed when the first transaction is executed.

3. The method of claim 1, wherein, The method further includes: grouping the multiple first transactions into multiple transaction groups based on the read / write sets corresponding to each of the multiple first transactions, so as to execute the multiple transaction groups in parallel.

4. The method of claim 1, wherein, The transaction data corresponding to any first transaction includes the contract address of the contract invoked by the first transaction and the method name of the contract method involved in the first transaction; Specifically, the read and write behavior information corresponding to any first transaction is obtained in the following way: based on the contract address of the contract called by the first transaction and the method name of the contract method involved in the first transaction, the read and write behavior information corresponding to the contract method involved in the first transaction is obtained from the metadata of the contract called by the first transaction; the read and write behavior information corresponding to the contract method is obtained in advance based on static analysis of the contract code by the compiler.

5. The method according to claim 1, wherein determining the read / write set corresponding to each of the plurality of first transactions based on the read / write behavior information corresponding to each of the plurality of first transactions and the transaction data corresponding to each of the plurality of first transactions comprises: Based on the transaction data corresponding to each of the plurality of first transactions, obtain the auxiliary information corresponding to each of the plurality of first transactions; The auxiliary information includes at least the following auxiliary tables: transaction execution context table, transaction parameter table, and contract constant table; Based on the read / write behavior information corresponding to each of the plurality of first transactions and the auxiliary information, the read / write set corresponding to each of the plurality of first transactions is determined.

6. The method of claim 5, wherein, The transaction data corresponding to any first transaction includes the contract address of the contract called by the first transaction, the method name of the contract method involved in the first transaction, the transaction parameter information and sender information corresponding to the first transaction; The step of obtaining auxiliary information corresponding to each of the plurality of first transactions based on the transaction data corresponding to each of the plurality of first transactions includes: Based on the sender information included in the transaction data, a transaction execution context list corresponding to each of the plurality of first transactions is generated; Based on the transaction parameter information included in the transaction data, a transaction parameter list corresponding to each of the plurality of first transactions is generated; Based on the contract addresses and contract method names of the contracts invoked by each of the multiple first transactions, the list of contract constants corresponding to each of the multiple first transactions is obtained from the metadata of the contracts invoked by each first transaction.

7. The method of claim 5, wherein, The read / write behavior information corresponding to any first transaction includes record entries for multiple read / write behaviors corresponding to the first transaction. Each record entry for a read / write behavior records the auxiliary table type and the index value within the auxiliary table corresponding to that read / write behavior. The auxiliary table is used to record the index value, encoding type, and path component within the auxiliary table corresponding to the read / write behavior in a related manner. The step of determining the read / write set corresponding to each of the plurality of first transactions based on the read / write behavior information corresponding to each of the plurality of first transactions and the auxiliary information includes: Based on the read and write behavior information corresponding to each of the multiple first transactions, determine the record entries for each read and write behavior corresponding to each of the multiple first transactions, and record the auxiliary table type and the index value in the auxiliary table corresponding to the auxiliary table type. Based on the auxiliary table type and the index value in the auxiliary table corresponding to the record entry of each read and write behavior, the path component corresponding to each read and write behavior and the encoding type corresponding to each path component are found from the auxiliary information. Based on the path components corresponding to each of the read and write operations, and the encoding type corresponding to each path component, the read and write sets corresponding to each of the multiple first transactions are determined.

8. The method of claim 3, wherein, The step of grouping the multiple first transactions into multiple transaction groups based on their respective read / write sets includes: grouping the multiple first transactions into the same group based on their respective read / write sets to obtain the multiple transaction groups.

9. The method of claim 8, wherein, The read / write set corresponding to any first transaction includes read / write categories. The first transactions with dependencies are grouped into the same group. Read-only read / write keys in the multiple read / write sets corresponding to the multiple first transactions are removed. The multiple transactions are grouped based on the updated read / write sets of the multiple transactions.

10. A blockchain node, comprising: A receiving unit is configured to receive multiple first transactions and obtain transaction data corresponding to each of the multiple first transactions; The multiple first transactions are transactions that invoke contracts; The acquisition unit is used to acquire read and write behavior information corresponding to each of the multiple first transactions from the metadata of each of the contracts invoked by each of the multiple first transactions; the read and write behavior information corresponding to any first transaction includes information on access to state data in the contract methods involved in the first transaction; The determining unit is used to determine the read / write set corresponding to each of the plurality of first transactions based on the read / write behavior information corresponding to each of the plurality of first transactions and the transaction data corresponding to each of the plurality of first transactions.

11. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-9.

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

Images