Node architecture for high capacity blockchain networks

Abstract

Methods, systems, and data structures for processing large volumes of transactions in blockchain nodes. The system may include: a propagation service for receiving and propagating blockchain transactions through the blockchain network; a transaction verification service for receiving transactions from the propagation service and verifying whether the received transactions conform to the blockchain protocol rules; a block assembly service for creating block templates for mining by the computing system, including creating one or more subtrees of verified transactions; one or more miners for searching for proof-of-work with respect to the block template; a verifier service for receiving and verifying incoming subtrees from other blockchain nodes on the blockchain network, and for verifying the validity of new blocks based on previously verified subtrees after receiving block solutions; and a blockchain service for managing block headers and subtree lists within blocks.

Description

Technical Field

[0001] This disclosure relates to blockchain networks, and more specifically to methods and devices for processing large volumes of transaction flows. Background Technology

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

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

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

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

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

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

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

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

[0010] As an example, reference is now made to the accompanying drawings illustrating exemplary embodiments of this application, in which: Figure 1 An exemplary system for implementing blockchain is shown; Figure 2 An exemplary transaction protocol is shown; Figure 3A An exemplary implementation of the client application is shown; Figure 3B An example of the user interface for the client application is shown; Figure 4 An exemplary node software for a blockchain node is shown; Figure 5 The diagram illustrates a simplified, exemplary blockchain node used to handle a large number of blockchain transactions; Figure 6A An overall view of an exemplary architecture of blockchain nodes, composed of different microservices and showing their interactions, is presented. Figures 6B to 6E It shows Figure 6A Enlarged images of each part to improve readability; Figure 7 shows an exemplary sequence diagram reflecting some of the operations in the operation of an exemplary blockchain node; Figure 8The diagram illustrates exemplary elements of the transaction propagation service; Figure 9 The diagram illustrates exemplary elements of the transaction verification service; Figure 10 The diagram illustrates exemplary elements of the block assembly service; Figure 11 The diagram illustrates exemplary elements of the verifier service; Figure 12 The diagram illustrates exemplary elements of a blockchain service; Figure 13 The diagram illustrates exemplary elements of a traditional peer-to-peer (P2P) service.

[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 computing system for processing blockchain transactions can be provided. The system may include one or more processing units; and a memory storing processor-executable instructions. When executed by the one or more processing units, the instructions cause the one or more processing units to implement: a propagation service for receiving and propagating blockchain transactions through a blockchain network; a transaction validation service for receiving transactions from the propagation service and validating whether the received transactions conform to blockchain protocol rules; a block assembly service for creating block templates for mining by the computing system, including creating one or more subtrees of validated transactions; one or more miners for searching for proof-of-work with respect to the block templates; a validator service for receiving and validating incoming subtrees from other blockchain nodes on the blockchain network, and for validating the validity of new blocks based on previously validated subtrees after receiving block solutions; and a blockchain service for managing block headers and subtree lists within blocks.

[0013] In some implementations, the system includes one or more data storage devices, and the instructions, when executed by the one or more processing units, also cause the one or more processing units to implement an asset service, which serves as an interface between microservices and data elements stored in the data storage devices.

[0014] In some implementations, the instructions, when executed by the one or more processing units, also cause the one or more processing units to implement a coinbase service for monitoring new coinbase transactions on the blockchain, recording the new coinbase transactions, and tracking the maturity of the new coinbase transactions.

[0015] In some implementations, the system includes a data storage device, and the instructions, when executed by the one or more processing units, also cause the one or more processing units to use the data storage device to implement UTXO storage, wherein the UTXO storage is used to track unspent transaction outputs and to respond to requests for unspent transaction output information from the transaction verification service and / or the verifier service.

[0016] In some implementations, the system includes a data storage device, and the instructions, when executed by the one or more processing units, also cause the one or more processing units to use the data storage device to implement transaction metadata storage, wherein the transaction metadata storage is used to store transaction data, and transaction metadata including at least a hash list of the parent transactions of the transaction.

[0017] In some implementations, the instructions, when executed by the one or more processing units, also cause the one or more processing units to implement a prohibition list service, wherein the prohibition list service is used to track the node identifiers of nodes that are prohibited from operating on the blockchain network due to violations of network protocol rules.

[0018] On the other hand, this application describes a method for nodes to process blockchain transactions. The method may include: sending and receiving blockchain transactions via a multicast broadcast service through a blockchain network; verifying the received blockchain transactions based on blockchain network protocol rules; assembling one or more subtrees based on the verified transactions, adding the one or more subtrees to a block template for mining by one or more mining units while assembling the one or more subtrees, and transmitting the one or more subtrees to other nodes on the blockchain network; receiving external subtrees from the other nodes on the blockchain network and verifying and storing the external subtrees while mining is in progress; and receiving a block solution from one of the other nodes and verifying the block solution using the verified external subtrees, and appending the solved block to the blockchain once verified.

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

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

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

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

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

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

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

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

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

[0028] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby enabling transaction 152 to propagate 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 respective memory.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0060] 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 to another valid transaction is formed in blockchain 150.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0104] An architecture overview of nodes constructed to handle large volumes of transaction flows will now be described.

[0105] Some implementations of blockchain networks impose constraints on block size, such as up to 1 megabyte. In some instances, this measure may have been implemented to prevent spam transactions when cryptocurrency adoption was still in its early stages. This size limit inherently restricts network throughput to approximately 3.3 to 7 transactions per second. As adoption increases, this constraint leads to bottlenecks in transaction processing, resulting in increased latency and transaction costs, highlighting the need for scalable solutions.

[0106] This application provides a node architecture and a method for addressing at least some of the challenges of vertical scaling by distributing workloads across multiple machines. This horizontal scaling approach, combined with an unlimited block size, enables network capacity to grow with demand by adding cluster nodes, thus achieving truly unlimited scaling.

[0107] The described processing system can sustainably handle over one million transactions per second. Nodes are designed as collections of services that work together to provide a decentralized, scalable, and secure blockchain network. Nodes are designed to be modular to allow for easy integration of new services and functionalities.

[0108] Now for reference Figure 6A The diagram illustrates an exemplary blockchain node composed of different microservices and shows their interactions. Figure 6A An overall view of the architecture is shown. Figures 6B to 6E It shows Figure 6A Enlarged images of each part are provided to improve readability.

[0109] The core node services are as follows: 1. Propagation Service: Responsible for receiving transactions (from other nodes) and propagating transactions (to other nodes).

[0110] 2. TX Verification Service: Checks the correctness of transactions and compliance with network rules.

[0111] 3. Block Assembly Service: Assemble blocks for the blockchain.

[0112] 4. Blockchain Service: Responsible for managing the block headers and subtree lists within the blocks.

[0113] 5. Block Verification Service: Verifies new subtrees and blocks before adding them to the blockchain.

[0114] In addition, nodes can include various overlay services, such as: 1. Traditional P2P Bridge: This service handles traditional peer-to-peer communication within a blockchain network. Since older (traditional) nodes cannot communicate directly with newer nodes, this service acts as a bridge between the two types of nodes.

[0115] 2. Peer Service: This service handles node discovery to manage connections with peer nodes in the network.

[0116] 3. Coinbase Cover Node: This service tracks and stores coinbase transactions, which are the first transactions in a block to create new coins and reward miners.

[0117] 4. TX / TXO lookup service: This service is used to query transactions and transaction output data within a "range".

[0118] 5. TX Commit (ARC): Submits a transaction to the network on behalf of the propagation service management.

[0119] 6. Prohibited List Service: Maintains and verifies a list of prohibited entities or nodes.

[0120] 7. UTXO Lookup Service: Retrieves information about unspent transaction outputs, which are crucial for verifying new transactions.

[0121] In addition to coverage services, nodes can also include additional services, such as: 1. Message Broker: Middleware that facilitates communication between different services.

[0122] 2. TX Status Store: Maintains tracking of the state of transactions within the system.

[0123] 3. Hasher: Performs the hashing calculations that are the core of the mining process.

[0124] In one aspect, this application provides certain changes to the way data is organized and propagated in a blockchain network (e.g., between blockchain nodes). In one example, the block size is infinite, enabling each block to handle a potentially infinite number of transactions, which eliminates any limitations on increasing throughput and ultimately reduces transaction fees.

[0125] In traditional Bitcoin, the block solution sent to other blockchain nodes contains all transactions (including all transaction data) for every transaction it contains, not just the transaction identifier. This means that if many transactions are included, the block size will be extremely large. From a scalability perspective, this is impractical because the block size would be too large to propagate through the network in a timely manner.

[0126] According to one aspect of this application, a transaction can be an "extended transaction" that includes additional metadata to facilitate processing. These transactions are broadcast to nodes on the network when encountered or occurring. Extended transactions may include tags to indicate that they are extended transactions. Extended transactions may include additional data such as "previous TX output" (which is the output value in satoshis of the previous input), "previous TX script length" (which is given as a non-negative integer), and / or "previous TX locking script" (which is the script associated with the output that was one of the inputs). Further information regarding extended transactions can be found in Bitcoin Improvement Protocol (BIP) 239 of November 9, 2022, the contents of which are hereby incorporated herein by reference.

[0127] subtree The subtree acts as an intermediate data structure to store the batch of transaction identifiers (including metadata) and the corresponding Merkle root of the subtree. It should be noted that the size of the subtree can be any number of transactions, as long as it is a power of 2 (16, 32, 64…). In some embodiments, all subtrees within a block must have the same size. At peak throughput, a subtree can contain millions of transaction identifiers.

[0128] The subtrees are broadcast once per second (assuming a baseline throughput of 1 million transactions per second), making data propagation more continuous, rather than batching every 10 minutes. By broadcasting these subtrees at such a high frequency, receiving nodes can quickly and continuously verify these batches, "pre-approving" them for inclusion in a block. This contrasts with some blockchain systems where new blocks, and therefore new batches of transactions, are broadcast approximately every ten minutes after being confirmed by the miner.

[0129] The subtree includes only the transaction ID, not the complete transaction data, because all nodes already have these transactions, thus reducing the size of the data to be propagated. Since it is assumed that all nodes participating in the network already have the complete transaction data (which these nodes receive and store as transactions are created and distributed across the network), there is no need to rebroadcast the full details of each subtree. The subtree then allows nodes to confirm that they have all relevant transactions and update their state accordingly, without duplicating large amounts of data.

[0130] Resolved block messages may contain a list of subtree identifiers, but not transactions or transaction identifiers. This is useful for nodes, as they are continuously processing subtrees to allow for rapid block verification. When a block is found, verification is accelerated due to the continuous processing of subtrees. If a node encounters a subtree within a new block that it is unaware of, it can request details from the node that committed the block.

[0131] Node Workflow From a high-level perspective, the exemplary node can perform the following functions or operations: 1. Transaction Commit: Transactions are committed to the network via the commit service. Blockchain nodes subscribe to IPv6 or an alternative broadcast service, and it is expected that all nodes will receive the transaction.

[0132] 2. Transaction Verification: Transactions are verified by the TX verification service. This service checks each received transaction according to network rules to ensure it is correctly formed and that its inputs are valid and unexpended (verified by the UTXO lookup service). Once verified, the transaction's status is updated in the TX state store to indicate that it has not yet been included in a block and meets the inclusion criteria.

[0133] 3. Subtree Assembly: The block assembly service ingests transactions and organizes them into subtrees. A "subtree" is a key component of a node, allowing for efficient processing of transactions and blocks. A subtree can contain a million or more transactions. Once a subtree is created, it is broadcast to all other nodes in the network. It is expected that different blockchain nodes on the network will reach similar or equal subtree compositions. All nodes should have roughly the same transactions in their subtrees, but the grouping and order of transactions may differ. As nodes build their subtrees, these nodes broadcast these subtrees to each other.

[0134] 4. Subtree Verification: The block verification service verifies the subtrees it receives. This involves checking the transactions within the subtree according to network rules and ensuring that they are correctly formed and that their inputs are valid and unexpended (verified by the UTXO lookup service). Once verified, the subtree's state is updated, marking it as compliant with inclusion criteria. If the subtree is invalid, it is discarded and not included in the block. If the subtree is valid, it is stored for later use in block verification and block assembly to clean up transactions and prepare for the next block template.

[0135] 5. Block Assembly: The block assembly service compiles block templates containing subtrees. These templates are pre-blocks that the node miner service will use to create the complete block. Once a hash processing solution has been found, the block is broadcast to all other nodes for verification.

[0136] 6. Block Verification: Once a node finds a valid hash solution (successful proof-of-work), it sends the found block to the block verification service. This service checks the new block according to the network's consensus rules. If the block is valid, the node appends it to its blockchain version.

[0137] Figure 7 shows an exemplary sequence diagram reflecting some of the operations / functions described above.

[0138] As described above, the exemplary blockchain node according to this application can be designed as a collection of microservices, each microservice handling a specific function. For example, a node may include the following services: Transaction propagation service. This service is responsible for receiving transactions from other nodes and forwarding them to the verifier service, as well as propagating transactions to other nodes. Figure 8 The diagram illustrates exemplary elements of the service, such as: 1. TX Storage Service: This is the data repository that stores all received transactions, whether invalid or compliant enough to be included in the next block template.

[0139] 2. Multicast Receiver Services (Multiple Instances): These services are responsible for listening for transactions broadcast over the network. These services listen for IPv6 multicast network addresses reserved for transactions. Multiple instances exist, each listening on a fixed set of IPv6 addresses, thus providing a horizontally scalable design to allow handling more transactions by increasing the number of service instances. Any number of these multicast receiver services can be running; this is part of how the system achieves scalability.

[0140] 3. Message Broker: This is the communication layer used by the multicast receiver service to forward extended transactions to the verification service. The use of a message broker introduces decoupling between services, thereby allowing for a more scalable and maintainable system.

[0141] 4. Soundness Check: Before sending a transaction to the verification service, the multicast receiver service performs basic verification to ensure that the transaction is correct and complies with network protocols.

[0142] It should be noted that while the main network may use multicast for propagation, the test network simplifies operations by using gRPC (a high-performance, open-source, general-purpose RPC framework) to enable direct communication between the propagation and verification services, bypassing the need for IPv6 broadcasts.

[0143] Transaction Verification Service. The transaction verification service is responsible for verifying transactions according to network rules and then sending the approved transaction identifier to the block assembly service. Transactions that have passed the TX verification service are immediately marked as spent in the UTXO store. After the UTXO is marked as spent, the transaction metadata is stored in the TX state store and forwarded to the block assembly service via the message broker. Figure 9 The diagram illustrates exemplary elements of the service, such as: 1. Message Broker: A communication layer that facilitates message passing between the propagation service and the verification service, as well as between the verification service and the block assembly service.

[0144] 2. Transaction Verification Service (Multiple Instances): Multiple instances of the service can be initiated, allowing transactions to be verified in parallel, which helps improve throughput and scalability.

[0145] 3. TX id: After verification, the transaction identifier (id) is passed to the block assembly service.

[0146] 4. UTXO service: A data repository for UTXOs (outputs from transactions that have not yet been spent and can be used as inputs in new transactions).

[0147] 5. TX Status: A data repository that manages the status of transactions. Transaction statuses are eligible to be included in blocks if they have been verified and not yet mined.

[0148] Block Assembly Service. This service is responsible for creating subtrees and block templates for hashing by the miner service. Block assembly broadcasts any newly created subtrees to the network. The block assembly service performs subtree assembly and block assembly. The subtree assembly service ingests transactions and organizes them into subtrees. Once a subtree is created, it is broadcast to other nodes in the network. The block assembly service compiles the block template composed of subtrees. Once a hash solution is found, the solved block template is broadcast to other nodes for verification. Figure 10 The diagram illustrates exemplary elements of the service, such as: 1. Subtree Storage: This stores the blocks and their corresponding Merkle subtrees.

[0149] 2. Message Broker: This is middleware that allows decoupling of different parts of a blockchain system, thereby facilitating asynchronous communication. Transaction IDs (TxIDs) are sent from the message broker to the block assembly controller.

[0150] 3. Block Assembly Controller: This component coordinates the process of creating new subtrees and new blocks. It receives transaction IDs from the message broker, performs necessary checks, and assembles the subtrees and blocks.

[0151] 4. TX State Database: This stores the state of transactions. The block assembly service checks this database before a transaction ID is included in a subtree or block template to ensure that the transaction was not previously included in another subtree / block. Right now (It has not yet appeared in the block).

[0152] 5. Subtrees: Completed subtrees are announced on the network so that other nodes can incorporate them into their blocks.

[0153] 6. Hasher / Miner: After preparing the block template (including all eligible transaction subtrees), it is sent to an entity called the miner, which is responsible for performing the computational work (hash processing) required to find valid blocks.

[0154] 7. Announcement: All completed new subtrees are announced on the IPv6 multicast block subtree network address.

[0155] Miner / Hasher. The miner service is responsible for mining blocks. This miner / hasher, on behalf of the block assembly service, solves the proof-of-work of hashing the current set of transactions and its subtree. After successfully mining a block, the miner receives a block reward (newly minted currency) and transaction fees for the transactions contained in the block. It should be understood that a temporary fork can occur in the blockchain if two miners solve a block approximately simultaneously. The network resolves this by selecting the chain with the largest accumulated work (usually the longest chain). Miners are configured to handle orphaned blocks and transactions. That is, if another chain becomes longer, transactions in orphaned blocks are tracked for mining in future blocks.

[0156] Subtree and Block Verifier. The verifier service aims to ensure the integrity and consistency of the blockchain network. The subtree and block verifier have two main responsibilities: subtree verification and block verification. Furthermore, the verifier service plays a crucial role in maintaining the set of unspent transaction outputs (UTXOs). Figure 11 The diagram illustrates exemplary elements of the service, such as: 1. Block Verification Controller: Acts as the coordinator of the block verification process. The block verification controller reacts to new subtrees or blocks found by the node or other nodes in the network. The service's task is to verify the individual subtrees of a block and later verify the blocks that aggregate the said subtrees.

[0157] 2. Subtree Storage: This stores Merkle subtrees, which are partial hashes of the complete block. These subtrees are crucial for quickly verifying new blocks found by competing miners. Once these subtrees are no longer needed (i.e., after a new block is found and the subtrees are no longer required), they are discarded.

[0158] 3. TX Storage Service: Maintains records of all created transactions, including those that have not yet been confirmed and added to blocks on the blockchain.

[0159] 4. UTXO service: Manages a list of all unspent transaction outputs, which represent potential inputs for new transactions.

[0160] 5. TX Status: Maintains tracking of the verification status of individual transactions.

[0161] 6. Multicast Subtree Announcement Network: This network broadcasts Merkel subtree announcements to the network. Multicast allows information to be efficiently distributed to nodes interested in receiving these announcements.

[0162] 7. TX Point-to-Point Request Network (IPv6): This is used to request the complete transaction data for a transaction that has not been "accredited".

[0163] When the verifier service verifies a subtree, it may receive the subtree frequently, sometimes as frequently as per second or higher. The verifier service checks the integrity of the subtree. This may include verifying that each transaction identifier listed in the subtree is valid, and that the corresponding transaction exists and is valid itself. If a transaction is missing, the node requests it from the mining node that sent the subtree. If the transaction is invalid, the subtree may be rejected. Part of the verification process may include ensuring that transactions within the subtree correctly reference and spend UTXOs.

[0164] By verifying subtrees in real time, the system can efficiently manage high-throughput transactions and reduce bottlenecks that would otherwise occur during block verification.

[0165] If the subtree contains transaction identifiers of transactions that have not been previously verified or "approved" by nodes, the verifier service retrieves and verifies the transactions. If the transaction is valid, it is also added to the block assembly process. If the transaction is invalid due to problems such as missing input, for example, the transaction and its subtree are rejected.

[0166] When performing block verification, the verifier service does not need to verify every individual transaction in a resolved block, as it has already completed the verification of all previously received subtrees. Instead, the verifier service can quickly verify blocks by checking the top of the Merkle tree formed by the Merkle roots of the subtrees. This significantly reduces the time and complexity of block verification after the announcement of resolved blocks.

[0167] Merkel subtree storage is a dedicated storage component within the verifier service used to store received subtrees. It retains the subtree until a new block is found and integrated into the blockchain; after that, the subtree is no longer needed and can be discarded. This storage ensures that the subtree is available for block verification and helps maintain the continuity of the verification process.

[0168] The verification process is continuous and iterative, designed to maintain the integrity of the blockchain and support high transaction throughput. Once the verifier service verifies a block, it propagates the block to the blockchain service to ensure that the blockchain remains up-to-date and consistent across all nodes.

[0169] Blockchain service. This service manages block updates and adds them to the blockchain maintained by the nodes. Blocks can be received from other nodes or mined by the nodes themselves. Blocks mined by nodes are broadcast to other nodes via the blockchain service.

[0170] The blockchain service manages the block header and subtree list for each block. All blocks (including orphaned blocks) are recorded in the blockchain database. Other services can request and store blocks from the service for purposes such as analyzing blockchain data or verifying chain integrity. The service also provides information about the current state of the blockchain, such as the best block header (the header of the most recently accepted block) and the current difficulty setting. Figure 12 The diagram illustrates exemplary elements of the service, such as: 1. Block (Header) Storage DB: This is the database that stores block headers. In a blockchain system, the block header is the part of a block that includes metadata such as hashes of previous blocks, timestamps, random numbers used for mining, and Merkle tree roots.

[0171] 2. Blockchain Server: It acts as the central node that interfaces with the block storage database. It is responsible for processing new blocks (found blocks) and identifying the best block headers for further operations (such as mining or appending to the chain).

[0172] 3. Block Assembly Service: This service retrieves transactions waiting to be included in a block and assembles these transactions into a new subtree and block. Once a new block is created (the found block), it sends the block to the blockchain server.

[0173] 4. Block Verification Service: This component is responsible for verifying new blocks. It checks whether the block conforms to the network's consensus rules. After the blockchain server processes a block (the found block), it interacts with this service to ensure the block is valid before it is finalized in the blockchain.

[0174] This system aims to maintain the integrity of the blockchain by ensuring that all blocks are correctly assembled, verified, and stored. It enables other services and participants in the network to interact with the blockchain, request data, and understand the current state of the network for further operations such as mining.

[0175] Asset Services. The Asset Services act as the interface ("front end" or "facade") for various data repositories. This service handles several key data elements, including transactions (TX), subtrees, blocks and block headers, UTXOs, and transaction metadata (TXMeta). The service uses both HTTP and gRPC as its communication protocols. It is designed to communicate with other nodes and external clients over the network. Various microservices write directly to the data repositories, but the Asset Services provide them as a public interface.

[0176] Coinbase Service. The Coinbase Service is designed to monitor new coinbase transactions in the blockchain, record new coinbase transactions, track the maturity of new coinbase transactions, and manage the spendability of rewards earned by miners. A "coinbase transaction" is the first transaction in the first subtree of a block and is created by assembling blocks. The unique aspect of this transaction is that it creates new coins out of thin air as a reward for miners' work in processing transactions and securing the network.

[0177] Coinbase Overlay Nodes (CONs) are specialized services used by miners to monitor all blocks being mined, ensuring accurate tracking of mined blocks and their unspent transaction outputs (UTXOs). This service actively listens for block header notifications and maintains a database of all blocks, regardless of their orphanage. Upon the announcement of a new block, the service requests it in a compact subtree format. This format includes Coinbase transactions, which facilitates the processing of any UTXOs linked to that miner.

[0178] When a miner intends to spend one of their currencies, they need to retrieve the corresponding UTXO from the CON service. They can then generate a valid transaction and transmit it through the CON service. This action marks the UTXO as spent.

[0179] Essentially, the CON service operates as a simple Simplified Payment Verification (SPV) overlay node, tailored to meet the needs of miners.

[0180] Bootstrapping service. This bootstrapping service helps new nodes find peers in the UBSV network. It allows nodes to register themselves and be notified of the existence of other nodes, thus acting as a discovery service.

[0181] The service manages a group of subscribers and broadcasts notifications to them and keeps them informed about the latest developments in the network.

[0182] The current version uses Google's RPC framework to set up the server and handle stream-based communication.

[0183] The P2P legacy service manages communication between legacy nodes and the nodes described above, effectively transitioning between old and new nodes. This allows legacy and new nodes to coexist, enabling a gradual rollout of the current architecture and processes.

[0184] As transaction volume increases, this traditional P2P network will be phased out, forcing an eventual migration towards more scalable and feature-rich systems. Figure 13 The diagram illustrates exemplary elements of the service, such as: 1. P2P network (IPv4): This refers to the original Bitcoin peer-to-peer network that uses the IPv4 Internet protocol.

[0185] 2. P2P Receiver Services: These are one or more services that receive transactions from a P2P network and send transactions to a P2P network.

[0186] 3. TX Lookup Service: This service is responsible for retrieving previously stored transaction information. It is used to enrich transactions with additional information before they are broadcast to the network.

[0187] 4. Multicast Group (Tx) Receive: This indicates a multicast setting that broadcasts a transaction to multiple nodes simultaneously. This is highly efficient for rapidly disseminating information to many nodes in the network.

[0188] UTXO storage. The UTXO storage service is responsible for tracking expendable UTXOs. These are UTXOs that can be used as input in new transactions. The UTXO storage service is primarily used by the validator service to retrieve UTXOs when validating transactions. The main purpose of this service is to provide fast lookup services on behalf of other microservices, such as the validator service.

[0189] Transaction metadata storage. This transaction metadata storage service is responsible for storing and retrieving transaction metadata. Many services, including the validator and block assembly service, use this transaction metadata storage service to retrieve transaction metadata when validating transactions. The block assembly service also uses this transaction metadata storage service to retrieve transaction metadata when assembling blocks.

[0190] Metadata within this service scope refers to additional fields of interest during transaction-related processing.

[0191]

[0192] Banned List Service. The blockchain network described here is an open, public system that anyone can use. While most participants act in good faith, the system needs to be protected from potential rogue or malicious actors. If a node violates the network consensus rules ("rogue" node), that node can be banned.

[0193] For example, any node attempting to introduce double-spending will be banned. Similarly, failing to announce a substantial percentage of the subtree before finding a block, or failing to broadcast the block after finding it, will violate the consensus rules and result in the node being banned. Once a node is banned, any transactions, subtrees, or blocks originating from that node will be rejected.

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

[0195] 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 computing system for processing blockchain transactions, comprising: One or more processing units; as well as The memory stores processor-executable instructions that, when executed by the one or more processing units, cause the one or more processing units to perform: A propagation service, wherein the propagation service is used to receive and propagate blockchain transactions through a blockchain network; A transaction verification service is provided, which is used to receive transactions from the propagation service and verify whether the received transactions conform to the blockchain protocol rules. A block assembly service is used to create block templates for the computing system to mine, including creating one or more subtrees of verified transactions; One or more miners, the one or more miners being used to search for proof-of-work with respect to the block template; A verifier service is provided for receiving and verifying incoming subtrees from other blockchain nodes on the blockchain network, and for verifying the validity of a new block based on previously verified subtrees after receiving a block solution. as well as A blockchain service for managing block headers and subtree lists within blocks.

2. The computing system according to claim 1, further comprising: A data storage device, wherein the instructions, when executed by the one or more processing units, also cause the one or more processing units to implement: an asset service, which serves as an interface between microservices and data elements stored in the data storage device.

3. The computing system of claim 1, wherein the instructions, when executed by the one or more processing units, further cause the one or more processing units to implement: a coinbase service for monitoring new coinbase transactions on the blockchain, recording the new coinbase transactions, and tracking the maturity of the new coinbase transactions.

4. The computing system according to claim 1, further comprising: A data storage device, wherein the instructions, when executed by the one or more processing units, also cause the one or more processing units to use the data storage device to implement UTXO storage, wherein the UTXO storage is used to track unspent transaction outputs and to respond to requests for unspent transaction output information from the transaction verification service and / or the verifier service.

5. The computing system according to claim 1, further comprising: A data storage device, wherein the instructions, when executed by the one or more processing units, also cause the one or more processing units to use the data storage device to implement transaction metadata storage, wherein the transaction metadata storage is used to store transaction data, and transaction metadata including at least a hash list of the parent transactions of the transaction.

6. The computing system of claim 1, wherein the instructions, when executed by the one or more processing units, further cause the one or more processing units to implement: a prohibition list service, wherein the prohibition list service is used to track node identifiers of nodes that are prohibited from operating on the blockchain network due to violations of network protocol rules.

7. A method for processing blockchain transactions by nodes, the method comprising: Sending and receiving blockchain transactions via multicast broadcast service through a blockchain network; The received blockchain transactions are verified based on the blockchain network protocol rules. Assemble one or more subtrees based on verified transactions; when assembling the one or more subtrees... Add the one or more subtrees to the block template for one or more mining units to mine, and Transmit the one or more subtrees to other nodes on the blockchain network; While mining is in progress, the external subtree is received from the other nodes on the blockchain network and the external subtree is verified and stored; as well as The block solution is received from one of the other nodes and verified using the verified outer subtree. Once verified, the solved block is appended to the blockchain.

Images