Blockchain node and method for processing a large number of transactions

Abstract

Methods, devices, and data structures for processing a large number of transactions in a blockchain node without using a memory pool. Incoming transactions are validated and added to a candidate block. Transaction identifiers are added to an ordered set of transaction identifiers in an array until completion. The completed array and its Merkle root are propagated to other nodes. A placeholder transaction can be used in the first array in place of a coinbase transaction, and a Merkle path for the placeholder transaction can be determined so that the coinbase transaction can be substituted for the placeholder transaction during mining. After a subsequent array is completed, the subsequent array is appended to a merged list of transaction identifiers to continually build a growing candidate block for mining.

Description

Technical Field

[0001] This disclosure relates to blockchain networks, and more specifically to methods and apparatus for storing and retrieving Merkle tree data. 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 5A An example of a Merkle tree is shown; Figure 5B An example of a "partial" Merkel tree is shown; Figure 6 An example of the Merkel path is shown; Figure 7 The diagram illustrates a simplified, exemplary blockchain node used to handle a large number of blockchain transactions; Figure 8 An exemplary method for performing transaction processing in a blockchain node is illustrated in flowchart form; Figure 9 An exemplary method for managing unconfirmed transactions when a working proof solution is found is illustrated in flowchart form; Figure 10 An example of a simplified Merkle tree for the first array is shown.

[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 computer-implemented method for performing blockchain transaction processing in a node may be provided, the method comprising: appending transaction identifiers of verified transactions to an array as an ordered list of transaction identifiers; and determining that the array has reached its maximum size. The method further comprises: in response, determining an array summary value of the ordered list of transaction identifiers; adding the ordered list of transaction identifiers to a candidate block (which contains a previously completed list of ordered transaction identifiers) to form a merged list of ordered transaction identifiers; using the array summary value and the array summary value of the previously completed list of ordered transaction identifiers to determine a top-level summary value of the merged list of ordered transaction identifiers; modifying the block header of the candidate block to include the top-level summary value; and propagating the array to multiple other nodes on the blockchain network.

[0013] In some implementations, the method further includes: in response to determining that the array has reached its maximum size, providing header data of the candidate blocks to one or more mining units to search for proof-of-work. In some examples, each of the one or more mining units receives a partially complete block header and the array summary value, and performs the following operations: determining the top-level summary value, and modifying the block header to include the top-level summary value.

[0014] In some implementations, the method further includes: in response to determining that the array has reached its maximum size, initializing a new array to contain a new ordered list of transaction identifiers for subsequently received transactions and verified transactions; and when the new array has reached the maximum size, appending the new ordered list of transaction identifiers to the merged ordered list of transaction identifiers.

[0015] In some implementations, determining that the array has reached its maximum size includes determining that the transaction count has reached its maximum count, and optionally, said maximum count is 2.n One transaction, of which n It is an integer.

[0016] In some implementations, the method may further include: receiving a block solution from a mining unit at the node, the block solution including a coinbase transaction and a solved block header; propagating the block solution to other nodes on the blockchain network; and initializing a new empty first array.

[0017] In some implementations, the method may further include: receiving a block solution from another node on the blockchain network; verifying the block solution; and, in response to the verification of the block solution, comparing a transaction identifier from the block solution with transaction identifiers in the merged ordered list of transaction identifiers; removing any matching transaction identifiers from the merged ordered list of transaction identifiers; and initializing a new first array containing the remaining mismatched transactions from the merged ordered list of transaction identifiers.

[0018] In some examples, the block solution includes an ordered set of array identifiers and a block header, and verifying the block solution includes: retrieving array data corresponding to the ordered set of array identifiers from memory, wherein the array data includes a previously verified array summary value; using the previously verified array summary value to determine a block summary value; and verifying whether the determined block summary value is in the block header.

[0019] In some implementations, the method may further include: constructing a first array, wherein the first array includes placeholder transactions; determining Merkel paths for the placeholder transactions; and propagating the first array to the plurality of other nodes on the blockchain network, and optionally, propagating the Merkel paths of the placeholder transactions to the plurality of other nodes on the blockchain. In some examples, the method further includes: replacing the placeholder transactions with coinbase transactions at a mining unit, and using the Merkel paths to determine a first array summary value for the first array.

[0020] In some implementations, the method may further include: receiving array data from another node on the blockchain network, the array data including a first array identifier, a first array containing placeholder transactions, and a Merkel path of the placeholder transactions; verifying the Merkel path; and storing the array data in memory in association with the first array identifier.

[0021] In some examples, the method may further include: receiving a block solution from the other node, the block solution including a coinbase transaction and an ordered set of array identifiers, the ordered set of array identifiers including a first array identifier; retrieving the first array and the Merkel path from memory based on the first array identifier; and determining a first array summary value using the coinbase transaction and the Merkel path. In some examples, the block solution includes a block header, and verifying the block solution includes: retrieving array data corresponding to the ordered set of array identifiers from memory, wherein the array data includes a previously verified array summary value; determining a block summary value using the first array summary value and the previously verified array summary value; and verifying whether the determined block summary value is in the block header.

[0022] In some implementations, the summary value is Merkle.

[0023] On the other hand, a computing device for implementing nodes on a blockchain 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.

[0024] 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 processor to perform at least one of the methods described herein.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] Exemplary System Overview Figure 1An 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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).

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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).

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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, and it 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.

[0058] 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 1They 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.

[0059] Previous matters Tx 0 One or more outputs 203 are specific UTXOs, denoted as UTXO 0 Each 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.

[0060] 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.

[0061] Therefore, in the example shown, Tx 0 Output 203 UTXO 0 Including the locking script [Checksig] P AThis locking script requires Alice's signature (Sig). P A to redeem UTXO 0 (Strictly speaking, it is for the purpose of enabling 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.

[0062] 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.)

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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).

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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).

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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).

[0085] 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".

[0086] 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.

[0087] 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).

[0088] 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.

[0089] 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.

[0090] 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).

[0091] 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.

[0092] 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.

[0093] Merkel proves As described above, mining nodes group transactions into blocks. The block payload contains an ordered set of transactions, including coinbase transactions. Each block has a block header that includes various data fields, including a field containing a summary value determined based on the block's content. The summary value represents a fingerprint or summary of the block's content. Specifically, the summary value is determined based on the ordered set of transactions within the block. In many implementations, this summary value is a Merkle root. The Merkle root is determined by constructing a Merkle tree from the ordered set of transactions. While the following description refers to the Merkle root, the term "summary value" can be understood to include the Merkle root or other such data values ​​representing the content of the payload, such as a hash chain.

[0094] Merkle trees of ordered sets of elements are constructed by hashing each element and recursively creating the next level by concatenating adjacent hashed pairs of elements and hashing the concatenated hashed elements. Figure 5A A simplified example of a Merkle tree 500 is shown.

[0095] In this example, for ease of illustration, Merkle tree 500 involves an ordered set of only eight elements. Merkle trees in other examples can be smaller, or more commonly, much larger. The layers of Merkle tree 500 are labeled from bottom to top, where layer 0 is the base layer, and in this example, layer 3 is the Merkle root 502. Merkle tree 500 is created by first hashing the elements. That is, each base layer node 504 is the hash of the corresponding element at that position. In the case of Bitcoin, each base layer node 504 is the hash of its corresponding transaction (double SHA256 in Bitcoin's case). The double SHA256 hash of the transaction is also its transaction identifier, i.e., TxID. Therefore, in the case of Bitcoin, each base layer node 504 is the TxID corresponding to the transaction at that position in the ordered transaction set within the block.

[0096] To construct the first level of nodes in Merkle tree 500, the base level nodes are grouped into pairs. Within each pair, the elements are concatenated and then hashed to find the value of the parent node in the upper level. For example, if the base level pair 506 includes... TxID 2 and TxID 3. Then concatenate the two TxIDs as follows: TxID 2|| TxID 3. And the resulting value is hashed to calculate element 508.

[0097] The elements of level 2 are calculated as the hash of the concatenated pairs of elements of level 1, and so on. For example, element 512 is calculated based on the hash of the concatenated pairs of elements 510 and 508. Layers are constructed by calculating the intermediate hashes of nodes at intermediate levels of Merkle tree 500 until a single element is produced at the top level, which is called Merkle root 502.

[0098] It should be understood that not every block will have exactly 2 n A complete transaction set of elements. Such a case may produce a "partial" Merkle tree. Figure 5B It shows that there are five elements at level 0. For example An example of five transactions within a block. While the first four elements can be paired, the last transaction, indicated by reference numeral 520, does not have a corresponding paired element. It should be understood that a missing paired element at the base layer only occurs if the last element is the left-hand member of the pair. For the purpose of constructing the Merkle tree in this case, a "copy" of the left-hand element is used as the right-hand element; that is, the one indicated by reference numeral 520... TxID 4. Concatenate with itself and hash to find the value of the parent element at node 522. Similarly, since node 522 does not have a corresponding right element in its pair, the element at node 522 is concatenated with itself and hashed to find the value of the parent element at node 524 in the second level.

[0099] Merklegen 502 is inserted into the block header to serve as a fingerprint of transactions within the block.

[0100] Merkle trees can be used to enable lightweight nodes (e.g., client applications on end-user devices) to determine whether a transaction exists in a block on the blockchain, without necessarily downloading the entire block or the complete blockchain. Client applications can determine the existence of a transaction in a block based on Merkle proofs. A Merkle proof involves tracing a transaction path (Merkle path) through the Merkle tree to the Merkle root to confirm that the transaction is included in the block. The term "Merkle proof" can refer to the paired nodes within the Merkle tree required to compute the parent node on the Merkle path, which are adjacent to nodes on that path. Right now Calculate the nodes along the Merkel path in order to confirm the paired adjacent Merkel tree hashes / nodes required for the Merkel root.

[0101] A node can request Merkel proof data related to a transaction, and based on that data, the node can perform the Merkel proof. For example Tracing the Merkel path. In one example, the requested data can be provided as an ordered hash set and binary signals corresponding to the paired hashes required to reach the Merkel root along the path within the Merkel tree. These binary signals indicate whether the calculated and / or provided hash is the left or right element of each pair.

[0102] For the purposes of this discussion, the following conventions may be used. Use available data ( For example The elements calculated by hashing transaction data or concatenated elements of a Merkle tree can be obtained using c[ n Instructions, in which n This refers to the layers of a Merkle tree, and the bottom or base layer is... n =0. For the purposes of Merkel's proof, the elements of the Merkel tree provided by another node ( For example Intermediate hash) can be used with p[ n The intermediate hash can be referred to as a "paired hash," or as something from a "paired intermediate node," or "intermediate paired node," because each node has a corresponding paired node used to determine the parent hash value.

[0103] Figure 6 An example of a Merkel path through Merkel tree 600 is shown. In this case, the Merkel path relates to verifying the existence of transaction Tx in the block. To complete a Merkel proof using the Merkel path, the computing device has transaction Tx (or at least TxID) and an ordered set of hashes (intermediate hashes) corresponding to the elements required to form pairs along the Merkel path. In this example, the ordered set includes p[0], p[1], and p[2].

[0104] The computing device also needs a mechanism to determine whether the provided intermediate hash is a left or right element of a pair. In some cases, this can be signaled using binary flags. Binary flags can indicate whether, for each layer, the calculated hash (or the provided hash) is a left or right element. In some cases, the position of the hash calculated in the bottom or base layer can be signaled. Right now Instead of signaling whether the hash calculated (or the hash provided) at each level is a left-hand element or a right-hand element, the index of the ordered set of elements is used. In some implementations, these can be practically equivalent. For example, bitwise signaling of the calculated element at level 2 to level 0 along the Merkel path from Merkel root 602, tracing the left (0) or right (1) path, yields bits [0, 1, 0]. Equivalently, the index of element c[0] can be signaled. i= 2, its binary form is 010. Other implementations can use different signaling or encoding.

[0105] To perform the Merkel proof, the computing device obtains the TxID by hashing the transaction Tx (double SHA256 in this example), thereby determining the element c[0]. In some cases, the computing device may already have the TxID. The computing device then concatenates it with the first provided hash p[0] in the ordered hash set. The computing device then determines the c[0] element based on the index. i Alternatively, the computed hash c[0] can be determined as either a left-hand element or a right-hand element based on bit signaling, and concatenated accordingly. The compute device then hashes the concatenation to determine c[1]. The compute device continues this process until it determines c[3], then compares c[3] with Merkle root 602 found in the block header. If they match, the compute device has determined that transaction Tx is included in the block. If they do not match, transaction Tx is not included in the block (or the Merkle proof hash provided to the compute device contains an error).

[0106] The position of an element in an ordered set of elements in a layer can be called an "index," and in referring to the first... n When calculating the index of an element within a layer, you can use... i Or use index Of(c[ n The index is indicated by ]). At the bottom or base layer, the index... i The range is from 0 to the transaction count in the block minus one.

[0107] 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, new transaction flows could grow to tens of thousands, hundreds of thousands, or even millions of transactions per minute.

[0108] The current structure of the Bitcoin blockchain architecture assumes that nodes maintain a "mempool," a data structure containing all pending transactions that have been verified by the node. Nodes then selectively choose a subset of those transactions to include in candidate blocks. One or more mining units of a node mine within these candidate blocks, attempting to find proof-of-work. As new transactions enter a node and are verified, they are added to the mempool. If the current node finds proof-of-work on a candidate block, it propagates the solution. If a solution is received from another node, that current node verifies it. Once a valid proof-of-work is found, the node updates the mempool to remove transactions now confirmed in the block where their proof-of-work was found, and constructs a new candidate block based on the subset of current transactions in the block. The selection of the subset of transactions to include in a block can be based on transaction fees, time spent in the mempool, or other factors.

[0109] As transaction volume increases, the architecture's capacity may struggle to keep up with the new transaction flow. It is advantageous to modify the architecture and the methods used to handle new transactions and build candidate blocks to achieve greater throughput.

[0110] In one aspect of this application, a node architecture and transaction processing method capable of handling large transaction flows are described. A node may not maintain a memory pool; instead, it may add all new verified transactions to a candidate block. These transactions are added sequentially, and their corresponding transaction identifiers are added to an array that tracks ordered sets of transactions by transaction identifier. When the array reaches a threshold size (e.g., a maximum transaction count), the node can determine the Merkle root of the ordered list of transaction identifiers in the array and add it to the candidate block header, then provide the candidate block header to the mining unit to find proofs of work. The node can continuously build new arrays, and after each array is completed, it appends the transaction list of the array to the current candidate block, increasing the size of the candidate block each time so that the candidate block contains a merged ordered list of transactions, and provides the updated and / or modified candidate block header to the node's mining unit. When each new array is appended to the current ordered list of transaction identifiers, the Merkle root of that array, together with the Merkle root of the previously added ordered list of transaction identifiers, is used to determine the current Merkle root of the block and update the block header.

[0111] In another aspect of this application, a placeholder transaction can be placed in the first position of the first transaction identifier in the ordered transaction identifier list. The placeholder transaction is replaced with a coinbase transaction inserted by the mining unit before performing the proof-of-work search. Therefore, the mining unit determines the actual Merkle root of the first ordered transaction list, thereby determining the overall top-level Merkle root of the candidate block, which is then inserted into the block header and subsequently hashed to search for proof-of-work.

[0112] In many implementations, as used herein, the term "transaction identifier" can refer to a TxID created from a transaction using double hashing; however, in some implementations, a "transaction identifier" can be any other unique identifier for a transaction. In some cases, it may originate from different hashes or hash combinations. In some cases, it may be an abbreviation of a regular TxID, such as BIP152.

[0113] Now for reference Figure 7 The diagram illustrates a simplified exemplary blockchain node 700 for handling a large number of blockchain transactions. In this example, node 700 is shown as a single device; however, it should be understood that node 700 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.

[0114] Node 700 is configured to receive incoming transactions via computer network 702. Transactions can be received from user devices, point-of-sale devices, merchant computing devices, or other transaction sources. In some cases, transactions can be received from other blockchain nodes. Node 700 includes a transaction verification component 706. The transaction verification component 706 performs transaction verification according to the applicable blockchain protocol. This may include determining whether the transaction input is validly formatted and available in the UTXO set 704 maintained at node 700 in a data structure stored in memory. The transaction verification component 706 can be configured to verify transactions in parallel in many implementations to increase throughput.

[0115] The verified transactions can then be added to the candidate block. In this example, node 700 adds the transaction identifiers of valid transactions to array 708. In some cases, array 708 can be a one-dimensional array. In some implementations, the array can be multi-dimensional, but the transaction identifiers are added to array 708 so that they form an ordered list or set of transaction identifiers. The transactions themselves can be similarly stored in a data structure with the same order. In some cases, transactions are added directly to the candidate block 710, which is maintained in memory at node 700, by appending the transactions to the set of transactions in candidate block 710, in the same order that the corresponding transaction identifiers of the transactions were added to array 708. In some implementations, the node maintains a separate data structure storing transactions for each transaction corresponding to the transaction identifier in array 708 until array 708 is complete, and then the transaction batches from the separate data structure are appended to the transactions in candidate block 710.

[0116] It should be understood that node 700 does not maintain a separate memory pool storing all pending and unconfirmed transactions, and node 700 does not selectively select a subset of pending transactions to include in the candidate block. Instead, all incoming confirmed transactions are added to candidate block 710, and array 708 maintains a list of corresponding transaction identifiers.

[0117] When array 708 is complete, node 700 determines the Merkle root of the ordered list of transaction identifiers. Array 708 can be considered "complete" when it reaches a certain threshold size (e.g., maximum transaction identifier count, maximum byte size, or some other similar metric). In many implementations, the array size needs to be 2^35. n Except for the last array. For large-scale processing, array 708 may contain hundreds of thousands, or even millions, of transaction identifiers in some embodiments.

[0118] In the case of the first array to be completed, only its transactions are in candidate block 710, therefore its Merkle root is the top-level Merkle root of candidate block 710, but special handling is required for the coinbase transactions, as described below. Node 700 can provide mining units with data about candidate block 710 so that mining units can begin searching for proof-of-work. In some cases, this may include providing mining units with an ordered list of transactions from the array and Merkle root information determined by node 700, along with additional block header information. In other cases, this may include providing these units only with block header data and Merkle path data so that mining units can add coinbase transactions and determine the top-level Merkle root based on the coinbase transactions and Merkle path data.

[0119] Node 700 continues to build arrays with transaction identifiers based on the verified transaction flow. When each array is complete, its Merkle root is determined, an ordered list of transactions is added to the candidate block to create a merged ordered set of transactions, and a top-level Merkle root is determined from the new Merkle root and the Merkle roots of all previously added arrays. Thus, Node 700 generates a set of arrays, each containing a non-overlapping set of ordered transaction identifiers. Upon completion of each array, the candidate block is updated to add the new transaction set, and the modified / updated candidate block headers and / or candidate block data are pushed to the mining unit to search for proof-of-work.

[0120] Node 700 is also configured to "pre-share" array information before discovering proof of work. That is, node 700 sends data about the completed array to other nodes 700 via blockchain network 720. Blockchain network 720 can be the same network as computer network 702, a different network from computer network 702, a sub-network within computer network 702, or an overlay network on top of computer network 702. Networks 702 and 720 can include wired and / or wireless communication networks using various possible communication protocols.

[0121] By sending the complete array to other nodes, the other nodes are able to determine if they are missing any transactions and request those transactions from node 700. Once the other nodes receive the new transactions, they can verify them and add them to their own arrays and candidate blocks. Other nodes can also store array data of the received arrays. In this way, if node 700 finds a proof of work, verification is faster because the other nodes have already seen one or more arrays, determined that these arrays contain verified transactions that the node has already reviewed, and verified the Merkle root determination. The other nodes only need to combine the Merkle roots of the arrays and confirm the top-level Merkle root in the block header.

[0122] In some cases, array 708 can be called a sub-tree because its transaction identifiers form part of an ordered list of transaction identifiers that can be in the total merge of candidate blocks, making the transaction identifiers from the array a part of the Merkle tree for finding candidate blocks. Right now "Subtree". Each array has a unique array identifier, or "subtree identifier," which is sent along with the array when propagated to other nodes through the blockchain network 720. 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 node 700 receives an array from other nodes, it determines whether it has received and verified all transactions listed in the array through 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.

[0123] Therefore, if the mining unit at node 700 finds a valid proof-of-work for a candidate block, its output solution includes a random number and other block header data, as well as the coinbase transaction included in the block. Node 700 forwards the solution to other nodes via blockchain network 720. The solution forwarded to other nodes may include the block header, the coinbase transaction, and an ordered array identifier set. The ordered array identifier set informs other nodes which arrays are in the successfully mined candidate blocks. This allows nodes to reconstruct the solved block based on the ordered array identifier set and the stored array data. Receiving nodes, having previously verified the transactions within the array and the Merkle root of the array, only need to use the Merkle root of the array, the coinbase transaction, and the corresponding Merkle path data of the coinbase transaction to construct the upper part of the Merkle tree, as described below. Therefore, they can verify the Merkle root in the block header and confirm the validity of the block solution.

[0124] If one of the other nodes has not seen an array of the array specified by the array identifier, then it can, for example, use INV The message or equivalent request message requests the array from node 700.

[0125] When node 700 receives a block solution from another node in the blockchain network 720, it performs the same process: retrieving the stored array from memory based on the array identifier sent in the block solution, searching for the Merkle root in the coinbase transaction and array Merkle root and confirming that it matches the Merkle root in the block header, and verifying that the hash of the block header is a valid solution. If the solution is valid, Right now If the solution is a solved block, node 700 adds the block to its blockchain replica in the usual manner. Then, the node removes all transactions from the solved block from its own candidate blocks and from any arrays of storage used to build the candidate blocks. Since no separate mempool is maintained, no mempool needs updating, but confirmed transactions are either extracted from or removed from the arrays and candidate blocks. This may result in all transactions being removed from the candidate blocks and arrays, or some unconfirmed transactions being left behind. If any unconfirmed transactions are left behind, they are grouped into ordered sets of transactions forming one or more new arrays, and new candidate blocks containing these new arrays are generated, and the mining process continues.

[0126] Many of the functions performed by node 700 can be implemented using a microservices architecture.

[0127] Now for reference Figure 8 This illustrates an exemplary method 800 for processing transactions in a blockchain node. Method 800 can be performed by a node (e.g., node 700). Figure 7 This method 800 is 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 the one or more processing units, can configure the processing units to perform the described functions or operations. In some cases, a microservices architecture may be used to implement method 800. Although the operations described below are presented in a linear format, it should be understood that some implementations may at least partially parallelize some of these operations and / or execute them in a different order without materially affecting the operation of method 800.

[0128] In operation 802, the node verifies the incoming transaction. Transaction verification is performed in a common manner according to the applicable blockchain protocol and may include confirming that the transaction's inputs have not yet been consumed. This may include verifying the availability of inputs through a set of UTXOs stored in memory. In operation 804, the node may then update the UTXO set to indicate that the transaction's inputs have been consumed, thereby avoiding potential double-spending in subsequent transactions. Various techniques can be employed to resolve conflicts between two unconfirmed transactions using the same one or more inputs and to determine which unconfirmed transaction is considered valid and which is considered invalid.

[0129] In operation 806, the node adds a verified transaction identifier to the array by appending it to an ordered list of transaction identifiers. Transactions can be added to candidate blocks and / or stored in memory in association with their transaction identifiers. As mentioned above, the array can be a one-dimensional array holding the ordered list of transaction identifiers. In some cases, the array can be implemented as a multi-dimensional array using a suitable data structure, provided that the transaction identifiers in the array are still arranged sequentially using some known storage pattern. In this example, the array is stored in memory at the node.

[0130] In operation 810, the node evaluates whether the array is complete. Determining array completeness can be based on the array's contents reaching a maximum or threshold number. This determination can be based on an array with N transaction identifiers, where N is an integer value. To enable concatenation of the list of transaction identifiers from the arrays and to build the top level of the Merkle tree based on the array Merkle root after the arrays are merged, the transaction count in each array conforms to 2^N. n The size of the array. If it is incomplete, the node continues to add newly verified transactions to the array, as these transactions flow into the transaction verification component or service and are processed.

[0131] If the array is considered complete, the node determines the Merkle root of the array in operation 810. Based on an ordered list of transaction identifiers, the node constructs a Merkle tree by concatenating and hashing pairs of transaction identifiers, building level by level until it reaches the top-level Merkle root of the array. The node can store the Merkle root of the array in memory in association with the array. In some cases, the Merkle root of the array also serves as a unique array identifier. In some cases, a separate array identifier is determined, such as by hashing the entire array or using some other mechanism to generate a unique identifier.

[0132] In operation 812, the node updates the candidate block header data. In some cases, this may include calculating the Merkle root of the candidate block header data based on the Merkle root determined in operation 810 for the newly completed array. If the transactions of the newly completed array are appended to an existing ordered set of transactions in the candidate block corresponding to previously completed arrays, then the determination of the Merkle root for the candidate block is based on the Merkle roots of those previously completed arrays and the Merkle root of the newly completed array.

[0133] Nodes maintain candidate blocks in memory, which sequentially include transactions corresponding to the complete array. In some cases, when a node adds a transaction's transaction identifier to the array in operation 806, it appends the transaction to the candidate block. In other cases, when a transaction identifier is added to the current array, the node stores the transaction in a separate data structure in memory, and subsequently, after the array is complete, the node appends the complete set of transactions from the separate data structure to the candidate block.

[0134] Candidate blocks have associated candidate block headers. The candidate block header may be a partially complete header that does not yet have a value in the Merkle root field. In some cases, the candidate block header data updated in operation 812 includes the Merkle root of a merged list of transactions represented by one or more arrays added to the candidate block. In some cases, operation 812 includes adding the newly completed array Merkle root to the list of array Merkle roots to be provided to the mining unit, which then uses those array Merkle roots and the coinbase transactions added to the block by the mining unit to determine the top-level block Merkle root. In some cases, the candidate block header data includes Merkle paths for coinbase transactions so that the mining unit can quickly determine the first array of Merkle roots in the block after determining its respective coinbase transactions.

[0135] In operation 814, the node propagates the newly completed array to other blockchain nodes on the blockchain network. Array propagation includes sending array data, such as an ordered list of transaction identifiers and the array identifier. Propagation may also include sending the array Merkle root. In some cases, the array Merkle root is also the array identifier.

[0136] The node also enables the mining unit to begin processing the updated candidate blocks ( Right now Mining (blocks with newly completed array transactions attached) is performed as instructed in Operation 816. This may include pushing updated candidate block header data to the mining unit, which then determines and inserts the coinbase transaction and computes the top-level Merkle root, after which the mining unit begins searching for proof-of-work.

[0137] In operation 818, the node initializes the new array and returns to operation 802 to begin building the new array with the incoming verified transaction.

[0138] Now for reference Figure 9 This illustrates an exemplary method 900 for managing pending transactions when a working proof solution is found. Method 900 can be configured by nodes (e.g., node 700). Figure 7 This method 900 is 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 the one or more processing units, can configure the processing units to perform the described functions or operations. In some cases, a microservices architecture may be used to implement method 900. Although the operations described below are presented in a linear format, it should be understood that some implementations may at least partially parallelize some of these operations and / or execute them in a different order without materially affecting the operation of method 900.

[0139] Operation 902 indicates the process of array construction and mining, as described above. Figure 8 As described above. This may include verifying transactions, constructing an array containing an ordered set of transaction identifiers, sharing this array with other nodes, adding transactions to candidate blocks, and determining the Merkle root of the array and the top-level Merkle root of the candidate block header based on the merged set of transactions in the candidate blocks and their respective array Merkle roots. As described above, array construction and mining are performed without using a memory pool, so that all verified transactions are added to the array and used to construct candidate blocks.

[0140] In operation 904, the node evaluates whether its mining unit has successfully found proof-of-work. In operation 910, the node evaluates whether it has received a proof-of-work solution from another node on the blockchain network. Although Figure 9 As shown sequentially, it should be understood that these operations can occur in parallel. In many implementations, operations can be initiated by an interruption or other notification from one mining unit or another node on the blockchain network. The absence of any such interruption or notification regarding the solution will redirect method 900 back to operation 902 to continue building the array and mining.

[0141] If one of the mining units finds a proof of work, as indicated in Operation 904, then in Operation 906, the node propagates the solution across the blockchain network. It is noteworthy that since the node has previously propagated an array reflecting the contents of the candidate blocks mined by the mining unit, the message conveying the solution can include block header data, such as the top-level Merkle root, a random number, and other such data, and may include the coinbase transaction used by the mining unit in the candidate block. The message conveying the solution may also include an ordered list of array identifiers signaling the contents of the candidate block. Any other node among the other nodes that has not yet received any of the arrays can then respond to the message by requesting any missing arrays. At the other nodes, a solved block can be constructed based on the array data corresponding to the array identifiers retrieved from local storage, and the solution can then be verified. In many cases, the other nodes have previously verified the arrays because they confirm that the transaction identifiers in the array have been seen and independently verified by those other nodes, and that the array Merkle root is valid. Therefore, upon receiving notification of the solution, the other nodes only need to use the already verified array Merkle root to construct the top of the Merkle tree in order to verify the block header.

[0142] In operation 908, the node can clear its array and candidate block data because all previously pending unconfirmed transactions listed in the array are now included in the mined blocks. The node can then further update the copy of the blockchain maintained at the node with the newly mined blocks. An empty array can then be initialized, and method 900 returns to operation 902 to start again. Initialization of the empty array may include inserting a placeholder transaction at the first index position in place of the coinbase transaction, as discussed further below.

[0143] If a node determines in Operation 910 that the proof-of-work has been found by another node in the blockchain network, for example, by receiving a block decryption message, then in Operation 912, the node verifies the newly mined block. Block verification may include constructing a Merkle tree to look up the Merkle root in the block header received in the block decryption message. The block decryption message may also include an ordered list of array identifiers that signal which transaction sets are in the block and in what order. The node confirms that it has received and verified the array data for each array identifier in the array identifiers, including confirming the array Merkle root. If the node has not yet received and verified the array corresponding to one of the array identifiers, it requests that data from the blockchain network.

[0144] Since the node has already verified the array and the array Merkle root, the node only needs to construct the top of the Merkle tree to verify the top-level Merkle root in the block header. The node has also already verified the transactions listed in the array through its Merkle root. Therefore, the verification of the block solution can occur much faster than in earlier blockchain systems.

[0145] Once a block solution is verified, in operation 914, the node compares the transactions and transaction identifiers in the solved new block with the transactions and transaction identifiers in the node's current candidate blocks, as well as an array stored in memory. The node removes or deletes any matching transactions and transaction identifiers, leaving only unconfirmed transactions and transaction identifiers not included in the solved block. In other words, the node cleans up its candidate blocks and its array containing any transactions that have been confirmed in the block. The remaining transactions are unconfirmed and will be included in the next candidate block the node attempts to mine.

[0146] In operation 916, the node forms one or more new arrays containing unconfirmed transactions remaining after cleaning up one or more old arrays with confirmed transactions. Then, method 900 returns to operation 902 to construct one or more arrays and mine candidate blocks using the new confirmed transaction inflow.

[0147] Now for reference Figure 10 The diagram illustrates a simplified Merkle tree 1000 for the first array. The first array can be the first array constructed for candidate blocks. In this simplified example, the first array includes a set of eight transaction identifiers (TxIDs) at level 0 of the array. The first TxID is a placeholder transaction at p[0,0].

[0148] In this example, the coinbase transaction would first be positioned in the list of all transactions contained within the block being mined. Normally, a mining unit could insert its coinbase transaction and compute the Merkle tree of the block so that the Merkle root is inserted into the block header before mining. However, in this example, the array is constructed by the nodes, and the array Merkle root is determined by the nodes and then provided to one or more mining units. Therefore, the nodes insert placeholder transactions in positions that would normally be occupied by coinbase transactions. The mining unit can then replace the placeholder transactions with coinbase transactions before mining a candidate block.

[0149] It should be understood that if a transaction in an ordered set of transactions is to be replaced, a node cannot accurately provide the array Merkle root of the ordered set of transactions. However, a node can provide a Merkle path that can quickly determine the array Merkle root of the first array. Using the exemplary simplified tree shown, a node can determine a Merkle path including nodes p[0,1], p[1,1], and p[2,1], where the symbols use the convention p[ class , index This indicates which nodes are computed by the nodes and provided as part of the Merkel path.

[0150] Then, once the mining units insert a coinbase transaction at position p[0,0], they use the Merkle path values ​​of p[0,1], p[1,1], and p[2,1] to compute the values ​​at c[1,0], c[2,0], and the array Merkle root at c[3,0].

[0151] Therefore, in the above description regarding the operation of transmitting or propagating arrays and array Merkle roots, it should be understood that, for the first array, this includes sending the coinbase Merkle path instead of the array Merkle root. This allows the mining unit and other nodes on the blockchain network to easily determine the array Merkle root after the coinbase transaction is available and used in place of the placeholder transaction.

[0152] 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 computer-implemented method for performing blockchain transaction processing in a node, the method comprising: Append the transaction identifiers of verified transactions to an array to form an ordered list of transaction identifiers; as well as Determine that the array has reached its maximum size, and in response, Determine the array summary value of the ordered list of transaction identifiers. The ordered list of transaction identifiers is added to the candidate block containing the previously completed ordered list of transaction identifiers to form a merged ordered list of transaction identifiers. The top-level summary value of the merged ordered transaction identifier list is determined using the array summary value and the array summary value of the previously completed ordered transaction identifier list. Modify the block header of the candidate block to include the top-level summary value; as well as The array is then propagated to multiple other nodes on the blockchain network.

2. The method according to claim 1, further comprising: In response to the determination that the array has reached its maximum size, the header data of the candidate blocks is provided to one or more mining units to search for proof of work.

3. The method of claim 2, wherein each of the one or more mining units receives a partially complete block header and the array summary value, and performs the following operations: determining the top-level summary value, and modifying the block header to include the top-level summary value.

4. The method according to any one of claims 1 to 3, wherein the method further comprises: In response to the determination that the array has reached its maximum size, a new array is initialized to contain a new ordered list of transaction identifiers for subsequently received transactions and verified transactions; And when the new array has reached the maximum size, the new ordered list of transaction identifiers is appended to the merged ordered list of transaction identifiers.

5. The method according to any one of claims 1 to 4, wherein determining that the array has reached its maximum size includes determining that the transaction count has reached its maximum count, and optionally, wherein the maximum count is 2. n One transaction, of which n It is an integer.

6. The method according to any one of claims 1 to 5, further comprising: Receive block solutions from the mining unit at the node, the block solutions including coinbase transactions and solved block headers; The block is then propagated to other nodes on the blockchain network. as well as Initialize a new empty first array.

7. The method according to any one of claims 1 to 5, further comprising: Receive block solutions from another node on the blockchain network; Verify the block solution; In addition, in response to the verification of the block solution, the transaction identifier from the block solution is compared with the transaction identifier in the merged ordered list of transaction identifiers; Remove any matching transaction identifier from the merged list of ordered transaction identifiers; And, initialize a new first array containing the remaining mismatched transactions from the merged ordered list of transaction identifiers.

8. The method of claim 7, wherein the block solution comprises an ordered array of identifiers and a block header, and wherein verifying the block solution comprises: Retrieve array data corresponding to the ordered set of array identifiers from memory, wherein the array data includes previously verified array summary values; The block summary value is determined using the previously verified array summary value; as well as Verify whether the determined block summary value is present in the block header.

9. The method according to any one of claims 1 to 8, further comprising: Construct a first array, wherein the first array includes placeholder transactions; Determine the Merkel path for the placeholder transaction; as well as The first array is propagated to the plurality of other nodes on the blockchain network, and optionally, the Merkel path of the placeholder transaction is propagated to the plurality of other nodes on the blockchain.

10. The method according to claim 9, further comprising: At the mining unit, the placeholder transaction is replaced with a coinbase transaction, and the Merkel path is used to determine the first array summary value of the first array.

11. The method according to any one of claims 1 to 8, further comprising: Receive array data from another node on the blockchain network, the array data including a first array identifier, a first array containing placeholder transactions, and the Merkel path of the placeholder transactions; Verify the stated Merkel path; as well as The array data is stored in memory in association with the first array identifier.

12. The method according to claim 11, further comprising: Receive a block solution from the other node, the block solution including a coinbase transaction and an ordered array identifier set, the ordered array identifier set including the first array identifier; Based on the first array identifier, retrieve the first array and the Merkel path from memory; and use the coinbase transaction and the Merkel path to determine the summary value of the first array.

13. The method of claim 12, wherein the block solution includes a block header, and wherein verifying the block solution includes: Retrieve array data corresponding to the ordered set of array identifiers from memory, wherein the array data includes previously verified array summary values; The block summary value is determined using the first array summary value and the previously verified array summary value; as well as Verify whether the determined block summary value is present in the block header.

14. The method according to any one of claims 1 to 13, wherein the summary value is Merklegen.

15. 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 14.

16. A computer-readable medium storing processor-executable instructions, the processor-executable instructions including instructions which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 14.

Images