Blockchain network segmentation

Abstract

This invention provides a system and method for assigning and / or approving transactions on a sharded blockchain network. [Solution] The method includes the steps of: identifying the transaction ID of a blockchain transaction; determining which shard to use among multiple shards based on the transaction ID and the number of shards within the multiple shards; assigning the transaction to the determined shard; and distributing the transaction to at least one node within the determined shard.

Description

Technical Field

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

Background Art

[0002] In this document, the term "blockchain" is used 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 well-known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have also been proposed and developed. Here, Bitcoin may be referred to for convenience and illustrative purposes, but it should be noted that the present disclosure is not limited to use in the Bitcoin blockchain, and alternative blockchain implementations and protocols are also within the scope of the present disclosure. The term "user" may here refer to a human or a processor-based resource. The term "Bitcoin" is used here 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 computer-based, decentralized system composed of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and it contains at least one input and at least one output. Each block contains the hash of the previous block, thereby concatenating the blocks together to create a persistent and immutable record of all transactions written to the blockchain since its inception. A transaction contains a small program known as a script embedded in the transaction's input and output, which specifies how and by whom the transaction's output can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. Software clients installed on the nodes perform this validation operation for 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 written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must i) be validated by the first node that receives the transaction, and if the transaction is validated, the node relays it to other nodes in the network, ii) be added to a new block built by miners, and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to explore the use of both Bitcoin's underlying cryptographic security system and the data that can be stored on the blockchain to implement new systems. Blockchain would be highly advantageous if it could be used for automated tasks and processes that are not limited to the realm of cryptocurrency. Such solutions could leverage the advantages of blockchain (e.g., a persistent, tamper-proof record of events, distributed processing, etc.) while also becoming more versatile in these applications.

[0006] As described above, blockchain networks, such as the Bitcoin blockchain network, are secure decentralized computing systems. The system's full nodes hold and manage a copy of the entire blockchain, send and receive transactions, validate them, and add blocks to the blockchain based on a shared decentralized consensus protocol. While this method is secure, it has scaling flaws associated with the fact that each transaction must be validated and remembered by all full nodes. Regarding validation, this causes delays in the network propagation of transactions, as each transaction must be validated before it can propagate to miners. Furthermore, the delays caused by validation make the network vulnerable to attacks related to "double-spend" attacks, such as the Sybil attack. [Overview of the project]

[0007] This 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 technologies or protocols for allocating and / or approving transactions on sharded blockchain networks. The following details are provided: • The network structure of sharded blockchains, and • Sharded UTXO and memory pool structure We will disclose the following.

[0008] Partitioning in this technical field considers two specific dimensions: horizontal and vertical. Horizontal partitioning, known as sharding, involves a partitioned section of a database where multiple instances of a particular database schema effectively exist, with data spread across each of these instances, thus mitigating instance redundancy. Vertical partitioning, however, involves dividing a particular database schema across multiple nodes, thereby distributing the attributes of a particular object using normalization.

[0009] Different stakeholders wishing to participate in a blockchain network can possess a variety of computing resources, ranging from small, low-power machines to server farms. Therefore, participants are limited to a predetermined level of involvement in the blockchain network by their computing resources.

[0010] In Bitcoin, the blockchain itself is a linked set of transactions that show specific changes in ownership of coins mined at the time of block creation. During transaction confirmation, one of the checks required is to check that no double spending exists. Double spending occurs when a transaction output is referenced by a transaction input that is already in the Bitcoin memory pool or has been confirmed against the blockchain. The memory pool is known to be a reference to a 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 held in an independent structure known as a UTXO set. This structure contains each transaction output that is to be used by a transaction, which can include coinbase and standard transactions.

[0011] According to one aspect of this disclosure, a computer implementation method for dividing a blockchain network into shards is provided. The method includes the steps of identifying a transaction ID of a blockchain transaction and assigning the transaction to a shard based on the transaction ID.

[0012] Dividing a blockchain network into shards allows users to choose their level of engagement 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 shards than all shards will require less storage space to remember all the transactions assigned to the shards they are a member of. Assigning transactions to shards based on transaction IDs has the advantage of resulting in shards of roughly equal size, thereby avoiding placing an excessive burden on members of larger shards compared to members of smaller shards, while simultaneously allowing transactions and associated verifications to be executed accurately without excessive delay.

[0013] The users referred to herein may be associated with one or more nodes or computing devices, and these nodes may also be referred to as client entities within the fragmented blockchain network. Hereafter, references to users may also be understood as references to nodes or entities associated with the user (which may own or control nodes or entities that are part of a shard or fragmented blockchain network). Each node may be communicatively connected to at least one other node within the fragmented blockchain network.

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

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

[0016] Accordingly, aspects of the present disclosure relate to a computer implementation method for assigning transactions related to a blockchain network, wherein the blockchain network is divided into a plurality of shards, each shard containing at least one node, and each node in the blockchain network is associated with at least one shard in the plurality of shards. The method includes the steps of: identifying a transaction ID of a blockchain transaction; determining a shard in the plurality of shards based on the transaction ID and the number of shards in the plurality of shards; assigning the transaction to the determined shard; and distributing the transaction to at least one node in the determined shard.

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

[0018] This offers the advantage that shard placement can be adjusted depending on the chosen behavior.

[0019] The operation may include modulo operations.

[0020] This offers the advantage of making it easier to generate the desired number of shards of equal size.

[0021] In some embodiments, the method includes the step of communicating or broadcasting a node's shard membership information to all other nodes in the shard associated with the node and / or one or more other nodes in the network. The method may also include the communication being performed using a modified addr message, which includes instructions for one or more shards to which the node is associated.

[0022] This disclosure provides a further computer implementation method for dividing a blockchain network into shards. The method includes the steps of: identifying a parent blockchain transaction, where the parent transaction is defined by outputs corresponding to inputs of child blockchain transactions; and assigning the parent and child transactions to the same shard.

[0023] Dividing a blockchain network into shards allows users to choose their level of engagement 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 shards than all of them will require less storage space to remember all the transactions assigned to the shards they are a member of. Assigning transactions to shards based on identifying a parent blockchain transaction defined by the output corresponding to the inputs of a child blockchain transaction, and assigning parent and child transactions to the same shard, has the advantage that approval actions performed by a user who is a member of a particular shard can be performed with less information sent to / from users who are members of different shards. This is because an approved child transaction always has a parent transaction that is a member of the same shard.

[0024] A parent transaction may be identified using one of the 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 of the multiple inputs.

[0025] This offers the advantage of allowing child transactions with multiple inputs to be assigned to a shard.

[0026] The parent transaction may be identified using the inputs of the largest subset among the plurality of inputs of the child blockchain transaction. For example, if a child transaction has five inputs, two of the five refer to two outputs of a previous transaction, and each of the remaining three inputs refers to three different previous transactions, the parent transaction is defined as the previous transaction to which the two inputs together refer, since the two inputs are the largest subset of inputs.

[0027] This provides the advantage that for a child transaction having a plurality of inputs, the amount of information required from users who are members of different shards is reduced.

[0028] According to the present disclosure, a computer-implemented method for approving a blockchain transaction is also provided. The method includes the steps of requesting at least one UTXO referred to by at least one respective input of the transaction from a member node of at least one shard including at least one UTXO, obtaining validity data of the at least one UTXO from the at least one node, and performing an approval check on the at least one input using the validity data.

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

[0030] The present disclosure further provides a computer-implemented method for approving blockchain transactions. The method includes the steps of: identifying at least one shard containing at least one UTXO referenced by at least one input of the transaction; sending the transaction to at least one member node of the at least one shard; and performing an approval check on at least one input using validity data of the UTXO.

[0031] This method allows blockchain transaction approvals to take place on 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 shards than all shards requires less computing power to approve all transactions assigned to the shards to which they belong.

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

[0033] This offers the advantage of providing a mechanism that makes it easier for nodes seeking shard membership information to find that information.

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

[0035] This provides a mechanism for transferring node shard membership information between nodes, thereby offering the advantage of reducing the likelihood of a node performing an authorization operation failing.

[0036] Communication may be performed using a modified addr message.

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

[0038] This disclosure also, Processor and Memory containing executable instructions that cause the system to perform any embodiment of the computer implementation described herein as a result of execution by the processor, We provide a system that includes this.

[0039] The disclosure also provides a non-temporary computer-readable storage medium that stores executable instructions, which, as a result of being executed by the processor of a computer system, cause a computer system to perform at least one of the embodiments of the computer implementation described herein.

[0040] Preferred embodiments of this disclosure are described below, in general terms and not in an exclusive sense, with reference to the accompanying drawings. [Brief explanation of the drawing]

[0041] [Figure 1a] This document shows a comparison between a conventional blockchain network (Figure 1a) and a sharded blockchain network (Figure 1b) according to the first embodiment of this disclosure. [Figure 1b] This document shows a comparison between a conventional blockchain network (Figure 1a) and a sharded blockchain network (Figure 1b) according to the first embodiment of this disclosure. [Figure 2] This shows a node usage rotation used in relation to a second embodiment of the present disclosure. [Figure 3] A method for assigning a transaction to a shard is shown according to a third embodiment of this disclosure. [Figure 4] The fourth embodiment describes how to assign a transaction to a shard. [Figure 5] The conventional UTXO data structure is shown. [Figure 6]A fifth embodiment of this disclosure is shown. [Figure 7a] A sixth embodiment of this disclosure is shown. [Figure 7b] A sixth embodiment of this disclosure is shown. [Figure 8a] A seventh embodiment of this disclosure is shown. [Figure 8b] A seventh embodiment of this disclosure is shown. [Figure 9] This is a schematic diagram showing a computing environment on which various embodiments of this disclosure can be implemented. [Modes for carrying out the invention]

[0042] In current blockchain networks, different nodes are connected peer-to-peer in a largely unstructured manner (with the exception of numerous hardcoded network seeds within the Bitcoin client to assist in node discovery). These nodes communicate to share information about valid transactions, blocks, and other nodes.

[0043] [Structure of a sharded network] A first embodiment of this disclosure is shown in Figure 1b, which illustrates the structure of a sharded blockchain network according to this disclosure. On the other hand, Figure 1a shows the structure of an existing, i.e., prior art, blockchain network.

[0044] According to this disclosure, in order to reduce the reliance on stakeholders to possess expensive and powerful computing resources to participate in a given level of involvement in a blockchain network, stakeholders may be permitted to be members of any number of shards in a sharded blockchain network. This means that small stakeholders, including hobbyists, can choose to be members of a single shard of the network shown in Figure 1b, while large stakeholders, such as financial institutions, can choose to be members of many or all of the shards in the sharded blockchain network shown in Figure 1b. This approach accommodates entities or stakeholders that may require security for transaction history, for example, ensuring that stakeholders who desire or require greater security can approve and remember all transactions in the blockchain, while other stakeholders or entities that may not desire or require the same (greater) level, or may desire less involvement, can still participate in the same sharded blockchain network shown in Figure 1b and remember only a subset of the blockchain.

[0045] As seen in Figure 1b, a particular node can be a member of one or more shard groups. This is evident from the shading shown in the figure, where nodes within the shaded area are members of both shard 2 and shard 3. For communication, the current Bitcoin network and Bitcoin SV (BSV) clients maintain a list of available peers, i.e., information about connectable nodes, distributable nodes, and receivable nodes for each node in the network. In the sharded blockchain according to the first embodiment, further information is maintained, including which shard each node belongs to. In some implementations, to handle transaction propagation between networks, each node shown in the sharded network in Figure 1b is positioned or configured to communicate with at least one node from each shard to propagate these transactions destined for different shards. In some implementations, the information maintained by each node may be in the form of a data structure indicating connectable nodes, distributable nodes, receivable nodes, and the shard to which it belongs in the sharded network shown in Figure 1b. Other details related to the node, such as identifiers and entity associations, may also be maintained. This data structure may be stored in the memory associated with each node, or, for example, in the memory associated with a shard.

[0046] A second embodiment of a sharded network, as shown in Figure 1b, describes a technique in which a node communicates with multiple other nodes within a single shard. This technique advantageously prevents "Sybil-style" attacks within the 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, the adversary may create multiple computers and IP addresses, and may also create multiple accounts / nodes by attempting to make it appear as if multiple accounts / nodes all exist. Manifestations of such an attack may be seen in the following exemplary implementations: If an attacker attempts to fill the network with clients it controls, nodes will be very likely to connect only to the attacker's nodes. For example, the attacker may refuse to relay blocks and transactions for a node, effectively isolating that particular node from the network. This can also manifest as the attacker relaying blocks it creates, effectively placing the node or entity on a different network, thereby isolating the node and the transactions associated with that node or entity, which means it is vulnerable to a double-spending attack. Therefore, Sybil attacks are a problem for existing blockchain networks.

[0048] In order to prevent Sybil attacks in a sharded blockchain network as shown in Figure 1b, according to the second embodiment, a node is configured to communicate with multiple or all other nodes within a single shard. As described above, Sybil attacks can effectively ignore transactions sent from a particular node and further prevent their propagation through the network. Therefore, the second embodiment of this disclosure provides a technique, as shown in Figure 2, that allows nodes in a given shard to exchange information about nodes in other shards and rotate their use.

[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), instead of performing a full transaction confirmation, it performs a basic transaction-level check before propagation. Note that in some implementations, the protocols and rules described above in relation to the second embodiment are considered to be related to, or part of, one or more other embodiments of the 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 done using a modified version of the addr protocol message, according to a second embodiment of this disclosure. The current implementation of the addr message 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 retrieve an addr message containing a bunch of known active peers (e.g., for bootstrapping). An addr message often contains only one address, but sometimes more, and in some examples, up to 1000. In some examples, all nodes broadcast an addr containing their IP address periodically, i.e., every 24 hours. The node may then relay these messages to its peers and remember the relayed addresses if they are new. In this way, nodes in the network may have a reasonably clear understanding of which IPs are connected to the network at the time they connect to the network or thereafter. In most cases, IP addresses are added to everyone's address database for the initial addr broadcast.

[0051] The implementation of the modified addr protocol according to this disclosure can transmit further information regarding which shard a particular node belongs to, in addition to the above. For example, in the modified addr protocol, when a node in a sharded network, such as in Figure 1b, joins a particular shard in the network, the broadcast as part of the addr message may also include a field that identifies one or more shards to which it is a member. This information is therefore also returned in response to a getaddr request from a peer in the network in Figure 1b. As described in the first embodiment, such information may be based on data structures associated with each node and / or each shard to which a node belongs. In some embodiments, the modified addr protocol may also include the state of the shards to which a 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 it may also be identified whether a particular shard is active or the number of active nodes in a given shard.

[0052] [Assigning transactions to shards in a sharded network] As described above, in a sharded blockchain network, transactions are not approved and stored by all nodes, but rather are assigned to one or more specific shards. Therefore, a mechanism is needed to assign transactions to different shards. Two possible embodiments are described below, which are referred to as “transaction ID-based” shards in the third embodiment of this disclosure and “input-based” shards in the fourth embodiment of this disclosure.

[0053] In some implementations, the existing Bitcoin protocol may undergo a fork to initiate one of these methods. When a node in a given shard subsequently receives a transaction, the node may check that it has been sent to the correct shard. This technique provides a balance of transactions across shards.

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

[0055] The sharding methods described below may be applied sequentially or in any order, multiple times. For example, transaction ID sharding may be performed first, and input-based sharding may be performed later. Furthermore, as described above, any method may be applied retrospectively, and any method may be applied subsequently. The number of shards n may be selected each time a sharding method is applied, allowing the protocol to be scaled by increasing the number of nodes. The number of nodes may be selected based on the total number of nodes on the network, the size of the blockchain, and / or other characteristics. For both of the sharding methods described below, the method by which transactions are stored by each node when sharding is performed 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 performing further sharding. In a third embodiment of this disclosure, as illustrated with Figure 3, transaction distribution between shards is processed based on transaction IDs (txids).

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

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

[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 allocated in step 306, the transaction is distributed to the identified shard, that is, the transaction is distributed to the nodes included in the shard identified in step 306.

[0061] Therefore, 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 implemented based on a data structure associated with each node, which includes information related to the node, as described above in the first embodiment. Advantageously, this technique provides an even balance of transactions across shards.

[0062] The shard count on the network is • The total number of nodes in the network, and • Blockchain size It can be arbitrarily selected based on a number of parameters, including [specific parameters].

[0063] [Input-based shard distribution] A sharding method according to a fourth embodiment of this disclosure will be explained using the flowchart in Figure 4.

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

[0065] In step 404, the output of the transaction before the input in step 402 is 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 the sharded network as shown in Figure 1b. In some implementations, this step includes identifying the shard to which both transactions will be assigned. 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 modified addr broadcast or a response to a getaddr request for either a given transaction or the previous transaction may be used to identify the shard. In other examples, the shard may be selected randomly or as specified for both transactions, i.e., based on rotation, as long as both transactions are assigned to the same shard. This may apply, for example, when the parent transaction is not identified, i.e., when the incoming transaction is a coinbase transaction.

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

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

[0069] It should be noted that the use of a first input to define the parent in step 402 is not mandatory for the method, and if multiple inputs exist in a given transaction, any of the inputs 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 refer to 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 allocated 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 designated specific input to be considered.

[0070] It should be noted that the 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 desired. For example, the blockchain network may be forked according to the input-based distribution of the fourth embodiment, and then one or more of the resulting forks may be sharded according to the transaction ID-based distribution of the third embodiment.

[0071] [Sharding of UTXO sets / memory pools] Currently, in the Bitcoin network, every node maintains its own set of UTXOs, which are checked and updated during transaction confirmation. An example of a UTXO set is shown in Figure 5.

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

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

[0074] Two methods that can be used to check UTXO sets for transaction approval under this disclosure are described below. These are referred to as transaction shard approval according to the sixth embodiment and UTXO shard approval according to the seventh embodiment, respectively.

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

[0076] Refer to Figure 7a to describe the check of UTXO sets performed between nodes in different shards. This process will also be 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 a UTXO. This is seen in step 702. The shard numbers are specified for illustrative purposes only, and any given node associated with any given shard may perform this request.

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

[0079] If the UTXO for a given transaction is received, in step 708, the transaction input is considered valid. As described in the background technology paragraph, it is known that a software client or program or application installed on a node may perform this confirmation on the UTXO by executing its lock and unlock script. In some implementations, this is called the transaction validity data. If the execution of the lock and unlock script evaluates to TRUE, the transaction is valid and written to the blockchain. Furthermore, as mentioned above, one of the validity checks is to check that no double spending exists. In some implementations, when a node receives a transaction, it looks up the UTXO that the transaction will use in the data structure associated with the node or the data structure of the associated shard.

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

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

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

[0083] Figure 8a shows that an expenditure transaction (Tx) created by a node in shard 4 is propagated to each shard containing the UTXO of 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 the shard receives a given transaction, in this embodiment, the process proceeds to approve the transaction based on inputs within the same shard.

[0085] Therefore, in step 804, it is checked whether the inputs of a given transaction are related to the same shard. Transactions may be assigned to shards as described above according to the fourth embodiment. If, as described above, a node is a member of more than one shard, the “same” shard check in this step applies to any of such shards.

[0086] As seen in step 806b, inputs related to UTXOs in different shards are not validated. In some implementations, validation of each input may be performed in much the same way that validation can currently be performed on the Bitcoin network. Otherwise, in step 806a, the node proceeds to validate the transaction.

[0087] Following step 806a, in step 808, the validity of the inputs associated with a given transaction is checked. As described above, and also in steps 706 and 708 of Figure 7b, confirmation of an unused transaction (UTXO) may also be done by executing its lock and unlock script. In some implementations, this is called transaction validity data. If the execution of the lock and unlock script evaluates to TRUE, the transaction is valid and written to the blockchain. Furthermore, also as described above, one of the validity checks is to check that no double spending exists. In some implementations, when a node receives a transaction, it searches for the UTXO 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 UTXO does not exist, if the value is greater than the UTXO, or if the input is invalid, such as in the case of a script error, the given transaction is discarded, as seen in step 810b. In this case, the given transaction is not propagated to other nodes in the same shard.

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

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

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

[0092] Referring next to Figure 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 as an example. In various embodiments, the computing device 2600 may be used to implement any of the computer implementation systems, methods, or protocols illustrated and described above, either alone or when communicatively coupled to one or more such nodes or systems, in a node or combination of nodes in one or more shards of a sharded blockchain network as shown in Figure 1b.

[0093] For example, the computing device 2600 may be configured to be used as a data server, a web server, a portable computing device, a personal computer, or any of these electronic computing devices. As shown in Figure 9, the computing device 2600 may include one or more processors having one or more levels of cache memory, and a memory controller (collectively labeled 2602) which can be configured to communicate with a storage subsystem 2606 including main memory 2608 and persistent storage 2610. The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620, as shown in the figure. The storage subsystem 2606 and cache memory 2602 may be used for storing information such as transaction and block-related details described herein. The processor 2602 may be used to provide a step or function of any embodiment described herein.

[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 enables 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 utilize multiple buses.

[0096] The network interface subsystem 2616 may provide interfaces to other computing devices and networks. The network interface subsystem 2616 may function as an interface for receiving data from other systems and sending data from the computing device 2600 to other systems. For example, the network interface subsystem 2616 may enable the device to be connected to a network so that data technicians can send data to the device and receive data from the device while they are in a remote location such as a data center.

[0097] The user interface input device 2612 may include one or more user input devices such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad or graphics tablet, a scanner, a barcode scanner, a touchscreen integrated into the display, an audio input device such as a voice recognition system or microphone, and other types of input devices. Generally, 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.

[0098] One or more user interface output devices 2614 may include non-visual displays such as display subsystems, printers, or audio output devices. The display subsystem may be a flat-panel device such as a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED) display, or a projection or other display device. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to enable user interaction with applications performing 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 configurations that can provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) may provide the functionality of one or more embodiments of the present disclosure when executed by one or more processors 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 further provide repositories for storing data used in accordance with the present disclosure. For example, main memory 2608 and cache memory 2602 can provide volatile storage for programs and data. Persistent storage 2610 can 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 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 computer device, a tablet computer, a workstation, or any other device described below. Furthermore, the computing device 2600 may include other devices that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). A device that can be connected to the computing device 2600 may include multiple ports configured to accept optical fiber connectors. Thus, this device may be configured to convert optical signals to electrical signals, which may be transmitted through ports connecting the device to the computing device 2600 for processing. Due to the constantly changing nature of computers and networks, the description of the exemplary computing device 2600 shown in Figure 9 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations are possible, having more or fewer components than the system shown in Figure 9.

[0101] The embodiments described above are illustrative and not limiting to the present invention, and those skilled in the art should note that many alternative embodiments can be designed without departing from the scope of this disclosure as defined by the appended claims. In the claims, any reference numerals enclosed in parentheses shall not be construed as limiting the claims. Terms such as “comprising” and “comprises” do not exclude the existence of elements or steps other than those enumerated in any claim or specification as a whole. In this specification, “comprises” means “includes or consists of,” and “comprising” means “comprising or consisting of.” A singular reference to an element does not exclude a plural reference to such an element, and vice versa. The present invention may be implemented by hardware comprising several distinct elements and by a appropriately programmed computer. In a device claim enumerating several means, some of these means may be embodied by a single identical hardware item. The mere fact that certain means are described in different dependent clauses does not indicate that combinations of these means cannot be used to their 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 by reading and understanding the above description. Although this disclosure is written with reference to a specific exemplary implementation, it should be recognized that this disclosure is not limited to the described implementation and can be implemented with modifications and changes within the scope of the appended claims. Accordingly, the specification and drawings should be considered illustrative, not restrictive. Accordingly, the scope of this disclosure should be determined by reference to the appended claims, along with the entire scope of equivalents to which the appended claims are entitled.

Claims

1. A computer implementation method for assigning and approving transactions related to a blockchain network, wherein the blockchain network is divided into a plurality of shards, each shard includes at least one node of the blockchain network, and each node in the blockchain network is associated with at least one shard among the plurality of shards, At the first node, Steps to identify the transaction identifier (ID) of a blockchain transaction, A step of determining a shard among the multiple shards based on the transaction ID and the number of shards among the multiple shards, The steps include assigning the blockchain transaction to the determined shard, The steps include distributing the blockchain transaction to at least one node in the determined shard, A step of requesting at least one UTXO referenced by at least one input of the blockchain transaction from a second node in at least one shard of the plurality of shards, which includes at least one unused transaction output (UTXO), The step of obtaining validity data for at least one UXTO, wherein the validity data includes a lock script, and The steps include: performing an approval check on the at least one input using the aforementioned validity data; A method that includes this.

2. The step further includes performing an operation using the aforementioned transaction ID, The method according to claim 1, wherein the step of assigning the transaction to the identified shard is based on the result of the operation.

3. The method according to claim 2, wherein the operation includes modulo arithmetic.

4. The method according to any one of claims 1 to 3, further comprising the step of communicating a request for shard membership information of a node to other nodes.

5. The method according to any one of claims 1 to 4, further comprising the step of communicating a node's shard membership information to other nodes.

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

7. A system for assigning and approving transactions related to a blockchain network, wherein the blockchain network is divided into multiple shards, each shard includes at least one node of the blockchain network, and each node in the blockchain network is associated with at least one shard among the multiple shards, Processor and As a result of execution by the aforementioned processor, the system has a memory containing executable instructions that cause the system to execute the computer implementation method described in any one of claims 1 to 6. A system that includes this.

8. A non-temporary computer-readable storage medium for assigning and approving transactions related to a blockchain network, wherein the blockchain network is divided into a plurality of shards, each shard includes at least one node, and each node in the blockchain network is associated with at least one shard among the plurality of shards, A non-temporary computer-readable storage medium storing executable instructions that, as a result of being executed by the processor of a computer system, cause the computer system to execute at least one of the computer implementation methods described in any one of claims 1 to 6.

Images