Blockchain transaction cleanup service

Abstract

Methods, devices, and data structures for processing a large number of transactions in a blockchain node. Solutions are provided for transaction cleanup after a block announcement is received from another node. In one example, if a transaction identifier in a list that matches a local candidate block matches a transaction identifier in the announced block, the transaction identifier in the list that matches the local candidate block is tagged, and once the announced block is verified, a block assembly service uses untagged transaction identifiers to build a new candidate block. In other examples, during a mining phase, a candidate database is built with transaction identifiers, and when other nodes on the network announce an array, the TxIDs are tagged with an array identifier or a node identifier. This can speed up the cleanup after the block announcement and reduce memory footprint of tagging TxIDs as included in a solved block after solving.

Description

Technical Field

[0001] This disclosure relates to blockchain networks, and more specifically, to methods and apparatus for verifying blocks involving a large flow of transactions. Background Technology

[0002] A blockchain is a distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"), and this copy is widely publicized. A blockchain consists of a series of data blocks, where each block includes one or more transactions. Apart from the so-called "coinbase transaction," each transaction points to a previous transaction in a sequence that can span one or more blocks up to one or more coinbase transactions. Coinbase transactions will be discussed below. Transactions submitted to the blockchain network are included in new blocks. The process of creating new blocks is often called "mining," which involves each of the multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on a defined, ordered, and verified set of pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at the nodes, and the publication of a block can be achieved by publishing only the block header.

[0003] Transactions in a blockchain are used to perform one or more of the following: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of log entries in a virtualized ledger or registry; receiving and processing timestamped entries; and / or sorting index pointers by time. Additional hierarchical functionality can also be implemented on the blockchain. Blockchain protocols allow for the storage of additional user data or data indexes within transactions. There is no pre-specified limit to the maximum data capacity that can be stored in a single transaction, allowing for the incorporation of increasingly complex data. For example, this can be used to store electronic documents, audio, or video data in the blockchain.

[0004] Nodes in a blockchain network (often called "miners") perform a distributed transaction registration and verification process, which will be described in detail later. In summary, during this process, nodes verify transactions and insert them into a block template that attempts to identify a valid proof-of-work solution for that block template. Once a valid solution is found, the new block is propagated to the other nodes in the network, allowing each node to record the new block on the blockchain. To record a transaction on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The node receiving the transaction can compete to find a proof-of-work solution to incorporate the verified valid transaction into the new block. Each node is configured to execute the same node protocol, which includes one or more conditions for confirming the validity of a transaction. Invalid transactions will not be propagated or incorporated into a block. Assuming a transaction has been verified as valid and thus accepted on the blockchain, the transaction (including any user data) will therefore be registered and indexed as an immutable public record on every node in the blockchain network.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction called a "coinbase transaction," which distributes a certain amount of digital assets, i.e., tokens. The detection and rejection of invalid transactions are carried out through the actions of competing nodes, which act as proxies for the network and incentivize reporting and preventing misconduct. The widespread dissemination of information allows users to continuously audit node performance. Publishing only the block header allows participants to ensure the continued integrity of the blockchain.

[0006] In the "output-based" model (sometimes called the UTXO-based model), a given transaction's data structure includes one or more inputs and one or more outputs. Any spendable output includes an element specifying the amount of digital assets, which is derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). Outputs may also include a locking script that specifies the future redemption conditions of the output. A locking script is a predicate that defines the conditions necessary to verify and transfer digital tokens or assets. Each input to a transaction (other than coinbase transactions) includes a pointer (i.e., a reference) to such outputs in a previous transaction and may also include an unlocking script used to unlock the locking script pointing to the output. Consider a pair of transactions, which may be referred to as the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying the amount of digital assets and has a locking script that defines one or more conditions for unlocking that output. The second (target) transaction has at least one input and an unlocking script that includes a pointer to the output of the first transaction; this unlocking script is used to unlock the output of the first transaction.

[0007] In this model, when a second (target) transaction is sent to the blockchain network for propagation and recording, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the conditions defined in one or more of the locking script of the first transaction. Another condition will be that the output of the first transaction has not yet been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid based on any of these conditions will not propagate the transaction (as a valid transaction, but possibly registering it as invalid) nor include it in a new block to be recorded in the blockchain.

[0008] Another transaction model is the account-based model. In this case, the amount of each transaction is not defined by referring to the UTXO of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes and is continuously updated.

[0009] As blockchain technology is applied to an increasing number of transactions, managing transaction volume becomes challenging. For example, common credit card payment networks (such as Mastercard or Visa) typically process thousands of transactions per second. It may be advantageous if solutions exist that enable blockchain networks to manage similar levels of throughput. Attached Figure Description

[0010] As an example, reference is now made to the accompanying drawings illustrating exemplary embodiments of this application, in which: Figure 1 An exemplary system for implementing blockchain is shown; Figure 2 An exemplary transaction protocol is shown; Figure 3A An exemplary implementation of the client application is shown; Figure 3B An example of the user interface for the client application is shown; Figure 4 An exemplary node software for a blockchain node is shown; Figure 5 The diagram illustrates a simplified, exemplary blockchain node used to handle a large number of blockchain transactions; Figure 6 An exemplary method for performing transaction cleanup as a result of block announcements is illustrated in flowchart form; Figure 7 Another exemplary method for performing transaction cleanup is illustrated in flowchart form; Figure 8 Another exemplary method for performing transaction cleanup is illustrated in flowchart form.

[0011] The same reference numerals are used in the accompanying drawings to denote the same elements and features. Detailed Implementation

[0012] In one aspect, a method implemented by a computer for processing blockchain transactions by a node is provided. The method may include, during a mining phase, constructing a candidate datastore containing transaction identifiers for each verified transaction in a candidate block; receiving from another node two or more arrays, each array containing a corresponding set of transaction identifiers; and identifying transaction identifiers in the candidate datastore that match transaction identifiers in one of the two or more arrays, and for each matching transaction identifier in the candidate datastore, recording an array identifier for the one of the two or more arrays. The method may further include, during the block verification phase, after receiving a block solution (wherein the block solution identifies a plurality of arrays) from the other node, identifying each transaction identifier in the candidate data repository as having a recorded array identifier that matches one of the arrays in the plurality of arrays, and marking the transaction identifier as being in the block solution; and, after verifying the block solution, identifying all transaction identifiers in the candidate data repository that are not marked as being in the block solution, and providing those transaction identifiers to another service in the node.

[0013] In some implementations, identifying each transaction identifier in the candidate data repository that has a recorded array identifier matching one of the plurality of arrays includes: constructing a list of array identifiers from the block solution in memory. In some examples, constructing the list of array identifiers includes: constructing a hash table populated with the array identifiers from the block solution. In some such examples, marking the transaction identifier as being in the block solution includes: for each array identifier in the hash table, searching the candidate data repository to identify transaction identifiers marked with the array identifier, and marking those transaction identifiers as being in the block solution.

[0014] In some implementations, marking the transaction identifier in the block solution includes marking the transaction identifier at the tip (or top). i Among them i It is the index of the block solution among multiple published block solutions.

[0015] In some implementations, identifying all transaction identifiers in the candidate data repository that are not marked as being in the block solution includes: deleting all transaction identifiers marked as being being in the block solution from the candidate data repository. In some examples, providing those transaction identifiers includes: copying all remaining transaction identifiers in the candidate data repository and sending them to the other service.

[0016] In some implementations, the block solution includes a new array that was not previously received from the other node, and the method further includes: obtaining a set of transaction identifiers included in the new array and loading them into memory; and querying a candidate data repository for a match for each transaction identifier in the set, and if a match is found, marking the transaction identifier in the candidate data repository as being in the block solution. The new array that was not previously received may be an array that was not received during the mining phase.

[0017] In some implementations, the method includes: constructing the candidate block containing the verified transaction while constructing the candidate data repository.

[0018] In some implementations, providing those transaction identifiers to another service includes forwarding those transaction identifiers to at least a block assembly service for use in constructing new candidate blocks.

[0019] In some implementations, providing those transaction identifiers may include: notifying the other service that the candidate database is available to be accessed by the other service, and that it contains all transaction identifiers not marked as being in the block solution.

[0020] In some implementations, the other service includes a memory pool monitoring service or a double-spending detection service.

[0021] On the other hand, this application describes a method for processing blockchain transactions by a node, the method comprising: during a mining phase, constructing a candidate data repository containing transaction identifiers for each verified transaction in a candidate block; receiving two or more arrays from another node, each array containing a corresponding set of transaction identifiers; and identifying transaction identifiers in the candidate data repository that match transaction identifiers in one of the two or more arrays, and for each matching transaction identifier in the candidate data repository, recording an array identifier for said one of the two or more arrays. The method may further comprise: during a block verification phase, after receiving a block solution (wherein the block solution identifies multiple arrays) from the other node, identifying each transaction identifier in the candidate data repository associated with the other node and marking those transaction identifiers as being in the block solution; and after verifying the block solution, identifying all transaction identifiers in the candidate data repository that are not marked as being in the block solution and providing those transaction identifiers to another service in the node.

[0022] In some implementations, the recording includes: recording the node identifier of the other node for each matching transaction identifier in the candidate data repository. In some cases, identifying each transaction identifier in the candidate data repository associated with the other node includes: identifying each transaction identifier in the candidate data repository marked with the node identifier of the other node. In some such cases, identifying each transaction identifier in the candidate data repository marked with the node identifier includes: as a prerequisite, determining that all arrays received from the other node are included in the block solution.

[0023] In some implementations, the block solution includes a new array that was not previously received from the other node, and the method further includes: obtaining a set of transaction identifiers included in the new array and loading them into memory; querying the candidate data repository for a match for each transaction identifier in the set, and if a match is found, marking that transaction identifier in the candidate data repository as being in the block solution. The new array that was not previously received may be an array that was not received during the mining phase.

[0024] In some implementations, marking transaction identifiers in the block solution includes: marking these transaction identifiers at the tip i Among them i It is the index of the block solution among multiple published block solutions.

[0025] In some implementations, the blockchain network includes multiple other nodes, and each node includes a corresponding candidate data repository for each of these other nodes, and each transaction identifier associated with the other node in the candidate data repository includes: identifying the corresponding candidate data repository associated with the other node.

[0026] In some implementations, the method includes constructing the candidate block containing these verified transactions simultaneously with constructing the candidate data repository. The construction of the candidate block can be performed using a first memory via a block assembly service, and the candidate data repository can be contained in a second memory separate from the first memory.

[0027] In some implementations, providing those transaction identifiers to another service includes forwarding those transaction identifiers to at least a block assembly service for use in constructing new candidate blocks.

[0028] In some implementations, providing those transaction identifiers may include: informing the other service that the candidate database is available to the other service, and that it contains all transaction identifiers not marked as being in the block solution.

[0029] In some implementations, this other service includes a memory pool monitoring service or a double-spending detection service.

[0030] In another aspect, this application describes a computer-implemented method for processing blockchain transactions by a node. The method may include: during a mining phase, constructing in memory a list of transaction identifiers included in candidate blocks mined by the node; receiving a block solution from another node, the block solution specifying a solved block, and in response, loading a set of transaction identifiers from the solved block into the memory; querying the set of transaction identifiers for a match for each transaction identifier in the list, and if a match is found, marking the transaction identifier in the list as included in the solved block; and after verifying the block solution, removing all transaction identifiers in the list marked as included in the solved block, and using any remaining transaction identifiers in the list to construct new candidate blocks.

[0031] On the other hand, a computing device for implementing nodes on a blockchain network can be provided. This computing device may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processor to perform one or more of the methods described herein.

[0032] In another aspect, a computer-readable medium may be provided that stores processor-executable instructions, including instructions which, when executed by one or more processors, cause the processors to perform at least one of the methods described herein.

[0033] Other exemplary embodiments of this disclosure will become clear to those skilled in the art by referring to the following detailed description in conjunction with the accompanying drawings.

[0034] In this application, the term "and / or" is intended to cover all possible combinations and sub-combinations of the listed elements, including any single element, any sub-combination of these elements, or all of them, and does not necessarily exclude additional elements.

[0035] In this application, the phrase “...or at least one of ...” is intended to cover any one or more of the listed elements, including any single element of the listed elements, any sub-combination of these elements, or all of them, without necessarily excluding any additional elements, and without necessarily requiring all of these elements.

[0036] Exemplary System Overview Figure 1 An exemplary system 100 for implementing blockchain 150 is shown. System 100 may include a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104, which can be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 can be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0037] Each blockchain node 104 includes peer computer devices, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing unit implemented by one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable memory in the form of non-transitory computer-readable media. The memory may include one or more memory cells employing one or more memory media, such as magnetic media like hard disks, electronic media like solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media like optical disc drives.

[0038] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple blockchain nodes 104 in a distributed or blockchain network 160. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Rather, blockchain 150 can be pruned as long as each blockchain node 150 stores the block header of each block 151 (discussed below). Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 has at least one input and at least one output. Each output specifies the quantity of digital assets represented as a property amount; an example is an output that is password-locked to a user 103 (requiring the user's signature or other solution to unlock, thus allowing redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0039] Each block 151 also includes a block pointer 155, which points to a previously created block 151 in the blockchain to define the order of blocks 151. Each transaction 152 (except for the coinbase transaction) has a pointer to a previous transaction to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of block 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more earlier original transactions 152 in blockchain 150 point to the genesis block 153, not to previous transactions.

[0040] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Each blockchain node 104 is configured to create block 151 and store a corresponding copy of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into block 151. The ordered set 154 is often referred to as a “mempool.” In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that node 104 has accepted as valid, and for that set, node 104 is forced not to accept any other transactions attempting to spend the same output.

[0041] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the existence and verification of the validity of the previous transaction 152i are required to ensure the validity of the current transaction, the existence of the previous transaction 152i is not necessary when creating the current transaction 152j or even sending the current transaction 152j to network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by pointers, and not necessarily the creation or sending time in the time series; thus, the possibility of creating or sending transactions 152i or 152j out of order is not necessarily excluded (see the discussion of isolated transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0042] The inputs of the current transaction 152j also include input authorization, such as the signature of user 103a to which the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Therefore, the current transaction 152j can transfer the amount defined in the inputs of the previous transaction 152i to a new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, transaction 152j may have multiple outputs to split the input amount among multiple users or entities (one of which can be the original user or entity 103a for modification). In some cases, a transaction may also have multiple inputs, aggregating the amounts from multiple outputs of one or more previous transactions and redistributing them to one or more outputs of the current transaction.

[0043] According to an output-based transaction protocol, such as Bitcoin, when an entity 103, such as a user or machine, wishes to issue a new transaction 152j, the entity sends the new transaction from its computer terminal 102 to a recipient. The entity or the recipient will eventually send the transaction to one or more blockchain nodes 104 on network 106 (currently typically servers or data centers, but in principle, other user terminals could also be involved). It is also not excluded that the entity 103 issuing the new transaction 152j may send the transaction to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks the validity of the transaction according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In this output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of entity 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i to which the new transaction is assigned. This condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined, at least in part, by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or by a combination thereof. Regardless of the approach, if the new transaction 152j is valid, blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and thus forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0044] In the output-based model, whether a given output (e.g., a UTXO) is allocated is defined as whether it has been validly redeemed by the input of another subsequent transaction 152j, according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i, which it is attempting to allocate or redeem, has not yet been allocated / redeemed by another transaction. Similarly, if invalid, transaction 152j will not be propagated in blockchain 150 (unless it is marked as invalid and propagated as a reminder) or recorded. This prevents double-spending, i.e., a transaction processor allocating the output of the same transaction more than once. On the other hand, the account-based model prevents double-spending by maintaining account balances. Because a defined transaction order also exists, the account balance has a single defined state at any given time.

[0045] In addition to verifying the validity of transactions, blockchain nodes 104 compete to be the first node to create a transaction block in a process commonly known as mining, which is backed by "proof-of-work". At blockchain node 104, new transactions are added to an ordered set 154 of valid transactions that have not yet appeared in block 151 recorded on blockchain 150. Blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 from the ordered set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "random number" value such that when the random number is juxtaposed with and hashed against the representation of the ordered set 154 of transactions, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof-of-work puzzle, and other types are not excluded. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs. Therefore, this search can only be performed by brute force, consuming significant processing resources at each blockchain node 104 attempting to solve the puzzle.

[0046] The first blockchain node 104 that solves the problem announces its solution on network 106, providing the solution as proof. Other blockchain nodes 104 in the network can then easily check the solution (once a hash value solution is provided, it can be directly checked whether the solution makes the hash value output satisfy the condition). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. Then, an ordered set of transactions 154 is recorded by each blockchain node 104 as a new block 151 in blockchain 150. A block pointer 155 is also assigned to a new block 151n pointing to a previously created block 151n-1 in the blockchain. The significant amount of work required to create the proof-of-work solution (e.g., in the form of a hash) signals the first node 104's intention to follow the blockchain protocol. These rules include that a transaction is not accepted as valid if it assigns the same output as a previously verified valid transaction; otherwise, it is called double-spending. Once created, block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in blockchain network 106. Block pointer 155 also imposes order on block 151. Since transaction 152 is recorded in ordered blocks at each blockchain node 104 in network 106, an immutable public ledger of transactions is provided.

[0047] It should be noted that different blockchain nodes 104 vying to solve a puzzle at any given time can do so based on different snapshots of an ordered set 154 of transactions that have not yet been published at any given time, depending on when they begin searching for solutions or the order in which they receive transactions. Those solving the corresponding puzzle first define the transactions 152 included in the new block 151n and their order, and update the current set of unpublished transactions 154. Then, blockchain nodes 104 continue to compete to create blocks from the newly defined, prominent ordered set of unpublished transactions 154, and so on. Furthermore, there are protocols for resolving any potential “forks,” where two blockchain nodes 104 solve the puzzle for each other in a very short time, thus propagating a conflicted view of the blockchain between nodes 104. In short, the fork with the longest fork direction becomes the final blockchain 150. It should be noted that this does not affect users or agents on the network, as the same transaction will appear in both forks.

[0048] According to the Bitcoin blockchain (and most other blockchains), the node that successfully constructs a new block 104 is granted the ability to allocate an accepted amount of digital assets in a new special type of transaction that distributes a limited amount of digital assets (as opposed to inter-agent or inter-user transactions, which transfer a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction," but can also be called a "starting transaction." It is typically the first transaction to form a new block 151n. Proof-of-work signals the intention of the node that constructed the new block to follow the protocol rules, thus allowing the redemption of that particular transaction later. The blockchain protocol rules may require a maturity period, such as 100 blocks, before the special transaction can be redeemed. Typically, the regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is typically called a "transaction fee" and is discussed below.

[0049] Due to the resources involved in transaction verification and publication, each blockchain node 104 typically takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a single user terminal or a networked set of user terminals.

[0050] Each blockchain node 104's memory stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role and process transactions 152 according to the blockchain node protocol. It should be understood that any action attributed herein to the blockchain node 104 can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or lower layers such as the operating system layer or protocol layer, or any combination of these layers.

[0051] The computer devices 102 of each of the multiple parties 103, acting as consumer users, are also connected to the network 101. These users can interact with the blockchain network but do not participate in verifying, constructing, or propagating transactions and blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can act as storage entities storing copies of the blockchain 150 (e.g., having already obtained a copy of the blockchain from blockchain node 104).

[0052] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on blockchain network 106. Users of the blockchain network (often referred to as “clients”) may be considered part of the system containing the blockchain network; however, these users are not blockchain nodes 104 because they do not perform the roles required for blockchain nodes. Instead, each party 103 may interact with blockchain network 106 to utilize blockchain 150 by connecting to blockchain node 106 (i.e., communicating with blockchain node 106). For illustrative purposes, parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in system 100, but are not shown for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob in this document, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document may be replaced by "first party" and "second party" respectively.

[0053] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., a computer-readable storage device in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media like SSDs, flash memory, or EEPROMs, and / or optical media like optical disc drives. The memory on each party 103's computer device 102 stores software, such as corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0054] The client application 105 may initially be provided to any given party 103's computer device 102 via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0055] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the respondent 103 to create, authorize (e.g., sign) transactions 152 and send them to one or more Bitcoin nodes 104, which then propagate through the network of blockchain nodes 104, thus being included in blockchain 150. The other function is to report to the respondent the amount of digital assets they currently possess. In an output-based system, this second function involves organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant parties scattered across blockchain 150.

[0056] It should be understood that while various client functionalities can be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client functionality described herein can be implemented within a suite of two or more different applications, for example, through an interface connection via an API or as a plugin for one application. More generally, client functionalities can be implemented at the application layer or at a lower layer such as the operating system, or any combination of these layers. The following description is based on client application 105, but it should be understood that this is not limiting.

[0057] An instance of client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also liaise with blockchain node 104 to query blockchain 150 for any transaction in which the corresponding party 103 is the recipient (or actually to check other parties' transactions in blockchain 150, since, in this embodiment, blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to verify transaction 152 according to a blockchain node protocol and forward transaction 152 for propagation in blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. All nodes 104 in network 106 use the same node protocol.

[0058] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends transaction 152j from client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this might be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it will process it according to the blockchain node protocol and its corresponding role. This may include first checking whether the newly received transaction 152j meets specific conditions to become "valid," specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions can be configured on a per-transaction basis via a script included in transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by combining scripts and the node protocol.

[0059] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "valid"), any blockchain node 104 that received transaction 152j will add the new verified valid transaction 152 to the ordered set of transactions 154 maintained at blockchain node 104. Furthermore, any blockchain node 104 that received transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in network 106. Since each blockchain node 104 applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will quickly propagate throughout network 106.

[0060] Once the transaction ordered set 154 maintained at a given blockchain node 104 is accessed, that blockchain node 104 will begin competing to solve a proof-of-work puzzle on the latest version of its respective transaction ordered set 154 containing the new transaction 152. (Remember, other blockchain nodes 104 can try to solve the puzzle based on different transaction ordered sets 154. However, the first to solve the puzzle will define the transaction ordered set included in the latest block 151, and eventually, blockchain node 104 will solve the puzzle for a portion of ordered set 154, which includes Alice's transaction 152j.) Once the ordered set 154 including the new transaction 152j has completed its proof-of-work, it will immutably become part of a block in block 151 of blockchain 150. Each transaction 152 includes pointers to earlier transactions, so the order of transactions is also immutably recorded.

[0061] Different blockchain nodes 104 can initially receive different instances of a given transaction, and thus have conflicting views about which instance is "valid" before an instance is published to a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and then finds a second instance already recorded in blockchain 150, then blockchain node 104 must accept this and discard (i.e., consider it invalid) its initially accepted instance (i.e., the instance not yet published in block 151).

[0062] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks can be called an "account-based" protocol. In an account-based system, each transaction does not define the amount transferred by referencing the UTXO of previous transactions in a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the network's nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as a "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0063] UTXO-based model Figure 2 An exemplary transaction protocol is illustrated. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to either an output-based or UTXO-based protocol. However, this is not limited to all possible embodiments. It should be noted that while an exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other example blockchain networks.

[0064] In the UTXO-based model, each transaction (“Tx”) 152 is a data structure with one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In some embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 committed to node 104.

[0065] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the middle, Alice's New Affairs 152j is marked as " Tx 1 The new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In the middle, the previous transaction 152i is marked as " Tx 0 ". Tx 0 and Tx 1 It is just an arbitrary marker, which does not necessarily mean Tx 0 The first transaction in Blockchain 151 and Tx 1 Subsequent transactions in pool 154. Tx 1 It can point to any previous (i.e. preceding) transaction that still has an unspent output 203 locked to Alice.

[0066] When Alice creates her new business Tx 1 At that time, or at least when she sent the new transaction to network 106, the previous transaction Tx 0 It may already be valid and included in block 151 of blockchain 150. The transaction may now be included in a block within block 151, or it may still be waiting in ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx 0 and Tx 1 They can be created and sent together to network 106; or, if the node protocol allows buffering of "orphaned" transactions, Tx 0 Even in Tx 1 Then it is sent. In the context of transaction sequences in this article, the terms "previous" and "subsequent" refer to the order of transactions in the sequence defined by the transaction pointers specified within the transaction (which transaction points to which other transaction, etc.). They can also be replaced with "predecessor" and "successor," "ancestor" and "descendant," or "parent" and "child," etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "children") that point to a previous transaction (ancestor transaction or "parent") are not valid unless the parent transaction is valid. Children that arrive at blockchain node 104 before their parents are considered orphaned. Depending on the node protocol and / or node behavior, they may be discarded or buffered for a period of time to wait for their parents.

[0067] Previous matters Tx 0 One or more outputs 203 are specific UTXOs, denoted as UTXO 0Each UTXO includes a value representing a digital asset amount and a locking script. This locking script defines the conditions that the unlocking script in input 202 of a subsequent transaction must meet for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following: the unlocking script in the input of the subsequent transaction includes a cryptographic signature of the party to whom the previous transaction was locked.

[0068] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "script" (with an uppercase S), which can be used by the blockchain network. The locking script specifies the information required for the transaction output 203, such as Alice's signature requirement. The unlocking script appears in the transaction output. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0069] Therefore, in the example shown, Tx 0 Output 203 UTXO 0 Including the locking script [Checksig] P A This locking script requires Alice's signature (Sig). P A to redeem UTXO 0 (Strictly speaking, it is for those who attempt to redeem) UTXO 0 (Subsequent transactions are valid). [Checksig P A Contains the public key from Alice's public-private key pair. P A The representation of (i.e., hash). Tx 1 Input 202 includes pointers to Tx 0 pointers (e.g., via their transaction IDs) TxID 0 In some embodiments, this is the entire transaction. Tx 0 (hash value). Tx 1 Input 202 includes Tx 0 Chinese logo UTXO 0 The index, in order to Tx 0 It is identified in any other possible output. Tx 1 Input 202 further includes an unlock script. <Sig P A The unlocking script has Alice's cryptographic signature, which Alice creates by applying the private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined through the locking script, the node protocol, or a combination thereof.

[0070] When new transactions Tx 1 Upon reaching blockchain node 104, the node applies the node protocol. This may include running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria). In some embodiments, this may involve juxtaposing two scripts: <Sig PA> <pa>|| [Checksig PA] Here, "||" indicates concatenation, "<...>" indicates placing data on the stack, and "[...]" indicates a function executed by the locked script (in this example, a stack-based language). Alternatively, scripts can be run one after another using a shared stack, instead of concatenating them. Regardless of the method used, when running together, the scripts use Alice's public key. P A (including) Tx 0 (in the output of the locking script) to authenticate. Tx 1 The signature in the input unlock script must include the expected portion of the data when Alice signs it. The expected portion of the data itself ("message") must also be included to perform this authentication. In this embodiment, the signature data includes the entire... Tx 1 (Therefore, there is no need to include a separate element to specify the part of the signature data in plaintext, because it already exists on its own.)

[0071] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext, other entities such as Node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and marking this as a signature on the message, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a specific data segment or transaction portion, etc., can mean signing the hash value of that data segment or transaction portion.

[0072] If the unlock script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (therefore, in the example shown, if Alice's signature is provided and authenticated in Tx1), then blockchain node 104 considers Tx1 valid. This means that blockchain node 104 will add Tx1 to the ordered set of transactions 154. Blockchain node 104 will also forward transaction Tx1 to one or more other blockchain nodes 104 in network 106 so that it will propagate throughout network 106. Once Tx1 is valid and included in blockchain 150, this defines UTXO0 as spent from Tx0. It should be noted that Tx1 is only valid if it spends the output of an unspent transaction 203. If it attempts to spend the output of another transaction 152 that has already been spent, Tx1 will be invalid even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been spent (i.e., whether it has become a valid input for another valid transaction). This is one of the reasons why the order in which blockchain 150 imposes definitions on transaction 152 is important. In practice, given a blockchain node 104, it can maintain a separate database that marks the UTXOs 203 of the spent transaction 152, but the final definition of whether a UTXO has been spent depends on whether a valid input of another valid transaction is formed in the blockchain 150.

[0073] This is another failure criterion in most transaction models if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202. Therefore, such a transaction will not be propagated or included in block 151.

[0074] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined as spent in a UTXO while simultaneously spending another portion. However, the amount of a UTXO can be split across multiple outputs of subsequent transactions. For example, Tx 0 of UTXO 0 The amount defined in can be Tx 1 This involves splitting the data between multiple UTXOs. Therefore, if Alice doesn't want to... UTXO 0 All the amounts defined in the document are given to Bob, and she can use the remainder in... Tx 1 In the second output, you either make change yourself or pay the other party.

[0075] In practice, Alice typically also needs to include fees for the Bitcoin node that publishes Alice's transaction 104. If Alice does not include such fees, Tx0 may be rejected by blockchain node 104 and therefore, although technically valid, may not propagate and be included in blockchain 150 (the node protocol does not force blockchain node 104 to accept transaction 152 if it does not wish to). In some protocols, transaction fees do not require their own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by the output 203 of a given transaction 152 is automatically provided to the blockchain node 104 that published the transaction. For example, suppose the pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference can be distributed by node 104 that publishes a block containing UTXO1. Alternatively or additionally, this does not necessarily preclude the possibility of explicitly specifying transaction costs in one of the UTXOs 203 of its own transaction 152.

[0076] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 at any point in blockchain 150. Therefore, typically, the assets of the given party 103 are scattered across the UTXOs of various transactions 152 throughout blockchain 150. No single number defining the total balance of the given party 103 is stored anywhere in blockchain 150. The wallet function of the client application 105 serves to consolidate the various UTXO values ​​locked to the respective parties that have not yet been spent in other subsequent transactions. To achieve this, it can query a copy of blockchain 150 stored at any Bitcoin node 104.

[0077] It should be noted that script code is typically represented graphically (i.e., using a non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For instance, OP_RETURN is a scripting language opcode. When OP_FALSE is added before the opcode at the beginning of the locking script, the opcode creates a non-spendable output for the transaction. This output can store data within the transaction, thus immutably recording the data in the blockchain. For example, the data may include files that need to be stored in the blockchain.

[0078] Typically, the input to a transaction contains a digital signature corresponding to the public key PA. In this embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature, used to select the output to be signed (and thus fixed at the time of signing).

[0079] Locking scripts are sometimes called "scriptPubKey," referring to the fact that they typically include the public keys of the parties to whom the corresponding transaction is locked. Unlocking scripts are sometimes called "scriptSig," referring to the fact that they typically provide the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature verification. Furthermore, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0080] like Figure 1 As shown, the client applications on each of Alice and Bob's computer devices 102a and 120b can include additional communication functionality. This additional functionality allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the instigation of either party or a third party). Side channel 301 enables the exchange of data off-chain. This type of communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange transaction 152 between Alice and Bob without registering the transaction (not yet) on blockchain network 106 or publishing it on chain 150 until one of them chooses to broadcast it on network 106. Sharing transactions in this way is sometimes referred to as sharing a "transaction template." The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, side channel 301 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0081] Side channel 301 can be established via the same packet-switching network 101 as blockchain network 106. Alternatively or additionally, side channel 301 can be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, side channel 301 as referred to anywhere herein can include any one or more links via one or more networking technologies or communication media used for "off-chain" data exchange, i.e., data exchanged outside of blockchain network 106. In the case of using multiple links, the bundle or set of off-chain links as a whole can be referred to as side channel 301. Therefore, it should be noted that if Alice and Bob exchange certain information or data via side channel 301, it does not necessarily mean that all of this data must be sent through the exact same link or even the same type of network.

[0082] Client software Figure 3A An exemplary implementation of a client application 105 for implementing embodiments of the present disclosure is shown. The client application 105 may include a transaction engine 401 and a user interface (UI) layer 402. According to the process discussed above, the transaction engine 401 is configured to implement basic transaction-related functions of the client 105, such as formulating a transaction 152, receiving and / or sending transactions and / or other data via a side channel 301, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106.

[0083] The UI layer 402 is configured to present a user interface via user input / output (I / O) methods of the corresponding user's computer device 102, including outputting information to the corresponding user 103 via user output methods of device 102, and receiving input from the corresponding user 103 via user input methods of device 102. For example, user output methods may include one or more screens (touch or non-touchscreen) providing visual output, one or more speakers providing audio output, and / or one or more haptic output devices providing haptic output, etc. User input methods may include, for example, an input array of one or more touchscreens (which may be the same as or different from the one / those used for output methods); one or more cursor-based devices, such as a mouse, trackpad, or trackball; one or more microphones and voice or sound recognition algorithms for receiving voice or sound input; one or more gesture-based input devices for receiving input in the form of manual or body gestures; or one or more mechanical buttons, switches, or levers, etc.

[0084] Note that while the various functionalities described herein may be described as being integrated into the same client application 105, this does not necessarily constitute a limitation. Instead, they can be implemented in a suite of programs consisting of two or more different applications, such as one application acting as a plug-in to another or interfaced via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application rather than in the UI layer 402, or the functionality of a given module such as the transaction engine 401 may be distributed across multiple applications. Furthermore, it is not excluded that some or all of the described functionalities may be implemented, for example, at the operating system layer. Wherever references are made to a single or given application 105 or the like anywhere in this document, it should be understood that this is merely illustrative, and more generally, the described functionalities can be implemented in any form of software.

[0085] Figure 3B A model of an example user interface (UI) 500 is provided, which can be rendered on Alice's device 102a by the UI layer 402 of the client application 105a. It should be understood that a similar UI can be rendered by the client 105b on Bob's device 102b or any other party's device.

[0086] Using diagrams, Figure 3B UI 500 is shown from Alice's perspective. UI 500 may include one or more UI elements 501, 502, 503, which are presented as different UI elements through user input.

[0087] For example, UI elements may include one or more user-selectable elements 501, which may be different buttons on the screen, different options in a menu, or the like. The user input method is set to enable user 103 (in this case, Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching a UI element on the screen, or by speaking the name of the desired option (Note: The term "manual" as used in this document is used only in contrast to automatic and is not necessarily limited to performing the operation by hand).

[0088] Alternatively or additionally, UI elements may include one or more data input fields 502. These data input fields 502 are presented via user output, such as on a screen, and data can be entered into the fields via user input, such as through a keyboard or touchscreen. Alternatively, data may be received verbally based on methods such as voice recognition.

[0089] Alternatively or additionally, UI elements may include one or more information elements 503 that output information to the user. For example, the information may be displayed on a screen or be audible.

[0090] It should be understood that the specific way various UI elements, selection options, and input data are presented is not important. The functionality of these UI elements will be discussed in more detail later. It should also be understood that... Figure 3B The UI 500 shown is just a schematic model. In practice, it may include one or more further UI elements, which are not described for the sake of brevity.

[0091] Node software Figure 4 An example of node software 450 running on each blockchain node 104 of network 106 is shown in an example of a UTXO-based or output-based model. It should be noted that another entity can run node software 450 without being classified as node 104 on network 106, i.e., without performing the actions required by node 104. Node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related functional modules 455. Each node 104 can run node software that includes (but is not limited to) the following three: a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). Protocol engine 401 is typically configured to identify different fields of transaction 152 and process such fields according to the node protocol. When a field pointing to another previous transaction 152i is received (…), the node software will process the different fields of the transaction 152i. Tx m-1 The input of transaction 152j is the output (e.g., UTXO) of the transaction. Tx j When ), the protocol engine 451 identifier Tx j The unlock script is then passed to script engine 452. Protocol engine 451 is also based on... Tx j Pointers in the input are used to identify and retrieve. Tx i . Tx i It can be published on blockchain 150, in which case the protocol engine can retrieve it from the copy of block 151 of blockchain 150 stored at node 104. Tx i .or, Tx i It can also be published on blockchain 150. In this case, protocol engine 451 can retrieve it from the unpublished ordered transaction set 154 maintained by node 104. Tx i Regardless of the method used, script engine 451 will identify... Tx i The locked script is referenced in the output and passed to the script engine 452.

[0092] Therefore, script engine 452 has Tx i The locking script and from Tx j The corresponding input unlock script. For example, in Figure 2 The transaction marker is shown in the image. Tx 0 and Tx 1 However, the same transaction can be applied to any transaction pair. As mentioned earlier, script engine 452 runs two scripts together, which will include placing data onto stack 453 and retrieving data from stack 453 according to the stack-based scripting language used (e.g., script).

[0093] By running the scripts simultaneously, the script engine 452 determines whether the unlock script meets one or more criteria defined in the locking script, i.e., whether the unlock script unlocks the output including the locking script. The script engine 452 returns this determination to the protocol engine 451. If the script engine 452 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns the result "TRUE". Otherwise, it returns the result "FALSE".

[0094] In the output-based model, the result "TRUE" from script engine 452 is one of the conditions for transaction validity. Typically, one or more further protocol-level conditions evaluated by protocol engine 451 must also be met; for example, Tx j The total amount of digital assets specified in the input does not exceed the total amount pointed to in its output, and Tx i The output pointed to by the transaction has not yet been spent by another valid transaction. Protocol engine 451 evaluates the results from script engine 452 along with one or more protocol-level conditions, and only verifies the transaction if all of them are TRUE. Tx j Valid. Protocol engine 451 outputs an indication of whether the transaction is valid to application-level decision engine 454. Only when... Tx j Under truly effective conditions, the decision engine 454 can choose to simultaneously control the consensus module 455C and the propagation module 455P to execute its intended purpose. Tx j The corresponding blockchain-related functions. This can include consensus module 455C, which adds to the corresponding ordered transaction set 154 of the node. Tx j , used to be incorporated into block 151; and propagation module 455P, to Tx j The transaction is forwarded to another blockchain node 104 in network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may only choose to publish a transaction if it is valid and sufficient transaction fees are reserved.

[0095] Furthermore, it should be noted that in this paper, the terms "TRUE" and "FALSE" are not necessarily limited to returning a result represented only as a single binary number (bit), although this is indeed one possible implementation. More colloquially, "TRUE" can refer to any state indicating a successful or affirmative result, while "FALSE" can refer to any state indicating an unsuccessful or uncertain result. For example, in an account-based model, a combination of implicit protocol-level verification of the signature and an additional affirmative output from the smart contract can indicate a result as "TRUE" (the overall result is considered TRUE if both individual results are TRUE).

[0096] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.

[0097] For example, some of the embodiments described above have been based on Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 above can be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the characteristics described above for Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104.

[0098] In some embodiments of the invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. It is not excluded that other network entities (or network elements) may perform only one or some of these functions, but not all of them. That is, network entities may perform the function of propagating and / or storing blocks without creating and publishing blocks (remember that these entities are not considered nodes of the preferred Bitcoin network 106).

[0099] In some other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that nodes may perform at least one or more, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, on these other blockchain networks, "node" may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or propagate these blocks 151 to other nodes.

[0100] To put it even more colloquially, any reference above to the term "Bitcoin node" 104 can be replaced by the terms "network entity" or "network element," where such an entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element can be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0101] Large transaction processing As network capacity grows to accommodate a larger number of transactions, nodes will need to adapt to handling massive transaction flows. In some cases, the new transaction flow could grow to tens of thousands, hundreds of thousands, or even millions of transactions per second.

[0102] One mechanism used to solve large and large block challenges is to have nodes pre-propagate their candidate blocks before finding a solution. In this way, once a block solution is found, the successful node only needs to send details of the solution, such as the Coinbase transaction, Merkle root, and random number, instead of sending the complete ordered list of TxIDs. Other nodes can then verify the solution based on the already received ordered list of TxIDs.

[0103] To address the issue of a continuous influx of new transactions, nodes can perform dynamic transaction verification and block assembly. Each node constructs a contiguous, ordered array of transactions, and the candidate blocks mined at that node consist of these arrays. As new arrays are completed, they are added to the candidate blocks. Simultaneously, the node propagates its completed arrays to other nodes. When a block solution is found, the node sends detailed information about the solution and a list of ordered array identifiers specifying the order of the arrays in the solved block. In this way, other nodes can quickly assemble solved blocks based on the arrays previously received from the node and then verify the block solution.

[0104] It should be understood that in the array-based solution described above, a node will receive many arrays from other nodes, reflecting the arrays constructed by those nodes and on which nodes are currently performing mining operations. Therefore, a node will maintain a record of arrays from each node. To speed up block verification, nodes can be configured to perform some verification work before the block solution is announced. In the case of a large volume of transactions, block assembly and verification are potential bottlenecks to be addressed. Block verification involves verifying that: (1) transaction inputs are valid (e.g., they reference existing outputs and their unlocking scripts are valid); (2) transactions are not double-spending on the outputs of previous blocks; (3) transactions are not double-spending on the outputs in the current block; and (4) transactions are topologically ordered. Topological ordering dictates that transactions that spend the outputs of another transaction in the same block must appear later in the order of occurrence. Right now Sub-transactions must occur after the ordered transactions within a block have converged on their parent transaction. The block verification service can perform some work during the mining phase using a transaction graph data repository or a set of array transaction databases to prepare for rapid confirmation of the topology order after another node finds the block solution. In some cases, the preprocessing of the array can be delegated to a separate processor, enabling horizontal scaling.

[0105] In scenarios with high transaction volumes, one of the technical challenges for blockchain nodes is that, after finding a valid block, a node needs to clean up or remove transactions currently in a confirmed block so that these transactions are not in the node's current candidate blocks. At a high level, a clean-up service can be configured to identify transactions in a candidate block that are included in an announced block from another node, and then remove those identified transactions from the candidate block. However, since this process may run in parallel with the block verification process, and since competing block announcements may be received, the cleanup operation ideally needs to be performed in a reversible manner, allowing it to be undone if necessary. In some cases, it may be advantageous to perform the cleanup preparation operations before announcing the block solution, so that the cleanup operation can be performed as quickly as possible once a new announced block has been verified.

[0106] Now refer to Figure 5 The diagram illustrates a simplified exemplary blockchain node 550 for handling a large number of blockchain transactions. In this example, node 550 is shown as a single device; however, it should be understood that node 550 can be implemented using one or more computing devices. Among other systems, the computing device includes one or more processors, memory, an internal communication bus, and an external network communication subsystem.

[0107] Blockchain node 550 is configured to communicate via one or more computer networks 552. Computer network 552 may include peer-to-peer computer networks, such as blockchain networks that interconnect blockchain nodes (e.g., other blockchain nodes 504). Computer network 552 may include public and / or private computing networks, including the Internet. In some cases, computer network 552 may support multicast communication. Computer network 552 may enable communication from user equipment 506, such as end-user computing or edge devices that can generate and send blockchain transactions or queries. User equipment may include mobile devices, point-of-sale devices, merchant computing systems, e-commerce platforms, financial service platforms, payment processing systems, and other such systems or devices.

[0108] Blockchain node 550 can implement many services, including propagation service 510, transaction verification service 512, block assembly service 514, blockchain service 516, and block verification service 518. Some or all of these services can be horizontally scalable.

[0109] Additionally, blockchain node 550 can maintain or access certain stored data. This data may be stored in a database format or, depending on the implementation, in other data structures. The stored data may include, for example, transaction storage device 520, UTXO storage device 522, one or more array databases 524, and blockchain storage device 526.

[0110] The propagation service 510 manages network communication for blockchain node 550. For example, it can listen for incoming transactions via an IPv6 multicast network. It can perform a degree of gating on incoming transactions, such as basic validity checks, ensuring that transactions are correctly formatted, have non-zero inputs and outputs, and other such basic validity checks.

[0111] Transaction verification service 512 can verify transactions according to the rules of the applicable blockchain protocol. For example, it can verify that the input consumed in a transaction is a valid, unspent output of a confirmed or unconfirmed transaction. For example UTXO. Transaction verification service 512 can verify that the input is unfunded by referencing UTXO storage device 522, thereby verifying that the block is partially valid. The verified transaction is then passed to block assembly service 514.

[0112] The transaction verification service 512 or its sub-service can mark any input of a transaction as spent in the UTXO storage device 522. Verified transactions can be stored in the transaction storage device 520.

[0113] The block assembly service 514 is responsible for creating new candidate blocks for the miners associated with blockchain node 550. The block assembly service 514 receives verified transaction streams and assembles them into an array of ordered transaction identifiers. When the array is complete, its Merkle root is calculated, added to the current candidate block, the Merkle root of the candidate block is updated, and the candidate block header is pushed to the miner. The newly completed array is announced to other blockchain nodes via computer network 552.

[0114] Blockchain service 516 manages the block header and arrays within the blocks, and records the block data in blockchain storage device 526. In some cases, blockchain storage device 526 may be a complete copy of the current blockchain. In other cases, blockchain storage device 526 may contain metadata, such as block headers and array data including TxIDs but not the complete transaction data.

[0115] In some cases, the arrays discussed above can be called subtrees because their transaction identifiers form part of an ordered list of transaction identifiers that can be merged into candidate blocks, making the array's transaction identifiers usable for finding a part of the Merkle tree of candidate blocks, i.e., a "subtree". Each array has a unique array identifier, or "subtree identifier," which is sent along with the array when it is propagated to other blockchain nodes 504 through the blockchain network. Other nodes determine that they have seen and verified all transactions in the array, and can then store the array identifier in memory in association with the array data. Similarly, when blockchain node 550 receives an array from other blockchain nodes 504, it determines whether it has received and verified all transactions listed in the array by the transaction identifier, and then verifies the Merkle root of the array and stores the array identifier in memory in association with the array data within the array database 524. Arrays are stored in association with the identifiers of the nodes that sent these arrays. That is, the array database 524 can include a set of arrays associated with a specific node identifier, which is unique to the node that created and propagated those arrays.

[0116] In the following example, the block verification service 518 is used to verify the validity of a block announced by one of the other blockchain nodes 504. It listens to the array communicated through the other blockchain nodes 504 and, if a solution is found, performs functions for compactly storing the array data in a way that allows for fast and efficient block verification. The block announcement by one of the other nodes 504 includes block header data and an ordered list of array identifiers from which the node can determine the block content, provided that the node has already received the arrays corresponding to the array identifiers. The block solution may be referred to as the new solution block in this document.

[0117] To handle large volumes of transactions, node 550 must be able to process incoming array data from other nodes quickly and efficiently, verify the validity of the incoming array data, and quickly and accurately verify blocks when a block solution is announced. To meet these challenges, the block verification service 518 is ideally horizontally scalable and stores array data in a structure and manner that allows node 550 to quickly verify blocks after a solution is announced. In one solution, node 550 utilizes a transaction graph data repository 528 to map transaction data and interrelationships so that the topological ordering can be verified after a solution is found. In another solution, node 550 utilizes a collection of array transaction databases (not shown) that track the input of transactions from previous blocks or other arrays to that array, as well as the output of transactions in arrays that are not consumed within that array.

[0118] The blockchain node 550 in this example also includes a cleanup service 530. The cleanup service 530 can be implemented as a standalone service, or in some cases, it can be part of the block verification service 518 or the block assembly service 514. The cleanup service 530 is configured to identify which verified transactions in the current candidate block created by the block assembly service 514 are included in the block solution received from another node, and remove those identified transactions once the block solution has been verified, so that the block assembly service 514 can determine the remaining verified transactions not included in the block solution. Right now, Unconfirmed transactions are used to construct new blocks. In some cases, a cleanup list of remaining unconfirmed transaction identifiers can be forwarded to the block assembly service 514. In some cases, a database or other storage structure containing the cleanup list of remaining unconfirmed transaction identifiers can be provided to the block assembly service 514. In some other cases, the cleanup list of remaining unconfirmed transaction identifiers can be forwarded to another service within the node besides the block assembly service, or the cleanup list of remaining unconfirmed transaction identifiers can be provided to that other service. Examples of that other service include a memory pool monitoring service or a double-spending detection service.

[0119] In one example below, the cleanup service 530 may rely on comparing the transaction identifiers in the announced blocks with the transaction identifiers in the node's own candidate blocks after the block resolution is completed. In one implementation, this can be done by loading the TxIDs of the announced blocks using the same RAM used for candidate blocks, thus enabling comparison within the same RAM. To improve speed and increase scalability, in another exemplary solution, the cleanup service 530 may build a candidate data repository separate from the RAM containing the TxIDs of all transactions in the node's own candidate blocks. During the mining phase, once the blocks are verified, the cleanup service 530 can use the candidate data repository 532 to prepare for rapid cleanup.

[0120] In the first exemplary solution, the cleanup service 530 can identify transactions listed in an array received from another node, and can use array identifiers to mark the corresponding transaction identifiers in the candidate data repository 532, such that the candidate data repository 532 records which transaction identifiers are included in which arrays. In the second exemplary solution, the cleanup service 530 can alternatively or additionally mark the transaction identifiers in the candidate data repository 532 with node identifiers, which indicate that the transaction identifiers are in the arrays received from that particular node. In both examples, once an announced block is received, while the block verification service 518 is performing verification on the block, the cleanup service 530 can quickly identify which transactions in the candidate data repository 532 are included in the announced block based on the array identifiers and / or node identifiers. This allows the cleanup service 530 to quickly remove or delete the included transactions, leaving only unconfirmed transaction identifiers in the candidate data repository 532. Alternatively, it can extract these unconfirmed transaction identifiers from the candidate data repository 532. In either case, the cleanup service 530 is thus configured to provide the block assembly service 514 with a list or set of unconfirmed transaction identifiers, enabling the block assembly service 514 to quickly build new candidate blocks so that the blockchain node 550 can start mining on the newly added blocks as quickly as possible.

[0121] Cleaning service Figure 6 An exemplary method 600 for performing transaction cleanup as a result of a block announcement is illustrated in flowchart form. Method 700 can be implemented by a blockchain node. A blockchain node can be implemented using one or more computing devices. In this example, the cleanup service and the block assembly service share the same RAM. Therefore, the cleanup service accesses the list of transactions in the candidate blocks.

[0122] As part of constructing an array of transaction identifiers that will form candidate blocks, the block assembly service constructs an ordered list of transaction identifiers that constitute the body of the candidate blocks. L Ordered list L Stored in RAM. During the mining phase, the block assembly service continues to build an array using newly verified transactions as blockchain nodes continue to receive a large stream of new transactions, potentially a million transactions per second in some examples. Therefore, during the mining phase, when a new array of transaction identifiers is completed and added to the candidate blocks (e.g., an ordered list of transactions), the candidate blocks are... L Rapid growth.

[0123] In Operation 602, a node can receive a block solution announcement from another node. In many implementations, the block solution announcement may include block header data (e.g., a random number, Merkle root, etc.) and some additional information (e.g., Coinbase transactions and an ordered list of array identifiers specifying the arrays included in the solved block).

[0124] In Operation 604, the cleanup service retrieves all transaction identifiers contained in the announced blocks. In some cases, this can be accomplished by querying the array database for stored arrays that match the array identifiers. The array database contains arrays previously received from other nodes and stores them associated with their unique array identifiers; specifically, the array database stores an ordered set of TxIDs that form the arrays and their unique array identifiers. Based on the received block solutions, the cleanup service retrieves the arrays contained in the solved blocks and loads them into RAM. In some cases, the cleanup service may construct a hash table (e.g., a HashMap). H This hash table contains transaction identifiers from all retrieved arrays.

[0125] If the network generates approximately 1 million transactions per second, the hash table used to solve the blocks could contain about 600 million transaction identifiers, which would require more than 19 GB of memory. In the case of hash tables, this number could be three times higher due to the data structure.

[0126] In operation 606, one or more processors can then traverse the ordered list. L middle( Right now The cleanup service checks the transactions in the candidate blocks of the node itself and sees if each transaction identifier in the candidate blocks is in a solved block. The cleanup service can use each transaction identifier in the candidate blocks to query a hash table containing transaction identifiers from solved blocks. As indicated in Operation 608, if a match is found, Right now If the transaction identifier in the candidate block is also in the solved block (e.g.) ， From L TxID in H In operation 610, within the ordered list... L The transaction identifier is marked with the identifier of the solved block. For example, it can be marked with "in_tip_{ i The} symbol marks the transaction identifier, where i This is an index (e.g., 0, 1, 2, etc.) of the announced blocks. The index is needed to handle situations where a node may be evaluating and verifying more than one announced block. In this case, the blockchain service will decide at some point which block to accept and on which block to attempt to build another block. Typically, this choice might be based on the first announced block received, but other factors may also be considered, such as whether another block has been added to one of the announced blocks. Furthermore, if it is found that one of the announced blocks violates a validity check at some point, the verification of that announced block may fail.

[0127] Operation 612 reflects the evaluation of whether a block has been verified and accepted. If it has not yet been verified and accepted, the node continues to evaluate transactions in the candidate block or transactions already added to the candidate block, as these transactions will continue to arrive during the verification of the announced blocks and can be added to a new array and inserted into the candidate block. Therefore, the identifiers of newly incorporated transactions can be added to the ordered list. L In addition, the hash table needs to be searched to ensure that these newly incorporated transaction identifiers are not already in the announced blocks. If so, they are marked as instructed above.

[0128] Once the block is verified and accepted, in operation 614, the node is removed from the ordered list. L Remove all transaction identifiers marked as included in already solved blocks. The newly accepted block may be referred to as a tip in this discussion. j The cleanup service starts from an ordered list. L Delete or remove items marked "in_tip_{ j All transaction identifiers of "}", and its subsequent command block assembly service uses a list. L Use the remaining transaction identifiers to construct a new array and new candidate blocks, as indicated in operation 616.

[0129] The method 600 described above advantageously relies on a single RAM shared between the block assembly service and the cleanup service, making it simple and straightforward to communicate the remaining transaction identifiers. While this technique is concise and elegant, it results in high main memory usage and limited scalability. It also primarily executes only after the block solution has been found. Therefore, it might be advantageous to employ other techniques that involve preparing for cleanup before announcing the block solution.

[0130] Now for reference Figure 7 This illustrates another exemplary method 700 for performing transaction cleanup as a result of block announcements. In this example, method 700 leverages the fact that array data is shared by other nodes prior to block announcements. That is, the nodes have already seen all the transaction identifiers listed in each array and recorded them in the array database. Therefore, it can prepare a candidate data repository in advance, which allows the cleanup service to perform cleanup operations quickly after the block resolution is announced without consuming a large amount of main memory.

[0131] In this exemplary method 700, a cleanup service manages a candidate data repository in which it stores transaction identifiers for all transactions in a candidate block. Whenever a new transaction is added to a candidate block, its transaction identifier is also added to the candidate data repository. For example, operation 702 instructs the addition of one or more transaction identifiers (e.g., an array of TxIDs) to a candidate block being constructed by a block assembly service. In operation 704, the cleanup service adds those identical transaction identifiers to the candidate data repository. In the example described herein, the candidate data repository is a separate data structure from the candidate blocks; however, in some implementations, the candidate data repository and the candidate blocks are the same. That is, the transaction markers described below can be applied within a database or data structure containing candidate blocks without creating a separate candidate data repository. The mention of a candidate data repository herein will be understood to include both possibilities.

[0132] Operation 706 assesses whether a new array has been received from another node on the network. If a block solution has not yet been announced, as instructed in Operation 708, the node continues to build candidate blocks and construct a candidate data repository.

[0133] When receiving a new array from another node in operation 706, the cleanup service queries the candidate data repository for each transaction identifier in the array to find a matching transaction identifier in the candidate data repository. The matching transaction identifier in the candidate data repository is then marked as associated with that array. For example, it can be done using "in_{ array_ID The} symbol marks the transaction identifier in the candidate data repository, where array_ID It is the array identifier of the array that was just received, as shown in operation 710.

[0134] If we assume that each array contains approximately 1 million transaction identifiers, and that approximately one array is received from each node per second (based on a transaction volume of approximately 1 million transactions per second), and if there are approximately 30 nodes in the network, then the cleanup service will perform approximately 30 million read and write accesses per second to the candidate data repository.

[0135] If an array containing transaction identifiers that are not yet in the candidate block and candidate data repository arrives, the node may not have previously received those transactions. The node requests copies of those transactions from other nodes, verifies them, and adds them to a new array so that they can be included in its own candidate block. Transactions can be stored in the candidate data repository along with the array identifier containing them.

[0136] It should be understood that many identical transactions will be included in different arrays from other nodes in the network because all nodes work according to a essentially common transaction pool. Therefore, in many cases, the transaction identifier in the candidate data repository may be marked as "in_{ array_ID The transaction identifier is marked with a unique array identifier (}). If there are 30 other nodes in the network, up to 30 different array identifiers may be used to mark the transaction identifier.

[0137] In operation 708, a node can receive a block announcement from one of the other nodes. As previously described, the block announcement may include a list of array identifiers and block header data. These array identifiers inform other nodes which arrays of transaction identifiers constitute the block's contents. In operation 712, the cleanup service constructs the list of array identifiers within the block. This list may be a hash table (e.g., a HashMap) or another such data structure. The hash table may be stored in the cleanup service's RAM.

[0138] If a node has not yet received an array from the block solution, in one implementation, it requests the array from another node. When the array is provided, other services within the node can perform functions related to storing the array, but the cleanup service can be configured to simply add the transaction identifier of the new array directly to the hash table.

[0139] In operation 714, once the hash table is built, the cleanup service uses the array identifier in the hash table to query candidate data repositories. For candidate data repositories, this array identifier (e.g., "in_{ array_ID For each transaction identifier marked with "}", the cleanup service will subsequently also mark that transaction identifier as "in_tip_{ i }",in i This is an index indicating the published block. As explained above, in cases where multiple possible solved blocks exist at the same level / height of a blockchain being evaluated and verified, the index is used to distinguish between the blocks. If a separate transaction identifier exists in the hash table, the cleanup service then searches the candidate data repository for a matching identifier and marks it as "in_tip_{ i }".

[0140] Once the block verification service accepts the block, it performs operation 716. That is, it determines the block is valid and adds it to the blockchain. As mentioned above, in this discussion, such a block can be referred to as a tip. j In this case, the cleanup service then identifies candidate data repositories that are not marked "in_tip_{ j All transaction identifiers marked "in_tip_{j}" are retrieved and sent to the block assembly service so that the block assembly service can begin building new arrays and new candidate blocks. Any transactions marked "in_tip_{j}" are removed or deleted from the candidate data repository. In some cases, all transactions are removed from the candidate data repository, and once the transactions sent to the block assembly service are placed into candidate blocks, they are simply added back to the candidate data repository. In some other cases, the remaining transactions are left in the candidate data repository, provided that the block assembly service quickly adds these remaining transactions to the new candidate blocks being built. In this case, the markings of those transactions in some arrays may be removed.

[0141] In some examples, the cleanup service may be able to open or provide access to a candidate data repository containing remaining transactions, allowing the block assembly service to read these remaining transactions from the candidate data repository. In some cases, the remaining transactions may be sent to or otherwise provided to another service in the node, such as a memory pool monitoring service and / or a double-spending detection service.

[0142] Advantageously, this solution involves far fewer RAM requirements because instead of loading millions of transaction identifiers into a hash table in memory for each array, a single array identifier is loaded into the hash table. If all arrays have been received, this might only involve about 600 array identifiers, whose storage space could be a few kilobytes.

[0143] A potential drawback of this solution is that it is not labeled "in_tip_{ j The remaining transaction identifiers of “}” need to be communicated by the cleanup service from the candidate data repository to the block assembly service so that the block assembly service can begin building new candidate blocks. This could represent a significant communication overhead for a large number of transactions; however, since all nodes on the network work with a roughly common set of transactions, it is expected that block solutions will tend to include most of the currently unconfirmed transactions, leaving a relatively small number of transactions not included in the candidate database.

[0144] The process described above involves tagging transaction identifiers with array identifiers, allowing the cleanup service to quickly identify confirmed transactions within a solved block based on the array identifiers that constitute the solved block. In this way, the cleanup service does not need to load all transaction identifiers in the solved block into a hash table and search for matches in the candidate data repository; instead, it only needs to load the array identifiers into the hash table and search the candidate data repository for transaction identifiers that have been tagged as being associated with or containing those array identifiers.

[0145] In the most likely scenario, further speed improvements and reduced RAM usage are possible. In many cases, the solved block will include a set of all array identifiers previously announced to the network by the successful node. Other nodes will see and store those previously announced arrays. Where a node can identify the node that sent a specific array, it can also tag or mark the transaction identifiers contained in that array as being "from that node". In other words, if an array from a specific node contains transaction identifiers, then the matching transaction identifiers in the candidate data repository are marked as "in _{ array_ID }”, and further labeled it as “received_from_{” using the node identifier. node_ID The node identifier can be a unique identifier for the node, such as a registered miner identifier, domain name, or IP address.

[0146] Now for reference Figure 8 It illustrates another exemplary method 800 for transaction cleanup after the announcement block is resolved, in the form of a flowchart.

[0147] The cleanup service builds a candidate data repository, in which it stores the transaction identifiers of all transactions in the candidate blocks. As instructed in operations 802 and 804, whenever a new transaction is added to a candidate block, the transaction identifier is also added to the candidate data repository. Specifically, operation 802 instructs the addition of one or more transaction identifiers (e.g., an array of TxIDs) to the candidate block being built by the block assembly service. In operation 804, the cleanup service adds those identical transaction identifiers to the candidate database. Operation 806 instructs the evaluation of whether a new array has been received from another node on the network. If a block solution has not yet been announced, as instructed in operation 808, then in operations 802 and 804, the node continues building candidate blocks and constructing the candidate data repository. It should be understood that even if a block solution has been announced, a node can continue to build candidate blocks and the candidate data repository in parallel while evaluating the solution, simultaneously performing block verification operations and cleanup preparation.

[0148] When a new array is received from another node in operation 806, the cleanup service queries the candidate data repository for each transaction identifier in the array to find a matching transaction identifier in the candidate data repository. Then, in operation 810, the matching transaction identifiers in the candidate data repository are marked as associated with the array and as associated with the node. For example, this can be done using "in_{ array_ID The} symbol marks the transaction identifier in the candidate data repository, where array_ID It is the array identifier of the array that was just received, and can be further used with "received_from_{ node_ID Mark it with}, where node_ID It is a unique node identifier for a node that propagates an array of nodes on a network.

[0149] In Operation 808, a node can determine that it has received a block announcement from one of the other nodes. As previously described, a block announcement may include a list of array identifiers and block header data. These array identifiers inform all nodes which arrays of transaction identifiers constitute the block's contents. In this case, the node knows that the block solution was received from a specific other node with a unique node identifier. Messages conveying detailed information about the block solution may include the node identifier.

[0150] A common and likely scenario is that the block solution from a specific node is based on all arrays that particular node has already communicated. This allows for rapid cleanup operations. Therefore, in operation 812, the node determines whether the block solution listing the array identifiers included in the blocks includes all arrays sent by the specific node. If no communicated arrays are missing from the solution, then in operation 814, the cleanup service can query the candidate data repository tagged with the node identifier ( Right now Using the node_ID of a specific node, with "received_from_ node_ID The transaction identifier is marked as "in_tip_{". This is followed by the marking of all those transaction identifiers in the candidate data repository as "in_tip_{ i }, to indicate that they are in the indexed area. i In the solved blocks.

[0151] Nodes can evaluate whether any additional arrays exist in the solution besides all arrays already seen from a particular node, as indicated by operation 816, based on the block solution. If none exist, the cleanup service does not need to take further action to tag transaction identifiers, because all included transaction identifiers will now be tagged as "in_tip_{" in the candidate data repository. i }".

[0152] If additional arrays are included that the node has not previously received, the node can request and receive details of the array contents. Right now, The array contains an ordered list of transaction identifiers. Then, in operation 818, the node can create a hash table in RAM, load the transaction identifiers from the new array, and perform an operation to query matching transaction identifiers from the candidate data repository. Any matching identifier is marked as "in_tip_{ i }, just like in methods 600 and 700 above.

[0153] The above operations are based on solved blocks from other nodes that contain all arrays previously announced by those nodes on the network. However, if, in operation 812, a node determines that the block solution omits one of the previously announced arrays from the solved block, it cannot simply mark all transaction identifiers from that other node as included in the block. In this case, if the block solution excludes one or more of these arrays, method 800 reverts to combining... Figure 7 The described process. Specifically, in operation 820, the node constructs an array of identifiers from the solved blocks. This list can be a hash table (e.g., a HashMap) or another such data structure. The hash table can be stored in the cleanup service's RAM.

[0154] In operation 822, once the hash table is built, the cleanup service uses the array identifier in the hash table to query candidate data repositories. For candidate data repositories, this array identifier (e.g., "in_{...}) is used... array_ID For each transaction identifier marked with "}", the cleanup service will subsequently also mark that transaction identifier as "in_tip_{ i }",in i This indicates the index of the announced block. As indicated in Operations 816 and 818, the cleanup service can also determine whether the block includes a new array that was not previously received, and if so, the cleanup service can add those transaction identifiers to the hash table and mark the corresponding transaction identifier in the candidate data repository as "in_tip_{ i }".

[0155] Regardless of whether the cleanup service can rely on node identifiers, once the blockchain service accepts a block, meaning the block has been determined to be valid and added to the blockchain, operation 824 is executed. As mentioned above, such a block can be called a tip. j In this case, the cleanup service then identifies candidate data repositories that are not marked "in_tip_{ j All transaction identifiers marked "in_tip_{j}" are retrieved and sent to the block assembly service so that the block assembly service can begin building new arrays and new candidate blocks. Any transactions marked "in_tip_{j}" are removed or deleted from the candidate data repository. In some cases, all transactions are removed from the candidate data repository, and once the transactions sent to the block assembly service are placed into candidate blocks, they are simply added back to the candidate data repository. In some other cases, the remaining transactions are left in the candidate data repository, provided that the block assembly service quickly adds these remaining transactions to the new candidate blocks being built. In this case, the markings of those transactions in some arrays may be removed.

[0156] In an alternative implementation, to alleviate the load on the candidate data repositories, the cleanup service can set up a candidate data repository for each other node in the network. That is, the number of replicas of the candidate data repository is the same as the number of nodes in the network. It should be understood that this involves significant data storage consumption because the same data repository is replicated for each of the other nodes. Each time a new transaction identifier is added to a candidate block, all candidate data repositories need to be updated to add those same transaction identifiers; however, when an array is received from a specific node, only the candidate data repository for that node is updated to tag the matching transaction identifiers with the array identifiers. Furthermore, it is not necessary to tag those transaction identifiers as associated with a specific node, because all tagged transaction identifiers in that data repository are associated with a specific node.

[0157] Many of the methods described above can be implemented using one or more computing devices, each having one or more processing units, memory, and communication subsystems. Suitable software, stored in memory and executable by one or more processing units, can configure the processing units to perform the described functions or operations. In some cases, a microservices architecture can be used to implement some or all of these methods. While the operations described above are presented in a linear format, it should be understood that some implementations can at least partially parallelize some of these operations and / or execute them in a different order without materially affecting the operation of these methods.

[0158] The various embodiments presented above are merely examples and are by no means intended to limit the scope of this application. The innovative variations described herein will be clearly apparent to those skilled in the art, and such variations are within the scope of this application. Specifically, features may be selected from one or more exemplary embodiments described above to create alternative exemplary embodiments, including feature sub-combinations that may not be explicitly described above. Additionally, features may be selected and combined from one or more exemplary embodiments described above to create alternative exemplary embodiments, including feature combinations that may not be explicitly described above. Upon reading this application as a whole, the features applicable to such combinations and sub-combinations will become clear to those skilled in the art. The subject matter described herein and in the stated claims is intended to cover and encompass all suitable technical modifications.< / pa>

Claims

1. A method for processing blockchain transactions by nodes, the method comprising: During the excavation phase Construct a candidate data repository, which contains a transaction identifier for each verified transaction in the candidate block; Receive two or more arrays from another node, each array containing a corresponding set of transaction identifiers; Identify the transaction identifier in the candidate data repository that matches the transaction identifier in one of the two or more arrays, and for each matching transaction identifier in the candidate data repository, record the array identifier of the one of the two or more arrays; During the block verification phase, after receiving the block solution from the other node, which identifies multiple arrays therein, Identify each transaction identifier associated with the other node in the candidate data repository, and mark those transaction identifiers as being in the block solution; as well as After the block solution is verified, all transaction identifiers in the candidate data repository that are not marked as being in the block solution are identified, and those transaction identifiers are provided to another service in the node.

2. The method of claim 1, wherein the recording comprises: For each matching transaction identifier in the candidate data repository, record the node identifier for the other node.

3. The method of claim 2, wherein identifying each transaction identifier associated with the other node in the candidate data repository comprises: Each transaction identifier in the candidate data repository is marked with the node identifier for the other node.

4. The method of claim 3, wherein each transaction identifier in the candidate data repository marked with the node identifier comprises: As a prerequisite, it is determined that all arrays received from the other node are included in the block solution.

5. The method according to any one of claims 1 to 4, wherein the block solution includes a new array not previously received from the other node, and the method further comprises: Obtain the set of transaction identifiers included in the new array, and load the transaction identifiers into memory; as well as The candidate data repository is queried for a match for each transaction identifier in the set, and if a match is found, the transaction identifier in the candidate data repository is marked as being in the block solution.

6. The method of claim 5, wherein the previously unreceived new array is an array that was not received during the mining phase.

7. The method according to any one of claims 1 to 6, wherein marking the transaction identifier in the block solution includes: The transaction identifier is marked in the tip i, where i is the index of the block solution among the plurality of announced block solutions.

8. The method of claim 1, wherein the blockchain network includes a plurality of other nodes, and wherein each node includes a corresponding candidate data repository for each of the other nodes, and wherein each transaction identifier associated with the other node in the candidate data repository includes: Identify the corresponding candidate data repository associated with the other node.

9. The method according to any one of claims 1 to 8, further comprising: When constructing the candidate data repository, construct the candidate block containing the verified transaction.

10. The method of claim 9, wherein the construction of the candidate block is performed by a block assembly service using a first memory, and wherein the candidate data repository is contained in a second memory separate from the first memory.

11. The method according to any one of claims 1 to 10, wherein providing those transaction identifiers to another service comprises: Those transaction identifiers are forwarded to at least the block assembly service for use in building new candidate blocks.

12. The method according to any one of claims 1 to 10, wherein providing those transaction identifiers includes: The other service is notified that the candidate database is available for access by the other service and that it contains all transaction identifiers not marked as being in the block solution.

13. The method according to any one of claims 1 to 12, wherein the other service includes a memory pool monitoring service or a double-spending detection service.

14. A computing device, the computing device comprising: One or more processors; Memory; as well as Computer-executable instructions stored in the memory, when executed by the one or more processors, cause the processors to perform the method according to any one of claims 1 to 13.

15. A computer-readable medium storing processor-executable instructions, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 13.

Images