Enforcing constraints on blockchain transactions

Abstract

A computer-implemented method for enforcing constraints on a blockchain transaction, where the method is executed by a first party and includes generating an enforcement lock script for inclusion in a first output of a first blockchain transaction, wherein the enforcement lock script comprises a commitment sub-script, and a constraint sub-script comprising a verification key, and wherein when executed with an unlock script of a second blockchain transaction, the unlock script comprises a transaction commitment and a constraint proof, the forced execution locking script is configured to enable the commitment sub-script to be configured to verify whether the transaction commitment corresponds to the second block chain transaction or not; and the constraint sub-script is configured to use the verification key to verify whether the constraint proof can prove that the committed block chain transaction satisfies one or more constraints.

Description

Technical Field

[0001] The present disclosure relates to a method of using blockchain transactions to enforce constraints on future blockchain transactions. 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] 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.

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

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

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

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

[0014] The present disclosure provides a mechanism that imposes structure (i.e., conditions, constraints, etc.) on the spend transaction and / or its ancestors without pushing the spend transaction to the stack. This solves the transaction bloat problem. Embodiments of the present disclosure also solve one or more other problems discussed previously.

[0015] According to one aspect disclosed herein, there is provided a computer-implemented method for enforcing constraints on a blockchain transaction, wherein the method is performed by a first party and comprises: generating an enforcement locking script for inclusion in a first output of a first blockchain transaction, wherein the enforcement locking script comprises a commitment sub-script, and a constraint sub-script, the constraint sub-script comprising a verification key, and wherein when executed together with an unlocking script of a second blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the enforcement locking script being configured such that: the commitment sub-script is configured to verify whether the transaction commitment corresponds to the second 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 a committed blockchain transaction satisfies one or more constraints.

[0016] According to another aspect disclosed herein, there is provided a computer-implemented method for generating a blockchain transaction that satisfies constraints, wherein a first blockchain transaction includes an output, the output includes an enforcement locking script, wherein the enforcement locking script includes a transaction commitment sub-script, and a constraint enforcement sub-script including a verification key, and wherein the commitment sub-script is configured to verify whether a candidate transaction commitment corresponds to a candidate blockchain transaction, and the constraint sub-script is configured to use the verification key to verify whether a candidate constraint proof can prove that the candidate blockchain transaction satisfies one or more constraints, wherein the method is performed by a second party and includes: generating at least a portion of a second blockchain transaction, the second blockchain including an input (referencing the output of the first blockchain transaction), and wherein the second blockchain transaction satisfies the one or more constraints; generating a transaction commitment based on the at least a portion of the second blockchain transaction; generating a constraint proof based on the second blockchain transaction, wherein the constraint proof can prove that the second blockchain transaction satisfies the one or more constraints; and including the transaction commitment and the constraint proof in an unlocking script of the input of the second blockchain transaction.

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

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

[0019] REFTX is not limited by the expressive power of the blockchain’s scripting language and can impose structure on said spend transaction or its ancestors (in contrast to PUSHTX). In fact, REFTX runs mostly off-chain. Furthermore, it allows for the enforcement of a rich class of constraints (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.

[0020] 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

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

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

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

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

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

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

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

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

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

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

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

[0032] 1. Exemplary System Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0060] 2. UTXO-based model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0080] 3. Side Channels

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

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

[0083] 4. SNARK

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

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

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

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

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

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

[0090]

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

[0092] 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(λ)polylog(|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.

[0093] 4.1 On-chain SNARK Verification

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

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

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

[0097] 5. Simple transaction integrity - STI mechanism

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

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

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

[0101] If accept←verify(tx,commit(tx)), then the mechanism is complete. If it is impossible to create two transactions with the same tag, then the mechanism is a binding mechanism. Therefore, for any probabilistic algorithm The following conditions are true:

[0102]

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

[0104] 5.1 Simple verification on the chain

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

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

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

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

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

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

[0111] 5.1.2 Exemplary on-chain STI mechanism

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

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

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

[0115] The corresponding verification script is defined as:

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

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

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

[0119] 6. Enforce constraints

[0120] Embodiments of the present disclosure enable constraints to be enforced 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0137] This section describes exemplary implementations of the above embodiments.

[0138] 7.1 Constraints as NP predicates

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

[0140] predicate

[0141] "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"

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

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

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

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

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

[0147] 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"

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

[0149] "Spending transaction stx has three outputs"

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

[0151] 7.2 Proving predicates concisely

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

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

[0154] Enhancement Program

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

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

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

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

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

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

[0161] 7.3 Verification Script

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

[0163]

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

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

[0166] 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 known that P is being verified when the corresponding verification key is entered into the verifier. In order to ensure that the program It has been verified, yes Authentication key is hard-coded. Therefore, the above REFTX script includes:

[0167]

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

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

[0170] If the logical cost required to prove on y in zero - knowledge is high, it can be performed 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.

[0171] 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 constraintP] is independent of the size of the spent transaction stx.

[0172] 7.4 REFTX with Virtual Signature

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

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

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

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

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

[0178] 8. Transactions verified by miners

[0179] Embodiments of the present disclosure may be used to implement a miner-verified token protocol.

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

[0181]

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

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

[0184] 8.1 Transfer and Token Verification

[0185] Algorithm ValiodateTransfer

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

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

[0188] [validate transfer of tk to PK R ]:=[P2PK PK R ][enforce constraint P NFT ]

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

[0190] AlgorithmTransferOwnerShip

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

[0192] Off-chain steps:

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

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

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

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

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

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

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

[0200] 8.2 Optimized scripts for transfer verification

[0201] 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 , rather than a virtual public key.

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

[0203]

[0204] 8.3 Example NFT Program

[0205] This section describes two example NFT programs.

[0206] 8.3.1 Procedure 1

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

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

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

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

[0211] Enhancement Program

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

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

[0214] Code:

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

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

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

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

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

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

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

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

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

[0224] The procedure described in step 2 NFT The ID of the issuing transaction (already on-chain) txid0 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.

[0225] 8.3.2 Procedure 2

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

[0227] "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 constraint P′ NFT ].

[0228] P′ NFT The definition includes a REFTX script that references the statement itself [enforce constraint P′ 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.

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

[0230] The definition of the (enhancement) program is as follows.

[0231] Enhancement Program

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

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

[0234] Code:

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

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

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

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

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

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

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

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

[0243] 8.4 Casting

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

[0245] Step 1 - Issue Transaction

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

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

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

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

[0250] Issuer uses script [STI verify] and To generate a verification script [enforce constraint P NFT ]. Then, the publisher issues:

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

[0252] Validation scripts.

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

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

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

[0256] How can the receiver R be sure that he owns the token tk? One possibility is that R sends the transaction tx S-R Traced back to the issuing transaction tx0 or the casting 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.

[0257] tk appears implicitly in every transaction tx S→R Because it is enhanced by the program The verification key vk in [enforce constraint P NFT ] is hard-coded in . Here, Denotes any of the programs described in Section 8.3.

[0258] Transaction tx S→R Must be linked to tx0, the conditions are as follows: (i) Prove π NFT Verification (by miners on a given tx S→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.

[0259] Receiver R confirms tx in blockchain S→R Then perform the following two checks.

[0260] 1) He checks tx S→R The script embedded in [validate transfer tk to PK R ] is well-formed. He can do this because the formation [P2PK PK R The opcodes for [enforce constraint P] and [enforce constraint P] are well known.

[0261] 2) He checks his public key PK R and the correct verification key vk is embedded in the script. The correct verification key is the one that appears in the minting transaction tx →Issuer The user can use the issuer's public PK I To identify casting transactions.

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

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

[0264] Token authenticity is determined by the issuer’s public key PK embedded in the minting transaction I Given.

[0265] 8.5 Completely Fair Transactions

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

[0267] First output: Output tx from the previous section S→R The locking script [validate transfer tk toPK R ].

[0268] Second output: P2PK output, which is represented by the sender's public key PK S Locking an agreed upon amount of digital assets.

[0269] The steps of SwapOwnershipByBitcoins are as follows:

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

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

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

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

[0274] 8.6 Royalties

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

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

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

[0278] Program P NFTroyalty :

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

[0280] Private input: w P .

[0281] Code:

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

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

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

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

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

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

[0288] 8.7 Limited Edition

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

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

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

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

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

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

[0295] Step 1 - Issue Transaction

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

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

[0298] Then, he collected the Merkle tree Identifiers in And set rt tk is the root of the tree. For simplicity, for some n, suppose N = 2 n (If N is not a power of 2, the publisher fills the last leaf of the tree with dummy data to obtain N′=2 n >N leaves. Here, n is such that n-1 <log2(N)<n。)

[0299] Program P NFTwithReplicas Manage transactions of token copies. The program checks NFT transaction tx (tx: = tx S→R or ) whether the first output point of the reference ID belongs to the token tree The procedure also enforces that the same sequence number i of the replica is embedded in the unlocking scripts of tx and tx_parent. These are relative to the procedure P from Section 8.3. NFT , P′ NFT The only two differences.

[0300] algorithm Checks membership in a Merkle tree. Used to check if an element txid belongs to the tree The circuit is well known. It takes four inputs: the claimed leaf txid, the leaf index i (the replica's serial number), the Merkle proof (certification path) and the root of the tree rt tk It then uses this information to recalculate the root as r′ tk , and if and only if rt tk =rt′ tk Output 1 when

[0301] Authentication path Consists of sibling leaves (leaves are indexed from 0 to N - 1, if i is odd, the sibling leaf is the (i - 1)-th leaf, otherwise it is the (i + 1)-th leaf) and all intermediate hashes H required to traverse the tree from bottom to top j 1 ≤ j < n. This algorithm uses sibling leaves and intermediate hashes to perform hashing iteratively to recompute the root r′ 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

[0302] Enhanced program

[0303] Common input: τ tx

[0304] Private input:

[0305] Code:

[0306] 1. Check Gadget STI (τ tx ; (tx, w STI )) = 1

[0307] 2. Check if the program P′ NFTwithReplicas outputs 1 as follows:

[0308] a. Check if parent_txid = SHA256d(parent_tx)

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

[0310] c. Check if i tx = i parent_tx , and i tx , i parent_tx are respectively embedded in the unlocking scripts of tx and tx_parent

[0311] d. If (the parent is not a copy - the root rt tk is hard - coded), then do the following:

[0312] i. Check if the locking scripts of the first outputs of tx and parent_tx are equal and correspond to [P2PK PK R [enforce constraint P′ NFT (except for the hard - coded variable PK R ). It should be noted that this includes checking if the hard - coded verification keys in the two scripts are equal

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

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

[0315] Step 3 — Generate a Minting Transaction

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

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

[0318] 8.7.1 Reprint

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

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

[0321] 8.8 Auction-friendly NFTs

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

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

[0324] 8.8.1 Bid

[0325] Buyer R generates an NFT transaction funded by its 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.

[0326] 8.8.2 Selecting the Winner

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

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

[0329] 8.8.3 Threshold Price Verified by Miners

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

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

[0332] Program P NFTauction :

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

[0334] Private input: w P .

[0335] Code:

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

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

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

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

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

[0341] 8.9 Non-burnable tokens

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

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

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

[0345] 9. Further comments

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

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

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

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

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

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

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

[0353] Statement 1. A computer-implemented method for enforcing constraints on blockchain transactions, wherein the method is performed by a first party and comprises:

[0354] generating an enforcement locking script for inclusion in a first output of a first blockchain transaction, 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 second blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the enforcement locking script being configured such that:

[0355] The commitment sub-script is configured to verify whether the transaction commitment corresponds to the second blockchain transaction; and,

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

[0357] Statement 2. The method of statement 1, wherein the constraint sub-script and / or the unlocking script includes 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.

[0358] Statement 3. The method of statement 1 or 2, 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 second blockchain transaction.

[0359] Statement 4. A method according to any of the preceding statements, 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 second blockchain transaction satisfies the one or more constraints.

[0360] Statement 5. A method as described in any preceding statement, 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.

[0361] Statement 6. A method according to any of the preceding statements, wherein the commitment sub-script includes a non-interactive zero-knowledge verification algorithm, and the non-interactive zero-knowledge verification algorithm is configured to verify whether the constraint proof has been generated to satisfy a specific program.

[0362] Statement 7. A method according to any of the preceding statements, 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 second transaction.

[0363] Statement 8. The method of statement 7, wherein the public key corresponds to a private key that is set equal to 1.

[0364] The private key may be an ECDSA private key.

[0365] Statement 9. A method according to any of the preceding statements, the method comprising:

[0366] including the enforcement locking script in the first output of the first blockchain transaction; and,

[0367] Cause the first blockchain transaction to be submitted to the second party and / or one or more nodes of the blockchain network.

[0368] Statement 10. The method of statement 5 or any statement dependent thereon, comprising providing the evaluation key to a second party.

[0369] Statement 11. A method as described in any of the preceding statements, wherein the one or more constraints impose restrictions on one or more of the form, content, and quantity of one or more inputs and / or one or more outputs of the second blockchain transaction.

[0370] Statement 12. A method according to any of the preceding statements, wherein at least one of the one or more constraints is that the committed blockchain transaction includes an input that references a target transaction, or that the committed blockchain references a transaction that forms part of a chain of one or more transactions linked to the target transaction.

[0371] The target transaction may be a token issuance transaction or a token minting transaction.

[0372] Statement 13. A method according to any of the preceding statements, wherein at least one of the one or more constraints is that the committed blockchain transaction includes a portion or all of the enforced locking script.

[0373] Statement 14. A method according to any of the preceding statements, 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 a target transaction, or that the transaction is the target transaction.

[0374] Statement 15. A method according to any of the preceding statements, 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 includes a signature corresponding to the target public key.

[0375] Statement 16. A method as described in any of the preceding statements, wherein the blockchain includes a token issuance transaction, wherein the token issuance transaction includes token metadata, wherein the first blockchain transaction is a token minting transaction, and wherein the input of the token minting transaction references the output of the token issuance transaction.

[0376] Statement 17. The method of statement 16, wherein the output of the token issuance transaction is locked to a public key associated with a token issuer.

[0377] Statement 18. A method according to any one of statements 1 to 15, wherein the blockchain includes a token issuance transaction, wherein the token issuance transaction includes token metadata, wherein the blockchain includes a token minting transaction, wherein the input of the token minting transaction references the output of the token issuance transaction, and wherein the input of the first blockchain transaction references the output of the token minting transaction or the output of a transaction that forms part of a chain of one or more transactions linked to the token minting transaction.

[0378] Statement 19. A method as described in statement 15 or any dependent statement thereof, wherein the target public key is associated with the second party, and wherein the first blockchain transaction includes a second output locked to a public key associated with the first party.

[0379] Statement 20. The method of statements 18 and 19 as dependent upon statement 9, the method comprising:

[0380] including in said inputs of said first blockchain transaction a constraint proof and a transaction commitment for unlocking said output of said token minting transaction or said output of a transaction forming part of a chain of one or more transactions linked to said token minting transaction;

[0381] sending the first blockchain transaction to the second party, wherein the second party is configured to include one or more corresponding inputs in the first blockchain transaction;

[0382] receiving the first blockchain transaction from the second party; and,

[0383] verifying that the first blockchain transaction includes one or more corresponding inputs that reference one or more corresponding transaction outputs locked to a corresponding public key of the second party;

[0384] A signature is included in the input of the first blockchain transaction for unlocking the output of the token minting transaction or the output of a transaction forming part of a chain of one or more transactions linked to the token minting transaction.

[0385] Statement 21. A method as described in any of the preceding statements, wherein at least one of the one or more constraints is that the second blockchain transaction includes an output locked to a public key associated with the first party.

[0386] Statement 22. A method according to any of the preceding statements, wherein at least one of the one or more constraints is that the second blockchain transaction includes an output locked to a public key associated with a predetermined party, and wherein at least one of the one or more constraints is that the output locks a predetermined amount of digital assets or a certain percentage of the amount of digital assets locked by different outputs of the second blockchain transaction.

[0387] Statement 23. A method according to any of the preceding statements, wherein the blockchain includes multiple corresponding issuance transactions, each corresponding issuance transaction includes corresponding token data, wherein the constraint sub-script includes a Merkle root of a Merkle tree generated based on corresponding transaction identifiers of the corresponding issuance transactions, and wherein at least one of the constraints is that the second blockchain transaction includes an input that references one of the corresponding issuance transactions, or the second blockchain references a transaction that forms part of a chain of one or more transactions linked to one of the corresponding issuance transactions.

[0388] Statement 24. A method according to any one of statements 1 to 22, wherein the blockchain includes a plurality of corresponding first issuance transactions, wherein a first Merkle root of a first Merkle tree is generated based on a corresponding transaction identifier of the corresponding first issuance transaction, wherein the blockchain includes a plurality of corresponding second issuance transactions, each corresponding second issuance transaction includes corresponding token data, wherein the constraint subscript includes the first Merkle root and a second Merkle root of a second Merkle tree generated based on the corresponding transaction identifier of the corresponding second issuance transaction, and wherein at least one of the constraints is that the second blockchain transaction includes an input that references one of the corresponding second issuance transactions, or the second blockchain references a transaction that forms part of a chain of one or more transactions linked to one of the corresponding second issuance transactions.

[0389] Statement 25. A method according to statement 15 or any dependent statement thereof, wherein the blockchain includes a transaction, the transaction includes a third output locked to a public key associated with the second party, wherein the second blockchain transaction includes an input that references the third output, and wherein at least one of the one or more constraints is that the target public key is associated with the public key associated with the second party.

[0390] Statement 26. The method of statement 19 or any statement dependent thereon, wherein at least one of the one or more constraints is that the second output locks up an amount of digital assets that is equal to or greater than a threshold amount.

[0391] Statement 27. A computer-implemented method of generating a blockchain transaction that satisfies constraints, wherein a first blockchain transaction comprises an output, the output comprising an enforcement locking script, wherein the enforcement locking script comprises a transaction commitment sub-script, and a constraint enforcement sub-script comprising a verification key, and wherein the commitment sub-script is configured to verify whether a candidate transaction commitment corresponds to a candidate blockchain transaction, and the constraint sub-script is configured to use the verification key to verify whether a candidate constraint proof is able to prove that the candidate blockchain transaction satisfies one or more constraints, wherein the method is performed by a second party and comprises:

[0392] generating at least a portion of a second blockchain transaction, the second blockchain comprising an input referencing an output of the first blockchain transaction, and wherein the second blockchain transaction satisfies the one or more constraints;

[0393] generating a transaction commitment based on the at least a portion of the second blockchain transaction;

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

[0395] including the transaction commitment and the constraint proof in an unlocking script of the input of the second blockchain transaction.

[0396] Statement 28. The method of statement 27, wherein the constraint proof is generated using an evaluation key corresponding to the verification key.

[0397] Statement 29. A method according to statement 27 or 28, wherein the constraint sub-script includes a non-interactive zero-knowledge verification algorithm, the non-interactive zero-knowledge verification algorithm is configured to verify whether the candidate constraint proof has been generated using a corresponding non-interactive zero-knowledge proof algorithm, and wherein the method includes: using the non-interactive zero-knowledge proof algorithm to generate the constraint proof.

[0398] Statement 30. A method according to any one of statements 27 to 29, wherein the commitment sub-script includes a public key, and wherein the generation of the transaction commitment includes: generating a digital signature based on the second blockchain transaction using a private key corresponding to the public key.

[0399] Statement 31. The method of statement 30, wherein the private key is set equal to 1 and the temporary key used to generate the digital signature is set equal to 1.

[0400] Statement 32. A method according to any one of statements 27 to 31, the method comprising: causing the second blockchain transaction to be submitted to the first party and / or one or more nodes of the blockchain network.

[0401] Statement 33. The method of any one of statements 27 to 32, wherein the enforcement locking script includes a transfer sub-script, wherein the transfer sub-script includes a target public key or a hash thereof, wherein the transfer sub-script is configured to verify whether the unlocking script includes a signature corresponding to the target public key, and wherein the method includes:

[0402] generating a signature using a private key corresponding to the target public key; and,

[0403] Including the signature in the unlocking script of the second blockchain transaction.

[0404] Statement 34. The method of any one of statements 27 to 33, wherein the condition for including the transaction commitment and the constraint proof in the unlocking script of the input of the second blockchain transaction is:

[0405] verifying that the enforcement lock script meets one or more predetermined conditions; and,

[0406] It is verified whether the verification key corresponds to a predetermined evaluation key.

[0407] Statement 35. The method of statements 33 and 34, wherein the condition for including the transaction commitment and the constraint proof in the unlocking script of the input of the second blockchain transaction is:

[0408] Verify whether the target public key is a public key owned by the second party.

[0409] Statement 36. A computer device, the computer device comprising:

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

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

[0412] Statement 37. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform a method according to any one of statements 1 to 35.

[0413] According to another aspect disclosed herein, a method may be provided, the method comprising actions of the first party and the second party.

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

Claims

1. A computer-implemented method for enforcing constraints on blockchain transactions, wherein the method is performed by a first party and comprises: generating an enforcement locking script for inclusion in a first output of a first blockchain transaction, 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 second blockchain transaction, the unlocking script comprises a transaction commitment and a constraint proof, the enforcement locking script being configured such that: The commitment sub-script is configured to verify whether the transaction commitment corresponds to the second 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.

2. The method of claim 1 , wherein the constraint sub-script and / or the unlocking script 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.

3. The method of claim 1 or 2, 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 second blockchain transaction.

4. The method of any preceding claim, 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 second blockchain transaction satisfies the one or more constraints.

5. A method according to any preceding claim, 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.

6. A method according to any preceding claim, wherein the commitment sub-script comprises a non-interactive zero-knowledge verification algorithm configured to verify whether the constraint proof has been generated to satisfy a specific procedure.

7. A method according to any preceding claim, 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 whether the digital signature signs a message based on the second transaction. The method of claim 7 , wherein the public key corresponds to a private key that is set equal to 1. 9 .

9. A method according to any preceding claim, comprising: including the enforcement locking script in the first output of the first blockchain transaction; as well as Cause the first blockchain transaction to be submitted to the second party and / or one or more nodes of the blockchain network.

10. The method according to claim 5 or any claim dependent thereon, comprising: The evaluation key is provided to the second party.

11. A method according to any preceding claim, wherein the one or more constraints impose restrictions on one or more of the form, content, and quantity of one or more inputs and / or one or more outputs of the second blockchain transaction.

12. A method according to any preceding claim, wherein at least one of the one or more constraints is that the committed blockchain transaction includes an input that references a target transaction, or that the committed blockchain references a transaction that forms part of a chain of one or more transactions linked to the target transaction.

13. A method according to any preceding claim, wherein at least one of the one or more constraints is that the committed blockchain transaction includes part or all of the enforcement locking script.

14. A method according to any preceding claim, 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 a target transaction, or that the transaction is the target transaction.

15. A method according to any preceding claim, wherein the enforcement locking script comprises a transfer sub-script, wherein the transfer sub-script comprises a target public key or a hash thereof, and wherein the transfer sub-script is configured to verify whether the unlocking script comprises a signature corresponding to the target public key.

16. A method according to any preceding claim, wherein the blockchain comprises a token issuance transaction, wherein the token issuance transaction comprises token metadata, wherein the first blockchain transaction is a token minting transaction, and wherein the inputs of the token minting transaction reference the outputs of the token issuance transaction.

17. The method of claim 16, wherein the output of the token issuance transaction is locked to a public key associated with a token issuer.

18. A method according to any one of claims 1 to 15, wherein the blockchain comprises a token issuance transaction, wherein the token issuance transaction comprises token metadata, wherein the blockchain comprises a token minting transaction, wherein the inputs of the token minting transaction reference the outputs of the token issuance transaction, and wherein the inputs of the first blockchain transaction reference the outputs of the token minting transaction or the outputs of a transaction forming part of a chain of one or more transactions linked to the token minting transaction.

19. The method of claim 15 or any claim dependent therefrom, wherein the target public key is associated with the second party, and wherein the first blockchain transaction comprises a second output locked to a public key associated with the first party.

20. The method according to claims 18 and 19 as appended to claim 9, comprising: including in said inputs of said first blockchain transaction a constraint proof and a transaction commitment for unlocking said output of said token minting transaction or said output of a transaction forming part of a chain of one or more transactions linked to said token minting transaction; sending the first blockchain transaction to the second party, wherein the second party is configured to include one or more corresponding inputs in the first blockchain transaction; receiving the first blockchain transaction from the second party; as well as verifying that the first blockchain transaction includes one or more corresponding inputs that reference one or more corresponding transaction outputs locked to a corresponding public key of the second party; A signature is included in the input of the first blockchain transaction for unlocking the output of the token minting transaction or the output of a transaction forming part of a chain of one or more transactions linked to the token minting transaction.

21. A method according to any preceding claim, wherein at least one of the one or more constraints is that the second blockchain transaction includes an output locked to a public key associated with the first party.

22. A method according to any of the preceding claims, wherein at least one of the one or more constraints is that the second blockchain transaction includes an output locked to a public key associated with a predetermined party, and wherein at least one of the one or more constraints is that the output locks a predetermined amount of digital assets or a certain percentage of the amount of digital assets locked by different outputs of the second blockchain transaction.

23. A method according to any of the preceding claims, wherein the blockchain comprises a plurality of respective issuance transactions, each respective issuance transaction comprising respective token data, wherein the constraint sub-script comprises a Merkle root of a Merkle tree generated based on respective transaction identifiers of the respective issuance transactions, and wherein at least one of the constraints is that the second blockchain transaction comprises an input that references one of the respective issuance transactions, or that the second blockchain references a transaction that forms part of a chain of one or more transactions linked to one of the respective issuance transactions.

24. A method according to any one of claims 1 to 22, wherein the blockchain comprises a plurality of respective first issuance transactions, wherein a first Merkle root of a first Merkle tree is generated based on respective transaction identifiers of the respective first issuance transactions, wherein the blockchain comprises a plurality of respective second issuance transactions, each respective second issuance transaction comprising respective token data, wherein the constraint subscript comprises the first Merkle root and a second Merkle root of a second Merkle tree generated based on the respective transaction identifiers of the respective second issuance transactions, and wherein at least one of the constraints is that the second blockchain transaction comprises an input that references one of the respective second issuance transactions, or that the second blockchain references a transaction that forms part of a chain of one or more transactions linked to one of the respective second issuance transactions.

25. A method according to claim 15 or any claim dependent thereon, wherein the blockchain comprises a transaction, the transaction comprising a third output locked to a public key associated with the second party, wherein the second blockchain transaction comprises an input referencing the third output, and wherein at least one of the one or more constraints is that the target public key is associated with the public key associated with the second party.

26. The method of claim 19 or any claim dependent thereon, wherein at least one of the one or more constraints is that the second output locks an amount of digital assets that is equal to or greater than a threshold amount.

27. A computer-implemented method of generating a blockchain transaction that satisfies constraints, wherein a first blockchain transaction comprises an output, the output comprising an enforcement locking script, wherein the enforcement locking script comprises a transaction commitment sub-script, and a constraint enforcement sub-script comprising a verification key, and wherein the commitment sub-script is configured to verify whether a candidate transaction commitment corresponds to a candidate blockchain transaction, and the constraint sub-script is configured to use the verification key to verify whether a candidate constraint proof is able to prove that the candidate blockchain transaction satisfies one or more constraints, wherein the method is performed by a second party and comprises: generating at least a portion of a second blockchain transaction, the second blockchain comprising an input referencing an output of the first blockchain transaction, and wherein the second blockchain transaction satisfies the one or more constraints; generating a transaction commitment based on the at least a portion of the second blockchain transaction; generating a constraint proof based on the second blockchain transaction, wherein the constraint proof is capable of proving that the second blockchain transaction satisfies the one or more constraints; as well as including the transaction commitment and the constraint proof in an unlocking script of the input of the second blockchain transaction.

28. The method of claim 27, wherein the constraint proof is generated using an evaluation key corresponding to the verification key.

29. The method of claim 27 or 28, wherein the constraint subscript comprises a non-interactive zero-knowledge verification algorithm configured to verify whether the candidate constraint proof has been generated using a corresponding non-interactive zero-knowledge proof algorithm, and wherein the method comprises: The constraint proof is generated using the non-interactive zero-knowledge proof algorithm.

30. The method of any one of claims 27 to 29, wherein the commitment sub-script comprises a public key, and wherein the generating of the transaction commitment comprises: A digital signature is generated based on the second blockchain transaction using a private key corresponding to the public key.

31. The method of claim 30, wherein the private key is set equal to 1 and a temporary key used to generate the digital signature is set equal to 1.

32. A method according to any one of claims 27 to 31, comprising: Cause the second blockchain transaction to be submitted to the first party and / or one or more nodes of a blockchain network.

33. A method according to any one of claims 27 to 32, wherein the enforcement locking script comprises a transfer sub-script, wherein the transfer sub-script comprises a target public key or a hash thereof, wherein the transfer sub-script is configured to verify whether the unlocking script comprises a signature corresponding to the target public key, and wherein the method comprises: generating a signature using a private key corresponding to the target public key; as well as Including the signature in the unlocking script of the second blockchain transaction.

34. The method of any one of claims 27 to 33, wherein the condition for including the transaction commitment and the constraint proof in the unlocking script of the input of the second blockchain transaction is: Verifying that the enforcement lock script meets one or more predetermined conditions; and It is verified whether the verification key corresponds to a predetermined evaluation key.

35. The method of claims 33 and 34, wherein the condition for including the transaction commitment and the constraint proof in the unlocking script of the input of the second blockchain transaction is: Verify whether the target public key is a public key owned by the second party.

36. 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 code arranged to be executed on the processing device, and the code is configured to execute the method according to any one of claims 1 to 35 when executed on the processing device.

37. 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 35.

Images