CN112269423A

CN112269423A - Method for locking global clock in blockchain system and blockchain system

Info

Publication number: CN112269423A
Application number: CN202011516622.1A
Authority: CN
Inventors: 邓福喜; 周知远; 谢桂鲁; 徐泉清; 李康; 杨达一
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2020-12-21
Filing date: 2020-12-21
Publication date: 2021-01-26
Anticipated expiration: 2040-12-21
Also published as: CN112269423B

Abstract

The specification provides a state storage method in a blockchain system, the blockchain system and a node. A method for locking global clock in a blockchain system, the blockchain system at least comprises two shards, different shards store different state sets; the blockchain system further comprises a backbone; the method comprises the following steps: generating a main chain block on a main chain, wherein the block head of the main chain block comprises a time stamp for indicating the generation time of the main chain block; the main chain sends the time stamp of the main chain block to the fragment; and in the process of generating the partitioned block by partitioning, setting the timestamp in the block header of the partitioned block as the latest timestamp sent by the main chain.

Description

Method for locking global clock in blockchain system and blockchain system

Technical Field

The embodiment of the specification belongs to the technical field of blockchain, and particularly relates to a method for locking a global clock in a blockchain system, the blockchain system, a fragment and a 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 present specification provides a method for storing state in a blockchain system, and a node.

The method for locking a global clock in a blockchain system, the shards and the nodes provided by the embodiments of the present specification are implemented by the following methods:

a method for locking global clock in a blockchain system, the blockchain system at least comprises two shards, different shards store different state sets; the blockchain system further comprises a backbone;

the method comprises the following steps:

generating a main chain block on a main chain, wherein the block head of the main chain block comprises a time stamp for indicating the generation time of the main chain block;

the main chain sends the time stamp of the main chain block to the fragment;

and in the process of generating the partitioned block by partitioning, setting the timestamp in the block header of the partitioned block as the latest timestamp sent by the main chain.

A block chain system at least comprises two fragments, wherein different fragments store different state sets; the blockchain system further comprises a backbone; and the number of the first and second electrodes,

generating a main chain block on the main chain, wherein the block head of the main chain block comprises a time stamp for indicating the generation time of the main chain block; the main chain also sends the time stamp of the main chain block to the fragment;

A blockchain shard, which is one shard in a blockchain system comprising a main chain, for storing a set of states, and the set of stored states is different from the set of states in other shards;

the block chain fragments receive the time stamp of the main chain block sent by the main chain;

and in the process of generating the partitioned blocks by the block chain partitioning, setting the timestamp in the block header of the partitioned block as the latest timestamp sent by the main chain.

A blockchain point that belongs to a slice in a blockchain system, the blockchain slice being one slice in the blockchain system that includes a main chain; the block chain nodes are used for storing the state sets, and the stored state sets are different from the state sets stored by the nodes in other fragments;

the block link point includes:

a processor;

a memory having a program stored therein, wherein when the program is executed by the processor, the following is performed:

the block link point receives a time stamp of a main chain block transmitted by a main chain;

and in the process of generating the partitioned blocks by the block link points, setting the timestamp in the block header of the partitioned block as the latest timestamp sent by the main chain.

A method for locking a blockchain system, the blockchain system at least comprises two shards, different shards store different state sets; the blockchain system further comprises a backbone;

the method comprises the following steps:

generating a main chain block on a main chain, wherein the block head of the main chain block comprises a unique identifier for marking the main chain block;

the main chain sends the unique identification of the main chain block;

and in the process of generating the partitioned block by partitioning, storing the latest unique identifier sent by the main chain in the block head of the partitioned block.

generating a main chain block on the main chain, wherein the block head of the main chain block comprises a unique identifier for marking the main chain block; the main chain also sends the unique identification of the main chain block to the fragment;

and in the process of generating the partitioned block by partitioning, storing the latest unique identifier sent by the main chain in the block header of the partitioned block.

the block chain fragment receives a unique identifier of a main chain block sent by a main chain;

and in the process of generating the partitioned block by the block chain partitioning, storing the latest unique identifier sent by the main chain in the block head of the partitioned block.

the block link point includes:

a processor;

the block link point receives a unique identifier of a main chain block sent by a main chain;

and in the process of generating the partitioned block by the block link points, storing the latest unique identifier sent by the main chain in the block head of the partitioned block.

Through the embodiment of the application, the time stamps in the block headers of the slices are set as the time stamps on the main chain, so that at any moment, the blocks on the slices corresponding to the moment can be determined, the states corresponding to the blocks on the slices can be further determined, and the global state determined at the moment can be obtained.

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 is a block chain state tree storage structure in 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 diagram illustrating the generation of tiles for a backbone and a sharded chain according to a backbone clock in one embodiment of the present description;

FIG. 17 is a flow diagram of a mechanism for messaging between a backbone and a sharded chain in one embodiment of the specification;

FIG. 18 is a block diagram illustrating the generation of a backbone and sharded chain according to a backbone clock in one embodiment of the present disclosure;

fig. 19 is a flow diagram of a message mechanism between a backbone and a sharded chain in one 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 basic fragmentation method, i.e. dividing the whole 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 separate 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 mapping 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 mapping 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 mapping 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 the mapping type, key = SHA3 (key in mapping, variable declaration position), that is, the hash value is calculated after the key in mapping and the state variable declaration position are pieced together into a string of a certain length (for example, 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 mapped values 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 state variables of a mapping type 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 mapping 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, the state variables of the mapping type 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 the state variables of the mapped type in one contract.

The number of mapped type state variables in the contract account generally corresponds to the external account, and in addition, the basic type state variables are also included in the contract account. When the number of external accounts is large, the number of mapping-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 state variables 1, 2, 3, … 10000 for all mapping types 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, mapping type state variables 1-1000 related to the external account 1 are decomposed into the storage of the external account 1; the mapping type state variable 1001 and 2000 associated with the external account 2 is decomposed into the storage of the external account 2, and so on.

In addition to the mapping data structure, 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 mapping type, key = SHA3 (key in mapping, variable declaration position), that is, the hash value is calculated after the key in mapping and the state variable declaration position are pieced together 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 mapping data for each external account. For example, storage _ root of external account 1 points to one of its key-value mapping types; external account 2 points to one key-value in its mapped 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; the second layer stores the mapping relation defined by the mapping and comprising the external account number and the new type assets in the form of key-value.

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 mapping type, key = SHA3 (key in mapping, variable declaration position), that is, the hash value is calculated after the key in mapping and the state variable declaration position are pieced together 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 mapping data for each external account. For example, store _ root of external account 1 points to a tree structure of a set of key-values in its mapping type; the storage _ root of external account 2 points to a tree structure of a set of key-values in its mapping 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; the second layer stores mapping relation defined by the mapping and comprising the external account 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 the mapping relation defined by the mapping 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 mapping and comprising the external account and one new type of asset 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 mapping type, key = SHA3 (key in mapping, variable declaration position), that is, the hash value is calculated after the key in mapping 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, 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 mapping data for each external account. For example, storage _ root of external account 1 points to one of its key-value mapping types; external account 2 points to one key-value in its mapped 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; the second layer stores the mapping relation defined by the mapping and comprising the external account number and the new type assets in the form of key-value.

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; the second layer stores mapping relation defined by the mapping and comprising the external account 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 the mapping relation defined by the mapping 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 mapping and comprising the external account and one new type of asset 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); nodes I, J, K, L in slice 3, each node's state storing the state of external accounts 3, 7, 11, 15. (e.g., a set of external accounts designated by positive integers starting at interval 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, the two external account sets corresponding to the shard 2 and the shard 3 respectively may have no external account with an intersection or may have an external account with 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 (key-value of the aforementioned mapping type) related to the external account generated by executing the contract, and is relatively fixedly stored in the node storage of a certain segment.

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 storage related to the external account is changed, so that the storage of most fragments is not adjusted, and the problem of = 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. By mapping type state variables, each external account may be given 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". 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 the mapping data structure, 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 intelligent contract, the contract status corresponding to the external account in the mapping 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 by a mapping data structure or other data structure. Taking the data structure definition of mapping as an example, the mapping relation between the external account and the asset is generally defined in the mapping. 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 may be defined through mapping. 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 involved in the contract, for example, the mapping relationship between the external account and the asset defined by the mapping 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, and 8, the mapping type state variable in storage may be stored in the form of key-value. In a specific example, for the mapping type, key = SHA3 (key in mapping, variable declaration location), that is, the hash value is calculated after the key in mapping and the variable declaration location are pieced together into a 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 mapping type, key = SHA3 (key in mapping, variable declaration position), that is, the hash value is calculated after the key in mapping 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, 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 mapping data for each external account. For example, storage _ root of external account 1 points to one of its key-value mapping types; external account 2 points to one key-value in its mapped 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; the second layer stores the mapping relation defined by the mapping and comprising the external account number and the new type assets in the form of key-value.

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 mapping type, key = SHA3 (key in mapping, variable declaration position), that is, the hash value is calculated after the key in mapping 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, i.e. the balance of assets of type balanceA, balanceB, balanceC, balanceD, …. As in fig. 6, the leaf nodes of the storage tree of external Account 1 (external Owned Account 1) have balances of 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 mapping data for each external account. For example, store _ root of external account 1 points to a tree structure of a set of key-values in its mapping type; the storage _ root of external account 2 points to a tree structure of a set of key-values in its mapping 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; the second layer stores mapping relation defined by the mapping and comprising the external account 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 variable described above is associated with each external account. Thus, for each external account, this mapping type of state variable is a local type of 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:

the mapping relationship of the external account and the asset defined by the mapping data structure.

The mapping relationship of the external account and the asset defined by the mapping 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 fragmentation scheme, as long as nodes in different fragments store states of different external account sets, since different fragments may use different clocks, the problem of determining the states of all accounts of different fragments at the same time point is involved. For a shard blockchain system that does not use a main chain, although inter-shard interlocking may be used, such an approach requires inter-locking of multiple shards. For example, in a system with a plurality of partitions, such as the system shown in fig. 10 that includes 4 partitions, partition 1 needs to lock partitions 2, 3, and 4, partition 2 needs to lock partitions 1, 3, and 4, partition 3 needs to lock partitions 1, 2, and 4, and partition 4 needs to lock partitions 1, 2, and 3. Therefore, multiple message interactions are needed among different fragments, and the complexity is high. For a blockchain system with n slices, the complexity of the message will typically be reached. In view of the above, the present application provides a main chain-based blockchain fragmentation 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 shard 1, 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 of slice 1 and slice 2 to generate new tiles may not be consistent; of course, lockstep may also be used, and is described herein primarily in terms of lockstep inconsistencies. Also, slice 1 and slice 2 may use different clocks. 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 appreciated that the transaction request is processed in slices, and the tiles are generated through a consensus mechanism. 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 hash result of all 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, an original transaction list may be generally included, and the transactions in the original transaction list may be organized by a tree structure, such as the aforementioned MPT tree, or a merkle tree. 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, slice 1 sequentially generates chunks 101 and 102 under its own clock, and slice 2 sequentially generates chunks 201 and 202 under its own clock. 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. Without a uniform clock, it is difficult to determine the state of all of the clocks at a certain time. In many business scenarios, if the overall status cannot be determined, the settlement of the transaction cannot be completed.

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. Because nodes in the backbone have a high degree of confidence, the clock in the slice may be determined based on the clock of the backbone. Similarly, the block generated on the main chain can also be locked by a Hash, for example, the Hash value of 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. Similarly, the Block header of the Block of the main chain may include fields such as a Block number (Block Num), a Timestamp (Timestamp), and a Hash value (Prev Hash) of the previous Block. The frequency of generating blocks on the main chain is generally higher than the frequency of generating blocks in each slice, at least not lower than the frequency of generating blocks in each slice. As shown in fig. 16, if the clock of the main chain is followed, the time points of the blocks generated in the main chain, slice 1, slice 2 as shown in the figure are respectively identified as. Then the time of the chunk generated in the slice needs to be locked to the clock of the main chain through a certain message mechanism and the design of the chunk header.

Fig. 17 shows the flow of this message mechanism, including:

s171: generating a main chain block on the main chain, wherein the block head of the main chain block comprises a time stamp for marking the generation time of the main chain block.

The backbone may have its own chain of blocks. The nodes in the main chain, as mentioned above, have a high degree of confidence. Blocks may be generated on the backbone by consensus, and are subsequently referred to as backbone blocks. In the generated main chain block, the block header may include fields such as a block number, a timestamp, and a hash value of a previous block. Wherein, the time stamp indicates the generation time of the main chain block on the main chain, and the generation time is determined according to the clock on the main chain.

S173: the master sends a timestamp of the master chunk to the slice.

After the master-chain chunk is generated, the master chain may send a timestamp in the chunk header of the master-chain chunk to the slice. It may be the master node or non-master node/nodes in the backbone that send a timestamp of the backbone block to a certain node or nodes in the slice.

For example, as shown in fig. 18, the main chain generates block 10001 at the time point of the main chain clock system, and the time stamp in the block header of the main chain block is, for example. The master node in the main chain may send the timestamp to all nodes in the segment 1 and all nodes in the segment 2, where the master node in the main chain sends the timestamp to the master node in the segment 1 and the master node in the segment 2, or at least a quorum (quorum, for example, a PBFT-based block chain system) number of nodes in the main chain sends the timestamp to the master node in the segment 1 and the master node in the segment 2, or at least a quorum number of nodes in the main chain sends the timestamp to the quorum node in the segment 1 and the quorum node in the segment 2.

For segment 1 and segment 2, a series of processes such as transaction request, consensus, transaction execution and the like can be normally received. For example, a node in slice 2 may receive a client-initiated transaction. The transaction may be a normal transfer transaction or a transaction that creates and/or invokes a contract. Under the condition of adopting the main consensus algorithm, the transaction sent by the client received in the segment 2 can be forwarded to the main node if the transaction is received by a non-main node. The master node may package several transactions initiated by the client over a period of time, and sequence the transactions to initiate consensus offers. In the case of using the masterless consensus algorithm, the nodes in segment 2 may initiate consensus suggestions in turn, or the nodes in segment 2 may initiate consensus suggestions in parallel, depending on the consensus algorithm used. Segment 1 is similar to segment 2 described above and will not be described in detail. For simplicity, the following description will use the PBFT consensus algorithm in the main chain and the segment as an example.

After consensus, the nodes in the shard may perform the packed transactions in order and generate new tiles (subsequently referred to as sharded tiles).

S175: and in the process of generating the partitioned block by partitioning, setting the timestamp in the block header of the partitioned block as the latest timestamp sent by the main chain.

For example, as shown in fig. 18, slice 2 receives a time stamp from the main chain. Subsequently, slice 2 generates chunk 201 in slice 2 (at a time on the main chain time axis). Segment 2 may add a timestamp sent by the main chain, for example, a timestamp sent by the main chain, to the consensus proposal message during the process of generating the chunk 201, for example, during the process of packaging the transaction and initiating the consensus by the main node in segment 2. After the consensus is achieved, when each node in the segment 2 executes the transaction packed by the host node in the segment 2 to generate a segment block, the timestamp sent from the host node, which is added to the consensus suggestion message initiated by the host node, may be set in a block header of the generated segment block, for example, the timestamp may be a value of a timestamp in the block header of the segment block.

For another example, slice 2 receives the time stamp of the sum of the three main-chain chunks sent by the main chain, but the latest time stamp, before generating chunk 202 in slice 2 at that time. Segment 2 may add the latest timestamp sent by the main chain, for example, the timestamp sent by the main chain, to the consensus proposal message during the process of generating the chunk 202, for example, during the process of packaging transaction and initiating consensus by the main node in segment 2. After the consensus is achieved, when each node in the segment 2 executes the transaction packed by the main node in the segment 2 to generate a segment block, the latest timestamp sent from the main node, which is added to the consensus suggestion message initiated by the main node, may be set in a block header of the generated segment block, for example, the latest timestamp in the block header of the segment block.

Similarly, slice 1, again for example, receives the time stamp sum of the master transmission before time instance generation block 101, but the time stamp of the newest master block. Then, during the generation of the chunk 101 in the chunk 1, for example, during the generation of the chunk in the chunk 1, the timestamp in the chunk header of the chunk 101 is set to the latest timestamp sent by the main chain. Slice 1 receives the time stamp of the main chain transmission, the sum, and the latest time stamp before the time of generating the chunk 102. Then, in the process of generating the chunk 102 in the chunk 1, for example, in the process of generating the chunk in the chunk 1, the timestamp in the chunk header of the chunk 102 is set to the latest timestamp sent by the main chain.

The time stamps in the block headers of the slices are set as the time stamps on the main chain, so that the blocks on the slices corresponding to the time can be determined at any time, the states corresponding to the blocks on the slices can be further determined, and the global state determined at the time can be obtained. For example, given a time, the time is between the sum of the main chain time axes. The global state corresponding to the time instant is the aggregate of the state corresponding to chunk 101 of slice 1 and the state corresponding to chunk 201 of slice 2.

In addition, the fragment block chain system in the application adopts the main chain, so that a plurality of fragments do not need to be directly locked with each other, but all the fragments are locked with the main chain. Thus, for a blockchain system with n shards, the message interaction between each shard and the main chain is approximate to the complexity of the system.

An embodiment of a blockchain system according to the present application is described below, where the blockchain system includes at least two shards, and different shards store different state sets; the blockchain system further comprises a backbone; and the number of the first and second electrodes,

The different shards store different state sets, including:

nodes in different fragments store the states of different external account sets; and/or the presence of a gas in the gas,

nodes in different fragments store different contract account state sets; and/or the presence of a gas in the gas,

nodes in different shards store the state of different contract account sets.

The frequency of generating blocks on the main chain is higher than the frequency of generating blocks in each slice.

The master chain sending the time stamp of the master chain block to the fragment comprises:

the master node or non-master node/nodes in the master chain send a timestamp of the master chain block to a node or nodes in the slice.

Nodes in the different shards store states of different external account sets, including:

the nodes in different segments execute the state related to the external account generated by creating and/or invoking the transaction of the contract and store the state; and/or the presence of a gas in the gas,

nodes in different segments execute the state of the external account generated by the common transfer transaction and store the state.

The nodes in the different segments execute the state related to the external account generated by the transaction of creating and/or calling the contract and store the state, and the state comprises the following steps:

executing a transaction of creating and/or invoking a contract at a blockchain link point belonging to a segment, generating a state related to the blockchain external account to be stored;

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

The status associated with the blockchain external account includes:

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

The mapping relationship between the external account and the asset defined in the contract comprises:

An embodiment of a blockchain shard of the present application is introduced below, where the blockchain shard is a shard in a blockchain system that includes a main chain and is used for storing a set of states, and the set of stored states is different from the sets of states in other shards;

The state set stored in the block chain shard is different from the state sets in other shards, and the method comprises the following steps:

the blockchain shard stores a state of an external account set different from other shards; and/or the presence of a gas in the gas,

the blockchain shard stores a contract account state set different from other shards; and/or the presence of a gas in the gas,

the blockchain shard stores a state of the contract account set that is different from other shards.

The blockchain shard stores a state of an external account set different from other shards, including:

the nodes in the block chain fragment execute the state related to the external account generated by creating and/or invoking the transaction of the contract and store the state; and/or the presence of a gas in the gas,

and executing the state of an external account generated by the common transfer transaction by the nodes in the block chain segment and storing the state.

The state related to the external account generated by the nodes in the block chain fragment executing the transaction of creating and/or invoking the contract is stored, and the state related to the external account comprises the following steps:

executing a contract creating and/or invoking transaction by a node belonging to the blockchain segment, and generating a state to be stored and related to the blockchain external account;

The status associated with the blockchain external account includes:

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

The following describes a blockchain link point of the present application that belongs to a segment in a blockchain system that is a segment in a blockchain system that includes a main chain; the block chain nodes are used for storing the state sets, and the stored state sets are different from the state sets stored by the nodes in other fragments;

the block link point includes:

a processor;

The state set stored by the block chain node is different from the state sets stored by the nodes in other fragments, and the method comprises the following steps:

the block chain node stores a state different from the state of an external account set stored by nodes in other fragments; and/or the presence of a gas in the gas,

the block chain node stores a contract account state set different from the contract account state sets stored by nodes in other fragments; and/or the presence of a gas in the gas,

the blockchain node stores a different state than contract account sets stored by nodes in other shards.

and the blockchain node executes the state of the external account generated by the common transfer transaction and stores the state.

The block chain node executes the state related to the external account generated by the trade of creating and/or calling contracts and stores the state, and comprises the following steps:

the blockchain link point performs a transaction to create and/or invoke a contract, resulting in a state to be stored in relation to the blockchain external account;

the blockchain link point stores the state to be stored in relation to the blockchain external accounts in a state store of the corresponding blockchain external accounts.

The status associated with the blockchain external account includes:

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

In addition, the timestamp may also be replaced with the block number of the latest block of the main chain. Holding the block number in the tile header of the tile may indirectly bind the backbone time, but this is an alternative or alternative. The main chain time, or global time, may need to be obtained by finding the timestamp in the block header of the block corresponding to the block number through the main chain. The same is the unique identifier such as the block hash. Preferably, the time stamp of the embodiment of fig. 17 is used, and the global time can be directly obtained through the time stamp. For example, there is a need to obtain system time in many contracts, and by means of time stamping, global time can be directly and easily taken when executing contracts in a sharded chain.

Fig. 19 shows the flow of this message mechanism replaced with a unique identifier such as a block number, including:

s191: generating a main chain block on the main chain, wherein the block head of the main chain block comprises a unique identifier for marking the main chain block.

Similar to the previous, the main chain may have its own chain of blocks. The nodes in the main chain, as mentioned above, have a high degree of confidence. In the main chain block which can be generated by the main chain through consensus, the block header can comprise fields such as a block number, a time stamp, a hash value of the previous block and the like. Wherein, the time stamp indicates the generation time of the main chain block on the main chain, and the generation time is determined according to the clock on the main chain. The block number is a number of a block, and is generally a natural number arranged in order and is unique. Typically, the block number of a block in the main chain corresponds to a time stamp in the block header of the block. Based on such a correspondence, the block number may also replace the time stamp in the embodiment of fig. 17 to play substantially the same role. Similarly, the block hash value is also included, so that the block hash value can be summarized as a unique identifier capable of indicating the main chain block, and further description is omitted.

S193: the main chain sends the unique identification of the main chain block to the fragment.

After the main chain chunk is generated, the main chain may send a unique identifier in a chunk header of the main chain chunk to the fragment. It may be that the master node or one or more non-master nodes in the backbone send a unique identification of the backbone block to a certain node or nodes in the slice.

For example, as shown in fig. 18, the main chain generates block 10001 at the time point of the main chain clock system, and the block number in the block header of the main chain block is, for example, 10001. The master node in the main chain may send the block number 10001 to all nodes in the segment 1 and all nodes in the segment 2, where the master node in the main chain sends the block number 10001 to the master nodes in the segment 1 and in the segment 2, or at least a quorum (quorum, for example, a PBFT-based block chain system) number of nodes in the main chain sends the block number 10001 to the master nodes in the segment 1 and the master nodes in the segment 2, or at least a quorum number of nodes in the main chain sends the block number 10001 to a quorum number of nodes in the segment 1 and a quorum number of nodes in the segment 2.

S195: and in the process of generating the partitioned block by partitioning, storing the latest unique identifier sent by the main chain in the block head of the partitioned block.

For example, as shown in fig. 18, slice 2 receives a primary sent block number 10001. Subsequently, slice 2 generates chunk 201 in slice 2 (at a time on the main chain time axis). Segment 2 may add the block number sent by the main chain, for example, block number 10001 sent by the main chain, to the consensus proposal message during the process of generating block 201, for example, during the process of packaging transaction and initiating consensus by the master node in segment 2. After the consensus is achieved, when each node in the segment 2 executes the transaction packed by the host node in the segment 2 to generate a segment block, the number of the block sent from the host node added in the consensus proposal message initiated by the host node may be set in the block header of the generated segment block, for example, 10001 is used as a value of one field in the block header of the segment block.

For another example, slice 2 receives

block numbers

10001, 10002, and 10003 of the three backbone blocks transmitted by the backbone before generating block 202 in slice 2 at the time, and 10003 is the latest block number. Slice 2 may add the latest chunk number sent by the main chain, for example, the chunk number 10003 sent by the main chain, to the consensus offer message during the process of generating the chunk 202, for example, during the process of packaging transaction and initiating consensus by the main node in slice 2. After the consensus is achieved, when each node in the segment 2 executes the transaction packed by the host node in the segment 2 to generate a segment block, the latest block number sent from the host node added in the consensus proposal message initiated by the host node may be set in the block header of the generated segment block, for example, 10001 is used as a value of one field in the block header of the segment block.

Similarly, for example, slice 1 receives the

block numbers

10001 and 10002 of the backbone transmission before generating block 101 at the time point, and 10002 is the block number of the latest backbone block. Then, in the process of generating the chunk 101, for example, in the process of generating the chunk in the chunk 1, the chunk 1 sets a field in the chunk header of the chunk 101 as the latest chunk number 10003 sent by the main chain. Slice 1 receives the transmitted

block numbers

10001, 10002, 10003, 10004 of the backbone before generating block 102 at that time, and 10004 is the latest block number. Then, during the process of generating the chunk 102, for example, during the process of generating the chunk in the chunk 1, the chunk 1 sets a field in the chunk header of the chunk 102 as the latest chunk number 100004 sent by the main chain.

Because the block head of each fragment comprises the latest block number on the main chain before the fragment block is generated, the main chain block number corresponding to the moment can be determined at any moment, the blocks on each fragment can be determined according to the main chain block number, and the state corresponding to the blocks on each fragment can be further determined, so that the global state determined at the moment can be obtained. For example, given a time, the time is between the sum of the main chain time axes. The latest backbone block number corresponding to the time is 10002, the backbone block number is 10001 in the segment block 101, the backbone block number is 10002 in the segment block 202, and the global state is the collection of the state corresponding to the block 101 of segment 1 and the state corresponding to the block 201 of segment 2.

The unique identifier of the main chain block comprises any one of a block number and a hash value of the main chain block.

The different shards store different state sets, including:

nodes in different shards store the state of different contract account sets.

The main chain sends the unique identifier of the main chain block to the fragment, and the method comprises the following steps:

the master node or one or more non-master nodes in the main chain send the unique identification of the main chain block to a certain node or certain nodes in the fragment.

The status associated with the blockchain external account includes:

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

The status associated with the blockchain external account includes:

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

The following describes an embodiment of a blockchain point of the present application that belongs to a segment of a blockchain system that includes a main chain; the block chain nodes are used for storing the state sets, and the stored state sets are different from the state sets stored by the nodes in other fragments;

the block link point includes:

a processor;

The status associated with the blockchain external account includes:

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

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 magnetic 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 present specification can 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 locking global clock in a blockchain system, the blockchain system at least comprises two shards, different shards store different state sets; the blockchain system further comprises a backbone;

the method comprises the following steps:

the main chain sends the time stamp of the main chain block to the fragment;

2. The method of claim 1, the different shards storing different sets of states, comprising:

nodes in different shards store the state of different contract account sets.

3. The method of claim 1, wherein the frequency of generating blocks on the main chain is higher than the frequency of generating blocks in each tile.

4. The method of claim 1, the backbone sending timestamps for the backbone chunks to tiles, comprising:

5. The method of claim 2, wherein nodes in the different shards store state of different sets of external accounts, comprising:

6. The method of claim 5, wherein the nodes in the different shards perform and store external account related state resulting from transactions that create and/or invoke contracts, comprising:

7. The method of claim 6, the status associated with the blockchain external account comprising:

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

8. The method of claim 7, the mapping of external accounts to assets defined in the contract comprising:

9. A block chain system at least comprises two fragments, wherein different fragments store different state sets; the blockchain system further comprises a backbone; and the number of the first and second electrodes,

10. The blockchain system of claim 9, the different shards storing different sets of states, comprising:

nodes in different shards store the state of different contract account sets.

11. The blockchain system of claim 9, wherein the frequency of generating blocks on the main chain is higher than the frequency of generating blocks in each tile.

12. The blockchain system of claim 9, the backbone sending timestamps of the backbone blocks to tiles comprising:

13. The blockchain system of claim 10, the nodes in the different shards storing the status of different sets of external accounts, comprising:

14. The blockchain system of claim 13, wherein the nodes in the different shards perform and store external account related state resulting from transactions that create and/or invoke contracts, including:

15. The blockchain system of claim 14, the status associated with the blockchain external accounts including:

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

16. The blockchain system of claim 14, the mapping of external accounts to assets defined in the contract comprising:

17. A blockchain shard, which is one shard in a blockchain system comprising a main chain, for storing a set of states, and the set of stored states is different from the set of states in other shards;

18. The blockchain slice of claim 17, wherein the blockchain slice stores a different state set than state sets in other slices, comprising:

19. The blockchain shard of claim 17, the blockchain shard storing status of the external account set different from other shards, comprising:

20. The blockchain shard of claim 19, wherein a node in the blockchain shard performs and stores external account related status generated by transactions that create and/or invoke contracts, comprising:

21. The blockchain shard of claim 20, the status associated with the blockchain external accounts including:

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

22. The blockchain shard of claim 21, wherein the external account to asset mapping defined in the contract comprises:

23. A blockchain point that belongs to a slice in a blockchain system, the blockchain slice being one slice in the blockchain system that includes a main chain; the block chain nodes are used for storing the state sets, and the stored state sets are different from the state sets stored by the nodes in other fragments;

the block link point includes:

a processor;

24. The blockchain node of claim 23, the blockchain node storing a different set of states than the set of states stored by nodes in other shards, comprising:

25. The blockchain node of claim 23, the blockchain shard storing a state of the external account set different from other shards, comprising:

26. The block link point of claim 25, wherein the state associated with the external account resulting from the execution of the transaction to create and/or invoke the contract is stored, comprising:

27. The blockchain link point of claim 26, the status associated with the blockchain external account including:

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

28. The block link point of claim 27, the external account to asset mapping defined in the contract comprising:

29. A method for locking a blockchain system, the blockchain system at least comprises two shards, different shards store different state sets; the blockchain system further comprises a backbone;

the method comprises the following steps:

the main chain sends the unique identification of the main chain block;

30. A method as claimed in claim 29, wherein the unique identity of the backbone block comprises any one of a block number, a hash value of the backbone block.

31. The method of claim 29, wherein the different shards store different sets of states, comprising:

nodes in different shards store the state of different contract account sets.

32. The method of claim 29, wherein the frequency of generating blocks on the main chain is higher than the frequency of generating blocks in each tile.

33. The method of claim 29, the backbone sending timestamps for the backbone chunks to tiles, comprising:

34. The method of claim 31, wherein nodes in the different shards store state of different sets of external accounts, comprising:

35. The method of claim 34, wherein the nodes in the different shards perform and store external account related state resulting from transactions that create and/or invoke contracts, comprising:

36. The method of claim 35, the status associated with the blockchain external account comprising:

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

37. The method of claim 36, wherein the mapping of external accounts to assets defined in the contract comprises:

38. A block chain system at least comprises two fragments, wherein different fragments store different state sets; the blockchain system further comprises a backbone; and the number of the first and second electrodes,

39. The blockchain system of claim 38, the unique identification of the backbone block comprising any of a block number, a hash value of the backbone block.

40. The blockchain system of claim 38, the different shards storing different sets of states including:

nodes in different shards store the state of different contract account sets.

41. The blockchain system of claim 38, wherein the frequency of generating blocks on the main chain is higher than the frequency of generating blocks in each tile.

42. The blockchain system of claim 38, the backbone sending a unique identification of the backbone block to a slice comprising:

43. The blockchain system of claim 40, the nodes in the different shards storing status of different sets of external accounts, comprising:

44. The blockchain system of claim 43, wherein the nodes in the different shards perform and store external account related state resulting from transactions that create and/or invoke contracts, comprising:

45. The blockchain system of claim 44, the status related to the blockchain external accounts including:

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

46. The blockchain system of claim 44, the mapping of external accounts to assets defined in the contract comprising:

47. A blockchain shard, which is one shard in a blockchain system comprising a main chain, for storing a set of states, and the set of stored states is different from the set of states in other shards;

48. The blockchain shard of claim 47, wherein the unique identification of the backbone block comprises any one of a block number, a hash value of the backbone block.

49. The blockchain slice of claim 47, wherein the blockchain slice stores a state set that is different from state sets in other slices, comprising:

50. The blockchain shard of claim 49, wherein the blockchain shard stores a status of the external account set different from other shards, comprising:

51. The blockchain shard of claim 50, wherein a node in the blockchain shard performs and stores external account related status generated by transactions that create and/or invoke contracts, comprising:

52. The blockchain shard of claim 51, the status associated with the blockchain external accounts including:

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

53. The blockchain shard of claim 52, wherein the external account to asset mapping defined in the contract comprises:

54. A blockchain point that belongs to a slice in a blockchain system, the blockchain slice being one slice in the blockchain system that includes a main chain; the block chain nodes are used for storing the state sets, and the stored state sets are different from the state sets stored by the nodes in other fragments;

the block link point includes:

a processor;

55. The block link point of claim 54, the unique identification of the master chain block comprising any of a block number, a hash value of the master chain block.

56. The blockchain link point of claim 54, the blockchain node storing a different set of states than nodes in other shards, comprising:

57. The blockchain link point of claim 54, the blockchain shard storing status of the external account set different from other shards, comprising:

58. The block link point of claim 57, wherein the state associated with the external account resulting from the execution of the transaction to create and/or invoke the contract is stored and comprises:

59. The blockchain link point of claim 58, the status associated with the blockchain external accounts comprising:

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

60. The block link point of claim 59, the external account to asset mapping defined in the contract comprising: