Enforcing constraints on blockchain transactions

Abstract

A computer-implemented method for enforcing constraints on blockchain transactions is provided, the method comprising: generating, when executed by a first party, an enforcement locking script for inclusion in a first output of a first blockchain transaction, the enforcement locking script including a commitment subscript and a constraint subscript having a verification key; and configured such that, when executed together with an unlocking script for a second blockchain transaction, the unlocking script having the transaction commitment and the constraint proof, the enforcement locking script is configured to verify that the commitment subscript verifies that the transaction commitment corresponds to the second blockchain transaction, and the constraint subscript is configured to verify, using the verification key, that the constraint proof provides proof that the committed blockchain transaction satisfies one or more constraints.

Description

[Technical Field]

[0001] The present disclosure relates to methods of using blockchain transactions to enforce constraints on future blockchain transactions. [Background technology]

[0002] A blockchain is a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly available at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain comprises a chain of blocks of data, with each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence that may span one or more blocks and extend back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are created through a process often referred to as "mining," which involves multiple nodes competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, validated, outstanding transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and publication of a block may be achieved through publication of only the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: moving digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or temporally ordering index pointers. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes for data within transactions. Because there is no pre-specified limit on the maximum amount of data that can be stored in a single transaction, increasingly more complex data can be incorporated. For example, this could be used to store electronic documents or audio or video data on the blockchain.

[0004] Nodes (often called "miners") in a blockchain network perform a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a target block template in an attempt to identify a valid proof-of-work solution for the transaction. Once a valid solution is found, the new block is disseminated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network to be disseminated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not disseminated and are not included in blocks. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, usually called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of fraudulent transactions is performed by the actions of competing nodes that are incentivized to act on behalf of the network and report and prevent fraud. Widespread publication of information allows users to continuously audit node behavior. The simple publication of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of a digital asset derivable from the preceding sequence of transactions. A consumable output is sometimes called a UTXO (unspent transaction output). An output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit a digital token or asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output specifying the amount of a digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input, which comprises a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, valid transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not disseminate the target transaction (not as a valid transaction, but possibly disseminate it to register a fraudulent transaction) and will not include the target transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing back to the UTXO of a previous transaction in a sequence of past transactions, but by referencing an absolute account balance. The current state of every account is stored in the blockchain and constantly updated by multiple nodes separately. Summary of the Invention [Problem to be solved by the invention]

[0009] It is generally known that conditions can be applied to fields of a consuming transaction, i.e., a transaction that spends (e.g., unlocks, allocates, transfers) the output of a previous transaction. For example, the previous transaction may include a locking script that imposes a condition on one or more outputs of the consuming transaction. It should be noted that, in the present technology, the term "consuming transaction" refers to a current transaction that unlocks at least one output of at least one previous transaction, and does not necessarily imply that the current transaction is related to a financial transaction.

[0010] One reason for enforcing a condition on a field in a consuming transaction is to ensure that the output of the consuming transaction contains the same locking script as the previous transaction. This way, we can guarantee that the consuming transaction will enforce the same condition on the next consuming transaction. That is, the n-1th transaction will contain a locking script that forces the nth transaction to contain the same locking script, and so the n+1th transaction will also contain the same locking script. In this way, a chain of transactions is created, where each transaction contains the same locking script. This can be used, for example, in the context of digital tokens that represent ownership of real-world or virtual-world objects. This is advantageous, as it means that each transfer of tokens follows the same rules.

[0011] Previous attempts to force a series of transactions to include the same locking script suffer from at least one of the following problems. First, some attempts require validators to trace back to the first transaction in the chain (e.g., the "issue transaction") to verify that the first transaction was created correctly (e.g., by a specific authority, such as the token issuer) or that the locking script included in the most recent transaction is identical to the locking script included in that transaction and all other transactions in the chain. This consumes validator resources (both computational resources, time, and effort) when validating the most recent transaction in the chain. Second, some attempts require a third party to be involved in creating and / or verifying the next transaction in the chain (e.g., a token transfer) to ensure that the next transaction is created correctly. This reliance on a third party undermines the trustless nature of blockchains and increases the number of parties that must interact, reducing efficiency. Third, as discussed below, some attempts to force a series of transactions to include the same locking script require the most recent transaction to include all previous transactions in the chain, resulting in transaction bloat. This creates problems for both sending and storing transactions. Fourth, some attempts are susceptible to replay attacks.

[0012] Previous attempts to impose conditions on future spend transactions have involved inserting the spend transaction into the stack of a blockchain script engine to execute business logic on transactions that have been validated by blockchain nodes. One technique for forcing the inclusion of such messages in unlock scripts 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] A mechanism called PUSHTX embeds (i.e., injects) a copy of the consuming transaction's signature hash field into the unlock script. By utilizing the OP_CHECKSIG opcode, validation logic can be developed in the lock script (of the parent transaction) to ensure that the injected copy matches the consuming transaction. Injecting the transaction's ancestors is also possible, but requires that all fields of the ancestors (including the unlock script) be embedded in the consuming transaction's unlock script. In some cases, this technique may not be appropriate. For example, repeated injection of parent transactions can cause the transaction size to grow rapidly as the unlock script accumulates all previous transactions.

[0014] The present disclosure provides a mechanism for imposing structure (i.e., conditions, constraints, etc.) on a consuming transaction and / or its ancestors without pushing the consuming transaction onto a stack, thereby solving the problem of transaction bloat. Embodiments of the present disclosure also solve one or more of the other problems discussed above. [Means for solving the problem]

[0015] In one aspect disclosed herein, a computer-implemented method for enforcing constraints on blockchain transactions is provided, the method comprising: generating, when executed by a first party, a forced locking script for inclusion in a first output of a first blockchain transaction, the forced locking script including a commitment subscript and a constraint subscript having a verification key; and configured such that, when executed together with an unlocking script for a second blockchain transaction, the unlocking script having the transaction commitment and the constraint proof, the forced locking script is configured to verify that the commitment subscript verifies that the transaction commitment corresponds to the second blockchain transaction, and the constraint subscript is configured to verify, using the verification key, that the constraint proof provides proof that the committed blockchain transaction satisfies one or more constraints.

[0016] In another aspect disclosed herein, a computer-implemented method for generating blockchain transactions that satisfy constraints is provided, wherein a first blockchain transaction has an output including a forced locking script, the forced locking script including a transaction commitment subscript and a constraint enforcement subscript including a verification key, the commitment subscript being configured to verify that a candidate transaction commitment corresponds to the candidate blockchain transaction, and the constraint subscript being configured to verify, using the verification key, that a candidate constraint proof provides proof that the candidate blockchain transaction satisfies one or more constraints, the method being executed by a second party and including: generating at least a portion of a second blockchain transaction, the second blockchain including an input that references the output of the first blockchain transaction, the second blockchain transaction satisfying the one or more constraints; generating the transaction commitment based on at least a portion of the second blockchain transaction; generating a constraint proof based on the second blockchain transaction, the constraint proof providing proof 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 an input of the second blockchain transaction.

[0017] A lock script (called a "mandatory lock script") is used to enforce conditions (i.e., constraints, limits, etc.) on future transactions that attempt to unlock an output (i.e., a consuming transaction) that includes the mandatory lock script. A lock script contains at least two subscripts (i.e., parts of the entire lock script). The first part (called the "commitment subscript" or "concise transaction integrity mechanism") is used to verify that the transaction commitment (i.e., a string) provided in the consuming transaction's unlock script is a binding commitment for the consuming transaction (i.e., a sighash serialization of the consuming transaction). In some examples, the transaction commitment is a hash digest or digital signature generated based on the consuming transaction. The second part (called the "constraint subscript") is used to verify that the consuming transaction (i.e., the committed transaction) satisfies one or more constraints. This is done without including the consuming transaction (or fields of the consuming transaction) in the consuming transaction's unlock script. In other words, the effect is that the sighash serialization of the consuming transaction no longer needs to be included in the consuming transaction's unlock script. Instead, the unlock script contains the commitment, the size of which is short and independent of the transaction's size.

[0018] Some embodiments of the present disclosure use concise non-interactive zero-knowledge arguments (SNARKs) to prove off-chain that a transaction's structure is constrained according to business logic. This generates a short (concise) proof that can be embedded as part of the unlocking script and verified on-chain. While the constrained subscript portion of the mandatory locking script (which contains the logic for verifying the proof) can be large, its size is constant and independent of the size of the spend transaction. This, combined with short commitments, solves the aforementioned transaction bloat problem. As previously explained, these embodiments are insufficient to simply apply a general-purpose SNARK. If applied directly, the verification algorithm would need to receive the validated spend transaction as input, which would re-introduce the bloat problem. To overcome this, SNARKs are combined with a concise transaction integrity mechanism that can be verified on-chain. A specific example of this type of integrity check is the so-called "dummy signature," as described in UK Patent Application GB2206039.6. The resulting mechanism is called REFTX, short for "Reference Transaction."

[0019] Unlike PUSHTX, REFTX is not constrained by the expressive power of blockchain scripting languages ​​to impose structure on spending transactions or their ancestors. In fact, REFTX operates primarily off-chain. Furthermore, its use of generic SNARKs allows it to enforce a rich set of constraints. The only requirement is that such constraints be expressible as programs verifiable by SNARKs, which allows it to cover almost any conceivable feasible computation.

[0020] The REFTX mechanism can be used to implement non-fungible token (NFT) schemes, whereby the transfer of ownership of a tokenized asset is controlled by a lock. The transfer of ownership is controlled by an NFT program that imposes constraints on previous transactions, ensuring that a spend transaction can be traced back to an issue or mint transaction involving the token.

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

[0022] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 illustrates a schematic diagram of an exemplary system for enforcing conditions on blockchain transactions. [Figure 4] FIG. 1 illustrates a schematic example of a first transaction enforcing a condition on a second transaction. [Figure 5] FIG. 1 illustrates schematically some exemplary transactions for issuing and minting a blockchain-based token. [Figure 6] FIG. 1 is a diagram illustrating several example transactions for trading tokens with two funding transactions, where PK1 and PK2 are controlled by the receiver, PK3 is controlled by the sender, and f represents the miner's fee. [Figure 7] FIG. 10 is a schematic diagram illustrating some exemplary transactions for trading tokens with a royalty of 1% of the transaction. [Figure 8]FIG. 10 is a diagram illustrating several example transactions for mining two duplicate tokens, where the root of the token hash tree is hard-coded into the token program that validates the transfer. [Figure 9] FIG. 10 is a schematic diagram illustrating an exemplary hash tree for encoding different editions of a duplicate token. [Figure 10] FIG. 10 is a schematic diagram illustrating some example transactions for trading non-burnable tokens, where a unique funding UTXO txid′||0 is unlocked using the same public key to which the tokens are sent. DETAILED DESCRIPTION OF THE INVENTION

[0023] 1. System Overview Example 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that may be adapted to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0024] Each blockchain node 104 comprises a peer computing device, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0025] A blockchain 150 comprises a chain of blocks of data 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned 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 of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing an amount of digital assets, such as a user 103 to which the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points to the output of a preceding transaction 152, thereby chaining transactions together.

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

[0027] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." As used herein, this term is not limited to a particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and for which the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0028] For a given current transaction 152j, the (or each) input comprises a pointer referencing the output of a previous transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily mean the transfer of a financial asset, although this is certainly a common usage. More generally, consumption 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 the ordered set 154 or any block 151. The previous transaction 152i does not necessarily exist at the time the current transaction 152j is created or even sent to the network 106, but the previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, as used herein, "preceding" refers to something that precedes in a logical sequence connected by pointers, and not necessarily to a time of creation or transmission in a chronological order, and does not necessarily preclude transactions 152i, 152j from being created or transmitted in a different order (see the discussion of orphan transactions below). A preceding transaction 152i may be equivalently referred to as an ancestor transaction or a predecessor transaction.

[0029] The input of the current transaction 152j also comprises the input's authorization, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which can be the original user or entity 103a to provide change). In some cases, the transaction can also have multiple inputs to aggregate amounts from multiple outputs of one or more preceding transactions and redistribute them into one or more outputs of the current transaction.

[0030] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to establish a new transaction 152j (either manually or through an automated process utilized by the party), the establishing party transmits the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but could in principle be other user terminals). It is not excluded that the party 103 establishing the new transaction 152j may transmit the transaction directly to one or more of the blockchain nodes 104, and in some instances may not transmit it to a recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is legitimate according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that the cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction consumes (i.e., "allocates"), which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may be determined solely by the blockchain node protocol, or by a combination of these. 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 tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0031] In an output-based model, the definition of whether a given output (e.g., a UTXO) is allocated (or "spent") is whether it has not already been validly redeemed by the input of another, earlier transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not disseminated (unless flagged as fraudulent and disseminated as a warning) or recorded in the blockchain 150. This protects against double spending, where a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining an account balance. Again, because there is no defined order to transactions, an account balance has a single defined state at any given time.

[0032] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is aided by "proof of work." At blockchain nodes 104, new transactions that have not yet appeared in a block 151 recorded in the blockchain 150 are added to an ordered pool 154 of legitimate transactions. Blockchain nodes then compete to assemble a new legitimate block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool of outstanding transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a defined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. The nature of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0033] The first blockchain node 104 that solves the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the solution causes the hash output to satisfy a condition). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and enforce the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n, which points to the previously created block 151n-1 in the chain. The large amount of effort required to produce the proof-of-work solution, e.g., in the form of a hash, indicates the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction (also known as double-spending). Once created, blocks 151 cannot be altered because they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this becomes an immutable public ledger of transactions.

[0034] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There are also protocols for resolving any possible "forks," which are situations in which two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to spread between the nodes 104. That is, the fork with the longest branch becomes the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0035] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional acceptable amount of digital assets in a new, special type of transaction (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional specified amount of digital assets. This special type of transaction is typically called a "coinbase transaction," but may also be named an "initial transaction" or "generation transaction." It typically forms the first transaction in a new block 151n. The proof of work indicates the node constructing the new block's willingness to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, an ordinary (non-generation) transaction 152 also specifies 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 is published. This fee is typically called a "transaction fee" and is discussed below.

[0036] Depending on the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0037] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

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

[0039] Some or all of the parties 103 may be connected as part of a different network, for example, a network superimposed on the blockchain network 106. Users of the blockchain network (often referred to as “clients”) are sometimes said to be part of a system that includes the blockchain network 106, but 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 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. By way of example only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not intended to be limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0040] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, e.g., 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 of the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 adapted to run on the processing unit. It will be understood that any action attributed herein to a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

[0042] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and submit transactions 152 to one or more Bitcoin nodes 104 so that the transactions 152 are disseminated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, the second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0043] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and any client function described herein may instead be implemented in a suite of two or more separate applications that interface, for example, via an API, or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer, at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to a client application 105, it will be understood that this is not limiting.

[0044] An instance of client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to inquire about any transactions of which the respective party 103 is the recipient (or, in embodiments, to actually investigate other parties' transactions in the blockchain 150, since the blockchain 150 is a public institution that lends credibility to transactions in part by being publicly visible). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As discussed above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward transactions 152 for dissemination throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol is attached to a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0045] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction (using the wallet functionality of Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it handles the transaction 152j according to the blockchain node protocol and its respective role. This involves first verifying whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity verification may be configurable per transaction via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0046] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., for it to be "validated"), every blockchain node 104 that receives the transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, the transaction 152j will soon be propagated throughout the network 106.

[0047] Once admitted to the ordered pool of outstanding transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle for the latest version of each pool 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, but whoever solves first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Because each transaction 152 includes a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0048] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views about which instance is "valid" before an 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 an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as fraudulent) the instance it originally accepted (i.e., the one not published in block 151).

[0049] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored separately on the blockchain and constantly updated by the network's nodes. In such a system, transactions are ordered using the account's transaction execution record (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0050] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation on all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0051] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value specifying an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201, which may include an indication of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0052] Suppose Alice 103a wishes to create transaction 152j that transfers an amount of a target digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It has the amount of digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediately following transaction in the pool 154. Tx1 may refer to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

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

[0054] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the recipient of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

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

[0056] So, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A ], which means that Alice's signature Sig P must exist in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A The Tx1 input 202 comprises a pointer to Tx1 (e.g., pointed to by transaction ID TxID0, where in an embodiment TxID0 is a hash of the entire transaction Tx0). The Tx1 input 202 comprises an index that identifies UTXO0 within Tx0, in order to identify UTXO0 among all other possible outputs of Tx0. The Tx1 input 202 further comprises an unlock script <Sig P A >, which comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or a combination of these.

[0057] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to see if the unlock script meets the conditions defined in the lock script (where the conditions may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' denotes concatenation, '<...>' means putting data on the stack, and '[...]' is the functionality the lock script contains (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, these scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. Athat the unlock script in Tx1's input contains Alice's signature signing the expected portion of data. The expected portion of data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus, a separate element specifying the signed portion of data in plaintext need not be included, as it is essentially already present).

[0058] The details of public-private cryptographic authentication will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then with Alice's public key, the plaintext, and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature with the message, thereby allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing particular data, portions of a transaction, etc., may, in embodiments, mean signing a hash of that data or portion of a transaction.

[0059] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of outstanding transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that transaction Tx1 is disseminated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as having been spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 is fraudulent, even if all other conditions are met. Therefore, blockchain node 104 also needs to verify whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

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

[0061] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Part of the amount defined in the UTXO is "left behind" as unspent, while another part is not. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself or pay another party the change in the second output of Tx1.

[0062] In practice, Alice is typically also required to include a fee for Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain nodes 104 and therefore may not be propagated or included in the blockchain 150, even if technically valid (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require a unique, separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by inputs 202 of a given transaction 152 and the total amount specified in outputs 203 is automatically given to the blockchain node 104 that issues the transaction. For example, suppose 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 by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0063] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines a given party's 103's entire balance. It is the role of the wallet function of the client application 105 to reconcile together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, forward transaction. The wallet function can do this by querying a copy of the blockchain 150, such as that stored in one of the Bitcoin nodes 104.

[0064] Note that script code is often represented generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0065] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portions of the outputs that the digital signature signs depend on the SIGHASH flag. The SIGHASH flag is typically a four-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0066] A lock script may be referred to as a "scriptPubKey," which refers to the fact that the lock script typically includes the public key of the party to which the respective transaction is locked. An unlock script may be referred to as a "scriptSig," which refers to the fact that the unlock script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may be used to define any condition or conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0067] 3. Side Channels As shown in FIG. 1, the client applications on each of Alice's computing device 102a and Bob's computing device 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish (either at the instigation of the first party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 without the transactions 152 being registered on the blockchain network 106 or entering the chain 150 until either Alice or Bob chooses to broadcast the transaction 152 between Alice and Bob to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0068] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 107 referred to anywhere herein may comprise any one or more links over one or more networking technologies or communication media for exchanging data “off-chain,” i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links may collectively be referred to as the side channel 107. Thus, it should be noted that when Alice and Bob are said to exchange certain information or data, etc., over the side channel 107, this does not necessarily imply that all such data must be transmitted over exactly the same links, or even the same type of network.

[0069] 4. SNARKS Suppose a binary program P{x; w}=b∈{0, 1} takes a bit string x (an instance) as public input, another bit string w (a witness) as private input, and outputs a decision bit b. Suppose P executes correctly if b=1.

[0070] A simple non-interactive proof of knowledge system (SNARK) for correctly executing a program P is a triplet of algorithms, SNARKF:= (Setup, Prove, Verify), where Setup(λ, P) → (ek, vk): Given a security parameter λ and a description of a program P, output a pair of evaluation and verification keys. Prove(ek, x, w) → π: Given an evaluation key, a public input x, and a private input w, output a proof π. Verify(vk, x, π) → b∈{accept, reject}: Given a verification key, a public input x, and a proof π, accept or reject the proof.

[0071] A SNARK is complete if the verifier always accepts the proof π produced by the prover SNARK.prove for an input pair (x, w) of public / private inputs that approves the program P. A SNARK is sound if, for all public inputs x for which there is no private input w that approves P, the verifier rejects the proof π of x with very high probability. More formally, a SNARK is sound if, for all probabilistic polynomial-time algorithms A (that catch potentially cheating provers), the following holds:

number

[0072] Note that the verification key must be correctly generated using the setup algorithm. Furthermore, a proof is said to be knowledge-sound if it can be efficiently computed (extracted) from a valid proof π and the random numbers used by a (possibly cheating) prover A to generate π (with negligible error, i.e., knowledge error).

[0073] A proof is "short" meaning that it is logarithmic in the size of the private input w. More specifically, as mentioned above, the size is poly(λ)polylog(|w|), where λ is the security parameter. A system has succinct verification (also called perfectly succinct) if, in addition to the proof being short, the verifier's running time is "fast." That is, it is logarithmic in both the size of the program P and the size of the private input w. Thus, the running time takes poly(λ)polylog(|x|+|w|) steps.

[0074] 4.1 On-chain SNARK Verification 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 exists a script [SNARK verify] that implements the verifier SNARK.verify. For example, in the case of pairing-based SNARKs, the verifier consists of evaluating a small number of pairings on elliptic curves. The pairings may be implemented using a set of finite field arithmetic opcodes built into the BSV scripting language. In the case of hash-based SNARKs, the verifier may be implemented primarily using the opcode OP_SHA256.

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

[0076] Therefore, <π> <x> <vk>[SNARK verify] pushes "True" onto the top of the stack if approval ← SNARK.verify(vk, x, π), otherwise pushes "False" (0 or -0).

[0077] 5. Simple Transaction Integrity - STI Mechanism The STI mechanism is a binding commitment for transactions. It has two algorithms: STI:=(commit, verify). commit(tx) → τ tx ∈{0, 1} λ When you enter a transaction, a commitment tag τ of size λ is generated. tx Output. verify(tx, τ tx ) → {accept, reject}: Given a commitment key, transaction, and tag, returns either accept or reject.

[0078] If approval ← verify(tx, commit(tx)), the mechanism is complete. It is bounded if it is infeasible to generate two transactions with the same tag. Thus, for any probabilistic algorithm A, the following holds:

number

[0079] The STI mechanism checks the integrity of the consuming transaction succinctly, which means that neither the size of the script that verifies the integrity of the consuming transaction nor the arguments of the script depend on the size of the consuming transaction.

[0080] 5.1 Simple on-chain verification Embodiments of the present disclosure may utilize STI mechanisms that can be verified on-chain, i.e., during script execution.

[0081] The STI mechanism needs to be succinct in the following sense: i. The parent transaction's locking script executes STI.verify(xtx, τ tx ) is accepted if and only if <τ tx Include the script [STI verify] as a subroutine so that [STI verify] pushes "True" onto the stack, where stx represents the spend transaction. ii. The size of [STI verify] is independent of the size of the consuming transaction. Specifically, |[STI verify]|∈O(λ), where λ is a security parameter. iii. The size of the tag is independent of the size of the consumption transaction. Specifically, |τ tx |∈O(λ).

[0082] Commitment tag τ tx To verify, the consuming transaction tx cannot be pushed onto the stack, otherwise it would violate either the second or third property above.

[0083] 5.1.2 On-chain STI mechanism example UK Patent Application GB2206039.6 describes a "dummy signature mechanism" which involves generating a "dummy" ECDSA signature on the secp256k1 curve with a signing key sk and an ephemeral key k set to 1 (sk=k=1). The message is hashed before signing, thus obtaining the binding property when SHA256 is considered as a random function.

[0084] In this case, the output of the STI commitment is set to the signature generated according to the process above: τ tx ←STI.commit(tx):= ECDSA.sign(sk:= 1, k:=1, SHA256(tx)).

[0085] The corresponding verification script is [STI verify]:= <g>Defined as OP_CHECHSIGVERIFY.

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

[0087] Note that what is passed as input to the ECDSA signing algorithm is a SIGHASH serialization of the spend transaction tx. The SIGHASH byte leaves some fields of tx unsigned and therefore unintegrity-guaranteed.

[0088] 6. Enforcing Constraints Embodiments of the present disclosure enable constraints to be enforced on consumption transactions. Figure 3 illustrates an exemplary system 300 for implementing these embodiments. 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 will be understood that this is for convenience.

[0089] Alice 103a is configured to generate a first transaction, the first transaction including 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, the second transaction including a first input including a first unlocking script. The first input of the second transaction references the first output of the first transaction. Note that "first," "second," etc. are used merely as labels and do not necessarily mean that the first output is the first logical output of the transaction, but rather that it is one possibility.

[0090] The first lock script (also called a mandatory lock script) includes a first subscript (also called a commitment subscript) and a second subscript (also called a constraint subscript). The commitment subscript may include a commitment key used to verify the transaction commitment. The constraint subscript includes a verification key used to verify the constraint proof. The transaction commitment and constraint proof are generated by Bob 103b and provided to the second (consuming) transaction's unlock script, which is used to unlock the mandatory lock script. Note that Alice 103a can generate the mandatory lock script herself or receive it from a third party.

[0091] The transaction commitment generated by Bob 103b is a commitment to a second transaction. The transaction commitment is generated based on the second transaction. The commitment subscript is configured to verify that the transaction commitment was generated based on the second transaction. In some examples, a commitment key is used to verify the transaction commitment. The commitment key may be a public key, and the transaction commitment may be a digital signature generated using a private key corresponding to the public key. In some examples, the private key is the integer 1. A signature generated using a private key set to 1 is referred to herein as a "dummy signature."

[0092] After the commitment subscript verifies that the transaction commitment was indeed generated based on the second transaction, it can provide the transaction commitment to the constraint subscript, which can then use the transaction commitment as part of input verification of the constraint proof.

[0093] The constraint proof generated by Bob 103b provides verifiable proof that the second (committed) transaction satisfies one or more constraints. The constraints may be hard-coded by a constraint subscript. The constraint subscript is configured to use a verification key to verify that the constraint proof proves that the constraints are indeed satisfied. In some examples, the constraints may be hard-coded by public inputs, i.e., inputs that appear in the lock script and are pushed onto the stack during execution. It is not excluded that public inputs may also be included in the unlock script of the second transaction. In these examples, the constraint subscript may use the public inputs to verify that the constraint proof provides proof that the second transaction satisfies the constraints.

[0094] In some examples, the verification key has a corresponding evaluation key, and Bob 103b uses the evaluation key to generate a constraint proof. In these examples, the constraint subscriber can use the verification key to verify that the constraint proof was generated using the evaluation key. Alice 103a can send the evaluation key to Bob 103b.

[0095] Proofs and proof verification can use a non-interactive zero-knowledge proof algorithm, also known as SNAR. Any suitable SNARK may be used. Constrained proofs may be generated using a SNARK proof algorithm. Proofs may be verified using a SNARK verification algorithm. Thus, in these examples, the constrained subscript is configured to run the SNARK verification algorithm. Bob 103b runs the proof algorithm off-chain, for example, using an evaluation key.

[0096] In general, the constraints enforced by the mandatory locking script may impose limits on one or more inputs and / or one or more outputs of the second transaction, which may include imposing limits on the number of inputs and / or outputs, the format of the inputs and / or outputs, and / or the content of the inputs and / or outputs.

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

[0098] As another example, one of the enforced constraints may be that the second transaction has an input that references a specific output of a specific previous transaction, or any output of a specific previous transaction. Additionally or alternatively, one of the enforced constraints may be that the second transaction links to a specific previous transaction via one or more previous transactions. In other words, the second transaction must belong to a chain of transactions with a given ancestor. In the context of tokens, the second transaction may be required to link to a token minting transaction or token issuance transaction that includes token metadata defining the token, such as an NFT.

[0099] In some examples, the token issuance transaction includes token metadata for the first time. The first transaction may be a token mint transaction that enforces the terms of the token protocol via a mandatory locking script and transfers ownership of the token to a particular 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 linked to the token mint transaction.

[0100] The mandatory locking script may include a transfer subscript. The transfer subscript may be locked to a public key or a hash of a public key and require the second transaction's unlocking script to include a signature corresponding to the public key. For example, the transfer subscript may include a P2PK (pay-to-public-key) script or a P2PKH (pay-to-public-key-hash) 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 a private key corresponding to his public key and include that signature in the second transaction's unlocking script.

[0101] In some examples, the second transaction includes an output locked to a particular public key, for example, a public key associated with Alice 103a or Bob 103b. In the context of tokens, this may be used to promote fair trading, whereby Alice 103a is guaranteed payment by transferring tokens to Bob 103b.

[0102] Similarly, a second transaction may be required to include an output locked to the same public key as the previous output that the second transaction's input references. In other words, the second transaction has an input that references a previous output, and 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 is sometimes used to ensure that tokens cannot be burned.

[0103] In some examples, the second transaction may be required to include an output that locks a predetermined amount or percentage of the native blockchain token (i.e., the blockchain's underlying digital asset, such as BSV). For example, the second transaction may include an output that locks an initial amount (e.g., to a public key controlled by Bob 103b). The second transaction may be required to include an output that locks a second amount, which may be the predetermined amount or a predetermined percentage of the initial 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 may be fixed by a forced locking script, which will cause all future spend transactions to lock the digital asset amount to the fixed public key. In the context of tokens, this may be used to enforce royalties paid to the token issuer. As described in the next section, embodiments of the present disclosure may be used to issue a variety of tokens, including limited edition tokens and non-burnable tokens.

[0104] 7. Simple Constraint Enforcement - REFTX Mechanism This section describes one embodiment of the embodiment described above.

[0105] 7.1 Constraints as NP predicates Let P be a program (constraint) whose correct execution must be proven for public inputs (stx, y) and private inputs w, where stx denotes a consumption transaction. The predicate to be proven is: Predicate P P (stx) : "Given a public string y, and knowing a proof w, there is a program P((y, stx); w)=1, where stx is a consuming transaction."

[0106] Predicate P P (stx) is always related to the consuming transaction stx, and not to any (possibly off-chain) transactions.

[0107] General predicate P P (stx) can be embodied in several ways, for example (informally):

[0108] A program P with an explicit public string y contains something like: "The string y is the field 'Field' of the consuming transaction stx." A consuming transaction may also be replaced by its i-th ancestor: "Let y(y', i), then the string y' is the field 'Field' of the i-th ancestor consuming transaction stx." Or, more complex statements like: "Let y := (y1, y2), then the consuming transaction stx has two outputs, the lock script for the first output is a P2PK with public key y1, and the lock script for the second output contains y2 as op-return data."

[0109] Programs with an empty public string y include statements like: "Consuming transaction stx has three output points" and "The lock script of the first output of consuming transaction stx is identical to the lock script of the transaction referenced in that first output point."

[0110] 7.2 Proving concise predicates As currently defined, the above predicate P P (stx) A program (parameterized by P) defines a spending transaction stx as part of its public input. This means that an on-chain SNARK verifier also takes stx as input, so stx must be on the stack (no conciseness). Another issue is that we need to ensure that a transaction tx such that P((y, tx);w) = 1 is a spending transaction stx and not some other transaction.

[0111] The SNARK scheme is set up to prove the correct execution of an augmented program that takes a transaction as private input (which solves the first problem) and an STI commitment tag τ as public input (which solves the second problem).

[0112] Extension Program

number

[0113] Gadget STI (τ; (tx, w STI )) checks the correct zero-knowledge generation of the STI commitment algorithm. The public input is a tag τ, and the private inputs are a transaction tx and an additional value w STI Receive: Gadget STI (T; (tx, w STI ))=1 if and only if STI.commit(tx)=τ.

[0114] Extension Program

number

number

[0115] 7.3 Validation Script The consuming transaction stx actually satisfies the predicate P P (stx) The script to verify that P is satisfied (also called the REFTX script) is defined as follows:

number

[0116] The REFTX script is an example of a mandatory locking script, as described in Section 6. The STI verification script is an example of a commitment subscript, as described above.

number

[0117] where:

number

number

[0118] As mentioned above, the description of the preprocessing SNARK verification algorithm SNARK.verify (which has a corresponding script [SNARK verify]) is independent of the program being verified. In fact, we do not know that P has been verified until we input the corresponding verification key into the verifier.

number

number

number

[0119] This is similar to hard-coding a public key in a P2PK script to ensure that funds are sent to the correct address. If y is empty, the REFTX script is not bound to OP_CAT (because the only public input to program P is the tag τ).

[0120] If the logic required about y is expensive to prove with zero-knowledge, it can be done in the script. For example, hashing a transaction field y is faster (a single opcode) in the script than doing it off-chain with zero-knowledge, since the prover would be forced to use expensive gadgets (for hashing). The prover only needs to prove with zero-knowledge that y is indeed part of the transaction.

[0121]

Number

[0122] 7.4 REFTX Using Dummy Signatures When the dummy signature technique described in Section 5.1.2 is used as the STI mechanism, the REFTX script is transformed as follows:

Number

[0123] Extended Program

Number

[0124] Extended Program

Number

[0125] The script [enforce constraint P] is input.

number

[0126] 8. MINER-VALIDATED TRANSACTIONS Embodiments of the present disclosure can be used to implement a minor validated token protocol. First, we define a non-fungible token (NFT) scheme as the following triplet of algorithms: NFT := (Mint, TransferOwnership, ValidateTransfer)

[0127] Some previous NFT schemes rely on off-chain validation, which poses the problem that malicious users can disrupt the chain of ownership by not adhering to transaction formats. This problem is prevented by shifting the task of validation to miners (i.e., blockchain nodes 104).

[0128] The REFTX mechanism is utilized to allow miners to validate transactions without causing transaction inflation.

[0129] 8.1 Transfer and Token Validation ValidateTransfer Algorithm This is implemented in a script and is executed as part of the normal validation of a transaction. When the ownership of a token tk is transferred from sender S to receiver R, transaction tx S→R This transaction is validated by publishing it to the blockchain. The first output of this transaction is locked with the following script: [validate transfer of tk to PK R ]:= [P2PK PK R ][enforce constraint P_NFT]

[0130] The P2PK part of the script ensures that the tokens are controlled by the recipient R. The rest of the script is the REFTX mechanism described above, which allows transactions tx S→R is linked to the issuing transaction tx0, NFT This is ensured by enforcing the correct execution of the following program:

[0131] TransferOwnerShip Algorithm To transfer token tk, sender S executes transaction tx S→R must prove that the token is linked to the issuing transaction.

[0132] Off-chain steps: 1) The sender sends a transaction, tx S→R Correctly generate: tx S→R and its first output is [validate transfer of tk to PK R ] Locked by script. The sender generates the unlock script as follows: 2) Penalty kick S The transaction is signed with the signing key corresponding to the signature σ S is obtained. 3) (signal)tx S→R Generate an STI tag τ of 4) Evaluation Key (generated at the time of issuance)

number

number

[0133] 8.2 Optimized script for transfer validation By using dummy signatures as an STI mechanism, the constraint enforcement subroutines of the P2PK script and the transfer validation script can be combined into a single subscript. R is used in the constraint enforcement script in place of the dummy public key.

[0134] The following script saves a few opcodes compared to the one in the previous section:

number

[0135] 8.3 Example NFT Program In this section, we will look at two example NFT programs.

number

[0136] 8.3.1 Program 1 The following (informally stated) program P NFT Consider: "Given transaction tx as input, its first output point either references issuing transaction tx0, or references an on-chain non-coinbase transaction parent_tx for which this statement is true."

[0137] Note the recursive nature of this statement: P NFT If an input transaction to a transaction has not consumed the issuing transaction, then its parent transaction or one of its ancestors must consume the issuing transaction, ensuring that the chain of ownership is maintained.

[0138] The issuer uses the issue transaction identifier txid0 as follows:

number

[0139] Extension Program

number

[0140] Program P written in step 2 NFT hardcodes the txid0 of the issuing transaction (which is already on-chain). The reason why the verification key vk is passed as the evidence and its hash is passed as the public input is a technical problem inherited from recursive SNARKS: the size of the verification key for any program is strictly larger than the size of its public input. Therefore, the public input for the program cannot contain the verification key. This problem is usually solved by passing a hash (of a fixed size) of the verification key and relying on collision resistance to ensure that the right key is used to verify the evidence internally. The hash used should preferably be a zero-knowledge friendly algorithm. The basic program P NFT is the STI tag τ of the parent transaction parent_tx is correct (Step 2.ci). This means that the evidence is correct for the input τ parent_tx is validated, so the script is actually an extended transaction for the parent transaction.

number

[0141] 8.3.2 Program 2 Alternatively, the script can use the following predicate P' on the consuming transaction: NFT It can be proven that:

[0142] "Given a transaction tx as input, its first output point either to the issuing transaction tx0, or it references an on-chain non-coinbase transaction parent_tx, whose first output is locked with the same script as the first output of tx, and that script is [P2PK PK R ][enforce constraint P' NFT ] is.”

[0143] P' NFT The definition of REFTX script [enforce constraint P' NFT ]. There is no circularity problem here, and the predicate is well defined, because only the script "template" is checked, not the variables (in fact, the statement P' NFT does not specify that the verification key vk is a specific one). More specifically, the circularity problem can arise within the script of the SNARK verifier SNARK.verify. However, in a fixed SNARK scheme, the exact steps of the verification algorithm are known, and therefore the exact opcodes snark_opcodes := {SNARK.Verify opecode} that describe the algorithm are known and checked. As mentioned above, the preprocessing SNARK verifier checks one or another program using different verification keys.

[0144] The (extended) program is defined as follows:

[0145] Extension Program

number

[0146] Difference from Program 1: Prover efficiency is improved. The task of validating previous transfers between users is delegated to miners. As a result, Program

number

number

[0147] 8.4 Minting The minting mechanism described in this section transforms the scheme in Section 8.1 into a true atomic swap: while the issuer must guarantee the authenticity of the token, the issuer need not be present when trading tokens between two parties.

[0148] Step 1 – Issue Transaction The original owner (issuer) creates an issue transaction tx0 and embeds the (non-fungible) token tk in it as OP_RETURN data. Then, tx0 is uploaded to the blockchain as a P2PK transaction, and the token is transferred to a public key PK controlled by the issuer. Issuer "Send" to.

[0149] Step 2 - Generate a key for your NFT program The issuer uses the issue transaction identifier txid0 to execute the extension program outlined in Section 8.3.

number

[0150] Step 3 - Mint transaction tx →Issuer Generation of The issuer is [STI verify]

number

number

[0151] This is the first transaction to trade the token: tx →Issuer This is done through a minting transaction. The token is issued using a public key PK, which is controlled by the issuer. I Once this transaction is confirmed on the blockchain, the minting process is complete and the tokens become tradable. In this example, the issuer funds the issue and mint transactions.

[0152] FIG. 5 shows an example transaction for minting a token.

[0153] program

number

number

[0154] How can a receiver R be sure that he owns a token tk? One way is for R to receive tx S→R Issue transaction tx0 or mint transaction tx →Issuer The first approach is to trace all the way back to the origin. Another approach is for a trusted party to attest to the origin, but this does not provide atomic transactions. This section describes alternative mechanisms that avoid relying on these.

[0155] Implicitly, tk is the number of transactions for each tx S→R appeared in, which is an expansion program

number

number

[0156] Transaction tx S→R must be chained such that tx0 satisfies the following conditions: (i) the proof πNFT is validated (tx S→R appears on-chain to the minter), and (ii) the verification key vk is correct, i.e., vk is the key generated by the issuer during the minting process.

[0157] The receiver R receives tx S→R Once confirmed on the blockchain, we perform two checks: 1) The receiver is tx S→R The embedded script [validate transfer tk to PK R ] is correctly formed. This is [P2PK PK R ] and [enforce constraint P] are well known and can be checked. 2) The recipient has his / her public key PK R and check that the correct verification key vk is embedded in the script. The correct verification key is mint transaction tx →Issuer The user obtains the issuer's public key PK I can be used to identify the mint transaction.

[0158] If the check passes, the receiver can pay the sender for the token.

[0159] With this embodiment of the minting process, receiver R extracts two transactions from the blockchain instead of the entire transaction chain: the last transaction tx S→R and the first transaction tx →Issuer (Mint transaction), you only need to obtain

[0160] The authenticity of the token is determined by the issuer's public key PK embedded in the mint transaction. I is given by

[0161] 8.5 Completely fair dealing In this section, we explain how to replace the algorithm TransferOwnership with an interactive process, SwapOwnershipByBitcoins, that is fair to both parties. In this process, both parties agree on the value of the token in terms of the native blockchain token (e.g., Bitcoin). Then, a transaction, tx, with two outputs: S⇔R is created. First output: Output tx from the previous section S→R Related lock scripts [validate transfer tk to PK R ]. Second output: sender's public key PK S A P2PK output indicating the agreed upon amount of digital assets locked by

[0162] The steps of SwapOwnershipByBitcoins are: 1. Sender S issues transaction tx S⇔R (no input yet) and send it to the recipient R over an off-chain channel (the channel does not need to be confidential or authenticated). 2. Receiver R performs the checks described in Section 8.5. If satisfied, he funds the transaction and signs it with his corresponding Bitcoin signing key, including all outputs (especially the first output for which he receives tokens) in the message signature using the flag SIGHASH_ALL ANYONECANPAY. He then sends the funded and signed transaction to the sender. 3. The sender checks that the output points included by the receiver are valid and have sufficient funds. If there are no problems, the sender executes the first output point unlock script (σ S , τ, π NFT ) and transfers the token tk to the recipient (as described in steps (2)-(5) of the TransferOwnership algorithm described in Section 8.1).

[0163] Figure 6 shows an example transaction to achieve fair trading. Tokens are traded in units of 9 of the native blockchain token. There may be many funding transactions, funded by different public keys / addresses.

[0164] 8.6 Royalties Issuers can require a royalty to be paid each time their token is traded. This royalty can be a fixed amount or a percentage of the amount the NFT is traded for. NFTroyalty is a trading transaction tx S⇔R has at least two outputs: the second output (the new one) converts the unit of the underlying digital asset into a public key PK controlled by the issuer, hard-coded in the program itself. Issuer Transfer to.

[0165] NFT transactions are completely fair swap transactions tx S⇔R (see Section 8.5) or one-way swap transaction tx S→R Figure 7 shows that an NFT transaction can be either tx S⇔R The royalty rate for the following cases is shown below. NFT is an arbitrary program for the NFT, for example, it can be the program described in Section 8.3. The issuer can create an extension program during the minting process.

number

[0166] Program P NFTroyalty : Public Input: At least NFT transaction stx (i.e., tx S→R or tx S⇔R ). Private input: w P . code: 1. TX S⇔R Check that there are three outputs 2. Program P NFT Check that w outputs 1 P Use. 3. If parent_txid ≠ txid0, check: a. Check that the value of the first output is a fixed fraction of the value of the second output (or at least a constant value). b. The third output is PK Issuer Check that it is locked with a P2PK containing 4. If the above checks are passed, output 1. Otherwise, output 0.

[0167] 8.7 Limited Edition In this section, we describe NFTs, which allow for the trading of copies of identical tokens. The number of copies N of a particular token tk is finite, and its specific value (the token's scarcity) is set by the issuer.

[0168] A reproduction may be an exact copy, for example, when an artist publishes N copies of the same digital art piece and sells them individually. Or it may be a collection of copies, each slightly different, such as concert tickets with seat numbers. In this case, the value of the reproduction will vary depending on its type. For example, concert tickets may have numbered seats, and the closer your seat is to the stage, the more valuable it may be.

[0169] A copy of a token tk is defined as the following triplet: tk (i) := (tk, i, replica_specific_field).

[0170] The first field indicates the token being duplicated, the second field is a serial number (counter), and the third field can be used to fill in duplicate-specific information if desired (it may be empty).

[0171] In some examples, an issuer may simply issue N copies of a token in parallel (following Section 0). However, this requires a different validation key for each copy, making transactions cumbersome (users must recognize many keys and know which key to use to transact the i-th copy). In this section, we show how to manage all copies using a single validation key.

[0172] Step 1 – Issue Transaction The issuer issues N different transactions tx0 (1) , …, tx0 (N) The i-th issued transaction tx0(i) has the i-th replica tk (i) is embedded as OP_RETURN data.

[0173] Step 2 - Key generation for the NFT program The issuer then sends the identifier (txid0 (1) ,..., txid0 (N) ) to Merkle Tree T tk Collected in RT tk Let be the root of this tree. For simplicity, let N=2 for some n. n (If N is not a power of 2, the issuer fills the last leaf of the tree with dummy data so that N' = 2 n > N leaves, where n satisfies n-1 < log2(N) < n).

[0174] Program P NFTwithReplicas manages the transaction of token duplication. This program creates an NFT transaction tx (tx := tx S→R or tx := tx S⇔R ) is the first output point of the token tree T tk It also enforces that the replica serial number i is embedded in the unlock scripts of tx and tx_parent.

number

[0175] AlgorithmCheckTreeMembership(txid, i, ap, rt tk ) → {0, 1} checks the membership of a Merkle tree. This circuit checks whether an element txid is in the tree T tk It takes four inputs: the estimated leaf txid, the leaf index i (the replica's serial number), the Merkle proof ap (the authentication path), and the tree root rt tk Then, use that information to create a route tk Recalculate ’, and rt tk = rt tk Output 1 only when ’.

[0176] The authentication path ap consists of sibling leaves (the leaf indices range from 0 to N - 1, and for odd i, the sibling leaf is the (i - 1)-th leaf, and for even i, it is the (i + 1)-th leaf), and all intermediate hashes H required to pass through the tree from bottom to top j formed by 1 ≤ j < n. The algorithm uses the sibling leaves and intermediate hashes to repeatedly recalculate the root rt tk ’. To determine the position of the input to the hash in the j-th iteration, use the j-th bit of the index i.

[0177] Expansion program

Number

[0178] Token Tree T tk Any suitable hash function can be used to generate {circumflex over (x)}.

[0179] Step 3 – Generate Mint Transactions The issuer then issues a validation script [enforce constraint P NFTwithReplicas ] and generate N mint transactions

number

[0180] Figure 8 shows an example transaction for minting two copies. The root of the token tree is hard-coded into the NFT program that validates the transfer.

[0181] 8.7.1 Re-editions Copies published together are said to belong to a particular edition. Publishers can also mint new editions over time. To impose ordering among editions, the token tree of the jth edition contains the root of the j-1th token tree as its first leaf (an empty leaf in the first edition). Figure 9 illustrates this process.

[0182] The fake reprints are generated by honestly generated mint transactions, but in all editions, the issuer's public key PK I It is always locked and can be detected. Only the publisher can initiate a reprint transaction.

[0183] 8.8 Auction-enabled NFTs This section describes the design of a minted NFT where buyers bid. After the auction ends, the issuer transfers the tokens to the buyer with the highest bid. From that point on, transfers between regular users are atomic swaps as already described. The interaction between buyer and issuer occurs offline, just like a full atomic swap.

[0184] 8.8.1 Conducting the Tender Buyer R funds his / her bid amount in NFT transaction tx Issuer⇔R To generate this transaction, the buyer uses the ID txid0 of the issue transaction tx that is already on-chain.

[0185] 8.8.2 Winner Selection The issuer reviews the list of bids received and selects a winner (usually the highest bidder). Issuer⇔Winner If there are no issues (whether the funding transaction has sufficient funds), the issuer transfers the tokens to the winner.

[0186] tx Issuer⇔Winner Once it appears on the blockchain, other transactions tx Issuer⇔R is invalid for R ≠ Winner, so the unselected bidders still have their funds unspent.

[0187] 8.8.3 Minor Validation Price Threshold Issuers can set a price below which no bids can be made, for example, at least the amount required to fund the issue transaction tx0. This price varies depending on the token.

[0188] Issuers can delegate to miners the check that a bid-based funding transaction is correct by including that check in a SNARK-enforced NFT program. This program will check that if the first output point references an issuance transaction, then the NFT transaction tx S⇔R It also checks whether the second output of has a value that exceeds a specified price threshold.

[0189] Program P NFTauction Public input: At least NFT transaction tx S⇔R and starting bid price threshold. Private input: w P . code: 1. Program P NFT Check that outputs 1 / / Use Wp 2. If parent_txid = txid0 (issue ID is hardcoded), check that the value of the second output is greater than or equal to threshold_price. 3. If the above two steps are passed, output 1, otherwise output 0.

[0190] As in the previous section, P NFT is an arbitrary program for NFTs. The threshold price is passed as a public input, so it becomes part of the unlock script, and therefore must be greater than or equal to a fixed value for a particular use case, which is enforced using the OP_GREATERTHANOREQUAL opcode, hard-coding that value into the lock script.

[0191] Alternatively, you can set the threshold price as a program P auction It can be hard-coded into itself.

[0192] 8.9 Non-burnable Tokens The NFTs described in Section 8.1 allow the transfer of tokens to meaningless outputs. For example, the current owner S can transfer tx S→R The first output of the program P NFT The NFT program P' described in Section 8.3 prevents explicit token burning. NFT Use the second instance of P' NFT Also, the first output of the spending transaction is locked with the same script and checks that the verification key is the same, making the above strategy impossible with this scheme. However, the only way to burn the tokens is to send them to a public key that is widely believed to be the one for which no one has the signing key.

[0193] Program P unburntNFT This program describes the design of P' NFT not only checks that the transaction outputs 1 (see Section 8.3), but also that the recipient knows the signing key. This program S⇔R and has exactly two outputs. This program also checks that the token is sent with the public key PK R This enforces that the first output of the funding transaction is P2PK locked with a public key matching the UTXO. The ability to unlock this UTXO ensures that the recipient knows the signing key; therefore, the token cannot be burned in the transaction. Figure 10 shows an example transaction for generating a non-burnable token.

[0194] 9. Appendix Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is limited only by the appended claims, not by the described embodiments.

[0195] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0196] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, disseminating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of disseminating and / or storing blocks without creating and publishing them (as noted above, these entities are not considered to be nodes of the preferred Bitcoin network 106).

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

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

[0199] Some embodiments are described for blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and general embodiments may use any type of suitable consensus mechanism, 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 randomized process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often called validators. Blockchain nodes can lock tokens for a certain period of time to earn the chance to become a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0200] It will be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements:

[0201] Statement 1. A computer-implemented method for enforcing constraints on blockchain transactions, the method being performed by a first party; generating a mandatory locking script for inclusion in a first output of a first blockchain transaction, the mandatory locking script including a commitment sub-script and a constraint sub-script having a verification key, the mandatory locking script, when executed together with an unlocking script of a second blockchain transaction, the unlocking script having the transaction commitment and constraint proof, the commitment subscript is configured to verify that the transaction commitment corresponds to the second blockchain transaction; the constraint subscript is configured to use the verification key to verify that the constraint proof provides proof that the committed blockchain transaction satisfies one or more constraints; A method configured to:

[0202] Statement 2. The method of claim 1 , wherein the constraint subscript and / or the unlock script include a public input, and the constraint subscript is configured to use both the verification key and the public input to verify that the constraint proof provides proof that the committed blockchain transaction satisfies one or more constraints.

[0203] Statement 3. The method of statement 1 or statement 2, wherein the commitment subscript includes a commitment key, and the commitment subscript is configured to use the commitment key to verify that the transaction commitment corresponds to the second blockchain transaction.

[0204] Statement 4. The method of any of statements 1-3, wherein the commitment subscript is configured to supply the transaction commitment proof to the constraint subscript, and the constraint subscript is configured to use the verification key, the public input, and the transaction commitment to verify that the constraint proof provides proof that the second blockchain transaction satisfies one or more constraints.

[0205] Statement 5. The method of any of statements 1 to 4, wherein the constraint subscript is configured to use a verification key to verify that the constraint proof was generated using an evaluation key corresponding to the verification key.

[0206] Statement 6. The method of any of statements 1 to 5, wherein the commitment subscript includes a non-interactive zero-knowledge proof algorithm configured to verify that a constraint proof is generated to satisfy a particular program.

[0207] Statement 7. The method of any of statements 1-6, wherein the transaction commitment includes a digital certificate, the commitment key includes a public key, and the commitment subscript is configured to verify that the digital signature signs the message based on the second blockchain transaction.

[0208] Statement 8. The method of statement 7, wherein the public key corresponds to the private key set to 1.

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

[0210] Statement 9. Including a forced lock script in a first output of a first blockchain transaction; causing the first blockchain transaction to be submitted to a second party and / or one or more nodes of the blockchain network; The method according to any one of statements 1 to 8, comprising:

[0211] Statement 10. The method of any of statement 5 or a statement dependent on statement 5, including making the evaluation key available to a second party.

[0212] Statement 11. The method of any of statements 1-10, wherein the one or more constraints impose restrictions on one or more of the format, content, and number of the one or more inputs and / or one or more outputs of the second blockchain transaction.

[0213] Statement 12. The method of any of statements 1 to 11, wherein at least one of the one or more constraints is that the committed blockchain transaction has an input that references the target transaction, or that the committed blockchain references a transaction that forms part of a chain of one or more transactions that link to the target transaction.

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

[0215] Statement 13. The method of any of statements 1-12, wherein at least one of the one or more constraints is that the committed blockchain transaction includes some or all of a forced locking script.

[0216] Statement 14. The method of any of statements 1-13, wherein at least one of the one or more constraints is that a transaction referenced by an input of the committed blockchain transaction contains a valid constraint proof linking the transaction to the target transaction, or the transaction is the target transaction.

[0217] Statement 15. The method of any of statements 1-14, wherein the mandatory locking script includes a transfer subscript, the transfer subscript has a target public key or a hash thereof, and the transfer subscript is configured to verify that the unlocking script has a signature corresponding to the target public key.

[0218] Statement 16. The method of any of statements 1-15, wherein the blockchain includes a token issuance transaction, the token issuance transaction includes token metadata, the first blockchain transaction is a token minting transaction, and an input of the token minting transaction references an output of the token issuance transaction.

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

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

[0221] Statement 19. The method of any of statement 15 or a statement dependent on statement 15, wherein the target public key is associated with a second party and the first blockchain transaction includes a second output locked to a public key associated with the first party.

[0222] Statement 20. Including in the input of a first blockchain transaction a constraint proof and a transaction commitment to unlock an output of a token minting transaction, or an output of a transaction that forms part of a chain of one or more transactions that link to the token minting transaction; sending the first blockchain transaction to a second party, the second party configured to include one or more respective inputs in the first blockchain transaction; receiving a first blockchain transaction from a second party; verifying that the first blockchain transaction includes one or more respective inputs that reference one or more respective transaction outputs locked to respective public keys of a second party; including in the input of the first blockchain transaction a signature to unlock the output of the token minting transaction or the output of a transaction that forms part of a chain of one or more transactions that link to the token minting transaction; The method according to statement 18 or statement 19, which is dependent on statement 9, including:

[0223] Statement 21. The method of any of statements 1-20, wherein at least one of the one or more constraints is that the second blockchain transaction has an output locked to a public key associated with the first party.

[0224] Statement 22. The method of any of statements 1-21, wherein at least one of the one or more constraints is that the second blockchain transaction has an output locked to a public key associated with a predetermined party, and at least one of the one or more constraints is that the output locks a predetermined amount of digital assets or a percentage of the amount of digital assets locked by a different output of the second blockchain transaction.

[0225] Statement 23. The method of any of statements 1-22, wherein the blockchain includes a plurality of respective issuance transactions, each of the issuance transactions including respective token data, the constraint subscript includes a Merkle root of a Merkle tree generated based on respective transaction identifiers of the respective issuance transactions, and at least one of the constraints is that the second blockchain transaction includes 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 that link to one of the respective issuance transactions.

[0226] Statement 24. The method of any of statements 1-22, wherein the blockchain includes a plurality of respective first issuance transactions, a first Merkle root of the first Merkle tree is generated based on a respective transaction identifier of the respective first issuance transactions, the blockchain includes a plurality of respective second issuance transactions, each of the plurality of respective second issuance transactions including respective token data, the constraint subscript includes a second Merkle root of a second Merkle tree generated based on the respective transaction identifier of the respective second issuance transaction and the first Merkle root, and at least one of the constraints is that the second blockchain transaction includes 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 that links to one of the respective second issuance transactions.

[0227] Statement 25. The method of any of statement 15 or a statement dependent on statement 15, wherein the blockchain has a transaction including a third output locked to a public key associated with a second party, the second blockchain transaction includes an input that references the third output, and 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.

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

[0229] Statement 27. A computer-implemented method for generating blockchain transactions that satisfy constraints, wherein a first blockchain transaction has an output including a forced locking script, the forced locking script including a transaction commitment subscript and a constraint enforcement subscript including a verification key, the commitment subscript configured to verify that a candidate transaction commitment corresponds to the candidate blockchain transaction, and the constraint subscript configured to verify, using the verification key, that the candidate constraint proof provides proof that the candidate blockchain transaction satisfies one or more constraints, the method being performed by a second party; generating at least a portion of a second blockchain transaction, the second blockchain including an input that references an output of the first blockchain transaction, and the second blockchain transaction satisfying one or more constraints; generating a transaction commitment based at least in part on the second blockchain transaction; generating a constraint proof based on the second blockchain transaction, the constraint proof providing proof that the second blockchain transaction satisfies one or more constraints; including the transaction commitment and the constraint proof in an input unlock script of a second blockchain transaction; A method comprising:

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

[0231] Statement 29. The method of statement 27 or statement 28, wherein the constraint subscript includes a non-interactive zero-knowledge proof algorithm, the non-interactive zero-knowledge proof algorithm is configured to verify that the candidate constraint proof was generated using a corresponding non-interactive zero-knowledge proof algorithm, and the method includes generating the constraint proof using the non-interactive zero-knowledge proof algorithm.

[0232] Statement 30. The method of any of statements 27-29, wherein the commitment subscript includes a public key, and generating the transaction commitment includes generating a digital signature based on the second blockchain transaction using a private key corresponding to the public key.

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

[0234] Statement 32. The method of any of statements 27-31, including causing the second blockchain transaction to be submitted to the first party and / or one or more nodes of the blockchain network.

[0235] Statement 33. In a method in which the mandatory locking script includes a transfer subscript, the transfer subscript includes a target public key or a hash thereof, and the transfer subscript is configured to verify that the unlocking script has a signature corresponding to the target public key, the method further comprises: generating a signature using a private key corresponding to the target public key; including a signature in the unlock script of the second blockchain transaction; A method according to any one of statements 27 to 32, comprising:

[0236] Statement 34. Including the transaction commitment and constraint proof in the unlock script of the input of the second blockchain transaction verifying that the mandatory locking script complies with one or more predetermined conditions; A method according to any of statements 27 to 33, conditioned on verifying that the verification key corresponds to a predetermined evaluation key.

[0237] Statement 35. Including the transaction commitment and constraint proof in the unlock script of the input of the second blockchain transaction The method of either statement 33 or statement 34, wherein the method is conditioned on verifying that the target public key is a public key owned by the second party.

[0238] Statement 35. A memory including one or more memory units; a processing unit including one or more processing units, A computing device, wherein the memory stores code configured to execute on a processor, the code configured, when executed on the processor, to perform the method recited in any of statements 1 to 34.

[0239] Statement 36. A computer program embodied on computer-readable storage, the computer program being configured to, when executed on one or more processors, perform the method of any of statements 1-34.

[0240] In another aspect disclosed herein, a method may be provided that includes actions of a first party and a second party.

[0241] In another aspect disclosed herein, a system may be provided that includes first party and second party computer devices. [Explanation of symbols]

[0242] 101 Internet, packet-switched networks 102 Computer terminals and equipment 103 users 104 blockchain nodes 105 Client Applications 106 P2P networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output< / g> < / vk> < / x>

Claims

1. 1. A computer-implemented method for enforcing constraints on blockchain transactions, the method being performed by a first party and comprising: generating a mandatory locking script for inclusion in a first output of a first blockchain transaction, the mandatory locking script including a commitment sub-script and a constraint sub-script having a verification key, the mandatory locking script, when executed together with an unlocking script of a second blockchain transaction, the unlocking script having the transaction commitment and constraint proof, the commitment subscript is configured to verify that the transaction commitment corresponds to the second blockchain transaction; the constraint subscript is configured to use the verification key to verify that the constraint proof provides proof that a committed blockchain transaction satisfies one or more constraints; A method configured to:

2. 2. The method of claim 1, wherein the constraint subscript and / or the unlock script include a public input, and the constraint subscript is configured to use both the verification key and the public input to verify that the constraint proof provides proof that a committed blockchain transaction satisfies the one or more constraints.

3. 3. The method of claim 1 or claim 2, wherein the commitment subscript includes a commitment key, and the commitment subscript is configured to use the commitment key to verify that the transaction commitment corresponds to the second blockchain transaction.

4. 4. The method of claim 1, wherein the commitment subscript is configured to provide a transaction commitment proof to the constraint subscript, and the constraint subscript is configured to use the verification key, a public input, and the transaction commitment to verify that the constraint proof provides proof that the second blockchain transaction satisfies the one or more constraints.

5. 5. The method of claim 1, wherein the constrained subscript is configured to use the verification key to verify that the constrained proof was generated using an evaluation key that corresponds to the verification key.

6. 6. The method of claim 1, wherein the commitment subscript comprises a non-interactive zero-knowledge proof algorithm configured to verify that the constraint proof is generated to satisfy a particular program.

7. 7. The method of claim 1, wherein the transaction commitment comprises a digital certificate, the commitment key comprises a public key, and the commitment subscript is configured to verify that a digital signature signs a message based on the second blockchain transaction.

8. The method of claim 7 , wherein the public key corresponds to a private key set to 1.

9. including the forced locking script in the first output of the first blockchain transaction; causing the first blockchain transaction to be submitted to a second party and / or one or more nodes of a blockchain network; The method according to any one of claims 1 to 8, comprising:

10. 6. A method according to claim 5 or any claim dependent thereon, comprising making the evaluation key available to a second party.

11. 11. The method of claim 1, wherein the one or more constraints impose restrictions on one or more of the format, content, and number of one or more inputs and / or one or more outputs of the second blockchain transaction.

12. 12. The method of claim 1, wherein at least one of the one or more constraints is that the committed blockchain transaction has an input that references a target transaction, or that the committed blockchain transaction references a transaction that forms part of a chain of one or more transactions that link to the target transaction.

13. 13. The method of claim 1, wherein at least one of the one or more constraints is that the committed blockchain transaction includes some or all of the forced locking script.

14. 14. The method of any one of claims 1 to 13, wherein at least one of the one or more constraints is that a transaction referenced by an input of the committed blockchain transaction contains a valid constraint proof linking the transaction to a target transaction, or that the transaction is the target transaction.

15. 15. The method of claim 1, wherein the mandatory locking script includes a transfer subscript, the transfer subscript having a target public key or a hash thereof, and the transfer subscript is configured to verify that the unlocking script has a signature corresponding to the target public key.

16. 16. The method of any one of claims 1 to 15, wherein a blockchain includes a token issuance transaction, the token issuance transaction includes token metadata, the first blockchain transaction is a token minting transaction, and an input of the token minting transaction references an output of the token issuance transaction.

17. 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. 16. The method of any one of claims 1 to 15, wherein a blockchain includes a token issuance transaction, the token issuance transaction including token metadata, the blockchain includes a token minting transaction, an input of the token minting transaction references an output of the token issuance transaction, and an input of the first blockchain transaction references an output of the token minting transaction or an output of a transaction that forms part of a chain of one or more transactions that link to the token minting transaction.

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

20. including in the input of the first blockchain transaction a constraint proof and a transaction commitment to unlock the output of a token minting transaction, or an output of a transaction that forms part of a chain of one or more transactions that link to the token minting transaction; sending the first blockchain transaction to a second party, the second party configured to include one or more respective inputs in the first blockchain transaction; receiving the first blockchain transaction from the second party; verifying that the first blockchain transaction includes one or more respective inputs that reference one or more respective transaction outputs locked to respective public keys of the second party; including in the input of the first blockchain transaction a signature to unlock the output of the token minting transaction or an output of a transaction that forms part of a chain of one or more transactions that link to the token minting transaction; 20. The method of claim 18 or claim 19 dependent on claim 9, comprising:

21. 21. The method of any one of claims 1 to 20, wherein at least one of the one or more constraints is that the second blockchain transaction has an output locked to a public key associated with the first party.

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

23. 23. The method of any one of claims 1 to 22, wherein the blockchain includes a plurality of respective issuance transactions, each of the issuance transactions including respective token data, the constraint subscript includes a Merkle root of a Merkle tree generated based on respective transaction identifiers of the respective issuance transactions, and at least one of the constraints is that the second blockchain transaction includes 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 that link to one of the respective issuance transactions.

24. 23. The method of claim 1, wherein the blockchain includes a plurality of respective first issuance transactions, a first Merkle root of a first Merkle tree is generated based on a respective transaction identifier of the respective first issuance transactions, the blockchain includes a plurality of respective second issuance transactions, each of the plurality of respective second issuance transactions including respective token data, the constraint subscript includes a second Merkle root of a second Merkle tree generated based on the respective transaction identifier of the respective second issuance transactions and the first Merkle root, and at least one of the constraints is that the second blockchain transaction includes 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 that links to one of the respective second issuance transactions.

25. 16. The method of claim 15 or any one of claims dependent on claim 15, wherein a blockchain has a transaction including a third output locked to a public key associated with a second party, the second blockchain transaction includes an input that references the third output, and 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. 20. The method of claim 19 or any one of claims dependent on claim 19, wherein at least one of the one or more constraints is to lock the amount of the digital asset such that the second output is equal to or greater than a threshold amount.

27. 1. A computer-implemented method for generating blockchain transactions that satisfy constraints, wherein a first blockchain transaction has an output including a mandatory locking script, the mandatory locking script including a transaction commitment subscript and a constraint enforcement subscript including a verification key, the commitment subscript configured to verify that a candidate transaction commitment corresponds to a candidate blockchain transaction, and the constraint subscript configured to verify, using the verification key, that a candidate constraint proof provides proof that the candidate blockchain transaction satisfies one or more constraints, the method being performed by a second party; generating at least a portion of a second blockchain transaction, the second blockchain including an input that references the output of the first blockchain transaction, and the second blockchain transaction satisfying 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, the constraint proof providing proof that the second blockchain transaction satisfies the one or more constraints; including the transaction commitment and the constraint proof in an unlock script for the input of the second blockchain transaction; A method comprising:

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

29. 29. A method according to claim 27 or claim 28, wherein the constraint subscript comprises a non-interactive zero-knowledge proof algorithm, the non-interactive zero-knowledge proof algorithm being configured to verify that the candidate constraint proof was generated using a corresponding non-interactive zero-knowledge proof algorithm, and the method comprises generating the constraint proof using the non-interactive zero-knowledge proof algorithm.

30. 30. The method of any one of claims 27 to 29, wherein the commitment subscript includes a public key, and generating the transaction commitment includes generating a digital signature based on the second blockchain transaction using a private key corresponding to the public key.

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

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

33. the mandatory locking script includes a transfer subscript, the transfer subscript includes a target public key or a hash thereof, and the transfer subscript is configured to verify that the unlocking script has a signature corresponding to the target public key; generating a signature using a private key corresponding to the target public key; including the signature in the unlock script of the second blockchain transaction; 33. The method of any one of claims 27 to 32, comprising:

34. Including the transaction commitment and the constraint proof in an unlock script for the input of the second blockchain transaction, verifying that the mandatory locking script complies with one or more predetermined conditions; verifying that the verification key corresponds to a predetermined evaluation key; The method of any one of claims 27 to 33, conditioned on:

35. Including the transaction commitment and the constraint proof in an unlock script for the input of the second blockchain transaction, 35. The method of claim 33 or claim 34, conditioned on verifying that the target public key is a public key owned by the second party.

36. a memory including one or more memory units; 35. A computing device comprising: a processing device including one or more processing units; wherein the memory stores code configured to run on the processing device, the code being configured, when executed on the processing device, to perform the method of any one of claims 1 to 34.

37. A computer program embodied on a computer readable storage, the computer program being configured to perform the method of any one of claims 1 to 34 when executed on one or more processors.

Images