Blockchain system with efficient world state data structure

Abstract

The present invention discloses a method, system and apparatus for processing world state information associated with a blockchain, including a computer program encoded on a computer storage medium. One of the systems includes: a blockchain database configured to store a blockchain managed by a blockchain network, wherein the blockchain data is stored on the blockchain through the consensus of the blockchain nodes of the blockchain network, wherein the blockchain includes one or more blocks storing transaction data associated with a user account associated with the blockchain; a world state database configured to store a world state data structure including multiple digital trees, wherein the world state stores information about the state of the user account; a smart contract database configured to store multiple smart contracts associated with the blockchain, wherein the first smart contract of the multiple smart contracts includes a first code, wherein the first code identifies the first state data and the first digital tree of the multiple digital trees for storing the first state data; and a virtual machine associated with the blockchain corresponding to the first smart contract, wherein the virtual machine is configured to execute the first smart contract so that the first state data is stored in the first digital tree.

Description

Technical Field

[0001] This paper deals with blockchain systems with efficient world state data structures. Background Art

[0002] A distributed ledger system (DLS), which may also be referred to as a consensus network and / or a blockchain network, enables participating entities to store data securely and immutably. Examples of types of blockchain networks may include public blockchain networks, private blockchain networks, and consortium blockchain networks. A consortium blockchain network is provided for a selected group of entities that controls the consensus process and includes an access control layer.

[0003] Programs based on blockchain can be executed by a distributed computing platform. For example, a distributed computing platform can include a virtual machine that provides an operating environment for executing smart contracts. The blockchain computing platform can be viewed as a transaction-based state machine. The state data in the platform can be combined into a global shared state called the world state. The world state includes a mapping between an account address and an account state. The world state can be stored in a content-addressed tree structure such as a Merkle Patricia tree (MPT).

[0004] Content-addressed state trees are incremental in nature. That is, changes in account state are reflected by adding new tree structures rather than updating the values ​​of existing state trees. Therefore, as new transactions continue to enter the blockchain, the size of the content-addressed state tree can grow very large. In some DLSs, each node stores an entire copy of the world state, which takes up a lot of storage space because all block data and state data are stored, dating back to the first transaction recorded to the blockchain, even if some state data associated with historical blocks is rarely accessed.

[0005] Since each blockchain node is responsible for processing the transaction volume of the entire blockchain network, for a blockchain network with a large number of nodes, the computational and storage burden of each blockchain node will be very high.

[0006] It is desirable to improve the processing of Merkle trees to make them faster and more efficient without affecting system performance and data integrity. According to the described embodiments, the processing of Merkle trees can be improved based on efficient data structures for processing world states and Merkle trees. Summary of the invention

[0007] Embodiments of the described subject matter may include one or more features, alone or in combination. For example, in one embodiment, a method for processing world state information associated with a blockchain is provided. The method includes providing a plurality of smart contracts associated with a plurality of user accounts, wherein each smart contract is associated with a corresponding blockchain managed by a corresponding blockchain network, and the blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network. The method includes providing a plurality of digital trees to maintain one or more world states associated with smart contracts and user accounts, wherein each world state stores state data associated with at least one of the user account or the smart contract. A first smart contract of the plurality of smart contracts includes a first code, the first code identifying first state data and a first digital tree of the plurality of digital trees for storing the first state data. The method also includes providing a virtual machine associated with the blockchain corresponding to the first smart contract, wherein the virtual machine is configured to execute the first smart contract so that the first state data is stored in the first digital tree.

[0008] In some embodiments, the virtual machine may include a smart contract compiler configured to compile the first smart contract into a first bytecode that can be executed by the virtual machine, wherein the compiler is configured to recognize and compile the first code so that the first bytecode, when executed by the virtual machine, causes the first state data to be stored in the first digital tree.

[0009] In some embodiments, the method may include providing a smart contract compiler, which is configured to compile the first smart contract into a first bytecode that can be executed by the virtual machine, wherein the compiler is configured to recognize and compile the first code so that the first bytecode, when executed by the virtual machine, causes the first state data to be stored in the first digital tree.

[0010] In some embodiments, the state data identified by the first code may include at least one of: (i) data regarding a state of a user account associated with the first smart contract, or (ii) data regarding a state of the first smart contract.

[0011] In some embodiments, the first smart contract may include a second code, the second code identifying second state data and a second digital tree in the plurality of digital trees for storing the second state data. The compiler may be configured to recognize and compile the first code and the second code so that the first bytecode, when executed by the virtual machine, causes the first state data to be stored in the first digital tree and the second state data to be stored in the second digital tree.

[0012] In some embodiments, the first digital tree and the second digital tree may, in combination, maintain a world state associated with a user account associated with the first smart contract.

[0013] In some embodiments, the first code may specify that state data associated with user accounts in a first geographic region is to be stored in the first digital tree, and the second code may specify that state data associated with user accounts in a second geographic region is to be stored in the second digital tree.

[0014] In some embodiments, the first smart contract may include a third code, the third code identifying third state data and a third digital tree in the plurality of digital trees for storing the third state data. The first digital tree, the second digital tree, and the third digital tree may be combined to maintain a world state associated with a user account associated with the first smart contract. The compiler may be configured to recognize and compile the first code, the second code, and the third code so that when the first bytecode is executed by the virtual machine, the first state data will be stored in the first digital tree, the second state data will be stored in the second digital tree, and the third state data will be stored in the third digital tree.

[0015] In some embodiments, the first digital tree, the second digital tree, and the third digital tree may, in combination, maintain a world state associated with a user account associated with the first smart contract.

[0016] In some embodiments, the first code may specify that status data associated with user accounts in a first geographic area is to be stored in the first digital tree, the second code may specify that status data associated with user accounts in a second geographic area is to be stored in the second digital tree, and the third code may specify that status data associated with user accounts in a third geographic area is to be stored in the third digital tree.

[0017] In some embodiments, a second smart contract among the plurality of smart contracts may include a fourth code, the fourth code identifying fourth state data and a fourth digital tree among the plurality of digital trees for storing the fourth state data. The first smart contract and the second smart contract may be associated with the same blockchain, and the first digital tree and the fourth digital tree may be combined to maintain a world state storing state data of user accounts associated with the first smart contract and the second smart contract. The compiler may be configured to compile the second smart contract into a second bytecode. The compiler may be configured to recognize and compile the fourth code so that the second bytecode causes the fourth state data to be stored in the fourth digital tree when executed by the virtual machine.

[0018] In some embodiments, the first code may include a first address of the first digital tree, and the compiler may be configured to compile the first smart contract into the first bytecode so that when the first bytecode is executed by the virtual machine, the first state data will be stored in the first digital tree having the first address.

[0019] In some embodiments, the first address may be represented by a constant value.

[0020] In some embodiments, the first address may be determined by a Boolean function.

[0021] In some embodiments, the first address may be determined by a mathematical function.

[0022] In some embodiments, the first address may be determined by a rule set comprising one or more rules.

[0023] In some embodiments, the first address can be determined during a first time period when the first smart contract is compiled.

[0024] In some embodiments, the first address may be determined during a second period of time during which the first bytecode is executed.

[0025] In some embodiments, the second code may include a second address of the second digital tree, and the compiler may be configured to compile the first smart contract into the first bytecode so that the first bytecode, when executed by the virtual machine, causes the second state data to be stored in the second digital tree having the second address.

[0026] In some embodiments, the second address may be represented by a constant value.

[0027] In some embodiments, the second address may be determined by a Boolean function.

[0028] In some embodiments, the second address may be determined by a mathematical function.

[0029] In some embodiments, the second address may be determined by a rule set comprising one or more rules.

[0030] In some embodiments, the second address may be determined at a first time period when compiling the second smart contract.

[0031] In some embodiments, the second address may be determined during a second period of time during which the second bytecode is executed.

[0032] In some embodiments, the third code may include a third address of the third digital tree, and the compiler may be configured to compile the first smart contract into the first bytecode so that the first bytecode, when executed by the virtual machine, causes the third state data to be stored in the third digital tree having the third address.

[0033] In some embodiments, the fourth code may include a fourth address of the fourth digital tree, and the compiler may be configured to compile the second smart contract into the second bytecode so that the second bytecode, when executed by the virtual machine, causes the fourth state data to be stored in the fourth digital tree having the fourth address.

[0034] In some embodiments, the method may include executing the compiler to generate at least one of the first bytecode or the second bytecode.

[0035] In some embodiments, the method may include executing the virtual machine and performing at least one of the following: storing the first state data in the first digital tree, storing the second state data in the second digital tree, storing the third state data in the third digital tree, or storing the fourth state data in the fourth digital tree.

[0036] In some embodiments, the method may include: determining a first root hash value of the first digital tree; determining a second root hash value of the second digital tree; and determining a world state root hash value based on the first root hash value and the second root hash value.

[0037] In some embodiments, the method may include: determining a third root hash value of the third digital tree; and determining the world state root hash value based on the first root hash value, the second root hash value, and the third root hash value.

[0038] In some embodiments, the world state root hash value may represent a digital fingerprint of a user account associated with the world state, or one or more states of one or more smart contracts.

[0039] In some embodiments, the first smart contract may specify that the first digital tree is stored at a first storage device and the second digital tree is stored at a second storage device.

[0040] In some embodiments, the first smart contract may specify that both the first digital tree and the second digital tree are stored at a first storage device.

[0041] In some embodiments, the method may include generating an index of the data stored in the first storage device, and storing the index in the first digital tree and the second digital tree.

[0042] In some embodiments, each digital tree may include, for example, a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0043] In another embodiment, a method for processing world state information associated with a blockchain is provided. The method includes providing a first smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain through consensus of blockchain nodes of the blockchain network; providing a first Merkle tree and a second Merkle tree to maintain a first world state associated with a first set of user accounts, wherein the first world state stores data about a current state of the first set of user accounts and a current state of the first smart contract. The first smart contract includes: a first code that specifies that first data is to be stored in the first Merkle tree, and a second code that specifies that second data is to be stored in the second Merkle tree.

[0044] In some embodiments, the first code may specify that data associated with user accounts in a first geographic region is to be stored in the first Merkle tree, and the second code may specify that data associated with user accounts in a second geographic region is to be stored in the second Merkle tree.

[0045] In some embodiments, the method may include providing a third Merkle tree, wherein the first Merkle tree, the second Merkle tree, and the third Merkle tree in combination maintain a world state associated with the user account. The first smart contract may include: the first code specifying that first data is to be stored in the first Merkle tree; the second code specifying that second data is to be stored in the second Merkle tree; and the third code specifying that third data is to be stored in the third Merkle tree.

[0046] In some embodiments, the first Merkle tree may have a first address, the second Merkle tree may have a second address, the first code may specify that the first data is to be stored in the Merkle tree having the first address, and the second code may specify that the second data is to be stored in the Merkle tree having the second address.

[0047] In some embodiments, the method may include providing a virtual machine configured to execute the first smart contract so that the first data is stored in the first Merkle tree and the second data is stored in the second Merkle tree.

[0048] In some embodiments, the method may include providing a compiler configured to compile the first smart contract into bytecode that can be executed by the virtual machine.

[0049] In some embodiments, the compiler may be part of the virtual machine.

[0050] In some embodiments, the first smart contract specifies that the first Merkle tree is stored at a first storage device and the second Merkle tree is stored at a second storage device.

[0051] In some embodiments, the first smart contract may specify that the first Merkle tree and the second Merkle tree are both stored at a first storage device.

[0052] In some embodiments, the method may include generating an index of the data stored in the first storage device, and storing the index in the first Merkle tree and the second Merkle tree.

[0053] In some embodiments, the method may include providing a second smart contract also associated with the blockchain, wherein the second smart contract includes third code specifying that third data is to be stored in the first Merkle tree.

[0054] In some embodiments, the first Merkle tree may store status information of user accounts based on a first geographic region, and the second Merkle tree may store status information of user accounts based on a second geographic region.

[0055] In some embodiments, the method may include providing a second smart contract associated with the blockchain, providing a third Merkle tree to maintain a second world state, the second world state storing data about a current state of the second smart contract, and determining a world state root hash value based on a first root hash value of the first Merkle tree and a second root hash value of the second Merkle tree.

[0056] In another embodiment, a computer-implemented method for processing one or more smart contracts associated with a blockchain is provided. The method includes: receiving a smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network; identifying a first code specifying first data and a first Merkle tree in the smart contract; identifying a second code specifying second data and a second Merkle tree in the smart contract; storing the first data in the first Merkle tree; and storing the second data in the second Merkle tree.

[0057] In some embodiments, the first code may specify that data associated with user accounts in a first geographic region is to be stored in the first Merkle tree, and the second code may specify that data associated with user accounts in a second geographic region is to be stored in the second Merkle tree.

[0058] In some embodiments, the method may include executing a virtual machine to execute the smart contract so that the first data is stored in the first Merkle tree and the second data is stored in the second Merkle tree.

[0059] In another embodiment, a method for processing world state information associated with a blockchain is provided. The method includes providing a smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain through consensus of blockchain nodes of the blockchain network; providing multiple Merkle trees to maintain a world state associated with a set of user accounts, wherein the world state stores data about a current state of the user accounts and a current state of the smart contract. The first smart contract includes a first code that specifies which of the multiple Merkle trees is used to store a data segment.

[0060] In some embodiments, the first code may include a modifier including an identification of a Merkle tree configured to store the data segment.

[0061] In some embodiments, the identification of the Merkle tree may include an address of the Merkle tree.

[0062] In some embodiments, the identifier of the Merkle tree may include a variable.

[0063] In some embodiments, the identification may be determined based on a mathematical function.

[0064] In some embodiments, the identification may be determined based on one or more rules.

[0065] In some embodiments, the method may include providing a compiler configured to recognize the decoration and compile the smart contract into bytecode executable by a virtual machine associated with the blockchain.

[0066] In some embodiments, the compiler may be part of the virtual machine.

[0067] In another embodiment, a system includes: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform any of the above methods.

[0068] In another embodiment, an apparatus includes multiple modules for performing any of the above methods.

[0069] In another embodiment, a system for processing world state information associated with a blockchain is provided. The system includes: a blockchain database configured to store a blockchain managed by a blockchain network, wherein the blockchain data is stored on the blockchain through the consensus of the blockchain nodes of the blockchain network, and the blockchain includes one or more blocks, wherein the one or more blocks store transaction data associated with a user account associated with the blockchain. The system includes a world state database, the world state database is configured to store a world state data structure including a first Merkle tree and a second Merkle tree, wherein the world state stores information about the state of the user account. The system includes a smart contract compiler, the smart contract compiler is configured to: receive a smart contract associated with the blockchain and the world state data structure; identify a first code specifying first data and the first Merkle tree in the smart contract; identify a second code specifying second data and the second Merkle tree in the smart contract; and compile the smart contract into bytecode. The system includes a virtual machine, the virtual machine is configured to execute the bytecode so that the virtual machine stores the first data in the first Merkle tree and stores the second data in the second Merkle tree.

[0070] In some embodiments, the compiler may be configured to: identify code in a smart contract, wherein the code identifies a data segment and one of multiple Merkle trees; and compile the smart contract code into bytecode so that when the bytecode is executed by the virtual machine, the virtual machine stores the data segment in the Merkle tree.

[0071] In some embodiments, the compiler can be configured to identify a constant value in the code of the smart contract, and the constant value represents the address of the Merkle tree or a pointer to the Merkle tree.

[0072] In some embodiments, the compiler can be configured to identify a variable in the code in the smart contract, and the variable represents the address of the Merkle tree or a pointer to the Merkle tree.

[0073] In some embodiments, the compiler can be configured to recognize code in the smart contract, and the code includes a function for identifying the Merkle tree.

[0074] In some embodiments, the compiler can be configured to recognize code in the smart contract, and the code includes a rule set for identifying the Merkle tree.

[0075] In some embodiments, the first Merkle tree may store status information of user accounts based on a first geographic region, and the second Merkle tree may store status information of user accounts based on a second geographic region.

[0076] In some embodiments, the compiler may be part of the virtual machine.

[0077] In another embodiment, a system for processing world state information associated with a blockchain is provided. The system includes: a blockchain database configured to store a blockchain managed by a blockchain network, wherein the blockchain data is stored on the blockchain through the consensus of the blockchain nodes of the blockchain network, and the blockchain includes one or more blocks, wherein the one or more blocks store transaction data associated with a user account associated with the blockchain. The system includes a world state database configured to store a world state data structure including a plurality of digital trees, wherein the world state stores information about the state of the user account. The system includes a smart contract database storing a plurality of smart contracts associated with the blockchain, wherein a first smart contract of the plurality of smart contracts includes a first code, wherein the first code identifies a first state data and a first digital tree of the plurality of digital trees for storing the first state data. The system includes a virtual machine associated with the blockchain corresponding to the first smart contract, wherein the virtual machine is configured to execute the first smart contract so that the first state data is stored in the first digital tree.

[0078] In some embodiments, the virtual machine may include a smart contract compiler configured to compile the first smart contract into a first bytecode that can be executed by the virtual machine, wherein the compiler is configured to recognize and compile the first code so that when the first bytecode is executed by the virtual machine, the first state data is stored in the first digital tree.

[0079] In some embodiments, the system may include a smart contract compiler configured to compile the first smart contract into a first bytecode that can be executed by the virtual machine, wherein the compiler is configured to recognize and compile the first code so that when the first bytecode is executed by the virtual machine, the first state data is stored in the first digital tree.

[0080] In some embodiments, the state data identified by the first code may include at least one of: (i) data regarding a state of a user account associated with the first smart contract, or (ii) data regarding a state of the first smart contract.

[0081] In some embodiments, the first smart contract may include a second code, the second code identifying second state data and a second digital tree in a plurality of digital trees for storing the second state data. The compiler may be configured to recognize and compile the first code and the second code so that the first bytecode causes the first state data to be stored in the first digital tree and the second state data to be stored in the second digital tree when executed by the virtual machine.

[0082] In some embodiments, the first digital tree and the second digital tree may, in combination, maintain a world state associated with a user account associated with the first smart contract.

[0083] In some embodiments, the first code may specify that state data associated with user accounts in a first geographic region is to be stored in the first digital tree, and the second code may specify that state data associated with user accounts in a second geographic region is to be stored in the second digital tree.

[0084] In some embodiments, the first smart contract may include a third code, the third code identifying third state data and a third digital tree in the plurality of digital trees for storing the third state data. The first digital tree, the second digital tree, and the third digital tree may be combined to maintain a world state associated with a user account associated with the first smart contract. The compiler may be configured to recognize and compile the first code, the second code, and the third code so that when the first bytecode is executed by the virtual machine, the first state data will be stored in the first digital tree, the second state data will be stored in the second digital tree, and the third state data will be stored in the third digital tree.

[0085] In some embodiments, the first digital tree, the second digital tree, and the third digital tree may be combined to maintain a world state associated with a user account associated with the first smart contract.

[0086] In some embodiments, the first code may specify that status data associated with user accounts in a first geographic region is to be stored in the first digital tree, the second code may specify that status data associated with user accounts in a second geographic region is to be stored in the second digital tree, and the third code may specify that status data associated with accounts of users in a third geographic region is to be stored in the third digital tree.

[0087] In some embodiments, a second smart contract among the plurality of smart contracts may include a fourth code, the fourth code identifying fourth state data and a fourth digital tree among the plurality of digital trees for storing the fourth state data. The first smart contract and the second smart contract may be associated with the same blockchain, and the first digital tree and the fourth digital tree may be combined to maintain a world state storing state data of user accounts associated with the first smart contract and the second smart contract. The compiler may be configured to compile the second smart contract into a second bytecode. The compiler may be configured to recognize and compile the fourth code so that the second bytecode causes the fourth state data to be stored in the fourth digital tree when executed by the virtual machine.

[0088] In some embodiments, the first code may include a first address of the first digital tree, and the compiler may be configured to compile the first smart contract into the first bytecode so that the first bytecode, when executed by the virtual machine, causes the first state data to be stored in the first digital tree having the first address.

[0089] In some embodiments, the first address may be represented by a constant value.

[0090] In some embodiments, the first address may be determined by at least one of a Boolean function or a mathematical function.

[0091] In some embodiments, the first address may be determined by a rule set comprising one or more rules.

[0092] In some embodiments, the first address may be determined during a first time period of compiling the first smart contract or during a second time period of executing the first bytecode.

[0093] In some embodiments, the second code may include a second address of the second digital tree, and the compiler may be configured to compile the first smart contract into the first bytecode so that the first bytecode, when executed by the virtual machine, causes the second state data to be stored in the second digital tree having the second address.

[0094] In some embodiments, the second address may be represented by a constant value.

[0095] In some embodiments, the second address may be determined by a Boolean function.

[0096] In some embodiments, the second address may be determined by a mathematical function.

[0097] In some embodiments, the second address may be determined by a rule set comprising one or more rules.

[0098] In some embodiments, the second address may be determined at a first time period when compiling the second smart contract.

[0099] In some embodiments, the second address may be determined during a second period of time during which the second bytecode is executed.

[0100] In some embodiments, the third code may include a third address of the third digital tree, and the compiler may be configured to compile the first smart contract into a first bytecode so that when the first bytecode is executed by the virtual machine, the third state data is stored in the third digital tree having the third address.

[0101] In some embodiments, the fourth code may include a fourth address of the fourth digital tree, and the compiler may be configured to compile the second smart contract into the second bytecode so that when the second bytecode is executed by the virtual machine, the fourth state data will be stored in the fourth digital tree having the fourth address.

[0102] In some embodiments, the system may include one or more computers at one or more locations and configured to: determine a first root hash value of the first digital tree; determine a second root hash value of the second digital tree; and determine a world state root hash value based on the first root hash value and the second root hash value.

[0103] In some embodiments, the one or more computers may be configured to: determine a third root hash value of the third digital tree; and determine the world state root hash value based on the first root hash value, the second root hash value, and the third root hash value.

[0104] In some embodiments, the world state root hash value may represent a digital fingerprint of the one or more states of a user account, one or more smart contracts associated with the world state.

[0105] In some embodiments, the first smart contract may specify that the first digital tree is stored at a first storage device and the second digital tree is stored at a second storage device.

[0106] In some embodiments, the first smart contract may specify that both the first digital tree and the second digital tree are stored at the first storage device.

[0107] In some embodiments, the system includes one or more computers at one or more locations and is configured to generate an index of the data stored in the first storage device and store the index in the first digital tree and the second digital tree.

[0108] In some embodiments, each digital tree may include at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0109] In another embodiment, a computer-implemented method for processing world state information associated with one or more blockchains is provided. The method includes providing a group world state comprising a plurality of shards, wherein each shard includes one or more world states, each world state stores information about a state of a user account associated with the world state, and each shard is associated with a blockchain comprising one or more blocks, wherein the one or more blocks store transaction data associated with a user account associated with the blockchain. The method includes dynamically modifying the number of shards in the group world state based on one or more criteria, including at least one of the following: (i) dividing one of the plurality of shards into two or more shards, (ii) merging two or more shards into one shard, (iii) adding one or more shards to the group world state, or (iv) removing one or more shards from the group world state. The method includes generating a root hash value of the group world state, wherein the root hash value represents a digital fingerprint of a state of a user account associated with a world state in a shard in the group world state.

[0110] In some embodiments, these general and specific aspects may be implemented using a system, method, or computer program, or any combination of a system, method, and computer program. Optionally, the aforementioned and other described embodiments may each include one or more of the following aspects:

[0111] In some embodiments, dynamically modifying the number of shards in the group world state based on one or more criteria includes dividing a first shard into a second shard and a third shard, wherein the second shard includes a second subset of the world state of the first shard, and the third shard includes a third subset of the world state of the first shard.

[0112] In some embodiments, dynamically modifying the number of shards in the group world state based on one or more criteria includes merging a second shard and a third shard to generate a first shard, wherein the first shard includes one or more world states of the second shard and one or more world states of the third shard.

[0113] In some embodiments, dynamically modifying the number of shards in the group world state based on one or more criteria includes adding one or more new shards to the group world state, wherein the one or more new shards include one or more world states not previously included in the group world state.

[0114] In some embodiments, dynamically modifying the number of shards in the group world state based on one or more criteria includes removing one or more shards from the group world state, including removing one or more world states in the one or more shards removed from the group world state.

[0115] In some embodiments, the method includes evaluating the one or more criteria at a system comprising one or more computers at one or more locations, and dividing one of the plurality of shards into two or more shards when it is determined that the one or more criteria are met.

[0116] In some embodiments, the method includes evaluating the one or more criteria at a system including one or more computers at one or more locations, and merging two or more shards into one shard upon determining that the one or more criteria are met.

[0117] In some embodiments, the method includes dynamically modifying resources allocated to the group world state based on the number of shards in the group world state.

[0118] In some embodiments, the method includes allocating more resources to the group world state in response to an increase in the number of shards in the group world state.

[0119] In some embodiments, the method includes allocating fewer resources to the group world state in response to a decrease in the number of shards in the group world state.

[0120] In some embodiments, the resource includes at least one of computing power, memory, data storage capacity, or data bandwidth.

[0121] In some embodiments, the one or more conditions include at least one of a quality of service metric, a computing power requirement, a memory capacity requirement, a data storage capacity requirement, or a data bandwidth requirement.

[0122] In some embodiments, the method includes determining at least one of: (i) a quality of service metric is below a threshold, (ii) a computing power requirement is not met, (iii) a memory capacity requirement is not met, (iv) a data storage capacity requirement is not met, or (v) a data bandwidth requirement is not met. The method includes: in response to the determination, dividing one of the plurality of shards into two or more shards, and allocating more resources to the combination of the two or more shards than to the one of the plurality of shards, wherein the resources include at least one of computing power, memory capacity, data storage capacity, or data bandwidth.

[0123] In some embodiments, the method includes determining at least one of: (i) a quality of service metric value is above a threshold, (ii) idle or excess computing power is above a threshold, (iii) available memory capacity is above a threshold, (iv) available data storage capacity is above a threshold, or (v) available data bandwidth is above a threshold. The method includes: in response to the determination, merging two or more shards into one shard, and allocating fewer resources to the merged single shard than the resources allocated to the two or more shards before the merging, wherein the resources include at least one of computing power, memory capacity, data storage capacity, or data bandwidth.

[0124] In some embodiments, each world state is maintained using at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a Bucket tree.

[0125] In some embodiments, dividing one of the plurality of shards into two or more shards includes dividing a first shard into a second shard and a third shard, the first shard including a first world state database, the first world state database including a first set of world states. Dividing the first shard into the second shard and the third shard includes: generating a first snapshot of the first shard, wherein the first snapshot includes a snapshot of the first world state database; trimming the first shard to generate the second shard, including removing one or more world states in the first world state database to generate a second world state database, the second world state database including a second subset of the one or more world states in the first shard. The method includes trimming the first snapshot of the first shard to generate the third shard, including removing one or more world states in the first world state database to generate a third world state database, the third world state database including a third subset of the one or more world states in the first shard, wherein the third subset of the one or more world states is different from the second subset of the one or more world states.

[0126] In some embodiments, dividing one of the plurality of shards into two or more shards includes dividing one of the plurality of shards into three or more shards.

[0127] In some embodiments, merging two or more shards into one shard includes merging a second shard and a third shard into a first shard. The second shard includes a second world state database, the second world state database includes a second set of world states storing state information associated with a second set of user accounts. The third shard includes a third world state database, the third world state database includes a third set of world states storing state information associated with a third set of user accounts. The first shard includes a first world state database, the first world state database includes a first set of world states, the first set of world states includes the second set of world states and the third set of world states, the first set of world states stores state information associated with a first set of user accounts, the first set of user accounts includes the second set of user accounts and the third set of user accounts.

[0128] In some embodiments, dividing one of the plurality of shards into two or more shards includes dividing a first shard into a second shard and a third shard. The first shard is associated with a first set of user accounts, the second shard is associated with a second set of user accounts, and the third shard is associated with a third set of user accounts. The second set of user accounts is a second subset of the first set of user accounts, the third set of user accounts is a third subset of the first set of user accounts, and the third subset of user accounts is different from the second subset of user accounts.

[0129] In some embodiments, the method includes associating user accounts with the world states based on characteristics of the user accounts, wherein each user account is associated with only one of the world states.

[0130] In some embodiments, the user account is associated with the world state based on characteristics of a user account identification.

[0131] In some embodiments, the user account is associated with the world state based on a predetermined byte or byte word of the user account identification.

[0132] In some embodiments, the group world state supports up to 2 n The user account whose user account identifier has a predetermined byte or byte word equal to m is associated with the mth world state, 1≤m≤2 n .

[0133] In some embodiments, the group world state supports up to 2 16=65536 world states, and the user account whose first two bytes of the user account identifier are equal to m is associated with the mth world state, 1≤m≤65536.

[0134] In some embodiments, the user account is associated with the world state based on a priority of the user account.

[0135] In some embodiments, the method includes providing a first set of one or more rules that specify one or more conditions under which a number of shards in a group world state is to be increased.

[0136] In some embodiments, the method includes providing a second set of one or more rules specifying one or more conditions under which the number of shards in the group world state is to be reduced.

[0137] In another embodiment, a computer-implemented method for processing world state information associated with one or more blockchains is provided. The method includes providing a first shard associated with a first set of user accounts, wherein the first shard includes a first blockchain database and a first world state database. The first blockchain database includes a first blockchain managed by a first blockchain network, wherein blockchain data is stored on the first blockchain by consensus of blockchain nodes of the first blockchain network. The first world state database includes a plurality of world states, each world state associated with a plurality of user accounts, each world state storing a current state of the user account associated with the world state. The method includes partitioning the first shard into a second shard and a third shard. The partitioning includes generating a first snapshot of the first shard, wherein the first snapshot includes a snapshot of the first blockchain database and a snapshot of the first world state database. The partitioning includes reducing the first shard to generate the second shard, including removing one or more world states in the first world state database of the first shard to generate a second world state database, the second world state database including a second subset of the one or more world states in the first shard. Reducing the first snapshot of the first shard to generate the third shard includes removing one or more world states in the first world state database of the first snapshot to generate a third world state database, the third world state database including a third subset of the one or more world states in the first shard, wherein the third subset of the one or more world states is different from the second subset of the one or more world states.

[0138] In some embodiments, the method includes allocating more resources to a combination of the second slice and the third slice than to the first slice after dividing the first slice into the second slice and the third slice.

[0139] In some embodiments, the first world state database is associated with a first group of user accounts, the second world state database is associated with a second group of user accounts, the third world state database is associated with a third group of user accounts, and the first group of user accounts includes the sum of the second group of user accounts and the third group of user accounts.

[0140] In some embodiments, the first world state database is associated with the first group of user accounts, the second world state database is associated with a second group of user accounts, and the third world state database is associated with a third group of user accounts, and the second group of user accounts does not overlap with the third group of user accounts.

[0141] In some embodiments, allocating more resources includes allocating at least one of more computing power, memory, data storage capacity, or data bandwidth.

[0142] In some embodiments, generating a snapshot of the first shard includes: generating a snapshot of the first shard using a virtual machine associated with the first shard.

[0143] In some embodiments, the consensus blockchain network includes: validating peer nodes that participate in a consensus process to determine whether to write data to the blockchain and non-validating peer nodes that do not participate in the consensus process. Generating a snapshot of the first shard includes generating the snapshot using the non-validating peer nodes.

[0144] In some embodiments, the consensus blockchain network includes: validating peer nodes that participate in a consensus process to determine whether to write data to the blockchain and non-validating peer nodes that do not participate in the consensus process. Generating a snapshot of the first shard includes increasing the number of validating peer nodes and generating the snapshot using the validating peer nodes.

[0145] In some embodiments, each of the multiple world states of the first world state database includes a root node. The first blockchain of the first blockchain database includes a first block, the first block includes a block header and a block body, the block header stores a first hash value, the first hash value is derived from a hash process of the hash value of the root node of the multiple world states of the first world state database, and the first hash value represents a digital fingerprint of the current state of the user account associated with the multiple world states of the first world state database.

[0146] In some embodiments, each of the multiple world states in the first world state database includes a root node, the first blockchain of the first blockchain database includes a first block, the first block includes a block header and a block body, and the block header stores a hash value of the root node of the world state in the first world state database.

[0147] In some embodiments, the second shard includes a second blockchain database including a second blockchain, the second blockchain storing transaction data associated with a user account associated with the second shard. The second blockchain includes a first block, the first block including a block body storing information about a transaction. Trimming the first shard includes: for user accounts not associated with a second subset of one or more world states in the second world state database, removing information related to transactions associated with the user account.

[0148] In some embodiments, the third shard includes a third blockchain database including a third blockchain, the third blockchain storing transaction data associated with a user account associated with the third shard. The third blockchain includes a first block, the first block including a block body storing information about a transaction. Reducing the first snapshot of the first shard includes: for a user account that is not associated with a third subset of one or more world states in the third world state database, removing information related to transactions associated with the user account.

[0149] In some embodiments, the third shard includes a third blockchain database including a third blockchain, the third blockchain storing transaction data associated with a user account associated with the third shard. The method includes dividing the third shard into a fourth shard and a fifth shard. The dividing includes: generating a second snapshot of the third shard, wherein the second snapshot includes a snapshot of the third blockchain database and a snapshot of the third world state database. The dividing includes: reducing the third shard to generate the fourth shard, including removing one or more world states in the third world state database of the third shard to generate a fourth world state database including a fourth subset of one or more world states in the third shard. The dividing includes: reducing the second snapshot of the third shard to generate the fifth shard, including removing one or more world states in the third world state database of the second snapshot to generate a fifth world state database, the fifth world state database including a fifth subset of one or more world states in the third shard, wherein the fifth subset of the one or more world states is different from the fourth subset of the one or more world states.

[0150] In some embodiments, the method includes allocating more resources to a combination of the fourth slice and the fifth slice than to the third slice.

[0151] In some embodiments, each world state is maintained using a digital tree comprising at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0152] In some embodiments, the method includes generating a group world state hash value representing the world state of the first shard and the second shard based on a hash value of a root node of a digital tree that maintains the world state of the first shard and the second shard.

[0153] In some embodiments, the method includes generating a simplified payment verification proof for a transaction associated with a user account by generating a first proof based on a path from a root node of a group world state to a root node of a shard world state, generating a second proof based on a path from the root node of the shard world state to a root node of a world state associated with the user account, and generating a third proof based on a path from the root node of the world state to a node representing the user account.

[0154] In another embodiment, a computer-implemented method for processing world state information associated with one or more blockchains is provided. The method includes providing a first shard of a blockchain ledger, wherein the first shard includes a first blockchain database and a first world state database, the first world state database includes a plurality of world states, and each world state stores a current state of a user account associated with the world state. The method includes generating a first copy of the first shard including a copy of the first blockchain database and a copy of the first world state database. The method includes generating a second shard by removing one or more world states in the first world state database of the first shard, wherein a second subset of the one or more world states in the first shard is retained in the second shard. The method includes generating a third shard by removing one or more world states in the first world state database in the first copy of the first shard, wherein a third subset of the one or more world states in the first shard is retained in the third shard, the third subset of the one or more world states being different from the second subset of the one or more world states.

[0155] In some embodiments, the method includes allocating more resources to a combination of the second slice and the third slice than to the first slice.

[0156] In another embodiment, a computer-implemented method for processing world state information associated with one or more blockchains is provided. The method includes: dividing a plurality of user accounts into at least a first group of user accounts and a second group of user accounts; and associating a first blockchain database and a first world state database with the first group of user accounts. The first blockchain database includes a first blockchain managed by a first blockchain network, wherein blockchain data is stored on the first blockchain by consensus of blockchain nodes of the first blockchain network. The first world state database includes a plurality of world states, each world state is associated with a subset of the first group of user accounts, and each world state stores a current state of the user account associated with the world state. The method includes associating a second blockchain database and a second world state database with the second group of user accounts. The second blockchain database includes a second blockchain managed by a second blockchain network, wherein blockchain data is stored on the second blockchain by consensus of blockchain nodes of the second blockchain network. The second world state database includes a plurality of world states, each world state is associated with a subset of the second group of user accounts, and each world state stores a current state of the user account associated with the world state. The method includes: generating a first hash value representing a digital fingerprint of a world state of the first world state database, wherein the first hash value is generated based on a root hash value of each world state in the first world state database. The method includes: generating a second hash value representing a digital fingerprint of a world state of the second world state database, wherein the second hash value is generated based on a root hash value of each world state in the second world state database. The method includes: storing the first hash value at a block header of a first block of the first blockchain; storing the second hash value at a block header of a first block of the second blockchain; and generating a group world state root hash value representing a digital fingerprint of the world state of the first world state database and the second world state database, wherein the group world state root hash value is generated based on the first hash value and the second hash value.

[0157] In another embodiment, a computer-implemented method for processing world state information associated with one or more blockchains is provided. The method includes dividing a plurality of user accounts into at least a first group of user accounts and a second group of user accounts. The method includes associating the first group of user accounts with a first blockchain database and a first world state database, wherein the first blockchain database stores a first blockchain, the first blockchain stores transaction data associated with the first group of user accounts, the first world state database includes a plurality of world states, and each world state is associated with a subset of the first group of user accounts. The method includes associating the second group of user accounts with a second blockchain database and a second world state database, wherein the second blockchain database stores a second blockchain, the second blockchain stores transaction data associated with the second group of user accounts, the second world state database includes a plurality of world states, and each world state is associated with a subset of the second group of user accounts. The method includes storing a first hash value representing a digital fingerprint of a world state in the first world state database at a block header of a first block of the first blockchain. The method includes storing a second hash value representing a digital fingerprint of a world state in the second world state database at a block header of a first block of the second blockchain. The method includes generating a group world state root hash value representing a digital fingerprint of a world state in the first world state database and the second world state database based on the first hash value and the second hash value.

[0158] In some embodiments, a computer-implemented method for processing world state information associated with one or more blockchains is provided. The method includes providing a group world state including a plurality of shards, wherein each shard includes a world state database. The world state database includes a plurality of world states, each world state storing information about a state of a user account associated with the world state, each shard being associated with a blockchain database including a blockchain comprising one or more blocks, wherein the one or more blocks store transaction data associated with a user account associated with the blockchain. A first shard of the plurality of shards includes a first world state database, the first world state database including a first set of world states storing state information about a first group of user accounts. A second shard of the plurality of shards includes a second world state database, the second world state database including a second set of world states storing state information about a second group of user accounts. The method includes merging the first shard and the second shard to generate a third shard, including merging the first world state database and the second world state database to generate a third world state database, the third world state database including a third set of world states, the third set of world states including the first set of world states and the second set of world states, wherein the third set of world states stores state information about the first group of user accounts and the second group of user accounts.

[0159] In some embodiments, each world state is maintained using a digital tree, the first group of world states is maintained using a first group of digital trees, the second group of world states is maintained using a second group of digital trees, and the third group of world states is maintained using a third group of digital trees, and the third group of digital trees includes the first group of digital trees and the second group of digital trees.

[0160] In some embodiments, each digital tree comprises at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0161] In some embodiments, the method includes determining that the first shard was generated by a split process, the split process including generating a snapshot of a fourth shard, reducing the fourth shard or the snapshot of the fourth shard to generate the first shard, and waiting for the fourth shard or the snapshot of the fourth shard to complete the reduction before merging the first shard and the second shard.

[0162] In some embodiments, the method includes allocating fewer resources to the third slice than the resources allocated to the first slice and the second slice combined.

[0163] In some embodiments, the resource includes at least one of computing power, memory, data storage capacity, or data bandwidth.

[0164] In some embodiments, the first shard is associated with a first blockchain database comprising a first blockchain, the first blockchain storing transaction data associated with the first set of user accounts, and the second shard is associated with a second blockchain database comprising a second blockchain, the second blockchain storing transaction data associated with the second set of user accounts. The method includes merging the first blockchain database and the second blockchain database to generate a third blockchain database comprising a third blockchain, the third blockchain storing transaction data associated with the first set of user accounts and the second set of user accounts.

[0165] In some embodiments, the third blockchain includes a first block storing information indicating that the third blockchain is generated by merging at least two blockchains.

[0166] In some embodiments, the first blockchain database includes a first data structure that facilitates searching of data in the first blockchain, the second blockchain database includes a second data structure that facilitates searching of data in the second blockchain, and the third blockchain database includes the first data structure and the second data structure that facilitate searching of data in the third blockchain database.

[0167] In some embodiments, the first blockchain database stores a first root hash value of the first set of world states, the second blockchain database stores a second root hash value of the second set of world states, and the third blockchain database stores a third root hash value of the third set of world states.

[0168] In another embodiment, a computer-implemented method for processing world state information associated with one or more blockchains is provided. The method includes providing a group world state including a plurality of shards, wherein each shard includes a world state database. The world state database includes a plurality of world states, each world state storing information about a state of a user account associated with the world state, and each shard is associated with a blockchain database including a blockchain containing one or more blocks, wherein the one or more blocks store transaction data associated with a user account associated with the blockchain. A first shard of the plurality of shards of the group world state includes a first world state database. The method includes: generating an intermediate shard by generating a snapshot of the first shard; removing one or more world states in the first shard to generate a second shard, the second shard including a second subset of the one or more world states in the first shard; and removing one or more world states in the intermediate shard to generate a third shard, the third shard including a third subset of the one or more world states in the first shard, wherein the third subset of the one or more world states is different from the second subset of the one or more world states.

[0169] In some embodiments, the method includes allocating more resources to a combination of the second slice and the third slice than to the first slice.

[0170] In another embodiment, a computer-implemented method for processing world state information associated with one or more blockchains is provided. The method includes providing a group world state comprising a plurality of shards, wherein each shard includes one or more world states, each world state stores information about a state of a user account associated with the world state, and each shard is associated with a blockchain comprising one or more blocks, wherein the one or more blocks store transaction data associated with the user account associated with the blockchain. The method includes dynamically modifying the number of shards in the group world state based on a comparison result of a consensus process at a first consensus node with a consensus process at one or more other consensus nodes; and generating a root hash value of the group world state, wherein the root hash value represents a digital fingerprint of a user account state associated with a world state in a shard in the group world state.

[0171] In some embodiments, dynamically modifying multiple shards in the group world state includes at least one of the following: (i) splitting one of the multiple shards into two or more shards, (ii) merging two or more shards into one shard, (iii) adding one or more new shards to the group world state, or (iv) removing one or more shards from the group world state.

[0172] In some embodiments, dynamically modifying the number of shards in the group world state includes increasing the number of shards in the group world state if consensus processing at the first consensus node is slower than consensus processing at one or more other consensus nodes by a first threshold.

[0173] In some embodiments, dynamically modifying the number of shards in the group world state includes reducing the number of shards in the group world state if consensus processing at the first consensus node is faster than consensus processing at one or more other consensus nodes by a second threshold.

[0174] In some embodiments, the method includes providing a first set of one or more rules that specify one or more conditions under which a number of shards in a group world state is to be increased.

[0175] In some embodiments, the method includes providing a second set of one or more rules that specify one or more conditions under which a number of shards in the group world state is to be reduced.

[0176] In some embodiments, the method includes determining a first speed of consensus processing at the first consensus node, and determining a second speed of consensus processing at one or more other consensus nodes. The method includes comparing the first speed of consensus processing at the first consensus node and the second speed of consensus processing at the one or more other consensus nodes; and generating a comparison result of the consensus processing at the first consensus node and the consensus processing at the one or more other consensus nodes.

[0177] In another embodiment, a system includes: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform any of the above methods.

[0178] In another embodiment, an apparatus includes multiple modules for performing any of the above methods.

[0179] In another embodiment, a system for processing world state information associated with one or more blockchains is provided. The system includes: a blockchain-based application module configured to provide services to users associated with user accounts; and a blockchain ledger including at least one blockchain and a group world state including multiple shards, wherein each shard includes a world state database, the world state database includes multiple world states, each world state is configured to store information about the state of the user account associated with the world state, and each shard is associated with a blockchain database including a blockchain containing one or more blocks, wherein the one or more blocks store transaction data associated with the user account associated with the blockchain. The system includes: a blockchain ledger modification module configured to dynamically modify the number of shards in the group world state based on one or more criteria, including at least one of the following: (i) dividing one of the multiple shards into two or more shards, (ii) merging two or more shards into one shard, (iii) adding one or more new shards to the group world state, or (iv) removing one or more shards from the group world state.

[0180] In some embodiments, the system includes a root hash value generation module configured to generate a root hash value of the group world state based on a root hash value of a world state in the group world state.

[0181] In some embodiments, the system includes a rule set database including a first set of one or more rules specifying one or more conditions for increasing the number of shards in the group world state.

[0182] In some embodiments, the system includes a rule set database including a second set of one or more rules specifying one or more conditions for reducing the number of shards in the group world state.

[0183] In another embodiment, a system for processing world state information associated with one or more blockchains is provided. The system includes: a blockchain-based application module configured to provide services to users associated with user accounts. The system includes: a blockchain ledger, the blockchain ledger including at least one blockchain and a group world state including multiple shards, wherein each shard includes a world state database. The world state database includes multiple world states, each world state is configured to store information about the state of a user account associated with the world state, and each shard is associated with a blockchain database including a blockchain containing one or more blocks, wherein the one or more blocks store transaction data associated with the user account associated with the blockchain. The system includes: a blockchain ledger modification module configured to dynamically modify the number of shards in the group world state based on a comparison result of a consensus process at the system with a consensus process at one or more other consensus nodes.

[0184] In some embodiments, the blockchain ledger modification module is configured to dynamically modify the number of shards in the group world state, including at least one of the following: (i) dividing one of the multiple shards into two or more shards, (ii) merging two or more shards into one shard, (iii) adding one or more new shards to the group world state, or (iv) removing one or more shards from the group world state.

[0185] In some embodiments, the system includes a rule set database including a first set of one or more rules specifying one or more conditions for increasing the number of shards in the group world state.

[0186] In some embodiments, the system includes a rule set database including a second set of one or more rules specifying one or more conditions for reducing the number of shards in the group world state.

[0187] It should be understood that the method described herein may include any combination of the various aspects and features described herein. That is, the method described herein is not limited to the combination of the various aspects and features specifically described herein, but also includes any combination of the various aspects and features provided.

[0188] The details of one or more embodiments of the present invention will be set forth in the accompanying drawings and the following description. Other features and advantages of the present invention will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0189] Figure 1is a diagram showing an example of an environment that can be used to implement embodiments herein.

[0190] Figure 2 is a diagram showing an example of an architecture according to embodiments herein.

[0191] Figure 3 is a diagram of a system for providing services to users and storing related transaction data and state information in the blockchain and world state.

[0192] Figure 4 is a diagram of the group world state design.

[0193] Figure 5 and Figure 6 is a diagram of an example of a shard expansion process.

[0194] Figure 7 and Figure 8 is a diagram of an example of shard shrinking processing.

[0195] Fig. 9 is a diagram showing an example of a world state storing state data for user accounts and smart contracts.

[0196] Fig.10 is a diagram of an example of a smart contract.

[0197] Fig.11 is a diagram of an example of the association of a smart contract and a Merkle tree.

[0198] Fig.12 and Fig.13 is a diagram of an example of a smart contract.

[0199] Fig.14 is a diagram of an example of the association of a smart contract and a Merkle tree.

[0200] Figures 15 to 26 are examples of processes that may be performed according to embodiments herein.

[0201] Figures 27 to 37 is an example of a module of an apparatus according to an embodiment of the present invention.

[0202] Fig.38 are examples of processes that may be performed according to embodiments herein.

[0203] Fig.39 is an example of a module of an apparatus according to an embodiment of the present invention.

[0204] Fig.40 is a diagram of a system for providing services to users and storing related transaction data and state information in the blockchain and world state.

[0205] Fig.41are examples of processes that may be performed according to embodiments herein.

[0206] Fig.42 is an example of a module of an apparatus according to an embodiment of the present invention.

[0207] Like reference numbers and designations throughout the various drawings represent like elements. DETAILED DESCRIPTION

[0208] This document describes techniques for implementing a group world state to store state information of user accounts associated with one or more blockchains, which are used to store transactions associated with services provided to users. The group world state includes multiple shards or partitions, each of which stores state information for a subset of the entire user account. The number of shards or partitions in the group world state can be dynamically increased or decreased based on the computing resources required to provide high-quality services to users. In some embodiments, a consensus node in a blockchain network can dynamically adjust the number of shards or partitions in the group world state to modify the speed of the consensus processing based on the current speed of the consensus processing relative to other consensus nodes. Adjustments to the shards or partitions of the group world state can be implemented with short downtime to reduce interruptions in services provided to users.

[0209] For example, the group world state can be used for any blockchain system or application with a large number of users and a large number of transactions between users. Examples of such blockchain systems or applications include, but are not limited to, online payment systems, online shopping systems, business-to-business systems, logistics systems, warehouse inventory systems, financial systems, stock exchange systems, systems for implementing distributed identification (described in PCT application PCT / CN2020 / 075272 filed on February 14, 2020), platforms for providing blockchain-based judicial services (described in U.S. application Ser. No. 16 / 714,455 filed on December 13, 2019), systems for providing standby letters of credit for blockchain-based credit services, and other blockchain-based systems. The present invention relates to a system for providing a blockchain-based customs clearance service (described in PCT application PCT / CN2020 / 094951 filed on June 8, 2020), a medical record system, an import and export processing system, an online education system, an online gaming system, an online travel processing system, a music streaming system, a video streaming system, an online media system, a social media system, an online food ordering system, a ride-hailing system, an online transportation processing system, and a cryptocurrency system. The entire contents of PCT application PCT / CN2020 / 075272, U.S. application Ser. No. 16 / 714,455, PCT application PCT / CN2020 / 074242, and PCT application PCT / CN2020 / 094951 are incorporated by reference.

[0210] For example, an online payment system may have hundreds of millions or billions of user accounts, with billions or trillions of transactions occurring each year. Transaction records and user account state information are stored in the blockchain and the world state. The world state describes the state of the ledger at a given point in time. The world state stores values ​​that represent the current state of a user account, for example, how many tokens a user account can use. As the online payment system grows, the system may add millions of new user accounts each year, and the data stored in the blockchain and world state also grows. For example, the online payment system may initially have a single blockchain and a single world state to store transaction data and user account state information, and one computer server is allocated to support the blockchain and world state associated with a user account located in Shanghai, China.

[0211] As the number of users in Shanghai grows, the online payment system may divide the blockchain and the world state into two shards. In some examples, the operator may evaluate the computing resources and determine whether to divide the blockchain and the world state into two shards. In some examples, the system includes an evaluation module that automatically evaluates the use of computing resources and determines whether to divide the blockchain and the world state into two shards. The first shard of the blockchain and the world state may store transaction data and user account status information associated with a user account located in Pudong, and the second shard of the blockchain and the world state may store transaction data and user account status information associated with a user account located in Puxi. For example, the system allocates a first computer server to support the first shard of the blockchain and the world state, and allocates a second computer server to support the second shard of the blockchain and the world state.

[0212] For example, the first group of users 334 may be located in Pudong, and the second group of users 336 may be located in Puxi. The first shard of the blockchain and world state may store transaction data and user account status information of the first group of users 334, and the second shard of the blockchain and world state may store transaction data and user account status information of the second group of users 336.

[0213] As the number of users in Shanghai grows further, the online payment system can further divide the blockchain and the world state into multiple shards, the number of which is equal to the number of districts in Shanghai, for example, wherein each shard of the blockchain and the world state can store transaction data and user account status information associated with user accounts located in the corresponding district of Shanghai. For example, the online payment system allocates multiple computer servers to support multiple shards of the blockchain and the world state, wherein each computer server supports a corresponding shard. The computer servers can be physical servers or virtual servers, such as those in a cloud computing system. As the number of user accounts and transactions increases, the various computing resources required by the online payment system also increase. Computing resources can include, for example, computing power, storage capacity, data storage capacity, and data bandwidth.

[0214] For example, an Internet shopping platform can provide services to buyers and sellers located around the world. Initially, the shopping platform may have users in China, and a computer server located in China may be allocated to support the blockchain and world state for storing transaction data and user account status information associated with users located in China. The shopping platform can be expanded to provide services to users located in the United States, Japan, and Germany. The shopping platform can divide the blockchain and world state into four shards. The first shard of the blockchain and world state is used to store transaction data and user account status information associated with users located in China. The second shard of the blockchain and world state is used to store transaction data and user account status information associated with users located in the United States. The third shard of the blockchain and world state is used to store transaction data and user account status information associated with users located in Japan. The fourth shard of the blockchain and world state is used to store transaction data and user account status information associated with users located in Germany. The shopping platform can allocate a computer server located in China to support the second shard, a computer server located in the United States to support the first shard, a computer server located in Japan to support the third shard, and a computer server located in Germany to support the fourth shard.

[0215] Described herein are techniques for assisting and / or modifying blockchain-based systems (e.g., online payment systems and online shopping systems) to manage the growth in size and complexity of blockchain data structures and world states used to store transaction data and user account state information while maintaining a high quality of service to users.

[0216] For example, this paper describes techniques for implementing dynamic blockchain network data expansion or contraction when blockchain nodes are added or removed. Sharding is a blockchain partitioning technique that can be used to divide a single logical data set and store it in multiple databases. Multiple shards can be used to horizontally expand the data storage capacity of a blockchain network. A group world state scheme is provided, in which a world state tree is generated for each shard. This design provides low computational complexity and storage space consumption while maintaining a stable root hash, which accommodates the expansion or contraction of the blockchain network storage capacity.

[0217] For example, this paper describes a new Merkle tree design that does not rely on a one-to-one relationship between a Merkle tree and a smart contract. A smart contract can correspond to multiple Merkle trees, and each smart contract can store a mapping table that records multiple Merkle trees that the smart contract can access. Multiple Merkle trees associated with the same smart contract can correspond to the same storage instance, and each Merkle tree can correspond to a unique address. When writing the program code of a smart contract, a modifier can be added before each variable to indicate that the variable will be stored in the Merkle tree specified by the modifier. The modifier can indicate the unique address of the Merkle tree, which in turn indicates the Merkle tree instance stored in the data storage. Under this tree structure, the programming of smart contracts can be more flexible, and the data of the world state can be traversed more efficiently.

[0218] The technology described in this article produces several technical effects. Blockchain systems or applications using group world state technology can have high service quality and reliability while using computing resources efficiently. The computing resources (e.g., computing power, storage capacity, data storage capacity, data bandwidth) allocated to the blockchain system or application can be dynamically adjusted (e.g., increased or decreased) according to the needs of the blockchain system or application. The adjustment of computing resources can be performed without interrupting or only slightly interrupting the services provided to users. Consensus nodes can dynamically adjust the use of computing resources to increase or decrease the speed of consensus processing so as to roughly match the consensus processing speed of other consensus nodes, thereby using computing resources more efficiently. The processing speed of smart contracts can be improved. The computing resources allocated for executing smart contracts can be used more efficiently.

[0219] The technology described in this article can produce further technical effects. For example, smart contracts are not fixedly bound to a single Merkle tree. Instead, smart contracts can be associated with multiple Merkle trees, allowing a large amount of state data associated with the smart contract to be stored. This also makes the storage of data associated with smart contracts more flexible, allowing different types of data with different priorities to be stored in different Merkle trees, which can have different quality of service levels to allow the system to provide higher quality of service to process higher priority data. The association between smart contracts and Merkle trees can be adjusted dynamically.

[0220] To provide further background for the embodiments of the present invention, as described above, a distributed ledger system (DLS), which may also be referred to as a consensus network (e.g., composed of peer-to-peer nodes) and a blockchain network, enables participating entities to conduct transactions and store data securely and immutably. Although the term blockchain is often associated with a specific network and / or use case, blockchain is generally used herein to refer to a DLS without reference to any specific use case.

[0221] Blockchain is a data structure that stores transactions in a way that transactions cannot be tampered with. Therefore, the transactions recorded on the blockchain are reliable and trustworthy. The blockchain includes one or more blocks. Each block in the chain is linked to the previous block by the cryptographic hash value of the previous block immediately before it in the chain. Each block also includes a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been verified by nodes in the blockchain network are hashed and compiled into a tree-shaped data structure or digital tree, which can be, for example, a Merkle tree. The Merkle tree is a data structure in which the data at the leaf nodes of the tree are hashed, and all hash values ​​in each branch of the tree are concatenated at the root of the branch. This process continues along the tree until the root of the entire tree, where a hash value representing all the data in the tree is stored. The hash value can be quickly verified by determining whether the hash value of the transaction claimed to be stored in the tree is consistent with the structure of the tree.

[0222] A blockchain is a decentralized or at least partially decentralized data structure for storing transactions, and a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains by broadcasting, verifying, and confirming transactions. As described above, a blockchain network can be provided as a public blockchain network, a private blockchain network, or a consortium blockchain network. The embodiments of this document are further described in detail herein with reference to a consortium blockchain network. However, it is contemplated that the embodiments of this document can be implemented in any suitable type of blockchain network.

[0223] Typically, a consortium blockchain network is private among participating entities. In a consortium blockchain network, the consensus process is controlled by a set of authorized nodes, which may be referred to as consensus nodes, and one or more consensus nodes are operated by the corresponding entity (e.g., financial institution, insurance company). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) may operate a consortium blockchain network, with each entity operating at least one node in the consortium blockchain network.

[0224] In some examples, in a consortium blockchain network, a global blockchain is provided as a blockchain replicated across all nodes. That is, all consensus nodes are in full consensus with respect to the global blockchain. In order to reach consensus (e.g., agree to add a block to the blockchain), a consensus protocol is implemented within the consortium blockchain network. For example, the consortium blockchain network can implement a practical Byzantine fault tolerance (PBFT) consensus, which will be described in further detail below.

[0225] Figure 1 1 is a diagram showing an example of an environment 100 that can be used to perform embodiments of the present invention. In some examples, the environment 100 enables entities to participate in the alliance blockchain network 102. The environment 100 includes computing systems 106, 108 and a network 110. In some examples, the network 110 includes a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and back-end systems. In some examples, the network 110 can be accessed through a wired and / or wireless communication link. In some examples, the network 110 enables communication with the alliance blockchain network 102 and communication within the alliance blockchain network 102. Typically, the network 110 represents one or more communication networks. In some cases, the computing systems 106, 108 can be nodes of a cloud computing system (not shown), or each of the computing systems 106, 108 can be a separate cloud computing system, which includes multiple computers interconnected by a network and used as a distributed processing system.

[0226] In the depicted example, computing systems 106, 108 may each include any suitable computing device capable of participating as a node in consortium blockchain network 102. Examples of computing devices include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smart phones. In some examples, computing systems 106, 108 host one or more computer-implemented services for interacting with consortium blockchain network 102. For example, computing system 106 may host a computer-implemented service for a first entity (e.g., user A), such as a transaction management system used by the first entity to manage its transactions with one or more other entities (e.g., other users). Computing system 108 may host a computer-implemented service for a second entity (e.g., user B), such as a transaction management system used by the second entity to manage its transactions with one or more other entities (e.g., other users). Figure 1 In the example of , the consortium blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing systems 106 , 108 provide nodes of a first entity and a second entity participating in the consortium blockchain network 102 , respectively.

[0227] Figure 2An example of an architecture 200 according to an embodiment of the present invention is shown. The exemplary conceptual architecture 200 includes participant systems 202, 204, 206 corresponding to participant A, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in a blockchain network 212 provided as a peer-to-peer network, which includes multiple nodes 214, at least some of which record information in an unalterable manner in a blockchain 216. As further detailed herein, although a single blockchain 216 is schematically depicted in the blockchain network 212, multiple copies of the blockchain 216 are provided and maintained on the blockchain network 212.

[0228] In the example shown, each participant system 202, 204, 206 is provided by or on behalf of participant A, participant B, and participant C, respectively, and serves as a corresponding node 214 in the blockchain network. As used herein, a node generally refers to an individual system (e.g., a computer, a server) that is connected to the blockchain network 212 and enables the corresponding participant to participate in the blockchain network. Figure 2 In the example of , a participant corresponds to each node 214. However, it is contemplated that a participant may operate multiple nodes 214 within the blockchain network 212, and / or multiple participants may share a node 214. In some examples, the participant systems 202, 204, 206 communicate with or through the blockchain network 212 using a protocol (e.g., Hypertext Transfer Protocol Secure (HTTPS)) and / or using remote procedure calls (RPCs).

[0229] The nodes 214 may have different levels of participation within the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miner nodes that add blocks to the blockchain 216), while other nodes 214 do not participate in this consensus process. As another example, some nodes 214 store a complete copy of the blockchain 216, while other nodes 214 store only a partial copy of the blockchain 216. For example, data access permissions may limit the blockchain data that a corresponding participant stores within their corresponding system. Figure 2 In the example of FIG. 2 , participant systems 202 , 204 , and 206 store complete copies 216 ′, 216 ″, and 216 ′″ of blockchain 216 , respectively.

[0230] Blockchain (e.g. Figure 2The blockchain 216) consists of a chain of blocks, each of which stores data. Examples of data include transaction data representing a transaction between two or more participants. Although "transaction" is used herein by way of non-limiting example, it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, videos, audio). Examples of transactions may include, but are not limited to, the exchange of valuables (e.g., assets, products, services, currencies). Transaction data is stored in an unalterable manner in the blockchain. That is, the transaction data cannot be changed.

[0231] Before storing the transaction data in the block, the transaction data is hashed. Hashing is the process of converting the transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is impossible to un-hash the hash value to obtain the transaction data. Hashing ensures that even if the transaction data is slightly changed, it will result in a completely different hash value. In addition, as mentioned above, the hash value has a fixed length. That is, regardless of the size of the transaction data, the length of the hash value is fixed. Hashing includes processing the transaction data through a hash function to generate a hash value. Examples of hash functions include, but are not limited to, the Secure Hash Algorithm (SHA)-256, which outputs a 256-bit hash value.

[0232] The transaction data of multiple transactions are hashed and stored in a block. For example, the hashes of two transactions are provided and they themselves are hashed to provide another hash. This process is repeated until a single hash is provided for all transactions to be stored in a block. This hash is called the Merkle root hash and is stored in the header of the block. Changes in any transaction will cause its hash to change and ultimately the Merkle root hash to change.

[0233] Blocks are added to the blockchain through a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol and perform work to add blocks to the blockchain. Such nodes are called consensus nodes. The PBFT introduced above is used as a non-limiting example of a consensus protocol. Consensus nodes execute the consensus protocol to add transactions to the blockchain and update the overall state of the blockchain network.

[0234] In more detail, the consensus node generates a block header, hashes all transactions in the block, and combines the hashes in pairs to generate further hashes until a single hash (Merkle root hash) is provided for all transactions in the block. This hash is added to the block header. The consensus node also determines the hash of the latest block in the blockchain (i.e., the last block added to the blockchain). The consensus node also adds a nonce value and a timestamp to the block header.

[0235] In general, PBFT provides practical Byzantine state machine replication that tolerates Byzantine faults (e.g., faulty nodes, malicious nodes). This is achieved by assuming in PBFT that failures will occur (e.g., assuming that there are independent node failures and / or manipulated messages sent by consensus nodes). In PBFT, consensus nodes are provided in a sequence that includes a primary consensus node and a backup consensus node. The primary consensus node is changed periodically. Transactions are added to the blockchain by all consensus nodes within the blockchain network reaching a consensus on the world state of the blockchain network. In this process, messages are transmitted between consensus nodes, and each consensus node proves that the message is received from a designated peer node and verifies that the message has not been modified during transmission.

[0236] In PBFT, the consensus protocol is provided in multiple stages with all consensus nodes starting from the same state. First, the client sends a request to the primary consensus node to invoke a service operation (e.g., execute a transaction within the blockchain network). In response to receiving the message, the primary consensus node multicasts the request to the backup consensus nodes. The backup consensus nodes execute the request, and each node sends a reply to the client. The client waits until a threshold number of replies are received. In some examples, the client waits until f+1 replies are received, where f is the maximum number of faulty consensus nodes that can be tolerated within the blockchain network. The end result is that a sufficient number of consensus nodes agree on the order in which records are added to the blockchain, and the record is either accepted or rejected.

[0237] In some blockchain networks, cryptography is used to maintain the privacy of transactions. For example, if two nodes want to keep a transaction private so that other nodes in the blockchain network cannot see the details of the transaction, the two nodes can encrypt the transaction data. Examples of encryption include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to encryption that uses a single key to both encrypt (generate ciphertext from plaintext) and decrypt (generate plaintext from ciphertext). In symmetric encryption, the same key can be used for multiple nodes, so each node can encrypt / decrypt transaction data.

[0238] Asymmetric encryption uses key pairs, each of which consists of a private key and a public key, where the private key is known only to the corresponding node and the public key is known to any or all other nodes in the blockchain network. A node can encrypt data using the public key of another node, and the encrypted data can be decrypted using the private key of the other node. For example, referring again to Figure 2 , participant A can use participant B's public key to encrypt data and send the encrypted data to participant B. Participant B can use its private key to decrypt the encrypted data (ciphertext) and extract the original data (plaintext). Messages encrypted using a node's public key can only be decrypted using that node's private key.

[0239] Asymmetric cryptography is used to provide digital signatures, which allow participants in a transaction to confirm the other participants in the transaction and the validity of the transaction. For example, a node can digitally sign a message, and another node can confirm that the message was sent by participant A based on the digital signature of participant A. Digital signatures can also be used to ensure that the message has not been tampered with during transmission. For example, again referring to Figure 2 , Participant A will send a message to Participant B. Participant A generates a hash value of the message and then encrypts the hash value using its private key to provide a digital signature that is an encrypted hash value. Participant A appends the digital signature to the message and sends the message with the digital signature to Participant B. Participant B decrypts the digital signature using Participant A's public key and extracts the hash value. Participant B hashes the message and compares the hash values. If the hash values ​​are the same, Participant B can confirm that the message is indeed from Participant A and has not been tampered with.

[0240] Some blockchain systems enable blockchain contracts (also known as smart contracts) to be executed through blockchain transactions. A blockchain transaction can be, for example, a signed message that originates from a blockchain account, is transmitted by a blockchain network, and is recorded in a blockchain. A blockchain contract can be written to implement various functions, for example, to add data to a blockchain account and / or to change data in a blockchain. Smart contracts do not have to be related to the traditional concept of a contract, but can be any type of computer program. The blockchain can be maintained and updated by executing various blockchain transactions. In some embodiments, when a blockchain transaction involves a blockchain contract, the blockchain node can execute the blockchain contract locally in its respective virtual machine (VM). In order to process a blockchain contract, each blockchain node of the blockchain network can execute a corresponding virtual machine and execute the same instructions in the blockchain contract. A virtual machine is a software simulation of a computer system based on a computer architecture and provides the functionality of a physical computer. A virtual machine in a blockchain environment can be understood as a system intended to be used as an operating environment for a blockchain contract.

[0241] A specific blockchain node that successfully mines a new block of the proposed blockchain transaction according to the consensus rules can package the new block into its local copy of the blockchain and multicast the result to other blockchain nodes. The specific blockchain node can be the blockchain node that first successfully completes the verification, obtains the verification privilege, or is selected based on other consensus rules. Other blockchain nodes can follow the same execution order performed by the specific blockchain node to locally execute the blockchain transaction in the new block, verify the execution results with each other (for example, by performing hash calculations), and synchronize their blockchain copies with the blockchain copy of the specific blockchain node. By updating their local copies of the blockchain, other blockchain nodes can similarly write such information in the blockchain transaction to their respective local storage. Blockchain contracts can be deployed on the blockchain using the above method.

[0242] The deployed blockchain contract may have an address at which the deployed contract may be accessed. The blockchain node may call the deployed blockchain contract by inputting specific parameters to the blockchain contract. In some embodiments, the user terminal may request to call the deployed blockchain contract to perform various operations. For example, data stored in the deployed blockchain contract may be retrieved, data may be added to the deployed blockchain contract, and / or a financial transaction specified in the deployed blockchain contract may be executed.

[0243] The invention described herein relates to a group world state for storing state data of user accounts associated with one or more blockchains, the one or more blockchains being used to store transactions associated with services provided to users. The group world state includes one or more shards or partitions, and the system is configured to dynamically adjust the number of shards or partitions to achieve efficient utilization of resources to maintain a high quality of service for users.

[0244] In some embodiments, a data structure such as a modified Merkle Patricia tree is used to maintain the world state of user accounts. As the number of users increases, the data structure also increases, and the number of nodes, branches, and paths also increases. The data stored in the data structure is processed more slowly, the system's ability to respond to user requests is reduced, and the quality of service is reduced. The present invention provides a solution to the problem by enabling resources to be dynamically allocated to one or more data structures for maintaining one or more world states for storing user account state data.

[0245] Techniques for implementing a blockchain-based system 300 are described below to allow efficient management of computing resources for maintaining a group world state that stores user account state information associated with one or more blockchains. Figure 3An example of an environment 302 is shown in which users (e.g., 304 and 306) access services provided by the system 300 through a blockchain-based application module 308. The application module 308 can provide services such as online payment services, online shopping services, business-to-business services, logistics services, warehouse inventory services, financial services, stock exchange services, distributed identity support services (described in PCT application PCT / CN2020 / 075272 filed on February 14, 2020), blockchain-based judicial services (described in U.S. application 16 / 714,455 filed on December 13, 2019), blockchain-based credit services, standby letter of credit services (described in PCT application PCT / CN2020 / 074242 filed on February 3, 2020), blockchain-based customs clearance services (described in PCT application PCT / CN2020 / 094951 filed on June 8, 2020), medical record services, import and export processing services, online education services, online gaming services, online travel processing services, music streaming services, video streaming services, online media services, social media services, online food ordering services, taxi services, online transportation processing services, and cryptocurrency services.

[0246] The system 300 stores transaction records and user account status information in a distributed blockchain ledger. Typically, a blockchain ledger includes two parts. The first part includes the world state, which stores the latest user account status information in the ledger as, for example, key-value pairs. The second part includes blockchain records of all transactions. The blockchain ledger is maintained by a blockchain network, which can be, for example, the consensus blockchain network described above. The consensus nodes of the blockchain network receive status updates in the form of new blocks, use blocks and world states to confirm (or commit) transactions, and update the world state and add transaction logs to the blockchain after reaching consensus.

[0247] In some embodiments, the blockchain ledger is maintained by one or more blockchain networks (e.g., 314, 316). Figure 1 to Figure 2 Describes the operation of a blockchain network. Figure 1 and Figure 2 Although the world state is not explicitly shown in the figure, it should be understood that the blockchain network maintains both the blockchain and the corresponding world state.

[0248] System 300 includes a local copy of a blockchain ledger 320, which includes a blockchain database 322 and a world state database 324. There are many ways to implement a blockchain database and a world state database. In the following example, we assume that each shard includes a blockchain database and a world state database. Each blockchain database stores a blockchain, and each world state database can store one or more world states. For example, blockchain database 322 stores a local copy of a blockchain maintained by a blockchain network. World state database 324 stores a local copy of a world state maintained by a blockchain network.

[0249] Typically, when users (e.g., 304 and 306) conduct transactions using services provided by the blockchain-based application system 300, the system 300 generates data, such as transaction records and user account status information, which are stored in the distributed blockchain ledger 320. For the purpose of illustration, Figure 3 , a blockchain ledger 320 is shown as having a separate blockchain database 322 and a world state database 324. In some embodiments, one or more blockchains and one or more world states may belong to the same database. One or more blockchains may be associated with one or more world states, and a blockchain network maintaining a blockchain ledger may update both the blockchain and the corresponding world state at the same time.

[0250] As described in more detail below, for a given application (e.g., an online payment application or an online shopping application), transaction data may be stored in one or more blockchains, and state information may be stored in one or more world states. A blockchain may be associated with one or more world states, and a world state may be associated with one or more blockchains. This article describes novel techniques for dividing a world state into multiple shards or partitioned world states, and merging multiple shards or partitioned world states into one world state.

[0251] In this document, the term "group world state" is used to refer to a set of world states that in combination stores user account state information related to a group of users who use services provided by the blockchain-based system 300. The root hash value of the group world state provides a fingerprint of the latest state values ​​of all user accounts associated with the group of users.

[0252] The system 300 includes computing resources 326, such as computing power (e.g., processor cores, processing threads, CPU runtime), memory, non-volatile storage, and / or data bandwidth to support the blockchain-based application module 308. The system 300 includes a resource demand assessment module 328 that determines whether the resources allocated to the blockchain-based application module 308 are sufficient to fully support the processing of the group world state. For example, the assessment module 328 may determine whether the allocated resources are sufficient based on one or more criteria such as the percentage of the total available resources being used and / or a quality of service metric. Examples of quality of service metrics may include transaction response time and / or service interruption or downtime. The system 300 includes a resource allocation module 330 that allocates resources to the application module 308.

[0253] For example, initially the system 300 may allocate a certain amount of resources (e.g., memory, non-volatile data storage, and data bandwidth) to support the application module 308. Over time, as the number of users and the number of transactions increase, if the amount of resources does not increase quickly, the evaluation module 328 may determine that the usage percentage of certain resources is above a threshold, such that the performance of the application module 308 may be adversely affected.

[0254] The system 300 is configured to divide the blockchain and world state associated with the application module 308 into multiple shards or partitions, and allocate more resources to support the blockchain and world state as the number of shards or partitions increases. Conversely, if the blockchain and world state require fewer resources, such as when some users migrate to other platforms, the system 300 is configured to reduce the number of shards or partitions and allocate fewer resources to support the blockchain and world state.

[0255] For example, an operator of system 300 may establish a rule set that includes one or more rules about whether to increase or decrease the number of shards or partitions in the group world state. For example, a rule may specify that if the CPU usage reaches X1% (e.g., 95%) for more than Y1% (e.g., 5%) of the time, the number of shards or partitions in the group world state should be increased. For example, a rule may specify that if the storage reaches Z1% (e.g., 80%) of capacity, the number of shards or partitions in the group world state should be increased. For example, a rule may specify that if the CPU usage remains below X2% (e.g., 20%) and the storage vacancy is greater than Z2% (e.g., 50%), the number of shards or partitions in the group world state should be reduced. In the above example, X1, X2, Y1, Z1, and Z2 are positive real numbers. The above rules are examples only, and other rules may also be used to determine whether to increase or decrease the number of shards or partitions in the group world state. The rule set may be stored in, for example, a rule set database.

[0256] In some embodiments, the system 300 includes a blockchain ledger modification module 332 configured to modify the blockchain database 322 and the world state database 324 by modifying the number of shards or partitions in the blockchain and the world state. The system includes a resource allocation module 330 that allocates computing resources 326 based on the number of shards or partitions in the blockchain and the world state.

[0257] In some embodiments, as the number of shards or partitions in the group world state increases, the computing resources 326 allocated to facilitate the processing of the blockchain and world state can be increased so that the consensus process can be performed faster. Therefore, the consensus node can decide whether to increase or decrease the number of shards or partitions in the group world state based on whether it is beneficial to speed up or slow down the performance of the consensus process. The consensus process can be based on a consensus algorithm, such as a consensus algorithm based on proof of work (PoW), a consensus algorithm based on proof of stake (PoS), a delegated Byzantine fault tolerance (dBFT) consensus algorithm, or a practical Byzantine fault tolerance (pBFT) consensus algorithm.

[0258] For example, if the first consensus node (e.g., 318) determines that its consensus processing is consistently slower than other consensus nodes, the first consensus node may increase the number of shards or partitions in the group world state to improve performance (i.e., increase the speed of the consensus processing). Conversely, if the first consensus node determines that it performs consensus processing much faster than other consensus nodes, the first consensus node may reduce the number of shards or partitions in the group world state to save computing resources (e.g., 326). If the first consensus node determines that it performs consensus processing at about the same speed as other consensus nodes, the number of shards or partitions in the group world state may remain unchanged.

[0259] The first consensus node can determine whether its consensus processing is faster or slower than other consensus nodes in a variety of ways. For example, each consensus node can broadcast the blocks it has processed. If the first consensus node often receives notifications from other consensus nodes indicating that the processing of certain blocks has been completed, and the first consensus node has not yet completed the processing of those blocks, the first consensus node can determine that its consensus processing is performed at a slower speed than other consensus nodes. For example, each consensus node can broadcast the highest block number or block height that the consensus node has processed to other consensus nodes. In this way, each consensus node can understand the relative speed of consensus processing by comparing its highest block number with the highest block number of other consensus nodes. For example, the blockchain system can provide an application programming interface that allows a single consensus node to determine the status of consensus processing by other consensus nodes. The first consensus node can compare its highest block number with the highest block number of other consensus nodes to determine whether the first consensus node is faster or slower than other consensus nodes in consensus processing. For example, the blockchain system can continuously monitor the consensus processing performed by consensus nodes and provide an application programming interface that allows a single consensus node to determine the speed level of consensus processing between consensus nodes.

[0260] The first consensus node may decide to increase or decrease the number of shards or partitions in the group world state based on a number of criteria, including, for example, any combination of the following:

[0261] Whether the consensus processing at the first consensus node is ahead or behind the average consensus processing of other consensus nodes.

[0262] Whether the consensus process at the first consensus node is ahead or behind the average consensus process of the fastest N1% of other consensus nodes, where N1 is a positive real number. For example, N1% can be 10%, 20%, 50%, or 80%, or any other number.

[0263] Whether the consensus process at the first consensus node is ahead or behind the average consensus process of other consensus nodes by more than a time threshold T1, where T1 is a positive real number. For example, T1 can be an hour, a day, a week, a month, or any other duration.

[0264] Whether the consensus processing at the first consensus node is ahead or behind the average consensus processing of other consensus nodes in a predetermined time period T2 (e.g., one day, one week, or one month) by more than N2 cycles, where T2 is a positive real number and N2 is a positive integer. For example, the first consensus node evaluates whether its consensus processing is ahead or behind other consensus nodes every day, week, or month, and determines whether the lead or lag is more than several consecutive days, weeks, or months.

[0265] Whether the consensus processing at the first consensus node is ahead or behind other consensus nodes by more than a threshold number N3 of transactions for a predetermined time period T3, where N3 is a positive integer and T3 is a positive real number.

[0266] The operator of the first consensus node may establish a rule set that includes one or more rules regarding whether to increase or decrease the number of shards or partitions in the group world state. For example, the first rule may specify that if the consensus processing at the first consensus node is slower than the consensus processing at one or more other consensus nodes by a first threshold, the number of shards or partitions in the group world state should be increased. For example, the second rule may specify that if the consensus processing at the first consensus node is faster than the consensus processing at one or more other consensus nodes by a second threshold, the number of shards or partitions in the group world state should be decreased. For example, the third rule may specify that if for more than Q1% (e.g., 50%) of transactions per unit time T5 (e.g., week), the consensus processing at the first consensus node lags behind the average consensus processing of the fastest P1% (e.g., 10%) of other consensus nodes by more than T4 (e.g., 1) minutes for N4 (e.g., four) consecutive unit times T5 (e.g., weeks), the number of shards or partitions in the group world state should be increased, where P1, T4, Q1, and T5 are positive real numbers and N4 is a positive integer. For example, a fourth rule may specify that if for more than Q2% (e.g., 50%) of transactions within a time period T7 (e.g., a week), the consensus processing at the first consensus node lags behind the average consensus processing of other consensus nodes by more than a predetermined time period T6 (e.g., 1 hour), then the number of shards or partitions in the group world state should be increased, where T6, Q2, and T7 are positive real numbers. The above rules are examples only, and other rules or other combinations of rules may also be used to determine whether to maintain the same, increase, or decrease the number of shards or partitions in the group world state. The rule set may be stored in, for example, a rule set database.

[0267] The blockchain and world state (e.g., 310a and 312a) are maintained by a blockchain network (e.g., 314, 316). The system 300 acts as a node between nodes of the blockchain network (e.g., 318, 319) and maintains a local copy of the blockchain and world state (e.g., 310b, 312b, 310c, 312c) stored in a blockchain database 322 and a world state database 324. The blockchain network 314, 316 can be similar to Figure 2 Blockchain network 212. Some nodes of blockchain network 314 may overlap with nodes of blockchain network 316.

[0268] The system 300 includes a root hash module 338 configured to calculate a root hash value of a world state (e.g., 310c, 312c) that represents a fingerprint of the latest state values ​​of all user accounts associated with the system 300. In this example, the group world state may have N shards, and each shard may have multiple world states. For each shard, based on the root hash value of each world state in the shard, the root hash module 338 first calculates a root hash value of the shard world state. The root hash value of the shard world state represents a fingerprint of the world state within the shard. Then, the root hash module 338 calculates a root hash value of the group world state based on the root hash values ​​of the N shard world states.

[0269] The world state associated with the blockchain stores the state information of the user accounts associated with the blockchain. The blockchain can be divided into multiple (e.g., N) shards to improve processing efficiency. The group world state stores the state information of all user accounts associated with all shards of the blockchain. The group world state is also divided into the same number of shards as the blockchain (e.g., N). In this example, each shard of the blockchain is associated with a shard world state, which stores the state information of the user accounts associated with the shard of the blockchain. Each shard world state can include multiple world states, and each world state stores the state information of a subset of user accounts.

[0270] In some embodiments, user accounts are assigned to world states using a predetermined allocation method. When the shards of the blockchain and group world state are expanded or reduced, the number of shards will change, but the total number of world states remains unchanged. For example, assume that the user account is assigned to 16 world states (referred to as world states 1 to 16) based on the first 4 bits of the user account identifier. Assume that at a first time point t1, there are two shards of the blockchain and two shard world states, for example, shard world state 1 and shard world state 2. Shard world state 1 includes world states 1 to 6, and shard world state 2 includes world states 7 to 16. Assume that at a second time point t2, shard world state 2 is divided into two shard world states, for example, shard world state 2 and shard world state 3. Assume that shard world state 2 includes world states 7 to 10, and shard world state 3 includes world states 11 to 16. In this example, after increasing or decreasing the number of shard world states, the user account associated with each individual world state remains unchanged (because it is based on the first 4 bits of the user account identifier).

[0271] The group world state data structure is designed to enable the state information of all user accounts to be stored and processed in an efficient manner. For example, there are two ways to design the group world state data structure. In the first design, the group world state is maintained by a digital tree structure, wherein each leaf node corresponds to a shard world state root node. The leaf node stores the shard world state root hash value. The group world state root hash value is calculated based on the shard world state root hash value. The advantages of this design are that the implementation is simple, the required data storage size is small, and the calculations required to process the world state information are less. The group world state root hash value is calculated based on the shard world state root hash value. When the shard is expanded or reduced, the user accounts associated with each shard world state may change, the shard world state root hash value may change, and the group world state root hash value may also change.

[0272] In the second design, the group world state is maintained by a digital tree structure, wherein each leaf node of the group world state corresponds to a shard world state, and each leaf node records the root hash value of the world state in the shard. The group world state root hash value is calculated based on the root hash value of the world state (rather than the shard world state root hash value). In this example, when the shards of the blockchain are expanded or reduced, the root hash of the group world state remains stable and does not change. The root hash value of the group world state reflects the status of all user accounts. Regardless of how each world state is assigned to each shard, if the status of the user account does not change, the root hash value of the group world state will not change. In this design, the storage capacity required to store the world state information is larger (for example, each leaf node needs to store information about all world states in the shard), the calculation required to process the world state information is also larger, and the implementation method is more complicated (compared to the first design).

[0273] Below, we describe an implementation of a group world state using the first design. In some implementations, the blockchain is divided into N shards, and each shard has a corresponding shard world state that stores state information of user accounts associated with the shard. Figure 44 is an illustration of an example of a data structure for a group world state 400 for storing state information of all user accounts under consideration (e.g., all user accounts associated with a blockchain-based application module 308). In this example, the group world state is divided into N shards, such as 402a, 402b, 402c, and 402d, collectively referred to as 402. Each shard of the group world state is referred to as a "shard world state". Each shard world state stores state information of a subset of all user accounts under consideration. For example, all user accounts under consideration may include all user accounts associated with an online payment system that are located in a particular country, state, province, or city. The group world state supports multiple world states, each of which stores state information of a subset of user accounts. For example, a user account may be assigned to a world state based on a first predetermined number of bytes of a user account identifier.

[0274] The number of shards can be less than the number of world states. For example, initially there can be a smaller number of shards, and each shard can include a larger number of world states. Over time, as the amount of data stored in each world state increases, the number of shards can increase, and each shard can include a smaller number of world states, so that the total amount of data managed in each shard does not exceed capacity.

[0275] exist Figure 4 In the example of , shard world state 402a includes M world states, such as 404a, 404b, 404c, 404d, collectively referred to as 404. Each world state 404 is maintained using a binary tree such as a Merkle tree. Each root node of world state 404 can be used to establish a binary tree for maintaining the shard world state. For example, the root node of world state 404 becomes a leaf node of the binary tree of shard world state 402a. Each root node of shard world state 402 can be used to establish a binary tree for maintaining group world state 400. For example, the root node of shard world state 402 becomes a leaf node of the binary tree of group world state 400. In some embodiments, each world state can be maintained using, for example, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a Bucket tree.

[0276] Each shard world state 402 is associated with a blockchain 406, which may include a plurality of blocks 408. The shard world state 402 stores state information of user accounts associated with the blockchain 406. In some embodiments, each block 408 in the blockchain 406 includes a block header 410 and a block body 412. The block body 412 includes, for example, a transaction list 422 and a receipt list 424. The block header 410 includes, for example, a shard identification 414, a block hash 416, a block number 418, and a shard world state root hash 420. The shard world state root hash 420 is calculated based on the root hash of the world state included in the shard. In this example, the shard world state 402a includes M world states (e.g., 404a, 404b, 404c, 404d), so the shard world state root hash value 420 is calculated based on the root hash values ​​of the M world states (e.g., 404a, 404b, 404c, 404d).

[0277] exist Figure 4 In the example of , the user account is assigned to the shard world state based on the first two bytes of the user account identifier. For example, if the first two bytes of the user account identifier are in the range of 0x0000 to 0x0010, the state information of the user account is stored in the first shard world state 402a. If the user account identifier is in the range of 0x0010 to 0x0020, the state information of the user account is stored in the second shard world state 402b. If the user identifier is in the range of 0xABCD to 0xFFFF, the user account is assigned to the Nth shard world state 402d.

[0278] Node 426a represents the root node of sharded world state 402a and stores the root hash value of sharded world state 402a, wherein the sharded world state root hash value represents the fingerprint of the state information of the user account associated with sharded world state 402a. Node 426b represents the root node of sharded world state 402b and stores the root hash value of sharded world state 402b, wherein the sharded world state root hash value represents the fingerprint of the state information of the user account associated with sharded world state 402b. Node 426d represents the root node of sharded world state 402d and stores the root hash value of sharded world state 402d, wherein the sharded world state root hash value represents the fingerprint of the state information of the user account associated with sharded world state 402d.

[0279] Node 428 represents the root node of group world state 400 and stores the root hash value of group world state 400, wherein the group world state root hash value represents the fingerprint of the state information of the user account associated with the group world state 400. The user account associated with group world state 400 includes the user account associated with all shard world states 402. The group world state root hash value is calculated based on the shard world state root hash values ​​of all shard world states 402. Node 428 stores information about all shards 402 of group world state 400. For example, node 428 may store the address of root node 426 of shard 402 (or a link or pointer to the address). In some examples, a group world state mapping table is established to store information about the address of root node 428 of group world state 400 and root nodes 426 of all shards 402.

[0280] In some embodiments, the user account identifier may be represented by a number, and the first two bytes of the user account identifier range from 0x0000 to 0xFFFF. For example, a user account may be assigned to a shard world state based on the first two bytes of the user account identifier. In this example, the group world state may support up to 2 16 = 65536 sharded world states. If each sharded world state corresponds to one blockchain shard, the group world state 402 can support up to 65536 blockchain shards.

[0281] In some implementations, user accounts can be assigned to sharded world states based on the first three bytes (comprising 24 bits) of the user account identifier. In this example, the group world state can support up to 2 24 = 16777216 sharded world states. If each sharded world state corresponds to one blockchain shard, the group world state can support up to 16777216 blockchain shards. If additional sharded world states are needed, the first four or more bytes of the user account identifier can be used to assign the user account to the sharded world state. In the following example, we assume that the user account is assigned to the sharded world state based on the first two bytes of the user identifier.

[0282] Typically, the system does not need to use the maximum number of shards that can be supported. For example, when the user account is assigned to the shard world state based on the first two bytes of the user account identifier, the group world state can support up to 65536 shard world states and up to 65536 blockchain shards. In this example, the system typically uses less than 65536 blockchain shards. Therefore, each shard includes multiple world states (e.g., M world states). In some embodiments, the number of world states in the shard and / or which world state belongs to the shard can be recorded in the block header or block body. For example, a smart contract associated with a blockchain can store rules for indicating the number of world states in the shard and / or which world state belongs to the shard. For example, the number of world states in the shard or which world state belongs to the shard can be determined by traversing a digital tree (e.g., a Merkle tree) of shard world states.

[0283] For example, even though the group world state can support 65536 shard world states, the system can use a smaller number of shard world states. Figure 4 In the example of , the user account is assigned to the shard world state based on the first two bytes of the user account identifier. As described above, if the first two bytes of the user account identifier are in the range of 0x0000 to 0x0010, the state information of the user account is stored in the first shard world state 402a. If the user account identifier is in the range of 0x0010 to 0x0020, the state information of the user account is stored in the second shard world state 402b. If the user account identifier is in the range of 0xABCD to 0xFFFF, the user account is assigned to the Nth shard world state 402d. Other methods of assigning a specific user account to a specific world state may also be used.

[0284] For example, each user account information may include a unique identifier that is specifically used to determine which world state the user account is assigned to. For example, the system may also assign attributes (e.g., priority) to users and assign different priorities to different shards. For example, a user account with a higher priority may be assigned to a first shard with better quality of service and / or faster processing time, which may also result in a higher service fee. A user account with a lower priority may be assigned to a second shard with lower quality of service and / or slower processing time, which may result in a lower service fee.

[0285] Simplified Payment Verification Proofs for transactions in a system using a group world state are described below. In a blockchain-based system, when a node receives a new transaction, the node confirms the transaction, including verifying that none of the transaction inputs have been used before. To perform this check, the node accesses the blockchain. The node can keep a complete local copy of the blockchain, making it possible to verify any inputs. Transactions can also be verified without running a full network node. This is called Simplified Payment Verification or SPV. Simplified Payment Verification allows lightweight clients to verify that a transaction is included in a block without downloading the entire blockchain. SPV clients download block headers that are much smaller than full blocks. Each block header includes a hash of all transactions within the block, which is constructed in such a way that it is easy to verify whether the transaction in question belongs to the block by considering the hash of the transaction. To verify that a transaction is in a block, an SPV client requests a proof of inclusion in the form of a Merkle branch that links the transaction to the block.

[0286] When using a group world state that includes multiple shards, where each shard includes multiple world states, generating a simplified payment verification proof may require additional SPV proofs from the shard world state to the world state compared to generating an SPV proof when using a single blockchain without shards. If we do not consider expanding or shrinking the capacity of the group world state by modifying the sharding scheme, the group world state can be recorded in a specific shard, where the group world state records the world state of each shard at a specific point in time. When an SPV proof needs to be provided to an external node, the SPV proof message may include three parts:

[0287] SPV proof from group world state to shard world state;

[0288] SPV proofs from the sharded world state to the corresponding world state; and

[0289] SPV proofs from the world state to the corresponding user accounts.

[0290] The following describes a process for expanding or shrinking the shard capacity of the group world state. In some examples, each shard is allocated a given amount of resources, such as storage capacity or computing power, and the amount of resources used to support the group world state can be increased by increasing the number of shards.

[0291] In some embodiments, the blockchain ledger includes three databases: a blockchain database (e.g., BlockDB), a world state database (e.g., StateDB), and a miscellaneous database (e.g., ExtraDB). The blockchain database stores blockchains, the world state database stores world states, and the miscellaneous database stores miscellaneous data. The blockchain ledger may also include miscellaneous databases, such as RelatedDB and consensus databases in the Mychain blockchain, which may be processed in a manner similar to the miscellaneous database (ExtraDB).

[0292] The following describes the expansion process of the group world state, including the expansion of the blockchain ledger shards, where the number of shards is increased. Figure 5 For example, in the first expansion operation 508 , the first shard 500 is divided into the second shard 510 and the third shard 512 . Next, in the second expansion operation 522 , the third shard 512 is divided into the fourth shard 528 and the fifth shard 530 .

[0293] The following describes the expansion of a shard of a world state data structure to increase the number of shard world states. In some embodiments, the expansion of the first shard world state 502 is achieved by dividing the first shard world state 502 into a second shard world state 514 and a third shard world state 516. For example, the first shard 500 initially includes four world states 504a, 504b, 504c, and 504d. Node 506 corresponds to the root node of the shard world state 502. Based on the root hash values ​​of world states 504a, 504b, 504c, and 504d, the root hash value of the shard world state 502 is calculated. After the first expansion 508, the second shard world state 514 includes world state 504a. Node 518 corresponds to the root node of the shard world state 514. Based on the root hash value of world state 504a, the root hash value of the shard world state 514 is calculated. The third shard world state 516 includes world states 504b, 504c, 504d. Node 520 corresponds to the root node of the shard world state 516. The root hash value of the shard world state 516 is calculated based on the root hash values ​​of the world states 504b, 504c, 504d.

[0294] Initially, when the first shard world state 502 is part of the group world state 400, the root node 428 stores the address (or link or pointer) of the root node 506 of the first shard world state 502. In some examples, after the first shard world state 502 is partitioned into the second shard world state 514 and the third shard world state 516, the system 300 configures the root node 428 of the group world state 400 to remove the address of the root node 506 of the first shard world state 502 and store the addresses of the root node 518 of the second shard world state 514 and the root node 520 of the third shard world state 516. In some examples, the group world state mapping table is updated to remove the address of the root node 506 and add the addresses of the root nodes 518 and 520.

[0295] After the second expansion of shard 522, the third shard world state 516 is divided into a fourth shard world state 524 (shown as 528 in the figure) and a fifth shard world state 526 (shown as 530 in the figure). The fourth shard world state 524 includes world state 504c. Node 532 corresponds to the root node of shard world state 524. Based on the root hash value of world state 504c, the root hash value of shard world state 524 is calculated. The fifth shard world state 526 includes world states 504b and 504d. Node 534 corresponds to the root node of shard world state 526. Based on the root hash values ​​of world states 504b and 504d, the root hash value of shard world state 526 is calculated.

[0296] In some examples, the system 300 configures the root node 428 of the group world state 400 to remove the address of the root node 520 of the third shard world state 516 and store the addresses of the root node 532 of the fourth shard world state 524 and the root node 534 of the fifth shard world state 526. In some examples, the group world state mapping table is updated to remove the address of the root node 520 and add the addresses of the root nodes 532 and 534.

[0297] Typically, after each expansion of a shard (the shard world state before the split is split into two new shard world states), the root node of the group world state is updated to remove the root node address of the shard world state before the split and add the root node address of the new shard world state. Alternatively, the group world state mapping table is updated to remove the root node address of the shard world state before the split and add the root node address of the new shard world state. In this way, the root node of the group world state or the group world state mapping table will have the correct information about which root nodes of the shard world state should be accessible in order to calculate the updated group world state root hash value.

[0298] Shard expansion can be achieved by partitioning the shard world state corresponding to the shard and assigning the world state to the newly partitioned shard world state. This allows the capacity of the shard to be expanded quickly, and users will only experience a small amount of downtime during the shard expansion process. When the first two bytes of the user account identifier are used to assign the user account to the world state, the group world state can support up to 256 2 = 65536 shard world states. Therefore, the maximum number of shards that can be supported in the example is 65536.

[0299] Figure 5 The process shown in relates to how to allocate world state to shard world state when the group world state is expanded by increasing the number of shards. The following describes the process of expanding the database to support the expansion of the group world state. Figure 6 In some embodiments, initially there is a single shard 600, which includes a blockchain database BlockDB 602, a world state database StateDB 604, and a miscellaneous database ExtraDB 606. In this example, the first shard 600 is divided into a second shard 608 and a third shard 610, wherein each of the second shard 608 and the third shard 610 has its own blockchain database, world state database, and miscellaneous database.

[0300] The process of scaling the group world state by dividing the first shard into the second and third shards is intended to minimize disruption to users to prevent or reduce interruptions in services provided by the system (e.g., blockchain-based application module 308). One way to achieve this goal is to generate a quick snapshot of the contents of the first shard and, for example, use Figure 5The processing shown redefines the structure of the group world state. The first shard becomes the initial second shard 618 and includes the blockchain database BlockDB 602, the world state database StateDB 604, and the miscellaneous database ExtraDB 606. The snapshot of the first shard becomes the initial third shard 620 and includes a copy 612 of the blockchain database BlockDB, a copy 614 of the world state database StateDB, and a copy 616 of the miscellaneous database ExtraDB. In some embodiments, the snapshot of the first shard does not initially include a complete copy of the content of the first shard. For example, the snapshot may include a pointer to the first shard that enables the system to identify the content of the copy of the first shard without actually making a complete copy of the first shard. This allows the snapshot to be established quickly without having to wait for the time required to make a complete copy of the first shard. Subsequently, when the snapshot needs to be processed, the content is copied from the first shard to the snapshot. Similarly, if a piece of data in the first shard is to be modified, the data segment is copied to the snapshot before the data segment in the first shard is modified.

[0301] There are multiple ways to generate a snapshot of the first shard. For example, in a first method, a snapshot of the first shard may be generated using a virtual machine associated with the first shard. For example, in a second method, the consensus blockchain network includes: a verification peer node that participates in a consensus process to determine whether to write data on the blockchain; and a non-verification peer node that does not participate in the consensus process. The snapshot of the first shard may be generated by the non-verification peer node. In a third method, the number of verification peer nodes may be increased, and a snapshot of the first shard may be generated by the verification peer node while the number of verification peer nodes is increased. The second method is more flexible, has better scalability characteristics, and requires lower online maintenance costs.

[0302] After the snapshot is generated, users can access the contents of the initial second shard 618 and the initial third shard 610, including the blockchain database BlockDB 602 / 612, the world state database StateDB 604 / 614, and the miscellaneous database ExtraDB 606 / 616. Generating a fast snapshot of the contents of the first shard takes a short time, so the system downtime is small and the corresponding interruption to users is also small.

[0303] Initially, both the initial second shard 618 and the initial third shard 620 include complete copies of the blockchain database BlockDB 602 / 612, the world state database StateDB 604 / 614, and the miscellaneous database ExtraDB 606 / 616. The amount of storage required to store the data supporting the second and third shards is twice the amount of storage required to support the first shard 600. In order to reduce data storage requirements, the databases in the initial second shard 618 and the initial third shard 620 can be reduced to remove data that is not necessary to support the second shard and the third shard, respectively. After the reduction, the initial second shard 618 becomes the target second shard 608, and the initial third shard 620 becomes the target third shard 610. The reduction operation can be implemented as a background process that does not interfere with the user.

[0304] In some embodiments, the blockchain database BlockDB 602 / 612, the world state database StateDB 604 / 614, and the miscellaneous database ExtraDB 606 / 616 can be reduced using the process described below. For example, when reducing the blockchain database BlockDB, the block header can be retained. Within the block body, transactions that are not related to user accounts associated with the shard world state will be gradually removed. For example, assuming that the first shard includes world states 504a, 504b, 504c, and 504d, the target second shard 608 includes world state 504a, and the target third shard 610 includes world states 504b, 504c, and 504d (this is similar to Figure 5 508 in ). The initial second shard 618 is reduced so that transactions unrelated to user accounts associated with world state 504a are gradually removed from the block body. The initial third shard 620 is reduced so that transactions unrelated to user accounts associated with world states 504b, 504c, and 540d are gradually removed from the block body.

[0305] For example, when shrinking the world state database StateDB, Merkle trees that are not related to the world state in the shard will be removed. For example, since the miscellaneous database ExtraDB is small, there is no need to shrink the miscellaneous database ExtraDB. Alternatively, the miscellaneous database ExtraDB can be shrunk by removing transaction indexes that are not required by the corresponding shard world state.

[0306] The reduction of the database in the second shard will result in the following results. In this example, a portion 622 of the blockchain database BlockDB is removed, and the remaining blockchain database Sharding2 BlockDB 624 includes transaction data of user accounts associated with the second shard. A portion 626 of the world state database StateDB is removed, and the remaining world state database Sharding2StateDB 628 includes state information of user accounts associated with the second shard. A portion 630 of the miscellaneous database ExtraDB is removed, and the remaining miscellaneous database Sharding2 ExtraDB 632 includes miscellaneous data of user accounts associated with the second shard.

[0307] The reduction of the database in the third shard will result in the following results. In this example, a portion 634 of the blockchain database BlockDB is removed, and the remaining blockchain database Sharding3 BlockDB 636 includes transaction data of user accounts associated with the third shard. A portion 638 of the world state database StateDB is removed, and the remaining world state database Sharding3StateDB 640 includes state information of user accounts associated with the third shard. A portion 642 of the miscellaneous database ExtraDB is removed, and the remaining miscellaneous database Sharding3 ExtraDB 644 includes miscellaneous data of user accounts associated with the third shard.

[0308] Shard expansion processing allows the capacity of a shard to be quickly expanded to provide users with high-quality online services. After expansion, the database can be reduced to reduce storage costs. Reduction can be performed when there are no transactions, or it can be processed in the background to avoid interruption to users.

[0309] The following describes the downscaling process of the sharded blockchain ledger. We first describe the downscaling of the sharded world state. A group world state data structure is provided, in which the world states of multiple shards are combined into a group world state.

[0310] For a regular content-addressable Merkle tree (FDMT_History / MPT), the data is<Hash,Value> The format is stored in the nodes of the Merkle tree, and the Merkle tree is already in a "forest" configuration, so the complete database of the group world state can be obtained by combining the two databases of the world state of each shard.

[0311] For non-content-addressable Merkle trees (FDMT_Current / Bucket Tree), each shard world state records the current state of user accounts in the shard, and different world states are separated based on user account identifiers (e.g., the first predetermined number of bytes of the user account identifier), so different shard world states are associated with different subsets of user accounts. Two shard world states can be combined to obtain a complete world state. However, before combining, the shard world state must be "pure", which means that each shard world state only stores the state information of the user account associated with the shard world state, and does not store the state information of the user account associated with another shard world state. Figure 6 As shown, when the first shard 600 is divided to generate the initial second shard 618 and the initial third shard 620, the initial second shard 618 and the initial third shard 620 include duplicate data and need to be reduced. The initial second shard 618 needs to be reduced to remove the state data of the user account associated with the target third shard 610, and the initial third shard 620 needs to be reduced to remove the state data of the user account associated with the target second shard 608. Therefore, after the reduction is completed, the second shard world state and the third shard world state can be combined.

[0312] Figure 7 An example of a process for combining the fourth shard 528 and the fifth shard 530 to generate the third shard 512 in the first shard scale-down operation 700 and combining the second shard 510 and the third shard 512 to generate the first shard 500 in the second shard scale-down operation 702 is shown. Figure 7 The fourth shard 528, the fifth shard 530, the third shard 512, the second shard 510 and the first shard 500 in Figure 5 Those fragments in .

[0313] Before combining the fourth shard 528 and the fifth shard 530 into the third shard world state 516, the root node 428 stores the addresses (or links or pointers) of the root node 518 of the second shard world state 514, the root node 532 of the fourth shard world state 524, and the root node 534 of the fifth shard world state 526. In some examples, after the fourth shard world state 524 is merged with the fifth shard world state 526, the system 300 configures the root node 428 of the group world state 400 to remove the addresses of the root nodes 532 and 534 and store the address of the root node 520. In some examples, the group world state mapping table is updated to remove the addresses of the root nodes 532 and 534 and add the address of the root node 520.

[0314] Figure 7 The sharding scaling example is basically Figure 5However, the shard scaling operation may also be performed differently. For example, the fourth shard 528 may be combined with the second shard 510 to generate the sixth shard, the fifth shard 530 may be combined with the third shard 512 to generate the seventh shard, and the sixth shard may be combined with the seventh shard to generate the first shard 500.

[0315] In this example, in the first shard scaling down operation 700, the fourth shard world state 524 is combined with the fifth shard world state 526 to generate the third shard world state 516. The fourth shard world state 524 includes the third world state 504c, and the fifth shard world state 526 includes the second world state 504b and the fourth world state 504d. After the fourth shard world state 524 is combined with the fifth shard world state 526, the third shard world state 516 includes the second world state 504b, the third world state 504c, and the fourth world state 504d. The second shard world state 514 includes the first world state 504a. After the second shard world state 514 is combined with the third shard world state 516, the first shard world state 502 includes the first world state 504a, the second world state 504b, the third world state 504c, and the fourth world state 504d.

[0316] In the fourth shard 528, the root node 532 of the fourth shard world state 524 stores the root hash value of the fourth shard world state 524, which is calculated based on the root hash value of the third world state 504c. In the fifth shard 530, the root node 534 of the fifth shard world state 526 stores the root hash value of the fifth shard world state 526, which is calculated based on the root hash values ​​of the second and fourth world states 504b and 504d. After the first shard scaling down operation 700, the root node 520 of the third shard world state 516 stores the root hash value of the third shard world state 516, which is based on the root hash values ​​504b, 504c, and 504d of the second, third, and fourth world states. After the second shard scaling down operation 702, the root node 506 of the first shard world state 502 stores the root hash value of the first shard world state 502, which is based on the root hash values ​​of the first, second, third and fourth world states 504a, 504b, 504c and 504d.

[0317] Typically, each time two sharded world states before combination are combined into a new sharded world state, the root node of the group world state is updated to remove the address of the root node of the sharded world state before combination and add the address of the root node of the new sharded world state. Alternatively, the group world state mapping table is updated to remove the address of the root node of the sharded world state before combination and add the address of the root node of the new sharded world state. In this way, the root node of the group world state or the group world state mapping table will have the correct information about which root nodes of the sharded world state should be accessible in order to calculate the updated group world state root hash value.

[0318] The following describes the scaling down of the blockchain ledger database. For two different shards of the blockchain ledger, their blockchain database BlockDB, world state database WorldDB, and miscellaneous database ExtraDB can be directly combined. It only takes a short time to combine the blockchain database BlockDB, world state database WorldDB, and miscellaneous database ExtraDB, so the disruption to users can be minimized.

[0319] Reference Figure 8 , the first shard 800 can be combined with the second shard 802 to form a third shard 804. The first shard 800 includes a first blockchain database BlockDB1 806, a first world state database StateDB1 808, and a first miscellaneous database ExtraDB1 810. The second shard 802 includes a second blockchain database BlockDB2 812, a second world state database StateDB2 814, and a second miscellaneous database ExtraDB2 816. After the shard reduction operation, the third shard 804 includes a blockchain database 818, which is a combination of the first blockchain database BlockDB1 806 and the second blockchain database BlockDB2 812. The third shard 804 includes a world state database 820, which is a combination of the first world state database StateDB1 808 and the second world state database StateDB2 814. The third shard 804 also includes a miscellaneous database 822, which is a combination of the first miscellaneous database ExtraDB1 810 and the second miscellaneous database ExtraDB2 816.

[0320] The following describes how to perform data search and how to generate a genesis block after a shard reduction operation. The block heights of the first shard 800 and the second shard 802 may be different. If the block heights of the first shard 800 and the second shard 802 are the same, their hash values ​​may be different. Typically, the third shard 804 may start from block 0. Alternatively, the third shard 804 may also start from a block height greater than 0. After merging the first shard 800 and the second shard 802, the first block of the third shard 804 should include information about the merger of the first shard 800 and the second shard 802. For example, such information may include three parts:

[0321] The third shard 804 is an indication generated due to a shard reduction operation;

[0322] The block index of the original shards (i.e., the first shard 800 and the second shard 802) enables efficient query of blocks and indexing of data in the third shard 804;

[0323] The root hash of the current shard world state, which in this example corresponds to the world state of the third shard 804.

[0324] The shard expansion and reduction processes described above allow resources to be used efficiently to support the world state data structure in order to provide high quality services to users. For example, the shard expansion operation is used to increase the number of shards of the group world state so that more resources are allocated to process the digital tree to maintain the group world state.

[0325] Another technique is described below, which is used to achieve efficient use of resources to support digital trees storing state information associated with smart contracts, thereby providing high-quality services to users. In some embodiments, smart contracts are executed on blockchains to autonomously process data to provide services to users. The blockchain-based system 300 may include a virtual machine that provides a runtime environment for executing smart contracts to facilitate the services provided by the blockchain-based application module 308. The blockchain-based application module 308 can be viewed as a transaction-based state machine. The state data associated with the blockchain-based application module 308 can be aggregated into a global shared state called a world state. The world state includes a mapping between an account address and an account state. The world state can be stored in a content-addressed tree structure such as a Merkle Patricia tree (MPT).

[0326] Fig. 9 is a diagram showing an example of a world state storing state data for user accounts and smart contracts. Fig. 9The upper portion of illustrative conceptually illustrates that world state 900 stores state information for a first set of user accounts 902 and a second set of user accounts 904. World state 900 also stores state information associated with a first smart contract 906 and a second smart contract 908. The root hash value of the world state provides a fingerprint of the latest state values ​​of the first and second sets of user accounts and the first and second smart contracts.

[0327] Fig. 9 The lower half of shows the world state data maintained in a digital tree (e.g., a Merkle tree) stored in a storage device. In this example, the first smart contract 906 generates a hash value 916 of the state data associated with the first smart contract 906 and stores the hash value in a first Merkle tree 910, which is stored in a first storage device 914. The state data associated with the second smart contract 908 is stored in a second Merkle tree 912, which is stored in a second storage device 918. The world state 900 is maintained by the first Merkle tree 910 and the second Merkle tree 912. In some embodiments, other types of tree data structures or digital trees (e.g., one or more Patricia trees, one or more Merkle Patricia trees, one or more modified Merkle Patricia trees, one or more barrel trees, or any combination of the above) can be used to maintain the world state.

[0328] Fig.10 An example of a smart contract "TestContract" 1000 is shown, which includes three types of data structures, namely, AccountInfo data structure 1002, CompanyInfo data structure 1004, and Country data structure 1006. Smart contract 100 specifies user account information 1008 (i.e., Zhejiang_account_infos), wherein keys of type "string" are mapped to user account values ​​of type "AccountInfo". Smart contract 1000 specifies user account information 1010 (i.e., Shanghai_account_infos), wherein keys of type "string" are mapped to user account values ​​of type "AccountInfo". Smart contract 1000 specifies company account information 1012 (i.e., string_map), wherein keys of type "address" are mapped to company account values ​​of type "CompanyInfo". Smart contract 1000 specifies region information 1014 of type "region" (i.e., countriesp array). For example, smart contract 1000 may correspond to Fig. 9 Smart contract 906 or 908.

[0329] For example, each of "Zhejiang_account_infos", "Shanghai_account_infos" and "string_map" may include an array of key-value pairs or a hash value table including key type and corresponding value type pairs. For example, user account information Zhejiang_account_infos may store account information of users living in Zhejiang, and user account information Shanghai_account_infos may store account information of users living in Shanghai.

[0330] In some embodiments, the smart contract is associated with a Merkle tree, so user account information Zhejiang_account_infos1008, user account information Shanghai_account_infos1010, company information string_map1012, and countriesp array 1014 are stored in a single Merkle tree. As the data in user account information Zhejiang_account_infos 1008, user account information Shanghai_account_infos 1010, company account information string_map 1012, and region information countriesp array 1014 increases, the amount of data stored in the Merkle tree increases, and the processing of data in the Merkle tree may become slower and more difficult. In addition, since the four types of data are stored in the same Merkle tree, searching for one type of data may require processing other types of data, thereby reducing search efficiency.

[0331] An improved system is described below in which two or more Merkle trees are associated with a smart contract so that the amount of data stored in each Merkle tree is reduced, thereby making the processing of Merkle trees more efficient.

[0332] Reference Fig.11 In some embodiments, the smart contract 1100 is configured to store state data or a hash of state data in a first Merkle tree 1102 and a third Merkle tree 1104. The smart contract 1100 includes code that specifies which type of data is stored in which Merkle tree. Each Merkle tree has a unique address that can be specified by the author of the smart contract. For example, the first Merkle tree 1102 can have an address of 0x00000001 and the third Merkle tree 1104 can have an address of 0x00000003. The first and third Merkle trees 1102 and 1104 are stored in a storage device 1106.

[0333] The second smart contract 1108 is configured to store state data or a hash of state data in the second Merkle tree 1110, the fourth Merkle tree 1112, and the fifth Merkle tree 1114. The smart contract 1108 includes code that specifies which type of data is stored in which Merkle tree. In this example, the second Merkle tree 1110 has an address of 0x00000002, the fourth Merkle tree 1112 has an address of 0x00000004, and the fifth Merkle tree 1114 has an address of 0x00000005. The second, fourth, and fifth Merkle trees 1110, 1112, and 1114 are stored in the storage device 1116.

[0334] Fig.11 The upper portion of the diagram conceptually shows that the world state 1118 stores state information of the first group of user accounts 1120 and the second group of user accounts 1122. The world state 1118 also stores state information associated with the first smart contract 1100 and the second smart contract 1108. The root hash value of the world state provides a fingerprint of the latest state values ​​of the first and second groups of user accounts and the first and second smart contracts. In this example, the world state 1118 is maintained by the first Merkle tree 1102, the second Merkle tree 1110, the third Merkle tree 1104, the fourth Merkle tree 1112, and the fifth Merkle tree 1114.

[0335] Fig.12 An example of a smart contract "TestContract" 1200 is shown, which includes three types of data structures, namely, AccountInfo data structure 1002, CompanyInfo data structure 1004 and Country data structure 1006, similar to Fig.10Those of the smart contract 1000. The smart contract 1200 includes a code for identifying state data and a specific Merkle tree for storing first state data. In this example, the smart contract 1200 includes a modifier "MerkleTree (0x00000001)" 1202 before the code "mapping (string=>AccountInfo) Zhejiang_account_infos", where the mapping of the value of the modification specified key to the user account information Zhejiang_account_infos1008 will be stored in the first Merkle tree 1102 with address 0x00000001. The smart contract 1200 includes a modification "MerkleTree (0x00000001)" 1204 before the code "mapping (string=>AccountInfo) Shanghai_account_infos", wherein the modification specifies that the mapping of the key to the value of the user account information Shanghai_account_infos1010 will be stored in the first Merkle tree 1102 with the address 0x00000001. The smart contract 1200 includes a modification "MerkleTree (0x00000003)" 1206 before the code "Country countriesp []", wherein the modification specifies that the countriesp array 1014 will be stored in the third Merkle tree 1104 with the address 0x00000003.

[0336] In some embodiments, the smart contract includes code written in a high-level language or a blockchain programming language (e.g., Solidity, Serpent) or a low-level Lisp-like language (LLL). Depending on the language in which the smart contract is written and the system on which the smart contract is deployed, there may be a variety of ways to execute the smart contract. For example, a virtual machine may include a compiler that compiles the smart contract into bytecode that can be deployed and executed on the blockchain. In some examples, the compiler may be provided by a device or node outside the virtual machine. The compiler may be configured to recognize the modification "MerkleTree (treeID)", where treeID represents the identification of a Merkle tree, such as the address of a Merkle tree, in which the data specified after the modification will be stored. In this article, the phrase "executing a smart contract" means something similar to executing bytecode that has been compiled from a smart contract.

[0337] In some examples, the virtual machine may include an interpreter that interprets the smart contract source code, allowing the smart contract code to start executing without waiting for the entire compilation process to complete. In this article, the term "compiler" refers to a module that can convert smart contract high-level source code into lower-level code that can be executed by the virtual machine. Depending on the context, the term "compiler" may also include an interpreter.

[0338] In some embodiments, the Merkle tree identifier can be a variable whose value depends on the values ​​of other parameters, for example, as a function of the values ​​of other parameters, or according to a rule set including one or more rules. For example, the function can be a Boolean function or a mathematical function. For example, the Merkle tree identifier can be determined during the time period when the compiler compiles the smart contract into bytecode or during the time period when the bytecode is executed. For example, the Merkle tree identifier can be an undetermined variable or parameter in the smart contract, and is determined when the compiler compiles the smart contract into bytecode. For example, the Merkle tree identifier can be a variable or parameter that is undetermined in the smart contract and the bytecode, and is determined when the virtual machine executes the bytecode.

[0339] For example, a smart contract may include code:

[0340] MerkleTree(TreeAddress1)mapping(string=>AccountInfo)Zhejiang_account_infos;

[0341] In this example, "TreeAddress1" is the variable.

[0342] For example, a smart contract may include code:

[0343] TreeAddress2=getTreeAddress(user_ID);

[0344] MerkleTree(TreeAddress2)mapping(string=>AccountInfo)Zhejiang_account_infos;

[0345] In this example, "getTreeAddress" is a function of "user_ID" and "TreeAddress2" is a variable.

[0346] For example, a smart contract may include code:

[0347] Rule 1: If user_ID is less than 100,000, then TreeAddress3=0x00000001;

[0348] Rule 2:If user_ID is less than 200,000and greater than or equal to100,000,then TreeAddress3=0x00000002;

[0349] Rule 3: If user_ID is less than 300,000 and greater than or equal to200,000, then TreeAddress3=0x00000003;

[0350] Rule 4: If user_ID is less than 400,000, and greater than or equal to 300,000, then TreeAddress3=0x00000004;

[0351] MerkleTree(TreeAddress3)mapping(string=>AccountInfo)Zhejiang_account_infos;

[0352] In this example, "TreeAddress3" is a variable determined based on rules 1 to 4.

[0353] For example, data may be stored in different Merkle trees according to characteristics of the data and / or characteristics of the Merkle tree and / or characteristics of the computing resources associated with the Merkle tree. For example, the characteristics of the data may include the size of the data and the priority of the data. For example, the function may specify that if the number of user accounts in the first group of user accounts is equal to or less than a predetermined number N4, the data associated with the first group of user accounts is stored in the first Merkle tree; if the number of user accounts in the first group of user accounts is greater than N4 and equal to or less than a predetermined number N5, it is stored in the second Merkle tree; if the number of user accounts in the first group of user accounts is greater than N5, it is stored in the third Merkle tree, where N4 and N5 are positive integers. For example, the function may specify that if the user account is associated with a low priority, the data associated with the user account is stored in the first Merkle tree; if the user account is associated with a high priority, it is stored in the second Merkle tree.

[0354] Characteristics of the Merkle tree may include, for example, how much data has been stored in the Merkle tree and processing times associated with the Merkle tree (e.g., read and write access times and the time period used to process the Merkle proof). For example, a smart contract may include code that specifies that data associated with a new user account should be stored in a first Merkle tree if the size of the Merkle tree is equal to or less than X3 gigabytes, and in a second Merkle tree if the size of the Merkle tree is greater than X3 gigabytes, where X3 is a positive real number.

[0355] For example, the characteristics of the computing resources associated with the Merkle tree may include characteristics of a storage device used to store the Merkle tree, such as the remaining capacity of the storage device or the location of the storage device. For example, a smart contract may include code specifying that data associated with a new user account should be stored in a Merkle tree stored in a storage device having at least X4 tetra-bytes of available space. For example, a smart contract may include code specifying that data associated with a new account of a user residing in a particular country should be stored in a Merkle tree stored in a storage device located in the particular country.

[0356] In some embodiments, when a smart contract is deployed on a blockchain, the identity of the Merkle tree may be unknown. The identity of the Merkle tree may be specified by passing a function parameter to the smart contract when executing the smart contract (e.g., at runtime). The compiler of the smart contract is configured to support the dynamic association of the Merkle tree with the above-mentioned smart contract.

[0357] A feature of the present invention is that a smart contract is not fixedly bound to a single Merkle tree. Instead, a smart contract can be associated with multiple Merkle trees. In addition, the association between a smart contract and a Merkle tree can be dynamically adjusted. For example, each smart contract can include a mapping table that provides information about all Merkle trees that the smart contract can access.

[0358] Fig.13 An example of a smart contract "TestContract2" 1300 including an AccountInfo data structure 1002 is shown, similar to Fig.10In the smart contract 1300, the modification "MerkleTree(0x00000002)" 1302 in front of the code "mapping(string=>AccountInfo)Beijing_account_infos" specifies that the mapping of Beijing_account_infos 1304 is stored in the second Merkle tree 1110 with address 0x00000002. The modification "MerkleTree(0x00000004)" 1306 in front of the code "mapping(string=>AccountInfo)Chongqing_account_infos" specifies that the mapping of Chongqing_account_infos 1308 is stored in the fourth Merkle tree 1112 with address 0x00000004. The decoration “MerkleTree(0x00000005)” 1310 in front of the code “mapping(string=>AccountInfo)Shenzhen_account_infos” specifies that the mapping of Shenzhen_account_infos 312 is stored in the fifth Merkle tree 1114 having the address x00000005.

[0359] In some implementations, a Merkle tree can store state information of two or more smart contracts. Fig.14 In some examples, the first smart contract 1300 stores the state data or the hash value of the state data in the first Merkle tree 1102, the second Merkle tree 1110, and the third Merkle tree 1104. The second smart contract 1302 stores the state data or the hash value of the state data in the second Merkle tree 1110, the fourth Merkle tree 1112, and the fifth Merkle tree 1114. In this example, both the first smart contract 1300 and the second smart contract store the state data in the second Merkle tree 1110.

[0360] In some implementations, two or more Merkle trees may be stored in a storage device. Fig.14In the example of , the second Merkle tree 1110 is stored in the storage device StorageB 1304. The second Merkle tree 1110 maintains an index for searching the data in the second storage device StorageB 1304. The fourth Merkle tree 1112 and the fifth Merkle tree 1114 are stored in the third storage device StorageC 1306. The fourth Merkle tree 1112 and the fifth Merkle tree 1114 maintain an index for searching the data stored in the third storage device StorageC 1306.

[0361] Fig.14 The upper portion of the diagram conceptually shows that the world state 1400 stores state information of the first group of user accounts 1402 and the second group of user accounts 1404. The world state 1400 also stores state information associated with the first smart contract 1300 and the second smart contract 1302. The root hash value of the world state provides a fingerprint of the latest state values ​​of the first and second groups of user accounts and the first and second smart contracts. In this example, the world state 1400 is maintained by the first Merkle tree 1102, the second Merkle tree 1110, the third Merkle tree 1104, the fourth Merkle tree 1112, and the fifth Merkle tree 1114. For example, the root hash value of world state 1400 may be determined based on the root hash value (1102) of Merkle tree 0x00000001, the root hash value (1110) of Merkle tree 0x00000002, the root hash value (1104) of Merkle tree 0x00000003, the root hash value (1112) of Merkle tree 0x00000004, and the root hash value (1114) of Merkle tree 0x00000005.

[0362] Fig.15 is a flow chart of an example of a process 1500 for processing world state information associated with one or more blockchains. For convenience, process 1500 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system (e.g., Figure 1 The computing system 106, 108 or Figure 3 The system 300 of can perform process 1500. Process 1500 includes the following steps.

[0363] At 1502, the system provides a group world state comprising a plurality of shards, wherein each shard comprises one or more world states, each world state stores information about a state of a user account associated with the world state, and each shard is associated with a blockchain comprising one or more blocks, the one or more blocks storing transaction data associated with the user account associated with the blockchain.

[0364] In some embodiments, each world state is maintained using at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a Bucket tree.

[0365] In some embodiments, user accounts are associated with world states based on characteristics of the user accounts, wherein each user account is associated with only one of the world states.

[0366] In some embodiments, a user account is associated with a world state based on characteristics of a user account identification.

[0367] In some embodiments, a user account is associated with a world state based on a predetermined byte or byte word of a user account identification.

[0368] In some embodiments, the group world state supports a maximum of 2 n A user account whose user account identifier has a predetermined byte or byte word equal to m is associated with the mth world state, 1≤m≤2 n .

[0369] In some embodiments, the group world state supports a maximum of 2 16 =65536 world states, and the user account whose first two bytes of the user account identifier are equal to m is associated with the mth world state, 1≤m≤65536.

[0370] In some embodiments, user accounts are associated with world states based on a priority of the user accounts.

[0371] At 1504, the system dynamically modifies the number of shards in the group world state based on one or more criteria, including at least one of: (i) splitting one of the shards into two or more shards, (ii) merging two or more shards into one shard, (iii) adding one or more new shards to the group world state, or (iv) removing one or more shards from the group world state.

[0372] In some embodiments, the number of shards in the group world state can be dynamically modified by splitting a first shard into a second shard and a third shard, wherein the second shard includes a second subset of the world state of the first shard and the third shard includes a third subset of the world state of the first shard.

[0373] In some embodiments, the number of shards in the group world state can be dynamically modified by merging the second shard and the third shard to generate a first shard, wherein the first shard includes one or more world states of the second shard and one or more world states of the third shard.

[0374] In some embodiments, the number of shards in the group world state can be dynamically modified by adding one or more new shards to the group world state, wherein the one or more new shards include one or more world states not previously included in the group world state.

[0375] In some embodiments, the number of shards in the group world state may be dynamically modified by removing one or more shards from the group world state, including removing from the group world state one or more world states in the removed one or more shards.

[0376] In some embodiments, the system evaluates one or more criteria and splits a shard into two or more shards upon determining that the one or more criteria are met.

[0377] In some embodiments, the system evaluates one or more criteria and merges two or more shards into one shard when it determines that the one or more criteria are met.

[0378] In some embodiments, the one or more criteria include at least one of a quality of service metric, a computing power requirement, a storage requirement, a data storage requirement, or a data bandwidth requirement.

[0379] In some embodiments, the system determines at least one of: (i) a quality of service metric is below a threshold, (ii) a computing power requirement is not met, (iii) a storage capacity requirement is not met, (iv) a data storage capacity requirement is not met, or (v) a data bandwidth requirement is not met. In response to the determination, the system divides one of the plurality of shards into two or more shards, and allocates more resources to a combination of the two or more shards than to one of the plurality of shards, wherein the resources include at least one of computing power, storage capacity, data storage capacity, or data bandwidth.

[0380] In some embodiments, the system determines at least one of: (i) a quality of service metric is above a threshold, (ii) idle or excess computing power is above a threshold, (iii) available storage capacity is greater than a threshold, (iv) available data storage capacity is greater than a threshold, or (v) available data bandwidth is greater than a threshold. In response to the determination, the system merges two or more shards into a single shard, and allocates fewer resources to the merged single shard than the resources allocated to the two or more shards before the merge, wherein the resources include at least one of computing power, storage capacity, data storage capacity, or data bandwidth.

[0381] In some embodiments, dividing one of the shards into two or more shards includes dividing the first shard into a second shard and a third shard. The first shard includes a first world state database, the first world state database including a first set of world states. Dividing the first shard into the second shard and the third shard includes: generating a first snapshot of the first shard, wherein the first snapshot includes a snapshot of the first world state database. The dividing includes reducing the first shard to generate the second shard, including removing one or more world states in the first world state database to generate a second world state database, the second world state database including a second subset of the one or more world states in the first shard. The dividing also includes reducing the first snapshot of the first shard to generate the third shard, including removing one or more world states in the first world state database to generate a third world state database, the third world state database including a third subset of the one or more world states in the first shard, wherein the third subset of the one or more world states is different from the second subset of the one or more world states.

[0382] In some embodiments, dividing one of the shards into two or more shards includes dividing one of the plurality of shards into three or more shards.

[0383] In some embodiments, merging two or more shards into one shard includes merging a second shard and a third shard into a first shard. The second shard includes a second world state database, the second world state database including a second set of world states storing state information associated with a second set of user accounts. The third shard includes a third world state database, the third world state database including a third set of world states storing state information associated with a third set of user accounts. The first shard includes a first world state database, the first world state database including a first set of world states, the first set of world states including a second set of world states and a third set of world states, the first set of world states storing state information associated with a first set of user accounts, the first set of user accounts including a second set of user accounts and a third set of user accounts.

[0384] In some embodiments, dividing one of the shards into two or more shards includes dividing the first shard into a second shard and a third shard, the first shard being associated with a first set of user accounts, the second shard being associated with a second set of user accounts, and the third shard being associated with a third set of user accounts, the second set of user accounts being a second subset of the first set of user accounts, the third set of user accounts being a third subset of the first set of user accounts, the third subset of user accounts being different from the second subset of user accounts.

[0385] In some embodiments, the system provides a first set of one or more rules that specify one or more conditions for increasing the number of shards in the group world state.

[0386] In some embodiments, the system provides a second set of one or more rules that specify one or more conditions under which the number of shards in the group world state is to be reduced.

[0387] At 1506, the system generates a root hash value of the group world state, wherein the root hash value represents a digital fingerprint of a state of a user account associated with a world state in a shard of the group world state.

[0388] In some embodiments, the system dynamically modifies resources allocated to the group world state based on the number of shards in the group world state.

[0389] In some embodiments, in response to an increase in the number of shards in the group world state, the system allocates more resources to the group world state.

[0390] In some embodiments, in response to a decrease in the number of shards in the group world state, the system allocates fewer resources to the group world state.

[0391] In some embodiments, the resource includes at least one of computing power, storage, data storage capacity, or data bandwidth.

[0392] Fig.16 is a flow chart of an example of a process 1600 for processing world state information associated with one or more blockchains. For convenience, process 1600 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 The computing system 106, 108 or Figure 3 The system 300 may perform the process 1600. The process 1600 includes the following steps.

[0393] At 1602, the system provides a first shard associated with a first set of user accounts, wherein the first shard includes a first blockchain database and a first world state database. The first blockchain database includes a first blockchain managed by a first blockchain network, wherein blockchain data is stored on the first blockchain by consensus of blockchain nodes of the first blockchain network. The first world state database includes a plurality of world states, each world state is associated with a plurality of user accounts, and each world state stores a current state of a user account associated with the world state.

[0394] In some embodiments, the first world state database is associated with a first group of user accounts, the second world state database is associated with a second group of user accounts, the third world state database is associated with a third group of user accounts, and the first group of user accounts includes the sum of the second group of user accounts and the third group of user accounts.

[0395] In some embodiments, the first world state database is associated with a first set of user accounts, the second world state database is associated with a second set of user accounts, the third world state database is associated with a third set of user accounts, and the second set of user accounts and the third set of user accounts do not overlap.

[0396] In some embodiments, each of the multiple world states of the first world state database includes a root node, the first blockchain of the first blockchain database includes a first block, the first block includes a block header and a block body, the block header stores a first hash value obtained by hashing the hash value of the root node of the multiple world states of the first world state database, and the first hash value represents a digital fingerprint of the current state of the user account associated with the multiple world states of the first world state database.

[0397] In some embodiments, each of the multiple world states of the first world state database includes a root node, the first blockchain of the first blockchain database includes a first block, the first block includes a block header and a block body, and the block header stores a hash value of the root node of the world state in the first world state database.

[0398] In some embodiments, each world state is maintained using at least one digital tree including a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0399] At 1604, the system divides the first shard into a second shard and a third shard. The division includes the following steps.

[0400] At 1606, the system generates a first snapshot of the first shard, wherein the first snapshot includes a snapshot of the first blockchain database and a snapshot of the first world state database.

[0401] In some embodiments, generating a snapshot of the first shard includes generating a snapshot of the first shard using a virtual machine associated with the first shard.

[0402] In some embodiments, the first blockchain network includes a consensus blockchain network including validating peer nodes that participate in a consensus process to determine whether to write data to the blockchain; and non-validating peer nodes that do not participate in the consensus process. Generating a snapshot of the first shard includes generating the snapshot using the non-validating peer nodes.

[0403] In some embodiments, the consensus blockchain network includes: validating peer nodes that participate in a consensus process to determine whether to write data to the blockchain; and non-validating peer nodes that do not participate in the consensus process. Generating a snapshot of the first shard includes increasing the number of validating peer nodes, and generating the snapshot using the validating peer nodes.

[0404] At 1608, the system shrinks the first shard to generate a second shard, including removing one or more world states in a first world state database of the first shard to generate a second world state database including a second subset of the one or more world states in the first shard.

[0405] In some embodiments, the second shard includes a second blockchain database, the second blockchain database includes a second blockchain, the second blockchain stores transaction data associated with a user account associated with the second shard. The second blockchain includes a first block, the first block includes a block body storing information about transactions. Shrinking the first shard includes removing information about transactions associated with a user account that is not associated with a second subset of one or more world states in the second world state database.

[0406] At 1610, the system shrinks the first snapshot of the first shard to generate a third shard, including removing one or more world states in the first world state database in the first snapshot to generate a third world state database including a third subset of the one or more world states in the first shard, wherein the third subset of the one or more world states is different from the second subset of the one or more world states.

[0407] In some embodiments, the third shard includes a third blockchain database including a third blockchain storing transaction data associated with a user account associated with the third shard. The third blockchain includes a first block, the first block including a block body storing information about the transaction. Shrinking the first snapshot of the first shard includes removing information about the transaction associated with the user account that is not associated with a third subset of the one or more world states in the third world state database.

[0408] In some embodiments, the third shard includes a third blockchain database, the third blockchain database including a third blockchain storing transaction data associated with a user account associated with the third shard. The system divides the third shard into a fourth shard and a fifth shard, wherein the division includes: generating a second snapshot of the third shard, wherein the second snapshot includes a snapshot of the third blockchain database and a snapshot of the third world state database. The division includes reducing the third shard to generate the fourth shard, including removing one or more world states in the third world state database of the third shard to generate a fourth world state database, the fourth world state database including a fourth subset of the one or more world states in the third shard. The division also includes reducing the second snapshot of the third shard to generate the fifth shard, including removing one or more world states in the third world state database in the second snapshot to generate a fifth subset including the one or more world state databases in the third shard, wherein the fifth subset of the one or more world states is different from the fourth subset of the one or more world states.

[0409] In some embodiments, the system allocates more resources to the fourth and fifth slices combined than to the third slice.

[0410] In some embodiments, after dividing the first shard into the second shard and the third shard, the system allocates more resources to the combination of the second shard and the third shard than to the first shard.

[0411] In some embodiments, allocating more resources includes allocating at least one of more computing power, storage, data storage capacity, or data bandwidth.

[0412] In some embodiments, the system generates a hash value of a group world state representing the world states of the first and second shards based on a hash value of a root node of a digital tree maintaining the world states of the first and second shards.

[0413] In some embodiments, the system generates a simplified payment verification proof for a transaction associated with a user account by generating a first proof based on a path from a root node of a group world state to a root node of a sharded world state, generating a second proof based on a path from the root node of the sharded world state to a root node of a world state associated with the user account, and generating a third proof based on a path from the root node of the world state to a node representing the user account.

[0414] Fig.17is a flow chart of an example of a process 1700 for processing world state information associated with one or more blockchains. For convenience, process 1700 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 The computing system 106, 108 or Figure 3 The system 300 may perform the process 1700. The process 1700 includes the following steps.

[0415] At 1702, the system provides a first shard of a blockchain ledger, wherein the first shard includes a first blockchain database and a first world state database, the first world state database includes a plurality of world states, and each world state stores a current state of a user account associated with the world state.

[0416] At 1704, the system generates a first copy of the first shard, the first copy of the first shard comprising a copy of the first blockchain database and a copy of the first world state database.

[0417] At 1706, the system generates a second shard by removing one or more world states in the first world state database of the first shard, wherein a second subset of the one or more world states in the first shard remains in the second shard.

[0418] At 1708, the system generates a third shard by removing one or more world states in the first world state database in the first replica of the first shard, wherein a third subset of the one or more world states in the first shard is retained in the third shard, and the third subset of the one or more world states is different from the second subset of the one or more world states.

[0419] In some embodiments, the system allocates more resources to the combination of the second shard and the third shard than to the first shard.

[0420] Fig.18 is a flow chart of an example of a process 1800 for processing world state information associated with one or more blockchains. For convenience, process 1800 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 The computing system 106, 108 or Figure 3 The system 300 may perform the process 1800. The process 1800 includes the following steps.

[0421] At 1802, the system provides a first shard of a blockchain ledger, wherein the first shard includes a first blockchain database and a first world state database, the first world state database includes a plurality of world states, and each world state stores a current state of a user account associated with the world state.

[0422] At 1804, the system generates two or more replicas of the first shard, each replica comprising a copy of the first blockchain database and a copy of the first world state database.

[0423] At 1806, the system generates partitioned shards by removing one or more world states in the first shard and two or more replicas of the first shard, wherein a subset of the one or more world states remains in each shard, and the sum of the subsets of the one or more world states retained in all shards includes all world states originally in the first shard.

[0424] In some embodiments, the system allocates more resources to the combination of the partitioned slices than to the first slice.

[0425] Fig.19A and Fig.19B A flow chart of an example of a process 1900 for processing world state information associated with one or more blockchains is shown. For convenience, process 1900 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 The computing system 106, 108 or Figure 3 The system 300 may perform the process 1900. The process 1900 includes the following steps.

[0426] At 1902 , the system divides a plurality of user accounts into at least a first group of user accounts and a second group of user accounts.

[0427] At 1904, the system associates a first blockchain database and a first world state database with the first set of user accounts, wherein the first blockchain database includes a first blockchain managed by a first blockchain network, wherein blockchain data is stored on the first blockchain by consensus of blockchain nodes of the first blockchain network. The first world state database includes a plurality of world states, each world state is associated with a subset of the first set of user accounts, and each world state stores a current state of a user account associated with the world state.

[0428] At 1906, the system associates a second blockchain database and a second world state database with a second set of user accounts, wherein the second blockchain database includes a second blockchain managed by a second blockchain network, wherein blockchain data is stored on the second blockchain by consensus of blockchain nodes of the second blockchain network. The second world state database includes a plurality of world states, each world state is associated with a subset of the second set of user accounts, and each world state stores a current state of a user account associated with the world state.

[0429] At 1908, the system generates a first hash value representing a digital fingerprint of a world state of a first world state database, wherein the first hash value is generated based on a root hash value of each world state in the first world state database.

[0430] At 1910, the system generates a second hash value representing a digital fingerprint of a world state of a second world state database, wherein the second hash value is generated based on a root hash value of each world state in the second world state database.

[0431] At 1912, the system stores the first hash value at a block header of a first block of the first blockchain.

[0432] At 1914, the system stores the second hash value at a block header of the first block of the second blockchain.

[0433] At 1916, the system generates a group world state root hash value representing a digital fingerprint of a world state of the first world state database and the second world state database, wherein the group world state root hash value is generated based on the first hash value and the second hash value.

[0434] Fig. 20 is a flow chart of an example of a process 2000 for processing world state information associated with one or more blockchains. For convenience, process 2000 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 The computing system 106, 108 or Figure 3 The system 300 may perform the process 2000. The process 2000 includes the following steps.

[0435] At 2002, the system divides a plurality of user accounts into at least a first group of user accounts and a second group of user accounts.

[0436] At 2004, the system associates a first set of user accounts with a first blockchain database and a first world state database, wherein the first blockchain database stores transaction data associated with the first set of user accounts, and the first world state database includes a plurality of world states, and each world state is associated with a subset of the first set of user accounts.

[0437] At 2006, the system associates a second set of user accounts with a second blockchain database and a second world state database, wherein the second blockchain database stores transaction data associated with the second set of user accounts, and the second world state database includes a plurality of world states, and each world state is associated with a subset of the second set of user accounts.

[0438] At 2008, at a block header of a first block of a first blockchain, the system stores a first hash value representing a digital fingerprint of a world state in a first world state database.

[0439] At 2010, at a block header of a first block of a second blockchain, the system stores a second hash value representing a digital fingerprint of the world state in a second world state database.

[0440] At 2012, the system generates a group world state root hash value representing a digital fingerprint of a world state in the first world state database and the second world state database based on the first hash value and the second hash value.

[0441] Fig.21 is a flow chart of an example of a process 2100 for processing world state information associated with one or more blockchains. For convenience, process 2100 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 The computing system 106, 108 or Figure 3 The system 300 may perform the process 2100. The process 2100 includes the following steps.

[0442] At 2102, the system provides a group world state comprising a plurality of shards, wherein each shard comprises a world state database. The world state database comprises a plurality of world states, each world state storing information about a state of a user account associated with the world state, and each shard is associated with a blockchain database, the blockchain database comprising a blockchain comprising one or more blocks, the one or more blocks storing transaction data associated with a user account associated with the blockchain. A first shard of the plurality of shards comprises a first world state database comprising a first set of world states, the first set of world states storing state information associated with a first set of user accounts. A second shard of the plurality of shards comprises a second world state database comprising a second set of world states, the second set of world states storing state information associated with a second set of user accounts.

[0443] In some embodiments, each world state is maintained using a digital tree, a first set of world states is maintained using a first set of digital trees, a second set of world states is maintained using a second set of digital trees, and a third set of world states is maintained using a third set of digital trees, the third set of digital trees including the first set of digital trees and the second set of digital trees.

[0444] In some embodiments, each digital tree comprises at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0445] In some embodiments, the first shard is associated with a first blockchain database comprising a first blockchain that stores transaction data associated with a first set of user accounts, and the second shard is associated with a second blockchain database comprising a second blockchain that stores transaction data associated with a second set of user accounts. The system merges the first blockchain database and the second blockchain database to generate a third blockchain database comprising a third blockchain that stores transaction data associated with the first set of user accounts and the second set of user accounts.

[0446] In some embodiments, the third blockchain includes a first block storing information indicating that the third blockchain was generated by merging at least two blockchains.

[0447] In some embodiments, the first blockchain database includes a first data structure that facilitates searching for data in the first blockchain, the second blockchain database includes a second data structure that facilitates searching for data in the second blockchain, and the third blockchain database includes the first data structure and the second data structure that facilitates searching for data in the third blockchain database.

[0448] In some embodiments, the first blockchain database stores a first root hash value of a first set of world states, the second blockchain database stores a second root hash value of a second set of world states, and the third blockchain database stores a third root hash value of a third set of world states.

[0449] At 2104, the system merges the first shard and the second shard to generate a third shard, including merging the first world state database and the second world state database to generate a third world state database including a third set of world states, the third set of world states including the first set of world states and the second set of world states, wherein the third set of world states stores state information about the first set of user accounts and the second set of user accounts.

[0450] In some embodiments, the system determines that the first shard is generated by a partitioning process, which includes generating a snapshot of the fourth shard, reducing the fourth shard or the snapshot of the fourth shard to generate the first shard, and waiting for the fourth shard or the snapshot of the fourth shard to be reduced before merging the first shard and the second shard.

[0451] In some embodiments, the system allocates fewer resources to the third shard than to the first shard and the second shard combined.

[0452] In some embodiments, the resource includes at least one of computing power, memory, data storage capacity, or data bandwidth.

[0453] Fig. 22 is a flow chart of an example of a process 2200 for processing world state information associated with one or more blockchains. For convenience, the process 2200 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to the present disclosure. For example, an appropriately programmed computing system, such as Figure 1 The computing system 106, 108 or Figure 1 The system 300 may perform the process 2200. The process 2200 includes the following steps.

[0454] At 2202, the system provides a group world state comprising a plurality of shards, wherein each shard comprises a world state database. The world state database comprises a plurality of world states, each world state storing information about a state of a user account associated with the world state and each shard being associated with a blockchain database comprising a blockchain comprising one or more blocks storing transaction data associated with a user account associated with the blockchain. A first shard of the plurality of shards of the group world state comprises a first world state database.

[0455] At 2204, the system generates an intermediate shard by generating a snapshot of the first shard.

[0456] At 2206, the system removes one or more world states in the first shard to generate a second shard that includes a second subset of the one or more world states in the first shard.

[0457] At 2208, the system removes one or more world states in the intermediate shard to generate a third shard, the third shard comprising a third subset of the one or more world states in the first shard, and the third subset of the one or more world states is different from the second subset of the one or more world states.

[0458] In some embodiments, the system allocates more resources to the combination of the second shard and the third shard than to the first shard.

[0459] Fig.23 is a flow chart of an example of a process 2300 for processing world state information associated with one or more blockchains. For convenience, the process 2300 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to the present disclosure. For example, an appropriately programmed computing system, such as Figure 1 The computing system 106, 108 or Figure 3 The system 300 may perform the process 2300. The process 2300 includes the following steps.

[0460] At 2302, the system provides a group world state comprising a plurality of shards, wherein each shard comprises one or more world states, each world state stores information about a state of a user account associated with the world state, and each shard is associated with a blockchain comprising one or more blocks storing transaction data associated with the user account associated with the blockchain.

[0461] At 2304, based on a comparison of the consensus process at the first consensus node with the consensus process at one or more other consensus nodes, the system dynamically modifies the number of shards in the group world state.

[0462] In some embodiments, the number of shards in the group world state is dynamically modified by at least one of: (i) splitting one of the plurality of shards into two or more shards; (ii) merging two or more shards into one shard, (iii) adding one or more new shards to the group world state, or (iv) removing one or more shards from the group world state.

[0463] In some embodiments, if consensus processing at a first consensus node is slower than consensus processing at one or more other consensus nodes by a first threshold, the system dynamically modifies the number of shards in the group world state by increasing the number of shards in the group world state.

[0464] In some embodiments, if consensus processing at the first consensus node is faster than consensus processing at one or more other consensus nodes by a second threshold, the system dynamically modifies the number of shards in the group world state by reducing the number of shards in the group world state.

[0465] At 2306, the system generates a root hash value of the group world state, wherein the root hash value represents a digital fingerprint of a state of a user account associated with a world state in a shard of the group world state.

[0466] In some embodiments, the system provides a first set of one or more rules that specify one or more conditions under which a number of shards in a group world state is to be increased.

[0467] In some embodiments, the system determines a first speed of consensus processing at a first consensus node, determines a second speed of consensus processing at one or more other consensus nodes, compares the first speed of consensus processing at the first consensus node with the second speed of consensus processing at the one or more other consensus nodes, and generates a result comparing the consensus processing at the first consensus node with the consensus processing at the one or more other consensus nodes.

[0468] In some embodiments, the system provides a second set of one or more rules that specify one or more conditions under which the number of shards in the group world state is to be reduced.

[0469] Fig.24 is a flow chart illustrating an example of a process 2400 for processing world state information associated with a blockchain. For convenience, the process 2400 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to the present disclosure. For example, an appropriately programmed computing system, such as Figure 1 computing systems 106, 108, Figure 3 System 300, Fig.40 The system 4000 may perform the process 2400. The process 2400 includes the following steps.

[0470] At 2402, the system provides a first smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network.

[0471] At 2404, the system provides a first Merkle tree and a second Merkle tree to maintain a first world state associated with a first set of user accounts, wherein the first world state stores data about a current state of the first set of user accounts and a current state of a first smart contract. The first smart contract includes: a first code that specifies first data to be stored in the first Merkle tree, and a second code that specifies second data to be stored in the second Merkle tree.

[0472] In some embodiments, the first code specifies that data associated with user accounts in a first geographic region is to be stored in a first Merkle tree, and the second code specifies that data associated with user accounts in a second geographic region is to be stored in a second Merkle tree.

[0473] In some embodiments, the system provides a third Merkle tree, wherein the first Merkle tree, the second Merkle tree, and the third Merkle tree in combination maintain a world state associated with multiple user accounts. The first smart contract includes: a first code that specifies that the first data is to be stored in the first Merkle tree; a second code that specifies that the second data is to be stored in the second Merkle tree; and a third code that specifies that the third data is to be stored in the third Merkle tree.

[0474] In some embodiments, the first Merkle tree has a first address, the second Merkle tree has a second address, the first code specifies that the first data is to be stored in the Merkle tree having the first address, and the second code specifies that the second data is to be stored in the Merkle tree having the second address.

[0475] In some embodiments, the system provides a virtual machine configured to execute a first smart contract so that the first data is stored in a first Merkle tree and the second data is stored in a second Merkle tree.

[0476] In some embodiments, the system provides a compiler configured to compile the first smart contract into bytecode executable by a virtual machine.

[0477] In some embodiments, the first smart contract specifies that the first Merkle tree is stored at a first storage device and the second Merkle tree is stored at a second storage device.

[0478] In some embodiments, the first smart contract specifies that both the first Merkle tree and the second Merkle tree are stored at the first storage device.

[0479] In some embodiments, the system generates an index of the data stored in the first storage device and stores the index in the first and second Merkle trees.

[0480] In some embodiments, the system provides a second smart contract that is also associated with the blockchain, wherein the second smart contract includes third code that specifies that third data is to be stored in the first Merkle tree.

[0481] In some embodiments, the first Merkle tree stores state information of user accounts based on a first geographic region, and the second Merkle tree stores state information of user accounts based on a second geographic region.

[0482] In some embodiments, the system provides a second smart contract associated with the blockchain; provides a third Merkle tree to maintain a second world state that stores data about a current state of the second smart contract; and determines a world state root hash value based on a first root hash value of the first Merkle tree and a second root hash value of the second Merkle tree.

[0483] Fig.25 is a flow chart of an example of a process 2500 for processing world state information associated with a blockchain. For convenience, process 2500 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 computing systems 106, 108, Figure 3 System 300, Fig.40 The system 4000 may perform the process 2500. The process 2500 includes the following steps.

[0484] At 2502, the system receives a smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network.

[0485] At 2504, the system identifies a first code specifying first data and a first Merkle tree in a smart contract.

[0486] At 2506, the system identifies a second code specifying second data and a second Merkle tree in the smart contract.

[0487] In some embodiments, the first code specifies that data associated with user accounts in a first geographic region is to be stored in a first Merkle tree, and the second code specifies that data associated with user accounts in a second geographic region is to be stored in a second Merkle tree.

[0488] At 2508, the system stores the first data in a first Merkle tree.

[0489] At 2510, the system stores the second data in a second Merkle tree.

[0490] In some embodiments, the system executes a virtual machine to execute a first smart contract so that the first data is stored in a first Merkle tree and the second data is stored in a second Merkle tree.

[0491] Fig.26 is a flow chart of an example of a process 2600 for processing world state information associated with a blockchain. For convenience, process 2600 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 computing systems 106, 108, Figure 3 System 300, Fig.40 The system 4000 may perform the process 2600. The process 2600 includes the following steps.

[0492] At 2602, the system provides a smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network.

[0493] At 2604, the system provides a plurality of Merkle trees to maintain a world state associated with a set of user accounts, wherein the world state stores data about a current state of the user accounts and a current state of a smart contract. A first smart contract includes a first code that specifies which Merkle tree of the plurality of Merkle trees is used to store data.

[0494] In some embodiments, the first code includes a decoration comprising an identification of a Merkle tree for storing the data segment.

[0495] In some embodiments, the identification of the Merkle tree includes an address of the Merkle tree.

[0496] In some embodiments, the identifier of the Merkle tree includes a variable.

[0497] In some embodiments, the identification is determined based on a mathematical function.

[0498] In some embodiments, the identification is determined based on one or more rules.

[0499] In some embodiments, the system provides a compiler configured to recognize decorations and compile the smart contract into bytecode executable by a virtual machine associated with the blockchain.

[0500] Fig. 27 2700 is a diagram of an example of a module of an apparatus 2700 according to an embodiment of the present invention. The apparatus 2700 may be an example of an embodiment of a system configured to process world state information associated with one or more blockchains. The apparatus 2700 may correspond to the above-mentioned embodiment, and the apparatus 2700 includes the following:

[0501] providing module 2702, providing a group world state comprising a plurality of shards, wherein each shard comprises one or more world states, each world state stores information about a state of a user account associated with the world state, and each shard is associated with a blockchain comprising one or more blocks, the one or more blocks storing transaction data associated with the user account associated with the blockchain;

[0502] A dynamic modification module 2704 dynamically modifies the number of shards in the group world state based on one or more conditions, including at least one of: (i) splitting one of the plurality of shards into two or more shards, (ii) merging two or more shards into one shard, (iii) adding one or more new shards to the group world state, or (iv) removing one or more shards from the group world state; and

[0503] A generation module 2706 generates a root hash value of a group world state, wherein the root hash value represents a digital fingerprint of a state of a user account associated with a world state of a shard in the group world state.

[0504] In an optional embodiment, the dynamic modification module may include a partitioning submodule that divides the first shard into a second shard and a third shard, the second shard including a second subset of the world state of the first shard, and the third shard including a third subset of the world state of the first shard.

[0505] In an optional embodiment, the dynamic modification module may include a merging submodule that merges the second shard and the third shard to generate a first shard, wherein the first shard includes one or more world states of the second shard and one or more world states of the third shard.

[0506] In an optional embodiment, the dynamic modification module may include an adding module that adds one or more new shards to the group world state, wherein the one or more new shards include one or more world states that were not previously included in the group world state.

[0507] In an optional embodiment, the dynamic modification module may include a removal submodule that removes one or more shards from the group world state, including removing one or more world states in the removed one or more shards from the group world state.

[0508] In an optional embodiment, the device 2700 may also include: an evaluation module, which evaluates one or more criteria; and a partitioning module, which partitions one of the multiple shards into two or more shards when it is determined that the one or more criteria are met.

[0509] In an optional embodiment, the device 2700 may further include: an evaluation module, which evaluates one or more criteria; and a merging module, which merges two or more fragments into one fragment when it is determined that the one or more criteria are met.

[0510] In an optional embodiment, the apparatus 2700 may further include a second dynamic modification module, which dynamically modifies the resources allocated to the group world state based on the number of shards in the group world state.

[0511] In an optional embodiment, the apparatus 2700 may further include an allocation module that allocates more resources to the group world state in response to an increase in the number of shards in the group world state.

[0512] In an optional embodiment, the apparatus 2700 may further include an allocation module that allocates fewer resources to the group world state in response to a decrease in the number of shards in the group world state.

[0513] In an optional embodiment, the resource may include at least one of computing power, storage, data storage capacity, or data bandwidth.

[0514] In an optional embodiment, the one or more conditions may include at least one of a quality of service metric, a computing power requirement, a memory requirement, a data storage requirement, or a data bandwidth requirement.

[0515] In an optional embodiment, the device 2700 may also include a determination module that determines at least one of the following: (i) the quality of service metric is less than a threshold, (ii) the computing power requirement is not met, (iii) the memory capacity requirement is not met, (iv) the data storage capacity requirement is not met, or (v) the data bandwidth requirement is not met. The device 2700 may also include a partitioning module that, in response to the determination, partitions one of the plurality of shards into two or more shards. The device 2700 may also include an allocation module that allocates more resources to a combination of the two or more shards than to one of the plurality of shards, wherein the resources include at least one of computing power, memory capacity, data storage capacity, or data bandwidth.

[0516] In an optional embodiment, the device 2700 may also include a determination module that determines at least one of the following: (i) a quality of service metric is greater than a threshold, (ii) idle or excess computing power is greater than a threshold, (iii) available storage capacity is greater than a threshold, (iv) available data storage capacity is greater than a threshold, or (v) available data bandwidth is greater than a threshold. The device 2700 may also include a merging module that merges two or more shards into a single shard in response to the determination. The device 2700 may also include an allocation module that allocates fewer resources to the single shard after the merger than to the two or more shards before the merger, wherein the resources include at least one of computing power, memory capacity, data storage capacity, or data bandwidth.

[0517] In an optional embodiment, each world state may be maintained using at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0518] In an optional embodiment, dividing one of the plurality of shards into two or more shards may include dividing a first shard into a second shard and a third shard, wherein the first shard includes a first world state database including a first set of world states. The partitioning module may include a generation submodule that generates a first snapshot of the first shard, wherein the first snapshot includes a snapshot of the first world state database. The partitioning module may include a reduction submodule that reduces the first shard to generate a second shard, including removing one or more world states in the first world state database to generate a second world state database, the second world state database including a second subset of the one or more world states in the first shard. The partitioning module may include a reduction submodule that reduces the first snapshot of the first shard to generate a third shard, including removing one or more world states in the first world state database to generate a third world state database, the third world state database including a third subset of the one or more world states in the first shard, wherein the third subset of the one or more world states is different from the second subset of the one or more world states.

[0519] In an optional embodiment, dividing one of the plurality of shards into two or more shards may include dividing one of the plurality of shards into three or more shards.

[0520] In an optional embodiment, merging two or more shards into one shard may include merging a second shard and a third shard into a first shard. The second shard may include a second world state database including a second set of world states storing state information associated with a second set of user accounts. The third shard may include a third world state database including a third set of world states storing state information associated with a third set of user accounts. The first shard may include a first world state database including a first set of world states including a second set of world states and a third set of world states, the first set of world states storing state information associated with a first set of user accounts including a second set of user accounts and a third set of user accounts.

[0521] In an optional embodiment, dividing one of the plurality of shards into two or more shards may include dividing the first shard into a second shard and a third shard, the first shard being associated with a first group of user accounts, the second shard being associated with a second group of user accounts, the third shard being associated with a third group of user accounts, the second group of user accounts being a second subset of the first group of user accounts, the third group of user accounts being a third subset of the first group of user accounts, and the third group of user accounts being different from the second group of user accounts.

[0522] In an optional embodiment, the device 2700 may further include an association module that associates user accounts with world states based on characteristics of the user accounts, wherein each user account is associated with only one of the world states.

[0523] In an alternative embodiment, a user account may be associated with a world state based on characteristics of the user account identification.

[0524] In an alternative embodiment, a user account may be associated with a world state based on a predetermined byte or byte word of the user account identification.

[0525] In an alternative embodiment, the group world state can support up to 2 n world state, and a user account whose user account identifier has a predetermined byte or byte word equal to m is associated with the mth world state, 1≤m≤2 n .

[0526] In an alternative embodiment, the group world state can support up to 2 16 =65536 world states, and the user account whose first two bytes of the user account identifier are equal to m is associated with the mth world state, 1≤m≤65536.

[0527] In an alternative embodiment, user accounts may be associated with world states based on their priority.

[0528] In an optional embodiment, the apparatus 2700 may further include a providing module that provides a first set of one or more rules that specify one or more conditions for increasing the number of shards in the group world state.

[0529] In an optional embodiment, the apparatus 2700 may further include a providing module that provides a second set of one or more rules that specify one or more conditions for reducing the number of shards in the group world state.

[0530] Fig.28 2800 is a diagram of an example of a module of an apparatus 2800 according to an embodiment of the present invention. The apparatus 2800 may be an example of an embodiment of a system configured to process world state information associated with one or more blockchains. The apparatus 2800 may correspond to the above-mentioned embodiment, and the apparatus 2800 includes the following:

[0531] providing module 2802, providing a first shard associated with a first set of user accounts, wherein the first shard includes a first blockchain database and a first world state database, the first blockchain database including a first blockchain managed by a first blockchain network, wherein blockchain data is stored on the first blockchain by consensus of blockchain nodes of the first blockchain network, the first world state database including a plurality of world states, each world state being associated with a plurality of user accounts, each world state storing a current state of a user account associated with the world state; and

[0532] A partitioning module 2804, which partitions the first shard into a second shard and a third shard. The partitioning module includes a generating submodule 2806, which generates a first snapshot of the first shard, wherein the first snapshot includes a snapshot of the first blockchain database and a snapshot of the first world state database. The partitioning module includes a first reduction submodule 2808, which reduces the first shard to generate a second shard, including removing one or more world states in the first world state database of the first shard to generate a second world state database, the second world state database including a second subset of the one or more world states in the first shard. The partitioning module also includes a second reduction submodule 2810, which reduces the first snapshot of the first shard to generate a third shard, including removing one or more world states in the first world state database in the first snapshot to generate a third world state database, the third world state database including a third subset of the one or more world states in the first shard, wherein the third subset of the one or more world states is different from the second subset of the one or more world states.

[0533] In an optional embodiment, the apparatus 2800 may further include an allocation module that allocates more resources to the combination of the second slice and the third slice than to the first slice after dividing the first slice into the second slice and the third slice.

[0534] In an optional embodiment, the first world state database may be associated with a first group of user accounts, the second world state database may be associated with a second group of user accounts, the third world state database may be associated with a third group of user accounts, and the first group of user accounts may include the sum of the second group of user accounts and the third group of user accounts.

[0535] In an optional embodiment, the first world state database can be associated with a first group of user accounts, the second world state database can be associated with a second group of user accounts, and the third world state database can be associated with a third group of user accounts, and the second group of user accounts does not overlap with the third group of user accounts.

[0536] In an optional embodiment, allocating more resources may include allocating at least one of more computing power, memory, data storage capacity, or data bandwidth.

[0537] In an optional embodiment, generating the snapshot of the first shard may include generating the snapshot of the first shard using a virtual machine associated with the first shard.

[0538] In an optional embodiment, the first blockchain network may include a consensus blockchain network including validating peer nodes that participate in a consensus process to determine whether to write data on the blockchain, and non-validating peer nodes that do not participate in the consensus process. Generating a snapshot of the first shard may include using a non-validating peer node to generate the snapshot.

[0539] In an optional embodiment, the consensus blockchain network may include validating peer nodes that participate in the consensus process to determine whether to write data on the blockchain, and non-validating peer nodes that do not participate in the consensus process. Generating a snapshot of the first shard may include increasing the number of validating peer nodes, and using the validating peer nodes to generate the snapshot.

[0540] In an optional embodiment, each of the multiple world states of the first world state database may include a root node. The first blockchain of the first blockchain database may include a first block, the first block includes a block header and a block body, the block header stores a first hash value obtained by hashing the hash value of the root node of the multiple world states of the first world state database, and the first hash value represents a digital fingerprint of the current state of the user account associated with the multiple world states of the first world state database.

[0541] In an optional embodiment, each of the multiple world states of the first world state database may include a root node, the first blockchain of the first blockchain database may include a first block, the first block may include a block header and a block body, and the block header stores a hash value of the root node of the world state in the first world state database.

[0542] In an optional embodiment, the second shard may include a second blockchain database, the second blockchain database including a second blockchain, the second blockchain storing transaction data associated with a user account associated with the second shard. The second blockchain may include a first block, and the first block may include a block body storing information about transactions. The first reduction submodule may include a first removal submodule that removes information about transactions associated with a user account that is not associated with a second subset of one or more world states in the second world state database.

[0543] In an optional embodiment, the third shard may include a third blockchain database, the third blockchain database including a third blockchain, the third blockchain storing transaction data associated with a user account associated with the third shard. The third blockchain may include a first block, and the first block may include a block body storing information about transactions. The second reduction submodule may include a second removal submodule that removes information about transactions associated with a user account that is not associated with a third subset of one or more world states in the third world state database.

[0544] In an optional embodiment, the third shard may include a third blockchain database, the third blockchain database including a third blockchain, the third blockchain storing transaction data associated with a user account associated with the third shard. The device 2800 may also include a partitioning module that partitions the third shard into a fourth shard and a fifth shard. The partitioning module may include a generation submodule that generates a second snapshot of the third shard, wherein the second snapshot includes a snapshot of the third blockchain database and a snapshot of the third world state database. The partitioning module may include a first reduction submodule that reduces the third shard to generate a fourth shard, including removing one or more world states in the third world state database of the third shard to generate a fourth world state database including a fourth subset of one or more world states in the third shard. The partitioning module may include a second reduction module that reduces the second snapshot of the third shard to generate a fifth shard, including removing one or more world states in the third world state database in the second snapshot to generate a fifth world state database, the fifth world state database including a fifth subset of one or more world states in the third shard, wherein the fifth subset of one or more world states is different from the fourth subset of one or more world states.

[0545] In an optional embodiment, the apparatus 2800 may further include an allocation module that allocates more resources to the combination of the fourth slice and the fifth slice than to the third slice.

[0546] In an optional embodiment, each world state may be maintained using at least one digital tree including a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0547] In an optional embodiment, the device 2800 may further include a generation module that generates a group world state hash value representing the world state of the first and second shards based on the hash value of the root node of the digital tree that maintains the world state of the first and second shards.

[0548] In an optional embodiment, the device 2800 may also include a generation module that generates a simplified payment verification proof for a transaction associated with a user account by generating a first proof based on a path from a root node of the group world state to a root node of a sharded world state, generating a second proof based on a path from the root node of the sharded world state to a root node of a world state associated with a user account, and generating a third proof based on a path from the root node of the world state to a node representing the user account.

[0549] Fig.29 2900 is a diagram of an example of a module of an apparatus 2900 according to an embodiment of the present invention. The apparatus 2900 may be an example of an embodiment of a system configured to process world state information associated with one or more blockchains. The apparatus 2900 may correspond to the above-mentioned embodiment, and the apparatus 2900 includes the following:

[0550] Providing module 2902, providing a first shard of a blockchain ledger, wherein the first shard includes a first blockchain database and a first world state database, the first world state database includes a plurality of world states, and each world state stores a current state of a user account associated with the world state;

[0551] A first generation module 2904 generates a first copy of the first shard, including a copy of the first blockchain database and a copy of the first world state database;

[0552] A second generation module 2906 generates a second shard by removing one or more world states in the first world state database of the first shard, wherein a second subset of the one or more world states in the first shard is retained in the second shard; and

[0553] A third generation module 2908 generates a third shard by removing one or more world states in the first world state database in the first replica of the first shard, wherein a third subset of the one or more world states in the first shard is retained in the third shard, and the third subset of the one or more world states is different from the second subset of the one or more world states.

[0554] In an optional embodiment, the apparatus 2900 may further include an allocation module that allocates more resources to the combination of the second slice and the third slice than to the first slice.

[0555] Fig.30 3000 is a diagram of an example of a module of an apparatus 3000 according to an embodiment of the present invention. The apparatus 3000 may be an example of an embodiment of a system configured to process world state information associated with one or more blockchains. The apparatus 3000 may correspond to the above-mentioned embodiment, and the apparatus 3000 includes the following:

[0556] A division module 3002 that divides a plurality of user accounts into at least a first group of user accounts and a second group of user accounts;

[0557] a first associating module 3004, associating a first blockchain database and a first world state database with the first set of user accounts, wherein the first blockchain database comprises a first blockchain managed by a first blockchain network, wherein blockchain data is stored in the first blockchain by consensus of blockchain nodes of the first blockchain network, and the first world state database comprises a plurality of world states, each world state being associated with a subset of the first set of user accounts, each world state storing a current state of a user account associated with the world state;

[0558] a second associating module 3006, associating a second blockchain database and a second world state database with the second set of user accounts, wherein the second blockchain database comprises a second blockchain managed by a second blockchain network, wherein blockchain data is stored in the second blockchain by consensus of blockchain nodes of the second blockchain network, and the second world state database comprises a plurality of world states, each world state being associated with a subset of the second set of user accounts, each world state storing a current state of a user account associated with the world state;

[0559] A first generation module 3008 generates a first hash value, wherein the first hash value represents a digital fingerprint of a world state of a first world state database, wherein the first hash value is generated based on a root hash value of each world state in the first world state database;

[0560] A second generation module 3010 generates a second hash value, wherein the second hash value represents a digital fingerprint of a world state of a second world state database, wherein the second hash value is generated based on a root hash value of each world state in the second world state database;

[0561] A first storage module 3012 stores the first hash value in a block header of a first block of the first blockchain;

[0562] A second storage module 3014 stores the second hash value at the block header of the first block of the second blockchain; and

[0563] A third generation module 3016 is configured to generate a group world state root hash value, wherein the group world state root hash value represents a digital fingerprint of the world state of the first and second world state databases, wherein the group world state root hash value is generated based on the first hash value and the second hash value.

[0564] Fig.31 3100 is a diagram of an example of modules of an apparatus 3100 according to an embodiment of the present invention. The apparatus 3100 may be an example of an embodiment of a system configured to process world state information associated with one or more blockchains. The apparatus 3100 may correspond to the above-mentioned embodiment, and the apparatus 3100 includes the following:

[0565] A division module 3102 that divides a plurality of user accounts into at least a first group of user accounts and a second group of user accounts;

[0566] A first associating module 3104 associates the first set of user accounts with a first blockchain database and a first world state database, wherein the first blockchain database stores transaction data associated with the first set of user accounts, and the first world state database includes a plurality of world states, and each world state is associated with a subset of the first set of user accounts;

[0567] a second associating module 3106, associating a second set of user accounts with a second blockchain database and a second world state database, wherein the second blockchain database stores transaction data associated with the second set of user accounts, and the second world state database includes a plurality of world states, and each world state is associated with a subset of the second set of user accounts;

[0568] A first storage module 3108 stores a first hash value at a block header of a first block of the first blockchain, where the first hash value represents a digital fingerprint of a world state in the first world state database;

[0569] A second storage module 3110 stores a second hash value at a block header of the first block of the second blockchain, the second hash value representing a digital fingerprint of the world state in the second world state database; and

[0570] A generating module 3112 generates a group world state root hash value based on the first hash value and the second hash value, wherein the group world state root hash value represents a digital fingerprint of the world state in the first and second world state databases.

[0571] Fig.32 3200 is a diagram of an example of modules of an apparatus 3200 according to an embodiment of the present invention. The apparatus 3200 may be an example of an embodiment of a system configured to process world state information associated with one or more blockchains. The apparatus 3200 may correspond to the above-mentioned embodiment, and the apparatus 3200 includes the following:

[0572] providing a module 3202, providing a group world state comprising a plurality of shards, wherein each shard comprises a world state database, the world state database comprising a plurality of world states, each world state storing information about a state of a user account associated with the world state, each shard being associated with a blockchain database comprising a blockchain comprising one or more blocks, the one or more blocks storing transaction data associated with the user account associated with the blockchain; wherein a first shard of the plurality of shards comprises a first world state database comprising a first set of world states storing state information about a first group of user accounts, and a second shard of the plurality of shards comprises a second world state database comprising a second set of world states storing state information about a second group of user accounts; and

[0573] A merging module 3204, merging the first shard and the second shard to generate a third shard, comprising merging the first world state database and the second world state database to generate a third world state database, the third world state database comprising a third set of world states, the third set of world states comprising the first set of world states and the second set of world states, wherein the third set of world states stores state information about the first set of user accounts and the second set of user accounts.

[0574] In an optional embodiment, a digital tree can be used to maintain each world state, a first group of digital trees can be used to maintain a first group of world states, a second group of digital trees can be used to maintain a second group of world states, and a third group of digital trees can be used to maintain a third group of world states, the third group of digital trees including the first group of digital trees and the second group of digital trees.

[0575] In an optional embodiment, each digital tree may include at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0576] In an optional embodiment, the device 3200 may also include a determination module that determines that the first shard is generated by partition processing including generating a snapshot of the fourth shard; a reduction module that reduces the fourth shard or the snapshot of the fourth shard to generate the first shard; and a waiting module that waits for the fourth shard or the snapshot of the fourth shard to complete the reduction before merging the first shard and the second shard.

[0577] In an alternative embodiment, the apparatus 3200 may further include an allocation module that allocates fewer resources to the third slice than the resources allocated to the combination of the first slice and the second slice.

[0578] In an optional embodiment, the resource may include at least one of computing power, memory, data storage capacity, or data bandwidth.

[0579] In an optional embodiment, the first shard may be associated with a first blockchain database, the first blockchain database including a first blockchain storing transaction data associated with a first set of user accounts, and the second shard may be associated with a second blockchain database, the second blockchain database including a second blockchain storing transaction data associated with a second set of user accounts. The apparatus 3200 may also include a merging module that merges the first blockchain database and the second blockchain database to generate a third blockchain database, the third blockchain database including a third blockchain storing transaction data associated with the first set of user accounts and the second set of user accounts.

[0580] In an optional embodiment, the third blockchain may include a first block storing information indicating that the third blockchain is generated by merging at least two blockchains.

[0581] In an optional embodiment, the first blockchain database may include a first data structure to facilitate data search in the first blockchain, the second blockchain database may include a second data structure to facilitate data search in the second blockchain, and the third blockchain database may include the first data structure and the second data structure to facilitate data search in the third blockchain database.

[0582] In an optional embodiment, the first blockchain database may store a first root hash value of a first set of world states, the second blockchain database may store a second root hash value of a second set of world states, and the third blockchain database may store a third root hash of a third set of world states.

[0583] Fig.333300 is a diagram of an example of a module of an apparatus 3300 according to an embodiment of the present invention. The apparatus 3300 may be an example of an embodiment of a system configured to process world state information associated with one or more blockchains. The apparatus 3300 may correspond to the above-mentioned embodiment, and the apparatus 3300 includes the following:

[0584] providing a module 3302 for providing a group world state comprising a plurality of shards, wherein each shard comprises a world state database, the world state database comprising a plurality of world states, each world state storing information about a state of a user account associated with the world state, and each shard being associated with a blockchain database comprising a blockchain comprising one or more blocks, the one or more blocks storing transaction data associated with the user account associated with the blockchain; wherein a first shard of the plurality of shards of the group world state comprises a first world state database;

[0585] A generation module 3304 generates an intermediate shard by generating a snapshot of the first shard;

[0586] A first removal module 3306 that removes one or more world states in the first shard to generate a second shard that includes a second subset of the one or more world states in the first shard; and

[0587] A second removal module 3308 removes one or more world states in the intermediate shard to generate a third shard, the third shard comprising a third subset of the one or more world states in the first shard, wherein the third subset of the one or more world states is different from the second subset of the one or more world states.

[0588] In an optional embodiment, the apparatus 3300 may further include an allocation module that allocates more resources to the combination of the second slice and the third slice than to the first slice.

[0589] Fig.34 3400 is a diagram of an example of modules of an apparatus 3400 according to an embodiment of the present invention. The apparatus 3400 may be an example of an embodiment of a system configured to process world state information associated with one or more blockchains. The apparatus 3400 may correspond to the above-mentioned embodiment, and the apparatus 3400 includes the following:

[0590] providing a module 3402 that provides a group world state comprising a plurality of shards, wherein each shard comprises one or more world states, each world state stores information about a state of a user account associated with the world state, and each shard is associated with a blockchain comprising one or more blocks, the one or more blocks storing transaction data associated with the user account associated with the blockchain;

[0591] A dynamic modification module 3404, which dynamically modifies the number of shards in the group world state based on a comparison result of the consensus process at the first consensus node and the consensus process at one or more other consensus nodes; and

[0592] A generating module 3406 generates a root hash value of the group world state, wherein the root hash value represents a digital fingerprint of a state of a user account associated with a world state in a shard in the group world state.

[0593] In an optional embodiment, dynamically modifying the number of shards in the group world state may include at least one of the following: (i) splitting one of the multiple shards into two or more shards, (ii) merging two or more shards into one shard, (iii) adding one or more new shards to the group world state, or (iv) removing one or more shards from the group world state.

[0594] In an optional embodiment, if consensus processing at the first consensus node is slower than consensus processing at one or more other consensus nodes by a first threshold, dynamically modifying the number of shards in the group world state may include increasing the number of shards in the group world state.

[0595] In an optional embodiment, dynamically modifying the plurality of shards in the group world state may include reducing the number of shards in the group world state if consensus processing at the first consensus node is faster than consensus processing at one or more other consensus nodes by a second threshold.

[0596] In an optional embodiment, the apparatus 3400 may further include a providing module that provides a first set of one or more rules that specify one or more conditions for increasing the number of shards in the group world state.

[0597] In an optional embodiment, the apparatus 3400 may further include a providing module that provides a second set of one or more rules that specify one or more conditions for reducing the number of shards in the group world state.

[0598] In an optional embodiment, the device 3400 may also include: a first determination module that determines a first speed of consensus processing at the first consensus node; a second determination module that determines a second speed of consensus processing at one or more other consensus nodes; a comparison module that compares the first speed of consensus processing at the first consensus node and the second speed of consensus processing at one or more other consensus nodes; and a generation module that generates a comparison result of the consensus processing at the first consensus node and the consensus processing at one or more other consensus nodes.

[0599] Fig.353500 is a diagram of an example of a module of an apparatus 3500 according to an embodiment of the present invention. The apparatus 3500 may be an example of an embodiment of a system configured to process world state information associated with a blockchain. The apparatus 3500 may correspond to the above-mentioned embodiment, and the apparatus 3500 includes the following:

[0600] A first providing module 3502, providing a first smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network; and

[0601] A second providing module 3504 provides a first Merkle tree and a second Merkle tree to maintain a first world state associated with a first set of user accounts, wherein the first world state stores data about a current state of the first set of users and a current state of a first smart contract; wherein the first smart contract includes: a first code specifying that the first data is to be stored in the first Merkle tree; and a second code specifying that the second data is to be stored in the second Merkle tree.

[0602] In an alternative embodiment, the first code may specify that data associated with user accounts in a first geographic region is to be stored in a first Merkle tree, and the second code may specify that data associated with user accounts in a second geographic region is to be stored in a second Merkle tree.

[0603] In an optional embodiment, the device 3500 may further include a third providing module that provides a third Merkle tree, wherein the first Merkle tree, the second Merkle tree, and the third Merkle tree in combination maintain a world state associated with multiple user accounts. The first smart contract may include: a first code that specifies that the first data is to be stored in the first Merkle tree; a second code that specifies that the second data is to be stored in the second Merkle tree; and a third code that specifies that the third data is to be stored in the third Merkle tree.

[0604] In an optional embodiment, the first Merkle tree may have a first address, the second Merkle tree may have a second address, the first code may specify that the first data is stored in the Merkle tree with the first address, and the second code may specify that the second data is stored in the Merkle tree with the second address.

[0605] In an optional embodiment, the device 3500 may also include a fourth providing module, which provides a virtual machine configured to execute the first smart contract so that the first data is stored in the first Merkle tree and the second data is stored in the second Merkle tree.

[0606] In an optional embodiment, the device 3500 may also include a fifth providing module, which provides a compiler configured to compile the first smart contract into bytecode executable by a virtual machine.

[0607] In an optional embodiment, the first smart contract may specify that the first Merkle tree is stored at a first storage device and the second Merkle tree is stored at a second storage device.

[0608] In an optional embodiment, the first smart contract may specify that both the first Merkle tree and the second Merkle tree are stored at the first storage device.

[0609] In an optional embodiment, the apparatus 3500 may further include a generation module that generates an index of the data stored in the first storage device and stores the index in the first and second Merkle trees.

[0610] In an optional embodiment, the device 3500 may also include a sixth providing module, which provides a second smart contract that is also associated with the blockchain, wherein the second smart contract includes a third code specifying that the third data is to be stored in the first Merkle tree.

[0611] In an optional embodiment, the first Merkle tree may store the status information of the user account based on the first geographical area, and the second Merkle tree may store the status information of the user account based on the second geographical area.

[0612] In an optional embodiment, the device 3500 may also include: a seventh providing module, which provides a second smart contract associated with the blockchain; an eighth providing module, which provides a third Merkle tree to maintain a second world state, which stores data about the current state of the second smart contract; and a determination module, which determines the world state root hash value based on the first root hash value of the first Merkle tree and the second root hash value of the second Merkle tree.

[0613] Fig.36 3600 is a diagram of an example of a module of an apparatus 3600 according to an embodiment of the present invention. The apparatus 3600 may be an example of an embodiment of a system configured to process world state information associated with a blockchain. The apparatus 3600 may correspond to the above-mentioned embodiment, and the apparatus 3600 includes the following:

[0614] A receiving module 3602 receives a smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain through consensus of blockchain nodes of the blockchain network;

[0615] A first identification module 3604, used to identify the first data and the first code of the first Merkle tree in the smart contract;

[0616] A second identification module 3606, used to identify the second code of the specified second data and the second Merkle tree in the smart contract;

[0617] A first storage module 3608 stores the first data in a first Merkle tree; and

[0618] The second storage module 3610 stores the second data in the second Merkle tree.

[0619] In an alternative embodiment, the first code may specify that data associated with user accounts in a first geographic region is to be stored in a first Merkle tree, and the second code may specify that data associated with user accounts in a second geographic region is to be stored in a second Merkle tree.

[0620] In an optional embodiment, the device 3600 may also include an execution module that executes a virtual machine to execute the first smart contract so that the first data is stored in the first Merkle tree and the second data is stored in the second Merkle tree.

[0621] Fig.37 3700 is a diagram of an example of a module of an apparatus 3700 according to an embodiment of the present invention. The apparatus 3700 may be an example of an embodiment of a system configured to process world state information associated with a blockchain. The apparatus 3700 may correspond to the above-mentioned embodiment, and the apparatus 3700 includes the following:

[0622] A first providing module 3702, providing a smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain through consensus of blockchain nodes of the blockchain network; and

[0623] a second providing module that provides a plurality of Merkle trees to maintain a world state associated with a set of user accounts, wherein the world state stores data about a current state of the user accounts and a current state of the smart contract; wherein the first smart contract includes a first code that specifies which Merkle tree of the plurality of Merkle trees to use to store a data segment.

[0624] In an optional embodiment, the first code may include a modification including an identification of a Merkle tree used to store the data segment.

[0625] In an optional embodiment, the identifier of the Merkle tree may include the address of the Merkle tree.

[0626] In an alternative embodiment, the identifier of the Merkle tree may include a variable.

[0627] In an alternative embodiment, the identification may be determined based on a mathematical function.

[0628] In an alternative embodiment, the identification may be determined based on one or more rules.

[0629] In an optional embodiment, the device 3700 may further include a third providing module that provides a compiler configured to identify the decoration and compile the smart contract into a bytecode executable by a virtual machine associated with the blockchain.

[0630] Fig.38 is a flow chart of an example of a process 3800 for processing world state information associated with a blockchain. For convenience, process 3800 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, an appropriately programmed computing system, such as Figure 1 computing systems 106, 108, Figure 3 System 300, or Fig.40 The system 4000 may perform the process 3800. The process 3800 includes the following steps.

[0631] At 3802, the system provides a plurality of smart contracts associated with a plurality of user accounts, wherein each smart contract is associated with a corresponding blockchain managed by a corresponding blockchain network, and wherein blockchain data is stored on the blockchain through a consensus of blockchain nodes of the blockchain network.

[0632] In some embodiments, the smart contract includes code written in a high-level language or blockchain programming language (e.g., Solidity, Serpent) or a low-level Lisp-like language (LLL).

[0633] At 3804, the system provides a plurality of digital trees to maintain one or more world states associated with smart contracts and user accounts, wherein each world state stores state data associated with at least one of the user account or the smart contract. A first smart contract in the plurality of smart contracts includes a first code that identifies first state data and a first digital tree in the plurality of digital trees for storing the first state data.

[0634] In some embodiments, the state data identified by the first code includes at least one of: (i) data regarding a state of a user account associated with the first smart contract, or (ii) data regarding a state of the first smart contract.

[0635] In some embodiments, the first smart contract includes a second code, the second state identifying second state data and a second digital tree in a plurality of digital trees for storing the second state data. The compiler is configured to recognize and compile the first code and the second code so that the first bytecode, when executed by the virtual machine, causes the first state data to be stored in the first digital tree and causes the second state data to be stored in the second digital tree.

[0636] In some embodiments, the first and second digital trees, in combination, maintain a world state associated with a user account associated with the first smart contract.

[0637] In some embodiments, the first code specifies that state data associated with user accounts in a first geographic region is to be stored in a first digital tree and the second code specifies that state data associated with user accounts in a second geographic region is to be stored in a second digital tree.

[0638] In some embodiments, the first smart contract includes a third code that identifies third state data and a third digital tree in a plurality of digital trees for storing the third state data. The first, second, and third digital trees in combination maintain a world state associated with a user account associated with the first smart contract. The compiler is configured to identify and compile the first code, the second code, and the third code so that when the first bytecode is executed by the virtual machine, the first state data is stored in the first digital tree, the second state data is stored in the first digital tree, and the third state data is stored in the third digital tree.

[0639] In some embodiments, the first, second, and third digital trees in combination maintain a world state associated with a user account associated with the first smart contract.

[0640] In some embodiments, a first code specifies that status data associated with user accounts in a first geographic region will be stored in a first digital tree, a second code specifies that status data associated with user accounts in a second geographic region will be stored in a second digital tree, and a third code specifies that status data associated with accounts of users in a third geographic region will be stored in a third digital tree.

[0641] In some embodiments, the first code includes a first address of a first digital tree, and the compiler is configured to compile the first smart contract into a first bytecode, so that the first bytecode, when executed by the virtual machine, causes first state data to be stored in the first digital tree having the first address.

[0642] In some embodiments, the first address is represented by a constant value.

[0643] In some embodiments, the first address is determined by at least one of a Boolean function or a mathematical function.

[0644] In some embodiments, the first address is determined by a rule set comprising one or more rules.

[0645] In some embodiments, the first address is determined during a first time period for compiling the first smart contract or during a second time period for executing the first bytecode.

[0646] At 3806, the system provides a compiler configured to compile the first smart contract into a first bytecode that can be executed by a virtual machine associated with a blockchain corresponding to the first smart contract. The compiler is configured to recognize and compile the first code so that the first bytecode, when executed by the virtual machine, causes the first state data to be stored in the first digital tree.

[0647] In some embodiments, a second smart contract in a plurality of smart contracts includes a fourth code that identifies fourth state data and a fourth digital tree in a plurality of digital trees for storing the fourth state data. The first and second smart contracts are associated with the same blockchain, and the first and fourth digital trees in combination maintain a world state that stores state data of user accounts associated with the first and second smart contracts. The compiler is configured to compile the second smart contract into a second bytecode. The compiler is configured to identify and compile the fourth code so that the second bytecode causes the fourth state data to be stored in the fourth digital tree when executed by the virtual machine.

[0648] In some embodiments, the second code includes a second address of the second digital tree, and the compiler is configured to compile the first smart contract into a first bytecode so that the first bytecode, when executed by the virtual machine, causes the second state data to be stored in the second digital tree having the second address.

[0649] In some embodiments, the second address is represented by a constant value.

[0650] In some embodiments, the second address is determined by a Boolean function.

[0651] In some embodiments, the second address is determined by a mathematical function.

[0652] In some embodiments, the second address is determined by a rule set comprising one or more rules.

[0653] In some embodiments, the second address is determined during the first time period when compiling the second smart contract.

[0654] In some embodiments, the second address is determined during a second period of time while executing the second bytecode.

[0655] In some embodiments, the third code includes a third address of the third digital tree, and the compiler is configured to compile the first smart contract into a first bytecode so that the first bytecode, when executed by the virtual machine, causes the third state data to be stored in the third digital tree having the third address.

[0656] In some embodiments, the fourth code includes a fourth address of a fourth digital tree, and the compiler is configured to compile the second smart contract into a second bytecode so that the second bytecode, when executed by the virtual machine, causes the fourth state data to be stored in a fourth digital tree having the fourth address.

[0657] In some embodiments, the system further executes a compiler to generate at least one of the first bytecode or the second bytecode.

[0658] In some embodiments, the system also provides a virtual machine.

[0659] In some embodiments, the system further executes a virtual machine and performs at least one of the following: storing the first state data in a first digital tree, storing the second state data in a second digital tree, storing the third state data in a third digital tree, or storing the fourth state data in a fourth digital tree.

[0660] In some embodiments, the system further determines a first root hash value of the first digital tree, determines a second root hash value of the second digital tree, and determines a world state root hash value based on the first root hash value and the second root hash value.

[0661] In some embodiments, the system further determines a third root hash value of the third digital tree, and determines a world state root hash value based on the first root hash value, the second root hash value, and the third root hash value.

[0662] In some embodiments, the world state root hash value represents a digital fingerprint of one or more states of a user account, one or more smart contracts, associated with the world state.

[0663] In some embodiments, the first smart contract specifies that the first digital tree is stored at a first storage device and the second digital tree is stored at a second storage device.

[0664] In some embodiments, the first smart contract specifies that both the first digital tree and the second digital tree are stored at the first storage device.

[0665] In some embodiments, the system further generates an index of the data stored in the first storage device and stores the index in the first digital tree and the second digital tree.

[0666] In some embodiments, each digital tree may include, for example, a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0667] Fig.39 3900 is a diagram of a module example of an apparatus 3900 according to an embodiment of the present invention. The apparatus 3900 may be an example of an embodiment of a system configured to process world state information associated with a blockchain. The apparatus 3900 may correspond to the above-mentioned embodiment, and the apparatus 3900 includes the following:

[0668] A first providing module 3902, providing a plurality of smart contracts associated with a plurality of user accounts, wherein each smart contract is associated with a corresponding blockchain managed by a corresponding blockchain network, and storing blockchain data on the blockchain through consensus of blockchain nodes of the blockchain network;

[0669] A second providing module 3904, providing a plurality of digital trees to maintain one or more world states associated with smart contracts and user accounts, wherein each world state stores state data associated with at least one of the user account or the smart contract, wherein a first smart contract of the plurality of smart contracts comprises a first code, the first code identifying first state data and a first digital tree of the plurality of digital trees for storing the first state data; and

[0670] A third providing module 3906 is provided, which is configured to compile the first smart contract into a first bytecode, wherein the first bytecode can be executed by a virtual machine associated with the blockchain corresponding to the first smart contract, wherein the compiler is configured to recognize and compile the first code so that the first bytecode causes the first state data to be stored in a first digital tree when executed by the virtual machine.

[0671] In an optional embodiment, the state data identified by the first code may include at least one of: (i) data about the state of a user account associated with the first smart contract, or (ii) data about the state of the first smart contract.

[0672] In an optional embodiment, the first smart contract may include a second code that identifies the second state data and a second digital tree in the plurality of digital trees for storing the second state data. The compiler may be configured to recognize and compile the first code and the second code so that the first bytecode, when executed by the virtual machine, causes the first state data to be stored in the first digital tree and causes the second state data to be stored in the second digital tree.

[0673] In an alternative embodiment, the combination of the first and second digital trees may maintain a world state associated with a user account associated with the first smart contract.

[0674] In an alternative embodiment, the first code may specify that status data associated with user accounts in a first geographic region is to be stored in a first digital tree, and the second code may specify that status data associated with user accounts in a second geographic region is to be stored in a second digital tree.

[0675] In an optional embodiment, the first smart contract may include a third code that identifies the third state data and a third digital tree in a plurality of digital trees for storing the third state data. The first, second, and third digital trees may be combined to maintain a world state associated with a user account associated with the first smart contract. The compiler may be configured to recognize and compile the first code, the second code, and the third code so that when the first bytecode is executed by the virtual machine, the first state data will be stored in the first digital tree, the second state data will be stored in the second digital tree, and the third state data will be stored in the third digital tree.

[0676] In an optional embodiment, the first, second, and third digital trees may be combined to maintain a world state associated with a user account associated with the first smart contract.

[0677] In an optional embodiment, a first code may specify that status data associated with user accounts in a first geographic area will be stored in a first digital tree, a second code may specify that status data associated with user accounts in a second geographic area will be stored in a second digital tree, and a third code may specify that status data associated with user accounts in a third geographic area will be stored in a third digital tree.

[0678] In an optional embodiment, a second smart contract in the plurality of smart contracts may include a fourth code that identifies fourth state data and a fourth digital tree in the plurality of digital trees for storing the fourth state data. The first and second smart contracts may be associated with the same blockchain, and the combination of the first and fourth digital trees may maintain a world state that stores state data of user accounts associated with the first and second smart contracts. The compiler may be configured to compile the second smart contract into a second bytecode. The compiler may be configured to identify and compile the fourth code so that the second bytecode, when executed by the virtual machine, causes the fourth state data to be stored in the fourth digital tree.

[0679] In an optional embodiment, the first code may include a first address of a first digital tree, and the compiler may be configured to compile the first smart contract into a first bytecode so that when the first bytecode is executed by the virtual machine, the first state data will be stored in the first digital tree having the first address.

[0680] In an alternative embodiment, the first address may be represented by a constant value.

[0681] In an alternative embodiment, the first address may be determined by at least one of a Boolean function or a mathematical function.

[0682] In an alternative embodiment, the first address may be determined by a rule set comprising one or more rules.

[0683] In an optional embodiment, the first address may be determined at a first time period when compiling the first smart contract.

[0684] In an alternative embodiment, the first address may be determined during a second period of time during which the first bytecode is executed.

[0685] In an optional embodiment, the second code may include a second address of the second digital tree, and the compiler may be configured to compile the first smart contract into a first bytecode so that the first bytecode, when executed by the virtual machine, causes the second state data to be stored in the second digital tree having the second address.

[0686] In an alternative embodiment, the second address may be represented by a constant value.

[0687] In an alternative embodiment, the second address may be determined by a Boolean function.

[0688] In an alternative embodiment, the second address may be determined by a mathematical function.

[0689] In an alternative embodiment, the second address may be determined by a rule set comprising one or more rules.

[0690] In an optional embodiment, the second address may be determined during the first time period when the second smart contract is compiled.

[0691] In an alternative embodiment, the second address may be determined during a second period of time during which the second bytecode is executed.

[0692] In an optional embodiment, the third code may include a third address of the third digital tree, and the compiler may be configured to compile the first smart contract into the first bytecode so that when the first bytecode is executed by the virtual machine, the third state data will be stored in the third digital tree having the third address.

[0693] In an optional embodiment, the fourth code may include a fourth address of a fourth digital tree, and the compiler may be configured to compile the second smart contract into a second bytecode so that the second bytecode, when executed by the virtual machine, causes the fourth state data to be stored in a fourth digital tree having the fourth address.

[0694] In an optional embodiment, the device 3900 may further include an execution module that executes the compiler to generate at least one of the first bytecode or the second bytecode.

[0695] In an optional embodiment, the device 3900 may further include a fourth providing module for providing a virtual machine.

[0696] In an optional embodiment, the device 3900 may also include: an execution module that executes a virtual machine; and a storage module that performs at least one of the following: storing the first state data in a first digital tree, storing the second state data in a second digital tree, storing the third state data in a third digital tree, or storing the fourth state data in a fourth digital tree.

[0697] In an optional embodiment, the device 3900 may also include a determination module that determines a first root hash value of the first digital tree, determines a second root hash value of the second digital tree, and determines a world state root hash value based on the first root hash value and the second root hash value.

[0698] In an optional embodiment, the device 3900 may further include a determination module that determines a third root hash value of the third digital tree and determines a world state root hash value based on the first root hash value, the second root hash value, and the third root hash value.

[0699] In an optional embodiment, the world state root hash value can represent a digital fingerprint of a user account, one or more states of one or more smart contracts associated with the world state.

[0700] In an optional embodiment, the first smart contract may specify that the first digital tree is stored at a first storage device and the second digital tree is stored at a second storage device.

[0701] In an optional embodiment, the first smart contract may specify that both the first digital tree and the second digital tree are stored at the first storage device.

[0702] In an optional embodiment, the apparatus 3900 may further include a generation module, which generates an index of the data stored in the first storage device and stores the index in the first digital tree and the second digital tree.

[0703] In alternative embodiments, each digital tree may include, for example, a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

[0704] Fig.40 An example of an environment 4002 is shown in which users (e.g., 304 and 306) access services provided by the system 4000 through a blockchain-based application module 4004. The application module 4004 can provide services similar to Figure 3Application module 308. System 4000 stores transaction records and user account status information in a distributed blockchain ledger. In general, the blockchain ledger includes three parts. The first part includes the world state, which stores the latest user account status information in the ledger, for example, key-value pairs. The second part includes blockchain records of all transactions. The blockchain ledger is maintained by a blockchain network, which can be, for example, the consensus blockchain network described above. The consensus nodes of the blockchain network receive status updates in the form of new blocks, use blocks and world states to confirm (or submit) transactions, and update the world state and add transaction logs to the blockchain after reaching consensus. The third part includes a smart contract database that stores smart contracts that facilitate transactions associated with the services provided by the application module 4004.

[0705] In some embodiments, one or more blockchain networks (e.g., 314, 316, similar to Figure 3 The system 4000 includes a local copy of the blockchain ledger 4006, which includes a blockchain database 4008, a world state database 4010, and a smart contract database 4016. The blockchain database 4008 includes a blockchain 4012. The world state database 4010 includes a world state 4014, which is maintained by a tree data structure or a digital tree (e.g., 4020a, 4020b, collectively referred to as 4020). Each digital tree can be, for example, a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a Bucket tree. In the following example, a Merkle tree is used as an example of a digital tree 4020, but other types of digital trees may also be used. For example, the blockchain database 4008 stores a local copy of the blockchain maintained by the blockchain network. The world state database 4010 stores a local copy of the world state maintained by the blockchain network.

[0706] exist Fig.40 In the example of , blockchain ledger 4006 includes blockchain database 4008 including blockchain 4012 and world state database 4010 including world state 4014. In some embodiments, blockchain ledger 4006 may include multiple blockchain databases, wherein the blockchain database includes multiple blockchains or multiple partitions or shards of a blockchain, similar to Figure 3 Similarly, the blockchain ledger 4006 may include multiple world state databases, wherein the world state database includes multiple world states or multiple partitions or shards of the world state, similar to Figure 3 Example shown.

[0707] The blockchain ledger 4006 includes a smart contract database 4016, which includes one or more smart contracts, such as 4018a, 4018b, collectively referred to as 4018. The smart contract database 4016 stores a local copy of the smart contract and the corresponding smart contract bytecode maintained by the blockchain network. The smart contract 4018 is associated with the blockchain 4012 and the world state 4014. The state data of the smart contract and the state data of the user account associated with the smart contract are stored in the world state 4014.

[0708] Typically, when users (e.g., 304 and 306) conduct transactions using services provided by blockchain-based application system 4000, system 4000 generates data, such as transaction records and user account status information, which are stored in distributed blockchain ledger 4006. For example, one or more smart contracts 4018 can be executed to update status data associated with a user account, where the status data is written to the corresponding Merkle tree. For illustration purposes, Fig.40 , blockchain ledger 4006 is shown as having separate blockchain database 4008 and world state database 4010. In some embodiments, blockchain 4012 and world state 4014 may belong to the same database. Blockchain 4012 is associated with world state 4014, and the blockchain network maintaining the blockchain ledger updates the blockchain and the corresponding world state.

[0709] For a given application (e.g., an online payment application or an online shopping application), transaction data may be stored in blockchain 4012, and state information may be stored in world state 4014. This article describes novel techniques for associating specific data segments in smart contracts 4018 with specific Merkle trees 4020, so that different data segments processed by smart contracts 4018 can be stored in different Merkle trees to improve the efficiency of data processing related to Merkle trees 4020, such as calculating the root hash value of the Merkle tree. The root hash value of the world state 4014 provides a fingerprint of the latest state values ​​of all user accounts associated with the world state 4014.

[0710] System 4000 includes computing resources, such as computing power (e.g., processor cores, processing threads, CPU runtime), memory, non-volatile storage, and / or data bandwidth to support blockchain-based application modules, similar to Figure 3 When the additional Merkle tree 4020 is used to maintain the world state 4014, more computing resources can be allocated to support the world state 4014, thus making data processing related to the world state 4014 or the Merkle tree 4020 faster.

[0711] The blockchain 4012 and the world state 4014 are maintained by the blockchain netw...

Claims

1. A system for processing world state information associated with a blockchain, the system comprising: a blockchain database configured to store a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network, and the blockchain includes one or more blocks, wherein the one or more blocks store transaction data associated with a user account associated with the blockchain; a world state database configured to store a world state data structure including a plurality of digital trees, wherein the world state stores information about the state of the user account; a smart contract database configured to store a plurality of smart contracts associated with the blockchain, wherein a first smart contract among the plurality of smart contracts comprises a first code and a second code, the first code identifying first state data and a first digital tree among the plurality of digital trees for storing the first state data, the second code identifying second state data and a second digital tree among the plurality of digital trees for storing the second state data; and A virtual machine is associated with the blockchain corresponding to the first smart contract, wherein the virtual machine is configured to execute the first smart contract so that the first state data is stored in the first digital tree and the second state data is stored in the second digital tree.

2. The system according to claim 1, wherein: The virtual machine includes a smart contract compiler, which is configured to compile the first smart contract into a first bytecode that can be executed by the virtual machine. The compiler is configured to recognize and compile the first code so that when the first bytecode is executed by the virtual machine, the first state data is stored in the first digital tree.

3. The system according to claim 1 comprises a smart contract compiler, which is configured to compile the first smart contract into a first bytecode that can be executed by the virtual machine, and the compiler is configured to recognize and compile the first code so that when the first bytecode is executed by the virtual machine, the first state data is stored in the first digital tree.

4. The system according to claim 1, wherein: The state data identified by the first code includes at least one of the following: (i) data about the state of a user account associated with the first smart contract, or (ii) data about the state of the first smart contract.

5. The system according to claim 3, wherein: The compiler is further configured to recognize and compile the second code so that the first bytecode, when executed by the virtual machine, causes the second state data to be stored in the second digital tree.

6. The system according to claim 5, wherein: The first digital tree and the second digital tree in combination maintain a world state associated with a user account associated with the first smart contract.

7. The system according to claim 5, wherein: The first code specifies that state data associated with accounts of users in a first geographic region is to be stored in the first digital tree, and the second code specifies that state data associated with accounts of users in a second geographic region is to be stored in the second digital tree.

8. The system according to claim 5, wherein: The first smart contract includes a third code, the third code identifying third state data and a third digital tree among the plurality of digital trees for storing the third state data; The first digital tree, the second digital tree, and the third digital tree in combination maintain a world state associated with a user account associated with the first smart contract; The compiler is configured to recognize and compile the first code, the second code, and the third code so that when the first bytecode is executed by the virtual machine, the first state data will be stored in the first digital tree, the second state data will be stored in the second digital tree, and the third state data will be stored in the third digital tree.

9. The system according to claim 8, wherein: The first digital tree, the second digital tree, and the third digital tree in combination maintain a world state associated with a user account associated with the first smart contract.

10. The system according to claim 8, wherein: The first code specifies that status data associated with accounts of users in a first geographic region is to be stored in the first digital tree, the second code specifies that status data associated with accounts of users in a second geographic region is to be stored in the second digital tree, and the third code specifies that status data associated with accounts of users in a third geographic region is to be stored in the third digital tree.

11. The system according to claim 2, wherein: A second smart contract among the plurality of smart contracts comprises: a fourth code, the fourth code identifying fourth state data and a fourth digital tree among the plurality of digital trees for storing the fourth state data; The first smart contract and the second smart contract are associated with the same blockchain, and the first digital tree and the fourth digital tree in combination maintain a world state storing state data of user accounts associated with the first smart contract and the second smart contract; The compiler is configured to compile the second smart contract into a second bytecode; and The compiler is configured to recognize and compile the fourth code so that the second bytecode, when executed by the virtual machine, causes the fourth state data to be stored in the fourth digital tree.

12. The system according to claim 11, wherein: The first code includes a first address of the first digital tree, and the compiler is configured to compile the first smart contract into the first bytecode, so that the first bytecode, when executed by the virtual machine, causes the first state data to be stored in the first digital tree having the first address.

13. The system according to claim 12, wherein: The first address is represented by a constant value.

14. The system according to claim 12, wherein: The first address is determined by at least one of a Boolean function or a mathematical function.

15. The system of claim 12, wherein: The first address is determined by a rule set comprising one or more rules.

16. The system of claim 12, wherein: The first address is determined during a first time period of compiling the first smart contract or during a second time period of executing the first bytecode.

17. The system of claim 12, wherein: The second code includes a second address of the second digital tree, and the compiler is configured to compile the first smart contract into the first bytecode so that the first bytecode, when executed by the virtual machine, causes the second state data to be stored in the second digital tree having the second address.

18. The system of claim 17, wherein: At least one of the following: (i) the second address is represented by a constant value; (ii) the second address is determined by a Boolean function; (iii) the second address is determined by a mathematical function; (iv) the second address is determined by a rule set comprising one or more rules; (v) the second address is determined during a first period of time when the second smart contract is compiled; or (vi) The second address is determined during a second period of time when the second bytecode is executed.

19. The system according to claim 8, wherein: The third code includes a third address of the third digital tree, and the compiler is configured to compile the first smart contract into the first bytecode, so that the first bytecode, when executed by the virtual machine, causes the third state data to be stored in the third digital tree having the third address.

20. The system of claim 11, wherein: The fourth code includes a fourth address of the fourth digital tree, and the compiler is configured to compile the second smart contract into the second bytecode, so that the second bytecode, when executed by the virtual machine, causes the fourth state data to be stored in the fourth digital tree having the fourth address.

21. The system of claim 8, comprising one or more computers at one or more locations and configured to: Determine a first root hash value of the first digital tree; Determining a second root hash value of the second digital tree; and Based on the first root hash value and the second root hash value, a world state root hash value is determined.

22. The system of claim 21, wherein: The one or more computers are configured to: Determining a third root hash value of the third digital tree; and The world state root hash value is determined based on the first root hash value, the second root hash value, and the third root hash value.

23. The system of claim 21, wherein: The world state root hash value represents a digital fingerprint of the one or more states of a user account, a smart contract, or multiple smart contracts associated with the world state.

24. The system of claim 5, wherein: The first smart contract specifies that the first digital tree is stored at a first storage device, and the second digital tree is stored at a second storage device.

25. The system of claim 24, wherein: The first smart contract specifies that both the first digital tree and the second digital tree are stored at the first storage device.

26. The system of claim 25, comprising one or more computers at one or more locations and configured to generate an index of the data stored in the first storage device and store the index in the first digital tree and the second digital tree.

27. A system according to any one of claims 1 to 26, wherein: Each digital tree includes at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

28. A method for processing world state information associated with a blockchain, the method comprising: providing a plurality of smart contracts associated with a plurality of user accounts, wherein each smart contract is associated with a corresponding blockchain managed by a corresponding blockchain network, and wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network; providing a plurality of digital trees to maintain one or more world states associated with the smart contract and the user account, wherein each world state stores state data associated with at least one of a user account or a smart contract; The first smart contract among the multiple smart contracts includes: a first code and a second code, the first code identifying first state data and a first digital tree of the plurality of digital trees for storing the first state data, the second code identifying second state data and a second digital tree of the plurality of digital trees for storing the second state data; and A virtual machine is provided that is associated with the blockchain corresponding to the first smart contract, wherein the virtual machine is configured to execute the first smart contract so that the first state data is stored in the first digital tree and the second state data is stored in the second digital tree.

29. The method according to claim 28, wherein: The virtual machine includes a smart contract compiler, which is configured to compile the first smart contract into a first bytecode that can be executed by the virtual machine. The compiler is configured to recognize and compile the first code so that when the first bytecode is executed by the virtual machine, the first state data is stored in the first digital tree.

30. The method according to claim 28 includes providing a smart contract compiler, wherein the smart contract compiler is configured to compile the first smart contract into a first bytecode that can be executed by the virtual machine, and the compiler is configured to recognize and compile the first code so that when the first bytecode is executed by the virtual machine, the first state data is stored in the first digital tree.

31. The method of claim 28, wherein: The state data identified by the first code includes at least one of the following: (i) data about the state of a user account associated with the first smart contract, or (ii) data about the state of the first smart contract.

32. The method of claim 29, the compiler being further configured to recognize and compile the second code so that the first bytecode, when executed by the virtual machine, causes the second state data to be stored in the second digital tree.

33. The method of claim 32, wherein: The first digital tree and the second digital tree in combination maintain a world state associated with a user account associated with the first smart contract.

34. The method of claim 32, wherein: The first code specifies that state data associated with accounts of users in a first geographic region is to be stored in the first digital tree, and the second code specifies that state data associated with accounts of users in a second geographic region is to be stored in the second digital tree.

35. The method of claim 32, wherein: The first smart contract includes a third code, the third code identifying third state data and a third digital tree among the plurality of digital trees for storing the third state data; The first digital tree, the second digital tree, and the third digital tree in combination maintain a world state associated with a user account associated with the first smart contract; The compiler is configured to recognize and compile the first code, the second code, and the third code so that when the first bytecode is executed by the virtual machine, the first state data is stored in the first digital tree, the second state data is stored in the second digital tree, and the third state data is stored in the third digital tree.

36. The method of claim 35, wherein: The first digital tree, the second digital tree, and the third digital tree in combination maintain a world state associated with a user account associated with the first smart contract.

37. The method of claim 35, wherein: The first code specifies that status data associated with accounts of users in a first geographic region is to be stored in the first digital tree, the second code specifies that status data associated with accounts of users in a second geographic region is to be stored in the second digital tree, and the third code specifies that status data associated with accounts of users in a third geographic region is to be stored in the third digital tree.

38. The method of claim 35, wherein: A second smart contract among the plurality of smart contracts comprises: a fourth code, identifying fourth state data and a fourth digital tree among the plurality of digital trees for storing the fourth state data; The first smart contract and the second smart contract are associated with the same blockchain, and the first digital tree and the fourth digital tree in combination maintain a world state storing state data of user accounts associated with the first smart contract and the second smart contract; The compiler is configured to compile the second smart contract into a second bytecode; and The compiler is configured to recognize and compile the fourth code so that the second bytecode, when executed by the virtual machine, causes the fourth state data to be stored in the fourth digital tree.

39. The method of claim 38, wherein: The first code includes a first address of the first digital tree, and the compiler is configured to compile the first smart contract into the first bytecode, so that when the first bytecode is executed by the virtual machine, the first state data will be stored in the first digital tree having the first address.

40. The method of claim 39, wherein: The first address is represented by a constant value.

41. The method of claim 39, wherein: The first address is determined by at least one of a Boolean function or a mathematical function.

42. The method of claim 39, wherein: The first address is determined by a rule set comprising one or more rules.

43. The method of claim 39, wherein: The first address is determined during a first time period of compiling the first smart contract or during a second time period of executing the first bytecode.

44. The method of claim 39, wherein: The second code includes a second address of the second digital tree, and the compiler is configured to compile the first smart contract into the first bytecode, so that when the first bytecode is executed by the virtual machine, the second state data will be stored in the second digital tree having the second address.

45. The method of claim 44, wherein: At least one of the following: (vii) the second address is represented by a constant value; (viii) the second address is determined by a Boolean function; (ix) the second address is determined by a mathematical function; (x) the second address is determined by a rule set comprising one or more rules; (xi) the second address is determined during a first period of time when the second smart contract is compiled; or (xii) The second address is determined during a second period of time during which the second bytecode is executed.

46. ​​The method of claim 35, wherein: The third code includes a third address of the third digital tree, and the compiler is configured to compile the first smart contract into the first bytecode, so that when the first bytecode is executed by the virtual machine, the third state data will be stored in the third digital tree having the third address.

47. The method of claim 38, wherein: The fourth code includes a fourth address of the fourth digital tree, and the compiler is configured to compile the second smart contract into the second bytecode, so that when the second bytecode is executed by the virtual machine, the fourth state data will be stored in the fourth digital tree having the fourth address.

48. The method of claim 47, comprising: The compiler is executed to generate at least one of the first bytecode or the second bytecode.

49. The method according to claim 38 includes executing the virtual machine and performing at least one of the following: storing the first state data in the first digital tree, storing the second state data in the second digital tree, storing the third state data in the third digital tree, or storing the fourth state data in the fourth digital tree.

50. The method of claim 49, comprising: Determine a first root hash value of the first digital tree; Determine a second root hash value of the second digital tree; as well as Based on the first root hash value and the second root hash value, a world state root hash value is determined.

51. The method of claim 50, comprising: Determine a third root hash value of the third digital tree; as well as The world state root hash value is determined based on the first root hash value, the second root hash value, and the third root hash value.

52. The method of claim 50, wherein: The world state root hash value represents a digital fingerprint of one or more states of a user account, a smart contract, or multiple smart contracts associated with the world state.

53. The method of claim 32, wherein: The first smart contract specifies that the first digital tree is stored at a first storage device, and the second digital tree is stored at a second storage device.

54. The method of claim 32, wherein: The first smart contract specifies that both the first digital tree and the second digital tree are stored at a first storage device.

55. The method of claim 54, comprising: An index of the data stored in the first storage device is generated, and the index is stored in the first digital tree and the second digital tree.

56. A method according to any one of claims 28 to 55, wherein: Each digital tree includes at least one of a Merkle tree, a Patricia tree, a Merkle Patricia tree, a modified Merkle Patricia tree, or a bucket tree.

57. A method for processing world state information associated with a blockchain, the method comprising: providing a first smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network; and providing a first Merkle tree and a second Merkle tree to maintain a first world state associated with a first set of user accounts, wherein the first world state stores data about a current state of the first set of user accounts and a current state of the first smart contract; The first smart contract includes: a first code specifying that first data is to be stored in the first Merkle tree, and a second code specifying that second data is to be stored in the second Merkle tree; When the first smart contract is executed, the first data is stored in the first Merkle tree, and the second data is stored in the second Merkle tree; the first data includes first state data, and the second data includes second state data.

58. The method of claim 57, wherein: The first code specifies that data associated with accounts of users in a first geographic region is to be stored in the first Merkle tree, and the second code specifies that data associated with accounts of users in a second geographic region is to be stored in the second Merkle tree.

59. The method of claim 57, comprising providing a third Merkle tree, wherein: The first Merkle tree, the second Merkle tree, and the third Merkle tree in combination maintain a world state associated with the user account, The first smart contract includes: specifying the first code to store first data in the first Merkle tree; specifying the second code to store second data in the second Merkle tree; and A third code is specified to store third data in the third Merkle tree.

60. The method of claim 57, wherein: The first Merkle tree has a first address, the second Merkle tree has a second address, the first code specifies that the first data is to be stored in the Merkle tree having the first address, and the second code specifies that the second data is to be stored in the Merkle tree having the second address.

61. The method of claim 57, comprising: A virtual machine is provided, wherein the virtual machine is configured to execute the first smart contract so that the first data is stored in the first Merkle tree, and the second data is stored in the second Merkle tree.

62. The method of claim 61, comprising: A compiler is provided, wherein the compiler is configured to compile the first smart contract into bytecode that can be executed by the virtual machine.

63. The method of claim 62, wherein: The compiler is part of the virtual machine.

64. The method of claim 57, wherein: The first smart contract specifies that the first Merkle tree is stored at a first storage device and the second Merkle tree is stored at a second storage device.

65. The method of claim 57, wherein: The first smart contract specifies that both the first Merkle tree and the second Merkle tree are stored at a first storage device.

66. The method of claim 65, comprising: An index of the data stored in the first storage device is generated, and the index is stored in the first Merkle tree and the second Merkle tree.

67. The method of claim 57, comprising: A second smart contract is provided that is also associated with the blockchain, wherein the second smart contract includes third code that specifies that third data is to be stored in the first Merkle tree.

68. The method of claim 57, wherein: The first Merkle tree stores state information of user accounts based on a first geographical area, and the second Merkle tree stores state information of user accounts based on a second geographical area.

69. The method according to any one of claims 57 to 68, comprising: providing a second smart contract associated with the blockchain; providing a third Merkle tree to maintain a second world state, the second world state storing data about a current state of the second smart contract; as well as A world state root hash value is determined based on a first root hash value of the first Merkle tree and a second root hash value of the second Merkle tree.

70. A computer-implemented method for processing one or more smart contracts associated with a blockchain, the method comprising: receiving a smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network; A first code identifying specified first data and a first Merkle tree in the smart contract; A second code identifying specified second data and a second Merkle tree in the smart contract; storing the first data in the first Merkle tree; and The second data is stored in the second Merkle tree; the first data includes first state data, and the second data includes second state data.

71. The method of claim 70, wherein: The first code specifies that data associated with accounts of users in a first geographic region is to be stored in the first Merkle tree, and the second code specifies that data associated with accounts of users in a second geographic region is to be stored in the second Merkle tree.

72. The method of claim 70 or 71, comprising: Execute a virtual machine to execute the smart contract so that the first data is stored in the first Merkle tree and the second data is stored in the second Merkle tree.

73. A method for processing world state information associated with a blockchain, the method comprising: providing a smart contract associated with a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network; and Providing a plurality of Merkle trees to maintain a world state associated with a set of user accounts, wherein the world state stores data regarding a current state of the user accounts and a current state of the smart contract; Among them, the first smart contract includes a first code and a second code, the first code specifies that a first Merkle tree among the multiple Merkle trees is used to store a first data segment, and the second code specifies that a second Merkle tree among the multiple Merkle trees is used to store a second data segment; the first data segment includes first state data, and the second data segment includes second state data.

74. The method of claim 73, wherein: The first code includes a modifier including an identifier of a first Merkle tree configured to store the first data segment; the second code includes a modifier including an identifier of a second Merkle tree configured to store the second data segment.

75. The method of claim 74, wherein: The identifier of the Merkle tree includes the address of the Merkle tree.

76. The method of claim 74, wherein: The identification of the Merkle tree includes variables.

77. The method of claim 74, wherein: The identification is determined based on a mathematical function.

78. The method of claim 74, wherein: The identification is determined based on one or more rules.

79. A method according to any one of claims 74 to 76, comprising: A compiler is provided that is configured to recognize the modifier and compile the smart contract into bytecode that can be executed by a virtual machine associated with the blockchain.

80. The method of claim 79, wherein: The compiler is part of the virtual machine.

81. A system comprising: one or more processors; as well as One or more computer-readable memories, coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the method of any one of claims 28 to 80.

82. An apparatus comprising a plurality of modules for performing the method of any one of claims 28 to 80.

83. A system for processing world state information associated with a blockchain, the system comprising: a blockchain database configured to store a blockchain managed by a blockchain network, wherein blockchain data is stored on the blockchain by consensus of blockchain nodes of the blockchain network, and the blockchain includes one or more blocks, wherein the one or more blocks store transaction data associated with a user account associated with the blockchain; a world state database configured to store a world state data structure including a first Merkle tree and a second Merkle tree, wherein the world state stores information about a state of the user account; Smart contract compiler, configured as: Receiving a smart contract associated with the blockchain and the world state data structure; A first code identifying specified first data in the smart contract and the first Merkle tree; a second code identifying specified second data in the smart contract and the second Merkle tree; and Compiling the smart contract into bytecode; and A virtual machine configured to execute the bytecode so that the virtual machine: storing the first data in the first Merkle tree, and The second data is stored in the second Merkle tree; the first data includes first state data, and the second data includes second state data.

84. The system of claim 83, wherein: The compiler is configured to: identifying code in a smart contract, wherein the code identifies a data segment and a Merkle tree in a plurality of Merkle trees; and Compile the smart contract code into bytecode, so that when the bytecode is executed by the virtual machine, the virtual machine stores the data segment in the Merkle tree.

85. The system of claim 83, wherein: The compiler is configured to identify a constant value in the code of the smart contract, and the constant value represents the address of the Merkle tree or a pointer to the Merkle tree.

86. The system of claim 83, wherein: The compiler is configured to identify variables in the code in the smart contract, and the variables represent the address of the Merkle tree or a pointer to the Merkle tree.

87. The system of claim 83, wherein: The compiler is configured to recognize code in the smart contract, and the code includes a function for identifying the Merkle tree.

88. The system of claim 83, wherein: The compiler is configured to recognize code in the smart contract, and the code includes a rule set for identifying the Merkle tree.

89. The system of claim 83, wherein: The first Merkle tree stores state information of user accounts based on a first geographical area, and the second Merkle tree stores state information of user accounts based on a second geographical area.

90. The system of any one of claims 83 to 89, wherein: The smart contract compiler is part of the virtual machine.

Images