A method and apparatus for querying data from a blockchain

Abstract

Embodiments of the present specification provide a method and device for querying data from a blockchain, wherein N storage units are included in a blockchain node of the blockchain, and each storage unit stores part of state data of a target block and constitutes a state tree, the method comprising: receiving a first state root of the target block and a first key of a target object, wherein the first state root and a plurality of second state roots are stored in the blockchain node in a corresponding relationship, and the plurality of second state roots are state roots of a plurality of state trees corresponding to the target block in the plurality of storage units; obtaining the plurality of second state roots from the blockchain node according to the first state root; determining a first storage unit corresponding to the target object from the plurality of storage units according to the first key, and obtaining a third state root corresponding to the first storage unit from the plurality of second state roots; and reading a value corresponding to the first key from the first storage unit according to the third state root and the first key.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method and apparatus for querying data from a blockchain. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The embodiments in this specification aim to provide a scheme for querying data from a blockchain. In a scenario where a blockchain node includes multiple storage units, each storage unit has its own state tree, and each stores a portion of the blockchain state data, a method is provided to obtain state data from the state trees of each storage unit based on the state root of the target block.

[0004] To achieve the above objectives, the first aspect of this specification provides a method for querying data from a blockchain, wherein a blockchain node includes N storage units, each storage unit stores state data of a portion of objects in the blockchain, and the state data in each storage unit corresponding to a block constitutes a state tree. The method includes: receiving a first state root of a target block and a first key of a target object, wherein the blockchain node stores a correspondence between the first state root and multiple second state roots, the multiple second state roots being state roots of multiple state trees corresponding to the target block in multiple storage units; obtaining the multiple second state roots from the blockchain node based on the first state root; determining the first storage unit corresponding to the target object from the multiple storage units based on the first key, and obtaining a third state root corresponding to the first storage unit from the multiple second state roots; and reading the value corresponding to the first key from the first storage unit based on the third state root and the first key.

[0005] A second aspect of this specification provides an apparatus for querying data from a blockchain, wherein a blockchain node includes N storage units, each storage unit stores state data of a portion of objects in the blockchain, and the state data in each storage unit corresponding to a block constitutes a state tree. The apparatus includes: a receiving unit for receiving a first state root of a target block and a first key of a target object, wherein the blockchain node stores a correspondence between the first state root and multiple second state roots, the multiple second state roots being state roots of multiple state trees corresponding to the target block in multiple storage units; a first processing unit for obtaining second state roots of the multiple state trees from the blockchain node based on the first state root; a second processing unit for determining the first storage unit corresponding to the target object from the multiple storage units based on the first key, and obtaining a third state root corresponding to the first storage unit from the multiple second state roots; and a target value acquisition unit for reading the value corresponding to the first key from the first storage unit based on the third state root and the first key.

[0006] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon that, when executed by a computer or processor, causes the computer or processor to perform the method described in the first aspect.

[0007] A fourth aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in the first aspect.

[0008] In the scheme for querying data from the blockchain provided in the embodiments of this specification, a method for obtaining state data from each storage unit can be provided in a distributed blockchain storage scenario where the blockchain node includes multiple storage units, each storage unit has a state tree, and each state tree stores a portion of the blockchain state data. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of a blockchain system architecture;

[0011] Figure 2 A schematic diagram of a storage structure for blockchain state data;

[0012] Figure 3 This is a schematic diagram of a blockchain state tree structure;

[0013] Figure 4 This is a schematic diagram of a multi-shard storage architecture in a blockchain node according to one embodiment;

[0014] Figure 5 This is a schematic diagram of another blockchain state tree structure;

[0015] Figure 6 This is a flowchart illustrating a method for querying data from a blockchain according to one embodiment of this specification;

[0016] Figure 7 This is a schematic diagram of a first key-value pair in one embodiment of this specification;

[0017] Figure 8 This is a state flowchart of a method for querying data from a blockchain according to another embodiment of this specification;

[0018] Figure 9 This is an architectural diagram of an apparatus for querying data from a blockchain according to one embodiment of this specification;

[0019] Figure 10 This is an architecture diagram of a blockchain node according to another embodiment of this specification. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0021] Figure 1 A blockchain architecture diagram is shown. (Example) Figure 1 The blockchain shown contains, for example, eight nodes. The connections between the nodes schematically represent P2P (Peer-to-Peer) connections. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain produces the same state by executing the same transactions, and each node stores the same state database. This can be understood as... Figure 1 Although the example shows a blockchain with 8 nodes, the embodiments in this specification are not limited to this and may include other numbers of nodes.

[0022] To better illustrate the method for calculating the state root of the target block in this application, we will first introduce some conventional blockchain state storage structures. Given that many blockchain platforms and applications are built on Ethereum's underlying technology, we will first introduce Ethereum's state storage structure. Ethereum expands upon the Bitcoin network by employing an account system and world state, allowing direct display of account balances and states. Ethereum accounts can be divided into two types: externally owned accounts: user accounts, such as Ether owner accounts; and contract accounts: storing the executed smart contract code and the values ​​of the state within the smart contract code, typically activated only through external account calls.

[0023] The design of external and contract accounts is essentially a mapping from account addresses to account states. Account states typically include fields such as nonce, balance, storage_root, and codeHash. Nonce and balance exist in both external and contract accounts. The codeHash and storage_root attributes are generally only valid for contract accounts. Nonce: A counter; for external accounts, this number represents the number of transactions sent from the account address; for contract accounts, it's the number of contracts created by the account. Balance: The amount of Ether held by this address. Storage_root: The hash of the root node of an MPT tree, which organizes the storage of state variables for the contract account. CodeHash: The hash value of the smart contract code. For contract accounts, this is the hashed and stored code of the smart contract; for external accounts, since no smart contract is included, the codeHash field can generally be an empty string or a string of all zeros.

[0024] MPT stands for Merkle Patricia Tree, a tree structure that combines the features of a Merkle Tree and a Patricia Tree (a compressed prefix tree, a more space-efficient Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins each pair of transactions and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is often simply referred to as an MPT tree.

[0025] The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs representing the storage content for each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (the address of the Ethereum account), distributed across storage nodes from the root to the leaf nodes. The "value" in the state trie is generated by encoding the information of the Ethereum account using recursive-length prefix encoding (RLP). As mentioned earlier, for external accounts, values ​​may include, for example, nonce and balance; for contract accounts, values ​​may include, for example, nonce, balance, codehash, and storage_root.

[0026] Figure 2 This is a schematic diagram of a blockchain data storage structure. Figure 2In some blockchain data storage examples, the block header of each block includes several fields, such as the previous block hash (prevHash in the diagram, or parent hash), a nonce (in some blockchain systems, this nonce is not random, or the nonce in the block header is not enabled in some blockchain systems), a timestamp, a block number (BlockNum), a state root hash (State_Root), a transaction root hash (Transaction_Root), and a receipt root hash (Receipt_Root). The PrevHash in the block header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the hash value of the previous block. In this way, the blockchain achieves locking of the previous block by the next block through the block header. Specifically, as mentioned earlier, state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block; that is, pointing to state_root is a state tree in MPT form. The root node of this MPT tree can be an extension node or a branch node. The `state_root` typically stores the hash value of this root node. A subset of values ​​from each node from the root to the leaf nodes are concatenated sequentially to form an account address, which serves as the key. The account information stored in the leaf nodes is the value corresponding to this account address, thus forming a key-value pair. Specifically, the key can be SHA3 (Address), i.e., the hash value of the account address (using a hash algorithm such as SHA3), and the stored value can be RLP (Account), i.e., the RLP encoding of the account information. The account information is a four-tuple consisting of [nonce, balance, storage_root, codeHash]. As mentioned earlier, for external accounts, generally only the `nonce` and `balance` fields are present, while the `storage_root` and `codeHash` fields default to storing empty strings / strings of all zeros. In other words, external accounts do not store contracts or the state variables generated after contract execution. A contract account typically includes nonce, balance, storage_root, and codeHash. Nonce is the transaction counter for the same account; balance is the account balance; storage_root corresponds to another MPT (Multi-Transaction Tree), which links to contract-related state information; and codeHash is the hash value of the contract code. Whether it's an external account or a contract account, its account information is generally located in a single leaf node.From the root node's extension / branch nodes to each account's leaf node, there may be several branch nodes and extension nodes in between.

[0027] The state tree can be an MPT (Multi-Level Tree) structure, typically a 16-ary tree, with each level having a maximum of 16 child nodes and a maximum depth of 64 levels. Extension nodes, used to store the common prefix, generally have one child node, which can be a branch node. Branch nodes can have a maximum of 16 child nodes, potentially including extension nodes and / or leaf nodes. Such an MPT tree can have a maximum depth of 64 levels. When the number of accounts in the blockchain reaches a certain threshold, this MPT tree may approach or reach a depth of 64 levels.

[0028] Figure 3 This is a schematic diagram of a state tree. A blockchain system contains several external accounts, such as... Figure 3 External accounts are numbered 1, 2, ... In addition, there are several contract accounts in the blockchain system, such as... Figure 3 The blocks contain contract accounts numbered 1, 2, ... These external and contract accounts, along with their information, are organized, for example, in the form of an MPT tree, forming a state tree. The state_root in the block header stores the hash value of the root node of this MPT tree. Figure 3 The MPT tree is illustrated using three nodes: node 1, node 2, and node 3. Specifically, these can represent extension nodes and branch nodes within the MPT tree. The `state_root` in the block header stores the hash value of the root node of the entire state tree. The tree structure of the state tree can be, for example, represented as... Figure 2 The MPT (Member of the Physical Education Test) can, of course, adopt other organizational forms; the following explanation will use the MPT as an example. Figure 3 As shown, an MPT tree can include extension nodes, branch nodes, and leaf nodes. Leaf nodes can correspond to external accounts or contract accounts, and are typically accessed through their corresponding account's address (the account address usually corresponds to the leaf node's key). In one example, the value corresponding to this key can include fields such as nonce and balance (which store the account's nonce value, balance value, etc.).

[0029] External accounts can deploy smart contracts on the blockchain through transactions that create contracts. Alternatively, smart contracts can be native contracts, meaning they are integrated into the blockchain platform's code and compiled together with the platform's code for deployment. Regardless of the deployment method, after a smart contract is created, a corresponding contract account appears on the blockchain with a specific address. The contract code and account storage are stored in this contract account. The smart contract's account storage holds the contract's state. After contract creation, external accounts can invoke the created smart contract, or they can invoke a smart contract through another smart contract (or through one or more smart contracts). The invoked smart contract writes the generated state variables into its account storage in key-value pairs, such as... Figure 3 As shown. These key-value pairs can be organized into an MPT tree to form a storage tree.

[0030] However, the above storage method also has the following problems. Since these blockchain nodes can store the entire ledger—that is, the state of all blocks and all accounts—the amount of data stored on a single node will increase dramatically as blockchain business grows, sometimes reaching the terabyte (TB) level (1024 GB), or even the petabyte (PB) or exabyte (EB) level (1 PB = 1024 TB, 1 EB = 1024 PB). To support the operation of the blockchain system and cope with the continuity of business, each node needs to be expanded (acquired with greater storage space), resulting in huge expenses.

[0031] To address this, engineers have proposed various solutions for scaling. From the perspective of the technologies employed, scaling can be divided into on-chain scaling and off-chain scaling. On-chain scaling typically includes solutions such as increasing block size, Segregated Witness, sharding, and consensus layer improvements. Off-chain scaling typically includes solutions such as state channels, sidechains, and off-chain computation. Sharding is a type of on-chain scaling solution. The concept of sharding originates from the database field, originally referring to the horizontal partitioning of data in a database (dividing different rows of a table into different shards), with each shard stored on a separate database server instance to distribute the load.

[0032] One approach to distributed blockchain storage involves dividing the blockchain state data stored in blockchain nodes into multiple shards. The storage processes for each shard can run on different storage nodes. Each storage process only provides access, storage, and other storage services for the blockchain state data assigned to its own shard. Figure 4 This is a schematic diagram of a multi-shard storage architecture in a blockchain node according to one embodiment. For example... Figure 4As shown, a blockchain node runs four sharding processes (or storage processes) – process 1, process 2, process 3, and process 4. Each process runs on storage node A, storage node B, storage node C, and storage node D, respectively. In different implementations, storage nodes can be, for example, physical or logical servers. This embodiment is merely an illustrative example of four storage nodes. In reality, the number of storage nodes included in each blockchain node can vary, and each storage node can also run multiple sharding processes. Each shard can also include multiple storage units, or minimum storage units (MSUs). A storage unit is the smallest structural unit for organizing stored state data within a shard; for example, it can include an MPT tree for storing state information such as accounts or variables. Figure 4 As shown, each shard may include, for example, 64 storage units, and the four shards together comprise 256 storage units, meaning the entire blockchain node comprises 256 storage units. Depending on the implementation, the number of shards in a blockchain node can vary, and the number of storage units in each shard can also differ. For example, in one implementation, a blockchain node may include two shards, each of which may include 128 storage units, resulting in a total of 256 storage units in the blockchain node. In another implementation, a blockchain node may include only one shard, which may comprise all 256 storage units.

[0033] All state data from a blockchain node can be stored in multiple storage units. Each storage unit includes an MPT tree to store a portion of the blockchain state data. For example, ... Figure 5 As shown, the target block contains state data for 5000 accounts. This account state data can be saved to various... Figure 4 The diagram shows multiple storage units. For example, storage unit 1 can store account 1, account 2... account 10, storage unit 64 can store account 631, account 632... account 640, and other storage units can also store the states of different accounts. The number of accounts stored in each storage unit can be different. The state data stored in each storage unit can be stored in the MPT tree of that unit. Combining the state data stored in each storage unit can include the state data of all 5000 accounts in the target block. For ease of description, only account state data is used as an example here. In different examples, blockchain state data can also include the state data of variables, and their allocation in different storage units is similar to the allocation of account states, which will not be elaborated further.

[0034] Storing blockchain state data across multiple storage units in at least one shard can improve the data storage capacity of blockchain nodes. However, this also raises the following technical issues. Conventionally, the full state data of a block is stored in a state tree (also referred to as the first state tree for simplicity). The state root of the first state tree is the state root of the full state data (also referred to as the first state root for simplicity), which is the state root of the block. When it is necessary to find the state data of any target object (such as an account or variable), the state data of the target object can be obtained from the first state tree through the first state root. Specifically, the first state root points to the root node of the first state tree, so the first state tree can be accessed through the first state root. Since all state data is stored in the first state tree, when it is necessary to find any target object, the first state tree is accessed through the first state root, and then the state data of the target object is obtained from the first state tree through the target object's key. However, when all state data is stored in state trees (also referred to as second state trees for convenience) of multiple storage units in at least one shard, the state root of a block points to any one of the second state trees, and only a portion of the state data can be accessed through that state root.

[0035] Therefore, this specification provides a scheme for querying data from a blockchain. The core idea is to combine the state roots of the target block from each of the five storage units to obtain a combined value. The state roots of the block are pre-set in the blockchain nodes.

[0036] This combined value is stored in association. Since the block's state root is typically used to determine whether the block's full state data has changed, the block's state root can also be determined based on the hash value of this combined value. Therefore, the combined value can be retrieved from the blockchain node based on the block's state root (the first state root), and this combined value can be decomposed to obtain the state data of the target object.

[0037] The state root of the target storage unit is located. Then, based on the state root of the target storage unit, the state tree of the target storage unit is accessed, and the state data of the target object is retrieved from it based on the key of the target object. Through this method, the full state can be retrieved.

[0038] Each data point corresponds to a state root, which accesses state data stored in state trees in different storage units.

[0039] The method for querying data from a blockchain, as provided in the embodiments of this specification, is described in further detail below. Figure 6 This is a flowchart illustrating a method for querying data from a blockchain according to one embodiment of this specification. The blockchain nodes include N...

[0040] Storage units, each storing state data of a portion of objects in the blockchain, and the state data corresponding to a block in each storage unit forms a state tree. For example... Figure 6 As shown, the method includes at least the following steps:

[0041] Step S601: Receive the first state root of the target block and the first key of the target object, wherein the blockchain node stores a correspondence between the first state root and multiple second state roots, and the multiple second state roots are multiple storage...

[0042] The state roots of multiple state trees in the unit that correspond to the target block;

[0043] Step S603: Obtain the plurality of second state roots from the blockchain node based on the first state root;

[0044] Step S605: Based on the first key, determine the first storage unit corresponding to the target object from the plurality of storage units, and obtain the third state root corresponding to the first storage unit from the plurality of second state roots;

[0045] Step S607: Read the value corresponding to the first key from the first storage unit according to the third state root and the first key.

[0046] First, in step S601, the first state root of the target block and the first key of the target object are received.

[0047] The purpose of the query is to obtain the state data of the target object corresponding to the target block. This step accepts the key (value) of the queried target object (i.e., the first key) and the state root of the target block (the first state root). The target object can be, for example, an account or a variable. Depending on the implementation, it can, for example, receive the target object sent / input by the blockchain user.

[0048] The key and the state root of the target block. It should be noted that the embodiments in this specification mainly focus on the processing method for obtaining the target object based on the key of the target object and the state root of the target block. The acquisition of the key of the target object and the state root of the target block...

[0049] The method or source of acquisition is not limited.

[0050] The second state tree is a state tree for the target block contained in each storage unit, used to store partial state data for the target block. Each second state tree has a state root, i.e., a second state root. A storage unit is the smallest structural unit for organizing and storing data in a fragment. Depending on the implementation, the specific structure of the storage unit can differ. In one implementation, a storage unit may include an MPT tree for storing data.

[0051] According to one implementation, a first state root can be generated based on the plurality of second state roots. According to a specific implementation, a first value can be obtained by pre-combining the second state roots of each state tree, and the first state root and the first value are associated and stored in a blockchain node. In a specific implementation, an auxiliary process can also run in the blockchain node, the auxiliary process being used to associate and store the first state root and the second state roots of each state tree. The auxiliary process can, for example, be used to manage a lightweight database that can be used to store key-value pairs, and can pre-store the first state root and the first combined value as a key-value pair in the lightweight database, and use it to subsequently query the first combined value based on the first state root. Therefore, according to another specific implementation, the auxiliary process can be used to store a first key-value pair, the first key-value pair consisting of a second key and a first value, the first value including the second state root of each state tree, the second key being the hash value of the first value, and the first state root being the second key.

[0052] After receiving the first state root and the first key of the target object, in step 603, the second state root of each state tree can be obtained from the blockchain node based on the first state root.

[0053] In this step, the second state roots of each state tree are obtained from the blockchain nodes using the first state root. According to the implementation method where the first state root and the first value are associated and stored in the blockchain nodes, the first value can be obtained from the blockchain nodes based on the first state root, and the first value can be decomposed to obtain the state roots (second state roots) of each storage node. According to the implementation method where an auxiliary process runs in the blockchain nodes, the second state roots of each state tree can be obtained from the auxiliary process based on the first state root.

[0054] Next, in step 605, based on the first key, the first storage unit corresponding to the target object is determined from the plurality of storage units, and the third state root corresponding to the first storage unit is obtained from the plurality of second state roots.

[0055] In this step, the storage unit (first storage unit) for storing the state data of the target object is determined from multiple storage units.

[0056] According to one implementation, the first storage unit corresponding to the target object can be determined from the plurality of storage units based on the pre-defined correspondence between the string of the first key and the serial number of the storage unit corresponding to the target object. The key of each storage object is typically represented by a string, or key string. That is, when the state data of each storage object (e.g., an account or variable) is saved to its respective storage unit, the storage unit where it is stored can be determined based on the key string of each storage object. Depending on the specific implementation, the correspondence between the key string of a storage object and its storage unit can be different. For example, the storage unit of a storage object can be determined based on the character at a predetermined position in the key string. For example, it can be based on the first character of the key string. In one example, for instance, a storage object whose key string begins with "a" can be saved to, for example, storage unit 1, and a storage object whose key string begins with "b" can be saved to, for example, storage unit 2, and so on. That is, there is a predetermined correspondence between the first character of the key string and its storage unit. In another example, for instance, the storage unit of a storage object can also be determined by the first two characters of the key string. Therefore, according to one specific implementation, the correspondence between the pre-set string of the first key and the sequence number of the storage unit corresponding to the target object can be the correspondence between the character at a predetermined position in the string of the first key and the sequence number of the storage unit corresponding to the target object. However, allocating storage units based on the first character of the key string may result in uneven distribution. Therefore, the number of keys starting with different characters is not evenly distributed, leading to significant differences in the number of storage objects allocated to different storage units, resulting in an unbalanced load on each storage unit. To improve the load balancing of each storage unit, the hash value of the key string of each storage object can be calculated first, and then the storage unit of the storage object can be determined based on the hash value of the key string. Therefore, according to another specific implementation, the correspondence between the character at a predetermined position in the hash value of the string of the first key and the sequence number of the storage unit corresponding to the target object is...

[0057] After determining the storage unit (first storage unit) corresponding to the target object, the third state root corresponding to the target block in the first storage unit can be obtained from the multiple second state roots obtained in step 603. According to the above implementation method where multiple second state roots form a first value (and together with the first key form a first key-value pair), the second state roots of each state tree can be arranged according to the sequence number of their respective storage units, such as... Figure 7 As shown. Furthermore, the third state root corresponding to the first storage unit can be obtained from the first value based on the sequence number of the first storage unit.

[0058] After obtaining the third state root, in step S607, the value corresponding to the first key can be read from the first storage unit according to the third state root and the first key.

[0059] In this step, the state tree for the target block in the first storage unit can be accessed based on the third state root, and the state data of the target object can be obtained from the first storage unit based on the first key. According to one embodiment, a first state tree corresponding to the third state root can be determined in the first storage unit based on the third state root; the value corresponding to the first key is read from the first state tree. Specifically, the first storage unit may also have multiple state trees for the state data of multiple blocks, and the first state tree can be accessed based on the third state root.

[0060] As described above, depending on the implementation method, the N storage units included in a blockchain node can be allocated to multiple storage processes for management. In essence, this involves sharding the state data of the blockchain node. Each storage process can correspond to a shard of state data. By processing the state data of the blockchain node through multiple storage processes, the storage and response capabilities of the blockchain node can be improved.

[0061] According to one specific implementation, the blockchain node may run M storage processes, each of which corresponds to multiple storage units among the N storage units. Thus, the third state root and the first key can be sent to the first storage process corresponding to the first storage unit, and the value corresponding to the first key read from the first storage unit by the first storage process can be received.

[0062] Furthermore, the storage processes for each shard can run on different storage nodes. Depending on the implementation, a storage node can be a physical or logical server used to store data for the blockchain. Therefore, according to one implementation, a blockchain node can include at least one storage node, and each storage node can run one or more of the aforementioned storage processes; that is, a storage node can store one or more shards.

[0063] Depending on the implementation method, the method for querying data from a blockchain provided in the embodiments of this specification can be executed, for example, by a client connected to the blockchain node, or by a computing process running in a node of the blockchain.

[0064] The method for querying data from a blockchain according to this application is further described below through a specific embodiment. Figure 8 This is a state flowchart illustrating a method for querying data from a blockchain according to another embodiment of this specification. Figure 8As shown, multiple storage processes run in the blockchain node, such as storage process 1, storage process 2, etc. Each storage process manages multiple storage units (MSUs). Specifically, for example, a client connected to the blockchain node can, in step S801, accept, for example, the state root (state_root) of the target block and the key (key1) of the target object being queried, input by the user. In step S803, the state_root is sent to an auxiliary process running in the blockchain node. In step S804, the value (value2) of the key-value pair <key2, value2> stored in the lightweight key-value database (KVDB) managed by the auxiliary process is received, where key2 = state_root. In step S805, value2 is decomposed to obtain the state roots of multiple storage units. In step S807, based on the string of key1 and the storage unit of the target object's state data, the storage unit of the target object's state data is determined, for example, msu1. And the state root of msu1, for example, root_hash1, is obtained from the state roots of the multiple storage units obtained in step S805. In step S809, root_hash1 and key1 are sent to the storage process managing the MSU, for example, storage process 2. Upon receiving root_hash1 and key1, storage process 2 can, in step S810, access MSU1 based on root_hash1 and key1, and retrieve the state data of the target object corresponding to key1, i.e., value1. Then, in step S812, the state data of the target object is returned to the client.

[0065] In summary, the advantages of the method for querying data from the blockchain provided in this specification are as follows: Firstly, this method can access the state data of a target object stored in the state tree of different storage units based on the state root of a single entire block. This is something that conventional blockchain state data query methods cannot accomplish. Secondly, the state root of the block used in this method is generated based on the hash value of the state root of each storage unit, which can be used to determine whether any state root in the state roots of all storage units has changed. The state root of each storage unit is generated based on its own stored partial state data, which can reflect changes in its own stored partial state data. Therefore, the state root of the block can be used to determine whether the entire state data has changed. In conclusion, this method can access the state data in different storage units through the full state root, thus satisfying the need to find state data in a distributed blockchain storage scenario with multiple storage units, and the state root used can represent the entire state, which is in line with the general operating mechanism of blockchain.

[0066] Figure 9This specification describes an embodiment of a device for querying data from a blockchain. The blockchain node comprises N storage units, each storing state data of a subset of objects within the blockchain. The state data in each storage unit, corresponding to a block, forms a state tree. For example... Figure 9 As shown, the device 900 includes:

[0067] The receiving unit 901 is used to receive the first state root of the target block and the first key of the target object, wherein the blockchain node stores the correspondence between the first state root and multiple second state roots, and the multiple second state roots are the state roots of multiple state trees corresponding to the target block in multiple storage units.

[0068] The first processing unit 902 is configured to obtain the second state root of the plurality of state trees from the blockchain node based on the first state root;

[0069] The second processing unit 903 is configured to determine the first storage unit corresponding to the target object from the plurality of storage units according to the first key, and obtain the third state root corresponding to the first storage unit from the plurality of second state roots;

[0070] The target value acquisition unit 904 is used to read the value corresponding to the first key from the first storage unit based on the third state root and the first key.

[0071] This specification also provides an example of a blockchain node. For example... Figure 10 As shown, the blockchain node 1000 includes a memory 1001 and a processor 1002. The memory 1001 stores executable code, and when the processor 1002 executes the executable code, it implements the method described above.

[0072] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0073] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0075] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0076] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0077] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0078] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0079] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0081] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0082] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0083] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

[0085] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0086] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method of querying data from a blockchain, wherein, The blockchain node of the blockchain includes N storage units, each of which stores state data of part of objects in the blockchain, and the state data corresponding to one block in each storage unit constitutes a state tree, and the method comprises: Receiving a first state root of a target block and a first key of a target object, wherein the first state root and a plurality of second state roots are stored in the blockchain node, and the plurality of second state roots are state roots of a plurality of state trees corresponding to the target block in a plurality of storage units; According to the first state root, the plurality of second state roots are obtained from the blockchain node; According to the first key, a first storage unit corresponding to the target object is determined from the plurality of storage units, and a third state root corresponding to the first storage unit is obtained from the plurality of second state roots; According to the third state root and the first key, the value corresponding to the first key is read from the first storage unit.

2. The method of claim 1, wherein, The auxiliary process is run in the node of the blockchain, and the auxiliary process is used to save the first state root in association with the plurality of second state roots, and the second state root of each state tree is obtained from the blockchain node according to the first state root, comprising: According to the first state root, the second state root of each state tree is obtained from the auxiliary process.

3. The method of claim 1, wherein, According to the first key, the first storage unit corresponding to the target object is determined from the plurality of storage units, comprising: According to the correspondence between the string of the first key and the serial number of the storage unit corresponding to the target object, the first storage unit corresponding to the target object is determined from the plurality of storage units.

4. The method of claim 3, wherein, The correspondence between the string of the first key and the serial number of the storage unit corresponding to the target object comprises: The character at the predetermined position in the string of the first key is associated with the serial number of the storage unit corresponding to the target object.

5. The method of claim 3, wherein, The correspondence between the string of the first key and the serial number of the storage unit corresponding to the target object comprises: The character at the predetermined position in the hash value of the string of the first key is associated with the serial number of the storage unit corresponding to the target object.

6. The method of claim 2, wherein, The auxiliary process is used to save the first state root in association with the plurality of second state roots, comprising: The auxiliary process is used to save the first state root in association with the combination value of the plurality of second state roots, and the combination value is used to obtain the plurality of second state roots.

7. The method of claim 6, wherein, The second state root of each state tree in the first value is arranged according to the serial number of the storage unit to which it belongs, and the third state root corresponding to the first storage unit is obtained from the plurality of second state roots, comprising: According to the serial number of the first storage unit, the third state root corresponding to the first storage unit is obtained from the first value.

8. The method of claim 1, wherein, The method is executed by a computing process running in the node of the blockchain or by a client connected to the node.

9. The method of claim 1, wherein, According to the third state root and the first key, the value corresponding to the first key is read from the first storage unit, comprising: determine, according to the third state root, a first state tree corresponding to the third state root in the first storage unit; read, from the first state tree, a value corresponding to the first key.

10. The method of claim 9, wherein, The blockchain node runs M storage processes, and each storage process corresponds to a plurality of storage units in the N storage units. The reading of the value corresponding to the first key from the first storage unit according to the third state root and the first key comprises: sending the third state root and the first key to a first storage process corresponding to the first storage unit, and receiving, from the first storage process, the value corresponding to the first key and the third state root read from the first storage unit.

11. The method of claim 10, wherein, The blockchain node comprises at least one storage node, and each storage node runs at least one storage process.

12. The method of claim 1, wherein, The first state root is generated based on the plurality of second state roots.

13. An apparatus for querying data from a blockchain, wherein, The blockchain node of the blockchain comprises N storage units, each storage unit storing state data of part of objects in the blockchain, and state data corresponding to one block in the state data in each storage unit constitutes a state tree, and the device comprises: a receiving unit configured to receive a first state root of a target block and a first key of a target object, wherein the blockchain node stores a correspondence between the first state root and a plurality of second state roots, and the plurality of second state roots are state roots of a plurality of state trees corresponding to the target block in a plurality of storage units; a first processing unit configured to obtain the plurality of second state roots from the blockchain node according to the first state root; a second processing unit configured to determine a first storage unit corresponding to the target object from the plurality of storage units according to the first key, and obtain a third state root corresponding to the first storage unit from the plurality of second state roots; a target value obtaining unit configured to read a value corresponding to the first key from the first storage unit according to the third state root and the first key.

14. A computer-readable storage medium having a computer program stored thereon, when the computer program is executed by a computer or a processor, the computer or the processor executes the method of any one of claims 1-12.

15. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method of any one of claims 1-12.

Images