Maintaining blocks of blockchain in partitioned blockchain network

Abstract

The present invention provides a computer-implemented method and system that maintains a plurality of blocks of a blockchain across a plurality of nodes of a fragmented blockchain network, where the nodes are members of one or more fragments of a plurality of active fragments. The method and system generates data representing a new block of the blockchain using a given node that is a member of a particular subset of the plurality of active fragments and stores the data representing the new block. Such data includes i) a list of transaction identifiers for transactions that are part of the new chunk and that are associated with a particular subset of the plurality of active slices, and / or ii) a local Merkel tree for the new chunk.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201980028786.9 (PCT international application number PCT / IB2019 / 053383), application date April 24, 2019, and name “Maintaining Blockchain Blocks in a Partitioned Blockchain Network”. Technical Field

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

[0003] In this document, the term "blockchain" refers to any of several types of computer-based electronic distributed ledgers. Such ledgers include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variants. It should be noted that the present disclosure is not limited to use with a specific blockchain, and alternative blockchain implementations and protocols fall within the scope of protection of the present disclosure.

[0004] A blockchain is an electronic ledger between peers, created and maintained by a decentralized, distributed computer-based system. The ledger consists of blocks, which in turn consist of transactions and other information. A blockchain system or network includes multiple blockchain nodes and a set of operations. A blockchain node can be used to perform some or all of the set of operations. Each blockchain node can be implemented as computer hardware, computer software, or a combination of both, and is run by a node operator, where the node operator can be independent of and unrelated to other node operators. Blockchain nodes can each maintain a copy of the blockchain ledger or a portion of the blockchain ledger. The set of operations can include creating transactions, propagating transactions, reading the blockchain ledger, evaluating the blockchain ledger, generating (mining) new blocks for proposed additions to the blockchain ledger, communicating with other blockchain nodes, and providing wallet functionality for users to create transactions and manage blockchain assets.

[0005] A blockchain ledger is a decentralized ledger in which there is no single blockchain node or entity that determines when the ledger is modified. Instead, blockchain nodes are each programmed with knowledge of the blockchain protocol rules to verify the blockchain ledger and confirm that actions taken by other blockchain nodes are consistent with those rules. The term "blockchain" may refer to the fact that a blockchain ledger comprises a series of linked blocks, each of which represents a data structure in computer memory that is readable by a computer process and can be transmitted as a means of data transmission. A block includes one or more transactions, also representing a data structure in computer memory that is readable by a computer process and can be transmitted as a means of data transmission. Blocks are linked in a chain because each new block that is formally added to the blockchain contains an immutable reference to the previous block, which contains an immutable reference to the block before it, and so on.

[0006] In order for a particular transaction to be included in a block written to the blockchain, one or more nodes validate the particular transaction and possibly propagate the transaction to other nodes, the node produces a block of transactions in which the node includes the particular transaction, and the other nodes confirm the validity of the block and the validity of the transactions in the node. Since some nodes are programmed or configured with these rules in mind, it is impossible for these nodes to include transactions in a node that may invalidate the node, and therefore, the block will not be accepted by other nodes and these nodes will not gain any benefit.

[0007] Transactions in a blockchain network contain various data elements, including units of value and other data elements. The units of value may be cryptocurrencies, but may also be other variations utilizing other digital assets. In a decentralized, distributed ledger system, the ledger may be a public ledger so that anyone can view the ledger and access the transactions stored in the ledger blocks.

[0008] Blockchain networks can be subject to performance limitations caused by latency in transaction network propagation related to transaction verification, as each transaction needs to be verified before it can be propagated to other nodes. Also, as the size of the blockchain grows, the storage requirements of the nodes verifying transactions and blocks increase. Summary of the invention

[0009] Therefore, there is a need to provide improved systems and methods for increasing the scalability of blockchain ledgers through the use of partitions or shards.

[0010] Partitioning a blockchain network into shards enables users to choose their own level of participation in the blockchain network. Each user can choose to be a member of one or more shards. A user that is a member of fewer than all shards requires less storage space to store all transactions assigned to the shards of which the user is a member. Assigning transactions to shards based on shard transaction identifiers has the advantage that the resulting shards are roughly equal in size, thereby avoiding undue burden on larger shard members relative to smaller shard members, while at the same time enabling transactions and associated verification to proceed accurately without any undue delays.

[0011] A user as referred to herein may be associated with one or more nodes or computing devices, and these nodes may also be referred to as client entities in a partitioned blockchain network. Hereinafter, reference to a user may also be understood as reference to a node or entity associated with the user (the node or entity owns or controls a node or entity that is part of a sharded or partitioned blockchain network). Each node may be communicatively coupled to at least one or more other nodes in a partitioned blockchain network.

[0012] The advantages discussed herein in connection with this and other aspects of the disclosure (described below) are due to the structure of the nodes, the resulting network topology and architecture of the sharded blockchain network, and the protocols associated with the network nodes. Receiving, storing and / or verifying unspent transaction outputs (UTXOs) in the sharded network is performed using the described and claimed methods, rules or protocols for communication, data storage and data sharing, and verification techniques for nodes within each shard and based on associated rules and protocols for communicating with nodes belonging to different shards.

[0013] These specific structures, data flow methods, transaction allocation and verification protocols will be further explained below with respect to various embodiments of the present disclosure. Advantageously, the sharded network structure or architecture and the associated methods described herein for transaction allocation and verification of such allocated transactions in a sharded blockchain network enable novel techniques for data flow, data storage, and unspent transaction output (UTXO) verification checks. Furthermore, these techniques advantageously prevent double-spending attacks, such as Sybil attacks in blockchains given the structure and data communication / verification protocols.

[0014] Therefore, according to the present disclosure, a computer-implemented method and system for maintaining multiple blocks of a blockchain across multiple nodes of a sharded blockchain network may be provided, wherein each node is a member of one or more of a plurality of active shards. The method and system use a given node that is a member of a particular subset of the plurality of active shards, wherein the given node is used to generate data representing a new block of the blockchain and store data representing the new block. Such data includes: i) a list of transaction identifiers of transactions that are part of the new block and are associated with a 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 are not associated with a particular subset of the plurality of active shards.

[0015] According to the present disclosure, there is also provided a computer-implemented method for maintaining multiple blocks of a blockchain across multiple nodes of a sharded blockchain network, the sharded blockchain network comprising multiple shards, wherein each node is a member of one or more shards (also referred to as each node belonging to one or more shards), and each node stores a UTXO set of each shard to which the node belongs, and block data of all shards to which the node belongs; the method comprising, at a given node (the given node is a member of a specific subset of the multiple shards):

[0016] receiving a new block of the blockchain, which includes a plurality of transactions;

[0017] Generating data representing the new block by: generating a list of transaction identifiers of a first plurality of transactions, wherein the first plurality of transactions are part of the new block and are associated with a particular subset of the plurality of shards, and,

[0018] generating a partial Merkle tree from transaction identifiers of a second plurality of transactions that are part of the new block;

[0019] Storing data representing the new block in the block data of the shard; and,

[0020] Propagate the block data to other nodes in the shard;

[0021] Among them, in the generation of data used to represent the new block, the node verifies the following transactions: the transaction has an input related to the UTXO stored in one of the (one or more) UTXO sets stored by the node, and skips the verification of the following transactions: transactions that are part of the new block and do not have an input related to the UTXO stored in one of the (one or more) UTXO sets stored by the node.

[0022] Optionally, the list of transaction identifiers excludes transaction identifiers of transactions that are part of the new block and are not associated with a particular subset of the plurality of shards.

[0023] 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 corresponding to transactions that are not associated with a particular subset of the plurality of active shards.

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

[0025] In an embodiment, the partial Merkle tree in ii) may be generated by constructing a complete Merkle tree for the new block based on data included in the new block, and processing the complete Merkle tree to replace placeholders for hash values ​​derived from transactions that are part of the new block and associated with a particular subset of the plurality of active shards.

[0026] In an embodiment, processing the complete Merkle tree may further include iterating from a bottom level of the complete Merkle tree to a root level, removing both hash values ​​of adjacent node pairs and leaving the parent hash value.

[0027] In an embodiment, processing the complete Merkle tree may further include iterating from a bottom level of the complete Merkle tree to a root level and replacing a placeholder for a hash value of a parent tree node that has two child nodes, neither of which represents a hash value derived from a transaction that is not associated with a particular subset of the plurality of active shards.

[0028] In an embodiment, a node may be operable to process a local Merkle tree to compute a Merkle root hash value for block validation without requiring access to transactions that are part of a block and are not associated with a specific subset of multiple active shards.

[0029] In an embodiment, processing the local Merkle tree to calculate the Merkle root hash value may involve iterating from a bottom level of the local Merkle tree to the root level, replacing any placeholders in the bottom level with corresponding hash values ​​from the list of transaction identifiers in i), and replacing any placeholders in levels above the bottom level with hash values ​​calculated based on corresponding sub-hash values ​​of the local Merkle tree.

[0030] In an embodiment, the list of transaction identifiers in i) and the local Merkle tree in ii) vary between nodes based on node membership and the distribution of transactions between shards.

[0031] In an embodiment, a transaction that is part of a new block may be associated with (or distributed to) multiple shards of the multiple active shards based on a transaction identifier.

[0032] In other embodiments, transactions that are part of a new block are associated with (or distributed to) a plurality of shards of a plurality of active shards based on a parent blockchain transaction, wherein the parent transaction is defined by outputs corresponding to child blockchain transaction inputs, and wherein both the parent transaction and the child transaction are associated with the same shard.

[0033] In an embodiment, the block data maintained by the node may omit transaction data that is part of a shard to which the node does not belong, thereby saving node storage space. Therefore, some nodes store the data structure of the blockchain only for a limited subset of blockchain transactions, while other nodes store the data structure for all transactions of the blockchain. In this case, the data storage capacity of the node storing the data structure for the limited subset of the blockchain may be much smaller than the data storage capacity of the node storing the data structure for the entire blockchain.

[0034] In an embodiment, when generating data representing a new block, a node may verify transactions that are part of the new block and are associated with a specific subset of the multiple active shards, while bypassing verification of transactions that are part of the new block and are not associated with the specific subset of the multiple active shards. Such processing may reduce the computational work of block verification operations. This advantage, along with reduced data storage capacity requirements for certain shards of the blockchain network, may allow nodes with computing resources to effectively participate in the blockchain network.

[0035] Hence, according to the present disclosure, there is provided a method as defined in the accompanying claims.

[0036] According to the present disclosure, an electronic device including a processor, a computer memory and a network interface device may be provided. The memory has stored therein computer executable instructions, which configure the processor to perform the method described herein when executed.

[0037] According to the present disclosure, a non-transitory computer-readable storage medium may be provided. The computer-readable storage medium includes computer-executable instructions, which configure a processor to perform the method described herein when executed. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The above aspects and other aspects of the present disclosure will be apparent and clarified by reference to the embodiments described herein. Embodiments of the present disclosure will now be described by way of example only and with reference to the accompanying drawings, in which:

[0039] Figure 1A A blockchain network is described in which various embodiments may be implemented.

[0040] Figure 1B Describes the blockchain ledger and representative blocks, which can be accessed through Figure 1A The blockchain network is maintained and various embodiments may be implemented therein.

[0041] Figure 2 Nodes of an illustrative sharded blockchain network are described along with a data structure of a sharded blockchain ledger maintained by such nodes.

[0042] Figure 3A and Figure 3B Together, they are flowcharts that illustrate the use of sharded blockchain ledgers (e.g., Figure 2 The generation and verification of blockchain transactions that are part of a sharded blockchain ledger.

[0043] Figure 4A and Figure 4B Together they are flow charts describing the actions performed by nodes that are not members of all shards when validating a new block.

[0044] Figure 5 is a flow chart describing the operations performed by nodes that are not members of all shards when building a local Merkle tree for a new block.

[0045] FIG. 6A to FIG. 6D for Figure 5 Schematic diagram of the operation shown.

[0046] FIG. 7A to FIG. 7D , collectively, is a flow chart describing operations performed by a node that is not a member of all shards when validating block data maintained by the node. Such operations process the local Merkle tree of the block to calculate the Merkle root hash value of the local Merkle tree.

[0047] FIG. 8A to FIG. 8D for FIG. 7A to FIG. 7D Schematic diagram of the operation shown.

[0048] Fig. 9 A computing environment is described in which various embodiments may be implemented. DETAILED DESCRIPTION

[0049] First reference Figure 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 that each run software and / or hardware instances that perform operations that follow a blockchain protocol that is agreed upon in whole or in part between blockchain node operators. In some examples, these distributed electronic devices are simply referred to as "nodes", e.g. Figure 1A Node 102 in .

[0050] Node 102 can be a plurality of computing devices in a distributed system of a computing resource service provider or through Fig. 9 The node 102 may be any suitable electronic client device such as a computing device 2600 of a computer, including 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.). The node 102 may have inputs to receive data messages or objects representing transactions and / or blocks and information related to other nodes. The node 102 may query the information it maintains, such as its understanding of the status of a transaction.

[0051] like Figure 1A As shown, some nodes 102 are communicatively coupled to one or more other nodes of node 102. As to which nodes 102 can communicate with which other nodes, these details do not need to be determined centrally. It is sufficient that active nodes in blockchain network 100 are able to communicate with one or more other nodes 102, so that a message passed from one node 102 to another node 102 can be propagated throughout blockchain network 100 (or some significant portion of the blockchain network), assuming that the message is a message that the blockchain protocol indicates should be forwarded. One such message may be the publication of a transaction proposed by one of nodes 102A, which message will then be propagated along a path such as path 106. Another such message may be the publication of a new block proposed for inclusion on the blockchain.

[0052] Node 102 may store a distributed blockchain ledger (or blockchain) containing data corresponding to transactions and data corresponding to transaction blocks. Node 102 may store a complete copy of the blockchain ledger or a portion thereof. For example, some nodes may store data for the entire blockchain ledger, while other nodes may store data for only unspent transactions, while other nodes may maintain the entire blockchain ledger. Node 102 may include functionality to verify each block it receives and the transactions in the block. Some nodes 102 collect transactions and create transaction blocks so that new blocks can be added to the blockchain ledger. Some nodes may need to perform a task that is both complex (to prevent malicious nodes from easily creating inappropriate blocks) and dependent on the data of the included transactions (so that malicious nodes cannot perform complex operations in advance), where other nodes can easily verify the execution of these tasks. When creating a new block, multiple nodes may compete to perform the necessary work. Alternatively, the nodes of the new block may be selected in a deterministic manner, depending on the value of the new block, which is also defined as equity. This is called "proof of equity" forging. Some nodes propagate the new block to other nodes for verification. Other nodes validate the new block and the transactions embedded in the new block. If the validation 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.

[0053] In some examples, blocks are groupings of transactions that are often marked with a timestamp and a "fingerprint" (e.g., a hash) of the previous block. In this way, each block becomes linked to the previous block, thereby creating a "chain" of blocks in the blockchain ledger. Each block includes data (e.g., a transaction identifier) ​​that refers to the block's group of transactions. In an embodiment, valid blocks are added to the blockchain ledger by consensus of nodes in the blockchain network. Likewise, in some examples, the blockchain ledger contains an ordered list of verified blocks. Figure 1B A blockchain ledger 1216 is illustrated having a chain of three blocks 1221, 1223, 1223. Note that block 1222 includes data referring to the transaction group of block 1222 (e.g., block header 1230 and transaction identifiers 1231(1), 1231(2), 1231(3) ...).

[0054] The present disclosure aims to improve the scalability of blockchain ledgers by using partitioning. Partitioning in the art considers two specific dimensions: horizontal and vertical. In horizontal partitioning, data is divided into different segments called shards, which are actually multiple instances of a specific database scheme, where data is distributed on each of these instances (regardless of instance redundancy). In vertical partitioning, a given database scheme is distributed on multiple nodes so that the attributes of a specific object are distributed using normalization.

[0055] The present disclosure uses a horizontal partitioning scheme for the data structure of the blockchain ledger between groups of associated nodes called "shards". Each shard is assigned a unique identifier. There is a group called "all shards" that covers all shards. Each node of the blockchain network can belong to one or more shards (including the "all shards" group). Nodes belonging to a shard can be called members of that shard. Figure 2 In the example, nodes A1 and A2 are members of shard A (belong to shard A), nodes B1 and B2 are members of shard B (belong to shard B), node C is a member of shards A and B (belong to shards A and B), and node D is a member of the "all shards" group (belongs to the "all shards" group). Other shards can also be used. In addition, each node is used to store the data structure of the blockchain ledger corresponding to the one or more shards to which it belongs. Figure 2 In the example of , the data structure of the blockchain ledger includes the relevant data structure of the shard, which includes the unspent transaction output set of the shard, the transaction queue (memory pool) of the shard, the transaction data of the shard (labeled as transaction data), and the block data of the shard. The unspent transaction output set of the shard represents the unspent transaction output (UTXO) that can be spent as a new transaction input.

[0056] In embodiments described herein, block data maintained by a given node includes block data for one or more shards to which the given node belongs. The block data includes data representing a block of a blockchain ledger, and may include the following data for each block: i) a block header including a local Merkle tree together 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 for transactions that are part of the block and associated with one or more shards to which the given node belongs; the list does not include transaction identifiers for transactions that are part of the block and are not associated with one or more shards to which the given node belongs. The local Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and associated with one or more shards to which the given node does not belong, but omits hash values ​​derived from transactions that are part of the block and associated with one or more shards to which the given node belongs. The local Merkle tree can be used to allow a node to calculate a block Merkle root hash value for block verification without requiring access to transactions that are part of the block and are not associated with one or more shards to which the node belongs. Thus, i) the local Merkle tree and ii) the list of given blocks stored as part of the block data by nodes of different shards may vary between nodes based on node membership and the distribution of transactions between shards. Advantageously, given the narrowness of sharded blockchain networks and the protocols described herein for establishing information that each node may or may not store, it is possible to use the local Merkle tree of blocks associated with the block header and other data (as described in this embodiment) in order to still accurately save and use the necessary details of the block to be verified and propagated without requiring each node to store and verify all unspent transaction outputs associated with a given transaction. As will be further explained herein, the creation and use of local Merkle trees for processing block information is facilitated by: This structure of the sharded network is facilitated by the protocols applied by nodes within the sharded network for communication and data flow within the same shard, plus other protocols for communication and data flow with one or more nodes outside the shard associated with the node.

[0057] exist Figure 2In the example of , nodes A1 and A2 store a copy of the unspent transaction output set of shard A, a copy of the transaction queue (memory pool) of shard A, a copy of the transaction data of shard A, and a copy of the block data of shard A. Nodes A1 and A2 do not store the following: a copy of the unspent transaction output set of other shards (except shard A), a copy of the transaction queue (memory pool) of other shards (except shard A), and a copy of the transaction data of other shards (except shard A). In addition, the block data of shard A includes data representing a block of the blockchain ledger, and may include the following data for each block: i) a block header including a local Merkle tree together with other data of the block, and ii) a list of transaction identifiers of transactions that are part of the block; the list includes only transaction identifiers for transactions that are part of the block and are associated with shard A; the list does not include transaction identifiers for transactions that are part of the block and are not associated with shard A. The local Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and not associated with Shard A, but omits hash values ​​derived from transactions that are part of the block and associated with Shard A.

[0058] Nodes B1 and B2 store a copy of the unspent transaction output set of shard B, a copy of the transaction queue (memory pool) of shard B, a copy of the transaction data of shard B, and a copy of the block data of shard B. Nodes B1 and B2 do not store the following: a copy of the unspent transaction output set of other shards (except shard B), a copy of the transaction queue (memory pool) of other shards (except shard B), and a copy of the transaction data of other shards (except shard B). In addition, the block data of shard B includes data representing a block of the blockchain ledger, and may include the following data for each block: i) a block header including a local Merkle tree together with other data of the block, and ii) a list of transaction identifiers of transactions that are part of the block; the list includes only transaction identifiers for transactions that are part of the block and are associated with shard B; the list does not include transaction identifiers for transactions that are part of the block and are not associated with shard B. The local Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and not associated with Shard B, but omits hash values ​​derived from transactions that are part of the block and associated with Shard B.

[0059] Node C stores a copy of Shard A's unspent transaction output set, a copy of Shard B's unspent transaction output set, a copy of Shard A's transaction queue (memory pool), a copy of Shard B's transaction queue (memory pool), a copy of Shard A's transaction data, a copy of Shard B's transaction data, and a copy of Shard A and B's block data. Node C does not store the following: copies of other shards (except Shards A and B), copies of other shards (except Shards A and B)'s transaction queues (memory pools), and copies of other shards (except Shards A and B)'s transaction data. In addition, the block data for shards A and B includes data representing a block of the blockchain ledger, and may include the following data for each block: i) a block header including a local Merkle tree along with other data for the block, and ii) a list of transaction identifiers for transactions that are part of the block; the list includes transaction identifiers only for transactions that are part of the block and are associated with shard A or B; the list does not include transaction identifiers for transactions that are part of the block and are not associated with shard A or B. The local Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and are not associated with shard A or B, but omits hash values ​​derived from transactions that are part of the block and are associated with shard A or B.

[0060] Node D stores a copy of the unspent transaction output sets of all shards, a copy of the transaction queues (memory pools) of all shards, a copy of the transaction data of all shards, and a copy of the block data of all shards.

[0061] It should be noted that the block data maintained by the node may omit transaction data that is part of the shard to which the node does not belong, thereby saving node storage space. Therefore, some nodes (e.g., nodes A1, A2, B1, B2, C) store data structures of the blockchain ledger only for a limited subset of blockchain ledger transactions, while other nodes (e.g., node D) store data structures for all transactions of the blockchain ledger. In this case, the data storage capacity of the node (e.g., nodes A1, A2, B1, B2, C) that stores data structures for a limited subset of the blockchain ledger 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. It should be noted that in other blockchain ledgers, other data structures may be stored and maintained for different shards.

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

[0063] In addition, each node is used to perform block validation operations that validate only those transactions associated with one or more shards to which the node belongs. In such operations, validation of any transactions associated with another shard to which the node does not belong is bypassed and does not affect whether the node considers the block valid. In this case, operators who choose to be members of a single shard have a lighter security participation by validating a limited set of transactions in the blockchain ledger, while operators who choose to be members of all shards have a higher security participation by validating all transactions in the blockchain ledger.

[0064] It should be noted that a node may be configured to communicate with multiple other nodes within a single shard to prevent Sybil attacks. These attacks may effectively ignore transactions sent from a node, preventing them from propagating further through the network. One or more nodes in a given shard may also be assigned to exchange information related to nodes in other shards, and such assignments may rotate between nodes in a given shard over time. Each node may broadcast each transaction it receives to the other nodes it is coupled to, and if the given node is not a member of the shard, it may perform basic transaction layer checks before propagating the transaction forward, rather than performing full transaction validation.

[0065] At different or specific times / instances, detailed information about other nodes can also be shared between nodes in a specific shard. This is performed according to the second embodiment of the present disclosure using a modified version of the addr protocol message. The current implementation of the addr message is used to list or identify one or more IP addresses and ports. For example, a getaddr request can be used to obtain an addr message containing a group of known active peers (e.g., for booting). The addr message usually contains only one address, but sometimes contains many addresses, and in some examples contains up to 1000 addresses. In some examples, all nodes periodically (i.e., every 24 hours) broadcast an addr containing their own IP address. The node can then pass these messages to its peers and store the passed addresses when the message is new for the node. In this way, nodes in the network can reasonably clearly know which IPs are connected to the network when or after connecting to the network. In most cases, the IP address is added to everyone's address database because of the initial addr broadcast.

[0066] In addition to the above, an implementation of the modified addr protocol according to the present disclosure may be able to transmit additional information about the shard to which a particular node belongs. For example, in the modified addr protocol, when a node in a shared network such as FIG. 1b joins a particular shard in the network, the content broadcast as part of the addr message may also include a field that identifies one or more shards of which the node is a member. Therefore, this information is also returned in response to a getaddr request from a peer in the network of FIG. 1b. As discussed in the first embodiment, this information may be based on a data structure that is associated with each node and / or each shard with which the node is associated.

[0067] Figure 3A and Figure 3B Together, they are flowcharts that illustrate the use of sharded blockchain ledgers (e.g., Figure 2 The generation and verification of blockchain transactions that are part of a sharded blockchain ledger.

[0068] In block 301, a client node generates a blockchain transaction, wherein the blockchain transaction is associated with (or assigned or allocated to) one or more shards of a blockchain network. The shard associated with a valid blockchain transaction may be a shard associated with the blockchain transaction itself, or may be a shard associated with one or more transaction inputs or transaction outputs of the valid blockchain transaction. For example, in one embodiment, the shard associated with the 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, the shard associated with the valid blockchain transaction may be determined by applying a modulus of the number of currently active shards 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 another embodiment, the shard associated with the valid blockchain transaction may be based on the first or other inputs of the blockchain transaction and the outputs of earlier transactions referenced by the inputs. In this case, the transaction whose output is referenced by the first input of the 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 it is not necessary for the method to use the first input to define the parent transaction; if there are multiple inputs, any input may be selected to perform the method. For example, if a particular number of inputs of a child transaction references a transaction output in the same shard as the parent transaction, then the earlier transaction may be defined as the parent transaction of the child transaction. The number of inputs may define the majority of the inputs of the child transaction. Details of these mechanisms are set forth in UK Patent Application 1806907.0 and UK Patent Application 1806909.6, both of which are commonly assigned to the assignee of the present application and are incorporated herein by reference in their entirety. In yet other embodiments, other mechanisms may be used to associate a blockchain transaction with one or more shards of a blockchain network.

[0069] In block 303, the client node broadcasts the blockchain transaction for communication with nodes belonging to one or more shards associated with the blockchain transaction (and potentially with other nodes belonging to shards not associated with the blockchain transaction).

[0070] In block 305 , a node belonging to one or more shards associated with a blockchain transaction receives the blockchain transaction.

[0071] In block 307 , nodes belonging to one or more shards associated with the blockchain transaction validate the received blockchain transaction or portion thereof, and each such node, when the received blockchain transaction or portion thereof is deemed valid, propagates the blockchain transaction to other nodes in the shard to which it belongs.

[0072] In one embodiment (referred to as "transaction shard validation"), the transaction validation of block 307 is performed by the shard to which the transaction is associated or assigned. As described above, a transaction may be associated with (or assigned to) a shard using the result of a modulo function applied to the transaction's transaction identifier. Because a transaction may have inputs from different shards, a node may communicate with nodes of other shards to perform unspent transaction output checks. Specifically, a node belonging to one or more shards may make a request to a node belonging to other shards to obtain the unspent transaction output set of the other shards. If none of the nodes has the requested unspent transaction output set, an empty response is given and the transaction in question is considered invalid. If the transaction inputs are considered valid, the transaction is added to the shard's transaction queue (memory pool), the transaction is associated with or assigned to the shard (block 309), and the transaction is propagated to other nodes in the shard (block 311).

[0073] In another embodiment (referred to as "unspent transaction output shard-based validation"), the transaction validation of block 307 validates the transaction based on inputs associated with a set of unspent transaction outputs that are in the same shard as the node performing validation. Inputs associated with a set of unspent transaction outputs in a different shard are not validated. Validation of each input may involve checking to confirm that the unspent transaction output of the referenced output has not been spent, validating (e.g., script validation) whether the input is authorized to collect the value of the referenced output, and several other checks. In the event that an input is invalid (such as when the unspent transaction output associated with the input does not exist, the value of the transaction output is greater than the unspent transaction output of the corresponding input, or there is a script error), the transaction is discarded and not propagated to other nodes in the same shard. If the input is deemed valid, the transaction is added to the transaction queue (memory pool) of the shard of the node performing validation (block 309), and the transaction is propagated to other nodes in the shard (block 311).

[0074] The details of the "Transaction Sharding Verification" embodiment and the "Verification Based on Unspent Transaction Output Sharding" embodiment are described in UK Patent Application 1806911.2 and UK Patent Application 1806914.6, which are jointly assigned to the assignee of the present application and are incorporated herein by reference in their entirety.

[0075] In an embodiment, the transaction validation of block 307 may also involve checks related to the transaction as a whole, such as checking whether the syntax and data structure of the transaction are correct, checking whether the transaction is smaller than the allowed block size and greater than or equal to 100 bytes, and checking whether the lock time is less than the maximum allowed value.

[0076] In block 309 , a node belonging to the shard associated with the valid blockchain transaction adds the valid blockchain transaction to the transaction queue (memory pool) of the shard associated with the valid blockchain transaction.

[0077] In box 311, one or more nodes form a block based on the transaction queues (memory pools) of all shards (e.g., the memory pool of "all shards") and propagate the new block to other nodes.

[0078] In box 313, the node receives the new block and processes the new block according to the consensus protocol to perform block verification and commit the block.

[0079] Figure 4A and Figure 4B Together, this is a flow chart describing the process of validating a new block for a node that is not a member of all shards. Figure 3A and Figure 3B The operation of block 313 of . In this case, the node belongs to a limited subset of active shards and therefore does not belong to one or more active shards. It should be noted that any node that is a member of all shards can verify the new block using the well-known block verification process.

[0080] In block 401, a node receives a new block. In an embodiment, the block includes a block header and lists data representing an ordered sequence of TX identifiers of the block. Figure 2 In the distributed blockchain system shown, the block header may include the following data fields:

[0081] [1] The block version number, which indicates which set of block validation rules to follow;

[0082] [2] The previous block header hash, which is a SHA256 (SHA256()) hash of the internal byte order of the previous block header. This ensures that if the block header is not changed,

[0083] You cannot change the previous block;

[0084] [3] A Merkle root hash derived from the hashes of all transactions included in a block, ensuring that such transactions cannot be modified without modifying the headers;

[0085] [4] Block time, which is the Unix epoch time at which some nodes start hashing headers (according to those nodes);

[0086] [5] nBits, which is an encoded version of the target threshold that the header hash must be less than or equal to; and

[0087] [6] A random number that is an arbitrary number that some nodes change to modify the header hash, resulting in a hash less than or equal to the target threshold.

[0088] Fig. 6A An example block with fields is shown.

[0089] In block 403 , the node extracts an ordered sequence list representing transaction identifiers (“TX identifiers” or “IX Ids”) stored in the block received in block 401 . Fig. 6A An example list of block transaction identifiers is schematically shown.

[0090] In block 405, the node generates a complete Merkle tree data representing the ordered sequence of block transaction identifiers extracted in block 403. A complete Merkle tree is a tree having an ordered sequence of leaf nodes, with the leaf nodes corresponding to the ordered sequence of block transaction identifiers. Each leaf node includes a hash of the transaction data referenced by the corresponding transaction identifier, and each non-leaf node includes a cryptographic hash of the hash values ​​of its child nodes. The non-leaf nodes of the complete Merkle tree are logically organized in multiple levels extending upward from the leaves (bottom) to the root, and as is well known, the root stores the root hash value of the complete Merkle tree. Fig. 6A An example complete Merkle tree of a block is schematically shown.

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

[0092] In block 409, the node evaluates the comparison value of block 407 to determine whether the extracted Merkle root hash value matches the root hash value of the complete Merkle tree generated in block 405. If not, operation continues to blocks 439 and 441. If yes, operation continues to block 411.

[0093] In block 411, the node evaluates other header conditions for block validity.

[0094] In block 413, the node checks the evaluation of block 411 to determine if the other header conditions for block validity are met. If not, operation continues to blocks 439 and 441. If yes, operation continues to block 415.

[0095] In block 415 , the node configuration loops through the ordered sequence of block transaction identifiers extracted in block 403 and performs the operations of blocks 417 to 425 for each given transaction identifier in the loop.

[0096] In block 417, the node identifies the shard corresponding to the transaction referenced by the given transaction identifier. The shard corresponding to the transaction may be the shard associated with the transaction itself or the shard associated with one or more transaction inputs or transaction outputs. Figure 3A and Figure 3B In block 301 of , examples of mechanisms that may be used to specify an association (or correspondence) between a transaction and one or more shards are described above.

[0097] In block 419, the node checks to see if it belongs to the shard identified in block 417. If not, operation continues to block 421. If yes, operation continues to block 422.

[0098] In block 421 , the node removes the given transaction identifier from the ordered sequence of block transaction identifiers as extracted in block 403 , and operation continues to block 425 .

[0099] 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 continues to box 425. If not, the operation continues to boxes 439 and 441. In an embodiment, the node can check to confirm that the transaction referenced by the given transaction identifier is stored in the transaction queue (memory pool) of the shard to which the node belongs. If so, the transaction can be considered valid and the operation continues to box 425. If not, the node can communicate with another node of the network to request and obtain a copy of the transaction. Upon receipt, the node can perform operations for verifying the received transaction. According to Figure 3A and Figure 3B 307, an example of a verification operation is described. If the transaction is deemed valid, the operation continues to block 425. In the case where the transaction is deemed invalid, the operation continues to blocks 439 and 441.

[0100] In block 425, the node checks whether all transaction identifiers have been processed in the loop through the ordered sequence of transaction identifiers configured in block 415. If not, operation returns to block 415 to continue looping with the next transaction identifier in the list. If so, operation continues to block 427.

[0101] Note that the operations of blocks 419 to 425 check the validity of transactions associated with the shard to which the node belongs, and therefore skip checking the validation of transactions associated with shards to which the node does not belong.

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

[0103] In block 429, the node stores data including the resulting list of block transaction identifiers. The resulting list of transaction identifiers may omit transaction identifiers associated with shards to which the node does not belong, and thus avoid storing a complete list of the ordered sequence of block transaction identifiers.

[0104] In block 431, the node derives data representing the local Merkle tree of the block. Figure 5 Let's describe this operation in detail.

[0105] In box 433, the node updates the header data of the block to include the local Merkle tree of the block derived in box 431.

[0106] In block 435, the node stores data representing the block (including the header updated with the local Merkle tree of the block in block 433, and the result list data including the block stored in block 429) as part of the block data for one or more shards to which the node belongs. Such operations may store the representation of the block to a permanent storage, such as a disk or other form of permanent data storage. Fig.6D Example header data and transaction list data representing a block are schematically shown.

[0107] Note that the local Merkle tree of block 431 may omit branches derived from transactions associated with a shard to which the node does not belong, and include placeholders (for hash values) along the branches, the placeholders being derived from transactions associated with the shard to which the node belongs. Thus, in many cases, the nodes and levels of the local Merkle tree are unbalanced relative to the conventional form of the full Merkle tree. Importantly, the operation of reducing the full Merkle tree to produce the local Merkle tree can be used to reduce the storage requirements of the local Merkle tree in the block data header of one or more shards to which the node belongs. Since Merkle tree branches are the result of the concatenation and hashing of the leaves below the branch or branches, the full Merkle tree can be reduced based on the complete path in the tree. If a branch results in the formation of a sufficiently complete leaf, the branch can be removed, leaving only its hash. The hash from the Merkle root to the leaf can be removed, so that the root hash of the local Merkle tree can be generated again by replacing the placeholder. By executing this procedure, the storage requirements can be reduced by reducing the number of hashes stored in the local Merkle tree.

[0108] In block 437 , the node may propagate the new block as received in block 401 to other nodes.

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

[0110] In block 441, the node may discard data representing the invalid block and refrain from propagating the invalid block to other nodes. The node may also discard transaction data of one or more transactions belonging to the invalid block as allocated to the shard, and return the unspent transaction outputs of the transaction to the unspent transaction output set of the shard, if appropriate.

[0111] Figure 5 A flowchart illustrating exemplary operations performed by a node to derive local Merkle tree data representing a block.

[0112] In block 501 , a node reads a block header and an ordered list of block transaction identifiers.

[0113] In block 503 , the node generates data representing a complete Merkle tree for the block using the list of block transaction identifiers as read in block 501 .

[0114] In block 505, the node configures a loop through the transaction identifiers of the ordered list of block transaction identifiers corresponding to the hash values ​​in the bottom level of the complete Merkle tree (from left to right). The loop performs the operations of blocks 507 to 513 for each given transaction identifier in the list.

[0115] In block 507, the node checks whether the transaction referenced by the given transaction identifier corresponds to the shard to which the node belongs. Figure 3A and 3B Block 301 of FIG. 300 describes an example of a mechanism that may be used to specify an association or correspondence between a transaction and one or more shards. If the transaction referenced by the given transaction identifier does not correspond to the shard to which the node belongs, the operation continues to blocks 509 and 513. If the transaction referenced by the given transaction identifier does correspond to the shard to which the node belongs, the operation continues to block 511.

[0116] In block 511, the node replaces a given transaction identifier (hash value) of the list with a placeholder, and the operation continues to block 513. The placeholder is a data value or character that has a small encoded size relative to the encoded size of the transaction identifier of the list. The placeholder is also configured to be easily identifiable from the allowed values ​​of the transaction identifier of the list. In an embodiment, the placeholder can be a null value or a specific character. Ideally, the placeholder should provide a 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.

[0117] In block 513, the node checks whether any transaction identifiers remain to be processed in the loop through transaction identifiers configured in block 505. If so, operation returns to block 505 to continue looping with the next transaction identifier in the list. If not, operation continues to block 515.

[0118] Note that the operations of blocks 507 through 513 are used to replace the transaction corresponding to the shard to which the node belongs from the placeholder for the transaction identifier in the bottom (leaf) level of the complete Merkle tree.

[0119] In block 515 , the node sets the Merkle tree current level pointer to the bottom (or leaf node level) of the complete Merkle tree represented by the data generated in block 503 .

[0120] In block 517, the node checks whether the current level pointer of the Merkle tree points to the root level of the complete Merkle tree. If not, the operation continues to block 533. If yes, the operation continues to block 519.

[0121] In block 519, the node configuration loops through the adjacent node pairs at the current level of the complete Merkle tree (referenced by the Merkle tree current level pointer). The loop performs the operations of blocks 521 to 529 for each given adjacent node pair at the current level of the complete Merkle tree.

[0122] In box 521, the node checks to confirm whether the two nodes of the given adjacent node pair each contain a hash value (as distinguished from the placeholder). Please note that the nodes of the adjacent node pair at the bottom level of the complete Merkle tree refer to the corresponding elements in the ordered list of transactions and placeholders generated by the operations of boxes 505 to box 513 as described above, where the correspondence is determined by matching the position in the list of transactions and placeholders with the leaf node position (from left to right) in the bottom level of the complete Merkle tree. If this condition is not met, the two nodes of the given adjacent node pair are left alone in box 523, the hash value of the parent tree node of the given adjacent node pair is replaced with the placeholder in box 525, and the operation continues to box 529. If this condition is met, the node removes the two nodes of the given adjacent node pair, and the hash value of the parent tree node of the adjacent node pair is left alone in box 527, and the operation continues to box 529.

[0123] In block 529, the node checks whether any more neighboring nodes at the current level of the complete Merkle tree remain to be processed in the loop of neighboring node pairs configured in block 519. If so, the operation returns to block 519 to continue the loop of neighboring node pairs at the current level of the complete Merkle tree. If not, the operation continues to block 531.

[0124] In block 531, the node adjusts the Merkle tree current level pointer to point to the next level of the complete Merkle tree, and the operation continues to repeat the operations of blocks 517 to 529 for the next level of the complete Merkle tree.

[0125] In block 533, the node replaces or substitutes the root node hash value of the complete Merkle tree with the placeholder, and the operation ends.

[0126] Fig. 6A A complete Merkle tree of an example block is shown.

[0127] Figure 6B Shows the Fig. 6A The complete Merkle tree of the example block is Figure 5 The result of the operations of box 519 to box 529 of the flowchart of . In these operations, the placeholders replace the hash values ​​(transaction identifiers) of the six transactions in the bottom level of the complete Merkle tree, where these transactions correspond to the shards to which the node belongs.

[0128] Figure 6C Shows the Fig. 6A The complete Merkle tree is Figure 5 The result of the operations of blocks 519 to 529 of the flowchart of FIG. 5 is shown in FIG. 5. In these operations, two adjacent hash values ​​in the bottom level of the complete Merkle tree (located on the left side of the complete Merkle tree) have been removed because such hash values ​​are derived from transactions that do not correspond to the shard to which the node belongs. In addition, in three cases where none of the adjacent nodes have a corresponding hash value and are therefore derived from at least one transaction corresponding to the shard to which the node belongs, placeholders have replaced the parent nodes of the adjacent leaf nodes in the second level of the complete Merkle tree (located on the left side of the complete Merkle tree).

[0129] Fig.6D shows a local Merkle tree, which is Fig. 6A The complete Merkle tree of Figure 5 The operation results of the flowchart in .

[0130] 7A to 7C is a flowchart illustrating the operations performed by nodes that are not members of all shards to verify the ledger of a sharded blockchain (e.g. Figure 2 A node is a block stored as part of a sharded blockchain ledger in a sharded blockchain. In this case, the node belongs to a limited subset of active shards and therefore does not belong to one or more active shards. It should be noted that any node that is a member of all shards can validate new blocks using the well-known block validation process.

[0131] In block 701, a node reads a block from the block data of the shard to which the node belongs. The block data includes a block header, which includes data representing a local Merkle tree of the block. The block header may also include other fields. The block data also includes an ordered list of transaction identifiers of transactions, which are part of the transaction and correspond to the shard to which the node belongs. Fig. 8A Example block data is schematically shown.

[0132] In block 703, the node extracts a sequential list of block transaction identifiers as stored in the block data read in block 701. The list of transaction identifiers may omit transactions that are part of the block and correspond to one or more shards to which the node does not belong, and thus avoid storing a complete list of the ordered sequence of transaction identifiers for the block.

[0133] In block 705 , the node extracts data representing the block-local Merkle tree as stored in the block data read in block 701 .

[0134] In block 707 , the node sets the local Merkle tree current level pointer to the bottom level of the local Merkle tree as represented by the data extracted in block 705 .

[0135] In block 709, the node configuration loops through the tree nodes at the current level of the local complete Merkle tree (which is the bottom level referenced by the local Merkle tree current level pointer set in block 707). The loop performs the operations of blocks 711 to 717 for each given tree node at the bottom level of the local Merkle tree.

[0136] In block 711, the node checks to determine if the given tree node is a placeholder. If not, the node skips the tree node in block 713 and proceeds to block 717. If so, the node proceeds to block 715 where the node replaces the placeholder with the corresponding transaction identifier (hash value) from the extracted list in block 703, and the operation proceeds to block 717. Note that the correspondence between the placeholder and the transaction identifier (hash value) in the extracted list in block 703 can be determined by the correspondence between the ordering of the placeholders in the bottom level of the local Merkle tree and the ordering of the transaction identifiers in the extracted list in block 703.

[0137] In block 717, the node checks whether any more tree nodes at the current level of the local Merkle tree (referenced by the local Merkle tree current level pointer) remain to be processed in the loop through the tree nodes configured in block 709. If so, the operation returns to block 709 to continue the loop with the next tree node. If not, the operation continues to block 719.

[0138] In block 719 , the node sets the local Merkle tree current level pointer to the next level (a level above the bottom leaf node level) of the local Merkle tree as represented by the data extracted in block 705 .

[0139] In block 721, the node checks to confirm whether the current level pointer of the local Merkle tree points to the root level in the local Merkle tree. If so, the operation continues to block 735. If not, the operation continues to block 723.

[0140] In block 723, the node configuration loops through the tree nodes at the current level of the local complete Merkle tree (referenced by the local Merkle tree current level pointer set in blocks 719 or 733). The loop performs the operations of blocks 725 through 731 for a given tree node at the current level of the local Merkle tree.

[0141] In block 725, the node checks to determine if the given tree node is a placeholder. If not, then in block 727, the node skips the tree node and continues to block 731. If yes, then the node continues to block 729 where the node calculates a hash value based on the hash values ​​of the two child nodes of the given tree node and replaces the placeholder with the calculated hash value, and operation continues to block 729.

[0142] In block 729, the node checks whether any more tree nodes at the current level of the local Merkle tree (referenced by the local Merkle tree current level pointer) remain to be processed in the loop through the tree nodes configured in block 723. If so, the operation returns to block 723 to continue the loop with the next tree node. If not, the operation continues to block 733.

[0143] In block 733, the node adjusts the local Merkle tree current level pointer to point to the next level of the local Merkle tree, and the operation returns to block 721 to process the next level in the local Merkle tree.

[0144] In block 735 , the node calculates a hash value based on the two child nodes of the root node as determined from the operations of blocks 709 to 731 , and replaces the placeholder for the root node with the calculated hash value.

[0145] In box 737 , the node extracts the Merkle root hash value stored in the block 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 local Merkle tree calculated in box 735 .

[0146] In block 739, the node evaluates the comparison value of block 737 to determine whether the extracted Merkle root hash value matches the root hash value of the local Merkle tree calculated in block 735. If so, operation continues to block 741. If not, operation continues to blocks 755 and 757.

[0147] In block 741, the node evaluates other header conditions for block validity.

[0148] In block 743, the node checks the evaluation of block 741 to determine if all other header conditions for block validity are met. If so, operation continues to block 745. If not, operation continues to blocks 755 and 757.

[0149] In block 745, the node configuration loops through the list of transaction identifiers extracted in block 703. The list of transaction identifiers may omit transactions associated with shards to which the node does not belong, and thus avoid storing a complete list of ordered sequences of block transaction identifiers. The loop performs the operations of blocks 747 to 749 for a given transaction identifier in this list.

[0150] In block 747, the node checks whether the transaction referenced by the given transaction identifier is valid. If the transaction referenced by the given transaction identifier is determined to be valid, the operation continues to block 749. If not, the operation continues to blocks 755 and 757. In an embodiment, the node may check to confirm that the transaction referenced by the given transaction identifier is stored in the transaction queue (memory pool) of the shard to which the node belongs. If the transaction is deemed valid, the operation continues to block 749. If not, the node may communicate with another node of the network to request and obtain a copy of the transaction. Upon receipt, the node may then perform operations for verifying the received transaction. See Figure 3A and Figure 3B The verification operation example is described above in block 307. If the transaction is deemed valid, the operation continues to block 749. If the transaction is deemed invalid, the operation continues to blocks 755 and 757.

[0151] In block 749, the node checks whether any transaction identifiers remain pending in the loop through transaction identifiers configured in block 745. If so, operation returns to block 745 to continue looping with the next transaction identifier in the list. If not, operation continues to blocks 751 and 753.

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

[0153] In block 753, the node may propagate data representing the valid block to other nodes belonging to the same shard set as the node.

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

[0155] In block 757, the node may discard block data representing the invalid block and refrain from propagating block data representing the invalid block to other nodes. The node may also discard transaction data of one or more transactions that are part of the invalid block, such as those assigned to the shard, and, if appropriate, transfer unspent transaction outputs of the transactions back to the unspent transaction output set of the shard.

[0156] Fig. 8A A local Merkle tree of an example block is shown.

[0157] Figure 8B Shows the Fig. 8A The local Merkle tree is FIG. 7A to FIG. 7D The result of the operations of blocks 709 to 717 of the flowchart of FIG. In these operations, the five placeholders in the lower (leaf) level of the local Merkle tree are replaced with the corresponding hash values ​​(transaction identifiers) extracted as part of the transaction identifier list in block 703.

[0158] Figure 8C Shows the Fig. 8A The local Merkle tree is FIG. 7A to FIG. 7D The result of the operations of blocks 723 to 731 of the flowchart of FIG. In these operations, the three placeholders in the second level of the local Merkle tree are replaced with hash values ​​derived from the child node hash values.

[0159] Fig.8D Shows the Fig. 8A The local Merkle tree is FIG. 7A to FIG. 7D The operations of blocks 723 to 737 of the flowchart of FIG. In these operations, the hash value of the root of the local Merkle tree is derived from the child node hash values ​​and compared with the Merkle root hash value stored in the block header of the block for verification.

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

[0161] The bus subsystem 2604 may provide a mechanism for enabling all components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may employ multiple buses. The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may be used as an interface for sending and receiving data from other systems of the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a wireless network, enabling the data technician to transmit and receive data when in a remote location (e.g., a user data center). The bus subsystem 2604 may be used to transmit data such as detailed information, search items, etc. to the supervisory model of the present disclosure, and may be used to transmit the output of the supervisory model to one or more processors 2602 and merchants and / or creditors through the network interface subsystem 2616.

[0162] The user interface input device 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 with a display; an audio input device, such as a voice recognition system and a microphone; and other types of input devices. In general, the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600. One or more user interface output devices 2614 may include a non-visual display such as a display subsystem, a printer, or 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, a projection or other display device. In general, the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. For example, one or more user interface output devices 2614 may be used to present a user interface to facilitate user interaction with an application that executes the processes and changes therein (when such interaction may be appropriate).

[0163] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that may provide the functionality of at least one embodiment of the present disclosure. When the application programs are executed by one or more processors, these application programs (such as programs, code modules, and instructions) may provide the functionality of one or more embodiments of the present disclosure and 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 also 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.

[0164] Memory subsystem 2608 may include a number of memories including a main random access memory (RAM) 2618 for storing instructions and data during program execution and a read-only memory (ROM) 2620 that may store fixed instructions. File / disk storage subsystem 2610 may provide non-transitory permanent (non-volatile) storage for program and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, removable media cartridges, and other similar storage media.

[0165] The computing device 2600 may include at least one local clock 2624. The local clock 2624 may be a counter that represents the number of ticks that have occurred since a particular start date, and may be entirely located within the computing device 2600. The local clock 2624 may be used to synchronize data transfers among the processor of the computing device 2600 and all subsystems included therein at a particular frequency pulse, and may be used to coordinate synchronization operations between the computing device 2600 and other systems in the data center. In one embodiment, the local clock 2624 is an atomic clock. In another embodiment, the local clock is a programmable interval timer.

[0166] The computing device 2600 may include various types of devices such as a portable computer device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 2600 may include another device that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, lightning port, etc.). The device that can be connected to the computing device 2600 may include multiple ports for plugging fiber optic connectors. Therefore, the device can be used to convert optical signals into electrical signals, which can then be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, for the purpose of describing the preferred embodiment of the device, Fig. 9 The depiction of computing device 2600 is intended only as a specific example. Fig. 9 Many other configurations of the systems are possible with more or fewer components than shown.

[0167] It should be noted that the above embodiments are intended to illustrate rather than limit the present disclosure, and that those skilled in the art will be able to design a variety of alternative embodiments without departing from the scope of the present disclosure as defined in the appended claims. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. "Including" and similar words do not exclude the presence of other elements or steps not listed in any claim or the overall specification. In this specification, "comprise, comprising" means "include, including or consist of, consisting of". A singular reference to an element does not exclude a plural reference to such an element, and vice versa. The present disclosure may be implemented by means of hardware comprising a number of elements, or by means of a suitably programmed computer. In a device claim that lists a number of components, several components of these devices may be embodied by the same hardware item. The mere fact that certain measures are described in mutually different dependent claims does not indicate that a combination of these measures cannot be used to profit.

[0168] It should be understood that the above description is illustrative and not restrictive. After reading and understanding the above description, many other embodiments will be apparent to those skilled in the art. Although the present disclosure has been described with reference to specific example embodiments, it should be recognized that the present disclosure is not limited to the described embodiments but can be modified and changed within the scope of the appended claims. Accordingly, this specification and the drawings should be regarded as exemplary but not limiting. Therefore, the scope of the present invention should be determined with reference to the appended claims and the full scope of equivalents to which the claims are entitled.

Claims

1. A computer-implemented method for maintaining a plurality of blocks of a blockchain across a plurality of nodes of a sharded blockchain network, the sharded blockchain network comprising a plurality of shards, wherein: Each node is a member of one or more shards, and each node stores: the UTXO set of each shard it belongs to, and the block data of all shards it belongs to; The method includes, at a given node that is a member of a particular subset of the plurality of shards: receiving a new block of the blockchain comprising a plurality of transactions; The data representing the new block is generated by the following steps: generating a list of transaction identifiers of a first plurality of transactions that are part of the new block and 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 of the shard; as well as Propagate the block data to other nodes in the shard; Wherein, in generating the data representing the new block, the node verifies transactions having inputs related to a UTXO stored in one of the UTXO sets stored by the node, while skipping verification of transactions that are part of the new block and do not have inputs related to a UTXO stored in one of the UTXO sets stored by the node.

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 are not associated with a particular subset of the plurality of shards.

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 corresponding to transactions that are not associated with the particular subset of the plurality of shards.

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

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

6. The computer-implemented method of claim 5, wherein: Processing the complete Merkle tree further includes iterating from a bottom level of the complete Merkle tree to a root level, removing two hash values ​​of adjacent node pairs, and leaving a parent hash value.

7. The computer-implemented method of claim 5, wherein: Processing the complete Merkle tree further includes iterating from a bottom level of the complete Merkle tree to a root level and replacing a placeholder for the hash value of a parent tree node, wherein the parent tree node has two child nodes, neither of which represents a hash value derived from a transaction not associated with the particular subset of the plurality of shards.

8. The computer-implemented method of claim 1 , wherein: The node is operated to process the local Merkle tree to calculate a Merkle root hash value for block verification without requiring access to the transaction, the transaction being part of the block and not associated with the particular subset of the plurality of shards.

9. The computer-implemented method of claim 8, wherein: The local Merkle tree is processed to compute the Merkle root hash value iterating from a lower level of the local Merkle tree to a root level, and placeholders are replaced with hash values ​​computed from corresponding child hash values ​​of the local Merkle tree.

10. The computer-implemented method of claim 1, wherein: Based on node membership and the distribution of the transactions among the shards, the transaction identifier list and the local Merkle tree vary among the nodes.

11. A system comprising: processor; as well as A memory comprising executable instructions which, due to execution by the processor, cause the system to perform at least part of a computer-implemented method according to any one of claims 1 to 10.

12. A non-transitory computer-readable storage medium storing executable instructions, the instructions being executed by a processor of a computer system so that the computer system performs at least part of the computer-implemented method according to any one of claims 1 to 10.

Images