Commencal Token System

Abstract

This provides a commensurate token system that benefits from blockchain technology in terms of double-spending prevention, data integrity, and other security features, while remaining unaffected by the blockchain system itself. [Solution] The validation entity performs the steps of: obtaining a target token transaction having token inputs and token outputs; and validating the target token transaction, wherein the validation of the target token transaction includes verifying that each token input of the target token transaction has mint data and / or that each token input of the target token transaction refers to a token output of either a token mint transaction or a token transaction validated prior to the token mint transaction.

Description

[Technical Field]

[0001] This disclosure relates to a method for verifying token transactions. A token transaction is a blockchain transaction that has one or more token outputs. [Background technology]

[0002] A blockchain is a form of decentralized data structure, the replication of which is maintained on each of several nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and made widely available. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," refers to a preceding transaction in a sequence that may span one or more blocks and return to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and block publication can be achieved by publishing only the block header.

[0003] Transactions in a blockchain can be used for one or more purposes, including carrying digital assets (i.e., a number of digital tokens), ordering sets of entries in a virtualized ledger or register, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be used to add additional functionality to them. For example, blockchain protocols can enable the storage of additional user data or indices for data within transactions. There is no predetermined limit to the maximum amount of data that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, or audio or video data, within the blockchain.

[0004] Nodes on a blockchain network (often called "miners") perform the decentralized process of registering and verifying transactions, which is explained in more detail below. In short, during this process, nodes validate transactions, insert them into block templates, and attempt to identify a valid proof-of-work solution for that block template. Once a valid solution is found, the new block is propagated to other nodes on the network, allowing each node to record the new block on the blockchain. To ensure a transaction is recorded on the blockchain, a user (e.g., a blockchain client application) sends it to one of the network's nodes so that the transaction can be propagated. Nodes receiving the transaction compete to find a proof-of-work solution that incorporates the validated transaction into a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor incorporated into blocks. Assuming a transaction is validated and accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each node in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to 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., a certain number of tokens. Invalid transactions are detected and rejected by competing nodes, which act as agents of the network and are motivated to report and block fraud. By making information widely public, users can continuously audit the performance of nodes. By publishing only the block header, participants can ensure that the integrity of the blockchain continues.

[0006] In the “output-based” model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs (“unconsumed transaction outputs”). Outputs may further comprise a locking script that specifies the conditions for further redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, which we will call the first transaction and the second transaction (or “target” transaction). The first transaction comprises at least one output, which comprises a locking script that specifies the amount of digital asset and defines one or more conditions for unlocking the output. The second target transaction has at least one input, which includes a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the validity criteria applied at each node is that the unlocking script satisfies all one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier valid transaction. Any node that finds a target transaction to be invalid according to any of these conditions will not propagate the transaction (and in some cases will not propagate it as a valid transaction to register an invalid transaction), nor will it include the transaction in a new block to be recorded on the blockchain. [Overview of the project] [Problems that the invention aims to solve]

[0008] Issuing and consuming tokens using blockchain is not new in itself. Previously, tokens were issued using non-consumable transaction output. Implementing the system requires building a special token engine to interpret the data payload of the non-consumable output, and the data itself is meaningless to the blockchain system. Regarding storage, this presents a challenge for blockchain nodes as it requires separating the data from the consumable output.

[0009] Another approach is the UTXO-based approach, where tokens are tied to the transaction outpoint. With enhanced integration with the native blockchain, UTXO-based token systems share several advantageous features of the blockchain system, in addition to security, such as inscript smart contracts for tokens. Furthermore, token issuers can peg the value of their tokens to the value of native blockchain tokens.

[0010] A blockchain-based token system is desirable, as it would allow for rapid and effective token validation (e.g., without requiring a dedicated token engine to interpret token data) and prevent blockchain nodes from negatively impacting blockchain storage (e.g., without bloating the blockchain with token payload data). [Means for solving the problem]

[0011] According to one aspect disclosed herein, a computer implementation method for validating a token transaction is provided, wherein the token transaction is a blockchain transaction having one or more token outputs, each token output locking the respective amount of tokens, the validating entity has access to a token mint transaction and / or a token setup transaction, the token mint transaction having cryptographic mint data and minting the initial amount of tokens, and the token setup transaction having mint data authenticated by the token issuer, the method is performed by the validating entity, the method is a method of obtaining a target token transaction having one or more token inputs and one or more token outputs, and the method is a method of validating the target token transaction, the validation of the target token transaction being a method of verifying that each token input of the target token transaction has mint data and / or that each token input of the target token transaction refers to the respective token output of either a token mint transaction or a previously validated token transaction that can be traced back to the token mint transaction.

[0012] It can be seen that the blockchain can be considered as a directed acyclic graph (DAG) having a plurality of transaction chains. Each transaction chain starts with a coinbase transaction or a plurality of coinbase transactions. By creating a transaction having a plurality of inputs from different transaction chains, two or more transaction chains can be merged. There are many functions that can be developed using this interpretation of the blockchain. Embodiments of the present invention enable the development of a token system, which is referred to herein as a "commensal token system".

[0013] Commensalism is a symbiotic relationship between two species in which members of one species benefit while members of the other species are neither benefited nor harmed. The commensal token system of the present invention benefits from the blockchain system with respect to double-spending prevention, data integrity, and other security functions while the blockchain system is not affected by the token system. This is achieved by pegging the token value to the native blockchain token value.

[0014] A token transaction is a blockchain transaction composed of one or more "token outputs". A token output is a consumable output of a blockchain transaction that locks a respective amount of tokens. In other words, the value of the token is pegged to a native blockchain token (such as Bitcoin). Therefore, there is no additional token-specific work or token data for the blockchain nodes to process. Furthermore, due to the peg, the security of the blockchain system is naturally inherited by the token system. That is, the token system benefits from the blockchain system without imposing an extra burden on the Bitcoin system. Each token transaction is verified for validity by a blockchain node according to the blockchain protocol. Therefore, for a validity verification entity to verify a token transaction, the validity verification entity only needs to verify the token transaction being verified (referred to as the target token transaction here), including the token input that can trace back to the token mint transaction. That is, the token input refers to the token output of the token mint transaction or the token output of a previous token transaction that is part of the transaction train returning to the token mint transaction. This improves the efficiency of verifying token transactions.

[0015] In some embodiments, the verification entity can construct a data structure to further improve the efficiency of verifying token transactions. For example, the validity verification entity may construct a token block similar to a blockchain block. Each token block contains a set of valid token transactions (or the respective transaction identifiers of the set of valid token transactions). Instead of tracing back to the token generation transaction, the validity verification entity only needs to check that the token input refers to a valid token transaction stored in the token block.

[0016] According to one aspect disclosed herein, a computer implementation method for validating a token transaction is provided, wherein the token transaction is a blockchain transaction having one or more token outputs, each token output locking each respective amount of tokens, the method is performed by a validation entity, the method comprising the steps of: obtaining a target token transaction having one or more token inputs and one or more token outputs; and validating the target token transaction, the step of validating the target token transaction comprising the steps of: each token input of the target token transaction refers to each token output stored in the current token snapshot, the current token snapshot includes a set of token unconsumed transaction outputs (UTXOs), each token UTXO being the token output of each unconsumed token transaction.

[0017] To aid in understanding the embodiments of the disclosure and to show how such embodiments may be put into practice, the accompanying drawings are referenced simply as examples. [Brief explanation of the drawing]

[0018] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates some examples of transactions that can be recorded on a blockchain. [Figure 3A] This is a schematic block diagram of the client application. [Figure 3B] Figure 3A is a schematic mockup of an exemplary user interface that may be presented by the client application. [Figure 4A] This diagram schematically represents the blockchain ledger as a directed acyclic graph divided into two transaction chains. [Figure 4B] This diagram schematically represents a blockchain ledger as a blockchain, where each block contains a new coinbase transaction. [Figure 5] This diagram schematically illustrates an example of a directed acyclic graph for outpoint signatures. [Figure 6] This diagram schematically illustrates an example of a token network connecting to a blockchain network. [Figure 7] This figure schematically illustrates an exemplary system for implementing an embodiment of the present invention. [Modes for carrying out the invention]

[0019] Overview of the Exemplary System Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may consist of a packet-switched network 101, which is typically a wide-area internetnet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that can be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a quasi-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0020] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes 104 belong to different peers. Each blockchain node 104 is equipped with a processing unit comprising one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as high-value disk drives.

[0021] Blockchain 150 comprises a chain of data blocks 151, and each copy of Blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the distributed network or blockchain network 106. As mentioned above, maintaining a copy of Blockchain 150 does not necessarily mean completely memorizing Blockchain 150. Instead, Blockchain 150 can be pruned, as long as each blockchain node 150 remembers the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In a common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output designates an amount representing a certain quantity of digital assets as property, an example being user 103, the target of which the output is cryptographically locked (requiring the user's signature or other solution for unlocking, redemption, or consumption). Each input points to the output of the preceding transaction 152, thereby linking those transactions.

[0022] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define the sequential order of blocks 151. Each transaction 152 (other than coinbase transactions) has a pointer to a previous transaction to define the order of the transaction sequence (note that the sequence of transactions 152 is allowed to fork). The chain of block 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. One or more of the initial original transactions 152 in chain 150 pointed to the genesis block 153, rather than a preceding transaction.

[0023] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the "memory pool". This term is not intended to be limited to any particular blockchain, protocol, or model as used herein. It refers to an ordered set of transactions that node 104 has accepted as valid and that node 104 is not obligated to accept other transactions attempting to consume the same output.

[0024] In a given current transaction 152j, the input (or each input) contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output will be redeemed, or "consumed," in the current transaction 152j. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist when the current transaction 152i is created, or even when it is sent to the network 106, but for the current transaction to be valid, a preceding transaction 152i must exist and be validated. Thus, "preceding" as used herein refers to something that precedes in a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in temporal order, and therefore does not necessarily exclude the possibility that transactions 152i, 152j may be created or sent out of order (see the following discussion on orphan transactions). A preceding transaction 152i may similarly be called an ancestor transaction or predecessor transaction.

[0025] The input to the current transaction 152j also includes input authorization, for example, the signature of user 103a, to whom the output of the preceding transaction 152i is subject to locking. The output of the current transaction 152j may then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to a new user or entity 103b, as defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to give the remaining balance). In some cases, the transaction may also have multiple inputs to collect amounts from multiple outputs of one or more preceding transactions and redistribute one or more outputs of the current transaction.

[0026] According to output-based transaction protocols such as Bitcoin, when a party 103, such as an individual user or organization, wishes to execute a new transaction 152j (manually or through automated processing adopted by the party), the executing party sends the new transaction from its computer terminal 102 to the recipient. The executing party or recipient then sends this transaction to one or more blockchain nodes 104 on the network 106 (which are usually servers or data centers today, but in principle could be other user terminals). It is not ruled out that the party 103 executing the new transaction 152j can send the transaction directly to one or more of the blockchain nodes 104, and in some cases cannot send it to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applicable to each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check that 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 such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i assigned by the new transaction, which typically includes checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is concatenated. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.

[0027] Alternatively, it may be fixed simply by the blockchain node protocol alone, or it may be a combination of these. In any case, 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 test according to the same blockchain node protocol, forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0028] In an output-based model, the definition of whether a given output (e.g., UXTO) is allocated (e.g., consumed) is whether it has already been validly redeemed by the input of another preceding transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that the transaction attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, transaction 152j is not propagated on blockchain 150 (unless it is flagged as invalid and propagated for warning) or recorded. This protects against double consumption, such as when a trader attempts to allocate the output of the same transaction more than once. Account-based models, on the other hand, protect against double consumption by maintaining account balances. Again, because there is a defined order of transactions, account balances have a single defined state at any given time.

[0029] In addition to verifying transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly called mining, which is aided by "proof of work". At blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 recorded in blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transaction 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool 154 of unprocessed transactions and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash has a certain number of leading zeros. Note that this is just one specific type of proof of work puzzle, and other types are not excluded. A property of hash functions is that they have an output that is unpredictable with respect to their inputs. Therefore, this search can only be performed by brute force, which consumes a large amount of processing resources on each blockchain node 104 attempting to solve the puzzle.

[0030] The first blockchain node 104, attempting to solve the puzzle, announces this to the network 106 and provides the solution as proof that can be easily checked by other blockchain nodes 104 in the network (given a solution to a hash, it is simple to check that the output of the hash satisfies the condition). The first blockchain node 104 spreads the block to the threshold consensus of other nodes that accept the block and thus enforce the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in blockchain 150. The block pointer 155 is also assigned to a new block 151n that points to a previously created block 151n-1 in the chain. The considerable effort required to create the proof-of-work solution, for example in the form of a hash, demonstrates the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction (this is otherwise known as double consumption). Once created, block 151 cannot be altered because it is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. The block pointer 155 also imposes a sequential order on block 151. Since transaction 152 is recorded in an ordered block at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0031] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time may be competing to solve the puzzle based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when those blockchain nodes began searching for the solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There are also protocols to resolve any "forks" that may occur, which are situations in which two blockchain nodes 104 solve the puzzle to each other in a very short time, resulting in a contradictory landscape of the blockchain spreading between the nodes 104. In other words, the longer the tip of the fork grows, the final blockchain 150 will be. It should be noted that this should not affect the network's users or agents, as the same transactions will appear in both forks.

[0032] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, permissible amount of digital assets in a new special type of transaction that distributes an additional predetermined 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 agent or user). This special type of transaction is usually called a "coinbase transaction," but may also be called an "initiating transaction" or "generating transaction." It typically forms the first transaction of a new block 151n. Proof of work demonstrates the intent of the node constructing the new block, that it will follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created block 151n in which its transaction was published. This fee is usually called a "transaction fee" and will be discussed below.

[0033] Due to the resources involved in validating and publishing transactions, each of the blockchain nodes 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 networked set of user terminals or a group of user terminals.

[0034] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104, performing its respective role and handling transaction 152 in accordance with the blockchain node protocol. It will be understood that any activity relating to the blockchain node 104 as described herein may be carried out by software running on the processing unit of each computer device. The node software may be implemented in one or more applications at the application layer, or at lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0035] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in the verification or construction of transactions and blocks. Some of these users or agents 103 may act as senders or receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., by obtaining a copy of the blockchain from a blockchain node 104).

[0036] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system, including the blockchain network 106. However, these users are not blockchain nodes 104, because they do not perform the roles required of blockchain nodes. Instead, each party 103 can utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a is referred to herein as Alice, and the second party 103b is referred to as Bob, but this is not limiting, and it will be understood that any reference to Alice or Bob herein may be replaced by “the first party” and “the second party,” respectively.

[0037] Each computer device 102 of Party 103 comprises its own processing unit, which comprises one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory in the form of a non-temporary computer-readable medium, i.e., computer-readable storage. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, SSDs, flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each instance of at least one client application 105 configured to run on the processing unit. It will be understood that any activity arising out of this specification with respect to a given Party 103 may be performed using software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

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

[0039] The client application 105 has at least a “wallet” function. This has two main functions. One of these is to enable each party 103 to create, approve (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, this second function is to match the amounts defined in the outputs of various 152 transactions scattered throughout blockchain 150 belonging to the party in question.

[0040] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited. Instead, any client function described herein may be implemented in a set of two or more separate applications, e.g., by interfacing via an API, or by one being a plug-in to another. More generally, client functions may be implemented in the application layer, or in lower layers such as the operating system, or any combination thereof. The following description will be based on, but will not be limited to, client application 105.

[0041] Each computer device 102 instance of a client application or software 105 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact blockchain node 104 to query blockchain 150 for any transaction to which each party 103 is a recipient (or, in an embodiment, actually investigate the transactions of other parties in blockchain 150, since blockchain 150 is a public entity that brings credibility to some transactions by being a public entity). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and forward them to propagate transaction 152 throughout the blockchain network 106. The transaction protocol and node protocol correspond to each other, and a given transaction protocol, accompanied by a given node protocol, together implements a given transaction model. The same transaction protocol is used for all 152 transactions within blockchain 150. The same node protocol is used by all 104 nodes within network 106.

[0042] When a given party 103, for example Alice, wishes to send a new transaction 152j to be included in blockchain 150, she organizes the new transaction according to the relevant transaction protocol (using the wallet function of her client application 105). She then sends transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be a blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, the blockchain node 104 handles the new transaction 152j according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets any conditions for being "valid," an example of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in transaction 152. Alternatively, these conditions may simply be built-in functions of the node protocol, or may be defined by a combination of the script and the node protocol.

[0043] Under the conditions that a newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), any blockchain node 104 receiving transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained on that blockchain node 104. Furthermore, any blockchain node 104 receiving transaction 152j spreads the validated transaction 152 and subsequent transactions to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, assuming transaction 152j is valid, this means it will soon spread throughout the entire network 106.

[0044] When a blockchain node 104 is granted access to an ordered pool 154 of unprocessed transactions maintained at that node, it begins to compete in solving a proof-of-work puzzle for the latest version of each pool 154 containing the new transaction 152 (remember that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but the first to arrive defines the set of transactions included in the latest block 151. Ultimately, blockchain node 104 solves the puzzle for the portion of the ordered pool 154 containing Alice's transaction 152j). Once the proof-of-work is performed for the pool 154 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. The order of transactions is also immutably recorded, as each transaction 152 has a pointer to an earlier transaction.

[0045] Since different blockchain nodes 104 first receive different instances of a given transaction, they may have conflicting views on which instance is "valid" before it is published in the new block 151, but at the time of publication, all blockchain nodes 104 agree that the published instance is the only valid instance. If blockchain node 104 accepts an instance as valid and discovers that a second instance is recorded in blockchain 150, that blockchain node 104 accepts this and discards the first instance it accepted (i.e., the instance not published in block 151) (i.e., treats it as invalid).

[0046] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an “account-based” protocol as part of an account-based transaction model. In the account-based model, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute account balance. The current state of all accounts is stored and periodically updated by the network’s nodes, separate from the blockchain. In such a system, transactions are ordered using the account’s running transaction tally (also called “position”). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0047] UTXO-based model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following will be described with reference to output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0048] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unconsumed transaction output (UTXO), which can be used as the source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of a digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which the UTXO originates. The transaction data structure may also have a header 201, which may contain an indicator of the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 sent to node 104.

[0049] Suppose Alice 103a wants to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". Tx1 takes the amount of digital assets locked in Alice in output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction on blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has an unspent output 203 locked in Alice.

[0050] The preceding transaction Tx0 may already be validated and included in block 151 of blockchain 150 when Alice creates the new transaction Tx1, or at least when she sends it to network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in an ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created together and sent to network 106, or, if the node protocol allows buffering of “orphan” transactions, Tx0 may even be sent after Tx1. The terms “preceding” and “successor” as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may be equally replaced by “preceder” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") pointing to a preceding transaction (ancestor transaction or "parent") will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain period of time to wait for its parent, depending on the node protocol and / or node behavior.

[0051] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, which is hereby labeled UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a locking script defining the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction in order for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction containing the locking script). That is, the locking script defines an unlocking condition, which typically includes the condition that the unlocking script in the input of the subsequent transaction contains the cryptographic signature of the party to which the preceding transaction is locked.

[0052] A locking script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The locking script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it might include Bob's signature. The unlocking script appears in transaction input 202.

[0053] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is signed by Alice SIG P so that UXTO0 can be redeemed (more precisely, so that subsequent transactions attempting to redeem UTXO0 become valid). A Locking script that requires [Checksig P A ] It is equipped with. [Checksig P A ] This is the public key P from Alice's public-private key pair. A The input 202 of Tx1 includes a pointer to Tx1 (for example, by its transaction ID TxID0, where TxID0 is, in an embodiment, the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 within Tx0 in order to identify UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script containing Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). <Sig P A >The data (or "message") that needs to be signed to provide a valid signature by Alice may be defined by a locking script, by the node protocol, or a combination thereof.

[0054] When a new transaction Tx1 reaches blockchain node 104, the node applies the node protocol. This involves executing the locking script and the unlocking script together to verify whether the unlocking script satisfies the conditions defined in the locking script (these conditions may consist of one or more criteria). In embodiments, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] Here, "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function included in the locking script (in this example, a stack-based language). Equivalently, instead of concatenating scripts, the scripts may be executed one after another using a common stack. In any case, when executed together, the scripts will use Alice's public key P A contained in the unlocking script in the input of Tx1 to authenticate that the signature of Alice includes signing the expected part of the data. The expected part of the data itself ("message") also needs to be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus, there is no need for a separate element to specify the signed part of the data in plaintext, as it was already present).

[0055] Details of authentication by public-private cryptography are familiar to those skilled in the art. Basically, when Alice signs a message using her private key, given the plaintext Alice's public key and the message, another entity such as Node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, enabling any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing, such as to a particular data or part of a transaction, means in an embodiment, signing the hash of that data or part of the transaction.

[0056] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (in the example thus shown, Alice's signature is provided and authenticated in Tx1), blockchain node 104 considers Tx1 valid. This means that blockchain node 104 adds Tx1 to the ordered pool 154 of pending transactions. Blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in network 106, so that it is spread throughout network 106. Once Tx1 is validated and included in blockchain 150, it defines UTXO0 from Tx0 as to be consumed. Note that Tx1 can only be valid if it consumes an unconsumed transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been consumed (i.e., whether it has already formed a valid input into another valid transaction). This is one reason why it is important for blockchain 150 to impose a predetermined order on transaction 152. In practice, a given blockchain node 104 may maintain a separate database marking which UTXO 203 transaction 152 consumed within it, but ultimately, what defines whether a UTXO has been consumed is whether the UTXO has already formed a valid input into another valid transaction in blockchain 150.

[0057] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is also grounds for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0058] In a UTXO-based transaction model, it should be noted that a given UTXO must be consumed as a whole. It cannot "leave behind" a portion of the amount defined in the UTXO as being consumed while another portion is consumed. However, the amount from a UTXO can be divided among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be divided among multiple UTX0s in Tx1. Therefore, if Alice does not wish to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself the remaining balance of the second output of Tx1 or pay it to another party.

[0059] In practice, Alice would normally need to include a fee for the Bitcoin node 104 that successfully included her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and, therefore, even if technically valid, may not be propagated and not 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, the transaction fee does not require a unique separate output 203 (i.e., a separate UTXO). Instead, any difference between the total amount pointed to by input 202 and the total amount specified in output 203 of a given transaction 152 is automatically given to blockchain node 104 publishing the transaction. For example, suppose a pointer to UTXO0 is the sole input to Tx1, and Tx1 has a sole output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by node 104, which wins the proof-of-work competition to create the block containing UTXO1. However, as an alternative or addition, it is not necessarily ruled out that a transaction fee may be explicitly specified in its own UTXO among UTXO203 of transaction 152.

[0060] Alice and Bob's digital assets consist of UTXOs that are locked to them in any transaction 152 located somewhere on blockchain 150. Thus, typically, the assets of a given party 103 are distributed across the UTXOs of various transactions 152 throughout blockchain 150. There is no single number that defines the total balance of a given party 103, stored somewhere on blockchain 150. The role of the wallet function of the client application 150 is to match together the values ​​of all the various UTXOs that are locked to each party and have not yet been consumed in another subsequent transaction. This wallet function can do this by querying a copy of blockchain 150, such as one stored on one of the Bitcoin nodes 104.

[0061] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a locking script, produces an unconsumable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0062] Typically, the input to a transaction is the public key P AThis includes a corresponding digital signature. In embodiments, this is based on ECDSA using elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the output to sign depend on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature (and therefore fixed at the time of signing) to select which outputs are signed.

[0063] A locking script is sometimes called a "scriptPubKey," referring to the fact that it typically contains the public key of the party whose transaction is being locked. An unlocking script is sometimes called a "scriptSig," referring to the fact that it typically contains the corresponding signature. However, more generally, it is not required in all blockchain applications that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" are sometimes preferred.

[0064] Side channel As shown in Figure 1, each client application on Alice's and Bob's computer devices 102a and 120b may have additional communication capabilities. This additional capability allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables the exchange of data separately from the blockchain network. Such communication is sometimes called “off-chain” communication. For example, this could be used to exchange transaction 152 between Alice and Bob without transaction 152 being registered on the blockchain network 106 or moving toward chain 150 until one of Alice or Bob chooses to broadcast transaction 152 to network 106. Sharing a transaction in this way is sometimes called sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. As an alternative or addition, the side channel 107 may be used to exchange any other transaction-related data, such as keys, amounts or terms to be negotiated, or data content.

[0065] Side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, side channel 107 may be established via a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, side channel 107 as referred to elsewhere in this specification may have any one or more links via one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. If more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as side channel 107. Therefore, when it is said that Alice and Bob exchange some information or data etc. via side channel 107, this does not necessarily imply that all of this data must be transmitted on the exact same link, or even on the same type of network.

[0066] Client software Figure 3A shows an exemplary implementation of a client application 105 for implementing an embodiment of the scheme disclosed herein. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement transaction-related functions behind the client 105, such as organizing transactions 152, receiving and / or transmitting transactions and / or other data via side channels 107, and / or sending transactions to one or more nodes 104 so that they can be disseminated through the blockchain network 106, in accordance with the scheme discussed above and which will be discussed in more detail shortly. According to the embodiments disclosed herein, the transaction engine 401 of each client 105 comprises a function 403 configured to generate token transactions.

[0067] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computer device 102, including outputting information to each user 103 via the user output means of the device 102 and receiving input from each user 103 via the user input means of the device 102. For example, the user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output. The user input means may include, for example, one or more input arrays of touchscreens (same or different as those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or voice input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more mechanical buttons, switches, or joysticks.

[0068] Note: While various functions may be described in this specification as being integrated into the same client application 105, this is not necessarily an limitation. Instead, they may be implemented in a series of two or more separate applications, for example, one plugging into the other, or through interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module such as the transaction engine 401 may be divided among one or more applications. It is not excluded that some or all of the functions described may be implemented, for example, in the operating system layer. Wherever a single or given application 105 is referenced anywhere in this specification, this is merely an example, and it should be understood that, more generally, the functions described may be implemented in any form of software.

[0069] Figure 3B gives a mockup of an example of a user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by client 105b on Bob's device 102b, or by a client on any other party's device.

[0070] As an example, Figure 3B shows UI500 from Alice's perspective. UI500 may comprise one or more UI elements 501, 502, 502 which are rendered as separate UI elements via a user output means.

[0071] For example, a UI element may comprise one or more user-selectable elements 501, which may be various on-screen buttons or various options in a menu. User input means are provided to allow user 103 (in this case, Alice 103a) to select one of the options or otherwise manipulate it by clicking or touching a UI element on the screen or by speaking the name of the desired option (the term “manual” as used herein is intended solely to be in contrast to “automatic” and is not necessarily limited to the use of hands).

[0072] Alternatively or additionally, a UI element may include one or more data entry fields 502. These data entry fields may be rendered, for example, on a screen, via user output means, and data may be entered into the fields via user input means, such as a keyboard or touchscreen. Alternatively, data may be received orally, for example, based on speech recognition.

[0073] Alternatively or additionally, a UI element may have outputs of one or more information elements 503 for outputting information to the user. For example, these may be rendered on the screen or audibly.

[0074] It will be understood that the specific means of rendering various UI elements, selecting options, and entering data are not tangible. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that UI500 shown in Figure 3 is merely a schematic mockup, and in reality, it may have one or more further UI elements, which are not shown for the sake of brevity.

[0075] Blockchain as a Directed Acyclic Graph The Bitcoin ledger is widely referred to as a blockchain, where the data structure is thought to be a chain of blocks. However, if we consider transactions (instead of blocks) as the fundamental elements, we can see that the Bitcoin ledger can be viewed as a directed acyclic graph. This section will explain the formal definition of the Bitcoin directed acyclic graph (BDAG) and the special types of subgraphs of the BDAG.

[0076] Definition - Bitcoin is a directed acyclic graph. The Bitcoin directed acyclic graph (BDAG) is a DAG, where, 1. A node is a Bitcoin transaction, 2. A directed edge is established from one node to another if at least one output is allocated (consumed) from the first node to the second node.

[0077] A directed cycle of transactions implies circular references of transaction IDs within the input, which is impossible, so note that the graph is acyclic. Based on the definition, several properties below can be highlighted. 1. Each node can have at most n outward-facing edges, where n is the number of dissipable outputs in the transaction represented by this node. 2. Coinbase nodes do not have inward-facing edges. 3. A path starting from any node and traversing in the opposite direction of the edge should end at one or more Coinbase nodes.

[0078] An example of a BDAG is shown in Figure 4A. Figure 4B shows the BDAG when the blockchain structure is stamped onto it. Definition - Transaction Path The transaction path from node A to node B within the BDAG is from node N0, N1, ..., N t This is a set, and here, 1. N0 is node A, and N t This is node B, 2. For all i=0, 1, ..., t-1, N i From N i+1 A directed edge exists to 3. t is defined as the path length.

[0079] Definition - Transaction Chain A transaction chain is a subgraph of a connected BDAG. That is, for any pair of nodes within a subgraph, there exists a path between the two nodes, ignoring the direction of the edges. Note that all transaction chains within a BDAG form a partition of the BDAG.

[0080] As shown in Figure 4A, there are two transaction chains. The first one starts with two coinbase transactions and can be thought of as a merge of two transaction chains, while the second one starts with one coinbase transaction and has a simpler structure.

[0081] While the above example refers to the Bitcoin ledger (i.e., the Bitcoin blockchain), please note that the same definition applies to other UTXO-style blockchains.

[0082] Token validity verification Embodiments of the present invention relate to the verification of token transactions. Figure 7 shows an exemplary system 700 according to several embodiments. As illustrated, the system 700 comprises a validation entity 701, a token issuer 702, one or more token users 703a, 703b, and a blockchain network 106. Although only two token users 703a, 703b are shown in Figure 7, it should be noted that in general, the system 700 can include any number of token users 703. Each of the token issuer 702 and one or more token users 703 can take the form of Alice 103a or Bob 103b, as described with reference to Figures 1 to 3. That is, each of the token issuer 702 and token users 703 can be configured to perform some or all of the actions performed by Alice 103a and / or Bob 103b.

[0083] The validation entity 701 can take one of several forms, the details of which are described below. However, generally, the validation entity 701 can operate a computer device that has a processing unit comprising one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer device further comprises memory, i.e., computer-readable storage device in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units using one or more memory media, such as a magnetic medium such as a hard disk; an electronic medium such as an SSD, flash memory, or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer device may contain each instance of at least one client application configured to store software and run on the processing unit. It will be understood herein that any action resulting from the validation entity 701 can be performed using software running on the processing unit of the computer device. The computer device of the validation entity 701 may comprise at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment of validation entity 701 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal. The client application may first be provided to the computer equipment of validation entity 701 on a suitable computer-readable storage medium, for example, by downloading from a server or by providing it on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0084] Validation entity 701 is configured to validate token transactions. Validation entity 701 has access to mint transactions. Mint transactions mint, or issue, a certain amount of tokens. Mint transactions may be signed by token issuer 702 (i.e., mint transactions may include inputs with a signature linked to an issuing public key owned by token issuer 702) and may include outputs that lock an initial amount of tokens. In other examples, mint transactions may include different forms of encrypted data, such as mint public keys, messages signed by the token issuer, and messages encrypted by the token issuer. Generally, mint transactions include encrypted "mint" data. Encrypted data is data used as part of an encryption scheme. Mint data is public information known to be related to minting tokens. Mint transactions may include multiple outputs that lock each initial amount of tokens. Mint transactions are recorded on blockchain 150. The validation entity 701 can access the mint transaction from blockchain 150, or the validation entity 701 can store the mint transaction locally. In some examples, the mint data may be a knowledge proof, such as a hash puzzle or an R-puzzle. Solving the knowledge proof, i.e., unlocking it, requires knowledge of the data.

[0085] The validation entity 701 obtains a "target token transaction," that is, a token transaction to be validated by the validation entity 701. The target token transaction may be submitted to the validation entity 701 by a token user 703. Alternatively, the target token transaction may be submitted to the validation entity by a different validation entity 701. That is, the system 700 may have multiple validation entities, such as the token server 601 and token client in Figure 6. The target transaction may be obtained by other means.

[0086] The first condition for a target token transaction to be a valid token transaction is that it must be part of a transaction chain that returns to a mint transaction. That is, the target transaction must contain inputs that reference (i.e., consume) the output of a mint transaction, or inputs that reference a previous token transaction that is part of a transaction chain that returns to a mint transaction. In the latter case, the previous transaction must contain inputs that reference the output of a mint transaction, or inputs that reference a previous token transaction that is part of a transaction chain that returns to a mint transaction. In other words, tracing the reference output of a previous token transaction must eventually lead to the token transaction. If the target token transaction is a mint transaction, the first condition is met: whether the target token transaction contains mint data, such as a mint public key.

[0087] The validation entity 701 may be configured to verify the first condition by performing the aforementioned tracking of the referenced output. Alternatively, the validation entity 701 may perform a more efficient process for verifying the first condition, as described below.

[0088] A target token transaction may contain multiple token inputs. In these examples, the validation entity 701 is configured to verify that each token input is part of a transaction chain that returns to a mint transaction. Note that there may be multiple mint transactions issued by the token issuer 702. In that case, a particular token input may trace back to multiple mint transactions. Similarly, the various token inputs of a target token transaction may trace back to various mint transactions.

[0089] In some cases, additional conditions must be met for a target token transaction to be considered valid. These additional conditions are described below.

[0090] Once validated, that is, once the first condition or any other condition has been verified, the validation entity 701 can submit the target token transaction to the blockchain network 106. That is, token user 703a can submit the target token transaction to the validation entity for validation, and provided that the target token transaction is valid, the validation entity 701 will transfer the target token transaction to the blockchain network 106.

[0091] The validation entity 701 can obtain confirmation that the target token transaction is a valid blockchain transaction. For example, the validation entity 701 can obtain confirmation that the target token transaction is published in block 151 on blockchain 150. The validation entity 701 can obtain a Merkle proof from blockchain node 104 to verify that the target token transaction is published in block 151. Once it is confirmed that the target token transaction is a valid blockchain transaction, the validation entity 701 can record the target token transaction in the list of valid token transactions. Note that the validation entity 701 can record the target token transaction in the list of valid token transactions before obtaining confirmation that the target token transaction is a valid blockchain transaction. The validation entity 701 can also choose to remove the target token transaction from the list if it is not a valid blockchain transaction.

[0092] In some examples, after validating a target token transaction, the validating entity 701 may sign the target token transaction before submitting it to the blockchain network 106. For example, the target token transaction may be incomplete, and the validating entity 701 may complete the target token transaction by including an input that includes the validating entity's signature, i.e., a signature linked to a public key owned by the validating entity 701. This signature indicates that the target token transaction has been validated. In some examples, the input may be a fee payment input, i.e., an input that pays the transaction fee collected by the blockchain node 104 that publishes the transaction in block 151. Such an input is an example of a “non-token input”.

[0093] A target tokenized transaction may contain one or more non-tokenized inputs before, for example, validation entity 701 adds non-tokenized inputs as needed. Validation entity 701 does not need to check that the non-tokenized inputs satisfy a first condition: that they are part of a transaction chain returning to the mint transaction. However, validation entity 701 needs to distinguish between tokenized and non-tokenized inputs in order to determine which inputs must satisfy the first condition. In its simplest example, inputs can be distinguished based on their index within the target transaction. For example, a first input could be defined as a tokenized input and a second input as a non-tokenized input, or vice versa.

[0094] In another example, a non-tokenized input can be identified by identifying the public key contained within the non-tokenized input. That is, the validation entity 701 can determine whether the input contains one of a predefined set of public keys, such as one of the fee-paying public keys. If the input contains one of the predefined set of public keys, the validation entity 701 considers the input to be a non-tokenized input.

[0095] Alternatively, the validation entity 701 can identify non-tokenized inputs as being signed with specific signature flags. For example, a non-tokenized input could be defined as being signed with the SIGHASH_SINGLE signature flag.

[0096] If a target token transaction includes one or more non-token inputs, the target token transaction must satisfy a second condition to be considered a valid token transaction. The validation entity 701 is configured to verify that the total amount of tokens locked by the target token transaction's token outputs does not exceed the total amount of tokens locked by the outputs referenced by the target token transaction's token inputs. In other words, a target token transaction cannot distribute more tokens across its token outputs than the tokens consumed by the target token transaction's token inputs.

[0097] A target token transaction may include one or more non-token outputs. For example, a non-token output may be used to return the difference between the fee payment input and the transaction fee to the entity paying the transaction fee. Non-token outputs may be used for other purposes. If a target token transaction includes one or more non-token outputs, the target token transaction must satisfy a third condition in order to be considered a valid token transaction. The validation entity 701 is configured to verify that the total amount of tokens locked by the token outputs of the target token transaction does not exceed the total amount of tokens locked by the outputs referenced by the token input of the target token transaction.

[0098] To verify the third condition, validation entity 701 must distinguish between tokenized and non-tokenized outputs. In the simplest case, the output index is sufficient to distinguish between tokenized and non-tokenized outputs; for example, non-tokenized outputs are placed at the beginning of the transaction. Alternatively, non-tokenized outputs may be identified as having the same index as their corresponding non-tokenized inputs. Or, if a non-tokenized input is defined as being signed with a specific signature flag, the non-tokenized output will be output as being signed with more signatures than the tokenized output.

[0099] As another optional condition, the validation entity 401 can verify that the target token transaction is not attempting to duplicate the output of the blockchain transaction. That is, the validation entity can verify that the output referenced by the inputs of the target token transaction (both non-token output and token output) is an unconsumed transaction output (UTXO). This check is performed by the blockchain node 104 when submitted to the blockchain network 106, but the validation entity 701 may also want to perform this check, for example, to prevent invalid blockchain transactions from being sent to the blockchain network 106.

[0100] In some cases, the validation entity 701 may also validate a mint transaction. For example, the validation entity 701 may verify that a mint transaction contains a signature linked to a mint public key associated with the token issuer 702.

[0101] The validation entity 701 may receive a request from the requesting entity (e.g., token user 703b) to verify whether a token transaction (e.g., target token transaction) is a valid token transaction. The validation entity 701 verifies that the token transaction is a valid token transaction, and if the token transaction is valid, it may send a response to the requesting entity informing it that it is a valid token transaction. This request and response process is described in detail below.

[0102] Token Server In some embodiments, the validation entity 701 may include a "token server" 601. That is, the validation entity 701 may take the form of (or include) a server configured to perform actions of the validation entity 701. The token server 601 may store a record (e.g., a database) of valid token transactions, i.e., previously validated token transactions. These token transactions may have been validated by the token server 601 or a different entity. In some examples, the token server 601 may store a record of all valid transactions.

[0103] In these embodiments, the token server 601 can verify that the token input of the target token transaction refers to the output of a previously validated token transaction by determining whether the referenced transaction exists in a record of valid token transactions, for example, by performing a lookup of the transaction ID of the referenced transaction.

[0104] In some cases, token server 601 can construct a “token block.” A token block shares some similarities with blockchain block 151. A token block consists of a token block header and a list of valid token transactions (or at least the identifier of each valid token transaction). A target token transaction, once validated, can be included in the current (i.e., latest) token block. The token block header of a particular token block consists of a Merkle root calculated based on the set of token transactions within that token block. As described below, the block header may include additional fields.

[0105] Similar to blockchain block 151, the block header of a token block may contain a pointer to a previous token block in the sequence (i.e., chain) of token blocks. The pointer may take the form of a hash (e.g., a double hash) of the block header of the previous token block. The pointer traces back to the first (i.e., the first token block created) token block.

[0106] The token server 601 may construct one token block for each blockchain block 151. That is, a token block may be constructed based on a transaction (specifically, a token transaction) within a particular token block. A token block may be constructed before the corresponding blockchain block 151 is published (for example, if the token transaction contained in blockchain block 151 is sent to the network 106 by the token server 601), or it may be constructed after blockchain block 151 is published (for example, the token server 601 may scan blockchain block 151 for the token transaction).

[0107] Optionally, part or all of a token block may contain one or more signatures. Signatures can be included in the block header of each token block. For example, token server 601 may include a signature to verify that the token block was actually constructed by token server 601. A signed message may contain part or all of a token block. In some examples, token issuer 703 and / or one or more additional entities (e.g., auditors, government agencies, or other public entities) may include their own signatures.

[0108] In addition to maintaining a record of token blocks, the token server 601 can send one or more token blocks (for example, periodically or on request) to a requesting entity, such as a token user 703b or a token issuer 702. The requesting entity may be a token issuer 702, a token user 703, or a different validation entity (for example, a token write client as described below). The token server 601 may send the entire token block or only the token block header.

[0109] In some cases, the token server 601 may send a token block header (and optionally the complete token block) as part of a simplified token verification method to verify the existence and integrity of a valid token transaction. Verifying the integrity of a transaction ensures that the data within the transaction has not been tampered with. For example, a requesting entity (e.g., token user 702b) may want to verify that a token transaction is valid. The token transaction in question may be a token transaction referenced by the input of the current token transaction, such as a target token transaction. To verify that the referenced token transaction is valid, the token server 601 may provide the requesting entity with a Merkle proof to verify the existence of the referenced token transaction in the token block. Merkle proofs are known to those skilled in the art. A Merkle proof sent to the requesting entity includes a sequence of hashes. The referenced token transaction is hashed and concatenated with the first hash in the sequence, and the result is hashed. The next result is concatenated with the next hash in the sequence (if any), and the result is hashed. Each hash in the sequence has a left or right indicator. Whether it is left or right can be determined by a single index, which may be provided as the first number in the Merkle proof. This process is repeated until each hash in the sequence has been used. If the final hash is equal to the Merkle root contained in the token block header of the token block, the referenced token transaction is included in the token block. Since a token block contains only valid token transactions, the referenced token transaction must be valid, and the data of the referenced transaction must not have been modified.

[0110] TokenLite client In some embodiments, the validation entity 701 may comprise a "token write client" 602a. That is, the validation entity 701 may take the form of (or include) a client application configured to perform actions of the validation entity 701. The token server 601 may store a record (e.g., a database) of valid token transactions, i.e., previously validated token transactions, which may have been validated by the token write client 602a or a different entity.

[0111] The token write client 602a maintains a record of the token block header, along with a record of the transaction identifier of a valid token transaction. The token write client 602a also stores a record of the token value and index of each token output of a valid token transaction. For example, the record may have multiple data items of the form TxID||index||value. The token block header may be obtained from the token server 601, for example, at request and / or when each token block is constructed by the token server 601. In some examples, the token block header may be that of a token block constructed by the token write client 602a.

[0112] The token-write client 602a can validate a received token transaction using the record. For example, the token-write client 602a may verify that the token output referenced by the token input of the target transaction is stored in the record. For example, the token-write client 602a performs a lookup of the referenced TxID||index||value in the record. If the target token transaction is valid (i.e., satisfies one or more validity conditions), the token-write client 602a may add the token output of the target transaction to the record. In some examples, the token-write client 602a may remove a referenced token output from the record.

[0113] The token light client 602a can receive token transactions from the token user 703, validate the token transactions, and then send them to the blockchain network 106 and / or the token server 601.

[0114] Similar to the token server 601, the token write client 602a can also construct token blocks. These token blocks can take the same form as those constructed by the token server 601. For example, the token write client 602a can receive token transactions from token user 703 and construct a token block based on those token transactions. The token write client 602a can also include token transactions in its token blocks that were sent to different instances of the token write client 602a and are then forwarded to the token write client 602a, or retrieved from blockchain 150 (after being sent to blockchain network 106 by other token write clients). Similar to the token server 601, the token write client 602a can construct a token block for each newly published block in blockchain 150.

[0115] In some examples, the token write client 602a can send the constructed token block to the token server 601 for verification, for example. The token server 601 can add its signature to the token block header of such a token block and return them to the token write client 602a. In some examples, the token write client 602a can receive the token block from the token server 601. For example, the token write client 602a may temporarily lose its connection to the blockchain network 106 and therefore be unable to construct a token block during that time.

[0116] Similar to the token server 601, in some cases, the token write client 602a may send a token block header (and optionally the complete token block) as part of a simplified token verification method to verify the existence of a valid token transaction. A similar scenario applies, and the token write client 602a sends the block header and a Merkle proof of a valid token transaction contained in the corresponding token block to the requesting entity (e.g., token user 703). If the Merkle proof leads to the Merkle root contained in the block header, it can be confirmed that the token transaction is contained in the token block and therefore is a valid token transaction.

[0117] Token UTXO client As shown in Figure 6, the system may comprise one or more token UTXO clients 602b. These client applications are also configured to validate token transactions. That is, the validation entity 701 can take the form of a token UTXO client application 602b. A token UTXO client maintains a record of one token snapshot. A token snapshot consists of a set of token UTXOs. Each token UTXO is an unconsumed token output of a token transaction. Each token snapshot captures a set of token UTXOs at different points in time.

[0118] Some or all of the token snapshot is constructed by the token UTXO client 602b. Some may be received from different instances of the token UTXO client 602b or from the token server 601. In some cases, the token server 601 may construct a token snapshot and send it to the token UTXO client 602b, for example, in response to the token UTXO client 602b losing its connection to the blockchain network 106. The token snapshot may be constructed by tracking the token UTXOs on the blockchain, that is, by tracking which token outputs have not yet been effectively consumed by subsequent blockchain transactions (token or non-token).

[0119] The token UTXO client 602b is configured to validate token transactions, for example, by verifying that each token input in a target token transaction refers to the respective unspent token output of a previous token transaction (which may be a mint transaction). The token UTXO client 602b does this by verifying that the referenced token output exists in the latest token snapshot.

[0120] Once the token transaction is validated, the token UTXO client 602b can send the token transaction to the blockchain network 106 and / or the token server 601. The token UTXO client 602b can then construct a new token snapshot that includes the token output of the target transaction but does not include the referenced token output.

[0121] The token UTXO client 602b can also perform a simplified token verification method to verify the existence of a valid token output. Each token UTXO snapshot may contain a Merkle root calculated based on the token UTXOs stored in the snapshot. To verify the existence of a token output, the token UTXO client 602b can send a Merkle path to the requesting entity (e.g., token user 703) linking a given token UTXO to the Merkle root of the current token snapshot. Note that the Merkle root may be constructed for a Merkle tree whose leaves take one of the following forms: 1. TxID||index 2. TxID||index||value 3. TxID||index||locking script||value

[0122] Examples of token systems Next, we will describe an example of a token system. It will be understood that some features of the token framework are optional, and other variations can be selected based on a specific implementation of the embodiment of the present invention. According to one example of the framework, a dust limit is imposed on blockchain transactions, the token value is pegged to a native blockchain token, and token-specific data is not pushed to the locking script.

[0123] Setup Transaction Token issuer 702 can issue a setup transaction. Suppose token issuer 702 wants to issue a token representing a country's currency. Note that this is only one of many possible use cases for the token system. Token issuer 702 may choose to publish the on-chain token specification in a non-consumable (e.g., OP_FALSE OP_RETURN) payload within the setup transaction. Alternatively, the specification may be published on a website or other appropriate public record, provided that the record is trusted by users and the general public. This allows token issuer 702 to make the token chain public and prove the rules of the token. In case of dispute, token users 703, including token issuer 702, can resolve the dispute by referring to the specification. The specification can be thought of as an article of a public company or the terms and conditions of the token system. This specification may refer to the ERC-20 standard, a tokenized standard, or a customized standard that the token issuer deems appropriate. If the token chain is private, the specification may be published as a hash value to ensure integrity.

[0124] An example of a setup transaction is shown below. [Table 1]

[0125] Token issuer 702 signs a setup transaction containing the issuing public key. The setup transaction can reference any unspent transaction output (UTXO) owned by token issuer 702. Similarly, the output of the setup transaction can be locked to any public key, such as another public key owned by token issuer 702.

[0126] Please note that the above description is for illustrative purposes only. Token issuer 702 may include all details regarding the token system in this setup transaction. In general, this specification aims to demonstrate that the token system is technically robust and legally compliant.

[0127] Three public keys are explicitly shown in the illustrative explanation. PK mint It is used for minting tokens, PK melt It is used to melt coins, PK Audit This is used to prove compliance with the token system. All three public keys are certified by the signature from token issuer 702 in the input of the setup transaction. Other types of mint data may be included herein instead of, or along with, the public keys.

[0128] Token issuer 702 can add more public keys to provide a more sophisticated access control structure. For example, there may be a public key for a transaction validator 701, in which case the token transaction may be validated and signed by the validator 701 before being sent to the blockchain network 106. Token issuer 702 can also add a master certificate public key as the token system evolves to create a hierarchical structure of authenticated public keys. There may also be a public key dedicated to the payment of transaction fees, as described below.

[0129] In the illustrative framework, the token is pegged to a native blockchain token. For simplicity, the Bitcoin example is used here, but it should be understood that this does not limit all embodiments. In that case, there is a fixed conversion rate between Bitcoin and the token. Note that this is not an exchange rate; it is simply a convenient representation of the token value. For example, 1000 satoshis (sats) may represent 1 GBP. Therefore, in the case of a token transaction with an output of 10,000 sats, the token value of the token output is 10 GBP. Note that, as of the time of writing, the dust limit is 546 satoshis, so it may be more convenient to define the peg ratio as 1:dust limit, where 1 is the smallest indivisible unit of the token.

[0130] In this example, note that this specification may include a reserve issuance ratio. This implies that token issuer 702 cannot issue tokens beyond its financial capacity. Token issuer 702 may also need to obtain a valid license from the central bank to be permitted to issue GBP tokens. The jurisdiction field may specify where the token system is regulated and where relevant laws can be applied. These compliances may be audited by third parties, and the audit results may be placed on the chain to ensure transparency. In general, all traditional approaches to financial entities or token issuers can be integrated into the sample token framework. Enforcement of rules, regulations, or laws may be carried out in a combination of on-chain and off-chain manners.

[0131] Mint Transaction To mint the token, token issuer 702 constructs a mint transaction. An example is shown below. [Table 2]

[0132] This exemplary transaction was prepared by token issuer 702 and uses a public key (PK). mint It has one input, which includes a signature that can be verified by TxID. A mint transaction may contain different forms of encrypted data, such as a signed or encrypted message. setup According to the specifications, this transaction generates x1GBP tokens, which are then allocated to the owners of PK1.

[0133] The transaction fee is the value of the mint out points - 1000 x 1, and it is assumed here that the token issuer 702 has prepared the mint out points to have the exact amount that covers both the transaction fee and the value of the first output. Details of the transaction fee are shown below.

[0134] In the following cases, a blockchain transaction is defined as a token mint transaction: 1. All inputs within a transaction include one or more signatures that can be verified by one or more Mint public keys, and 2. If it is a valid blockchain transaction.

[0135] The meaning of this definition is that Bitcoin is colored by its mint public key. The color is then preserved throughout the entire transaction chain, starting with the mint transaction or multiple mint transactions. To check if a blockchain transaction is a token transaction, one can trace it back through the transaction chain to the mint transaction. This can be difficult in large systems. However, this process can be optimized using token blocks and token UTXO snapshots.

[0136] Token issuer 702 can construct multiple such transactions to meet the demand for the tokens. In this case, the number of tokens that can be minted is limited by the number of Bitcoins held by token issuer 702 and the rules of the specifications.

[0137] Consumption Transactions Once the mint transaction is published on blockchain 150, token user 703, who possesses the public key that locks the token output of the mint transaction, can use the token.

[0138] TxID mint The next transaction to consume, TxID spend Let's consider this. [Table 3]

[0139] This transaction is a public key PK. mint It does not have an explicit reference to the transaction (TxID). To identify this transaction as a token transaction, the transaction referenced in the input (TxID) must be used. mint ) needs to be traced back to the TxID. mint By obtaining it locally or from the blockchain network 106, it is confirmed that it is a valid token mint transaction, and therefore the TxID spent It is possible to verify that it is a token transaction. To validate a token transaction, the following three main checks are necessary: 1. The output point referenced in the input is unused. 2. The output value is less than or equal to the input value, and 3. The signature is valid (or the script has been successfully validated).

[0140] It should be noted that all these checks are performed simultaneously with the normal validation of blockchain transactions. Therefore, all checks can be delegated to blockchain node 104. In summary, token transaction validation consists of only two steps: 1. A step to check that the input can be traced back to the token mint transaction, and 2. The step of obtaining confirmation from the blockchain node that the token is blockchain valid.

[0141] Transaction fee There are three ways to process transaction fees.

[0142] The first approach is a token-only approach. To maintain the simplicity of token transaction validation and ensure that token transactions consist only of token inputs and outputs, transaction fees can be paid by burning a small portion of the tokens. TxID spend As shown, the owner of PK1 transfers x2 GBP tokens to the owner of PK2. The transaction fee of 1000(x1-x2) effectively burns (x1-x2) tokens. For token users, this can be thought of as a token transfer fee. For token issuers, this means that the number of tokens in the system decreases in proportion to usage. This is a desirable feature for certain types of tokens whose value naturally decreases. On the other hand, if this is a problem for token issuers, they can mint new tokens from time to time to offset the transaction fee.

[0143] If transaction fees are accepted by blockchain node 104, the issue of paying fees for token transactions is resolved. However, token issuer 702 must pay blockchain node 104 in fiat currency off-chain through a business contract. In this case, token issuer 702 is effectively paying transaction fees to token user 703.

[0144] The second approach is the public key approach. Another possibility is to use a public key to indicate the purpose of the input in a token transaction. In this case, the token issuer 702 can introduce a fee-paying public key or a set thereof into the specifications of the setup transaction. The fee-paying public key is owned by the token issuer and can be distributed to the token wallet. The idea is to add another input to every token consumption transaction to cover the exact amount of the transaction fee. An example is shown below. [Table 4]

[0145] It should be noted that fee outpoints are not token inputs, meaning they cannot be traced back to the token mint transaction. However, since the public key in the unlocking script can be identified as a valid public key authenticated by the token issuer (702), fee outpoints do not invalidate the token transaction. For greater flexibility, token issuers may allow users to register fee-paying public keys. A list of authenticated fee-paying public keys can be published in an updated version of the specification.

[0146] The advantage of this approach is that all outputs of a token transaction are token outputs. This simplifies verification. As a token issuer 702, it is also possible to use the fee payment input as an authorization for the token transfer. The token user 703 first constructs a partial transaction. The token issuer 702 or wallet software authorizes the transaction by adding a fee input to complete the transaction. This additional authorization process prevents the user from accidentally burning tokens.

[0147] Regarding the token-only approach, this approach has two drawbacks. 1. Several additional checks need to be implemented. a. Check that the public key for fee payment is included in the specifications. b. Check that the output value is equal to (or less than) the token input value. This is to prevent token users from artificially inflating the token output value by "borrowing" some Bitcoin from the fee payment input. In a token-only approach, the input consists only of token inputs, so the check is the same as checking that the total output value is not greater than the total input value, which can be delegated to blockchain node 104. 2. The fee outpoint must contain the exact amount to pay the transaction fee. Non-token output is not permitted, and therefore changes cannot be collected. For this reason, token users or token issuers must prepare the fee outpoint before transferring tokens.

[0148] The overhead caused by 1b is negligible from a computational standpoint, and the benefit it provides is crucial in terms of preventing accidental token burning. The second drawback can also be mitigated by the token issuer 702 having its own fee outpoint pool or server and providing appropriate fee outpoints for each token transaction request.

[0149] The third approach is the SIGHASH_SINGLE approach. The goal here is to address the lack of flexibility in paying transaction fees while simultaneously resolving the confusion between token and non-token outputs. It turns out that paying transaction fees and collecting some changes requires only one input and one output from a token transaction. SIGHASH_SINGLE is used to link this input-output pair and make the output distinguishable from other outputs.

[0150] SIGHASH_SINGLE is a flag added to a signature to indicate that the signed message excludes all outputs except those with the same index as the input containing the signature. Note that other blockchains may use different signature flags for the same purpose, and SIGHASH_SINGLE is used only as an example for illustrative purposes. This means that if the index of the signed output is the same, you can add or modify an output to a transaction without invalidating the signature. Since SIGHASH_NONE is not built in, you cannot add or modify an input.

[0151] To construct a consumption transaction, the user sends token input to wallet software or an entity that provides funds for the transaction fee (which can be the user themselves) (e.g., TxI Dmint ||0). An incomplete transaction is constructed as follows: [Table 5] Signature Sig fee teeth,

number

[0152] Upon receiving or constructing an incomplete transaction, user 703 completes the transaction by adding any number of token outputs and signs the updated transaction. [Table 6] In this transaction, signature Sig1 signs all inputs and outputs. The following equation applies to the values: Transaction fee = Value of fee outpoint - z x1 = x2 + x3

[0153] There are several ways to distinguish between fee payment input and token input. 1. Check if the input is a token output. This becomes very difficult if there is no list of token output points for reference. Starting from the fee output point can take a long time before reaching a negative conclusion. 2. Define that the first input is always the fee payment input. This can be implemented as part of the wallet software. 3. Define the input as a fee payment input using SIGHASH_SINGLE. This means that SIGHASH_SINGLE cannot be used with other token inputs.

[0154] Assuming that fee payment inputs can be distinguished from tokenized inputs, identifying non-tokenized outputs simply requires checking whether the output index is the same as the index of the fee payment input.

[0155] However, assuming that SIGHASH_SINGLE is used to flag fee payment inputs (Method 3), non-tokenized outputs can be directly identified without identifying fee payment inputs. For each output, the number of signatures that signed that output can be counted. Non-tokenized outputs will have the most signatures because they always have at least one additional signature from fee payment inputs.

[0156] This characteristic of token output induces another type of directed acyclic graph at the outpoint level.

[0157] Outpoint-signed directed acyclic graph (OS DAG) An outpointed signed directed acyclic graph is a DAG, 1. A node is an outpoint for blockchain transactions. 2. A directed edge is established from one node to another if the second node is part of a message signed with the signature required to allocate (consume) the first node.

[0158] Roughly speaking, there are outpoints as nodes and signatures as edges. All edges within an OS DAG are established within a blockchain transaction. Figure 5 is an example.

number

[0159] The advantage of this SIGHASH_SINGLE approach is that it provides flexibility in paying transaction fees.

[0160] Security of non-token input Non-token inputs are introduced into token transactions to pay transaction fees. These non-token inputs may be used inadvertently or maliciously to inflate the value of token outputs. Checks need to be implemented to ensure that these token transactions are deemed invalid.

[0161] The sum of the input values ​​in the token transaction satoshi is used in VI. token + VI non-token Therefore, the sum of the output values ​​is VO token + VO non-token Transaction fees are V feeThis means that VO token + VO non-token + V fee = VI token + VI non-token To obtain.

[0162] VO token = VI token It is expected that this will be the case. However, token users will be VO non-token or V fee From this, we can obtain some satoshi. That is,

number

[0163] As a blockchain transaction, it remains valid. As a token transaction, it is considered invalid.

[0164] An example of a token transaction pair is shown below. [Table 7]

[0165] The first transaction is token-valid in the sense that the token output has the same value as the token input, and the difference between the fee input and the fee output indicates a transaction fee of 2000 satoshi. The second transaction is token-invalid in the sense that the token output is greater than the token input. However, the difference between the sum of the inputs and the sum of the outputs indicates a transaction fee of 1000 satoshi. This transaction is blockchain-valid and accepted by blockchain nodes. Therefore, once this transaction is made public, the value of the token represented by 1000 satoshi is lost.

[0166] In both token-only and public-key approaches, the fee payment input must be added after the token input and output are complete. Therefore, the fee payment entity (token issuer or wallet software) can enforce a check before signing the token transaction. There is no incentive for users to intentionally inflate token output in this way, as this would result in burning tokens. On the other hand, accidental mistakes are immutably recorded on the blockchain. Token users can demonstrate to the token issuer that the accident was real, and the issuer can choose to mint new tokens to refund the user. However, avoiding accidental mistakes remains crucial.

[0167] Validity of token transactions We have explained how to mint and spend tokens. This allows us to provide a comprehensive definition of the validity of token transactions. Definition - Token Outpoint Outpoint TxID||Index is a token out point in the following cases: 1. Transaction TxID is a token mint transaction, or 2. There is a transaction path from the token mint transaction to the transaction TxID, and 3. The index does not support indexes with fee payment inputs or non-tokenized inputs.

[0168] Definition - Validity of token transactions A token transaction is valid if it is a valid token mint transaction, or 1. Blockchain is enabled, 2. At least one input refers to a token out point, and 3. A token is valid if the sum of the token outputs is less than or equal to the sum of the token inputs.

[0169] Given the above definition, each blockchain transaction needs to be traced back to either a mint transaction or a coinbase transaction. If it ultimately becomes a mint transaction, then it is a token transaction. If it becomes a coinbase transaction without being identified as a mint transaction, then it is not a token transaction. As blockchain systems expand, identifying and validating token transactions can become difficult. One way to improve this is to maintain a record of known valid token transactions. Validators can stop at known valid token transactions instead of tracing back to mint transactions. Furthermore, if validators have access to a trusted set of unused token outpoints, tracing can be replaced with a search operation that checks membership in the set.

[0170] To address the scalability of the token system, we propose several options for optimizing token transaction validation. We begin with a description of token server 601, which holds a record of all token transactions. Next, we propose a block structure on the record, which leads to a description of the light client of the token system. Finally, to further improve efficiency, we propose a token client that utilizes token UTXO snapshots.

[0171] Definition - Token Server Token server 601 must meet the following requirements: 1. The ability to verify token transactions. 2. It must be connected to a blockchain network.

[0172] The first requirement is that the token server 601 must store some information about the token system in order to recognize that the input to a blockchain transaction is a token input. There are many ways to achieve this.

[0173] The simplest method is to store the token setting transaction along with the token specification and all subsequent token transactions. The token server 601 first checks whether the transaction is a token mint transaction by checking the public key and corresponding signature in the input. If it is not a token mint transaction, the token server 601 checks whether the input of the blockchain transaction is from a past token transaction. If the check passes, the token server 601 can begin validating the token transaction as defined below.

[0174] It should be noted that double consumption checks are provided by blockchain nodes and are optional for token clients. If token server 601 delegates some checks regarding transaction validity to blockchain nodes, the nodes must wait for validity confirmation from the network. Thus, the definition has a second requirement.

[0175] It is possible to replace signature validation with format checking, which could make the implementation more efficient. The idea is to ensure that when a public key is given as input, a corresponding signature also exists, and delegate signature validation to the blockchain node. This can be achieved when the locking script is a standard P2PKH and the unlocking script in the input contains only one public key and one signature. Other common scripts may be allowed, and if there is a problem with the script, it can be returned to signature validation.

[0176] Token block Regarding the structure of the data stored in the token server 601, we can mimic a blockchain system and introduce the concept of token blocks. This will allow us to introduce the concept of the token write client 602a in the next section. An example definition of a token block is shown below.

[0177] Definition - Token Block A token block consists of a block header and a list of valid token transactions. The block header may include some or all of the following fields: 1. The version indicates which token system this block belongs to. 2. The previous block header hash is twice the SHA256 value of the previous token block header, and is empty in the case of a genesis token block. 3. The Merkle root is calculated based on the token transactions within that token block. 4. The height of a Bitcoin block indicates which Bitcoin block all token transactions originated from. 5. The transaction count indicates the total number of token transactions included in a token block.

[0178] A list of digital signatures can be added to each token block to indicate that each signer has verified the validity of the block, where a token block is valid if: 1. All transactions are token-valid. 2. All transactions are retrieved from the blockchain block specified by the blockchain block height. 3. Contains the hash value of the previous token block header. 4. The Merkle root of the token transaction is calculated correctly. 5. The number of transactions is correct.

[0179] As soon as a new blockchain block is published, a token block is built on token server 601. For example, suppose there is a newly published blockchain block. [Table 8]

[0180] 1. Use the version field to indicate which token system the block belongs to. 2. The previous block hash is the hash value of the previous block header. Note that proof of work is not required here. 3. The Merkle root is calculated from the transactions included in the token block. Another method is to use the Bitcoin Merkle root. 4. A new field called Bitcoin block height is used to indicate which Bitcoin block every token transaction belongs to. 5. The transaction count indicates the number of transactions present within a token block. 6. The complete list of transactions is listed in the Transactions field. 7. The signature field allows entities to add a digital signature to sign the block header. This could be a signature from the token issuer or delegate. The signature should only be added after the token block has been successfully verified.

[0181] Note that the token block header includes the first five fields within the token block.

[0182] Each blockchain block can have at most one token block, and it is impossible for a token block to contain a set of transactions originating from two different blockchain blocks.

[0183] There is no proof-of-work required for the token system. However, since all information about the token system can be obtained from the blockchain ledger, the security of the token system is inherited from the blockchain system. Signatures added to a block provide a shortcut to verifying the token block. However, even if a user does not trust the signer, they can verify the block independently. All the information necessary to verify a token block is publicly available and accessible on the blockchain ledger. On the other hand, given that token blocks can be publicly verified, signers are incentivized not to sign invalid token blocks.

[0184] A common concern is orphaned blocks, which occur occasionally but rarely. Indeed, token systems, like blockchain systems, are subject to reorganization. When a valid block becomes orphaned due to the existence of another longer chain with more proof-of-work, all transactions within that block that are not included in the other longer chain revert to private status. The same applies to token status. However, as is often the case, honest users and honest blockchain nodes are unaffected by reorganization, as transactions on competing chains are identical. For token issuers, keeping their token system accurately up-to-date requires ensuring that the token server 601 maintaining the token system is connected to the majority of the network.

[0185] To optimize token verification, we can attempt to minimize storage for token transactions and improve lookup efficiency. We will introduce the TokenLite client 602a, which is equivalent to the Bitcoin Lite client.

[0186] TokenLite client TokenWrite client 602a is a token client that maintains the following: 1. Token setup transaction, 2. Token block header, 3. Token transactions within transaction IDs, and 4. The token value of each stored transaction ID and the index of each output.

[0187] The last two items can be concatenated into a string of the format TxID||index||value. The token light client 602a is capable of validating token transactions and constructing token blocks.

[0188] When a token transaction is sent to the token write client 602a, the token write client 602a performs the following steps: 1. Check whether a token transaction is a mint transaction by comparing the public key in the input with the public key in the token specification. 2. Otherwise, for each input, check whether the referenced outpoint matches a token outpoint stored locally. 3. If a match is found, identify all token outputs and check that the sum of the token inputs is equal to (or greater than) the sum of the token outputs.

[0189] If the check is successful, the tokenlight client 602a stores the transaction for each of its token outputs as TxID||index||value||flag. The flag indicates whether the corresponding transaction output (TxID||index) has been consumed or not. The token transaction is then sent to the blockchain network for further checks.

[0190] Once TokenWrite client 602a obtains confirmation from a blockchain node that the transaction is valid and accepted, TokenWrite client 602a can include the transaction in the next token block. When a new blockchain block is published, TokenWrite client 602a can construct the corresponding token block. Note that complete transaction data is not required to construct a token block; only the transaction ID is sufficient. Furthermore, there is no work of proof required to construct a block. It would be wise to double-check that everything has been calculated and recorded correctly. The token block can be completed by obtaining a signature from the token issuer.

[0191] Token UTXO client The token system can be further improved by observing that there is no need to store used token transactions or token outpoints. In this section, we maintain the token server 601 as described above and introduce the concept of the token UTXO client 602b. The token UTXO client 602b is responsible for tracking all unused token outpoints, which improves the efficiency of token transaction identification and verification. In case of any problems, the token system can always fall back to the token server 601.

[0192] Definition - Token UTXO snapshot A token UTXO snapshot consists of a snapshot header and a set of outpoints. The snapshot header contains five fields. 1. The version indicates which token chain this snapshot belongs to. 2. The hash of the previous snapshot header is twice the SHA256 value of the previous token snapshot header. 3. The Merkle root is calculated using all outpoints within the token UTXO set. 4. The Bitcoin block height indicates how many Bitcoin blocks a token UTXO set can derive from. 5. The outpoint count indicates the total number of outpoints in the token UTXO set.

[0193] The token server 601 and / or token UTXO client 602b can build and maintain a list of token UTXO snapshots. An example is shown below. [Table 9]

[0194] The advantage of this solution is that, as a token client, it can choose to store only the most recent token UTXO snapshot, since the token client contains all the information necessary to validate token transactions and build the next token UTXO snapshot. When receiving a blockchain transaction, the token client only needs to search for the outpoints in the input and check if they are included in the latest token UTXO set. If they are present, they are valid token inputs. Note that the token client does not check for double consumption conditions; this check is performed by the blockchain node. This is one of the main advantages of UTXO-based token systems.

[0195] The drawback is that if the latest token UTXO snapshot is corrupted, the token UTXO client 602b will retrieve the last available token UTXO snapshot, and subsequent blockchain blocks or token blocks will need to derive the latest snapshot block by block. In this case, the token server becomes a reliable source of the necessary information.

[0196] To further mitigate the potential risk of losing the latest UTXO snapshot, token issuers can choose to have multiple token servers and a small number of token UTXO clients to maintain the token system. If one token UTXO client 602b fails, the other UTXO clients can provide information for rapid recovery while maintaining the uninterrupted operation of the token system.

[0197] Figure 6 shows an example of a token network. In summary, a token network consists of some or all of the following: Token server 601 stores all token-related transactions and structures them into blocks. • One or more token write clients 602a that store all token outpoints and their corresponding values, and • One or more token UTXO clients 602b that store all unused token outpoints and their corresponding values.

[0198] All of these can verify token transactions and create checkpoints (e.g., token blocks or token UTXO snapshots) to improve efficiency.

[0199] Bitcoin enabled and token disabled Like many other token systems, shared token systems can trigger transactions that invalidate tokens even if the blockchain is valid, resulting in token loss. This problem can be mitigated by introducing a verification step before adding a transaction fee to complete token transactions. This verification step can be performed by a token wallet, token client, or token server.

[0200] Tokens and non-tokens One of the major challenges in designing a token system is avoiding mixing tokens with non-tokens or other tokens. The challenge becomes even more difficult when token transactions need to include transaction fees. To address this, the public-key approach and the sighash-single approach are proposed. In both cases, mechanisms are introduced to prevent the Bitcoin representing the token from being mixed with the Bitcoin covering the transaction fee.

[0201] These mechanisms were implemented to fix the token value to the Bitcoin value and prevent the mixing of tokens and non-tokens, meaning that the total amount of Bitcoin in the token system exists at the time of token issuance. These tokens, or colored Bitcoins, can be transferred, split, and even burned, but they will never be mixed with colorless Bitcoins.

[0202] This leads to another use case: "Green Bitcoin." To promote environmentally friendly mining, Bitcoin mined using renewable energy could be colored and called Green Bitcoin, using an authenticated public key or miner ID. By employing a public key approach or a sighash-single approach, Green Bitcoin would not be mixed with non-Green Bitcoin. As users tend to acquire Green Bitcoin, more Bitcoin nodes would be encouraged to switch to renewable energy and mint Green Coins.

[0203] substitutability Due to the nature of pegging, shared token systems are primarily used for alternative tokens. However, simply abstracting the idea of ​​using public keys to color Bitcoin allows for the creation of non-fungible tokens. For the time being, we consider non-fungible tokens to be outside the scope of this white paper.

[0204] Scalability By design, the shared token system relies on the blockchain system and reuses work from the blockchain system as much as possible. The shared token system does not need to check for duplicate consumption. Therefore, it does not require memory to hold unpublished token transactions (mempool) or temporarily set token UTXOs. As the blockchain system expands, the shared token system will expand accordingly.

[0205] conclusion Other variations or uses of the techniques disclosed may become apparent to those skilled in the art upon being given the disclosures herein. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

[0206] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any above references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may 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 described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0207] In a preferred embodiment of the present 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, distributing, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (it is not to be noted that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0208] In an undesirable embodiment of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some of, but not all, of the functions of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, in those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store those blocks 151 and / or to distribute them to other nodes.

[0209] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with respect to blockchain nodes 104.

[0210] It will be apparent that the embodiments described above are for illustrative purposes only. More generally, methods, apparatus, and programs can be provided that conform to any one or more of the following:

[0211] Statement 1. A computer implementation method for validating a token transaction, wherein the token transaction is a blockchain transaction having one or more token outputs, each token output locking the respective amount of tokens, the validating entity has access to a token mint transaction and / or a token setup transaction, the token mint transaction having encrypted mint data and minting the initial amount of tokens, and the token setup transaction having mint data authenticated by the token issuer, the method being performed by the validating entity and comprising the steps of obtaining a target token transaction having one or more token inputs and one or more token outputs, and validating the target token transaction, the validation of the target token transaction comprising verifying that each token input of the target token transaction has mint data, and / or that each token input of the target token transaction refers to the respective token output of either a token mint transaction or a previously validated token transaction that can be traced back to the token mint transaction.

[0212] In other words, a target token transaction is a valid mint transaction if its input includes a mint public key (and the signature corresponding to that mint public key).

[0213] Encrypted data is data used as part of the encryption method, that is, in the encryption settings.

[0214] Statement 2. The method of Statement 1, comprising the step of sending a target token transaction to a blockchain network on condition that the target token transaction is a valid token transaction.

[0215] Statement 3. The method of Statement 2, comprising the step of obtaining, from a blockchain network, confirmation that the target token transaction is a valid blockchain transaction.

[0216] When obtaining the above confirmation, the validity confirmation entity may store the target token transaction in a list of valid token transactions.

[0217] Statement 4. The method according to claim 3, wherein the step of obtaining confirmation includes the step of verifying that the target token transaction is recorded on the blockchain.

[0218] Statement 5. The mint data is - a mint public key related to the token issuer, - a proof of knowledge created by the token issuer, - a symmetrically signed message signed by the token issuer, and - one of the messages encrypted by the token issuer, any of the methods of Statements 1 to 4.

[0219] Statement 6. For confirmation that the target token transaction is a valid token transaction, the method of any of Statements 1 to 5, comprising the step of receiving a request from a first requesting entity and, on condition that the target token transaction is a valid token transaction, sending to the first requesting entity confirmation that the target token transaction is a valid token transaction.

[0220] Statement 7. Any method according to Statement 2 or subordinate to Statement 2, including the step of signing the target token transaction with a signature linked to the validation public key associated with the validation entity, under the condition that the target token transaction is a valid token transaction and before sending the target token transaction to the blockchain network.

[0221] Statement 8. Any method of Statements 1-7, including the step of identifying one or more non-token inputs, where the target token transaction includes one or more non-token inputs that reference the output of each previous blockchain transaction, and the method has one or more of a predetermined set of public keys, such as a fee payment public key, as inputs.

[0222] Statement 9. The method of Statement 8, where the step of validating the target token transaction includes verifying that the total amount of tokens locked by one or more token outputs of the target token transaction is less than or equal to the amount locked by one or more respective token outputs referenced by one or more token inputs of the target token transaction.

[0223] Statement 10. Any method of Statements 1-9, where the target token transaction includes one or more non-token inputs and one or more non-token outputs, and the step of validating the target token transaction includes verifying that the total amount of tokens locked by one or more token outputs of the target token transaction is less than or equal to the amount locked by the token outputs referenced by one or more token inputs.

[0224] Statement 11. Any method of statements 8-10, which includes the step of identifying a non-tokenized input as an input signed with a signature having a predetermined signature flag, such as the sighash_single signature flag.

[0225] Statement 12. The method of Statement 11, including the step of identifying a non-tokenized output as an output signed with more signatures.

[0226] Statement 13. Any method of Statements 1-12, wherein the step of validating the target token transaction includes a step of verifying that the token output of a previously validated token transaction is an unconsumed transaction output.

[0227] Statement 14. Any method of Statements 1-12, wherein the step of validating the target token transaction does not include a step of verifying that the token output of a previously validated token transaction is an unconsumed transaction output.

[0228] In other words, it involves delegating to the blockchain network the task of verifying that the token output of a previously validated token transaction is an unconsumed transaction output.

[0229] Statement 15. Any method of Statements 1-14, which includes a step of validating a token mint transaction, wherein the step of validating a token mint transaction includes a step of verifying that the token mint transaction has a mint public key associated with the token issuer.

[0230] Statement 16. A validation entity stores a record of previously validated token transactions, and any method of Statements 1-15 includes the step of verifying that each token input of a target token transaction references each token output of a previously validated token transaction, and the step of determining whether the referenced token output exists in the record of previously validated token transactions.

[0231] Statement 17. Any method of Statements 1-16, including the step of constructing the current token block, the current token block including a token block header, a set of valid token transactions including the target token transaction, and / or its identifier, the token block header including a Merkle root calculated based on the set of valid token transactions of the token block.

[0232] Statement 18. The validation entity maintains a sequence of previously constructed token blocks, and the block header of the current token block has a hash of the block headers of the respective token blocks immediately preceding the current token block in the sequence, in the manner of Statement 17.

[0233] Each token block to be constructed, except for the first one, has a hash of the previous block header, i.e., the hash of the block header of the token block preceding the token block in the sequence.

[0234] A record of previously validated token transactions may serve as the record of a token block.

[0235] Statement 19. The method of Statement 17 or Statement 18, which includes the step of constructing the respective token block for each newly published block of the blockchain.

[0236] The token block headers of each token block have the block heights of the respective blocks of each blockchain.

[0237] Statement 20. The block header of the current token block includes the respective signatures generated by some or all of the token issuer, the validation entity, the auditing entity, and / or the government entity, in any of the ways of Statements 17 to 19.

[0238] Statement 21. Any of the ways of Statements 17 to 20, including the step of sending one or more token blocks and / or their respective block headers to a second requesting entity.

[0239] Statement 22. The step of sending a confirmation to the first requesting entity includes the step of sending a Merkle path that links the target token transaction to the Merkle root stored in the block header of the current token block, in any of the ways of Statement 6 and Statement 21.

[0240] Statement 23. The validation entity includes a token server, in any of the ways of Statements 1 to 22.

[0241] Statement 24. The first and / or second requesting entity includes a token client application, and / or the step of obtaining the target token transaction includes the step of receiving the target token transaction from the token client application, in the way of Statement 23.

[0242] Statement 25. A validation entity stores, in any way of Statements 1 to 13, a set of token block headers for each token block, where each token block header contains the respective Merkle root calculated based on each set of valid transactions stored in each token block; a set of token transaction identifiers; and a set of token outputs, where each token output contains the respective output index of one of the set of token transaction identifiers and the respective token amount.

[0243] Statement 26. The method of Statement 25, wherein the step of verifying that each token input of a target token transaction references the respective token output of a previously validated token transaction includes the step of determining whether the referenced token output exists in the set of token outputs.

[0244] Statement 27. The method of Statement 26, which includes the step of storing the transaction identifier of a target token transaction and one or more token outputs of a target transaction in a set of token transaction identifiers and a set of token outputs, respectively, provided that the target token transaction is a valid token transaction.

[0245] Statement 28. The method of Statement 27, which includes the step of constructing a current token block, the current token block including a token block header and a set of transaction identifiers for a valid token transaction including a target token transaction, the token block header including a Merkle root calculated based on the set of transaction identifiers.

[0246] Statement 29. The method of Statement 28, including the step of constructing each token block for each newly published block of the blockchain.

[0247] Statement 30. The validation entity is one of the methods described in Statements 25-29, including the token client application.

[0248] Statement 31. The step of obtaining a target token transaction is the method of Statement 30, which includes the step of receiving a target token transaction from a user as input.

[0249] Statement 32. The method of Statement 30 or Statement 31, which includes the step of sending a target token transaction to a token server, provided that the target token transaction is a valid token transaction.

[0250] Statement 33. Any method of statements 30-32, for example, including the step of receiving one or more token blocks and / or their respective block headers from a token server in response to a temporary loss of connection to the blockchain.

[0251] Statement 34. Any method of statements 30-33, which includes the step of sending one or more token blocks to a token server for verification.

[0252] Statement 35. Encrypted mint data includes publicly available information known to be related to the minting of tokens, in any way described in Statements 1 through 34.

[0253] Statement 36. A computer implementation method for validating a token transaction, wherein the token transaction is a blockchain transaction having one or more token outputs, each token output locking each respective amount of tokens; the method is performed by a validation entity and includes the steps of: obtaining a target token transaction having one or more token inputs and one or more token outputs; and validating the target token transaction, wherein the step of validating the target token transaction includes the steps of: each token input of the target token transaction refers to each token output stored in the current token snapshot, the current token snapshot includes a set of token unconsumed transaction outputs (UTXOs), each token UTXO being the token output of each unconsumed token transaction.

[0254] Statement 37. The method of Statement 36, including the step of constructing the current token snapshot.

[0255] Statement 38. The method of Statement 37, wherein the step of constructing the current token snapshot includes the step of tracking the token UTXO on the blockchain.

[0256] Statement 39. The method of Statement 36, including the step of receiving the current token snapshot from the token server.

[0257] Statement 40. Any method of statements 36-39, comprising the step of constructing an updated token snapshot, provided that the target transaction is a valid token transaction, wherein the updated token snapshot includes one or more token outputs of the target transaction, but does not include one or more token outputs referenced by one or more token inputs of the target token transaction.

[0258] Statement 41. Any method of Statements 36-40, which includes the step of sending the target token transaction to the token server and / or blockchain network, provided that the target transaction is a valid token transaction.

[0259] Statement 42. Any method of statements 36-41, comprising the steps of receiving a request from a first requesting entity for confirmation that the target token transaction is a valid token transaction, and, provided that the target token transaction is a valid token transaction, sending a confirmation to the first requesting entity that the target token transaction is a valid token transaction.

[0260] Statement 43. The method of Statement 42, wherein the current snapshot contains a Merkle route calculated based on each set of token UTXOs, and the step of sending confirmation to the first requesting entity includes the step of sending a Merkle path that links the token output referenced to the Merkle route stored in the block header of the current snapshot.

[0261] Statement 44. A computer device comprising a memory having one or more memory units and a processing unit having one or more processing units, wherein the memory stores code arranged for execution on the processing unit, and the code is configured to execute any of the methods of Statements 1 to 35 when executed on the processing unit.

[0262] Statement 45. A computer program, embodied on computer-readable storage, configured to execute any of the methods described in statements 1 through 35 when executed on one or more processors.

[0263] Statement 46. A computer device comprising a memory having one or more memory units and a processing unit having one or more processing units, wherein the memory stores code arranged for execution on the processing unit, and the code, when executed on the processing unit, is configured to perform any of the methods of statements 36 to 43.

[0264] Statement 47. A computer program, embodied on computer-readable storage, configured to execute any of the methods described in statements 36-43 when executed on one or more processors.

[0265] A method may be provided that includes some or all actions of a token server, a token UTXO client, and a token write client, according to another aspect of the disclosure herein.

[0266] According to another aspect of the disclosure herein, a system may be provided that includes some or all actions of a token server, a token UTXO client, and a token write client. [Explanation of Symbols]

[0267] 100 Systems 101 Blockchain networks, packet-switched networks, internet 102 Computer equipment, computer terminals 102a Alice's computer equipment, Alice's devices 102b Bob's computer equipment, Bob's devices 103 Users, entities, parties, and agents 103a User, Entity, First Party, Alice 103b User, Entity, Second Party, Bob 104 Blockchain Nodes, 1st Node, Bitcoin Node, Transactions 105 Client applications, software, clients 105a Client Application 105b Client 106 Blockchain Networks, Bitcoin Networks 150 Blockchain, Client Applications, Bitcoin Blockchain Block 151, blockchain 151n-1 block 151n block 152 transactions 152i Transaction 152j transaction 153 Genesis Block (Gb) 154 Ordered sets, transactions, and pools 155 Block pointers 160 Blockchain Networks

Claims

1. A computer implementation method for validating a token transaction, wherein the token transaction is a blockchain transaction having one or more token outputs, each token output locking the respective amount of tokens, the validating entity has access to a token mint transaction and / or a token setup transaction, the token mint transaction has encrypted mint data and mints the initial amount of tokens, the token setup transaction has mint data authenticated by the token issuer, and the method is performed by the validating entity. A step of obtaining a target token transaction having one or more token inputs and one or more token outputs, A step of validating the target token transaction, wherein the validation of the target token transaction is Verify that each token input of the target token transaction has the mint data, and / or A method comprising verifying that each token input of the target token transaction refers to the respective token output of either the token mint transaction or a previously validated token transaction that can be traced back to the token mint transaction.

2. The method according to claim 1, further comprising the step of sending the target token transaction to a blockchain network, provided that the target token transaction is a valid token transaction.

3. The method according to claim 2, further comprising the step of obtaining confirmation from the blockchain network that the target token transaction is a valid blockchain transaction.

4. The method according to claim 3, wherein the step of obtaining the confirmation includes the step of verifying that the target token transaction is recorded on the blockchain.

5. The aforementioned mint data is, - Mint public key associated with the aforementioned token issuer, - Knowledge proof created by the aforementioned token issuer, - A symmetrically signed message signed by the token issuer, and - Message encrypted by the aforementioned token issuer The method according to any one of claims 1 to 4.

6. The steps include receiving a request from a first requesting entity in order to confirm that the target token transaction is a valid token transaction, The steps include: under the condition that the target token transaction is a valid token transaction, sending confirmation that the target token transaction is a valid token transaction to the first requesting entity; The method according to any one of claims 1 to 5, including the method described in any one of claims 1 to 5.

7. The method according to claim 2 or any one dependent on claim 2, provided that the target token transaction is a valid token transaction and before transmitting the target token transaction to the blockchain network, the method comprising signing the target token transaction with a signature linked to a validating public key associated with the validating entity.

8. The method according to any one of claims 1 to 7, wherein the target token transaction includes one or more non-token inputs that refer to the respective outputs of previous blockchain transactions, and the method includes the step of identifying the one or more non-token inputs as inputs having one or more of a predetermined set of public keys.

9. The method according to claim 8, wherein the step of validating the target token transaction includes verifying that the total amount of tokens locked by the one or more token outputs of the target token transaction is less than or equal to the amount locked by each of the one or more token outputs referenced by the one or more token inputs of the target token transaction.

10. The method according to any one of claims 1 to 9, wherein the target token transaction comprises one or more non-token inputs and one or more non-token outputs, and the step of validating the target token transaction includes verifying that the total amount of tokens locked by the one or more token outputs of the target token transaction is less than or equal to the amount locked by the token outputs referenced by the one or more token inputs.

11. The method according to any one of claims 8 to 10, further comprising the step of identifying the non-tokenized input as an input signed with a signature having a predetermined signature flag.

12. The method according to claim 11, further comprising the step of identifying a non-tokenized output as an output signed with more signatures.

13. The method according to any one of claims 1 to 12, wherein the step of validating the target token transaction includes the step of verifying that the token output of the previously validated token transaction is an unused transaction output.

14. The method according to any one of claims 1 to 12, wherein the step of validating the target token transaction does not include the step of verifying that the token output of the previously validated token transaction is an unconsumed transaction output.

15. The method according to any one of claims 1 to 14, comprising the step of validating the token mint transaction, wherein the step of validating the token mint transaction includes the step of verifying that the token mint transaction comprises a mint public key associated with the token issuer.

16. The method according to any one of claims 1 to 15, wherein the validation entity stores a record of previously validated token transactions, and the step of verifying that each token input of the target token transaction references each token output of a previously validated token transaction includes the step of determining whether the referenced token output exists in the record of a previously validated token transaction.

17. The method according to any one of claims 1 to 16, comprising the step of constructing a current token block, the current token block comprising a token block header, a set of valid token transactions including the target token transaction, and / or an identifier thereof, the token block header comprising a Merkle root calculated based on the set of valid token transactions of the token block.

18. The method according to claim 17, wherein the validation entity maintains a sequence of previously constructed token blocks, and the block header of the current token block has a hash of the block headers of the respective token blocks in the sequence immediately preceding the current token block.

19. The method according to claim 17 or claim 18, comprising the step of constructing a token block for each of the newly published blocks of the blockchain.

20. The method according to any one of claims 17 to 19, wherein the block header of the current token block includes the respective signatures generated by some or all of the token issuer, the validation entity, the auditing entity, and / or the government entities.

21. The method according to any one of claims 17 to 20, comprising the step of sending one or more token blocks and / or their respective block headers to a second requesting entity.

22. The method according to any one of claims 6 and 21, wherein the step of sending confirmation to a first requesting entity includes sending a Merkle path linking the target token transaction to a Merkle root stored in the block header of the current token block.

23. The method according to any one of claims 1 to 22, wherein the validation entity includes a token server.

24. The method according to claim 23, wherein the first and / or second requesting entity includes a token client application, and / or the step of obtaining the target token transaction includes the step of receiving the target token transaction from the token client application.

25. The validation entity is, A set of token block headers for each token block, wherein each token block header includes a Merkle root calculated based on each set of valid transactions stored in the respective token block, A set of token transaction identifiers, The method according to any one of claims 1 to 13, wherein a set of token outputs stores a set of token outputs, each of which includes one output index of the set of token transaction identifiers and a corresponding token amount.

26. The method according to claim 25, wherein the step of verifying that each token input of the target token transaction references each token output of a previously validated token transaction includes the step of determining whether the referenced token output is present in the set of token outputs.

27. The method according to claim 26, wherein, under the condition that the target token transaction is a valid token transaction, the step of storing the transaction identifier of the target token transaction and the one or more token outputs of the target transaction in the set of token transaction identifiers and the set of token outputs, respectively.

28. The method according to claim 27, comprising the step of constructing a current token block, wherein the current token block comprises a token block header and a set of transaction identifiers for valid token transactions including the target token transaction, the token block header comprising a Merkle root calculated based on the set of transaction identifiers.

29. The method according to claim 28, comprising the step of constructing a token block for each of the newly published blocks of the blockchain.

30. The method according to any one of claims 25 to 29, wherein the validation entity includes a token client application.

31. The method according to claim 30, wherein the step of obtaining the target token transaction includes the step of receiving the target token transaction from a user as input.

32. The method according to claim 30 or 31, further comprising the step of sending the target token transaction to a token server, provided that the target token transaction is a valid token transaction.

33. The method according to any one of claims 30 to 32, comprising the step of receiving one or more token blocks and / or their respective block headers from a token server.

34. The method according to any one of claims 30 to 33, comprising the step of sending one or more token blocks to a token server for verification.

35. The method according to any one of claims 1 to 34, wherein the encrypted mint data includes publicly available information known to be related to the minting of tokens.

36. A computer implementation method for validating a token transaction, wherein the token transaction is a blockchain transaction having one or more token outputs, each token output locking a respective amount of tokens, and the method is performed by a validating entity. A step of obtaining a target token transaction having one or more token inputs and one or more token outputs, A method for validating the target token transaction, wherein each token input of the target token transaction refers to the respective token output stored in the current token snapshot, the current token snapshot includes a set of token unconsumed transaction outputs (UTXOs), each token UTXO being the token output of the respective unconsumed token transaction.

37. The method according to claim 36, comprising the step of constructing the current token snapshot.

38. The method according to claim 37, wherein the step of constructing the current token snapshot includes the step of tracking token UTXOs on the blockchain.

39. The method according to claim 36, further comprising the step of receiving the current token snapshot from the token server.

40. The method according to any one of claims 36 to 39, comprising the step of constructing an updated token snapshot, provided that the target transaction is a valid token transaction, wherein the updated token snapshot includes the one or more token outputs of the target transaction, but does not include the one or more token outputs referenced by the one or more token inputs of the target token transaction.

41. The method according to any one of claims 36 to 40, comprising the step of sending the target token transaction to a token server and / or blockchain network, provided that the target transaction is a valid token transaction.

42. The steps include receiving a request from a first requesting entity in order to confirm that the target token transaction is a valid token transaction, The steps include: under the condition that the target token transaction is a valid token transaction, sending confirmation that the target token transaction is a valid token transaction to the first requesting entity; The method according to any one of claims 36 to 41, including the method described in any one of claims 36 to 41.

43. The method according to claim 42, wherein the current snapshot includes a Merkle route calculated based on each set of token UTXOs, and the step of sending the confirmation to the first requesting entity includes sending a Merkle path that links the referenced token output to the Merkle route stored in the block header of the current snapshot.

44. A memory having one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein the memory stores code arranged for execution on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 35.

45. A computer program, embodied on computer-readable storage, configured to perform the method described in any one of claims 1 to 35 when executed on one or more processors.

46. A memory having one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein the memory stores code arranged for execution on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 36 to 43.

47. A computer program, embodied on computer-readable storage, configured to perform the method described in any one of claims 36 to 43 when executed on one or more processors.

Images