Maintenance of blockchain blocks in a partitioned blockchain network

Abstract

To provide a computer-implemented method and system to maintain blocks of a blockchain across nodes of a sharded blockchain network.SOLUTION: Each node is a member of one or more shards of a plurality of active shards. The method and system employ a given node that is a member of a particular subset of the plurality of active shards to generate data representing a new block of the blockchain and store the data representing the new block. Such data includes i) a list of transaction identifiers for transactions that are part of the new block and associated with the particular subset of the plurality of active shards, and / or ii) a partial Merkle tree for the new block.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present disclosure relates generally to computer-implemented systems and methods for processing blockchain transactions, and more particularly to systems and methods for partitioning a blockchain and validating transactions and blocks of the partitioned blockchain. [Background technology]

[0002] In this document, the term "blockchain" refers to any of several forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, private (permissioned) and public (un-permissioned) ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Although reference may be made to the Bitcoin example herein for convenience and illustrative purposes of this disclosure, it should be noted that this disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are also within the scope of this disclosure. For example, this disclosure may be useful in other blockchain implementations that have similar restrictions as Bitcoin regarding what constraints can be encoded in transactions.

[0003] A blockchain is a peer-to-peer electronic ledger that is created and maintained by a computer-based decentralized system. The ledger is composed of blocks, which in turn are composed of transactions and other information. A blockchain system or network includes a plurality of blockchain nodes and a set of operations. A blockchain node may be configured to perform some or all of the operations in the set of operations. Various blockchain nodes may be implemented as computer hardware, computer software, or a combination of both operated by node operators, which may be independent and unrelated to other node operators. The blockchain nodes may each maintain a copy of the blockchain ledger or some portion thereof. The set of operations may include creating transactions, propagating transactions, reading the blockchain ledger, evaluating the blockchain ledger, generating new blocks for proposed additions to the blockchain ledger (mining), communicating with other blockchain nodes, and providing wallet functionality for users to create transactions and manage blockchain assets.

[0004] A blockchain ledger is decentralized in that there is no single blockchain node or entity that determines when the ledger is modified. Instead, each of the blockchain nodes is programmed to know the rules of the blockchain protocol in order to validate the blockchain ledger and verify that actions taken by other blockchain nodes are consistent with the rules. The term "blockchain" may refer to the fact that a blockchain ledger includes a series of linked blocks, each of which can be represented as a data structure in computer memory, readable by a computer process, and transmittable as a data transmission. A block includes one or more transactions, which can also be represented as a data structure in computer memory, readable by a computer process, and transmittable as a data transmission. The blocks are linked in that each new block that is officially added to the blockchain includes an immutable reference to the previous block, which in turn includes an immutable reference to the block before it, and so on.

[0005] For a given transaction to be included in a block written to the blockchain, one or more nodes approve the given transaction and possibly propagate the transaction to other nodes, the nodes mine a block of transactions where the block contains the given transaction, and other nodes verify the validity of the block and the transactions within it. Since mining nodes are programmed or configured with awareness of these rules, they are unlikely to include transactions in a block that would invalidate the block, because such a block would not be accepted by other nodes and the mining node would not obtain any profit. For example, in many blockchain networks, blocks can include "reward" transactions, where a specified amount of value is assigned to the mining node operator. In this way, successful miners are compensated with the value created by the block. Additionally, transactions can include transaction fees, which are also profitable for the mining node operator.

[0006] Transactions in a blockchain network include various data elements, including units of value and other data elements. The units of value can be cryptocurrencies (such as Bitcoin SV), but other variations using other digital assets are possible. In a decentralized distributed ledger system, the ledger can be public, so that anyone can view it and access the transactions stored in the blocks of the ledger.

[0007] Blockchain networks, for example the Bitcoin blockchain network, can suffer from performance limitations on transaction approval caused by delays in the network propagation of transactions, since each transaction needs to be approved before it can be propagated to other nodes for mining. Furthermore, as the size of the blockchain grows, the storage requirements of the nodes that approve transactions and blocks grow as well. Summary of the Invention

[0008] It would therefore be desirable to provide improved systems and methods for improving the scalability of blockchain ledgers through the use of partitioning or sharding.

[0009] Dividing a blockchain network into shards allows users to choose their level of involvement with the blockchain network. Each user can choose to be a member of one or more shards. A user who is a member of fewer than all shards requires less storage space to store all of the transactions assigned to the shards of which he is a member. Assigning transactions to shards based on transaction ID provides the advantage that the resulting shards will be approximately equal in size, thereby avoiding overburdening members of larger shards relative to members of smaller shards, while at the same time allowing transactions and associated validations to be executed accurately without undue delay.

[0010] A user as referred to herein may be associated with one or more nodes or computing devices, which may also be referred to as client entities in the partitioned blockchain network. Hereinafter, references to a user may also be understood to be references to a node or entity (which may own or control a shard or a node or entity that is part of the partitioned blockchain network) associated with the user. Each node may be communicatively coupled to at least one or more other nodes in the partitioned blockchain network.

[0011] These advantages described herein in this regard, along with other aspects of the disclosure (discussed below), result from the structure of the nodes and the resulting network topology and architecture of a sharded blockchain network and protocols associated with the nodes of the network. Receiving, storing and / or acknowledging UTXOs in such a sharded network is performed using the methods, rules and protocols described and claimed herein for communication, data storage, data sharing, along with acknowledgement techniques for nodes within each shard based on rules and protocols associated with communication with nodes belonging to different shards.

[0012] These particular structures, methods of data flow, transaction allocation and approval protocols are further described below with respect to various embodiments of the present disclosure. Advantageously, the sharded network structure or architecture and associated methods described herein for allocation of transactions in a sharded blockchain network and approval of such allocated transactions enable novel techniques for data flow, data storage and UTXO approval checks. Moreover, these techniques, in terms of the structure and data communication / approval protocols, advantageously prevent double-spend attacks, such as Sybil attacks, in the Bitcoin blockchain.

[0013] Thus, according to the present disclosure, a computer-implemented method and system may be provided for maintaining blocks of a blockchain among nodes of a sharded blockchain network, each node being a member of one or more of a plurality of active shards. The method and system may employ a given node that is a member of a particular subset of the plurality of active shards, the given node being configured to generate data representative of a new block of the blockchain and to store the data representative of the new block. Such data may include i) a list of transaction identifiers of transactions that are part of the new block and that are associated with the particular subset of the plurality of active shards, and / or ii) a partial Merkle Tree of the new block. The list of transaction identifiers in i) does not include transaction identifiers of transactions that are part of the new block and that are not associated with the particular subset of the plurality of active shards.

[0014] In an embodiment, the list of transaction identifiers in i) may be generated by constructing an initial list of transaction identifiers for the new block based on data included in the new block, and processing the initial list of transaction identifiers by removing any transaction identifiers that correspond to transactions that are not associated with a particular subset of the multiple active shards.

[0015] In an embodiment, the partial Merkle tree in ii) includes hash values ​​derived from transactions that are part of the new block and that are not associated with the particular subset of the active shards, while omitting hash values ​​derived from transactions that are part of the new block and that are associated with the particular subset of the active shards.

[0016] In an embodiment, the partial Merkle tree of ii) may be generated by building a full Merkle tree for the new block based on the data contained in the new block, and substituting hash values ​​derived from transactions that are part of the new block and that are associated with a particular subset of the active shards with placeholders.

[0017] In an embodiment, processing the entire Merkle tree may further include iterating through the entire Merkle tree from the lowest level to the root level, removing the two hash values ​​for adjacent node pairs, and retaining the parent hash value.

[0018] In embodiments, processing the entire Merkle tree may further include iterating through the entire Merkle tree from the lowest level to the root level and replacing with a placeholder the hash value of a parent tree node that has two child nodes that together do not represent a hash value derived from transactions that are not related to the particular subset of the multiple active shards.

[0019] In embodiments, a node is operable to process a partial Merkle tree to calculate a Merkle root hash value for block approval without requiring access to transactions that are part of the block and that are not related to a particular subset of the multiple active shards.

[0020] In an embodiment, processing the partial Merkle tree to compute the Merkle root hash value may include iterating from the lowest level of the partial Merkle tree to the root level, replacing any placeholders at the lowest level with corresponding hash values ​​from the transaction identifier list in i), and replacing any placeholders at levels above the lowest level with hash values ​​computed from corresponding child hash values ​​of the partial Merkle tree.

[0021] In an embodiment, the list of transaction identifiers in i) and the partial Merkle tree in ii) can vary among nodes based on node membership and allocation of transactions among shards.

[0022] In embodiments, transactions that are part of a new block may be associated with (or assigned to) a shard among multiple active shards based on a transaction identifier.

[0023] In other embodiments, transactions that are part of a new block may be associated (or assigned) to a shard among multiple active shards based on a parent blockchain transaction, where the parent transaction is defined by outputs that correspond to inputs of a child blockchain transaction, and both the parent transaction and the child transaction are associated with the same shard.

[0024] In embodiments, block data maintained by a node may omit transaction data that is part of a shard to which the node does not belong, thus saving node storage space. Thus, some nodes may store blockchain data structures for only a limited subset of the blockchain's transactions, while other nodes may store data structures for all of the blockchain's transactions. In this case, the data storage capacity of a node that stores data structures for a limited subset of the blockchain may be much smaller than the data storage capacity of a node that stores data structures for the entire blockchain.

[0025] In an embodiment, when generating data representing a new block, a node may approve transactions that are part of the new block and that are associated with a particular subset of the active shards, while bypassing approval of transactions that are part of the new block and that are not associated with the particular subset of the active shards. Such a process may reduce the computational effort of a block approval operation. This advantage, together with reduced data storage requirements for a particular shard of the blockchain network, may enable nodes with limited computational resources to effectively participate in the blockchain network.

[0026] Thus, in accordance with the present disclosure, there is provided a method as defined in the accompanying claims.

[0027] According to the present disclosure, there may be provided an electronic device including a processor, a computer memory, and a network interface device, the memory storing computer-executable instructions that, when executed, configure the processor to perform the methods described herein.

[0028] According to the present disclosure, a non-transitory computer readable storage medium may be provided that includes computer executable instructions that, when executed, configure a processor to perform the methods described herein. [Brief description of the drawings]

[0029] These and other aspects of the present disclosure will be apparent from and will be elucidated with reference to the embodiments described hereinafter, which are described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1A] 1 illustrates a blockchain network in which various embodiments may be implemented. [Figure 1B] 1A illustrates a blockchain ledger and representative blocks that may be maintained by the blockchain network of FIG. 1A and in which various embodiments may be implemented. [Diagram 2] 1 illustrates nodes of an exemplary sharded blockchain network, along with the data structure of a sharded blockchain ledger maintained by such nodes. [Figure 3A] FIG. 3 is a flowchart illustrating the creation, validation, and mining of blockchain transactions as part of a sharded blockchain ledger, such as the sharded blockchain ledger of FIG. [Figure 3B] FIG. 3 is a flowchart illustrating the creation, validation, and mining of blockchain transactions as part of a sharded blockchain ledger, such as the sharded blockchain ledger of FIG. [Figure 4A] 13 is a flowchart describing the operations performed by a node that is not a member of all shards when approving a new block produced by a miner. [Figure 4B] 13 is a flowchart describing the operations performed by a node that is not a member of all shards when approving a new block produced by a miner. [Diagram 5] 13 is a flowchart describing operations performed by a node that is not a member of all shards when building a partial Merkle tree for a new block. [Figure 6A] FIG. 6 is a schematic diagram of the operation of FIG. 5. [Figure 6B] FIG. 6 is a schematic diagram of the operation of FIG. 5. [Figure 6C] FIG. 6 is a schematic diagram of the operation of FIG. 5. [Figure 6D] FIG. 6 is a schematic diagram of the operation of FIG. 5. [Figure 7A] 11 is a flowchart describing operations performed by a node that is not a member of all shards when validating block data maintained by the node, such operations processing a partial Merkle tree of the block to compute a Merkle root hash value for the partial Merkle tree. [Figure 7B]11 is a flowchart describing operations performed by a node that is not a member of all shards when validating block data maintained by the node, such operations processing a partial Merkle tree of the block to compute a Merkle root hash value for the partial Merkle tree. [Figure 7C] 11 is a flowchart describing operations performed by a node that is not a member of all shards when validating block data maintained by the node, such operations processing a partial Merkle tree of the block to compute a Merkle root hash value for the partial Merkle tree. [Figure 7D] 11 is a flowchart describing operations performed by a node that is not a member of all shards when validating block data maintained by the node, such operations processing a partial Merkle tree of the block to compute a Merkle root hash value for the partial Merkle tree. [Figure 8A] FIG. 8 is a schematic diagram of the operation of FIGS. 7A to 7D. [Figure 8B] FIG. 8 is a schematic diagram of the operation of FIGS. 7A to 7D. [Figure 8C] FIG. 8 is a schematic diagram of the operation of FIGS. 7A to 7D. [Figure 8D] FIG. 8 is a schematic diagram of the operation of FIGS. 7A to 7D. [Figure 9] 1 illustrates a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] Reference is first made to FIG. 1A, which illustrates an example blockchain network 100 associated with a blockchain according to an embodiment of the present disclosure. In an embodiment, the blockchain network 100 includes blockchain nodes, which may be implemented as peer-to-peer distributed electronic devices each executing instances of software and / or hardware that perform operations according to a blockchain protocol agreed upon in whole or in part among operators of the blockchain nodes. In some examples, these distributed electronic devices are referred to simply as "nodes," such as node 102 in FIG. 1A. An example of a blockchain protocol is the Bitcoin protocol.

[0031] Nodes 102 may include any suitable computing device (e.g., a server in a data center, a client computing device such as a desktop computer, a laptop computer, a tablet computer, a smart phone, etc.), multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device such as computing device 2600 of FIG. 9. Nodes 102 may have inputs for receiving data messages or objects representing transactions and / or blocks along with information about other nodes. Nodes 102 may be able to query information they maintain, such as, for example, an understanding of the state of a transaction.

[0032] As shown in FIG. 1A, some nodes 102 are communicatively coupled to one or more other of the nodes 102. Details regarding which nodes 102 can communicate with which other nodes need not be determined centrally. Given that the blockchain protocol is message forwarding, it may be sufficient that active nodes in the blockchain network 100 can communicate with one or more other nodes 102 such that messages passed from one node 102 to other nodes 102 can propagate through the blockchain network 100 (or a substantial portion thereof). One such message is the publication of a proposed transaction by one of the nodes 102A, which then propagates along a path such as path 106. Another such message may be the publication of a proposed new block for inclusion in the blockchain.

[0033] The nodes 102 may store a distributed blockchain ledger (or blockchain) that includes data corresponding to transactions and data corresponding to blocks of transactions. The nodes 102 may store a complete copy of the blockchain ledger or a portion of it. For example, some nodes may store the data of the entire blockchain ledger, while other nodes may store data of only unspent transactions, while other nodes may maintain the entire blockchain ledger. The nodes 102 may include functionality to approve each block received and the transactions within such blocks. Some of the nodes 102 may be miner nodes that collect transactions and create blocks of transactions so that new blocks can be added to the blockchain ledger. Miner nodes may be expected to perform some operations that are complex (to prevent a rogue node from easily creating an inappropriate block) and dependent on the data of the transactions included (so that a rogue node cannot perform complex operations in advance), and the execution of these operations is easily verified by other nodes. In some cases, multiple miner nodes may compete to perform the operations required in creating a new block. This is called "proof-of-work" mining. Alternatively, the miner node of a new block can be selected in a deterministic way depending on its wealth, also defined as stake. This is called "proof-of-stake" mining or forging. The miner node propagates the new block to other nodes for approval. The other nodes approve the new block and the transactions embedded in the new block. If the approval operation performed by the node is successful, the node adds the new block to the blockchain and propagates the new block to other nodes. This commits the new block to the blockchain ledger.

[0034] In some examples, a block is a grouping of transactions, often marked with a timestamp and a “fingerprint” (e.g., a hash) of the previous block. In this way, each block is linked to the previous block, thereby creating a “chain” that links the blocks in the blockchain ledger. Each block includes data (e.g., transaction identifiers) that indicate the group of transactions of that block. In embodiments, valid blocks are added to the blockchain ledger by consensus of nodes in the blockchain network. Also, in some examples, the blockchain ledger includes an ordered list of approved blocks. FIG. 1B shows a blockchain ledger 1216 with a chain of three blocks 1221, 1223, and 1223. Note that block 1222 includes data (e.g., block header 1230 and transaction identifiers 1231(1), 1231(2), 1231(3)...) that indicate the group of transactions for block 1222.

[0035] The present disclosure aims to improve the scalability of blockchain ledgers through the use of partitioning. Partitioning in the art considers two specific dimensions: horizontal and vertical. In horizontal partitioning, data is partitioned into different sections known as shards, which are effectively multiple instances of a particular database schema, and data is spread among each of these instances (discounting the redundancy of the instances). In vertical partitioning, a given database schema is distributed among multiple nodes, whereby attributes of a particular object are distributed using normalization.

[0036] The present disclosure uses a horizontal partitioning scheme for the data structure of the blockchain ledger among groups of related nodes called "shards." Each shard is assigned a unique identifier. There is one group called "All Shards" that encompasses all shards. Each node in the blockchain network can belong to one or more shards (including the "All Shards" group). Nodes that belong to a shard may be called members of that shard. In the example of FIG. 2, nodes A1 and A2 are members of shard A, nodes B1 and B2 are members of shard B, node C is a member of shards A and B, and node D is a member of the "All Shards" group. Other shards can be used as well. Furthermore, each node is configured to store a data structure of the blockchain ledger corresponding to one or more shards to which it belongs. In the example of Figure 2, the blockchain ledger data structures include Bitcoin-related data structures for the shard, including a UTXO set for the shard, a transaction queue (mempool) for the shard, transaction data for the shard (labeled TX data), and block data for the shard. The UTXO set for the shard represents unspent transaction outputs (UTXOs) that can be used as inputs to new transactions.

[0037] In the embodiments described herein, block data maintained by a given node includes block data for one or more shards to which the given node belongs. Such block data includes data representing blocks of a blockchain ledger and may include the following data for each block: i) a block header including a partial Merkle tree along with other data of the block, and / or ii) a list of transaction identifiers of transactions that are part of the block. The list includes transaction identifiers only of transactions that are part of the block and related to one or more shards to which the given node belongs, and does not include transaction identifiers of transactions that are part of the block and are not related to one or more shards to which the given node belongs. The partial Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and related to one or more shards to which the given node does not belong, while omitting hash values ​​derived from transactions that are part of the block and related to one or more shards to which the given node belongs. The partial Merkle tree may be used to allow a node to calculate a Merkle root hash value of a block for block validation without needing access to transactions that are part of the block and are not related to one or more shards to which the node belongs. In this manner, the partial Merkle trees of i) and the lists of ii) for a given block stored as part of the block data by nodes of different shards can vary among nodes based on the membership of the nodes and the distribution of transactions among the shards. Advantageously, the use of partial Merkle trees in conjunction with the block header and other data of a block as described in this embodiment is made possible in view of the structure of a sharded blockchain network together with the protocols described herein for establishing what information each node may or may not store in order to still accurately retain and use the details necessary for a block to be approved and propagated without each node having to store and approve all UTXOs associated with a given transaction.As described further herein, the creation and use of partial Merkle trees to process block information is enabled by this structure of a sharded network and protocols applied by nodes in the sharded network for communication and data flow within the same shard, in addition to other protocols for communication and data flow with one or more nodes outside the shard with which the node is associated.

[0038] In the example of FIG. 2, nodes A1 and A2 store a copy of the UTXO set for shard A, a copy of the transaction queue (memory pool) for shard A, a copy of the transaction data for shard A, and a copy of the block data for shard A. Nodes A1 and A2 do not store the following: copies of the UTXO set for other shards (other than shard A), copies of the transaction queue (memory pool) for other shards (other than shard A), and copies of the transaction data for other shards (other than shard A). Furthermore, the block data for shard A includes data representing blocks of the blockchain ledger, and for each block may include the following data: i) a block header that includes a partial Merkle tree along with other data for the block, and ii) a list of transaction identifiers for transactions that are part of the block. This list includes transaction identifiers only for transactions that are part of the block and that are related to shard A, and this list does not include transaction identifiers for transactions that are part of the block and that are not related to shard A. The partial Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and that are not associated with shard A, while omitting hash values ​​derived from transactions that are part of the block and that are associated with shard A.

[0039] Nodes B1 and B2 store a copy of the UTXO set for shard B, a copy of the transaction queue (memory pool) for shard B, a copy of the transaction data for shard B, and a copy of the block data for shard B. Nodes B1 and B2 do not store the following: copies of the UTXO set for other shards (other than shard B), copies of the transaction queue (memory pool) for other shards (other than shard B), copies of the transaction data for other shards (other than shard B). Furthermore, the block data for shard B includes data representing blocks of the blockchain ledger and may include the following data for each block: i) a block header including a partial Merkle tree along with other data for the block, and ii) a list of transaction identifiers for transactions that are part of the block. This list includes transaction identifiers only for transactions that are part of the block and that are relevant to shard B; this list does not include transaction identifiers for transactions that are part of the block and that are not relevant to shard B. The partial Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and that do not involve shard B, while omitting hash values ​​derived from transactions that are part of the block and that are involved in shard B.

[0040] Node C stores a copy of the UTXO set for shard A, a UTXO set for shard B, a copy of the transaction queue (memory pool) for shard A, a copy of the transaction queue (memory pool) for shard B, a copy of the transaction data for shard A, a copy of the transaction data for shard B, and copies of the data blocks for shards A and B. Node C does not store the following: copies of the UTXO set for other shards (other than shards A and B), copies of the transaction queue (memory pool) for other shards (other than shards A and B), and copies of the transaction data for other shards (other than shards A and B). Additionally, the block data for shards A and B includes data representing blocks of the blockchain ledger and may include the following data for each block: i) a block header that includes a partial Merkle tree along with other data for the block, and ii) a list of transaction identifiers for transactions that are part of the block. This list includes transaction identifiers only for transactions that are part of the block and that are associated with shards A or B; this list does not include transaction identifiers for transactions that are part of the block and that are not associated with shards A or B. The partial Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and that are not associated with shards A or B, while omitting hash values ​​derived from transactions that are part of the block and that are associated with shards A or B.

[0041] Node D stores copies of the UTXO sets for all shards, copies of the transaction queues (memory pools) for all shards, copies of transaction data for all shards, and copies of block data for all shards.

[0042] Note that block data maintained by a node may omit transaction data that is part of a shard to which the node does not belong, thus saving storage space for the node. Thus, some nodes (e.g., nodes A1, A2, B1, B2, and C) store data structures of the blockchain ledger for only a limited subset of the transactions of the blockchain ledger, while other nodes (e.g., node D) store data structures for all of the transactions of the blockchain ledger. In this case, the data storage capacity of the nodes (e.g., nodes A1, A2, B1, B2, and C) that store data structures for a limited subset of the blockchain may be much smaller than the data storage capacity of the node (e.g., node D) that stores data structures for the entire blockchain ledger. Note that other data structures for different shards may be stored and maintained in other blockchain ledgers.

[0043] The horizontal partitioning scheme of Figure 2 allows node operators to decide or choose to become members of one or more shards of a blockchain network. This allows smaller parties with limited data storage capacity (such as hobbyists) to choose to become members of a single shard, while larger parties with greater data storage capacity (such as financial institutions) can decide or choose to become members of all shards.

[0044] Additionally, each node can be configured to perform block approval operations that approve only transactions related to one or more shards to which the node belongs. In such operations, approval of any transactions related to other shards to which the node does not belong is bypassed and does not affect whether a block is considered valid by the node. In this case, an operator who chooses to be a member of a single shard has a lighter security commitment by approving a limited set of transactions in the blockchain ledger, while an operator who chooses to be a member of all shares has a greater security commitment by approving all transactions in the blockchain ledger.

[0045] Note that nodes can be configured to communicate with multiple other nodes within a single shard to prevent Sybil attacks. These attacks can effectively ignore transactions sent from a node, preventing their propagation further through the network. One or more nodes in a given shard can also be assigned to exchange information about nodes in other shards, and such assignments can rotate over time among the nodes in a given shard. Each node can broadcast all transactions it receives to other nodes with which it is joined, and if the given node is not a member of that shard, it performs basic transaction-level checks before propagating the transaction instead of performing a full transaction approval.

[0046] Details about other nodes at different or specific times / instances can also be shared between nodes in a particular shard. This is done using a modified version of the addr protocol message according to the second embodiment of the present disclosure. The implementation of the addr message currently existing as part of the Bitcoin protocol is used to enumerate or identify one or more IP addresses and ports. For example, a getaddr request may be used to obtain an addr message containing a bunch of known active peers (e.g., for bootstrapping). The addr message often contains only one address, but in some cases contains more, in some examples up to 1000. In some examples, all nodes periodically, i.e., every 24 hours, broadcast an addr containing their IP address. Nodes may then relay these messages to their peers and can remember the relayed address if it is new. In this way, nodes in the network may have a reasonably clear idea of ​​which IPs are connected to the network at the time of joining the network or thereafter. In most cases, the IP address is added to everyone's address database because of the initial addr broadcast.

[0047] In addition to the above, implementations of the modified addr protocol according to the present disclosure can transmit further information regarding which shards a particular node belongs to. For example, in the modified addr protocol, when a node in a sharded network such as that of FIG. 1b joins a particular shard in the network, what is broadcast as part of the addr message may also include a field identifying the one or more shards of which it is a member. This information is therefore also returned in response to getaddr requests from peers in the network of FIG. 1b. As described in the first embodiment, such information may be based on data structures associated with each node and / or each shard with which the node is associated.

[0048] 3A and 3B, taken together, are a flowchart illustrating the creation, validation, and mining of blockchain transactions as part of a sharded blockchain ledger, such as the sharded blockchain ledger of FIG. 2.

[0049] In box 301, a client node generates a blockchain transaction, which is associated with (or allocated or assigned to) one or more shards of a blockchain network. A shard associated with a valid blockchain transaction may be a shard associated with the blockchain transaction itself, or a shard associated with one or more transaction inputs or transaction outputs of the valid blockchain transaction. For example, in one embodiment, a shard associated with a valid blockchain transaction may be based on a transaction identifier of the blockchain transaction, which is created by applying a SHA256 function to the transaction data of the blockchain transaction. More specifically, a shard associated with a valid blockchain transaction may be determined by applying a modulo of the number of shards currently active on the blockchain network to the transaction identifier, i.e., shard identifier = TX ID mod n, where n is the number of currently active shards. In other embodiments, a shard associated with a valid blockchain transaction may be based on the first input or other inputs of the blockchain transaction and the output of a previous transaction that the input references. In this context, a transaction whose output is referenced by a first input of a subsequent transaction is referred to as a "parent" transaction, and the subsequent transaction is referred to as a "child" transaction. It should be noted that the use of the first input to define a parent is not required for the method, and if there are multiple inputs, any input may be selected to execute the method. For example, a previous transaction may be defined as a parent of a child transaction if a certain number of inputs of the child transaction reference outputs of transactions in the same shard as the parent. The number of inputs may be defined as a majority of the inputs of the child transaction.Further details of these mechanisms are described in UK Patent Application No. 1806907.0 and UK Patent Application No. 1806909.6, which are commonly assigned to the assignee of the present application and are incorporated by reference in their entirety. In yet other embodiments, other mechanisms can be used to associate a blockchain transaction with one or more shards of a blockchain network.

[0050] In box 303, the client node broadcasts the blockchain transaction for communication to nodes belonging to one or more shards related to the blockchain transaction (and possibly other nodes belonging to shards not related to the blockchain transaction).

[0051] In box 305, nodes belonging to one or more shards associated with the blockchain transaction receive the blockchain transaction.

[0052] In box 307, nodes belonging to one or more shards associated with the blockchain transaction approve the received blockchain transaction or portions thereof, and each such node propagates the blockchain transaction to other nodes in the shard to which it belongs if the received blockchain transaction or portions thereof are deemed valid.

[0053] In one embodiment (called "transaction shard approval"), transaction approval in box 307 is performed by the shard to which the transaction is associated or assigned. As described above, a transaction can be associated (or assigned) to a shard using the result of a modulo function applied to the transaction's transaction identifier. Since a transaction can have inputs from different shards, a node can communicate with nodes in other shards for UTXO checks. Specifically, a node belonging to one or more shards can make a request to a node belonging to another shard to obtain the UTXO set for the other shard. If no node has the requested UTXO set, a null response is given and the transaction in question is considered invalid. If the transaction input is considered valid, the transaction is added to the transaction queue (memory pool) for the shard to which the transaction is associated or assigned (box 309), and the transaction is propagated to other nodes in this shard (box 311).

[0054] In another embodiment (called "UTXO shard-based approval"), the transaction approval in box 307 approves the transaction based on inputs associated with UTXO sets in the same shard as the node performing the approval. Inputs associated with UTXO sets in different shards are not approved. Approval of each input may include checking that the UTXO of the referenced output has not been spent, verifying that the input is authorized to collect the value of the referenced output (e.g., script validation), and many other checks. If the input is invalid (e.g., if there is no UTXO associated with the input, if the value of the transaction's output is greater than the UTXO of the corresponding input, or if a script error exists), the transaction is discarded and is not propagated to other nodes in the same shard. If the input is deemed valid, the transaction is added to the shard's transaction queue (memory pool) for the node performing the approval (box 309), and the transaction is propagated to other nodes in this shard (box 311).

[0055] Further details of the "transaction shard validation" and "UTXO shard based validation" embodiments are described in UK Patent Application No. 1806911.2 and UK Patent Application No. 1806914.6, which are commonly assigned to the assignee of the present application, and are incorporated by reference in their entireties.

[0056] In an embodiment, validation of the transaction in box 307 may also include checks related to the transaction as a whole, such as checking that the transaction syntax and data structures are correct, that the transaction is smaller than the allowed block size and greater than or equal to 100 bytes, and that the locktime is smaller than the maximum allowed.

[0057] In box 309, a node belonging to the shard associated with the valid blockchain transaction adds the valid blockchain transaction to a transaction queue (memory pool) for the shard associated with the valid blockchain transaction.

[0058] In box 311, one or more nodes (e.g., miners) form a block from the transaction queue (memory pool) for a shard (e.g., the memory pool for the “all shards” group) and propagate this new block to other nodes.

[0059] In box 313, the node receives the new block and processes the new block for block approval and commitment according to a consensus protocol.

[0060] Figures 4A and 4B taken together are a flow chart illustrating the operation of box 313 of Figures 3A and 3B in approving a new block generated by a miner of a node that is not a member of all shards. In this case, the node belongs to a limited subset of the active shards and therefore does not belong to one or more active shards. Note that any node that is a member of all shards can approve the new block using the well-known block approval process.

[0061] In box 401, a node receives a new block. In an embodiment, the block includes a block header and list data representing an ordered sequence of TX identifiers of the block. In a Bitcoin-style distributed blockchain system as shown in FIG. 2, the block header can include the following data fields: [1] The block version number indicates which set of block approval rules should be followed. [2] The hash of the previous block's header is the SHA256 (SHA256()) hash of the internal byte-order of the previous block's header. This ensures that the previous block cannot be changed without changing this block's header. [3] The Merkle root hash, derived from the hashes of all transactions contained in this block, ensures that none of these transactions can be modified without modifying their headers. [4] The block time is the UNIX epoch time when the miner started hashing the header (according to the miner). [5] nBits is an encoded version of the target threshold that this block's header hash must be less than or equal to. [6] A nonce is an arbitrary number that a miner modifies to modify the header hash to produce hashes below a target threshold.

[0062] An example of these fields is shown in FIG. 6A.

[0063] In box 403, the node extracts a list representing an ordered sequence of transaction identifiers ("TX identifiers" or "TX IDs") stored in the blocks received in box 401. An exemplary list of transaction identifiers for blocks is shown diagrammatically in FIG. 6A.

[0064] In box 405, the node generates data representing a full Merkle tree for the ordered sequence of transaction identifiers of blocks extracted in box 403. A full Merkle tree is a tree having an ordered sequence of leaf nodes corresponding to the ordered sequence of transaction identifiers of blocks. Each leaf node contains a hash of the transaction data referenced by the corresponding transaction identifier, and every non-leaf node contains a cryptographic hash of the hash value of its child nodes. The non-leaf nodes of the full Merkle tree are logically organized in levels extending upward from the leaves (bottom) to the root, which stores the root hash value of the full Merkle tree, as is well known. An exemplary full Merkle tree of a block is shown diagrammatically in FIG. 6A.

[0065] In box 407, the node extracts the Merkle root hash value stored in the header of the block received in box 401, and the node compares the extracted Merkle root hash value with the root hash value of the entire Merkle tree generated in box 405.

[0066] In box 409, the node evaluates the comparison of box 407 to determine whether the extracted Merkle root hash value matches the root hash value of the entire Merkle tree generated in box 405. If not, operation proceeds to boxes 439 and 441. If so, operation proceeds to box 411.

[0067] In box 411, the node evaluates other header conditions for the validity of the block.

[0068] In box 413, the node checks the evaluation of box 411 to determine whether all other header conditions for block validity are met. If not, operation proceeds to boxes 439 and 441. If so, operation proceeds to box 415.

[0069] In box 415, the node loops through the ordered sequence of transaction identifiers of the blocks extracted in box 403, and performs the acts of boxes 417-425 for each given transaction identifier in the loop.

[0070] In box 417, the node identifies a shard that corresponds to the transaction referenced by the given transaction identifier. A shard that corresponds to a transaction may be a shard associated with the transaction itself or a shard associated with one or more transaction inputs or transaction outputs of the transaction. Examples of mechanisms that can be used to specify an association (or correspondence) between a transaction and one or more shards are described above with respect to box 301 of Figures 3A and 3B.

[0071] In box 419, the node checks whether it belongs to the shard identified in box 417. If not, the operation proceeds to box 421. If so, the operation proceeds to box 422.

[0072] In box 421 , the node removes the given transaction identifier from the ordered sequence of transaction identifiers of the blocks extracted in box 403 , and operation proceeds to box 425 .

[0073] In box 423, the node checks whether the transaction referenced by the given transaction identifier is valid. If it is determined that the transaction referenced by the given transaction identifier is valid, the operation proceeds to box 425. If not, the operation proceeds to boxes 439 and 441. In an embodiment, the node can check that the transaction referenced by the given transaction identifier is stored in a transaction queue (memory pool) for the shard to which the node belongs. If so, the transaction can be considered valid and the operation proceeds to box 425. If not, the node can communicate with other nodes of the network to request and obtain a copy of the transaction. Once received, the node can perform an operation to approve the received transaction. An example of such an approval operation is described above with reference to box 307 of Figures 3A and 3B. If the transaction is considered valid, the operation proceeds to box 425. If the transaction is considered invalid, the operation proceeds to boxes 439 and 441.

[0074] In box 425, the node checks whether all transaction identifiers have been processed in a loop through the ordered sequence of transaction identifiers constructed in box 415. If not, the operation returns to box 415 and continues looping for the next transaction identifier in the list. If so, the operation proceeds to box 427.

[0075] Note that the acts in boxes 419-425 check the validity of transactions that relate to shards to which the node belongs, and thus bypass checking the validity of transactions that relate to shards to which the node does not belong.

[0076] In box 427, the node may generate and store data marking the block as valid.

[0077] In box 429, the node stores data including the resulting list of transaction identifiers for the blocks. This resulting list of transaction identifiers may omit transaction identifiers associated with shards to which the node does not belong, thus avoiding storing an entire list of ordered sequences of transaction identifiers for the blocks.

[0078] In box 431, the node derives data representing a partial Merkle tree for the block. Details of such operations are described below with reference to FIG.

[0079] In box 433, the node updates the block's header data to include the block's partial Merkle tree derived in box 431.

[0080] In box 435, the node stores the data representing the block (including the header updated in the block's partial Merkle tree in box 433 and the data including the resulting list of blocks stored in box 429) as part of the block data for one or more shards to which the node belongs. Such an operation may store the representation of the block to persistent storage, such as a disk or other form of persistent data storage. Exemplary header data and transaction list data representing the block are shown generally in FIG. 6D.

[0081] Note that the partial Merkle tree in box 431 may omit branches derived from transactions associated with shards to which the node does not belong, and may include placeholders (for hash values) along branches derived from transactions associated with shards to which the node does belong. Thus, in many cases, the nodes and levels of the partial Merkle tree will be unbalanced compared to the normal form of the full Merkle tree. Importantly, the act of reducing the full Merkle tree to create a partial Merkle tree can be used to reduce the storage requirements of the partial Merkle tree in the header of the block data for one or more shards to which the node belongs. Because the branches of a Merkle tree are the product of concatenations and hashes of the branches or leaves below them, the full Merkle tree can be reduced based on complete paths in the tree. If the branches result in a complete leaf, these branches can be removed, leaving only its hash. Each hash from the Merkle root to the leaf can be removed so that the root hash of the partial Merkle tree can be created again by replacing the placeholders. By performing this process, the number of hashes that require storage in the partial Merkle tree can be reduced, lowering storage requirements.

[0082] In box 437, the node can propagate the new block received in box 401 to other nodes.

[0083] In box 439, the node may generate and store data marking the block as invalid.

[0084] In box 441, the node may discard data representing the invalid block and avoid propagating the invalid block to other nodes. The node may also discard transaction data for one or more transactions that are part of the invalid block allocated to the shard, and optionally return the UTXOs of such transactions to the UTXO set for the shard.

[0085] FIG. 5 is a flowchart illustrating example operations performed by a node to derive data representing a partial Merkle tree for a block.

[0086] In box 501, a node reads the block header and the ordered list of transaction identifiers for the block.

[0087] In box 503, the node uses the list of transaction identifiers of the blocks read in box 501 to generate data representing the entire Merkle tree of the block.

[0088] In box 505, the node loops through the transaction identifiers of the ordered list of transaction identifiers of blocks that correspond to the hash values ​​(from left to right) at the lowest level of the entire Merkle tree, and performs the operations in boxes 507-513 for each given transaction identifier in the list.

[0089] In box 507, the node checks whether the transaction referenced by the given transaction identifier corresponds to a shard to which the node belongs. Examples of mechanisms that can be used to specify an association or correspondence between a transaction and one or more shards are described above with respect to box 301 in Figures 3A and 3B. If the transaction referenced by the given transaction identifier does not correspond to a shard to which the node belongs, the operations proceed to boxes 509 and 513. If the transaction referenced by the given transaction identifier corresponds to a shard to which the node belongs, the operations proceed to box 511.

[0090] In box 511, the node replaces the given transaction identifier (hash value) in the list with a placeholder, and operation proceeds to box 513. The placeholder is a data value or character with an encoding size smaller than the encoding size of the transaction identifier in the list. The placeholder is also constructed so that it is easily distinguishable from the allowed values ​​of the transaction identifier in the list. In an embodiment, the placeholder can be a null value or a specific character. Ideally, the placeholder should provide the maximum space reduction relative to a 256-bit hash. Alternatively, the placeholder can provide some other minimum-to-maximum space reduction relative to a 256-bit hash.

[0091] In box 513, the node checks whether any transaction identifiers remain to be processed in the loop through the transaction identifiers configured in box 505. If so, the operation returns to box 505 and continues looping for the next transaction identifier in the list. If not, the operation proceeds to box 515.

[0092] Note that the acts in boxes 507-513 replace the transaction corresponding to the shard to which the node belongs with a placeholder from the transaction identifier at the lowest (leaf) level of the entire Merkle tree.

[0093] In box 515 , the node sets the Merkle tree's current level pointer to the bottom (or leaf node level) of the entire Merkle tree represented by the data generated in box 503 .

[0094] In box 517, the node checks whether the current level pointer of the Merkle tree points to the root level in the entire Merkle tree. If not, operation proceeds to box 533. If so, operation proceeds to box 519.

[0095] In box 519, the node loops through adjacent node pairs at the current level of the full Merkle tree (referenced by the full Merkle tree current level pointer), performing the operations in boxes 521-529 for each given adjacent node pair at the current level of the full Merkle tree.

[0096] In box 521, the node checks whether both nodes of a given adjacent pair each contain a hash value (as distinct from a placeholder). Note that the nodes of an adjacent pair at the lowest level of the entire Merkle tree represent corresponding elements of the ordered list of placeholders and transactions resulting from the operations in boxes 505-513, as described above. Such correspondence is described by matching the positions of the lists of placeholders and transactions with the leaf node positions (from left to right) at the lowest level of the entire Merkle tree. If this condition is not met, then both nodes of the given adjacent pair are left alone in box 523, and the hash value of the parent tree node of the given adjacent pair is replaced with a placeholder in box 525, and operations proceed to box 529. If this condition is met, then the node removes both nodes of the given adjacent pair in box 527, leaving only the hash value of the parent tree node of the adjacent pair, and operations proceed to box 529.

[0097] In box 529, the node checks whether any adjacent node pairs at the current level of the full Merkle tree remain to be processed in the loop through the adjacent node pairs constructed in box 519. If so, the operation returns to box 519 and continues looping for the next adjacent node pair at the current level of the full Merkle tree. If not, the operation proceeds to box 531.

[0098] In box 531, the node adjusts the current level pointer of the Merkle tree to point to the next level in the full Merkle tree, and operations continue repeating the operations in boxes 517-529 for the next level of the full Merkle tree.

[0099] In box 533, the node replaces or substitutes the root node hash values ​​of the entire Merkle tree with a placeholder, and the operation ends.

[0100] FIG. 6A shows a full Merkle tree for an example block.

[0101] Figure 6B illustrates the results of the operations of boxes 519-529 of the flowchart of Figure 5 for the full Merkle tree of the example block of Figure 6A. In these operations, placeholders have replaced hash values ​​(transaction identifiers) for the six transactions at the lowest level of the full Merkle tree, where such transactions correspond to the shard to which the node belongs.

[0102] Figure 6C shows the result of the operations of boxes 519-529 of the flowchart of Figure 5 for the full Merkle tree of Figure 6A. In these operations, two adjacent hash values ​​at the bottom level of the full Merkle tree (the left side of the full Merkle tree) have been removed because the hash values ​​are derived from transactions that do not correspond to the shard to which the node belongs. In addition, a placeholder has replaced the parent node of an adjacent leaf node at the second level of the full Merkle tree (the left side of the full Merkle tree) in three cases where the adjacent nodes do not both have corresponding hash values ​​and are therefore derived from at least one transaction that corresponds to the shard to which the node belongs.

[0103] FIG. 6D shows a partial Merkle tree that is the result of operating the flowchart of FIG. 5 on the full Merkle tree of FIG. 6A.

[0104] Figures 7A-7C, taken together, are a flowchart illustrating operations performed by a node that is not a member of all shards to approve a block stored as part of a sharded blockchain ledger, such as the sharded blockchain ledger of Figure 2. In this case, the node belongs to a limited subset of the active shards and therefore does not belong to one or more active shards. Note that any node that is a member of all shards can approve a new block using well-known block approval processes.

[0105] In box 701, a node reads a block from the block data for the shard to which it belongs. The block data includes a block header that contains data representing a partial Merkle tree for the block. The block header may include other fields as well. The block data also includes an ordered list of transaction identifiers for transactions that are part of the block and that correspond to the shard to which the node belongs. Exemplary block data is shown diagrammatically in FIG. 8A.

[0106] In box 703, the node extracts an ordered list of transaction identifiers for the blocks stored in the block data read in box 701. The list of transaction identifiers optionally omits transactions that are part of the block and that correspond to one or more shards to which the node does not belong, thus avoiding storing an entire list of the ordered sequence of transaction identifiers for the blocks.

[0107] In box 705 , the node extracts data representing the partial Merkle tree of the block stored in the block data read in box 701 .

[0108] In box 707 , the node sets the partial Merkle tree's current level pointer to the lowest level of the partial Merkle tree represented by the data extracted in box 705 .

[0109] In box 709, the node loops through the tree nodes at the current level of the partial full Merkle tree (the lowest level referenced by the partial Merkle tree's current level pointer set in box 707). This loop performs the acts in boxes 711-717 for each given tree node at the lowest level of the partial Merkle tree.

[0110] In box 711, the node checks whether the given tree node is a placeholder. If not, the node skips the tree node in box 713 and proceeds to box 717. If so, the node proceeds to box 715, where the node replaces the placeholder with the corresponding transaction identifier (hash value) from the list extracted in box 703, and operation proceeds to box 717. Note that the correspondence between the transaction identifiers (hash values) from the list extracted in box 703 and the placeholders can be described by the correspondence between the order of the placeholders at the lowest level of the partial Merkle tree and the order of the transaction identifiers in the list extracted in box 703.

[0111] In box 717, the node checks whether any tree nodes at the current level of the partial Merkle tree (referenced by the partial Merkle tree current level pointer) remain to be processed in the loop through the tree nodes constructed in box 709. If so, the operation returns to box 709 to continue looping for the next tree node. If not, the operation proceeds to box 719.

[0112] In box 719, the node sets the partial Merkle tree's current level pointer to the next level of the partial Merkle tree represented by the data extracted in box 705 (the level above the bottom leaf node level).

[0113] In box 721, the node checks whether the partial Merkle tree's current level pointer points to the root level in the partial Merkle tree. If so, operation proceeds to box 735. If not, operation proceeds to box 723.

[0114] In box 723, the node loops through the tree nodes at the current level of the partial full Merkle tree (referenced by the partial Merkle tree's current level pointer set in box 719 or 733), performing the acts in boxes 725 through 731 for each given tree node at the current level of the partial Merkle tree.

[0115] In box 725, the node checks whether the given tree node is a placeholder. If not, the node skips the tree node in box 727 and proceeds to box 731. If so, the node proceeds to box 729, where the node calculates a hash value based on the hash values ​​of the two child nodes of the given tree node, replaces the placeholder with this calculated hash value, and operation proceeds to box 729.

[0116] In box 729, the node checks whether any tree nodes at the current level of the partial Merkle tree (referenced by the partial Merkle tree current level pointer) remain to be processed in the loop through the tree nodes constructed in box 723. If so, the operation returns to box 723 to continue looping for the next tree node. If not, the operation proceeds to box 733.

[0117] In box 733, the node adjusts the partial Merkle tree's current level pointer to point to the next level in the partial Merkle tree, and operation returns to box 721 to process the next level of the partial Merkle tree.

[0118] In box 735, the node calculates a hash value based on the two child nodes of the root node determined from the operations in boxes 709-731, and replaces the placeholder in the root node with this calculated hash value.

[0119] In box 737, the node extracts the Merkle root hash value that was stored in the block's header as part of the block data read in box 701, and the node compares the extracted Merkle root hash value with the root hash value of the partial Merkle tree computed in box 735.

[0120] In box 739, the node evaluates the comparison of box 737 to determine whether the extracted Merkle root hash value matches the root hash value of the partial Merkle tree computed in box 735. If so, operation proceeds to box 741. If not, operation proceeds to boxes 755 and 757.

[0121] In box 741, the node evaluates other header conditions for the validity of the block.

[0122] In box 743, the node checks the evaluation of box 741 to determine whether all other header conditions for block validity are met. If so, operation proceeds to box 745. If not, operation proceeds to boxes 755 and 757.

[0123] In box 745, the node loops through the list of transaction identifiers extracted in box 703. The list of transaction identifiers optionally omits transactions that relate to shards to which the node does not belong, thus avoiding storing an entire list of ordered sequences of transaction identifiers for blocks. The loop performs the operations of boxes 747-749 for each given transaction identifier in the list.

[0124] In box 747, the node checks whether the transaction referenced by the given transaction identifier is valid. If it is determined that the transaction referenced by the given transaction identifier is valid, the operation proceeds to box 749. If not, the operation proceeds to boxes 755 and 757. In an embodiment, the node can check that the transaction referenced by the given transaction identifier is stored in a transaction queue (memory pool) for the shard to which the node belongs. If so, the transaction can be considered valid and the operation proceeds to box 749. If not, the node can communicate with other nodes in the network to request and obtain a copy of the transaction. Once received, the node can perform an operation to approve the received transaction. An example of such an approval operation is described above with reference to box 307 of Figures 3A and 3B. If the transaction is considered valid, the operation proceeds to box 749. If the transaction is considered invalid, the operation proceeds to boxes 755 and 757.

[0125] In box 749, the node checks whether any transaction identifiers remain to be processed in the loop through the transaction identifiers configured in box 745. If so, operation returns to box 745 and continues looping for the next transaction identifier in the list. If not, operation proceeds to boxes 751 and 753.

[0126] In box 751, the node generates and stores data marking the block as valid.

[0127] In box 753, the node may propagate the data representing the valid block to other nodes that belong to the same set of shards as the node.

[0128] In box 755, the node generates and stores data marking the block as invalid.

[0129] In box 757, the node may discard the block data representing the invalid block and avoid propagating the block data representing the invalid block to other nodes. The node may also discard transaction data for one or more transactions that are part of the invalid block allocated to the shard, and optionally return UTXOs for such transactions to the UTXO set for the shard.

[0130] FIG. 8A illustrates a partial Merkle tree for an example block.

[0131] Figure 8B shows the result of the operations of boxes 709-717 of the flowchart of Figures 7A-7D on the partial Merkle tree of Figure 8A, in which five placeholders at the lower (leaf) levels of the partial Merkle tree are replaced with their corresponding hash values ​​(transaction identifiers) as part of the list of transaction identifiers extracted in box 703.

[0132] Figure 8C shows the result of the operations of boxes 723-731 of the flowchart of Figures 7A-7D on the partial Merkle tree of Figure 8A, in which three placeholders at the second level of the partial Merkle tree are replaced with hash values ​​derived from the hash values ​​of their child nodes.

[0133] Figure 8D shows the result of the operations of boxes 723-737 of the flowchart of Figures 7A-7D on the partial Merkle tree of Figure 8A. In these operations, a hash value for the root of the partial Merkle tree is derived from the hash values ​​of the child nodes and compared to the Merkle root hash value stored in the block header of the block for validation.

[0134] FIG. 9 is an exemplary simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the systems shown and described above. For example, the computing device 2600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 9, the computing device 2600 may include one or more processors 2602 that may be configured to communicate with and operably coupled to a number of peripheral subsystems via a bus subsystem 2604. The processor 2602 may be utilized to process unlock and lock scripts as part of authorizing transactions in use as described herein. These peripheral subsystems may include a storage subsystem 2606, including a memory subsystem 2608 and a file / disk storage subsystem 2610, one or more user interface input devices 2612, one or more user interface output devices 2614, and a network interface subsystem 2616. Such storage subsystems 2606 may be used for temporary or long-term storage of information such as details related to the transactions and blocks described in this disclosure.

[0135] The bus subsystem 2604 may provide a mechanism that allows the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface to receive data from other systems and to transmit data from the computing device 2600 to other systems. For example, the network interface subsystem 2616 may enable a data technician to connect to a wireless network so that data technicians can transmit and receive data while at a remote location, such as a data center. The bus subsystem 2604 may be utilized to communicate data such as details, search items, etc., to the supervised models of the present disclosure and to communicate the output of the supervised models to one or more processors 2602 and to counterparties and / or creditors via the network interface subsystem 2616.

[0136] The user interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device, such as a microphone, and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600. The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display, such as an audio output device. The display subsystem may be a flat panel device, such as a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used to present a user interface, for example to facilitate user interaction with applications performing the processes and variations thereof described herein, when user interaction may be appropriate.

[0137] The storage subsystem 2606 may provide a computer readable storage medium for storing basic programming and data constructs that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide functionality of one or more embodiments of the present disclosure, may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may further provide a repository for storing data used in accordance with the present disclosure. The storage subsystem 2606 may include a memory subsystem 2608 and a file / disk storage subsystem 2610.

[0138] The memory subsystem 2608 may include multiple memories, including a main random access memory (RAM) 2618 for storing instructions and data during program execution, and a read only memory (ROM) 2620 in which fixed instructions may be stored. The file / disk storage subsystem 2610 may provide non-transient persistent (non-volatile) storage for program and data files, and may include hard disk drives, floppy disk drives with associated removable media, compact disk read only memory (CD-ROM) drives, optical drives, removable media cartridges, and other similar storage media.

[0139] The computing device 2600 may include at least one local clock 2624. The local clock 2624 may be a counter representing the number of ticks that have occurred since a particular starting date and may be integrally located within the computing device 2600. The local clock 2624 may be used to synchronize data transfers in the processor for the computing device 2600 and all subsystems contained therein at a particular clock pulse, and may be used to coordinate synchronous operations between the computing device 2600 and other systems in a data center. In one embodiment, the local clock 2624 is an atomic clock. In another embodiment, the local clock is a timer with a programmable interval.

[0140] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include other devices that may be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, lightning connector, etc.). The devices that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals, which may be transmitted through ports that connect the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the exemplary computing device 2600 shown in FIG. 9 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 9.

[0141] It should be noted that the above embodiments are illustrative rather than limiting of the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present disclosure, which is defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the scope of the claims. The words "comprising" and "comprises" do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes or consists of" and "comprising" means "comprising or consisting of". A reference to a singular form of an element does not exclude a reference to a plural form of such element, and vice versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0142] It should be understood that the above description is intended to be illustrative and not restrictive. Many other implementations will become apparent to those skilled in the art upon reading and understanding the above description. Although the present disclosure has been described with reference to certain exemplary implementations, it will be recognized that the present disclosure is not limited to the described implementations, but can be practiced with modification and alteration within the scope of the appended claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense. The scope of the present disclosure should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. 1. A computer-implemented method for maintaining blocks of a blockchain among nodes of a sharded blockchain network including a plurality of shards, where each node is a member of one or more shards, and where each node stores a UTXO set for each shard of which it is a member and block data for all shards of which it is a member, comprising: At a given node that is a member of a particular subset of the plurality of shards, receiving a new block of the blockchain, the new block including a plurality of transactions; generating data representing the new block by generating a list of transaction identifiers of a first plurality of transactions that are part of the new block and that are associated with the particular subset of the plurality of shards, and generating a partial Merkle tree from transaction identifiers of a second plurality of transactions that are part of the new block; storing the data representing the new block in the block data for the shard; propagating the block data to other nodes in the shard; Including, a node that, in generating the data representing the new block, approves transactions that have inputs associated with UTXOs stored in one of its stored UTXO sets, while bypassing approval of transactions that are part of the new block and do not have inputs associated with UTXOs stored in one of its stored UTXO sets.

2. 2. The computer-implemented method of claim 1, wherein the list of transaction identifiers does not include transaction identifiers of transactions that are part of the new block and that are not associated with the particular subset of the plurality of shards.

3. 3. The computer-implemented method of claim 2, wherein the list of transaction identifiers is generated by constructing an initial list of transaction identifiers for the new block based on data included in the new block, and processing the initial list of transaction identifiers to remove any transaction identifiers that correspond to transactions not related to the particular subset of the plurality of shards.

4. 2. The computer-implemented method of claim 1, wherein the partial Merkle tree includes hash values ​​derived from transactions that are part of the new block and that are not related to the particular subset of the plurality of shards, while omitting hash values ​​derived from transactions that are part of the new block and that are related to the particular subset of the plurality of shards.

5. 2. The computer-implemented method of claim 1, wherein the partial Merkle tree is generated by building a full Merkle tree for the new block based on data included in the new block, and processing the full Merkle tree to replace hash values ​​derived from transactions that are part of the new block and that are associated with the particular subset of the plurality of shards with placeholders.

6. 6. The computer-implemented method of claim 5, wherein processing the entire Merkle tree further comprises iterating from a bottom level to a root level of the entire Merkle tree, removing two hash values ​​for adjacent node pairs, and retaining a parent hash value.

7. 6. The computer-implemented method of claim 5, wherein processing the entire Merkle tree further comprises iterating from a bottom level to a root level of the entire Merkle tree and replacing with a placeholder a hash value of a parent tree node that has two child nodes that together do not represent a hash value derived from transactions that are not related to the particular subset of the plurality of shards.

8. 2. The computer-implemented method of claim 1, further comprising: operating the node to process the partial Merkle tree to calculate a Merkle root hash value for block approval without requiring access to transactions that are part of the block and that are not related to the particular subset of the plurality of shards.

9. 9. The computer-implemented method of claim 8, wherein processing the partial Merkle tree to compute the Merkle root hash value iterates from lower levels of the partial Merkle tree to the root level and replaces placeholders with hash values ​​computed from corresponding child hash values ​​of the partial Merkle tree.

10. 2. The computer-implemented method of claim 1 , wherein the list of transaction identifiers and the partial Merkle tree vary among the nodes based on node membership and allocation of the transactions among the shards.

11. 1. A system comprising: A processor; a memory containing executable instructions which, upon execution by the processor, cause the system to perform a computer-implemented method according to any one of claims 1 to 10; A system including:

12. A non-transitory computer readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to perform at least the computer-implemented method of any one of claims 1 to 10.

Images