Proving and verifying an ordered sequence of events

Abstract

A computer-implemented method for providing proof of an ordered sequence of events, the method being executed on a computing device and comprising the steps of receiving a transaction; creating a further transaction to be sent to a further computing device; obtaining proof data associated with the further transaction that provides proof to the further computing device that the further transaction is linked to an initial transaction in a transaction chain comprising transactions, the initial transaction involving an initial event in the ordered sequence of events, the proof data comprising (i) a proof, (ii) an identifier of the transaction, and (iii) a unique identifier of the initial transaction; and transmitting the further transaction and the proof data to the further computing device.

Description

[Technical field]

[0001] The present disclosure relates to providing proofs of ordered sequences of events and verifying ordered sequences of events. [Background technology]

[0002] Blockchain refers to a form of distributed data structure, where a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain comprises a chain of blocks of data, where each block comprises one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to a previous transaction in the sequence, which may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called "mining", which involves multiple nodes each competing to perform a "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and validated outstanding transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved by publishing only the block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to carry digital assets (i.e., a number of digital tokens), to order a set of journal entries in a virtualized ledger or register, to receive and process timestamp entries, and / or to time-order index pointers. A blockchain may also be utilized to overlay additional functionality onto the blockchain. For example, a blockchain protocol may allow for the storage of additional user data or indexes to data in a transaction. Since there is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, increasingly complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data in the blockchain.

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

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of invalid transactions is performed by the activities of competing nodes, who act as agents of the network and have an incentive to report and prevent fraud. Public disclosure of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the ongoing integrity of the blockchain.

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

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

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

[0009] Bitcoin allows data to be inserted into transactions and stored immutably on the blockchain. A concise proof of a transaction's completeness is given by a process known as Simplified Payment Verification. However, the relationships between transactions can also convey additional information. For example, if transaction B consumes one of transaction A's outputs, then the rules of the protocol tell us that transaction B was created after transaction A.

[0010] The concept of transaction ordering can be extended to linear transaction chains. If each transaction consumes the output of previous transactions in the chain, an immutable ordering can be established. This ordering is inherited by the data payload within the transaction, which is aided by proof-of-work.

[0011] Currently, there is no concise way to prove that two transactions are connected through a transaction chain without using a trusted third party. Instead, one must identify every transaction in the chain and explicitly verify that each transaction consumes the output of the previous transaction. While this can be an efficient method for many use cases, it results in storage costs that grow linearly with the length of the chain. For a chain of one million transactions, the proof size is several hundred megabytes. Even in high-fee ledgers such as Bitcoin, transaction chains of this size can grow over time. Summary of the Invention [Means for solving the problem]

[0012] According to one aspect disclosed herein, a computer-implemented method for providing proof of an ordered sequence of events is provided, the method being executed on a computing device and comprising the steps of receiving a transaction; creating a further transaction to be sent to a further computing device; obtaining proof data associated with the further transaction providing to the further computing device proof that the further transaction is linked to an initial transaction in a transaction chain comprising transactions, the initial transaction involving an initial event in the ordered sequence of events, the proof data comprising (i) a proof, (ii) an identifier of the transaction, and (iii) a unique identifier of the initial transaction; and transmitting the further transaction and the proof data to the further computing device.

[0013] According to another aspect disclosed herein, there is provided a computer-implemented method for verifying an ordered sequence of events, the method executing on a computing device, comprising the steps of receiving a transaction from a further computing device; receiving proof data associated with the transaction from the further computing device, the proof data comprising (i) a proof, (ii) an identifier of a previous transaction in the transaction chain, and (iii) a unique identifier of a first transaction in the transaction chain, where the first transaction relates to a first event in the ordered sequence of events; and verifying that the transaction is linked to the first transaction in the transaction chain using the proof, the identifier of the previous transaction in the transaction chain, the unique identifier of the first transaction, and a verification key.

[0014] A zero-knowledge proof (ZKP) is a method by which a party, known as a prover, can prove to another party, known as a verifier, that a statement is true without revealing any information other than the fact that the statement is true. In embodiments of the present disclosure, a ZKP is generated to provide a proof that two transactions are linked through an unbroken chain of transactions.

[0015] The embodiments of the present disclosure have several applications. For example, using the embodiments of the present disclosure, it is possible to determine the current state of the Bitcoin network in just a few kilobytes. If a new blockchain node wants to enter the Bitcoin network, it is faced with downloading hundreds of gigabytes of data and verifying that all transactions from the genesis block are indeed correct. Using the embodiments of the present disclosure, it is possible to construct proofs to verify the entirety of the Bitcoin blockchain in a single function. This can be done at the level of the block header or the transaction DAG itself.

[0016] To aid in understanding embodiments of the present disclosure and to show how such embodiments may be embodied, reference will be made, by way of example only, to the accompanying drawings. [Brief description of the drawings]

[0017] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] FIG. 3B is a schematic mock-up diagram of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 1 illustrates a primary transaction chain. [Diagram 5] FIG. 1 is a schematic representation of a typical Bitcoin transaction. [Figure 6] FIG. 1 illustrates transactions of a transaction chain sent between user computing devices. [Figure 7a] FIG. 1 illustrates a method for providing proof of an ordered sequence of events in response to receiving an initial transaction. [Figure 7b] FIG. 1 illustrates a method for providing proof of an ordered sequence of events in response to receiving an initial transaction. [Figure 8] FIG. 1 illustrates a method for validating an ordered sequence of events. [Figure 9a] FIG. 1 illustrates a method for providing proof of an ordered sequence of events in response to receiving a transaction that is not the first transaction in a transaction chain. [Figure 9b] FIG. 1 illustrates a method for providing proof of an ordered sequence of events in response to receiving a transaction that is not the first transaction in a transaction chain. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0019] Each blockchain node 104 comprises a peer's computing equipment, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing unit comprising one or more processors, for example one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium. The memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as high-value disk drives.

[0020] The blockchain 150 comprises a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in the distributed network or blockchain network 101. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing some quantity of digital assets as assets, such as a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and redeemed or spent). Each input points to the output of a preceding transaction 152, thereby linking those transactions.

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

[0022] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "memory pool." This term in this specification 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 has accepted as valid and that the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0023] For a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, which specifies that this output is to be redeemed or "consumed" in the current transaction 152j. In general, the preceding transaction can be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152i is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in the logical sequence linked by the pointer, and does not necessarily refer to the time of creation or transmission in the temporal order, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below on orphan transactions). The preceding transaction 152i may also be referred to as an ancestor transaction or a predecessor transaction.

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

[0025] According to an output-based transaction protocol such as Bitcoin, when a participant 103, such as an individual user or an organization, wants to define a new transaction 152j (either manually or by an automated process used by the participant), the defining participant transmits the new transaction from his computer terminal 102 to the recipient. The defining participant or the recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are usually servers or data centers, but in principle could be other user terminals). It is not excluded that the participant 103 implementing the new transaction 152j can transmit the transaction directly to one or more of the blockchain nodes 104 and in some instances not to the recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 104. The blockchain node protocol usually requires the blockchain node 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that a cryptographic signature or other authorization of a participant 103 included in the input of the new transaction 152j matches a condition defined in the output of a preceding transaction 152i that the new transaction assigns, which condition typically comprises at least verifying that a cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of a previous transaction 152i to which the input of the new transaction is chained. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may simply be fixed by the blockchain node protocol alone, or it may be by a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

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

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

[0028] The first blockchain node 104 that attempts to solve the puzzle announces this to the network 106 and provides the solution as a proof that can be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is simple to verify that the output of the hash thereby satisfies the conditions). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and therefore enforce the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. This large amount of effort, for example in the form of a hash, required to create the proof-of-work solution is indicative of the first node's 104 intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction (otherwise known as double-spend). Once created, blocks 151 cannot be altered because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in blocks that are ordered at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0029] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be competing to solve the puzzle based on different snapshots of the pool of not-yet-published transactions 154 at any given time, depending on when they started searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may arise, which are situations where two blockchain nodes 104 solve a puzzle within a very short time of each other, resulting in conflicting views of the blockchain being propagated between the nodes 104. That is, whichever tip of the fork has grown longer will be the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0030] In the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate an additional acceptable amount of digital assets in a new special type of transaction (rather than an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional defined amount of digital assets. This special type of transaction is usually called a "coinbase transaction", but may also be called an "initiation transaction" or "generation transaction". It usually forms the first transaction of a new block 151n. The proof of work indicates the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is usually called a "transaction fee" and is discussed below.

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

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

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

[0034] Some or all of the participants 103 may be connected as part of a different network, for example a network superimposed on the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system including the blockchain network 106. However, these users are not blockchain nodes 104, as they do not perform the role required of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150, by connecting to (i.e., communicating with) the blockchain node 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that more such participants 103 and their respective computer devices 102 may be present and participating in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

[0035] The computing device 102 of each participant 103 comprises a respective processing device comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing device 102 of each participant 103 further comprises a memory in the form of a non-transitory computer readable medium, i.e. computer readable storage. This memory may comprise one or more memory units utilizing one or more memory media, e.g. magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 adapted to execute on the processing device. It will be understood that any activity attributable to this specification for a given participant 103 may be performed using software executed on the processing device of the respective computing device 102. The computing device 102 of each participant 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 smart watch. The computing equipment 102 of a given participant 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

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

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

[0038] NOTE: Although various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in a series of two or more separate applications, for example interfacing via an API or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. The following is described with respect to client application 105, but it will be understood that this is not limiting.

[0039] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the 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 in which the respective participant 103 is a recipient (or in an embodiment, actually investigate the transactions of other participants in the blockchain 150, since the blockchain 150 is a public entity that provides credit for some transactions by virtue of its public presence). The wallet function of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As mentioned above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward them to disseminate the transactions 152 throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is accompanied by a given node protocol, and together 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.

[0040] When a given party 103, for example Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she organizes the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then transmits the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it handles the new transaction 152j according to the blockchain node protocol and its respective role. This comprises first verifying whether the newly received transaction 152j satisfies some condition for being "valid", an example of which will be discussed in more detail shortly. In some transaction protocols, the condition for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, this condition may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

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

[0042] Once granted access to the ordered pool 154 of outstanding transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle for the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different ordered sets of transactions 154, but whoever gets there first defines the set of transactions contained in the latest block 1511. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 has a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0043] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views of which instance is "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it accepts it and discards (i.e., treats as invalid) the instance it first accepted (i.e., the instance not published in block 151).

[0044] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, not by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored and periodically updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, the optional data field may also be the signed transaction. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

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

[0046] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO comprises a value that specifies an amount of a digital asset. It represents a set number of tokens on the distributed ledger. The UTXO may also comprise, among other information, a transaction ID for the transaction from which the UTXO originates. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and the output fields 203. The header 201 may also include an ID for the transaction. In an embodiment, 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 issued to the node 104.

[0047] Suppose Alice 103a wants to create a transaction 152j that transfers a target amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". Tx1 takes the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor do they mean that Tx1 is the immediate next transaction in the pool 154. Tx1 may point to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

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

[0049] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labelled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be met by an unlocking script in the input 202 of the following transaction in order for the following transaction to be validated, and thus for the redemption of the UTXO to be successful. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition, which typically comprises a condition that the unlocking script in the input of the following transaction comprises a cryptographic signature of the party to which the preceding transaction is locked.

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

[0051] Thus, in the example shown, UTXO0 in output 203 of Tx0 must contain Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A Requires lock script [Checksig P A ]. [Checksig PA ] 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 to 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 identify UTXO0 among all other possible outputs of Tx0. Tx1's input 202 further comprises an unlock 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 A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0052] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol, which comprises running the lock script and the unlock script together to see if the unlock script satisfies the conditions defined in the lock script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] Here, "||" denotes concatenation, "<...>" means putting data on the stack, and "[...]" is a function contained in the lock script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a common stack. Either way, when executed together, the scripts will create a lock script that contains Alice's public key P, as contained in the lock script in the output of Tx0. Ais used to authenticate that the unlock script in Tx1's input contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (so there is no need to include a separate element specifying the signed portion of the data in the clear, since it was there originally).

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

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

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

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

[0057] In practice, Alice would normally also need to include a fee for any Bitcoin node 104 that succeeds in including Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus not disseminated and included in the blockchain 150, even though it is technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to do so). In some protocols, the transaction fee does not require a unique separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in its own one of the UTXOs 203 of transaction 152.

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

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

[0060] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs, and some or all of the transaction outputs. The specific parts of the outputs to sign depend on the SIGHASH flag, which is normally a 4-byte code included at the end of the signature (and thus fixed at the time of signing) to select which outputs are signed.

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

[0062] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the schemes disclosed herein. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to perform transaction-related functions behind the scenes of the client 105, such as orchestrating transactions 152 and sending the transactions to one or more nodes 104 for dissemination through the blockchain network 106, according to schemes as discussed above and in more detail shortly.

[0063] The UI layer 402 is configured to render a user interface via user input / output (I / O) means of the device 102, including outputting information to each user 103 via a user output means of the respective user's computing device 102, and receiving input from each user 103 via a user input means of the device 102. For example, the user output means may comprise one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output, etc. The user input means may comprise, for example, one or more touch screen input arrays (same or different as those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or voice input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more mechanical buttons, switches, or joysticks, etc.

[0064] Note: although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting, and instead they may be implemented in a suite of two or more separate applications, e.g., one plugging into the other or interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split between more than one application. It is not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, etc., it will be understood that this is by way of example only, and more generally, the described functionality may be implemented in any form of software.

[0065] 3B provides a mock-up of an example user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by the client 105b on Bob's device 102b, or any other participant's client.

[0066] 3B shows a UI 500 from Alice's perspective. The UI 500 may comprise one or more UI elements 501, 502, 503 that are rendered as separate UI elements via user output means.

[0067] For example, the UI elements may comprise one or more user-selectable elements 501, which may be different on-screen buttons, or different options in a menu, etc. User input means are provided to allow a user 103 (in this case Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching the UI element on the screen, or by speaking the name of the desired option (note that the term "manual" as used herein is intended only to contrast with automatic, and is not necessarily limited to using hands). The options allow the user (Alice) to organize transactions 152 and send them to one or more nodes 104 for dissemination through the blockchain network 106.

[0068] Alternatively or additionally, the UI element may comprise one or more data entry fields 502, through which a user can organize a transaction 152 and submit the transaction to one or more nodes 104 for dissemination through the blockchain network 106. These data entry fields may be rendered via a user output means, e.g., on a screen, and data may be entered into the fields via a user input means, e.g., a keyboard or a touch screen. Alternatively, data may be received orally, e.g., based on speech recognition.

[0069] Alternatively or additionally, the UI elements may comprise one or more information elements 503 for outputting information to the user. For example, this / these may be rendered on a screen or in sound.

[0070] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not important. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 500 shown in FIG. 3B is only a schematic mockup, and may in fact comprise one or more additional UI elements that are not shown for the sake of brevity.

[0071] Primary Transaction Chain Consider a sequence of transactions where the first input of each transaction consumes the first output of the previous transaction, which we call a primary transaction chain and is shown in Figure 4.

[0072] Consider a scenario with prover Alice and verifier Bob. The first transaction Tx0 is public data known to both Alice and Bob. Alice submits transaction Tx n Then, they build two transactions (Tx0, Tx n ).

[0073] Alice wants to prove the following statements to Bob: Statement 1: Tx0 is a Tx n If Bob accepts Alice's proof, then Bob will use the combination ((Tx0,Tx n ),proof n ).

[0074] Now consider a third party, Charlie. Bob sees that the first input is Tx n A new transaction Tx is the first output of n+1 Bob creates Tx through the primary transaction chain. n+1 Modify Alice's proof to create a new proof that ((Tx0,Tx n+1 ),proof n+1 ) to Charlie.

[0075] In this example, given that Tx0 corresponds to public data known to Alice, Bob, and Charlie, the flow of information is n , proof n to Bob, and Bob sends Tx n+1 , proof n+1 to Charlie.

[0076] Alice can easily prove statement 1 by sending every single transaction in the chain to Bob, who can unambiguously see that the first input of each transaction consumes the first output of the previous transaction.

[0077] This approach has several advantages. Design and implementation: Conceptually simple and easy to implement. No sophisticated cryptographic algorithms are involved. ·Alice's computational cost: Alice has no computational overhead.

[0078] However, this approach has several drawbacks. Communication costs: proportional to the size of the transaction chain. Alice has to send the entire transaction chain to Bob. This can require the transfer of a lot of data. A typical transaction contains around 200 bytes, and there is no upper limit on the length of the primary transaction chain. A chain of 1 million transactions will be around 200MB. Computational cost for Bob: Given a transaction, Bob checks if it is part of the transaction chain. If Bob has the Merkle root of the latest transaction, he is also guaranteed that the miners have correctly validated it. Privacy cost: There is no privacy, since the data in all transactions is given to Bob. This is especially important if some of the transactions have not yet been submitted to the Bitcoin network. Even if all transactions have already appeared on-chain, giving the transactions directly to Bob makes it easier for him to identify sensitive information. Iteration cost: When Bob sends his new proof to Charlie, Charlie has to repeat the same calculations as Bob.

[0079] According to embodiments of the present disclosure, Alice may prove the correctness of statement 1 using recursive zkSNARKs. Alice does not need to send the entire transaction chain to Bob. Instead, Alice only sends a proof for the correctness of statement 1.

[0080] This approach has several advantages. Communication costs: Due to the concise proof size of zkSNARKs, only a small amount of data is sent to Bob. The size of the proof is very small and independent of the number of transactions in the chain. For example, with a recursive zkSNARK, the size of the proof is around 3.5kb for 128-bit security, even if there are 1 million transactions in the chain. This is small enough that the proof can be inserted into the transaction. For example, Alice can send the proof of her last transaction Tx n You can recursively insert your own proofs into any transaction in the chain. Bob’s computational cost: Bob’s verification time is fast. Bob only needs to verify the proof. Privacy cost: Alice has more control over her privacy since she does not need to send every transaction in the chain to Bob. This is because Tx n This may be combined with other privacy controls, such as obscuring some of the data in the Iteration cost: Proofs can be constructed recursively. Bob creates a new transaction Tx n+1 Bob can then append Tx n Charlie does not need to repeat the computations for the proof up to now. Charlie only needs to verify this new proof. Charlie does not need to repeat any of the computations performed by Bob.

[0081] Transactions and Transaction Chains In some embodiments of the present disclosure, the transaction is a blockchain transaction (i.e., a transaction that is committed to the blockchain 150 through an interaction with the blockchain network 106).

[0082] A schematic representation of a typical Bitcoin transaction 152 is shown in FIG.

[0083] A Bitcoin transaction 152 has a unique identifier called the Transaction ID (TxID) 201 that is calculated by taking the double-SHA256 of the transaction data (all fields below TxID in Figure 5). Note that the TxID is not considered to be part of the transaction itself.

[0084] A transaction input 202 includes a reference to a previous transaction ID (PrevTxID) and an output index. The combination of the previous transaction ID and the output index is called an output point 502 and is labeled PrevTxID||Index (see FIG. 5).

[0085] The set of all Bitcoin transactions forms a directed acyclic graph (DAG) with edges connecting the output of one transaction to the input of another. This DAG is sometimes called the Bitcoin ledger.

[0086] Data can be inserted into a transaction in several places. In Figure 5, there is a data payload in each output lock script 504, which is a convenient place to insert data. These data payloads play no role in the script execution because they are each located after an OP_RETURN statement. The lock script 504 contains a Pay-to-Public-Key-Hash (P2PKH) script pattern and a data payload.

[0087] At a very high level, Bitcoin defines a transaction generation routine as follows:

[0088] In the first step, a public and private key pair is generated and the destination address is derived from the public key.

[0089] In the second step, a new transaction is created. The transaction output (2 64 For each of the 2000 addresses (limited to 1000), this involves getting the destination addresses, creating a locking script for each address, and specifying the amount of satoshis to be allocated to each address. 64For input UTXOs (limited to 1000,000), this involves (i) identifying the input UTXOs and inserting a transaction ID (and output index), called PrevTxID, and (ii) generating an unlock script for each input UTXO. This typically involves creating a digital signature (as in PKPKH) over the output data and input data (excluding the unlock script). Metadata is also generated, such as version number 506, input and output counts, and lock time 508. Finally, the transaction ID 201 is calculated: TxID=SHA256d(Tx), where Tx(inputs, outputs, metadata). Note that TxID is a double hash of the transaction data, including the PrevTxID. The transaction ID is used as an identifier for the transaction; it is not part of the transaction itself.

[0090] In a third step, the transaction is broadcast to the Bitcoin network 106. This involves the computing device 102 taking the transaction and sending it to one or more blockchain nodes 104 on the Bitcoin network 106. When the blockchain node 104 receives the transaction, it verifies that the transaction is valid and that none of the inputs have been previously allocated (i.e., double-spent). The blockchain node 104 additionally verifies whether a sufficient transaction fee is included. If the transaction passes these checks, it is accepted by the node and placed in an ordered pool 154 of transactions 152 waiting to be incorporated into a block 151. The blockchain node 104 also broadcasts the transaction to other blockchain nodes. Once the transaction is accepted by a sufficient number of blockchain nodes on the Bitcoin network 106, the transaction may be considered safe, since double-spents cannot be accepted.

[0091] In a fourth step, after a period of time (10 minutes on average), the blockchain node 104 publishes a block containing the transaction, which provides further guarantee that the transaction cannot be double-spended.

[0092] A transaction is valid if it satisfies the Bitcoin rule set by itself. This means that the transaction has the correct structure and the unlocking script succeeds in unlocking the output point, for example by providing a valid signature. There are additional consistency checks, such as that the value of the output does not exceed the input.

[0093] A valid transaction is a candidate to be accepted in the Bitcoin network and published in a block. A valid transaction references previous transactions in its input list. These previous transactions may or may not be valid. However, if a transaction is accepted by a node on the Bitcoin network, all previous transactions must be valid.

[0094] An ordered set of transactions, where each transaction consumes the output of the previous transaction in the set, is called a "transaction chain". By the rules of the blockchain protocol, each transaction in the set must be created chronologically later than the previous transaction in the set. This means that the order of transactions in the chain can be understood as the chronological order in which the transactions were created.

[0095] In the following, Tx i .Outpoints is transaction Tx i The present invention provides a mathematical definition of a "transaction chain" and a "primary transaction chain", which are defined as an ordered set of output points of a

[0096] We first give a mathematical definition of a transaction chain: TxSet=(Tx1, …Tx n ) is an ordered set of valid transactions, and TxID i =SHA256d(Tx i ) Then,

[0097]

number

[0098] The derived sequence

[0099]

number

[0100] For each j i For ∈{2,…,n},

[0101]

number

[0102] and

[0103]

number

[0104] Therefore,

[0105]

number

[0106] is the transaction chain for i∈{1,…,n}, 1≦k≦2 64 It is.

[0107] Note that the transaction chain is unique except for differences in the order of transaction IDs, since it is already known. However, if ID collisions occur,

[0108]

number

[0109] is the first transaction with a collusion ID. Therefore, the transaction chain may not necessarily be unique, since hash collisions are possible.

[0110] We now give a mathematical definition of a primary transaction chain. Given a transaction chain TxChain, where the first input of each transaction points to the first output of the previous transaction, we refer to this as a primary transaction chain. In a primary transaction chain, Txi.Outpoints=(TxID i-1 ||0,…).

[0111] We now refer to the first lemma, Lemma 1.

[0112] Lemma 1: Assume that SHA256 is collision resistant. (This property is especially true when the compression function of SHA256 is collision resistant.) For any Tx i A transaction chain TxChain=(Tx1, Tx2, …, Tx n ) is computationally infeasible.

[0113] Proof: TxChain is a chain of TxIDs for each i∈{2,…,n}. i =SHA256d(…,TxID i-1 ,…), we can create a random mapping based on SHA256 for a certain TxID. i-1 TxID iThis can be modeled as a mapping to 127 It is expected that the cycle length will be

[0114] One consequence of Lemma 1 is that a transaction chain imposes a time order on its elements: the next transaction in the chain must be created after the previous transaction in the chain.

[0115] Here we present an important theory (Theorem 1). This is useful because it allows us to leverage the transaction processing done by Bitcoin nodes 104. It means that in the embodiments of the present disclosure, it is not necessary to check the validity of each transaction in our recursive zkSNARK. We know that as long as the last transaction is accepted by the Bitcoin network 106 and as long as each transaction has the correct structure, they should be valid.

[0116] Theory 1: TxSet=(Tx1,Tx2,…,Tx n ) is an ordered set, TxID i =SHA256d(Tx i ) for each element Tx i is the output point Tx that is in the correct position according to the Bitcoin rule set i .Outpoints, and for each i∈{2,…,n} and for some index k, Tx i .Outpoints=(…,TxID i-1 Let us assume that the last transaction Tx n If is accepted by a node on the Bitcoin network, each element Tx i is a valid transaction, and TxSet is a transaction chain. Moreover, if a TxSet is a primary transaction chain, then it is unique.

[0117] Certification:Tx nIf Tx is accepted by node A on the Bitcoin network, then all previous transactions are valid and have also been accepted by node A. n-1 is a valid transaction and is accepted by node A. This discussion is repeated up to Tx1. This is because for each element Tx i is a valid transaction and TxSet is a transaction chain.

[0118] Now, if TxSet is a primary transaction chain, we prove that it is unique. We prove this by induction for primary transaction chains of length N>1.

[0119] N=2: Consider a primary transaction chain with two elements (Tx1, Tx2).

[0120]

number

[0121] A second primary transaction chain such that

[0122]

number

[0123] Assume that there is.

[0124]

number

[0125] Therefore,

[0126]

number

[0127] and therefore

[0128]

number

[0129] It is.

[0130] Due to the one-way nature of the hash function and its resistance to collisions, Tx1

[0131]

number

[0132] Therefore, either m=2 and both primary chains are the same, or the second primary chain of transactions is

[0133]

number

[0134] Since Tx1 is repeated, this contradicts Lemma 1. We conclude that (Tx1, Tx2) is a unique first-order transaction chain.

[0135] N=n-1 By our inductive hypothesis, (Tx1, Tx2, …, Tx n-1 ) is a unique primary transaction chain.

[0136] Element (Tx n-1 ,Tx n ) forms a first-order transaction chain of two elements. This chain is unique by the argument for the case N=2.

[0137] Two unique primary transaction chains (Tx1, Tx2, …, Tx n-1 ) and (Tx n-1,Tx n ) remains. Therefore, the combination (Tx1, Tx2, …, Tx n ) forms a unique primary transaction chain.

[0138] Zero-knowledge proofs As mentioned above, zero-knowledge proofs (ZKPs) can be used to prove knowledge of a secret without revealing any secret data.

[0139] A zero-knowledge proof demonstrates knowledge of a satisfactory proof for some non-deterministic polynomial (NP) statement without disclosing anything about that proof. zkSNARKs use non-interactive knowledge arguments, which are arguments that allow a verifier to confirm that the prover actually knows the proof.

[0140] A zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is a non-interactive zero-knowledge (NIZK) proof of knowledge that is concise and whose proofs are very short and easy to verify. A statement is expressed in terms of a logic circuit that is used to generate a proof of the statement. In the most efficient construction, the verifier simply performs a fixed number of group operations. A zkSNARK is a proof that for a given output, a secret input is generated for any function F.

[0141]

number

[0142] It uses linear probability proofs in combination with zero-knowledge techniques based on bilinear pairing and the discrete logarithm problem (DLP).

[0143] The concept of recursive zkSNARKS was initially started in Incrementally Verifiable Computation (IVC), where a proof not only proves the correct execution of a computation, but also proves the validity of previous proofs. Thus, a large, practically infinite, amount of computations can be easily verified with a single proof.

[0144] In a generic zkSNARK construction, the prover produces a proof π of knowing some public input x and a private input w that satisfy some relation R specified by an arithmetic circuit C. Note that the majority of use cases for zkSNARK construction in the blockchain world concern scalability rather than privacy. In this context, zkSNARK construction is flexible with respect to inputs, and the private input may be empty, i.e. w=⊥.

[0145] An arithmetic circuit C is used to represent a function F such that, given public inputs and outputs, the ZKP can be provided with a private input. The circuit is constructed from multiplication and addition gates. The output of a multiplication gate that is not the output of the entire circuit is labeled an auxiliary variable.

[0146] In zkSNARKs, a proof π proves the fact that R(x,w)=1, meaning that the statement is indeed true. The verifier then takes in a proof π and a public input x, and outputs 1 if the proof is valid. However, this verification itself can also be expressed as a relation R'; that is, for all valid inputs to the verifier, it can be expressed as R'(x,π):=V(x,π). Thus, proofs can be created that prove the validity of other proofs. The goal of recursive proof construction is to build ZKPs that verify other ZKPs, which allows for proof aggregation. This is used in embodiments of the present disclosure, as explained in more detail below.

[0147] The theory expressed below (Theorem 2) guarantees the existence of recursive zkSNARKs, given zkSNARK construction.

[0148] Theorem 2: If we have a zkSNARK with a succinct proof and it is adaptively secure, we can do it recursively, in the sense that we can use recursion to obtain a data primitive that carries the proof from it.

[0149] Consider a set S of system states with initial state s0∈S. i From s i+1 If and only if there is a valid transition to input state s i A predicate Π that evaluates to 1 on (or a commitment to) s In the context of this disclosure, a transaction is considered to be a state, and Π i Tx i-1 FromTx i Evaluates to true for valid transitions to

[0150] The Proof Carrier Data (PCD) system includes three algorithms:

[0151] Setup: Generate(Π S ,1 k ) Key generation is done by predicate Π S and a security parameter k as input (i.e., the system has k bits of security) and outputs a proof and verification key (pk, vk). Prover: Prove(pk,s i+1 ,TxSet,s i ,π i ,w i ) →π i+1 The prover gives the proof key pk and the current state s i and the next state s i+1 , evidence w i , s i Proof that is a valid state i (which proves that the old proof is already valid), and takes as input a set of valid transactions t ∈ TxSet, and s i →s i+1 Proof that is a valid state transitionπi+1 Output. · Verifier: Verify(vk,B i ,π i ) → Yes / No. Verification key vk, proof π i , and state s i Commitment to B i Given, the verifier must determine i But state s i If it is a valid proof that is valid, output "Yes", otherwise output "No" with a very high probability.

[0152] The proof and verification keys (pk, vk) may be created by an independent trusted party. This party needs to be trusted because knowledge of the private key of the proof key pk allows for the generation of fake proofs. Only one set of proof and verification keys (pk, vk) needs to be generated for one ZKP circuit. Thus, if the ZKP circuit is constant for a particular use case, this key generation process may only need to be performed once. In some implementations, the proof and verification keys (pk, vk) may involve multiple different parties as part of the key generation ceremony.

[0153] Note that in each iteration of proof generation, the prover and verifier can be different. In a recursive proof construction, the second prover does not need to trust the prover, since it first verifies the previous proof before generating a new proof of the current state. This means that many different token processors (i.e., blockchain service providers such as NFT providers) can use the same token protocol without having to trust each other.

[0154] Without loss of generality, the embodiments of the present disclosure are described with reference to the Halo framework (e.g., Halo, Halo 2, Halo infinite) from which different ZKP implementations can be used. The Halo construction is characterized by using the Sonic ZKP, a trustless recursive version of zkSNARKs that eliminates the need for a "trusted setup" while creating attestation and verification keys. The Halo 2 construction uses the Plonk ZKP. Halo has a Structured Reference String (SRS) that can be used to construct proofs with any transaction chain. That is, in the embodiments of the present disclosure, it is not necessary to generate trusted setup parameters (specific keys) for every single circuit.

[0155] However, embodiments of the present disclosure are not limited to ZKPs in the Halo framework and may utilize other types of recursive zkSNARKs. Note that a Groth16-like construction of a zkSNARK protocol is not homomorphic because it does not use polynomial commitments. Thus, a Groth16-like construction cannot be opened at a suitable random point and cannot be converted to a recursive zkSNARK through the accumulation method. However, it may be done in other ways, for example, through cycles of a pairing-friendly curve.

[0156] When using Halo construction, a Structured Reference String (SRS) is generated during setup and includes a proof / verification key pair (pk, vk). This setup is not limited to a single circuit; instead, the SRS is general-purpose and can be used for any circuit up to a given maximum size. Thus, the SRS can be used to construct proofs using any transaction chain. That is, it is not necessary to generate setup parameters (specific keys) trusted for each individual circuit. The SRS may be computed through a multi-party ceremony (which makes the system a kind of trustless system) and is proportional to the size of the circuit. Thus, it depends on the size of the circuit but not on the number of iterations. That is, the proof size and verification time in embodiments of the present disclosure do not increase with the depth of recursion.

[0157] A common approach to achieving recursive proof assembly is to first obtain a non-interactive knowledge argument about the satisfiability of an arithmetic circuit. A given circuit is satisfiable if there is a way to assign true values (0 or 1) to the input variables such that the input variables are evaluated to 1. In other words, if every variable assignment is evaluated to 0, then it is not satisfiable. For public input x and witness w, let C(x, w) = 1. The verification algorithm for this argument is encoded into such an arithmetic circuit. Assuming that the proof verification circuit is sub-linear with respect to the size of the circuit, by Theory 2 described above, it becomes possible to recursively verify a proof such that C(x, w) = 1 without disclosing any information about w. The circuit C in this construction is fixed, and the prover repeatedly interacts with the verifier to be involved in multiple arguments in the sequence.

[0158] Let M, Q, k be integers such that d = 4M = 2 k and 3Q < d. The arithmetic constraint system encoding C is a witness known only to the prover

[0159]

Number

[0160] and some instances of encoding public input

[0161]

number

[0162] This constraint system is satisfied for the i-th constraint a i b i =c i and some fixed iterative coding of C, where the q-th constraint is of the form

[0163]

number

[0164] In contrast,

[0165]

number

[0166] It consists of Q linear constraints, each of which is of the form:

[0167] In Halo, this relation deals with the fact that a particular circuit in a description never changes with each recursion. Halo constructions are computations that are incrementally verifiable rather than proofs carrying data. Commitment S in Halo constructions old and S new Note that,S,is always a commitment to the same polynomial S that specifies the constraints, but at different points (i.e., to the old and new states). On the verifier's side, this means that the verifier oldThis is reflected in the use of ,S,. Using variables as inputs requires changing S to result in a different circuit. That is, a different set of transaction chain rules will result in a different S commitment. In the primary transaction chain, the function to be verified is Tx i .PrevTxID==z i-1 The aim is to check whether z i-1 =SHA256d(Tx i-1 ).

[0168] Proving and verifying an ordered sequence of events An embodiment of the present disclosure considers a first transaction Tx0 (which may also include a representation of a digital asset) and considers another transaction Tx that occurred some time after Tx0. n When considering Tx0, n This addresses the problem of how to prove that there is a transaction chain (e.g., a primary transaction chain) that ties Tx0 to Tx0. A known solution involves downloading the entire history of the chain of transactions that originated from Tx0 and n This requires validation of each individual transaction until

[0169] A common but inefficient solution is to have each chain link (Tx i-1 ,Tx i One approach would be to use zkSNARKs by outsourcing the generation of proofs for each transaction to an untrusted third party to provide concise verification. However, with this approach, users must download and verify each proof. Instead of generating proofs for each transaction, it may be possible to use a third party to generate a single proof for the entire transaction chain where the computation required is of a similar size.

[0170] However, in embodiments of the present disclosure, the attesting computing device can provide a single proof to show recursively that all previous proofs are indeed validated. In this way, a user only needs to download the first transaction Tx0 (which may include the digital asset) in addition to the current state of the network (i.e., the most recent transaction at the end of the transaction chain) and a single proof that this state is correct in order to verify the transaction chain.

[0171] FIG. 6 illustrates transactions in a transaction chain sent between user computing devices 102.

[0172] Figure 6 shows a transaction chain starting with a first transaction, TX0 602, which we call the issue transaction. The transaction ID TxID0 of the issue transaction 602 acts as a unique identifier for the transaction chain. That is, the transaction ID of the issue transaction (i.e., TXID0=SHA256d(Tx0)) is the identifier carried on the transaction chain.

[0173] As a first example, FIG. 6 illustrates a use case where a transaction in a transaction chain represents a transfer of ownership of a digital asset. In this example, as shown in FIG. 6, an issue transaction 602 may include a payload that includes a digital asset (DA). The digital asset may be digital currency, an image, an audio file, and / or text. In one example, the digital asset is a non-fungible token (NFT). Specifically, the payload of the issue transaction 602 may include a unique identifier of the NFT (e.g., a serial number), an identifier of the token creator, an identifier of the storage location of the NFT, and / or its most recent purchase price, etc. In some implementations, the payload of the issue transaction 602 may include a hash digest of the DA.

[0174] In the issue transaction 602 shown in Figure 6, a signature, which may be from the issuer itself, is in the unlock script of Tx0, and the digital asset may be embedded after the OP_RETURN statement. As shown in Figure 6, the first output of Tx0 contains the P2PKH lock script along with the public key of user U1. This assigns ownership of the digital asset to user U1.

[0175] As shown in FIG. 6, an issuance transaction 602 is sent to a computing device 102a associated with a user U1.

[0176] Assume that user U1 wishes to allocate digital assets to user U2 and does so by creating a new transaction Tx1604. In an embodiment of the present disclosure, user U1 performs an initialization process that is run only once (i.e., no other users involved in the transaction chain perform the initialization process). The steps performed by user U1 are described in more detail below with reference to Figures 7a and 7b.

[0177] In the primary transaction chain, the first input of transaction Tx1 604 consumes the first output of issuing transaction Tx0 602.

[0178] The first output of Tx1 includes the P2PKH script along with the public key of user U2. In addition to providing transaction Tx1 604 to the computer device 102b associated with user U2, user U1 also provides proof data to the computer device 102b associated with user U2. This allows recursive proofs to be built up by following users U2, U3, ... in subsequent transactions.

[0179] Upon receiving transaction Tx1604, the computing device 102b associated with user U2 verifies the proof provided in the proof data. i-1 Upon receipt of the user U iThe steps performed by are described in more detail below with reference to FIG.

[0180] Now assume that user U2 wants to transfer digital assets to user U3 and does so by creating a new transaction Tx2606. In an embodiment of the present disclosure, user U2 (and any other users later involved in the transaction chain) performs a recursive process. The steps performed by user U2 are described in more detail below with reference to Figures 9a and 9b.

[0181] In the primary transaction chain, the first input of transaction Tx2 606 consumes the first output of transaction Tx1 604.

[0182] The first output of Tx2 includes the P2PKH script along with the public key of user U3. In addition to providing transaction Tx2 606 to the computer device 102c associated with user U3, user U2 also provides proof data to the computer device 102c associated with user U3.

[0183] It can be seen from the above that each transaction comprises event data relating to the transfer of ownership of a digital asset (where the event in this use case is a digital asset being transferred between users).

[0184] FIG. 6 illustrates embedding a digital asset (or a hash digest thereof) in an issuance transaction 602. Subsequent transactions may also include the digital asset (or a hash digest thereof), but this is optional. In fact, including the digital asset (or a hash digest thereof) is not required for any of the transactions. For example, a database or other storage location on the remote device may store event data associated with each transaction in the transaction chain. For example, in an example where the digital asset is an NFT, the remote device may store a transaction ID for each transaction in the transaction chain and associate the transaction ID with an identifier for the digital asset. In an example where the digital asset is a digital currency, the remote device may store a transaction ID for each transaction in the transaction chain and associate the transaction ID with the amount of digital currency transferred by the transaction.

[0185] Figure 6 illustrates a use case where a transaction on the transaction chain represents a transfer of ownership of a digital asset, but this is just an example.

[0186] In other embodiments, each transaction in a transaction chain may comprise event data in the form of a data record associated with a physical or digital object. For example, the event data in a transaction may record the completion of a manufacturing step of a car (i.e., a physical object) or record revisions to an electronic file (i.e., a digital object), such as a text document, spreadsheet, or other electronic file. In further embodiments, each transaction in a transaction chain may comprise event data in the form of a data record associated with a person. For example, the event data in a transaction may record a person's gambling activities at an online casino, or the event data in a transaction may record communications between a person and their doctor. A data record associated with a transaction may be a modified version (e.g., by adding, deleting, or modifying data) of a previous data record associated with a immediately preceding transaction. Alternatively, a data record associated with a transaction may comprise data that is completely different from the data of a previous data record associated with a immediately preceding transaction.

[0187] In these other embodiments, the transactions in the transaction chain may comprise event data, or in a manner similar to that described above, a database or other storage location on the remote device may store the event data associated with each transaction in the transaction chain. For example, the remote device may store a transaction ID for each transaction in the transaction chain and associate the transaction ID with the respective data record.

[0188] In FIG. 6, the users (U1, U2, U3, Un) may be, for example, individual users, organizations, or departments or divisions within an organization.

[0189] In some embodiments, transactions in a transaction chain are transmitted between computing devices of users involved in the transaction chain.

[0190] In some embodiments, the transaction is a blockchain transaction (i.e., a transaction committed to the blockchain 150 through an interaction with the blockchain network 106). i sends the transaction to a further user U i+1 To send to i The computing device of the user U may send the transaction to one or more blockchain nodes 104, which then disseminates the transaction across the network of blockchain nodes 104 and thereby includes it in the blockchain 150. i+1 A user U’s computing device can receive a transaction by reading it from the blockchain. i of computing devices, more users i+1 may transmit the transaction to a computing device of a further user U i+1 The computing device may then transmit the transaction to one or more blockchain nodes 104, which then disseminates the transaction across the network of blockchain nodes 104 and thereby includes it in the blockchain 150.

[0191] Although FIG. 6 shows a transaction comprising proof data, this is by way of example only, and the proof data may remain outside the transaction as long as it is disseminated between particular users through some communication channel.

[0192] 7a illustrates a method 700 for providing proof of an ordered sequence of events. The method 700 is performed by a computing device in response to receiving an initial transaction. For example, referring to FIG. 6, the method 700 is performed by a computing device 102a associated with a user U1.

[0193] In step S702, the computing device 102a receives a publishing transaction Tx0602 for a first event.

[0194] User U1 wants to record further events. In step S704, the computing device 102a obtains the verification data for sending to the further users. In an embodiment of the present disclosure, user U i The proof data obtained by i-1 (ii) the transaction ID TxID0 of the issuing transaction 602, and (iii) an identifier z, which is the identifier of a previous transaction in the transaction chain. i-1 Equipped with.

[0195] FIG. 7b shows step S704 in more detail.

[0196] In step S752, the computing device 102a sets the identifier z0 to a predefined initial value. Although Fig. 7b shows the identifier z0 being set to 0, this is by way of example only and other values ​​may be used to indicate that the proof is a "null" proof since the previous transaction was the issuing transaction Tx0 602.

[0197] In step S754, the computing device 102a sets the initial proof π0 to a predefined proof value. For example, the initial proof π0 may be set to 1 to assume that the proof is valid by default.

[0198] In step S756, the computing device 102a determines the transaction ID TxID0 of the issuing transaction 602 by reading it from the issuing transaction 602.

[0199] Returning to FIG. 7a, once the computing device 102a obtains the proof data in step S704, in step S706, the computing device 102a creates a new transaction Tx1604 with an output including the P2PKH script together with the public key of user U2.

[0200] In step S708, the computing device 102a transmits the transaction Tx1604 and the proof data to the computing device 102b associated with the user U2. The proof data provides the user U2 with proof that there is a transaction chain linking the transaction Tx1604 to the issuing transaction 602.

[0201] As described above, the proof data obtained in step S704 may be provided within a field of transaction Tx 1604. For example, the proof data may be included in a consumable output of transaction Tx 1604. Alternatively, the proof data may be included in a non-consumable output of transaction Tx 1604, such as an OP_RETURN payload or an OP_FALSE OP_RETURN payload.

[0202] Alternatively, the proof data obtained in step S704 and the transaction Tx1604 may be transmitted separately to the computing device 102b.

[0203] 8 illustrates a method 800 for validating an ordered sequence of events. The method 800 is performed by a computing device in response to receiving a transaction that is not the first transaction in a transaction chain. That is, the method 800 performs the following steps: i-1 When user U receivesi It is executed by.

[0204] Referring to the example of FIG. 6 described above, a computing device 102b associated with user U2 (as well as computing devices 102 associated with subsequent users involved in the transaction chain) performs method 800.

[0205] In step S802, the user U i The computer equipment associated with i-1 from a further computing device associated with the transaction Tx i-1 That is, with respect to the computing device 102b, the computing device 102b associated with the user U2 receives the transaction Tx1604 from the computing device 102a associated with the user U1.

[0206] In step S804, the user U i The computing device associated with the user U receives the proof data. i The proof data received by i-2 , (ii) the transaction ID TxID0 of the issued transaction 602, and (iii) the identifier of the previous transaction z i-2 (i.e., U i-1 Typically (for i≧3), z i-2 is U i-1 , but there is a unique instance for user U2 where identifier z0 corresponds to the transaction ID of a transaction in the transaction chain received by the computing device associated with user U2, as described above, in which identifier z0 is set to a predetermined initial value.

[0207] That is, with respect to the computing device 102b, the computing device 102b associated with the user U2 receives the initial certificate π0, the transaction ID TxID0 of the issuance transaction 602, and the identifier z0.

[0208] As explained above, the proof data may be inserted into transaction Tx 1604 or transmitted outside of transaction Tx 1604.

[0209] In step S806, the proof π i-2 To verify this, the user U i The computer equipment associated with the proof π i-2 , identifier z i-2 , the transaction ID TxID0 of the issuing transaction 602, and the verification key vk as inputs to a proof verification process, which outputs a decision of acceptance or rejection depending on whether the proof is found to be valid or invalid.

[0210] vk, TxID0, Tx i-1 , and Tx i (User U i Created by π i-1 , z i-1 (Tx0,…,Tx i-1 ) is proof π i-1 If it is verified, the new owner U i+1 If the original transaction Tx0 contains digital assets, this proof is accepted as a transaction chain by Tx i It also guarantees proof of ownership for the owner.

[0211] The verifier checks that the issuing transaction Tx0 is bound to the last transaction given. Thus, the last verification step ensures that the first proof started with the original transaction. Also, in the case of an issuing transaction with an OP_RETURN payload as shown in Figure 6, once the proof of ownership transfer is validated, the receiver accepts the proof and verifies the signature of the original issuer of the asset, Sig. issuer can be verified.

[0212] 9a and 9b illustrate a method 900 for providing proof of an ordered sequence of events. The method 900 is performed by a computing device in response to receiving a transaction that is not the first transaction in a chain of transactions.

[0213] For example, referring to FIG. 6, method 900 is performed by computing equipment 102b associated with user U2 when user U2 wishes to record a further event (e.g., when user U2 wishes to transfer digital assets to U3 by generating transaction Tx2606), and also by any subsequent users in the transaction chain who wish to record an event.

[0214] In step S902, the user U i The computing device 102 associated with the received transaction Tx i-1 Verify that satisfies at least one given condition.

[0215] That is, with respect to the computing device 102b, the computing device 102b associated with the user U2 verifies that the received transaction Tx1604 satisfies at least one predetermined condition.

[0216] At least one predetermined condition may specify that a transaction consumes a transaction output of a previous transaction (the immediately preceding transaction) in the transaction chain.

[0217] Additionally or alternatively, the at least one predetermined condition may specify that the transaction comprises an index of a transaction output of the transaction. For example, the at least one predetermined condition may specify that a transaction input of the transaction comprises an index of a transaction output of the transaction (which transaction output may store the event data).

[0218] Additionally or alternatively, the at least one predetermined condition may specify that the first input of the transaction consumes the first output of a previous transaction in the transaction chain, i.e., the received transaction is part of a primary transaction chain. n Let Tx0,…,Tx be a valid blockchain transaction with multiple input UTXOs and multiple output UTXOs. n ) is also a transaction chain. Note that the lock script of the first output of Tx0 may also contain digital assets. The given condition is xSet=(Tx0, Tx1, ..., Tx n ) is the primary transaction chain. n ), a received transaction (e.g., with ownership transfer) is a chain of transactions Tx0, Tx1, …, Tx n is accepted only if it is the first index of

[0219] Additionally or alternatively, the at least one predetermined condition may specify that a unique token ID (UTID) is recorded in the received transaction.

[0220] Additionally or alternatively, the at least one predetermined condition may specify that a transaction chain sequence number i is recorded for each transaction in the chain.

[0221] Additionally or alternatively, at least one predefined condition may specify that the received transaction records the results of a predefined program for a given set of inputs. Some of the inputs may be the result of a calculation from a previous transaction in the transaction chain, and some may be new inputs. The issuing transaction may include a predefined code and an initial set of inputs. Such a rule set ensures that the execution of the program can be independently verified at each stage.

[0222] Each transaction may record the state of a Deterministic Finite Automata (DFA), and at least one predefined condition may enforce that the correct state transition is taken.

[0223] It will be appreciated that the at least one predetermined condition may comprise one or any combination of the examples mentioned above.

[0224] In step S904, the computing device 102b obtains the proof data for further transmission to the user. As described above, in an embodiment of the present disclosure, the user U i The proof data obtained by i-1 (ii) the transaction ID TxID0 of the issuing transaction 602, and (iii) an identifier z, which is the identifier of a previous transaction in the transaction chain. i-1 Equipped with.

[0225] FIG. 9b shows step S904 in more detail.

[0226] In step S952, the user U i The computer equipment associated with transaction Tx i-1Identifier z is obtained by taking the double hash of i-1 That is, with respect to the computing device 102b, the computing device 102b associated with the user U2 calculates the identifier z1 by taking a double hash of the transaction Tx1604.

[0227] In step S954, the user U i A computing device associated with i-1 (Transaction Tx i-1 or in transaction Tx i-1 Transaction Tx, which may be sent separately from i-1 , which contains the proof data associated with i-1 That is, with respect to the computing device 102b, the computing device 102b associated with the user U2 constructs the proof π1 by providing the proof key pk and the transaction Tx1604 (including the proof data associated with the transaction Tx1604) as inputs to a proof generation process. i-1 Transaction Tx i-2 and transaction Tx i-1 Prove the connection between.

[0228] In step S956, the user U i The computing device associated with the user U identifies the transaction ID TxID0 of the issuing transaction in the transaction chain. Step 956 may be performed in a number of different ways. In one example, i The transaction ID TxID0 of the issued transaction is taken as the transaction Tx i-1 That is, with respect to the computing device 102b, the computing device 102b associated with the user U2 identifies the transaction ID TxID0 of the issuance transaction 602.

[0229] Returning to FIG. 9a, once the computing device has obtained the proof data in step S904, in step S906 the computing device i+1 A new transaction Tx with an output containing the P2PKH script along with the public key of i Thus, in step S906, the computing device 102b creates a new transaction Tx2 606 with an output including the P2PKH script along with the public key of user U3.

[0230] In step S908, the computing device 102b transmits the transaction Tx2 606 and the proof data to the computing device 102c associated with the user U3. The proof data provides the user U3 with proof that there is a transaction chain linking the transaction Tx2 606 to the issuing transaction 602.

[0231] As described above, the proof data obtained in step S904 may be provided within a field of transaction Tx 2606. For example, the proof data may be included in a consumable output of transaction Tx 2606. Alternatively, the proof data may be included in a non-consumable output of transaction Tx 2606, for example, in an OP_RETURN payload or an OP_FALSE OP_RETURN payload.

[0232] Alternatively, the proof data obtained in step S904 and the transaction Tx2606 may be transmitted separately to the computing device 102c.

[0233] In an embodiment of the present disclosure, the proof size is about 3.5kb and is independent of the number of transactions in the chain. The proofs are recursive, which means that if additional transactions are added to the transaction chain, the proofs can be updated without repeating any computations.

[0234] The proof-carrying data is small enough to be included in the OP_RETURN statement in each transaction. This allows this approach to be an on-chain token protocol that eliminates the need to trace back to issuance. In this architecture, the blockchain network 106 is used for double-spend protection and to store the proof-carrying data. The blockchain nodes 104 play no role in proof construction or validation.

[0235] conclusion Those skilled in the art will understand that the steps involved in the proof generation process performed by a proving computer device will depend on the particular type of ZKP being implemented, and that such steps will be known to those skilled in the art. Similarly, those skilled in the art will understand that the steps involved in the proof verification process performed by a verifier computer device will depend on the particular type of ZKP being implemented, and that such steps will be known to those skilled in the art.

[0236] Other variations or uses of the disclosed techniques may be apparent to those of ordinary skill in the art given the disclosure herein. The scope of the disclosure is limited only by the appended claims, and not by the described embodiments.

[0237] Some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply 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 reference 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 properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

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

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

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

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

[0242] Aspects of the present disclosure are defined below with reference to the following clauses:

[0243] 1. A computer-implemented method for providing a proof of an ordered sequence of events, the method being executed on a computing device and comprising: receiving a transaction; creating a further transaction to be transmitted to a further computing device; obtaining proof data associated with the further transaction, the proof data providing to a further computing device proof that the further transaction is linked to an initial transaction in a transaction chain comprising transactions, the initial transaction involving an initial event in an ordered sequence of events, the proof data comprising (i) a proof, (ii) an identifier of the transaction, and (iii) a unique identifier of the initial transaction; and transmitting the further transaction and proof data to a further computing device.

[0244] 2. The method of clause 1, wherein the transaction is an initial transaction and obtaining proof data comprises setting the proof to a predefined proof value and setting an identifier of the transaction to a predefined initial value.

[0245] 3. The method of clause 1, wherein the transaction is not the first transaction in a chain of transactions and the method comprises verifying that the transaction complies with at least one predetermined condition.

[0246] 4. The method of clause 3, wherein at least one predetermined condition specifies that a transaction consumes a transaction output of a previous transaction in the transaction chain.

[0247] 5. The method of clause 3, wherein at least one predetermined condition specifies that the transaction comprises an index of a transaction output of the transaction.

[0248] 6. The step of obtaining proof data comprises: generating a proof using the transaction and the proof key; 6. The method of any of clauses 3 to 5, comprising the step of: calculating an identifier for the transaction.

[0249] 7. The method of any preceding clause, comprising the step of including the proof data in a further transaction.

[0250] 8. The method of clause 7, comprising including the proof data in a consumable output of the further transaction.

[0251] 9. The method of clause 7, comprising including the proof data in a non-consumable output of the further transaction.

[0252] 10. The method of any of clauses 1 to 6, wherein the proof data is not included in the further transaction, and the method comprises the step of transmitting the further transaction and the proof data separately to the further computing device.

[0253] 11. The method of any preceding clause, wherein the transaction represents a transfer of ownership of the digital asset to a user associated with a computing device, and the further transaction represents a transfer of ownership of the digital asset to a further user associated with a further computing device.

[0254] 12. The method of clause 11 where the digital asset is a non-fungible token.

[0255] 13. Any of the methods of clauses 1 to 10, wherein a transaction is associated with event data, the event data involving an event in an ordered sequence of events, and a further transaction is associated with further event data relating to a later event in the ordered sequence of events.

[0256] 14. The method of clause 13, wherein the event data comprises a data record associated with a physical object or a digital object, and the further event data comprises a further data record associated with the physical object or the digital object.

[0257] 15. The method of clause 13, wherein the event data comprises a data record associated with the user, and the further event data comprises a further data record associated with the user.

[0258] 16. The method of any of clauses 13 to 15, wherein the transaction comprises a representation of event data and the further transaction comprises a representation of further event data.

[0259] 17. A method according to any of clauses 13 to 15, wherein the event data is stored on the remote device in association with an identifier of the transaction, and the method comprises the step of storing further event data on the remote device in association with an identifier of a further transaction.

[0260] 18. The method of any preceding clause where the transaction and the further transaction are blockchain transactions.

[0261] 19. A computer program which, when read by a computing device, causes the computing device to perform the method of any preceding clause.

[0262] 20. A non-transitory computer-readable storage medium comprising computer-readable instructions that, when read by a computing device, cause the computing device to perform any of the methods of clauses 1 to 18.

[0263] 21. A computing device comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the computing device to perform any of the methods of clauses 1 to 18.

[0264] 22. A computer-implemented method for verifying an ordered sequence of events, the method being executed on a computing device, comprising: receiving a transaction from a further computing device; receiving proof data associated with the transaction from a further computing device, the proof data comprising (i) a proof, (ii) an identifier of a previous transaction in the transaction chain, and (iii) a unique identifier of a first transaction in the transaction chain, the first transaction relating to a first event in the ordered sequence of events; and verifying that the transaction is linked to the first transaction in the transaction chain using the proof, an identifier of the previous transaction in the transaction chain, a unique identifier of the first transaction, and a verification key.

[0265] 23. The method of clause 22, wherein the transaction comprises proof data.

[0266] 24. A method as set forth in Clause 23 in which a transaction includes proof data in the transaction’s consumable output.

[0267] 25. A method in accordance with Clause 23 in which a transaction includes proof data in a non-consumable output of the transaction.

[0268] 26. A method as set forth in clause 22, in which the proof data is received separately from the transaction.

[0269] 27. The step of verifying that the transaction is linked to a first transaction in the transaction chain further comprises: Obtaining an initial transaction; calculating a unique identifier for a first transaction; and verifying that the calculated unique identifier of the first transaction matches the unique identifier of the first transaction in the proof data.

[0270] 28. The method of any of clauses 22 to 27, wherein the transaction represents a transfer of ownership of the digital asset from a user associated with the further computing device to a user associated with the computing device.

[0271] 29. The method of clause 28 where the digital asset is a non-fungible token.

[0272] 30. The method of any of clauses 22 to 27, wherein a transaction is associated with event data, the event data involving an event in an ordered sequence of events, and a further transaction is associated with further event data relating to a later event in the ordered sequence of events.

[0273] 31. The method of clause 30, wherein the event data comprises a data record associated with a physical or digital object, and the further event data comprises a further data record associated with the physical or digital object.

[0274] 32. The method of clause 30, wherein the event data comprises a data record associated with the user, and the further event data comprises a further data record associated with the user.

[0275] 33. Any of the methods of clauses 22 to 32, wherein the transaction is a blockchain transaction.

[0276] 34. A computer program which, when read by a computing device, causes the computing device to perform any of the methods of clauses 22 to 33.

[0277] 35. A non-transitory computer-readable storage medium comprising computer-readable instructions which, when read by a computing device, cause the computing device to perform any of the methods of clauses 22 to 33.

[0278] The instructions may be provided on a carrier such as a disk, CD-ROM or DVD-ROM, a programmed memory (firmware) such as a read-only memory, or a data carrier such as a carrier for an optical or electrical signal. Instructions for implementing embodiments of the present disclosure may comprise source code, object code or executable code in a conventional programming language (interpreted or compiled) such as C or assembly code, code for configuring or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array), or code for a hardware description language. [Explanation of symbols]

[0279] 101 Packet Switching Network 102 Computer Equipment 103 Related parties 104 Blockchain nodes 105 Client Applications 106 Blockchain Network 150 Blockchain 151 Blocks 152 Transactions 153 Genesis Block 154 Ordered Sets 155 Block Pointer 201 Header 202 Input Field 203 Output Fields 502 output points 504 Lock Script 506 Version Number 508 Rock Time 602 Issue Transactions 604 Transactions 606 Transactions

Claims

1. 1. A computer-implemented method for providing a proof of an ordered sequence of events, the method being executed on a computing device and comprising: receiving a transaction; creating a further transaction to be transmitted to a further computing device; obtaining proof data associated with the further transaction providing to the further computing device proof that the further transaction is linked to an initial transaction in a transaction chain comprising the transaction, the initial transaction involving an initial event in the ordered sequence of events, the proof data comprising (i) a proof, (ii) an identifier of the transaction, and (iii) a unique identifier of the initial transaction; transmitting the further transaction and the proof data to the further computing device; A method comprising:

2. the transaction is the first transaction, the step of obtaining proof data comprises setting the proof to a predetermined proof value; setting the identifier of the transaction to a predetermined initial value; The method of claim 1 , comprising:

3. the transaction is not the first transaction in the transaction chain; The method of claim 1 , wherein the method comprises the step of verifying that the transaction complies with at least one predetermined condition.

4. 4. The method of claim 3, wherein the at least one predetermined condition specifies that the transaction consumes a transaction output of a previous transaction in the transaction chain.

5. The method of claim 3 , wherein the at least one predetermined condition specifies that the transaction comprises an index of a transaction output of the transaction.

6. The step of obtaining the proof data comprises: generating the proof using the transaction and a proof key; calculating the identifier for the transaction; 6. The method according to claim 3, comprising:

7. A method according to any one of claims 1 to 6, comprising including said proof data in said further transaction.

8. The method of claim 7 , comprising including the proof data in a consumable output of the further transaction.

9. The method of claim 7 , comprising including the proof data in a non-consumable output of the further transaction.

10. the proof data is not included in the further transaction; The method of claim 1 , wherein the method comprises the step of transmitting the further transaction and the proof data separately to the further computing device.

11. the transaction represents a transfer of ownership of a digital asset to a user associated with the computing device; The method of claim 1 , wherein the further transaction represents a transfer of ownership of the digital asset to a further user associated with the further computing device.

12. 12. The method of claim 11, wherein the digital asset is a non-fungible token.

13. the transaction is associated with event data; the event data relates to an event in the ordered sequence of events; 11. The method of claim 1, wherein the further transaction is associated with further event data relating to a later event in the ordered sequence of events.

14. the event data comprises data records associated with physical or digital objects; The method of claim 13 , wherein the further event data comprises a further data record associated with the physical or digital object.

15. the event data comprises a data record associated with a user; The method of claim 13 , wherein the further event data comprises a further data record associated with the user.

16. the transaction comprises a representation of the event data; 16. The method of claim 13, wherein the further transaction comprises a representation of the further event data.

17. The event data is stored on a remote device in association with the identifier of the transaction; 16. The method according to any one of claims 13 to 15, wherein the method comprises the step of storing the further event data in association with an identifier of the further transaction on the remote device.

18. 18. The method of claim 1, wherein the transaction and the further transaction are blockchain transactions.

19. A computer program which, when read by a computing device, causes said computing device to perform the method of any one of claims 1 to 18.

20. A non-transitory computer readable storage medium having stored thereon computer readable instructions which, when read by a computing device, cause the computing device to perform the method of any one of claims 1 to 18.

21. A computing device comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the computing device to perform a method according to any one of claims 1 to 18.

22. 1. A computer-implemented method for verifying an ordered sequence of events, said method running on a computing device, comprising: receiving a transaction from a further computing device; receiving proof data associated with the transaction from the further computing device, the proof data comprising (i) a proof, (ii) an identifier of a previous transaction in the transaction chain, and (iii) a unique identifier of a first transaction in the transaction chain, the first transaction relating to a first event in the ordered sequence of events; verifying that the transaction is linked to the first transaction in the transaction chain using the proof, the identifier of the previous transaction in the transaction chain, the unique identifier of the first transaction, and a verification key; A method comprising:

23. The method of claim 22 , wherein the transaction comprises the proof data.

24. 24. The method of claim 23, wherein the transaction includes the proof data in a consumable output of the transaction.

25. 24. The method of claim 23, wherein the transaction includes the proof data in a non-consumable output of the transaction.

26. 23. The method of claim 22, wherein the proof data is received separately from the transaction.

27. verifying that the transaction is linked to the first transaction in the transaction chain, obtaining the first transaction; calculating a unique identifier for the first transaction; verifying that the calculated unique identifier of the first transaction matches the unique identifier of the first transaction in the proof data; 27. The method of any one of claims 22 to 26, further comprising:

28. 28. The method of claim 22, wherein the transaction represents a transfer of ownership of a digital asset from a user associated with the further computing device to a user associated with the computing device.

29. 30. The method of claim 28, wherein the digital asset is a non-fungible token.

30. the transaction is associated with event data; the event data relates to an event in the ordered sequence of events; 28. A method according to any one of claims 22 to 27, wherein the further transaction is associated with further event data relating to a later event in the ordered sequence of events.

31. the event data comprising a data record associated with a physical or digital object; The method of claim 30 , wherein the further event data comprises a further data record associated with the physical or digital object.

32. the event data comprises a data record associated with a user; The method of claim 30 , wherein the further event data comprises a further data record associated with the user.

33. 33. The method of any one of claims 22 to 32, wherein the transaction is a blockchain transaction.

34. A computer program which, when read by a computing device, causes said computing device to perform the method of any one of claims 22 to 33.

35. A non-transitory computer readable storage medium having stored thereon computer readable instructions which, when read by a computing device, cause the computing device to perform the method of any one of claims 22 to 33.

36. A computing device comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the computing device to perform a method according to any one of claims 22 to 33.

Images