CN112261158B

CN112261158B - Method and system for returning cross-fragment transaction response, main chain node and source fragment node

Info

Publication number: CN112261158B
Application number: CN202011515895.4A
Authority: CN
Inventors: 邓福喜; 周知远; 谢桂鲁; 徐泉清; 李康; 杨达一
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-12-21
Filing date: 2020-12-21
Publication date: 2021-04-20
Anticipated expiration: 2040-12-21
Also published as: CN112261158A

Abstract

A method and system for returning cross-slice transaction response in a blockchain system comprising slices, a main chain node and a source slicing node are provided. The block chain system at least comprises two fragments, and nodes in different fragments store different state sets; the blockchain system further comprises a backbone; the method comprises the following steps: generating a cross-slice transaction response according to a cross-slice transaction executed by a target slice in the process of generating a target slice block by the target slice, and sending the cross-slice transaction response to a main chain; in the process of generating the main chain block by the main chain, filling the received cross-chip transaction response into the block body of the main chain block; the main chain sends the cross-fragment transaction response to the corresponding source fragment according to the identifier of the source fragment; and in the process of generating a source fragmentation block by the source fragmentation, filling the received cross-fragment transaction response sent by the main chain into the block body of the source fragmentation block.

Description

Method and system for returning cross-fragment transaction response, main chain node and source fragment node

Technical Field

The embodiment of the specification belongs to the technical field of blockchain, and particularly relates to a method and a system for returning cross-chip transaction response in a blockchain system comprising fragments, a main chain node and a source fragment node.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. The block chain is a chain data structure formed by combining data blocks in a sequential connection mode according to a time sequence, and is a distributed account book which is guaranteed in a cryptographic mode and cannot be tampered and forged. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.

Disclosure of Invention

The invention aims to provide a method and a system for returning cross-chip transaction response in a block chain system containing fragments, a main chain node and a source fragment node, wherein the method comprises the following steps:

a method for returning cross-chip transaction response in a blockchain system containing fragments comprises at least two fragments, wherein nodes in different fragments store different state sets; the blockchain system further comprises a backbone;

the method comprises the following steps:

generating a cross-slice transaction response according to a cross-slice transaction executed by a target slice in the process of generating a target slice block by the target slice, and sending the cross-slice transaction response to a main chain;

in the process of generating the main chain block by the main chain, filling the received cross-chip transaction response into the block body of the main chain block; the main chain sends the cross-fragment transaction response to the corresponding source fragment according to the identifier of the source fragment;

and in the process of generating a source fragmentation block by the source fragmentation, filling the received cross-fragment transaction response sent by the main chain into the block body of the source fragmentation block.

A system for returning a cross-chip transaction response in a blockchain system comprising fragments, wherein the blockchain system at least comprises two fragments, and nodes in different fragments store different state sets; the blockchain system further comprises a backbone;

A backbone node in a blockchain system comprising shards, comprising:

a receiving unit, configured to receive a cross-slice transaction response that needs to be executed by a source slice;

the main chain block generating unit is used for generating a main chain block and filling the received cross-chip transaction response into the block body of the main chain block in the process of generating the main chain block;

and the sending unit is used for sending the cross-slice transaction response to the corresponding source slice according to the identifier of the source slice.

A source sharded node in a blockchain system containing shards, comprising:

the receiving unit is used for receiving the cross-chip transaction response sent by the main chain;

and the fragmentation block generating unit is used for generating a source fragmentation block and filling the received cross-fragment transaction response sent by the main chain into the block body of the source fragmentation block in the process of generating the source fragmentation block.

The above-described embodiments of returning a cross-slice transaction response provided by the present application provide a feedback scheme for a cross-slice transaction response in a sharded-containing blockchain system by forwarding a cross-slice transaction response generated in a target shard to a source shard through a main chain in the sharded-containing blockchain system. This process, through the authority of the nodes that make up the backbone, enables cross-slice transaction responses generated in the target slice to be reliably forwarded under the witness of the backbone.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

FIG. 1 is a block chain system architecture in accordance with an embodiment;

FIG. 2 is a block chain system slice architecture in an embodiment;

FIG. 3 is a block chain data storage structure in an embodiment of the present disclosure;

FIG. 4 is a simplified version of a state tree diagram in one embodiment of the present description;

FIG. 5 is a block chain state tree storage structure in an embodiment of the present disclosure;

FIG. 6 is a block chain state tree storage structure in an embodiment of the present disclosure;

FIG. 7 is a block chain state tree storage structure in an embodiment of the present disclosure;

FIG. 8 is a block chain state tree storage structure in an embodiment of the present disclosure;

FIG. 9 illustrates a block chain state tree storage method according to an embodiment of the present disclosure;

fig. 10 is a block chain fragmentation architecture in an embodiment of the present disclosure;

FIG. 11 is a schematic diagram of consistent hashing in one embodiment of the present description;

FIG. 12 is a block chain state tree storage structure in an embodiment of the present disclosure;

FIG. 13 is a block link point diagram in one embodiment of the present description;

FIG. 14 is a block link point diagram in one embodiment of the present description;

FIG. 15 is a block chain slicing system based on a main chain according to an embodiment of the present disclosure;

FIG. 16 is a block diagram of the generation of a block by a block chain slicing system incorporating a main chain according to an embodiment of the present disclosure;

FIG. 17 is a method for performing a cross-slice transaction in a blockchain system including slices in one embodiment of the present description;

fig. 18 is a schematic diagram illustrating that a fragment block generated by fragment 2 includes a cross-fragment transaction list and reports the cross-fragment transaction list to a main chain in an embodiment of the present specification;

FIG. 19 is a block diagram of a backbone block generated by the backbone including a cross-chip transaction and a partition block root according to one embodiment of the present disclosure;

fig. 20 is a schematic diagram of target tile blocks generated by target tiles in an embodiment of the present disclosure;

fig. 21 is a diagram illustrating that a target fragment block generated by target fragment according to an embodiment of the present specification includes a main chain block hash;

fig. 22 is a schematic diagram illustrating that a target fragment block generated by target fragment according to an embodiment of the present specification includes a main chain block hash;

fig. 23 is a schematic diagram illustrating that a target fragment block generated by target fragment according to an embodiment of the present specification includes a main chain block hash;

FIG. 24 is a flow diagram of returning a cross-slice transaction response to a source slice in one embodiment of the present description;

FIG. 25 is a block diagram of a backbone block generated by the backbone including a cross-chip transaction response and a partition block root according to an embodiment of the present disclosure;

fig. 26 is a diagram illustrating a source tile block generated by source tiles in an embodiment of the present specification;

FIG. 27 is a block chain system including shards in one embodiment of the present disclosure;

fig. 28 is a source sharded node in a blockchain system including shards in an embodiment of the specification.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

One of the most important factors that currently limit the large-scale application of blockchain technology is performance, i.e., throughput, which is generally measured by the number of Transactions Per Second (TPS). Developers have proposed various schemes to try to increase the throughput of blocks, a process known as "capacity expansion". From the direction of the expansion technology, the expansion can be divided into two directions of on-chain expansion and under-chain expansion. On-strand expansion typically includes schemes of block expansion, isolation witness, fragmentation, and consensus layer refinement. The under-chain expansion generally comprises the schemes of state channel, side chain and under-chain calculation.

The fragmentation technique belongs to a scheme of chain expansion. The sharding concept stems from the field of databases, which is intended to mean horizontal partitioning of data in a database (dividing different rows of a table into different partitions), each shard being maintained on a separate database server instance to spread the load. The basic idea of blockchain fragmentation is to divide nodes in a blockchain network into a plurality of relatively independent sub-networks, each sub-network includes a part of nodes, and one sub-network is a fragment (shard). A single fragment processes a transaction with a small scale, even only part of network states are stored, and a plurality of fragments process the transaction in parallel, so that the throughput of the whole network is theoretically improved.

The fragmentation technology can be divided into three types according to different fragmentation mechanisms: network sharding (network sharding), transaction sharding (transaction sharding), state sharding (state sharding). Network fragmentation is the most fundamental way of fragmentation, including dividing the entire blockchain network into multiple sub-networks, i.e., multiple fragments. In this way, multiple slices in a blockchain network can process different transactions in the network in parallel. The transaction slicing is to distribute the transaction to different slices according to a certain rule, and the idea is to distribute the transaction to the same slice according to a certain rule for processing, so that the purpose of parallel processing can be achieved, and the problem of double flowers can be avoided. The premise of transaction fragmentation is that network fragmentation is performed first. Among all fragmentation mechanisms, state fragmentation is the most challenging way to fragment. The key of the state fragmentation is to separate the whole storage area, so that different fragments store different parts, and each node is only responsible for storing own fragmentation data, but not storing the complete block chain state. State fragmentation can solve the storage capacity bottleneck problem.

Some blockchain system architectures are shown in fig. 1. As shown in fig. 1, a blockchain system includes, for example, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P full-quantum nodes. The lines between the nodes schematically represent P2P (Peer-to-Peer) connections. All the nodes store the full amount of accounts, namely, all transactions, intelligent contracts and various states are stored. As the block chain traffic grows, the amount of data stored by a single node also grows larger and larger, some of the data reach the order of T (1 TB =1024 GB), and even reach the order of P or E (1 PB =1024TB, 1EB =1024 PB). In order to support the operation of the blockchain system and the duration of the coping business, each node needs to seek the capacity expansion (obtain larger storage space) and have great cost.

Based on this, the embodiments of the present specification provide a block chain system. After being fragmented, the nodes in the blockchain system are divided into 4 fragments, as shown in fig. 2. Each slice includes 4 nodes. The lines between nodes within each slice represent P2P connections, and the lines between each slice also represent P2P connections. The embodiment is merely an example for convenience of illustration, and 4 slices are schematically listed, and each slice includes 4 nodes. In practice, the number of nodes in each shard may be different. Furthermore, there may not be a network connection between some or all of the slices, that is, in some cases, some or all of the slices may not be in direct communication with each other. To support communication between the slices, a backbone may be included in the blockchain network that serves all slices. This backbone is not shown in figure 2.

For explaining the state slicing method in the present application, the block chain state storage structure related to the present application will be introduced first. Given that many blockchain platforms and applications are built based on the underlying technology of etherhouses (Ethereum), the state storage structure of etherhouses is first introduced here. Of course, the blockchain System constructed based on other blockchain technologies may also be applicable to the core content of the present application, such as Fabric-based hyper ledger (hyper folder) and Enterprise Operating System (EOS), Quorum, and Corda, which are not described in detail herein.

The Ethengfang is expanded compared with a bitcoin network, and the balance and the state of the account can be directly displayed by the account by adopting an account system and a world state. The accounts of the etherhouses can be divided into two types:

external account (Externally owned account): the user's account, such as an etherchip owner account.

Contract account (contract account): storing the executed intelligent contract code and the value of the state in the intelligent contract code can typically only be activated by an external account call.

The design of the external account and the contract account is actually a mapping of the account address to the account status. The status of an account typically includes fields such as nonce, balance, storage _ Root, codeHash, etc. Both nonces, balances exist in external accounts and contract accounts. The codeHash and storage Root attributes are generally only valid on contract accounts.

And (4) nonce: a counter. For external accounts, this number represents the number of transactions sent from the account address; for a contract account, it is the number of contracts that the account creates.

balance: the number of ethercoins this address owns.

storage _ Root: a hash of a root node of an MPT tree that organizes the storage of state variables for the contract account.

codeHash: a hash value of the intelligent contract code. For contract accounts, this is the code that the intelligent contract is hashed and stored; for external accounts, the codeHash field may typically be a null string/all 0 string since no smart contract is included.

MPT is known as Merkle Patricia Tree, and is a Tree structure combining Merkle Tree and Patricia Tree (compressed prefix Tree, a more space-saving Trie Tree, dictionary Tree). The Merkle Tree algorithm calculates a Hash value for each transaction, and then calculates the Hash again by connecting two by two until the top-most Merkle root. The etherhouse uses an improved MPT tree, for example a structure of 16-way trees, also commonly referred to as MPT trees for short.

The data structure of the etherhouse MPT tree includes a state tree (state trie). The state tree includes key and value pair (key and value pair) of the storage content corresponding to each account in the ethernet network. The "key" in the state tree may be a 160bits identifier (address of the etherhouse account) that is distributed in the store starting from the root node to the leaf nodes of the state tree. The "value" in the state tree is generated by encoding the information of the etherhouse account using a Recursive-Length dictionary encoding (RLP) method. As previously mentioned, for external accounts, values include nonce and balance; for contract accounts, values include nonce, balance, codehash, and storage _ Root.

The contract account is used to store intelligent contract-related state. After the intelligent contract is deployed on the block chain, a corresponding contract account is generated. This contract account will typically have states that are defined by state variables in the intelligent contract and that generate new values when the intelligent contract is created, executed. The intelligent contract generally refers to a contract defined in a block chain environment in a digital form and capable of automatically executing terms. The code may be executed automatically as soon as an event triggers a term in the contract (execution condition is met). In a block chain, the relevant state of a contract is stored in a storage tree (storage tree), and the hash value of the Root node of the storage tree is stored in the storage _ Root, so that all the states of the contract are locked to the contract account through the hash. The storage tree is also an MPT tree structure that stores a key-value mapping of state addresses to state values. The address of a state is stored from the root node to the leaf node of the memory tree, and a value of a state is stored in one leaf node.

Fig. 3 is a schematic diagram of a block chain data storage structure. In some blockchain data stores, as shown in fig. 3, the block header of each block includes several fields, such as the previous block Hash previous _ Hash (or called parent Hash in the figure), random number Nonce (this Nonce is not a random number in some blockchain systems or is not enabled in some blockchain systems), Timestamp, block number blockacknum, State Root Hash State _ Root, Transaction Root Hash Transaction _ Root, Receipt Root Hash record _ Root, etc. Wherein, the PrevHash in the header of the next block (e.g., block N + 1) points to the previous block (e.g., block N), which is the hash value of the previous block. In this way, the next block is locked to the previous block by the block head on the block chain. In particular, as mentioned above, the state _ root is a hash value of the root of the MPT tree composed of the states of all accounts in the current block, i.e., the state tree in the form of an MPT pointing to the state _ root. The root Node of the MPT tree may be an Extension Node (Extension Node) or a Branch Node (Branch Node), and the state _ root stores a hash value of the root Node. Part of values from the root node of the MPT to each node in the leaf nodes are connected in series according to the sequence to form an account address and serve as a key, and the account information stored in the leaf nodes is a value corresponding to the account address, so that a key-value key value pair is formed. Specifically, the key may be sha3(Address), that is, a hash value of the account Address (the hash algorithm adopts, for example, sha3 algorithm), and the value stored in the key may be rlp (account), that is, rlp encoding of the account information. The account information is a quadruple formed by [ nonce, balance, storage _ Root, codeHash ]. As previously mentioned, for external accounts, there are typically only two terms, nonces and balance, while the storage _ Root, codeHash fields store the empty/all 0 strings by default. That is, the external account does not store the contract, nor the generated state variable after execution of the contract. Contract accounts typically include nonces, balance, storage _ Root, codeHash. Wherein the nonce is a transaction counter for the contract account; balance is the account balance; the storage _ Root corresponds to another MPT and can be linked to the information of the state related to the contract through the storage _ Root; the codeHash is the hash value of the contract code. Whether an external account or a contract account, the account information is typically located in a single Leaf Node (Leaf Node). From the extension/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.

The state tree may be a tree of the MPT form, typically a 16-way tree, and may have up to 16 child nodes per level and up to 64 levels deep. For an extension node, for storing a common prefix, there are typically 1 child node, which may be a branch node. For a branch node, there may be 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 levels. When the number of accounts in a blockchain reaches a certain number, this MPT tree may approach or reach a depth of 64 levels.

Wherein, for one contract account in the state tree, its storage _ Root points to another tree which is also in MPT form, and data of state variables (state variables) involved in contract execution are stored. This tree of MPT form pointed to by the storage _ Root is a storage tree, i.e., the hash value of the Root node of the storage tree. Typically, this storage tree stores key-value pairs as well. A part of data stored on a path from the root node to the leaf node is connected to form a key, and a value is stored in the leaf node. As mentioned above, this storage tree may also be a tree in the form of an MPT, and typically also a 16-way tree, i.e. for a branch node there may be up to 16 child nodes, which may include extension nodes and/or leaf nodes. While for an extension node, there may typically be 1 child node, which may be a branch node. This storage tree may have a depth of up to 64 levels.

In an intelligent contract, for example, in the solidity high-level development language provided by etherhouses, state variables that can be defined include two types, 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 fragment of the code of an intelligent contract written in solid:

contract Demo {

int a;

int x;

mapping(address => int) public balanceA;

function myfunc() public {

a = 8;

x = 9;

balanceA [123] = 100;

}

wherein, the shaping variables a and x both belong to basic data types, and in the myfunc function, a is assigned to 8, and x is assigned to 9. In the map type data structure, the mapping of the external account address to the balance (balance a, different from balance in the external account and balance in the contract account) of one asset type, i.e., the mapping of address → balance a, is defined in the above code. In the myfunc function, for example, address 123 of the external account is initialized to correspond to balance a of 100.

In etherhouses and other blockchain systems, new digital assets may be created, for example, in smart contracts in accordance with the ERC20 standard, but may be otherwise customized. For example, balanceA as described above may be a digital asset created according to the ERC20 standard. Of course, in one intelligent contract, multiple asset types may be defined, such as balanceA, balanceB, balanceC, …. The map in this contract may give each external account the ability to hold and trade such newly created digital assets. As with the code example above, each external account may correspond to a balance A type asset, in general. Then, if there are 10000 external accounts in the state tree of the blockchain, each external account may correspond to holding/trading a balanceA type asset through the smart contract, i.e., there are 10000 mappings of "external account → balanceA".

It should be noted that the assets herein are broad and may be other than balance. For example, in the context of a blockchain electronic invoice, an asset may be defined as a collection of codes for the invoice, such as balanceP. Thus, in the "external account → balanceP" mapping, a set of codes for a set of invoices may be included in balanceP. New invoice codes may be added to this invoice code set.

The state variables of the basic data type and the map type can be stored in the storage tree in the form of key-value key value pairs. For the basic data type, key is the position of the state variable declaration in the contract (counting from 0). For map type, key = SHA3 (key in map, variable declaration position), that is, calculating hash value after piecing together the key in map and state variable declaration position into a string of a certain length (e.g., 64 bytes). value may store the actual value of the state variable.

As mentioned above, if there are 10000 external accounts in the state tree of the block chain, each external account may correspond to holding/trading a balanceA type asset through the smart contract, i.e., there are 10000 external accounts → a mapping. Specifically, under the contract account, the values of the maps may be stored in a storage tree. As described above, in particular, by means of key-value, in the storage tree. Similarly, the storage tree may be a tree in the form of an MPT, and is typically a 16-way tree, with up to 16 child nodes per level, and up to 64 levels deep. A part of data stored from the root node of the MPT to the leaf node may be connected as a key, and the information stored in the leaf node is a value corresponding to the key. Thus, a key-value pair is constructed.

When the number of external accounts in a blockchain reaches a certain amount, the depth of the state tree may approach or reach a depth of 64 levels. Similarly, the number of map-type state variables in a contract may reach the same amount, where the memory tree is also near or up to 64 levels deep. Furthermore, for an intelligent contract, there are not too many variables in the contract that are basic data types, and generally there are not more than 32. Thus, when the number of external accounts is large, the total number of state variables in the contract is substantially comparable to the external accounts, plus variables of the underlying data type in the contract.

Fig. 4 is a simplified version of a state tree diagram. There are several external accounts in the blockchain system, such as external account 1, external account 2, … numbered separately in fig. 4. In addition, there are several contract accounts in the blockchain system, such as separately numbered contract account 1, contract account 2, … in fig. 4. These external and contract accounts and their information content are organized, for example, in the form of an MPT tree, constituting a state tree. The state _ root in the block header stores the hash value of the root node of this MPT tree. In fig. 4, the form of the MPT tree is schematically represented by three nodes, namely node 1, node 2, and node 3, and specifically, the form may represent an extended node and a branch node in the MPT tree.

The external account may deploy intelligent contracts on the blockchain through transactions that create the contracts. In addition, the intelligent contract may also be a native contract, that is, the intelligent contract is fused in the code of the blockchain platform and compiled together with the code of the blockchain platform to complete deployment. Regardless of the form of the intelligent contract deployed, after the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code and the account storage are stored in the contract account. The account storage of the intelligent contract maintains the state of this contract. After the contract is created, the external account may invoke the created intelligent contract, or the external account may invoke the intelligent contract through the intelligent contract (or may invoke the intelligent contract through 1 or more intelligent contracts). The called intelligent contract writes the generated state variable into the account storage of the intelligent contract in the form of key-value, as shown in fig. 4. These key-values, which may be organized in the form of MPT trees, form a storage tree. In the storage tree, the key-value may include a state variable of a map type in addition to a state variable of a basic data type. Generally, no more than 32 basic type state variables in a contract, that is, no more than 32 key-values are included in a storage tree to correspond to the storage of the basic type state variables. In one contract, map-type state variables generally correspond to external accounts. In the case where there are N external accounts, there are typically N key-values corresponding to the storage of map-type state variables in a contract.

The number of map-type state variables in a contract account generally corresponds to an external account, and in addition, basic-type state variables are included in the contract account. 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 the MPT structure, each layer being 64 layers deep at maximum. For a large number of contract operations in a blockchain system, the state variables of the contracts are involved. Thus, in the existing account architecture, although the external account and the contract account are established, the hot spot of the operation will be concentrated on the state variables in the contract account, and the operation on the external account is rare. This forms a single account hotspot. The single account hot spot causes a large load pressure of the contract account storage, which limits and affects the performance of the blockchain system.

The embodiment of the specification provides a storage structure of a block chain state tree. As shown in fig. 5.

The state _ root in the block header stores the hash value of the root node of the entire state tree. The tree structure may be, for example, the MPT shown in fig. 3, or may be of other organization types, and this point is similarly described below by taking the MPT as an example. Overall, the state tree may adopt a three-level tree structure. For example, for the MPT, each layer in fig. 5 schematically represents the form of the MPT tree with three nodes, namely node 1, node 2, and node 3, and specifically may represent an extended node and a branch node in the MPT tree. The leaf nodes of the first layer of tree structure can be used for storing the root hash value stored by the external account, and can also be used for storing some basic information of the contract account. There may be several external accounts and contract accounts, respectively. In a typical blockchain application scenario, 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 first-layer leaf node can be calculated based on the hash value stored by the intelligent contract related to the external account, the balance and the nonces of the external account. Wherein, the nonces and balance of the external accounts in fig. 5 can be the same as those in fig. 3 and 4. The second layer is a contract storage tree (schema storage tree). Specifically, the root node of the second-level tree structure is a stored hash value of the smart contract related to the external account. Similarly, the second layer may schematically represent the form of the MPT tree by one node, which is three nodes including node 1, node 2, and node 3, and specifically may represent the extended nodes and branch nodes in the MPT tree. The second tier of storage may include one or more intelligent contracts, i.e., there may be multiple leaf nodes. Each leaf node of the second layer may be configured to store a stored root hash value of an intelligent contract involved under the external account, which may be calculated based on the contract id (contract id), storage _ root involved in the external account. The third level is a memory tree. Specifically, the root node of the third-layer tree structure is a root hash value of a state variable in the intelligent contract related to the external account. Similarly, the third layer may schematically represent the form of the MPT tree by one node, which is three nodes including node 1, node 2, and node 3, and specifically may represent the extended nodes and branch nodes in the MPT tree. Each leaf node of the third level may be used to store a value for a state variable in the contract. In the three-layer tree structure, a part of data stored on a path from the root node to the leaf node of each tree may be connected to form a key, and a value may be stored in the leaf node. Thus, with such a storage model, the key-value of the state variable in each smart contract to which the external account relates can be stored under each external account.

The embodiment of the specification provides a storage structure of a block chain state tree. As shown in fig. 6.

In an actual blockchain business system, in many cases one blockchain is dedicated to providing one service. A service may be generally implemented using an intelligent contract. In this case, there is only one intelligent contract in the blockchain system. The second level of the structure of fig. 5 may be simplified when there is only one intelligent contract, and the second level of the structure of fig. 5 is not required, as shown in fig. 6. The root hash of each external account in the leaf nodes of the first-layer tree structure can be calculated based on the hash value stored by the intelligent contract related to the external account, the balance and the nonces of the external account. Wherein, the nonces and balance of the external accounts in fig. 6 may be the same as those in fig. 3 and 4. The second level is a memory tree. Specifically, the root node of the second-level tree structure is a root hash value of a state variable in the intelligent contract related to the external account. Similarly, the second layer may schematically represent the form of the MPT tree by one node, which is three nodes including node 1, node 2, and node 3, and specifically may represent the extended nodes and branch nodes in the MPT tree. Each leaf node of the second level may be used to store a value for a state variable in the contract. In the two-layer tree structure, a part of data stored on a path from the root node to the leaf node of each tree is connected to form a key, and a value can be stored in the leaf node. Thus, with such a storage model, the key-value of the state variable in each smart contract to which the external account relates can be stored under each external account.

All state variables involved in the contract are included in the contract account storage of fig. 3, 4. By providing the storage structure of the block chain state tree according to the embodiments of fig. 5 and fig. 6 described above, all state variables in the contract related to the original contract account storage are actually decomposed into the storage of the corresponding external account according to the associated external account. For example, the original contract account store includes all map-type state variables 1, 2, 3, … 10000 involved in the contract, where 1-1000 is associated with external account 1, 1001-2000 is associated with external account 2, and so on. Thus, the state variables 1-1000 of the map type associated with external account 1 are decomposed into the storage of external account 1; the map-type state variable 1001 associated with external account 2 and 2000 are decomposed into the storage of external account 2, and so on.

In addition to map data structures, the mapping of external account addresses to an asset type may be defined by other data structures, and is not limited herein.

In the simplest case, as shown in FIG. 7, an intelligent contract is created in a blockchain system, and a new type of asset is defined in the intelligent contract. Furthermore, a contract may be created in which only one new type of asset is defined, or in which case only one of the new types of assets is enabled (while the other new type of asset is not enabled or initialized). In this case, since each external account corresponds to the balance of one type of asset, the balance of the type of asset may not need to be organized in a tree form, and may be stored by one key-value. In this map type, key = SHA3 (key in map, variable declaration position), that is, the hash value is calculated by piecing together the key in map and the state variable declaration position into a string of a certain length (for example, 64 bytes). value may store the actual value of the variable, i.e., the balance of the balance a type of asset. Thus, the store _ root of the external account may be the hash value of this key-value. There may be one such map data per external account. For example, store _ 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 intelligent contract in the blockchain system and only one new type of asset is defined or enabled in the intelligent contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a hash value of key-value related to an external account and comprising the new type of assets in each leaf node through a tree structure; and the second layer stores mapping relation defined by the map and comprising the external account and the new type assets in a key-value form.

As previously mentioned, in a smart contract, multiple asset types may be defined, such as balanceA, balanceB, balanceC, balanceD, …. Thus, each external account may have a balance corresponding to a type of asset, balanceA, balanceB, balanceC, balanceD, …, respectively. In this case, since each external account corresponds to balances of plural types of assets, the balances of the plural types of assets may be organized in a tree form. As shown in fig. 6, in the second-level storage tree, a form of a tree is schematically represented by three nodes of node 1, node 2, and node 3. This tree is for example an MPT tree, and node 1, node 2, node 3 may schematically represent extended nodes, branch nodes in the MPT tree. In this map type, key = SHA3 (key in map, variable declaration position), that is, the hash value is calculated by piecing together the key in map and the state variable declaration position into a string of a certain length (for example, 64 bytes). value may store the actual value of the state variable, i.e. the balance of assets of type balanceA, balanceB, balanceC, balanceD, …. As in fig. 4, the leaf nodes of the storage tree for external account 1 have balances for assets of types balanceA, balanceB, balanceC, balanceD, …, respectively. Thus, the storage _ root of the external account may be the root hash value after the form of a key-value composition tree of assets of type balanceA, balanceB, balanceC, balanceD, …. There may be one such map data per external account. For example, store _ root of external account 1 points to a tree structure of a set of key-values in its map type; the store _ root of external account 2 points to a tree structure of a set of key-values in its map type. And so on. Thus, for the case where there is only one intelligent contract in the blockchain system and at least two new types of assets are defined and enabled in the intelligent contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a root hash value of key-value related to an external account and including all the assets of the new type in each leaf node through a tree structure; and the second layer stores mapping relation defined by the map and comprising the external account number and the key-value form of the new type of assets in each leaf node through a tree structure.

In a blockchain system, multiple intelligent contracts may be created. For example, a blockchain system has a plurality of intelligent contracts created therein, and these intelligent contracts can be organized by a tree structure, as shown in fig. 8, i.e., the second layer in the diagram stores a tree for the contracts. Each of the majority of smart contracts may define one or more new types of assets. Each smart contract has a different state. For example, in fig. 8, two contracts are shown connected by a tree structure to external account 1. Each contract can be calculated to obtain 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 the schema _ storage _ root in the figure. For the case where each of the two created contracts defines only one new type of asset, or only one of them is enabled (and the other new type of asset is not enabled or initialized) in the case where a plurality of new types of assets are defined, each contract corresponds to the balance of one type of asset, so the balance of the type of asset may not need to be organized in a tree form, and may be stored by one key-value, like the second layer structure in fig. 7. Thus, the storage _ root of an intelligent contract may be the hash value of this key-value. And so on. In summary, for the case that there are at least two intelligent contracts in the blockchain system, and only one new type of asset is defined or enabled in the intelligent contracts, the storage of the state tree in the blockchain includes three layers; the first layer stores a root hash value related to an external account and including all intelligent contract related information in each leaf node through a tree structure; the second layer stores a hash value of key-value related to an external account and comprising the new type of assets related to the intelligent contract in each leaf node through a tree structure; and the third layer stores mapping relation defined by the map and comprising the external account number and the property in a key-value form.

In a blockchain system, multiple intelligent contracts may be created, and multiple asset types may be defined in each contract, such as balanceA, balanceB, balanceC, balanceD, …. This situation can be seen in fig. 5. Connecting external accounts 1 through a tree structure, two contracts are shown. I.e., the second level contract memory tree. In practice, the second tier of storage may comprise a plurality of intelligent contracts, i.e. there may be a plurality of leaf nodes. Each contract can be calculated to obtain 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 the schema _ storage _ root in the figure. Each leaf node of the second layer may be configured to store a stored root hash value of an intelligent contract involved under the external account, which may be calculated based on a hash value including a contract id (contract id) and a storage involved in the external account. The third level is a memory tree. Specifically, the root node of the third-layer tree structure is a root hash value of a state variable in the intelligent contract related to the external account. Similarly, the third layer may schematically represent the form of the MPT tree by using three nodes, namely node 1, node 2, and node 3, and specifically may represent the extended nodes and branch nodes in the MPT tree. Each leaf node of the third level may be used to store a value for a state variable in the contract. In the three-layer tree structure, a part of data stored on a path from the root node to the leaf node of each tree may be connected to form a key, and a value may be stored in the leaf node. Thus, with such a storage model, the key-value of the state variable in each smart contract to which the external account relates can be stored under each external account. In summary, for the case that there are at least two intelligent contracts in the blockchain system, and only at least two new types of assets are defined or enabled in the intelligent contracts, the storage of the state tree in the blockchain includes three layers; the first layer stores a root hash value related to an external account and including all intelligent contract related information in each leaf node through a tree structure; the second layer stores a root hash value of key-value related to an external account and including all the new type assets related to the intelligent contract in each leaf node through a tree structure; and the third layer stores mapping relation defined by the map and comprising the external account number and the new type of assets in the form of key-value in each leaf node through a tree structure.

In the above examples of fig. 5-8, the first layer may also store the transaction count for the external account in each leaf node via a tree structure.

In the above examples of fig. 5 and 8, the second layer further stores the number of the associated intelligent contract in each leaf node through a tree structure. Furthermore, the second layer may also store not the number of the associated intelligent contract in each leaf node, but the root node of the second layer stores the address of the concerned intelligent contract or a mapping value based on the address of the concerned intelligent contract in a path to each leaf node of the second layer through the tree structure of the second layer.

In conjunction with the above, the present application provides a method for storing states in a blockchain system, as shown in fig. 9. The blockchain system comprises at least two shards, and nodes in different shards store the states of different external account sets.

The blockchain system may, for example, include 4 slices as shown in fig. 10. Each slice may include 4 nodes. The 4 nodes in each shard may all be full-size nodes. This is merely an illustrative example, and different slices may have different numbers of nodes, which is not limited herein. The nodes contained in each segment can meet the Byzantine Fault Tolerance (BFT) requirement. The byzantine fault tolerance requirement can be understood that byzantine nodes can exist in the fragments, and the byzantine behaviors are not presented outside the fragment pairs. Generally, some Byzantine Fault-tolerant 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-tolerant algorithm pbft (practical Byzantine Fault tolerance).

Nodes in different shards may store the state of different sets of external accounts. As in the example of fig. 10, node A, B, C, D in slice 1, the state of each node stores the state of external accounts 1, 5, 9, 13. (e.g., a set of external accounts designated by positive integers starting at 1 and every 4). Means for storing the status of external accounts 1, 5, 9, 13 in node A, B, C, D, as in any of the examples of fig. 5-8.

In connection with the simplest implementation of fig. 7, for example, an intelligent contract is created in the blockchain system, and a new type of asset is defined in the intelligent contract. Only one new type of asset may be defined in the created contract, or only one of them may be enabled if 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 type of asset may not need to be organized in a tree form, and may be stored by one key-value. In this map type, key = SHA3 (key in map, variable declaration position), that is, the hash value is calculated by piecing together the key in map and the variable declaration position into a string of a certain length (for example, 64 bytes). value may store the actual value of the variable, i.e., the balance of the balance a type of asset. Thus, the store _ root of the external account may be the hash value of this key-value. There may be one such map data per external account. For example, store _ 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 intelligent contract in the blockchain system and only one new type of asset is defined or enabled in the intelligent contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a hash value of key-value related to an external account and comprising the new type of assets in each leaf node through a tree structure; and the second layer stores mapping relation defined by the map and comprising the external account and the new type assets in a key-value form.

For example, in connection with the implementation of fig. 6, in one intelligent contract, multiple asset types may be defined, such as balanceA, balanceB, balanceC, balanceD, …. Thus, each external account may have a balance corresponding to a type of asset, balanceA, balanceB, balanceC, balanceD, …, respectively. In this case, since each external account corresponds to balances of plural types of assets, the balances of the plural types of assets may be organized in a tree form. Thus, for the case where there is only one intelligent contract in the blockchain system and at least two new types of assets are defined and enabled in the intelligent contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a root hash value of key-value related to an external account and including all the assets of the new type in each leaf node through a tree structure; and the second layer stores mapping relation defined by the map and comprising the external account number and the key-value form of the new type of assets in each leaf node through a tree structure.

For example, in connection with the implementation in fig. 8, a plurality of intelligent contracts are created in a blockchain system, and these intelligent contracts may be organized by a tree structure, i.e., the second layer in fig. 8 is a contract storage tree. Each contract corresponds to the balance of one type of asset for the case where only one new type of asset is defined for each of the two created contracts, or where only one of the new types of assets is enabled (while the other new type of asset is not enabled or initialized) for the case where multiple new types of assets are defined. Thus, for the case where there are at least two intelligent contracts in the blockchain system and only one new type of asset is defined or enabled in the intelligent contracts, the storage of the state tree in the blockchain includes three levels; the first layer stores a root hash value related to an external account and including all intelligent contract related information in each leaf node through a tree structure; the second layer stores a hash value of key-value related to an external account and comprising the new type of assets related to the intelligent contract in each leaf node through a tree structure; and the third layer stores mapping relation defined by the map and comprising the external account number and the property in a key-value form.

For example in connection with the implementation in FIG. 5, a blockchain system may create multiple intelligent contracts, and multiple asset types may be defined in each contract. Thus, for the case where there are at least two intelligent contracts in the blockchain system and only at least two new types of assets are defined or enabled in the intelligent contracts, the storage of the state tree in the blockchain includes three levels; the first layer stores a root hash value related to an external account and including all intelligent contract related information in each leaf node through a tree structure; the second layer stores a root hash value of key-value related to an external account and including all the new type assets related to the intelligent contract in each leaf node through a tree structure; and the third layer stores mapping relation defined by the map and comprising the external account number and the new type of assets in the form of key-value in each leaf node through a tree structure.

Nodes in different shards may store the state of different sets of external accounts. In addition to node E, F, G, H in slice 2, as in the example of slice 1 in fig. 10, the state of each node stores the state of external accounts 2, 6, 10, 14. (e.g., a set of external accounts designated by positive integers starting at 2 and spaced by 4); node I, J in slice 3,K. L, the state of each node stores the state of external accounts 3, 7, 11, 15. (e.g., a set of external accounts designated by positive integers starting at an interval of 4 from 3); node M, N, O, P in slice 4, the state of each node storing the state of external accounts 4, 8, 12, 16. (e.g., a set of external accounts designated by positive integers starting at 4 and spaced by 4). The manner of storing the corresponding external account by the nodes in the segments 2, 3, and 4 is similar to that described above, and is not described herein again. It should be noted that, different external account sets corresponding to different shards may have a certain intersection between the sets. For example, two external account sets { external account set }corresponding to slice 2 and slice 3 respectively_{Slicing 2}And { external Account set }_{Slice 3}There may be no external accounts of intersection between the two sets, or there may be external accounts of a certain intersection.

In the above example of fig. 10, the external accounts corresponding to different shards are an account set formed at the same interval from different initial values according to the unique identifier of the external account, which is a modular manner. In addition to this modulo approach, a piecewise approach may also be employed. For example, the external accounts in the blockchain system include 4000 accounts with IDs of 1-4000. The node in segment 1 may be assigned to store the status of external accounts 1-1000, the node in segment 2 stores the status of external account 1001-2000, the node in segment 3 stores the status of external account 2001-3000, and the node in segment 4 stores the status of external account 3001-4000. The above-mentioned modulo or segmentation may be ID division for the external account, or address division for the external account, or hash value division for the ID or address, etc., and may be divided according to a certain unique identifier of the account as a whole, which is not limited herein.

Thus, when a new registered user is generated in the blockchain system, the state of the external account of the user can be determined according to the hash value of the user, such as ID, address, ID/address, including the state (such as the aforementioned map-type key-value) related to the external account generated by executing the contract, and is relatively fixedly stored in the node storage of a certain slice.

If the number of segments is increased or decreased only in a modular or segmented manner, the mapping relationship between most account storages and segments may be changed, which is obviously uneconomical, and the long adjustment may result in a large number of operations related to the account storages failing to hit the correct segments and nodes.

In view of this, in addition to the above modulo and segmentation manner, the state storage of the account may be allocated to the corresponding segment in a consistent hash manner. In this way, the shard can be mapped to the value space [0, 2^32-1], and the mapping rule can be the identification of the shard and the like, for example, the mapping is performed by some hash algorithm. Also, the account may be mapped to the value space [0, 2^32-1], and the mapping rule may be the address, the registry, and the like of the account, for example, by the same hash algorithm. For a certain account, if a node satisfying hash (shard) < = hash (account), the node with the largest hash (shard) is selected to store the account. If there is no shard satisfying the above condition, the shard with the smallest hash (shard) is selected to store the account, as illustrated in fig. 11. It can be simply explained that the corresponding state is allocated to the segment corresponding to the first segment hash value in the clockwise direction of the ring in fig. 11 according to the hash value of the account. And the distribution is carried out by adopting a consistent hash mode, when the fragments are changed, only a small part of the storage related to the external account is changed, so that the storage of most fragments is not adjusted, and the problem of low hit is reduced.

In addition, the state storage of the account can be distributed to the corresponding segments according to the account registration place. The registration place may include the connected blockchain link points when the user registers the account, for example, when the user registers the account, the user connects to the blockchain node E through the client, and the node E belongs to the segment 2, then the account generated by registration corresponds to the segment 2. In other implementation scenarios, the registration place may also be a geographic location where the user is registered for the account. For example, when a user registers an account, the IP address of the user is located in a special administrative district in hong kong, and one segment in the blockchain system corresponds to the blockchain service of the relevant special administrative district, for example, segment 4, then the account registered by the user corresponds to segment 4. Therefore, in another embodiment provided by this specification, the predetermined fragmentation policy may include: and determining the segment to which the account belongs according to the registration place of the account. The registration place comprises a segment to which a client is connected to a block chain node when the user registers the account, or the geographic position of the IP when the user registers the account, or the registration place filled/selected by the user. For the latter, according to the geographic location where the IP of the user is located when the user registers the account or the home location filled/selected by the user, the state storage of the account may be allocated to the shards in the same/similar geographic location, or allocated to the shards designated by the system.

By determining the fragmentation strategy of the fragments to which the account belongs according to the registration place, some services with regionality can be centralized in the same fragment for processing, and the states of transaction relating to addition, deletion and modification are controlled in a single fragment as much as possible, so that the cross-fragment distributed transaction can be effectively reduced, the cross-fragment message interaction and transaction processing can be reduced, and the system throughput and performance can be further improved. For example, in a blockchain scenario of a blockchain electronic invoice, if different segments are divided corresponding to chinese provinces, a user account in the guangdong is registered in the segment in the guangdong, and a user account in the zhejiang is registered in the segment in the zhejiang. In practical applications, users in the Guangdong often consume in the Guangdong, and transactions with other users in the Guangdong are more likely to occur; while users in Zhejiang are typically consuming at Zhejiang, there is a greater likelihood of a transaction with other users in Zhejiang. Most users in the Guangdong province are invoiced in the Guangdong province, and similarly, most users in Zhejiang province are invoiced in the Zhejiang province. Therefore, the partition of the account is determined based on the registration place of the account of the user, cross-partition transaction can be greatly reduced, and the complexity of the blockchain system is reduced.

In addition, in another embodiment, the application also provides a section to which the state storage of the account is configured according to the business relationship. In a blockchain cross-border remittance service, for example, cross-border transfer transactions are effected via intelligent contracts and the down-link assets are anchored to the up-link issued assets. The accounts of different banks are accessed through the client, and the transaction parties with transfer accounts may be different. According to the frequency and the proportion of business transactions, the state storage of the account with large relevance can be distributed to the same sub-slice. For example, in the block chain cross-border remittance service, most of the account a accessed to the bank 1 through the client transfers between the account b accessed to the bank 2 through the client, that is, the account a and the account b have a relatively large association, so that the state storage related to the account a and the account b generated by invoking the intelligent contract can be allocated to the same segment. Of course, in the above mentioned different allocation manners, the account status of the sharded storage may be dynamically adjusted according to the service relationship.

In addition, as previously described, the blockchain fragmentation mechanism provided by embodiments of the present specification also supports cross-fragmentation transactions, such as through an intermediate node or blockchain backbone that provides a reliable message transport mechanism.

Of course, in addition to some of the above-mentioned cross-account transactions of money transfers and electronic invoices, there are some single-account transactions, such as deposit transactions, in the blockchain system. The initiating account of such single account transactions, the state store that invokes the intelligent contract generation, is focused on the initiating account itself, and generally does not involve other accounts. Because cross-fragmentation transaction does not exist, when the state storage scheme is applied, the throughput can be more efficiently and simply improved, the block chain performance is improved, and the problem of storage bottleneck is easily solved.

As shown in fig. 9, the state storage method provided in the present application specifically includes:

s91: the block chain link points belonging to the segment execute the transaction of the calling contract, and generate the state related to the block chain external account to be stored.

Transactions in the blockchain may support the creation and invocation of intelligent contracts. For the transaction of creating the contract, the block link point may receive the transaction sent by the client and containing the creation of the intelligent contract, and the deployment of the intelligent contract is completed. The transaction that created the smart contract may be propagated to other blockchain nodes (or to most other blockchain nodes) through the P2P network. Each block link point that receives the transaction will typically verify and agree on the transaction. For example, for a primary consensus algorithm, such as a Practical Byzantine Fault Tolerance (PBFT), a primary node in a block chain consensus network may initiate consensus. After consensus is achieved, the blockchain nexus in the blockchain network may perform this transaction locally. In particular, a block link point may execute this transaction to create a contract via a local virtual machine (e.g., an etherhouse virtual machine EVM) and generate a corresponding contract instance. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain. The storage of the contract account on the blockchain may include a codehash and a deployed contract code (typically a bytecode of the contract code). The value of the codehash is the hash value of the deployed contract code. This contract account typically has a specific address.

In addition, the intelligent contract can also be a native contract compiled together with the blockchain code, and the deployment of the intelligent contract is completed.

A new asset type may be defined in the smart contract, such as balanceA in the aforementioned program code fragment. Of course, in one intelligent contract, multiple asset types may be defined, such as balanceA, balanceB, balanceC, …. As previously mentioned, state variables may also be defined in the smart contracts. For example, in the solid advanced development language provided by etherhouses, state variables that can be defined include two types, one is a state variable of a basic data type, and the other is a state variable of a mapping (map or mapping) type. Each external account may be given the ability to hold and trade such newly created digital assets through map-type state variables. As with the code example above, each external account may correspond to a balance A type asset, in general. Then, if there are 10000 external accounts in the state tree of the blockchain, each external account may correspond to holding/trading a balanceA type asset through the smart contract, i.e., there are 10000 mappings of "external account → balanceA". Similarly, for assets that include a balanceB type, there may be 10000 mappings of "external account → balanceB". And so on. As previously mentioned, the mapping of external account addresses to an asset type may be defined by other data structures than map data structures, and is not limited herein. The following illustrates a data structure in the form of a map.

After this contract is successfully created, subsequent external accounts may invoke this contract. The intelligent contracts may be executed independently at each node in the blockchain network in the manner specified in the contract code, and the executed transactions, the generated states, and the receipt of the transactions may be saved on the blockchain. Invoking the contract may generally be in the form of initiating a transaction. The from field of the transaction is the address of the account from which the intelligent contract was initiated, the to field may represent the address of the intelligent contract being invoked, and the data field of the transaction may include the method and incoming parameters that invoked the intelligent contract. By invoking the 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. Thus, the value in the map changes. The changed value needs to be stored on the blockchain. Thus, the contract status includes the status of the corresponding blockchain external account number.

As previously described, the contract state to be stored includes a mapping of external accounts to assets defined in the contract. In particular, the contract may define such a mapping relationship via a map data structure or other data structure. Taking the data structure definition of map as an example, the mapping relationship between the external account and the asset is generally defined in the map. If a new asset is defined in the smart contract, such as a balanceA asset, a mapping relationship between the external account and the balanceA type asset can be defined by map. Furthermore, a way of defining similar data structures can be provided by adaptation in the compiler, the virtual machine, such as:

schema {

uint256 balanceP;

bool owner_flag;

};

the code example described above may also define a mapping of external accounts to assets. Specifically, the agent 256 represents an asset type defined as balance P, an unsigned integer, 256 bits in length. The boolean variable is denoted boolean and corresponds to the identifier of the external account, owner _ flag. Thus, defining the mapping relationship between the external account and the asset is also realized in this way. Of course, adaptation of the compiler and virtual machine is required to support such defined ways in the contract.

The client may initiate a transaction to invoke the contract to the blockchain system. In the blockchain system, the transaction of the calling contract can be received by the main chain, and the transaction is routed to the sub-sheet storing the external account. In the transaction that invokes the contract, the state that typically involves the associated external account changes after execution. The changed state of the external account includes the state of the related external account related in the contract, for example, 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 segment. The backbone may serve the role of receiving the transaction and routing the transaction. The routing transaction may be routed to a segment storing the external account, for example, based on the external account involved in the transaction invoking the contract that has changed state. Specifically, the main chain routes the transaction into the sub-sheets storing the external accounts according to strategies such as modulus, segmentation, registration places and the like adopted by the blockchain system.

In turn, the blockchain link points attributed in a segment may execute transactions that invoke contracts and generate state to be stored in association with the blockchain external account.

Further, similar to S91, the chunk link points attributed in a shard may also be transactions that execute to create contracts. During execution of a transaction to create a contract, a state associated with an account external to the blockchain may also be generated to be stored, such as initializing a state associated with no account external. The following description mainly takes the execution of the transaction for invoking the contract as an example, and the execution of the transaction for creating the contract is similar to this, and is not described in detail again. Similarly for the transaction that creates a contract, it may be that the transaction that creates a contract is received by the aforementioned backbone and routed to the slice that stores the external account.

S93: and storing the state related to the blockchain external account to be stored into a state storage of the corresponding blockchain external account.

As shown in fig. 5, 6, 7, 8, the map type state variable in storage may be stored in the form of key-value. In a specific example, for the map type, key = SHA3 (key in the map, variable declaration position), that is, the hash value is calculated after the key in the map and the variable declaration position are pieced together into a character string of a certain length (for example, 64 bytes). value may store the actual value of the variable.

In the simplest case, as shown in FIG. 7, an intelligent contract is created in a blockchain system, and a new type of asset is defined in the intelligent contract. Furthermore, a contract may be created in which only one new type of asset is defined, or in which case only one of the new types of assets is enabled (while the other new type of asset is not enabled or initialized). In this case, since each external account corresponds to the balance of one type of asset, the balance of the type of asset may not need to be organized in a tree form, and may be stored by one key-value. In this map type, key = SHA3 (key in map, variable declaration position), that is, the hash value is calculated by piecing together the key in map and the variable declaration position into a string of a certain length (for example, 64 bytes). value may store the actual value of the variable, i.e., the balance of the balance a type of asset. Thus, the store _ root of the external account may be the hash value of this key-value. There may be one such map data per external account. For example, store _ 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 intelligent contract in the blockchain system and only one new type of asset is defined or enabled in the intelligent contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a hash value of key-value related to an external account and comprising the new type of assets in each leaf node through a tree structure; and the second layer stores mapping relation defined by the map and comprising the external account and the new type assets in a key-value form.

As previously mentioned, in a smart contract, multiple asset types may be defined, such as balanceA, balanceB, balanceC, balanceD, …. Thus, each external account may have a balance corresponding to a type of asset, balanceA, balanceB, balanceC, balanceD, …, respectively. In this case, since each external account corresponds to balances of plural types of assets, the balances of the plural types of assets may be organized in a tree form. As shown in fig. 6, in the second-level storage tree, a form of a tree is schematically represented by three nodes of node 1, node 2, and node 3. This tree is for example an MPT tree, and node 1, node 2, node 3 may schematically represent extended nodes, branch nodes in the MPT tree. In this map type, key = SHA3 (key in map, variable declaration position), that is, the hash value is calculated by piecing together the key in map and the variable declaration position into a string of a certain length (for example, 64 bytes). value may store the actual value of the variable, i.e. the balance of assets of type balanceA, balanceB, balanceC, balanceD, …. As in fig. 6, the leaf nodes of the storage tree for external account 1 have balances for assets of types balanceA, balanceB, balanceC, balanceD, …, respectively. Thus, the storage _ root of the external account may be the root hash value after the form of a key-value composition tree of assets of type balanceA, balanceB, balanceC, balanceD, …. There may be one such map data per external account. For example, store _ root of external account 1 points to a tree structure of a set of key-values in its map type; the store _ root of external account 2 points to a tree structure of a set of key-values in its map type. And so on. Thus, for the case where there is only one intelligent contract in the blockchain system and at least two new types of assets are defined and enabled in the intelligent contract, the storage of the state tree in the blockchain includes two layers; the first layer stores a root hash value of key-value related to an external account and including all the assets of the new type in each leaf node through a tree structure; and the second layer stores mapping relation defined by the map and comprising the external account number and the key-value form of the new type of assets in each leaf node through a tree structure.

As mentioned above, the state variables that can be defined in the intelligent contract include two types, 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 map type state variables described above are associated with each external account. Thus, for each external account, this map-type state variable is a local-type state variable. In addition, the underlying data types defined in the smart contract may be associated with each external account, not just with one. Thus, the state variables of the primitive data type belong to state variables of the global type.

Additionally, as previously described, a contract account may appear after the intelligent contract is created. The contract account may also be associated with each external account, not just one. For example, in a smart contract for betting, transfers of external account a and external account B under the next day weather conditions are agreed. If the next day is a sunny day, external account a transfers an asset (e.g., 50 dollars) to external account B, and if the next day is not a sunny day, external account B transfers an asset (e.g., 50 dollars) to external account a. When the external account a and the external account B call the intelligent contract, an asset (for example, 50 yuan) needs to be transferred to the contract account. Thus, the state variables in the contract account are also of a global type.

The foregoing illustrates the storage of local type state variables by way of FIGS. 5-8. The storage of the global type state variables is explained below.

The first way is to set, in the contract account, the storage of the state variables of the basic data types in the intelligent contract and the state variables of 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 store of the contract account. Fig. 12 is an example of the explanation based on fig. 5. The state _ root in the block header stores the hash value of the root node of the entire state tree. Leaf nodes of the first level tree structure may be used to store root hash values for external account storage and contract account storage. There may be several external accounts and contract accounts, respectively. The root hash of the account information of each contract account in the first-layer leaf node may be calculated based on the stored root hash values including the nonce, balance, codehash of the contract account and the intelligent contract to which the contract account relates. The stored root hash value of the smart contract is shown as store _ root of contract account 2 in fig. 12. Similarly, the second layer may schematically represent the form of the MPT tree by one node, three nodes being node 1, node 2, and node 3. Each leaf node of the second level may be used to store a global type of state variable involved under the contract account. As mentioned above, the state variable related to the contract account may be a basic data type, or may be a state variable in the contract account. Specifically, the root node of the tree structure in the layer is the root hash value of the state variable of the global type in the intelligent contract related to the contract account. Similarly, the layer may schematically represent the form of the MPT tree by one node, which is three nodes including node 1, node 2, and node 3, and specifically may represent the extended node and the branch node in the MPT tree. Each leaf node of the third level may be used to store a value for a state variable in the contract. In the tree structure, a part of data stored on a path from the root node to the leaf node of each tree is connected to form a key, and a value can be stored in the leaf node. Thus, through such a storage model, the key-value of the global type of state variable that the contract account refers to may be stored.

In this way, for a transaction of executing a call contract at a block link point, a state related to the block link contract account to be stored is generated, for example, a state variable of a basic data type in the contract and a state variable of a contract account are generated, and the state related to the block link contract account to be stored may be stored in a state storage of the corresponding block link 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 may be stored in the state storage of the corresponding block link contract account. And storing the key-value mapping relation of the global state variable related to the block link contract account in the state storage of the block link contract account through a tree structure, wherein the details are similar to those described above and are not repeated.

In the second way, in the contract account, the storage store related to the contract state may not be set, but a global state store independent of the external account store and the contract account store may be set. In this way, the state to be stored in relation to the blockchain contract account may be stored in a global state store that is independent of the external account store and the contract account store, i.e., the state variables of the underlying data types in the contract to be stored and the state variables of the contract account may be stored in a global state store that is independent of the external account store and the contract account store. Specifically, in the global state storage, a key-value mapping relationship of the state related to the block chain contract account may be stored in a tree structure, that is, state variables of basic data types in the contract to be stored and 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.

In addition, there may be a third way to store the state variables of the contract account to be stored into the state storage of the corresponding blockchain contract account, and store the state variables of the basic data type into a global state storage independent of the external account storage and the contract account storage. Specifically, the key-value mapping relationship of the state variable of the block chain contract account may be stored in the state storage of the contract account by a tree structure, and the key-value mapping relationship of the state variable of the basic data type may be stored in the global state storage by a tree structure.

The tree structure may be a 16-way tree. Generally, the global state in an intelligent contract does not exceed 32 state variables. With a 16-pronged tree, a two-level tree structure may be employed. Then 16 x 16=256 leaf nodes, much larger than 32, may be included in the second level tree structure, and thus the number of global states that may be included in a general intelligent contract may be satisfied.

Note that, in this specification, the concept of a logical node is emphasized with reference to a block link point. That is, one physical node may also be logically divided into a plurality of logical nodes. Of course, the block link points in this specification may also be applied to the case of physical nodes.

Through the embodiment of the application, the blockchain system at least comprises two shards, nodes in different shards store states of different external account sets, the states to be stored and related to the blockchain external accounts are stored in the state storage of the corresponding blockchain external accounts, the state of each external account stores the state related to the corresponding external account, and then different shards in the blockchain system store the states of different external account sets. Therefore, the problem of single account hot spots is avoided, and meanwhile, the load pressure of state storage borne by each fragment is relatively low, so that the performance of the whole block chain system can be improved. Moreover, after the state of each external account is stored in a scattered manner, the state quantity of one external account is relatively small, and the complete block chain state is not stored, so that the bottleneck problem of the storage capacity can be solved. Meanwhile, the mode of the application does not concentrate the states of all the external accounts in the state storage of the contract account like in fig. 3, so that the depth of the tree structure of each external account can be greatly reduced, the time for searching and updating the external accounts is further shortened, and the read-write efficiency of block chain storage is improved.

For the global state, even if all the global states are stored in the state storage of the contract account in the first manner, the requirement of 32 global states can be generally met, that is, the requirement of storage can be met by adopting an attribute structure with two layers of depth, so that the depth of the tree can be greatly reduced. The depth of the tree can also be greatly reduced by using the second or third manner described above.

As shown in fig. 10, an embodiment of the present application further provides a blockchain system, where the blockchain system includes at least two shards, and nodes in different shards are used to store states of different external account sets; and the number of the first and second electrodes,

the state related to the external account of the block chain generated by executing the transaction of the calling contract by the block chain link points belonging to the fragments is stored in the state storage of the corresponding external account of the block chain.

The status associated with the blockchain external account may include:

a mapping of external accounts to assets defined in the contract.

The mapping of the external account to the asset defined in the contract may include:

mapping of external accounts to assets defined by the map data structure.

The mapping of the external account to the asset defined by the map data structure may be stored by key-value.

For the case where there is only one intelligent contract in the blockchain system and only one new type of asset is defined or enabled in the intelligent contract, the storage of the state tree in the blockchain may include two layers;

the first layer stores a hash value of key-value related to an external account and comprising the new type of assets in each leaf node through a tree structure;

the second layer stores a defined mapping relationship comprising the external account and the key-value of the new type of asset.

For the case where there is only one intelligent contract in the blockchain system and at least two new types of assets are defined and enabled in the intelligent contract, the storage of the state tree in the blockchain may include two layers;

the first layer stores a root hash value of key-value related to an external account and including all the assets of the new type in each leaf node through a tree structure;

the second layer stores a defined mapping relation including key-value of the external account and one kind of the new type assets in each leaf node through a tree structure.

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

the first layer stores a root hash value related to an external account and including all intelligent contract related information in each leaf node through a tree structure;

the second layer stores a hash value of key-value related to an external account and comprising the new type of assets related to the intelligent contract in each leaf node through a tree structure;

the third layer stores a defined key-value mapping comprising the external account and the asset.

For the case where there are at least two intelligent contracts in the blockchain system, and at least two new types of assets are defined or enabled in the intelligent contracts, the storage of the state tree in the blockchain may include three levels;

the second layer stores a root hash value of key-value related to an external account and including all the new type assets related to the intelligent contract in each leaf node through a tree structure;

the third layer stores a defined mapping relation comprising the external account and the key-value of the new type of assets in each leaf node through a tree structure.

The first layer may also store a transaction count for the external account in each leaf node through a tree structure.

The second layer may also store the number of the associated intelligent contract in each leaf node through a tree structure.

The state associated with the blockchain contract account resulting from the transaction of the blockchain link point execution invocation contract may be stored in a state store of the corresponding blockchain contract account.

The state associated with a blockchain contract account may include state variables of the underlying data types in the contract and state variables of the contract account; the key-value mapping relation of the block chain contract account related state can be stored in the state storage of the contract account through a tree structure.

State associated with the blockchain contract account resulting from the transaction of the blockchain link point execution invoking contract may be stored in a global state store that is separate from the external account store and the contract account store; the global state storage can store the key-value mapping relationship of the state related to the block chain contract account through a tree structure.

The state variables of the contract account may be stored in a state store of the corresponding blockchain contract account; the key-value mapping relation of the state variables of the block chain contract account can be stored in the state storage of the contract account through a tree structure;

state variables of the underlying data type may be stored in a global state store that is independent of the external account store and the contract account store; the global state storage can store the key-value mapping relation of the state variables of the basic data types through a tree structure.

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

the external accounts corresponding to different segments form an external account set at the same interval from different initial values according to the unique identification of the external accounts; or the like, or, alternatively,

the external accounts corresponding to different segments form an external account set after being segmented according to the unique identification of the external accounts; or the like, or, alternatively,

based on the unique identifier of the external account, the state of the external account is stored and distributed to the corresponding fragments in a consistent hash mode; or the like, or, alternatively,

and determining the segment to which the account belongs according to the registration place of the account.

The registering may include:

when a user registers an account, the user is connected to the segment to which the block chain node belongs through a client; or the like, or, alternatively,

the geographic location of the IP of the user when the user registers the account; or the like, or, alternatively,

the user fills in/selects the home.

According to the geographic position of the IP of the user when the user registers the account or the attribution filled/selected by the user, the state storage of the account can be distributed to the fragments of the same/similar geographic position, and the state storage of the account can also be distributed to the fragments appointed by the system.

and storing the affiliated segments according to the state of the account configured according to the business relationship.

The blockchain system may also include a main chain to receive a transaction of the invoking contract and route the transaction into a tile storing the external account.

The receiving by the main chain of the transaction of the invoking contract may be based on the external account involved in the transaction of the invoking contract, the transaction being routed to the slice storing the external account.

As shown in fig. 13, an embodiment of the present application further provides a blockchain node belonging to a segment in a blockchain system, including:

the storage unit 132 is configured to store a state of an external account set, where the corresponding external account set is different from external account sets in blockchain nodes in other segments;

an execution unit 131 for executing the state storage method as described above.

As shown in fig. 14, an embodiment of the present application further provides a blockchain node, where the blockchain node belongs to one segment in the blockchain system, and is used to store the state of the external account set, and the corresponding external account set is different from the external account sets in the blockchain nodes in other segments;

the block link point includes:

a processor 141;

a memory 142 in which a program is stored, wherein the state storage method as described before is performed when the processor executes the program.

The above state fragmentation scheme is a solution provided in the present application. In addition to this, other state fragmentation schemes are possible. Regardless of the state sharding scheme, as long as nodes in different shards store the state of different external account sets, the problem of determining the world state of all accounts of different shards is involved.

For example, an account in segment 1 may have a transaction with another account in segment 2. Specifically, for example, an account in segment 1 is transferred to another account in segment 2, or an account in segment 1 initiates a transaction for invoking a contract, and the invoked contract, when executed, involves an operation on an account in segment 2. In the case of invoking a contract, according to the mapping relationship between the external account and the asset defined in the contract, a specific example is, for example, that a certain account in segment 1 initiates repayment of a new asset type, and the accounts under the asset type (including the external account and the contract account) each have a certain balance (balance). External account 1, such as shard1 in fig. 15, transfers a certain amount of assets of that type to the contract account, which in turn transfers them from the contract account to external account 6, such as shard 2 in fig. 15, according to the conditions in the contract.

It should be apparent that the above examples relate to cross-sharded transactions. The application provides a main chain-based cross-fragment transaction method which can be realized in a main chain-based block chain fragment system. The main-chain based blockchain sharding system of the present application, for example, as shown in fig. 15, has a main chain in addition to several shards. The main chain comprises a plurality of block chain nodes, such as Q1, Q2, Q3 and Q4 in the figure. The main chain is connected with each fragment. As mentioned above, although the connection between the slices is illustrated by the connection line in the figure, it is also possible that the slices are not all intercommunicated, or that each slice is not communicated with other slices. In the last case, i.e. the individual fragments may be connected to each other and only to the main chain. Here, the communication between the fragments may be that one node in one fragment is communicated with any node in another fragment, or that one node in one fragment is communicated with one or part of nodes in another fragment. Similarly, the fragment is communicated with the main chain, a node in the fragment may be communicated with any node in the main chain or one or part of nodes in the main chain of a node in the fragment, or a node in the main chain may be communicated with any node in the fragment or one or part of nodes in the fragment.

Nodes in different segments may store the state of different external account sets, including the state associated with external accounts resulting from executing a transaction to create and/or invoke a contract as described above in the corresponding embodiments of fig. 5-12, as well as the state of external accounts resulting from ordinary transfer transactions. The status slicing schemes of the embodiments corresponding to fig. 5 to 12 of the present application are not used, but the status related to the external account generated by the transaction for executing the creation and/or calling of the contract is stored in the status storage of the contract account, and there may be a case where nodes in different slices store a set of different contract account statuses, or a case where nodes in different slices store statuses of different contract account sets, which is also applicable to the schemes of the present application to be mentioned below. For example, there is a contract in the blockchain system, and the contract accounts corresponding to the contract have different states, such as state a, state b, state c, and state d, which may be simpler to store the state set { a } of the node in the segment 1, the state set { b } of the node in the segment 2, the state set { c } of the node in the segment 3, and the state set { d } of the node in the segment 4. For example, if 4 contracts exist in the whole blockchain system, which are respectively contract 1, contract 2, contract 3, and contract 4, the nodes in the different shards may store the state set { state of contract account 1} in shard1, the nodes in shard 2 store the state set { state of contract account 2 }, the nodes in shard 3 store the state set { state of contract account 3}, and the nodes in shard 4 store the state set { state of contract account 4 }, which may be simpler. Further, it will be appreciated that a mixture of the two may also be possible for there to be multiple contracts, each having multiple states. The various situations described above, collectively, may be referred to as different shards storing different sets of states.

For storing different state sets for different shards, a main chain is introduced in the scheme proposed by the application, and an exemplary architecture is shown in fig. 16. As in fig. 16, the cadence at which slice 1 and slice 2 generate new tiles may not be consistent; of course, lockstep may also be used, and is described herein primarily in terms of lockstep inconsistencies. It should be noted that, here, for simplicity, only the case of 2 slices is shown, and the case of more than 2 slices is similar to this and is not described again. Also, only the case where the partitions 101 and 102 are sequentially generated in slice 1, and the cases where the partitions 201 and 202 are sequentially generated in slice 2 are shown. In fact, it will be understood that the transaction request is processed in the segment, and after the consensus is achieved through the consensus mechanism, the transaction is executed and the block is generated. The block numbers of the generated blocks are generally consecutive and the Hash value of the previous block is locked in the block header of the next block by a field, for example, by the Prev Hash field as in fig. 3. The hash value for a block is typically the result of a hash calculation of all the fields in the block header. In the Block header of the Block generated by fragmentation, as shown in fig. 3, the Block header may generally include a Block number (Block Num), a Timestamp (Timestamp), a Hash value (Prev Hash) of the previous Block, and a Transaction Root Hash (Transaction _ Root), a status Root Hash (State _ Root), and may further include a Receipt Root Hash (request _ Root) and a random number (Nonce). In the block of the tile generated by the tile, as shown in fig. 3, the original transaction list may be generally included, and these transactions may be organized by a tree structure, such as the aforementioned MPT tree, or a merkle tree, etc. And storing the hash value of the Root of the original Transaction list organized by the tree structure in the Transaction _ Root of the block header. As mentioned before, the state _ root can be a hash value of the root of the MPT tree composed of the states of all accounts in the current blockchain, i.e. a state tree in the form of an MPT pointing to the state _ root. For the case where the Recript _ Root is included in the chunk header, the Recript _ Root can be the hash value of the Root of the MPT tree or the Merkle composed of all receipts in the current chunk.

For example, as shown in fig. 16, tile 1 sequentially generates chunks 101 and 102, and tile 2 sequentially generates chunks 201 and 202. Slice 1 has a corresponding state set in block 101 and a corresponding state set in block 102. Slice 2 has a corresponding state set at block 201 and a corresponding state set at block 202.

In an embodiment of the present application, a system for blockchain fragmentation including a backbone is provided. Several nodes may be included in the backbone. Generally, nodes in the main chain have higher credibility, and the main chain formed by the nodes meets the Byzantine fault tolerance requirement. The backbone may have its own clock, as shown in FIG. 16, which is the time axis that expresses the backbone clock. According to the time axis of the main chain, the generation time of slice 2 chunk 201 is between the generation time of main chain chunk 10001 and the generation time of main chain chunk 10002, the generation time of slice 1 chunk 101 is between the generation time of main chain chunk 10002 and the generation time of main chain chunk 10003, the generation time of slice 2 chunk 202 is between the generation time of main chain chunk 10003 and the generation time of main chain chunk 10004, and the generation time of slice 1 chunk 102 is after the generation time of main chain chunk 10004. Generally, the frequency of generating blocks on the main chain is higher than the frequency of generating blocks in each slice, and at least not lower than the frequency of generating blocks in each slice.

For example, node a in segment 1 receives a transaction initiated by the client before the time, such as a normal transfer transaction, which is transferred from external account 1 in segment 1 to external account 6 in segment 2. Upon receiving the transaction, e.g., node a in segment 1 broadcasts the transaction to other nodes in segment 1. A short time later, a certain number of transactions including the transaction may be packaged and a consensus proposal initiated by the master node (e.g., node C) in segment 1. These packed transactions are performed by the various nodes in segment 1 after consensus has passed in segment 1. Since these transactions include cross-shard transactions (also referred to as cross-shard transactions), only deduction of a certain balance in the external account 1 can be performed in shard 1. The remaining operations performed in segment 2 to add a certain balance to the external account 6 need to be performed by the nodes in segment 2. Then, this process needs to forward part of the operation of the transaction received in segment 1 to segment 2 for segment 2 to execute.

As another example, the node B in segment 1 receives a transaction initiated by the client before the time, such as a transaction for invoking a contract, where the transaction is initiated by an external account 1 in segment 1 to invoke a certain intelligent contract. After receiving the transaction, the node B in segment 1 broadcasts the transaction to other nodes in segment 1. After a period of time, a certain number of transactions including the transaction may be packaged and a consensus proposal initiated by the master node (e.g., node C) in segment 1. After consensus in segment 1, the packaged transaction is performed by each node in segment 1. Intelligent contracts in these transactions may involve cross-sharded transaction transactions, around the execution. As in the previous example, an account in slice 1 initiates a redemption of an amount of a new asset type, and the accounts under the asset type (including external accounts and contract accounts) each have a balance (balance). External account 1, such as shard1 in fig. 15, transfers a certain amount of assets of that type to the contract account, which in turn transfers them from the contract account to external account 6, such as shard 2 in fig. 15, according to the conditions in the contract. In the segment 1, an operation of deducting a certain new asset type balance from the external account 1 can be executed; operations to add some new asset type balance to the external account 6 may be performed in segment 2 and need to be performed by a node in segment 2. Then, this process needs to forward part of the operation of the transaction received in segment 1 to segment 2 for segment 2 to execute.

The present application may be implemented by a tile slicing system based on a backbone. Since the nodes in the main chain have high confidence, operations related to other fragments (hereinafter referred to as target fragments) in the cross-fragment transaction received in one fragment (hereinafter referred to as source fragment) can be sent to the main chain and forwarded to the target fragment by the main chain. Specifically, fig. 17 shows a method for executing a cross-slice transaction in a blockchain system including slices in an embodiment of the present application, including:

s171: determining cross-fragment transaction in a source fragment block in the process of generating the source fragment block by a source fragment, and sending the cross-fragment transaction which needs to be executed by a target fragment in the cross-fragment transaction to a main chain.

The client may initiate a transaction request to a connected node in the source fragment. The transaction may be a transfer transaction, as described above, or may be a transaction to create/invoke a contract. The node in the source fragment that initiates the transaction by the client is received, and the transaction can be broadcast to other nodes in the source fragment or forwarded to the host node. Taking the PBFT consensus algorithm as an example, after a period of time, a certain number of transactions including the transaction may be packaged and a consensus proposal initiated by the master node in the source shard. It should be noted that, in the transaction packaged by the master node in the source segment, in addition to the cross-segment transaction, an intra-segment transaction may also be included.

For ordinary transfer transactions, the transaction structure is simple, and whether the transaction is a cross-piece transaction can be judged according to an initiator (indicated by a from field) and a receiver (indicated by a to field) of the transaction. Generally, for the aforementioned status fragmentation scheme, nodes in different fragments store statuses of different external account sets, and then in a client initiating a transaction request, an account logging in the client stores a corresponding account status in a connected source fragment. That is to say, generally, an external account stored in a segment may initiate a transaction in the segment through a client, and an account indicated by a from field in the transaction stores a corresponding external account status in the segment. Furthermore, the nodes in the segment can judge according to the to field in the transfer transaction, and if the account in the to field has no corresponding external account state in the segment, the transaction is cross-segment transaction. And in intra-segment transaction, the accounts marked by the from field and the to field have corresponding external account states in the segment.

For creating/invoking contract transactions, a client may initiate contract-related transaction requests to connected nodes in a source shard. Similarly, the account designated in the from field of the transaction stores the corresponding external account status in the slice, while the to field designates the address of the contract (call contract) or null (create contract). One or more target accounts may be involved in the contract code, possibly including an external account and/or an account of another contract. For the case where the target account is another contract account, it is common to invoke another contract through one contract, which may in turn involve some external account. More levels of contract invocation, and so on. Due to the complexity of contracts, it is often not possible to determine what other accounts are involved when executing the contract, except the initiator (indicated by the from field), such as in the case of complex conditional decisions in the contract and in the case of a contract invocation. In particular, it is likely that the one or more target accounts involved will only be determined at the time of contract execution. The aforementioned status fragmentation scheme executes a transaction of creating and/or invoking a contract attributed to a blockchain link point in a fragment, and stores a generated status to be stored in relation to the blockchain external account in a corresponding status storage of the blockchain external account, where the status in relation to the blockchain external account includes a mapping relationship between an external account and an asset defined in the contract, for example, a mapping relationship between an external account and an asset defined by a map data structure. As described above, there may also be a case where nodes in different segments store sets of different contract account statuses, or a case where nodes in different segments store statuses of different contract account sets, which is not described again. In this way, the source shard determines whether the transaction is a cross-shard transaction during execution of the contract according to whether the account stored on the shard other than the source shard is involved, for example, each node in the source shard may determine whether the transaction is a cross-shard transaction during execution of the transaction after consensus is reached according to whether the account stored on the shard other than the source shard is involved.

For ordinary transfer transactions, the source segment can screen out cross-segment transfer transactions according to the target account indicated by the to field. And if the target external account of the common transfer transaction marked by the to field does not belong to the external account set corresponding to the sub-slice, the common transfer transaction is judged to be the cross-slice transfer transaction. For cross-piece transaction, because only the from field in the external account set corresponding to the source piece indicates the external account in the source piece, for ordinary transfer transaction, the balance operation can be performed on the external account in the source piece indicated by the from field in the piece only by executing transaction. And the operation of balance of the target external account in other segments marked by the to field in the ordinary transfer transaction cannot be operated in the source segment. Thus, the source fragment may send transactions to the target fragment that need to be executed by the target fragment. For example, in one source sharded block generated by the source shard, 1000 transactions are packaged, wherein 500 common transfer transactions are provided, and the source shard may determine that 200 cross-sharded transactions are included in the 500 common transfer transactions. The source segment may keep locally executing the transactions that need to be executed locally in the 200 cross-segment transactions, that is, locally executing the operation of the balance of the involved external account, and send the transactions that need to be executed by the target segment in the 200 cross-segment transactions to the target segment.

For a transaction that creates/invokes a contract, as previously described, due to the complexity of the contract, it is often impossible to determine from the contract code itself whether the transaction involves a cross-sharded transaction, particularly for a transaction that invokes a contract. A node in a source shard may determine whether the transaction is a cross-shard transaction during execution of a contract after agreement based on whether an account stored on a shard other than the shard is involved. Similarly, for a cross-sharded transaction, such as a cross-sharded transaction involving a call contract transaction, a source shard may execute a transaction for an account involved in the shard during execution of the transaction, i.e., change the state of the account involved in the shard, including the state of an external account and/or a contract account. And for the change of the account state corresponding to the target fragment, the source fragment may send the transaction that needs to be executed by the target fragment in the cross-fragment transaction to the target fragment.

For the source fragment, since the operation of the target fragment involved in the cross-fragment transactions needs to be sent to the target fragment for execution, before it is not determined that the target fragment has been executed, even if the node in the source fragment completes consensus in the current fragment and executes the cross-fragment transactions in the source fragment block, the changed state of the relevant account in the current fragment generated in the cross-fragment transactions in the source fragment block is not submitted to the database, that is, the persistent storage is not performed. When the source fragment receives confirmation such as response or commit indication of the transaction which needs to be executed by the target fragment in the cross-fragment transaction (which depends on the design of the interaction protocol) completed by the target fragment, the node in the source fragment locally commits the transaction executed by the source fragment in the cross-fragment transaction, and completes the persistent storage.

As mentioned above, a certain number of transactions including the transaction are packaged by the master node in the source segment, and a consensus proposal is initiated, and after reaching the consensus, each node in the source segment may execute the transaction locally, but does not submit the execution result to the underlying database. When each node in the source fragment executes the transaction locally after the consensus is achieved, the state of the related account in the fragment changes, including the change of the state of the external account and/or the contract account. The source shard may generate a sharded chunk according to these changed states. After the states of the related external account and contract account are changed, each node in the source segment may calculate a hash value of a Root node of the new State tree (i.e., the State Root hash, State _ Root) according to an organization structure of the merkle tree or the MPT tree. The resulting State _ Root can be filled in the block header of the block. Taking the MPT tree as an example, as mentioned above, the state _ root is a hash value of a root of the MPT tree composed of states of all accounts in the current block, that is, a state tree pointing to the state _ root in the form of an MPT. The Root node of the MPT tree may be an extension node or a branch node, and the hash value of the Root node is stored in the State Root. Although the current block may involve a change in the State of a portion of the accounts in the account State corresponding to the current tile, i.e., only a portion of the accounts corresponding to the tile are involved in the transaction of the current tile listing, a State _ Root including the State of the entire accounts corresponding to the current tile may be generated by referencing the State that was not changed in the previous tile. For example, as shown in fig. 10, the accounts involved in slice 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}, while the status of only those external accounts 1, 9, 21, 33 involved in the transaction packaged by this block changes, 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 is not changed, according to the organization form of the MPT tree, the changed state of the external account can be added into the state of the block, and refers to the most recent account status in the previous block that has not changed, thereby obtaining the hash value of the root node of the MPT tree.

In the process of generating the source fragmentation block, for a Transaction _ Root, transactions packed by the master node may be organized according to a tree structure of a merkle tree or an MPT tree, and a hash value of the tree Root is the Transaction _ Root. This Transaction Root may be filled in the block header of the source tiled block. For the case that the block header of the source partition includes the script _ Root, the script _ Root is generally similar to the Transaction _ Root described above, and after the Transaction is executed locally, the generated Receipt can be generated into the script _ Root according to the organization form of the merkle tree or the MPT tree and filled into the block header of the source partition. As mentioned above, the block header typically further includes a block number, a timestamp, a random number, a hash of the previous block, and the like.

The source fragment transmits the transaction needing to be executed by the target fragment in the cross-fragment transaction to the target fragment, and the transaction can be transmitted through the main chain. Specifically, the source fragmentation block in the source fragmentation is agreed and then sent to the node in the main chain by the main node, or the source fragmentation block in the source fragmentation is agreed and then sent to the main node by one or more nodes. In one example, it may be that at least 2f +1 nodes of the at least 3f +1 nodes included in the source fragment that satisfy the byzantine fault tolerance send the same transaction to one or more nodes in the backbone that needs to be performed by the target fragment.

As mentioned above, the block body of the block generated by the fragmentation generally may include an original Transaction list, transactions in the original Transaction list are organized according to a tree structure of a merkle tree or an MPT tree, and a hash value of a tree Root is Transaction _ Root. In addition, the block body of the sharded chunk generated by the source shard may further include the transactions that the cross-shard transaction in the original transaction list needs to be executed by the target shard. As shown in fig. 18, in the shard chunk 201 and the shard chunk 202 generated by shard 2, in addition to the original transaction list, a cross-shard transaction list may also be included, where the cross-shard transaction list includes cross-shard transactions that need to be executed by the target shard in the cross-shard transaction. The cross-slice transaction list may generally be a subset of the original transaction list in the block. It should be noted that since there may be a cross-slice transaction of slice 2 with a different target slice, a cross-slice transaction list in a slice block generated by slice 2 may include a cross-slice transaction that needs to be executed by a plurality of different target slices. Accordingly, in the chunk header, a field, such as cross-slice transaction _ root, may be set for storing a hash value of a tree root of the chunk, wherein the cross-slice transactions are organized according to a tree structure of a merkle tree or an MPT tree. Through the cross-slice transaction _ root, the cross-slice transaction list in the chunk can be locked into the chunk header. Thus, the hash value of the sliced block may be a hash calculated according to each field in the block header, and these fields may include the cross-slice transaction _ root. The following block in the slice may lock the Hash value of the previous block through the Prev _ Hash field in the block header.

The source fragment may send the block header of the generated source fragment block to the main chain, in addition to sending the cross-fragment transaction to the main chain.

S173: in the process of generating the main chain block by the main chain, filling the received cross-slice transaction which needs to be executed by the target slice into the block body of the main chain block, and sending the cross-slice transaction which needs to be executed by the target slice to the corresponding target slice according to the identification of the target slice.

After receiving the cross-chip transaction sent by the source fragment, the node in the main chain can verify the cross-chip transaction first. For example, a hash value of a root node of a tree formed by the cross-slice transaction may be calculated according to a tree structure, and whether the currently received cross-slice transaction is repeated with a previously received cross-slice transaction may be determined according to the hash value. If the transaction is repeated, the cross-slice transaction sent this time can not be processed, otherwise, the processing is continued.

The main node in the main chain may collect the transactions sent by the source fragment, or the non-main nodes in the main chain may forward the transactions to the main node in the main chain after receiving the transactions sent by the source fragment, and the transactions may include a cross-fragment transaction list sent by the source fragment. As mentioned above, the cross-slice transaction list sent by each source slice may include cross-slice transactions that need to be executed by multiple different target slices. To illustrate by way of example in fig. 15, in a case that 4 shards are included, the main chain may receive cross-shard transactions from shard1 to shard 4, the cross-shard transaction from shard1 includes { the cross-shard transaction in shard1 requires the cross-shard transaction executed by shard 2, the cross-shard transaction in shard1 requires the cross-shard transaction executed by shard 3}, the cross-shard transaction from shard 2 includes { the cross-shard transaction in shard 2 requires the cross-shard transaction executed by shard1, the cross-shard transaction in shard 2 requires the cross-shard transaction executed by shard 3, the cross-shard transaction in shard 2 requires the cross-shard transaction executed by shard 4 }, the cross-shard transaction from shard 3 includes { the cross-shard transaction in shard 3 requires the cross-shard transaction executed by shard1, the cross-shard transaction in shard transaction from shard 4 includes { the cross-shard transaction executed by shard1, a cross-slice transaction in slice 4 requires a cross-slice transaction performed by slice 2 and a cross-slice transaction in slice 4 requires a cross-slice transaction performed by slice 3 }. As shown in the above example, in the cross-slice transaction, the identification of the target slice may be included, and the identification of the source slice may also be included.

The master node in the backbone may package a certain number of cross-slice transactions sent from each slice over a period of time and initiate consensus offers. In addition, the main node in the main chain can package other transactions besides the cross-slice transaction. After consensus is reached in the backbone, these packed transactions are performed by each node in the backbone, generating a backbone block. Nodes in the backbone perform these packed transactions and not cross-slice transactions among them. As described above, the account statuses corresponding to these cross-slice transactions are stored in the target slice, so the operations of the account statuses corresponding to these cross-slice transactions need to be performed by the target slice.

Each node in the main chain performs these packed transactions and generates a chunk, which may include populating the chunk of the main chain chunk with the cross-slice transactions that need to be performed by the target shard. Furthermore, each node in the main chain may organize the cross-slice transactions into a tree in the same tree structure, generate a hash value according to the root of the tree, and fill the hash value into the transaction root hash field of the block head of the main chain block. And adding fields such as a block number, a timestamp, a hash of the previous block and the like into the block head of the main chain block to generate the main chain block.

Executing the packaged transactions by each node in the main chain and generating a block, filling the cross-slice transaction needing to be executed by the target slice into the block body of the main chain block, specifically, according to the sequence of the cross-slice transaction needing to be executed by the target slice in the message of the consensus proposal initiated by the main node in the main chainThe cross-slice transactions performed by the target shard fill in the tile body of the master-chain chunk, as in the cross-slice transaction list shown in fig. 19. In addition, the cross-slice transactions may also be grouped according to the target sharding, and the grouped cross-slice transactions are filled into the block body of the main chain block. The grouped cross-chip transactions can be arranged in ascending order or descending order according to the grouping numbers and then filled into the block body of the main chain block. Furthermore, each node in the main chain may organize the cross-slice transactions into a tree in the same tree structure, generate a hash value according to the root of the tree, and fill the hash value into the Transaction _ root field of the block header of the main chain block. The grouped cross-slice transaction is, for example, the following structure:

cross-slice transactions that need to be performed by slice 1
	......
Cross-slice transactions that need to be performed by slice n

TABLE 1

As mentioned above with the example including 4 shards in fig. 15, the grouped cross-shard transaction may specifically include 4 groups according to the target shard:

cross-slice transactions that need to be performed by slice 1 (including from slices 2 and 4)
	Cross-slice transactions that need to be performed by slice 2 (including from slices 1, 3, 4)
Cross-slice transactions that need to be performed by slice 3 (including from slices 1, 2, 4)
	Cross-slice transactions that need to be performed by slice 4 (including from slices 2 and 3)

TABLE 2

And grouping the cross-slice transactions according to the target slicing, wherein the sequence of the cross-slice transactions in each group after grouping is preferably consistent with the time sequence of the cross-slice transactions, namely the cross-slice transactions are arranged according to the time sequence. Because the different sequence of the transaction will probably lead to different transaction results, the cross-slice transactions in each group after grouping are arranged according to the time sequence, which is beneficial to ensuring that after the cross-slice transactions are subsequently sent to the target fragments, the target fragments will not cause errors or abnormalities caused by inconsistent sequence when executing the cross-slice transactions.

A main chain block generated by the main chain, grouped cross-slice transactions are filled into a block body of the main chain block, a hash value is generated according to a Root node calculated by the cross-slice transactions according to a tree structure, and the generated hash value is filled into a Transaction _ Root in a block header, as shown in fig. 18. Similarly, the block generated on the main chain can also be locked by a Hash, for example, the previous block 10001 is stored in the Prev Hash of the block head of the block 10002 in the main chain, and so on. As shown in fig. 18, the Block header (Block nHeader) of the Block of the main chain may include fields such as a Block number (Block Num), a Timestamp (Timestamp), a Hash value (Prev Hash) of the previous Block, and a Transaction _ Root. The block body of the main-chain block (block nBody) may include the cross-slice transaction sent to the main chain by each slice before the main-chain block is generated, i.e. the operation performed by the target slice is needed. Preferably, the chunk body of the main chain chunk includes cross-chunk transactions that need to be executed by each target chunk, which are not packed in previously generated chunks by the main chain.

It should be noted that, if there is no cross-slice transaction executed by a certain fragment in the master node packaging transaction before the generation of the main-chain block generated in the main chain, the block body of the main-chain block may not include the cross-slice transaction that needs to be executed by the target fragment.

As mentioned above, the source slice may send the block header of the generated source slice block to the main chain in addition to sending the cross-slice transaction to the main chain. After the main chain receives the block head of the source fragmentation block sent by the source fragmentation and the cross-fragment transaction, the block head of the source fragmentation block can be verified. The verifying may include computing a hash value of the root node in a tree structure from the cross-slice transaction, and determining that the value is consistent with the cross-slice transaction _ root in the block header. If not, the verification is not passed, otherwise, the verification is passed. It may also be verified whether the block header of the source sliced block from this time is the same as the block header of the source sliced block from the previous time, which means that the block header is the same as the block header of the source sliced block from the previous time, and if so, the block header is repeated with the previous block from the source sliced 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 partitioned block sent this time is the Hash value of the source partitioned block of the previous block number, if so, the verification is passed, otherwise, the verification is not passed.

For the case that the source partition further sends the block header of the generated source partition block to the main chain, the main chain may also calculate the hash value of the source partition block according to the received block header of the source partition block in the process of generating the main chain block. Furthermore, the main chain may fill the hash value of the tile from each source tile into the tile body of the main chain tile, specifically, for example, from Shard1_ BlockHash to Shardn _ BlockHash in fig. 19. Further, the main chain may also fill the hash value of the root calculated by the hash of the partitioned partition blocks of each partition according to the tree structure into a partitioned partition block root (Shards _ BlockRoot) field of the block header of the main chain block, as shown in fig. 19. As previously mentioned, nodes in the backbone have a high degree of confidence. The node on the main chain locks the block hash of the partitioned block into the main chain block, so that the generated partitioned block can be prevented from rolling back by the partition. This is because, based on the property of the hash algorithm, the fragment header remains unchanged under the condition that different transactions cannot be forged by the fragment, thereby ensuring the security of the fragment transaction. Specifically, the safety of cross-segment transaction can be guaranteed, and the safety of intra-segment transaction can also be guaranteed. In FIG. 19, the contents of Table 1 are reduced to a cross-slice transaction list for simplicity.

Each node in the main chain block executes the transaction packaged in the main node consensus proposal, fills the received cross-slice transaction required to be executed by the target fragment into the block body of the main chain block and generates the main chain block, so that the cross-slice transaction required to be executed by the target fragment can be locked in the main chain block. And then, the cross-slice transaction needing to be executed by the target slice can be sent to the corresponding target slice according to the identifier of the target slice. As with the previous example, the identification of target shards that cross-shard transactions in the body of the backbone zone execute as needed may be sent separately.

Specifically, the cross-slice transaction list in the chunk of the main-chain chunk may be filled after grouping the cross-slice transactions according to the target shard. As in the example in table 1 above. In this way, the main chain can send the cross-slice transactions grouped in the main chain block body to the target slices corresponding to the groups according to the groups in the block body of the main chain block. As in the example in table 2 above, the main chain sends the cross-slice transaction (including those sent from slices 2 and 4) to be executed by slice 1 in the block of the main chain block to slice 1, sends the cross-slice transaction (including those sent from slices 1, 3 and 4) to be executed by slice 2 to slice 2, sends the cross-slice transaction (including those sent from slices 1, 2 and 4) to be executed by slice 3 to slice 3, and sends the cross-slice transaction (including those sent from slices 2 and 3) to be executed by slice 4 to slice 4.

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

S175: and in the process of generating a target fragmentation block by the target fragmentation, filling the received cross-fragment transaction sent by the main chain into a block body of the target fragmentation block, and executing the cross-fragment transaction.

After receiving the cross-slice transaction sent by the main chain, the node in the target slice can verify the cross-slice transaction first. For example, a hash value of a root node of a tree formed by the cross-slice transaction may be calculated according to a tree structure, and whether the currently received cross-slice transaction is repeated with a previously received cross-slice transaction may be determined according to the hash value. If the transaction is repeated, the cross-slice transaction sent this time can not be processed, otherwise, the processing is continued.

The target fragment may also receive a cross-slice transaction sent by the main chain and required to be executed by the target fragment as a fragment for executing the cross-slice transaction. Specifically, the master node in the target fragment may receive a cross-fragment transaction sent by the master node and needing to be executed by the target fragment; or the non-master node in the target fragment may receive the cross-fragment transactions that need to be executed by the target fragment and are sent from the master node in the target fragment, and then forward the cross-fragment transactions to the master node in the target fragment. In addition, the target segment may also receive a transaction request initiated by a client connected thereto. The transaction may be a transfer transaction, as described above, or may be a transaction to create/invoke a contract.

The master node in the target segment may package a certain number of transactions received over a period of time and initiate a consensus proposal. The packaged transaction may include the cross-slice transaction sent by the main chain, and may also include a transaction sent by a client received by the target slice. After consensus is achieved in the target segment, each node in the target segment executes the packaged transactions to generate a target segment block. In the process of generating a target sharded chunk by the target shard, the received cross-sharded transaction sent from the main shard may be filled into a chunk of the target sharded chunk, specifically, in an original transaction list. In addition, the target shard may also fill the block of the target shard block with the packaged transaction sent by the client, specifically, in the original transaction list. The transactions filled in the block body of the target partitioned block can be organized according to a tree structure, and the hash value generated according to the tree Root is the Transaction _ Root in the block head of the generated target partitioned block.

And executing transaction by each node in the target fragment, including executing the cross-fragment transaction. In addition, the transaction executed by each node in the target segment may also include a transaction sent by a client received by the target segment. Because the target segment stores the account state corresponding to the cross-segment transaction, executing the cross-segment transaction may cause the state of the corresponding account stored in the target segment to change. After each node in the target fragment executes the cross-fragment transaction, the state after the corresponding account change in the fragment caused by the execution of the cross-fragment transaction is not submitted to a bottom database, namely, the persistent storage is not performed. And when the target fragment receives the submission confirmation of the source fragment on the cross-fragment transaction, locally submitting the transaction executed by the target fragment in the cross-fragment transaction to complete the persistent storage.

If after each node in the target fragment executes the cross-fragment transaction, part or all of the cross-fragment transactions relate to accounts stored on other fragments except the current fragment, that is, the cross-fragment transactions are multiple cross-fragment transactions. For such multiple cross-slice transactions, on the one hand, the changed state of the corresponding account in the current slice caused by executing the cross-slice transaction is not committed to the underlying database, and on the other hand, cross-slice transactions that need to be executed by other slices and are further involved in the cross-slice transactions are sent to the main chain, that is, the processing in S171, S173 and S175 is repeatedly performed until new cross-slice transactions are no longer involved.

The simplest cross-slice transaction is a single cross-slice transaction, i.e., a cross-slice transaction from a source slice to a target slice is a transaction that is completed. The multiple cross-slice transaction can be the superposition of single cross-slice transactions. The following description mainly uses a single cross-slice transaction as an example. Those skilled in the art can easily extend to the case of multiple cross-slice transactions according to the example of single cross-slice transaction given herein, and these extended cases should obviously also fall within the scope of this patent.

In addition, for each node executing the transactions sent by the client received by the target segment, if the transactions are intra-segment transactions, that is, the related accounts all store corresponding states in the segment, then executing the transactions may also cause the states of the corresponding accounts stored in the segment to change.

Similarly, when each node in the target segment executes the transaction locally after reaching the consensus, the state of the relevant account in the segment may change, including the change of the state of the external account and/or the contract account. After the states of the related external account and contract account are changed, each node in the target segment may calculate a hash value of a Root node of the new State tree (i.e., the State Root hash, State _ Root) according to an organization structure of the merkle tree or the MPT tree. The obtained State _ Root can be filled in the block header of the generated target sliced block. In addition, fields such as a block number, a timestamp, and a hash of a previous block may be included in the block header, as shown in fig. 20.

As mentioned in S173, in addition to sending the cross-slice transaction to the corresponding target slice, the main chain may also send the block header of the main chain block to the target slice. After the target fragment receives the block head of the main chain block sent by the main chain and the cross-fragment transaction, the block head of the main chain block can be verified. The verification may include that the target fragment calculates a hash of the main chain block according to the block head of the main chain block sent from the main chain this time, and determines whether the hash is the same as the block head of the main chain block sent from the previous time based on the hash of the main chain block, if the hash is the same as the block head of the main chain block sent from the previous time, the target fragment and the main chain block are repeated, and the verification fails, otherwise, the target fragment and the main chain block pass the verification. In addition, 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 can be verified, if yes, the verification is passed, and if not, the verification is not passed.

For the situation that the main chain further sends the generated block header of the main chain block to the target fragment, the target fragment may calculate the hash value of the main chain block according to the received block header of the main chain block in the process of generating the target fragment block. Furthermore, the target fragment may also fill the hash value of the main chain block into a block header of a target fragment block generated by the target fragment. For the case that the generation speed of the main chain block is not lower than the generation speed of the tile block, the target tile may fill the Hash value of the latest main chain block into the block header of the target tile block generated by the target tile, as shown in the Hash fields of the latest main chain block in the blocks 101 and 102 in fig. 21. Whether or not it is up-to-date can be determined from the time stamp or block number in the block header of the main chain block. As described above, in the process of generating the target partition block, the target partition may further verify whether the hash value of the current main chain block is repeated with the previously sent main chain block. If the transaction is repeated, the sent block header and the corresponding cross-slice transaction are not processed any more, otherwise, the processing is continued. The target fragment fills the hash value of the latest main chain block into the block header of the target fragment block generated by the target fragment, and for the case that the generation speed of the main chain block is equal to the generation speed of the fragment block, the target fragment can identify the cross-slice transaction processed in the current target fragment as the cross-slice transaction in the block body of which main chain block, and for the case that the generation speed of the main chain block is higher than the generation speed of the fragment block, the target fragment can identify the cross-slice transaction processed in the current target fragment as the cross-slice transaction in the block body of which main chain block is ended.

Since the generation speed of the main-chain block is not lower than the generation speed of the tile block, in the case that the generation speed of the main-chain block is higher than the generation speed of the tile block, with the aid of the scheme shown in fig. 21, tile 1 has generated two main-chain blocks in the main chain between the generation tile block 101 and the target tile block 102, which are main-chain blocks 10003 and 10004, respectively. In addition to the backbone shown in fig. 21 sending the chunk header of backbone chunk 10004 and the cross-slice transaction in backbone chunk 10004 to slice 1, in fact, before that, if the cross-slice transaction that slice 1 needs to process is also contained in backbone chunk 10003, the backbone may also send the chunk header of backbone chunk 10003 and the cross-slice transaction that slice 1 needs to process in backbone chunk 10003 to slice 1. That is, normally, the main chain sends the block header of the main chain block and the corresponding cross-slice transaction to the slices involved in the cross-slice transaction according to the time sequence generated by the main chain block. In this way, the target partition may fill the hash value of the latest main chain block into the block header of the target partition block generated by the target partition, in the above example, the block hash of the main chain block 10004 is filled into the block header of the target partition block generated by the target partition. Meanwhile, slice 1 may include that cross-slice transactions that need to be processed by slice 1 are involved in main-chain chunks 10003 and 10004 in the original transaction list of the chunk body of generated slice chunk 102. In addition, the original transaction list of the sharded tile 102 may also include a transaction request initiated by a client connected to shard 1. The transaction request initiated by the client connected with segment 1 may be a transfer transaction or a transaction for creating/invoking a contract.

Another situation is as shown in fig. 22, for the case that the generated sharded chunk includes chunk headers of multiple main-chain chunks sent by the main chain and corresponding cross-slice transactions that need to be executed by the target shard, in addition to including cross-slice transactions that need to be processed by the shard in the multiple main-chain chunks in the original transaction list of the chunk of the sharded chunk (which may also include a packed transaction request initiated by a client connected to the shard), the chunk headers of the multiple main-chain chunks may also be included in the chunk headers of the sharded chunk, such as "hash of processed main-chain chunk m" and "hash value of processed main-chain chunk n" in the chunk header of chunk 101 of fig. 22 (here, only hash of 2 main-chain chunks is shown in fig. 22, and in fact, the number of chunk headers of main-chain chunks received before the current sharded chunk is generated may also be obviously greater than 2), and "hash of processed main-chain chunk p" and "processed main-chain chunk hash" of processed main-chain chunk p "in the chunk headers of chunk 102 Hash of block q "(here, only the hash of 2 main-chain blocks is shown in the case of fig. 22, and it is obvious that the number of block headers of the main-chain block received before the current tile is generated may be larger than 2). Obviously, in this case, the number of hashes of processed main-chain blocks contained in the block headers of the tile blocks may be variable.

As shown in fig. 23, for the case that the generated tile includes the chunk headers of the multiple main-chain chunks sent from the main chain and the corresponding cross-slice transactions that need to be executed by the target tile, besides including the cross-slice transactions in the multiple main-chain chunks that need to be processed by the tile in the original transaction list of the chunk of the tile (which may also include a packed client-initiated transaction request connected to the tile), the chunk hashes of the multiple main-chain chunks may also be included in the chunk of the tile, such as "hash of main-chain chunk m" and "hash of main-chain chunk n" in the chunk 101 of fig. 23 (where the hashes of the 2 main-chain chunks are shown only in the case of fig. 22, and in fact, the number of chunk headers of the main-chain chunks received before the current tile is generated may also be greater than 2), and the hashes of "main-chain chunk p" and "main-chain chunk q" in the chunk 102 (only according to the hash of "main-chain chunk p" and "main-chain chunk q" in the block p "here The situation in fig. 22 shows the hash of 2 main-chain blocks, and it is obvious that the number of block headers of the main-chain block received before the current tile is generated may be larger than 2). The hashes of the processed main chain blocks included in the block bodies of the partitioned blocks may be organized according to the tree structure as described above, and the Hash value of the root of the tree is filled into a field "main chain block root Hash" added in the block header, that is, the Hash value of the root calculated by the Hash of each main chain block according to the tree structure is filled into the main chain block root Hash of the block header of the partitioned block. For example, the "root Hash of the main chain block" in the block header of the block 101 is a Hash value of a root node of a tree structure organized by the "Hash of the main chain block m" and the "Hash of the main chain block n" in the block of the block 101; the "root Hash of the main chain block" in the block header of the block 102 is a Hash value of a root node of a tree structure organized by "Hash of the main chain block p" and "Hash of the main chain block q" in the block of the block 101. This has the advantage that the hash of an indefinite number of processed main chain blocks that may be included in a block body of a tiled block can be locked by a fixed field in the block header of said tiled block.

Furthermore, the transaction executed by the target fragment in the generated fragment block includes a cross-fragment transaction that needs to be executed by the target fragment and corresponds to the main chain block locked in the target fragment, and may further include a transaction request initiated by a client connected to the fragment. For example, the transaction that slice 1 performs in slice chunk 102 may include a cross-slice transaction in main chain chunks 10003 and 10004 that relates to slice 1, and a client-initiated transaction request that is packed in slice chunk 102 and connected to slice 1.

Preferably, in the target segment, when the transaction executed by the generated segment block includes a cross-segment transaction sent by the main chain and a transaction sent by a client connected to the target segment, the target segment executes the cross-segment transaction sent by the main chain first, and then executes the transaction sent by the client connected to the target segment. This is because, the cross-slice transaction sent by the main chain and requiring the target slice to execute actually occurs before, the transaction sent by the client connected to the target slice actually occurs after, and the order of executing the transaction is also a precondition for ensuring that the account status is correctly converted, so to avoid the failure of the transaction or the confusion of the status caused by the wrong conversion of the account status stored in the target slice, it is better to execute the transaction in the actual order of the transaction.

In addition, the target fragment executes the cross-fragment transaction, and the cross-fragment transaction received from the main chain is filled into the block body of the target fragment block in the process that the target fragment generates the target fragment block, and the cross-fragment transaction and the block body do not have a strict sequence, and can also be executed in parallel.

Preferably, in a case that a target partition locks a plurality of main chain blocks in a generated target partition block, the target partition executes a cross-partition transaction in the plurality of main chain blocks according to a generation order of the main chain blocks. For example, slice 1 locks backbone blocks 10003 and 10004 in generated slice block 102, and then slice 1 executes the cross-slice transactions in backbone blocks 10003 and 10004 in the order of backbone blocks 10003 and 10004 instead of executing the cross-slice transactions in backbone blocks 10003 and 10004 in the order of backbone blocks 10004 and 10003. This is because, the cross-slice transaction sent by the main chain and needing to be executed by the target slice, the cross-slice transaction in the block corresponding to the block head sent by the main chain first actually occurs before, the cross-slice transaction in the block corresponding to the block head sent by the main chain later actually occurs after, and the order of executing the transaction is also a precondition for ensuring that the account status is correctly converted, so to avoid the failure of the transaction or the confusion of the status caused by the incorrect conversion of the account status stored by the target slice, it is better to execute the transaction according to the actual order of the transaction.

In addition, the main chain may also send the generated time stamp of the main chain chunk to the slice, for example, by sending the time stamp of the main chain chunk indicated by the chunk header of the main chain chunk before, so that the slice may fill the time stamp of the latest main chain chunk into the timestamp of the slice chunk during the process of generating the slice chunk. For example, in S175, in the process of generating the tile block by the tile, the timestamp in the block header of the tile block is set to be the latest timestamp sent by the main chain. Similarly, in the process of generating the tile block in S171, the timestamp in the block header of the tile block is also 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 slice, so that the slice has the same clock system as the main chain. In the case that the fragment and the main chain have the same clock system, a client connected to the fragment may determine the initiation time of a transaction when initiating the transaction. Thus, when a client initiates a transaction, a timestamp of the initiation time can be attached to the initiated transaction. Then, as mentioned above, in the cross-slice transaction in which multiple source slices are sent to the main chain, the same target slice is involved, and the target slice preferably executes the cross-slice transactions according to the order of the transactions. In this way, the target shard is for the cross-shard transactions in the same main chain block, and no matter which source shard initiates the cross-shard transactions, the cross-shard transactions can be executed in sequence according to the timestamps of the cross-shard transactions (i.e. the timestamps of the cross-shard transactions initiated in the source shard) uniformly, so that the transactions can be processed correctly and the states generated after the transactions are executed are consistent.

The above embodiments of executing a cross-slice transaction provided by the present application provide an execution scheme for a cross-slice transaction in a sharded-containing blockchain system by forwarding a cross-slice transaction generated in a source shard to a target shard through a main chain in the sharded-containing blockchain system. The process ensures that cross-slice transactions generated in the slices can be reliably forwarded and executed under the witness of the main chain by constituting the authority of the main chain node, and the witness is stored on the source slice, the main chain and the target slice.

As mentioned above, even if the node in the source segment in S171 completes the consensus in the source segment and executes the cross-segment transactions in the source segment block, the changed state of the relevant account in the source segment block generated by the cross-segment transactions in the source segment block is not submitted to the database, i.e. the persistent storage is not performed. Similarly, after each node in the target segment in S175 executes the cross-segment transaction, the state of the corresponding account change in the segment caused by executing the cross-segment transaction is not submitted to the underlying database, that is, the persistent storage is not performed. In order to enable the changed state generated by the accounts involved on the source shard and the target shard to be submitted to the underlying database, the target shard needs to feed back the response generated by executing the cross-shard transaction to the source shard. After the foregoing process shown in fig. 17 is completed, the process may further include a flow shown in fig. 24:

s241: and generating a cross-slice transaction response according to the cross-slice transaction executed by the target fragment in the process of generating the target fragment block by the target fragment, and sending the cross-slice transaction response to the main chain.

In S175, the target shard executes the cross-shard transaction, and if the cross-shard transaction is successfully executed, cross-shard transaction responses may be generated and added to the chunk body of the shard chunk, for example, in the cross-shard transaction response list shown in fig. 25. Note that, for simplicity, the Hash of the main chain block of the process in fig. 23 is included in the main chain block Hash list in fig. 25. The main chain block Hash list of block 101 in fig. 25 actually includes the Hash of processed main chain block m, the Hash of processed main chain block n, … … in fig. 23, and the main chain block Hash list of block 102 in fig. 25 actually includes the Hash of processed main chain block p, the Hash of processed main chain block q, … … in fig. 23. The cross-slice transaction responses in the cross-slice transaction response list can be organized in a tree form. Furthermore, the target shard may add a cross-shard transaction response _ Root field in the generated chunk header for storing the hash of the Root of the tree organized by the cross-shard transaction responses in the chunk. In this way, the target shard can lock the response generated after the cross-shard transaction is executed in the chunk header. As shown in fig. 25, the block header of the sliced block generated by the target slice may include a block number, a timestamp, a hash of a previous block, a transaction Root hash, a main chain block Root hash, a cross-slice transaction response _ Root, and the like. Correspondingly, the hash value of the partitioned block is a hash value calculated from fields in the block header including the cross-slice transaction response _ Root field.

In turn, the target shard may return a cross-shard transaction response to the backbone. Moreover, the target shard may send a chunk header of the generated shard chunk to a master chain together with the cross-shard transaction response. In addition, the target segment may also process a transaction sent by the client and received by the target segment in the generated segment block. The transactions sent by these clients may also include cross-slice transactions. At this point, the target slice is also the source slice. Those skilled in the art will appreciate that in this case, the source fragmentation is performed repeatedly from S171. For simplicity herein, only the case of returning a cross-slice transaction response to the backbone as a target slice is discussed below.

In addition to sending the cross-slice transaction response to the main chain, the target slice may also send a block header of the generated target slice block to the main chain.

S243: in the process of generating the main chain block by the main chain, filling the received cross-chip transaction response into the block body of the main chain block; and the main chain sends the cross-fragment transaction response to the corresponding source fragment according to the identifier of the source fragment.

After receiving the cross-chip transaction response sent by the target fragment, the node in the main chain can verify the cross-chip transaction response. For example, a hash value of a root node of a tree formed by the cross-slice transaction response may be calculated according to a tree structure, and whether the currently received cross-slice transaction response is repeated with a previously received cross-slice transaction response is determined according to the hash value. If the transaction is repeated, the cross-slice transaction response sent this time can not be processed, otherwise, the processing is continued.

The master node in the main chain may collect the cross-chip transaction responses sent by the target slice, or the non-master node in the main chain receives the cross-chip transaction responses sent by the target slice and forwards the cross-chip transaction responses to the master node in the main chain. The master node in the backbone may package a certain number of cross-slice transaction responses sent from each slice over a period of time and initiate consensus offers. After consensus is reached in the backbone, these packed transactions are performed by each node in the backbone, generating a backbone block.

Executing the packed cross-slice transaction responses and generating the chunks by each node in the main chain may include filling the cross-slice transaction responses that need to be executed by the source shard into a chunk of the main chain chunk. Furthermore, each node in the main chain may organize the cross-chip Transaction responses into a tree, generate a hash value based on the Root of the tree, and then fill the hash value into the Transaction _ Root of the block header of the main chain block. For example, in the aforementioned case where the cross-slice Transaction list is included in the main-chain block, the cross-slice Transaction response list may be organized into a tree together with the cross-slice Transaction list in S173, and the hash value may be filled into the Transaction _ Root of the block header of the main-chain block after being generated based on the tree Root. Alternatively, the cross-slice 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 (e.g., a new field, such as cross-slice transaction response _ root, not shown in fig. 25). After fields such as a block number, a timestamp, and a hash of a previous block are added to the block header of the main chain block, the main chain block is generated.

In the process that the main chain generates the main chain block, the block hash of the target block sent by each target fragment can be calculated, and the target block hash is filled into the block body of the main chain block, such as a fragment block hash list. Further, the main chain may further fill a hash value of a root calculated by the sharded tile hash of each shard according to the tree structure into a Shards tile root (Shards _ BlockRoot) of the tile header of the main chain tile, for example, as shown in fig. 25.

Each node in the main chain executes the packaged transactions and generates a block, and fills the cross-slice transaction responses required to be executed by the source fragment into the block body of the main chain block, specifically, the cross-slice transaction responses required to be executed by the source fragment are filled into the block body of the main chain block according to the sequence of the cross-slice transaction responses required to be executed by the source fragment in the message of the consensus proposal initiated by the main node in the main chain. In addition, the cross-slice transaction responses may also be grouped according to the source fragment fed back as needed, and the grouped cross-slice transaction responses are filled into the block body of the main chain block. The grouped cross-chip transaction responses can be arranged in an ascending order or a descending order according to the grouping numbers and then filled in the block body of the main chain block. Furthermore, each node in the main chain may organize the cross-slice Transaction responses into a tree in the same tree structure, and obtain the Transaction _ root field of the block head filling the main chain block based on the hash value of the root of the tree (for example, organize the cross-slice Transaction response list and the cross-slice Transaction list in S173 together into a tree, and fill the hash value into the Transaction _ root of the block head of the main chain block after generating the hash value based on the root of the tree). Preferably, the block body of the main chain block comprises cross-chip transaction responses which need to be received by each source fragment and are packed in a block generated before the main chain. In addition, if there is no cross-slice transaction response received by a certain source slice during the master node packaging transaction before the main chain block generated in the main chain is generated, the block body of the main chain block may not include the cross-slice transaction response corresponding to the source slice.

As mentioned above, the target shard may send the chunk header of the generated target shard chunk to the master chain together with the cross-shard transaction response. After the main chain receives the block head of the target partitioned block sent by the target partition and the cross-slice transaction response, the block head of the target partitioned block can be verified. The verifying may include calculating a hash value of the root node according to the cross-slice transaction response in a tree structure, and determining that the value is consistent with the cross-slice transaction response _ root in the block header. Or, the root of the tree is obtained by calculating according to the cross-slice Transaction response and a hash value is obtained based on the tree root (which may also include the root of the tree formed by the cross-slice transactions, etc.), and the value is determined to be consistent with the Transaction _ root in the block header. If not, the verification is not passed, otherwise, the verification is passed. And if the block head of the target block from the current time of the target block is the same as the block head of the target block from the previous time, the same result indicates that the target block is repeated with the previous target block, and the verification is not passed, otherwise, the verification is passed. In addition, whether the Prev Hash in the block header of the target partitioned block sent this time is the Hash value of the target partitioned block of the previous block number can be verified, if so, the verification is passed, otherwise, the verification is not passed.

And then, the main chain can send the cross-slice transaction response which needs to be received by the source slice to the corresponding source slice according to the identifier of the source slice. Specifically, the cross-slice transaction response grouped in the chunk of the main-chain chunk may be sent to the corresponding source slice according to the identifier of the source slice. In this way, the identifiers of the source fragments received by the cross-fragment transaction response in the backbone region block according to the needs can be respectively sent. In addition to sending the cross-slice transaction response that needs to be executed by the source slice to the corresponding source slice according to the identifier of the source slice, the block header of the main-chain block may also be sent to the source slice, for example, to the source slice together with the cross-slice transaction response that needs to be processed by the corresponding source slice.

As mentioned above, the target slice may send the block header of the generated target slice block to the main chain in addition to sending the cross-slice transaction response to the main chain.

S245: and in the process of generating a source fragmentation block by the source fragmentation, filling the received cross-fragment transaction response sent by the main chain into the block body of the source fragmentation block.

After receiving the cross-slice transaction response sent by the main chain, the node in the source slice may verify the cross-slice transaction response first. For example, a hash value of a root node of a tree formed by the cross-slice transaction response may be calculated according to a tree structure, and whether the currently received cross-slice transaction response is repeated with a previously received cross-slice transaction response is determined according to the hash value. If the transaction is repeated, the cross-slice transaction response sent this time can not be processed, otherwise, the processing is continued.

The source shard may receive a cross-shard transaction response sent by the master shard that needs to be received by the source shard. In addition, the source slice may also receive a transaction request initiated by a client connected thereto. A master node in the source fragment may package a certain number of transactions received over a period of time and initiate a consensus proposal. The packaged transaction may include the cross-slice transaction response sent by the main chain, and may also include a transaction sent by a client received by the source slice. After consensus is reached in the source shard, the packed transactions are executed by each node in the source shard to generate a source shard block. The source tile here is different from the source tile in S171. Since the source fragment is continuously blocked, the fragment block generated by the source fragment is later than the source fragment block in S171. For example, if the block 201 is generated in S171 as shown in fig. 18, the block generated after the block 201 is here, for example, the block 202. In the process of generating a source sharded chunk by the source shard, the received cross-shard transaction response sent from the main shard may be filled into a chunk of the source sharded chunk, specifically, in a cross-shard transaction response list. In addition, the target shard may also fill the chunk of the source shard chunk with the packaged transaction sent by the client, specifically, in the original transaction list. The cross-slice transaction response list filled in the block of the source partitioned block may be organized according to a tree structure, and the hash value of the tree Root is the cross-slice transaction response _ Root in the block header of the generated target partitioned block. Such as shown in fig. 26.

As mentioned in S243, in addition to sending the cross-slice transaction response to the corresponding source slice, the main chain may also send the block header of the main chain block to the source slice. After the source fragment receives the block head of the main chain block sent by the main chain and the cross-fragment transaction response, the block head of the main chain block can be verified. The verification may include that the source fragment calculates a hash of the main chain block according to the block head of the main chain block sent from the main chain this time, and determines whether the hash is the same as the block head of the main chain block sent from the previous time based on the hash of the main chain block, if the hash is the same as the block head of the main chain block sent from the previous time, the source fragment and the main chain block are repeated, and the verification fails, otherwise, the verification passes. In addition, 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 can be verified, if yes, the verification is passed, and if not, the verification is not passed.

For the case that the main chain further sends the generated block header of the main chain block to the source fragment, the hash value of the main chain block can be calculated by the source fragment according to the received block header of the main chain block in the process of generating the source fragment block. Furthermore, the source fragment may also fill the hash value of the main-chain block into a block header of a source fragment block generated by the source fragment. For the case that the generation speed of the main chain block is not lower than the generation speed of the fragmentation block, the source fragmentation may fill the hash value of the latest main chain block into the block header of the source fragmentation block generated by the source fragmentation. Whether or not it is up-to-date can be determined from the time stamp or block number in the block header of the main chain block. As described above, in the process of generating a source shard block, the source shard may also verify whether the hash value of the current primary-chain block is repeated with the previously sent primary-chain block. If the transaction is repeated, the sent block header and the corresponding cross-slice transaction response can not be processed any more, otherwise, the processing is continued. The source fragment fills the hash value of the latest main chain block into the block header of the source fragment block generated by the source fragment, and for the case that the generation speed of the main chain block is equal to the generation speed of the fragment block, the cross-slice transaction response received in the current source fragment can be identified in the source fragment as the cross-slice transaction response in the block body of which main chain block, and for the case that the generation speed of the main chain block is higher than the generation speed of the fragment block, the cross-slice transaction response received in the current source fragment can be identified in the source fragment as the cross-slice transaction response in the block body of which main chain block the cross-slice transaction response is ended.

Since the generation speed of the main-chain chunk is not lower than the generation speed of the tile chunk, in the case that the generation speed of the main-chain chunk is higher than the generation speed of the tile chunk, with the aid of the scheme shown in fig. 26, two main-chain chunks, namely main-

chain chunks

10002 and 10003, have been generated in the main chain between the generation tile 201 and the target tile 202 in the tile 2. In addition to the backbone shown in fig. 26 sending the chunk header of backbone chunk 10003 and the cross-slice transaction response in backbone chunk 10003 to slice 2, in fact, before that, if the cross-slice transaction response that slice 2 needs to receive is also contained in backbone chunk 10002, the backbone may also send the chunk header of backbone chunk 10002 and the cross-slice transaction response in backbone chunk 10002 that needs to be received by slice 2 to slice 2. That is, normally, the main chain sends the block header of the main chain block and the corresponding cross-slice transaction response to the slice involved in the cross-slice transaction response according to the time sequence generated by the main chain block. In this way, the source slice may fill the hash value of the latest main-chain block into the block header of the source slice block generated by the source slice, in the above example, the block hash of the main-chain block 10003 is filled into the block header of the source slice block generated by the source slice (not shown in fig. 26). Meanwhile, slice 2 may include in the generated original transaction list of the chunk body of slice chunk 202 that the cross-slice transaction response that needs to be received by slice 2 is involved in main-

chain chunks

10002 and 10003. In addition, the original transaction list of the sliced block 202 may also include a transaction request initiated by a client connected to slice 2. The transaction request initiated by the client connected to segment 2 may be a transfer transaction or a transaction for creating/invoking a contract.

In another case, for the case that the generated source sharded chunk includes chunk headers of a plurality of main-chain chunks sent from the main chain and corresponding cross-slice transaction responses that need to be received by the source shard, in addition to including the cross-slice transaction responses that need to be processed by the shard in the cross-slice transaction response list of the chunk body of the sharded chunk, the chunk headers of the plurality of main-chain chunks may be included in the chunk headers of the shard chunk. Obviously, in this case, the number of hashes of processed main-chain blocks contained in the block headers of the tile blocks may be variable.

In another case, as shown in fig. 26, for a generated tile block including a chunk header of a plurality of main-chain chunks sent from a main chain and a corresponding cross-slice transaction response that needs to be received by a source tile, in addition to including a cross-slice transaction response that needs to be processed by the tile in a cross-slice transaction response list of a chunk of the tile block, a chunk hash of the plurality of main-chain chunks may be included in a chunk of the tile block, such as a main-chain chunk hash list in a chunk of chunk 201 of fig. 26. The hashes of the processed main chain blocks included in the block bodies of the partitioned blocks may be organized according to the tree structure as described above, and the Hash value of the root of the tree is filled into a field "main chain block root Hash" added in the block header, that is, the Hash value of the root calculated by the Hash of each main chain block according to the tree structure is filled into the main chain block root Hash of the block header of the partitioned block. For example, the "main chain block root Hash" in the block header of the block 201 is a Hash value of a root node of a tree structure organized by the main chain block Hash in the main chain block Hash list in the block 201; the "backbone block root Hash" in the block header of block 202, the Hash value of the root node of the tree structure organized by the backbone block hashes in the backbone block Hash list in the block header of block 202. This has the advantage that the hash of an indefinite number of processed main chain blocks that may be included in a block body of a tiled block can be locked by a fixed field in the block header of said tiled block.

In addition, the main chain may also send the generated time stamp of the main chain chunk to the source slice, for example, by sending the time stamp of the main chain chunk indicated by the chunk header of the main chain chunk before, so that the slice may fill the time stamp of the latest main chain chunk into the timestamp of the slice chunk during the process of generating the slice chunk. For example, in S245, in the process of generating a source slice block by a source slice, the timestamp in the block header of the source slice 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 slice, so that the slice has the same clock system as the main chain. In the case that the fragment and the main chain have the same clock system, a client connected to the fragment may determine the initiation time of a transaction when initiating the transaction. Thus, when a client initiates a transaction, a timestamp of the initiation time can be attached to the initiated transaction.

In the foregoing embodiment of the method for returning a cross-slice transaction response provided by the present application, a cross-slice transaction response generated in a target slice is forwarded to a source slice through a main chain in a blockchain system including slices, so that a feedback scheme of the cross-slice transaction response in the blockchain system including slices is provided. The process ensures that the cross-chip transaction response generated in the target fragment can be reliably forwarded under the witness of the main chain through the authority of the nodes forming the main chain, and the witness is stored on the target fragment, the main chain and the source fragment.

The following describes an embodiment of a system for returning a cross-slice transaction response in a blockchain system including slices, where the blockchain system includes at least two slices, and nodes in different slices store different state sets; the blockchain system further comprises a backbone;

The block body of the target partitioned block generated by the target partition further comprises a cross-slice transaction response list, and the cross-slice transaction response list comprises cross-slice transaction responses needing to be fed back to the source partition.

The block header of the target partitioned block generated by the target partition further includes a cross-slice transaction response _ root field, which is used for locking the cross-slice transaction response list in the block into the block header.

The chunk body of the master-chain chunk includes cross-slice transaction responses received by the respective source fragments that are not packed by the master-chain in previously generated chunks.

Before the main chain generates the main chain block, the method further comprises the following steps: after receiving a cross-chip transaction response sent by a target fragment, a node in the main chain verifies the cross-chip transaction response.

The verification comprises: and calculating the hash value of the root node of the tree formed by the cross-piece transaction responses sent by the sub-pieces by the nodes in the main chain according to the tree structure, and judging whether the received cross-piece transaction response is repeated with the previously received cross-piece transaction response or not according to the hash value.

And the target fragment sends the fragment spanning transaction response to the main chain and also sends the block head of the generated target fragment block to the main chain.

And in the process of generating the main chain block by the main chain, calculating the block hash of the target block sent by each target fragment, and filling the target block hash into the block body of the main chain block.

And in the process of generating the main chain block by the main chain, filling the hash value of the root of the partitioned block hash of each partition calculated according to the tree structure into the partitioned block root of the block head of the main chain block.

And after receiving the block head of the target partitioned block sent by the target partition and the cross-slice transaction response, the main chain also verifies the block head of the target partitioned block.

And the verification comprises the step of organizing the cross-slice transaction response according to a tree structure to obtain a hash value of the tree, and determining that the value is consistent with the cross-slice transaction response _ root in the block head of the target slicing block.

The main chain sends the cross-fragment transaction response to the corresponding source fragment according to the identifier of the source fragment, and the method comprises the following steps:

and sending the cross-fragment transaction response grouped in the block body of the main chain block to the corresponding source fragment according to the identifier of the source fragment.

The main chain also sends a block header of the main chain block to the source tile.

Before the source fragment generates the source fragment block, the method further includes: and after receiving a cross-chip transaction response sent by a main chain, the node in the source fragment verifies the cross-chip transaction response.

The verification comprises: and calculating the hash value of the root node of the tree formed by the cross-piece transaction response by the nodes in the source fragment according to the tree structure, and judging whether the cross-piece transaction response received this time is repeated with the previously received cross-piece transaction response according to the hash.

And after the source fragment receives the block head of the main chain block sent by the main chain and the cross-fragment transaction response, verifying the block head of the main chain block.

In the process of generating a source fragmentation block, the source fragmentation calculates a hash value of the main chain block according to the received block header of the main chain block, and fills the hash value of the main chain block into the block header of the source fragmentation block generated by the source fragmentation.

And for the condition that the generation speed of the main chain block is not lower than the generation speed of the fragmentation block, the source fragmentation fills the hash value of the latest main chain block into the block header of the source fragmentation block generated by the source fragmentation.

For the case that the generation speed of the main chain block is higher than that of the fragment block:

the source fragment fills hash values of a plurality of main chain blocks corresponding to the cross-fragment transaction response packaged in the source fragment block into a block header of a source fragment block generated by the source fragment; or the like, or, alternatively,

the source fragmentation fills Hash values of a plurality of main chain blocks corresponding to the cross-fragment transaction response packed in the source fragmentation block into a block body of the source fragmentation block generated by the source fragmentation, and fills a root Hash value obtained by calculating the Hash of each main chain block according to a tree structure into a main chain block root Hash of a block head of the source fragmentation block.

The main chain also sends the generated time stamp of the main chain block to the source fragment, and the source fragment fills the time stamp of the main chain block into the timestamp of the source fragment block in the process of generating the source fragment block.

The master sends the timestamp of the master chunk to the source slice by sending the chunk header of the master chunk.

And the main chain sends the generated timestamp of the latest main chain block to the source fragment, and correspondingly, the source fragment fills the timestamp of the latest main chain block into a timestamp of the fragment block in the process of generating the source fragment block.

The following introduces a main chain node in a blockchain system including shards according to the present application, as shown in fig. 27, including:

a receiving unit 271, configured to receive a cross-slice transaction response that needs to be executed by a source slice;

a main chain block generating unit 272, configured to generate a main chain block, and fill the received cross-slice transaction response into a block body of the main chain block in the process of generating the main chain block;

a sending unit 273, configured to send the cross-slice transaction response to the corresponding source slice according to the identifier of the source slice.

The chunk body of the chunk generated by the master-chain chunk generation unit 272 includes cross-slice transaction responses received by the respective source slices, which are not packed in the previously generated chunk by the master chain.

The system further comprises a verification unit 274, and after the receiving unit receives the cross-chip transaction response sent by the target fragment, the verification unit verifies the cross-chip transaction response.

The receiving unit 271 also receives a block header of a target tile.

In the process of generating the main chain block, the main chain block generating unit 272 further calculates a block hash of the target block sent from each target partition, and fills the block hash of the target block into the block of the main chain block.

In the process of generating the main chain block, the main chain block generating unit 272 further fills the hash value of the root calculated by the hash of the partitioned block of each partition according to the tree structure into the partitioned block root of the block head of the main chain block.

After the receiving unit 271 receives the block header of the target partitioned block sent by the target partition and the cross-slice transaction response, the verifying unit also verifies the block header of the target partitioned block.

The sending unit 273 sends the cross-slice transaction response to the corresponding source slice according to the identifier of the source slice, where the sending includes:

The sending unit 273 further sends the block header of the main-chain block to the source slice.

The following introduces a source sharding node in a blockchain system including shards according to the present application, as shown in fig. 28, including:

a receiving unit 281, configured to receive a cross-slice transaction response sent by a main chain;

the sharded chunk generating unit 282 is configured to generate a source sharded chunk, and fill the cross-sharded transaction response received from the main sharded chunk into the chunk body of the source sharded chunk in the process of generating the source sharded chunk.

The system further includes an authentication unit 283, where before the fragmentation block generation unit generates the source fragmentation block, after the receiving unit receives the cross-fragment transaction response sent by the main chain, the authentication unit authenticates the cross-fragment transaction response.

After the receiving unit 281 receives the block header of the main chain block sent by the main chain and the cross-chip transaction response, the verifying unit also verifies the block header of the main chain block.

The fragmentation block generation unit 282 calculates, during the process of generating the source fragmentation block, a hash value of the main chain block according to the received block header of the main chain block, and fills the hash value of the main chain block into the block header of the source fragmentation block generated by the source fragmentation.

For the case that the generation speed of the main chain block is not lower than the generation speed of the fragmentation block, the fragmentation block generation unit 282 fills the hash value of the latest main chain block into the block header of the source fragmentation block generated by the source fragmentation.

the fragmentation block generating unit 282 fills hash values of a plurality of main chain blocks corresponding to the cross-fragment transaction responses packed in the source fragmentation block into a block header of the source fragmentation block generated by the source fragmentation; or the like, or, alternatively,

the fragmentation block generation unit 282 fills Hash values of a plurality of main chain blocks corresponding to the cross-fragment transaction responses packed in the source fragmentation block into a block body of the source fragmentation block generated by the source fragmentation, and also fills a Hash value of a root calculated by the Hash of each main chain block according to a tree structure into a main chain block root Hash of a block header of the source fragmentation block.

The receiving unit 281 further receives a timestamp of the main chain chunk sent by the main chain, and the shard chunk generating unit 282 fills the timestamp of the main chain chunk into a timestamp of the source shard chunk in the process of generating the source shard chunk.

The main chain sends the timestamp of the generated latest main chain block to the source fragment, and correspondingly, the fragment block generating unit 282 of the source fragment fills the timestamp of the latest main chain block into the timestamp of the fragment block in the process of generating the source fragment block.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A method for returning cross-chip transaction response in a blockchain system containing fragments comprises at least two fragments, wherein nodes in different fragments store different state sets; the blockchain system further comprises a backbone;

the method comprises the following steps:

2. The method of claim 1, wherein a block of the target sharded chunk generated by the target shard further comprises a cross-shard transaction response list, and the cross-shard transaction response list comprises cross-shard transaction responses that need to be fed back to the source shard.

3. The method of claim 2, further comprising a cross-slice transaction response _ root field in a chunk header of a target sliced chunk generated by the target slice, for locking a cross-slice transaction response list in the chunk header.

4. The method of claim 1, wherein the tile body of the master-tile comprises source-tile-received cross-tile transaction responses that are not packed by the master in previously generated tiles.

5. The method of claim 1, prior to the backbone generating the backbone block, further comprising: after receiving a cross-chip transaction response sent by a target fragment, a node in the main chain verifies the cross-chip transaction response.

6. The method of claim 5, the verifying comprising: and calculating the hash value of a root node of a tree formed by the cross-slice transaction responses sent by the target slice by the nodes in the main chain according to the tree structure, and judging whether the received cross-slice transaction response is repeated with the previously received cross-slice transaction response or not according to the hash value.

7. The method of claim 1, wherein the target slice further sends a block header of the generated target slice block to the main chain.

8. The method according to claim 7, wherein in the process of generating the main chain block by the main chain, a block hash value of a target block sent from each target partition is further calculated, and the block hash value of the target block is filled into the block of the main chain block.

9. The method according to claim 8, wherein in the process of generating the main chain block by the main chain, the hash value of the root calculated according to the tree structure of the partitioned block hash value of each target partition is further filled into the partitioned block root of the block head of the main chain block.

10. The method of claim 9, wherein the main chain further verifies the chunk header of the target partitioned chunk after receiving the chunk header of the target partitioned chunk sent by the target partition and the cross-slice transaction response.

11. The method of claim 10, wherein the validating comprises determining whether a hash value of a tree obtained by organizing the cross-slice transaction responses in a tree structure is consistent with a cross-slice transaction response _ root in a block header of the target tiled block.

12. The method of claim 1, wherein the backbone sends the cross-slice transaction response to the corresponding source slice according to the identifier of the source slice, and the method comprises:

13. The method of claim 1, the backbone further sending a chunk header for the backbone chunk to the source tile.

14. The method of claim 1, wherein before the source shard generates the source shard chunk, further comprising: and after receiving a cross-chip transaction response sent by a main chain, the node in the source fragment verifies the cross-chip transaction response.

15. The method of claim 14, the verifying comprising: and calculating the hash value of the root node of the tree formed by the cross-piece transaction response by the nodes in the source fragment according to the tree structure, and judging whether the cross-piece transaction response received this time is repeated with the previously received cross-piece transaction response according to the hash value.

16. The method of claim 13, wherein the source fragment further verifies the chunk header of the primary-chain chunk after receiving the chunk header of the primary-chain chunk sent by the primary chain and the cross-fragment transaction response.

17. The method according to claim 13, wherein in the process of generating a source tile block by the source tile, a hash value of the main chain block is calculated according to a block header of the received main chain block, and the hash value of the main chain block is filled in the block header of the source tile block generated by the source tile.

18. The method according to claim 17, wherein for a case that the generation speed of the main-chain chunk is not lower than the generation speed of the slice chunk, the source slice fills the hash value of the latest main-chain chunk into a chunk header of a source slice chunk generated by the source slice.

19. The method of claim 17, wherein for the case that the generation speed of the main-chain tile is higher than the generation speed of the tile:

the source fragmentation fills hash values of a plurality of main chain blocks corresponding to the cross-fragment transaction responses packaged in the source fragmentation block into a block body of the source fragmentation block generated by the source fragmentation, and fills a root hash value obtained by calculating the hash value of each main chain block according to a tree structure into a main chain block root hash field of a block head of the source fragmentation block.

20. The method of claim 1, wherein the main chain further sends the generated time stamp of the main chain chunk to the source shard, and the source shard fills the time stamp of the main chain chunk into the timestamp of the source shard chunk in the process of generating the source shard chunk.

21. The method of claim 13, the backbone sends the timestamp of the backbone chunk to the source tile by sending a chunk header of the backbone chunk.

22. The method of claim 20 or 21, wherein the main chain sends the timestamp of the generated latest main chain chunk to the source shard, and accordingly, the source shard fills the timestamp of the latest main chain chunk into the timestamp of the shard chunk in the process of generating the source shard chunk.

23. A system for returning a cross-chip transaction response in a blockchain system comprising fragments, wherein the blockchain system at least comprises two fragments, and nodes in different fragments store different state sets; the blockchain system further comprises a backbone;

24. The system of claim 23, wherein the chunk of the target sharded chunk generated by the target shard further comprises a cross-shard transaction response list, and the cross-shard transaction response list comprises cross-shard transaction responses that need to be fed back to the source shard.

25. The system of claim 24, wherein the target sharded chunk further comprises a cross-sharded transaction response _ root field in the chunk header for locking the cross-sharded transaction response list in the chunk into the chunk header.

26. The system of claim 23, wherein the chunk body of the backbone chunk comprises source fragments that receive cross-slice transaction responses that are unpacked by the backbone in previously generated chunks.

27. The system for returning a cross-slice transaction response of claim 23, the backbone further comprising, prior to generating the backbone block: after receiving a cross-chip transaction response sent by a target fragment, a node in the main chain verifies the cross-chip transaction response.

28. The system of returning a cross-slice transaction response of claim 27, the validating comprising: and calculating the hash value of a root node of a tree formed by the cross-slice transaction responses sent by the target slice by the nodes in the main chain according to the tree structure, and judging whether the received cross-slice transaction response is repeated with the previously received cross-slice transaction response or not according to the hash value.

29. The system of claim 23, wherein the target shard sends a chunk header of the generated target shard chunk to the master chain in addition to sending the cross-shard transaction response to the master chain.

30. The system according to claim 29, wherein in the process of generating the main chain block by the main chain, a block hash value of a target block sent from each target partition is further calculated, and the block hash value of the target block is filled into the block body of the main chain block.

31. The system according to claim 30, wherein in the process of generating the main chain block by the main chain, the hash value of the root of each target fragment is further filled into the fragment block root of the block header of the main chain block according to the hash value of the root calculated by the tree structure.

32. The system of claim 31, wherein the backbone further validates the chunk header of the target tiled chunk after receiving the chunk header of the target tiled chunk and the cross-slice transaction response from the target tiled chunk.

33. The system of claim 32, wherein the validating comprises determining whether a hash value of a tree obtained by organizing the cross-slice transaction response in a tree structure is consistent with a cross-slice transaction response _ root in a block header of the target sliced block.

34. The system of claim 23, wherein the backbone sends the cross-slice transaction response to the corresponding source slice according to the identifier of the source slice, and the system comprises:

35. The system of claim 23, wherein the backbone further sends a chunk header of the backbone chunk to the source slice.

36. The system for returning a cross-slice transaction response of claim 23, before the source shard generates a source sharded chunk, further comprising: and after receiving a cross-chip transaction response sent by a main chain, the node in the source fragment verifies the cross-chip transaction response.

37. The system to return a cross-slice transaction response of claim 36, the validating comprising: and calculating the hash value of the root node of the tree formed by the cross-piece transaction response by the nodes in the source fragment according to the tree structure, and judging whether the cross-piece transaction response received this time is repeated with the previously received cross-piece transaction response according to the hash value.

38. The system of claim 35, wherein the source fragment receives the chunk header of the primary-chain chunk and the cross-fragment transaction response and verifies the chunk header of the primary-chain chunk.

39. The system according to claim 35, wherein in the process of generating a source tile by the source tile, the hash value of the main-chain block is calculated according to the received block header of the main-chain block, and the hash value of the main-chain block is filled into the block header of the source tile generated by the source tile.

40. The system for returning a cross-slice transaction response of claim 39, wherein for a case that the generation speed of the main-chain chunk is not lower than the generation speed of the slice chunk, the source slice fills the hash value of the latest main-chain chunk into the chunk header of the source slice chunk generated by the source slice.

41. The system for returning a cross-tile transaction response of claim 39, wherein for a case that the generation speed of the main-chain chunk is higher than the generation speed of the sliced chunk:

42. The system of claim 23, wherein the master chain further sends a timestamp of the generated master chain chunk to a source shard, and the source shard fills the timestamp of the master chain chunk into a timestamp of the source shard chunk during generation of the source shard chunk.

43. The system of claim 35, wherein the backbone sends the timestamp of the backbone chunk to the source slice by sending a chunk header of the backbone chunk.

44. The system of claim 42 or 43, wherein the backbone sends the timestamp of the latest generated backbone chunk to the source shard, and accordingly, the source shard fills the timestamp of the latest backbone chunk into the timestamp of the sharded chunk during generation of the source shard chunk.

45. A backbone node in a blockchain system comprising shards, comprising:

a receiving unit, configured to receive, from a target fragment, a cross-slice transaction response that needs to be executed by a source fragment, where the cross-slice transaction response is generated by the target fragment according to a cross-slice transaction executed by the target fragment in a process of generating a target fragment block;

46. The master chain node of claim 45 wherein the cross-slice transaction responses received by the respective source slices included in the block of the block generated by the master chain block generation unit are unpacked in a previously generated block by the master chain.

47. The backbone node of claim 45, further comprising a verification unit, wherein the verification unit verifies the cross-slice transaction response after the receiving unit receives the cross-slice transaction response sent by the target slice.

48. The backbone node of claim 47, the validating comprising: and calculating the hash value of a root node of a tree formed by the cross-slice transaction responses sent by the target slice by the nodes in the main chain according to the tree structure, and judging whether the received cross-slice transaction response is repeated with the previously received cross-slice transaction response or not according to the hash value.

49. The master-chain node of claim 47, the receiving unit further receives a block header of a target tiled block.

50. The main chain node of claim 49, wherein in the process of generating the main chain block, the main chain block generating unit further calculates a block hash value of each target partition sent by each target partition, and fills the block hash value of each target partition into the block body of the main chain block.

51. The main chain node of claim 50, wherein in the process of generating the main chain block, the main chain block generation unit further fills a hash value of a root, which is calculated according to a tree structure, of the partitioned block hash value of each target partition into the partitioned block root of the block header of the main chain block.

52. The main-chain node of claim 51, wherein the receiving unit further verifies the chunk header of the target fragmented chunk after receiving the chunk header of the target fragmented chunk and the cross-fragment transaction response from the target fragmented chunk.

53. The backbone node of claim 52, wherein the validating comprises determining whether a hash value of a tree obtained by organizing the cross-slice transaction responses in a tree structure is consistent with a cross-slice transaction response _ root in a block header of the target tiled block.

54. The main-chain node of claim 45, wherein the sending unit sends the cross-slice transaction response to the corresponding source slice according to the identifier of the source slice, and the sending unit includes:

55. The backbone node of claim 45, the sending unit to further send a block header of the backbone block to the source slice.

56. A source sharded node in a blockchain system containing shards, comprising:

the receiving unit is used for receiving the cross-chip transaction response sent by the main chain; the cross-slice transaction response is generated by a target slice according to a cross-slice transaction executed by the target slice in the process of generating a target slice block by the target slice and is sent to a main chain through the target slice;

57. The source sharded node of claim 56 further comprising an authentication unit, before the sharded block generating unit generates the source sharded block, after the receiving unit receives the cross-sharded transaction response sent from the main sharded node, the authentication unit authenticates the cross-sharded transaction response.

58. The source sharding node of claim 57, wherein the verifying comprises: and calculating the hash value of the root node of the tree formed by the cross-piece transaction response by the nodes in the source fragment according to the tree structure, and judging whether the cross-piece transaction response received this time is repeated with the previously received cross-piece transaction response according to the hash value.

59. The source-sharded node of claim 57 wherein the receiving unit, upon receiving the block header of the primary-chain chunk sent from the primary chain and the cross-sharded transaction response, the verifying unit further verifies the block header of the primary-chain chunk.

60. The source fragmentation node of claim 56, wherein the fragmentation block generation unit, during generation of the source fragmentation block, calculates a hash value of the main chain block according to the received block header of the main chain block, and fills the hash value of the main chain block into the block header of the source fragmentation block generated by the source fragmentation.

61. The source-sharded node of claim 60, wherein for a case that the generation speed of the main-chain chunk is not lower than the generation speed of the shard chunk, the shard chunk generation unit fills the hash value of the latest main-chain chunk into the chunk header of the source-sharded chunk generated by the source shard.

62. The source sharded node of claim 60, for a case that the main-chain chunk is generated at a higher speed than the sharded chunks:

the fragmentation block generation unit fills hash values of a plurality of main chain blocks corresponding to the cross-fragment transaction response packaged in the source fragmentation block into a block header of the source fragmentation block generated by the source fragmentation; or the like, or, alternatively,

the fragmentation block generation unit fills hash values of a plurality of main chain blocks corresponding to the cross-fragment transaction responses packaged in the source fragmentation block into a block body of the source fragmentation block generated by the source fragmentation, and also fills a root hash value obtained by calculating the hash value of each main chain block according to a tree structure into a main chain block root hash field of a block head of the source fragmentation block.

63. The source-sharded node of claim 56, the receiving unit further receives a time stamp of a main-chain chunk transmitted by the main chain, and the sharded chunk generating unit fills the time stamp of the main-chain chunk in a timestamp of the source-sharded chunk in the course of generating the source-sharded chunk.

64. The source sharded node of claim 63, said master chain sending the timestamp of the generated latest master chain chunk to the source shard, correspondingly, the sharded chunk generating unit of the source shard filling the timestamp of the latest master chain chunk into the timestamp of the sharded chunk in the process of generating the source shard chunk.