Method and system for exiting cross-shard transactions, main chain node and target shard node

Abstract

A method and system for exiting a cross-shard transaction in a blockchain system including shards, a main chain node, and a target shard node. The blockchain system includes at least two shards and a main chain; the method includes: the target shard locally withdraws the cross-shard transaction operation that has an exception / timeout, generates an exit instruction that needs to be executed by the corresponding source shard for the cross-shard transaction, and sends the cross-shard transaction exit instruction to the main chain; in the process of the main chain generating a main chain block, the received instruction to exit the cross-shard transaction that needs to be executed by the source shard is filled into the block body of the main chain block; the main chain sends the instruction to exit the cross-shard transaction that needs to be executed by the source shard to the corresponding source shard according to the identifier of the source shard; in the process of the source shard generating a source shard block, the cross-shard transaction received from the main chain is filled into the block body of the source shard block, and the instruction to exit the cross-shard transaction is executed.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and more particularly to a method and system for exiting a cross-shard transaction in a blockchain system including shards, a main chain node, and a target shard node. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is a chain data structure that combines data blocks in a sequential manner in chronological order, and a distributed ledger that is tamper-proof and unforgeable by cryptography. Due to the characteristics of blockchain such as decentralization, information immutability, and autonomy, blockchain has also received more and more attention and application. Summary of the invention

[0003] The object of the present invention is to provide a method and system for exiting a cross-shard transaction in a blockchain system including shards, a main chain node, and a target shard node, including:

[0004] A method for exiting a cross-shard transaction in a blockchain system including shards, wherein the blockchain system includes at least two shards, and nodes in different shards store different state sets; the blockchain system also includes a main chain;

[0005] The method includes: an exception occurs when the target shard submits a cross-shard transaction-related operation locally, or a timeout occurs when waiting for a message related to the cross-shard transaction:

[0006] The target shard locally withdraws the cross-shard transaction operation that has an exception / timeout, generates an exit instruction for the cross-shard transaction that needs to be executed by the corresponding source shard, and sends the cross-shard transaction exit instruction to the main chain;

[0007] In the process of generating the main chain block, the main chain fills the received instruction of exiting the cross-shard transaction that needs to be executed by the source shard into the block body of the main chain block; the main chain sends the instruction of exiting the cross-shard transaction that needs to be executed by the source shard to the corresponding source shard according to the identifier of the source shard;

[0008] In the process of the source shard generating the source shard block, the cross-shard transaction received from the main chain is filled into the block body of the source shard block, and the instruction to exit the cross-shard transaction is executed.

[0009] A system for exiting a cross-shard transaction in a blockchain system including shards, wherein the blockchain system includes at least two shards, and nodes in different shards store different state sets; the blockchain system also includes a main chain;

[0010] The target shard encounters an exception when submitting cross-shard transaction-related operations locally, or times out while waiting for messages related to cross-shard transactions:

[0011] The target shard locally withdraws the cross-shard transaction operation that has an exception / timeout, generates an exit instruction for the cross-shard transaction that needs to be executed by the corresponding source shard, and sends the cross-shard transaction exit instruction to the main chain;

[0012] In the process of generating the main chain block, the main chain fills the received instruction of exiting the cross-shard transaction that needs to be executed by the source shard into the block body of the main chain block; the main chain sends the instruction of exiting the cross-shard transaction that needs to be executed by the source shard to the corresponding source shard according to the identifier of the source shard;

[0013] In the process of the source shard generating the source shard block, the cross-shard transaction received from the main chain is filled into the block body of the source shard block, and the instruction to exit the cross-shard transaction is executed.

[0014] A target shard node in a blockchain system including shards, comprising:

[0015] Execution unit, used to locally execute cross-shard transaction-related operations;

[0016] The target shard block generation unit is used to generate a target shard block when an exception occurs in the operation related to the cross-shard transaction submitted locally by the execution unit or a timeout occurs when waiting for a message related to the cross-shard transaction occurs, and generate a cross-shard transaction exit instruction in the process of generating the target shard block;

[0017] The cross-shard transaction exit unit is used to locally withdraw cross-shard transaction operations that have encountered exceptions or timeouts;

[0018] A sending unit is used to send the cross-shard transaction exit instruction to the main chain.

[0019] A main chain node in a blockchain system including shards, comprising:

[0020] A receiving unit, used to receive a cross-shard transaction exit instruction that needs to be executed by a source shard;

[0021] A main chain block generation unit, used to generate a main chain block, and in the process of generating the main chain block, fill the received cross-shard transaction exit instruction into the block body of the main chain block;

[0022] A sending unit is used to send the cross-shard transaction exit instruction to the corresponding source shard according to the identifier of the source shard.

[0023] The method embodiment of exiting a cross-shard transaction provided by the present application provides a solution for exiting a shard transaction in a blockchain system including shards by forwarding the exit instruction of a cross-shard transaction generated in a source shard to a target shard through the main chain, thereby ensuring the atomicity of cross-shard transactions. In this process, through the authority of the nodes constituting the main chain, the exit instruction of a cross-shard transaction generated in the source shard can be reliably forwarded and executed in the target shard under the witness of the main chain, and evidence is stored on the source shard, the main chain, and the target shard. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use 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 ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0025] Figure 1 This is a schematic diagram of the blockchain system architecture in one embodiment;

[0026] Figure 2 is a schematic diagram of a sharding architecture of a blockchain system in one embodiment;

[0027] Figure 3 This is a schematic diagram of the structure of blockchain data storage in an embodiment of this specification;

[0028] Figure 4 It is a simplified state tree diagram of an embodiment of this specification;

[0029] Figure 5 It is a storage structure of a blockchain state tree in an embodiment of this specification;

[0030] Figure 6 It is a storage structure of a blockchain state tree in an embodiment of this specification;

[0031] Figure 7 It is a storage structure of a blockchain state tree in an embodiment of this specification;

[0032] Figure 8 It is a storage structure of a blockchain state tree in an embodiment of this specification;

[0033] Fig. 9 It is a state storage method in a blockchain system in an embodiment of this specification;

[0034] Fig.10 It is a schematic diagram of a blockchain sharding architecture in an embodiment of this specification;

[0035] Fig.11 It is a schematic diagram of the principle of consistent hashing in an embodiment of this specification;

[0036] Fig.12 It is a storage structure of a blockchain state tree in an embodiment of this specification;

[0037] Fig.13 It is a schematic diagram of a blockchain node in an embodiment of this specification;

[0038] Fig.14 It is a schematic diagram of a blockchain node in an embodiment of this specification;

[0039] Fig.15 It is a schematic diagram of a blockchain sharding system based on the main chain in an embodiment of this specification;

[0040] Fig.16 It is a schematic diagram of generating blocks in a blockchain sharding system that introduces a main chain in an embodiment of this specification;

[0041] Fig.17 A method for executing cross-shard transactions in a blockchain system including shards in an embodiment of this specification;

[0042] Fig.18 It is a schematic diagram of an embodiment of the present specification in which a shard block generated by shard 2 includes a cross-shard transaction list and reports the cross-shard transaction list to the main chain;

[0043] Fig.19 It is a schematic diagram of a main chain block generated by a main chain in an embodiment of this specification including cross-shard transactions and shard block roots;

[0044] Fig. 20 is a schematic diagram of a target sharding block generated by a target sharding in an embodiment of the present specification;

[0045] Fig.21 It is a schematic diagram of a target shard block generated by a target shard in an embodiment of this specification including a main chain block hash;

[0046] Fig. 22 It is a schematic diagram of a target shard block generated by a target shard in an embodiment of this specification including a main chain block hash;

[0047] Fig.23 It is a schematic diagram of a target shard block generated by a target shard in an embodiment of this specification including a main chain block hash;

[0048] Fig.24 This is a flowchart of returning a cross-shard transaction response to a source shard in an embodiment of this specification;

[0049] Fig.25It is a schematic diagram of a main chain block generated by a main chain in an embodiment of this specification including a cross-shard transaction response and a shard block root;

[0050] Fig.26 is a schematic diagram of source shard blocks generated by source shards in one embodiment of this specification;

[0051] Fig. 27 It is a schematic diagram of sending a cross-slice transaction submission instruction and submitting a cross-slice transaction in an embodiment of this specification;

[0052] Fig.28 It is a schematic diagram of a main chain block generated by a main chain in an embodiment of this specification including a cross-shard transaction submission instruction and a shard block root;

[0053] Fig.29 is a schematic diagram of a target shard block generated by a target shard in an embodiment of the present specification;

[0054] Fig.30 It is a schematic diagram of sending a cross-shard transaction submission response and submitting a cross-shard transaction in an embodiment of this specification;

[0055] Fig.31 It is a schematic diagram of a main chain block generated by a main chain in an embodiment of this specification including a cross-shard transaction submission response and a shard block root;

[0056] Fig.32 is a schematic diagram of source shard blocks generated by source shards in one embodiment of this specification;

[0057] Fig.33 It is a schematic diagram of sending a cross-slice transaction submission instruction and submitting a cross-slice transaction in an embodiment of this specification;

[0058] Fig.34 It is a schematic diagram of sending a cross-slice transaction submission instruction and submitting a cross-slice transaction in an embodiment of this specification;

[0059] Fig.35 It is a schematic diagram of a main chain block generated by a main chain in an embodiment of this specification including a cross-shard transaction submission instruction and a shard block root;

[0060] Fig.36 is a schematic diagram of source shard blocks generated by source shards in one embodiment of this specification;

[0061] Fig.37 It is a schematic diagram of sending a cross-slice transaction exit instruction and submitting a cross-slice transaction in an embodiment of this specification;

[0062] Fig.38 It is a schematic diagram of a main chain block generated by a main chain in an embodiment of this specification including a cross-shard transaction exit instruction and a shard block root;

[0063] Fig.39 is a schematic diagram of a target shard block generated by a target shard in an embodiment of the present specification;

[0064] Fig.40 It is a schematic diagram of sending a cross-slice transaction exit instruction and submitting a cross-slice transaction in an embodiment of this specification;

[0065] Fig.41 It is a schematic diagram of a main chain block generated by a main chain in an embodiment of this specification including a cross-shard transaction submission instruction and a shard block root;

[0066] Fig.42 is a schematic diagram of source shard blocks generated by source shards in one embodiment of this specification;

[0067] Fig.43 It is the target shard node in the blockchain system including shards in an embodiment of this specification;

[0068] Fig.44 It is the main chain node in the blockchain system including shards in one embodiment of this specification. DETAILED DESCRIPTION

[0069] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0070] Currently, a very important factor limiting the large-scale application of blockchain technology is performance, that is, throughput, which can generally be measured by the number of transactions per second (TPS). Developers have proposed various solutions to try to increase the throughput of blocks, a process called "capacity expansion". From the perspective of the technology used for capacity expansion, it can be divided into two directions: on-chain capacity expansion and off-chain capacity expansion. On-chain capacity expansion usually includes solutions such as block expansion, segregated witness, sharding, and consensus layer improvement. Off-chain capacity expansion usually includes solutions such as state channels, side chains, and off-chain computing.

[0071] Sharding technology is a solution for on-chain expansion. The concept of sharding originated from the database field. It originally refers to the horizontal partitioning of data in the database (dividing different rows of a table into different partitions). Each shard is stored on a separate database server instance to distribute the load. The basic idea of ​​blockchain sharding is to divide the nodes in the blockchain network into several relatively independent sub-networks. Each sub-network contains a part of the nodes, and a sub-network is a shard. A single shard handles smaller transactions, or even only stores part of the network status. Multiple shards process transactions in parallel. In theory, the throughput of the entire network will increase.

[0072] Sharding technology can be divided into three types according to different sharding mechanisms: network sharding, transaction sharding, and state sharding. Network sharding is the most basic sharding method, which includes dividing the entire blockchain network into multiple sub-networks, that is, multiple shards. In this way, multiple shards in the blockchain network can process different transactions in the network in parallel. Transaction sharding is to assign transactions to different shards according to certain rules. The idea is to assign transactions to the same shard for processing according to certain rules, so that the purpose of parallel processing can be achieved and the double-spending problem can be avoided. The premise of transaction sharding is to perform network sharding first. Among all sharding mechanisms, state sharding is the most challenging sharding method. The key to state sharding is to separate the entire storage area, allowing different shards to store different parts. Each node is only responsible for storing its own shard data, rather than storing the complete blockchain state. State sharding can solve the storage capacity bottleneck problem.

[0073] Some blockchain system architectures such as Figure 1 As shown. Figure 1 In the example, a blockchain system contains 16 full nodes, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, and P. The lines between the nodes schematically represent P2P (Peer to Peer) connections. These nodes store full ledgers, that is, they are responsible for storing all transactions, smart contracts, and various states. With the growth of blockchain business, the amount of data stored in a single node will also increase, some reaching the order of T (1TB = 1024GB), or even the order of P or E (1PB = 1024TB, 1EB = 1024PB). In order to support the operation of the blockchain system and cope with the continuation of business, each node needs to seek capacity expansion (to obtain more storage space) and incur huge expenses.

[0074] Based on this, the embodiment of this specification provides a blockchain system. After the nodes in the blockchain system are sharded, for example Figure 2As shown, it is divided into 4 shards. Each shard includes 4 nodes. The lines between the nodes in each shard represent P2P connections, and the lines between each shard also represent P2P connections. This embodiment only schematically lists 4 shards for the sake of convenience, and each shard includes 4 nodes. In fact, the number of nodes in each shard may be different. In addition, there may be no network connection between some or all of the shards, that is, in some cases, some or all of the shards may not communicate directly with each other. In order to support communication between shards, the blockchain network may include a main chain that provides services for all shards. This main chain is Figure 2 It is not shown in the.

[0075] In order to illustrate the state sharding method in this application, the blockchain state storage structure involved in this application is first introduced. In view of the fact that many blockchain platforms and applications are built based on the underlying technology of Ethereum, the state storage structure of Ethereum is first introduced here. Of course, blockchain systems built based on other blockchain technologies may also be applicable to the core content of this application, such as Hyperledger and Enterprise Operating System (EOS), Quorum, Corda, etc. based on Fabric, which will not be repeated here.

[0076] Compared with the Bitcoin network, Ethereum has expanded and adopted an account system and world state, which can directly use accounts to display the balance and status of accounts. Ethereum accounts can be divided into two types:

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

[0078] Contract account: stores the executed smart contract code and the value of the state in the smart contract code, and can usually only be activated by calling an external account.

[0079] The design of external accounts and contract accounts is actually a mapping from account addresses to account status. The status of an account usually includes fields such as nonce, balance, storage_root, and codeHash. Nonce and balance exist in both external accounts and contract accounts. CodeHash and storage_root attributes are generally only valid on contract accounts.

[0080] nonce: Counter. For external accounts, this number represents the number of transactions sent from the account address; for contract accounts, it is the number of contracts created by the account.

[0081] Balance: The amount of ether owned by this address.

[0082] storage_root: The hash of the root node of an MPT tree that organizes the storage of state variables of the contract account.

[0083] codeHash: The hash value of the smart contract code. For contract accounts, this is the code of the smart contract that is hashed and stored; for external accounts, since the smart contract is not included, the codeHash field can generally be an empty string / all-0 string.

[0084] MPT stands for Merkle Patricia Tree, which is a tree structure that combines Merkle Tree and PatriciaTree (compressed prefix tree, a more space-saving Trie tree, dictionary tree). Merkle Tree, the Merkle tree algorithm calculates a hash value for each transaction, and then connects two by two to calculate the hash again until the top Merkle root. Ethereum uses an improved MPT tree, such as a 16-way tree structure, which is usually referred to as MPT tree.

[0085] The data structure of the Ethereum MPT tree includes a state trie. The state trie contains key and value pairs of storage content corresponding to each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (the address of the Ethereum account), and this account address is distributed in the storage from the root node of the state trie to the leaf node. The "value" in the state trie is generated by encoding the information of the Ethereum account (using the Recursive-Length Prefix encoding (RLP) method). As mentioned earlier, for external accounts, the values ​​include nonce and balance; for contract accounts, the values ​​include nonce, balance, codehash, and storage_root.

[0086] The contract account is used to store the states related to the smart contract. After the smart contract is deployed on the blockchain, a corresponding contract account will be generated. This contract account generally has some states, which are defined by the state variables in the smart contract and generate new values ​​when the smart contract is created and executed. The smart contract generally refers to a contract that can automatically execute clauses in a digital form in a blockchain environment. Once an event triggers the clauses in the contract (meets the execution conditions), the code can be automatically executed. In the blockchain, the relevant states of the contract are stored in the storage tree (storagetrie), and the hash value of the root node of the storage tree is stored in the above storage_root, so that all states of the contract are locked to the contract account through hash. The storage tree is also an MPT tree structure, which stores the key-value mapping from the state address to the state value. From the root node to the leaf node of the storage tree, the address of a state is stored, and a leaf node stores the value of a state.

[0087] Figure 3 This is a schematic diagram of the structure of blockchain data storage. Figure 3In some of the blockchain data storages shown, the block header of each block includes several fields, such as the previous block hash previous_Hash (PrevHash in the figure, or called parent hash), random number Nonce (in some blockchain systems, this Nonce is not a random number, or in some blockchain systems, Nonce in the block header is not enabled), timestamp Timestamp, block number BlockNum, state root hash State_Root, transaction root hash Transaction_Root, receipt root hash Receipt_Root, etc. Among them, the PrevHash in the block header of the next block (such as block N+1) points to the previous block (such as block N), which is the hash value of the previous block. In this way, the next block locks the previous block through the block header on the blockchain. In particular, as mentioned above, state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, that is, the state tree pointing to state_root is a state tree in the form of MPT. The root node of this MPT tree can be an extension node (Extension Node) or a branch node (BranchNode), and the hash value of this root node is generally stored in state_root. A part of the value of each node from the root node of this MPT to the leaf node can be connected in sequence to form an account address and serve as a key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. Specifically, this key can be sha3(Address), that is, the hash value of the account address (the hash algorithm uses the sha3 algorithm, for example), and the value stored can be rlp(Account), that is, the rlp encoding of the account information. The account information is a four-tuple consisting of [nonce, balance, storage_root, codeHash]. As mentioned above, for external accounts, there are generally only two items, nonce and balance, and the storage_root and codeHash fields store empty strings / all 0 strings by default. In other words, external accounts do not store contracts, nor do they store state variables generated after contract execution. Contract accounts generally include nonce, balance, storage_root, and codeHash. Nonce is the transaction counter of the same account; balance is the account balance; storage_root corresponds to another MPT, through which storage_root can be linked to the information of the contract-related status; codeHash is the hash value of the contract code. Whether it is an external account or a contract account, its account information is generally located in a separate leaf node.From the extension node / branch node of the root node to the leaf node of each account, there may be several branch nodes and extension nodes in the middle.

[0088] The state tree can be a tree in the form of MPT, generally a 16-way tree, each layer can have up to 16 child nodes, and can have a depth of up to 64 layers. For an extension node, it is used to store common prefixes, and it generally has 1 child node, which can be a branch node. For a branch node, it can have up to 16 child nodes, which may include extension nodes and / or leaf nodes. Such an MPT tree can have a depth of up to 64 layers. When the number of accounts in the blockchain reaches a certain number, the MPT tree may approach or reach a depth of 64 layers.

[0089] Among them, for a contract account in the state tree, its storage_Root points to another tree in the MPT format, which stores the data of the state variables involved in the contract execution. The MPT-formatted tree pointed to by this storage_Root is the storage tree, that is, the hash value of the root node of the storage tree. Generally, this storage tree also stores key-value pairs. A part of the data stored on the path from the root node to the leaf node is connected to form the key, and the leaf node stores the value. As mentioned earlier, this storage tree can also be a tree in the MPT format, which is generally a hexadecimal tree, that is, for a branch node, it can have up to 16 child nodes, which may include extension nodes and / or leaf nodes. For an extension node, it can generally have 1 child node, which can be a branch node. This storage tree can have a depth of up to 64 layers.

[0090] In smart contracts, such as the solidity high-level development language provided by Ethereum, there are two types of state variables that can be defined: one is a state variable of a basic data type, and the other is a state variable of a mapping (map or mapping) type. The following is a snippet of a smart contract code written in solidity:

[0091]

[0092] Among them, the integer variables a and x are both basic data types. In the myfunc function, a is assigned to 8 and x is assigned to 9. In the map type data structure, the above code defines the mapping from the external account address to the balance of an asset type (balanceA, which is different from the balance in the external account and the balance in the contract account), that is, the mapping from address address to balanceA. In the myfunc function, for example, the corresponding balanceA is initialized to 100 for the address 123 of the external account.

[0093] In Ethereum and other blockchain systems, for example, new digital assets can be created in smart contracts according to the ERC20 standard, and of course, digital assets customized in other ways can also be created. For example, the above balanceA can be a digital asset created according to the ERC20 standard. Of course, in a smart contract, multiple asset types can be defined, such as balanceA, balanceB, balanceC, ... The map in this contract can give each external account the ability to hold and trade this newly created digital asset. As in the example of the above code, generally, each external account can correspond to an asset of type balanceA. Then, if there are 10,000 external accounts in the state tree of the blockchain, each external account can correspond to holding / trading assets of type balanceA through smart contracts, that is, there are 10,000 "external account→balanceA" mappings.

[0094] It should be noted that the assets here are broad in scope and can also be other additional content. For example, in the scenario of blockchain electronic invoices, assets can be defined as a set of invoice codes, such as balanceP. In this way, in the mapping of "external account → balanceP", balanceP can include a set of invoice codes. New invoice codes may be added to this invoice code set.

[0095] The above basic data types and map type state variables can be stored in the form of key-value pairs in the storage tree. For basic data types, key is the position of the state variable declaration in the contract (counting from 0). For map type, key = SHA3 (keyword in map, variable declaration position), that is, the keyword in the map and the state variable declaration position are combined into a string of a certain length (for example, 64 bytes) and the hash value is calculated. value can store the actual value of the state variable.

[0096] As mentioned earlier, if there are 10,000 external accounts in the state tree of the blockchain, then through the smart contract, each external account can correspond to holding / trading assets of type balanceA, that is, there are 10,000 external accounts → balanceA mappings. Specifically, under the contract account, the values ​​of these maps can be stored in the storage tree. As mentioned above, it is specifically stored in the storage tree in the form of key-value. Similarly, this storage tree can also be a tree in the form of MPT, which is generally a 16-way tree. Each layer can have up to 16 child nodes and a depth of up to 64 layers. A part of the data stored from the root node of this MPT to the leaf node can be connected as a key, and the information stored in the leaf node is the value corresponding to this key. In this way, a key-value pair is formed.

[0097] When the number of external accounts in the blockchain reaches a certain amount, the depth of the state tree may approach or reach 64 layers. Similarly, the number of map-type state variables in the contract may also reach the same amount, and the storage tree also approaches or reaches 64 layers. In addition, for a smart contract, there will not be too many variables of basic data types in the contract, generally not more than 32. In this way, when the number of external accounts is large, plus the variables of basic data types in the contract, the total number of state variables in the contract is basically the same as the external accounts.

[0098] Figure 4 This is a simplified state tree diagram. There are several external accounts in the blockchain system, such as Figure 4 In the blockchain system, there are several contract accounts, such as Figure 4 The contract accounts 1, contract account 2, ... are numbered in the block. These external accounts and contract accounts and their information contents are organized in the form of an MPT tree to form a state tree. The state_root in the block header stores the hash value of the root node of the MPT tree. Figure 4 In the figure, three nodes, namely, node 1, node 2 and node 3, are used to schematically represent the form of the MPT tree. Specifically, they can represent extension nodes and branch nodes in the MPT tree.

[0099] External accounts can deploy smart contracts on the blockchain through transactions that create contracts. In addition, smart contracts can also be native contracts, that is, they are integrated into the code of the blockchain platform and deployed after being compiled together with the blockchain platform code. Regardless of the form of deployed smart contracts, after the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address. The contract code and account storage will be saved in the contract account. The account storage of the smart contract saves the status of this contract. After the contract is created, an external account can call the created smart contract, or an external account can call the smart contract through a smart contract (it can also call a smart contract through one or more smart contracts). The called smart contract writes the generated state variables into the account storage of the smart contract in the form of key-value, such as Figure 4 As shown. These key-values ​​can be organized into the form of an MPT tree to form a storage tree. In the storage tree, key-values ​​include not only state variables of basic data types, but also state variables of map type. Generally, there are no more than 32 state variables of basic types in a contract, that is, generally a storage tree includes no more than 32 key-values ​​to correspond to the storage of state variables of basic types. In a contract, map-type state variables generally correspond to external accounts. When there are N external accounts, there are generally N corresponding key-values ​​in a contract to correspond to the storage of map-type state variables.

[0100] The number of map-type state variables in a contract account generally corresponds to that of an external account. In addition, the contract account also includes basic-type state variables. When the number of external accounts is large, the number of map-type state variables in the contract account is also large. The state tree actually includes two layers of MPT structure, and the maximum depth of each layer is 64 layers. For a large number of contract operations in the blockchain system, the state variables of the contract must be involved. In this way, in the existing account architecture, although external accounts and contract accounts are established, the hot spots of operations will be concentrated on the state variables in the contract account, while there are few operations on external accounts. This forms a single-account hot spot. The single-account hot spot leads to a large load pressure on the storage of the contract account, which will limit and affect the performance of the blockchain system.

[0101] This specification embodiment provides a storage structure of a blockchain state tree. Figure 5 shown.

[0102] The state_root in the block header stores the hash value of the root node of the entire state tree. The tree structure can be, for example, Figure 3The MPT in the example can also be organized in other ways. This is similar to the following, and the MPT is used as an example to illustrate. Overall, the state tree can adopt a three-layer tree structure. For example, for MPT, Figure 5 Each layer of the MPT tree is schematically represented by three nodes, namely Node 1, Node 2, and Node 3. Specifically, they can represent extension nodes and branch nodes in the MPT tree. The leaf nodes of the first-layer tree structure can be used to store the root hash value stored in the external account, and can also store some basic information of the contract account. There can be several external accounts and contract accounts respectively. In general blockchain application scenarios, the number of external accounts may be significantly greater than the number of contract accounts. The root hash of the account information of each external account in the leaf node of the first layer can be calculated based on the nonce, balance of the external account, and the hash value stored in the smart contract involved in the external account. Among them, Figure 5 The nonce and balance of the external account can be Figure 3 , Figure 4 The second layer is the schematic storage trie. Specifically, the root node of the second layer tree structure is the hash value of the storage of the smart contract involved in the external account. Similarly, the second layer can be schematically represented by a node 1, node 2, and node 3, which can specifically represent the extension node and branch node in the MPT tree. The storage of the second layer can include one or more smart contracts, that is, there can be multiple leaf nodes. Each leaf node of the second layer can be used to store the root hash value of the storage of a smart contract involved in the external account, which can be calculated based on the contract ID (contractID) and storage_root involved in the external account. The third layer is the storage tree. Specifically, the root node of the third layer tree structure is the root hash value of the state variable in the smart contract involved in the external account. Similarly, the third layer can be schematically represented by a node 1, node 2, and node 3, which can specifically represent the extension node and branch node in the MPT tree. Each leaf node of the third layer can be used to store the value of a state variable in the contract. In the above three-layer tree structure, part of the data stored on the path from the root node to the leaf node of each tree can be connected to form a key, and the leaf node can store the value. In this way, through such a storage model, the key-value of the state variable in each smart contract involved in each external account can be stored under each external account.

[0103] This specification embodiment provides a storage structure of a blockchain state tree. Figure 6 shown.

[0104] In actual blockchain business systems, in many cases, a blockchain focuses on providing a service. A service can generally be implemented using a smart contract. In this case, there is only one smart contract in the blockchain system. When there is only one smart contract, Figure 5 The second layer in can be simplified and does not need Figure 5 The second layer structure in Figure 6 As shown. The root hash of each external account in the leaf node of the first-level tree structure can be calculated based on the nonce, balance and hash value stored in the smart contract involved in the external account. Figure 6 The nonce and balance of the external account can be Figure 3 , Figure 4 The second layer is the storage tree. Specifically, the root node of the second-layer tree structure is the root hash value of the state variable in the smart contract involved in the external account. Similarly, the second layer can be schematically represented by a MPT tree with three nodes, namely node 1, node 2, and node 3. Specifically, it can represent the extension node and branch node in the MPT tree. Each leaf node of the second layer can be used to store the value of a state variable in the contract. In the above two-layer tree structure, a part of the data stored on the path from the root node to the leaf node of each tree can be connected to form a key, and the value can be stored in the leaf node. In this way, through such a storage model, the key-value of the state variable in each smart contract involved in the external account can be stored under each external account.

[0105] Figure 3 , Figure 4 The contract account storage includes all state variables involved in the contract. Figure 5 , Figure 6 The embodiment provides a storage structure of the blockchain state tree, which actually decomposes all state variables in the contract involved in the original contract account storage into the storage of the corresponding external account according to the associated external account. For example, the original contract account storage includes all map-type state variables 1, 2, 3, ... 10000 involved in the contract, of which 1-1000 is related to external account 1, 1001-2000 is related to external account 2, and so on. In this way, the map-type state variables 1-1000 related to external account 1 are decomposed into the storage of external account 1; the map-type state variables 1001-2000 related to external account 2 are decomposed into the storage of external account 2, and so on.

[0106] In addition to the map data structure, other data structures can also be used to define the mapping of external account addresses to an asset type, which is not limited here.

[0107] The simplest case is Figure 7 As shown in the figure, a smart contract is created in a blockchain system, and a new type of asset is defined in the smart contract. Moreover, in the created contract, only one new type of asset can be defined, or only one of the new types of assets can be enabled when multiple new types of assets are defined (while the other new types of assets are not enabled or initialized). In this case, since each external account corresponds to the balance of one type of asset, the balance of the asset of this type does not need to be organized into a tree form, and can be stored through a key-value. Among them, in this map type, key = SHA3 (keyword in the map, variable declaration position), that is, the keyword in the map and the state variable declaration position are combined into a string of a certain length (for example, 64 bytes) and the hash value is calculated. Value can store the actual value of the variable, that is, the balance of assets of type balanceA. In this way, the storage_root of the external account can be the hash value of this key-value. Each external account can have such a map data. For example, the storage_root of external account 1 points to a key-value in its map type; external account 2 points to a key-value in its map type; and so on. In summary, for the case where there is only one smart contract in the blockchain system, and only one new type of asset is defined or enabled in the smart contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a hash value of the key-value of the new type of asset related to an external account in each leaf node through a tree structure; the second layer stores the mapping relationship between the external account and the new type of asset in the form of key-value defined by the map.

[0108] As mentioned above, in a smart contract, multiple asset types can be defined, such as balanceA, balanceB, balanceC, balanceD, ... In this way, each external account can have balances corresponding to assets of types balanceA, balanceB, balanceC, balanceD, ... In this case, since each external account corresponds to the balances of multiple types of assets, the balances of multiple types of assets can be organized into a tree form. Figure 6As shown in , in the storage tree of the second layer, a tree form is schematically represented by three nodes, namely, node 1, node 2, and node 3. If this tree is, for example, an MPT tree, then nodes 1, 2, and 3 can schematically represent extension nodes and branch nodes in the MPT tree. Among them, in this map type, key = SHA3 (keyword in the map, variable declaration position), that is, the keyword in the map and the state variable declaration position are put together into a string of a certain length (for example, 64 bytes) and then the hash value is calculated. Value can store the actual value of the state variable, that is, the balance of assets of types such as balanceA, balanceB, balanceC, balanceD, etc. As Figure 4 In the example, the leaf nodes of the storage tree of external account 1 have the balances of assets of types balanceA, balanceB, balanceC, balanceD, ... respectively. In this way, the storage_root of the external account can be the root hash value of the key-value tree of assets of types balanceA, balanceB, balanceC, balanceD, .... Each external account can have such map data. For example, the storage_root of external account 1 points to a tree structure of a set of key-values ​​in its map type; the storage_root of external account 2 points to a tree structure of a set of key-values ​​in its map type. And so on. In this way, for the case where there is only one smart contract in the blockchain system, and at least two new types of assets are defined and enabled in the smart contract, the storage of the state tree in the blockchain includes two layers; the first layer stores the root hash value of the key-value of all the new types of assets related to an external account in each leaf node through a tree structure; the second layer stores the mapping relationship defined by the map in the form of key-value between the external account and one of the new types of assets in each leaf node through a tree structure.

[0109] In a blockchain system, multiple smart contracts can be created. For example, multiple smart contracts are created in a blockchain system, and these smart contracts can be organized in a tree structure, such as Figure 8 As shown, the second layer in the figure is the contract storage tree. Each of most smart contracts can define one or more new types of assets. Each smart contract has different states. For example Figure 8In the figure, two contracts are shown that are connected to external account 1 through a tree structure. Each contract can calculate a hash value based on its ID and storage_root, and the hash value can be stored in a leaf node of the second-level tree structure, such as schematic_storage_root in the figure. For the case where each of the two created contracts only defines one new type of asset, or when multiple new types of assets are defined and only one of them is enabled (while the other new types of assets are not enabled or initialized), each contract corresponds to the balance of one type of asset, so the balance of this type of asset does not need to be organized into a tree form, and can be stored through a key-value, similar to Figure 7 The second layer structure in the blockchain. In this way, the storage_root of a smart contract can be the hash value of this key-value. And so on. In summary, for the case where there are at least two smart contracts in the blockchain system, and only one new type of asset is defined or enabled in the smart contract, the storage of the state tree in the blockchain includes three layers; the first layer stores the root hash value of all smart contract-related information related to an external account in each leaf node through a tree structure; the second layer stores the hash value of the key-value of the new type of asset related to an external account in each leaf node through a tree structure; the third layer stores the mapping relationship between the external account and the asset in the form of key-value defined by the map.

[0110] In a blockchain system, multiple smart contracts can be created, and multiple asset types can be defined in each contract, such as balanceA, balanceB, balanceC, balanceD, etc. This situation can be as follows Figure 5As shown. Two contracts are shown by connecting external account 1 through a tree structure. This is the second-layer contract storage tree. In fact, the second-layer storage can include multiple smart contracts, that is, there can be multiple leaf nodes. Each contract can calculate a hash value based on its ID and storage_root, and the hash value can be stored in a leaf node of the second-layer tree structure, such as schematic_storage_root in the figure. Each leaf node of the second layer can be used to store the root hash value of the storage of a smart contract involved in the external account, which can be calculated based on the hash value of the contract ID and storage involved in the external account. The third layer is the storage tree. Specifically, the root node of the third-layer tree structure is the root hash value of the state variable in the smart contract involved in the external account. Similarly, the third layer can be schematically represented by a total of three nodes, node 1, node 2, and node 3, in the form of an MPT tree. Specifically, it can represent an extension node and a branch node in the MPT tree. Each leaf node of the third layer can be used to store the value of a state variable in the contract. In the above three-layer tree structure, a part of the data stored on the path from the root node to the leaf node of each tree can be connected to form a key, and the leaf node can store a value. In this way, through such a storage model, the key-value of the state variable in each smart contract involved in the external account can be stored under each external account. In summary, for the case where there are at least two smart contracts in the blockchain system, and only at least two new types of assets are defined or enabled in the smart contract, the storage of the state tree in the blockchain includes three layers; the first layer stores the root hash value of all smart contract-related information related to an external account in each leaf node through a tree structure; the second layer stores the root hash value of the key-value of all new types of assets involved in a smart contract related to an external account in each leaf node through a tree structure; the third layer stores the mapping relationship defined by the map in the form of key-value between the external account and a new type of asset in each leaf node through a tree structure.

[0111] Above Figure 5-8 In the example of , the first layer can also store the transaction count of the external account in each leaf node through the tree structure.

[0112] Above Figure 5 , Figure 8In the example, it is shown that the second layer also stores the number of the associated smart contract in each leaf node through the tree structure. In addition, the second layer may not store the number of the associated smart contract in each leaf node, but the root node of the second layer stores the address of the involved smart contract or a mapping value based on the address of the involved smart contract in the path from the root node of the second layer to each leaf node of the second layer through the tree structure of the second layer.

[0113] In combination with the above content, the present application provides a state storage method in a blockchain system, such as Fig. 9 As shown in the figure, the blockchain system includes at least two shards, and nodes in different shards store the status of different external account sets.

[0114] The blockchain system can be Fig.10 As shown, for example, 4 shards are included. Each shard may include 4 nodes. The 4 nodes in each shard may all be full nodes. This is only an illustrative example, and different shards may have different numbers of nodes, which is not limited here. The nodes contained in each shard may meet the Byzantine Fault Tolerance (BFT) requirements. The Byzantine Fault Tolerance requirement can be understood as Byzantine nodes can exist inside the shard, while the shard does not reflect Byzantine behavior to the outside. In general, some Byzantine fault tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).

[0115] Nodes in different shards can store the status of different sets of external accounts. Fig.10 For example, nodes A, B, C, and D in shard 1, each node's state stores the state of external accounts 1, 5, 9, 13, ... (for example, a set of external accounts marked by positive integers starting from 1 and with an interval of 4). The state of external accounts 1, 5, 9, 13, ... is stored in nodes A, B, C, and D, as shown in the following figure: Figure 5-8 Any of the examples in .

[0116] Combined with the simplest Figure 7For example, a smart contract is created in the blockchain system, and a new type of asset is defined in the smart contract. The created contract can define only one new type of asset, or define multiple new types of assets and only enable one of them (while the other new types of assets are not enabled or initialized). In this case, since each external account corresponds to the balance of one type of asset, the balance of this type of asset does not need to be organized into a tree form, and can be stored through a key-value. Among them, in this map type, key = SHA3 (keyword in the map, variable declaration position), that is, the keyword and variable declaration position in the map are combined into a string of a certain length (for example, 64 bytes) and the hash value is calculated. value can store the actual value of the variable, that is, the balance of assets of type balanceA. In this way, the storage_root of the external account can be the hash value of this key-value. Each external account can have such a map data. For example, the storage_root of external account 1 points to a key-value in its map type; external account 2 points to a key-value in its map type; and so on. In summary, for the case where there is only one smart contract in the blockchain system, and only one new type of asset is defined or enabled in the smart contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a hash value of the key-value of the new type of asset related to an external account in each leaf node through a tree structure; the second layer stores the mapping relationship between the external account and the new type of asset in the form of key-value defined by the map.

[0117] Combined with Figure 6 Taking the implementation in as an example, in a smart contract, multiple asset types can be defined, such as balanceA, balanceB, balanceC, balanceD, .... In this way, each external account can have balances corresponding to assets of types balanceA, balanceB, balanceC, balanceD, ... respectively. In this case, since each external account corresponds to the balances of multiple types of assets, the balances of the multiple types of assets can be organized in the form of a tree. In this way, for the case where there is only one smart contract in the blockchain system, and at least two new types of assets are defined and enabled in the smart contract, the storage of the state tree in the blockchain includes two layers; the first layer stores the root hash value of the key-value of all the new types of assets related to an external account in each leaf node through a tree structure; the second layer stores the mapping relationship defined by the map in the form of key-value between the external account and one of the new types of assets in each leaf node through a tree structure.

[0118] Combined with Figure 8 Taking the implementation in as an example, multiple smart contracts are created in a blockchain system. These smart contracts can be organized in a tree structure, such as Figure 8 The second layer in is the contract storage tree. For the case where each of the two created contracts only defines one new type of asset, or where multiple new types of assets are defined and only one of them is enabled (while the other new types of assets are not enabled or initialized), each contract corresponds to the balance of one type of asset. In this way, for the case where there are at least two smart contracts in the blockchain system, and only one new type of asset is defined or enabled in the smart contract, the storage of the state tree in the blockchain includes three layers; the first layer stores the root hash value of all smart contract-related information related to an external account in each leaf node through a tree structure; the second layer stores the key-value hash value of the new type of asset related to an external account in each leaf node through a tree structure; the third layer stores the mapping relationship between the external account and the asset in the form of key-value defined by the map.

[0119] Combined with Figure 5 For example, a blockchain system can create multiple smart contracts, and multiple asset types can be defined in each contract. In this way, for the case where there are at least two smart contracts in the blockchain system, and only at least two new types of assets are defined or enabled in the smart contract, the storage of the state tree in the blockchain includes three layers; the first layer stores the root hash value of all smart contract-related information related to an external account in each leaf node through a tree structure; the second layer stores the root hash value of the key-value of all new types of assets related to an external account in each leaf node through a tree structure; the third layer stores the mapping relationship between the external account and a new type of asset in the form of key-value defined by the map in each leaf node through a tree structure.

[0120] Nodes in different shards can store the status of different sets of external accounts. Fig.10In the example of shard 1, the state of each node of nodes E, F, G, and H in shard 2 stores the state of external accounts 2, 6, 10, 14... (for example, a set of external accounts marked with positive integers starting from 2 and with an interval of 4); the state of each node of nodes I, J, K, and L in shard 3 stores the state of external accounts 3, 7, 11, 15... (for example, a set of external accounts marked with positive integers starting from 3 and with an interval of 4); the state of each node of nodes M, N, O, and P in shard 4 stores the state of external accounts 4, 8, 12, 16... (for example, a set of external accounts marked with positive integers starting from 4 and with an interval of 4). The way in which nodes in shards 2, 3, and 4 store corresponding external accounts is similar to the above, and will not be repeated here. It should be noted that different external account sets corresponding to different shards may have a certain intersection between these sets. For example, the two external account sets {external account set} corresponding to shard 2 and shard 3 respectively 分片2 and {external account collection} 分片3 , there can be no intersection of external accounts between the two sets, or there can be a certain intersection of external accounts.

[0121] above Fig.10 In the example, the external accounts corresponding to different shards are account sets formed at the same interval starting from different initial values ​​according to the unique identifier of the external account. This is a modular method. In addition to this modular method, a segmented method can also be used. For example, the external accounts in the blockchain system include a total of 4000 accounts with IDs of 1-4000. The nodes in shard 1 can be assigned to store the status of external accounts 1-1000, the nodes in shard 2 can store the status of external accounts 1001-2000, the nodes in shard 3 can store the status of external accounts 2001-3000, and the nodes in shard 4 can store the status of external accounts 3001-4000. The above-mentioned modularization or segmentation can be for the ID division of the external account, or for the address division of the external account, or for the hash value division of the ID or address, etc., and can be divided according to a unique identifier of the account as a whole, which is not limited here.

[0122] In this way, when a new registered user is generated in the blockchain system, the status of the user's external account can be determined based on the user's ID, address, and hash value of ID / address, including the status related to the external account generated by the execution of the contract (such as the key-value of the map type mentioned above), which is relatively fixedly stored in the node storage of a certain shard.

[0123] If we only follow the modulo or segmentation method, when we need to increase or decrease shards, the mapping relationship between most account storage and shards may be changed. This is obviously not economical, and long-term adjustments may cause a large number of operations related to account storage to fail to hit the correct shards and nodes.

[0124] It is precisely with this in mind that, in addition to the above-mentioned modulo and segmentation methods, the consistent hashing method can also be used to distribute the account status storage to the corresponding shards. In this way, the shard can be mapped to the numerical space [0,2^32-1], and the mapping rule can be the shard identifier, such as through a certain hash algorithm for mapping. In addition, the account can also be mapped to the numerical space [0,2^32-1], and the mapping rule can be the account address, registration place, etc., such as through the same hash algorithm for mapping. For a certain account account, if the node satisfies hash(shard)<=hash(account), select the node with the largest hash(shard) to store the account. If there is no shard that meets the above conditions, select the shard with the smallest hash(shard) to store the account, such as Fig.11 It can be simply explained as assigning the corresponding status to the account according to the hash value of the account. Fig.11 The shard corresponding to the hash value of the first shard in the clockwise direction of the ring in the shard. The consistent hashing method is used for allocation. When the shard changes, only a small part of the storage related to the external account will change, so that the storage of most shards will not be adjusted, thereby reducing the problem of low hits.

[0125] In addition, the state storage of the account can also be allocated to the corresponding shard according to the account registration place. The registration place may include the blockchain node connected to the user when registering the account. For example, when the user registers the account, he connects to the blockchain node E through the client, and the node E belongs to the shard 2, then the account generated by the registration corresponds to the shard 2. In other implementation scenarios, the registration place may also be the geographical location where the user is located when registering the account. For example, when a user registers an account, his IP address is located in the Hong Kong Special Administrative Region, and there is a shard in the blockchain system corresponding to the blockchain business of the relevant special administrative region, such as shard 4, then the account registered by the user corresponds to shard 4. Therefore, in another embodiment provided by this specification, the predetermined sharding strategy may include: determining the shard to which the account belongs according to the registration place of the account. The registration place includes the shard to which the user belongs when connecting to the blockchain node through the client when registering the account, or the geographical location where the user's IP is located when registering the account, or the belonging place filled in / selected by the user. For the latter, according to the geographical location where the user's IP is located when registering the account or the belonging place filled in / selected by the user, the state storage of the account can be allocated to the shard of the same / similar geographical location, or the state storage of the account can be allocated to the shard specified by the system.

[0126] By determining the shard to which the account belongs based on the place of registration, some regional businesses can be concentrated in the same shard for processing, and the states involved in the addition, deletion and modification of transactions can be controlled as much as possible within a single shard, which can effectively reduce cross-shard distributed transactions, reduce cross-shard message interactions and transaction processing, and thus improve system throughput and performance. For example, in a blockchain electronic invoice scenario, if there are different shards corresponding to the provinces of China, such as the user account in Guangdong is registered in the shard of Guangdong, and the user account in Zhejiang is registered in the shard of Zhejiang. In actual applications, users in Guangdong usually consume in Guangdong and are more likely to trade with other users in Guangdong; while users in Zhejiang usually consume in Zhejiang and are more likely to trade with other users in Zhejiang. Then users in Guangdong also issue invoices in Guangdong Province in most cases, and similarly, users in Zhejiang also mostly issue invoices in Zhejiang Province. In this way, dividing and determining the shards of accounts based on the place of registration of the user's account can greatly reduce cross-shard transactions and reduce the complexity of the blockchain system.

[0127] In addition, in another embodiment, the present application also provides a shard to which the state storage of an account is configured according to a business relationship. For example, in the cross-border remittance business of blockchain, cross-border transfer transactions are realized through smart contracts, and off-chain assets are anchored to assets issued on the chain. By accessing accounts of different banks through the client, the counterparties of the transfer may be different. According to the frequency and proportion of business transactions, the state storage of accounts with high correlation can be allocated to the same shard. For example, in the cross-border remittance business of blockchain, most of the transfers of account a that accesses bank 1 through the client occur between account b that accesses bank 2 through the client, that is, account a and account b have a large correlation. Therefore, the state storage related to account a and account b generated by calling the smart contract can be allocated to the same shard. Of course, in the different allocation methods mentioned above, the account status of the shard storage can be dynamically adjusted according to the business relationship.

[0128] In addition, as mentioned above, the blockchain sharding mechanism provided in the embodiments of this specification also supports cross-shard transactions, such as through an intermediate node or blockchain main chain that provides a reliable message transmission mechanism.

[0129] Of course, in addition to the cross-account transactions of remittances and electronic invoices mentioned above, there are also some single-account transactions in the blockchain system, such as evidence storage transactions. The initiating account of this type of single-account transaction, the state storage generated by calling the smart contract, is concentrated in the initiating account itself and generally does not involve other accounts. Since there is no cross-shard transaction, when the above state storage solution is applied, it can be more efficient and simple to improve throughput, improve blockchain performance, and easily overcome the storage bottleneck problem.

[0130] The state storage method provided in this application is as follows: Fig. 9 As shown, specifically including:

[0131] S91: The blockchain node belonging to the shard executes the transaction of calling the contract, generating a state related to the blockchain external account to be stored.

[0132] Transactions in the blockchain can support the creation and invocation of smart contracts. For transactions that create contracts, a blockchain node can, for example, receive a transaction containing the creation of a smart contract sent by a client to complete the deployment of the smart contract. Through the P2P network, the transaction that creates a smart contract can be propagated to other blockchain nodes (or to most other blockchain nodes). Each blockchain node that receives this transaction generally verifies and reaches a consensus on the transaction. For example, for a master consensus algorithm, such as Practical Byzantine Fault Tolerance (PBFT), the master node in the blockchain consensus network can initiate a consensus. After consensus is reached, the blockchain nodes in the blockchain network can execute the transaction locally. Specifically, the blockchain node can execute the transaction that creates a contract through a local virtual machine (such as the Ethereum virtual machine EVM) and generate a corresponding contract instance. After the contract is created, a contract account corresponding to the smart contract appears on the blockchain. The storage of the contract account on the blockchain may include codehash and the deployed contract code (usually the bytecode of the contract code). The value of codehash is the hash value of the deployed contract code. This contract account generally has a specific address.

[0133] In addition, it can also be a native contract compiled together with the blockchain code to complete the deployment of smart contracts.

[0134] New asset types can be defined in smart contracts, such as balanceA in the above program code snippet. Of course, multiple asset types can be defined in a smart contract, such as balanceA, balanceB, balanceC, ... As mentioned above, state variables can also be defined in smart contracts. For example, in the solidity high-level development language provided by Ethereum, the state variables that can be defined include two types, one is the state variable of the basic data type, and the other is the state variable of the mapping (map or mapping) type. Through the map type state variable, each external account can be given the ability to hold and trade this newly created digital asset. As in the example of the above code, generally, each external account can correspond to an asset of type balanceA. Then, if there are 10,000 external accounts in the state tree of the blockchain, through the smart contract, each external account can correspond to holding / trading assets of type balanceA, that is, there are 10,000 "external account → balanceA" mappings. Similarly, for assets including type balanceB, there can be 10,000 "external account → balanceB" mappings. And so on. As mentioned above, in addition to the map data structure, other data structures can also be used to define the mapping of external account addresses to an asset type, which is not limited here. The following is an example of a data structure in the form of a map.

[0135] After this contract is successfully created, subsequent external accounts can call this contract. Smart contracts can be executed independently on each node in the blockchain network in the manner specified in the contract code, and the executed transactions, generated status and transaction receipts can be saved on the blockchain. Calling a contract can generally be done by initiating a transaction. The from field of the transaction is the address of the account that initiates the call to the smart contract, the to field can represent the address of the smart contract being called, and the data field of the transaction can include the method for calling the smart contract and the parameters passed in. By calling a smart contract, the contract status corresponding to the external account in the map may change, for example, the balance of a certain asset type corresponding to the external account may change. In this way, the value in the map mapping will change. The changed value needs to be stored on the blockchain. In this way, the contract status includes the status of the corresponding blockchain external account.

[0136] As mentioned above, the contract state to be stored includes the mapping relationship between external accounts and assets defined in the contract. Specifically, the mapping relationship can be defined in the contract through a map data structure or other data structures. Taking the data structure definition of map as an example, the map generally defines the mapping relationship between external accounts and assets. If a new asset is defined in the smart contract, such as a balanceA asset, the mapping relationship between the external account and the balanceA type asset can be defined through map. In addition, a method for defining similar data structures can be set by adapting the compiler and virtual machine, such as:

[0137] schema{

[0138] uint256 balanceP;

[0139] bool owner_flag;

[0140] };

[0141] The above code example can also define the mapping relationship between external accounts and assets. Specifically, uint256 indicates that an asset type called balanceP is defined, which is an unsigned integer with a length of 256 bits. bool indicates a Boolean type variable, corresponding to the owner_flag of the external account. In this way, the mapping relationship between external accounts and assets is also defined. Of course, the compiler and virtual machine need to be adapted to support such a definition in the contract.

[0142] The client can initiate a transaction to call a contract to the blockchain system. In the blockchain system, the transaction to call the contract can be received by the aforementioned main chain, and the transaction can be routed to the shard storing the external account. In the transaction to call the contract, the state of the relevant external account generally changes after execution. The state of the external account after the change, including the state of the relevant external account involved in the contract, such as the mapping relationship between the external account and the asset defined by the map data structure, needs to be stored in the state storage of the node of the corresponding shard. The main chain can act as a role to receive the transaction and route the transaction. The routing transaction, for example, can route the transaction to the shard storing the external account according to the external account whose state changes are involved in the transaction to call the contract. Specifically, the main chain routes the transaction to the shard storing the external account according to the strategies such as modulus, segmentation, and registration place adopted by the blockchain system.

[0143] Furthermore, the blockchain nodes belonging to the shard can execute transactions that call contracts and generate states related to the blockchain external accounts to be stored.

[0144] In addition, similar to S91, the blockchain node belonging to the shard can also be a transaction that executes the creation of a contract. In the process of executing the transaction to create a contract, a state related to the external account of the blockchain to be stored may also be generated, such as initializing the state related to the external account. The following mainly uses the transaction of executing the call contract as an example to illustrate, and the transaction of executing the creation of the contract is similar to this, and will not be repeated. For the transaction to create a contract, similarly, the transaction to create the contract can be received by the aforementioned main chain and routed to the shard storing the external account.

[0145] S93: Store the state to be stored related to the blockchain external account in the state storage of the corresponding blockchain external account.

[0146] like Figure 5 , Figure 6 , Figure 7 , Figure 8 As shown in , the map type state variables in storage can be stored in key-value format. In a specific example, for the map type, key = SHA3 (keyword in the map, variable declaration position), that is, the keyword in the map and the variable declaration position are combined into a string of a certain length (for example, 64 bytes) and then the hash value is calculated. The value can store the actual value of the variable.

[0147] The simplest case is Figure 7As shown in the figure, a smart contract is created in a blockchain system, and a new type of asset is defined in the smart contract. Moreover, in the created contract, only one new type of asset can be defined, or only one of the new types of assets can be enabled when multiple new types of assets are defined (while the other new types of assets are not enabled or initialized). In this case, since each external account corresponds to the balance of one type of asset, the balance of the asset of this type does not need to be organized into a tree form, and can be stored through a key-value. Among them, in this map type, key = SHA3 (keyword in the map, variable declaration position), that is, the keyword and variable declaration position in the map are combined into a string of a certain length (for example, 64 bytes) and the hash value is calculated. Value can store the actual value of the variable, that is, the balance of assets of type balanceA. In this way, the storage_root of the external account can be the hash value of this key-value. Each external account can have such a map data. For example, the storage_root of external account 1 points to a key-value in its map type; external account 2 points to a key-value in its map type; and so on. In summary, for the case where there is only one smart contract in the blockchain system, and only one new type of asset is defined or enabled in the smart contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a hash value of the key-value of the new type of asset related to an external account in each leaf node through a tree structure; the second layer stores the mapping relationship between the external account and the new type of asset in the form of key-value defined by the map.

[0148] As mentioned above, in a smart contract, multiple asset types can be defined, such as balanceA, balanceB, balanceC, balanceD, ... In this way, each external account can have balances corresponding to assets of types balanceA, balanceB, balanceC, balanceD, ... In this case, since each external account corresponds to the balances of multiple types of assets, the balances of multiple types of assets can be organized into a tree form. Figure 6As shown in , in the storage tree of the second layer, a tree form is schematically represented by three nodes, namely, node 1, node 2, and node 3. If this tree is, for example, an MPT tree, then nodes 1, 2, and 3 can schematically represent extension nodes and branch nodes in the MPT tree. Among them, in this map type, key = SHA3 (keyword in the map, variable declaration position), that is, the keyword and variable declaration position in the map are put together into a string of a certain length (for example, 64 bytes) and then the hash value is calculated. value can store the actual value of the variable, that is, the balance of assets of types balanceA, balanceB, balanceC, balanceD, ... As Figure 6 In the example, the leaf nodes of the storage tree of external account 1 have the balances of assets of types balanceA, balanceB, balanceC, balanceD, ... respectively. In this way, the storage_root of the external account can be the root hash value of the key-value tree of assets of types balanceA, balanceB, balanceC, balanceD, .... Each external account can have such map data. For example, the storage_root of external account 1 points to a tree structure of a set of key-values ​​in its map type; the storage_root of external account 2 points to a tree structure of a set of key-values ​​in its map type. And so on. In this way, for the case where there is only one smart contract in the blockchain system, and at least two new types of assets are defined and enabled in the smart contract, the storage of the state tree in the blockchain includes two layers; the first layer stores the root hash value of the key-value of all the new types of assets related to an external account in each leaf node through a tree structure; the second layer stores the mapping relationship defined by the map in the form of key-value between the external account and one of the new types of assets in each leaf node through a tree structure.

[0149] In a blockchain system, multiple smart contracts can be created. For example, multiple smart contracts are created in a blockchain system, and these smart contracts can be organized in a tree structure, such as Figure 8 As shown, the second layer in the figure is the contract storage tree. Each of most smart contracts can define one or more new types of assets. Each smart contract has different states. For example Figure 8In the figure, two contracts are shown that are connected to external account 1 through a tree structure. Each contract can calculate a hash value based on its ID and storage_root, and the hash value can be stored in a leaf node of the second-level tree structure, such as schematic_storage_root in the figure. For the case where each of the two created contracts only defines one new type of asset, or when multiple new types of assets are defined and only one of them is enabled (while the other new types of assets are not enabled or initialized), each contract corresponds to the balance of one type of asset, so the balance of this type of asset does not need to be organized into a tree form, and can be stored through a key-value, similar to Figure 7 The second layer structure in the blockchain. In this way, the storage_root of a smart contract can be the hash value of this key-value. And so on. In summary, for the case where there are at least two smart contracts in the blockchain system, and only one new type of asset is defined or enabled in the smart contract, the storage of the state tree in the blockchain includes three layers; the first layer stores the root hash value of all smart contract-related information related to an external account in each leaf node through a tree structure; the second layer stores the hash value of the key-value of the new type of asset related to an external account in each leaf node through a tree structure; the third layer stores the mapping relationship between the external account and the asset in the form of key-value defined by the map.

[0150] In a blockchain system, multiple smart contracts can be created, and multiple asset types can be defined in each contract, such as balanceA, balanceB, balanceC, balanceD, etc. This situation can be as follows Figure 5As shown. Two contracts are shown by connecting external account 1 through a tree structure. This is the second-layer contract storage tree. In fact, the second-layer storage can include multiple smart contracts, that is, there can be multiple leaf nodes. Each contract can calculate a hash value based on its ID and storage_root, and the hash value can be stored in a leaf node of the second-layer tree structure, such as schematic_storage_root in the figure. Each leaf node of the second layer can be used to store the root hash value of the storage of a smart contract involved in the external account, which can be calculated based on the hash value of the contract ID and storage involved in the external account. The third layer is the storage tree. Specifically, the root node of the third-layer tree structure is the root hash value of the state variable in the smart contract involved in the external account. Similarly, the third layer can be schematically represented by a total of three nodes, node 1, node 2, and node 3, in the form of an MPT tree. Specifically, it can represent an extension node and a branch node in the MPT tree. Each leaf node of the third layer can be used to store the value of a state variable in the contract. In the above three-layer tree structure, a part of the data stored on the path from the root node to the leaf node of each tree can be connected to form a key, and the leaf node can store a value. In this way, through such a storage model, the key-value of the state variable in each smart contract involved in the external account can be stored under each external account. In summary, for the case where there are at least two smart contracts in the blockchain system, and only at least two new types of assets are defined or enabled in the smart contract, the storage of the state tree in the blockchain includes three layers; the first layer stores the root hash value of all smart contract-related information related to an external account in each leaf node through a tree structure; the second layer stores the root hash value of the key-value of all new types of assets involved in a smart contract related to an external account in each leaf node through a tree structure; the third layer stores the mapping relationship defined by the map in the form of key-value between the external account and a new type of asset in each leaf node through a tree structure.

[0151] Above Figure 5-8 In the example of , the first layer can also store the transaction count of the external account in each leaf node through the tree structure.

[0152] Above Figure 5 , Figure 8In the example, it is shown that the second layer also stores the number of the associated smart contract in each leaf node through the tree structure. In addition, the second layer may not store the number of the associated smart contract in each leaf node, but the root node of the second layer stores the address of the involved smart contract or a mapping value based on the address of the involved smart contract in the path from the root node of the second layer to each leaf node of the second layer through the tree structure of the second layer.

[0153] As mentioned above, there are two types of state variables that can be defined in smart contracts: one is a state variable of basic data type, and the other is a state variable of mapping type. The above-mentioned map type state variable is related to each external account. In this way, for each external account, this map type state variable is a local type state variable. In addition, the basic data type defined in the smart contract may be related to each external account, not just one external account. In this way, the state variable of the basic data type belongs to the global type state variable.

[0154] In addition, as mentioned above, after the smart contract is created, a contract account will appear. The contract account may also be related to each external account, not just one external account. For example, in a smart contract about betting, the transfer between external account A and external account B under the weather conditions of the next day is stipulated. If the next day is sunny, external account A will transfer an asset (such as 50 yuan) to external account B. If the next day is not sunny, external account B will transfer an asset (such as 50 yuan) to external account A. When external account A and external account B call this smart contract, they need to transfer an asset (such as 50 yuan) to the contract account respectively. In this way, the state variables in the contract account also belong to the global type of state variables.

[0155] The aforementioned Figure 5-8 The storage of local type state variables is illustrated in the example. The storage of global type state variables is explained below.

[0156] The first way is to set the storage of the state variables of the basic data types in the smart contract and the state variables of the contract account in the contract account. For example, the state variables of the basic data types and the state variables of the contract account are stored in the storage of the contract account. Figure 5 Based on Fig.12Take the state_root in the block header as an example to illustrate. The hash value of the root node of the entire state tree is stored in the state_root in the block header. The leaf nodes of the first-level tree structure can be used to store the root hash values ​​of the external account storage and the contract account storage. There can be several external accounts and contract accounts respectively. The root hash of the account information of each contract account in the first-level leaf node can be calculated based on the nonce, balance, codehash of the contract account and the root hash value of the storage of the smart contract involved in the contract account. The root hash value of the storage of the smart contract is as follows: Fig.12 storage_root of contract account 2 in the contract account. Similarly, the second layer can be schematically represented by a MPT tree with three nodes, node 1, node 2, and node 3. Each leaf node of the second layer can be used to store a global type of state variable involved in the contract account. As mentioned above, the state variable involved in this contract account can be a basic data type or a state variable in the contract account. Specifically, the root node of the tree structure of this layer is the root hash value of the global type of state variable in the smart contract involved in the contract account. Similarly, this layer can be schematically represented by a MPT tree with three nodes, node 1, node 2, and node 3, and specifically, it can represent the extension node and branch node in the MPT tree. Each leaf node of the third layer can be used to store the value of a state variable in the contract. In the structure of the above tree, a part of the data stored on the path from the root node to the leaf node of each tree can be connected to form a key, and the leaf node can store the value. In this way, through such a storage model, the key-value of the global type of state variable involved in the contract account can be stored.

[0157] In this way, for a blockchain node to execute a transaction that calls a contract, a state to be stored related to the blockchain contract account is generated, such as a state variable of a basic data type in the contract and a state variable of a contract account. The state to be stored related to the blockchain contract account can be stored in the state storage of the corresponding blockchain contract account, that is, the state variable of the basic data type in the contract to be stored and the state variable of the contract account are stored in the state storage of the corresponding blockchain contract account. The key-value mapping relationship of the global type state variable involved in the blockchain contract account is stored in the state storage of the blockchain contract account through a tree structure, which is similar to the above and will not be repeated.

[0158] The second way is that, in the contract account, it is possible to no longer set storage related to the contract state, but to set a global state storage independent of the external account storage and the contract account storage. In this way, the state to be stored related to the blockchain contract account can be stored in a global state storage independent of the external account storage and the contract account storage, that is, the state variables of the basic data types in the contract to be stored and the state variables of the contract account are stored in a global state storage independent of the external account storage and the contract account storage. Specifically, in the global state storage, the key-value mapping relationship of the state related to the blockchain contract account can be stored through a tree structure, that is, the state variables of the basic data types in the contract to be stored and the state variables of the contract account are stored in a global state storage independent of the external account storage and the contract account storage through a tree structure.

[0159] In addition, there can be a third way, that is, storing the state variables of the contract account to be stored in the state storage of the corresponding blockchain contract account, and storing the state variables of the basic data type in a global state storage independent of the external account storage and the contract account storage. Specifically, the key-value mapping relationship of the state variables of the blockchain contract account can be stored in the state storage of the contract account through a tree structure, and the key-value mapping relationship of the state variables of the basic data type can be stored in the global state storage through a tree structure.

[0160] The above tree structure can adopt a hexadecimal tree. Generally, the global state in a smart contract does not exceed 32 state variables. A two-layer tree structure can be adopted by adopting a hexadecimal tree. Then the second-layer tree structure can include 16*16=256 leaf nodes, which is much larger than 32, so it can meet the number of global states that may be included in a general smart contract.

[0161] It should be noted that the blockchain nodes mentioned in this specification focus on the concept of logical nodes. In other words, a physical node can also be logically divided into multiple logical nodes. Of course, the blockchain nodes in this specification can also be applied to the case of physical nodes.

[0162] Through the above-mentioned embodiments of the present application, the blockchain system includes at least two shards, and the nodes in different shards store the status of different sets of external accounts, and store the status to be stored related to the blockchain external account in the status storage of the corresponding blockchain external account. The status storage of each external account corresponds to the status of the external account, so that different shards in the blockchain system store the status of different sets of external accounts. In this way, the problem of single account hotspots is avoided. At the same time, the load pressure of the state storage borne by each shard is relatively small, which can improve the performance of the entire blockchain system. Moreover, after the status storage is dispersed to each external account, since the number of states of an external account is relatively small, the complete blockchain state is not stored, thereby solving the storage capacity bottleneck problem. At the same time, the method of the present application will not be like Figure 3 The status of all external accounts in the contract account are concentrated in the state storage of the contract account, which can greatly reduce the depth of the tree structure of each external account, thereby shortening the time for searching and updating external accounts and improving the read and write efficiency of blockchain storage.

[0163] For global states, even if the first method mentioned above is used to store all of them in the state storage of the contract account, the requirement of 32 global states can generally be met, that is, a two-layer deep attribute structure can meet the storage requirements, thereby greatly reducing the depth of the tree. The second or third method mentioned above can also greatly reduce the depth of the tree.

[0164] like Fig.10 As shown, the embodiment of the present application further provides a blockchain system, which includes at least two shards, and the nodes in different shards are used to store the status of different external account sets; and,

[0165] The state related to the blockchain external account generated by the blockchain node belonging to the shard executing the transaction of calling the contract is stored in the state storage of the corresponding blockchain external account.

[0166] The state related to the blockchain external account may include:

[0167] The mapping relationship between external accounts and assets defined in the contract.

[0168] The mapping relationship between external accounts and assets defined in the contract may include:

[0169] The mapping relationship between external accounts and assets is defined through the map data structure.

[0170] The mapping relationship between the external account and the asset defined by the map data structure can be stored by key-value.

[0171] If there is only one smart contract in the blockchain system, and only one new type of asset is defined or enabled in the smart contract, the storage of the state tree in the blockchain can include two layers;

[0172] The first layer stores a hash value of the key-value of the new type of asset related to an external account in each leaf node through a tree structure;

[0173] The second layer storage definition includes the key-value mapping relationship between the external account and the new type of asset.

[0174] If there is only one smart contract in the blockchain system, and at least two new types of assets are defined and enabled in the smart contract, the storage of the state tree in the blockchain may include two layers;

[0175] The first layer stores a root hash value of the key-value of all new types of assets related to an external account in each leaf node through a tree structure;

[0176] The second layer stores the defined key-value mapping relationship between the external account and the new type of asset in each leaf node through a tree structure.

[0177] For the case where there are at least two smart contracts in the blockchain system, and only one new type of asset is defined or enabled in the smart contract, the storage of the state tree in the blockchain may include three layers;

[0178] The first layer uses a tree structure to store the root hash value of all smart contract-related information related to an external account in each leaf node;

[0179] The second layer stores a hash value of a key-value of the new type of asset involved in a smart contract in each leaf node related to an external account through a tree structure;

[0180] The third layer storage definition includes the key-value mapping relationship between the external account and the asset.

[0181] For the case where there are at least two smart contracts in the blockchain system, and at least two new types of assets are defined or enabled in the smart contract, the storage of the state tree in the blockchain may include three layers;

[0182] The first layer uses a tree structure to store the root hash value of all smart contract-related information related to an external account in each leaf node;

[0183] The second layer stores the root hash value of the key-value of all new types of assets involved in a smart contract in each leaf node related to an external account through a tree structure;

[0184] The third layer stores a defined mapping relationship between the external account and a key-value of the new type of asset at each leaf node through a tree structure.

[0185] The first layer can also store the transaction count of the external account in each leaf node through a tree structure.

[0186] The second layer can also store the number of the associated smart contract in each leaf node through a tree structure.

[0187] The state related to the blockchain contract account generated by the blockchain node executing the transaction of calling the contract can be stored in the state storage of the corresponding blockchain contract account.

[0188] The state related to the blockchain contract account may include state variables of basic data types in the contract and state variables of the contract account; the state storage of the contract account may store the key-value mapping relationship of the state related to the blockchain contract account through a tree structure.

[0189] The state related to the blockchain contract account generated by the blockchain node executing the transaction of calling the contract can be stored in a global state storage independent of the external account storage and the contract account storage; the global state storage can store the key-value mapping relationship of the state related to the blockchain contract account through a tree structure.

[0190] The state variables of the contract account may be stored in the state storage of the corresponding blockchain contract account; the state storage of the contract account may store the key-value mapping relationship of the state variables of the blockchain contract account through a tree structure;

[0191] The state variables of the basic data types may be stored in a global state storage that is independent of the external account storage and the contract account storage; the global state storage may store the key-value mapping relationship of the state variables of the basic data types through a tree structure.

[0192] The nodes in different shards store the states of different external account sets, which may include:

[0193] The external accounts corresponding to different shards form external account sets at the same interval starting from different initial values ​​according to the unique identifiers of the external accounts; or,

[0194] The external accounts corresponding to different shards are segmented according to the unique identifier of the external account to form an external account set; or,

[0195] Based on the unique identifier of the external account, the state storage of the external account is allocated to the corresponding shard using consistent hashing; or,

[0196] The shard to which the account belongs is determined based on the account's registration location.

[0197] The place of registration may include:

[0198] When a user registers an account, they connect to the shard to which the blockchain node belongs through the client; or

[0199] The geographical location of the user's IP address when the user registered their account; or

[0200] The place of attribution filled in / selected by the user.

[0201] Based on the geographical location of the user's IP when registering the account or the place of affiliation filled in / selected by the user, the state storage of the account can be allocated to the shard with the same / similar geographical location, or it can be allocated to the shard specified by the system.

[0202] The nodes in different shards store the states of different external account sets, which may include:

[0203] Configure the shard to which the account's state storage belongs based on the business relationship.

[0204] The blockchain system may further include a main chain for receiving the transaction of calling the contract and routing the transaction to the shard storing the external account.

[0205] The transaction of calling the contract received by the main chain can route the transaction to the shard storing the external account according to the external account whose state has changed and involved in the transaction of calling the contract.

[0206] like Fig.13 As shown, an embodiment of the present application further provides a blockchain node, which belongs to a shard in the blockchain system, including:

[0207] A storage unit 132 is used to store the state of an external account set, and the corresponding external account set is different from the external account set in the blockchain node in other shards;

[0208] The execution unit 131 is used to execute the state storage method as described above.

[0209] like Fig.14As shown, an embodiment of the present application further provides a blockchain node, which belongs to a shard in the blockchain system and is used to store the state of an external account set, and the corresponding external account set is different from the external account set in the blockchain nodes in other shards;

[0210] The blockchain node includes:

[0211] Processor 141;

[0212] The memory 142 stores a program, wherein when the processor executes the program, the state storage method described above is executed.

[0213] The above-mentioned state sharding scheme is a solution provided in this application. In addition, there may be other state sharding schemes. Regardless of the state sharding scheme, as long as the nodes in different shards store the states of different sets of external accounts, it will involve the problem of determining the world state of all accounts in different shards.

[0214] For example, an account in Shard 1 may have a transaction related to another account in Shard 2. Specifically, for example, a transfer from an account in Shard 1 to another account in Shard 2, or an account in Shard 1 initiates a transaction to call a contract, and the called contract, when executed, involves operations on an account in Shard 2. In the case of calling a contract, according to the mapping relationship between external accounts and assets defined in the contract mentioned above, in a specific example, for example, an account in Shard 1 initiates the repayment of a new asset type, and the accounts under this asset type (including external accounts and contract accounts) each have a certain balance. Fig.15 External account 1 in shard 1 in the transfers a certain amount of assets of this type to the contract account, and then according to the conditions in the contract, the contract account transfers it to Fig.15 External account 6 of shard 2.

[0215] Obviously, the above examples involve cross-shard transactions. This application proposes a main chain-based cross-shard transaction method that can be implemented in a main chain-based blockchain sharding system. Fig.15As shown, in addition to several shards, there is also a main chain. The main chain includes several blockchain nodes, such as Q1, Q2, Q3 and Q4 in the figure. The main chain is connected to each shard. As mentioned above, although the shards are connected to each other through connecting lines in the figure, it is also possible that the shards are not all interconnected, or each shard is not connected to other shards. For the last case, that is to say, the shards may not be connected to each other, but only to the main chain. Here, the shards are connected, which means that a node in a shard is connected to any node in another shard, or a node in a shard is connected to one or part of the nodes in another shard. Similarly, the shards are connected to the main chain, which means that a node in a shard is connected to any node in the main chain or a node in a shard is connected to one or part of the nodes in the main chain, or a node in the main chain is connected to any node in the shard or one or part of the nodes in the shard.

[0216] Nodes in different shards can store the status of different sets of external accounts, including the above Figure 5-12 The state related to the external account generated by the transaction of creating and / or calling the contract in the corresponding embodiment may also be the state of the external account generated by the ordinary transfer transaction. Figure 5-12The state sharding scheme of the corresponding embodiment, instead of storing the state related to the external account generated by the transaction of executing the creation and / or calling the contract in the state storage of the contract account, there may be a situation where nodes in different shards store a collection of different contract account states, or a situation where nodes in different shards store the states of different contract account sets, which is also applicable to the scheme of the present application to be mentioned below. The situation where the nodes in different shards store a collection of different contract account states, for example, there is a contract in the blockchain system, and the contract account corresponding to the contract has different states, such as state a, state b, state c and state d. A simpler one can be that the nodes in shard 1 store the state set {a}, the nodes in shard 2 store the state set {b}, the nodes in shard 3 store the state set {c}, and the nodes in shard 4 store the state set {d}. The nodes in different shards store the status of different sets of contract accounts. For example, there are 4 contracts in the entire blockchain system, namely Contract 1, Contract 2, Contract 3 and Contract 4, which correspond to Contract Account 1, Contract Account 2, Contract Account 3 and Contract Account 4 respectively. A simpler one can be that the nodes in shard 1 store the status set {the status of contract account 1}, the nodes in shard 2 store the status set {the status of contract account 2}, the nodes in shard 3 store the status set {the status of contract account 3}, and the nodes in shard 4 store the status set {the status of contract account 4}. In addition, it can be understood that for the existence of multiple contracts and each contract has multiple states, it can also be a mixture of the above two situations. Generally speaking, the above situations can be referred to as different shards storing different sets of states.

[0217] For different shards storing different state sets, the solution proposed in this application introduces the main chain. The schematic architecture is as follows: Fig.16 As shown. Fig.16 In the example, Shard 1 and Shard 2 may generate new blocks at different paces; of course, they may also be in sync, and the explanation here is mainly based on the inconsistency. It should be noted that for simplicity, only the case of two shards is shown here. The case of more than two shards is similar and will not be repeated. Moreover, only the case of Shard 1 generating blocks 101 and 102 in sequence, and the case of Shard 2 generating blocks 201 and 202 in sequence are shown. In fact, it can be understood that transaction requests are processed in the shards, and after reaching a consensus through a consensus mechanism, transactions are executed and blocks are generated. The block numbers of the generated blocks are generally continuous, and the hash value of the previous block is locked through a field in the block header of the next block, for example, through Figure 3 The hash value of a block is generally the result of the hash calculation of all fields in the block header. In the block header of the block generated by the shard, such as Figure 3As shown in , it generally includes the block number (Block Num), timestamp (Timestamp), the hash value of the previous block (Prev Hash), as well as the transaction root hash (Transaction_Root), state root hash (State_Root), and may also include the receipt root hash (Receipt_Root) and random number (Nonce). In the block body of the block generated by the shard, such as Figure 3 As shown, it can generally include the original transaction list, which can be organized by a tree structure, such as the MPT tree mentioned above, or a merkle tree, etc. The hash value of the root of the original transaction list organized by the tree structure is stored in the Transaction_Root of the block header. As mentioned above, state_root can be the hash value of the root of the MPT tree composed of the status of all accounts in the current blockchain, that is, the state tree pointing to state_root is a state tree in the form of MPT. In the case where Receipt_Root is included in the block header, Receipt_Root can be the hash value of the root of the Merkle or MPT tree composed of all receipts in the current block.

[0218] For example Fig.16 As shown in , shard 1 generates blocks 101 and 102 sequentially, and shard 2 generates blocks 201 and 202 sequentially. Shard 1 has a corresponding state set in block 101 and a corresponding state set in block 102. Shard 2 has a corresponding state set in block 201 and a corresponding state set in block 202.

[0219] In the embodiment of the present application, a system of blockchain shards including a main chain is provided. The main chain may include several nodes. Generally, the nodes in the main chain have a high degree of credibility, and the main chain composed of these nodes meets the Byzantine fault tolerance requirements. The main chain can have its own clock, such as Fig.16 The main chain timeline shown in is the timeline expressing the main chain clock. According to the main chain timeline, the generation time of shard 2 block 201 is t 2 At the generation time t of main chain block 10001 1 and the generation time t of main chain block 10002 3 The generation time of shard 1 block 101 is t 4 At the generation time t of main chain block 10002 3 and the generation time t of main chain block 10003 5 The generation time of shard 2 block 202 is t 6 At the generation time t of main chain block 10003 5 and the generation time t of main chain block 10004 7The generation time of shard 1 block 102 is t 8 At the generation time t of main chain block 10004 7 After that. Generally, the frequency of generating blocks on the main chain is higher than the frequency of generating blocks in each shard, or at least not lower than the frequency of generating blocks in each shard.

[0220] For example, node A in shard 1 at t 4 Before the moment, a transaction initiated by the client is received, for example, a normal transfer transaction, which is a transfer from external account 1 in shard 1 to external account 6 in shard 2. After receiving the transaction, for example, node A in shard 1 broadcasts the transaction to other nodes in shard 1. After a short period of time, a certain number of transactions including the transaction can be packaged by the master node (for example, node C) in shard 1 and a consensus proposal can be initiated. After consensus in shard 1, these packaged transactions are executed by each node in shard 1. Since these transactions include cross-shard transactions (also called cross-shard transactions), only the operation of deducting a certain balance in external account 1 can be executed in shard 1. The remaining operations of increasing a certain balance for external account 6 in shard 2 need to be executed by nodes in shard 2. Then, this process requires forwarding some operations of the transactions received in shard 1 to shard 2 for execution by shard 2.

[0221] For another example, node B in shard 1 is at t 4 A transaction initiated by the client is received before the moment, for example, a transaction to call a contract. This transaction is initiated by external account 1 in shard 1 to call a smart contract. After node B in shard 1 receives the transaction, it broadcasts the transaction to other nodes in shard 1. After a period of time, the master node in shard 1 (such as node C) can package a certain number of transactions including this transaction and initiate a consensus proposal. After consensus in shard 1, the packaged transactions are executed by each node in shard 1. The smart contracts in these transactions may involve cross-shard transaction transactions during the execution process. As in the previous example, an account in shard 1 initiates the repayment of a certain amount of a new asset type. The accounts under this asset type (including external accounts and contract accounts) each have a certain balance. As Fig.15 External account 1 in shard 1 in the transfers a certain amount of assets of this type to the contract account, and then according to the conditions in the contract, the contract account transfers it to Fig.15 Shard 2's external account 6. Shard 1 can deduct a certain new asset type balance from external account 1; Shard 2 can add a certain new asset type balance to external account 6, and this operation needs to be performed by the node in Shard 2. Then, this process needs to forward part of the operations of the transaction received in Shard 1 to Shard 2 for execution.

[0222] The present application can be implemented by a block sharding system based on a main chain. Since the nodes in the main chain have a high degree of credibility, the operations involving other shards (hereinafter referred to as target shards) in the cross-shard transactions received in one shard (hereinafter referred to as the source shard) can be sent to the main chain, and forwarded by the main chain to the target shard. Specifically, Fig.17 A method for executing cross-shard transactions in a blockchain system including shards in an embodiment of the present application is shown, including:

[0223] S171: In the process of the source shard generating the source shard block, the cross-shard transaction in the source shard block is determined, and the cross-shard transaction that needs to be executed by the target shard in the cross-shard transaction is sent to the main chain.

[0224] The client can initiate a transaction request to the connected node in the source shard. As mentioned above, the transaction can be a transfer transaction or a transaction to create / call a contract. The node in the source shard that receives the transaction initiated by the client can then broadcast the transaction to other nodes in the source shard, or forward it to the master node. Taking the PBFT consensus algorithm as an example, after a period of time, the master node in the source shard can package a certain number of transactions including the transaction and initiate a consensus proposal. It should be noted that the transactions packaged by the master node in the source shard can include not only cross-shard transactions, but also intra-shard transactions.

[0225] For ordinary transfer transactions, the transaction structure is relatively simple, and whether it is a cross-shard transaction can be determined based on the initiator (indicated by the from field) and the receiver (indicated by the to field) of the transaction. Generally, for the aforementioned state sharding scheme, nodes in different shards store the status of different external account sets. In the client that initiates the transaction request, the account logged into the client has the corresponding account status stored in the connected source shard. In other words, generally, an external account stored in a shard can initiate a transaction in this shard through the client, and the account indicated by the from field in the transaction has the corresponding external account status stored in this shard. Furthermore, the nodes in this shard can judge based on the to field in the transfer transaction. If the account in the to field does not have a corresponding external account status in this shard, the transaction is a cross-shard transaction. For intra-shard transactions, the accounts indicated by the from field and the to field have corresponding external account status in this shard.

[0226] For creating / calling contract transactions, the client can initiate contract-related transaction requests to the connected nodes in the source shard. Similarly, the account indicated by the from field in the transaction stores the corresponding external account status in this shard, and the to field indicates the address of the contract (calling the contract) or empty (creating the contract). The contract code may involve one or more target accounts, which may include external accounts and / or accounts of another contract. In the case where the target account is another contract account, it is generally called by one contract, and the other contract may involve some external accounts. The same is true for more levels of contract calls. Due to the complexity of the contract, in many cases, it is only when the contract is executed that it is determined which accounts other than the initiator (indicated by the from field) are involved, such as complex conditional judgments in the contract and the case of a contract calling a contract. Specifically, it is likely that one or more target accounts involved can be determined when the contract is executed. The aforementioned state sharding scheme, in which the blockchain nodes in the shards execute transactions that create and / or call contracts, stores the generated states related to the blockchain external accounts in the state storage of the corresponding blockchain external accounts. The states related to the blockchain external accounts include the mapping relationship between external accounts and assets defined in the contract, such as the mapping relationship between external accounts and assets defined by the map data structure. As mentioned above, there may also be situations where nodes in different shards store sets of different contract account states, or where nodes in different shards store states of different contract account sets, which will not be repeated. In this way, the source shard determines whether the transaction is a cross-shard transaction based on whether it involves accounts stored on other shards other than the current shard during the execution of the contract. For example, each node in the source shard can determine whether the transaction is a cross-shard transaction based on whether it involves accounts stored on other shards other than the current shard during the execution of the transaction after reaching a consensus.

[0227] For ordinary transfer transactions, the source shard can filter out cross-shard transfer transactions according to the target account indicated by the to field. If the target external account of the ordinary transfer transaction indicated by the to field does not belong to the external account set corresponding to this shard, the ordinary transfer transaction is judged as a cross-shard transfer transaction. For cross-shard transactions, since only the from field indicates the external account in the source shard in the external account set corresponding to the source shard, for ordinary transfer transactions, the balance operation can only be performed on the external account in the source shard indicated by the from field in this shard by executing the transaction. The balance operation of the target external account in other shards indicated by the to field in the ordinary transfer transaction cannot be performed in the source shard. Therefore, the source shard can send the transaction that needs to be executed by the target shard to the target shard. For example, in a source shard block generated by the source shard, 1,000 transactions are packaged, of which 500 are ordinary transfer transactions, and the source shard can determine that these 500 ordinary transfer transactions include 200 cross-shard transactions. The source shard can keep the transactions that need to be executed locally in the 200 cross-shard transactions, that is, execute the balance operations of the external accounts involved locally, and send the transactions that need to be executed by the target shard in the 200 cross-shard transactions to the target shard.

[0228] For transactions that create / call contracts, as mentioned above, due to the complexity of contracts, in many cases it is impossible to determine whether the transaction involves a cross-shard transaction from the contract code itself, especially for transactions that call contracts. The nodes in the source shard can determine whether the transaction is a cross-shard transaction based on whether it involves accounts stored on shards other than the current shard during the contract execution process after reaching a consensus. Similarly, for cross-shard transactions, such as cross-shard transactions involving contract calls, the source shard can execute transactions involving accounts in the current shard during the execution of the transaction, that is, change the status of the accounts involved in the current shard, including the status of external accounts and / or contract accounts. As for changes in the account status corresponding to the target shard, the source shard can send the transactions that need to be executed by the target shard in these cross-shard transactions to the target shard.

[0229] For the source shard, since the operations of the target shard involved in these cross-shard transactions need to be sent to the target shard for execution, before it is determined that the target shard has been executed, even if the nodes in the source shard have completed consensus in their own shard and executed these cross-shard transactions in the source shard block, they will not submit the changed status of the relevant accounts in their own shard generated by the cross-shard transactions in the source shard block to the database, that is, they will not be persistently stored. When the source shard receives a response or confirmation such as a commit instruction from the target shard that the transaction needs to be executed by the target shard in the cross-shard transaction (this depends on the design of the interaction protocol), the nodes in the source shard will submit the transaction executed by the source shard in the cross-shard transaction locally to complete the persistent storage.

[0230] As mentioned above, the master node in the source shard packages a certain number of transactions including this transaction and initiates a consensus proposal. After reaching a consensus, each node in the source shard can execute the transaction locally, but the execution result is not submitted to the underlying database. After reaching a consensus, each node in the source shard executes the transaction locally, and the status of the relevant accounts in this shard will change, including the change of the status of the external account and / or the contract account. The source shard can generate a shard block based on these changed states. After the status of the relevant external account and contract account changes, each node in the source shard can calculate the hash value of the root node of the new state tree (that is, the aforementioned state root hash, State_Root) according to the organizational structure of the merkle tree or MPT tree. The obtained State_Root can be filled in the block header of the block. Taking the MPT tree as an example, as mentioned above, state_root is the hash value of the root of the MPT tree composed of the status of all accounts in the current block, that is, the state tree pointing to state_root is an MPT-style state tree. The root node of this MPT tree can be an extension node or a branch node, and State_Root generally stores the hash value of this root node. Although the current block may involve changes in the status of some accounts in the account status corresponding to the current shard, that is, the transactions included in the current block are only related to some accounts in the corresponding accounts of the corresponding shard, it is possible to generate a State_Root that includes the status of all accounts corresponding to the current shard by referencing the unchanged status in the previous block. For example, Fig.10As shown, the accounts involved in shard 1 include {external account 1, external account 5, external account 9, external account 13, external account 17, external account 21, external account 25, external account 29, external account 33, external account 37, external account 41}, and the transactions packaged in this block only involve changes in the status of {external account 1, external account 9, external account 21, external account 33}, while the status of {external account 5, external account 13, external account 17, external account 25, external account 29, external account 37, external account 41} has not changed. According to the organizational form of the MPT tree, the status of the changed external accounts can be added to the status of this block, and the latest unchanged account status in the previous block can be referenced to obtain the hash value of the root node of the MPT tree.

[0231] In the process of generating source shard blocks, each node in the source shard can organize the transactions packaged by the master node according to the tree structure of the merkle tree or MPT tree for Transaction_Root, and the hash value of the tree root is Transaction_Root. This Transaction_Root can be filled in the block header of the source shard block. In the case where the block header of the source shard block includes Receipt_Root, it is generally similar to the above-mentioned Transaction_Root. After the transaction is executed locally, the generated receipt is generated according to the organization form of the merkle tree or MPT tree to generate Receipt_Root, and filled in the block header of the source shard block. As mentioned above, the block header generally also includes the block number, timestamp, random number, hash of the previous block, etc.

[0232] The above-mentioned source shard sends the transaction that needs to be executed by the target shard in the cross-shard transaction to the target shard, which can be sent through the main chain. Specifically, it can be sent by the master node to the node in the main chain after reaching a consensus on the source shard block in the source shard, or it can be sent by one or more nodes to the master node after reaching a consensus on the source shard block in the source shard. In one example, at least 2f+1 nodes out of at least 3f+1 nodes that meet Byzantine fault tolerance included in the source shard can send the same transaction that needs to be executed by the target shard to one or more nodes in the main chain.

[0233] As mentioned above, the block body of the block generated by the shard generally includes the original transaction list. The transactions in the original transaction list are organized according to the tree structure of the merkle tree or MPT tree, and the hash value of the tree root is Transaction_Root. In addition, the block body of the shard block generated by the source shard may also include the cross-shard transactions in the original transaction list that need to be executed by the target shard. Fig.18 As shown, in the shard block 201 and shard block 202 generated by shard 2, in addition to the original original transaction list, a cross-shard transaction list may also be included in the block body, which includes cross-shard transactions that need to be executed by the target shard in the cross-shard transaction. The cross-shard transaction list can generally be a subset of the original transaction list in the block body. It should be noted that since there may be cross-shard transactions between shard 2 and different target shards, the cross-shard transaction list in the shard block generated by shard 2 may include cross-shard transactions that need to be executed by multiple different target shards. Correspondingly, in the block header, a field, such as cross-shard transaction_root, can be set to store the hash value of the root of the cross-shard transaction in the block body organized according to the tree structure of the merkle tree or MPT tree. Through the cross-shard transaction_root, the cross-shard transaction list in the block body can be locked into the block header. In this way, the hash value of the shard block can be a hash calculated based on each field in the block header, and these fields may include cross-shard transaction_root. The next block in a shard can lock the hash value of the previous block through the Prev_Hash field in the block header.

[0234] In addition to sending the cross-shard transaction to the main chain, the source shard can also send the block header of the generated source shard block to the main chain.

[0235] S173: During the process of generating a main chain block from the main chain, the received cross-shard transaction that needs to be executed by the target shard is filled into the block body of the main chain block, and the cross-shard transaction that needs to be executed by the target shard is sent to the corresponding target shard according to the identifier of the target shard.

[0236] After receiving the cross-shard transaction from the source shard, the node in the main chain can verify the cross-shard transaction first. For example, the hash value of the root node of the tree formed by the cross-shard transaction can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction received this time is repeated with the cross-shard transaction received previously. If it is repeated, the cross-shard transaction sent this time can be stopped, otherwise it can continue to be processed.

[0237] The master node in the main chain can collect transactions from the source shard, or the non-master node in the main chain can receive transactions from the source shard and forward these transactions to the master node in the main chain. These transactions may include a list of cross-shard transactions sent by the source shard. As mentioned above, the list of cross-shard transactions sent by each source shard may include cross-shard transactions that need to be executed by multiple different target shards. Fig.15For example, in the case of 4 shards, the main chain may receive cross-shard transactions from shards 1 to shard 4. The cross-shard transactions sent by shard 1 include {cross-shard transactions in shard 1 need to be executed by shard 2, and cross-shard transactions in shard 1 need to be executed by shard 3}, and the cross-shard transactions sent by shard 2 include {cross-shard transactions in shard 2 need to be executed by shard 1, cross-shard transactions in shard 2 need to be executed by shard 3, and cross-shard transactions in shard 2 need to be executed by shard 3}. The cross-shard transaction in Shard 3 needs to be executed by Shard 2, and the cross-shard transaction in Shard 3 needs to be executed by Shard 4. The cross-shard transaction sent by Shard 4 includes {the cross-shard transaction in Shard 4 needs to be executed by Shard 1, the cross-shard transaction in Shard 4 needs to be executed by Shard 2, and the cross-shard transaction in Shard 4 needs to be executed by Shard 3}. As shown in the above example, the cross-shard transaction can include the identifier of the target shard or the identifier of the source shard.

[0238] The master node in the main chain can package a certain number of cross-shard transactions sent by each shard within a period of time and initiate a consensus proposal. In addition, the content packaged by the master node in the main chain can also include other transactions in addition to the cross-shard transactions. After reaching a consensus in the main chain, each node in the main chain executes these packaged transactions to generate a main chain block. The nodes in the main chain execute these packaged transactions, not the cross-shard transactions therein. As mentioned above, the account status corresponding to these cross-shard transactions is stored in the target shard, so the operations on the account status corresponding to these cross-shard transactions need to be executed by the target shard.

[0239] Each node in the main chain executes these packaged transactions and generates blocks, which may include filling the cross-shard transactions that need to be executed by the target shard into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-shard transactions into a tree with the same tree structure, and generate a hash value based on the root of the tree and fill the hash value into the transaction root hash field of the block header of the main chain block. After adding the block number, timestamp, hash of the previous block and other fields to the block header of the main chain block, the main chain block is generated.

[0240] Each node in the main chain executes these packaged transactions and generates blocks, and fills the cross-shard transactions that need to be executed by the target shard into the block body of the main chain block. Specifically, the cross-shard transactions executed by the target shard can be filled into the block body of the main chain block in the order of the cross-shard transactions that need to be executed by the target shard in the message of the consensus proposal initiated by the master node in the main chain, such as Fig.19In the cross-shard transaction list shown in . In addition, cross-shard transactions can also be grouped according to the target shard, and the grouped cross-shard transactions can be filled into the block body of the main chain block. The grouped groups of cross-shard transactions can be sorted in ascending or descending order according to the grouping number and filled into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-shard transactions into a tree with the same tree structure, generate a hash value based on the root of the tree and fill it into the Transaction_root field of the block header of the main chain block. The grouped cross-shard transactions are, for example, structured as follows:

[0241] Cross-shard transactions that need to be executed by shard 1 ...... Cross-shard transactions that need to be executed by shard n

[0242] Table 1

[0243] As mentioned above Fig.15 In the example of 4 shards, the grouped cross-shard transactions can be divided into 4 groups according to the target shards:

[0244] Cross-shard transactions that need to be executed by shard 1 (including those sent by shards 2 and 4) Cross-shard transactions that need to be executed by shard 2 (including those sent by shards 1, 3, and 4) Cross-shard transactions that need to be executed by shard 3 (including those sent by shards 1, 2, and 4) Cross-shard transactions that need to be executed by shard 4 (including those sent by shards 2 and 3)

[0245] Table 2

[0246] Cross-shard transactions are grouped according to the target shard. The order of cross-shard transactions in each group after grouping is preferably consistent with the time order of the cross-shard transactions, that is, they are arranged in chronological order. Since different transaction orders are likely to lead to different transaction results, the cross-shard transactions in each group after grouping are arranged in chronological order, which is conducive to ensuring that after these cross-shard transactions are subsequently sent to the target shard, the target shard will not cause errors or exceptions due to inconsistent order when executing these cross-shard transactions.

[0247] The main chain block generated by the main chain, the grouped cross-shard transactions are filled into the block body of the main chain block, and the hash value is generated according to the root node calculated according to the tree structure of these cross-shard transactions, and the generated hash value is filled into the Transaction_Root in the block header, which can be as follows Fig.18 Similarly, blocks generated on the main chain can also be locked by hash. For example, the Prev Hash of the block header of block 10002 in the main chain stores the hash value of the previous block 10001, and so on. Fig.18As shown, the block header (block nHeader) of the block of the main chain may include fields such as the block number (Block Num), timestamp (Timestamp), the hash value of the previous block (Prev Hash), and Transaction_Root. The block body (block nBody) of the main chain block may include cross-shard transactions sent to the main chain by each shard before the main chain block is generated, that is, operations that need to be performed by the target shard. Preferably, the cross-shard transactions that need to be performed by each target shard included in the block body of the main chain block are not packaged in the previously generated blocks of the main chain.

[0248] It should be noted that, for a main chain block generated in the main chain, if there is no cross-shard transaction executed for a certain shard when the main node packages the transaction before the block is generated, the block body of the main chain block may not include the cross-shard transaction that needs to be executed by the target shard.

[0249] As mentioned above, in addition to sending the cross-shard transaction to the main chain, the source shard can also send the block header of the generated source shard block to the main chain. After the main chain receives the block header and cross-shard transaction of the source shard block sent by the source shard, the block header of the source shard block can be verified. The verification may include calculating the hash value of the root node according to the tree structure of the cross-shard transaction, and determining that the value is consistent with the cross-shard transaction _root in the block header. If it is inconsistent, the verification fails, otherwise the verification passes. It can also be verified whether the block header of the source shard block sent by the source shard this time is the same as the block header of the source shard block sent previously. If it is the same, it means that it is repeated with the previous source shard block, and the verification fails, otherwise the verification passes. In addition, it can also be verified whether the Prev Hash in the block header of the source shard block sent this time is the hash value of the source shard block of the previous block number. If it is, it passes the verification, otherwise it fails.

[0250] In the case where the source shard also sends the block header of the generated source shard block to the main chain, the main chain can also calculate the hash value of the source shard block according to the received block header of the source shard block during the process of generating the main chain block. Then, the main chain can fill the hash value of the shard block sent by each source shard into the block body of the main chain block. For example Fig.19 Furthermore, the main chain can also fill the root hash value of the shard block hash of each shard into the shard block root (Shards_BlockRoot) field of the block header of the main chain block, such as Fig.19As shown above. As mentioned above, the nodes in the main chain have a high degree of credibility. The nodes on the main chain lock the block hash of the shard block into the main chain block, which can prevent the shard from rolling back the generated shard block. This is because, based on the nature of the hash algorithm, the shard cannot forge different transactions while keeping the block header unchanged, thereby ensuring the security of the shard transaction. Specifically, it can ensure the security of cross-shard transactions as well as the security of transactions within a shard. Fig.19 For simplicity, the content of Table 1 is simplified into a list of cross-shard transactions.

[0251] Each node in the main chain block executes the transactions packaged in the master node consensus proposal, fills the received cross-shard transactions that need to be executed by the target shard into the block body of the main chain block and generates the main chain block, so that the cross-shard transactions that need to be executed by the target shard can be locked in the main chain block. Afterwards, the cross-shard transactions that need to be executed by the target shard can be sent to the corresponding target shard according to the identifier of the target shard. As in the above example, the cross-shard transactions in the main chain block body can be sent separately according to the identifier of the target shard that needs to be executed.

[0252] Specifically, the list of cross-shard transactions in the block body of the main chain block can be filled in after the cross-shard transactions are grouped according to the target shards. Such as the example in the previous Table 1. In this way, the main chain can send the cross-shard transactions grouped in the main chain block body to the target shards corresponding to the grouping according to the grouping in the block body of the main chain block. As in the example in the previous Table 2, the main chain sends the cross-shard transactions (including those sent by shards 2 and 4) in the block body of the main chain block that need to be executed by shard 1 to shard 1, and sends the cross-shard transactions (including those sent by shards 1, 3, and 4) that need to be executed by shard 2 to shard 2, and sends the cross-shard transactions (including those sent by shards 1, 2, and 4) that need to be executed by shard 3 to shard 3, and sends the cross-shard transactions (including those sent by shards 2 and 3) that need to be executed by shard 4 to shard 4.

[0253] After the main chain generates the main chain block, in addition to sending the cross-shard transaction that needs to be executed by the target shard to the corresponding target shard according to the identifier of the target shard, the block header of the main chain block can also be sent to the target shard, for example, together with the cross-shard transaction that needs to be processed by the corresponding target shard.

[0254] S175: When the target shard generates the target shard block, the cross-shard transaction received from the main chain is filled into the block body of the target shard block, and the cross-shard transaction is executed.

[0255] After receiving the cross-shard transaction from the main chain, the node in the target shard can first verify the cross-shard transaction. For example, the hash value of the root node of the tree formed by the cross-shard transaction can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction received this time is repeated with the cross-shard transaction received previously. If it is repeated, the cross-shard transaction sent this time can be stopped, otherwise it can continue to be processed.

[0256] The target shard, as the shard that executes the aforementioned cross-shard transaction, can also receive cross-shard transactions sent by the main chain that need to be executed by the target shard. Specifically, the master node in the target shard can receive the cross-shard transactions sent by the main chain that need to be executed by the target shard; or the non-master node in the target shard can receive the cross-shard transactions sent by the main chain that need to be executed by the target shard, and then forward these cross-shard transactions to the master node in the target shard. In addition, the target shard can also receive transaction requests initiated by the client connected to it. As mentioned above, the transaction can be a transfer transaction or a transaction to create / call a contract.

[0257] The master node in the target shard can package a certain number of transactions received within a period of time and initiate a consensus proposal. The packaged transactions may include the cross-shard transactions sent by the aforementioned main chain, and may also include transactions sent by the client received by the target shard. After reaching a consensus in the target shard, each node in the target shard executes these packaged transactions to generate a target shard block. In the process of generating a target shard block by the target shard, the cross-shard transactions received from the main chain can be filled into the block body of the target shard block, as shown in the original transaction list. In addition, the target shard can also fill the packaged transactions sent by the client into the block body of the target shard block, as shown in the original transaction list. The transactions filled in the block body of the target shard block can be organized in a tree structure, and the hash value generated according to the tree root is the Transaction_Root in the block header of the generated target shard block.

[0258] Each node in the target shard executes transactions, including executing the cross-shard transaction. In addition, the transactions executed by each node in the target shard may also include transactions sent by the client received by the target shard. Since the target shard stores the account status corresponding to the cross-shard transaction, executing the cross-shard transaction will cause the status of the corresponding account stored in the target shard to change. After each node in the target shard executes the cross-shard transaction, it does not submit the changed status of the corresponding account in the shard caused by the execution of the cross-shard transaction to the underlying database, that is, it does not persist the storage. When the target shard receives the submission confirmation of the cross-shard transaction from the source shard, it will submit the transaction executed by the target shard in the cross-shard transaction locally to complete the persistent storage.

[0259] If, after each node in the target shard executes the cross-shard transaction, some or all of the cross-shard transactions involve accounts stored on other shards other than the current shard, that is, these cross-shard transactions are multiple cross-shard transactions. For such multiple cross-shard transactions, on the one hand, the changed status of the corresponding accounts in the current shard caused by the execution of the cross-shard transaction is not submitted to the underlying database, and on the other hand, the cross-shard transactions further involved in these cross-shard transactions that need to be executed by other shards are sent to the main chain, that is, the processing of S171, S173, and S175 is repeated until no new cross-shard transactions are involved.

[0260] The simplest cross-shard transaction is a single cross-shard transaction, that is, a cross-shard transaction from one source shard to one target shard, that is, a completed transaction. Multiple cross-shard transactions can be the superposition of single cross-shard transactions. The following mainly uses a single cross-shard transaction as an example for explanation. Those skilled in the art can easily expand the example of a single cross-shard transaction given here to the case of multiple cross-shard transactions, and these extended cases should obviously also fall within the scope of this patent.

[0261] In addition, for each node executing transactions sent by the client received by the target shard, if these transactions are intra-shard transactions, that is, the accounts involved have corresponding status stored in this shard, then executing these transactions will also cause the status of the corresponding accounts stored in this shard to change.

[0262] Similarly, after reaching a consensus, each node in the target shard executes transactions locally, and the status of related accounts in this shard will change, including changes in the status of external accounts and / or contract accounts. After the status of related external accounts and contract accounts changes, each node in the target shard can calculate the hash value of the root node of the new state tree (i.e. the aforementioned state root hash, State_Root) based on the organizational structure of the merkle tree or MPT tree. The obtained State_Root can be filled in the block header of the generated target shard block. In addition, the block header can also include fields such as block number, timestamp, hash of the previous block, etc. Fig. 20 shown.

[0263] As mentioned in the aforementioned S173, in addition to sending the cross-shard transaction to the corresponding target shard, the main chain can also send the block header of the main chain block to the target shard. After the target shard receives the block header and cross-shard transaction of the main chain block sent by the main chain, it can verify the block header of the main chain block. The verification may include that the target shard calculates the hash of the main chain block based on the block header of the main chain block sent by the main chain this time, and judges whether it is the same as the block header of the main chain block sent previously based on the hash of the main chain block. If they are the same, it means that it is repeated with the previous main chain block and the verification fails, otherwise the verification passes. In addition, it can also be verified whether the Prev Hash in the block header of the main chain block sent this time is the hash value of the main chain block sent last time. If so, the verification passes, otherwise it fails.

[0264] In the case where the main chain also sends the block header of the generated main chain block to the target shard, the target shard can calculate the hash value of the main chain block based on the received block header of the main chain block during the process of generating the target shard block. Furthermore, the target shard can also fill the hash value of the main chain block into the block header of the target shard block generated by the target shard. In the case where the generation speed of the main chain block is not lower than the generation speed of the shard block, the target shard can fill the hash value of the latest main chain block into the block header of the target shard block generated by the target shard, such as Fig.21The latest main chain block Hash field in block 101 and block 102. Whether it is the latest can be judged according to the timestamp or block number in the block header of the main chain block. As mentioned above, in the process of generating the target shard block, the target shard can also verify whether the hash value of the current main chain block is repeated with the main chain block sent previously. If it is repeated, the block header and the corresponding cross-shard transaction sent this time can no longer be processed, otherwise continue to process. The target shard fills the hash value of the latest main chain block into the block header of the target shard block generated by the target shard. For the case where the generation speed of the main chain block is equal to the generation speed of the shard block, the cross-shard transaction processed in the current target shard can be identified in the target shard. For the case where the generation speed of the main chain block is higher than the generation speed of the shard block, the cross-shard transaction processed in the current target shard can be identified in the target shard. It is a cross-shard transaction in the block body of which main chain block.

[0265] Since the generation speed of the main chain block is not lower than the generation speed of the shard block, if the generation speed of the main chain block is higher than the generation speed of the shard block, Fig.21 As shown in , between the generation of shard block 101 and the target shard block 102, shard 1 has generated two main chain blocks in the main chain, namely main chain blocks 10003 and 10004. Fig.21 The main chain shown in sends the block header of the main chain block 10004 and the cross-shard transaction in the main chain block 10004 to shard 1. In fact, before this, if the main chain block 10003 also contains the cross-shard transaction that needs to be processed by shard 1, the main chain can also send the block header of the main chain block 10003 and the cross-shard transaction in the main chain block 10003 that needs to be processed by shard 1 to shard 1. That is, under normal circumstances, the main chain sends the block header of the main chain block and the corresponding cross-shard transaction to the shard involved in the cross-shard transaction in the time sequence of the main chain block generation. In this way, the target shard can fill the hash value of the latest main chain block into the block header of the target shard block generated by the target shard. In the above example, the block hash of the main chain block 10004 is filled into the block header of the target shard block generated by the target shard. At the same time, in the original transaction list of the block body of the generated shard block 102, shard 1 may include cross-shard transactions in the main chain blocks 10003 and 10004 that need to be processed by shard 1. In addition, the original transaction list of the shard block 102 may also include transaction requests initiated by the client connected to shard 1. The transaction request initiated by the client connected to shard 1 may be a transfer transaction or a transaction to create / call a contract.

[0266] Another situation is Fig. 22As shown, for the case where the generated shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transactions that need to be executed by the target shard, in addition to including the cross-shard transactions that need to be processed by the shard in the original transaction list of the block body of the shard block (of course, it can also include the packaged transaction requests initiated by the client connected to the shard), the block header of the shard block can also include the block headers of the multiple main chain blocks, as shown in FIG. Fig. 22 In the block header of block 101, the "hash of the processed main chain block m" and the "hash value of the processed main chain block n" (here only according to Fig. 22 The situation in the figure shows the hash of two main chain blocks. In fact, the number of block headers of the main chain blocks received before the current shard block is generated can obviously be greater than 2) and the "hash of the processed main chain block p" and "hash of the processed main chain block q" in the block header of block 102 (here only according to Fig. 22 The situation in the figure shows the hash of 2 main chain blocks. In fact, the number of main chain block headers received before the current shard block is generated can obviously be greater than 2. Obviously, in this case, the number of hashes of the processed main chain blocks contained in the block header of the shard block may be uncertain.

[0267] Another situation is Fig.23 As shown, for the case where the generated shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transactions that need to be executed by the target shard, in addition to including the cross-shard transactions that need to be processed by the shard in the multiple main chain blocks in the original transaction list of the block body of the shard block (of course, it can also include the packaged transaction requests initiated by the client connected to the shard), the block body of the shard block can also include the block hashes of the multiple main chain blocks, such as Fig.23 In the block body of block 101, the hash of the main chain block m and the hash of the main chain block n are (here only according to Fig. 22 The situation in the figure shows the hash of two main chain blocks. In fact, the number of block headers of the main chain blocks received before the current shard block is generated can obviously be greater than 2) and the "hash of the main chain block p" and "hash value of the main chain block q" in the block body of block 102 (here only according to Fig. 22The situation in the figure shows the hash of two main chain blocks. In fact, the number of block headers of the main chain blocks received before the current shard block is generated can obviously be greater than 2). The hashes of these processed main chain blocks contained in the block body of the shard block can be organized according to the tree structure as described above, and the hash value of the root of the tree is filled into the field "main chain block root Hash" added in the block header, that is, the hash value of the root of each main chain block calculated according to the tree structure is filled into the main chain block root Hash of the block header of the shard block. For example, the "main chain block root Hash" in the block header of block 101 is the hash value of the root node of the tree structure organized by "the hash of main chain block m" and "the hash of main chain block n" in the block body of block 101; the "main chain block root Hash" in the block header of block 102 is the hash value of the root node of the tree structure organized by "the hash of main chain block p" and "the hash of main chain block q" in the block body of block 101. The advantage of this is that a fixed field can be used in the block header of the shard block to lock the hash of an indefinite number of processed main chain blocks that may be included in the block body of the shard block.

[0268] Furthermore, the transactions executed by the target shard in the generated shard block include the cross-shard transactions corresponding to the main chain block locked in the target shard that need to be executed by the target shard, and may also include transaction requests initiated by the client connected to the shard. For example, the transactions executed by shard 1 in shard block 102 may include cross-shard transactions involving shard 1 in main chain blocks 10003 and 10004, and transaction requests initiated by the client connected to shard 1 packaged in shard block 102.

[0269] Preferably, when the target shard generates a shard block and the corresponding transaction executed includes a cross-shard transaction sent by the main chain and a transaction sent by a client connected to the target shard, the target shard first executes the cross-shard transaction sent by the main chain, and then executes the transaction sent by the client connected to the target shard. This is because the cross-shard transaction sent by the main chain that needs to be executed by the target shard actually occurs first, and the transaction sent by the client connected to the target shard actually occurs later, and the order of executing transactions is also a prerequisite for ensuring the correct conversion of account status. Therefore, in order to avoid the failure of the transaction or the confusion of the status caused by the incorrect conversion of the account status stored in the target shard, it is best to execute according to the actual order of the transactions.

[0270] In addition, the target shard executes the cross-shard transaction, and the target shard generates the target shard block, and fills the cross-shard transaction received from the main chain into the block body of the target shard block. There is no strict order between the two, and they can also be executed in parallel.

[0271] Preferably, when the target shard locks multiple main chain blocks in the generated target shard block, the target shard executes cross-shard transactions in the multiple main chain blocks according to the generation order of the main chain blocks. For example, if shard 1 locks main chain blocks 10003 and 10004 in the generated shard block 102, shard 1 executes cross-shard transactions in main chain blocks 10003 and 10004 in the order of main chain blocks 10003 and 10004, rather than executing cross-shard transactions in main chain blocks 10003 and 10004 in the order of main chain blocks 10004 and 10003. This is because, for the cross-shard transactions sent by the main chain that need to be executed by the target shard, the cross-shard transactions in the blocks corresponding to the block headers sent by the main chain first actually occur first, and the cross-shard transactions in the blocks corresponding to the block headers sent by the main chain later actually occur later. The order of executing transactions is also a prerequisite for ensuring the correct conversion of account status. Therefore, in order to avoid the failure of transactions or confusion of status due to incorrect conversion of account status stored in the target shard, it is best to execute them in the actual order of transactions.

[0272] In addition, the main chain can also send the timestamp of the generated main chain block to the shard, for example, by indicating the timestamp of the main chain block through the block header of the main chain block sent previously, so that the shard can fill the timestamp of the latest main chain block into the timestamp of the shard block in the process of generating the shard block. For example, in S175, in the process of generating the shard block by the shard, the timestamp in the block header of the shard block is set to the latest timestamp sent by the main chain. Similarly, in the process of generating the shard block in S171, the timestamp in the block header of the shard block is also set to the latest timestamp sent by the main chain before. In this way, the time system of the main chain can be anchored in the shard, so that the shard has the same clock system as the main chain. In the case where the shard has the same clock system as the main chain, the client connected to the shard can determine the initiation time of the transaction when initiating the transaction. Thus, when the client initiates the transaction, the timestamp of the initiation moment can be attached to the initiated transaction. Then, as mentioned above, among the cross-shard transactions sent to the main chain by multiple source shards, if they involve the same target shard, the target shard is also better to execute these cross-shard transactions in the order of transactions. In this way, the target shard can uniformly execute the cross-shard transactions in the same main chain block according to the timestamps of these cross-shard transactions (i.e. the timestamps of the cross-shard transactions initiated in the source shard) in order, regardless of which source shard these cross-shard transactions are initiated by, so as to ensure that the transactions can be processed correctly and the status generated after the transaction execution is consistent.

[0273] The above embodiment of executing cross-shard transactions provided by the present application forwards the cross-shard transactions generated in the source shard to the target shard through the main chain in the blockchain system containing shards, and provides an execution scheme for cross-shard transactions in the blockchain system containing shards. This process, through the authority of the main chain node, enables the cross-shard transactions generated in the shard to be reliably forwarded and executed under the witness of the main chain, and evidence is stored on the source shard, the main chain and the target shard.

[0274] As mentioned above, even if the nodes in the source shard in S171 have completed consensus in their own shard and executed these cross-shard transactions in the source shard block, they will not submit the changed status of the relevant accounts in their own shard caused by the cross-shard transactions in the source shard block to the database, that is, they will not store them persistently. Similarly, after each node in the target shard in S175 executes the cross-shard transaction, it will not submit the changed status of the corresponding accounts in their own shard caused by the execution of the cross-shard transaction to the underlying database, that is, it will not store them persistently. In order to enable the changed status of the accounts involved in the source and target shards to be submitted to the underlying database, the target shard also needs to feed back the response generated by the execution of the cross-shard transaction to the source shard. Fig.17 After the process shown is completed, the following steps may also be included: Fig.24 The process shown:

[0275] S241: In the process of generating a target shard block by the target shard, a cross-shard transaction response is generated according to the cross-shard transaction executed by the target shard, and the cross-shard transaction response is sent to the main chain.

[0276] In S175, the target shard executes the cross-shard transaction. If the execution is successful, a cross-shard transaction response can be generated, and these cross-shard transaction responses can be added to the block body of the shard block, for example Fig.25 In the cross-shard transaction response list shown in . It should be noted that for simplicity, Fig.25 The main chain block Hash list includes Fig.23 The hash of the main chain block processed in . Fig.25 The main chain block hash list of block 101 actually includes Fig.23 The Hash of the processed main chain block m, the Hash of the processed main chain block n, ..., Fig.25 The main chain block hash list of block 102 actually includes Fig.23The cross-shard transaction responses in the cross-shard transaction response list can be organized into a tree. Furthermore, the target shard can add a cross-shard transaction response_Root field in the generated block header to store the hash of the root of the tree organized into these cross-shard transaction responses in the block body. In this way, the target shard can lock the response generated after executing the cross-shard transaction in this block in the block header. Fig.25 As shown in , the block header of the shard block generated by the target shard may include the block number, timestamp, hash of the previous block, transaction root hash, main chain block root hash, cross-shard transaction response_Root, etc. Correspondingly, the hash value of the shard block is the hash value calculated by the fields in the block header including the cross-shard transaction response_Root field.

[0277] Furthermore, the target shard can return the cross-shard transaction response to the main chain. Moreover, the target shard can send the block header of the generated shard block together with the cross-shard transaction response to the main chain. In addition, the target shard can also process transactions sent by the client received by the target shard in the generated shard block. And the transactions sent by these clients may also include cross-shard transactions. At this time, the target shard is also the source shard. Those skilled in the art can understand that this is the case of the source shard, and the execution can be repeated from S171. For simplicity here, only the case of returning a cross-shard transaction response to the main chain as the target shard is discussed below.

[0278] In addition to sending the cross-shard transaction response to the main chain, the target shard can also send the block header of the generated target shard block to the main chain.

[0279] S243: During the process of generating a main chain block, the main chain fills the received cross-shard transaction response into the block body of the main chain block; the main chain sends the cross-shard transaction response to the corresponding source shard according to the identifier of the source shard.

[0280] After receiving the cross-shard transaction response from the target shard, the node in the main chain can first verify the cross-shard transaction response. For example, the hash value of the root node of the tree formed by the cross-shard transaction response can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction response received this time is repeated with the cross-shard transaction response received previously. If it is repeated, the cross-shard transaction response sent this time can be stopped, otherwise it can continue to be processed.

[0281] The master node in the main chain can collect the cross-shard transaction responses sent by the target shard, or the non-master node in the main chain can forward these cross-shard transaction responses to the master node in the main chain after receiving the cross-shard transaction responses sent by the target shard. The master node in the main chain can package a certain number of cross-shard transaction responses sent by each shard within a period of time and initiate a consensus proposal. After reaching a consensus in the main chain, each node in the main chain executes these packaged transactions to generate a main chain block.

[0282] Each node in the main chain executes these packaged cross-shard transaction responses and generates blocks, which may include filling the cross-shard transaction responses that need to be executed by the source shard into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-shard transaction responses into a tree, and generate a hash value based on the root of the tree and fill the hash value into the Transaction_Root of the block header of the main chain block. For example, for the aforementioned case where the main chain block includes a cross-shard transaction list, the cross-shard transaction response list and the cross-shard transaction list in S173 can be organized into a tree together, and a hash value is generated based on the root of the tree and the hash value is filled into the Transaction_Root of the block header of the main chain block. Alternatively, the cross-shard transaction responses are organized into a separate tree, and the hash value of the root of the generated tree is filled into the block header of the main chain block (for example, a new field, such as cross-shard transaction response_root, Fig.25 After adding the block number, timestamp, hash of the previous block and other fields to the block header of the main chain block, the main chain block is generated.

[0283] In the process of generating the main chain block, the main chain can also calculate the block hash of the target shard block sent by each target shard, and fill the target shard block hash into the block body of the main chain block, such as the shard block hash list. Furthermore, the main chain can also fill the hash value of the root calculated by the shard block hash of each shard according to the tree structure into the shard block root (Shards_BlockRoot) of the block header of the main chain block, for example Fig.25 as shown in .

[0284] Each node in the main chain executes these packaged transactions and generates blocks, and fills the cross-shard transaction responses that need to be executed by the source shard into the block body of the main chain block. Specifically, the cross-shard transaction responses that need to be executed by the source shard can be filled into the block body of the main chain block in the order of the cross-shard transaction responses that need to be executed by the source shard in the message of the consensus proposal initiated by the master node in the main chain. In addition, the cross-shard transaction responses can be grouped according to the source shards that need to be fed back, and the grouped cross-shard transaction responses can be filled into the block body of the main chain block. The grouped groups of cross-shard transaction responses can be sorted in ascending or descending order according to the grouping number and filled into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-shard transaction responses into a tree with the same tree structure, and obtain the Transaction_root field of the block header of the main chain block based on the hash value of the root of the tree (such as organizing the cross-shard transaction response list and the cross-shard transaction list in S173 into a tree, and generating a hash value based on the root of the tree and then filling the hash value into the Transaction_root of the block header of the main chain block). Preferably, the cross-shard transaction responses that each source shard needs to receive included in the block body of the main chain block are not packaged in the previously generated blocks of the main chain. In addition, if the main chain block generated in the main chain does not have a cross-shard transaction response received for a certain source shard when the main node packages the transaction before the block is generated, then the block body of the main chain block may not include the cross-shard transaction response that needs to be responded to by the source shard.

[0285] As mentioned above, the target shard can send the generated block header of the target shard block and the cross-shard transaction response to the main chain together. After the main chain receives the block header of the target shard block and the cross-shard transaction response sent by the target shard, it can verify the block header of the target shard block. The verification may include calculating the hash value of the root node according to the tree structure based on the cross-shard transaction response, and determining that the value is consistent with the cross-shard transaction response_root in the block header. Alternatively, the root of the tree is calculated according to the tree structure based on the cross-shard transaction response, and the hash value is obtained based on the tree root (which may also include the root of the tree composed of the cross-shard transaction, etc.), and determining that the value is consistent with the Transaction_root in the block header. If they are inconsistent, the verification fails, otherwise the verification passes. It can also be verified whether the block header of the target shard block sent by the target shard this time is the same as the block header of the target shard block sent previously. If they are the same, it means that it is repeated with the previous target shard block, and the verification fails, otherwise the verification passes. In addition, it is also possible to verify whether the PrevHash in the block header of the target shard block sent this time is the hash value of the target shard block of the previous block number. If so, the verification passes, otherwise it fails.

[0286] Afterwards, the main chain can send the cross-shard transaction response that needs to be received by the source shard to the corresponding source shard according to the identifier of the source shard. Specifically, the cross-shard transaction responses grouped in the block body of the main chain block can be sent to the corresponding source shard according to the identifier of the source shard. In this way, the cross-shard transaction responses in the main chain block body can be sent separately according to the identifier of the source shard that needs to be received. In addition to sending the cross-shard transaction response that needs to be executed by the source shard to the corresponding source shard according to the identifier of the source shard, the block header of the main chain block can also be sent to the source shard, for example, together with the cross-shard transaction response that needs to be processed by the corresponding source shard, it is sent to the source shard.

[0287] As mentioned above, in addition to sending the cross-shard transaction response to the main chain, the target shard can also send the block header of the generated target shard block to the main chain.

[0288] S245: During the process of the source shard generating the source shard block, the cross-shard transaction response received from the main chain is filled into the block body of the source shard block.

[0289] After receiving the cross-shard transaction response from the main chain, the node in the source shard may first verify the cross-shard transaction response. For example, the hash value of the root node of the tree formed by the cross-shard transaction response may be calculated according to the tree structure, and the hash value may be used to determine whether the cross-shard transaction response received this time is repeated with the cross-shard transaction response received previously. If repeated, the cross-shard transaction response sent this time may not be processed, otherwise it continues to be processed.

[0290] The source shard can receive cross-shard transaction responses from the main chain that need to be received by the source shard. In addition, the source shard can also receive transaction requests initiated by clients connected to it. The master node in the source shard can package a certain number of transactions received within a period of time and initiate a consensus proposal. The packaged transactions may include cross-shard transaction responses from the aforementioned main chain, and may also include transactions from clients received by the source shard. After reaching a consensus in the source shard, each node in the source shard executes these packaged transactions to generate a source shard block. The source shard blocks here are different from the source shard blocks in S171. Since the source shard is constantly forming blocks, the shard blocks generated by the source shard here are later than the source shard blocks in S171. For example, in S171, Fig.18If block 201 is generated, then this is the block generated after block 201, such as block 202. In the process of the source shard generating the source shard block, the cross-shard transaction response received from the main chain can be filled into the block body of the source shard block, such as in the cross-shard transaction response list. In addition, the target shard can also fill the packaged transactions sent by the client into the block body of the source shard block, such as in the original transaction list. The cross-shard transaction response list filled in the block body of the source shard block can be organized in a tree structure, and the hash value of the root of the tree is the cross-shard transaction response_Root in the block header of the generated target shard block. For example, Fig.26 shown.

[0291] As mentioned in the aforementioned S243, in addition to sending the cross-shard transaction response to the corresponding source shard, the main chain can also send the block header of the main chain block to the source shard. After the source shard receives the block header of the main chain block and the cross-shard transaction response sent by the main chain, it can verify the block header of the main chain block. The verification may include that the source shard calculates the hash of the main chain block based on the block header of the main chain block sent by the main chain this time, and judges whether it is the same as the block header of the main chain block sent previously based on the hash of the main chain block. If they are the same, it means that it is repeated with the previous main chain block and the verification fails, otherwise the verification passes. In addition, it can also be verified whether the Prev Hash in the block header of the main chain block sent this time is the hash value of the main chain block sent last time. If so, the verification passes, otherwise it fails.

[0292] In the case where the main chain also sends the block header of the generated main chain block to the source shard, the source shard can calculate the hash value of the main chain block according to the block header of the received main chain block in the process of generating the source shard block. Furthermore, the source shard can also fill the hash value of the main chain block into the block header of the source shard block generated by the source shard. In the case where the generation speed of the main chain block is not lower than the generation speed of the shard block, the source shard can fill the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. Whether it is the latest can be judged according to the timestamp or block number in the block header of the main chain block. As mentioned above, in the process of generating the source shard block, the source shard can also verify whether the hash value of the current main chain block is repeated with the main chain block sent previously. If it is repeated, the block header sent this time and the corresponding cross-shard transaction response can no longer be processed, otherwise continue to process. The source shard fills the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. If the generation speed of the main chain block is equal to the generation speed of the shard block, the source shard can identify in the source shard the main chain block in which the cross-shard transaction response received in the current source shard is a cross-shard transaction response. If the generation speed of the main chain block is higher than the generation speed of the shard block, the source shard can identify in the source shard the main chain block in which the cross-shard transaction response received in the current source shard is a cross-shard transaction response up to.

[0293] Since the generation speed of the main chain block is not lower than the generation speed of the shard block, if the generation speed of the main chain block is higher than the generation speed of the shard block, Fig.26 As shown in , between the generation of shard block 201 and the target shard block 202, shard 2 has generated two main chain blocks in the main chain, namely main chain blocks 10002 and 10003. Fig.26 The main chain shown in sends the block header of the main chain block 10003 and the cross-shard transaction response in the main chain block 10003 to Shard 2. In fact, before that, if the main chain block 10002 also contains the cross-shard transaction response that Shard 2 needs to receive, the main chain can also send the block header of the main chain block 10002 and the cross-shard transaction response in the main chain block 10002 that needs to be received by Shard 2 to Shard 2. That is, under normal circumstances, the main chain sends the block header of the main chain block and the corresponding cross-shard transaction response to the shard involved in the cross-shard transaction response in the time sequence of the generation of the main chain block. In this way, the source shard can fill the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. In the above example, the block hash of the main chain block 10003 is filled into the block header of the source shard block generated by the source shard ( Fig.26At the same time, shard 2 may include cross-shard transaction responses in main chain blocks 10002 and 10003 that need to be received by shard 2 in the original transaction list of the block body of the generated shard block 202. In addition, the original transaction list of the shard block 202 may also include transaction requests initiated by clients connected to shard 2. The transaction request initiated by the client connected to shard 2 may be a transfer transaction or a transaction to create / call a contract.

[0294] In another case, for the case where the generated source shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction responses that need to be received by the source shard, in addition to including the cross-shard transaction responses that need to be processed by the shard in the cross-shard transaction response list of the block body of the shard block, the block header of the shard block may also include the block headers of the multiple main chain blocks. Obviously, in this case, the number of hashes of the processed main chain blocks contained in the block header of the shard block may be uncertain.

[0295] Another situation is Fig.26 As shown, for the case where the generated shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction responses that need to be received by the source shard, in addition to including the cross-shard transaction responses that need to be processed by the shard in the cross-shard transaction response list of the block body of the shard block, the block body of the shard block may also include the block hashes of the multiple main chain blocks, such as Fig.26 The hash of the main chain block in the block body of block 201. The hashes of these processed main chain blocks contained in the block body of the shard block can be organized according to the tree structure as described above, and the hash value of the root of the tree is filled into the field "main chain block root Hash" added in the block header, that is, the hash value of the root calculated according to the tree structure of the hash of each main chain block is filled into the main chain block root Hash in the block header of the shard block. For example, the "main chain block root Hash" in the block header of block 201 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block body of block 201; the "main chain block root Hash" in the block header of block 202 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block header of block 202. This has the advantage that a fixed field can be used in the block header of the shard block to lock the hash of an indefinite number of processed main chain blocks that may be included in the block body of the shard block.

[0296] In addition, the main chain can also send the timestamp of the generated main chain block to the source shard, for example, by indicating the timestamp of the main chain block through the block header of the main chain block sent previously, so that the shard can fill the timestamp of the latest main chain block into the timestamp of the shard block in the process of generating the shard block. For example, in S245, in the process of the source shard generating the source shard block, the timestamp in the block header of the source shard block is set to the latest timestamp sent by the main chain. In this way, the time system of the main chain can be anchored in the shard, so that the shard has the same clock system as the main chain. In the case where the shard has the same clock system as the main chain, the client connected to the shard can determine the initiation time of the transaction when initiating the transaction. Thus, when the client initiates the transaction, the timestamp of the initiation moment can be attached to the initiated transaction.

[0297] The method embodiment of returning a cross-shard transaction response provided by the present application above forwards the cross-shard transaction response generated in the target shard to the source shard through the main chain in the blockchain system including shards, and provides a feedback scheme for cross-shard transaction responses in the blockchain system including shards. This process, through the authority of the nodes constituting the main chain, enables the cross-shard transaction response generated in the target shard to be reliably forwarded under the witness of the main chain, and evidence is stored on the target shard, the main chain, and the source shard.

[0298] As mentioned above, even if the nodes in the source shard in S171 have completed consensus in their own shard and executed these cross-shard transactions in the source shard block, they will not submit the changed status of the relevant accounts in their own shard caused by the cross-shard transactions in the source shard block to the database, i.e., they will not store them persistently. Similarly, after each node in the target shard in S175 executes the cross-shard transaction, it will not submit the changed status of the corresponding accounts in their own shard caused by the execution of the cross-shard transaction to the underlying database, i.e., they will not store them persistently. Fig.24 The source shard can receive the cross-shard transaction response returned by the target shard. In order to enable the changed status of the accounts involved in the source and target shards to be submitted to the underlying database, the source shard also needs to send a message to the target shard instructing the cross-shard transaction to be submitted.

[0299] Fig. 27 The process is shown, including:

[0300] S271: In the process of the source shard generating the source shard block, a cross-shard transaction commit instruction is generated according to the cross-shard transaction response, and the cross-shard transaction commit instruction is sent to the main chain.

[0301] After receiving the cross-shard transaction response, each node in the source shard can determine that the cross-shard transaction sent to the main chain in S171 has been executed by the corresponding target shard. The source shard and the target shards involved in these cross-shard transactions have not submitted the changes in the status of the relevant accounts caused by the executed cross-shard transactions to the underlying database locally, that is, they have not been persistently stored. The source shard can generate a cross-shard transaction commit instruction corresponding to the cross-shard transaction response.

[0302] The source shard can add the generated cross-shard transaction commit instruction to the block body of the generated shard block during the process of generating the source shard block, for example: Fig.28 The cross-shard transaction commit instruction list in the shard blocks 201 and 202. The cross-shard transaction commit instructions in these cross-shard transaction commit instruction lists can be organized in the form of a tree. Furthermore, the source shard can add a cross-shard transaction commit instruction_Root field in the generated block header to store the hash of the root of the tree organized into these cross-shard transaction commit instructions in the block body. In this way, the source shard can lock the cross-shard transaction commit instructions generated in this block in the block header. In addition, Fig.28 The block bodies of shard blocks 201 and 202 may also include the original transaction list and the main chain block Hash list. Similarly, in the block header, Transaction_root may be used to lock the original transaction list in the block body, and the main chain block Hash list in the block body may be locked with the main chain block root Hash. In addition to the original transaction list and cross-shard transaction submission instruction list, the block body may also include a cross-shard transaction list generated by this block (not shown in the figure). It should be noted that the cross-shard transaction submission instruction list is for the cross-shard transaction list in the previous block, not the cross-shard transaction in this block. Since there may be cross-shard transactions between Shard 2 and different target shards, the cross-shard transaction submission instruction list in the shard block generated by Shard 2 may include cross-shard transaction submission instructions that need to be sent to multiple different target shards. As shown in the figure, Fig.28 As shown in , the block header of the shard block generated by the source shard may include the block number, timestamp, hash of the previous block, Transaction_root, main chain block root hash, cross-shard transaction submission instruction_Root, etc. Correspondingly, the hash value of the shard block is the hash value calculated from the fields in the block header including the cross-shard transaction submission instruction_Root field. As mentioned above, in the process of the source shard generating the source shard block, the cross-shard transaction response received from the main chain can be filled into the block body of the source shard block, as shown in the cross-shard transaction response list. For simplicity, Fig.28The cross-shard transaction response list is omitted. In addition, the cross-shard transaction submission instructions received by each target shard included in the block body of the main chain block are preferably not packaged in a previously generated block of the main chain.

[0303] Furthermore, the source shard may send a cross-shard transaction commit instruction to the main chain. Moreover, the source shard may send the block header of the generated source shard block together with the cross-shard transaction commit instruction to the main chain. In addition, the source shard may also process transactions sent by the client received by the source shard in the generated shard block. The transactions sent by these clients may also include cross-shard transactions. Those skilled in the art may understand that for situations including cross-shard transactions, the execution may be repeated starting from S171. For simplicity, only the case where the source shard sends a cross-shard transaction commit instruction to the main chain is discussed below.

[0304] In addition to sending the cross-shard transaction submission instruction to the main chain, the source shard can also send the block header of the generated source shard block to the main chain.

[0305] S273: During the process of generating a main chain block, the main chain fills the received cross-shard transaction submission instruction that needs to be sent to the target shard into the block body of the main chain block; the main chain sends the cross-shard transaction submission instruction to the corresponding target shard according to the identifier of the target shard.

[0306] After receiving the cross-shard transaction submission instruction from the source shard, the node in the main chain can first verify the cross-shard transaction submission instruction. For example, the hash value of the root node of the tree formed by the cross-shard transaction submission instruction can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction submission instruction received this time is repeated with the cross-shard transaction submission instruction received previously. If it is repeated, the cross-shard transaction submission instruction sent this time can be stopped, otherwise it continues to be processed.

[0307] The master node in the main chain can collect cross-shard transaction submission instructions sent by the source shard, or the non-master node in the main chain can forward these cross-shard transaction submission instructions to the master node in the main chain after receiving the cross-shard transaction submission instructions sent by the source shard. The master node in the main chain can package a certain number of cross-shard transaction submission instructions sent by each shard within a period of time and initiate a consensus proposal. After reaching a consensus in the main chain, each node in the main chain executes these packaged transactions to generate a main chain block.

[0308] In the process of generating the main chain block, the block hash of the source shard block sent by each source shard can also be calculated, and the source shard block hash can be filled into the block body of the main chain block. Furthermore, in the process of generating the main chain block, the hash value of the root calculated by the shard block hash of each shard according to the tree structure can also be filled into the shard block root of the block header of the main chain block, for example Fig.28 as shown in .

[0309] Each node in the main chain executes these packaged cross-slice transaction submission instructions and generates a block, which may include filling the cross-slice transaction submission instructions that need to be sent to the target slicing into the block body of the main chain block. Specifically, the cross-slice transaction submission instructions that need to be executed by the target slicing can be filled into the block body of the main chain block according to the order of the cross-slice transaction submission instructions that need to be sent to the target slicing in the message of the consensus proposal initiated by the master node in the main chain. In addition, the cross-slice transaction submission instructions can be grouped according to the target slicing to be sent to, and the grouped cross-slice transaction submission instructions can be filled into the block body of the main chain block. The grouped groups of cross-slice transaction submission instructions can be arranged in ascending or descending order according to the grouping number and then filled into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-slice transaction submission instructions into a tree, and generate a hash value based on the root of the tree and fill the hash value into the Transaction_Root of the block header of the main chain block. In addition, for the aforementioned case where the main chain block includes a cross-shard transaction list, the cross-shard transaction submission instruction list and the cross-shard transaction list in S173 can be organized into a tree, and a hash value is generated based on the tree root and the hash value is filled into the Transaction_Root of the block header of the main chain block. Alternatively, the cross-shard transaction submission instructions are organized into a separate tree, and the hash value of the root of the generated tree is filled into the block header of the main chain block (for example, a new field, such as cross-shard transaction submission instruction_root, Fig.28 After adding the block number, timestamp, hash of the previous block and other fields to the block header of the main chain block, the main chain block is generated.

[0310] As mentioned above, the source shard can send the block header of the generated shard block and the cross-shard transaction submission instruction to the main chain together. After the main chain receives the block header of the source shard block and the cross-shard transaction submission instruction sent by the source shard, it can verify the block header of the shard block. The verification may include calculating the hash value of the root node according to the tree structure according to the cross-shard transaction submission instruction, and determining that the value is consistent with the cross-shard transaction submission instruction_root in the block header. Alternatively, the root of the tree is calculated according to the tree structure according to the cross-shard transaction submission instruction, and the hash value is obtained based on the tree root (which may also include the root of the tree composed of cross-shard transactions, the root of the tree composed of cross-shard transaction responses, etc.), and determining that the value is consistent with the Transaction_root in the block header. If they are inconsistent, the verification fails, otherwise the verification passes. It can also be verified whether the block header of the shard block sent by the source shard this time is the same as the block header of the shard block sent previously. If they are the same, it means that it is repeated with the previous shard block, and the verification fails, otherwise the verification passes. In addition, it is also possible to verify whether the Prev Hash in the block header of the shard block sent this time is the hash value of the shard block of the previous block number. If it is, the verification passes, otherwise it fails.

[0311] Afterwards, the main chain can send the cross-shard transaction submission instruction that needs to be executed by the target shard to the corresponding target shard according to the identifier of the target shard. Specifically, the cross-shard transaction submission instructions grouped in the block body of the main chain block can be sent to the corresponding target shard according to the identifier of the target shard. In this way, the cross-shard transaction submission instructions grouped in the block body of the main chain block can be sent to the corresponding target shard according to the identifier of the target shard. In addition to sending the cross-shard transaction submission instruction that needs to be executed by the target shard to the corresponding target shard according to the identifier of the target shard, the block header of the main chain block can also be sent to the target shard, for example, sent to the target shard together with the cross-shard transaction submission instruction that needs to be processed by the corresponding target shard.

[0312] S275: During the process of the target shard generating the target shard block, the cross-shard transaction submission instruction received from the main chain is filled into the block body of the target shard block, and the status generated by executing the cross-shard transaction is submitted locally.

[0313] After the node in the target shard receives the cross-shard transaction submission instruction sent by the main chain, it can first verify the cross-shard transaction submission instruction. For example, the hash value of the root node of the tree formed by the cross-shard transaction submission can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction submission instruction received this time is repeated with the cross-shard transaction submission instruction received previously. If repeated, the cross-shard transaction submission instruction sent this time can be no longer processed, otherwise it continues to be processed.

[0314] The target shard can receive a cross-shard transaction submission instruction from the main chain that needs to be executed by the target shard. In addition, the target shard can also receive a transaction request initiated by a client connected to it. The master node in the target shard can package a certain number of transactions received within a period of time and initiate a consensus proposal. The packaged transaction may include the cross-shard transaction submission instruction sent by the aforementioned main chain, and may also include the transaction sent by the client received by the target shard, and may also include the aforementioned cross-shard transaction response. After reaching a consensus in the target shard, each node in the target shard executes these packaged transactions to generate a target shard block. The target shard block here is different from the target shard block in S245. Since the target shard is constantly forming blocks, the shard block generated by the target shard here is later than the target shard block in S245. For example, in S245, Fig.29 If block 201 is generated, then this is the block generated after block 201, for example, block 202. In the process of generating the target shard block by the target shard, the cross-shard transaction submission instruction received from the main chain can be filled into the block body of the source shard block, such as in the cross-shard transaction submission instruction list. In addition, the target shard can also fill the packaged transaction sent by the client into the block body of the target shard block, such as in the original transaction list. The cross-shard transaction submission instruction filled in the block body of the target shard block can be organized in a tree structure, and the hash value of the tree root is the cross-shard transaction submission instruction _Root in the block header of the generated target shard block.

[0315] As mentioned in the aforementioned S273, in addition to sending the cross-shard transaction to the corresponding target shard, the main chain can also send the block header of the main chain block to the target shard. After the target shard receives the block header of the main chain block and the cross-shard transaction submission instruction sent by the main chain, it can verify the block header of the main chain block. The verification may include that the target shard calculates the hash of the main chain block based on the block header of the main chain block sent by the main chain this time, and judges whether it is the same as the block header of the main chain block sent previously based on the hash of the main chain block. If they are the same, it means that it is repeated with the previous main chain block and the verification fails, otherwise the verification passes. In addition, it can also be verified whether the Prev Hash in the block header of the main chain block sent this time is the hash value of the main chain block sent last time. If so, the verification passes, otherwise it fails.

[0316] In the case where the main chain also sends the block header of the generated main chain block to the target shard, the target shard can calculate the hash value of the main chain block according to the block header of the received main chain block in the process of generating the target shard block. Furthermore, the target shard can also fill the hash value of the main chain block into the block header of the target shard block generated by the target shard. In the case where the generation speed of the main chain block is not lower than the generation speed of the shard block, the target shard can fill the hash value of the latest main chain block into the block header of the target shard block generated by the target shard. Whether it is the latest can be judged according to the timestamp or block number in the block header of the main chain block. As mentioned above, in the process of generating the target shard block, the target shard can also verify whether the hash value of the current main chain block is repeated with the main chain block sent previously. If it is repeated, the block header sent this time and the corresponding cross-shard transaction submission instruction can no longer be processed, otherwise continue to process. The target shard fills the hash value of the latest main chain block into the block header of the target shard block generated by the target shard. If the generation speed of the main chain block is equal to the generation speed of the shard block, the target shard can identify in the target shard the main chain block whose block body the cross-shard transaction submission instruction received in the current target shard is the cross-shard transaction submission instruction. If the generation speed of the main chain block is higher than the generation speed of the shard block, the target shard can identify in the target shard the main chain block whose block body the cross-shard transaction submission instruction received in the current target shard is the cross-shard transaction submission instruction up to.

[0317] Since the generation speed of the main chain block is not lower than the generation speed of the shard block, if the generation speed of the main chain block is higher than the generation speed of the shard block, Fig.29 As shown in , between the generation of shard block 101 and the target shard block 102, shard 1 has generated two main chain blocks in the main chain, namely main chain blocks 10003 and 10004. Fig.29 The main chain shown in sends the block header of the main chain block 10004 and the cross-shard transaction submission instruction in the main chain block 10004 to Shard 1. In fact, before this, if the main chain block 10003 also contains the cross-shard transaction submission instruction that Shard 1 needs to process, the main chain can also send the block header of the main chain block 10003 and the cross-shard transaction submission instruction in the main chain block 10003 that needs to be processed by Shard 1 to Shard 1. That is, under normal circumstances, the main chain sends the block header of the main chain block and the corresponding cross-shard transaction submission instruction to the shard involved in the cross-shard transaction submission instruction in the time sequence of the generation of the main chain block. In this way, the target shard can fill the hash value of the latest main chain block into the block header of the target shard block generated by the target shard. In the above example, the block hash of the main chain block 10004 is filled into the block header of the target shard block generated by the target shard ( Fig.29(not shown). At the same time, shard 1 may include cross-shard transaction submission instructions in main chain blocks 10003 and 10004 that need to be processed by shard 1 in the original transaction list of the block body of the generated shard block 102. In addition, the original transaction list of the shard block 102 may also include transaction requests initiated by clients connected to shard 1. The transaction request initiated by the client connected to shard 1 may be a transfer transaction or a transaction to create / call a contract.

[0318] In another case, when the generated target shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction submission instructions that need to be executed by the source shard, in addition to including the cross-shard transaction submission instructions that need to be processed by the shard in the cross-shard transaction submission instruction list of the block body of the shard block, the block header of the shard block may also include the block headers of the multiple main chain blocks. Obviously, in this case, the number of hashes of the processed main chain blocks contained in the block header of the shard block may be uncertain.

[0319] Another situation is Fig.29 As shown, for the case where the generated shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction submission instructions that need to be executed by the target shard, in addition to including the cross-shard transaction submission instructions that need to be processed by the shard in the cross-shard transaction submission instruction list of the block body of the shard block, the block body of the shard block may also include the block hashes of the multiple main chain blocks, such as Fig.29 The hash of the main chain blocks in the block body of block 101 of the shard block. The hashes of these processed main chain blocks contained in the block body of the shard block can be organized according to the tree structure as described above, and the hash value of the root of the tree is filled into the field "main chain block root Hash" added in the block header, that is, the hash value of the root calculated according to the tree structure of the hash of each main chain block is filled into the main chain block root Hash in the block header of the shard block. For example, the "main chain block root Hash" in the block header of block 101 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block body of block 101; the "main chain block root Hash" in the block header of block 102 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block header of block 102. This has the advantage that a fixed field can be used in the block header of the shard block to lock the hash of an indefinite number of processed main chain blocks that may be included in the block body of the shard block.

[0320] In addition, the main chain can also send the timestamp of the generated main chain block to the target shard, for example, by indicating the timestamp of the main chain block through the block header of the main chain block sent previously, so that the shard can fill the timestamp of the latest main chain block into the timestamp of the shard block in the process of generating the shard block. For example, in S275, during the process of the target shard generating the target shard block, the timestamp in the block header of the target shard block is set to the latest timestamp sent by the main chain. In this way, the time system of the main chain can be anchored in the shard, so that the shard has the same clock system as the main chain. In the case where the shard has the same clock system as the main chain, the client connected to the shard can determine the initiation time of the transaction when initiating the transaction. Thus, when the client initiates the transaction, the timestamp of the initiation moment can be attached to the initiated transaction.

[0321] Each node in the target shard executes the transaction, including executing the cross-shard transaction commit instruction. Executing the cross-shard transaction commit instruction includes submitting the relevant changed state in the target shard corresponding to the cross-shard transaction commit instruction to the underlying database, i.e., persistent storage.

[0322] In addition, the state generated by the target shard submitting and executing the cross-shard transaction locally, and the cross-shard transaction submission instruction received from the main chain is filled into the block body of the target shard block during the process of the target shard generating the target shard block. There is no strict order between the two, and they can also be executed in parallel.

[0323] The method embodiment of the instruction submission cross-shard transaction provided by the present application forwards the cross-shard transaction submission instruction generated in the source shard to the target shard through the main chain in the blockchain system including shards, and provides a solution for submitting shard transactions by instructions in the blockchain system including shards. This process, through the authority of the nodes constituting the main chain, enables the cross-shard transaction submission instruction generated in the source shard to be reliably forwarded and executed in the target shard under the witness of the main chain, and evidence is stored on the source shard, the main chain and the target shard.

[0324] As mentioned above, even if the nodes in the source shard in S171 have completed consensus in this shard and executed these cross-shard transactions in the source shard block, the changed status of the relevant accounts in this shard caused by the cross-shard transactions in the source shard block will not be submitted to the database, that is, not persistently stored. In S275, after each node in the target shard executes the cross-shard transaction commit instruction, it submits the changed status of the corresponding accounts in this shard caused by the execution of the cross-shard transaction to the underlying database, that is, persistently stored. In order to enable the changed status of the accounts involved in the cross-shard transaction on the source shard to be submitted to the underlying database, the target shard also needs to send a cross-shard transaction commit response to the source shard.

[0325] Fig.30 The process is shown, including:

[0326] S301: In the process of generating a target shard block by a target shard, a cross-shard transaction submission response is generated according to a cross-shard transaction submission instruction executed by the target shard, and the cross-shard transaction submission response is sent to the main chain.

[0327] In S275, the target shard executes the cross-shard transaction. If the execution is successful, a cross-shard transaction commit response can be generated, and these cross-shard transaction commit responses can be added to the block body of the shard block, for example Fig.31 The cross-shard transaction commit response list shown in . The cross-shard transaction commit responses in these cross-shard transaction commit response lists can be organized in the form of a tree. Furthermore, the target shard can add a cross-shard transaction commit response_Root field in the generated block header to store the hash of the root of the tree organized into these cross-shard transaction commit responses in the block body. In this way, the target shard can lock the commit response generated after the cross-shard transaction commit instruction is executed in this block in the block header. In addition, as described in S275 above, the target shard block generated by the target shard may also include a cross-shard transaction commit instruction list. Similarly, the target shard can add a cross-shard transaction commit instruction_Root field in the generated block header to store the hash of the root of the tree organized into these cross-shard transaction commit instructions in the block body (not shown in the figure). As Fig.31 As shown in , the block header of the shard block generated by the target shard may include the block number, timestamp, hash of the previous block, transaction root hash, main chain block root hash, cross-shard transaction submission response_Root, etc. Correspondingly, the hash value of the shard block is the hash value calculated by the fields in the block header including the cross-shard transaction submission response_Root field.

[0328] Furthermore, the target shard can return the cross-shard transaction submission response to the main chain. Moreover, the target shard can send the block header of the generated shard block together with the cross-shard transaction submission response to the main chain. In addition, the target shard can also process transactions sent by clients received by the target shard in the generated shard block. And the transactions sent by these clients may also include cross-shard transactions. At this time, the target shard is also the source shard. Those skilled in the art can understand that this is the case of the source shard, and the execution can be repeated from S171. For simplicity here, only the case of returning a cross-shard transaction submission response to the main chain as the target shard is discussed below.

[0329] In addition to sending the cross-shard transaction submission response to the main chain, the target shard can also send the block header of the generated target shard block to the main chain.

[0330] S303: In the process of generating a main chain block by the main chain, the received cross-shard transaction submission response is filled into the block body of the main chain block; the main chain sends the cross-shard transaction submission response to the corresponding source shard according to the identifier of the source shard.

[0331] After receiving the cross-shard transaction submission response from the target shard, the node in the main chain can first verify the cross-shard transaction submission response. For example, the hash value of the root node of the tree formed by the cross-shard transaction submission response can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction submission response received this time is repeated with the cross-shard transaction submission response received previously. If it is repeated, the cross-shard transaction submission response sent this time can be stopped, otherwise it continues to be processed.

[0332] The master node in the main chain can collect the cross-shard transaction submission responses sent by the target shard, or the non-master node in the main chain can forward these cross-shard transaction submission responses to the master node in the main chain after receiving the cross-shard transaction submission responses sent by the target shard. The master node in the main chain can package a certain number of cross-shard transaction submission responses sent by each shard within a period of time and initiate a consensus proposal. After reaching a consensus in the main chain, each node in the main chain executes these packaged transactions to generate a main chain block.

[0333] Each node in the main chain executes these packaged cross-shard transaction submission responses and generates a block, which may include filling the cross-shard transaction submission responses that need to be executed by the source shard into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-shard transaction submission responses into a tree, and generate a hash value based on the root of the tree and fill the hash value into the Transaction_Root of the block header of the main chain block. For example, for the aforementioned case where the main chain block includes a cross-shard transaction list, the cross-shard transaction submission response list and the cross-shard transaction list can be organized into a tree together, and a hash value is generated based on the root of the tree and the hash value is filled into the Transaction_Root of the block header of the main chain block. Alternatively, the cross-shard transaction submission responses are organized into a separate tree, and the hash value of the root of the generated tree is filled into the block header of the main chain block (for example, a new field, such as cross-shard transaction submission response_root, Fig.31 After adding the block number, timestamp, hash of the previous block and other fields to the block header of the main chain block, the main chain block is generated.

[0334] In the process of generating the main chain block, the main chain can also calculate the block hash of the target shard block sent by each target shard, and fill the target shard block hash into the block body of the main chain block, such as the shard block hash list. Furthermore, the main chain can also fill the hash value of the root calculated by the shard block hash of each shard according to the tree structure into the shard block root (Shards_BlockRoot) of the block header of the main chain block, for example Fig.31 as shown in .

[0335] Each node in the main chain executes these packaged transactions and generates blocks, and fills the cross-shard transaction submission responses that need to be executed by the source shard into the block body of the main chain block. Specifically, the cross-shard transaction submission responses that need to be executed by the source shard can be filled into the block body of the main chain block in the order of the cross-shard transaction submission responses that need to be executed by the source shard in the message of the consensus proposal initiated by the master node in the main chain. In addition, the cross-shard transaction submission responses can also be grouped according to the source shards that need to be fed back, and the grouped cross-shard transaction submission responses can be filled into the block body of the main chain block. The grouped groups of cross-shard transaction submission responses can be sorted in ascending or descending order according to the grouping number and then filled into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-shard transaction submission responses into a tree with the same tree structure, and obtain a hash value based on the root of the tree and fill the hash value into the Transaction_root field of the block header of the main chain block (such as organizing the cross-shard transaction submission response list and the cross-shard transaction list in S173 into a tree, and generating a hash value based on the root of the tree and filling the hash value into the Transaction_root of the block header of the main chain block). Preferably, the cross-shard transaction submission responses that each source shard needs to receive included in the block body of the main chain block are not packaged in the previously generated blocks of the main chain. In addition, if the main chain block generated in the main chain does not have a cross-shard transaction submission response received by a certain source shard when the main node packages the transaction before the block is generated, then the cross-shard transaction submission response that needs to be corresponding to the source shard may not be included in the block body of the main chain block.

[0336] As mentioned above, the target shard can send the generated block header of the target shard block and the cross-shard transaction submission response to the main chain together. After the main chain receives the block header of the target shard block and the cross-shard transaction submission response sent by the target shard, it can verify the block header of the target shard block. The verification may include calculating the hash value of the root node according to the tree structure based on the cross-shard transaction submission response, and determining that the value is consistent with the cross-shard transaction submission response_root in the block header. Alternatively, the root of the tree is calculated according to the tree structure based on the cross-shard transaction submission response, and the hash value is obtained based on the tree root (which may also include the root of the tree composed of cross-shard transactions, the root of the tree composed of cross-shard transaction responses, the root of the tree composed of cross-shard transaction submission instructions, etc.), and it is determined that the value is consistent with the Transaction_root in the block header. If it is inconsistent, the verification fails, otherwise the verification passes. It is also possible to verify whether the block header of the target shard block sent by the target shard this time is the same as the block header of the target shard block sent previously. If they are the same, it means that the block is repeated with the previous target shard block and the verification fails. Otherwise, the verification passes. In addition, it is also possible to verify whether the Prev Hash in the block header of the target shard block sent this time is the hash value of the target shard block of the previous block number. If so, the verification passes, otherwise it fails.

[0337] Afterwards, the main chain can send the cross-shard transaction submission response that needs to be received by the source shard to the corresponding source shard according to the identifier of the source shard. Specifically, the cross-shard transaction submission responses grouped in the block body of the main chain block can be sent to the corresponding source shard according to the identifier of the source shard. In this way, the cross-shard transaction submission responses in the main chain block body can be sent separately according to the identifier of the source shard that needs to be received. In addition to sending the cross-shard transaction submission response that needs to be executed by the source shard to the corresponding source shard according to the identifier of the source shard, the block header of the main chain block can also be sent to the source shard, for example, together with the cross-shard transaction submission response that needs to be processed by the corresponding source shard, it is sent to the source shard.

[0338] As mentioned above, in addition to sending the cross-shard transaction submission response to the main chain, the target shard can also send the block header of the generated target shard block to the main chain.

[0339] S305: During the process of the source shard generating the source shard block, the cross-shard transaction submission response received from the main chain is filled into the block body of the source shard block, and the status generated by executing the cross-shard transaction is submitted locally.

[0340] After the node in the source shard receives the cross-shard transaction submission response sent by the main chain, it can first verify the cross-shard transaction submission response. For example, the hash value of the root node of the tree formed by the cross-shard transaction submission response can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction submission response received this time is repeated with the cross-shard transaction submission response received previously. If it is repeated, the cross-shard transaction submission response sent this time can be no longer processed, otherwise it continues to be processed.

[0341] The source shard can receive a cross-shard transaction submission response from the main chain that needs to be received by the source shard. In addition, the source shard can also receive transaction requests initiated by clients connected to it. The master node in the source shard can package a certain number of transactions received within a period of time and initiate a consensus proposal. The packaged transactions may include the cross-shard transaction submission response sent by the aforementioned main chain, and may also include transactions from clients received by the source shard. After reaching a consensus in the source shard, each node in the source shard executes these packaged transactions to generate a source shard block. The source shard blocks here are different from the source shard blocks in S271. Since the source shard is constantly forming blocks, the shard blocks generated by the source shard here are later than the source shard blocks in S271. For example, in S271, Fig.28 As shown, block 201 is generated, then this is the block generated after block 201, such as block 202. In the process of the source shard generating the source shard block, the cross-shard transaction submission response received from the main chain can be filled into the block body of the source shard block, such as in the cross-shard transaction submission response list. In addition, the target shard can also fill the packaged transactions sent by the client into the block body of the source shard block, such as in the original transaction list. The cross-shard transaction submission response list filled in the block body of the source shard block can be organized in a tree structure, and the hash value of the tree root is the cross-shard transaction submission response_Root in the block header of the generated target shard block. For example, Fig.32 shown.

[0342] As mentioned in the aforementioned S303, in addition to sending the cross-shard transaction submission response to the corresponding source shard, the main chain can also send the block header of the main chain block to the source shard. After the source shard receives the block header of the main chain block and the cross-shard transaction submission response sent by the main chain, it can verify the block header of the main chain block. The verification may include that the source shard calculates the hash of the main chain block based on the block header of the main chain block sent by the main chain this time, and judges whether it is the same as the block header of the main chain block sent previously based on the hash of the main chain block. If they are the same, it means that it is repeated with the previous main chain block and the verification fails, otherwise the verification passes. In addition, it can also be verified whether the Prev Hash in the block header of the main chain block sent this time is the hash value of the main chain block sent last time. If so, the verification passes, otherwise it fails.

[0343] In the case where the main chain also sends the block header of the generated main chain block to the source shard, the source shard can calculate the hash value of the main chain block according to the block header of the received main chain block in the process of generating the source shard block. Furthermore, the source shard can also fill the hash value of the main chain block into the block header of the source shard block generated by the source shard. In the case where the generation speed of the main chain block is not lower than the generation speed of the shard block, the source shard can fill the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. Whether it is the latest can be judged according to the timestamp or block number in the block header of the main chain block. As mentioned above, in the process of generating the source shard block, the source shard can also verify whether the hash value of the current main chain block is repeated with the main chain block sent previously. If it is repeated, the block header sent this time and the corresponding cross-shard transaction submission response can no longer be processed, otherwise continue to process. The source shard fills the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. If the generation speed of the main chain block is equal to the generation speed of the shard block, the source shard can identify in the source shard the main chain block in which the cross-shard transaction submission response received in the current source shard is the cross-shard transaction submission response. If the generation speed of the main chain block is higher than the generation speed of the shard block, the source shard can identify in the source shard the main chain block in which the cross-shard transaction submission response received in the current source shard is the cross-shard transaction submission response.

[0344] Since the generation speed of the main chain block is not lower than the generation speed of the shard block, if the generation speed of the main chain block is higher than the generation speed of the shard block, Fig.32 As shown in , between the generation of shard block 201 and the target shard block 202, shard 2 has generated two main chain blocks in the main chain, namely main chain blocks 10002 and 10003. Fig.32The main chain shown in sends the block header of the main chain block 10003 and the cross-shard transaction submission response in the main chain block 10003 to Shard 2. In fact, before this, if the main chain block 10002 also contains the cross-shard transaction submission response that Shard 2 needs to receive, the main chain can also send the block header of the main chain block 10002 and the cross-shard transaction submission response in the main chain block 10002 that needs to be received by Shard 2 to Shard 2. That is, under normal circumstances, the main chain sends the block header of the main chain block and the corresponding cross-shard transaction submission response to the shard involved in the cross-shard transaction submission response in the time sequence of the generation of the main chain block. In this way, the source shard can fill the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. In the above example, the block hash of the main chain block 10003 is filled into the block header of the source shard block generated by the source shard ( Fig.32 (not shown). At the same time, shard 2 may include the cross-shard transaction submission response in main chain blocks 10002 and 10003 that needs to be received by shard 2 in the original transaction list of the block body of the generated shard block 202. In addition, the original transaction list of the shard block 202 may also include the transaction request initiated by the client connected to shard 2. The transaction request initiated by the client connected to shard 2 may be a transfer transaction or a transaction to create / call a contract.

[0345] In another case, for the case where the generated source shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction submission responses that need to be received by the source shard, in addition to including the cross-shard transaction submission responses that need to be processed by the shard in the cross-shard transaction submission response list of the block body of the shard block, the block header of the shard block may also include the block headers of the multiple main chain blocks. Obviously, in this case, the number of hashes of the processed main chain blocks contained in the block header of the shard block may be uncertain.

[0346] In another case, for the case where the generated shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction submission responses that need to be received by the source shard, in addition to including the cross-shard transaction submission responses that need to be processed by the shard in the cross-shard transaction submission response list of the block body of the shard block, the block body of the shard block can also include the block hashes of the multiple main chain blocks. The hashes of these processed main chain blocks contained in the block body of the shard block can be organized according to the tree structure as described above, and the hash value of the root of the tree is filled in the field "main chain block root Hash" added in the block header, such as Fig.32As shown, the hash value of the root calculated according to the tree structure of the hash of each main chain block is filled into the main chain block root Hash in the block header of the shard block. For example, the "main chain block root Hash" in the block header of block 201 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block body of block 201; the "main chain block root Hash" in the block header of block 202 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block header of block 202. The advantage of this is that a fixed field can be used in the block header of the shard block to lock the hash of an indefinite number of processed main chain blocks that may be included in the block body of the shard block.

[0347] In addition, the main chain can also send the timestamp of the generated main chain block to the source shard, for example, by indicating the timestamp of the main chain block through the block header of the main chain block sent previously, so that the shard can fill the timestamp of the latest main chain block into the timestamp of the shard block in the process of generating the shard block. For example, in S305, in the process of the source shard generating the source shard block, the timestamp in the block header of the source shard block is set to the latest timestamp sent by the main chain. In this way, the time system of the main chain can be anchored in the shard, so that the shard has the same clock system as the main chain. In the case where the shard has the same clock system as the main chain, the client connected to the shard can determine the initiation time of the transaction when initiating the transaction. Thus, when the client initiates the transaction, the timestamp of the initiation moment can be attached to the initiated transaction.

[0348] Each node in the source shard executes the transaction, including submitting the relevant changed state in the target shard corresponding to the cross-shard transaction submission response to the underlying database, i.e., persistent storage. In addition, the source shard locally submits the state generated by the execution of the cross-shard transaction, and the source shard generates the source shard block in the process of filling the cross-shard transaction submission response received from the main chain into the block body of the source shard block. There is no strict order between the two, and they can also be executed in parallel.

[0349] The method embodiment of submitting cross-shard transactions provided by the present application forwards the cross-shard transaction submission response generated in the target shard to the source shard through the main chain in the blockchain system including shards, and provides a feedback scheme for the cross-shard transaction submission response in the blockchain system including shards and a scheme for the source shard to submit cross-shard transactions. This process, through the authority of the nodes constituting the main chain, enables the cross-shard transaction submission response generated in the target shard to be reliably forwarded under the witness of the main chain, and evidence is stored on the target shard, the main chain and the source shard.

[0350] After the above Fig.24 According to the process, the source shard can receive the cross-shard transaction response returned by the target shard. At this time, the source shard can locally submit the state generated by executing the cross-shard transaction. At the same time, in order to enable the changed state of the account involved in the target shard to be submitted to the underlying database, the source shard also needs to send a message to the target shard to instruct the cross-shard transaction to be submitted.

[0351] Fig.33 The process is shown, including:

[0352] S331: In the process of generating a source shard block, the source shard generates a cross-shard transaction commit instruction according to the cross-shard transaction response, and locally commits the state generated by executing the cross-shard transaction, and also sends the cross-shard transaction commit instruction to the main chain.

[0353] After each node in the source shard receives the cross-shard transaction response, it can be determined that the cross-shard transaction sent to the main chain in S171 has been executed by the corresponding target shard. Neither the source shard nor the target shard involved in these cross-shard transactions has submitted the changes in the status of the relevant accounts caused by the executed cross-shard transactions to the underlying database locally, that is, it has not been persistently stored. The source shard can generate a cross-shard transaction commit instruction corresponding to the cross-shard transaction response. The source shard locally submits the status generated by the execution of the cross-shard transaction, and generates a cross-shard transaction commit instruction according to the cross-shard transaction response in the process of generating the source shard block. The two have no strict order of precedence and can also be executed in parallel.

[0354] The source shard can add the generated cross-shard transaction commit instruction to the block body of the generated shard block during the process of generating the source shard block, for example: Fig.28 The cross-shard transaction commit instruction list in the shard blocks 201 and 202. The cross-shard transaction commit instructions in these cross-shard transaction commit instruction lists can be organized in the form of a tree. Furthermore, the source shard can add a cross-shard transaction commit instruction_Root field in the generated block header to store the hash of the root of the tree organized into these cross-shard transaction commit instructions in the block body. In this way, the source shard can lock the cross-shard transaction commit instructions generated in this block in the block header. In addition, Fig.28The block bodies of shard blocks 201 and 202 may also include the original transaction list and the main chain block Hash list. Similarly, in the block header, Transaction_root may be used to lock the original transaction list in the block body, and the main chain block Hash list in the block body may be locked with the main chain block root Hash. In addition to the original transaction list and cross-shard transaction submission instruction list, the block body may also include a cross-shard transaction list generated by this block (not shown in the figure). It should be noted that the cross-shard transaction submission instruction list is for the cross-shard transaction list in the previous block, not the cross-shard transaction in this block. Since there may be cross-shard transactions between Shard 2 and different target shards, the cross-shard transaction submission instruction list in the shard block generated by Shard 2 may include cross-shard transaction submission instructions that need to be sent to multiple different target shards. As shown in the figure, Fig.28 As shown in , the block header of the shard block generated by the source shard may include the block number, timestamp, hash of the previous block, Transaction_root, main chain block root hash, cross-shard transaction submission instruction_Root, etc. Correspondingly, the hash value of the shard block is the hash value calculated from the fields in the block header including the cross-shard transaction submission instruction_Root field. As mentioned above, in the process of the source shard generating the source shard block, the cross-shard transaction response received from the main chain can be filled into the block body of the source shard block, as shown in the cross-shard transaction response list. For simplicity, Fig.28 The cross-shard transaction response list is omitted. In addition, the cross-shard transaction submission instructions received by each target shard included in the block body of the main chain block are preferably not packaged in a previously generated block of the main chain.

[0355] Furthermore, the source shard may send a cross-shard transaction commit instruction to the main chain. Moreover, the source shard may send the block header of the generated source shard block together with the cross-shard transaction commit instruction to the main chain. In addition, the source shard may also process transactions sent by the client received by the source shard in the generated shard block. The transactions sent by these clients may also include cross-shard transactions. Those skilled in the art may understand that for situations including cross-shard transactions, the execution may be repeated starting from S171. For simplicity, only the case where the source shard sends a cross-shard transaction commit instruction to the main chain is discussed below.

[0356] In addition to sending the cross-shard transaction submission instruction to the main chain, the source shard can also send the block header of the generated source shard block to the main chain.

[0357] S333: During the process of generating a main chain block, the main chain fills the received cross-shard transaction submission instruction that needs to be sent to the target shard into the block body of the main chain block; the main chain sends the cross-shard transaction submission instruction to the corresponding target shard according to the identifier of the target shard.

[0358] After receiving the cross-shard transaction submission instruction from the target shard, the node in the main chain can first verify the cross-shard transaction submission instruction. For example, the hash value of the root node of the tree formed by the cross-shard transaction submission instruction can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction submission instruction received this time is repeated with the cross-shard transaction submission instruction received previously. If repeated, the cross-shard transaction submission instruction sent this time can be stopped, otherwise continue to be processed.

[0359] The master node in the main chain can collect cross-shard transaction submission instructions sent by the source shard, or the non-master node in the main chain can forward these cross-shard transaction submission instructions to the master node in the main chain after receiving the cross-shard transaction submission instructions sent by the source shard. The master node in the main chain can package a certain number of cross-shard transaction submission instructions sent by each shard within a period of time and initiate a consensus proposal. After reaching a consensus in the main chain, each node in the main chain executes these packaged transactions to generate a main chain block.

[0360] In the process of generating the main chain block, the block hash of the source shard block sent by each source shard can also be calculated, and the source shard block hash can be filled into the block body of the main chain block. Furthermore, in the process of generating the main chain block, the hash value of the root calculated by the shard block hash of each shard according to the tree structure can also be filled into the shard block root of the block header of the main chain block, for example Fig.28 as shown in .

[0361] Each node in the main chain executes these packaged cross-slice transaction submission instructions and generates a block, which may include filling the cross-slice transaction submission instructions that need to be sent to the target slicing into the block body of the main chain block. Specifically, the cross-slice transaction submission instructions that need to be executed by the target slicing can be filled into the block body of the main chain block according to the order of the cross-slice transaction submission instructions that need to be sent to the target slicing in the message of the consensus proposal initiated by the master node in the main chain. In addition, the cross-slice transaction submission instructions can be grouped according to the target slicing to be sent to, and the grouped cross-slice transaction submission instructions can be filled into the block body of the main chain block. The grouped groups of cross-slice transaction submission instructions can be arranged in ascending or descending order according to the grouping number and then filled into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-slice transaction submission instructions into a tree, and generate a hash value based on the root of the tree and fill the hash value into the Transaction_Root of the block header of the main chain block. In addition, for the aforementioned case where the main chain block includes a cross-shard transaction list, the cross-shard transaction submission instruction list and the cross-shard transaction list in S173 can be organized into a tree, and a hash value is generated based on the tree root and the hash value is filled into the Transaction_Root of the block header of the main chain block. Alternatively, the cross-shard transaction submission instructions are organized into a separate tree, and the hash value of the root of the generated tree is filled into the block header of the main chain block (for example, a new field, such as cross-shard transaction submission instruction_root, Fig.28 After adding the block number, timestamp, hash of the previous block and other fields to the block header of the main chain block, the main chain block is generated.

[0362] As mentioned above, the source shard can send the block header of the generated shard block and the cross-shard transaction submission instruction to the main chain together. After the main chain receives the block header of the source shard block and the cross-shard transaction submission instruction sent by the source shard, it can verify the block header of the shard block. The verification may include calculating the hash value of the root node according to the tree structure according to the cross-shard transaction submission instruction, and determining that the value is consistent with the cross-shard transaction submission instruction_root in the block header. Alternatively, the root of the tree is calculated according to the tree structure according to the cross-shard transaction submission instruction, and the hash value is obtained based on the tree root (which may also include the root of the tree composed of cross-shard transactions, the root of the tree composed of cross-shard transaction responses, etc.), and determining that the value is consistent with the Transaction_root in the block header. If they are inconsistent, the verification fails, otherwise the verification passes. It can also be verified whether the block header of the shard block sent by the source shard this time is the same as the block header of the shard block sent previously. If they are the same, it means that it is repeated with the previous shard block, and the verification fails, otherwise the verification passes. In addition, it is also possible to verify whether the Prev Hash in the block header of the shard block sent this time is the hash value of the shard block of the previous block number. If it is, the verification passes, otherwise it fails.

[0363] Afterwards, the main chain can send the cross-shard transaction submission instruction that needs to be executed by the target shard to the corresponding target shard according to the identifier of the target shard. Specifically, the cross-shard transaction submission instructions grouped in the block body of the main chain block can be sent to the corresponding target shard according to the identifier of the target shard. In this way, the cross-shard transaction submission instructions grouped in the block body of the main chain block can be sent to the corresponding target shard according to the identifier of the target shard. In addition to sending the cross-shard transaction submission instruction that needs to be executed by the target shard to the corresponding target shard according to the identifier of the target shard, the block header of the main chain block can also be sent to the target shard, for example, sent to the target shard together with the cross-shard transaction submission instruction that needs to be processed by the corresponding target shard.

[0364] S335: During the process of the target shard generating the target shard block, the cross-shard transaction submission instruction received from the main chain is filled into the block body of the target shard block, and the status generated by executing the cross-shard transaction is submitted locally.

[0365] After the node in the target shard receives the cross-shard transaction submission instruction sent by the main chain, it can first verify the cross-shard transaction submission instruction. For example, the hash value of the root node of the tree formed by the cross-shard transaction submission can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction submission instruction received this time is repeated with the cross-shard transaction submission instruction received previously. If repeated, the cross-shard transaction submission instruction sent this time can be no longer processed, otherwise it continues to be processed.

[0366] The target shard can receive a cross-shard transaction submission instruction from the main chain that needs to be executed by the target shard. In addition, the target shard can also receive a transaction request initiated by a client connected to it. The master node in the target shard can package a certain number of transactions received within a period of time and initiate a consensus proposal. The packaged transaction may include the cross-shard transaction submission instruction sent by the aforementioned main chain, and may also include the transaction sent by the client received by the target shard, and may also include the aforementioned cross-shard transaction response. After reaching a consensus in the target shard, each node in the target shard executes these packaged transactions to generate a target shard block. The target shard block here is different from the target shard block in S245. Since the target shard is constantly forming blocks, the shard block generated by the target shard here is later than the target shard block in S245. For example, in S245, Fig.29 If block 201 is generated, then this is the block generated after block 201, for example, block 202. In the process of generating the target shard block by the target shard, the cross-shard transaction submission instruction received from the main chain can be filled into the block body of the source shard block, such as in the cross-shard transaction submission instruction list. In addition, the target shard can also fill the packaged transaction sent by the client into the block body of the target shard block, such as in the original transaction list. The cross-shard transaction submission instruction filled in the block body of the target shard block can be organized in a tree structure, and the hash value of the tree root is the cross-shard transaction submission instruction _Root in the block header of the generated target shard block.

[0367] As mentioned in the aforementioned S333, in addition to sending the cross-shard transaction to the corresponding target shard, the main chain can also send the block header of the main chain block to the target shard. After the target shard receives the block header of the main chain block and the cross-shard transaction submission instruction sent by the main chain, it can verify the block header of the main chain block. The verification may include that the target shard calculates the hash of the main chain block based on the block header of the main chain block sent by the main chain this time, and judges whether it is the same as the block header of the main chain block sent previously based on the hash of the main chain block. If they are the same, it means that it is repeated with the previous main chain block and the verification fails, otherwise the verification passes. In addition, it can also be verified whether the Prev Hash in the block header of the main chain block sent this time is the hash value of the main chain block sent last time. If so, the verification passes, otherwise it fails.

[0368] In the case where the main chain also sends the block header of the generated main chain block to the target shard, the target shard can calculate the hash value of the main chain block according to the block header of the received main chain block in the process of generating the target shard block. Furthermore, the target shard can also fill the hash value of the main chain block into the block header of the target shard block generated by the target shard. In the case where the generation speed of the main chain block is not lower than the generation speed of the shard block, the target shard can fill the hash value of the latest main chain block into the block header of the target shard block generated by the target shard. Whether it is the latest can be judged according to the timestamp or block number in the block header of the main chain block. As mentioned above, in the process of generating the target shard block, the target shard can also verify whether the hash value of the current main chain block is repeated with the main chain block sent previously. If it is repeated, the block header sent this time and the corresponding cross-shard transaction submission instruction can no longer be processed, otherwise continue to process. The target shard fills the hash value of the latest main chain block into the block header of the target shard block generated by the target shard. If the generation speed of the main chain block is equal to the generation speed of the shard block, the target shard can identify in the target shard the main chain block whose block body the cross-shard transaction submission instruction received in the current target shard is the cross-shard transaction submission instruction. If the generation speed of the main chain block is higher than the generation speed of the shard block, the target shard can identify in the target shard the main chain block whose block body the cross-shard transaction submission instruction received in the current target shard is the cross-shard transaction submission instruction up to.

[0369] Since the generation speed of the main chain block is not lower than the generation speed of the shard block, if the generation speed of the main chain block is higher than the generation speed of the shard block, Fig.29 As shown in , between the generation of shard block 101 and the target shard block 102, shard 1 has generated two main chain blocks in the main chain, namely main chain blocks 10003 and 10004. Fig.29 The main chain shown in sends the block header of the main chain block 10004 and the cross-shard transaction submission instruction in the main chain block 10004 to Shard 1. In fact, before this, if the main chain block 10003 also contains the cross-shard transaction submission instruction that Shard 1 needs to process, the main chain can also send the block header of the main chain block 10003 and the cross-shard transaction submission instruction in the main chain block 10003 that needs to be processed by Shard 1 to Shard 1. That is, under normal circumstances, the main chain sends the block header of the main chain block and the corresponding cross-shard transaction submission instruction to the shard involved in the cross-shard transaction submission instruction in the time sequence of the generation of the main chain block. In this way, the target shard can fill the hash value of the latest main chain block into the block header of the target shard block generated by the target shard. In the above example, the block hash of the main chain block 10004 is filled into the block header of the target shard block generated by the target shard ( Fig.29(not shown). At the same time, shard 1 may include cross-shard transaction submission instructions in main chain blocks 10003 and 10004 that need to be processed by shard 1 in the original transaction list of the block body of the generated shard block 102. In addition, the original transaction list of the shard block 102 may also include transaction requests initiated by clients connected to shard 1. The transaction request initiated by the client connected to shard 1 may be a transfer transaction or a transaction to create / call a contract.

[0370] In another case, when the generated target shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction submission instructions that need to be executed by the source shard, in addition to including the cross-shard transaction submission instructions that need to be processed by the shard in the cross-shard transaction submission instruction list of the block body of the shard block, the block header of the shard block may also include the block headers of the multiple main chain blocks. Obviously, in this case, the number of hashes of the processed main chain blocks contained in the block header of the shard block may be uncertain.

[0371] Another situation is Fig.29 As shown, for the case where the generated shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction submission instructions that need to be executed by the target shard, in addition to including the cross-shard transaction submission instructions that need to be processed by the shard in the cross-shard transaction submission instruction list of the block body of the shard block, the block body of the shard block may also include the block hashes of the multiple main chain blocks, such as Fig.29 The hash of the main chain blocks in the block body of block 101 of the shard block. The hashes of these processed main chain blocks contained in the block body of the shard block can be organized according to the tree structure as described above, and the hash value of the root of the tree is filled into the field "main chain block root Hash" added in the block header, that is, the hash value of the root calculated according to the tree structure of the hash of each main chain block is filled into the main chain block root Hash in the block header of the shard block. For example, the "main chain block root Hash" in the block header of block 101 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block body of block 101; the "main chain block root Hash" in the block header of block 102 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block header of block 102. This has the advantage that a fixed field can be used in the block header of the shard block to lock the hash of an indefinite number of processed main chain blocks that may be included in the block body of the shard block.

[0372] In addition, the main chain can also send the timestamp of the generated main chain block to the target shard, for example, by indicating the timestamp of the main chain block through the block header of the main chain block sent previously, so that the shard can fill the timestamp of the latest main chain block into the timestamp of the shard block in the process of generating the shard block. For example, in S335, during the process of the target shard generating the target shard block, the timestamp in the block header of the target shard block is set to the latest timestamp sent by the main chain. In this way, the time system of the main chain can be anchored in the shard, so that the shard has the same clock system as the main chain. In the case where the shard has the same clock system as the main chain, the client connected to the shard can determine the initiation time of the transaction when initiating the transaction. Thus, when the client initiates the transaction, the timestamp of the initiation moment can be attached to the initiated transaction.

[0373] Each node in the target shard executes the transaction, including executing the cross-shard transaction commit instruction. Executing the cross-shard transaction commit instruction includes submitting the relevant changed state in the target shard corresponding to the cross-shard transaction commit instruction to the underlying database, i.e., persistent storage.

[0374] In addition, the state generated by the target shard submitting and executing the cross-shard transaction locally, and the cross-shard transaction submission instruction received from the main chain is filled into the block body of the target shard block during the process of the target shard generating the target shard block. There is no strict order between the two, and they can also be executed in parallel.

[0375] The method embodiment of submitting cross-shard transactions provided by the present application forwards the cross-shard transaction submission instruction generated in the source shard to the target shard through the main chain in the blockchain system including shards, and provides a solution for submitting shard transactions in the blockchain system including shards. This process, through the authority of the nodes constituting the main chain, enables the cross-shard transaction submission instruction generated in the source shard to be reliably forwarded and executed in the target shard under the witness of the main chain, and evidence is stored on the source shard, the main chain and the target shard.

[0376] As mentioned above, even if the nodes in the source shard in S171 have completed consensus in their own shard and executed these cross-shard transactions in the source shard block, they will not submit the changed status of the relevant accounts in their own shard generated by the cross-shard transactions in the source shard block to the database, i.e., they will not be persistently stored. Furthermore, the source shard forwards the cross-shard transactions generated in the source shard to the target shard through the main chain.

[0377] After each node in the target shard executes the cross-shard transaction, it can also determine whether the executed cross-shard transaction also involves cross-shard transactions that need to be executed by other shards. If the target shard determines that the executed cross-shard transaction does not involve other shards, the changed state of the corresponding account in the target shard can be submitted to the underlying database, that is, persistent storage. Furthermore, the target shard can notify the source shard through the main chain to submit the state generated by the cross-shard transaction.

[0378] Fig.34 The process is shown, including:

[0379] S341: In the process of generating a target shard block, after determining that there are no cross-shard transactions that need to be executed by other shards based on the cross-shard transactions executed by the target shard, the status generated by executing the cross-shard transactions is submitted locally, and a cross-shard transaction submission instruction is generated and sent to the main chain.

[0380] The state generated by the target shard submitting and executing the cross-shard transaction locally and the cross-shard transaction submission instruction generated in the process of generating the target shard block have no strict order and can be executed in parallel.

[0381] As mentioned above, there are also cases of multiple cross-shard transactions. For example, there is a type of cross-shard transaction. When the source shard generates a first cross-shard transaction that needs to be executed by the first shard, the first cross-shard transaction is sent to the first shard for execution by the first shard. After the first shard executes the first cross-shard transaction, a second cross-shard transaction that needs to be executed by the target shard is generated, and the second cross-shard transaction is sent to the target shard. Then, the target shard executes the second cross-shard transaction, and in the process of the target shard executing the second cross-shard transaction, no cross-shard transactions that need to be executed by other shards other than the second shard are generated. Similarly, more complex cross-shard transactions may involve the first shard, the second shard, and so on between the source shard and the target shard.

[0382] In the case of multiple cross-shard transactions, for example, there is a type of cross-shard transaction. After the first shard generates a first cross-shard transaction that needs to be executed by the second shard, the first cross-shard transaction is sent to the second shard for execution by the second shard. After the second shard executes the first cross-shard transaction, a second cross-shard transaction that needs to be executed by the first shard is generated, and the second cross-shard transaction is sent to the first shard. Then, the second cross-shard transaction is executed by the first shard, and during the process of the first shard executing the second cross-shard transaction, no cross-shard transaction that needs to be executed by other shards other than the first shard is generated.

[0383] In the above example, when a shard executes a cross-shard transaction, it can often determine whether there are cross-shard transactions that need to be continued by other shards during the execution process. If it is determined that there are no cross-shard transactions that need to be continued by other shards, then the shard is the last execution link of a cross-shard transaction. For the shard that executes the last execution link of a cross-shard transaction, the state generated by executing the cross-shard transaction can be submitted locally after the cross-shard transaction is executed. The shard that executes the last execution link of the cross-shard transaction is referred to as the target shard here. The shard that executes the cross-shard transaction in the previous link of the target shard is the source shard relative to the target shard. Multiple cross-shard transactions can be the superposition of multiple single cross-shard transactions. Then, the target shard of a single cross-shard transaction can be the source shard of another single cross-shard transaction.

[0384] The target shard executes the cross-shard transaction. If the execution is successful, a cross-shard transaction commit instruction can be generated, and these cross-shard transaction commit instructions can be added to the block body of the shard block, for example Fig.35 The cross-shard transaction commit instruction list shown in . The cross-shard transaction commit instructions in these cross-shard transaction commit instruction lists can be organized into a tree form. Furthermore, the target shard can add a cross-shard transaction commit instruction_Root field in the generated block header to store the hash of the root of the tree organized into these cross-shard transaction commit instructions in the block body. In this way, the target shard can lock the commit instruction generated after executing the cross-shard transaction in this block in the block header. Fig.35 As shown in , the block header of the shard block generated by the target shard may include the block number, timestamp, hash of the previous block, transaction root hash, main chain block root hash, cross-shard transaction submission instruction _Root, etc. Correspondingly, the hash value of the shard block is the hash value calculated by the fields in the block header including the cross-shard transaction submission instruction _Root field.

[0385] Furthermore, the target shard can return the cross-shard transaction submission instruction to the main chain. Moreover, the target shard can send the block header of the generated shard block together with the cross-shard transaction submission instruction to the main chain. In addition, the target shard can also process transactions sent by the client received by the target shard in the generated shard block. And the transactions sent by these clients may also include cross-shard transactions. At this time, the target shard is also the source shard. Those skilled in the art can understand that this is the case of the source shard, and the execution can be repeated from S171. For simplicity here, only the case of returning the cross-shard transaction submission instruction to the main chain as the target shard is discussed below.

[0386] In addition to sending the cross-shard transaction submission instruction to the main chain, the target shard can also send the block header of the generated target shard block to the main chain.

[0387] S343: During the process of generating a main chain block, the main chain fills the received cross-shard transaction submission instruction into the block body of the main chain block; the main chain sends the cross-shard transaction submission instruction to the corresponding source shard according to the identifier of the source shard.

[0388] After receiving the cross-shard transaction instruction from the target shard, the node in the main chain can first verify the cross-shard transaction submission instruction. For example, the hash value of the root node of the tree formed by the cross-shard transaction submission instruction can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction submission instruction received this time is repeated with the cross-shard transaction submission instruction received previously. If repeated, the cross-shard transaction submission instruction sent this time can be stopped, otherwise continue to be processed.

[0389] The master node in the main chain can collect the cross-shard transaction submission instructions sent by the target shard, or the non-master node in the main chain can forward these cross-shard transaction submission instructions to the master node in the main chain after receiving the cross-shard transaction submission instructions sent by the target shard. The master node in the main chain can package a certain number of cross-shard transaction submission instructions sent by each shard within a period of time and initiate a consensus proposal. After reaching a consensus in the main chain, each node in the main chain executes these packaged transactions to generate a main chain block.

[0390] Each node in the main chain executes these packaged cross-shard transaction submission instructions and generates a block, which may include filling the cross-shard transaction submission instructions that need to be executed by the source shard into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-shard transaction submission instructions into a tree, and generate a hash value based on the root of the tree and fill the hash value into the Transaction_Root of the block header of the main chain block. For example, for the aforementioned case where the main chain block includes a cross-shard transaction list, the cross-shard transaction submission instruction list and the cross-shard transaction list can be organized into a tree together, and a hash value is generated based on the root of the tree and the hash value is filled into the Transaction_Root of the block header of the main chain block. Alternatively, the cross-shard transaction submission instructions are organized into a separate tree, and the hash value of the root of the generated tree is filled into the block header of the main chain block (for example, a new field, such as cross-shard transaction submission instruction_root, Fig.35 After adding the block number, timestamp, hash of the previous block and other fields to the block header of the main chain block, the main chain block is generated.

[0391] In the process of generating the main chain block, the main chain can also calculate the block hash of the target shard block sent by each target shard, and fill the target shard block hash into the block body of the main chain block, such as the shard block hash list. Furthermore, the main chain can also fill the hash value of the root calculated by the shard block hash of each shard according to the tree structure into the shard block root (Shards_BlockRoot) of the block header of the main chain block, for example Fig.35 as shown in .

[0392] Each node in the main chain executes these packaged transactions and generates blocks, and fills the cross-shard transaction submission instructions that need to be executed by the source shard into the block body of the main chain block. Specifically, the cross-shard transaction submission instructions that need to be executed by the source shard can be filled into the block body of the main chain block according to the order of the cross-shard transaction submission instructions that need to be executed by the source shard in the message of the consensus proposal initiated by the master node in the main chain. In addition, the cross-shard transaction submission instructions can be grouped according to the source shards that need to be fed back, and the grouped cross-shard transaction submission instructions can be filled into the block body of the main chain block. The grouped groups of cross-shard transaction submission instructions can be sorted in ascending or descending order according to the grouping number and then filled into the block body of the main chain block. Furthermore, each node in the main chain can organize these cross-shard transaction submission instructions into a tree with the same tree structure, and fill the hash value into the Transaction_root field of the block header of the main chain block after obtaining the hash value based on the root of the tree (such as organizing the cross-shard transaction submission instruction list and the cross-shard transaction list in S173 into a tree, and generating a hash value based on the root of the tree and filling the hash value into the Transaction_root of the block header of the main chain block). Preferably, the cross-shard transaction submission instructions that each source shard needs to receive included in the block body of the main chain block are not packaged in the previously generated blocks of the main chain. In addition, if the main chain block generated in the main chain does not have a cross-shard transaction submission instruction received by a certain source shard when the main node packages the transaction before the block is generated, the block body of the main chain block may not include the cross-shard transaction submission instruction that needs to be corresponding to the source shard.

[0393] As mentioned above, the target shard can send the generated block header of the target shard block and the cross-shard transaction submission instruction to the main chain together. After the main chain receives the block header of the target shard block and the cross-shard transaction submission instruction sent by the target shard, it can verify the block header of the target shard block. The verification may include calculating the hash value of the root node according to the tree structure according to the cross-shard transaction submission instruction, and determining that the value is consistent with the cross-shard transaction submission instruction_root in the block header. Alternatively, the root of the tree is calculated according to the tree structure according to the cross-shard transaction submission instruction, and the hash value is obtained based on the tree root (which may also include the root of the tree composed of the cross-shard transaction, etc.), and it is determined that the value is consistent with the Transaction_root in the block header. If it is inconsistent, the verification fails, otherwise the verification passes. It can also be verified whether the block header of the target shard block sent by the target shard this time is the same as the block header of the target shard block sent previously. If they are the same, it means that it is repeated with the previous target shard block, and the verification fails, otherwise the verification passes. In addition, it is also possible to verify whether the Prev Hash in the block header of the target shard block sent this time is the hash value of the target shard block of the previous block number. If so, the verification passes, otherwise it fails.

[0394] Afterwards, the main chain can send the cross-shard transaction submission instruction that needs to be received by the source shard to the corresponding source shard according to the identifier of the source shard. Specifically, the cross-shard transaction submission instructions grouped in the block body of the main chain block can be sent to the corresponding source shard according to the identifier of the source shard. In this way, the cross-shard transaction submission instructions in the main chain block body can be sent separately according to the identifier of the source shard that needs to be received. In addition to sending the cross-shard transaction submission instruction that needs to be executed by the source shard to the corresponding source shard according to the identifier of the source shard, the block header of the main chain block can also be sent to the source shard, for example, together with the cross-shard transaction submission instruction that needs to be processed by the corresponding source shard, it is sent to the source shard.

[0395] As mentioned above, in addition to sending the cross-shard transaction submission instruction to the main chain, the target shard can also send the block header of the generated target shard block to the main chain.

[0396] S345: During the process of the source shard generating the source shard block, the cross-shard transaction submission instruction received from the main chain is filled into the block body of the source shard block, and the status generated by executing the cross-shard transaction is submitted locally.

[0397] After the node in the source shard receives the cross-shard transaction submission instruction sent by the main chain, it can first verify the cross-shard transaction submission instruction. For example, the hash value of the root node of the tree formed by the cross-shard transaction submission instruction can be calculated according to the tree structure, and the hash value can be used to determine whether the cross-shard transaction submission instruction received this time is repeated with the cross-shard transaction submission instruction received previously. If repeated, the cross-shard transaction submission instruction sent this time can be no longer processed, otherwise it continues to be processed.

[0398] The source shard can receive cross-shard transaction submission instructions from the main chain that need to be received by the source shard. In addition, the source shard can also receive transaction requests initiated by clients connected to it. The master node in the source shard can package a certain number of transactions received within a period of time and initiate a consensus proposal. The packaged transactions may include cross-shard transaction submission instructions sent by the aforementioned main chain, and may also include transactions from clients received by the source shard. After reaching a consensus in the source shard, each node in the source shard executes these packaged transactions to generate a source shard block. The source shard blocks here are different from the source shard blocks in S271. Since the source shard is constantly forming blocks, the shard blocks generated by the source shard here are later than the source shard blocks in S271. For example, in S271, Fig.28 As shown, block 201 is generated, and this is the block generated after block 201, such as block 202. In the process of the source shard generating the source shard block, the cross-shard transaction submission instruction received from the main chain can be filled into the block body of the source shard block, such as in the cross-shard transaction submission instruction list. In addition, the target shard can also fill the packaged transactions sent by the client into the block body of the source shard block, such as in the original transaction list. The cross-shard transaction submission instruction list filled in the block body of the source shard block can be organized in a tree structure, and the hash value of the root of the tree is the cross-shard transaction submission instruction _Root in the block header of the generated target shard block. For example, Fig.36 shown.

[0399] As mentioned in the aforementioned S343, in addition to sending the cross-shard transaction submission instruction to the corresponding source shard, the main chain can also send the block header of the main chain block to the source shard. After the source shard receives the block header of the main chain block and the cross-shard transaction submission instruction sent by the main chain, it can verify the block header of the main chain block. The verification may include that the source shard calculates the hash of the main chain block based on the block header of the main chain block sent by the main chain this time, and judges whether it is the same as the block header of the main chain block sent previously based on the hash of the main chain block. If they are the same, it means that it is repeated with the previous main chain block and the verification fails, otherwise the verification passes. In addition, it can also be verified whether the Prev Hash in the block header of the main chain block sent this time is the hash value of the main chain block sent last time. If so, the verification passes, otherwise it fails.

[0400] In the case where the main chain also sends the block header of the generated main chain block to the source shard, the source shard can calculate the hash value of the main chain block according to the block header of the received main chain block in the process of generating the source shard block. Furthermore, the source shard can also fill the hash value of the main chain block into the block header of the source shard block generated by the source shard. In the case where the generation speed of the main chain block is not lower than the generation speed of the shard block, the source shard can fill the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. Whether it is the latest can be judged according to the timestamp or block number in the block header of the main chain block. As mentioned above, in the process of generating the source shard block, the source shard can also verify whether the hash value of the current main chain block is repeated with the main chain block sent previously. If it is repeated, the block header sent this time and the corresponding cross-shard transaction submission instruction can no longer be processed, otherwise continue to process. The source shard fills the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. If the generation speed of the main chain block is equal to the generation speed of the shard block, the source shard can be identified in the source shard for the main chain block whose block body the cross-shard transaction submission instruction received in the current source shard is the cross-shard transaction submission instruction. If the generation speed of the main chain block is higher than the generation speed of the shard block, the source shard can be identified in the source shard for the main chain block whose block body the cross-shard transaction submission instruction received in the current source shard is the cross-shard transaction submission instruction up to.

[0401] Since the generation speed of the main chain block is not lower than the generation speed of the shard block, if the generation speed of the main chain block is higher than the generation speed of the shard block, Fig.36 As shown in , between the generation of shard block 201 and the target shard block 202, shard 2 has generated two main chain blocks in the main chain, namely main chain blocks 10002 and 10003. Fig.36The main chain shown in sends the block header of the main chain block 10003 and the cross-shard transaction submission instruction in the main chain block 10003 to Shard 2. In fact, before this, if the main chain block 10002 also contains the cross-shard transaction submission instruction that Shard 2 needs to receive, the main chain can also send the block header of the main chain block 10002 and the cross-shard transaction submission instruction in the main chain block 10002 that needs to be received by Shard 2 to Shard 2. That is, under normal circumstances, the main chain sends the block header of the main chain block and the corresponding cross-shard transaction submission instruction to the shard involved in the cross-shard transaction submission instruction in the time sequence of the generation of the main chain block. In this way, the source shard can fill the hash value of the latest main chain block into the block header of the source shard block generated by the source shard. In the above example, the block hash of the main chain block 10003 is filled into the block header of the source shard block generated by the source shard ( Fig.36 At the same time, shard 2 may include cross-shard transaction submission instructions in main chain blocks 10002 and 10003 that need to be received by shard 2 in the original transaction list of the block body of the generated shard block 202. In addition, the original transaction list of the shard block 202 may also include transaction requests initiated by clients connected to shard 2. The transaction request initiated by the client connected to shard 2 may be a transfer transaction or a transaction to create / call a contract.

[0402] In another case, when the generated source shard block includes the block headers of multiple main chain blocks sent by the main chain and the corresponding cross-shard transaction submission instructions that need to be received by the source shard, in addition to including the cross-shard transaction submission instructions that need to be processed by the shard in the cross-shard transaction submission instruction list of the block body of the shard block, the block header of the shard block may also include the block headers of the multiple main chain blocks. Obviously, in this case, the number of hashes of the processed main chain blocks contained in the block header of the shard block may be uncertain.

[0403] In another case, for the case where the generated shard block includes the block headers of multiple main chain blocks sent from the main chain and the corresponding cross-shard transaction submission instructions that need to be received by the source shard, in addition to including the cross-shard transaction submission instructions that need to be processed by the shard in the cross-shard transaction submission instruction list of the block body of the shard block, the block body of the shard block may also include the block hashes of the multiple main chain blocks. The hashes of these processed main chain blocks contained in the block body of the shard block can be organized according to the tree structure as described above, and the hash value of the root of the tree is filled in the field "main chain block root Hash" added in the block header, such as Fig.36As shown, the hash value of the root calculated according to the tree structure of the hash of each main chain block is filled into the main chain block root Hash in the block header of the shard block. For example, the "main chain block root Hash" in the block header of block 201 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block body of block 201; the "main chain block root Hash" in the block header of block 202 is the hash value of the root node of the tree structure organized by the main chain block hash in the main chain block hash list in the block header of block 202. The advantage of this is that a fixed field can be used in the block header of the shard block to lock the hash of an indefinite number of processed ma...

Claims

1. A method for exiting a cross-shard transaction in a blockchain system including shards, wherein the blockchain system includes at least two shards, and nodes in different shards store different state sets, wherein: The different state sets include any one or more of the following: states of different external account sets; sets of different contract account states; and states of different contract account sets; the blockchain system also includes a main chain; The method includes: an exception occurs when the target shard submits a cross-shard transaction-related operation locally, or a timeout occurs when waiting for a message related to the cross-shard transaction: The target shard locally withdraws the cross-shard transaction operation that has an exception / timeout, generates an exit instruction for the cross-shard transaction that needs to be executed by the corresponding source shard, and sends the cross-shard transaction exit instruction to the main chain; In the process of generating the main chain block, the main chain fills the received instruction of exiting the cross-shard transaction that needs to be executed by the source shard into the block body of the main chain block; the main chain sends the instruction of exiting the cross-shard transaction that needs to be executed by the source shard to the corresponding source shard according to the identifier of the source shard; In the process of the source shard generating the source shard block, the cross-shard transaction exit instruction received from the main chain is filled into the block body of the source shard block, and the instruction to exit the cross-shard transaction is executed.

2. According to the method of claim 1, the target shard locally submits operations related to the cross-shard transaction, including: The target shard executes the cross-shard transaction locally, or, The target shard generates a cross-shard transaction commit instruction locally, or, The target shard locally commits the state generated by executing the cross-shard transaction.

3. The method according to claim 1, wherein the timeout occurs when the target shard waits for a message related to the cross-shard transaction, comprising: The target shard times out waiting for a response from the cross-shard transaction, or, The target shard times out waiting for a cross-shard transaction commit response, or, The target shard times out waiting for the cross-shard transaction commit instruction.

4. The method according to claim 1, wherein the target shard locally withdraws the cross-shard transaction operation that has an exception / timeout, specifically comprising: The target shard locally deletes the data temporarily inserted into the underlying database by executing the cross-shard transaction. and / or, The target shard locally performs a reverse operation on the state changed by executing the cross-shard transaction, so as to roll back the state to the state before the cross-shard transaction was executed.

5. According to the method of claim 1, the block body of the target shard block generated by the target shard also includes the cross-shard transaction exit instruction list, and the cross-shard transaction exit instruction list includes the cross-shard transaction exit instructions that need to be sent to the source shard.

6. According to the method of claim 5, the block header of the target shard block generated by the target shard also includes a cross-shard transaction exit instruction_root field, which is used to lock the cross-shard transaction exit instruction list in the block body into the block header.

7. According to the method as claimed in claim 1, the block body of the main chain block includes the cross-shard transaction exit instructions received by each source shard, which are not packaged in the previously generated block of the main chain.

8. The method according to claim 1, before the main chain generates the main chain block, further comprising: After receiving the cross-shard transaction exit instruction sent by the target shard, the node in the main chain verifies the cross-shard transaction exit instruction.

9. The method of claim 8, wherein the verification comprises: The nodes in the main chain calculate the hash value of the root node of the tree composed of the cross-shard transaction exit instructions sent by the target shard according to the tree structure, and determine whether the cross-shard transaction exit instruction received this time is the same as the cross-shard transaction exit instruction received previously based on the hash value.

10. According to the method of claim 1, in addition to sending the cross-shard transaction exit instruction to the main chain, the target shard also sends the generated block header of the target shard block to the main chain.

11. According to the method of claim 10, in the process of generating the main chain block from the main chain, the block hash value of the target shard block sent by each target shard is also calculated, and the target shard block hash value is filled into the block body of the main chain block.

12. According to the method as claimed in claim 11, in the process of generating the main chain block by the main chain, the hash value of the root of the shard block hash value of each target shard calculated according to the tree structure is filled into the shard block root of the block header of the main chain block.

13. According to the method of claim 12, after the main link receives the block header of the target shard block and the cross-shard transaction exit instruction sent by the target shard, it also verifies the block header of the target shard block.

14. The method as claimed in claim 13, wherein the verification includes determining whether the hash value of the tree obtained by organizing the cross-shard transaction exit according to the tree structure is consistent with the cross-shard transaction exit instruction _root in the block header of the target shard block.

15. The method according to claim 1, wherein the main chain sends the cross-shard transaction exit instruction to the corresponding source shard according to the identifier of the source shard, comprising: The cross-shard transaction exit instructions grouped in the block body of the main chain block are sent to the corresponding source shard according to the identifier of the source shard.

16. According to the method of claim 1, the main chain also sends the block header of the main chain block to the source shard.

17. The method according to claim 1, before the source shard generates the source shard block, further comprising: After receiving the cross-shard transaction exit instruction sent by the main chain, the node in the source shard verifies the cross-shard transaction exit instruction.

18. The method of claim 17, wherein the verification comprises: The nodes in the source shard calculate the hash value of the root node of the tree formed by the cross-shard transaction exit instruction according to the tree structure, and determine whether the cross-shard transaction exit instruction received this time is the same as the cross-shard transaction exit instruction received previously based on the hash value.

19. According to the method of claim 16, after the source shard receives the block header of the main chain block and the cross-shard transaction exit instruction sent by the main chain, the source shard also verifies the block header of the main chain block.

20. According to the method of claim 16, in the process of generating a source shard block, the source shard calculates the hash value of the main chain block according to the block header of the received main chain block, and fills the hash value of the main chain block into the block header of the source shard block generated by the source shard.

21. The method as claimed in claim 20, when the generation speed of the main chain block is not lower than the generation speed of the source shard block, the source shard fills the hash value of the latest main chain block into the block header of the source shard block generated by the source shard.

22. The method of claim 20, wherein when the generation speed of the main chain block is higher than the generation speed of the source shard block: The source shard fills the hash values ​​of multiple main chain blocks corresponding to the cross-shard transaction exit instructions packaged in the source shard block into the block header of the source shard block generated by the source shard; or, The source shard fills the hash values ​​of multiple main chain blocks corresponding to the cross-shard transaction exit instructions packaged in the source shard block into the block body of the source shard block generated by the source shard, and also fills the hash value of the root calculated according to the tree structure of the hash value of each main chain block into the main chain block root hash value of the block header of the source shard block.

23. According to the method of claim 1, the main chain also sends the timestamp of the generated main chain block to the source shard, and the source shard fills the timestamp of the main chain block into the timestamp of the source shard block during the process of generating the source shard block.

24. The method of claim 16, wherein the main chain sends the timestamp of the main chain block to the source shard by sending the block header of the main chain block.

25. According to the method of claim 23 or 24, the main chain sends the timestamp of the latest main chain block generated to the source shard, and accordingly, the source shard fills the timestamp of the latest main chain block into the timestamp of the source shard block during the process of generating the source shard block.

26. The method according to claim 1, wherein the source shard executes the cross-shard transaction exit instruction, comprising: The source shard locally deletes the data that was temporarily inserted into the underlying database when executing the cross-shard transaction. and / or, The source shard locally performs a reverse operation on the state changed by executing the cross-shard transaction, so as to roll back the state to the state before the cross-shard transaction was executed.

27. A system for exiting cross-shard transactions in a blockchain system including shards, wherein the blockchain system includes at least two shards, and nodes in different shards store different state sets, wherein: The different state sets include any one or more of the following: states of different external account sets; sets of different contract account states; and states of different contract account sets; the blockchain system also includes a main chain; The target shard encounters an exception when submitting cross-shard transaction-related operations locally, or times out while waiting for messages related to cross-shard transactions: The target shard locally withdraws the cross-shard transaction operation that has an exception / timeout, generates an exit instruction for the cross-shard transaction that needs to be executed by the corresponding source shard, and sends the cross-shard transaction exit instruction to the main chain; In the process of generating the main chain block, the main chain fills the received instruction of exiting the cross-shard transaction that needs to be executed by the source shard into the block body of the main chain block; the main chain sends the instruction of exiting the cross-shard transaction that needs to be executed by the source shard to the corresponding source shard according to the identifier of the source shard; In the process of the source shard generating the source shard block, the cross-shard transaction exit instruction received from the main chain is filled into the block body of the source shard block, and the instruction to exit the cross-shard transaction is executed.

28. The system of claim 27, wherein the target shard locally submits operations related to the cross-shard transaction, comprising: The target shard executes the cross-shard transaction locally, or, The target shard generates a cross-shard transaction commit instruction locally, or, The target shard locally commits the state generated by executing the cross-shard transaction.

29. The system of claim 27, wherein the target shard waits for a message related to the cross-shard transaction to time out, comprising: The target shard times out waiting for a response from the cross-shard transaction, or, The target shard times out waiting for a cross-shard transaction commit response, or, The target shard times out waiting for the cross-shard transaction commit instruction.

30. The system according to claim 27, wherein the target shard locally withdraws the cross-shard transaction operation that has an exception / timeout, specifically comprising: The target shard locally deletes the data temporarily inserted into the underlying database by executing the cross-shard transaction. and / or, The target shard locally performs a reverse operation on the state changed by executing the cross-shard transaction, so as to roll back the state to the state before the cross-shard transaction was executed.

31. The system of claim 27, wherein the block body of the target shard block generated by the target shard also includes the cross-shard transaction exit instruction list, and the cross-shard transaction exit instruction list includes the cross-shard transaction exit instructions that need to be sent to the source shard.

32. The system of claim 31, wherein the block header of the target shard block generated by the target shard further includes a cross-shard transaction exit instruction_root field, which is used to lock the cross-shard transaction exit instruction list in the block body into the block header.

33. In the system as described in claim 27, the block body of the main chain block includes the cross-shard transaction exit instructions received by each source shard, which are not packaged in the previously generated block of the main chain.

34. The system of claim 27, before the main chain generates the main chain block, further comprising: After receiving the cross-shard transaction exit instruction sent by the target shard, the node in the main chain verifies the cross-shard transaction exit instruction.

35. The system of claim 34, wherein the verification comprises: The nodes in the main chain calculate the hash value of the root node of the tree composed of the cross-shard transaction exit instructions sent by the target shard according to the tree structure, and determine whether the cross-shard transaction exit instruction received this time is the same as the cross-shard transaction exit instruction received previously based on the hash value.

36. In the system of claim 27, in addition to sending the cross-shard transaction exit instruction to the main chain, the target shard also sends the block header of the generated target shard block to the main chain.

37. The system as described in claim 36, in the process of generating the main chain block by the main chain, also calculates the block hash value of the target shard block sent by each target shard, and fills the target shard block hash value into the block body of the main chain block.

38. The system as described in claim 37, in the process of generating the main chain block by the main chain, also fills the hash value of the root of the shard block root of the block header of the main chain block with the hash value of the shard block of each target shard calculated according to the tree structure.

39. In the system as described in claim 38, after the main link receives the block header of the target shard block and the cross-shard transaction exit instruction sent by the target shard, it also verifies the block header of the target shard block.

40. The system of claim 39, wherein the verification comprises determining whether a hash value of a tree obtained by organizing the cross-shard transaction exit in a tree structure is consistent with a cross-shard transaction exit instruction _root in a block header of the target shard block.

41. The system of claim 27, wherein the main chain sends the cross-shard transaction exit instruction to the corresponding source shard according to the identifier of the source shard, comprising: The cross-shard transaction exit instructions grouped in the block body of the main chain block are sent to the corresponding source shard according to the identifier of the source shard.

42. The system of claim 27, wherein the main chain also sends a block header of the main chain block to the source shard.

43. The system of claim 27, before the source shard generates the source shard block, further comprising: After receiving the cross-shard transaction exit instruction sent by the main chain, the node in the source shard verifies the cross-shard transaction exit instruction.

44. The system of claim 43, wherein the verification comprises: The nodes in the source shard calculate the hash value of the root node of the tree formed by the cross-shard transaction exit instruction according to the tree structure, and determine whether the cross-shard transaction exit instruction received this time is the same as the cross-shard transaction exit instruction received previously based on the hash value.

45. In the system as described in claim 42, after the source shard receives the block header of the main chain block and the cross-shard transaction exit instruction sent by the main chain, it also verifies the block header of the main chain block.

46. ​​In the system as described in claim 42, during the process of generating the source shard block, the source shard calculates the hash value of the main chain block according to the block header of the received main chain block, and fills the hash value of the main chain block into the block header of the source shard block generated by the source shard.

47. In the system as described in claim 46, when the generation speed of the main chain block is not lower than the generation speed of the source shard block, the source shard fills the hash value of the latest main chain block into the block header of the source shard block generated by the source shard.

48. The system of claim 46, wherein when the generation speed of the main chain block is higher than the generation speed of the source shard block: The source shard fills the hash values ​​of multiple main chain blocks corresponding to the cross-shard transaction exit instructions packaged in the source shard block into the block header of the source shard block generated by the source shard; or, The source shard fills the hash values ​​of multiple main chain blocks corresponding to the cross-shard transaction exit instructions packaged in the source shard block into the block body of the source shard block generated by the source shard, and also fills the hash value of the root calculated according to the tree structure of the hash value of each main chain block into the main chain block root hash value of the block header of the source shard block.

49. In the system as described in claim 27, the main chain also sends the timestamp of the generated main chain block to the source shard, and the source shard fills the timestamp of the main chain block into the timestamp of the source shard block during the process of generating the source shard block.

50. The system of claim 42, wherein the main chain sends the timestamp of the main chain block to the source shard by sending the block header of the main chain block.

51. In the system as described in claim 49 or 50, the main chain sends the timestamp of the latest main chain block generated to the source shard, and accordingly, the source shard fills the timestamp of the latest main chain block into the timestamp of the source shard block during the process of generating the source shard block.

52. The system of claim 27, wherein the source shard executes the cross-shard transaction exit instruction, comprising: The source shard locally deletes the data that was temporarily inserted into the underlying database when executing the cross-shard transaction. and / or, The source shard locally performs a reverse operation on the state changed by executing the cross-shard transaction, so as to roll back the state to the state before the cross-shard transaction was executed.

53. A target shard node in a blockchain system comprising shards, wherein: The blockchain system includes at least two shards, and nodes in different shards store different state sets; the different state sets include any one or more of the following: states of different external account sets; A collection of different contract account states; And the status of different contract account sets; The target sharding node includes: Execution unit, used to locally execute cross-shard transaction-related operations; The target shard block generation unit is used to generate a target shard block when an exception occurs in the operation related to the cross-shard transaction submitted locally by the execution unit or a timeout occurs when waiting for a message related to the cross-shard transaction occurs, and generate a cross-shard transaction exit instruction in the process of generating the target shard block; The cross-shard transaction exit unit is used to locally withdraw cross-shard transaction operations that have encountered exceptions or timeouts; A sending unit is used to send the cross-shard transaction exit instruction to the main chain.

54. The target shard node according to claim 53, wherein the execution unit locally submits operations related to the cross-shard transaction, including: The execution unit executes cross-shard transactions locally, or, The execution unit generates a cross-shard transaction commit instruction locally, or, The execution unit locally commits the state generated by executing cross-shard transactions.

55. The target shard node of claim 53, wherein the execution unit waits for a timeout on a message related to a cross-shard transaction, comprising: The execution unit times out while waiting for a cross-shard transaction response, or, The execution unit times out while waiting for a cross-shard transaction commit response, or, The execution unit timed out waiting for the cross-shard transaction commit instruction.

56. The target shard node according to claim 53, wherein the cross-shard transaction exit unit locally withdraws the cross-shard transaction operation that is abnormal / timed out, specifically comprising: The cross-shard transaction exit unit locally deletes the data temporarily inserted into the underlying database during the execution of the cross-shard transaction; and / or, The cross-shard transaction exit unit locally performs a reverse operation on the state changed by executing the cross-shard transaction, so as to roll back the state to the state before the cross-shard transaction was executed.

57. The target shard node as described in claim 53, wherein the block body of the target shard block generated by the target shard block generation unit also includes the cross-shard transaction exit instruction list, and the cross-shard transaction exit instruction list includes the cross-shard transaction exit instructions that need to be sent to the source shard.

58. The target sharding node as described in claim 57, wherein the block header of the target sharding block generated by the target sharding block generation unit also includes a cross-shard transaction exit instruction_root field, which is used to lock the cross-shard transaction exit instruction list in the block body into the block header.

59. The target sharding node as described in claim 53, wherein the sending unit also sends the block header of the sharding block generated by the target sharding block generation unit to the main chain.

60. A main chain node in a blockchain system including shards, wherein: The blockchain system includes at least two shards, and nodes in different shards store different state sets; the different state sets include any one or more of the following: states of different external account sets; A collection of different contract account states; And the status of different contract account sets; the main chain nodes include: A receiving unit, configured to receive a cross-shard transaction exit instruction to be executed by a source shard; A main chain block generation unit, used to generate a main chain block, and in the process of generating the main chain block, fill the received cross-shard transaction exit instruction into the block body of the main chain block; A sending unit is used to send the cross-shard transaction exit instruction to the corresponding source shard according to the identifier of the source shard.

61. In the main chain node as described in claim 60, the block body of the block generated by the main chain block generation unit includes the cross-shard transaction exit instructions received by each source shard, which are not packaged in the previously generated block of the main chain.

62. The main chain node as described in claim 60 further includes a verification unit, and after the receiving unit receives the cross-shard transaction exit instruction sent by the target shard, the verification unit verifies the cross-shard transaction exit instruction.

63. The main chain node according to claim 62, wherein the verification comprises: The nodes in the main chain calculate the hash value of the root node of the tree composed of the cross-shard transaction exit instructions sent by the target shard according to the tree structure, and determine whether the cross-shard transaction commit instruction received this time is the same as the cross-shard transaction exit instruction received previously based on the hash value.

64. In the main chain node as described in claim 62, the receiving unit also receives the block header of the target shard block.

65. The main chain node as described in claim 64, in the process of generating the main chain block by the main chain block generation unit, also calculates the block hash value of the target shard block sent by each target shard, and fills the target shard block hash value into the block body of the main chain block.

66. The main chain node as described in claim 65, in the process of generating the main chain block by the main chain block generation unit, also fills the hash value of the root calculated according to the tree structure of the shard block hash value of each target shard into the shard block root of the block header of the main chain block.

67. In the main chain node as described in claim 66, after the receiving unit receives the block header of the target block and the cross-shard transaction exit instruction sent by the target shard, the verification unit also verifies the block header of the target shard block.

68. The main chain node as described in claim 67, wherein the verification includes organizing the cross-shard transaction exit instruction in a tree structure to obtain a hash value of the tree, and determining whether the value is consistent with the cross-shard transaction exit instruction _root in the block header of the target shard block.

69. The main chain node according to claim 60, wherein the sending unit sends the cross-shard transaction exit instruction to the corresponding source shard according to the identifier of the source shard, comprising: The cross-shard transaction exit instructions grouped in the block body of the main chain block are sent to the corresponding source shard according to the identifier of the source shard.

70. In the main chain node of claim 60, the sending unit further sends the block header of the main chain block to the source shard.

Images