Computer-implemented method and system

Abstract

A computer-implemented method of issuing a digital token using a blockchain, where the method is performed by a token issuer and includes: sending an issuing transaction to one or more nodes of a blockchain network, where the issuing transaction is signed by the token issuer and includes a first identifier, the first token identifier is based at least on first token data associated with a first token; obtaining a first inclusion proof, wherein the first inclusion proof is used for proving that the issuing transaction has been recorded on the block chain; and maintaining a database, where the database includes the first token identifier, the first token identifier mapped to the issuing transaction, and the first inclusion attestation, where the database is provided to one or more token users.

Description

Technical Field

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

[0002] An emerging use of blockchain is to issue "tokens". For example, a token can represent a certain amount of fiat currency within a central bank digital currency (CBDC) system, a digital ID, a unique digital artwork, an event ticket, a company share, a physical asset (such as materials within a supply chain), etc.

[0003] To verify whether a transaction containing a token is valid, it is usually necessary to verify whether the transaction satisfies the set of rules defined by the relevant token system and the underlying blockchain rules. It is also necessary to verify the "provenance" of the token, i.e., its history since issuance. As each new transaction is generated for the token, this process becomes increasingly difficult as the distance between the token issuance and the current transaction grows. This is known as the back-to-genesis problem or the traceback problem.

[0004] Consider Figure 5 the exemplary transaction chain shown. In the simplest case, each transaction has one input and one output. The first transaction Tx0 is an issuance transaction that creates (mints) the token. Each subsequent transaction spends the output of the previous transaction and represents a transfer of ownership of the token. This is called a transaction chain. Suppose transaction Tx n is presented to a recipient and is valid under both the blockchain and the token rule set. This recipient must also verify that Tx n is part of an unbroken transaction chain Tx0, …, Tx n (originating from the issuance transaction), and that all previous transactions Tx0, …, Tx n-1 in the chain are valid under the blockchain and the token rules. There are currently various methods for verifying a token chain, details of which can be found in Section 3.3 below. Each method has its associated problems. The present disclosure provides a novel solution to these problems. Summary of the Invention

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

[0006] According to another aspect disclosed herein, there is provided a computer-implemented method for verifying a digital token issued using a blockchain, wherein the blockchain includes an issuance transaction that is signed by a token issuer and includes a first token identifier, the first token identifier being at least based on first token data associated with a first token, and wherein the method is performed by a token verifier and includes: obtaining a target transfer transaction, wherein the target transfer is the final transaction in a chain of one or more corresponding transfer transactions that link back to the issuance transaction, and wherein the target transfer transaction includes the first token identifier; obtaining a database, wherein the database includes the first token identifier, the first token identifier being mapped to the issuance transaction, a first proof of inclusion for proving that the issuance transaction has been recorded on the blockchain, and a target proof of inclusion for proving that the target transfer transaction has been recorded on the blockchain; and determining whether the target transfer transaction includes a valid token by at least performing the following operations: i) using the first proof of inclusion to verify whether the issuance transaction has been recorded on the blockchain, ii) using the target proof of inclusion to verify whether the target transfer transaction has been recorded on the blockchain, and iii) verifying whether 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 verified, as well as techniques for efficiently verifying the tokens.

[0008] The described token system allows for "offline" transfer of tokens, as the transfer does not require the participation of a central authority (i.e., the token issuer) (and thus does not require connection to the central authority). All information required to verify a token is provided to the token recipient in the form of a (distributed) hash table that can be shared peer-to-peer among token users.

[0009] The database (e.g., hash table) stores Merkle proofs of the issuance transactions and the transfer transactions, which can be used to prove that a target (e.g., the most recent) transfer transaction has been recorded on the blockchain. By verifying whether the target transfer transaction and the issuance transaction have been recorded on the blockchain and whether the target transfer transaction is linked to the issuance transaction, the token recipient can determine the origin of the relevant token. To increase certainty, the token recipient can verify the existence of each transaction in the transaction chain that links the target transfer transaction to the issuance transaction. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0012] Figure 2 schematically shows some examples of transactions that can be recorded on a blockchain;

[0013] Figure 3 is a schematic block diagram of an exemplary system for issuing and verifying tokens;

[0014] Figure 4 schematically shows a token transaction chain;

[0015] Figure 5 schematically shows a token transaction chain;

[0016] Figure 6 schematically shows an example of a Merkle tree;

[0017] Figure 7 schematically shows Figure 6 an exemplary Merkle path of the Merkle tree shown. DETAILED DESCRIPTION

[0018] 1. Issuing and Verifying Tokens

[0019] As an illustrative example, consider a central authority (e.g., a central bank) that wishes to issue tokens (e.g., digital currency). However, if tokens are to be transferred without the central authority signing the transaction (the advantage of which is to make the process simple and efficient), a problem arises because without the central authority's signature, the token recipient cannot ensure that the token is valid. Instead, the recipient must trace the received (i.e., the most recent) transaction back to the issuance transaction that issued the token. This is resource-intensive and is referred to as the tracing problem / regression to the origin problem.

[0020] The central authority can choose to issue tokens as fungible tokens. However, the problem with fungible tokens is that for any given token transaction, the transaction can reference multiple previous transactions. As more and more tokens are transferred, the number of transactions that need to be checked increases.

[0021] Therefore, the central authority can choose to issue non-fungible tokens. Now, each token has only one previous transaction, or more precisely, each token is associated with only one input (and thus only with the previous transaction output). It should be noted that a given token transaction can still contain multiple tokens. Therefore, the task of checking the transaction chain is linear with the size of the chain traced back to the issuance. In other words, there are fewer previous transactions to check for validity compared to fungible tokens.

[0022] The embodiments described herein provide an efficient mechanism for verifying tokens. Figure 3 An exemplary system 300 for implementing the described embodiments is shown. System 300 includes a token issuer 301 and multiple token users 302. The token issuer is responsible for issuing tokens according to the token protocol. Only two token users 302a, 302b are shown, but it should be understood that system 300 can include any number of token users 302. System 300 also includes one or more nodes 104 of a blockchain network 106 (e.g., the exemplary network 106 described below). For simplicity, the first token user 302a will be referred to as Alice 103a, and the second token user 302b will be referred to as Bob 103b. Generally, each token user 302 can be configured to perform any of the actions performed by Alice 103a and / or Bob 103b described below.

[0023] The token issuer 301 can be any type of entity, such as a user, a group of users, a company, a government agency, a bank, an event operator, etc. The token issuer 301 can issue any number of tokens, but for simplicity, the embodiments will be described based on the issuance of a single token.

[0024] The token issuer 301 generates an issuance transaction for issuing a token. The token can be a non-fungible token. The issuance transaction contains a token identifier value (e.g., a token hash value). The token identifier is a unique (and preferably concise) identifier of the token. For example, the token hash value can be generated by hashing the token data associated with the token. In this example, the token data itself can include the identifier of the token, but not the hash value. The token data can include the rules of the token protocol. The token data can define one or more attributes of the token. The token data can be included in the transaction or stored elsewhere (on-chain or off-chain). Other examples of token identifiers include the Pederson commitment of the token data, or a Uniform Resource Locator (URL) that references the token data (e.g., a web page containing the token data). Generally, as long as any commitment or reference to the token data is unique for the corresponding token, that commitment or reference can be used.

[0025] 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 can correspond to a public key known to be associated with the token issuer 301. The public key can be authenticated as being associated with the token issuer 301.

[0026] The issuance transaction can be locked to a recipient (e.g., Alice 103a). That is, in order to transfer the token, Alice 103a may have to provide data that only Alice 103a can provide. In some examples, the issuance transaction can 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 and transfers the token to a token user 302 such as Alice 103a.

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

[0028] The token issuer 301 sends an issuance transaction to the blockchain network 106. After the issuance transaction has been recorded on the blockchain 150, the token issuer 301 obtains (e.g., generates or receives from a blockchain node 104) a Merkle proof that the issuance transaction has been recorded on the blockchain 150. Other inclusion proofs can be used instead of the Merkle proof. It should be noted that "Merkle proof" is used to refer to any Merkle-style proof.

[0029] The token issuer 301 maintains a database, such as a hash table. The hash table can be a distributed hash table. The database can be provided to the token user 302. For example, the token issuer 301 can send the database to the token user 302. The database can be stored online (e.g., in a cloud storage device) such that it can be accessed by the token user 302. Examples will be described mainly in terms of the hash table, but in general, any suitable type of database that allows lookup operations can be used. Unless the context requires otherwise, any reference to "hash table" can be replaced with "database", and any reference to "hash value" or "token hash" can be replaced with "token identifier".

[0030] The hash table contains token hashes (from the issuance transaction) that are mapped to the issuance transaction and the Merkle proof of the issuance transaction. Similarly, in general, any database can be used where the token identifier is mapped to the issuance transaction and the corresponding Merkle proof. The hash table is used by the token user 302 to verify token transactions, as described below.

[0031] Before turning to verification, as described above, the token issuer 301 itself can transfer the token to the token user 302 (e.g., Alice 103a). For example, the token issuer 301 can generate a transfer transaction that references the issuance transaction. The transfer transaction is signed by the token issuer 301. The transfer transaction can be locked to the 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 signature of the token issuer. The transfer transaction includes a token output (linked to the token input) that is locked to Alice's public key, e.g., using a pay-to-public-key (P2PK) or pay-to-public-key-hash (P2PKH) locking script. The transfer transaction includes a token hash.

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

[0033] Similarly, each time a transfer transaction is submitted to the blockchain 150 to transfer tokens between token users 302 (e.g., from Alice 103a to Bob 103b), the token issuer 301 obtains the (one or more) transfer transactions and the (one or more) corresponding Merkle proofs, and updates the database (e.g., hash table) to map the transfer transactions and Merkle proofs to the token hash.

[0034] It should be understood that the database (e.g., hash table) may contain many token identifiers (token hashes), each token identifier associated with a specific token, and each token identifier mapped to one or more transactions and one or more corresponding Merkle proofs.

[0035] Now turning to the process of verifying a token. The token verifier (e.g., a token user such as Alice 103a) obtains the 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 that is locked to Alice 103a's public key. The target transfer transaction includes a token hash. The target transfer transaction may contain other token-related data (e.g., an identifier of the token).

[0036] Alice 103a uses the token identifier (e.g., token hash) to obtain the issuance transaction and its Merkle proof from the database (e.g., hash table) maintained by the token issuer 301. Alice 103a also obtains the Merkle proof of the target transfer transaction.

[0037] Using the Merkle proof, Alice 103a verifies whether the issuance transaction and the target transfer transaction have been recorded on the blockchain 150. It should also be noted that other inclusion proofs may be used instead of the Merkle proof. Alice 103a may require the block headers of 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.

[0038] Alice 103a also verifies whether the target transfer transaction is linked to an issuance transaction. That is, Alice 103a verifies whether the target transfer transaction is part of a transaction chain that starts with the issuance transaction (it should be noted that the issuance transaction is not necessarily the very first part of the chain; the Coinbase / generation transaction is usually the very first part of the chain). If the verification passes, then Alice 103a can determine that the target transfer transaction is a valid token transaction and contains a valid token issued by the token issuer 301.

[0039] In some examples, Alice 103a can verify whether the target transfer transaction is linked to the issuance transaction by obtaining each transfer transaction in the transfer transactions that connect the target transfer transaction to the issuance transaction. These transactions can be obtained from the hash table. If the hash table contains the corresponding Merkle proof for the corresponding transaction, then Alice 103a can also verify whether each corresponding transaction in the corresponding transaction has been recorded on the blockchain 150.

[0040] Upon determining that the target transfer transaction is valid, Alice 103a can generate a new transfer transaction that transfers 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 uses her private key to generate a signature that signs at least a part of the new transfer transaction. The signature can be included in the token input of the new transfer transaction and is used to unlock the token output of the target transfer transaction. The new transfer transaction can be locked to Bob's public key. For example, the token output of the new transfer transaction can include a (P2PK or P2PKH) locking script that locks the output to Bob's public key. The new transfer transaction also includes a token hash, for example, as part of the token output or a different output.

[0041] Alice 103a sends the new transfer transaction to Bob 103b and / or the blockchain network 106. Bob 103b can perform a process similar to that of Alice 103a to verify the new transfer transaction.

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

[0043] When using non-fungible tokens (NFTs), the regression genesis problem is reduced compared to fungible tokens. For NFTs, there is a single input causally associated with the new token output, so to verify the token history, only a single input needs to be verified. For fungible tokens, the new token output cannot be provably mapped to a single input, so to prove a transaction is valid, every input must be verified. In the context of CBDCs, using NFTs with a fixed denomination may mean more token pairs are needed in a transaction to create the correct total value. In terms of increasing the number of inputs to check, this is a one-time cost, but each input will still have a linear transaction chain history.

[0044] The token system described herein allows a verifier to prove the validity of a token while imposing a minimal computational burden on the token issuer or blockchain node 104. It does not require a trusted third party and allows a user 302 to verify a token transaction chain without running a full node (i.e., with lightweight data storage and computational capabilities)—suitable for running on a mobile phone or laptop.

[0045] The token can be a UTXO-based NFT that represents a fixed denomination. Token ownership and transfer can be controlled via a locking script (e.g., P2PKH). The UTXO can be signed using the SINGLE|ANYONE CAN PAY (S|ACP) sighash flag.

[0046] Each transaction includes a hash (e.g., using OP_RETURN) that links to an external distributed hash table (maintained by the token issuer and peer-shared among users via, e.g., Torrent). This hash table contains the transaction data for each transaction in the token chain as well as the Merkle proof for each transaction. The hash table can also contain token identifier data and optional additional token data (e.g., token data related to the token's functionality). This data is mapped to the hash of the token data so that users can use the hash value to look up the relevant proof and data.

[0047] Token user 302 maintains a list of block headers. When receiving a token transaction, user 302 uses the hash value included in the transaction to perform a lookup to access the token data and verification proof. The user can check whether each transaction in the chain is valid according to the blockchain and token rule set. The user can perform a Merkle proof for each transaction in the chain. The user performs a Merkle proof for at least the issuance transaction and the received transaction.

[0048] Compared to systems such as "Proof of Transaction Chain" or "Miner-validated token", the described token system is more efficient, where the proof size and complexity are independent of the chain length.

[0049] 2. Encryption Techniques

[0050] 2.1 Simple Payment Verification

[0051] Traditionally, to verify a transaction in blockchain network 106, the entire blockchain history had to be downloaded and every block that had appeared previously (along with all transactions within each block) had to be verified. This is a time-consuming and resource-intensive process that not all users of blockchain network 106 can or want to perform. Simple Payment Verification (SPV) protocols have been defined that support more "lightweight" clients, enabling such clients to verify individual transactions without hosting the entire blockchain database. This allows SPV clients to verify a new transaction Tx n for validity based on

[0052] · the complete transaction data of the proposed transaction Tx n

[0053] · all input transactions to Tx n (i.e., all transactions that created the UTXOs used as inputs in Tx n )

[0054] · Merkle proofs of all input transactions

[0055] · the blockchain block headers.

[0056] During verification, each input to Tx n is verified by comparing the transaction data and Merkle proofs with the block header data. For example, an example of the method used for this verification can be found in Section 8 of the Bitcoin white paper. By verifying the Merkle proofs of all input transactions and running signature verification against Tx n , the SPV client can prove that Tx n is valid.

[0057] It should be noted that SPV systems do not necessarily prevent double-spending attempts, but they do allow these attempts to be identified.

[0058] Two important features of SPV systems are that they allow peer-to-peer (P2P) transactions (e.g., using the IPv6 protocol), and that services can run offline, i.e., without a permanent connection to blockchain network 106. These factors enable the construction of scalable capabilities and services on blockchain 150.

[0059] 2.2 Merkle Proof ​

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

[0061] To prove that a particular transaction is part of block 151, the Merkle root must be recreated using the transaction data. A Merkle proof provides a way to do this without knowing the full details of all the other transactions that are used as data leaves. Instead, at each level of the tree, the value of one node in a binary pair can be computed, and the value of the other node obtained as part of the Merkle proof. For example, Figure 7 shows the elements required to prove that D1 is in block 151.

[0062] 3. Exemplary Token System

[0063] By including data in a transaction, a token system can be encoded on top of blockchain 150. This enables the token system to leverage the properties of the underlying blockchain 150, such as the immutability of the blockchain ledger, while implementing the functionality of the token system at the "second layer". To integrate the token system with the underlying blockchain 150, the transactions carrying the token data must satisfy the rule set of blockchain 150.

[0064] The token system will have its own rule set that enables the data stored in a transaction to be verified and interpreted. The token rule set is defined by the token issuer 301, who is also responsible for minting the tokens. Depending on the implementation, the token issuer may also play a role in verifying token transactions, destroying and reminting tokens, and hosting the data associated with each token.

[0065] The token system can be defined very flexibly. The three main factors that can be used to distinguish tokenization methods are as follows:

[0066] · Encoding: The way in which the token information is stored in a transaction.

[0067] · Homogeneity: The extent to which the token represents a unique and indivisible asset.

[0068] · Verification: The method of verifying the token.

[0069] 3.1.1 Encoding Mechanism

[0070] Tokens represent objects in a second-layer system. For example, this could be a certain amount of fiat currency, a digital ID, a unique digital artwork, an event ticket, or a physical asset (such as materials within a supply chain) within a central bank digital currency (CBDC) system. Each token can have a unique identifier that can be represented in a transaction, as well as other core information related to the token rules, such as the conditions required for transfer. Table 1 shows the structure of an exemplary transaction.

[0071]

[0072] 3.1.2 OP_RETURN

[0073] One way to include data in a transaction is to use the OP_RETURN (or equivalent) code in the locking script of the output. There is no limit to the size of the data that can be included in this way, so the data can be represented in its entirety (either in plaintext or encoded form). One advantage of doing this is that all the data required to interpret the token is stored on the blockchain 150, making this data freely accessible and immutable. However, since the transaction fee is proportional to the size of the transaction, a more economical option is to include the hash digest of the data in the OP_RETURN and maintain a distributed hash table that links the full data to its hash value.

[0074] 3.1.3 Standard Transaction Fields

[0075] Another way to include token data in a transaction is to directly map it to a field that already exists in the transaction. Specifically, the locking script can be used to define the token transfer conditions (for example, the ability to produce a signature corresponding to a specific public key). Additionally, some fields that are not currently in use, such as the transaction version (a 4-byte integer), can be used to mark the transaction as part of the token system. Similarly, if the locktime is set to 0, the nSequence field (a 4-byte integer) becomes meaningless, so it can be used to encode a value. This method does not affect the size of the transaction and therefore minimizes the transaction fee, but the amount of data that can be encoded in the transaction is limited.

[0076] 3.1.4 UTXO

[0077] A transaction output is a unique element in a blockchain system and can be in one of the following two states: unspent (initial state) or spent (final state). Each token can be bound to an unspent transaction output (UTXO) and token rules can be created, where for each spent UTXO, a new paired UTXO is created in the same transaction (see Section 3.4), i.e., a new instantiation of the same token. The UTXO-based token system leverages the inherent double-spending prevention feature of the blockchain 150 to ensure that each token remains unique and has a verifiable history.

[0078] 3.2 Homogenization

[0079] Fungibility is the degree of uniqueness and indivisibility of the assets represented by tokens. Fungible assets are not unique and can be divided into multiple parts. For example, a fungible token might represent a 10% stake in a company; there can be at most 10 shares of "10% stake" in the company, and each share functions identically—they are interchangeable. The 10% stake can also be split into two 5% stakes without affecting the function or value of the stake.

[0080] In contrast, non-fungible assets are unique objects that cannot be broken down into multiple components. A non-fungible token (NFT) might represent a house or a unique digital artwork. Each token represents a specific instance and cannot be swapped with similar assets (e.g., a house is not the same as its adjacent house) or broken down into multiple components. NFTs can be regarded as digital twins, where there is a 1:1 mapping between the token and the asset it represents.

[0081] It should be noted that fungibility has nothing to do with value—for example, the legal value of company stocks (fungible) and houses (non-fungible) may vary depending on the market.

[0082] 3.3. Verification

[0083] 3.3.1 Trusted Third Party

[0084] One method of verification that avoids explicit checking of the transaction chain history is to use a trusted third party (TTP) (e.g., the token issuer). The TTP keeps track of every transaction that occurs, verifies whether it satisfies the token rule set and includes the inputs of the transactions they have previously verified. This means that when creating Tx n , all transactions x0, …, Tx n-1 have been verified by the TTP, and the TTP only needs to verify Tx nWhether the token rules are followed. Create token transactions such that they require the signature of the token issuer to be valid on the blockchain network 106. Thus, if a transaction is published on the blockchain 150, the user can determine that the transaction has been verified and signed by the token issuer.

[0085] From the user's perspective, the scheme is lightweight because they do not need to run any verification themselves. From the TTP's perspective, the scheme is also efficient because token transactions only need to be verified once. However, the scheme requires a secure and verifiable connection between the user and the TTP. The scheme also relies on trust in the TTP and the assumption that they will continue to provide the service as long as the user still requires it.

[0086] 3.3.2 Proof of Transaction Chain

[0087] For this verification method, the token issuer creates a proof transaction Tx n Linked to the transaction Tx0 through an uninterrupted transaction chain - a transaction chain proof (TCP). Regardless of the length of the transaction chain, the size of the TCP is fixed. The TCP uses recursive zkSNARK (a form of zero - knowledge proof), so the user can verify the proof without knowing the complete data including the transaction chain. The recursive property means that when creating an updated proof, the work used to create the proof for the previous transactions in the chain can be reused, so proofs can be generated efficiently.

[0088] Each TCP proves the following:

[0089] i. The new transaction Tx n Satisfies the token rule set.

[0090] ii. Either the previous transaction Tx n-1 Has a valid proof, or the issuing transaction Tx0 has a valid proof.

[0091] The proof circuit is built based on the token rule set, where the unique token identifier is hard - coded into the initial proof. Once established, each subsequent transaction in the chain of that token will use the same ZKP circuit.

[0092] The proof size depends on the ZKP implementation. These all come with different security and efficiency trade - offs. For example, Groth16 requires a proof size of 1.5 kB but requires a trusted setup for each circuit. While Halo requires a proof size of 3.5 kB but does not require a trusted setup.

[0093] The proof can be stored on-chain in the transactions it validates (e.g., in unspendable outputs) to provide a complete on-chain record of the validity of each token. This also means that users can determine whether a transaction is valid without connecting to the token issuer to request 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 by users on demand via a secure connection.

[0094] TCP assumes that the token issuer constructs proofs for each new token transaction and may store these proofs and send them to users when needed. However, TCP can be constructed by anyone, and its validity can be explicitly checked. This means that while the token issuer provides a continuous service to users, they do not need to be a trusted party.

[0095] Miners play no role in the creation or validation of these proofs, and the proofs themselves do not involve Bitcoin scripts, so they do not impose additional processing or burden on miners. However, validating the proof does require the user to be able to run the proof circuit.

[0096] 3.3.3 Miner-Verified Token (MVT)

[0097] The verification method is constructed using a specific locking script template. The verification method consists of three parts: a fixed element encoding the token rule set; an element containing the unique token identifier; and a customizable element for any other spending conditions (such as pay-to-public-key-hash scripts).

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

[0099] Therefore, successfully spending a child MVT locking script ensures that the parents have the same locking script. Thus, by induction, it can be known that each transaction in the chain (all the way back to the issuance transaction) has the same locking script. Additionally, due to the uniqueness of the token identifier, these scripts cannot be replicated and successfully executed. This makes the protocol resistant to replay attacks.

[0100] A key feature of the MVT technology is that it can avoid transaction bloat, i.e., the unlocking script of each new transaction is larger than that of the previous transaction. Specifically, regardless of how many transactions there are in the chain, the MVT unlocking script only contains information about two previous transactions. This is achieved by introducing auxiliary transactions and implementing a partial SHA-256 hash algorithm via an opcode in the locking script.

[0101] The size of MVT transactions is fixed, and the requirements for verifying proofs do not increase as the transaction chain grows. This means they are scalable solutions like TCP. Token verification is also hardcoded into the transaction's locking script, so no TTP is needed and users do not need to explicitly verify the transaction chain - if a transaction is included in the blockchain 150, it proves that the transaction and its chain history are valid.

[0102] Technically, MVTs are verified by the miners of the blockchain network 106, but crucially, they do not need to change their transaction verification process to accommodate token verification because token verification is implemented in the locking script. However, it imposes a computational burden of verification on the miners.

[0103] 3.4S | ACP-Signed Input-Output Pair

[0104] For UTXO-based token systems, it is necessary to pair the token input UTXO with the output used as the new UTXO associated with the token. This pairing between a single input and output is suitable for implementation through input-output pairs signed with SINGLE|ANYONE CAN PAY (S|ACP).

[0105] When creating a signature, the ECDSA algorithm used in the transaction requires a private key and a message. The message is formed based on some details of the transaction. Verifying the signature can:

[0106] · Authorize the spending of the UTXO input to which the signature applies; and

[0107] · Authenticate the transaction details in the signature message.

[0108] Each signature contains a sighash flag that indicates which inputs and outputs are signed. The S|ACP flag variant protects the input spent for signature verification and the output at the corresponding index position. Table 2 shows in bold the information that will be protected in the case of creating an S|ACP signature (Sig1) to authorize Input 1. For the information in other inputs or outputs, the input-output pairs signed with S|ACP do not impose any restrictions, so multiple S|ACP signature pairs can be combined together in a single transaction without invalidating any signature. This is suitable for applications that combine multiple input-output pairs that require signatures from different parties (e.g., combining multiple token transfers signed by different users into a single transaction). Combining the pairs in this way results in a small reduction in the necessary transaction fees, but also means that a single Merkle proof applicable to all pairs in the transaction can be stored.

[0109]

[0110] 2. Exemplary System Overview

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

[0112] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtual ledger or registry; receiving and processing timestamp entries; and / or sorting index pointers by time. Hierarchical additional functions on the blockchain can also be realized by using the blockchain. For example, the blockchain protocol can allow additional user data or data indexes to be stored in transactions. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio or video data in the blockchain.

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

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

[0115] Another type of transaction model is the account-based model. In this case, each transaction does not define the amount transferred by referring to the UTXOs of previous transactions in the past transaction sequence, but rather by referring to the absolute account balance. The current state of all accounts is stored separately by the nodes into the blockchain and is continuously updated.

[0116] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 can include a packet-switching network 101, typically a wide-area internet such as the Internet. The packet-switching network 101 includes a plurality of blockchain nodes 104 (commonly referred to as “miners”), which can be arranged to form a peer-to-peer (P2P) network 106 within the packet-switching network 101. Although not shown, the blockchain nodes 104 can be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0118] The blockchain 150 includes a series of data blocks 151, where a corresponding copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in a distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, the blockchain 150 can perform data pruning as long as each blockchain node 150 stores the block headers of each block 151 (discussed below). Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A particular transaction protocol is used throughout a given blockchain.

[0119] The blockchain node 104 can be configured to forward the transaction 152 to other blockchain nodes 104, thereby enabling the transaction 152 to propagate throughout the network 106. The blockchain node 104 can be configured to create a block 151 and store a corresponding copy of the same blockchain 150 in its corresponding memory. The blockchain node 104 can also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into the block 151. The ordered pool 154 is commonly referred to as the "mempool". In this document, the term is not intended to be restricted to any particular blockchain, protocol, or model. The term refers to an ordered set of transactions that the node 104 has accepted as valid, and for which the node 104 is forced not to accept any other transaction that attempts to spend the same output.

[0120] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring financial assets, although this is certainly a common application. More generally, spending can be described as consuming the output, or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified as valid in order to ensure the validity of the current transaction, the previous transaction 152i does not have to exist at the time the current transaction 152j is created or even sent to the network 106. Thus, in this document, "previous" refers to the predecessor in a logical sequence linked by a pointer, and not necessarily to the creation time or send time in a time sequence, and thus does not necessarily rule out the case of unordered creation or sending of transactions 152i, 152j (see the discussion of orphan transactions below). The previous transaction 152i can equally be referred to as the antecedent transaction or the predecessor transaction.

[0121] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server including one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

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

[0123] Any given blockchain node can be configured to perform one or more of the following operations: verify transactions, store transactions, propagate transactions to other peers, perform consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, nodes can be specialized for a particular operation. For example, a node 104 can focus on transaction verification and propagation, or can focus on block mining. In some examples, a blockchain node 104 can perform more than one of these operations in parallel. Any reference to a blockchain node 104 can refer to an entity configured to perform at least one of these operations.

[0124] The computer device 102 of each party 103 in the multi - party 103 acting as consumer users is also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in a transaction. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can 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).

[0125] Some or all of the parties 103 can be connected as part of different networks, such as a network overlaying the blockchain network 106. Users of the blockchain network (often referred to as "clients") can be said to be part of the system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 can interact with the blockchain network 106 to utilize the blockchain 150 by connecting to a blockchain node 106 (i.e., communicating with the blockchain node 106). For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but are not shown for convenience. Each party 103 can be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is called Alice and the second party 103b is called Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced by "first party" and "second party" respectively.

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

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

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

[0129] Note: Although the various client functions can be described as integrated into a given client application 105, this is not necessarily restrictive. Instead, any client function described herein can be implemented in a suite of two or more different applications, such as interfacing via an API or one application as a plugin to another application. More generally, client functions can be implemented at the application layer or a lower layer such as an operating system or any combination of these layers. The following will be described in terms of the client application 105, but it should be understood that this is not restrictive.

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

[0131] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks can be referred to as an "account-based" protocol. In the account-based case, each transaction does not define the amount of the transfer by referring to the UTXO of the previous transaction in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is separately stored in the blockchain by the nodes of the network and is continuously updated. In such a system, transactions are sorted using the running transaction record of the account (also referred to as "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and is hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0132] Some account - based transaction models have some similarities with the output - based transaction model described herein. For example, as described above, the data fields of an account - based transaction can point to the previous transaction, which is equivalent to the input of an output - based transaction that references the output points of the previous transaction. Thus, both models support chaining between transactions. Another example is that an account - based transaction contains a "recipient" field (where the receiving address of the account is specified) and a "value" field (where a certain amount of digital assets can be specified). Together, the recipient and value fields are equivalent to the output of an output - based transaction, which can be used to allocate a certain amount of digital assets to a blockchain address. Similarly, an account - based transaction has a "signature" field, which includes the signature of the transaction. The signature is generated using the sender's private key and confirms that the sender has authorized the transaction. This is equivalent to the input / unlock script of an output - based transaction, which typically includes the signature of 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. On an account - based blockchain, a "smart contract" refers to a transaction that contains 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) that satisfy one or more conditions defined by the script of the smart contract. The smart contract exists as a transaction on the blockchain and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract can be considered equivalent to the locking script of an output - based transaction (which can be triggered by a subsequent transaction) and checks whether the inputs of the subsequent transaction satisfy one or more conditions defined by the locking script.

[0133] 3. UTXO-Based Model

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

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

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

[0137] The terms “previous” and “subsequent” as used in the context of the transaction sequence herein refer to the order of transactions in the sequence as defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can equally be replaced with terms such as “predecessor” and “successor”, “ancestor” and “descendant” or “parent” and “child”. This does not necessarily refer to the order in which they are created, sent to the network 106 or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or “child”) that points to a previous transaction (ancestor transaction or “parent”) will not be valid unless the parent transaction is valid. A child that arrives at the blockchain node 104 before its parent is considered orphaned. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for the parent.

[0138] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value that specifies the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of a subsequent transaction must meet in order for the subsequent transaction to be valid and thus successfully redeem the UTXO.

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

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

[0141] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script meets the conditions defined in the locking script (where the conditions can include one or more criteria).

[0142] It should be noted that script code is typically represented diagrammatically (i.e., using non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to specific opcodes of the script language. For example, OP_RETURN is a script language opcode that, when preceded by OP_FALSE at the start of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby immutably recording the data on the blockchain 150. For example, the data can include a file to be stored on the blockchain.

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

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

[0145] 4. Side Channel

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

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

[0148] 5. Further Comments

[0149] Once the disclosure of this document is given, other variations or use cases of the disclosed technology may become obvious to those skilled in the art. The scope of this disclosure is not limited by the described embodiments, but only by the appended claims.

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

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

[0152] 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 of the functions of creating, publishing, propagating, and storing the blocks 151 of the blockchain 150 but not all of them. For example, on these other blockchain networks, the term "node" may be used to refer to a network entity that is configured to create and publish the blocks 151 but not store and / or propagate these blocks 151 to other nodes.

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

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

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

[0156] Statement 1. A computer-implemented method for issuing digital tokens using a blockchain, where the method is performed by a token issuer and includes:

[0157] Sending an issuance transaction to one or more nodes of a blockchain network, where the issuance transaction is signed by the token issuer and includes a first token identifier that is at least based on first token data associated with a first token;

[0158] Obtaining a first inclusion proof that proves that the issuance transaction has been recorded on the blockchain; and,

[0159] Maintaining a database that includes the first token identifier, which is mapped to the issuance transaction and the first inclusion proof, where the database is provided to one or more token users.

[0160] The inclusion proof can be a Merkle proof.

[0161] Statement 2. The method according to statement 1, where the issuance transaction includes: i) a first token input that includes the signature of the token issuer; ii) a first token output that is locked to the public key of the token issuer and / or a first token user.

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

[0163] Statement 4. The method according to statement 2 or 3, where the signature signs a message based on the first token output.

[0164] Statement 5. The method according to any of the preceding statements, the method comprising:

[0165] Sending a first transfer transaction to one or more nodes of the blockchain network and / or the first token user, wherein the first transfer transaction includes the first token identifier;

[0166] Obtaining a second inclusion proof proving that the first transfer transaction has been recorded on the blockchain; and,

[0167] Updating the database by mapping the first token identifier to the first transfer transaction and the second inclusion proof.

[0168] Statement 6. The method according to statement 5, wherein the first transfer transaction includes: i) a first token input, the first token input including at least a signature of the token issuer; ii) a first token output, the first token output locked to a public key of the first token user.

[0169] The first token output may have an input index corresponding to the output index of the first token output. The signature may be a signature on a message based on the first token output.

[0170] Statement 7. The method according to any of the preceding statements, the method comprising:

[0171] Obtaining one or more corresponding transfer transactions, each corresponding transfer transaction forming a transfer transaction chain that links back to the issuance transaction, wherein each corresponding transfer transaction includes the first token identifier;

[0172] For each corresponding transfer transaction, obtaining a corresponding inclusion proof for proving that the corresponding transfer transaction has been recorded on the blockchain; and,

[0173] Updating the database by mapping the first token identifier to each corresponding transfer transaction and each corresponding inclusion proof.

[0174] Each corresponding transfer transaction may include: i) a corresponding token input, the corresponding token input including a corresponding signature of a corresponding token user; ii) a corresponding token output, the corresponding token output locked to at least a corresponding public key of a corresponding token user.

[0175] The corresponding token input may have an input index corresponding to the output index of the corresponding token output. The corresponding signature may be a signature on a corresponding message based on the corresponding token output.

[0176] Statement 8. The method according to any of the preceding statements, wherein the database includes a hash table.

[0177] Statement 9. The method according to any of the preceding statements, wherein the first token identifier includes a commitment to the first token data.

[0178] Statement 10. The method according to statement 9, wherein the first token identifier includes a first token hash, which is generated by inputting at least the first token data into a hash function.

[0179] Alternatively, the first token identifier may include a Pedersen commitment of the first token data, or include a Uniform Resource Locator (URL) referring to the first token data.

[0180] Statement 11. A computer-implemented method for verifying a digital token issued using a blockchain, wherein the blockchain includes an issuance transaction, the issuance transaction is signed by a token issuer and includes a first token identifier, the first token identifier is at least based on first token data related to a first token, and wherein the method is performed by a token verifier and includes:

[0181] Obtaining a target transfer transaction, wherein the target transfer is the final transaction in a chain of one or more corresponding transfer transactions that link back to the issuance transaction, and wherein the target transfer transaction includes the first token identifier;

[0182] Obtaining a database, wherein the database includes the first token identifier, the first token identifier is mapped to the issuance transaction, a first inclusion proof for proving that the issuance transaction has been recorded on the blockchain, and a target inclusion proof for proving that the target transfer transaction has been recorded on the blockchain; and,

[0183] Determining whether the target transfer transaction includes a valid token by performing at least the following operations:

[0184] i) Using the first inclusion proof to verify whether the issuance transaction has been recorded on the blockchain,

[0185] ii) Using the target inclusion proof to verify whether the target transfer transaction has been recorded on the blockchain, and,

[0186] iii) Verifying whether the target transfer transaction is linked to the issuance transaction.

[0187] Statement 12. The method according to statement 11, wherein verifying whether the target transfer transaction is linked to the issuance transaction includes: obtaining each transaction in the chain of one or more corresponding transfer transactions.

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

[0189] Statement 14. The method according to any one of statements 11 to 13, wherein the first token identifier is mapped to a corresponding inclusion proof, the corresponding inclusion proof being for proving that each corresponding transfer transaction has been recorded on the blockchain, and wherein determining whether the target transfer transaction includes a valid token further comprises:

[0190] iv) Using each corresponding inclusion proof to verify whether each corresponding transfer transaction has been recorded on the blockchain.

[0191] Statement 15. The method according to any one of statements 11 to 14, wherein the token verifier is a first token user, the target transfer transaction includes a token output locked to the public key of the first token user, and wherein the method comprises transferring the first token to a second token user by:

[0192] Generating a further transfer transaction, wherein the further transfer transaction comprises: i) a first token input, the first token input including the signature of the first token user, ii) a first token output, the first token output being locked to the public key of the second token user, and iii) the first token identifier; and,

[0193] Sending the further transfer transaction to one or more nodes of the blockchain network and / or the second token user.

[0194] Statement 16. A computer device, the computer device comprising:

[0195] A memory, the memory comprising one or more memory units; and,

[0196] A processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to run on the processing device, the code being configured to, when run on the processing device, execute the method according to any one of statements 1 to 15.

[0197] Statement 17. A computer program, the computer program being embodied on a computer-readable memory and configured to, when run on one or more processors, execute the method according to any one of statements 1 to 15.

[0198] According to another aspect disclosed herein, a method can be provided that includes actions of the token issuer and the token verifier. According to another aspect disclosed herein, a system can be provided that includes computer devices of the token issuer and the token verifier.

Claims

1. A computer-implemented method for issuing digital tokens using a blockchain, wherein the method is performed by a token issuer and includes: Sending an issuance transaction to one or more nodes of a blockchain network, wherein the issuance transaction is signed by the token issuer and includes a first token identifier that is at least based on first token data associated with a first token; Obtaining a first inclusion proof for proving that the issuance transaction has been recorded on the blockchain; And Maintaining a database that includes the first token identifier mapped to the issuance transaction and the first inclusion proof, wherein the database is provided to one or more token users.

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

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

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

5. The method according to any of the preceding claims, the method includes: Sending a first transfer transaction to one or more nodes of the blockchain network and / or the first token user, wherein the first transfer transaction includes the first token identifier; Obtaining a second inclusion proof for proving that the first transfer transaction has been recorded on the blockchain; And Updating the database by mapping the first token identifier to the first transfer transaction and the second inclusion proof.

6. The method according to claim 5, wherein the first transfer transaction includes: i) A first token input that at least includes a signature of the token issuer; ii) A first token output that is locked to a public key of the first token user.

7. The method according to any of the preceding claims, the method includes: Obtaining one or more corresponding transfer transactions, each corresponding transfer transaction forming a chain of transfer transactions that links back to the issuance transaction, wherein each corresponding transfer transaction includes the first token identifier; For each corresponding transfer transaction, obtaining a corresponding inclusion proof for proving that the corresponding transfer transaction has been recorded on the blockchain; And Updating the database by mapping the first token identifier to each corresponding transfer transaction and each corresponding inclusion proof.

8. The method according to any of the preceding claims, wherein the database includes a hash table.

9. The method according to any of the preceding claims, wherein the first token identifier includes a commitment to the first token data.

10. The method according to claim 9, wherein the first token identifier includes a first token hash that is generated by at least inputting the first token data into a hash function.

11. A computer-implemented method for verifying a digital token issued using a blockchain, wherein the blockchain includes an issuance transaction that is signed by a token issuer and includes a first token identifier, the first token identifier being at least based on first token data associated with the first token, and wherein the method is performed by a token verifier and includes: Obtaining a target transfer transaction, wherein the target transfer is the final transaction in a chain of one or more corresponding transfer transactions that link back to the issuance transaction, and wherein the target transfer transaction includes the first token identifier; Obtaining a database, wherein the database includes the first token identifier, the first token identifier being mapped to the issuance transaction, a first inclusion proof for proving that the issuance transaction has been recorded on the blockchain, and a target inclusion proof for proving that the target transfer transaction has been recorded on the blockchain; And Determining whether the target transfer transaction includes a valid token by at least performing the following: i) Using the first inclusion proof to verify whether the issuance transaction has been recorded on the blockchain, ii) Using the target inclusion proof to verify whether the target transfer transaction has been recorded on the blockchain, and iii) Verifying whether the target transfer transaction is linked to the issuance transaction.

12. The method according to claim 11, wherein verifying whether the target transfer transaction is linked to the issuance transaction includes: Obtaining each transaction in the chain of one or more corresponding transfer transactions.

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

14. The method according to any one of claims 11 to 13, wherein the first token identifier is mapped to a corresponding inclusion proof for proving that each corresponding transfer transaction has been recorded on the blockchain, and wherein determining whether the target transfer transaction includes a valid token further includes: iv) Using each corresponding inclusion proof to verify whether each corresponding transfer transaction has been recorded on the blockchain.

15. The method according to any one of claims 11 to 14, wherein the token verifier is a first token user, the target transfer transaction includes a token output locked to the public key of the first token user, and wherein the method includes transferring the first token to a second token user by: Generate a further transfer transaction, wherein the further transfer transaction includes: i) A first token input that includes a signature of the first token user, ii) A first token output that is locked to the public key of the second token user, and iii) The first token identifier; And Sending the further transfer transaction to one or more nodes of the blockchain network and / or the second token user.

16. A computer device, the computer device including: A memory that includes one or more memory units; And A processing device, the processing device including one or more processing units, wherein the memory stores code configured to run on the processing device and, when run on the processing device, execute the method according to any one of claims 1 to 15.

17. A computer program, the computer program being embodied on a computer-readable memory and configured to, when run on one or more processors, execute the method according to any one of claims 1 to 15.

Images