Computer-Implemented Method and System

Abstract

A computer-implemented method for issuing digital tokens using a blockchain, the method being executed by a token issuer and comprising: sending an issuance transaction to one or more nodes of a blockchain network, the issuance transaction being signed by the token issuer and comprising a first token identifier, the first token identifier being based on at least first token data related to the first token; obtaining a first proof of inclusion that certifies that the issuance transaction is recorded on the blockchain; and maintaining a database comprising the first token identifier mapped to the issuance transaction and the first proof of inclusion, the database being made available to one or more token users.

Description

[Technical Field]

[0001] The present disclosure relates to methods and systems for issuing and validating blockchain-based digital tokens. [Background technology]

[0002] One emerging use of blockchain is to issue "tokens," which may represent, for example, some amount of fiat currency in a central bank digital currency (CBDC) system, a digital identity, a unique work of digital art, an event ticket, stock in a company, or a physical asset such as materials in a supply chain.

[0003] To verify whether a transaction involving a token is valid, one must typically verify that the transaction satisfies both the rule sets prescribed by the associated token system and the underlying blockchain regulations. It is also necessary to verify the "provenance" of the token, i.e., its history since issuance. This process becomes more difficult as the distance between the token issuance and the current transaction increases as each new transaction is generated for the token. This is called the back-to-genesis problem or traceback problem.

[0004] Consider the example chain of transactions shown in Figure 5. In this simplest case, each transaction has one input and one output. The first transaction, Tx0, is an issuance transaction that creates (mints) a token. Each subsequent transaction consumes the output of the previous transaction and represents a transfer of ownership of the token. This is called a transaction chain. A valid transaction under both the blockchain rule set and the token rule set is Tx0. n The receiver also receives Txn is an unbroken chain of transactions Tx0, ..., Tx n and the chain Tx0, ..., Tx n-1 The first step is to verify that all preceding transactions in are valid under both the blockchain rules and the token rules. As detailed below in Section 3.3, there are currently several approaches to validating token chains, each of which has its associated problems. This disclosure provides a novel solution that addresses these problems. Summary of the Invention [Means for solving the problem]

[0005] According to one aspect disclosed herein, there is provided a computer-implemented method for issuing digital tokens using a blockchain, the method being executed by a token issuer and comprising: sending an issuance transaction to one or more nodes of a blockchain network, the issuance transaction being signed by the token issuer and comprising a first token identifier, the first token identifier being based on at least first token data related to the first token; obtaining a first proof of inclusion that certifies that the issuance transaction is recorded on the blockchain; and maintaining a database comprising the first token identifier mapped to the issuance transaction and the first proof of inclusion, the database being made available to one or more token users.

[0006] According to another aspect disclosed herein, there is provided a computer-implemented method for validating an issued digital token using a blockchain, the blockchain comprising an issuance transaction signed by a token issuer and comprising a first token identifier, the first token identifier being based on at least first token data related to the first token, the method being performed by a token validator and comprising: obtaining a target transfer transaction, the target transfer transaction being a final transaction in a chain of one or more respective transfer transactions linked back to the issuance transaction, the target transfer transaction comprising the first token identifier; and obtaining a database, the database comprising a database linked to the issuance transaction. and determining that the target transfer transaction comprises a valid token by performing at least the following: i) using the first proof of inclusion to verify that the issuance transaction is recorded on the blockchain; ii) using the target proof of inclusion to verify that the target transfer transaction is recorded on the blockchain; and iii) verifying that the target transfer transaction is linked to the issuance transaction.

[0007] Embodiments of the present disclosure provide techniques for issuing tokens that can be efficiently validated, and techniques for efficiently validating said tokens.

[0008] The described token system allows for "offline" transfer of tokens, as the transfer does not require the involvement of (and therefore connection to) a central authority (i.e., the token issuer). All of the information needed to validate a token is made available to the token recipient as a (distributed) hash table, which can be shared peer-to-peer among token users.

[0009] A database (e.g., a hash table) stores Merkle proofs of issuance and transfer transactions that can be used to prove that the target (e.g., most recent) transfer transaction is recorded on the blockchain. By verifying that the target transfer transaction and the issuance transaction are recorded on the blockchain and that the target transfer transaction is linked to the issuance transaction, the token receiver can be confident of the origin of the associated token. For added certainty, the token receiver may verify the existence of each transaction in the chain of transactions that links the target transfer transaction to the issuance transaction.

[0010] To assist in understanding 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]

[0011] [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 in a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of an exemplary system for issuing and validating tokens. [Figure 4] FIG. 1 shows a schematic diagram of a chain of token transactions. [Figure 5]FIG. 1 shows a schematic diagram of a chain of token transactions. [Figure 6] FIG. 1 is a schematic diagram of an exemplary Merkle tree. [Figure 7] FIG. 7 is a schematic diagram illustrating an exemplary Merkle path for the Merkle tree shown in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0012] 1. Token Issuance and Activation As an illustrative example, consider a central authority (e.g., a central bank) that wants to issue a token (e.g., a digital currency). However, if the token were to be transferred without the central authority signing the transaction (which would have the advantage of making the process simple and efficient), a problem arises because without the central authority's signature, the recipient of the token cannot be sure that the token is valid. Instead, the recipient must trace back the received (i.e., most recent) transaction to the issuance transaction that issued the token. This is resource intensive and is called the traceback problem / back-to-genesis problem.

[0013] A central authority may choose to issue tokens as fungible tokens. However, a problem with fungible tokens is that for any given token transaction, the transaction may reference multiple previous transactions. As more and more tokens are transferred, there becomes an ever-increasing number of transactions to check.

[0014] Therefore, a central authority may choose to issue non-fungible tokens instead, where every token has only one previous transaction, or more precisely, each token is associated with only one input (and therefore only one previous transaction output). Note that a given token transaction may still involve multiple tokens. Thus, the task of checking the transaction chain back to issuance becomes linear in the size of the chain. In other words, there are not as many previous transactions to check for validity compared to fungible tokens.

[0015] The embodiments described herein provide an efficient mechanism for validating tokens. FIG. 3 illustrates an exemplary system 300 for implementing the described embodiments. The system 300 includes a token issuer 301 responsible for issuing tokens according to a token protocol, and multiple token users 302. While only two token users 302a, 302b are illustrated, it will be appreciated that the system 300 may include any number of token users 302. The system 300 also includes one or more nodes 104 of a blockchain network 106, e.g., an exemplary network 106 described below. For simplicity, the first token user 302a is referred to as Alice 103a, and the second token user 302b is referred to as Bob 103b. In general, each token user 302 may be configured to perform any of the actions described below as being performed by Alice 103a and / or Bob 103b.

[0016] The token issuer 301 may be any type of entity, for example, a user, a group of users, a business, a government organization, a bank, an event organizer, etc. The token issuer 301 may issue any number of tokens, but for simplicity, the present embodiment is described with respect to issuing a single token.

[0017] The token issuer 301 generates an issuance transaction to issue a token. The token may be a non-fungible token. The issuance transaction includes a token identifier value (e.g., a token hash value). The token identifier is a unique (and preferably concise) identifier for the token. For example, the token hash value may be generated by hashing token data for the token. In this example, the token data itself may include the token's identifier but may not include the hash value. The token data may include the rules of the token protocol. The token data may specify one or more characteristics of the token. The token data may be included in the transaction or may be stored elsewhere, either on-chain or off-chain. Other examples of token identifiers include a Pederson commitment of the token data or a uniform resource locator (URL) referencing the token data, e.g., a web page containing the token data. In general, any commitment or reference to token data may be used as long as it is unique to the corresponding token.

[0018] The issuance transaction is signed by the token issuer 301. That is, the issuance transaction includes a signature generated using a private key controlled by the token issuer 301. The private key may correspond to a known public key to be associated with the token issuer 301. The public key may be certified as being associated with the token issuer 301.

[0019] The issuance transaction may be locked to a recipient, e.g., Alice 103a. That is, to transfer the token, Alice 103a may have to provide data that only Alice 103a can provide. In some examples, the issuance transaction may alternatively or additionally be locked to the token issuer 301. In the former case, a first transfer transaction (described below) is created by the token issuer 301 to transfer the token to a token user 302, such as Alice 103a.

[0020] When using a UTXO-based blockchain, an issuance transaction may have an input ("token input") that includes the token issuer's signature, and an output ("token output") that is locked to the recipient's public key, e.g., Alice's public key. A token hash may be included as part of the token output or as part of a different output. The token input and token output may be linked, e.g., they may occupy the same position in the transaction's list of inputs and list of outputs. That is, they may have the same input index and output index. As an example, the token input may be the first input of the transaction, and the token output may be the transaction's first output. In some examples, the token issuer's signature may sign the token output, or rather a message based on the token output. In some examples, the signature does not sign other inputs and / or outputs.

[0021] A token issuer 301 sends an issuance transaction to the blockchain network 106. After the issuance transaction is recorded on the blockchain 150, the token issuer 301 obtains (e.g., generates or receives from a blockchain node 104) a Merkle proof that proves that the issuance transaction is recorded on the blockchain 150. Other inclusion proofs may be used instead of Merkle proofs. Note that "Merckle proof" is used to refer to any Merkle-like proof.

[0022] The token issuer 301 maintains a database, such as a hash table. The hash table may be a distributed hash table. The database is available to the token user 302. For example, the token issuer 301 may send the database to the token user 302. The database may be stored online (e.g., in cloud storage) such that it can be accessed by the token user 302. Although examples are described primarily with respect to hash tables, in general, any suitable type of database that allows for lookup operations may be used. Unless the context requires otherwise, any reference to a "hash table" may be replaced with a "database," and any reference to a "hash value" or "token hash" may be replaced with a "token identifier."

[0023] The hash table contains token hashes (from issuance transactions) mapped to issuance transactions and Merkle proofs of the issuance transactions. Again, in general, any database may be used that maps token identifiers to issuance transactions and corresponding Merkle proofs. The hash table is used by token users 302 to validate token transactions, as described below.

[0024] Before proceeding with validation, the token issuer 301 itself may transfer the token to a token user 302, e.g., Alice 103a, as described above. For example, the token issuer 301 may generate a transfer transaction that references the issuance transaction. The transfer transaction is signed by the token issuer 301. The transfer transaction may be locked to a public key associated with Alice 103a. When using a UTXO-based blockchain, the transfer transaction has a token input that references the token output of the issuance transaction and includes the token issuer's signature. The transfer transaction includes a token output (linked to the token input), which is locked to Alice's public key using, for example, a pay-to-public-key (P2PK) or pay-to-public-key-hash (P2PKH) locking script. The transfer transaction includes a token hash.

[0025] The token issuer 301 sends the transfer transaction to the blockchain network 106 to be recorded on the blockchain 150. Alternatively, the token issuer 301 may send the transfer transaction to Alice 103a, who sends it to the blockchain network 106. In any event, the token issuer obtains a Merkle proof that proves the transfer transaction has been recorded on the blockchain 150. The token issuer 301 updates a hash table by mapping the token hash to the transfer transaction and the Merkle proof of the transfer transaction.

[0026] Similarly, each time a transfer transaction is submitted to the blockchain 150 to transfer a token between token users 302, e.g., from Alice 103a to Bob 103b, the token issuer 301 retrieves the transfer transaction and the corresponding Merkle proof and updates a database (e.g., a hash table) to map the transfer transaction and the Merkle proof to the token hash.

[0027] It will be appreciated that the database (e.g., a hash table) may contain many token identifiers (token hashes), each relating to a particular token and each mapping to one or more transactions and one or more corresponding Merkle proofs.

[0028] The process of validating a token is as follows: A token validator (e.g., a token user such as Alice 103a) obtains a target transfer transaction. For example, Alice 103a may receive the target transaction from the token issuer 301 or a different token user 302. The target transfer transaction may have a token output locked to Alice's public key 103a. The target transfer transaction includes a token hash. The target transfer transaction may include other token-related data, for example, an identifier for the token.

[0029] Alice 103a retrieves the issuance transaction and its Merkle proof using the token identifier (e.g., token hash) from a database (e.g., a hash table) maintained by the token issuer 301. Alice 103a also retrieves the Merkle proof for the target transfer transaction.

[0030] Using Merkle proofs, Alice 103a verifies that the issuance transaction and the target transfer transaction are recorded on the blockchain 150. Note again that other inclusion proofs may be used instead of Merkle proofs. Alice 103a may need block headers from the blockchain 150. One or more block headers may be obtained from the token issuer 301. One or more block headers may be obtained from the blockchain node 104. Alice 103a may already have a list of block headers.

[0031] Alice 103a also verifies that the target transfer transaction is linked to the issue transaction, i.e., Alice 103a verifies that the target transfer transaction is part of a transaction chain starting from the issue transaction (note that the issue transaction does not necessarily have to be the very start of the chain, which is usually the coinbase / create transaction). If the verification passes, Alice 103a may determine that the target transfer transaction is a valid token transaction and contains a valid token issued by the token issuer 301.

[0032] In some examples, Alice 103a may verify that the target transfer transaction is linked to the issuance transaction by retrieving each of the transfer transactions that connect the target transfer transaction to the issuance transaction. The transactions may be retrieved from a hash table. If the hash table contains a Merkle proof for each transaction, Alice 103a may also verify that each of the respective transactions is recorded on the blockchain 150.

[0033] Upon determining that the target transfer transaction is valid, Alice 103a may generate a new transfer transaction to transfer the token to a different token user 302, e.g., Bob 103b. The new transfer transaction is signed by Alice 103a. That is, Alice 103a generates a signature using her private key that signs over at least a portion of the new transfer transaction. The signature may be included in the token input of the new transfer transaction and may be used to unlock the token output of the target transfer transaction. The new transfer transaction may be locked to Bob's public key. For example, the token output of the new transfer transaction may comprise a locking script (P2PK or P2PKH) that locks the output to Bob's public key. The new transfer transaction also includes a token hash, e.g., as part of the token output or a different output.

[0034] Alice 103a sends the new transfer transaction to Bob 103b and / or the blockchain network 106. Bob 103b may perform a similar process as Alice 103a to validate the new transfer transaction.

[0035] An exemplary transaction chain created in accordance with the described embodiments is shown in Figure 4. The transaction chain begins with an issuance transaction, includes one or more transfer transactions that connect the issuance transaction to a target transfer transaction, and ends with a new (further) transfer transaction.

[0036] Compared to fungible tokens, using non-fungible tokens (NFTs) reduces the back-to-genesis problem. With NFTs, there is a single input causally linked to the new token output, so only a single input needs to be verified to verify the token history. With fungible tokens, the new token output does not provably map to a single input, so every input must be verified to prove the transaction is valid. In the context of CBDCs, using NFTs with fixed denominations may mean that more token pairs are required in a transaction to create the correct total value. This is a one-time cost in terms of increasing the number of inputs to check, but each input still has a linear transaction chain history.

[0037] The token system described herein allows validators to prove the validity of tokens with minimal computational burden on the token issuer or blockchain node 104. It does not require a trusted third party, allows users 302 to verify token transaction chains without running a full node (i.e., lightweight data storage and computing power), and is suitable for running on a mobile or laptop.

[0038] Tokens may be UTXO-based NFTs representing a fixed denomination. Token ownership and transfer may be controlled via a locking script (e.g., P2PKH). UTXOs may be signed using a single, anyone can pay (S|ACP) sighash flag.

[0039] A hash is included in each transaction (e.g., using OP_RETURN) that is linked to an external, distributed hash table (maintained by the token issuer and shared peer-to-peer among users, e.g., via Trent). The hash table contains transaction data for each transaction in the token chain and its Merkle proof. The hash table may also contain token identifier data and, optionally, additional token data, e.g., related to token functionality. Data is mapped to a hash of the token data, so that users can use the hash value to look up the associated proof and data.

[0040] The token user 302 maintains a list of block headers. Upon receiving a token transaction, the user 302 performs a lookup using the hash value included in the transaction to access the token data and validation proof. The user may check that each transaction in the chain is valid according to the blockchain rule set and the token rule set. The user may perform Merkle proofs of each transaction in the chain. At a minimum, the user performs Merkle proofs of the issuance and received transactions.

[0041] The described token system is more efficient compared to systems such as "proof of transaction chain" or "minor validation tokens", where proof size and complexity are independent of chain length.

[0042] 2. Cryptographic techniques 2.1 Simple Payment Verification Traditionally, to validate a transaction in a blockchain network 106, the complete blockchain history must be downloaded and every block ever to come (and every transaction in each block) must be validated. This is a time- and resource-intensive process that not all users of the blockchain network 106 are able or willing to perform. The simple payment verification (SPV) protocol has been defined to facilitate more "lightweight" clients that can verify individual transactions without the need to host a full blockchain database. It validates new transactions Tx based on: n This allows the SPV client to verify that the Proposed transaction Tx n Complete transaction data for Tx n All incoming transactions (i.e., Tx n Complete transaction data for all transactions in which UTXOs were created that are used as inputs in Merkle proofs for all input transactions Blockchain block header

[0043] Under verification, Tx n Each input to is verified by comparing the transaction data and Merkle proofs with the block header data. An example of a method for this verification can be found, for example, in Section 8 of the Bitcoin whitepaper. Verifying the Merkle proofs of all input transactions and n By performing signature verification on Tx n can be proven to be valid.

[0044] It should be noted that the SPV system does not necessarily eliminate double-spend attempts, but allows these attempts to be identified.

[0045] Two important features of an SPV system are that it allows for peer-to-peer (P2P) transactions (e.g., using IPv6 protocols) and that services can function offline, i.e., without a permanent connection to the blockchain network 106. These factors allow functions and services to be built on top of the blockchain 150 with the ability to scale.

[0046] 2.2 Merkle proofs According to some blockchain protocols, the block header of block 151 contains the Merkle root of all transactions contained within block 151. The Merkle root is derived by combining the transaction hashes in a Merkle tree structure. An exemplary Merkle tree is shown in FIG. 6.

[0047] To prove that some transaction is part of block 151, the Merkle root must be recreated using the transaction data. Merkle proofs provide a way to do this without knowing the full details of all the other transactions that were used as data leaves. Instead, at each level of the tree, the value of one node in a binary pair can be calculated, given the value of the other as part of the Merkle proof. For example, Figure 7 shows the elements needed to prove that D1 is in block 151.

[0048] 3. Exemplary Token System A token system may be encoded on top of the blockchain 150 by including data within transactions. This allows the token system to take advantage of properties of the underlying blockchain 150, such as the immutability of the blockchain ledger, while enabling the functionality of the token system in a "second layer." In order for a token system to integrate with the underlying blockchain 150, transactions carrying token data must satisfy the ruleset of the blockchain 150.

[0049] The token system has its own set of rules by which the data stored in transactions can be validated and interpreted. The token rule set is defined by the token issuer 301, who is also responsible for minting tokens. Depending on the implementation, the token issuer may also be responsible for validating token transactions, melting and re-minting tokens, and hosting the data associated with each token.

[0050] There is a great deal of flexibility when defining a token system. Three main factors that can be used to distinguish between tokenization methods are: Encoding: How the token information is stored within the transaction. · Fungibility: The extent to which a token represents a unique and indivisible asset. · Validation: How the token is validated.

[0051] 3.1.1 Encoding Mechanism A token represents an object in the second layer system. This may be, for example, some amount of fiat currency in a central bank digital currency (CBDC) system, a digital identity, a unique work of digital art, an event ticket, or a physical asset such as materials in a supply chain. Each token may have a unique identifier that can be represented in a transaction along with other core information related to the token rule set, such as the conditions required for transfer. Table 1 shows the structure of an example transaction.

[0052] [Table 1]

[0053] 3.1.2 OP_RETURN One way to include data within a transaction is to use the OP_RETURN (or equivalent) code in the output locking script. There are no constraints on the size of the data that can be included in this way, so the data can be represented in its entirety (either in plain text or encoded). One advantage to this is that all data needed to interpret the token is stored on the blockchain 150, which is freely accessible and immutable. However, because transaction fees are proportional to the size of the transaction, a more economical option is to include a hash digest of the data in the OP_RETURN and maintain a distributed hash table that links the complete data to its hash value.

[0054] 3.1.3 Standard Transaction Fields Another way to include token data in a transaction is to map it directly to a field already present in the transaction. In particular, a locking script can be used to specify conditions for the transfer of tokens (e.g., the ability to generate a signature corresponding to a specific public key). Additionally, some fields, such as the transaction version (a 4-byte integer), are currently unused and can be used to flag transactions as part of the token system. Similarly, if the lock time is set to 0, the nSequence field (a 4-byte integer) becomes meaningless and can therefore be used to encode value. This approach does not affect the size of the transaction, thereby minimizing transaction fees, but it limits the amount of data that can be encoded in the transaction.

[0055] 3.1.4 UTXO Transaction outputs are unique elements within a blockchain system that can have one of two states: unspent (initial state) or spent (final state). It is possible to bind each token to an unspent transaction output (UTXO) and create token rules (see Section 3.4) such that for every UTXO that is spent, a new paired UTXO is created within the same transaction—a new instantiation of the same token. UTXO-based token systems leverage the double-spend prevention inherent in blockchain 150 to ensure that each token remains unique and has a verifiable history.

[0056] 3.2 Substitutability Fungibility is the extent to which the asset a token represents is unique and indivisible. A fungible asset is not unique and can be divided into parts. For example, a fungible token may represent a 10% stake in a company; there may be up to ten "10% shares" of that company, each functioning equally to the others and being interchangeable. It is also possible to split a 10% share into two 5% shares without affecting the function or value of the shares.

[0057] In contrast, a non-fungible asset is a unique object that cannot be broken down into its constituent parts. A non-fungible token (NFT) might represent a house or a unique piece of digital artwork. Each token represents a specific instance that is not interchangeable with similar assets (e.g., a house is not the same as its neighbor) and cannot be divided into constituent parts. NFTs can be thought of as digital twins, where the token has a 1:1 mapping to the asset it represents.

[0058] Note that fungibility is not tied to value; for example, the legal value of both company shares (fungible) and a house (non-fungible) may change according to the market.

[0059] Validation 3.3.1 Trusted Third Parties One validation method that avoids explicitly checking the transaction chain history is to use a trusted third party (TTP), e.g., the token issuer. The TTP tracks every transaction as it occurs and verifies that the transaction satisfies the token rule set and contains inputs from transactions that the TTP has previously validated. n When created, all transactions Tx0, ..., Tx n-1 has already been verified by TTP and Tx nThis means that the TTP only needs to verify that the token conforms to the token rule set. Token transactions are created that require a signature from the token issuer to be valid on the blockchain network 106. Thus, when a transaction is published on the blockchain 150, users can be confident that the transaction has been verified and signed by the token issuer.

[0060] This solution is lightweight from the user's perspective, since no verification is required for the user to perform themselves. It is also efficient from the TTP's perspective, since the token transaction only needs to be verified once. However, it requires a secure and verifiable connection between the user and the TTP. It also relies on trust in the TTP and the assumption that the TTP will remain available as a service provider for as long as the user still needs the service.

[0061] 3.3.2 Transaction Chain Proof For this validation method, the token issuer must execute the transaction Tx n is linked to transaction Tx0 through an unbroken chain of transactions, i.e., a transaction chain proof (TCP). TCP is constant in size regardless of the length of the transaction chain. TCP uses recursive zkSNARKs, a form of zero-knowledge proofs, so that users can verify proofs without knowledge of the complete data that comprises the transaction chain. The recursive property means that work used to create proofs of previous transactions in the chain can be reused when creating updated proofs, so proofs can be generated efficiently.

[0062] Each TCP proves that: i. New transaction Tx nsatisfies the token rule set. ii. Previous transaction Tx n-1 either has a valid certificate or is the issuing transaction Tx0.

[0063] Attestation circuits are constructed based on the token ruleset with a unique token identifier hard-coded into the initial attestation. Once established, each subsequent transaction in the chain for that token will use the same ZKP circuit.

[0064] Proof sizes depend on the ZKP implementation; they come with different tradeoffs between security and efficiency. For example, Groth16 requires a 1.5kB proof size but requires trusted setup per circuit, while Halo requires a 3.5kB proof size but no trusted setup.

[0065] The proof may be stored on-chain within the transaction it verifies (e.g., in a non-spendable output) to provide a complete on-chain record of each token's validity. This also means that users can determine whether a transaction is valid without connecting to the token issuer to request the information. Alternatively, if minimizing transaction size is a factor, the proof can be stored externally (e.g., by the token issuer or in a distributed database) and accessed on-demand by users via a secure connection.

[0066] TCP assumes that the token issuer constructs proofs for each new token transaction, potentially storing these proofs and sending them to the user when needed. However, TCPs can be constructed by anyone, and their validity can be explicitly checked. This means that the token issuer provides a continuous service to the user, but the user does not need to be a trusted party.

[0067] Miners play no role in creating or verifying these proofs, and the proofs themselves do not involve Bitcoin scripts, so there is no additional processing or burden imposed on miners. However, verifying proofs requires that users have the ability to run the proof circuit.

[0068] 3.3.3 Miner-validated token (MVT) This validation method is built using a specific locking script template, which consists of three parts: a fixed element that encodes the token ruleset, an element containing the unique token identifier, and a customizable element for any other spending conditions, such as a Pay-to-Public-Key-Hash script.

[0069] The MVT fixed element and token identifier are stored in the parent transaction Tx unless it is an issuance transaction. n-1 and grandparent transaction Tx n-2 Tx only if the same locking script appears in both n is a valid token transaction.

[0070] As a result, successful consumption of a child's MVT locking script guarantees that the parent has the same locking script. Thus, by inductive inference, we know that every transaction in the chain, all the way back to the issuing transaction, has the same locking script. Furthermore, due to the uniqueness of the token identifier, these scripts cannot be copied and successfully executed. This secures the protocol against replay attacks.

[0071] The main feature of the MVT technique is that it avoids transaction bloat, where the unlocking script of every new transaction is larger than the unlocking script of the previous transaction. In particular, the MVT unlocking script only contains information about the two previous transactions, regardless of how many transactions there are in the chain. This is achieved by introducing an auxiliary transaction and a partial implementation of the SHA-256 hashing algorithm via opcodes in the locking script.

[0072] MVT transactions are constant in size, and the requirements for validating proofs do not grow as the transaction chain grows, meaning they are a scalable solution, like TCP. Token validation is also hard-coded into the transaction's locking script, so there is no need for TTP; users do not need to explicitly validate the transaction chain; i.e., a transaction proves that the transaction and its chain history are valid when included in the blockchain 150.

[0073] MVTs are technically validated by miners of the blockchain network 106, but crucially, because token validation is performed within the locking script, their transaction validation process does not need to change to accommodate token validation. However, this places the computational burden of validation on the miners.

[0074] 3.4 S|ACP Signed Input-Output Pairs UTXO-based token systems require that a token input UTXO be paired with an output that serves as a new UTXO associated with the token. This pairing between a single input and output lends itself to implementation via a SINGLE|ANYONE CAN PAY (S|ACP) signed input-output pair.

[0075] When creating a signature, the ECDSA algorithm used in a transaction requires both a private key and a message. The message is formed based on some of the transaction details. Signature verification does the following: Authorization to consume the UTXO input to which the signature applies, and · Authentication of transaction details in signed messages.

[0076] Each signature includes a sighash flag indicating which inputs and outputs are signed. The S|ACP flag variant assures the input that it consumes the output at the corresponding index location and that the signature validates that output. Table 2 shows in bold text the information that would be secured if an S|ACP signature (Sig1) were created to authorize Input 1. Input-output pairs signed using S|ACP impose no constraints on information in other inputs or outputs, so multiple S|ACP-signed pairs can be combined together into a single transaction without invalidating any of the signatures. This is useful for applications where multiple input-output pairs requiring signatures from different parties are combined into a single transaction (e.g., combining multiple token transfers signed by different users into a single transaction). Combining pairs in this way results in a small reduction in the required transaction fee, but also means that a single Merkle proof can be stored that applies to all pairs in a transaction.

[0077] [Table 2]

[0078] 2. Example System Overview A blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). A blockchain comprises a chain of blocks of data, each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in a sequence that may span one or more blocks, leading back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes each competing to perform a solution to a cryptographic puzzle based on a "proof of work," i.e., a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved through the mere publication of block headers.

[0079] Transactions in a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., some digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. 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 to data within transactions. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly more complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data, within the blockchain.

[0080] 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. Any consumable output comprises an element specifying an amount of a digital asset derivable from an evolving series of transactions. A consumable output is sometimes called a UTXO (“unspent transaction output”). The output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that specifies the conditions necessary to activate and transfer a digital token or digital 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, a pair of transactions is considered, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that specifies one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0081] In such a model, when a second target transaction is sent to the blockchain network to be propagated 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 specified in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in the new block to be recorded in the blockchain.

[0082] An alternative type of transaction model is the account-based model, where each transaction specifies the amount to be transferred by reference to absolute account balances rather than by referencing backwards the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain.

[0083] 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, i.e., typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 (often referred to as "miners") that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be organized as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0084] Each blockchain node 104 comprises a peer computing device, with different ones of the 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 one or more non-transitory computer-readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0085] A blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be a pruned version of the data, so long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain comprises one or more transactions 152, with a transaction in this context referring to a type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or methodology. A given blockchain uses one particular transaction protocol throughout.

[0086] Blockchain nodes 104 may be configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Blockchain nodes 104 may be configured to create blocks 151 and store respective copies of the same block chain 150 in their respective memories. Blockchain nodes 104 may also maintain 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." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 accepts as valid and that the node 104 is obligated not to accept any other transactions attempting to consume the same output.

[0087] For a given current transaction 152j, the (or each) input comprises a pointer to the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consuming can be described as consuming an output, i.e., allocating it to one or more outputs in another transaction onward. 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 need to exist at the time the current transaction 152j is created and even sent to the network 106, but the previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "preceding" herein refers to a predecessor in a logical sequence linked by a pointer, not necessarily to the time of creation or submission in a temporal sequence, and therefore does not necessarily preclude a transaction 152i, 152j from being created or submitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may equally be referred to as an antecedent transaction or a predecessor transaction.

[0088] Due to the resources involved in transaction validation and publishing, 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 may also take the form of a user terminal or a group of user terminals networked together.

[0089] 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 one or more roles and to process 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 in a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0090] Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, accumulating transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node may specialize in a particular operation. For example, a node 104 may focus on transaction validation and transaction propagation or on block mining. In some examples, a blockchain node 104 may perform two or more of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0091] 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 accumulating entities that accumulate copies of the blockchain 150 (e.g., obtain copies of the blockchain from blockchain nodes 104).

[0092] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be 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 required roles 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 is understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0093] 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 one or more non-transitory computer-readable media. This memory may comprise one or more memory units employing 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 on the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any actions 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, that are accessed via the user terminal.

[0094] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or may be 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.

[0095] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report back to each party the amount of digital assets that they currently own. In an output-based system, this second functionality comprises reconciling the amounts specified in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0096] Note: While various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may instead be implemented within a set of two or more separate applications that interface via, for example, an API, or one plugged into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to client application 105, it will be appreciated that this is not limiting.

[0097] An instance of a 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 allows a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or, in embodiments, to truly inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part through its public visibility). The wallet function on each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is used with a given node protocol to jointly 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.

[0098] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred by reference to an absolute account balance rather than by referencing backward the UTXO of a transaction that precedes it in the sequence of past transactions. The current state of every account is accumulated and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction account (also called a "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed with a transaction. This data field may point backward to a previous transaction, for example, if the data field contains a previous transaction ID.

[0099] Some account-based transaction models share some similarities with the output-based transaction models described herein. For example, as described above, the data fields of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction, which references the output point of the previous transaction. Thus, both models allow for linking between transactions. As another example, an account-based transaction includes a "recipient" field (in which the receiving address of the account is specified) and a "value" field (in which the amount of a digital asset may be specified). Together, the recipient field and value field are equivalent to the output of an output-based transaction, which can be used to assign the amount of a digital asset to a blockchain address. Similarly, account-based transactions have a "signature" field that contains a signature for the transaction. The signature is generated using the sender's private key and verifies that the sender has authorized this transaction. This is equivalent to the input / unlocking script of an output-based transaction, which typically includes a signature for the transaction. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. In an account-based blockchain, a "smart contract" refers to a transaction that includes a script configured to perform one or more actions (e.g., send or "release" digital assets to a recipient address) in response to one or more inputs (provided by the transaction) satisfying one or more conditions specified by the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions.Thus, in some examples, a smart contract may be considered equivalent to a locking script for an output-based transaction that can be triggered by a subsequent transaction, checking whether one or more conditions specified by the locking script are met by the inputs of the subsequent transaction.

[0100] 3. 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 intended to limit all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented in other exemplary blockchain networks.

[0101] 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) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also comprise a header 201, which may comprise indicators 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 the node 104.

[0102] For example, Alice 103a wishes to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least some of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are arbitrary labels only. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0103] The terms “preceding” and “subsequent,” 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 transactions point backward to which other transactions). They may be equivalently interchanged with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” or the like. 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. However, a subsequent transaction (a descendant transaction or “child”) that points to a preceding transaction (an ancestor transaction or “parent”) will not be 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. Depending on the node protocol and / or node behavior, the orphan may be discarded or may be buffered for some time to wait for a parent.

[0104] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO 0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a locking script that specifies the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be valid, and therefore for the UTXO to be successfully redeemed.

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

[0106] So, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Locking script [Checksig P A ]. [Checksig P A ] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's transaction ID, TxID0. Tx1's input 202 comprises a pointer that points backward into Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. Tx1's input 202 comprises an unlocking script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P AThe data (or "message") that needs to be signed by Alice to provide a valid signature may be specified by a locking script, or by a node protocol, or a combination of these.

[0107] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions specified in the locking script (where this condition may comprise one or more criteria).

[0108] Note that script code is often expressed generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to specific opcodes 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 a locking script, can accumulate data within the transaction, thereby creating a non-consumable output of the transaction that can immutably record the data in the blockchain 150. For example, the data may comprise a document that is desired to be accumulated in the blockchain.

[0109] 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 a specific piece of 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 portion of the outputs it signs depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0110] A locking script may be referred to as a "scriptPubKey," typically referring to the fact that the locking script comprises the public key of the party to which each transaction is locked. An unlocking script may be referred to as a "scriptSig," typically referring to the fact that the unlocking script provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating the signature. More generally, a scripting language may be used to specify any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0111] 4. Side Channels As shown in FIG. 1 , the client application on each of Alice's and Bob's computing devices 102 a and 102 b, respectively, may include additional communication functionality. This additional functionality allows Alice 103 a to establish (at the instigation of either the parties or a third party) a separate side channel 107 with Bob 103 b. 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 between Alice and Bob without the transaction being registered on the blockchain network 106 or on the chain 150 until one of the parties chooses to broadcast it 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.

[0112] 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 107 may be established over a variety of networks, such as a local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, a side channel 107 as referenced elsewhere herein may comprise any one or more links, via one or more networking technologies or communications 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 as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange several pieces of information or data, or the like, over the side channel 107, this does not necessarily imply that all these pieces of data must be sent over exactly the same links, or even the same type of network.

[0113] 5. Further Special Notes Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those skilled in the art. The scope of the present disclosure is limited not by the described embodiments, but only by the appended claims.

[0114] 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 appreciated 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.

[0115] 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, issuing, propagating, 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, network entities may perform the function of propagating and / or storing blocks without creating and issuing blocks (recall that these entities are not considered to be nodes of the suitable Bitcoin network 106).

[0116] 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, issuing, propagating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and issue blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0117] 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, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in a similar manner as described above with reference to blockchain node 104.

[0118] Some embodiments are described with respect to a blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as, for example, 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 node 104 will be given the opportunity to generate the next block 151. The node that is chosen is often called a validator. Blockchain nodes can look up their tokens for some time to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time has the best chance of becoming the next validator.

[0119] It will be appreciated that the above embodiments have been 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:

[0120] Statement 1. A computer-implemented method for issuing digital tokens using a blockchain, the method being performed by a token issuer: sending an issuance transaction to one or more nodes of a blockchain network, the issuance transaction being signed by a token issuer and comprising a first token identifier, the first token identifier being based on at least first token data related to the first token; obtaining a first proof of inclusion that proves that the issuance transaction is recorded on the blockchain; and and maintaining a database, the database comprising first token identifiers mapped to issuance transactions and first proofs of inclusion, the database being made available to one or more token users.

[0121] The proof of containment may be a Merkle proof.

[0122] Statement 2. The method of Statement 1, wherein the issuance transaction comprises: i) a first token input, the first token input comprising a signature of a token issuer; and ii) a first token output locked to a public key of the token issuer and / or the first token user.

[0123] Statement 3. The method of statement 2, wherein the first token input has an input index that corresponds to the output index of the first token output.

[0124] Statement 4. The method of Statement 2 or Statement 3, wherein the signature signs the message based on the first token output.

[0125] Statement 5. Any of the preceding statements, sending a first transfer transaction to one or more nodes of the blockchain network and / or the first token user, the first transfer transaction comprising a first token identifier; obtaining a second proof of inclusion that proves that the first transfer transaction is recorded on the blockchain; and and updating the database by mapping the first token identifier to the first transfer transaction and the second proof of inclusion.

[0126] Statement 6. The method of Statement 5, wherein the first transfer transaction comprises: i) a first token input, the first token input comprising at least a signature of a token issuer; and ii) a first token output locked to a public key of a first token user.

[0127] The first token output may have an input index that corresponds to the output index of the first token output. The signature may sign the message based on the first token output.

[0128] Statement 7. Any of the preceding statements, obtaining one or more respective transfer transactions each forming a chain of transfer transactions linked back to the issuance transaction, each respective transfer transaction comprising a first token identifier; obtaining, for each transfer transaction, a respective proof of inclusion that proves that the respective transfer transaction is recorded on the blockchain; and updating the database by mapping the first token identifier to each respective transfer transaction and each respective proof of inclusion.

[0129] Each respective transfer transaction may comprise: i) a respective token input, the respective token input comprising a respective signature of a respective token user; and ii) a respective token output locked to at least a respective public key of the respective token user.

[0130] Each token input may have an input index that corresponds to the output index of each token output. Each signature may sign each message based on each token output.

[0131] Statement 8. The method of any preceding statement, wherein the database comprises a hash table.

[0132] Statement 9. The method of any preceding statement, wherein the first token identifier comprises a commitment to the first token data.

[0133] Statement 10. The method of statement 9, wherein the first token identifier comprises a first token hash, the first token hash being generated by inputting at least the first token data into a hash function.

[0134] Alternatively, the first token identifier may comprise a Pederson commitment of the first token data or a uniform resource locator (URL) referencing the first token data.

[0135] Statement 11. A computer-implemented method for validating an issued digital token using a blockchain, the blockchain comprising an issuance transaction signed by a token issuer and comprising a first token identifier, the first token identifier based on at least first token data relating to the first token, the method being performed by a token validator; obtaining a target transfer transaction, the target transfer transaction being a final transaction in a chain of one or more respective transfer transactions linked back to the issuance transaction, the target transfer transaction comprising a first token identifier; Obtaining a database, the database comprising a first token identifier mapped to an issuance transaction, a first proof of inclusion that proves the issuance transaction is recorded on the blockchain, and a target proof of inclusion that proves the target transfer transaction is recorded on the blockchain; At a minimum, the following: i) using the first proof of inclusion to verify that the issuance transaction is recorded on the blockchain; ii) using the target proof of inclusion to verify that the target transfer transaction is recorded on the blockchain; and iii) by verifying that the target transfer transaction is linked to the issuance transaction; determining that the target transfer transaction comprises a valid token.

[0136] Statement 12. The method of statement 11, wherein said verifying that the target transfer transaction is linked to the issuance transaction comprises obtaining each transaction in the chain of one or more respective transfer transactions.

[0137] Statement 13. The method of statement 11 or statement 12, wherein the first token identifier is mapped to each transaction in the chain of one or more respective transfer transactions.

[0138] Statement 14. The method of any of statements 11-13, wherein the first token identifier is mapped to a respective proof of inclusion that proves that each respective transfer transaction is recorded on the blockchain, and wherein determining that the target transfer transaction comprises a valid token includes: iv) further comprising using each respective proof of inclusion to verify that each respective transfer transaction is recorded on the blockchain.

[0139] Statement 15. The method of any of statements 11-14, wherein the token validator is a first token user and the target transfer transaction comprises a token output locked to the public key of the first token user, and the method further comprises: generating a further transfer transaction, the further transfer transaction comprising: i) a first token input, the first token input comprising a signature of a first token user; ii) a first token output locked to a public key of a second token user; and iii) a first token identifier; by sending a further transfer transaction to one or more nodes of the blockchain network and / or the second token user; transferring the first token to the second token user.

[0140] Statement 16. A computing device comprising: a memory having one or more memory units; and a processing device having one or more processing units, the memory storing code configured to execute on the processing device, the code configured, when on the processing device, to perform the method of any of statements 1-15.

[0141] Statement 17. A computer program embodied on computer-readable storage and configured to perform the method of any of statements 1 to 15 when executed on one or more processors.

[0142] According to another aspect disclosed herein, a method may be provided that includes actions of a token issuer and a token validator. According to another aspect disclosed herein, a system may be provided that includes computer devices of a token issuer and a token validator. [Explanation of symbols]

[0143] 100 systems 101 Packet Switched Network 102 Computer Equipment 103 Users, Parties, and Agents 103a Alice 103b Bob 104 nodes, blockchain nodes, Bitcoin nodes 105 Client Applications, Software 106 Peer-to-peer (P2P) networks, decentralized networks, blockchain networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 154 Ordered Sets, Ordered Pools 201 Header 202 Input, input field 203 Output, Output Field 300 System 301 Token Issuer 302 Token User, User 302a First Token User 302b Secondary Token User

Claims

1. 1. A computer-implemented method for issuing digital tokens using a blockchain, the method being executed by a token issuer and comprising: sending an issuance transaction to one or more nodes of a blockchain network, the issuance transaction being signed by the token issuer and comprising a first token identifier, the first token identifier being based on at least first token data relating to a first token; obtaining a first proof of inclusion that proves that the issuance transaction is recorded on the blockchain; maintaining a database comprising the first token identifiers mapped to the issuance transactions and the first proof of inclusion, the database being made available to one or more token users; A method for providing

2. 2. The method of claim 1, wherein the issuance transaction comprises: i) a first token input, the first token input comprising a signature of the token issuer; and ii) a first token output locked to a public key of the token issuer and / or a first token user.

3. The method of claim 2 , wherein the first token input has an input index that corresponds to an output index of the first token output.

4. The method of claim 2 or 3, wherein the signature signs a message based on the first token output.

5. sending a first transfer transaction to one or more nodes of the blockchain network and / or the first token user, the first transfer transaction comprising the first token identifier; obtaining a second proof of inclusion that proves that the first transfer transaction was recorded on the blockchain; updating the database by mapping the first token identifier to the first transfer transaction and the second proof of inclusion; 5. The method of claim 1, comprising:

6. 6. The method of claim 5, wherein the first transfer transaction comprises: i) a first token input, the first token input comprising at least a signature of the token issuer; and ii) a first token output locked to a public key of a first token user.

7. obtaining one or more respective transfer transactions each forming a chain of transfer transactions linked back to the issuance transaction, each respective transfer transaction comprising the first token identifier; obtaining, for each transfer transaction, a respective proof of inclusion that proves that the respective transfer transaction is recorded on the blockchain; updating the database by mapping the first token identifier to each respective transfer transaction and each respective proof of inclusion; 7. The method of claim 1, comprising:

8. The method of any one of claims 1 to 7, wherein the database comprises a hash table.

9. 9. The method of claim 1, wherein the first token identifier comprises a commitment to the first token data.

10. 10. The method of claim 9, wherein the first token identifier comprises a first token hash, the first token hash being generated by inputting at least the first token data into a hash function.

11. 1. A computer-implemented method for validating an issued digital token using a blockchain, the blockchain comprising an issuance transaction signed by a token issuer and comprising a first token identifier, the first token identifier being based on at least first token data relating to the first token, the method being performed by a token validator; obtaining a target transfer transaction, the target transfer transaction being the last transaction in a chain of one or more respective transfer transactions linked back to the issuance transaction, the target transfer transaction comprising the first token identifier; obtaining a database, the database comprising the first token identifier mapped to the issuance transaction, a first proof of inclusion that proves the issuance transaction is recorded on the blockchain, and a target proof of inclusion that proves the target transfer transaction is recorded on the blockchain; At a minimum, the following: i) using the first proof of inclusion to verify that the issuance transaction is recorded on the blockchain; ii) using the target proof of inclusion to verify that the target transfer transaction is recorded on the blockchain; and iii) verifying that the target transfer transaction is linked to the issuance transaction. determining that the target transfer transaction comprises a valid token by performing A method comprising:

12. 12. The method of claim 11, wherein the step of verifying that the target transfer transaction is linked to the issuance transaction comprises the step of obtaining each transaction in the chain of one or more respective transfer transactions.

13. 13. The method of claim 11 or 12, wherein the first token identifier is mapped to each transaction in the chain of one or more respective transfer transactions.

14. the first token identifier is mapped to a respective proof of inclusion that proves that each respective transfer transaction is recorded on the blockchain, and the step of determining that the target transfer transaction comprises a valid token includes: iv) using each respective proof of inclusion to verify that each respective transfer transaction has been recorded on said blockchain; 14. The method of claim 11, further comprising:

15. the token validator is a first token user, the target transfer transaction comprises a token output locked to a public key of the first token user, and the method comprises: generating a further transfer transaction, the further transfer transaction comprising: i) a first token input, the first token input comprising a signature of the first token user; ii) a first token output locked to a public key of a second token user; and iii) the first token identifier; sending the further transfer transaction to one or more nodes of a blockchain network and / or the second token user; 15. The method of claim 11, further comprising transferring the first token to the second token user by

16. A computer device comprising: a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to run on the processing device, the code configured to run the method of any one of claims 1 to 15 when present on the processing device.

17. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 15 when executed on one or more processors.

Images