Splitting the Blockchain Network

Abstract

To provide a computer-implemented method of validating a blockchain transaction.SOLUTION: The method comprises the steps of: requesting at least one UTXO referenced by at least one respective input of the transaction from a member node of at least one shard comprising at least one UTXO; obtaining validity data of at least one UTXO from at least one node; and performing a validation check on at least one input using the validity data.SELECTED DRAWING: Figure 7b

Description

[Technical Field]

[0001] The present disclosure relates to methods for partitioning a blockchain network and for validating transactions in the partitioned blockchain network, and particularly, but not exclusively, to methods for partitioning a set of unspent transaction outputs (UTXOs) in the Bitcoin blockchain and for validating transactions in the partitioned UTXO set in the Bitcoin blockchain. [Background technology]

[0002] This document uses the term "blockchain" to include all 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, although other blockchain implementations have been proposed and developed. While Bitcoin may be referenced herein for convenience and illustrative purposes, 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. The term "user" herein may refer to a human or processor-based resource. The term "Bitcoin" is used herein to include any version or variation derived from or based on the Bitcoin protocol.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, computer-based system composed of blocks, which result in transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, thereby chaining blocks together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in the transaction's inputs and outputs, which specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) work to ensure each transaction is valid, and invalid transactions are rejected by the network. A software client installed on a node performs this validation operation on unspent transactions (UTXOs) by executing lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be approved by the first node that received the transaction; if the transaction is approved, the node relays it to other nodes in the network; ii) it must be added to a new block constructed by miners; and iii) it must be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptographic security system that Bitcoin is based on and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency realm. Such solutions could take advantage of the benefits of blockchain (e.g., permanent, tamper-proof record of events, distributed processing, etc.) while being more versatile in these applications.

[0006] As described above, a blockchain network, e.g., the Bitcoin blockchain network, is a secure distributed computing system. Full nodes in the system hold and manage a copy of the entire blockchain, send and receive transactions, approve them, and add blocks to the blockchain based on a shared, decentralized consensus protocol. While this approach is secure, it suffers from scaling flaws related to the fact that each transaction is approved and stored by all full nodes. Regarding approvals, this causes delays in the network propagation of transactions, as each transaction must be approved before it can be propagated toward miners. Furthermore, the delays caused by approvals make the network susceptible to "double-spend" related attacks, such as Sybil attacks. Summary of the Invention

[0007] The present disclosure aims to improve the scalability, speed, reliability, and security of blockchain networks through the use of horizontal partitioning, also known as sharding, along with related techniques or protocols for allocating and / or approving transactions on sharded blockchain networks. The network structure of a sharded blockchain, and Sharded UTXO and mempool structure Disclose the following.

[0008] Partitioning in the art considers two specific dimensions: horizontal and vertical. In a horizontally partitioned database partition section, known as a shard, there are effectively multiple instances of a particular database schema, and data is spread across each of these instances, discounting the redundancy of the instances. However, vertical partitioning involves dividing a particular database schema among multiple nodes, whereby the attributes of a particular object are distributed using normalization.

[0009] Different parties wishing to participate in a blockchain network may possess different computing resources, ranging from small, low-power machines to server farms, and thus participants are limited to a given level of involvement in the blockchain network by their computing resources.

[0010] In Bitcoin, the blockchain itself is a set of linked transactions that indicate a specific change in ownership of coins mined at the creation of a block. During transaction confirmation, one of the required checks is to ensure that no double spends exist. A double spend occurs when a transaction output is referenced in a transaction input that is already in the Bitcoin memory pool or has been confirmed against the blockchain. The memory pool is known as a reference to the memory pool or area for Bitcoin transactions that each full node maintains for itself. Traditionally, after a transaction is verified by a node, it waits in the memory pool until it is inserted into a block. To make transaction confirmation more efficient in terms of checking transaction inputs, instead of confirming the entire blockchain, the current state of the network is kept in a separate structure known as the UTXO set. This structure contains each transaction output that has already been spent by a transaction, which can include coinbase and standard transactions.

[0011] According to one aspect of the present disclosure, a computer-implemented method for dividing a blockchain network into shards is provided, the method including identifying transaction IDs of blockchain transactions and assigning the transactions to shards based on the transaction IDs.

[0012] 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 they are a member. Assigning transactions to shards based on transaction ID provides the advantage that the resulting shards are approximately equal in size, thereby avoiding overburdening members of larger shards relative to members of smaller shards, while allowing transactions and associated validations to be executed accurately without undue delay.

[0013] 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 within the partitioned blockchain network. Hereinafter, references to a user may also be understood to be references to a node or entity associated with the user (which may own or control a node or entity that is part of a shard or partitioned blockchain network). Each node may be communicatively coupled to at least one or more other nodes within the partitioned blockchain network.

[0014] These advantages described herein in this context, along with other aspects of the disclosure (described below), result from the node structure and 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 described and claimed methods, rules, or protocols for communication, data storage, and data sharing, along with approval techniques for nodes within each shard, based on rules and protocols associated with communication with nodes belonging to different shards.

[0015] These particular structures, data flow methods, 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 allocating transactions within a sharded blockchain network and approving such allocated transactions enable novel techniques for data flow, data storage, and UTXO approval checks. Furthermore, these techniques, in terms of structure and data communication / approval protocols, advantageously prevent double-spend attacks, such as Sybil attacks, on the Bitcoin blockchain.

[0016] The method may further include performing an operation using the transaction ID. Assigning the transaction to a shard may be based on a result of the operation.

[0017] This provides the advantage that the placement of shards can be adjusted depending on the action selected.

[0018] The operation may include a modulo operation.

[0019] This provides the advantage that a desired number of equally sized shards can be more easily generated.

[0020] According to the present disclosure, there is further provided a computer-implemented method for dividing a blockchain network into shards, the method including identifying a parent blockchain transaction, the parent transaction being defined by outputs corresponding to inputs of a child blockchain transaction, and assigning the parent transaction and the child transaction to the same shard.

[0021] 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 they are a member. Assigning transactions to shards based on identifying a parent blockchain transaction defined by the outputs corresponding to the inputs of the child blockchain transaction and assigning the parent and child transactions to the same shard provides the advantage that approval actions performed by a user who is a member of a particular shard can be performed while requiring less information to be sent to / from users who are members of different shards. This is because a child transaction being approved always has a parent transaction that is a member of the same shard.

[0022] A parent transaction may be identified using an input from among multiple inputs of a child blockchain transaction. The input used may be selected based on its index. The index may be 1, in which case the input used is the first input from among the multiple inputs.

[0023] This provides the advantage of allowing child transactions with multiple inputs to be assigned to shards.

[0024] A parent transaction may be identified using the largest subset of inputs of a child blockchain transaction. For example, if a child transaction has five inputs, two of which reference two outputs of a previous transaction, and the remaining three inputs each reference three different previous transactions, the parent transaction is defined as the previous transaction that both inputs reference, since those two inputs are the largest subset of inputs.

[0025] This provides the advantage that for child transactions with multiple inputs, the amount of information required from users who are members of different shards is reduced.

[0026] The present disclosure also provides a computer-implemented method for validating blockchain transactions, the method including requesting at least one UTXO referenced by at least one respective input of the transaction from member nodes of at least one shard containing the at least one UTXO, obtaining validity data for the at least one UTXO from the at least one node, and performing an validation check on the at least one input using the validity data.

[0027] This method allows for approval of blockchain transactions to occur in a sharded blockchain network. The advantage offered by this method is that each user can choose to be a member of one or more shards, and a user who is a member of fewer than all shards requires less computing power to approve all of the transactions assigned to the shards of which the user is a member.

[0028] The present disclosure relates to a computer-implemented method for approving transactions related to a blockchain network, the blockchain network being divided into a plurality of shards, each shard including at least one member node, each node in the blockchain network being a member of at least one shard among the plurality of shards, the method including: requesting, by a requesting node, at least one UTXO referenced by at least one respective input of the transaction from a member node of at least one shard that includes the at least one UTXO, the member node being associated with a set of UTXOs related to the one or more transactions allocated to each shard of which the member node is a member; based on a determination that the requested at least one UTXO is available from the member node, the method further including: performing an approval check on the at least one input based on validity data associated with the at least one UTXO; based on a determination that the transaction is valid, adding the transaction to a memory pool associated with the requesting node; and propagating the transaction to other member nodes of the at least one shard of which the requesting node is a member.

[0029] The present disclosure further provides a computer-implemented method for validating a blockchain transaction, the method including identifying at least one shard that includes at least one UTXO referenced by at least one respective input of the transaction, sending the transaction to at least one member node of the at least one shard, and performing an validation check on the at least one input using validity data of the UTXO.

[0030] This method allows for approval of blockchain transactions to occur in a sharded blockchain network. The advantage offered by this method is that each user can choose to be a member of one or more shards, and a user who is a member of fewer than all shards requires less computing power to approve all of the transactions assigned to the shards of which the user is a member.

[0031] Any of the above methods may further include communicating the node's request for shard membership information to other nodes.

[0032] This provides the advantage that nodes seeking shard membership information have a mechanism to more easily find that information.

[0033] Any of the above methods may further include communicating the node's shard membership information to other nodes.

[0034] This provides the advantage of providing a mechanism by which node shard membership information can be transferred between nodes, thereby reducing the chance of a node performing an authorization operation failing.

[0035] In some embodiments, the method includes communicating or broadcasting the node's shard membership information to all other nodes in a shard associated with the node and / or to one or more other nodes in the network. The method may also include the communicating being performed using a modify-addr message, the modify-addr message including an indication of one or more shards with which the node is associated.

[0036] The communication may be performed using a modify-addr message.

[0037] This offers the advantage of providing a more secure mechanism for exchanging shard membership information between nodes.

[0038] The present disclosure also provides a processor; a memory containing executable instructions that, upon execution by a processor, cause the system to perform any embodiment of the computer-implemented method described herein; The present invention provides a system including:

[0039] The present disclosure also provides a non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer system, cause the computer system to perform at least embodiments of the computer-implemented methods described herein.

[0040] Preferred embodiments of the present disclosure will now be described generally, and not in a limiting sense, with reference to the accompanying drawings. [Brief explanation of the drawings]

[0041] [Figure 1a] 1 shows a comparison between a traditional blockchain network (FIG. 1a) and a sharded blockchain network (FIG. 1b) according to a first embodiment of the present disclosure. [Figure 1b] 1 shows a comparison between a traditional blockchain network (FIG. 1a) and a sharded blockchain network (FIG. 1b) according to a first embodiment of the present disclosure. [Figure 2] 10 illustrates a rotation of node usage used in connection with the second embodiment of the present disclosure. [Figure 3] 10 illustrates a method for allocating transactions to shards according to a third embodiment of the present disclosure. [Figure 4] 10 illustrates a method for allocating transactions to shards according to a fourth embodiment. [Figure 5] 1 shows a prior art UTXO data structure. [Figure 6]5 illustrates a fifth embodiment of the present disclosure. [Figure 7a] 10 illustrates a sixth embodiment of the present disclosure. [Figure 7b] 10 illustrates a sixth embodiment of the present disclosure. [Figure 8a] 7 illustrates a seventh embodiment of the present disclosure. [Figure 8b] 7 illustrates a seventh embodiment of the present disclosure. [Figure 9] FIG. 1 is a schematic diagram illustrating a computing environment in which various embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0042] In current blockchain networks, different nodes are connected peer-to-peer in a largely unstructured manner (other than a number of hard-coded network seeds in Bitcoin clients to aid in node discovery). These nodes communicate to share information about valid transactions, blocks, and other nodes.

[0043] [Sharded network structure] A first embodiment of the present disclosure can be seen in Figure 1b, which shows the structure of a sharded blockchain network according to the present disclosure, while Figure 1a shows the structure of an existing, i.e., prior art, blockchain network.

[0044] According to the present disclosure, to reduce a party's reliance on having expensive, powerful computational resources to participate in a given level of involvement in a blockchain network, a party may be allowed to be a member of any number of shards in a sharded blockchain network. This means that a small party, including a hobbyist, may choose to be a member of a single shard in the network shown in FIG. 1b, while a large party, such as a financial institution, may choose to be a member of many or all shards in the sharded blockchain network of FIG. 1b. This approach accommodates entities or parties that may require security of transaction history, for example, by allowing parties that desire or require greater security to approve and store all transactions in the blockchain, while ensuring that other parties or entities that may not desire or require the same (greater) level, or that may desire less involvement, may also participate in the same sharded blockchain network of FIG. 1b but store only a subset of the blockchain.

[0045] As seen in FIG. 1b, a particular node can be a member of more than one shard group. This can be seen from the shaded lines shown in this figure, with nodes in the shaded area being members of both Shard 2 and Shard 3. For communication purposes, current Bitcoin networks and Bitcoin SV (BSV) clients maintain a list of available peers, i.e., nodes in the network maintain information about nodes they can connect to, nodes they can distribute to, and nodes they can receive from. In a sharded blockchain according to the first embodiment, additional information is maintained, including which shards each node is a member of. In some implementations, to handle transaction propagation between networks, each node shown in the sharded network in FIG. 1b is arranged or configured to communicate with at least one node from each shard to propagate those transactions destined for different shards. In some implementations, the information maintained by each node may be in the form of a data structure to indicate nodes they can connect to, nodes they can distribute to, nodes they can receive from, and the shards to which they belong in the sharded network shown in FIG. 1b. Other details associated with the node, such as identifiers, entity associations, etc., may also be maintained. This data structure may be held in memory associated with each node, or may be held in memory associated with a shard, for example.

[0046] A second embodiment, relating to a sharded network as shown in Figure lb, describes a technique in which a node communicates with multiple other nodes within a single shard, which advantageously prevents "Sybil-style" attacks within a blockchain network.

[0047] A Sybil attack is an attack in which a single adversary or malicious entity may control multiple nodes on a network that are unknown to the network. For example, an adversary may create multiple computers and IP addresses, or they may create multiple accounts / nodes in an attempt to pretend that all of the accounts / nodes exist. A manifestation of such an attack can be seen in the following example implementation: If an attacker attempts to flood the network with clients they control, nodes will very likely connect only to the attacker's node. For example, an attacker can refuse to relay blocks and transactions for a node, effectively disconnecting that particular node from the network. This can also manifest by the attacker relaying blocks that it created, effectively placing the node or entity on a separate network, thereby isolating the node and transactions associated with that node or entity, which represents an opening for double-spend attacks. Thus, Sybil attacks are problematic for existing blockchain networks.

[0048] To prevent Sybil attacks in a sharded blockchain network such as that shown in FIG. 1b, according to a second embodiment, nodes are configured to communicate with multiple or all other nodes within a single shard. As noted above, a Sybil attack can effectively ignore transactions sent from a particular node, further preventing their propagation through the network. Thus, the second embodiment of the present disclosure provides a technique that allows nodes within a given shard to exchange information about nodes in other shards and rotate their usage, as seen in FIG. 2.

[0049] According to the second embodiment, each node in a sharded network can broadcast all transactions to each other. If a given node is not a member of the shard associated with a transaction (this association is described below with reference to the third and fourth embodiments), then instead of performing a full transaction approval, it performs basic transaction-level checks before propagating further. Note that in some implementations, the protocols and rules described above in connection with the second embodiment may also be considered associated with and part of one or more or all of the other embodiments of the present disclosure described herein.

[0050] Details about other nodes at different or specific times / instances can also be shared among nodes within a particular shard. This is performed using a modified version of the addr protocol message according to a second embodiment of the present disclosure. The implementation of the addr message currently present 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 set of known active peers (e.g., for bootstrapping). The addr message often contains only one address, but may contain more, in some instances up to 1,000. In some instances, all nodes periodically, i.e., every 24 hours, broadcast an addr message containing their IP address. Nodes may then relay these messages to their peers and, if new, may remember the relayed address. In this way, nodes in the network may have a reasonably clear understanding of which IPs are connected to the network at the time of joining or thereafter. In most cases, the IP address is added to everyone's address database due to the initial addr broadcast.

[0051] 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, the broadcast as part of the addr message may also include a field identifying 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. In some embodiments, the modified addr protocol may also include the state of the shards of which the node is a member and / or the state of the node itself. For example, details of the number of nodes in each member shard may be identified, or whether a particular shard is active or the number of active nodes in a given shard may also be identified.

[0052] [Assigning transactions to shards in a sharded network] As mentioned above, in a sharded blockchain network, transactions are not accepted and stored by all nodes, but instead are assigned to one or more specific shards. Therefore, a strategy is needed to assign transactions to different shards. Two possible embodiments are described below, which are referred to as "transaction ID-based" sharding according to a third embodiment of the present disclosure and "input-based" sharding according to a fourth embodiment of the present disclosure.

[0053] In some implementations, the existing Bitcoin protocol may undergo a fork to initiate either method. When a node in a given shard subsequently receives a transaction, the node may check that it is being sent to the correct shard. This approach provides for balancing of transactions between shards.

[0054] Any sharding method may be applied to a blockchain retroactively and to any extent, i.e., any method may be applied such that the sharded network is defined to exist from the time of the first block in the blockchain (the so-called genesis block in the case of the Bitcoin blockchain) to an arbitrarily chosen block number in the future.

[0055] The sharding methods described below may be applied multiple times, sequentially and in any order. For example, transaction ID sharding may be performed first, and input-based sharding may be performed at a later date. Furthermore, as described above, either method may be applied retroactively, and either method may be applied subsequently. The number of shards, n, may be selected each time a sharding method is applied, allowing the protocol to scale by increasing the number of nodes. The number of nodes may be selected based on the number of total nodes on the network, the size of the blockchain, and / or other characteristics. For both sharding methods described below, the manner in which transactions are stored by each node when sharding occurs is also described.

[0056] [Transaction ID-based shard distribution] In a horizontally partitioned blockchain, each shard does not contain or process all transactions on the network, so a strategy is needed to allocate transactions to different shards. Furthermore, any sharding method must be capable of further sharding. In a third embodiment of the present disclosure, transaction distribution among shards is handled based on transaction ID (txid), as described with reference to FIG. 3.

[0057] In step 302, a transaction ID for a given transaction is created, denoted as txid. In some implementations, this txid is obtained as a result of applying a SHA256 function to the transaction data.

[0058] Using this transaction ID, an action is performed based on the txid and the number of available shards in the sharded network in step 304. In some implementations, a modulo of the number of shards currently active on the blockchain network is applied to the transaction ID, i.e., shard number = txid mod n, where n is the number of shards (given or active).

[0059] In step 306, the result of step 304 corresponds to the shard to which the given transaction is assigned.

[0060] In step 308, once assigned in step 306, the transaction is distributed to the identified shards, i.e., the transaction is distributed to the nodes included in the shards identified in step 306.

[0061] Thus, when a node in a given shard receives a transaction, the node can easily check that it has been sent to the correct shard. In some embodiments, such a check may be accomplished based on a data structure associated with each node that contains information related to the node, as described above in the first embodiment. Advantageously, this approach provides an even balance of transactions among shards.

[0062] The shard count on the network is The total number of nodes on the network, and Blockchain size The selection can be made arbitrarily based on a number of parameters, including:

[0063] [Input-based shard distribution] A sharding method according to the fourth embodiment of the present disclosure will be described with reference to the flow diagram of FIG.

[0064] In this embodiment, an input for a given transaction is identified in step 402. In some implementations, this is the first input for the transaction.

[0065] In step 404, the outputs of previous transactions referenced by the inputs of step 402 are identified.

[0066] In step 406, the results of steps 402 and 404, i.e., both the corresponding input and the output from the previous transaction, are assigned to the same shard in a sharded network such as that shown in FIG. 1b. In some implementations, this step includes identifying a shard to assign both transactions to. In one example, this may be the shard associated with the previous transaction if it has already been assigned. In other examples, as described above, a response to a fix-addr broadcast or getaddr request for either the given transaction or the previous transaction may be used to identify the shard. In other examples, a shard may be selected randomly or as specified, i.e., based on a rotation, for both transactions, as long as both transactions are assigned to the same shard. This may apply, for example, when no parent transaction is identified, i.e., when the received transaction is a coinbase transaction.

[0067] Step 408 indicates that the above process in steps 402-406 is repeated to generate a chain of transactions linked by the first input.

[0068] A transaction whose output is referenced by the first input of a subsequent transaction is called the "parent" transaction in this context, and the subsequent transaction is called the "child" transaction.

[0069] It should be noted that the use of the first input to define the parent in step 402 is not required by the method; if multiple inputs are present in a given transaction, any input may be selected to perform the method. For example, a previous transaction may be defined as the parent of a child transaction if a certain number of the child transaction's inputs reference outputs in the same shard as the parent. The number of inputs may be defined as a majority of the child transaction's inputs. Thus, in some implementations described above in step 406, the assigned shard will be the same as that of the identified parent, based on either the number of inputs or the actual first input or other specified specific input to be considered.

[0070] It should be noted that the above two sharding methods of the third and fourth embodiments may be performed sequentially in either order, and the two methods may be performed multiple times as desired. For example, a blockchain network may be forked according to the input-based distribution of the fourth embodiment, and then one or more of the resulting branches may be sharded according to the transaction ID-based distribution of the third embodiment.

[0071] [UTXO Set / Memory Pool Sharding] Currently, in the Bitcoin network, every node maintains its own UTXO set, which is checked and updated during confirmation. An example UTXO set is shown in Figure 5.

[0072] According to a fifth embodiment of the present disclosure, in a sharded blockchain (shown in FIG. 1b), each member node of one or more shards has a UTXO set for transactions associated with each shard of which the node is a member. This is further illustrated in FIG. 6, which shows nodes that are members of more than one shard. These are seen in this figure by overlapping distinctly shaded areas. It will be understood that in some implementations, with respect to the fifth embodiment, such a UTXO set (hereinafter referred to as sharded UTXOs) may be considered part of, and as part of, one or more or all of the other embodiments of the present disclosure described herein.

[0073] [Transaction Approval] For a transaction to be approved, the UTXO set must be checked and updated in the Bitcoin network. This disclosure provides a new version of this process for implementing approval on a sharded blockchain when the UTXO set is sharded. As noted above, each node on a sharded blockchain, such as that of FIG. 1b, is associated with or maintains a list of nodes on the network, including information about the shards of which it is a member. This was described above in connection with the first embodiment.

[0074] Two methods that can be used to check the UTXO set for transaction confirmation according to the present disclosure are described below, which are referred to as transaction shard confirmation according to the sixth embodiment and UTXO shard confirmation according to the seventh embodiment, respectively.

[0075] [Transaction shard approval] In the sixth embodiment, transaction validation is performed by the shard to which the transaction is assigned. As described above with respect to the third embodiment, transactions are distributed to shards using the result of a modulo function applied to the transaction ID. Because a transaction may have inputs from different shards, the validating node communicates with other shards for UTXO checks.

[0076] The checking of UTXO sets between nodes in different shards is described with reference to Figure 7a, and this process is also described in relation to Figure 7b.

[0077] According to the sixth embodiment, a node in shard 4 makes a request to a node in shard 1 that is known to obtain the UTXO. This is seen in step 702. The shard numbers are specified for illustrative purposes only; any given node associated with any given shard may perform this request.

[0078] The validity of the received response is then evaluated in step 704. If no node has the UTXO, a null response is given. In this case, the transaction in question is deemed invalid in step 706. In this case, no further propagation of the transaction occurs. In some cases, a transaction is also deemed invalid if there is a script error or any indication that the UTXO is unavailable.

[0079] If the UTXO for a given transaction is received, then in step 708, the transaction input is considered valid. As discussed in the Background section, it is known that a software client or program or application installed on a node may perform this validation on the UTXO by executing its lock and unlock script. In some implementations, this is referred to as the transaction's validity data. If execution of the lock and unlock script evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Furthermore, as discussed above, one validity check is to check that no double spends exist. In some implementations, when a node receives a transaction, it looks up the UTXO that the transaction uses in a data structure associated with the node or in the data structure of the associated shard.

[0080] Then, in step 710, the transaction in question is added to shard 4 or a node on shard 4's memory pool.

[0081] Then, in step 712, the transaction is propagated to other nodes in shard 4.

[0082] [UTXO shard-based confirmation] In a seventh embodiment, a transaction is propagated to a shard (a shard of a sharded network such as that shown in Figure 1b) that contains the UTXO of the given transaction.

[0083] Figure 8a shows that a spend transaction (Tx) created by a node in shard 4 is propagated to each of the shards that contain the UTXO for that transaction. In this embodiment, the node sends the transaction to both shards 1 and 2. This process is further illustrated in Figure 8b.

[0084] In step 802, when a node in a shard receives a given transaction, in this embodiment it proceeds to approve the transaction based on inputs that are in the same shard.

[0085] Thus, in step 804, it is checked whether the inputs of a given transaction relate to the same shard. Transactions may be assigned to shards as described above in accordance with the fourth embodiment. As described above, if a node is a member of more than one shard, the "same" shard check in this step applies to any such shard.

[0086] As seen in step 806b, inputs associated with UTXOs in different shards are not confirmed. In some implementations, confirmation of each input may be performed in much the same way as confirmation is currently performed in the Bitcoin network. If not, in step 806a, the node proceeds to confirm the transaction.

[0087] Following step 806a, in step 808, the validity of the inputs associated with a given transaction is checked. As noted above, and also in steps 706 and 708 of FIG. 7b, approval of an unspent transaction (UTXO) may be by executing its lock and unlock script. In some implementations, this is referred to as the transaction's validity data. If execution of the lock and unlock script evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Additionally, and as noted above, one validity check is to check that no double spends exist. In some implementations, when a node receives a transaction, it looks up the UTXOs that the transaction uses in a data structure associated with the node or a data structure associated with the node's shard.

[0088] If the input is invalid, such as if the UTXO does not exist, if the value is greater than the UTXO, or if there is a script error, the given transaction is discarded, as seen in step 810b, in which case the given transaction is not propagated to other nodes in the same shard.

[0089] If the input is deemed valid, then in step 810a the transaction is identified as valid.

[0090] The transaction is then added to the node's memory pool in step 812 .

[0091] In step 814, the transaction is propagated to other nodes in the shard associated with the node.

[0092] 9, a simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided by way of example. In various embodiments, the computing device 2600 may be used to implement any of the computer-implemented systems, methods, or protocols shown and described above on a node or combination of nodes within one or more shards of a sharded blockchain network such as that shown in FIG. 1b, and / or alone or when communicatively coupled to one or more such nodes or systems.

[0093] For example, 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 , computing device 2600 may include one or more processors having one or more levels of cache memory and a memory controller (collectively labeled 2602) that may be configured to communicate with a storage subsystem 2606 including main memory 2608 and persistent storage 2610. Main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620, as shown. Storage subsystem 2606 and cache memory 2602 may be used for storage of information such as details related to transactions and blocks described in this disclosure. Processor 2602 may be utilized to provide the steps or functionality of any of the embodiments described in this disclosure.

[0094] The processor 2602 can also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0095] 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 schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0096] Network interface subsystem 2616 may provide an interface to other computing devices and networks. Network interface subsystem 2616 may act as an interface for receiving data from other systems and transmitting data from computing device 2600 to other systems. For example, network interface subsystem 2616 may allow a data technician to connect the device to a network so that they can transmit data to and receive data from the device while at a remote location, such as a data center.

[0097] 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 touchscreen integrated into a display, an audio input device such as a voice recognition system, a microphone, and other types of input devices. In general, use of the term "input device" is intended to encompass all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0098] 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, 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. The one or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with applications that perform the processes and variations thereof described herein, when user interaction may be appropriate.

[0099] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide the 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 the 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 also provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The persistent storage 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid-state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM, DVD, or Blu-ray) with associated removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments described in this disclosure and data related to transactions and blocks described in this disclosure.

[0100] 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.). A device 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 connecting 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 .

[0101] It should be noted that the above-described embodiments illustrate rather than limit 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 between parentheses shall not be construed as limiting the scope of the claim. The use of terms such as "comprising" and "comprises" does 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 element does not exclude a reference to a plural of such elements, 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.

[0102] 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. While the present disclosure has been described with reference to certain exemplary implementations, it is recognized that the 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 approving a first blockchain transaction in a blockchain network partitioned into multiple shards, comprising: Each shard includes at least one node, and each node in the blockchain network is a member node of at least one of the shards; Each blockchain transaction in the network is assigned to an identified shard of the plurality of shards, and when assigned, each blockchain transaction is distributed to nodes of the identified shard, and each node of the identified shard includes a UTXO set related to the blockchain transaction in the identified shard; requesting at least one UTXO referenced by at least one respective input of the transaction from at least one member node of the shard having a UTXO set containing the at least one UTXO; obtaining validity data for the at least one UTXO from a member node of the shard; performing an approval check on said at least one respective input using said validity data; communicating the node's shard membership information to other nodes; A method comprising:

2. The method of claim 1 , further comprising communicating the node's request for shard membership information to other nodes.

3. 3. The method of claim 1, wherein the communication is performed using a modify-addr message.

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

5. A non-transitory computer-readable storage medium having stored thereon executable instructions that, 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 3.

Images