CN110800008A

CN110800008A - Building block chain world state mercker patricia dictionary tree subtree

Info

Publication number: CN110800008A
Application number: CN201980003201.8A
Authority: CN
Inventors: 张文彬
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-03-04
Filing date: 2019-03-04
Publication date: 2020-02-14
Anticipated expiration: 2039-03-04
Also published as: AU2019203850A1; CA3057738A1; JP6865851B2; US10691665B1; AU2019203850B2; JP2020530213A; KR20200107771A; TWI720712B; TW202034246A; WO2019101230A2; KR102277289B1; EP3596684A4; US20200320055A1; WO2019101230A3; SG11201908944WA; EP3596684A2; US10929374B2; CN110800008B

Abstract

Embodiments herein include traversing the world state MPT through a plurality of iterations, in each iteration, for a current node of the world state MPT, performing one of: marking a current node as an account node, storing the address of the current node in an address list, determining that the current node is an extended node, moving to the next iteration of traversal, setting the current node as a node referenced by the extended node by the next iteration, marking the current node as a transition node, and storing the address of the current node in the address list; a subtree of the world state MPT is created based on the address list, a root node of the subtree including a root node of the world state MPT, addresses of one or more child nodes of the subtree corresponding to the nodes of the world state MPT being stored in the address list.

Description

Building block chain world state mercker patricia dictionary tree subtree

Background

Distributed Ledger System (DLS), which may also be referred to as a consensus network and/or a blockchain network, enables participating entities to securely and tamperproof store data. Without reference to any particular use case, DLS is often referred to as a blockchain network. Example types of blockchain networks may include public blockchain networks, private blockchain networks, and federation blockchain networks. The public blockchain network opens all entities to use DLS and participate in consensus processing. A private blockchain network is provided for a particular entity that centrally controls read and write permissions. A federated blockchain network is provided for a selected entity group that controls the consensus process, and the federated blockchain network includes an access control layer.

A hash tree may be used for blockchain network storage of information. For example, the world state of the blockchain network (e.g., the state of the nodes (accounts) in the blockchain network) may be stored in a hash tree. Examples of hash trees include the world state Merkel PatriciaTrie (MPT) that maintains the world state of all nodes (accounts) within a blockchain network. As blockchain networks grow, world state information correspondingly increases, resulting in complex data-intensive hash trees.

Not all nodes within a blockchain network need to maintain the world state of the blockchain. For example, so-called consensus nodes (full clients) participating in adding transactions to blockchains within a blockchain network maintain a world state hash tree to be able to participate in the consensus process. Other nodes (lightweight clients) that only transact within the blockchain network do not need to maintain, or even know, the world state. However, such nodes need to know their own state and the state (e.g., local state) of other nodes with which they are transacting within the blockchain. Given the size and complexity of the world state hash tree and the resource limitations of the devices used by lightweight clients, resource and bandwidth efficient data structures and processes for updating the data structures to maintain the local state of the blockchain network are needed.

Disclosure of Invention

Embodiments herein include a computer-implemented method for generating and updating a sub-tree of a world state merkel patricia dictionary tree MPT.

In some implementations, the actions include: providing a world state MPT and an address list for storing addresses of nodes in the blockchain network by a consensus client of the blockchain network, wherein the address list is empty initially; the consensus client traverses at least a portion of the world state MPT over a plurality of iterations, and in each iteration, for a current node of at least a portion of the world state MPT, performs one of: marking the current node as an account node, storing the address of the current node in an address list, determining that the current node is an extended node, moving to the next iteration of traversal, setting the current node as a node referenced by the extended node in the next iteration, marking the current node as a transition node, and storing the address of the current node in the address list; the consensus client creates a sub-tree of the world state MPT based on the address list, wherein the root node of the sub-tree comprises the root node of the world state MPT, and the addresses of one or more sub-nodes of the sub-tree corresponding to the node of the world state MPT are stored in the address list; the consensus client sends a sub-tree of the world state MPT to the non-consensus client of the blockchain network, the sub-tree providing a state of an account associated with the non-consensus client. Other embodiments include corresponding systems, devices, and computer programs, encoded on computer storage devices, configured to perform the actions of the methods.

These and other embodiments may each optionally include one or more of the following features: in response to determining that the current node is one of a leaf node and a branch node with an empty value, marking the current node as an account node; in response to determining that the current node is a branch node and that all children nodes of the branch node have been traversed, marking the current node as a transition node; after marking the current node as an account node, the current node of the next iteration of the traversal comprises a parent node of the account node; after marking the current node as one of the account node and the transition node, the current node of the next iteration of the traversal includes a child node of the one of the account node and the transition node; creating a subtree of the world state MPT based on the address list includes, at least in part: for addresses marked as account nodes in the address list, determining a path in the world state MPT, and adding the path to the subtree; the traversal comprises a depth-first precedence traversal.

Also provided herein are one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

Also provided herein are systems for implementing the methods provided herein. The system includes one or more processors and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

It should be appreciated that methods in accordance with the present disclosure may include any combination of the aspects and features described herein. That is, methods according to the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided.

The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the text and drawings, and from the claims.

Drawings

FIG. 1 depicts an example of an environment that may be used to implement embodiments herein.

Fig. 2 depicts an example of a conceptual architecture according to embodiments herein.

FIG. 3 depicts an example of the world state Merkle Patricia dictionary tree (MPT).

Fig. 4 depicts an example of a sub-tree generated based on the example world state MPT of fig. 3, according to embodiments herein.

Fig. 5A and 5B depict examples of processes that may be performed according to embodiments herein.

FIG. 6 depicts the example world state MPT of FIG. 3 including an update.

Fig. 7 depicts the subtree of fig. 4 including updates based on the exemplary world state MPT of fig. 6, according to embodiments herein.

Fig. 8A and 8B depict examples of processes that may be performed according to embodiments herein.

Fig. 9 depicts an example of modules of an apparatus according to embodiments herein.

Fig. 10 depicts an example of modules of an apparatus according to embodiments herein.

Like reference symbols in the various drawings indicate like elements.

Detailed Description

Embodiments herein include a computer-implemented method for generating and updating a sub-tree of a world state merkel patricia dictionary tree (MPT). As described in further detail herein, embodiments herein include the following actions: the world state MPT is traversed over a plurality of iterations, and in each iteration, for a current node of the world state MPT, one of the following operations is performed: marking the current node as an account node, storing the address of the current node in an address list, determining that the current node is an extended node, moving to the next iteration of traversal, setting the current node as a node referenced by the extended node in the next iteration, marking the current node as a transition node, and storing the address of the current node in the address list; a subtree of the world state MPT is created based on the address list, a root node of the subtree including a root node of the world state MPT, addresses of one or more child nodes of the subtree corresponding to the nodes of the world state MPT being stored in the address list.

Further background is provided for embodiments herein, and as noted above, Distributed Ledger Systems (DLSs), which may also be referred to as consensus networks (e.g., consisting of point-to-point nodes) and blockchain networks, enable participating entities to securely and non-tamperproof conduct transactions and store data. Although the term "blockchain" is typically associated with a particular network and/or use case, blockchains as used herein generally refer to DLS without reference to any particular use case.

Blockchains are data structures that store transactions in a transaction-untamperable manner. Thus, the transactions recorded on the blockchain are reliable and trustworthy. A block chain includes one or more blocks. Each block in the chain is linked to the immediately preceding block in the chain by a cryptographic hash value (cryptographic hash) that contains the preceding block. Each tile 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 merkel (Merkle) trees. A Merkle tree is a data structure in which data at leaf nodes of the tree is hashed and all hash values in each branch of the tree are concatenated at the root of the branch. This process continues down the tree up to the root of the entire tree where hash values representing all of the data in the tree are stored. The hash value of a transaction purportedly stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree. A blockchain is a decentralized or at least partially decentralized data structure for storing transactions, while a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains by broadcasting, validating, and confirming transactions, etc.

As described above, the blockchain network may be provided as a public blockchain network, a private blockchain network, or a federated blockchain network. Embodiments herein are described in further detail with reference to federated blockchain networks. However, it is contemplated that the embodiments herein may be implemented in any suitable type of blockchain network. Although the techniques described herein are indicated as being related to a federated blockchain network, the techniques may be used with or without changes in other types of blockchain networks, including public blockchain networks and private blockchain networks.

Typically, a federated blockchain network is private between the participating entities. In a federated blockchain network, consensus processes are controlled by an authorized set of nodes, which may be referred to as consensus nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, and each entity may operate at least one node in the federated blockchain network.

In some examples, within a federated blockchain network, a global blockchain is provided as a blockchain that is replicated across all nodes. That is, all consensus nodes are in a fully consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented within the federated blockchain network. Example consensus protocols include, but are not limited to, pragmatine fault tolerance (PBFT), proof of workload (POW), proof of rights over (POS), and proof of authority (POA).

In view of the above background, embodiments herein are described in further detail herein. More specifically, and as described in further detail herein, embodiments herein perform depth-first pre-order traversal (depth-first pre-order traversal) to improve the order of addressing in the MPT, and utilize a particular type of node between two account nodes (leaf nodes) in the traversal process, referred to herein as a transition node.

In more detail, embodiments herein provide a world state sub-tree, referred to herein as a sub-tree T2, based on the world state MPT T0 and the address list L0. The embodiments herein avoid finding a path from the root node to the leaf nodes for each address by first constructing a subtree (referred to herein as subtree T1) from the address list L0, and then performing a depth-first-precedence traversal in subtree T1. And sequentially searching the account node address and the transition node address through depth-first forward traversal. If a transition node exists between two account nodes, then a transition node is returned from the first account node and looked up from the transition node to the other account node. In this way, the search for the second account node need not start at the root node, but at the transition node.

As also described in further detail herein, the embodiments herein reduce the requirements for the processor and storage. For example, for each address, paths from the root node to its respective leaf node are saved, and overlapping nodes in these paths are merged. More specifically, if there is a transition node between two account nodes, instead of storing a complete path from the root node to each account node (i.e., each leaf node corresponding to an account address), only the path from the transition node to the next account node is saved. In this way, paths to multiple account nodes are merged, which improves efficiency and avoids wasted operations and storage caused by overlapping paths.

FIG. 1 depicts an example of an environment 100 that may be used to implement embodiments herein. In some examples, the example environment 100 enables entities to participate in a federated blockchain network 102. The example environment 100 includes computing devices 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 network sites, user devices (e.g., computing devices), and backend systems. In some examples, network 110 may be accessed through wired and/or wireless communication links. In some examples, network 110 enables communication with federated blockchain network 102 as well as communication within federated blockchain network 102. In general, the network 110 represents one or more communication networks. In some cases, the computing devices 106, 108 may be nodes of a cloud computing system (not shown), or the computing devices 106, 108 may each be a stand-alone cloud computing system that includes multiple computers interconnected by a network and functions as a distributed processing system.

In the depicted example, computing systems 106, 108 may each include any suitable computing device 120 capable of participating as a node in federation blockchain network 102. Example computing devices include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smart phones. In some examples, the computing systems 106, 108 carry one or more computer-implemented services for interacting with the federation blockchain network 102. For example, the computing system 106 may host a computer-implemented service, such as a transaction management system, of a first entity (e.g., participant a) that the first entity uses to manage its transactions with one or more other entities (e.g., other participants). The computing system 108 may host a computer-implemented service, such as a transaction management system, of a second entity (e.g., participant B), e.g., which the second entity uses to manage its transactions with one or more other entities (e.g., other participants). In the example of fig. 1, the federated blockchain network 102 is represented as a Peer-to-Peer network of nodes (Peer-to-Peer network), and the computing systems 106, 108 provide nodes of first and second entities, respectively, participating in the federated blockchain network 102.

Fig. 2 depicts an example of a conceptual architecture 200 according to embodiments herein. The exemplary concept 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 that includes a plurality of nodes 214, at least some of which record information in a blockchain 216 without tampering. As further detailed in the figure, although a single blockchain 216 is schematically depicted in blockchain network 212, multiple copies of blockchain 216 are provided and maintained on blockchain network 212.

In the depicted example, each

participant system

202, 204, 206 is provided by or represents participant a, participant B, and participant C, respectively, and functions as a respective node 214 in the blockchain network. As used herein, a node generally refers to an individual system (e.g., computer, server) that is connected to the blockchain network 212 and enables the respective participants to participate in the blockchain network. In the example of fig. 2, a participant corresponds to each node 214. However, it is contemplated that one participant may operate multiple nodes 214 within blockchain network 212, and/or that 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).

The nodes 214 may have different degrees of participation within the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles 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 blockchain 216, while other nodes 214 store only a copy of a portion of blockchain 216. For example, the data access privileges may restrict blockchain data stored by the respective participants within their respective systems. In the example of fig. 2, the

participant systems

202, 204 store respective full copies 216', 216 "of the blockchain 216.

Nodes participating in a blockchain network may be referred to as clients, which connect with other clients in a point-to-point manner. As mentioned above, clients (nodes) may participate in blockchain networks to varying degrees. For example, clients may include full clients and lightweight clients.

In some examples, the full number of clients participate in the consensus process and maintain the state of the blockchain (e.g., store and continually update blockchains). Thus, each full client downloads and verifies each tile added to the blockchain, and thus each transaction in each tile. In the example of fig. 2, the

participant systems

202, 204 may be considered to be full clients (full nodes).

In some examples, lightweight clients (lightweight nodes) enable users to access and interact with the blockchain system. The lightweight client does not participate in the consensus process and does not synchronize the entire blockchain. Thus, lightweight clients may be referred to as non-consensus nodes. And the lightweight client is connected to one or more full clients, whereupon the lightweight node interacts with the blockchain. That is, lightweight clients do not interact directly with the blockchain, but rather interact with the blockchain using a full-scale node as an intermediary. Thus, lightweight clients require significantly less (e.g., an order of magnitude less) computing resources and storage than full-size clients. However, lightweight clients may not be able to access all of the blockchain, but only the data they are authorized to access. In the example of fig. 2, the participant system 206 may be considered a lightweight client that does not have a copy of the blockchain 216.

A blockchain (e.g., blockchain 216 of fig. 2) consists of a series of blocks, each block storing data. Exemplary data includes transaction data representing a transaction between two or more participants. Although "transactions" are used herein by way of non-limiting example, it is contemplated that any suitable data (e.g., documents, images, video, audio) may be stored in the blockchain. Example transactions may include, but are not limited to, the exchange of value (e.g., assets, products, services, currency). Transaction data is stored in the blockchain in a tamperproof manner. That is, the transaction data cannot be changed.

The transaction data is hashed prior to being stored in the chunk. The hash process is a process of converting transaction data (provided as character string data) into a fixed-length hash value (also provided as character string data). It is not possible to perform a de-hash process (un-hash) on the hash value to obtain the transaction data. The hashing process may ensure that even slight changes in the transaction data result in an entirely different hash value. Further, as described above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. The hash process includes processing the transaction data through a hash function to generate a hash value. Exemplary hash functions include, but are not limited to, Secure Hash Algorithm (SHA) -256 which outputs a 256-bit hash value.

Transaction data for a plurality of transactions is hashed and stored in a block. For example, hash values for two transactions are provided, and themselves are hashed to provide another hash value. This process is repeated until a single hash value is provided for all transactions to be stored in the block. This hash value is called the merkel (Merkle) root hash value and is stored in the header of the chunk. Any change in a transaction causes its hash value to change and ultimately the Merkle root hash value to change.

The blocks are added to the block chain by a consensus protocol. A plurality of nodes in the blockchain network participate in the consensus protocol and perform the work of adding a block to the blockchain. Such nodes are referred to as consensus nodes. The PBFT introduced above serves as a non-limiting example of a consensus protocol. The consensus node executes a consensus protocol to add the transaction to the blockchain.

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

Typically, PBFT provides a practical byzantine machine state replication that is tolerant of byzantine errors (e.g., failed nodes, malicious nodes). This is achieved by assuming that errors will occur in the PBFT (e.g., assuming there is an independent node failure and/or a tamper message sent by a cognizant node). In PBFT, consensus nodes are provided in a sequence comprising a primary consensus node and a secondary consensus node. The master consensus node is periodically changed, and a transaction is added to the blockchain by all consensus nodes within the blockchain network agreeing on the global state of the blockchain network. In this process, messages are transmitted between the consensus nodes, and each consensus node proves that the message was received from a designated peer node and verifies that the message was not tampered with during the transaction.

In PBFT, the consensus protocol is provided in multiple phases with all consensus nodes starting in the same state. First, a client sends a request to a master consensus node to invoke a service operation (e.g., perform a transaction within a blockchain network). In response to receiving the request, the primary consensus node multicasts the request to the backup consensus node. The backup consensus nodes execute the request and each send a recovery to the client. The client waits until a threshold number of recoveries are received. In some examples, the client waits to receive f +1 copies, where f is the maximum number of false 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, either accepted or rejected.

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

Asymmetric encryption uses key pairs, each key pair comprising a private key and a public key, the private key being known only to the respective node, and the public key being known to any or all other nodes in the blockchain network. A node may encrypt data using a public key of another node, and the encrypted data may be decrypted using a private key of the other node. For example, referring again to fig. 2, participant a may encrypt data using participant B's public key 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 the node's private key.

Asymmetric encryption is used to provide a digital signature that enables a participant in a transaction to confirm the other participants in the transaction and the validity of the transaction. For example, a node may digitally sign a message, and another node may confirm that the message was sent by the node based on the digital signature of participant a. Digital signatures may also be used to ensure that messages are not tampered with during transmission. For example, referring again to fig. 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 did indeed come from participant A and has not been tampered with.

To provide further context for embodiments herein, a hash tree (also known as a merkler tree (Merkletree), as described above) is a tree of nodes and edges between nodes. The Merkle tree includes a root node, child nodes, and leaf nodes. In blockchain networks, the Merkle tree stores hash values, as described above. In the Merkle tree, each leaf node is labeled with a hash value of the data block and each non-leaf node is labeled with a labeled hash value of its child node. The Merkle tree enables efficient and secure verification of the contents of large data structures such as blockchains. A trie (also known as a prefix tree) is a multi-way tree structure that can be used to store alphabetically expressed strings. A Patricia trie is a compact representation of a trie in which any node that is a unique child node is merged with its parent. A Mercker Patriey dictionary tree (also known as a Mercker Patriei Tree (Tree) or MPT) is a tree that contains both Merkle trees and Patriei dictionary trees (Prefix trees) and inherits the advantages of both.

In more detail, MPTs can be described as a persistent, volatile data structure that maps between 256-bit binary segments and binary data of arbitrary length (byte arrays). In some examples, the MPT may be implemented as a database. The MPT provides a single value that identifies a given set of key-value pairs, which may be a 32-byte sequence or a null-byte sequence. For example, when traversing an MPT from a root node to a leaf node, the corresponding key-value pair is provided. Keys are accumulated by traversal, taking a single four-bit (i.e., a single hexadecimal number, hex digit) from each branch node, as described below. In the example where multiple keys share the same prefix, or in the case of a single key with a unique suffix, an optimized node is provided. Thus, when traversing the MPT, multiple four bits can be obtained from the other two node types (extension node and leaf node), respectively.

In MPT, leaf nodes are each provided as a two-item (two-item) structure. One entry corresponds to four bits in the key that have not been considered by the accumulation of the key and the branches traversed from the root. Hexadecimal prefix coding is used and the second parameter of the function is required to be true (true). Examples of leaf nodes and corresponding items are described in further detail herein. The expansion nodes are each provided as two structures. One entry corresponds to a series of four bits of size greater than 1, shared by at least two different keys after the accumulation of the four-bit key and the traversal of the branch from the root. Hexadecimal prefix coding is used and the second parameter of the function is required to be false (false). Examples of extension nodes and corresponding items are described in further detail herein. The branch nodes are provided as a 17-entry structure, with the first sixteen entries corresponding to each of the sixteen possible four-bit values (e.g., hexadecimal values 0-f) of the key at that point in the traversal. Item 17 is for the case where the branch node is a termination node, and thus the key terminates at that point in the traversal. Branches are used only when necessary, and there may not be a branch node containing only a single non-zero entry (entry).

In a blockchain network, MPT implements password authentication and performance balancing and is used for world state data management to manage the account state (and smart contracts) of users. In some blockchain networks, an interface is provided for querying the status of an account through a so-called world-state MPT. For example, an account address may be entered through an interface, and a node of the blockchain network (e.g., a full client) returns the status of the account. When querying the status of a large number of accounts, the interface is invoked repeatedly and the status of each account is returned. It may be noted that the data returned (e.g., account, status) is fragmented and has no structure. Although the data may be assembled locally into the state tree, the resulting state tree is typically not consistent with the world state MPT. Thus, the advantages of MPT itself are lost and the performance of operation and storage is relatively low.

As described in further detail herein, embodiments herein perform a depth-first-precedence traversal to improve the order in which addresses are searched in the MPT tree, and utilize a particular type of node, referred to herein as a transition node, between two account nodes (leaf nodes) in the traversal process. In more detail, the embodiments herein provide a world state sub-tree, referred to herein as a sub-tree T2, based on the world state MPT T0 and the address list L0. Embodiments herein avoid finding a path to a leaf node from a root node for each address by first constructing a sub-tree, referred to herein as sub-tree T1, from address list L0, and then performing a depth-first-precedence traversal in sub-tree T1. And sequentially searching the account node address and the transition node address through depth-first forward traversal. If there is a transition node between two account nodes, the first account node is returned to the transition node, from where it looks up to the other account node. In this way, the search for the second account node need not start at the root node, but at the transition node.

As also described in further detail herein, the embodiments herein reduce the requirements for the processor and storage. For example, for each address, paths from the root node to its respective leaf node are saved, and overlapping nodes in these paths are merged. More specifically, rather than storing a complete path from the root node to each account node (i.e., each leaf node corresponding to an account address), only paths from the transition node to the next account node are saved if there is a transition node between two account nodes. In this way, paths to multiple account nodes are merged, which improves efficiency and avoids wasted operations and storage caused by overlapping paths.

In some embodiments, and as described in further detail herein, given a list of account addresses in a world state MPT, a sub-tree of the list of addresses is provided. The embodiments herein employ a depth-first-precedence traversal algorithm to improve the order of searching addresses in the MPT and increase the efficiency of the nodes. Further, embodiments herein provide a node traversal process that includes a transition node between two account nodes. To avoid the search waste caused by looking up each account node starting from the root node, embodiments include saving the path from the transition node to the next account node, accounting for the overlap of the paths from the root node to the two account nodes. As described herein, the present embodiments improve efficiency and avoid wasted operations and storage caused by overlapping paths.

Embodiments herein are described in further detail with reference to an exemplary world state MPT. An exemplary world state MPT is based on The Etherhouse blockchain application platform provided by The Etherum Foundation of Zug (Switzerland) of Swedengge. Etherhouses offer digital assets called Ethercoins (ETH), the smallest unit of which is called Wei (Wei ). However, it is contemplated that the embodiments herein may be implemented in any suitable blockchain network and any suitable world state MPT.

Fig. 3 depicts an example of a world state MPT 300. It should be understood that the exemplary world state MPT300 of fig. 3 is relatively simplistic to facilitate easy understanding of embodiments herein. However, it is contemplated that the present embodiments may be implemented with MPTs of varying complexity (e.g., hundreds or thousands of nodes). In the example of fig. 3, the MPT300 includes a root node 302,

branch nodes

304, 306, an extension node 308, and

leaf nodes

310, 312, 314. In some examples,

leaf nodes

310, 312, 314 correspond to respective accounts (account _1, account _2, account _3) within the blockchain network. The exemplary world state MPT300 also includes a table 320 that records key-value pairs. In the example of FIG. 3, the table 320 includes key-value pairs 322, 324, 326 corresponding to

leaf nodes

310, 312, 314, respectively.

In some examples, the world state MPT300 of fig. 3 is maintained (e.g., built, updated) by multiple clients within a blockchain network. For example, a full number of clients as described above may participate in the consensus process and maintain the world state of blockchains within the blockchain network. This may include, for example, storing a complete copy of the block chain and the world state MPT 300. The exemplary full-scale client includes the

participant systems

202, 204 of fig. 2 as described above.

As described above, the blockchain network may include a lightweight client that does not maintain the world state of the blockchain and does not store a complete copy of the blockchain and the world state MPT 300. As a non-limiting example, a lightweight client may be interested in or have access to only a subset of accounts within the blockchain network (e.g., account _1, account _2), and neither interested nor authorized to access other accounts (e.g., account _ 3). According to embodiments herein, a lightweight client may maintain the state of a subset of accounts that are consistent with the state provided in the world state MPT 300. As described in further detail herein, the full-scale client generates a subtree of the MPT300 that represents the portion of the world state MPT300 that is relevant to the subset of accounts. The subtrees are provided to lightweight clients and are periodically updated to ensure that the state of the subtrees is consistent with the state of the world state MPT 300.

Fig. 4 depicts an example of a sub-tree 400 generated based on the example world state MPT300 of fig. 3, according to embodiments herein. In fig. 4, an exemplary sub-tree 400 includes a root node 402,

branch nodes

404, 406, an extension node 408, and

leaf nodes

410, 412 corresponding to the root node 302,

branch nodes

304, 306, extension node 308, and

leaf nodes

310, 312, respectively, of the world state MPT300 of fig. 3. The

leaf nodes

410, 412 correspond to respective clients (e.g., lightweight clients) that may access respective accounts (Account _1, Account _2) within the blockchain network. The exemplary sub-tree 400 also includes a table 420 that records key-value pairs. In the example of FIG. 4, the table 420 includes key-value pairs 422, 424 corresponding to

leaf nodes

410, 412, respectively.

The subtree 400 of fig. 4 does not have a leaf node corresponding to the leaf node 314 of the world state MPT300 of fig. 3 (e.g., a lightweight client does not have access to the account represented by the leaf node 314 (account _ 3)). And branch node 406 includes the placeholder character in item 10.

According to embodiments herein, and as described in detail herein, subtree 400 may be generated by a full-scale client for a lightweight client. For example, a lightweight client may submit a request for a subtree to the blockchain network. In response to the request, the full-volume client may generate a subtree 400 based on the account accessible to the lightweight client and the world state MPT300 maintained by the full-volume client. In some examples, the request from the lightweight client includes a list of addresses corresponding to a subset of accounts accessible to the lightweight client. In some examples, a list of addresses for a subset of accounts accessible to the lightweight client is determined by the full-scale client, e.g., an Access Control List (ACL) is indexed within a blockchain network using a unique identifier of the lightweight client. As described in further detail herein, given the world state MPT300 and the address list, the full number of clients generate a subtree 400 and return the subtree 400 to the requesting lightweight client.

Fig. 5A and 5B depict examples of processes 500, 550 that may be performed according to embodiments herein. In some implementations, the example processes 500, 550 may be performed using one or more computer-executable programs executed with one or more computing devices. For example, the example processes 500, 550 may be performed by a full-scale client to generate a subtree for a lightweight client within a blockchain network.

With particular reference to FIG. 5A, the exemplary process 500 may be performed to provide an address list L1 from the world state MPT T0 for constructing a sub-tree T2.

A world state MPT T0 and an address list L0 are provided (502). For example, world state MPT 0 (e.g., world state MPT300 of fig. 3) and address list L0 are provided as inputs for generating a subtree of address lists by a full-scale client (e.g., the full-scale client stores world state MPT300 and receives address lists). In some examples, each address in address list L0 is an address of a leaf node of MPT 0 (e.g.,

leaf nodes

310, 312, 314 of MPT 300). Any order of account addresses may be provided within address list L0. In some embodiments, and as described in further detail herein, a depth-first-precedence traversal algorithm is used to search over the nodes of MPT tree T0.

The MPT tree T1 is provided from the address list L0 (502). In some examples, address list L0 is based on an ACL that represents a list of addresses that a particular lightweight client is allowed to access. In some examples, the address list L0 provides addresses to be included in the subtree T2 to be created. In some examples, the value of each address in address list L0 is defaulted to a null string (e.g., referred to as null), and the value of each node in T1 may be calculated. An empty address list L1 is created 504. A node traversal is performed starting from the root node of T1 and traversing T1 with a depth-first-precedence traversal (506). As described in further detail herein, the example process 500 recursively records the nodes of the addresses in the respective address list L0 and the transition nodes between them in the address list L1.

It is determined whether the current node is a leaf node (508). If the current node is a leaf node, the node corresponds to a node in the address list. The node is marked (e.g., "account node"), and the address and mark of the node are saved to address list L1 (510). Traversal returns to the parent node of the leaf node (512). If the current node is not a leaf node, a determination is made whether the current node is an extended node (514). If the current node is an extended node, the value of the node points to a reference to another node, traversing to the referenced node (516).

If the current node is not an extension node, the current node is a branch node and a determination is made whether to reach the node for the first time (520). If not, a determination is made as to whether all children of the current node have been traversed (522). If all child nodes have been traversed, the traversal returns to the parent node of the branch node (512). If not all children have been traversed, the node is marked as a "transition node" and the address and marker for the node is saved in L1 (524), the traversal moves to children that have not been traversed (526). If it is the first time to the current node (branch node), it is determined whether its value is null (e.g., null string, also referred to as null) (528). If its value is null, indicating that the node corresponds to a node in the address list, then the node is marked as an "account node" and the mark and address are saved to L1(530) and the traversal moves to the first child node (526).

With particular reference to FIG. 5B, the exemplary process 550 may be performed to construct a subtree T2 from the address list L1 and the world state MPT T T0. As described herein, the subtree T2 includes the same root node as the world state MPT T0, and the remainder of the subtree T2 is constructed from the root node by recursively performing the following operations.

The sub-tree T2 is provided with the root node of T0 (552). The first address labeled "Account node" in the Address List L1 is selected (554). The corresponding node (556) is looked up in T0. Thus, a search path from the root node in T0 to the corresponding node is provided. Each node on the path is added to T2 (558). The next address in the address list L1 is selected (560). A determination is made as to whether the node corresponding to the address is marked as an "account node" (562). If the node is marked as "Account node", then starting with the current node in T0, the node corresponding to the address is looked up in T0, adding each node on the path to T2 (564).

If the node is not marked as an "account node," a determination is made as to whether the node is marked as a "transit node" (566). If the node is marked as a "transition node," starting with the current node in T0, the node corresponding to the address is determined and provided as the (new) current node in T0 (568). The account node to transition node path is not added to T2. After traversing all the addresses in the address list L1, the resulting T2 is a sub-tree of the address list L0 in the original world state MPT T T0.

As described above, embodiments herein also relate to updating subtrees based on world state MPTs. More specifically, since the world state records account states of all nodes (e.g., users, smart contracts), the amount of data recorded in the world state MPT may be large. For clients such as lightweight clients, large amounts of data are irrelevant or inaccessible (e.g., without access rights). Thus, and as described above, some clients may be willing only to locally maintain account status for some of the users (and smart contracts) associated with them in the world state. As described herein, this is achieved by providing clients (lightweight clients) with subtrees of the world state MPTs that the clients store locally.

However, the world state maintained by the consensus node (e.g., in the world state MPT) is updated frequently. Thus, the subtrees maintained by the client also need to be periodically updated. Generally, updating the sub-tree may include synchronizing the most recent data of the sub-tree with data of the world state MPT of the consensus node. In view of this, embodiments herein provide for determining an updated state of a subtree from an updated world state, MPT, for updating the subtree in a bandwidth-efficient, processor-efficient, and memory-efficient manner.

Fig. 6 depicts the exemplary world state MPT300 of fig. 3 including an update. In the example of fig. 6, MPT300 includes root node 302,

branch nodes

304, 306, extension node 308,

leaf nodes

310, 312, 314, and leaf node 318. In some examples, and as described above,

leaf nodes

310, 312, 314 correspond to respective accounts (account _1, account _2, account _3) within the blockchain network. The leaf node 318 corresponds to (e.g., after the world state MPT300 of fig. 3 is provisioned) a respective account (account _4) that is added to the blockchain network. The example table 320 records key-value pairs 322, 324, 326 corresponding to

leaf nodes

310, 312, 314, respectively, and key-value pair 328 corresponding to leaf node 318. Thus, updates to the world state MPT300 include the leaf node 318 and the corresponding key-value pair 328.

According to embodiments herein, and as described in detail herein, subtree 400 of fig. 4 may be updated based on a set of updates provided by a full-scale client for a lightweight client. For example, a lightweight client may submit a request for an updated subtree to the blockchain network. In response to the request, the full client may determine an update to sub-tree 400 based on a current state of a world state MPT300 (e.g., described in fig. 6) maintained by the full client. In some examples, the full-scale client generates a set of updates (e.g., as opposed to a new subtree) and sends the set of updates to the lightweight client. The lightweight client processes the set of updates to update sub-tree 400.

Fig. 7 depicts the subtree of fig. 4 including updates based on the exemplary world state MPT300 of fig. 6, according to embodiments herein. The exemplary sub-tree 400 of fig. 7 includes a root node 402,

branch nodes

404, 406, an extension node 408,

leaf nodes

410, 412 corresponding to the root node 302,

branch nodes

304, 306, extension node 308, and

leaf nodes

310, 312, respectively, of the world state MPT300 of fig. 3. The

leaf nodes

410, 412 correspond to respective clients (e.g., lightweight clients) that may access respective accounts (Account _1, Account _2) within the blockchain network. The exemplary sub-tree 400 also includes a table 420 that records key-value pairs. In the example of FIG. 7, the table 420 includes key-value pairs 422, 424, 426 corresponding to

leaf nodes

410, 412, 414, respectively.

As in fig. 4, the subtree 400 of fig. 7 does not have a leaf node corresponding to the leaf node 314 of the world state MPT300 of fig. 3 and 6 (e.g., a lightweight client does not have access to the account represented by the leaf node 314 (account _ 3)). And branch node 406 includes the placeholder character in item 10. Furthermore, the subtree 400 of fig. 7 does not have a leaf node corresponding to the leaf node 318 of the world state MPT300 of fig. 6 (e.g., a lightweight client does not have access to the account represented by the leaf node 318 (account _ 4)). And branch node 404 includes the placeholder character in item 16.

Fig. 8A and 8B depict examples of processes 800, 850 that may be performed according to embodiments herein. In some implementations, the example processes 800, 850 may be performed using one or more computer-executable programs executed using one or more computing devices. For example, the example process 800 may be performed by a full-scale client to generate a set of updates for a subtree of a lightweight client within a blockchain network, and the example process 850 may be performed by a lightweight client to update a locally maintained subtree.

With particular reference to fig. 8A, the example process 800 may be performed to provide a set of updates from the world state MPT T0 and the subtree T2 (e.g., the subtree T2' provided as an updated node). As described herein, the example process 800 performs a pair-wise node comparison between a node (current node) of the subtree T2 and a corresponding node (current node) of the world state MPT 0, and adds any different node of the world state MPT 0 to the update tree T2'.

The value of the root node of T0 and the value of the root node of T2 are determined (802) and compared (804). If the values are the same, the sub-tree T2 is in a consistent state with the MPT T0 and indicates as such (806). For example, a response may be sent from the full client to the lightweight client requesting the update indicating that subtree T2 is consistent with the world state. If the values are different, the world state MPTT0 has been updated since the subtree T2 was created. Thus, an update tree T2' is created with the root node of the MPT T0, the current node moving from the root node of the subtree T2 to the node whose value is referenced (808). That is, the value of a leaf node is a key of some data stored in a database (storing key-value pairs). Thus, the values of the leaf nodes reference real data in the database. For a non-leaf node, its value is the address of another node. That is, a non-leaf node points to (references) another node.

It is determined if it first reaches the current node in sub-tree T2 (810). If it is the first time to the current node in the sub-tree T2, the node corresponding to the address of the current node is looked up in the MPT 0 and a search path is provided (812). In some examples, the search path is a deep traversal within the MPT 0 to the corresponding node. It is determined whether there are any intermediate nodes in the search path (814). If there are one or more intermediate nodes in the search path, the intermediate nodes are added to the tree T2' and each intermediate node is labeled (marked) to indicate that they are nodes not included in the sub-tree T2 (816). In some examples, tags are provided as metadata for tagging nodes, as described herein.

A determination is made as to whether the current node in T2 is a leaf node 818. If the current node in T2 is a leaf node, a determination is made as to whether the current node in T0 is a leaf node (820). If the current node in T0 is a leaf node, the values of the current node of T2 and T0 are compared (822). If the values are different, then the current node in T0 is added to T2' (824). If the values are the same, then the current node in T2 moves to the parent node (826). In this way, the current node of T0 is added to the update tree T2' only if the current node of T0 is a different type of node from the current node of T2, or has a different value from the current node of T2. If the current node of T0 is of the same type as the current node of T2 and their values are the same, then the current node of T0 is not added to the update tree T2'. If the current node in T2 is not a leaf node, a determination is made as to whether the current node in T2 is an extension node (828). If the current node in T2 is an expansion node, then the current node in T0 is added to T2', the current node in T2 moves to the node pointed to by the slot (slot) (830), and the example process (800) returns to the loop.

If the current node in T2 is not an expansion node, then the current node in T2 and the current node in T0 are both branch nodes. It is determined whether to consider the current node in T2 for the first time (832). If it is the first time, it is determined whether the value of the current node of T2 is different from the value of the current node of T0 (834). If the values are different, the current node of T0 is added to the update tree T2' (824). If the values are the same, it is determined that the next slot in the current node in T2 that points to another node in T2, the current node of T2 moves to the node to which the slot points. That is, any slot that does not point to another node in T2 is not considered even if its value is not null because such a slot points to a node in T0 that is not in T2. Accordingly, the example process 800 provides a slot comparison, starting with the first slot, until a slot with a different value is encountered, the current node in T2 moves to the node pointed to by the slot (836), and the example process 800 returns to the loop.

If it is not the first time to the current node of T2 (832), a determination is made as to whether all slots between the current node of T2 and the current node of T0 have been compared (838). If all slots have been compared, the example process 800 returns to the loop to move to the parent node (826). If all slots are not compared, the remaining non-empty slots are iteratively compared to the slot of the current node of T0 until different values are encountered in the remaining slots (840). The current node of T0 moves to the node to which the slot points (842) and the example process 800 returns to the loop.

As exemplary process 800 recursively executes, and the current node of subtree T2 iteratively moves to the parent node (826), a determination is made as to whether the parent node is the root node (844). If the parent node is not the root node, the example process 800 returns to the loop to consider the (new) current node of the subtree T2 associated with the MPT T0. If the parent node is the root node, then update tree T2' (846) is returned. The update subtree consists of all the nodes of the subtree T2 updated according to the updated world state MPT T0. That is, the update tree T2' includes only those nodes of the sub-tree T2 that have been updated according to the updated MPT T0.

With particular reference to fig. 8B, an exemplary process 850 may be performed to update the subtree T2 at lightweight clients based on an update tree T2' provided from a full number of clients. That is, the full client need only send the update tree T2' to the lightweight client, rather than a newly created sub-tree. Since the update tree T2' includes only updated nodes, it is a smaller data structure than the sub-tree T2. Thus, by sending only the update tree T2', computational resources and bandwidth are saved (e.g., as opposed to sending an entirely new sub-tree T2 to a lightweight client). In some examples, upon receiving the update tree T2', the lightweight client performs the exemplary process 850 to locally update the subtree T2.

Starting from the root node of update tree T1, exemplary process 850 performs a depth-first traversal to consider each node (as the current node). It is determined whether the current node has been considered (852). If the current node has been considered, the next node is selected as the current node (854), and the example process returns to the loop. If the current node has not been considered, then a determination is made as to whether the current node has a label (marked) (856). If the current node does not have a tag, the node whose address is in the original sub-tree T2 is determined and the old node is replaced with the new node from the update tree T2' (858). If the current node has a tag (i.e., its address does not have a corresponding node in the original sub-tree T2), then the node is inserted into sub-tree T2 (860). After traversing all the nodes of the update tree T2', the sub-tree T2 is updated to reflect the relevant updates of the updated MPT T0.

Fig. 9 depicts an example of modules of an apparatus 900 according to embodiments herein. Apparatus 900 may be an example implementation of a block-link point of a sub-tree in a block-chain network, such as a federation block-chain network, configured to generate world-state MPTs. The apparatus 900 may correspond to the above embodiments, and the apparatus 900 may comprise the following: a generator or generation unit 902 for providing a world state MPT and an address list for storing addresses of nodes within the blockchain network; an executor or execution unit 904 for traversing the world state MPT; a creator or creating unit 906 for generating a sub-tree of the world state MPT; a transmitter or sending unit 908 for sending the subtree of the world state MPT to the non-co-aware clients of the blockchain network.

Fig. 10 depicts an example of modules of an apparatus 1000 according to embodiments herein. Apparatus 1000 may be an example implementation of a block-link point of a sub-tree in a block-link network, such as a federated block-link network, configured to update a world state MPT. The apparatus 1000 may correspond to the above embodiments, and the apparatus 1000 may comprise the following: a generator or generation unit 1002 for creating an update tree comprising a root node of the world state MPT and initially having no other nodes; an executor or execution unit 1004 for traversing at least a portion of the subtrees through a plurality of iterations; a transmitter or sending unit 1006, configured to send an update tree of the sub-tree to a non-consensus node of the blockchain network, the non-consensus client updating the locally stored sub-tree with the update tree to provide an updated sub-tree, the updated sub-tree providing a status of an account associated with the non-consensus client.

The system, apparatus, module or unit shown in the previous embodiments may be implemented by using a computer chip or entity, or may be implemented by using an article of manufacture having a specific function. A typical implementation device is a computer, which may be a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet, wearable device, or any combination of these devices.

For the implementation of the functions and roles of the individual units in the device, reference can be made to the implementation of the corresponding steps in the previous method. Details are omitted here for simplicity.

Since the device implementation substantially corresponds to the method implementation, reference can be made to the relevant description in the method implementation for the relevant parts. The previously described device implementations are merely examples. Elements described as separate parts may or may not be physically separate and parts shown as elements may or may not be physical elements, may be located in one position, or may be distributed over a plurality of network elements. Some or all of the modules may be selected based on actual needs to achieve the objectives of the solution of the present description. Those of ordinary skill in the art will understand and appreciate the embodiments of the present application without undue experimentation.

Referring again to fig. 9, it can be interpreted as showing the internal functional modules and structure of the subtree generating apparatus of the world state MPT. The sub-tree generating means of the world state MPT may be an example of a blockchain node configured to generate a sub-tree of the world state MPT within a blockchain network. Referring again to fig. 10, it can be interpreted as showing the internal functional modules and structure of the subtree updating apparatus of the world state MPT. The subtree updating apparatus of the world state MPT may be an example of a blockchain node configured to update a subtree of the world state MPT within a blockchain network. The execution subject may be essentially an electronic device and an electronic device including: one or more processors; and a memory storing executable instructions for the one or more processors.

Implementations of the described subject matter can include one or more features alone or in combination. For example, in a first embodiment, the actions may be performed as: providing a world state MPT and an address list for storing addresses of nodes within a blockchain network, the address list initially being empty; traversing at least a portion of the world state MPT over a plurality of iterations, and in each iteration, for a current node of at least a portion of the world state MPT, performing one of: marking the current node as an account node, storing the address of the current node in an address list, determining that the current node is an extended node, moving to the next iteration of traversal, setting the current node as a node referenced by the extended node in the next iteration, marking the current node as a transition node, and storing the address of the current node in the address list; creating a subtree of the world state MPT based on the address list, a root node of the subtree including a root node of the world state MPT, addresses of one or more child nodes of the subtree corresponding to the node of the world state MPT being stored in the address list; a sub-tree of the world state MPT is sent to a non-consensus client of the blockchain network, the sub-tree providing a state of an account associated with the non-consensus client.

Other embodiments described and illustrated above may each optionally include one or more of the following features:

in a first feature which may be combined with any of the following features, in response to determining that the current node is one of a leaf node and a branch node whose value is empty, marking the current node as an account node.

In a second feature which may be combined with any of the features below, in response to determining that the current node is a branch node and that all children of the branch node have been traversed, the current node is marked as a transition node.

In a third feature which may be combined with any of the following features, after marking the current node as an account node, the current node of the next iteration of the traversal comprises a parent node of the account node.

In a fourth feature which may be combined with any of the features below, after marking the current node as one of an account node and a transition node, the current node of the next iteration of the traversal comprises a child node of one of the account node and the transition node.

In a fifth feature that may be combined with any of the following features, creating a subtree of the world state MPT based on the address list comprises, at least in part: for addresses in the address list that are marked as account nodes, a path within the world state MPT is determined and added to the subtree.

In a sixth feature which may be combined with any of the features above, the traversal comprises a depth-first precedence traversal.

Implementations of the subject matter, acts, and operations described herein may be implemented in digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware, including the structures disclosed in this specification and their structural equivalents, or combinations of one or more of them. Implementations of the subject matter described herein may be implemented as one or more computer programs, e.g., one or more modules of computer program instructions, encoded on a computer program carrier for execution by, or to control the operation of, data processing apparatus. The carrier may be a tangible, non-transitory computer storage medium. Alternatively or additionally, the carrier may be an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be or be partially a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Computer storage media is not a propagated signal.

The term "data processing apparatus" includes all types of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The data processing apparatus may comprise special purpose logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application-specific integrated circuit), or a GPU (graphics processing unit). In addition to hardware, the apparatus can include code that creates an execution environment for the computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

A computer program can also be referred to or described as a program, software application, app, module, software module, engine, script, or code and can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages; it can be deployed in any form, including as a stand-alone program or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment, which may include one or more computers interconnected by a communications data network at one or more locations.

A computer program may, but need not, correspond to a file in a file system. The computer program may be stored in: a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document; a single file dedicated to the program in question; or multiple coordinated files, such as files that store one or more modules, sub programs, or portions of code.

The processes and logic flows described herein can be performed by one or more computers executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows can also be performed by, and in combination with, special purpose logic circuitry, e.g., an FPGA, an ASIC, a GPU, etc., and one or more programmed computers.

A computer suitable for executing a computer program may be based on a general and/or special purpose microprocessor, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or integrated in, special purpose logic circuitry.

Typically, a computer will also include, or be operatively coupled to receive data from or transfer data to, one or more mass storage devices. The mass storage device may be, for example, a magnetic, magneto-optical disk or an optical disk or a solid state drive. However, a computer need not have such devices. Moreover, a computer may be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a Universal Serial Bus (USB) flash drive, to name a few.

To provide for interaction with a user, embodiments of the subject matter described herein may be implemented on or configured to communicate with a computer having: a display device, e.g., an LCD (liquid crystal display) monitor, for displaying information to a user; and input devices through which a user may provide input to the computer, such as a keyboard and a pointing device, such as a mouse, trackball or touch pad. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and may receive any form of input from the user, including acoustic, speech, or tactile input. Further, the computer may interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending a web page to a web browser on the user device in response to a request received from the web browser, or by interacting with an application (app) running on the user device, such as a smartphone or electronic tablet. In addition, the computer may interact with the user by sending text messages or other forms of messages in turn to a personal device (e.g., a smartphone running a messaging application) and receiving response messages from the user.

The term "configured" is used herein in relation to systems, apparatuses, and computer program components. For a system of one or more computers configured to perform particular operations or actions, it is meant that the system has installed thereon software, firmware, hardware, or a combination thereof that, when executed, causes the system to perform the operations or actions. For one or more computer programs configured to perform specific operations or actions, it is meant that the one or more programs include instructions, which when executed by a data processing apparatus, cause the apparatus to perform the operations or actions. By dedicated logic circuitry configured to perform a particular operation or action is meant that the circuitry has electronic logic to perform the operation or action.

While this document contains many specific implementation details, these should not be construed as limitations on the scope of what is claimed, as defined by the claims themselves, but rather as descriptions of specific features of particular embodiments. Particular features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings and recited in the claims in a particular order, this should not be understood as: it may be desirable to perform the operations in the particular order shown, or in sequence, or to perform all of the operations shown, in order to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the division of the various system modules and components in the embodiments described above should not be understood as requiring such division in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Particular embodiments of the subject matter have been described. Other implementations are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not require the particular order shown, or sequence, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.

Claims

1. A computer-implemented method for providing a sub-tree of a world state mercker patricia dictionary tree, MPT, within a blockchain network, the method comprising:

providing, by a consensus client of the blockchain network, a world state MPT and an address list for storing addresses of nodes within the blockchain network, the address list initially being empty;

the consensus client traverses at least a portion of the world state MPT over a plurality of iterations, and in each iteration, for a current node of the at least a portion of the world state MPT, performs one of:

marking the current node as an account node and storing the address of the current node in the address list,

determining that the current node is an extension node and moving to a next iteration of the traversal that sets the current node as the node referenced by the extension node,

marking the current node as a transition node, and storing the address of the current node in the address list;

the consensus client creating a sub-tree of the world state MPT based on the address list, a root node of the sub-tree comprising a root node of the world state MPT, addresses of one or more sub-nodes of the sub-tree corresponding to nodes of the world state MPT being stored in the address list;

the consensus client sends the sub-tree of the world state MPT to a non-consensus client of the blockchain network, the sub-tree providing a state of an account associated with the non-consensus client.

2. The method of claim 1, wherein the current node is marked as an account node in response to determining that the current node is one of a leaf node and a branch node that does not have a null value.

3. The method of claim 1, wherein the current node is marked as a transition node in response to determining that the current node is a branch node and that all children of the branch node have been traversed.

4. The method of claim 1, wherein, after marking the current node as an account node, the current node of the next iteration of the traversal comprises a parent node of the account node.

5. The method of claim 1, wherein, after marking the current node as one of an account node and a transition node, the current node of the next iteration of the traversal comprises a child node of the one of the account node and the transition node.

6. The method of claim 1, wherein creating a sub-tree of the world state MPT based on the address list comprises, at least in part: determining a path within the world state MPT for an address in the address list marked as an account node, and adding the path to the sub-tree.

7. The method of claim 1, wherein the traversal comprises a depth-first-precedence traversal.

8. A non-transitory computer-readable storage medium coupled to one or more computers and having instructions stored thereon that are executable to provide a sub-tree of a world state mercker patricia dictionary tree, MPT, within a blockchain network, the instructions being executable by the one or more computers to:

9. The computer-readable storage medium of claim 8, wherein the current node is marked as an account node in response to determining that the current node is one of a leaf node and a branch node that does not have a null value.

10. The computer-readable storage medium of claim 8, wherein the current node is marked as a transition node in response to determining that the current node is a branch node and that all children of the branch node have been traversed.

11. The computer-readable storage medium of claim 8, wherein, after marking the current node as an account node, the current node of the next iteration of the traversal comprises a parent node of the account node.

12. The computer-readable storage medium of claim 8, wherein, after marking the current node as one of an account node and a transition node, the current node of the next iteration of the traversal comprises a child node of the one of the account node and the transition node.

13. The computer-readable storage medium of claim 8, wherein creating a sub-tree of the world state MPT based on the address list comprises, at least in part: determining a path within the world state MPT for an address in the address list marked as an account node, and adding the path to the sub-tree.

14. The computer-readable storage medium of claim 8, wherein the traversal comprises a depth-first-precedence traversal.

15. A system, comprising:

one or more computers; and

one or more computer-readable memories coupled to the one or more computers and storing instructions executable to provide a sub-tree of a world state merkel patricia dictionary tree MPT within a blockchain network, the instructions executable by the one or more computers to:

16. The system of claim 15, wherein the current node is marked as an account node in response to determining that the current node is one of a leaf node and a branch node that does not have a null value.

17. The system of claim 15, wherein the current node is marked as a transition node in response to determining that the current node is a branch node and that all children of the branch node have been traversed.

18. The system of claim 15, wherein, after marking the current node as an account node, the current node of the next iteration of the traversal comprises a parent node of the account node.

19. The system of claim 15, wherein, after marking the current node as one of an account node and a transition node, the current node of the next iteration of the traversal comprises a child node of the one of the account node and the transition node.

20. The system of claim 15, wherein creating a sub-tree of the world state MPT based on the address list comprises, at least in part: determining a path within the world state MPT for an address in the address list marked as an account node, and adding the path to the sub-tree.

21. The system of claim 15, wherein the traversal comprises a depth-first-precedence traversal.