Atomic exchange token transactions

Abstract

A computer-implemented method of transferring tokens using a blockchain, the method comprising: generating a transaction, the transactions include an input referencing an output of an issued transaction or an output of a transaction forming part of a chain linked to one or more transactions of the issued transaction, an output locked to a public key of a recipient, and an output locked to a public key of a sender; sending the transaction to the receiving party; receiving a funded transaction from the recipient; verifying whether the output locked to the public key of the sender locks a predetermined number of digital assets, and if it does lock, generating a signed transaction by including a signature in the input of the funded transaction, where the signature corresponds to a first public key of the sender; and sending the signed transaction to a block chain network.

Description

Technical Field

[0001] The present disclosure relates to methods of sending and receiving (ie, transacting) tokens using a blockchain. 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] There are several token protocols of varying complexity on the blockchain, through which tokens can be transferred from one party to another using blockchain transactions. Most token protocols are not interactive when trading tokens. Therefore, there may be situations where one party can transfer tokens to another party without receiving a reward in return, or at least without receiving a reward when transferring said tokens. Similarly, a party can transfer assets to the holder of said tokens, but without receiving said tokens in return, or at least without receiving said tokens when transferring said tokens. The present application aims to solve these problems.

[0010] According to one aspect disclosed herein, there is provided a computer-implemented method for transferring tokens using a blockchain, wherein the blockchain comprises a token issuance transaction, wherein the token issuance transaction comprises token data and an output locked to a public key of an issuing party, and wherein the method is performed by a sending party and comprises: generating a first transaction, wherein the first transaction comprises: i) a first input, the first input referencing an output of the token issuance transaction or an output of a previous transaction (forming part of a chain of one or more previous transactions linked to the token issuance transaction), wherein the referenced output is locked to a first public key of the sending party, ii) a first output, the first output being locked to a public key of a recipient, the first output comprising token data, and iii) a second output, the second output being locked to a public key of the sending party; sending the first transaction to the recipient, wherein the recipient is configured to verify whether the first input refers to the output of the token issuance transaction or the output of the previous transaction forming part of the chain of one or more previous transactions linked to the token issuance transaction, and whether the first output is locked to the public key of the recipient, and if so, transferring the first transaction to the recipient by (referencing one or more corresponding funding transactions (funding transactions)). The method comprises: generating a funded first transaction by including one or more corresponding inputs of one or more corresponding outputs of a first transaction (or a funding transaction, a funding transaction) in the first transaction, wherein the one or more corresponding outputs are locked to one or more corresponding public keys of the recipient; receiving the funded first transaction from the recipient; verifying whether the second output locked to the public key of the sender locks a predetermined amount of digital assets, and if so, generating a signed first transaction by including a signature in the first input of the funded first transaction, wherein the signature corresponds to the first public key of the sender; and sending the signed first transaction to one or more nodes of a blockchain network and / or the recipient.

[0011] According to another aspect disclosed herein, there is provided a computer-implemented method for accepting a token transferred using a blockchain, wherein the blockchain includes a token issuance transaction, wherein the token issuance transaction includes token data and an output locked to a public key of an issuer, and wherein the method is performed by a receiving party and includes: receiving a first transaction from a sender; verifying whether the first transaction includes a first input, the first input referencing an output of the token issuance transaction, or an output of a previous transaction forming part of a chain of one or more previous transactions linked to the token issuance transaction, wherein the referenced output is locked to a first public key of the sender; verifying whether a first output of the first transaction is locked to a public key of the recipient; generating a funded first transaction by including in the first transaction one or more corresponding inputs (referencing one or more corresponding outputs of one or more corresponding funded transactions), the one or more corresponding outputs being locked to one or more corresponding public keys of the recipient, wherein the provided a first funded transaction including a second output locked to a public key of the recipient, the second output including token data; sending the funded first transaction to the sender, wherein the sender is configured to verify whether the one or more corresponding funded transactions are on the blockchain, and verify whether the second output of the first funded transaction is locked to the public key of the sender and locks a predetermined amount of digital assets, and if so, generate a signed first transaction by including a signature in the first input of the funded first transaction, wherein the signature corresponds to the first public key of the sender, and send the signed first transaction to one or more nodes of a blockchain network and / or the recipient.

[0012] Embodiments of the present disclosure provide an interactive process for transferring (i.e., trading) tokens using a blockchain. The transaction involves the interaction of both parties, a sender and a receiver. The transaction can only occur if both parties perform certain actions and checks. This makes the transaction atomic, in which case a completely fair transaction can be performed. The sender sends a token transaction to the receiver ("first transaction"). At this point, the token transaction is incomplete. The receiver performs one or more checks (i.e., verification), and if the one or more checks pass, funds the token transaction ("funded first transaction") and returns the funded transaction to the sender. The sender performs one or more checks on the funded transaction, and if the one or more checks pass, signs the token transaction ("signed first transaction"). The signed transaction is then sent to the blockchain network. After being sent to the network, the receiver receives the token (because the token transaction contains an output locked to the receiver and contains the token data), and the sender obtains the fee for the transfer (because the token transaction contains an output locked to the sender).

[0013] As is well known, conditions can be enforced on fields of a spend transaction (i.e., a transaction that spends (unlocks, allocates, transfers, etc.) an output of a previous transaction). For example, the previous transaction may include a locking script that imposes conditions on one or more outputs of the spend transaction. It should be noted that the term "spend transaction" as used in the art refers to a current transaction that unlocks at least one output of at least one previous transaction, and does not necessarily mean that the current transaction is related to a financial transaction.

[0014] One reason for wanting to enforce conditions on the fields of a spend transaction is to ensure that the spend transaction has an output that includes the same locking script as the previous transaction. In this way, it can be ensured that the spend transaction enforces the same conditions on subsequent spend transactions. That is, the n-1th transaction includes a locking script that forces the nth transaction to include the same locking script, thereby forcing the n+1th transaction to include the same locking script. In this way, a chain of transactions is created whereby each transaction includes the same locking script. This can be used, for example, in the context of digital tokens that represent ownership of real-world objects, or even objects in the virtual world. This is advantageous because it means that every transfer of the token follows the same rules.

[0015] Previous attempts to force a chain of transactions to include the same locking script have encountered at least one of the following problems. First, some attempts require the verifier to trace back to the first transaction in the chain (e.g., the "issuance transaction") to ensure that the first transaction (e.g., by a specific authority, such as a token issuer) was created correctly, or that the locking script included in the most recent transaction is the same as the locking script included in the first transaction and every other transaction in the chain. This consumes the verifier's resources (in terms of computing resources, time, and energy) to verify the latest transaction in the chain. Second, some attempts require a third party to participate in the creation and / or verification of the subsequent transaction in the chain (e.g., transfer tokens) to ensure that the subsequent transaction is created correctly. This undermines the trustless nature of the blockchain due to reliance on a third party and increases the number of parties that must interact with each other, thereby reducing efficiency. Third, as discussed below, some attempts to force a chain of transactions to include the same locking script require the latest transaction in the chain to include every previous transaction in the chain, thereby introducing a transaction bloat problem. This is a problem for both the transmission and storage of transactions. Fourth, some attempts are vulnerable to replay attacks.

[0016] Previous attempts to impose conditions on future spend transactions involved injecting said spend transactions into the stack of the blockchain script engine in order to execute business logic on the transaction being verified by the blockchain node. One technique for forcing the unlocking script to contain such a message is known in the art as PUSHTX, which is a pseudo opcode, i.e., a combination of opcodes configured to perform a specific function. PUSHTX is described in UK patent application GB2112930.9.

[0017] The so-called PUSHTX mechanism embeds (i.e., injects) a copy of the sighash field of the spend transaction in the unlocking script of the spend transaction. Using the opcode OP_CHECKSIG, verification logic can be developed in the locking script (of the parent transaction) to ensure that the injected copy corresponds to the spend transaction. It is also possible to inject ancestors of the transaction, but all fields of the ancestor (including the unlocking script) need to be embedded in the unlocking script of the spend transaction. In some cases, this technique may not be suitable. For example, since the unlocking script accumulates all previous transactions, iterative injection of the parent transaction can result in transactions that quickly expand in size.

[0018] The present disclosure provides a mechanism to impose structure (i.e., conditions, constraints, etc.) on the spend transaction and / or its ancestors without pushing the spend transaction to the stack. This enables conditions to be imposed on some or all token transactions while addressing the transaction bloat problem. Embodiments of the present disclosure also address one or more of the other issues discussed previously.

[0019] A locking script (referred to as an "enforcement locking script") is used to enforce conditions (i.e., constraints, restrictions, etc.) on future transactions (i.e., spending transactions) that attempt to unlock an output containing the enforcement locking script. The locking script contains at least two sub-scripts (i.e., parts of the entire locking script). The first part (referred to as a "commitment sub-script" or "compact transaction integrity mechanism") is used to verify whether the transaction commitment (i.e., string) provided in the unlocking script of the spending transaction is a binding commitment (sighash serialized) of the spending transaction. In some examples, the transaction commitment is based on a hash digest or digital signature generated by the spending transaction. The second part (referred to as a "constraint sub-script") is used to verify whether the spending transaction (i.e., the committed transaction) satisfies one or more constraints. This is done without including the spending transaction (or a field of the spending transaction) in the unlocking script of the spending transaction. In other words, this results in the sighash serialization of the spending transaction not needing to be included in the unlocking script of the spending transaction. Instead, the unlocking script contains its commitment, which is shorter in size and independent of the transaction size.

[0020] Some embodiments of the present disclosure use concise non-interactive zero-knowledge arguments (SNARKs) to prove off-chain that the structure of the transaction is constrained according to the business logic. This generates a short (concise) proof that can be embedded as part of the unlocking script and verified on-chain. The constraint sub-script portion of the enforced locking script (containing the logic for verifying the proof) may be large, but has a constant size and is independent of the size of the spending transaction. This, together with short commitments, solves the above-mentioned transaction expansion problem. As already explained, these embodiments require more than just applying a general SNARK. Direct application would require the verification algorithm to receive the spending transaction being verified as input, thereby reintroducing the expansion problem. To overcome this problem, SNARKs are combined with a concise transaction integrity mechanism that can be verified on-chain. A specific example of such an integrity check uses a so-called "virtual signature", as described in UK patent application GB2206039.6. The resulting mechanism of these embodiments is called REFTX, which stands for "reference transaction".

[0021] REFTX is not limited by the expressive power of the blockchain scripting language and can impose structure on said spend transaction or its ancestors (contrary to PUSHTX). In fact, REFTX runs mostly off-chain. Furthermore, it allows for a rich class of constraints to be enforced (due to the use of generalized SNARKs). The only requirement is that such constraints can be expressed as programs that can be verified via SNARKs. This covers almost any feasible computation that can be thought of.

[0022] The REFTX mechanism can be used to implement non-fungible token (NFT) schemes where the transfer of ownership of tokenized assets is managed through locks. The transfer of ownership is controlled by the NFT program, which imposes constraints on previous transactions to ensure that the spending transaction can be traced back to the issuance or minting transaction containing the token. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0026] Figure 3 An exemplary system for enforcing conditions on blockchain transactions is schematically illustrated;

[0027] Figure 4 schematically illustrates an example of a first transaction enforcing a condition on a second transaction;

[0028] Figure 5 Some exemplary transactions for issuing and minting blockchain-based tokens are schematically illustrated;

[0029] Figure 6 Schematically illustrates some exemplary transactions for trading tokens using two funding transactions, where PK1, PK2 are controlled by the receiver, PK3 is controlled by the sender, and f represents the miner's fee;

[0030] Figure 7 Schematically illustrating some example transactions for trading tokens for a 1% royalty fee on the transaction;

[0031] Figure 8 Schematically illustrates some example transactions for minting two replicated tokens, where the root of the token hash tree is hardcoded in the token program that verifies the transfer;

[0032] Fig. 9 schematically illustrates an exemplary hash tree for encoding different versions of replication tokens; and

[0033] Fig.10 Schematically illustrated are some example transactions for transacting non-burnable tokens, where the only funding UTXOtxid′||0 is unlocked using the same public key that the tokens were sent to. DETAILED DESCRIPTION

[0034] 1. Exemplary System Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0050] Computer devices 102 of each of the 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).

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

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

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

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

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

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

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

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

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

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

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

[0062] 2. UTXO-based model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0082] 3. Side Channels

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

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

[0085] 4. SNARK

[0086] Let P(x;w)=b∈{0,1} be a binary program that takes a bit string x (instance) as public input and another bit string w (witness) as private input, and outputs a decision bit b. If b=1, then P executes correctly.

[0087] A Succinct Non-Interactive Argument of Knowledge (SNARK) for the correct execution of a preprocessed program P is an algorithmic triple SNARK:=(Setup,Prove,Verify) such that:

[0088] Setup(λ,P)→(ek,vk): After inputting the security parameter λ and the description of the program P, it outputs a pair of evaluation key and verification key.

[0089] Prove(ek,x,w)→π: When given the evaluation key, public input x, and private input w, it outputs proof π.

[0090] Verify(vk,x,π)→b∈{accept,reject}: After inputting the verification key, the public input x, and the proof π, it either accepts or rejects the proof.

[0091] A SNARK is complete if the verifier always accepts a proof π generated by the prover SNARK.prove on an input pair (x,w) of public / private input that makes the program P accept. This is plausible if for all public inputs x without private input w that makes P accept, the verifier is very likely to reject any proof π of x. More formally, if for all probabilistic polynomial-time algorithms (Capturing possible cheating provers) are all true, then the scheme is reasonable:

[0092]

[0093] Note that the verification key must be generated honestly using a set algorithm. Furthermore, if it is also possible to obtain a valid proof of π and a (possibly cheating) prover If the witness can be efficiently computed (extracted) from the randomness used to generate π (at most negligible error - knowledge error), then the proof is considered to be knowledge-justified.

[0094] The proof is a "short" proof. This means that the proof is logarithmic in the size of the private input w. More specifically, the proof is of size poly(λ)ploylog(|w|), remembering that λ is a security parameter. If, in addition to being short, the verifier runtime is also "fast", then the system has succinct verification (sometimes called completely succinct). That is, the size of the program P is logarithmic in the size of the private input w. So if the runtime takes poly(λ)polylog((|x|+|w|) steps.

[0095] 4.1 On-chain SNARK Verification

[0096] Embodiments of the present disclosure may utilize SNARK schemes that can be verified on-chain (i.e., during script execution). For a given SNARK scheme, there is a script [SNARK verify] that implements the verifier SNARK.verify. For example, for pairing-based SNARKs, the verifier consists of evaluating a small number of pairings on an elliptic curve. Pairing can be implemented using a finite field arithmetic opcode set built in the BSV scripting language. For hash-based SNARKs, the verifier can be implemented primarily using the opcode OP_SHA256.

[0097] In any case, the verification script takes as input the proof π, the public input x, and the verification key vk, and pushes a 1 (accept) or 0 (reject) to the top of the stack.

[0098] Therefore, if accept←SNARK.verify(vk,x,π), then <π> <x> <vk>[SNARK verify] Pushes "True" to the top of the stack, otherwise pushes "False" (0 or negative 0).

[0099] 5. Simple transaction integrity - STI mechanism

[0100] The STI mechanism is a binding commitment of a transaction. The mechanism includes two algorithms STI: = (commit, verify).

[0101] commit(tx)→τ tx ∈{0,1} λ : After inputting a transaction, it outputs a commitment tag τ of size λ tx .

[0102] verify(tx,τ tx ) → {accept, reject}: After inputting the commitment key, transaction, and tag, it will accept or reject.

[0103] If accept←verify(tx,commit(tx)), then the mechanism is complete. If two transactions with the same tag cannot be created, then the mechanism is a binding mechanism. Therefore, for any probabilistic algorithm A, the following holds:

[0104]

[0105] The STI mechanism checks the integrity of the spend transaction concisely. This means that the size of the script that verifies the integrity of the spend transaction and the argument of the script do not depend on the size of the spend transaction.

[0106] 5.1 Simple verification on the chain

[0107] Embodiments of the present disclosure may utilize an STI mechanism that may be verified on-chain (i.e., during script execution).

[0108] The STI mechanism needs to be concise, as follows:

[0109] i. The locking script of the parent transaction contains the script [STI verify] as a subroutine, so that if and only if STI.verify(stx,τ tx ) is accepted, <τ tx >[STI verify] pushes "True" to the stack. Here, stx represents a spending transaction.

[0110] ii. The size of [STI verify] is independent of the size of the spend transaction. Specifically, where λ is a security parameter.

[0111] iii. The size of the tag is independent of the size of the spend transaction. Specifically,

[0112] To verify the commitment label τ tx , the spending transaction tx cannot be pushed to the stack. Otherwise, the second or third property mentioned above will be violated.

[0113] 5.1.2 Exemplary on-chain STI mechanism

[0114] UK patent application GB2206039.6 describes a "virtual signature mechanism" that involves generating a "virtual" ECDSA signature on the secp256k1 curve, where the signing key sk and the temporary key k are set to 1, sk = k = 1. The message is hashed before it is signed. Therefore, if SHA256 is treated as a random function, the binding property is obtained.

[0115] In this case, set the output of STI.commit to the signature generated according to the above process:

[0116] τ tx ←STI.commit(tx):=ECDSA.sign(sk:=1,k:=1,SHA256(tx)).

[0117] The corresponding verification script is defined as:

[0118] [STI verify]:= <g>OP_CHECKSIGVERIFY.

[0119] Therefore, <τ tx >[STI verify] Accept τ tx as a valid commitment tag for the spend transaction, or reject it and abort any subsequent logic execution.

[0120] It should be noted that what is passed as input to the ECDSA signature algorithm is the SIGHASH serialization of the spend transaction tx. Depending on the SIGHASH bytes, some fields of tx will not be signed, so their integrity cannot be guaranteed.

[0121] 6. Enforce constraints

[0122] This section describes embodiments of the present disclosure that enable enforcing constraints on spending transactions. Figure 3 An exemplary system 300 for implementing these embodiments is shown. The exemplary system 300 includes a first party, a second party, and one or more blockchain nodes 104 of a blockchain network 10. In this example, the first party is shown as Alice 103a and the second party is shown as Bob 103b. It should be understood that this is for convenience only.

[0123] Alice 103a is configured to generate a first transaction, wherein the first transaction includes a first output, the first output including a first locking script. The first locking script includes logic for enforcing a condition on a second transaction generated by Bob 103b, wherein the second transaction includes a first input, the first input including a first unlocking script. The first input of the second transaction references the first output of the first transaction. It should be noted that "first", "second", etc. are used only as labels and do not necessarily mean that the first output is the initial, logically first output of the transaction, although this is possible.

[0124] The first locking script (also referred to as the enforcement locking script) includes a first subscript (also referred to as the commitment subscript) and a second subscript (also referred to as the constraint subscript). The commitment subscript may include a commitment key for verifying the transaction commitment. The constraint subscript includes a verification key for verifying the constraint proof. The transaction commitment and constraint proof are generated by Bob 103b and provided in the unlocking script of the second (spending) transaction for unlocking the enforcement locking script. It should be noted that Alice 103a can generate the enforcement locking script on her own or receive the enforcement locking script from a third party.

[0125] The transaction commitment generated by Bob 103b is a commitment to a second transaction. The commitment is generated based on the second transaction. The commitment sub-script is configured to verify whether the transaction commitment has been generated based on the second transaction. In some examples, the transaction commitment is verified using a commitment key. The commitment key can be a public key, and the transaction commitment can be a digital signature generated using a private key corresponding to the public key. In some examples, the private key is an integer 1. A signature generated using a private key set equal to 1 is referred to herein as a "virtual signature."

[0126] The commitment sub-script can provide the transaction commitment to the constraint sub-script after verifying that the transaction commitment is indeed generated based on the second transaction. The constraint sub-script can then use the transaction commitment as part of the input verification of its constraint proof.

[0127] The constraint proof generated by Bob 103b verifiably proves that the second (committed) transaction satisfies one or more constraints. These constraints may be hard-coded by the constraint sub-script. The constraint sub-script is configured to use the verification key to verify whether the constraint proof indeed proves that the constraints have been satisfied. In some examples, these constraints may be hard-coded by public inputs (i.e., inputs that appear in the locking script and are pushed to the stack during execution). It is also not excluded that the public inputs may be included in the unlocking script of the second transaction. In these examples, the constraint sub-script may use the public inputs to verify whether the constraint proof proves that the second transaction satisfies the constraints.

[0128] In some examples, the verification key has a corresponding evaluation key, and Bob 103b uses the evaluation key to generate the constraint proof. In these examples, the constraint subscript can use the verification key to verify whether the constraint proof has been generated using the evaluation key. Alice 103a can send the evaluation key to Bob 103b.

[0129] The proof and verification of the proof may use a non-interactive zero-knowledge verification algorithm, also known as a SNARK. Any suitable SNARK may be used. The constraint proof may be generated using a SNARK's proof algorithm. The proof may be verified using a SNARK's verification algorithm. Thus, in these examples, the constraint subscript is configured to implement a SNARK's verification algorithm. Bob 103b, for example, uses an evaluation key to execute the proof algorithm off-chain.

[0130] Typically, the constraints enforced by the locking script may impose restrictions on one or more inputs of the second transaction and / or one or more outputs of the second transaction. This may include imposing restrictions on the number of inputs and / or outputs, the form of the inputs and / or outputs, and / or the content of the inputs and / or outputs.

[0131] For example, the second transaction may need to have an output that includes part or all of the enforcement locking script. The output of the second transaction may need to include an exact copy of the enforcement locking script. Alternatively, at least part of the enforcement locking script may be ignored or exchanged with alternative data. For example, the enforcement locking script may include one or more variables (e.g., a public key and / or a public key hash) that may be replaced with alternative variables of the same type. For example, a public key may be exchanged with a different public key.

[0132] As another example, one of the enforced constraints may be that the second transaction has an input that references a particular output of a particular previous transaction or any output of a particular previous transaction. Additionally or alternatively, one of the enforced constraints may be that the second transaction links back to a particular previous transaction through one or more previous transactions. In other words, the second transaction must belong to a chain of transactions with a predetermined ancestor. In the context of tokens, the second transaction may need to link back to a token minting or token issuance transaction that includes token metadata that defines a token (e.g., an NFT).

[0133] In some examples, a token issuance transaction includes token metadata for the first time. The first transaction may be a token minting transaction that enforces the conditions of the token agreement by enforcing a locking script and transfers ownership of the token to a specific party (e.g., Alice 103a or Bob 103b). The second transaction may be a token transfer transaction that transfers ownership of the token to another party (e.g., Bob 103b). Alternatively, the first transaction may be a token transfer transaction that links back to a token minting transaction.

[0134] Enforcing the locking script may include a transfer sub-script. The transfer sub-script may be locked to a public key or a public key hash and require that the unlocking script of the second transaction include a signature corresponding to the public key. For example, the transfer sub-script may include a pay-to-public-key (P2PK) script or a pay-to-public-key-hash (P2PKH) script. In the context of a token, the public key may be associated with the new recipient (owner) of the token (e.g., Bob 103b). In this case, Bob 103b may generate a signature based on the second transaction using the private key corresponding to his public key and include the signature in the unlocking script of the second transaction.

[0135] In some examples, the second transaction includes an output locked to a specific public key (e.g., a public key associated with Alice 103a or Bob 103b). In the context of tokens, this can be used to promote fair transactions, ensuring that Alice 103a is paid for transferring tokens to Bob 103b5.2.

[0136] Similarly, a second transaction may need to include an output that is locked to the same public key that the output referenced by the second transaction's input is locked to. In other words, the second transaction has an input that references a previous output, where that previous output is locked to a public key. The output of the second transaction must be locked to the same public key. In the context of tokens, this can be used to ensure that tokens cannot be burned.

[0137] In some examples, the second transaction may need to include locking a predetermined amount or percentage of the output of the native blockchain token (i.e., the underlying digital asset of the blockchain, such as BSV). For example, the second transaction may include locking a first amount (e.g., locked to a public key controlled by Bob 103b). The second transaction may need to include locking a second amount of output, which is a predetermined amount or a predetermined percentage of the first amount. The second amount may be locked to a public key controlled by Alice 103a or a different party. In this example, the public key to which the second amount is locked can be fixed by enforcing a locking script so that each future spending transaction locks a certain amount of digital assets to a fixed public key. In the context of tokens, this can be used to enforce royalties paid to the token issuer. As discussed in the following sections, embodiments of the present disclosure can be used to issue a series of tokens, including limited edition tokens and non-burnable tokens.

[0138] 7. Simple enforcement of constraints — REFTX mechanism

[0139] This section describes an exemplary implementation of the embodiments described in Section 7 above.

[0140] 7.1 Constraints as NP predicates

[0141] Let P be a program (constraint) that proves correct execution on public input (stx,y) and private input w. Here, stx represents a spending transaction. The predicate to be proved is as follows:

[0142] predicate

[0143] "Let public string y be a string, and I know witness w, so that the procedure P((y,stx);w)=1, where stx is a spending transaction"

[0144] The predicate Always with respect to the spend transaction stx, not with any arbitrary (possibly off-chain) transaction.

[0145] General predicate This can be done in a number of ways. For example (informal):

[0146] A program P with an explicit public string y consists of:

[0147] "The string y is the field "Field" of the spend transaction stx".

[0148] In addition, the spending transaction can be replaced by its ith ancestor, i.e., "Let y := (y′, i), where string y′ is the field "Field" of the ith ancestor spending transaction stx".

[0149] Or more complex statements, such as "Let string y := (y1, y2), spending transaction stx has two outputs, the locking script of the first output is P2PK with public key y1, and the locking script of the second output contains y2 as op-return data"

[0150] Programs with an empty public string y include:

[0151] "Spending transaction stx has three outputs"

[0152] "The locking script of the first output of the spending transaction stx is the same as the locking script of the transaction referenced in the first output point of the spending transaction stx".

[0153] 7.2 Proving predicates concisely

[0154] As currently defined, the above predicate The spending transaction stx is defined as part of its public input (parameterized using a program P). This means that the on-chain SNARK verifier also takes stx as an input, so it must be on the stack (not succinct). Another problem is that we need to ensure that a transaction tx (where P((y,tx);w)=1) is a spending transaction stx, and not some other transaction.

[0155] The SNARK scheme aims to prove the correct execution of an augmented program that treats transactions as private inputs (which solves the first problem) and the STI commitment tag τ as public input (which is sufficient to solve the second problem).

[0156] Enhancement Program

[0157] 1. Check Gadgets STI (τ;(tx,w STI ))=1

[0158] 2. Check P((y,tx);w P )=1

[0159] 3. If both checks pass, output 1. Otherwise, output 0.

[0160] Gadget STI (τ;(tx,w STI )) allows checking the zero-knowledge correct generation of the STI commitment algorithm. It takes the label τ as a public input and the transaction tx along with an additional value w STI As private input, such as:

[0161] If and only if STI.commit(tx) = τ, Gadget STI (τ;(tx,w STI ))=1.

[0162] Enhancement Program is a wrapper around a basic program P. Therefore, given P, its enhancement It is also known.

[0163] 7.3 Verification Script

[0164] Used to verify whether the spending transaction stx actually satisfies the predicate The script [enforce constraintP] (also called REFTX script) is defined as follows:

[0165]

[0166] The REFTX script is an example of an enforcement locking script as described in Section 6. The STI verification script is an example of the commitment subscript described above. is an example of the constraint subscript above.

[0167] here, is a valid proof that proves the following statement "I know the string w and the transaction tx such that As defined, the script includes OP_VERIFY to mark the transaction as invalid in the event that the STI script fails on the input tag τ or the SNARK verification script fails.

[0168] It should be remembered that the description of the verification algorithm SNARK.verify (with the corresponding script [SNARKverify]) for the preprocessing SNARK has nothing to do with the program being verified. In fact, it is only when the corresponding verification key is entered into the verifier that it is known that P is being verified. In order to ensure that the program It has been verified, yes Authentication key is hard-coded. Therefore, the above REFTX script includes:

[0169]

[0170] This is like hard-coding the public key in the P2PK script to ensure that funds are sent to the correct address.

[0171] If y is empty, the REFTX script does not cascade with OP_CAT (since the common input of program P is just the tag τ).

[0172] If the logical cost required to prove on y in zero - knowledge is high, it can be executed in the script. For example, hashing the transaction field y in the script (using a single opcode) is faster than hashing it off - chain in zero - knowledge, because this forces the prover to use an expensive gadget (for hashing). The prover will only need to prove in zero - knowledge that y is indeed part of the transaction.

[0173] Verification script and proof do not depend on the size of the witnessed transaction (or only logarithmically). Additionally, the succinct property of the STI mechanism can ensure that the description of τ and its verification script [STI verify] is also independent of the spent transaction stx. Combining these two observations, it can be seen that the size of [enforce constraint P] is independent of the size of the spent transaction stx.

[0174] 7.4 REFTX with Virtual Signature

[0175] When the virtual signature technique described in Section 5.1.2 is used as the STI mechanism, the REFTX script is transformed into:

[0176] where G := (x, y) is the base point and the virtual signature τ of the Bitcoin curve secp256k1 (with base field and order n < p). It should be noted that the overhead of the STI mechanism in the script is only 66 bytes (hard - coded base point plus two opcodes).

[0177] When the STI commitment algorithm is set to virtual signature, the gadget in the enhanced program STI uses a virtual key to generate an ECDSA signature, just as done in the Bitcoin protocol.

[0178] Enhanced program is more complex than program P because it includes the STI gadget (which checks whether the STI tag is correctly generated). For the case of virtual signature, this cost mainly depends on checking the correct SHA256 hash.

[0179] If the script [enforce constraintP] outputs 1 to the top of the stack on input vk, y, τ, then it can be guaranteed that the predicate is true (very likely). It should be remembered that It's always about spending transactions stx.

[0180] 8. Transactions verified by miners

[0181] This section describes embodiments of the present disclosure that can be used to implement a miner-verified token protocol using the techniques described in Sections 6 and 7 above.

[0182] First, the non-fungible token (NFT) scheme is defined as a triple algorithm:

[0183]

[0184] Some previous NFT schemes have the problem of relying on off-chain verification, and malicious users can destroy the ownership chain by not complying with the transaction format. If the verification task is moved to miners (i.e., blockchain nodes 104), this problem can be prevented.

[0185] The REFTX mechanism allows for miner verification without introducing any transaction bloat.

[0186] 8.1 Transfer and Token Verification

[0187] AlgorithmValidateTransfer

[0188] The algorithm is implemented in script form and executed as part of the normal verification of a transaction.

[0189] The ownership of token tk is transferred from sender S to receiver R via transaction tx S→R Published to the blockchain for verification. The first output of the transaction is locked using the following script:

[0190] [validate transfer of tk to PK R ]:=[P2PK PK R ][enforce constraintP NFT ]

[0191] The P2PK portion of the script guarantees that the token is controlled by the recipient R. The rest of the script is the REFTX mechanism described above and enforces correct execution of the NFT program P. NFT To ensure transaction tx S→R Link to the issuance transaction tx0. An example procedure is provided below.

[0192] AlgorithmTransferOwnerShip

[0193] In order to transfer token tk, sender S must prove transaction tx S→R Link to the issuing transaction.

[0194] Off-chain steps:

[0195] 1) The sender correctly generates the transaction tx S→R :The sender creates tx S→R , whose first output uses the script [validatetransfer of tk to PK R ] to lock.

[0196] The sender generates the unlocking script as follows:

[0197] 2) Use and PK S The corresponding signing key signs the transaction. This produces a signature σ S .

[0198] 3) Generate tx S→R (sighash) of the STI tag τ.

[0199] 4) Use the evaluation key (created when casting) To generate the program Proof of the satisfiability of the common input π for the above STI label τ NFT .

[0200] 5) Signature σ S , explicit public input y, STI label τ and proof π NFT Embed tx S→R The first input of the unlocking script.

[0201] Figure 4 An exemplary transaction for transferring ownership of token tk is shown.

[0202] 8.2 Optimized scripts for transfer verification

[0203] By using virtual signatures as the STI mechanism, the constraint enforcement subroutines of the P2PK script and the transfer verification script can be combined into a single subscript. R , instead of a virtual public key.

[0204] The following script stores some opcodes related to the opcodes in the previous section:

[0205]

[0206] 8.3 Example NFT Program

[0207] This section describes two example NFT programs.

[0208] 8.3.1 Procedure 1

[0209] Consider the following (informally) program P NFT :

[0210] "Given transaction tx as input, its first output references the issuing transaction tx0, or references the on-chain non-Coinbase transaction parent_tx for which this statement is true."

[0211] It should be noted that the statement is recursive: if P NFT If an input transaction does not spend the issuing transaction, then its parent transaction or one of its ancestors must spend the issuing transaction. This ensures that the chain of ownership is respected.

[0212] The issuer uses the issuance transaction identifier txid0 to indicate the following enhancements: Generate evaluation key for recursive SNARK and verification key

[0213] Enhancement Program

[0214] Common input: τ tx ,y:=h vk := hash(vk) / / Hash of transaction tag and verification key.

[0215] Private input: tx,w STI ,w P :=(vk,parent_tx,parent_txid,τ parent_tx ,π) code:

[0216] 1. Check Gadgets STI (τ tx ;(tx,w STI ))=1

[0217] 2. Check Program P NFT Is it output as follows: / / Use w P

[0218] a. Check parent_txid = SHA256d(parent_tx)

[0219] b. Check if the first output point of tx is parent_txid||0

[0220] c. If parent_txid ≠ txid0 (the issuance ID is hardcoded), then do the following:

[0221] i. Check STI.commit(parent_tx) = τ parent_tx

[0222] ii. Check SNARK.verify((vk,τ parent_tx ),π)=1

[0223] iii. Check h vk =Hash(vk)

[0224] 3. If the above two steps pass, output 1. Otherwise, output 0.

[0225] The procedure described in step 2 NFT The ID txid0 of the issuing transaction (already on-chain) is hardcoded in its description. The reason for passing the verification key vk as a witness and its hash as a public input is a technical detail inherited from recursive SNARKs: the size of any program's verification key is strictly larger than the size of its public input. Therefore, a program's verification key cannot be part of the program's public input. This is usually solved by passing its (constant-size) hash, and relying on collision resistance to ensure that the correct key is used to verify the proof internally. The hash used can be a zero-knowledge friendly algorithm. The basic program P NFT Check the STI tag of the parent transaction τ parent_tx is correct (step 2.ci). This is necessary because the proof will be parent_tx , so you need to make sure that the script is actually validating the enhancements of the parent transaction. Rather than an enhancement of other transactions. The latter is guaranteed by the binding properties of the STI mechanism.

[0226] 8.3.2 Procedure 2

[0227] Alternatively, the script can prove the following statement P′ about the spending transaction NFT :

[0228] "Given transaction tx as input, its first output point references the issuing transaction tx0, or references the on-chain non-Coinbase transaction parent_tx, the first output of which is locked with the same script as the first output of tx, and the script is [P2PK PK R ][enforce constraintP′ NFT ].

[0229] P′ NFT The definition includes a REFTX script that references the statement itself [enforce constraintP′ NFT ]. There is no loop problem here, and the statement is well defined. The reason is that only the "template" of the script is checked, not the variables. (In fact, the statement P′ NFT It does not mean that the verification key vk must be a specific verification key). More specifically, the only place where the loop problem can occur is in the script of the SNARK verifier SNARK.verify. However, for a fixed SNARK scheme, the exact steps of the verification algorithm are known, and therefore the exact opcodes are also known.

[0230] snark_opcodes:={SNARK.Verify opcode} describing such an algorithm is known, and this is what is checked. It should be remembered that the pre-processing SNARK verifier uses different verification keys to check one or the other program.

[0231] The (enhancement) procedure is defined as follows.

[0232] Enhancement Program

[0233] Common input: τ tx / / Transaction tag

[0234] Private input: tx,w STI ,w P :=(parent_tx,parent_txid)

[0235] Code:

[0236] 1. Check Gadgets STI (τ tx ;(tx,w STI ))=1

[0237] 2. Checking procedure P′ NFT Does it output 1 as follows:

[0238] a. Check parent_txid = SHA256d(parent_tx)

[0239] b. Check if the first output point of tx is parent_txid||0

[0240] c. If parent_txid ≠ txid0 (the issuance ID is hardcoded), then do the following:

[0241] i. Check that the locking scripts of the first output of tx and parent_tx are equal and correspond to [P2PKPK R ][enforce constraintP′ NFT ](Hard-coded variable PK R ). It should be noted that this includes checking for equality of hard-coded authentication keys in both scripts.

[0242] 3. If the above two steps pass, output 1. Otherwise, output 0.

[0243] The difference from the first procedure is that the prover is more efficient. The task of verifying the user's previous transfer is delegated to the miner. The resulting procedure Than previous procedures The proofs are more efficient, mainly because the SNARK verification gadget (which is expensive to simulate in zero-knowledge) is replaced with byte comparisons. In addition, since recursion is no longer required, the verification key is no longer an input to the program, and the parameters of the SNARK scheme are lighter (for the same security level) than those used when recursion was required. The lighter parameters are the main source of efficiency.

[0244] 8.4 Casting

[0245] The minting mechanism described in this section transforms the scheme in Section 8.1 into a true atomic swap (a transaction between two parties without involving a third party). Although the issuer is still required to guarantee the authenticity of the token, the issuer can be eliminated when trading tokens between two users.

[0246] Step 1 - Issue Transaction

[0247] The original owner (issuer) creates an issuance transaction tx0, with the (non-fungible) token tk embedded as OP_RETURN data. He then uploads tx0 to the blockchain as a regular P2PK transaction, which "sends" the token to a public key PK under his control. Issuer .

[0248] Step 2 — Generate keys for the NFT program

[0249] The issuer uses the issuance transaction identifier txid0 to facilitate the enhancement procedure outlined in Section 8.3. An enhanced procedure in generates the evaluation key ek and verification key vk of the SNARK.

[0250] Step 3 — Generate a minting transaction tx →Issuer

[0251] Issuer uses script [STI verify] and To generate the verification script [enforce constraintP NFT ]. Then, the publisher issues:

[0252] ·With the program Corresponding evaluation key ek and verification key vk.

[0253] Validation scripts.

[0254] This is done through transaction tx →Issuer The token is sent to the public key PK controlled by the issuer. I After the transaction is confirmed in the blockchain, the minting process is complete and the token can be traded. In this example, the issuer provides funds for the issuance and minting transactions.

[0255] Figure 5 An example transaction for minting tokens is shown.

[0256] If you use the program Then when transferring tokens from the issuer to the first recipient, the issuer will need proof to verify the minting transaction tx →Issuer It is the parent transaction of the issuing transaction tx0". He can generate the proof himself and provide it to the program The prover of .

[0257] How can the receiver R be sure that he owns the token tk? One possibility is that R traces the transaction txS→R directly to the issuing transaction tx0 or the minting transaction tx →Issuer Alternatively, a trusted party could authenticate the origin, but this does not make transactions atomic. This section describes alternative mechanisms that avoid either of these possibilities.

[0258] tk is implicitly present in every transaction txS→R because it is added via the enhancement procedure The verification key vk is hardcoded in [enforce constraintPNFE]. Here, Denotes any of the programs described in Section 8.3.

[0259] Transaction txS→R must be linked to tx0, given that (i) πNFT is verified (ensured by miners given txS→R appears on-chain), and (ii) the verification key vk is the correct verification key, that is, the key vk generated by the issuer during the minting process.

[0260] The receiver R performs the following two checks after confirming txS→R in the blockchain.

[0261] 1) He checks the well-formedness of the script [validate transfertktoPKR] embedded in txS→R. He can do this because the opcodes that form [P2PKPKR] and [enforce constraintP] are well known.

[0262] 2) He checks that his public key PKR and the correct verification key vk are embedded in the script. The correct verification key is the one that appears in the minting transaction tx →Issuser The verification key in. Users can use the issuer's public PKI to identify minted transactions.

[0263] If the check passes, he can proceed to pay the sender the token fee.

[0264] This implementation of the minting process allows the recipient R to obtain only two transactions from the blockchain: the last txS →R and the first tx →Issuer (minting transaction), not the entire chain.

[0265] Token authenticity is given by the issuer’s public key PKI embedded in the minting transaction.

[0266] 8.5 Completely Fair Transactions

[0267] This section describes how to replace the algorithm TransferOwnerShip with an interactive process that is fair to both parties, SwapOwnershipByBitcoins. In this process, both parties agree on the value of the token relative to the native blockchain token (e.g., Bitcoin). Then, a transaction with two outputs is created.

[0268] First output: The locking script [validatetransfertktoPKR] of the output tsS→R from the previous section.

[0269] Second output: P2PK output, where the agreed amount of digital assets is locked by the sender’s public key PKS.

[0270] The steps of SwapOwnershipByBitcoins are as follows:

[0271] 1. Sender S creates a transaction (It does not have input yet) and sends it to the recipient R through an off-chain channel. (This channel does not need to be confidential or authenticated.)

[0272] 2. The receiver R performs the checks explained in Section 8.5. If satisfied, he adds the inputs to fund the transaction and signs the transaction using the corresponding Bitcoin signing key. To sign, he uses the flags SIGHASH_ALL|ANYONECANPAY to include all outputs (specifically, the first output that transfers tokens to him) in the message signature. He then sends the funded signed transaction to the sender.

[0273] 3. The sender checks if the output point included by the receiver is valid and has sufficient funds. If so, he generates the unlocking script of the first output point (σ S ,τ,π NFT ) to transfer the token tk to the recipient. (As explained in steps (2) to (5) of the algorithm TransferOwnerShip described in Section 8.1.)

[0274] Figure 6 An example transaction for implementing a fair transaction is shown. Tokens are traded in 9 units of the native blockchain digital asset. There may be many funding transactions that can provide funds from different public keys / addresses.

[0275] 8.6 Royalties

[0276] The issuer may require that a royalty be paid to him every time a token is traded. This can be a fixed amount or a percentage of the NFT transaction amount. NFTroyalty Trading Affairs Whether it has at least two outputs. The second output (new) transfers units of the underlying digital asset to the public key PK controlled by the issuer Issuer , which is hard-coded in the program itself.

[0277] NFT transactions can be completely fair exchanges (See Section 8.5) or unilateral exchange Figure 7 An example of a NFT transaction where the royalties are

[0278] Next, P NFT It can be any procedure for NFT. For example, the procedure described in Section 8.3 can be adopted. The issuer can enhance the procedure during the minting process. Generate an evaluation key / verification key.

[0279] Program P NFTroyalty :

[0280] Public input: at least NFT transaction stx (i.e., tx S→R or ).

[0281] Private input: w P .

[0282] Code:

[0283] 1. Inspection Does it have three outputs?

[0284] 2. Check Program P NFT Whether to output 1 / / use w P

[0285] 3. If parent_txid≠txid0, check the following

[0286] a. Check if the value of the first output is a constant fraction of the value of the second output. (Or, check if it is at least a constant value.)

[0287] b. Check if the third output has PK Issuer P2PK to lock.

[0288] 4. If the above check passes, output 1. Otherwise, output 0

[0289] 8.7 Limited Edition

[0290] This section describes NFTs used to trade copies of the same token. The number N of copies of a given token tk is finite, and its specific value (the scarcity of the token) is configured by the issuer.

[0291] Copies can be exact copies, for example, an artist can mint N copies of the same digital artwork and sell them individually. Or, copies can be bundled together, but each copy is slightly different, like a ticket to a concert with numbered seats. The value of a copy will depend on its type. In the case of a concert ticket, seats closer to the stage may be more valuable.

[0292] A copy of a token tk is defined as a triple

[0293] tk (i) :=(tk,i,replica_specific_field).

[0294] The first field indicates the token they are replicating. The second field is a sequence number (counter). The third field can be used to fill in any replica specific information needed (can be empty).

[0295] In some examples, the issuer can simply mint N copies of the token in parallel (as per Section 0). However, this means that each copy will have a different verification key, making transactions cumbersome (the user will need to know many keys, and should somehow know which key to use to trade the i-th copy). This section shows how a single verification key can be used to control all copies.

[0296] Step 1 - Issue Transaction

[0297] The issuer creates N different issuance transactions The i-th issuance transaction Contains the i-th replica tk embedded as OP_RETURN data (i) .

[0298] Step 2 - Generate Keys for the NFT Program

[0299] Then, he collects the identifiers in the Merkle tree and sets rt tk to be the root of the tree. For simplicity, for some n, assume N = 2 n . (If N is not a power of 2, the issuer uses dummy data to fill the last leaves of the tree to obtain N' = 2 n > N leaves. Here, n is such that n - 1 < log2(N) < n.)

[0300] Program P NFTwithReplicas manages the transactions of the token copies. The program checks whether the first output point of the NFT transaction tx (tx := tx S→R or ) references the transaction tx_parent whose ID belongs to the token tree . The program also forces the same serial number i of the copy to be embedded in the unlocking scripts of tx and tx_parent. These are the only two differences with respect to programs P NFT , P' NFT from Section 8.3.

[0301] Algorithm checks the membership of the Merkle tree. The circuit for checking whether an element txid belongs to the tree is well-known. It requires four inputs: the claimed leaf txid, the leaf index i (the serial number of the copy), the Merkle proof (the authentication path) and the root rt tk of the tree. Then, it uses this information to recompute the root as rt' tk , and outputs 1 if and only if rt tk = rt' tk .

[0302] Authentication Path is formed by the sibling leaves (the leaves are indexed from 0 to N - 1, and if i is odd, the sibling leaf is the (i - 1)-th leaf, otherwise the (i + 1)-th leaf) and all the intermediate hashes H j 1 ≤ j < n required to traverse the tree from bottom to top. The algorithm iteratively hash-processes the sibling leaves and the intermediate hashes to recompute the root rt' tk . To determine the position of the input to the hash at the j-th iteration, the j-th bit of the index i can be used.

[0303] Enhanced Program

[0304] Common Input: τ tx

[0305] Private Input:

[0306] Code:

[0307] 1. Check Gadgets STI (τ tx ;(tx,w STI ))=1

[0308] 2. Checking procedure P′ NFTwithReplicas Does it output 1 as follows:

[0309] a. Check parent_txid = SHA256d(parent_tx)

[0310] b. Check if the first output point of tx is parent_txid||0

[0311] c. Check whether i tx =i parent_tx , and i tx 、i parent_tx Embedded in the unlocking scripts of tx and tx_parent respectively.

[0312] d. If (The parent is not a copy - root rt tk is hardcoded), then do the following:

[0313] i. Check that the locking scripts of the first output of tx and parent_tx are equal and correspond to [P2PKPK R ][enforce constraintP′ NFT ](Hard-coded variable PK R ). It should be noted that this includes checking for equality of hard-coded verification keys in both scripts.

[0314] 3. If the above two steps pass, output 1. Otherwise, output 0.

[0315] Any suitable hash function can be used to generate the token tree

[0316] Step 3 — Generate a Minting Transaction

[0317] Then, the issuer generates a validation script [enforce constraint P NFTwithReplicas ] and create N casting transactions Each minting transaction costs one issuance transaction out of the issuance transactions. After all transactions are confirmed in the blockchain, the N copies of the token can be traded individually. To trade the i-th copy, a normal user buys start.

[0318] Figure 8 An example transaction for minting two copies is shown. The root of the token tree is hardcoded in the NFT program that verifies the transfer.

[0319] 8.7.1 Reprint

[0320] Copies minted together are considered to belong to a specific version. Issuers may also mint new versions over time. To order between versions, the token tree of version j contains the root of the j-1 token tree as the first leaf (an empty leaf in the first version). Fig. 9 The process is shown.

[0321] Detects false re-publications because honestly generated minted transactions always use the issuer’s public key PK in all versions I Only the publisher can initiate a transaction each time a reprint is published.

[0322] 8.8 Auction-friendly NFTs

[0323] This section describes the design of an NFT, for which buyers bid after minting. After the auction is over, the issuer transfers the token to the buyer with the higher bid. From then on, transfers between ordinary users are just atomic swaps, as already explained.

[0324] The interaction between the buyer and the issuer occurs offline in a manner similar to a fully atomic swap.

[0325] 8.8.1 Bid

[0326] Buyer T generates an NFT transaction funded by his bid He sends this transaction to the issuer. To generate this transaction, the buyer uses the ID txid0 of the issuance transaction tx0 that is already on the chain.

[0327] 8.8.2 Selecting the Winner

[0328] The issuer looks at the list of all bids received and chooses the winner (usually the higher bidder). If he is satisfied with the transaction (i.e. The underlying funding transaction has sufficient funds), he will transfer the token to the Winner.

[0329] once Appear on the chain, other transactions It becomes invalid for R≠Winner, so the funds of everyone whose bid was not selected remain unspent.

[0330] 8.8.3 Threshold Price Verified by Miners

[0331] The issuer can set a price below which no bids may be made. For example, a price can be set that is at least as high as required to fund the issuance transaction tx0. This will vary depending on the token.

[0332] The issuer can delegate to miners to check whether the funding transaction behind the bid is correct by incorporating such checks into the NFT program enforced using SNARKs. Thus, if the first output point references the issuance transaction, the program also checks that the NFT transaction is the value of the second output of is above some threshold price given as input.

[0333] Program R NFTauction :

[0334] Public inputs: at least NFT transactions and the starting price threshold_price.

[0335] Private input: w P .

[0336] Code:

[0337] 1. Check Program P NFT Whether to output 1 / / use w P .

[0338] 2. If parent_txid = txid0 (issue ID is hard-coded), check if the value of the second output is equal to or greater than threshold_price.

[0339] 3. If the above two steps pass, output 1. Otherwise, output 0.

[0340] As in the previous section, P NFT Since the threshold price is passed as a public input, it will become part of the unlocking script and can therefore be forced to be greater than a specific per-use case fixed value via the opcode OP_GREATERTHANOREQUAL and hard-coded in the locking script.

[0341] Another option is to use the program P auction The threshold price is hard-coded in the .

[0342] 8.9 Non-burnable tokens

[0343] The NFT described in Section 8.1 allows tokens to be transferred to meaningless outputs. For example, the current owner S can set up a tx locked with OP_0OP_RETURN S→R The first output, which interrupts the program P NFT This means that tokens traded using such schemes may be burned, which may not be desirable in some cases.

[0344] To prevent explicit token burning, the NFT procedure P′ described in Section 8.3 is used NFT The second instantiation of . Since P′ NFT It is also checked that the first output of the spending transaction is also locked with the same script, and the verification key is the same, so the strategy discussed in the previous paragraph is not possible with this scheme. However, a token can only be burned by sending it to a public key, for which it is generally believed that no one has the signing key.

[0345] Informally explain the disclosed procedure P unburntNFT In addition to checking P′ NFT In addition to outputting 1 (see Section 8.3), the program also ensures that the recipient actually knows the signing key. The program checks whether the transaction uses The procedure also enforces the use of a P2PK to lock the first output of the transaction that provides funds, whose public key matches the public key PK to which the token is sent. R Matching. The ability to unlock such UTXO guarantees that the recipient knows the signing key. Therefore, tokens cannot be burned in transactions. Fig.10 An example transaction for generating a non-burnable token is shown.

[0346] 9. Completely fair trade

[0347] This section describes embodiments of the present disclosure that enable atomic (completely fair) token transactions. These embodiments can be implemented independently of or in conjunction with the embodiments described in Sections 6 to 8 above. In other words, a token protocol may or may not use the above-described enforced locking scripts or the above-described REFTX technique. In at least some examples, an enforced locking script (e.g., a locking script described as part of the REFTX technique) can be used to lock at least one output (e.g., an output containing token data) of each token transaction. However, more generally, a protocol for implementing completely fair transactions can be used with any token protocol.

[0348] These embodiments will refer to Figure 3 103a plays the role of the sender and Bob 103b plays the role of the receiver. Here, the "sending" and "receiving" are from the perspective of the token, that is, Alice 103a is sending a token to Bob 103b. Figure 3 In FIG. 1 , Tx1 is a first token transaction used to transfer a token to Bob 103b. Tx2 may be a second token transaction used by Bob 103b to transfer to a different party.

[0349] Figure 3 Token issuance transactions are not shown in the figure. Token issuance transactions are created by a token issuer and submitted to the blockchain network 106. In some examples, Alice 103a can play the role of a token issuer. The token issuance transaction issues a token for the first time and contains relevant token data. The token data can define the rules of the token, the tokens that can be used and / or redeemed, etc. The token can be a non-fungible token.

[0350] Alice 103a first creates a first token transaction. Here, "first" is used only as a label and does not necessarily imply that it is a first token transaction (i.e., a first token transaction that transfers tokens from a token issuance transaction), although this is an option. The first token transaction includes an input that references an output of the token issuance transaction or an output of a token transaction that links back to the token issuance transaction. That is, a chain of one or more token transactions starting with the token issuance transaction may be recorded on the blockchain, where each subsequent token transaction in the chain references a previous token transaction in the chain. The first token transaction also includes an output locked to Bob's public key ("first output") and an output locked to Alice's public key ("second output"). The first output includes token data (e.g., the same token data as the token issuance transaction).

[0351] Alice 103a sends a first token transaction to Bob 103b. Bob 103b verifies that the inputs of the first token transaction link back to the token issuance transaction. That is, the inputs reference outputs of the token issuance transaction, or reference outputs of a transaction that is part of a chain of token transactions starting with the token issuance transaction. In the case where the referenced output is a subsequent transaction in the chain, Bob 103b can trace back along the entire chain of transactions to the token issuance transaction. Other techniques may also be used, such as a constraint proof (contained in the referenced transaction or the first token transaction) that verifies that the referenced transaction is linked back to the token issuance transaction. Bob 103b also verifies that the first output is at least partially locked to his public key (the first output may be locked to another public key and / or locked by one or more additional constraints).

[0352] After verifying that the inputs of the first token transaction are linked to the token issuance transaction and that the first output is locked to his public key, Bob 103b funds the first token transaction. That is, Bob 103b adds one or more corresponding inputs to the first token transaction, which reference corresponding unspent transaction outputs controlled by Bob 103b (e.g., locked to Bob's public key). Bob 103b includes in the corresponding inputs the corresponding data required to unlock the corresponding unspent transaction outputs. Typically, this will include a digital signature generated using a corresponding private key that corresponds to the corresponding public key used to lock the corresponding output. A transaction that includes Bob's inputs is called a funded token transaction.

[0353] Bob 103b sends a funded token transaction to Alice 103a. Alice 103a verifies that the output locked to her public key controls the agreed-upon amount of digital assets (e.g., Satoshi). Alice 103a may also verify that the corresponding transaction or transactions referenced by one or more corresponding inputs of Bob (i.e., the inputs added by Bob 103b) are on the blockchain 150. Alice 103a may also verify that the referenced output is unspent. It should be noted that she does not necessarily need to do this, as if the output is unspent, the transaction will not be accepted on the blockchain 150.

[0354] After verifying that the referenced transaction is on-chain, Alice 103a signs the funded transaction. That is, she includes a signature in the first input of the funded token transaction that references the issuing token transaction or a transaction in the chain of transactions linked to the token issuing transaction. Since only Alice 103a can generate this signature, the token transaction can only be submitted to the blockchain 150 after Alice 103a is satisfied that all checks have been completed. Alice 103a can send the signed token transaction to the blockchain network 106 on her own, or through a different party (such as Bob 103b). Later, Bob 103b can perform the equivalent actions of Alice 103a to transfer the token to another party (e.g., Charlie). That is, Bob 103b can generate a second token transaction with an input that references the output of the token transaction locked to Bob's public key, and perform the same interactive protocol described above with Charlie.

[0355] As described above, the tokens of the transaction can be part of a protocol that uses the above-described enforcement locking script. That is, the input of the first token transaction can reference an output that is locked using the enforcement locking script. In this case, Alice 103a generates a transaction commitment and constraint proof, and includes the commitment and proof in the unlocking script of the input of the first token transaction in order to unlock the referenced output. The process of generating a transaction commitment and constraint proof has been described above. The commitment and proof can be included in the input at any suitable point in time (e.g., before sending the first token transaction to Bob 103b, or after receiving the funded token transaction from Bob 103b and before signing the funded token transaction).

[0356] Similarly, the output of the first token transaction locked to Bob's public key can be locked using an enforced locking script. This requires Bob 103b to generate a transaction commitment and constraint proof when trading tokens with Charlie.

[0357] In some examples, Bob 103a may verify that an enforcement locking script that forms part of an output referenced by an input of the first token transaction includes a particular verification key (eg, a verification key included in the issuance transaction).

[0358] In some examples, the enforcement locking script of the referenced transaction may include the REFTX script described above, such as [validate transfer of tk to PK S ], where PK S is Alice’s public key (i.e., the sender’s public key). Similarly, the enforcement locking script of the first token transaction may include a REFTX script, such as [validate transfer oftk to PK R ], where PK R is Bob's public key (i.e., the recipient's public key).

[0359] Specific examples of arm's length transactions described in this section are provided in Section 8.5 above and in Figure 6 Shown in.

[0360] Exemplary interactions according to these embodiments can be summarized as follows:

[0361] 1. The sender sends a token transaction to the receiver. (The token transaction contains zero-knowledge proofs in the unlocking script of the inputs, and the outputs paid to the sender.)

[0362] 2. The receiver checks the script of the parent token transaction referenced in the input of the token transaction [validate transferof tk to PK S ] contains the correct verification key. The receiver also checks his public key PK R Whether to embed the script [validate transfer of tk to PK S ] Only in this case does the receiver fund the token transaction to pay the sender. The receiver sends the funded token transaction to the sender.

[0363] 3. The sender checks that the transaction providing the funds is on-chain and that the second output of the token transaction is locked to her public key PK S , and then unlocks the script by adding its signature [validate transfer of tk to PK S ].

[0364] The sender signs in the last step, and the receiver performs some checks in the second step. Only the sender can unlock the P2PK part of the script [validate transfer]. It does not matter when the zk proof is included. This can be done at any step by the sender or the prover.

[0365] The more general interaction according to these embodiments can be summarized as follows:

[0366] 1. The sender sends a token transaction to the receiver.

[0367] 2. The recipient checks whether the referenced input transaction is linked to the issuing transaction and whether only he can unlock the first output of the token transaction (i.e. he controls the token after the transfer has been completed), and if so, funds the token transaction.

[0368] 3. The sender checks that the transaction providing the funds is on-chain and that the funds were sent to her public key, and only then unlocks the referenced output by adding her signature.

[0369] The recipient may perform any suitable checks in step 2. For example, the recipient may check whether there are all intermediate transactions tracing back to the issuing transaction.

[0370] 10. Further comments

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

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

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

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

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

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

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

[0378] Statement 1. A computer-implemented method of transferring a token using a blockchain, wherein the blockchain includes a token issuance transaction, wherein the token issuance transaction includes token data and an output locked to a public key of an issuer, and wherein the method is performed by a sender and includes:

[0379] generating a first transaction, wherein the first transaction comprises: i) a first input, the first input referencing an output of the token issuance transaction, or an output of a previous transaction forming part of a chain of one or more previous transactions linked to the token issuance transaction, wherein the referenced output is locked to a first public key of the sender, ii) a first output, the first output being locked to a public key of a recipient, the first output comprising token data, and iii) a second output, the second output being locked to the public key of the sender;

[0380] sending the first transaction to the recipient, wherein the recipient is configured to verify whether the first input references the output of the token issuance transaction or the output of the previous transaction forming part of the chain of one or more previous transactions linked to the token issuance transaction, and to verify whether the first output is locked to the public key of the recipient, and if so, generating a funded first transaction by including in the first transaction one or more corresponding inputs referencing one or more corresponding outputs of one or more corresponding funding transactions, the one or more corresponding outputs being locked to one or more corresponding public keys of the recipient;

[0381] receiving the funded first transaction from the recipient;

[0382] verifying whether the second output locked to the public key of the sender locks a predetermined amount of digital assets, and if so, generating a signed first transaction by including a signature in the first input of the funded first transaction, wherein the signature corresponds to the first public key of the sender; and,

[0383] The signed first transaction is sent to one or more nodes of a blockchain network and / or the recipient.

[0384] Statement 2. The method of claim 1 , comprising: verifying that the one or more corresponding funding transactions are on the blockchain, wherein the generation of the signed first transaction is dependent upon the verification.

[0385] Statement 3. The method of claim 1 or 2, wherein the referenced output comprises an enforcement locking script, wherein the enforcement locking script comprises a commitment sub-script, and a constraint sub-script comprising a verification key, and wherein when executed together with an unlocking script of a blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the enforcement locking script is configured such that the commitment sub-script is configured to verify whether the transaction commitment corresponds to the blockchain transaction, and the constraint sub-script is configured to use the verification key to verify whether the constraint proof provides proof that the committed blockchain transaction satisfies one or more constraints, and wherein the method comprises:

[0386] generating a transaction commitment based on the first transaction or the funded first transaction;

[0387] generating a constraint proof based on the first transaction or the funded first transaction, wherein the constraint proof is capable of proving that the first transaction or the funded first transaction satisfies the one or more constraints; and

[0388] The transaction commitment and the constraint proof are included in an unlocking script of the first input of the first transaction or the funded first transaction.

[0389] Statement 4. The method of claim 3, wherein the constraint sub-script and / or the unlocking script of the first input comprises a public input, and wherein the constraint sub-script is configured to use both the verification key and the public input to verify whether the constraint proof is able to prove that the committed blockchain transaction satisfies the one or more constraints.

[0390] Statement 5. The method of claim 3 or 4, wherein the commitment sub-script includes a commitment key, and wherein the commitment sub-script is configured to use the commitment key to verify whether the transaction commitment corresponds to the first transaction or the funded first transaction.

[0391] Statement 6. A method according to claim 3 or any dependent claim thereof, wherein the commitment sub-script is configured to provide the transaction commitment proof to the constraint sub-script, and wherein the constraint sub-script is configured to use the verification key, the public input and the transaction commitment to verify whether the constraint proof is able to prove that the first transaction or the funded first transaction satisfies the one or more constraints.

[0392] Statement 7. A method according to claim 3 or any dependent claim thereof, wherein the constraint sub-script is configured to use the verification key to verify whether the constraint proof has been generated using an evaluation key corresponding to the verification key, and wherein the method includes: generating the constraint proof based on the evaluation key.

[0393] Statement 8. A method according to claim 3 or any dependent claim thereof, wherein the commitment sub-script includes a non-interactive zero-knowledge verification algorithm, the non-interactive zero-knowledge verification algorithm is configured to verify whether the constraint proof has been generated to satisfy a specific program, and wherein the method includes: generating the constraint proof to satisfy the specific program.

[0394] Statement 9. A method according to claim 3 or any dependent claim thereof, wherein the transaction commitment includes a digital signature, wherein the commitment key includes a public key, and wherein the commitment sub-script is configured to verify whether the digital signature signs a message based on the first transaction or the first funded transaction, and wherein the method includes: generating a digital signature based on the first transaction or the first funded transaction.

[0395] Statement 10. The method of claim 9, wherein the public key corresponds to a private key that is set equal to 1.

[0396] Statement 11. A method according to claim 3 or any claim dependent thereon, wherein at least one of the one or more constraints is that the committed blockchain transaction includes an input that references the token issuance transaction, or that the committed blockchain references a transaction that forms part of a chain of one or more transactions linked to the token issuance transaction.

[0397] Statement 12. The method of claim 3 or any claim dependent thereon, wherein at least one of the one or more constraints is that a transaction referenced by an input of the committed blockchain transaction includes a valid constraint proof linking the transaction to the token issuance transaction, or that the transaction is the token issuance transaction.

[0398] Statement 13. A method according to claim 3 or any dependent claim thereof, wherein the enforcement of the locking script includes a transfer sub-script, wherein the transfer sub-script includes a target public key or a hash thereof, and wherein the transfer sub-script is configured to verify whether the unlocking script of the first input includes a signature corresponding to the first public key of the sender.

[0399] Statement 14. The method of claim 3 or any claim dependent thereon, comprising including the enforcement locking script in the second output of the first blockchain transaction.

[0400] Statement 15. The method of claim 3 or any claim dependent thereon, wherein at least one of the one or more constraints is that the committed blockchain transaction includes a portion or all of the enforcement locking script.

[0401] Statement 16. A computer-implemented method of accepting a token transferred using a blockchain, wherein the blockchain includes a token issuance transaction, wherein the token issuance transaction includes token data and an output locked to a public key of an issuer, and wherein the method is performed by a recipient and comprises:

[0402] receiving a first transaction from a sender;

[0403] verifying that the first transaction includes a first input that references an output of the token issuance transaction, or references an output of a previous transaction that forms part of a chain of one or more previous transactions linked to the token issuance transaction, wherein the referenced output is locked to a first public key of the sender;

[0404] verifying that the first output of the first transaction is locked to the public key of the recipient;

[0405] generating a first funded transaction by including in the first transaction one or more respective inputs referencing one or more respective outputs of one or more respective funded transactions, the one or more respective outputs being locked to one or more respective public keys of the recipient, wherein the first funded transaction includes a second output locked to the public key of the recipient, the second output including token data;

[0406] sending the funded first transaction to the sender, wherein the sender is configured to verify whether the one or more corresponding funded transactions are on the blockchain, and verify whether a second output of the funded first transaction is locked to a public key of the sender and locks a predetermined amount of the digital asset, and if so, generate a signed first transaction by including a signature in the first input of the funded first transaction, wherein the signature corresponds to the first public key of the sender, and send the signed first transaction to one or more nodes of a blockchain network and / or the recipient.

[0407] Statement 17. The method of claim 16, comprising:

[0408] receiving the signed first transaction from the sender; and,

[0409] Sending the signed first transaction to one or more nodes of the blockchain network.

[0410] Statement 18. The method of claim 16 or 17, wherein the recipient includes the first output locked to the public key of the recipient in the funded first transaction.

[0411] Statement 19. The method of claim 16 or any claim dependent thereon, wherein the referenced output comprises an enforcement locking script, wherein the enforcement locking script comprises a commitment sub-script and a constraint sub-script comprising a verification key, and wherein when executed together with an unlocking script of a blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the enforcement locking script is configured such that the commitment sub-script is configured to verify whether the transaction commitment corresponds to the blockchain transaction, and the constraint sub-script is configured to use the verification key to verify whether the constraint proof is able to prove that the committed blockchain transaction satisfies one or more constraints, and wherein the method comprises:

[0412] Verifying whether the verification key corresponds to a specific verification key, wherein the generating of the funded first transaction is dependent upon the verification key corresponding to the specific verification key.

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

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

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

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

[0417] According to another aspect disclosed herein, a method may be provided, the method comprising actions of the sender and the receiver.

[0418] According to another aspect disclosed herein, a system may be provided, the system comprising computer devices of the sender and the receiver.< / g> < / vk> < / x> < / pa>

Claims

1. A computer-implemented method of transferring a token using a blockchain, wherein the blockchain includes a token issuance transaction, wherein the token issuance transaction includes token data and an output locked to a public key of an issuer, and wherein the method is performed by a sender and includes: generating a first transaction, wherein the first transaction comprises: i) a first input, the first input referencing an output of the token issuance transaction, or an output of a previous transaction forming part of a chain of one or more previous transactions linked to the token issuance transaction, wherein the referenced output is locked to a first public key of the sender, ii) a first output, the first output being locked to a public key of a recipient, the first output comprising token data, and iii) a second output, the second output being locked to the public key of the sender; sending the first transaction to the recipient, wherein the recipient is configured to verify whether the first input references the output of the token issuance transaction or the output of the previous transaction forming part of the chain of one or more previous transactions linked to the token issuance transaction, and to verify whether the first output is locked to the public key of the recipient, and if so, generating a funded first transaction by including in the first transaction one or more corresponding inputs referencing one or more corresponding outputs of one or more corresponding funding transactions, the one or more corresponding outputs being locked to one or more corresponding public keys of the recipient; receiving the funded first transaction from the recipient; verifying whether the second output locked to the public key of the sender locks a predetermined amount of digital assets, and if so, generating a signed first transaction by including a signature in the first input of the funded first transaction, wherein the signature corresponds to the first public key of the sender; and The signed first transaction is sent to one or more nodes of a blockchain network and / or the recipient.

2. The method according to claim 1, comprising: verifying that the one or more corresponding funded transactions are on the blockchain, wherein the generating of the signed first transaction is dependent upon the verifying.

3. The method of claim 1 or 2, wherein the referenced output comprises an enforcement locking script, wherein the enforcement locking script comprises a commitment sub-script, and a constraint sub-script comprising a verification key, and wherein when executed together with an unlocking script of a blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the enforcement locking script is configured such that the commitment sub-script is configured to verify whether the transaction commitment corresponds to the blockchain transaction, and the constraint sub-script is configured to use the verification key to verify whether the constraint proof is able to prove that the committed blockchain transaction satisfies one or more constraints, and wherein the method comprises: generating a transaction commitment based on the first transaction or the funded first transaction; generating a constraint proof based on the first transaction or the funded first transaction, wherein the constraint proof is capable of proving that the first transaction or the funded first transaction satisfies the one or more constraints; as well as The transaction commitment and the constraint proof are included in an unlocking script of the first input of the first transaction or the funded first transaction.

4. The method according to claim 3, wherein: The constraint sub-script and / or the unlocking script of the first input include a public input, and wherein the constraint sub-script is configured to use both the verification key and the public input to verify whether the constraint proof is able to prove that the committed blockchain transaction satisfies the one or more constraints.

5. The method of claim 3 or 4, wherein the commitment sub-script includes a commitment key, and wherein the commitment sub-script is configured to use the commitment key to verify whether the transaction commitment corresponds to the first transaction or the funded first transaction.

6. The method of claim 3 or any claim dependent thereon, wherein the commitment sub-script is configured to provide the transaction commitment proof to the constraint sub-script, and wherein the constraint sub-script is configured to use the verification key, the public input, and the transaction commitment to verify whether the constraint proof is able to prove that the first transaction or the funded first transaction satisfies the one or more constraints.

7. The method of claim 3 or any claim dependent thereon, wherein the constraint sub-script is configured to use the verification key to verify whether the constraint proof has been generated using an evaluation key corresponding to the verification key, and wherein the method comprises: The constraint proof is generated based on the evaluation key.

8. The method of claim 3 or any claim dependent thereon, wherein the commitment sub-script comprises a non-interactive zero-knowledge verification algorithm configured to verify that the constraint proof has been generated to satisfy a specific procedure, and wherein the method comprises: The constraint proof is generated to satisfy the specific program.

9. The method of claim 3 or any claim dependent therefrom, wherein the transaction commitment comprises a digital signature, wherein the commitment key comprises a public key, and wherein the commitment sub-script is configured to verify that the digital signature signs a message based on the first transaction or the funded first transaction, and wherein the method comprises: A digital signature is generated based on the first transaction or the first funded transaction.

10. The method of claim 9, wherein the public key corresponds to a private key that is set equal to 1.

11. A method according to claim 3 or any claim dependent thereon, wherein at least one of the one or more constraints is that the committed blockchain transaction includes an input that references the token issuance transaction, or that the committed blockchain references a transaction that forms part of a chain of one or more transactions linked to the token issuance transaction.

12. A method according to claim 3 or any claim dependent thereon, wherein at least one of the one or more constraints is that a transaction referenced by an input of the committed blockchain transaction includes a valid constraint proof linking the transaction to the token issuance transaction, or that the transaction is the token issuance transaction.

13. A method according to claim 3 or any dependent claim thereof, wherein the enforcement locking script includes a transfer sub-script, wherein the transfer sub-script includes a target public key or a hash thereof, and wherein the transfer sub-script is configured to verify whether the unlocking script of the first input includes a signature corresponding to the first public key of the sender.

14. A method according to claim 3 or any claim dependent therefrom, comprising: Including the enforcement locking script in the second output of the first blockchain transaction.

15. The method of claim 3 or any claim dependent thereon, wherein at least one of the one or more constraints is that the committed blockchain transaction includes a portion or all of the enforcement locking script.

16. A computer-implemented method of accepting a token transferred using a blockchain, wherein the blockchain includes a token issuance transaction, wherein the token issuance transaction includes token data and an output locked to a public key of an issuing party, and wherein the method is performed by a recipient and comprises: receiving a first transaction from a sender; verifying that the first transaction includes a first input that references an output of the token issuance transaction, or references an output of a previous transaction that forms part of a chain of one or more previous transactions linked to the token issuance transaction, wherein the referenced output is locked to a first public key of the sender; verifying that the first output of the first transaction is locked to the public key of the recipient; generating a first funded transaction by including in the first transaction one or more respective inputs referencing one or more respective outputs of one or more respective funded transactions, the one or more respective outputs being locked to one or more respective public keys of the recipient, wherein the first funded transaction includes a second output locked to the public key of the recipient, the second output including token data; sending the funded first transaction to the sender, wherein the sender is configured to verify whether the one or more corresponding funded transactions are on the blockchain, and verify whether a second output of the funded first transaction is locked to a public key of the sender and locks a predetermined amount of the digital asset, and if so, generate a signed first transaction by including a signature in the first input of the funded first transaction, wherein the signature corresponds to the first public key of the sender, and send the signed first transaction to one or more nodes of a blockchain network and / or the recipient.

17. The method according to claim 16, comprising: receiving the signed first transaction from the sender; as well as Sending the signed first transaction to one or more nodes of the blockchain network.

18. The method of claim 16 or 17, wherein the recipient includes the first output locked to the public key of the recipient in the funded first transaction.

19. The method of claim 16 or any claim dependent thereon, wherein the referenced output comprises an enforcement locking script, wherein the enforcement locking script comprises a commitment sub-script and a constraint sub-script comprising a verification key, and wherein when executed together with an unlocking script of a blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the enforcement locking script is configured such that the commitment sub-script is configured to verify whether the transaction commitment corresponds to the blockchain transaction, and the constraint sub-script is configured to use the verification key to verify whether the constraint proof is able to prove that the committed blockchain transaction satisfies one or more constraints, and wherein the method comprises: Verifying whether the verification key corresponds to a specific verification key, wherein the generating of the funded first transaction is dependent upon the verification key corresponding to the specific verification key.

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