Transaction processing method in block chain system and block chain node

Abstract

The invention discloses a transaction processing method in a block chain system and a block chain node. The method comprises the following steps: determining a transaction type of a first transaction and / or feature information of the first transaction; determining whether a target analysis rule matched with the transaction type and / or the feature information exists in a plurality of pre-configured read-write key analysis rules or not; and if yes, determining a read-write key of the first transaction according to the target analysis rule.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of computer technology, and more particularly, to a transaction processing method and a blockchain node in a blockchain system. Background Art

[0002] The blockchain system is a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, and cryptographically guaranteed to be tamper-proof and unforgeable. Due to its decentralized, tamper-proof, and autonomous nature, blockchain systems are gaining increasing attention and application. Summary of the Invention

[0003] The purpose of the present invention is to provide a transaction processing method and a blockchain node in a blockchain system.

[0004] In a first aspect, a transaction processing method in a blockchain system is provided, the method comprising: determining a transaction type of a first transaction and / or characteristic information of the first transaction; determining whether there is a target analysis rule that matches the transaction type and / or the characteristic information among several pre-configured read-write key analysis rules; if so, determining the read-write key of the first transaction according to the target analysis rule.

[0005] In a second aspect, a blockchain node in a blockchain system is provided, wherein the blockchain node includes: a transaction analysis unit, configured to determine the transaction type of a first transaction and / or characteristic information of the first transaction; a rule matching unit, configured to determine whether there is a target analysis rule that matches the transaction type and / or the characteristic information among several pre-configured read-write key analysis rules, and if so, triggering the read-write analysis unit; the read-write analysis unit is configured to determine the read-write key of the first transaction according to the target analysis rule under the triggering of the rule matching unit.

[0006] In a third aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method described in the first aspect is implemented.

[0007] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computing device, the computing device executes the method described in the first aspect.

[0008] In the technical solution provided by the embodiments of this specification: by pre-configuring a plurality of read-write key analysis rules, when it is possible to determine a target analysis rule that matches the transaction type and / or feature information of a transaction from the plurality of read-write key analysis rules, the read-write key of the first transaction can be quickly determined according to the determined target analysis rule, without expending excessive resources on pre-execution of each transaction, which is beneficial to improving the overall performance of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0010] Figure 1 This is an architectural diagram of a blockchain system exemplified in the embodiments of this specification;

[0011] Figure 2 A schematic diagram of a transaction processing process in a blockchain system provided in an embodiment of this specification;

[0012] Figure 3 A flowchart of a method for managing rule application information in a blockchain system is provided as an example;

[0013] Figure 4 This is a flowchart of a transaction processing method in a blockchain system provided in an embodiment of this specification;

[0014] Figure 5 This is a schematic diagram of the structure of a blockchain node in a blockchain system provided in an embodiment of this specification. DETAILED DESCRIPTION

[0015] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative work should fall within the scope of protection of this specification.

[0016] Figure 1 This is an architectural diagram of a blockchain system provided as an example in the embodiments of this specification. The blockchain system may include N blockchain nodes, where Figure 18 blockchain nodes, Node 1 to Node 8, are shown as examples. The lines between the nodes schematically represent the connections between the nodes, which are used to support data transmission between different nodes.

[0017] Blockchain systems offer smart contract functionality. Smart contracts in blockchain systems are contracts that can be triggered and executed by transactions, defined in the form of contract code. Calling a smart contract in a blockchain system involves initiating a transaction pointing to the smart contract's address, causing the blockchain nodes in the system to execute the corresponding contract code in a distributed manner.

[0018] In various blockchain systems that introduce smart contracts, accounts can generally be divided into two types:

[0019] Contract account (CA): Mainly used to store the contract code of the corresponding smart contract and the values of the state variables defined in the smart contract. It can usually only be activated by calling an external account;

[0020] Externally owned account (EOA): An account registered by an external user in the blockchain system.

[0021] The design of external accounts and contract accounts is essentially a mapping of account addresses to account states. The account state of any account typically includes fields such as nonce, balance, storageRoot, and codeHash. While nonce and balance exist in both external and contract accounts, codeHash and storageRoot are generally only valid for contract accounts.

[0022] More specifically, for external accounts, the nonce value represents the number of transactions sent from the relevant account address; for contract accounts, the nonce value can represent the number of smart contracts created by the relevant account address. The Balance value represents the number of certain digital resources / tokens owned by the relevant account address. The value of Storage root is the hash value of the root node of a tree structure, such as an MPT tree. This MPT tree is used to organize / manage the storage of state variables of the relevant contract account. The CodeHash value represents the hash value of the contract code of the relevant smart contract. For external accounts, since smart contracts are not included, the values of the storageRoot and CodeHash fields can generally be empty strings / all-0 strings.

[0023] It's important to note that MPT, short for Merkle Patricia Tree, is a tree structure that combines the Merkle Tree and the Patricia Tree (a compressed prefix tree, a more space-efficient dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then hashes them again for each transaction until the top-level Merkle root is reached. Some blockchain systems often use a modified MPT tree, such as a hexadecimal tree structure, often referred to as an MPT tree.

[0024] The system data that needs to be persistently stored in the blockchain system can be divided into two parts: block data and status data.

[0025] Block data includes one or more blocks incremented by block height (or block number). A single block can include a block header and a block body. The block header may include the previous block's block hash (or parent hash), timestamp, block number (BlockNum), state root hash (State_Root), transaction root hash (Transaction_Root), receipt root hash (Receipt_Root), and random number (nonce). The block body may include a transaction set and a receipt set.

[0026] A transaction in a blockchain system is a unit of work executed and recorded within the blockchain system. A single transaction may include, but is not limited to, one or more of the following fields: a From field, a To field, a Data field, a Value field, a Nonce field, and a Digital Signature field.

[0027] For any Nth block, multiple transactions in the target transaction sequence of block N can be executed based on the state data with block number (or version number) N-1 to obtain the execution results of these multiple transactions. Furthermore, the state data with version number N-1 is updated based on the execution results of these multiple transactions to obtain state data with version number N.

[0028] Some blockchain systems may use an asynchronous pipeline mechanism to concurrently process multiple block generation transactions corresponding to multiple blocks. Block generation transactions may include, but are not limited to, consensus processing transactions (primarily including reaching consensus on the consensus proposal corresponding to the block to be generated, ultimately obtaining a target transaction sequence that is allowed to be packaged into a block), transaction execution transactions (primarily including executing transactions in the target transaction sequence), and block submission transactions (primarily including generating and persisting blocks based on the execution results of the target transaction sequence). Typically, the read-write keys of transactions can be obtained by pre-executing the transactions before they are executed. When multiple transactions in a target transaction sequence need to be executed, the multiple transactions can be divided into multiple transaction groups based on their respective read-write keys. For example, transactions with read-write conflicts can be grouped into the same transaction group, and the transactions in the multiple transaction groups can be executed concurrently by multiple computing services.

[0029] For a single transaction, the resources required for pre-execution (e.g., computing resources, storage resources, and time resources) are relatively high. For example, due to the lack of prior read and write key information for the transaction, the CPU needs to perform a large amount of on-demand IO, wasting a large amount of computing, storage, and time resources, which will affect the performance of the blockchain system.

[0030] The embodiments of this specification provide a transaction processing method, blockchain node, computing device, and computer-readable storage medium in a blockchain system. First, the transaction type and / or characteristic information of a first transaction are determined. Next, a target analysis rule is determined among several pre-configured read / write key analysis rules to match the transaction type and / or characteristic information of the first transaction. If so, the read / write key of the first transaction is determined based on the target analysis rule.

[0031] In this way, by pre-configuring several read-write key analysis rules in the blockchain system, when it is possible to determine a target analysis rule that matches the transaction type and / or feature information of a transaction from the several read-write key analysis rules based on the transaction type and / or feature information of a transaction, the read-write key of the first transaction can be quickly determined according to the determined target analysis rule, without spending too many resources on pre-execution of each transaction, which is beneficial to improving the overall performance of the blockchain system.

[0032] Figure 2 This is a schematic diagram of a transaction processing process in a blockchain system provided as an example in the embodiments of this specification. Figure 2As shown, when a blockchain node needs to analyze the read-write keys of a transaction, if it can match a target analysis rule among several pre-configured read-write key rules based on the transaction type and / or feature information, the read-write key of the transaction can be calculated based on the target analysis rule. If the target analysis rule is not matched, the read-write key of the transaction can be obtained by pre-executing the transaction. In the subsequent process, multiple transactions can still be executed concurrently based on the read-write keys of multiple transactions.

[0033] The inventors have discovered that transactions in a blockchain system can generally be categorized into several types: ordinary transfer transactions (used to transfer native resources in the blockchain system between different external accounts), contract deployment transactions (used to deploy new smart contracts in the blockchain system), and contract call transactions (used to call smart contracts already deployed in the blockchain system). For ordinary transfer transactions, the read key includes the From field and the account address included in the To field of the transaction; the write key includes the From field and the account address included in the To field of the transaction. For contract deployment transactions, the read key includes the account address included in the From field of the transaction; the write key includes the account address included in the From field of the transaction. For contract call transactions, if the smart contract called by the transaction is a standard contract, such as an EIP (Ethereum Improvement Proposals) standard contract, the keys of the state variables within the smart contract that need to be read / written during the execution of certain method functions in the standard contract are obtained by processing the input parameters of the method functions based on a deterministic calculation process. Therefore, deterministic read-write key analysis rules can be configured for certain method functions in the standard contract so that the read-write keys of the relevant contract call transactions can be calculated using the configured read-write key analysis rules.

[0034] The aforementioned EIP standard contracts may include, but are not limited to, smart contracts using the Tangerine Whistle, ERC-20, ERC-721, and Skinny CREATE2 protocols. This description uses the ERC-20 smart contract Token SC1 as an example. Token SC1 may include a method function with the function identifier "a9059cbb," which is used to support the transfer of tokens (e.g., Token1) issued by Token SC1 between different account addresses. For a contract call transaction (denoted as Tx1) that calls the method function "a9059cbb" in Token SC1, assuming that Tx1 is used to transfer Token1 held by account address a1 to account address a2, the From field of Tx1 includes account address a1, the To field includes the contract address of Token SC1, and the Data field includes the function identifier "a9059cbb" and input parameters. The input parameters here include account address a2 and the share s1 of Token1 to be transferred from account address a1 to account address a2. The read key for Tx1 typically includes: the account address a1 included in the From field of Tx1, the hash value of the contract code of Token SC1 (i.e., CodeHash), from_slot, and recipient_slot. The write key for Tx1 typically includes: the account address a1 included in the From field of Tx1, from_slot, and recipient_slot. The value of from_slot is used to indicate the share of Token 1 held by account address a1 in Token SC1, and the value of recipient_slot is used to indicate the share of Token 1 held by account address a2 in Token SC1. The calculation of from_slot depends on the storage slot of the state variable _balances defined in Token SC1 and the account address a1 included in the From field of Tx1. The calculation of recipient_slot depends on the storage slot of the state variable _balances and the account address a2 in the input parameter. Among them, from_slot and recipient_slot usually also use the contract address of Token SC1 as a prefix, and the storage slot of _balances can be determined based on the declaration position of _balances in Token SC1.

[0035] In this way, the contract address and function identifier "a9059cbb" of Token SC1 can be used as a characteristic information P1, or the metadata hash and function identifier "a9059cbb" of Token SC1 can be used as a characteristic information P1, and a read-write key analysis rule L1 that can match the characteristic information P1 is pre-configured in the blockchain system. The read-write key analysis rule L1 specifically defines: for a contract call transaction used to call the method function "a9059cbb" in Token SC1, a calculation logic for calculating several read-write keys based on at least part of the information included in at least part of the fields in the contract call transaction, that is, the calculation logic can be used to calculate, according to the transaction Tx1 in the aforementioned example, the read key of Tx1 including: the account address a1 included in the From field of Tx1, the CodeHash of the contract code of Token SC1, from_slot and recipient_slot; and the write key of Tx1 including: the account address a1, from_slot and recipient_slot included in the From field of Tx1.

[0036] It's understandable that the aforementioned read-write key analysis rule L1 can match not only feature information P1 but also other feature information. For example, a blockchain system might deploy a smart contract called Token SC2 that uses the ERC20 protocol. Token SC2 also includes a method function with the function identifier "a9059cbb," which supports the transfer of tokens (e.g., Token2) issued by Token SC2 between different account addresses. Therefore, the contract address of Token SC2 and the function identifier "a9059cbb" might constitute feature information P2 that matches read-write key analysis rule L1.

[0037] The previous article exemplifies the process of configuring the read-write key analysis rule L1 for a specific method function in a specific standard contract. In fact, other read-write key analysis rules can also be configured for other method functions in the standard contract, which will not be described in detail here.

[0038] In specific technical scenarios, multiple contract deployers often deploy multiple smart contracts in a blockchain system. For example, Contract Deployer 1 may deploy Token SC1, while Contract Deployer 2 may deploy Token SC2. Method functions implemented in different smart contracts for the same transaction, such as the method function "a9059cbb" in Token SC1 used to transfer Token 1 between different account addresses, and the method function "a9059cbb" in Token SC2 used to transfer Token 2 between different account addresses, may utilize the same read-write key analysis rules to calculate the read-write keys for the contract call transaction invoking the method function "a9059cbb." Contract deployers have a better understanding of the specific read-write key analysis rules that apply to each method function in their provisioned smart contract. Therefore, they can configure one or more rule application information for one or more method functions in their provisioned smart contracts. Based on this rule application information, the correct read-write key analysis rules are matched to the relevant contract call transactions, enabling widespread application of the pre-configured read-write key analysis rules and further improving the performance of the blockchain system.

[0039] Figure 3 This is a flowchart illustrating a method for managing rule application information in a blockchain system. This method can be executed by a blockchain node in the blockchain system. In addition to pre-configuring several read-write key analysis rules, the blockchain system can also deploy a smart contract (i.e., a second smart contract) for managing rule application information. This method exemplifies the process of managing rule application information corresponding to method functions in a first smart contract through a second smart contract.

[0040] Reference Figure 3 As shown, the method may include but is not limited to part or all of the following steps S301 to S307.

[0041] Step S301: Receive a second transaction for calling a second smart contract, where the second transaction includes a first contract address of a first smart contract and registration information of the first smart contract.

[0042] The first smart contract can typically be a standard contract. The following description will primarily use the example of the first smart contract, Token SC2, a standard contract using the ERC20 protocol, as described above. For example, when a contract deployer uses its account address a3 to initiate a contract deployment transaction, such as transaction Tx2, to the blockchain system through a corresponding client to deploy Token SC2, the blockchain system can complete the deployment of Token SC2 by executing transaction Tx2. If the contract deployer with account address a3 wishes to register the rule application information Y1 corresponding to a method function in Token SC2, such as the method function with the function identifier "a9059cbb," with a second smart contract, the contract deployer can continue to use account address a3 to initiate a second transaction to the blockchain system to invoke the first smart contract.

[0043] The From field of the second transaction includes the account address a3, the To field includes the contract address of Token SC2, and the Data field may include the function identifier of the method function (denoted as method function F1) used to register the rule application information in the second smart contract and the input parameters of method function F1. The input parameters may include but are not limited to the contract address of Token SC2 and the registration information of Token SC2, and may also include part or all of the information in the rule application information Y1.

[0044] Blockchain systems may provide multiple contract deployment methods. For example, Ethereum or blockchain systems with similar architectures typically offer two contract deployment methods, CREATE and CREATE2, providing two opcodes, CREATE and CREATE2, to deploy smart contracts. When using the CREATE contract deployment method to deploy the smart contract Token SC2, the contract address of Token SC2 is typically a hash value calculated from the account address a3 in the From field of the transaction Tx2 used to deploy Token SC2, and the value of the nonce field in the transaction Tx2. When using the CREATE2 contract deployment method to deploy the smart contract Token SC2, the contract address of Token SC2 is typically a hash value calculated from the account address a3 in the From field of the transaction Tx2 used to deploy Token SC2, the salt value (SALT), and the CodeHash of the contract code of Token SC2. Therefore, when the contract deployment method CREATE is adopted, the registration information of Token SC2 may include: the operation code / method identifier CREATE, and the value included in the Nonce field of transaction Tx2; when the contract deployment method CREATE2 is adopted, the registration information of Token SC2 may include: the operation code / method identifier CREATE2, the salt value (SALT) and the CodeHash of the contract code of Token SC2.

[0045] Step S303: Execute the second smart contract according to the second transaction, calculate the current contract address according to the registration information of the first smart contract, and store the target rule application information when the current contract address is the same as the first contract address of the first smart contract, wherein the target rule application information includes feature information, the target account address for initiating the second transaction, and rule indication information for indicating the target analysis rule.

[0046] Continuing with the above example, when the registration information of Token SC2 includes the method identifier CREATE and the value of the Nonce field in the transaction Tx2 used to deploy Token SC2, the current contract address can be calculated based on the account address included in the From field of the second transaction and the value of the Nonce field in the transaction Tx2. When the registration information of Token SC2 includes the method identifier CREATE2, a salt value (SALT), and the CodeHash of the contract code corresponding to Token SC2, the current contract address can be calculated based on the account address included in the From field of the second transaction, the salt value (SALT), and the CodeHash of the contract code corresponding to Token SC2. If the calculated current hash value is the same as the contract address of Token SC2 included in the second transaction, it means that the second transaction was indeed initiated by the contract deployer of Token SC2. The initiator of the second transaction has the permission to register rule application information for one or more method functions in Token SC2 and can store the rule application information Y1 that the second transaction intends to register, for example, in the contract state.

[0047] For example, referring to the data structure of the rule application information Y1 shown in the following example, the rule application information Y1 may include, but is not limited to, one or more of the following information:

[0048]

[0049] In the aforementioned example rule application information Y1, the function identifier and contract address can constitute the feature information, or the hash value of the smart contract's metadata can constitute the feature information together with the function identifier. When the programming language Solidity is used to write the source code of a smart contract, and the source code is compiled by the Solidity compiler to obtain the contract code, the Solidity compiler automatically generates a JSON file for the smart contract, which includes the smart contract's metadata. The metadata can be used to query the Solidity compiler version, the source code used by the contract code, and so on. The hash value of the metadata will be embedded in the contract code.

[0050] The Data field of the second transaction can include the complete rule application information Y1. If the calculated current contract address is the same as the contract address of Token SC2, it can be determined whether the account address included in the adder_ field of the rule application information Y1 is the same as the account address included in the From field of the second transaction. If so, the rule application information Y1 is stored.

[0051] In the rule application information Y1 included in the Data field of the second transaction, the value of the adder_ field can be empty. When the calculated current contract address is the same as the contract address of Token SC2, the account address included in the From field of the second transaction is added to the adder_ field of the rule application information Y1 to obtain and store the complete rule application information Y1.

[0052] A blockchain system may employ asynchronous pipelines to concurrently process multiple block generation transactions corresponding to multiple blocks. Specifically, the blockchain system may utilize separate services to implement read-write key analysis transactions and transaction execution transactions. In this case, the transaction execution service may also generate corresponding rule management events. The service implementing the read-write key analysis transaction can then learn about the registration and management of rule application information Y1 through these rule management events.

[0053] The contract deployer of the first smart contract may desire to manage the registered rule application information on demand, such as changing the state of the target rule application information from the effective state to another state, deleting the target rule application information, etc. Therefore, based on the aforementioned steps S301 and S303, the blockchain node may also execute the following steps S305 and S307.

[0054] Step S305: Receive a third transaction for invoking the second smart contract, where the third transaction includes a management instruction corresponding to the target rule application information.

[0055] Continuing with the previous example, the contract deployer holding account address a3 may wish to manage the registered target rule application information Y1 on demand due to updates, deletions, or other reasons associated with Token SC2. In this case, the contract deployer of Token SC2 can use its account address a3 to send a third transaction to the blockchain system through the corresponding client to invoke the second smart contract. More specifically, the From field of the third transaction includes the account address a3, the To field includes the contract address of the second smart contract, and the Data field includes the function identifier of the method function (denoted as method function F2) in the second smart contract for managing rule application information, as well as the input parameters of method function F2. The input parameters may include the identification information of the target rule application information Y1 and corresponding management instructions. The management instructions may, for example, be used to instruct the target rule application information to change its state to a desired target state or to instruct the target rule application information to be deleted.

[0056] Step S307: Execute the second smart contract based on the third transaction to determine whether the account address used to initiate the third transaction is the same as the target account address. If so, manage the target rule application information according to the management instruction.

[0057] When the account address initiating the third transaction, that is, the account address included in the From field of the third transaction, is the same as the target account address included in the target rule application information, for example, the same as the account address included in the adder_ field in the target rule application information, it means that the initiator of the third transaction has the management authority to manage the target rule application information. In this case, according to the management instructions included in the third transaction, corresponding management operations can be performed on the target rule application information, such as deleting the target rule application information from the contract state of the second smart contract or modifying the state of the target rule application information.

[0058] The preceding description illustrates the process of registering target rule application information for a method function in a smart contract and managing this target rule application information in a blockchain system through a second smart contract. However, it is understood that the process described in steps S301 through S307 can be performed one or more times to register multiple rule application information for multiple method functions in multiple smart contracts and manage the registered rule application information in a blockchain system.

[0059] The preceding example illustrates the use of rule application information to describe the mapping relationship between read-write key analysis rules and feature information, and the process of registering and managing rule application information on demand in the blockchain system through a second smart contract. It is understood that in specific technical scenarios, the mapping relationship between feature information and read-write key analysis rules may also be preconfigured in the blockchain system.

[0060] The following describes the process of analyzing the read-write keys of a transaction using several pre-configured read-write key analysis rules.

[0061] Figure 4 This is a flowchart of a transaction processing method in a blockchain system provided in an embodiment of this specification. The method can be executed by a blockchain node in the blockchain system, and the blockchain node is pre-configured with several read-write key analysis rules.

[0062] Reference Figure 4 As shown, the method may include but is not limited to part or all of the following steps S401 to S403.

[0063] Step S301: Determine the transaction type of a first transaction and / or characteristic information of the first transaction.

[0064] The transaction type of the first transaction may be determined based on the data structure of the first transaction itself.

[0065] If the To field of the first transaction is null, it can be determined that the transaction type of the first transaction is a contract deployment transaction.

[0066] If the To field of the first transaction is not empty, it is possible to continue to determine whether the account address included in the To field of the first transaction is a contract address. If so, the characteristic information of the first transaction is determined. If not, the transaction type of the first transaction is directly determined to be an ordinary transfer transaction. Referring to the above, for the characteristic information of the first transaction, the function identifier of the method function that the first transaction expects to call can be obtained from the Data field of the first transaction, and the contract address included in the To field of the first transaction and the obtained function identifier are used to form the characteristic information of the first transaction; or, based on the contract address included in the To field of the first transaction, the metadata hash of the smart contract can be obtained from the contract code of the smart contract called by the first transaction, and the contract address and metadata hash included in the To field of the first transaction are used to form the characteristic information of the first transaction.

[0067] Step S303: Determine whether there is a target analysis rule that matches the transaction type of the first transaction and / or the feature information of the first transaction among the pre-configured read-write key analysis rules.

[0068] The multiple read-write key analysis rules may include, but are not limited to, one or more of the following rules: a first read-write key analysis rule that matches ordinary transfer transactions, used to indicate that the account address included in the From field and To field of the transaction is determined as the read key, and the account address included in the From field and To field of the transaction is determined as the write key; a second read-write key analysis rule that matches contract deployment transactions, used to indicate that the account address included in the From field of the transaction is determined as the read key and the write key; at least one third read-write key analysis rule that matches at least one feature information, the third read-write key analysis rule being used to define the calculation logic for calculating multiple read-write keys based on at least part of the information included in at least part of the fields in the transaction.

[0069] When the transaction type of the first transaction is a common transfer transaction, the target analysis rule may be a first read-write key analysis rule.

[0070] When the transaction type of the first transaction is a contract deployment transaction, the target analysis rule may be the second read-write key analysis rule.

[0071] When the transaction type of the first transaction is a contract call transaction, a query can be made to see whether there is target rule application information matching the characteristic information of the first transaction among the multiple rule application information stored at the current moment. As previously mentioned, the target rule application information is registered by the developer of the first smart contract to the second smart contract, and the contract address included in the To field of the first transaction is the contract address of the first smart contract. When the target rule application information exists and is in effect, the third read-write key analysis rule indicated by the target rule application information is determined as the target analysis rule.

[0072] Continuing with the above example, it is assumed that the From field of the first transaction includes the account address a1, the To field includes the contract address of the smart contract Token SC2, and the Data field includes the function identifier "a9059cbb" and input parameters. The input parameters include the account address a2 and the share s2 of Token2 that is expected to be transferred from account address a1 to account address a2. The characteristic information of the first transaction may include the contract address of Token SC2 and the function identifier "a9059cbb". Based on this characteristic information, the rule application information Y1 in the above example may be matched. When the rule application information Y1 is in an effective state, for example, when the value of the state_ field in the rule application information Y1 is 0, the read-write key analysis rule indicated by the rule indication information in the rule application information Y1, for example, the read-write key analysis rule L1 indicated by the rule identifier L1 included in the type_ field in the rule application information Y1, can be determined as the target analysis rule that matches the characteristic information of the first transaction.

[0073] As previously mentioned, blockchain nodes may also pre-configure mappings between feature information and read-write key analysis rules. In this case, when the first transaction type is a contract call transaction, the pre-configured mappings may be queried to determine whether a target mapping relationship exists that includes the feature information of the first transaction. If so, the read-write key analysis rule indicated by the target mapping relationship is determined as the target analysis rule that matches the feature information of the first transaction.

[0074] Step S305: Determine the read and write keys of the first transaction according to the target analysis rule.

[0075] The target analysis rule describes the calculation logic for calculating the read-write key based on the data structure of the transaction itself, so the read-write key of the first transaction can be directly determined based on the target analysis rule without pre-execution of the first transaction.

[0076] Continuing with the above example, when the target analysis rule is the first read-write key analysis rule in the above example, the account addresses included in the From field and the To field of the first transaction can both be determined as the read key of the first transaction. When the target analysis rule is the second read-write key analysis rule in the above example, the account address included in the From field of the first transaction can be determined as the read key of the first transaction, and the account address included in the From field of the first transaction can be determined as the write key of the first transaction. When the target analysis rule is the read-write key analysis rule L1 in the aforementioned example, the calculation logic defined by the read-write key analysis rule L1 can be used to calculate the read key of the first transaction, including: the account address included in the From field of the first transaction, the CodeHash of the smart contract that the first transaction expects to call, such as Token SC2, the from_slot obtained by processing the account address included in the From field of the first transaction based on a deterministic calculation process, the recipient_slot obtained by processing the account address in the input parameter included in the Data field of the first transaction based on a deterministic calculation process, and the write key of the first transaction is calculated to include the account address, from_slot and recipient_slot included in the From field of the first transaction.

[0077] Based on the same concept as the aforementioned method embodiment, this specification also provides a blockchain node 500 in a blockchain system. Figure 5 As shown, the blockchain node 500 includes: a transaction analysis unit 501, configured to determine the transaction type of a first transaction and / or the characteristic information of the first transaction; a rule matching unit 503, configured to determine whether there is a target analysis rule that matches the transaction type and / or the characteristic information among several pre-configured read-write key analysis rules, and if so, triggering the read-write analysis unit 505; the read-write analysis unit 505 is configured to determine the read-write key of the first transaction according to the target analysis rule under the triggering of the rule matching unit 503.

[0078] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the methods performed by the blockchain node in the aforementioned embodiments.

[0079] The embodiments of this specification also provide a computing device, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the method performed by the blockchain node in the aforementioned embodiments is implemented.

[0080] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, 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, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0081] The controller can be implemented in any suitable manner. For example, the controller 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 Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

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

[0083] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0084] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0085] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts 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, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0086] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0087] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

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

[0089] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0090] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0091] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. 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 magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0092] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0093] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, the description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, unless they conflict with each other.

[0094] The foregoing description is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. Those skilled in the art will appreciate that various modifications and variations of one or more embodiments of this specification are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification are intended to be included within the scope of the claims.

Claims

1. A transaction processing method in a blockchain system, the method comprising: determining a transaction type of a first transaction and / or characteristic information of the first transaction; Determining whether there is a target analysis rule matching the transaction type and / or the feature information among a plurality of pre-configured read-write key analysis rules; If so, the read-write key of the first transaction is determined according to the target analysis rule.

2. According to the method of claim 1, the transaction type includes a general transfer transaction, a contract call transaction, or a contract deployment transaction; wherein when the transaction type is the contract call transaction, the characteristic information includes the first contract address included in the To field of the first transaction, and / or the function identifier included in the Data field of the first transaction.

3. The method according to claim 1, wherein the plurality of read-write key analysis rules include at least one of the following rules: A first read-write key analysis rule matching a common transfer transaction, indicating that the account address included in the From and To fields of the transaction is determined as the read key, and the account address included in the Ffrom and To fields of the transaction is determined as the write key; The second read-write key analysis rule that matches the contract deployment transaction is used to indicate that the account address included in the From field of the transaction is determined as the read key and write key; At least one third read-write key analysis rule matching the at least one feature information, the third read-write key analysis rule being used to define calculation logic for calculating the read-write key based on at least part of the information respectively included in at least part of the fields in the transaction.

4. The method according to claim 1, wherein determining whether there is a target analysis rule matching the transaction type and / or the feature information among the pre-configured read / write key analysis rules comprises: When the transaction type of the first transaction is a contract call transaction, query whether there is target rule application information corresponding to the feature information in the stored rule application information, the target rule application information is registered by the developer of the first smart contract to the second smart contract deployed by the blockchain system, and the contract address included in the To field of the first transaction is the first contract address of the first smart contract; When the target rule application information exists and is in a valid state, the read-write key analysis rule indicated by the target rule application information is determined as the target analysis rule that matches the feature information.

5. The method according to claim 4, further comprising: receiving a second transaction for invoking the second smart contract, where the second transaction includes a first contract address of the first smart contract and registration information of the first smart contract; Execute the second smart contract according to the second transaction, calculate the current contract address according to the registration information of the first smart contract, and store the target rule application information when the current contract address is the same as the first contract address, wherein the target rule application information includes the feature information, the target account address for initiating the second transaction, and rule indication information for indicating the target analysis rule.

6. The method according to claim 5, further comprising: receiving a third transaction for invoking the second smart contract, wherein the third transaction includes a management instruction corresponding to the target rule application information; The second smart contract is executed according to the third transaction to determine whether the account address used to initiate the third transaction is the same as the target account address, and if so, manage the target rule application information according to the management instruction.

7. According to the method according to claim 5, the registration information of the first smart contract includes at least one of the following information: a hash value of the contract code of the first smart contract, a value of a nonce field included in a contract deployment exchange used to deploy the first smart contract, a method identifier and / or a salt value of a deployment method used when deploying the first smart contract.

8. A blockchain node in a blockchain system, the blockchain node comprising: a transaction analysis unit configured to determine a transaction type of a first transaction and / or characteristic information of the first transaction; a rule matching unit configured to determine whether there is a target analysis rule matching the transaction type and / or the feature information among a plurality of pre-configured read-write key analysis rules, and if so, trigger the read-write analysis unit; The read-write analysis unit is configured to determine the read-write key of the first transaction according to the target analysis rule.

9. A computing device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed in a computing device, the computing device executes the method according to any one of claims 1 to 7.

Images