Token protocol based on block chain

Abstract

A computer-implemented method of executing a token protocol using a blockchain, the method comprising: obtaining a token destruction transaction, the token destruction transaction comprising: a first input signed by a first party, where the first input references a respective output of a first token transfer transaction, wherein the respective outputs are locked to a first public key of the first party and include a first number of tokens; and a first output locked to a destruction public key of a delegate entity and including the first number of tokens; creating a token casting transaction, the token casting transaction comprising: a respective input signed by the delegation entity using a signature corresponding to a casting public key; and a respective output that locks a respective number of the digital assets, the respective number of the digital assets being sufficient to fund one or more respective token transfer transactions, where the respective output is locked to a second public key of the first party and includes the first number of tokens.

Description

Technical Field

[0001] The present disclosure relates to a method of implementing a token protocol, and more particularly to a method related to token destruction and minting as part of a token protocol. Background Art

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

[0003] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing time-stamped entries; and / or sorting index pointers by time. Blockchains can also be used to implement hierarchical additional functions on blockchains. For example, a blockchain protocol may allow additional user data or data indexes to be stored in a transaction. There is no pre-specified limit on the maximum data capacity 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, audio, or video data in a blockchain.

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

[0005] The node that successfully solves the proof-of-work puzzle to create the latest block is usually rewarded with a new transaction called a "coinbase transaction" that distributes the amount of digital assets, i.e. the number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, which act as agents of the network and are incentivized to report and prevent improper behavior. The widespread publication of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the continued integrity of the blockchain.

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

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

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

[0009] In the modern world, cash still plays a vital role in the economies of multiple regions and markets around the world. Cash provides instant peer-to-peer transactions without the need for a central authority, thereby guaranteeing privacy for all parties involved. In addition, cash can be used for transactions even if one or more parties do not hold or have access to a bank account. However, as technology advances, traditional paper cash is becoming increasingly obsolete, and new forms of cash are needed. Blockchain-based cash (called digital cash) can be exchanged digitally using, for example, smartphones and is seen as an alternative to traditional cash. Digital cash has all the properties of traditional cash and is minted and backed by a trusted central authority such as a central bank. However, instead of being printed on paper, digital cash is published on a blockchain. Blockchain-based digital cash can be exchanged peer-to-peer, both online (i.e., there is an internet connection) and offline (i.e., there is no internet connection).

[0010] However, blockchain-based digital cash (and other token protocols) face several challenges, one of which is how to verify a recent token transaction, for example, in order to be able to accept a token in said token transaction.

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for executing a token protocol using a blockchain, wherein a token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of a digital asset and including a respective locking script, the respective locking script being locked to a respective public key of the respective party and including a respective amount of tokens, and wherein the method is performed by a delegated entity. entity) and includes: obtaining a token melt transaction, wherein the token melt transaction includes: i) a first input, the first input being signed by a first party, wherein the first input references a corresponding output of a first token transfer transaction, wherein the corresponding output is locked to a first public key of the first party and includes a first token amount; and ii) a first output, the first output being locked to a burn public key of the delegate entity and including the first token amount; creating a token mint transaction, wherein the token mint transaction includes: i) a corresponding input, the corresponding input being signed by the delegate entity using a signature corresponding to the mint public key; and ii) a corresponding output, the corresponding output locking a corresponding amount of the digital asset, the corresponding amount of the digital asset being sufficient to fund one or more corresponding token transfer transactions, wherein the corresponding output is locked to a second public key of the first party and includes the first token amount; and causing the token mint transaction to be submitted to one or more nodes of a blockchain network.

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method for executing a token protocol using a blockchain, wherein each token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of a digital asset and including a respective locking script, the respective locking script being locked to a respective public key of the respective party and including a respective amount of tokens, and wherein the method is performed by a first party and comprises: initiating a destroy and mint protocol, wherein the destroy and mint protocol comprises: creating a token destroy transaction, wherein the token destroy transaction comprises: i) a first input, the first input being signed by the first party, wherein the first input references a first token locked to a first public key of the first party The invention relates to a method for obtaining a token minting transaction, wherein the token minting transaction comprises: i) a corresponding input, the corresponding input being signed by the delegate entity using a signature corresponding to the minting public key; and ii) a corresponding output, the corresponding output locking a corresponding amount of the digital asset, the corresponding amount of the digital asset being sufficient to fund one or more corresponding token transfer transactions, wherein the corresponding output is locked to the second public key of the first party and comprises the first token amount.

[0013] Embodiments of the present disclosure relate to a "destroy and mint protocol" that can reduce the number of checks that must be performed to verify tokens. Tokens can be "destroyed" (i.e., removed from the token protocol, rendering the token unusable) and minted (i.e., reissued or reintroduced into the token protocol) at certain checkpoints. This means that tokens do not have to be traced back to issuance in order to be verified. The delegate entity is responsible for minting tokens in response to destruction requests. Since the interaction of such delegate entities can cause bottlenecks, such as during peak hours, the protocol is designed to minimize the role of delegate entities in the token transactions without removing them entirely. The delegate entity only needs to check the validity of the token between two transactions (with the checkpoint role), which are called destroy and mint transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] To facilitate an understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0015] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0016] Figure 2 Some examples of transactions that may be recorded in a blockchain are schematically shown;

[0017] Figure 3 A sequence diagram illustrating an exemplary token issuance protocol;

[0018] Figure 4 is a schematic block diagram of an exemplary system for implementing a burning and minting protocol;

[0019] Figure 5 An exemplary transaction chain from a minting transaction to a destroying transaction is shown;

[0020] Figure 6 is a schematic block diagram of an exemplary system for transferring a token transaction and verifying a token transaction;

[0021] Figure 7 An exemplary transaction payment tree is shown, starting with a minting transaction and ending with a current token transaction;

[0022] Figure 8 is a schematic block diagram of an exemplary system for submitting a token transaction to a blockchain;

[0023] Fig. 9 shows an example sequence of token transactions, including a double spend of a token; and

[0024] Fig.10 An exemplary cost graph of a transaction chain is shown. DETAILED DESCRIPTION

[0025] 1. Exemplary System Overview

[0026] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switched network 101, typically a wide area internet such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104, which may 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 nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0027] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, special processors and / or field programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, that is, a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0028] The blockchain 150 includes a series of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores a block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of a digital asset represented as a property, an example of which is an output that is cryptographically locked to a user 103 (requiring the user's signature or other solution to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

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

[0030] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, so that transactions 152 are propagated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. Ordered pools 154 are often referred to as "memory pools". In this article, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid, and for which the node 104 is forced to not accept any other transaction that attempts to spend the same output.

[0031] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring a financial asset, although this is certainly a common application. More generally, spending can be described as consuming an output, or allocating it to one or more outputs in another subsequent transaction. In general, a previous transaction can be any transaction in an ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, it is not necessary for a previous transaction 152i to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this article, "previous" refers to the predecessor in a logical sequence linked by a pointer, and not necessarily the creation time or sending time in a time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of isolated transactions below). A previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0032] The inputs of the current transaction 152j also include input authorizations, such as the signature of the user 103a to whom the outputs of the previous transaction 152i are locked. In turn, the outputs of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amounts among multiple users or entities (one of which may be the original user or entity 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0033] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle it can also be other user terminals). It is also not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i that the new transaction spends (or "allocates"), where the condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or may be determined by a combination thereof. In either case, if the new transaction 152j is valid, the 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, and therefore forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

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

[0035] In addition to verifying that transactions are valid, blockchain nodes 104 compete to be the first node to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At a blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 that attempts to solve the puzzle.

[0036] The first blockchain node 104 that solves the puzzle announces the puzzle solution on the network 106, providing the solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution satisfies the output of the hash value). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the intention of the first node 104 to follow the blockchain protocol. These rules include not accepting a transaction as valid if it spends or allocates the same output as a previously verified valid transaction, otherwise it is called a double spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointers 155 also impose an order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an immutable public ledger of transactions is provided.

[0037] It should be noted that the different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the pool 154 of transactions that have not yet been published at any given time, depending on when they began searching for a solution or the order in which they received the transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool of unpublished transactions 154. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. In addition, there is a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve puzzles within a short time of each other, thereby propagating conflicting views of the blockchain between the nodes 104. In short, the fork direction that is the longest becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0038] 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, accepted amount of digital assets in a new special type of transaction that allocates an additional limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction", but may also be called a "starting transaction" or "generating transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the intention of the node that constructs the new block to follow the protocol rules, thereby allowing the particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is often called a "transaction fee" and is discussed below.

[0039] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 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 may take the form of a user terminal or a group of user terminals networked together.

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

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

[0042] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be referred to as being part of a system that includes 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 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced with "first party" and "second party" respectively.

[0043] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, specific application processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be executed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0045] The client application 105 includes at least a "wallet" function. This has two main functions. One of the functions is to enable the corresponding party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered in the blockchain 150.

[0046] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and rather, any client function described herein may be implemented in a suite consisting of two or more different applications, such as interfacing via an API or one application as a plug-in to another application. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

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

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

[0049] If the newly received transaction 152j passes the validity test (i.e., under the “valid” condition), any blockchain node 104 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, it is assumed that the transaction 152j is valid, which means that the transaction will soon be propagated throughout the network 106.

[0050] Once in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 will begin racing to solve the proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152 (keep in mind that other blockchain nodes 104 can attempt to solve the puzzle based on different transaction pools 154. However, whoever solves the puzzle first will define the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j). Once the pool 154 including the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

[0051] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is “valid” before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that has not yet been published in block 151).

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

[0053] 2. UTXO-based model

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

[0055] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not been redeemed). The UTXO includes a value that specifies the amount of a digital asset. This represents a set of tokens on a distributed ledger. The UTXO may also include a transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include an indicator of the size of the input field 202 and the output field 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0056] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 In , Alice's new transaction 152j is labeled "Tx1". This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. Figure 2, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels that do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to a subsequent transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0057] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 may already be valid and included in block 151 of the blockchain 150. The transaction may have been included in one of the blocks 151 at this time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 soon. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together; or, if the node protocol allows buffering of "orphan" transactions, Tx0 may even be sent after Tx1. The terms "previous" and "successor" as used herein in the context of transaction sequences refer to the order of transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may equally be replaced by "predecessors" and "successors", "predecessors" and "descendants", or "parents" and "children", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "child transactions") pointing to a previous transaction (predecessor transaction or "parent transaction") will not be valid unless the parent transaction is valid. A child transaction that arrives at the blockchain node 104 before the parent transaction is considered an orphan transaction. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for the parent transaction.

[0058] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking condition, which typically includes the following conditions: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to which the previous transaction was locked.

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

[0060] Thus in the example shown, UTXO0 in output 203 of Tx0 includes a locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , in order to redeem UTXO0 (strictly speaking, to make subsequent transactions that attempt to redeem UTXO0 valid). A ] contains Alice's public key P from her public-private key pair A The input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in the embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script <Sig P A >, the unlocking script includes Alice's cryptographic signature, which is created by Alice by applying the private key of her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0061] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing two scripts:

[0062] <Sig PA> <pa>||[Checksig PA]

[0063] Where "||" means concatenation, "<…>" means putting data on the stack, and "[…]" means a function consisting of locked scripts (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack instead of concatenating the scripts. In either case, when run together, the scripts use Alice's public key P A (included in the locking script of the output of Tx0) to verify that the unlocking script in the input of Tx1 contains Alice's signature when signing the expected portion of the data. The expected partial data itself (the "message") also needs to be included in order to perform this verification. In an embodiment, the signed data includes the entire Tx1 (so there is no need to include a separate element to plaintext specify the signed partial data, as it is already present).

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

[0065] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the example shown, if Alice's signature is provided and authenticated in Tx1), then the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the pending transaction ordered pool 154. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that it will propagate throughout the network 106. Once Tx1 is valid and included in the blockchain 150, this will define UTXO0 from Tx0 as spent. It should be noted that Tx1 is only valid if it spends unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been spent (that is, whether it has formed a valid input for another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXO 203 of a transaction 152 as having been spent, but ultimately defining whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in the blockchain 150.

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

[0067] Note that in the UTXO-based transaction model, a given UTXO needs to be spent as a whole. You cannot "leave behind" a portion of the amount defined in a UTXO as spent while spending another portion. However, the amount of a UTXO can be split between multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split between multiple UTXOs in Tx1. Therefore, if Alice does not want to give all of the amount defined in UTXO0 to Bob, she can use the remaining portion to make change for herself in the second output of Tx1, or to pay another party.

[0068] In practice, Alice will also typically need to include a fee for the Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104, and therefore, although technically valid, may not be propagated and included in the blockchain 150 (if the blockchain node 104 does not want to accept transaction 152, the node protocol does not force the blockchain node 104 to accept it). In some protocols, the transaction fee does not require its own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 that issued the transaction. For example, assume that a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or spent) by the node 104 that wins the proof-of-work race to create the block containing UTXO1. Alternatively or additionally, this does not necessarily preclude the possibility of explicitly specifying a transaction fee in one of the UTXOs 203 in its own transaction 152.

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

[0070] It should be noted that script code is often represented schematically (i.e., using an imprecise language). For example, an opcode (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode of the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a file to be stored in the blockchain.

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

[0072] The locking script is sometimes referred to as "scriptPubKey", which means that it usually includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", which means that it usually provides the corresponding signature. However, more generally speaking, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily include verification of the signature. More generally speaking, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0073] 3. Side Channels

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

[0075] The side channel 107 may be established via the same packet switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 107 referred to anywhere in this document may include any one or more links via one or more networking technologies or communication media that are used to exchange data "off-chain", i.e., off-chain. The bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Therefore, it should be noted that if Alice and Bob are said to exchange certain information or data, etc., via a side channel 107, this does not necessarily mean that all of this data must be sent over exactly the same link or even the same type of network.

[0076] 4. Token

[0077] A token can be defined as a unit of value issued by a (trusted) organization. Tokens can be used to represent and manage real-world assets. Here, tokens are different from the underlying digital assets of the blockchain, such as Satoshi / Bitcoin. Tokens are issued and transferred using blockchain transactions, but the value of the transaction (e.g., in Satoshi) does not need to replicate the value of the embedded token (e.g., a transaction that moves a few Satoshis can transfer any number of tokens). Tokens can be managed and verified using trusted third-party services and / or the blockchain's native scripting language. In the latter case, smart contracts that can be used to regulate tokens can be considered stateful smart contracts, where the transaction state contains the number of available tokens.

[0078] Tokens may be permissioned or permissionless. Permissioned tokens are controlled by a central authority (e.g., a government or a trusted institution) or a group of pre-approved entities that are responsible for issuance, management, freezing, and other operations. In contrast, permissionless tokens are a class of tokens whose exchange no one can control. Anyone can issue permissionless tokens, but cannot control their circulation.

[0079] 4.1 Token Validity

[0080] Bitcoin is an example of a UTXO-based blockchain 150. Therefore, each time one or more tokens are transferred from one public key to another, a new transaction output (UTXO) is created. The blockchain network 106 verifies the validity of the native token (e.g., Bitcoin) every time there is a new transaction. However, when new tokens are minted and embedded in UTXO, they are not automatically verified as valid by the nodes 104, so additional verification is required.

[0081] A token scheme on top of blockchain 150 is a unique set of digital assets that are issued at a specific time and distributed following a specific set of rules. Tokens are issued by a trusted party called an issuer. It can be assumed that all parties are able to recognize a newly minted token by the issuer. If a token has followed all rules since issuance, then the token may be considered valid at present. A key challenge facing token schemes is how to know that a token is currently valid. It is often helpful to think of token validity checking as being performed in two steps.

[0082] 1. Was the token ever valid? This usually happens when the user receives the token.

[0083] 2. Is the token currently valid? This usually happens when a user spends a token.

[0084] In terms of the user journey, if the user is about to receive a token, the first step is critical — they want to know if the token is real. Once the user has the token, the second part is critical — they want to know that the token has not been double-spent.

[0085] Consider an analogy with the blockchain itself. The native blockchain token is UTXO. In this case, point 1 corresponds to the Merkle proof of the previous transaction, and point 2 corresponds to the acceptance of the transaction containing the UTXO in the blockchain network 106.

[0086] Another approach to token management is to use accounts. In this case, instead of embedding tokens into UTXO, the amount held by each user is stored in a contract that tracks all balances and provides token transfer functionality. This approach is the preferred solution for blockchains that allow state to be maintained (e.g., Ethereum ERC20 tokens). However, this approach is rarely used in UTXO-based blockchains because the state needs to be maintained within the UTXO, centralizing the protocol and generating large transactions.

[0087] 4.2 Tracing

[0088] Some token protocols involve so-called "traceback" methods to check if a token is valid. Traceback is a technique used by token protocols that set a token rule set and require users to ensure that the rule set is followed. The challenge is that the only way to check if a token is valid is to trace it back to issuance. Such protocols often indicate that wallet software may be responsible for tracking the validity of tokens, but it is unclear what would happen if the wallet software was bypassed. Another challenge is that in such protocols, it is easy to burn tokens if a token transaction is created that does not follow the token rules.

[0089] 4.3 Dust Limitation

[0090] Dust limits prevent transactions of very low value from being published on the blockchain 150. The reason for setting dust limits is that under standard fee policies, outputs of very low value would require a higher fee than the output itself, making these transactions uneconomical to run (the cost of the unlocking script would be higher than the UTXO value).

[0091] Another reason to set dust limits is to prevent dust attacks. Scammers use dust attacks to anonymize transactions, thereby revealing the person or organization behind a wallet. Scammers can "dust" a large number of addresses, wait for wallets to spend these dust outputs, and then perform analysis to reveal which of these addresses belong to the same wallet.

[0092] 5. Destruction and Minting Protocol

[0093] Figure 4 An exemplary system 400 for implementing a destruction and minting protocol as part of a token protocol (e.g., a token protocol having some or all of the features described in Sections 4 and / or 8) is shown. For example, the token protocol can be a protocol for implementing a digital cash system. The system 400 includes one or more entrusting entities 302, a transferor (or payer) 401, a transferee (or payee) 402, and one or more nodes 104 of a blockchain network 106. The transferor and the transferee may also be referred to as a first party and a second party, respectively. The transferor 401 may be configured to perform a combination of Figure 1 and Figure 2 of some or all of the actions attributed to Alice 103a and / or Bob 103b. Similarly, assignee 402 is described above. The assignee may be configured to perform the combined Figure 1 and Figure 2 of some or all of the actions attributed to Alice 103a and / or Bob 103b.

[0094] As described below, the delegate entity 302 is responsible for minting (i.e., issuing, or more precisely, reissuing) new tokens in response to a destruction request from a token user (e.g., a transferor 401). A transferor is a token user who intends to transfer a certain number of tokens to a transferee 402, where the transferee is the recipient of the number of tokens. Here, transferring a token means transferring the ownership of the token to the transferee 402.

[0095] A blockchain transaction that transfers token ownership is referred to herein as a token transfer transaction, or simply a transfer transaction. According to the token protocol described herein, a transfer transaction may need to satisfy one or more of the following conditions in order to be considered a valid transfer transaction. The first of these conditions is that the transfer transaction must include at least one input signed by the transferor 401. A transfer transaction may include more than one input signed by the transferor 401. Each input of the transfer transaction must reference the output of the previous transfer transaction, or the output of the minting transaction. Minting transactions are described below.

[0096] The second of these conditions is that the transfer transaction must include one or more outputs, each of which is locked to a corresponding public key of a token user (e.g., transferee 402). One or more outputs may be locked to transferor 401. Each output contains a corresponding token amount that defines the number of tokens transferred (assigned) to the owner of the corresponding public key to which the output is locked. The token amount may be included as a string or otherwise. In some examples, the token amount is included in a portion of the output (specifically, the locking script for the output) that is not executed during script execution. For example, the token amount may follow an OP_RETURN opcode or an equivalent opcode.

[0097] The third of these conditions is that the sum of the number of tokens in the outputs of the transfer transaction must be equal to the sum of the number of tokens included in the outputs of the previous transfer or minting transaction referenced by the input of the current transfer transaction. For example, if the current transfer transaction references a single output including 50 tokens, the sum of the tokens included in the output of the current transfer transaction must also be 50 tokens, for example, the current transfer transaction can include five outputs, each including 10 tokens.

[0098] Each output of a transfer transaction locks a corresponding amount of the underlying digital asset of the blockchain 150. The underlying asset is different from a token. The number of tokens is added as data to the locking script of the output of the transaction, and the underlying digital asset is the basis of the transaction and is required by the blockchain protocol. Taking Bitcoin as an example, the underlying asset is in satoshis. The fourth of these conditions is that each token output of the transfer transaction (a token output is an output that contains the number of tokens) must lock a sufficient amount of the underlying asset. The sufficient amount can be a predetermined amount. The sufficient amount can be a fixed amount or a minimum amount. In some examples, the sufficient amount can be a portion (i.e., a small portion) of the amount of the underlying asset locked by one or more outputs referenced by one or more inputs of the previous one or more transfer transactions.

[0099] A transfer transaction may have to satisfy one or more further conditions in order to be considered valid. These further conditions are discussed below.

[0100] In response to determining that the transferor 401 cannot generate a valid transfer transaction due to an insufficient amount of digital assets to create more than one token transaction, the transferor 401 may initiate a burn and mint protocol with the delegate entity 302. Initiating the burn and mint protocol may include sending a request to the delegate entity 302. If the amount of one or more outputs of the current token transaction locked together is less than the sufficient amount required to lock the corresponding outputs of more than one transfer transaction, then the amount of digital assets of the transferor 401 is insufficient. The transferor has at least enough digital assets to create a burn transaction (i.e., one token transaction), but less than the amount of digital assets required to create two token transactions (e.g., two transfer transactions).

[0101] Transferor 401 generates a destruction transaction. The destruction transaction includes an input that references an output of a recent transfer transaction, where the output is locked to a first public key associated with transferor 401. The input is signed using a signature that is generated using a first private key corresponding to the first public key. The referenced output includes a first token quantity, such as 40 tokens. The destruction transaction includes an output locked to a destruction public key associated with entrusting entity 302. The output of the destruction transaction includes a first token quantity, such as 40 tokens. That is, the destruction transaction destroys the transferor's existing tokens. Here, destroying tokens actually means transferring tokens to entrusting entity 302 so that they are no longer available to token users. Transferor 401 submits the destruction transaction to blockchain network 106 directly or through an intermediary (e.g., entrusting entity 302).

[0102] The delegating entity 302 obtains the destruction transaction. For example, the delegating entity 302 may obtain the destruction transaction from the blockchain 150, and / or the delegating entity may receive the destruction transaction from the transferor 401.

[0103] The delegate entity 302 generates a minting transaction. The minting transaction includes an input signed with a signature generated using a private key corresponding to a minting public key associated with the delegate entity 302. The minting public key may be the same or different than the destruction public key. In some examples, the input of the minting transaction references the output of the destruction transaction. In other examples, to protect privacy, the input of the minting transaction does not reference the output of the destruction transaction. The minting transaction includes an output locked to a second public key associated with the transferor 401. The second public key may be the same or different than the delegate entity 302. Using a different public key may protect privacy. The delegate entity 302 may receive the second public key from the transferor 402. The output of the minting transaction includes a first token quantity, i.e., the minting transaction mints the same number of tokens as the destruction transaction destroys. The output of the minting transaction locks a certain amount of digital assets, which is sufficient to fund one or more further transfer transactions (i.e., create one or more further transfer transactions). The amount of digital assets locked may be predetermined. The amount may be fixed, i.e., each minting transaction locks the same amount of digital assets. The delegate entity 302 submits the minting transaction to the blockchain network 106 directly or through an intermediary (e.g., transferor 401).

[0104] The transferor 401 obtains a minting transaction. For example, the transferor 401 may obtain a minting transaction from the blockchain 150, and / or the transferor 401 may receive a minting transaction from the entrusting entity 302. After obtaining the minting transaction, the transferor 401 may generate a next transfer transaction that transfers part or all of the first token quantity to the transferee 402. That is, the transferor 401 may generate a token transaction that includes an output that references the minting transaction and an input signed with a signature that is generated using a private key corresponding to the second public key. The token transaction includes one or more outputs, each output including a corresponding token quantity. The sum of the token quantities is equal to the first token quantity. At least one of the outputs includes the second token quantity and is locked to a public key associated with the transferee 402. In addition, each output locks a sufficient amount of digital assets. The transferor 401 submits the token transaction to the blockchain network 106 directly or through an intermediary (e.g., the entrusting entity 302 or the transferee 402).

[0105] Figure 5 An exemplary burn and mint protocol is shown. From top to bottom, the top-most transaction shows an exemplary mint transaction signed with a mint signature and having two token outputs, one locked to Alice's public key and the other locked to Frank's public key. Alice and Frank both issue 50 tokens. The next transaction then shows Alice transferring 40 tokens to Bob, thereby returning 10 tokens to herself. Several transactions later, Dave transfers 40 tokens to Frank. Frank then initiates a burn and mint protocol by generating a burn transaction because he is unable to generate a token transaction due to insufficient funds. The burn transaction is signed by Frank and locks the 40 tokens to the burn public key. The delegate entity 302 then uses the mint transaction to mint 40 tokens and locks those tokens to Frank's public key.

[0106] In some examples, in response to receiving a request from transferor 401, entrusting entity 302 may send a digital certificate to transferor 401, wherein the digital certificate includes a destruction public key. The certificate authenticates that the destruction public key is controlled by entrusting entity 302. Transferor 401 may use the certificate to generate a destruction transaction, for example, by extracting the destruction public key. In some examples, transferor 402 may verify that the digital certificate is a valid certificate and proceed with the destruction and casting protocol only if the certificate is valid. Verifying that the certificate is valid may include verifying that the certificate has not been revoked. Those skilled in the art will be familiar with how to verify that a digital certificate is valid. Continuing the destruction and casting protocol may include generating a destruction transaction.

[0107] The entrusted entity 302 may verify the identity of the transferor before proceeding with the destruction and casting protocol. Continuing with the destruction and casting protocol may include generating a casting transaction. In some examples, in order to verify the identity of the transferor 401, the transferor 401 may send a digital certificate to the entrusted entity, wherein the certificate includes an identity public key associated with the transferor 401. In some examples, the certificate may be publicly accessible. The certificate authenticates that the identity public key is controlled by the transferor 401. The transferor 401 may sign the certificate using a signature generated using a private key corresponding to the temporary public key. The entrusted entity 302 may verify that the identity public key is based on the first public key and the temporary key (i.e., linked to the first public key and the temporary key, or derivable from the first public key and the temporary key).

[0108] In some examples, before proceeding with the destruction and minting protocol, the delegate entity 302 may verify that the destruction transaction generated by the transferor 401 is part of a chain of token transactions that traces back to one or more minting transactions.

[0109] In some examples, the delegate entity 302 may proceed with the destruction and minting protocol only after determining that the destruction transaction is a valid token transaction. Verifying that the token transaction is valid is described below in Section 6. The delegate entity 302 may use some or all of the techniques described in Section 6 to verify that the minting transaction is valid.

[0110] 6. Token Transfer and Verification

[0111] Figure 6 An exemplary system 600 for implementing a transfer (e.g., payment) and verification protocol as part of a token protocol (e.g., a token protocol having some or all of the features described in Sections 4 and / or 8) is shown. For example, the token protocol can be a protocol for implementing a digital cash system. The transfer and verification protocols can be used in conjunction with or separately from the destruction and minting protocols described in Section 5. For example, a delegating entity 302 can use a verification protocol to verify that a destruction transaction is valid. A transferor 401 can use a transfer protocol to transfer tokens from a minting transaction. As will be described, a transferee 402 can use a verification protocol to verify that a transfer transaction generated by a transferor 401 is valid.

[0112] When transferring tokens as part of a token agreement, a transferor 401 may generate a "candidate" transfer transaction. A candidate transfer transaction is a transfer transaction that will be submitted to the blockchain network 106 once it is verified as valid by the transferee 402. In some examples, there may be no difference between the candidate transfer transaction received by the transferee 402 and the corresponding transfer transaction sent to the blockchain network 106, in which case the term "candidate" is used only as a label for the transaction sent by the transferor 401.

[0113] The candidate transfer transaction has at least one input, which is signed by the transferor 401 and references the output of the previous token transaction (previous transfer transaction or minting transaction). The candidate transfer transaction may have more than one input, each input referencing a corresponding token output. If the transaction is signed using a minting signature generated by the entrusting entity 302, the transaction is a minting transaction. Each referenced output includes a corresponding token quantity. The candidate transfer transaction has at least one output, which is locked to the public key of the transferee 402. The candidate transfer transaction may have more than one output. Each output contains a corresponding token quantity. The sum of the token quantities included in the outputs of the candidate transfer transaction must be equal to the sum of the token quantities included in the outputs referenced by the inputs of the candidate transfer transaction. Each output locks a corresponding amount of the underlying digital asset.

[0114] Transferor 401 sends a candidate transfer transaction to transferee 402. Transferor 401 also sends one or more lists to transferee 402, one list for each input of the candidate transfer transaction. Each list contains transactions that trace back from the candidate transfer transaction to one or more corresponding minting transactions through the transactions referenced by the corresponding inputs. For example, reference Figure 7 And taking TxAliceBob as an example of a candidate transfer transaction, one list would contain every transaction in the transaction chain traced from TxAliceBob to minting transactions TxMint1 and TxMint2 via input IN_1. Another list would contain every transaction in the transaction chain traced from TxAliceBob to minting transactions TxMint3 and TxMint4 via input IN_2. It should be noted that these lists can be sent together as one overall list. One or more lists may contain references to transactions, such as their respective transaction identifiers, or the lists may contain the transactions themselves.

[0115] As previously described, each minting transaction is signed using a corresponding minting signature corresponding to a corresponding minting public key. The transferor 401 may also send a corresponding certificate to the transferee 402, the corresponding certificate authenticating that each minting public key is associated with a corresponding trust entity.

[0116] The transferee 402 uses the verification protocol to verify that the candidate transfer transaction is valid. The trustee entity 302 may also use the verification protocol to verify that the destruction transaction described in the above section is valid.

[0117] The transferee 402 receives a candidate transfer transaction and one or more lists of transactions that trace back from the candidate transfer transaction to one or more minting transactions. The transferee 402 uses the one or more lists to verify that each input of the candidate transfer transaction traces back to a corresponding minting transaction. The transferee 402 also verifies that the sum of the number of tokens included in the outputs of the candidate transfer transaction is equal to the sum of the number of tokens included in the outputs of the transactions referenced by the inputs of the candidate transfer transaction. Both verifications must pass for the candidate transfer transaction to be considered valid.

[0118] After determining that the candidate transfer transaction is a valid token transaction, the transferee 402 may submit the candidate transfer transaction (here referred to as a transfer transaction) to the blockchain network 106 directly or indirectly.

[0119] The candidate transfer transaction may undergo one or more additional checks before being deemed valid, as will now be described. For example, the transferee 402 may verify that each minting transaction is signed using a signature corresponding to a corresponding minting public key controlled by the corresponding delegation entity 302. The transferee 402 may perform this verification using a certificate received from the transferor. Additionally, the transferee 402 may check whether the certificate is valid.

[0120] In some examples, the transferee can verify that the candidate transfer transaction has sufficient transaction fees to ensure that the candidate transfer transaction is not sent to the secondary memory pool of the blockchain node 104. If the transaction does not include the minimum transaction fee, these transactions are collected in the secondary memory pool (or secondary transaction pool). This can prevent the transaction from being recorded on the blockchain 150. The transaction fee is usually not explicitly specified in the transaction. Instead, the transaction fee is the difference between the sum of the number of digital assets locked by the corresponding outputs of the transaction and the sum of the number of digital assets locked by the corresponding outputs referenced by the corresponding inputs of the transaction. The transferee 401 can verify that the transaction fee is at least a predetermined minimum value.

[0121] In some examples, a candidate transfer transaction may be considered valid only if each transaction in a chain of one or more transactions tracing back to the one or more minting transactions is also valid. Thus, transferee 402 may verify that each transaction in the chain of one or more transactions is also valid.

[0122] As discussed, the delegation entity 302 may use the verification protocol to verify that the destruction transaction is valid. The delegation entity 302 performs steps equivalent to those described as being performed by the transferee 402, with the candidate transfer transaction being substituted for the destruction transaction.

[0123] 7. Submit the transaction to the blockchain

[0124] Figure 8 An exemplary system 800 for facilitating submission of a transaction to a blockchain network 106 is shown. The system 800 includes a first party, a second party, a third party, and one or more nodes 104 of the blockchain network 106. The first party and the second party may be reference Figures 4 to 7 The transferor 401 and the transferee 402. The third party may be a trusted third party 801.

[0125] The first party 401 may operate a device that is not capable of (i.e., is not configured to) connect to the blockchain network 106 (i.e., send data to the blockchain network). In this case, the first party 401 may not be able to submit transactions to the blockchain network 106. For example, the first party may not be able to connect to the blockchain network 106 via the Internet. The first party 401 may not be able to connect to the blockchain network 106 at all (e.g., the device does not have this capability), or the first party 401 may be temporarily unable to connect to the network 106 (e.g., due to a lack of coverage in the area where the first party 401 is located). The transaction may be related to any purpose or protocol (e.g., the token protocol described herein). This may prevent the first party 401 from utilizing the blockchain. The third party 801 does operate a device that is capable of (i.e., is configured to) connect to the blockchain network 106 (i.e., send data to the blockchain network).

[0126] The first party 401 operates a device capable of sending data to the third party 801. Similarly, the third party 801 operates a device capable of receiving data from the first party. The first party 401 sends a first message to the third party 801, wherein the message includes data for generating a transaction. The third party 801 receives the first message and generates a first transaction based on the message. In some examples, the message includes at least part of the transaction. In other examples, the first message includes a complete transaction. The message is sent via a first connection. The first connection can be a wireless connection. That is, the first party 401 can send a message via a wireless connection. For example, the message can be sent via a mobile (cellular) connection such as a general packet radio service (GPRS). The message can be sent via a short message service (SMS) or a multimedia message service (MMS). Other types of wireless connections that can be used include Bluetooth connections, near field communication (NFC) connections, and low frequency wireless (Tetra).

[0127] The third party 801 sends the first transaction to the blockchain network 106 through the second connection based on the first message. The second connection is different from the first connection. The second connection can be a packet switching network 101, which is usually a wide area Internet such as the Internet. The third party 801 can convert the first message into a first transaction. That is, the first party 801 can use the data included in the first message (e.g., one or more signatures, one or more public keys, one or more token quantities, etc.) to generate the first transaction.

[0128] In some examples, the third party 801 can receive a second message from the blockchain network 106. The second message is received via a second connection (e.g., the Internet). The third party 801 then sends the second message (or a message based on the second message) to the first party 801 and / or the second party via the first connection. In these examples, the second party 402 is also unable to send data to and receive data from the blockchain network 106. For example, the second message may include a confirmation (e.g., a Merkle proof) indicating that the first transaction has been recorded on the blockchain.

[0129] For example, the system 800 can be used to facilitate the transmission of a token transaction to the blockchain network 106. The transferor 401 can send a candidate transfer transaction to the transferee 402, or send a message containing data for generating the candidate transfer transaction. Figure 6 and Figure 7 A candidate transfer transaction is described. Transferor 401 and transferee 402 may communicate via any suitable connection common to both parties (e.g., a first connection). Transferee 402 then sends a transfer transaction (i.e., a candidate transfer transaction that transferee 402 verifies is valid) to trusted third party 801 via the first connection (e.g., via GPRS). Transferee 402 may send a message containing data for generating a transfer transaction, rather than sending the transfer transaction itself. Trusted third party 801 submits the transfer transaction to blockchain network 106 via a second connection (e.g., via the Internet). Trusted third party 801 may obtain confirmation from blockchain network 106 via the second connection and send a response to transferee 402 via the first connection. The transferee may forward the response to transferor 401.

[0130] 8. Digital Cash

[0131] This section briefly describes an exemplary digital cash protocol. Digital cash can be implemented using a blockchain-based token protocol. Embodiments of the present disclosure can be implemented in the context of this exemplary digital cash protocol.

[0132] 8.1 Blockchain Network

[0133] The blockchain network 106 ensures that digital cash payments will not be double-spent, and because the blockchain 150 is public, transparency of token circulation is achieved. In addition, the blockchain network 106 guarantees the correct execution of digital cash payments through its consensus mechanism.

[0134] 8.2 Issuer

[0135] The token issuer (e.g., a central bank) issues digital cash in the form of tokens. Each issuance is published to the blockchain network 106. The issuer establishes a network connection with the blockchain network 106 and the delegated entity described below.

[0136] 8.3 Entrusted Entity

[0137] The delegate entity can be a trusted third-party entity (e.g., a commercial bank), which is highly regulated and each entity has an associated wallet. The role of the delegate entity is:

[0138] Receive newly issued tokens and use a wallet to store them;

[0139] Communicate with users (e.g., distribute issued tokens to users);

[0140] and sending the transaction to the blockchain network 106.

[0141] These entities establish network connections with the blockchain network 106, issuers, and user wallets. Some issuers may also be delegated entities.

[0142] 8.4 Users

[0143] Users (e.g., citizens who wish to redeem digital cash payments) have associated user wallets. Wallets receive tokens from delegate entities and make digital cash payments to other user wallets. Wallets can connect to the blockchain network 106 according to the P2P payment protocol, and they also establish connections with other user wallets and one or more delegate entities. Users cannot be issuers and cannot be delegate entities. Alice 103a and / or Bob 103b can be users of the token protocol.

[0144] 8.5 Digital Certificates and PKI

[0145] This section describes the public key infrastructure (PKI) that can be used by token issuers, delegated entities, and users. It is assumed that central banks and government agencies, for example, can embody several trusted third parties (TTPs) and certification authorities (CAs).

[0146] 8.5.1 PKI

[0147] Each user can generate a private key sk id and the associated public key pk id After the user proves his identity, the public key pk id Authenticated by a CA (see Section 8.5.2). This authentication can have two Know Your Customer (KYC) layers:

[0148] 1. The user has proved his / her identity using his / her resident ID; or

[0149] 2. The user has confirmed their phone number and / or email address.

[0150] The second option could limit the number of transactions a user can perform and the value of each digital cash payment. Proof of authentication (i.e., the digital certificate generated in Section 8.5.2) could be added on-chain.

[0151] sk id and pk id It is called an identity key. In addition, users can also store a personal master key generated by their wallet application. From this master key, users can derive keys using enhanced key derivation protocols such as BIP32. These keys are called temporary keys and should preferably only be used once.

[0152] The token issuer and delegate entity PKI may include one or more master keys stored securely offline (i.e., cold storage). These master keys are used to generate online Level 1 keys (L1), which have limited time validity (e.g., monthly validity), are maintained online and used for authentication. From these keys, the token issuer and delegate entity can derive Level 2 keys (L2) used to sign transactions. L2 keys have stricter time validity (e.g., daily). Similar to user identity keys, L1 and L2 keys are certified by a CA.

[0153] The PKI structure just described can be deployed using randomly generated L2 keys, which are then authenticated using the signature of a valid L1 key. Here, the public key is linked to an output point, and the validity of the public key can be checked by simply checking whether the corresponding output point is in the UTXO set. In other words, the public key is valid until the associated UTXO stays in the memory pool UTXO set, and is invalidated by spending the associated UXTO.

[0154] 8.5.2 Digital Certificates

[0155] Each digital certificate can contain some or all of the following information:

[0156] A hash of private information such as a phone number, email address, or resident ID (if a user) or registration number (if a token issuer or delegated entity);

[0157] Refers to the type of KYC performed on behalf of the user. The delegated entity layer always refers to the strongest KYC process.

[0158] Identity public key (if it is a user) or L1 or L2 public key (if it is a delegate entity);

[0159] Date the certificate was issued;

[0160] The certificate expiry date;

[0161] A digital signature created using the CA’s private key for the above items.

[0162] The temporal validity of L1 and L2 keys is managed through digital certificate issuance and expiration dates.

[0163] The CA issues public keys associated with the private keys used for signing. These public keys are available on a website or in a network repository. As described in the previous section, new keys can be issued and old keys revoked. Once a key is revoked, the digital certificate needs to be reissued.

[0164] It should be noted that a digital certificate can be renewed before its expiration date. This will not invalidate the previous certificate unless it has already expired.

[0165] After receiving a digital certificate, the entity or user determines its validity by checking the following:

[0166] 1. The current date is between the issue date and the expiration date;

[0167] 2. And the digital signature is valid.

[0168] 8.6 Token issuance and structure

[0169] Tokens can only be issued by the token issuer and are not related to the underlying digital asset. Each token has a value expressed in the currency of the token issuer, as well as additional information authenticating its issuance.

[0170] Once issued, the token is embedded in the transaction and is addressed to one of the delegate entities. The delegate entity can be randomly selected, or the delegate entity can request new tokens for distribution. If the user is entitled to receive a token (for example, if they request a digital cash transfer), the delegate entity is responsible for sending that token to the user's wallet.

[0171] Table 1 shows an example of a token issuance transaction:

[0172]

[0173] Table 1

[0174] in<Token Specification> Can be

[0175] Token Currency Great Blockland Pound(GBP) Token Value XGBP Reserves: Issue 1:1 Contact details <![CDATA[Issuer@ctsforgbp.com(PK Issue )]]> jurisdiction Great Blockland Issuance of license Great Blockland Central Bank Additional Information GBP per person

[0176] 8.7 Entrusted physical wallet

[0177] Each delegate entity has an associated wallet that tracks tokens that can be distributed to other users. The functionality supported by this wallet may include one or more of the following:

[0178] Track the total number of tokens available for distribution.

[0179] For each token, record the output point location (the UTXO index and transaction ID where the token is located).

[0180] Set up a key wallet and create a private-public key pair as described above.

[0181] Record the CA's public key.

[0182] Communicate with other delegated entities.

[0183] Receive issued tokens from the token issuer.

[0184] Distribute the issued tokens to users.

[0185] The following details how the delegate entity receives payment from the token issuer. Figure 3 An exemplary protocol for issuing tokens is shown:

[0186] 1. The delegate entity 302 and the token issuer 301 exchange their digital certificates off-chain.

[0187] 2. The entrusting entity 302 and the token issuer 301 check the validity of the received digital certificate. If the certificate is valid, the remaining steps are executed. Otherwise, the protocol stops.

[0188] 3. Token issuer 301 creates transaction TxID issue The payment address of the transaction is the public key contained in the certificate of the entrusted entity 302.

[0189] 4. The transaction is sent by the token issuer 301 to the blockchain network 106.

[0190] 5. The issuer 301 obtains confirmation from the blockchain network 106 that the transaction is valid.

[0191] 6. The issuer 301 sends a copy of the transaction off-chain to the delegate entity 302. The delegate entity 302 now knows the transaction content and the amount of issued digital cash they can distribute to user wallets.

[0192] Since the token issuer 301 and the delegated entity 302 have associated digital certificates, and transactions are published on-chain, the protocol for issuing tokens is secure when the majority of the delegated entities 302 behave correctly.

[0193] 8.8 User Wallet

[0194] User wallets may have one or more of the following features:

[0195] Track the total number of tokens available to a user.

[0196] For each token, record the output point location (the UTXO index and transaction ID where the token is located).

[0197] Set up a key wallet and create a private-public key pair as described above.

[0198] Store and frequently update the CA's public key.

[0199] Communicate with delegated entities and other user wallets (e.g., via TCP / IP). User wallets may also have the ability to connect to the blockchain network 106.

[0200] Send and receive digital cash.

[0201] To distribute the issued tokens to the user wallet, the delegate entity 302 may create the following transaction shown in Table 2, spending TxID issue The output:

[0202]

[0203]

[0204] Table 2

[0205] Transaction TxID user The second input provides any required transaction fees for the transaction.

[0206] A user may receive tokens in his wallet from a delegated entity 302 in the following circumstances:

[0207] The user receives a transfer to the digital cash wallet from the bank (acting as the delegated entity) (e.g., a digital cash withdrawal);

[0208] The user executes the burning and minting protocols described below.

[0209] To calculate PK user , the user wallet can choose one of the following options:

[0210] According to pk id and pk e To calculate PK user , as shown below:

[0211] PK user =pk id +pk e

[0212] Among them, it should be remembered that pk id is the identity public key, and pk e It is the temporary public key of the user's wallet.

[0213] Or the wallet uses a key derivation mechanism such as BIP32 to derive PK user .

[0214] In the latter case, the user wallet can define pk e =PK user -pk id To create a PK user With pk id The link between the temporary key pk e It can be used to link user digital certificates and identity public keys to transaction payments and on-chain public keys.

[0215] PK user May be used only once, and may be used with pk id Unrelated. Unrelated to ensure the public key PK on the chain user Will not be linked to the identity public key pk id To achieve this, the temporary public key pk e =PK user -pk id Just have enough randomness.

[0216] 8.9 Destruction and Minting Protocol

[0217] This section details how users can use a layer 2 protocol to send and receive digital cash payments that can reduce the involvement of a delegated entity 302 compared to some protocols. The protocol aims to find a balance between solving the traceability issue and decentralization. Any of the examples described in this section can be used in conjunction with the burning and minting protocol described in Section 5 above.

[0218] User-to-user digital cash payments are called peer-to-peer (P2P) transactions, payments, or transfers. Unless otherwise specified, the term X tokens will refer only to a UTXO containing a digital cash payment of value X.

[0219] Burn and mint is a protocol that reduces the number of checks that must be performed to verify that a token is valid - tokens do not have to be traced back to issuance, thus solving the trace back to issuance problem. Since the delegate entity 302 may cause a bottleneck during peak hours, the protocol minimizes the role of the delegate entity in P2P transactions without removing the delegate entity completely. In this solution, the delegate entity 302 will have to check the validity of the token between two transactions (with the checkpoint role), which are called the burn and mint transactions. These two transactions are defined as:

[0220] A destroy transaction (representing a destroy checkpoint), where a token is sent from a user (e.g., transferor 401) to a delegating entity 302;

[0221] A mint transaction (representing a mint checkpoint) where a token is returned from the delegating entity 302 to the same user.

[0222] After the minting transaction, there will be on average T chain transactions before the destroying transaction.

[0223] Each user wallet can store units of the underlying digital asset (e.g., Satoshi). These Satoshi are in the value of each UTXO containing the token. Satoshi are received from the delegate entity 302 after the user wallet requests a transfer from, for example, a bank to its digital cash wallet, or through a burn and mint protocol. Receiving Satoshi from the delegate entity 302 acts like a top-up system for the user, where the role of Satoshi is to pay the transaction fees of the P2P payment without the delegate entity 302 being involved in the payment process. The structure of the P2P payment is shown in Table 3 below:

[0224]

[0225] Table 3

[0226] 1. This column is not part of the transaction but is added here for illustration purposes.

[0227] In the above transaction, the transferor Alice 401 is required to spend Z = X + Y tokens of value s satoshis contained in the UTXO. In addition, Alice sends half of her satoshis to the transferee Bob 402 and receives back the remaining satoshis after deducting the transaction fee. Therefore, Bob 402 will have s / 2 satoshis in his wallet to spend X tokens. The choice to send s / 2 to Bob 402 is arbitrary, and the wallet may make other choices as well.

[0228] Whenever the user wallet of transferor 401 wants to spend tokens sitting in UTXO (which does not have enough satoshis to create at least two more transactions), the destruction and minting protocol with threshold T performs the following steps:

[0229] 1. The user wallet 401 requests the delegate entity 302 to destroy the checkpoint.

[0230] 2. The entrusted entity 302 wallet sends its digital certificate to the user wallet 401.

[0231] 3. The user wallet 401 checks the validity of the certificate received in step 2.

[0232] 4. The user wallet 401 spends the UTXO and sends the satoshi and tokens to the public key of the delegate entity 302 contained in the certificate. The transaction created is a destroy transaction.

[0233] 5. User wallet 401 exports the public key PK′ for which they want to receive tokens user .

[0234] 6. The entrusted entity 302 verifies the identity of the user wallet:

[0235] a. The user wallet 401 sends the digital certificate to the trust entity 302.

[0236] b. The trusted entity 302 checks the digital certificate.

[0237] c. User wallet 401 sends the signature by using the digital certificate created using the following equation

[0238] pk e =PK user -pk id

[0239] Among them PK user is the public key included in the input of the destroy transaction.

[0240] d. The trusted entity 302 checks the signature received in step 6c.

[0241] e. The trust entity 302 checks the pk in the user's digital certificate id Whether pk is satisfied id =PK user -pk e .

[0242] 7. The delegate entity 302 checks that all tokens are valid by tracing back to each minting transaction using the verification protocol described below.

[0243] 8. Delegated entity 302 creates a minting transaction with a payment address provided by user 401. The payment is contained in a UTXO that includes:

[0244] a. The user wallet 401 sends the same amount of tokens to the delegate entity via a destroy transaction.

[0245] b. The associated satoshi value, which is enough on average to pay for T transactions, until step 1 needs to be performed again.

[0246] If the delegate entity 302 does not allocate enough Satoshi in step 8b, the user 401 may choose to execute the burn and mint protocol early. Otherwise, if the user 401 does not have enough Satoshi remaining in their wallet, they cannot perform further token payments. This may happen if too many UTXOs are created in the transaction chain. Further estimates of how many Satoshis the delegate entity 302 must allocate are given below.

[0247] Figure 5 The transaction chain between the minting transaction TxID0 and the destroying transaction is shown.

[0248] In summary, destruction and minting have the following characteristics:

[0249] • The delegate entity 302 waits for requests to destroy and mint tokens.

[0250] • The delegate entity 302 only pays the minting transaction fee to cover a chain consisting of T transactions.

[0251] When performing a burn and mint, payment traceability is reduced from the public perspective because the burn public key is always different from the mint public key.

[0252] 8.10 P2P Payments and Token Verification

[0253] To perform a P2P payment, it is assumed in this section that both parties are online. The payer (transferor) 401 is the user, and the payee (transferee) 402 is the user or the delegate entity 302. Any of the examples described in this section can be used in conjunction with the transfer and verification protocols described in Section 6 above.

[0254] To receive the token, the payer 401 and the payee 402 follow the following protocol:

[0255] 1. Payer 401 sends the following to payee 402:

[0256] a. Transactions involving token payments; and

[0257] b. A list of transactions linking the payment to the minting transaction.

[0258] 2. The Payer 401 sends the Payee 402 the digital certificate of the delegate entity 302 that created the minting transaction to which the Payer transaction is linked.

[0259] 3. The payee 402 verifies the validity of the transaction and that the token rules have been correctly implemented. This is done by tracing the token payment back to the minting transaction. The minting transaction is identified using the digital certificate of the delegated entity.

[0260] 4. The payee 401 submits the transaction to the blockchain.

[0261] Expand on step 3 and use Figure 7 The specific example shown in . Figure 7 A diagram of transactions received by Bob 402 is shown. Arrows represent spending of outputs. The transaction labeled TxMint is a minting transaction created by the delegate entity 302. The transaction on the far right is a payment from Alice 401 to Bob 402 and the return of change to Alice 401. The diagram shows a payment tree that Bob 402 needs to verify is valid before accepting payments from Alice 401, with the leaves represented by minting transactions. In general, the set of transactions received by Bob 402 can form a directed acyclic graph (DAG). Next, we will describe in detail how Bob 402 verifies that the tokens they receive from Alice 401 are valid. The transaction that Bob 402 receives from Alice 401 has the following format, as shown in Table 4:

[0262]

[0263] Table 4

[0264] Assume Alice 401 unlocks Z tokens and z satoshis. To verify that the transaction is valid, Bob 402 must check:

[0265] 1.Z(unlockednumber of tokens)=X(received tokens)+Y(change tokenssent back to Alice).

[0266] 2. Check that the token specification has the required format.

[0267] 3. z=x+y+fees (transaction fees paid to the miner) - to ensure that the transaction has not been added to the secondary memory pool of the blockchain node 104, which can prevent the transaction from being recorded on the blockchain 150.

[0268] Additionally, Bob 402 may need to verify the TxID contained in Alice 401 AliceBob To this end, Bob 402 performs the same checks to ensure that the received token is valid, as shown below.

[0269] For each transaction until the minting transaction TxID mint (See Table 5), Bob 402 performs the following steps:

[0270] 1. Check if the sum of input tokens is the same as the sum of output tokens.

[0271] 2. Check whether sufficient transaction fees have been paid.

[0272] 3. Check whether the token specification has been followed.

[0273] Essentially, Bob 402 performs a DAG traversal algorithm (e.g., depth-first search (DFS) and breadth-first search (BFS)) to check the validity of the payment received from Alice 401.

[0274]

[0275] Table 5

[0276] It should be remembered that for each minted transaction, Bob 401 has also received a digital certificate to identify the entrusted entity 302. To check whether the above transaction is a minted transaction, Bob 402 must check the following:

[0277] 1.PK mint Whether it is in the corresponding digital certificate;

[0278] 2. Whether the digital certificate of the entrusted entity is valid. The certificate may have expired. In this case, the user wallet 402 can accept the payment at its own risk, or ask the entrusted entity 302 to perform verification and use the on-chain data to check the validity of the payment.

[0279] When making a digital cash payment, Bob can also send the following to the next payee so that the payee can verify that the payment is valid:

[0280] 1. Bob sends the transaction payment to the payee.

[0281] 2. For each input, Bob sends the full payment DAG of transactions (or trees).

[0282] 3. Bob sends all digital certificates of delegated entities associated with each minted transaction as part of Alice’s payment DAG.

[0283] 4. Bob can now delete each sent digital certificate corresponding to the delegated entity.

[0284] Finally, all of the above steps may also be performed by the delegate entity 302 when receiving a token from the user wallet 401. This occurs via a destroy transaction as described above. The verification protocol is the same.

[0285] The token verification process can be quite heavy in terms of communication (step 1) and verification (step 3). This is because the number of transactions grows exponentially with the number of outputs. Therefore, if there are too many transactions to send to the payee (for example, more than 10), the payer can first request that the burn and minting be performed in advance, and then the payment be sent to the payee. This will reduce the communication to only two transactions (the minting transaction and the transaction containing the token payment).

[0286] 8.11 Online and Offline Payments

[0287] User wallets are typically deployed on mobile phones that have the computational power to verify that the ECDSA signature is valid and perform a SHA256 hash. However, depending on location, token payments can be made online or offline, and the checks that the payee 402 must perform depend on their connectivity to the blockchain network 106. Devices can be differentiated by their connectivity level:

[0288] Level 1 – Internet connection

[0289] Level 2 – Mobile network coverage (e.g., GPRS)

[0290] Level 3 – Low frequency (e.g., 300Mhz) wireless coverage

[0291] Level 4 – Offline

[0292] If the users 401, 402 have a device that can convert between wireless and GPRS signals (e.g. issued by an authority), they have level 3 connectivity. The conversion between wireless and Internet signals can be achieved by using a wireless access network or Tetra. The advantage is that the implementation cost is low because the wireless infrastructure already exists and its coverage is more extensive than the Internet. The only cost incurred is the device that can convert between wireless and Internet signals.

[0293] Levels 2 and 3 involve trusted third parties 801 that receive messages from users 401, 402, convert those messages into transactions and forward them to the blockchain 150. These trusted parties 801 can be mobile or wireless companies, or companies that have built the underlying network infrastructure. The trusted third party 801 does not necessarily have to be one of the delegated entities 302, although this is an option.

[0294] Users 401 , 402 with Level 4 connectivity can receive payments via a short-range wireless protocol (e.g., Bluetooth), but cannot connect to the blockchain 150 (either directly or through a trusted third party 801 ).

[0295] Depending on the level of connectivity, different checks or communication protocols need to be established between the payer 401, the payee 402, and the blockchain network 106. The payer 401 can have any level of connectivity as long as it can communicate with the payee 402. Assuming that destruction and recasting do not have to be performed, each payment protocol is described in detail for each level of connectivity of the payee 402. Any of the examples described in this section can be used in conjunction with the payment protocol described in Section 7 above.

[0296] 8.11.1 Level 1 Agreement:

[0297] This is the protocol described in detail in Section 8.10, repeated here for completeness:

[0298] 1. Payer 401 sends the following to payee 402:

[0299] a. Transactions involving token payments; and

[0300] b. A list of transactions linking the payment to the minting transaction.

[0301] 2. The Payer 401 sends the Payee 402 the digital certificate of the delegate entity 302 that created the minting transaction to which the Payer transaction is linked.

[0302] 3. The payee 402 verifies the validity of the transaction and that the token rules have been correctly implemented. This is done by tracing the token payment back to the minting transaction. The minting transaction is identified using the digital certificate of the delegated entity.

[0303] 4. The payee 401 submits the transaction to the blockchain.

[0304] 8.11.2 Level 2 and Level 3 Protocols:

[0305] 1. Payer 401 and payee 402 execute steps 1 to 3 of Level 1 protocol.

[0306] 2. Payee 402 submits the transaction to trusted third party 801 via SMS or wireless.

[0307] 3. The trusted third party 801 submits the transaction to the blockchain 150 and receives a response from the blockchain network 106.

[0308] 4. The trusted third party 801 sends the response to the payee 402 via SMS or wireless.

[0309] 5. If the response from the blockchain network 106 is that the transaction is valid, the payee 402 accepts the payment.

[0310] 8.11.3 Level 4 protocol:

[0311] 1. Payer 401 and payee 402 execute steps 1 to 3 of Level 1 protocol.

[0312] 2. Payer 401 sends the Merkle proof of the minting transaction and the corresponding block header to payee 402.

[0313] 3. Payee 402 performs the checks detailed in Section 8.13.

[0314] 4. When all checks have been performed successfully, the payee 402 accepts the payment. In the case of double spending, once the payee 402 obtains better connectivity (level 3 or higher), the protocol in Section 6.2 is executed.

[0315] Even though payee 402 performs checks in offline payments, they still rely on a certain level of trust between payer 401 and payee 402. To mitigate the risk of offline transactions, payee 402 may choose to only accept limited payment values ​​from payer 401. The risk of such payments can be modeled by the payee's wallet using a mathematical utility function.

[0316] 8.12 Destruction and Minting Integration

[0317] If the payee 402 is always online (level 1 connectivity), they can choose to perform a burn and mint before each token payment. By calling burn and mint, there is no traceable link between transactions from the public perspective, and the delegate entity 302 is unaware of the token payment that will be made until the payee 402 calls burn and mint.

[0318] On the other hand, Level 2, 3, and 4 connectivity always rely on burning and minting with a threshold of T transactions. When a user runs out of available fees or reaches the threshold T, a remint must be performed. For Level 2 and 3, users can request a remint. However, in the case of Level 4, users need to increase their connectivity level to at least Level 3. This can be achieved by:

[0319] The user finds a geographic area with wireless or mobile network coverage; or

[0320] One of these trust entities may have a mobile station that can be called by the user or regularly travels through the area where the user is located. The mobile station has at least level 3 connectivity and the user connects to the mobile station for recasting.

[0321] 8.13 Offline Payment Verification

[0322] In order to enable offline payments between users, it is necessary to ensure that the validity of transactions can be verified and that users can be held accountable in the event of cheating. Figure 5 In the exemplary transaction chain in , assume that Alice 401 wants to pay Bob 402 and Bob 402 is offline. Bob 402 receives the following from Alice 401 (e.g., via Bluetooth):

[0323] Transaction TxID1 from Alice 401;

[0324] · Casting transaction TxID0;

[0325] The Merkle inclusion proof for transaction TxID0 within the block; and

[0326] The block header of TxID0 is already included.

[0327] Bob 402 needs to store a list of public keys from several CAs. Since it is expected that few authorities will play the CA role, this will not incur a significant storage overhead. The verification protocol is divided into payment verification and identity verification parts.

[0328] 8.13.1 Payment Verification

[0329] 1. Bob 402 uses the Merkle proof of TxID0 to compute the Merkle root.

[0330] 2. If the Merkle root is not the same as the root in the block header, Charlie 103c refuses to spend.

[0331] 3. Otherwise, Bob 402 checks if the difficulty target in the block header storing the transaction is above a predefined threshold. Otherwise, this stops the protocol because Alice 401 may be sending an invalid Merkle proof and header.

[0332] 4. Bob 402 checks if TxID1 spends Alice’s UTXO in TxID0 using Alice’s signature and public key

[0333] pk=pk id +pk e ,

[0334] Among them, it should be remembered that pk id is the identity public key, and pk e It is a temporary public key that can only be used once.

[0335] 5. Bob 402 checks the validity of the token. Otherwise, the payment will be rejected.

[0336] 8.13.2 Authentication

[0337] 6. Alice 401 sends pk to Bob 402 e And use with pk e A digital certificate signed by the associated private key.

[0338] 7. In addition, Alice 401 sends Bob 402 any digital certificates and temporary keys pk of users in the transaction chain from the minting transaction to the current transaction e .

[0339] 8. Bob 402 checks the validity of each digital certificate:

[0340] a. Using pk through digital certificates e Whether the created signature is valid.

[0341] b.pk-pk e Whether it is the public key of the identity in the digital certificate.

[0342] c. Whether the digital certificate is valid.

[0343] If Bob 402 wants to send a payment to an offline user who requests authentication, Bob 402 will send his digital certificate along with pk e and all the digital certificates and keys they received from Alice 401.

[0344] 8.13.3 Public Key Format

[0345] The public key must be in the format pk=pk id +pk e It may seem obvious that only offline payment verification can be enabled. This is not the case. If Alice 401 has received a payment for P2PKH using a public key pk′ associated with a private key sk′, she can still prove her identity to Bob 402. This is done by Alice 401 defining a temporary private key sk′ e =sk′-sk id and the associated public key pk′ e =pk′-pk id Alice 401 can then use pk′ e To perform step 5, and use the private key sk′ e to create a signature.

[0346] 8.13.4 Security

[0347] If Alice 401 submits a different version of TxID1 on the blockchain, Alice 401 subsequently signs two different transactions that spend her UTXO in TxID0. If Alice 401 has provided her digital certificate to Bob 402, Alice 401 can be identified by the trusted third party 801, and Alice 401 is legally responsible for double spending and deceiving Bob 402.

[0348] The person who sends payment to Bob 402 must be Alice 401, that is, Charlie 103c cannot impersonate Alice 401 without knowing Alice's private key. The reason is as follows: If TxID1 spends Alice's UTXO in TxID0, Charlie 103c knows the private key sk. Since Bob 402 uses pk e To check the signature (step 7a), Charlie 103c also knows Alice’s private key sk e Therefore, Charlie 103c knows the private key sk id Therefore, Charlie 103c must be Alice 401.

[0349] 8.13.5 Proof of Work and Proof of Stake

[0350] Charlie 103c can ensure based on the Merkle proof and the block header that the transaction is valid and that the inclusion of TxID0 in the block is correct. In proof of work, new blocks take a certain amount of time to be produced, so users can verify the validity of the chain even if it is received from an untrusted source. Malicious users cannot create a fake chain that embeds the same proof of work without wasting a lot of computing power and money. The same level of security cannot be ensured in proof of stake because the inclusion of transactions in the blockchain is based on machine voting and cannot be easily verified offline.

[0351] 8.13.6 Anonymity

[0352] Only pk=pk id +pk e The transaction is published on-chain, so it is anonymous. However, the payee (Bob) 402 can always use the offline information (pk e + digital certificate) to prove the identity of the payer 401. Therefore, the verification protocol mitigates the risk of offline transactions.

[0353] 8.14 Offline Payment Settlement

[0354] In this section, it is shown how to refund a payee 402 who has received an offline payment and has been double-spent. To this end, two additional trusted third parties 801 are introduced, called the executor entity 901 and the settlement entity 902. The settlement entity 902 is responsible for responding to double-spending notifications and correctly paying any user who has been double-spent. The executor entity 901 is responsible for recovering the loss caused by the user through double spending. To simplify the process and clarify the ideas, use Fig. 9 , where Alice 103a, Frank 103f, Merchant 1 903a, Merchant 2 903b and Merchant 3 903c, as well as the executor entity 903 and the settlement entity 902 have at least 3 levels of connectivity.

[0355] First investigate a scenario where all users have a first KYC tier digital certificate, then discuss how to reduce that requirement. Fig. 9 The payment scenario process given in is as follows:

[0356] 1. Alice 103a double spends, spending the same UTXO to pay Bob 103b and Frank 103f.

[0357] 2. All offline participants exchange payments offline, unaware that their payments depend on Alice’s payment.

[0358] It should be noted that all payments are exchanged using an offline payment verification protocol. Therefore, all participants know all digital certificates of all payees before Alice 103a.

[0359] 3. Dave 103d pays online merchant 1 903a. This payment follows the Level 1 payment protocol.

[0360] 4. Merchant 1 903a detects a double spend when attempting to settle the transaction received from Dave 103d.

[0361] 5. Alice 103a receives notification of their double spend, and the option to create a transaction to pay the token to Bob 103b, Charlie 103c, Dave 103d, and Merchant 1 903a.

[0362] If Alice 103a does not create a transaction, then:

[0363] a. Merchant 1 903a sends the double spend proof to the settlement entity 902 along with the digital certificates of Alice 103a, Bob 103b, Charlie 103c and Dave 103d.

[0364] b. Settlement entity 902 stores the payment chain from Alice 103a to Merchant 1 903a, thereby sending digital proof of Alice's actions to Executor entity 901.

[0365] c. Settlement entity 902 creates a new transaction to pay the loss to Bob 103b, Charlie 103c, and Dave 103d. The transaction created to pay Charlie 103c is given in Table 6.

[0366] d. Settlement entity 902 sends the transaction to blockchain network 106. Once online, Bob 103b, Charlie 103c, and Dave 103d are notified of these payments.

[0367] 6. Mallory 103m pays online merchant 2 903b. This payment follows the Level 1 payment protocol.

[0368] 7. Merchant 2 903b detects a double spend when attempting to settle the transaction received from Mallory 103m.

[0369] 8. Alice 103a receives notification of their double spend, and the option to create a transaction to pay the token to Bob 103b, Elaine 103e, Mallory 103m, and Merchant 1 903a.

[0370] If Alice 103a does not create a transaction, then:

[0371] a. Merchant 2 903b sends the double spend proof to the settlement entity 902 along with the digital certificates of Alice 103a, Bob 103b, Irene 103e, and Mallory 103m.

[0372] b. The settlement entity 902 stores the payment chain from Alice 103a to Merchant 2 903b, thereby sending additional proof of Alice's actions to the performer entity 901.

[0373] c. Settlement entity 902 creates a new transaction to pay Irene 103e and Mallory 103m. The transaction created to pay Irene 103e is shown in Table 7.

[0374] d. Settlement entity 902 sends the transaction to blockchain network 106. Once online, Bob 103b, Elaine 103e, and Mallory 103m are notified of these payments.

[0375] 9. For any transactions that Alice 103a refuses to create, the Executor entity 901 will contact Alice 103a. Alice 103a will have to pay the Delegating entity 302 the cost of all fees for the transactions that the Settlement entity 902 had to create, as well as their initial payment to Bob 103b.

[0376]

[0377]

[0378] Table 6

[0379]

[0380] Table 7

[0381] It should be noted that if Bob 103b double spends when paying Irene 103e and Charlie 103c, Bob 103b will also receive notification of the creation of additional transactions. If Bob 103b remains offline, the Executor entity 901 and the Settlement entity 902 must intervene according to the above protocol.

[0382] To reduce reliance on user digital certificates with the first KYC layer, one of the following alternative protocols can be used to improve user privacy.

[0383] 8.14.1 Alternative 1

[0384] In the above scenario, when Merchant 1 and Merchant 2 detect that they cannot mine the transaction on the blockchain, they will refuse the payment (steps 4 and 7). In addition, all offline users will lose any tokens created as change outputs due to the creation of the transaction associated with Alice's payment. In this case, users do not have to use digital certificates, and offline payments can only be accepted within the trust network.

[0385] 8.14.2 Alternative 2

[0386] All protocol steps are followed, except that the digital certificate has a different KYC layer and Alice 103a may not be responsible for the double spend. Therefore, no enforcer entity is needed. In this case, the only proof received by the settlement entity is the double spend and the transaction created offline. Therefore, the settlement entity can choose to bear all losses of offline users up to a certain token value.

[0387] This alternative could impose high costs on settlement entities if users create sidechains that claim to have double-spended in order to obtain additional payments.

[0388] 8.14.3 Alternative 3

[0389] This alternative combines the above protocol with Alternative 1 in order to create a hybrid solution. Users can choose to request a digital certificate from a CA, but it is not mandatory. For example, when Dave receives a payment from Charlie, Dave can perform the following checks:

[0390] 1. Check that everyone in the payment chain (from Alice to themselves) has a digital certificate for the first KYC layer.

[0391] 2. If yes, then Dave accepts the payment.

[0392] 3. If no (eg, Bob does not own it), then Dave can accept the payment but at his own risk.

[0393] a. Dave will receive any settlement for any recurring spends made by users with the first KYC layer digital certificate.

[0394] b. Dave cannot identify users who do not have the first KYC layer digital certificate and who double spend to the settlement entity and the executor entity. In this case, the settlement entity can choose but does not need to bear Dave's loss.

[0395] 8.15 Transaction Fees

[0396] Statistical models can be used to estimate the value of the underlying asset (e.g., satoshis) required to fund a chain of T transactions and execute the burning and minting protocol. A solution is formulated below, with reference to the chain of transactions in Section 5.1.

[0397] The transaction output forms a cost graph. Assume that the graph is a tree of height 6 (T=5), consisting of TxID0,…,TxID5 and TxID melt Each node is a transaction output, and each outgoing edge from node N represents a spend of the UTXO associated with N. Fig.10 An example is shown.

[0398] In addition, a value V is associated with each node N, which represents the amount of fees that can be paid for subsequent transactions. For example, the root node must pay its input fees and the fees of all subsequent transactions, and keep each UTXO value within the dust limit l d Assume that TxID melt The UTXO value is equal to the dust limit l d . The amount V will be minted mint is defined as the associated value of the root node. More formally, V mint Defined as:

[0399]

[0400] Fee in and fee out These are the fees required to create P2PKH inputs and outputs, respectively, for all transactions.

[0401] Define the branching factor of a tree as the average number of branches per node in the tree. Then, for T=5, the number of castings is:

[0402]

[0403] where r in is the branching factor of the tree formed by TxID0,…,TxID5, and r out is composed of TxID1,…,TxID melt The branching factor of the tree formed can be calculated based on r in To calculate r out , as shown below:

[0404]

[0405] It is observed that for any r in , r out ≤2, and assuming that r out =2. Then

[0406]

[0407] Due to the fee in 、fee out and l d is a constant, in order to obtain the V mint To estimate the branching factor r in Use the following burning and minting protocol to heuristically determine the value r in :

[0408] 1. From the initial branching factor r in-0 (For example, 3) Start.

[0409] 2. Quantity of use To mint currency.

[0410] 3. Execute transactions TxID0, TxID1, ..., TxID5, TxID melt .

[0411] If V mint If it is too low, go to step 4.

[0412] Otherwise, go to step 5.

[0413] 4. Use r in-0 +1 as a branching factor to do the early casting and step 2.

[0414] 5. Calculate the branching factor r of transaction chain TxID0,…,TxID5 in .

[0415] 6. Calculate the moving average branching factor

[0416] 7. Use the branch factor r of the next minted transaction in-1 to perform step 2.

[0417] For example, suppose the branching factor of the first 6 transactions is r in =3( Fig.10 The fee is calculated based on the transaction fee rate of 0.5 SAT / byte. in =74SAT, fee out =17SAT and l d =135SAT. Then, the minting quantity is

[0418] V mint =74·1093+17·254+17280=102480SAT.

[0419] 7. Further comments

[0420] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.

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

[0422] 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 functions described in creating, publishing, propagating and storing blocks 151 of the 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 but not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing blocks (remember that these entities are not considered to be nodes of the preferred Bitcoin network 106).

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

[0424] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0425] Some embodiments have been described in terms of a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments any type of suitable consensus mechanism may be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has a chance to produce the next block 151. The selected node is often referred to as a verifier. A blockchain node may lock its token for a period of time in order to have a chance to become a verifier. Typically, the node that has locked the largest stake for the longest time is most likely to become the next verifier.

[0426] It should be understood that the above embodiments are described by way of example only. In more general terms, a method, apparatus or program may be provided according to any one or more of the following statements.

[0427] Statement 1. A computer-implemented method of executing a token protocol using a blockchain, wherein a token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of a digital asset and comprising a respective locking script, the respective locking script being locked to a respective public key of the respective party and comprising a respective amount of tokens, and wherein the method is performed by a delegate entity and comprises:

[0428] Obtaining a token destruction transaction, wherein the token destruction transaction comprises: i) a first input, the first input being signed by a first party, wherein the first input references a corresponding output of a first token transfer transaction, wherein the corresponding output is locked to a first public key of the first party and comprises a first token amount, and ii) a first output, the first output being locked to a destruction public key of the delegation entity and comprising the first token amount;

[0429] Creating a token minting transaction, wherein the token minting transaction includes: i) a corresponding input, the corresponding input being signed by the delegate entity using a signature corresponding to the minting public key, and ii) a corresponding output, the corresponding output locking a corresponding amount of the digital asset, the corresponding amount of the digital asset being sufficient to fund one or more corresponding token transfer transactions, wherein the corresponding output is locked to the second public key of the first party and includes the first token amount; and causing the token minting transaction to be submitted to one or more nodes of a blockchain network.

[0430] Statement 2. The method of statement 1, comprising:

[0431] receiving a request from the first party to initiate a destruction and minting protocol; and

[0432] In response, a trustee entity digital certificate is sent to the first party, wherein the trustee entity digital certificate includes the destruction public key of the trustee entity.

[0433] Statement 3. A method according to statement 1 or 2, wherein the condition for creating the token minting transaction is to verify the identity of the first party.

[0434] Statement 4. The method of statement 3, wherein said verifying said identity of said first party comprises:

[0435] Obtaining a first party digital certificate, wherein the first party digital certificate includes the first party's identity public key;

[0436] receiving from the first party a signature based on the first party's digital certificate;

[0437] verifying the signature using a temporary public key obtained from the first party; and

[0438] Verifying the identity public key is based on the first public key and the temporary public key of the party.

[0439] Statement 5. A method as described in any of the preceding statements, wherein the destruction public key is different than the casting public key.

[0440] Statement 6. A method according to any of the preceding statements, wherein the condition for creating the token minting transaction is to determine that the token destruction transaction is part of a token transaction chain that traces back to one or more token minting transactions.

[0441] Statement 7. The method according to any of the preceding statements, wherein the condition for creating the token minting transaction is to verify the token destroying transaction, wherein the verifying the token destroying transaction comprises:

[0442] obtaining, from the first party, a list of transactions traceable to one or more corresponding token minting transactions, the one or more corresponding token minting transactions linking the token destroying transaction to the corresponding token minting transactions;

[0443] Verifying that the first input of the token destruction transaction can be traced back to the corresponding token minting transaction using the transaction list; and

[0444] Verify that the first output of the token-destroying transaction includes the first amount of tokens equal to the first amount of tokens included in the corresponding output of the first transfer transaction.

[0445] Statement 8. The method of statement 7, wherein said verifying said token destruction transaction comprises:

[0446] For each corresponding token minting transaction included in the transaction list:

[0447] Obtaining a corresponding delegate entity digital certificate, wherein the delegate entity digital certificate includes a corresponding minting public key of the corresponding delegate entity, the corresponding minting public key being used to sign the corresponding input of the corresponding token minting transaction; and

[0448] Verifying that a respective signature of the respective input used to sign the respective token minting transaction corresponds to a respective minting public key included in the respective delegate entity digital certificate.

[0449] Statement 9. The method of statement 8, wherein said verifying said token destruction transaction comprises: verifying that each corresponding delegate entity digital certificate is a valid certificate.

[0450] Statement 10. The method of any one of statements 7 to 9, wherein said verifying said token destruction transaction comprises:

[0451] Verifying that the corresponding amount of the digital asset locked by the first output of the token destruction transaction is equal to the sum of the corresponding amount of the digital asset locked by the corresponding output of the first token transfer transaction referenced by the first input of the token destruction transaction and a transaction fee collected by a blockchain node for recording the token minting transaction on the blockchain.

[0452] Statement 11. The method of any one of statements 7 to 10, wherein said verifying said token destruction transaction comprises: verifying each transaction tracing back to said corresponding token minting transaction linking said token destruction transaction to said corresponding token minting transaction.

[0453] Statement 12. A computer-implemented method of executing a token protocol using a blockchain, wherein each token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of a digital asset and comprising a respective locking script, the respective locking script being locked to a respective public key of the respective party and comprising a respective token amount, and wherein the method is performed by a first party and comprises:

[0454] Initiate a destruction and minting agreement, wherein the destruction and minting agreement includes:

[0455] creating a token destruction transaction, wherein the token destruction transaction comprises: i) a first input, the first input being signed by the first party, wherein the first input references a corresponding output of a first token transfer transaction locked to a first public key of the first party and comprising a first token amount, and ii) a first output, the first output being locked to a destruction public key of a delegate entity and comprising the first token amount;

[0456] causing the token destruction transaction to be submitted to one or more nodes of a blockchain network;

[0457] Obtaining a token minting transaction, wherein the token minting transaction comprises: i) a corresponding input, the corresponding input being signed by the delegate entity using a signature corresponding to a minting public key, and ii) a corresponding output, the corresponding output locking a corresponding amount of the digital asset, the corresponding amount of the digital asset being sufficient to fund one or more corresponding token transfer transactions, wherein the corresponding output is locked to a second public key of the first party and comprises the first token amount.

[0458] Statement 13. The method of statement 12, comprising:

[0459] creating a second token transfer transaction, wherein the second token transfer transaction comprises: i) a second input, the second input being signed by the first party, wherein the second input references the corresponding output of the token minting transaction; and ii) one or more corresponding second outputs, each second output locking a corresponding amount of the digital asset, wherein each corresponding second output comprises a corresponding locking script locked to a corresponding public key of a corresponding party and a corresponding amount of tokens, wherein a sum of the corresponding amounts of tokens equals the first amount of tokens; and

[0460] Causes the token-second token transaction to be submitted to one or more nodes of a blockchain network.

[0461] Statement 14. The method of statement 12 or 13, wherein initiating the destruction and minting protocol comprises:

[0462] Requesting a token destruction transaction from the delegated entity;

[0463] A trust entity digital certificate is received from the trust entity, wherein the trust entity digital certificate includes the destruction public key of the trust entity.

[0464] Statement 15. The method of statement 14, wherein the condition for creating the token destruction transaction is that the delegate entity digital certificate received from the delegate entity is valid.

[0465] Statement 16. The method of any one of Statements 12 to 15, wherein the first public key of the first party is different than the second public key of the first party.

[0466] Statement 17. The method of any one of statements 12 to 16, wherein the delegate entity has access to a first party digital certificate including an identity public key of the first party, and wherein the method comprises:

[0467] generating a signature based on the first party digital certificate using a private key corresponding to a temporary public key based on the first public key of the first party and the identity public key of the first party; and

[0468] The signature is sent to the delegate entity.

[0469] The method may include the first party sending the first party digital certificate to the trust entity.

[0470] Statement 18. The method of any one of statements 12 to 17, comprising sending the second public key of the first party to the trust entity.

[0471] Statement 19. The method of any one of statements 12 to 18, wherein the initiating is responsive to determining that the first party is unable to create a next token transfer transaction due to an insufficient amount of the digital asset.

[0472] Statement 20. A computer device, the computer device comprising:

[0473] a memory, the memory comprising one or more memory cells; and

[0474] A processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured to execute a method according to any one of statements 1 to 19 when executed on the processing device.

[0475] Statement 21. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform the method of any one of statements 1 to 19.

[0476] According to another aspect disclosed herein, a method may be provided, the method comprising actions by the first party and the delegate entity.

[0477] According to another aspect disclosed herein, a system may be provided, the system comprising a computer device of the first party and the entrusted entity.< / pa>

Claims

1. A computer-implemented method for executing a token protocol using a blockchain, wherein a token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of a digital asset and including a respective locking script, the respective locking script being locked to a respective public key of the respective party and including a respective amount of tokens, and wherein the method is performed by a delegate entity and comprises: Obtaining a token destruction transaction, wherein the token destruction transaction comprises: i) a first input, the first input being signed by a first party, wherein the first input references a corresponding output of a first token transfer transaction, wherein the corresponding output is locked to a first public key of the first party and comprises a first token amount, and ii) a first output, the first output being locked to a destruction public key of the delegation entity and comprising the first token amount; creating a token minting transaction, wherein the token minting transaction comprises: i) a respective input, the respective input being signed by the delegate entity using a signature corresponding to a minting public key, and ii) a respective output, the respective output locking a respective amount of the digital asset, the respective amount of the digital asset being sufficient to fund one or more respective token transfer transactions, wherein the respective output is locked to a second public key of the first party and comprises the first token amount; and Causes the token minting transaction to be submitted to one or more nodes of the blockchain network.

2. The method according to claim 1, comprising: receiving a request from the first party to initiate a destruction and minting protocol; as well as In response, a trustee entity digital certificate is sent to the first party, wherein the trustee entity digital certificate includes the destruction public key of the trustee entity.

3. A method according to claim 1 or 2, wherein the condition for creating the token minting transaction is to verify the identity of the first party.

4. The method of claim 3, wherein verifying the identity of the first party comprises: Obtaining a first party digital certificate, wherein the first party digital certificate includes the first party's identity public key; receiving from the first party a signature based on the first party's digital certificate; verifying the signature using a temporary public key obtained from the first party; as well as Verifying the identity public key is based on the first public key and the temporary public key of the party.

5. A method according to any preceding claim, wherein the destruction public key is different compared to the minting public key.

6. A method according to any preceding claim, wherein the condition for creating the token minting transaction is to determine that the token destroying transaction is part of a token transaction chain tracing back to one or more token minting transactions.

7. The method according to any of the preceding claims, wherein the condition for creating the token minting transaction is to verify the token destroying transaction, wherein the verifying the token destroying transaction comprises: obtaining, from the first party, a list of transactions traceable to one or more corresponding token minting transactions, the one or more corresponding token minting transactions linking the token destroying transaction to the corresponding token minting transactions; Verifying that the first input of the token destruction transaction can be traced back to the corresponding token minting transaction using the transaction list; as well as Verify that the first output of the token-destroying transaction includes the first amount of tokens equal to the first amount of tokens included in the corresponding output of the first transfer transaction.

8. The method of claim 7, wherein verifying the token destruction transaction comprises: For each corresponding token minting transaction included in the transaction list: Obtaining a corresponding delegate entity digital certificate, wherein the delegate entity digital certificate includes a corresponding minting public key of the corresponding delegate entity, the corresponding minting public key being used to sign the corresponding input of the corresponding token minting transaction; and Verifying that a respective signature of the respective input used to sign the respective token minting transaction corresponds to a respective minting public key included in the respective delegate entity digital certificate.

9. The method of claim 8, wherein verifying the token destruction transaction comprises: Verify that each corresponding trusted entity digital certificate is a valid certificate.

10. The method according to any one of claims 7 to 9, wherein the verifying the token destruction transaction comprises: Verifying that the corresponding amount of the digital asset locked by the first output of the token destruction transaction is equal to the sum of the corresponding amount of the digital asset locked by the corresponding output of the first token transfer transaction referenced by the first input of the token destruction transaction and a transaction fee collected by a blockchain node for recording the token minting transaction on the blockchain.

11. The method according to any one of claims 7 to 10, wherein the verifying the token destruction transaction comprises: Verifying each transaction traceable to the corresponding token minting transaction linking the token destroying transaction to the corresponding token minting transaction.

12. A computer-implemented method of executing a token protocol using a blockchain, wherein each token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of a digital asset and comprising a respective locking script, the respective locking script being locked to a respective public key of the respective party and comprising a respective amount of tokens, and wherein the method is performed by a first party and comprises: Initiate a destruction and minting agreement, wherein the destruction and minting agreement includes: creating a token destruction transaction, wherein the token destruction transaction comprises: i) a first input, the first input being signed by the first party, wherein the first input references a corresponding output of a first token transfer transaction locked to a first public key of the first party and comprising a first token amount, and ii) a first output, the first output being locked to a destruction public key of a delegate entity and comprising the first token amount; causing the token destruction transaction to be submitted to one or more nodes of a blockchain network; Obtaining a token minting transaction, wherein the token minting transaction comprises: i) a corresponding input, the corresponding input being signed by the delegate entity using a signature corresponding to a minting public key, and ii) a corresponding output, the corresponding output locking a corresponding amount of the digital asset, the corresponding amount of the digital asset being sufficient to fund one or more corresponding token transfer transactions, wherein the corresponding output is locked to a second public key of the first party and comprises the first token amount.

13. The method according to claim 12, comprising: creating a second token transfer transaction, wherein the second token transfer transaction comprises: i) a second input, the second input being signed by the first party, wherein the second input references the corresponding output of the token minting transaction; and ii) one or more corresponding second outputs, each second output locking a corresponding amount of the digital asset, wherein each corresponding second output comprises a corresponding locking script locked to a corresponding public key of a corresponding party and a corresponding amount of tokens, wherein a sum of the corresponding amounts of tokens equals the first amount of tokens; and Causes the token-second token transaction to be submitted to one or more nodes of a blockchain network.

14. The method of claim 12 or 13, wherein initiating the destruction and minting protocol comprises: Requesting a token destruction transaction from the delegated entity; A trust entity digital certificate is received from the trust entity, wherein the trust entity digital certificate includes the destruction public key of the trust entity.

15. The method according to claim 14, wherein the condition for creating the token destruction transaction is that the delegate entity digital certificate received from the delegate entity is valid.

16. The method of any one of claims 12 to 15, wherein the first public key of the first party is different compared to the second public key of the first party.

17. A method according to any one of claims 12 to 16, wherein the delegate entity has access to a first party digital certificate comprising an identity public key of the first party, and wherein the method comprises: generating a signature based on the first party digital certificate using a private key corresponding to a temporary public key based on the first public key of the first party and the identity public key of the first party; as well as The signature is sent to the delegate entity.

18. The method according to any one of claims 12 to 17, comprising: The second public key of the first party is sent to the trust entity.

19. The method of any one of claims 12 to 18, wherein the initiating is responsive to determining that the first party is unable to create a next token transfer transaction due to an insufficient amount of the digital asset.

20. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores a code arranged to be executed on the processing device, the code being configured to execute the method according to any one of claims 1 to 19 when executed on the processing device.

21. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 19.

Images