Blockchain network partitioning

Abstract

A computer-implemented method of partitioning a blockchain network into slices is disclosed, the method comprising: identifying a parent blockchain transaction, the parent transaction defined by an output corresponding to an input of a child blockchain transaction; and allocating the parent transaction and the child transaction to the same fragment.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201980028770.8 (PCT international application number PCT / IB2019 / 053380), application date April 24, 2019, and name “Blockchain Network Partitioning”. Technical Field

[0002] The present disclosure relates to a method for partitioning a blockchain network and a method for verifying transactions of a partitioned blockchain network, and particularly but not exclusively to a method for partitioning an unspent transaction output (UTXO) set of a blockchain and a method for verifying transactions of the UTXO set of the partitioned blockchain. Background Art

[0003] In this document, we use the term "blockchain" to cover all forms of computer-based electronic distributed ledgers. This includes consensus-based blockchain and transaction chain technologies, permissioned and permissionless 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 the present disclosure. The term "user" in this article can refer to human-based or processor-based resources.

[0004] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system that consists of multiple blocks, which in turn consist of multiple transactions. Each transaction is a data structure that encodes the transfer of control of digital assets in the blockchain system between participants and includes at least one input and at least one output. Each block contains a hash of the previous block, so blocks are linked together to create a permanent, unchangeable record of all transactions that have been written to the blockchain since its creation. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. On some platforms, these scripts are written using a stack-based scripting language.

[0005] In order for a transaction to be written to the blockchain, it must be “validated”. Network nodes perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. The software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, then the transaction is valid and the transaction is written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must be: i) validated by the first node that receives the transaction – if the transaction is validated, then that node relays it to other nodes in the network; and ii) added to a new block; iii) added to the public ledger of past transactions.

[0006] Digital entrepreneurs have begun exploring the implementation of new systems using both cryptographically secure systems and data that can be stored on blockchain. It would be extremely advantageous if blockchain could be used to automate tasks and processes. Such solutions would be able to leverage the benefits of blockchain (e.g., permanent, tamper-proof evidential records of events, distributed processing, etc.) while being more versatile in their applications.

[0007] As mentioned above, a blockchain network is a secure distributed computing system. All nodes of the system will keep and manage a copy of the entire blockchain, send and receive transactions, verify them, and add blocks to the blockchain based on a shared decentralized consensus protocol. This approach, while secure, does have drawbacks that need to be overcome related to the fact that every transaction is verified and stored by every full node. In terms of verification, this causes delays in the propagation of transactions through the network, as each transaction needs to be verified before it can continue to propagate. In addition, the network delays attributed to verification make it more vulnerable to "double-spend" related attacks, such as Sybil attacks. Summary of the invention

[0008] The present disclosure aims to improve the scalability, speed, reliability and security of blockchain networks by using horizontal partitioning (also known as sharding) and technologies or protocols related to distributing and / or verifying transactions on sharded blockchain networks. Disclosed herein are:

[0009] The network structure of the blockchain after sharding; and

[0010] The structure of UTXO and memory pool after sharding.

[0011] The partitioning of this technology considers two specific dimensions: horizontal and vertical. In the partitioned parts of the database that are partitioned horizontally (called shards), there are actually multiple instances of a specific database schema, and the data is spread in each instance, thereby reducing instance redundancy. However, vertical partitioning is to split a given database schema across multiple nodes, thereby expanding the properties of specific objects using a normalized approach.

[0012] Parties wishing to participate in a blockchain network may have a variety of computing resources, from small low-power machines to server farms. As a result, parties are limited by computing resources to a predetermined level of participation in the blockchain network.

[0013] The blockchain itself is a linked set of transactions that mark specific changes in the ownership of the coins mined when a block is created. During transaction validation, one of the checks that needs to be done is to check for double spends. A double spend is when a transaction output has been referenced in the mempool or in the inputs of a transaction that has been confirmed on the blockchain. The mempool is a reference to the pool or area of ​​memory for transactions that each full node maintains itself. Traditionally, after a transaction is validated by a node, it sits in the mempool until it is inserted into a block. In order to make transaction validation more efficient in terms of transaction input checking, instead of validating the entire blockchain, the current state of the network is saved in a separate structure called the UTXO set. This structure contains every transaction output that has not yet been spent by a transaction, which can include both coinbases and standard transactions.

[0014] According to one aspect of the present disclosure, a computer-implemented method for dividing a blockchain network into shards is provided. The method includes: identifying a transaction ID of a blockchain transaction; and assigning the transaction to a shard based on the transaction ID.

[0015] Dividing a blockchain network into multiple shards enables users to choose their level of participation in the blockchain network. Each user can choose to be a member of one or more shards. As a user who is a member of fewer shards than all shards, the user requires less storage space to store all transactions assigned to the shards to which the user belongs. Assigning transactions to shards based on transaction IDs has the following advantages: the resulting shards will be roughly equal in size, thereby avoiding undue burden on members of larger shards relative to members of smaller shards, while enabling transactions and related verifications to be accurately executed without any undue delays.

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

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

[0018] These specific structures, methods of data flow, 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 related methods for allocating transactions and verifying transactions after allocation in a sharded blockchain network described herein enable the implementation of novel techniques for data flow, data storage, and UTXO verification checks. In addition, given the structure and data communication / verification protocol, these techniques advantageously prevent double-spending attacks, such as Sybil attacks.

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

[0020] This provides the advantage of adjusting the arrangement of the plurality of shards according to the selection of the operation.

[0021] The operation may include a modulo operation.

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

[0023] According to the present disclosure, another computer-implemented method for partitioning a blockchain network into shards is provided. The method includes: 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.

[0024] Dividing a blockchain network into multiple shards enables users to choose their level of participation in the blockchain network. Each user can choose to be a member of one or more shards. As a user who is a member of fewer shards than all shards, the user requires less storage space to store all transactions assigned to the shard to which the user belongs. Assigning transactions to shards based on identifying a parent blockchain transaction, which is defined by the outputs corresponding to the inputs of a child blockchain transaction, and assigning parent and child transactions to the same shard has the following advantages: verification operations performed by users who are members of a particular shard may require less information to be transmitted back and forth with users who are members of different shards, because the child transaction being verified will always have a parent transaction that is a member of the same shard.

[0025] The present disclosure accordingly relates to a computer-implemented method for distributing transactions associated with a blockchain network, wherein the blockchain network is divided into a plurality of shards, each shard comprising at least one node, and wherein each node in the blockchain network is associated with at least one shard of the plurality of shards, the method comprising the steps of: identifying an input of a given transaction; identifying an output of an earlier transaction corresponding to the input of the given transaction; determining that the earlier transaction is a parent transaction of the given transaction and that the given transaction is a child transaction; identifying a shard among the plurality of shards; distributing the parent transaction and the child transaction to the identified shard among the plurality of shards; and distributing the parent transaction and the child transaction to at least one node of the determined shard.

[0026] The parent transaction can be identified using one of the multiple inputs of the child blockchain transaction. The input to be used is selected based on its index. This index can be 1, in which case the input used is the first input of the multiple inputs.

[0027] This provides the advantage of being able to assign a sub-transaction with multiple inputs to a shard.

[0028] The parent transaction can be identified using the largest subset of inputs (largest subset of inputs) among the multiple inputs of the child blockchain transaction. For example, in an instance where the child transaction has five inputs, two of the five inputs refer to two outputs of an earlier transaction, and each of the remaining three inputs refer to three different earlier transactions, then the parent transaction is defined as the earlier transaction to which both inputs refer, since they are the largest subset of inputs.

[0029] This has the advantage of reducing the amount of information required from users who are members of different shards for subtransactions with multiple inputs.

[0030] In some embodiments, the method includes the steps of communicating or broadcasting shard membership information of a node to all other nodes in a shard associated with the node and / or one or more other nodes in the network. The method also includes performing the communication using a modified addr message, wherein the modified addr message includes an indication of one or more shards associated with the node.

[0031] According to the present disclosure, there is also provided a computer-implemented method for verifying a blockchain transaction. The method includes: requesting at least one UTXO referenced by at least one corresponding input of a transaction from a member node of at least one shard including 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.

[0032] This method enables the verification of blockchain transactions in a sharded blockchain network. This method provides the advantage that each user can choose to be a member of one or more shards, and as a user who is a member of fewer shards than all shards, the user requires less computing power to verify all transactions assigned to the shards to which the user belongs.

[0033] According to the present disclosure, there is also provided a computer-implemented method for distributing and verifying transactions associated with a blockchain network, wherein the blockchain network is divided into a plurality of shards, each shard comprising at least one node, and wherein each node in the blockchain network is associated with at least one shard of the plurality of shards, the method comprising the following steps: at a first node:

[0034] Identify a transaction ID of a blockchain transaction; determine a shard among the plurality of shards based on the transaction ID and the number of shards among the plurality of shards; assign the transaction to the determined shard; distribute the transaction to the at least one node in the determined shard; request at least one UTXO referenced by at least one corresponding input of the transaction from a node of at least one shard among the plurality of shards that includes at least one UTXO; obtain validity data for the at least one UTXO; and perform a validation check on the at least one input using the validity data.

[0035] Optionally, the method further comprises the steps of: performing an operation using the transaction ID; and wherein the step of assigning the transaction to the identified shard is based on a result of the operation. Optionally, the operation comprises a modulo operation.

[0036] According to the present disclosure, there is also provided a computer-implemented method for verifying a blockchain transaction. The method includes: identifying at least one shard, the at least one shard including at least one UTXO referenced by at least one corresponding input of the transaction; transmitting the transaction to at least one member node of the at least one shard; and using the validity data of the UTXO to perform a verification check on at least one input.

[0037] This method enables the verification of blockchain transactions in a sharded blockchain network. This method provides the advantage that each user can choose to be a member of one or more shards, and as a user who is a member of fewer than all shards, the user requires less computing power to verify all transactions assigned to the shards to which the user belongs.

[0038] Any of the above methods may also include the following step: communicating a request for shard membership information of a node to another node.

[0039] This provides the advantage that a node seeking shard membership information is provided with a mechanism to more easily locate that information.

[0040] Any of the above methods may also include the following step: communicating shard membership information of one node to another node.

[0041] This provides a mechanism for communicating a node's shard membership information between nodes, thereby providing the advantage of reducing the likelihood that a node will be unable to perform a validation operation.

[0042] The communication can be performed using the modified addr message.

[0043] This provides the following advantages: It provides a mechanism for nodes to more securely exchange shard membership information.

[0044] The present disclosure also provides a system, comprising:

[0045] Processor; and

[0046] A memory including executable instructions, the executable instructions, due to being executed by the processor, causing the system to perform any embodiment of the computer-implemented method described in the present disclosure.

[0047] The present disclosure also provides a non-transitory computer-readable storage medium having executable instructions stored thereon, where the executable instructions, when executed by a processor of a computer system, cause the computer system to perform at least one embodiment of the computer-implemented method described in the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Preferred embodiments of the present disclosure are described below in a general and non-limiting manner with reference to the accompanying drawings, in which:

[0049] Figure 1a and 1b The traditional blockchain network ( Figure 1a ) and the sharded blockchain according to the first embodiment of the present disclosure ( Figure 1b )Comparison between networks.

[0050] Figure 2 The diagram shows nodes that are used in turn in the second embodiment of the present disclosure.

[0051] Figure 3 A method for allocating transactions to shards according to a third embodiment of the present disclosure is shown.

[0052] Figure 4 A method of allocating transactions to shards according to a fourth embodiment is shown.

[0053] Figure 5 The UTXO data structure of the prior art is shown;

[0054] Figure 6 A fifth embodiment of the present disclosure is shown;

[0055] Figure 7a and 7b shows a sixth embodiment of the present disclosure; and

[0056] Figure 8a and 8b A seventh embodiment of the present disclosure is shown.

[0057] Fig. 9 A schematic diagram of a computing environment in which various embodiments of the present disclosure may be implemented is shown. DETAILED DESCRIPTION

[0058] In current blockchain networks, different nodes are connected peer-to-peer in a largely unstructured manner (aside from many hard-coded network seeds in the client that help discover nodes). These nodes communicate to share valid transactions, blocks, and information about other nodes.

[0059] The structure of the sharded network

[0060] exist Figure 1b The first embodiment of the present disclosure can be seen in , which depicts the structure of the sharded blockchain network according to the present disclosure. On the other hand, Figure 1a The structure of an existing (i.e., prior art) blockchain network is shown.

[0061] According to the present disclosure, in order to reduce the reliance of multiple parties participating in a blockchain network at a predetermined level of participation on expensive and powerful computing resources, each party may be allowed to become a member of any number of shards in a sharded blockchain network. Figure 1b This means that small groups, including enthusiasts, can choose to become Figure 1b shard in the network shown, while larger groups (such as financial institutions) can choose to become members of Figure 1b Members of many or even all shards in the sharded blockchain network shown. This approach is suitable for entities or participants who may need transaction history security, for example, to ensure that those participants who intend or need higher security can verify and store every transaction in the blockchain, while other participants or entities may not expect or need the same (higher) level of participation or may need lighter participation, or may participate in the same Figure 1b The same sharded blockchain network may only store a subset of the blockchain.

[0062] like Figure 1b As shown in , a particular node can be a member of one or more shard groups. As shown by the shaded lines in the figure, the nodes in the shaded area are members of shards 2 and shard 3. For communication, in some current networks and some clients, the list of available peers (i.e., nodes in the network) contains information about multiple nodes that it can connect to, distribute to, and receive from. In the sharded blockchain according to the first embodiment, additional information is retained, including which shard each node belongs to. In some implementations, in order to handle transaction propagation across the network, Figure 1b Each node in the sharded network is arranged or configured so that it can communicate with at least a single node from each shard to propagate transactions destined for different shards. In some embodiments, the information held by each node can take the form of a data structure to indicate the nodes it can connect to and distribute to, as well as the nodes and Figure 1b The shards to which it belongs in the sharded network shown. Other details related to the node may also be saved, such as identifiers, entity associations, etc. For example, the data structure may be saved in a memory associated with each node, or may be saved in a memory associated with a shard.

[0063] In such Figure 1b In the second embodiment of the sharded network, a technique for a node to communicate with multiple other nodes in a single shard is described. This technique advantageously prevents "sybil-type" attacks in the blockchain network.

[0064] A Sybil attack is an attack where a single adversary or malicious entity may control multiple nodes on a network without the network's knowledge. For example, an adversary may create multiple computers and IP addresses, and possibly also multiple accounts / nodes, to pretend that they all exist. This attack can be seen in action with the following example implementation. If an attacker attempts to saturate the entire network with clients they control, it is likely that nodes will only connect to the attacker's node. For example, an attacker could refuse to relay blocks and transactions for that node, effectively disconnecting that particular node from the network. This also manifests itself in an attacker relaying blocks that they have created, effectively placing the node or entity on a separate network, making the node and the transactions associated with that node or the entity it represents vulnerable to double-spending attacks. Sybil attacks are therefore a problem for existing blockchain networks.

[0065] To prevent Figure 1b The sharded blockchain network shown is subject to a Sybil attack. According to a second embodiment, a node is configured to communicate with multiple or all other nodes within a single shard. As described above, a Sybil attack can effectively ignore transactions sent from a specific node, thereby preventing them from propagating further through the network. Therefore, in the second embodiment of the present disclosure, Figure 2 As shown, nodes in a given shard can exchange information about nodes in other shards and take turns.

[0066] According to the second embodiment, each node in the sharded network can broadcast each transaction to each other. If a given node is not a member of the shard associated with a transaction (this association will be described below with reference to the third and fourth embodiments), full transaction validation will not be performed, but basic transaction level checks will be performed before continuing to propagate forward. It should be noted that in some embodiments, the protocols and rules discussed above with respect to the second embodiment are related to and considered part of one or more or all other embodiments of the present disclosure discussed herein.

[0067] At different or specific times / instances, detailed information about other nodes can also be shared between multiple nodes in a specific shard. According to a second embodiment of the present disclosure, a modified version of the addr protocol message is used to perform sharing. The current addr message is implemented 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 large number of known active peers (for example, for bootstrapping). The addr message usually contains only one address, but sometimes contains more addresses, in some examples, up to 1000 addresses. In some examples, all nodes broadcast addr containing their own IP addresses periodically (i.e., every 24 hours). The node can then relay these messages to its peers and can store the relayed addresses (if new to them). In this way, nodes in the network can clearly understand which IPs are connected to the network when or after connecting to the network. In most cases, due to the initial addr broadcast, the IP address is added to everyone's address database.

[0068] In addition to the above, the implementation of the modified addr protocol according to the present disclosure can also transmit additional information on one or more slices of a specific node. For example, in the modified addr protocol, when a shared network (such as Figure 1b ) joins a particular shard in the network, the content broadcast as part of the addr message may also include a field that identifies the shard or shards to which it belongs. Figure 1b A getaddr request to a peer in the network returns this information. As discussed in the first embodiment, such information can be based on a data structure associated with each node and / or each shard associated with the node. In some embodiments, the modified addr protocol also includes the state of the shard to which the node belongs and / or the state of the node itself. For example, detailed information on the number of nodes in each member shard can be identified, or whether a particular shard is active, or the number of active nodes in a given shard can also be identified.

[0069] Assigning transactions to shards in a sharded network

[0070] As described above, in a sharded blockchain network, transactions are not verified and stored by each node, but are assigned to one or more specific shards. Therefore, a strategy for assigning transactions to different shards is needed. Two possible embodiments will be described below and will be referred to as "transaction id-based" sharding according to the third embodiment of the present disclosure and "input-based" sharding according to the fourth embodiment of the present disclosure.

[0071] In some implementations, the existing protocol may undergo a fork to enable either approach. When nodes in a given shard subsequently receive a transaction, they can check that it has been sent to the correct shard. This approach provides transaction balancing across shards.

[0072] Each sharding approach is traceable and applicable to any degree to a blockchain. That is, any approach can be used to define a sharded network from the time the first block in the blockchain (called the genesis block in the case of some blockchains) is established until an arbitrarily chosen block number in the future.

[0073] The sharding methods described below can be applied multiple times in sequence and in any order. For example, in a first instance, transaction id-based sharding can be performed first, followed by input-based sharding. In addition, as described above, either of the two methods can be applied retroactively, and in addition, either of the two methods can be applied subsequently. Each time a sharding method is applied, the number of shards n can be selected, allowing the protocol to be expanded by increasing the number of nodes. The number of nodes can be selected based on the total number of nodes on the network, the size of the blockchain, and / or other characteristics. For the two sharding methods described below, the way in which each node stores transactions once sharding is performed will also be described.

[0074] Shard distribution based on transaction ID

[0075] In a horizontally partitioned blockchain, since each shard will not contain and process all transactions on the network, a strategy for assigning transactions to different shards is required. In addition, any sharding method needs to be able to perform further sharding. In the third embodiment of the present disclosure, by means of Figure 3 As explained, transaction distribution across shards is handled based on transaction id (txid).

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

[0077] In step 304, using the transaction id, an operation is performed based on the txid and the available number of shards in the sharded network. In some implementations, the modulus of the number of shards currently active on the blockchain network is applied to the transaction id, i.e., number of shards = txid mod n, where n is the number of shards (required or active).

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

[0079] In step 308 , once the allocation is made in step 306 , the transaction is allocated to the identified shard, that is, the transaction is allocated to the nodes included in the identified shard in step 306 .

[0080] Thus, when nodes in a given shard receive a transaction, they can easily check whether the transaction has been sent to the correct shard. In some embodiments, as discussed above in the first embodiment, this check is facilitated based on a data structure associated with each node that includes information associated with the node. Advantageously, this approach provides an even balance of transactions across shards.

[0081] The number of shards on a network can be arbitrarily chosen based on a number of parameters, including:

[0082] The total number of nodes on the network; and

[0083] The size of the blockchain.

[0084] Sharding distribution based on input

[0085] With the help of Figure 4 The flowchart in explains the slicing method according to the fourth embodiment of the present disclosure.

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

[0087] In step 404, the output of an earlier transaction to which the input in step 402 relates is identified.

[0088] In step 406, if Figure 1b As shown, the results of steps 402 and 404, i.e., the corresponding inputs and the outputs from the earlier transaction, are assigned to the same shard in the sharded network. In some implementations, this step includes identifying the shard to which the two transactions are assigned. In one example, if an earlier transaction has been assigned, the shard may be the shard associated with the earlier transaction. In another example, as described above, a modified address broadcast or a response to a getaddr request for a given or earlier transaction can be used to identify the shard. In other examples, as long as both transactions are assigned to the same shard, the shards of the two transactions can be selected based on a random or predetermined, i.e., rotation-based manner. For example, if the parent transaction is not identified, i.e., if a coinbase or a first transaction is received, the method can be applied.

[0089] Step 408 shows iterating the above process in steps 402 to 406 to generate a transaction chain linked by its first input.

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

[0091] It is noted that using the first input to define the parent in step 402 is not essential to the method. If there are multiple inputs in a given transaction, any input may be selected to perform the method. For example, if a particular number of inputs of a child transaction involve outputs of a transaction in the same shard as the parent, then the earlier transaction may be defined as the parent of the child transaction. The number of inputs may define the majority number of the child transaction's inputs.

[0092] It is noted that the above two sharding methods of the third and fourth embodiments may be performed sequentially in any order, and the two methods may be performed multiple times as needed. For example, the blockchain network may be forked based on the distribution of inputs in the fourth embodiment, and one or more of the resulting forks may be subsequently sharded based on the distribution of transaction ids in the third embodiment. Thus, in some implementations discussed above in step 406, the shards assigned will be the same as the shards of the identified parent based on the number of inputs or indeed the first or any other specified specific input to be considered.

[0093] UTXO Set / Mempool Sharding

[0094] In some current networks, each node maintains its own UTXO set and checks and updates it during the verification process. Examples of UTXO sets are Figure 5 shown.

[0095] According to the fifth embodiment of the present disclosure, in a sharded blockchain (e.g. Figure 1b ), each member node of one or more shards has a UTXO set associated with a transaction that is associated with each shard to which the node belongs. Figure 6 It is further explained in Figure 6 Nodes that are members of multiple shards are depicted. These can be seen in the distinct shaded areas that overlap in this figure. It will be appreciated that in some implementations, such UTXO sets (hereinafter referred to as sharded UTXOs) related to the fifth embodiment may be related to and considered part of one or more or all other embodiments of the present disclosure discussed herein.

[0096] Transaction Verification

[0097] In order to verify transactions, the UTXO set needs to be checked and updated in the network. This disclosure provides a new version of this process for implementing verification on sharded blockchains when the UTXO set is sharded. As described above, Figure 1bAs shown in , each node on the sharded blockchain is associated with or maintains a list of nodes on the network, which includes information about the shards to which they belong. This was discussed above with respect to the first embodiment.

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

[0099] Transaction Sharding Verification

[0100] In the sixth embodiment, transaction verification is performed by the shard to which the transaction is assigned. As described above with respect to the third embodiment, transactions are assigned to shards using the result of a modulo function applied to the transaction id. Because transactions can have inputs from different shards, the validation node communicates with other shards for UTXO checking.

[0101] refer to Figure 7a , we will now describe the UTXO set checks performed between nodes in different shards. And refer to Figure 7b The process is explained.

[0102] According to the sixth embodiment, the node in shard 4 makes a request to the node in shard 1 that it knows to obtain the UTXO. This can be seen in step 702. The designation of the shard numbers is for illustration only, and any given node associated with any given shard can perform the request.

[0103] The validity of the received response is then evaluated in step 704. If no node has the UTXO, an empty response is given. In this case, the transaction under consideration is considered invalid in step 706. In this case, no further propagation of the transaction will be performed. In some cases, for example, if a script error occurs or any transaction indicating that the UTXO is not available is also considered invalid.

[0104] In the case of receiving a given transaction UTXO, the transaction input is considered valid in step 708. As discussed in the background section, it is known that a software client or program or application installed on a node can perform this verification on the UTXO by executing its locking and unlocking scripts. In some implementations, this is referred to as the validity data of the transaction. If the execution of the locking and unlocking scripts is evaluated as TRUE, the transaction is valid and the transaction is written to the blockchain. In addition, as described above, one of the validity checks is to check whether double spending occurs. In some implementations, when a node receives a transaction, it will query the UTXO spent by the transaction in a data structure associated with the node or the associated shard.

[0105] In step 710, the transaction in question is then added to a node on Shard 4 or Shard 4's memory pool.

[0106] In step 712, the transaction is then propagated to other nodes in shard 4.

[0107] Verification based on UTXO sharding

[0108] In the seventh embodiment, the transaction is propagated to the (eg Figure 1b (a) multiple shards of the sharded network shown.

[0109] Figure 8a Figure 1 shows a spending transaction (Tx) created by a node in shard 4, which is propagated to each shard containing the transaction UTXO. In this example, the node sends the transaction to shard 1 and shard 2. This process is described in Figure 8b Further shown in .

[0110] When a node within a shard receives a given transaction in step 802, the node continues to verify the transaction based on the input within the same shard.

[0111] Thus, in step 804, it is checked whether the inputs of a given transaction are associated with the same shard. According to the fourth embodiment, transactions may be assigned to shards, as described above. As described above, if a node is a member of multiple shards, the "same" shard check in this step will apply to any such shards.

[0112] As shown in step 806b, the inputs associated with the UTXO in different shards are not verified. In some implementations, the verification of each input can be performed in the same manner as verification is currently performed in some networks. Otherwise, in step 806a, the node continues to verify the transaction.

[0113] Following step 806a, the input validity associated with a given transaction is checked in step 808. As described above, also in Figure 7b In steps 706 and 708 of , a validation may be performed on the unspent transaction (UTXO) by executing its locking and unlocking scripts. In some implementations, this is referred to as the validity data of the transaction. If the execution of the locking and unlocking scripts is evaluated to TRUE, then the transaction is valid and the transaction is written to the blockchain. In addition, as described above, one of the validity checks is to check if there is a double payment. In some implementations, when a node receives a transaction, it will look up the UTXO spent by the transaction in a data structure associated with the node or with the node's shard.

[0114] In the case of invalid input, for example, UTXO does not exist, or the value is greater than UTXO, or the script is wrong; then as shown in step 810b, the given transaction is discarded. In this case, the given transaction will not be propagated to other nodes in the same shard.

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

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

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

[0118] Now turn to Fig. 9 , provides an illustrative 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, when alone or when communicatively coupled to one or more other such nodes or systems, the computing device 2600 can be used to implement Figure 1b A node or combination of nodes in one or more shards of a sharded blockchain network as shown, and / or any computer-implemented system, method, or protocol as shown.

[0119] For example, computing device 2600 may 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 includes one or more processors with one or more high-level cache memories and a memory controller (collectively referred to as 2602), which can be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a permanent memory 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 can be used to store information, such as details associated with transactions and blocks described in the present disclosure. Processor 2602 can be used to provide the steps or functions of any embodiment described in the present disclosure.

[0120] The processor 2602 may 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 .

[0121] The bus subsystem 2604 may provide a mechanism for enabling the various 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 use multiple busses.

[0122] 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 receiving data from other systems and transmitting data to other systems by the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network, enabling the data technician to transfer data to and receive data from the device at a remote location (e.g., a data center).

[0123] The user interface input devices 2612 may include one or more user input devices such as a keyboard; a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen included in a display; an audio input device, such as a voice recognition system, a microphone; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0124] 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 cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projector or other display device. In general, use of the term "output device" is intended to include all possible types of devices and structures for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present interfaces to a user that facilitate user interaction with an application that performs the described processes and variations therein, when such interaction is appropriate.

[0125] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programs and data structures that provide the functions of at least one embodiment of the present disclosure. When the application (program, code module, instruction) is executed by one or more processors, the functions of one or more embodiments of the present disclosure may be provided 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 additionally provide a repository for storing data used according to the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The permanent storage 2610 may provide permanent (non-volatile) storage for programs and data, and may include flash memory, one or more solid-state drives, one or more magnetic hard drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM or DVD or Blue-Ray) drives with associated removable media and other similar storage media. Such programs and data may include programs for executing the steps of one or more embodiments described in the present disclosure, as well as data associated with transactions and blocks described in the present disclosure.

[0126] The computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 via one or more ports (e.g., USB, a headphone jack, a Lightning connector, etc.). The device that may be connected to the computing device 2600 may include a plurality of ports configured to accommodate fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may 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 purposes of illustrating preferred embodiments of the device, Fig. 9 The description of computing device 2600 depicted in FIG. 2 is intended only as a specific example. Fig. 9 Many other configurations of the systems shown with more or fewer components are possible.

[0127] It should be noted that the above embodiments illustrate rather than limit the present disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure as defined by the appended claims. In the claims, any reference numerals in parentheses shall not be interpreted as limiting the claims. The words "comprises" and "comprising" and the like do not exclude the presence of elements or steps other than those listed in any claim or in the specification as a whole. In this specification, "comprises" means "includes or consists of..." and "comprising" means "includes or consists of...". The singular form of an element does not exclude the plural form of such elements, and vice versa. The present disclosure may be implemented by hardware comprising several different elements and by appropriately programmed computers. In a device claim listing several means, several of these means may be embodied by one and the same hardware. The fact that certain measures are recorded in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.

[0128] It should be understood that the above description is intended to be illustrative rather than 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 will be appreciated that the present disclosure is not limited to the described embodiments, but can be practiced by modification and variation within the scope of the appended claims. Therefore, the description and drawings should be considered illustrative rather than restrictive. Therefore, the scope of the present disclosure should be determined with reference to the appended claims and the full scope of equivalents to which these claims are assigned.

Claims

1. A computer-implemented method for distributing and verifying transactions associated with a blockchain network, wherein: The blockchain network is divided into a plurality of shards, each shard includes at least one node, and wherein each node in the blockchain network is associated with at least one shard of the plurality of shards, the method comprising the following steps: at a first node: Transaction ID that identifies blockchain transactions; Determining a shard among the plurality of shards based on the transaction ID and the number of shards among the plurality of shards; Assigning the transaction to the determined shard; Distributing the transaction to the at least one node in the determined shard; requesting, from a node of at least one shard of the plurality of shards that includes at least one UTXO, at least one UTXO referenced by at least one corresponding input of the transaction; Obtaining validity data for the at least one UTXO; and A validation check is performed on the at least one input using the validity data.

2. The method according to claim 1, further comprising the steps of: Use the transaction ID to perform the operation. And wherein said step of assigning said transaction to said identified shard is based on a result of said operation.

3. The method according to claim 2, wherein: The operation includes a modulo operation.

4. The method according to any one of the preceding claims, further comprising the steps of: Communicates a request for shard membership information from one node to another node.

5. The method according to any one of the preceding claims, further comprising the steps of: Communicates a node's shard membership information to another node.

6. The method according to claim 4 or 5, wherein: The communication is performed using a modified addr message.

7. A system for distributing and verifying transactions associated with a blockchain network, wherein: The blockchain network is divided into a plurality of shards, each shard includes at least one node, and wherein each node in the blockchain network is associated with at least one shard of the plurality of shards, the system comprising: Processor; and A memory comprising executable instructions which, as a result of execution by a processor, cause the system to perform the computer-implemented method of any one of claims 1 to 6.

8. A non-transitory computer-readable storage medium for distributing and verifying transactions associated with a blockchain network, wherein: The blockchain network is divided into a plurality of shards, each shard comprising at least one node, and wherein each node in the blockchain network is associated with at least one shard of the plurality of shards, and the storage medium stores executable instructions, which, due to being executed by a processor of a computer system, cause the computer system to perform a computer-implemented method as described in any one of claims 1 to 6.

Images