Zero-knowledge proofs

Abstract

A computer-implemented method for generating zero-knowledge proofs for proving that each data block of a plurality of data blocks corresponding to a Merkle tree satisfies a predefined criterion. Leaf nodes are mapped to leaf hash values ​​of the Merkle tree, and interior nodes are mapped to interior hash values ​​of the Merkle tree. The leaf nodes are implemented such that each leaf node receives a respective data block and a corresponding data block proof for proving that the data block satisfies the predefined criterion, verifies the respective data block proof, and computes and outputs a data block hash. The interior nodes are implemented such that each interior node receives a respective hash value from each of its two previous nodes, computes and outputs an output hash value. The output hash value computed by the final interior node in the final layer of the Merkle tree is the Merkle root corresponding to the Merkle tree.

Description

[Technical Field]

[0001] The present disclosure relates to a method for generating zero-knowledge proofs for proving that leaves of a Merkle tree satisfy a predefined criterion, and a computer system for implementing the method. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a copy of the blockchain is maintained and publicly available at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). The blockchain includes a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding 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 a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes competing to solve a cryptographic puzzle based on a "proof-of-work"—a representation of a defined set of ordered, confirmed, pending transactions awaiting inclusion in a new block on the blockchain. Note that the blockchain may be pruned at some nodes, and the publication of blocks may be achieved simply by publishing the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: transferring digital assets (i.e., some digital tokens), ordering a collection of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or time-ordering index pointers. Blockchains can also be utilized to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storing additional user data or indexes to data in transactions. There is no predefined limit on the maximum amount of data that can be stored in a single transaction, and thus, more and more complex data can be incorporated. For example, this may be used to store electronic documents on a blockchain or to store audio or video data.

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

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, typically called a "coinbase transaction," that distributes a certain amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, who act as agents of the network and are incentivized to report and block fraudulent activity. Widespread publication of information allows users to continuously audit node performance. Publication of simple block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Every spendable output includes an element specifying the amount of a digital asset derivable from the ongoing sequence of transactions. A spendable output is sometimes called a UTXO (unspent transaction output). An output may further include a locking script that specifies the conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to approve and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output of a prior transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Consider a pair of transactions, called a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second, target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been fulfilled by another, previous, valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but possibly propagate to register an invalid transaction) 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 looking backwards at the UTXOs of previous transactions in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention [Means for solving the problem]

[0009] Known succinct zero-knowledge arguments of knowledge (SNARKs) for knowledge of a hash preimage or for Merkle tree statements, such as proving knowledge of an authentication path that matches a Merkle root, typically prove knowledge of either a witness taken from a fixed domain or of various sizes, but upper-bounded by a small constant. This is due to the monolithic approach of expressing the entire computation as a single circuit and proving the satisfiability of this circuit in a single computation. Indeed, the larger the size of the witness, the larger the size of the circuit, making the prover algorithm more time / space consuming.

[0010] Herein, a new method for generating zero-knowledge proofs is presented that departs from known monolithic approaches. Instead, recursive SNARKs, or more specifically, proof-carrying data (PCD), are used. PCD is a primitive for proving the correct evaluation of a distributed computation (whose transcript can be described using a graph). Each node (i) calculates the compliance Π(z in , z loc , z out ) = 1 and (ii) the validity of the proof attached to the input data. Thanks to the recursive nature of proof generation (which verifies the incoming proof), the verifier only needs to verify the proof generated by the last (sink) node in the computation transcript.

[0011] The focus is two-fold. a) Interpret the entire computation as a "distributed" computation, where a potentially large computation is broken down into a series of small subroutines (resulting in tractable circuits). Each node only performs an instantiation of a given subroutine -- in particular, if a subroutine is one step of a loop, there will be as many nodes as there are iterations of the loop. b) Leveraging existing PCD methods for well-described compliant computational transcripts (which internally invoke the PCD algorithm) constructs the resulting SNARK.

[0012] Any PCD scheme can be used for step (b). In Section 8.1, the choice of curves when working with pairing-based pre-processing PCD is discussed.

[0013] According to one aspect disclosed herein, there is provided a computer-implemented method for generating a zero-knowledge proof for proving that each data block of a plurality of data blocks corresponding to a Merkle tree satisfies a predefined criterion, the Merkle tree including a plurality of leaf hash values ​​and a plurality of inner hash values, the plurality of inner hash values ​​being arranged in layers, a plurality of leaf nodes being mapped to the plurality of leaf hash values, and a plurality of inner nodes being mapped to the plurality of inner hash values, the method including the steps of executing a plurality of leaf nodes, each leaf node receiving a respective data block and a corresponding data block proof for proving that the data block satisfies the predefined criterion, verifying the respective data block proof, calculating a data block hash based on the respective data block, and a plurality of internal nodes configured to receive a respective hash value from each of two previous nodes in a Merkle tree, calculate an output hash value based on the respective received hash values, and output the output hash value; wherein the respective received hash values ​​of a first layer of the plurality of internal nodes are respective data block hashes received from respective leaf nodes, the respective received hash values ​​of each of the plurality of internal nodes are respective output hash values ​​received from respective internal nodes, and the output hash value calculated by a final internal node in a final layer of the Merkle tree is a Merkle root corresponding to the Merkle tree.

[0014] This disclosure provides concise zero-knowledge knowledge arguments (SNARKs) for hash-based statements. Proof generation is scalable and incrementally computable. For example, to prove knowledge of an arbitrarily large SHA256 preimage (e.g., a preimage of 1 GB or more), the memory requirements for the prover can be the same as the requirements for proving knowledge of a 512-bit preimage.

[0015] In general, the running time of the prover scales well with the size of the private input (proof - which could be, for example, a large preimage or many leaves of a Merkle tree), which means that there are no hard requirements on the prover's hardware (RAM).

[0016] Also, proof generation can be paused and resumed at a later stage, not necessarily by the same prover. In particular, proof generation can be distributed among several nodes that know only a portion of the private input. This can be achieved thanks to the incremental nature of the SNARKs provided herein.

[0017] The succinct property of SNARKs also ensures that the size of the proof is constant regardless of the size of the proof (or is only logarithmic to the size of the proof).

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

[0019] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 shows a schematic representation of a computational transcript of a function f(x, y) := (2(x + y), 3(x + y)) with bounded noise. [Figure 4] FIG. 1 shows a schematic diagram of a SHA2 transcript. [Figure 5] FIG. 10 is a diagram illustrating the input relationship of a SHA2 node. [Figure 6] FIG. 1 provides an exemplary method for proving knowledge of a preimage using zero-knowledge proofs. [Figure 7] FIG. 1 is a diagram illustrating a Merkle tree for generating a zero-knowledge proof for proving that each leaf of the Merkle tree satisfies a criterion. [Figure 8] FIG. 1 provides an exemplary method for proving that each leaf of a Merkle tree satisfies a criterion. [Figure 9] Multiple Predicates for Efficient and Scalable Zero-Knowledge Proofs

number

[0020] 1. Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple 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 tightly connected to the other blockchain nodes 104.

[0021] Each blockchain node 104 includes a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

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

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

[0024] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered collection (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term, as used herein, is not intended to be limited to any particular blockchain, protocol, or model. This term refers to an ordered collection of transactions that a node 104 accepts as valid and that the node 104 is obligated to not accept any other transactions attempting to consume the same output.

[0025] For a given current transaction 152j, the (or each) input contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be fulfilled or "consumed" in the current transaction 152j. Consuming or fulfilling does not necessarily mean the transfer of financial assets, although that is certainly one common use. More broadly, consuming may be described as spending an output or allocating an output to one or more outputs of another onward transaction. In general, a previous transaction may be any transaction within the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist at the time the current transaction 152j is created or even sent to the network 106, but the previous transaction 152i must exist and be approved for the current transaction to be valid. Thus, "predecessor" herein refers to a predecessor in a logical sequence linked by pointers, and not necessarily to a time of creation or transmission in a temporal sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may also be referred to as an antecedent or predecessor transaction.

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

[0027] According to an output-based transaction protocol such as Bitcoin, when a participant 103, such as an individual user or an organization, wants to execute a new transaction 152j (either manually or through an automated process employed by the participant), the initiator sends the new transaction from their computer terminal 102 to a recipient. The initiator or recipient ultimately transmits this transaction to one or more blockchain nodes 104 of the network 106 (currently typically a server or data center, but in principle could be other user terminals). It is also not excluded that the participant 103 executing the new transaction 152j may transmit the transaction directly to one or more blockchain nodes 104 and, in some instances, not to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol generally requires the blockchain nodes 104 to check that the cryptographic signature of the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that a cryptographic signature or other authorization of a party 103 included in the input of a new transaction 152j matches a condition defined in the output of a prior transaction 152i that the new transaction consumes (or "allocates"), which condition generally includes at least checking that the cryptographic signature or other authorization of the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the prior transaction 152i.Alternatively, the conditions may be determined solely by the blockchain node protocol, or may result from a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction 152j 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 thus forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

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

[0029] In addition to approving transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process supported by "proof of work," typically referred to as mining. At a blockchain node 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. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Generally, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; others are not excluded. A property of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force, thus expending a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0030] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof that can then be easily checked by other blockchain nodes 104 in the network (given the hash solution, it is easy to check that it satisfies the conditions on the hash output). The first blockchain node 104 accepts the block and therefore propagates it to a threshold consensus of other nodes that enforce the rules of the protocol. The ordered set of transactions 154 is then recorded in the blockchain 150 by each of the blockchain nodes 104 as a new block 151. The new block 151n is also assigned a block pointer 155 that points backward to the previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of hashing, required to create the proof-of-work solution signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously approved transaction, also known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 of the blockchain network 106. Block pointers 155 also impart a chronological order to blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks on each blockchain node 104 of the network 106.

[0031] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool 154 of transactions not yet published at any given time, depending on when those blockchain nodes 104 began searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool 154 of unpublished transactions, and so on. There is also a protocol for resolving any possible "forks," where two blockchain nodes 104 solve their puzzles within a very short time of each other so that conflicting views of the blockchain are propagated between the nodes 104. In short, the longest fork's tine becomes the final blockchain 150. Note that this should not affect users or agents of the network, as the same transaction appears in both forks.

[0032] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate additional authorized amounts of digital assets in a new, special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is typically called a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” This special type of transaction generally forms the first transaction of a new block 151n. The proof of work signals the node constructing the new block’s intent to follow the rules of the protocol, which allow this special transaction to be subsequently executed. The rules of the blockchain protocol may require a maturity period, e.g., 100 blocks, before this special transaction may be executed. Often, a regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as the "transaction fee" and is discussed below.

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

[0034] 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 or roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that all actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0035] Further connected to the network 101 are computing devices 102 for each of a number of participants 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in approving transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some 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).

[0036] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not fulfill the required role of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106 by connecting to (i.e., communicating with) a blockchain node 106, thereby utilizing the blockchain 150. For illustrative purposes, two participants 103 and their respective devices 102 are shown: a first participant 103a and its respective computing device 102a, and a second participant 103b and its respective computing device 102b. It will be understood that many additional such participants 103 and their respective computing devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely for purposes of illustration, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be understood that this is not limiting and all references herein to Alice or Bob may be replaced by "first party" and "second party" respectively.

[0037] The computing equipment 102 of each participant 103 includes a respective processing unit including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each participant 103 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing equipment 102 of each participant 103 stores software including a respective instance of at least one client application 105 arranged to execute on the processing unit. It will be understood that all actions attributed to a given participant 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each participant 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given participant 103 may also include one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

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

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

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

[0041] 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 enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for which each party 103 is the recipient of any transactions (or, in embodiments, to verify the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality of each computing device 102 is configured to assemble and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to approve transactions 152 according to the blockchain node protocol and forward transactions 152 to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol together with a given node protocol implements 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.

[0042] When a given party 103, e.g., Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she assembles the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. The party 103 then transmits the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it processes the new transaction 152j according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be discussed in more detail shortly. In some transaction protocols, conditions for approval may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions could simply be a built-in feature of the node protocol or defined by a combination of the script and the node protocol.

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

[0044] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins a race to solve a proof-of-work puzzle for the latest version of its respective pool 154 of transactions, including the new transaction 152j. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions; whoever succeeds first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, the pool 154 immutably becomes part of one of the blocks 151 of the blockchain 150. Each transaction 152 includes a pointer back to previous transactions; therefore, the order of the transactions is also immutably recorded.

[0045] Different blockchain nodes 104 initially receive different instances of a given transaction and may therefore have conflicting views of which instance is "valid" before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then later discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance that it originally accepted (i.e., the instance that was not published in block 151).

[0046] 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 an account-based system, each transaction defines the amount to be transferred by referencing an absolute account balance, rather than by referencing the UTXO of a previous transaction backward in a sequence of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be assigned to a transaction. This data field may point backward to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0047] 2. 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 the fundamental data structure of a blockchain 150 (each block 151 contains 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. Note that the exemplary UTXO-based protocol is described in relation to Bitcoin, but may be similarly implemented in other exemplary blockchain networks.

[0048] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO is not already fulfilled). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. 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 submitted to the node 104.

[0049] Suppose Alice 103a wishes to create transaction 152j to send the amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1." Transaction 152j takes the amount of the digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and sends at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 may point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

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

[0051] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script of the input 202 of the subsequent transaction for the subsequent transaction to be approved and, therefore, for the UTXO to be successfully fulfilled. Generally, 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 unlocking conditions that generally include a condition that the unlocking script of the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

[0052] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S), used by blockchain networks. A lock script specifies what information is required to consume a transaction output 203, for example, the need for Alice's signature. An unlock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the lock script's criteria. For example, an unlock script might include Bob's signature. An unlock script appears in the transaction's input 202.

[0053] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 must contain Alice's signature Sig P for UTXO0 to be fulfilled (or, more precisely, for any subsequent transaction attempting to fulfill UTXO0 to be valid). A Requires a lock script [Checksig P A ]. [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer that points back into Tx0 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predefined 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 a lock script, or by a node protocol, or by a combination of these.

[0054] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts, i.e., <Sig P A > <P A > || [Checksig P A ] where "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function included by the lock script (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. In either case, when executed together, the scripts will use Alice's public key P, included in the lock script of the output of Tx0.A is used to authenticate that the unlock script in Tx1's input contains Alice's signature, which signs the expected portion of the data. The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (thus a separate element specifying the signed portion of the plaintext data need not be included, as it is already inherently present).

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

[0056] If the unlock script of Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, if Alice's signature is provided in Tx1 and is authenticated), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that transaction Tx1 is propagated throughout the network 106. Once Tx1 is approved and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it consumes unspent transaction outputs 203. If Tx1 attempts to consume outputs that have already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO of the prior transaction Tx0 has already been spent (i.e., whether that UTXO already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database indicating which UTXOs 203 of which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it has already formed a valid input to another valid transaction in blockchain 150.

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

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

[0059] In practice, Alice must also typically include a fee to any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus, while technically valid, may not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 of a given transaction 152 and the total amount specified in the output 203 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 (or consumed) 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 one of transaction 152's UTXOs 203 itself.

[0060] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere on the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere on the blockchain 150 that defines a given party's 103 total balance. It is the responsibility of a wallet function within the client application 105 to compile the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. The wallet function can do this by querying a copy of the blockchain 150 stored on one of the Bitcoin nodes 104.

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

[0062] Generally, the input to 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 portions of the outputs that the signature signs depend on the SIGHASH flag, which is a 4-byte code typically included at the end of the signature (and therefore fixed at the time of signing) to select which outputs are signed.

[0063] A lock script may be referred to as a "scriptPubKey," generally referring to the fact that it contains the public key of the party to whom each transaction is locked. An unlock script may be referred to as a "scriptSig," generally referring to the fact that it provides the corresponding signature. However, more broadly, it is not required in all applications of blockchain 150 that the condition for a UTXO to be fulfilled include authenticating the signature. More broadly, a scripting language may be used to define any condition or conditions. Therefore, the broader terms "lock script" and "unlock script" may be preferred.

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

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

[0066] 4. SHA2 Hash SHA2 is a cryptographic hash algorithm.

[0067]

number

[0068] Message

[0069]

number

[0070] as input and generate a d-bit digest H∈{0,1} d The length of M can vary up to a certain upper bound.

[0071]

number

[0072] The digest length is fixed. "SHAd" is used to denote a cryptographic hash function of the SHA2 family that outputs a digest of size d.

[0073] SHAd proceeds in two stages. First,

[0074]

number

[0075] The message M is divided into N blocks of fixed size m. For this purpose, padding is required, M (1) || … || M (N-1) || M (N) := pad(M) is.

[0076] The padding is defined as follows: k is

[0077]

number

[0078] Add a 1 to the end of M, followed by k zeros. Then,

[0079]

number

[0080] corresponds to the binary representation of

[0081]

number

[0082] The result of padding is that at most one extra block is added.

[0083]

number

[0084] If the bits fit into B blocks of m bits each, then after padding there will be at most B + 1 blocks. The extra blocks are

[0085]

number

[0086] It is added only if

[0087] The second step of SHAd is to apply the compression function σ to the input message block and the previous compressed value. CF m,d : {0,1} m ×{0,1} d →{0,1} d Iteratively applies the following. The first compressed value is the initialization vector IV, which is set to a specific constant d-bit array for each SHAd function. In summary, the SHAd(M) algorithm is as follows: 1. M (1) || … || M (N-1) || M (N) := pad(M) 2. H (0) := Set IV 3. For i = 1 to N, H i := CF m,d (H (i-1) , M (i) ) 4. H := H (N) Output

[0088] The table below gives the parameters for the SHA256 and SHA512 functions.

[0089] [Table 1]

[0090] 5. Proof Systems 5.1 zkSNARKs Let P(x;w) = b∈{0,1} be an efficiently computable binary program that takes a bit string x (the instance) as public input, another bit string w (the evidence) as private input, and outputs a decision bit b. If b = 1, then P accepts.

[0091] The relevant NP relation R is given by the instance / evidence pairs that we want program P to accept. R := {(x,w) | P(x,w) = 1}

[0092] A preprocessing succinct non-interactive argument system of knowledge (SNARK) for the correct execution of a program P is a triplet of algorithms SNARK := (Gen, Prove, Verify) such that: Gen(λ, P) → (pk, vk): For input security parameters λ and a description of a program P, Gen(λ, P) outputs a pair of proof and verification keys. Prove(pk, x, w) → π: For an input proof key, a public input x, and a private input w, Prove(pk, x, w) outputs a proof π. Verify(vk, x, π) → b∈{0,1}: For an input verification key, a public input x, and a proof π, Verify(vk, x, π) either accepts or rejects the proof.

[0093] Completeness, (knowledge) soundness, and zero-knowledge. A SNARK is complete if a verifier always accepts a proof π produced by a prover, SNARK.prove, for any input pair (x, w) of public / private input that a program P accepts. A SNARK is sound if, for all public inputs x for which no private input w is accepted by P, a verifier rejects with extremely high probability any proof π about x. Furthermore, a proof is said to be knowledge-sound if it is possible to efficiently compute (extract) a proof from a valid proof π and the randomness (up to some negligible error - knowledge error) used by a (possibly dishonest) prover to generate π. A proof π is zero-knowledge if it reveals no information about w.

[0094] Succinctness. A proof is "short." This means that the proof is logarithmic in the size of the private input w. More specifically, the proof has size poly(λ)polylog(|w|), where λ is a security parameter. If, in addition to a short proof, the verifier's running time is "fast," then the system has succinct verification (also called perfectly succinct). That is, the proof is logarithmic in both the size of the public input x and the size of the private input w. Thus, a system is perfectly succinct if its running time takes poly(λ)polylog(|x| + |w|) steps.

[0095] 5.2 Proven Data Proven Data (PCD) schemes provide a means to prove the integrity or correctness of dynamic computations distributed among mutually distrusting nodes. PCD schemes differ from multi-party computation protocols in two main respects: the number of nodes is not fixed, and privacy of the computation is not an issue. The latter point allows PCD to be more lightweight (no node communication overhead).

[0096] 5.2.1 Multi-predicate transcripts A transcript T of a dynamic computation is modeled as a directed acyclic graph G = (V, E) originating from some source node and terminating in an output (sink) node. Edges (u, v) ∈ E are attached to data. Each node v ∈ V is attached to incoming data.

[0097]

number

[0098] , outgoing data z out , and (possibly) local data z loc The computation at node v must conform to some predicate Π, i.e.,

[0099]

number

[0100] is.

[0101] Definition. A computation transcript is a tuple T := (G, TYPE, LOC, PAYLOAD): G = (V, E) is a directed acyclic graph TYPE:

[0102]

number

[0103] is the node label (the compliance predicate to which the node adheres). LOC: V → {0,1}* is another node labeling (local data) PAYLOAD: E→{0,1}* is an edge label (data flowing into and out of a node).

[0104] Messages and Outputs. For an edge (u, v)∈E, the message z attached to that edge (u, v) has two parts: its type z.type := (TYPE(u)), which is the type of the parent node, and its payload z.payload := PAYLOAD((u, v)), which is the actual data. The output of the transcript out(T) is the set of messages attached to edge (v, w), where w is the output (sink) node.

[0105] Compliance of transcripts and outputs. A vector of compliance predicates is

[0106]

number

[0107] A transcript T is a transcript if and only if:

[0108]

number

[0109] is. i. Let s∈V. We have TYPE(s) = 0 if and only if s is a source node. ii. For every non-source node v∈V, let i := TYPE(v),

[0110]

number

[0111] Let be the incoming message to v,

[0112]

number

[0113] is the message going out,

[0114]

number

[0115] Let be the local data. Then,

[0116]

number

[0117] (Thus, a node must conform to the predicate given by its type).

[0118] A message z is a set of messages z∈out(T) such that z∈out(T).

[0119]

number

[0120] If transcript T is present,

[0121]

number

[0122] is.

[0123] Figure 3 is a schematic diagram of a computational transcript of a function f(x, y) := (2(x + y), 3(x + y)) with bounded noise. The computational transcript includes two source nodes 302, two output nodes 306, and an intermediate node 304. All non-source nodes 304, 306 enforce different compliance predicates on their inputs and outputs. The "+" node (intermediate node 304) is allowed to introduce the bounded noise summand ||e||2 < B as local data for its computation.

[0124] 5.2.2 Pre-treated PCD Syntax. The preprocessing PCD method is a triplet of algorithms.

[0125]

number

[0126] and the generator

[0127]

number

[0128] is a compliance predicate

[0129]

number

[0130] as input and generates a proof / verification key pair (pk pcd , vk pcd ) for each non-source node.

[0131]

number

[0132] is the incoming data z in , and proofs establishing compliance of their parent nodes (if the parent nodes are non-source nodes).

[0133]

number

[0134] , local data z loc , and outgoing data z out Take as input and prove

[0135]

number

[0136] Generate a verifier.

[0137]

number

[0138] takes the outgoing data and a proof as input and either accepts or rejects it. Generally, PCDs are built from succinct zero-knowledge proof systems (SNARKs) that can be recursed. In Section 8.1, existing schemes that are suitable for recursion are provided and compared.

[0139] Security (knowledge integrity). Data leaving

[0140]

number

[0141] Proof of

[0142]

number

[0143] If the set of nodes accepts it, the output (sink) node will

[0144]

number

[0145] There is a computational transcript T with (and such that)

[0146]

number

[0147] ) and all nodes (back to the source node)

[0148]

number

[0149] It is guaranteed that the incoming / local / outgoing data is

[0150]

number

[0151] The set of verifies compliance of the entire computational transcript.

[0152] 6. Scalable SNARKs for Hash-Based Statements 6.1 Knowledge of Arbitrarily Large SHA2 Preimages SNARKs are defined for the following NP relations:

[0153]

number

[0154] Therefore, given a public digest H and length

[0155]

number

[0156] against

[0157]

number

[0158] The knowledge of the preimage M (private input) of is proved. This relation is given by the digest size d, the block size m, and the maximum message length

[0159]

number

[0160] , and the initialization vector IV that is implicitly used when evaluating the SHA2 function.

[0161] 6.1.1 Computational Transcript The SHA2 evaluation can be seen as a transcript of the dynamic computation. The i-th node has the current iteration counter i - 1 and the current state H (i-1) takes as input, updates i, H, also called the next iteration counter and the next state (i) The next state is the i-th message block M (i) The first node receives the initialization vector as input, and the last node receives the message length

[0162]

number

[0163] Using the last block M (N) Padded to H (N) Output.

[0164] FIG. 4 shows a schematic of a SHA2 transcript 400 having a source node 302, an init node 402, intermediate nodes 304, and a digest (output) node 306.

[0165] The message M is M := (M (1) || … || M (N) ) A series of message blocks M (i)and, if necessary, padding blocks M' (N) but, M' (N) := pad(M (N) ) is defined by

[0166] Digest H is H = SHAd(M) It is defined as follows:

[0167] A message M is sometimes referred to herein as a preimage, and a message block M (i) is sometimes called a preimage block.

[0168] 6.1.2 Node Compliance The transcript 400 includes a series of nodes: a source node 302 (type 0), an init node 402 (type 1), an intermediate state node 304 (type 2), and a digest node 306 (type 3). The transcript 400 provides a method

[0169] For each non-source type node 402, 304, 306, a compression function criterion is enforced to verify that the predefined compression function has been correctly calculated. Each of these nodes 402, 304, 306 has a current state H (i-1) as input and apply the compression function to the next state H (i) Nodes 402, 304, and 306 also take the current iteration counter i-1 as input and increment the current iteration counter i-1 to calculate the next iteration counter i.

[0170] Each of these nodes 402, 304, 306 also performs a compression function evaluation check to check that the compression function has been evaluated correctly. (i) is used for this check. Nodes 402, 304, 306 generate proofs that demonstrate the correct evaluation of the compression functions at nodes 402, 304, 306.

[0171] In this way, each node 402, 304, 306 performs one iteration of the compression function. This allows proofs to be generated iteratively, reducing the computational requirements of the prover, thus increasing the efficiency of the process, and allowing proofs of arbitrarily large messages to be generated. The output of the final node 306 is the digest H, and a preimage proof π that, in addition to correct execution by the final node 306, proves that all previous nodes 402, 304 have correctly executed the compression function, and therefore proves knowledge of the message M. preim is.

[0172] In addition to checking the compression function, the first (init) node 402 and the final (digest) node 306 perform additional checks.

[0173] The first node 402 performs an initialization check to check that the received initialization vector IV received as part of its input is correct. The received initialization vector may be referred to as the current state of the first node 402, i.e., H (0) = IV. The received initialization vector IV is compared with a predefined initialization vector, and if found to be equal, the received initialization vector is determined to be correct. The predefined initialization vector may be hard-coded in the first node 302. The first node 302 may determine that the current iteration counter received at the first node 302 has a first iteration count value, i.e., i in = 0. In some embodiments, the first iteration count value may be 1.

[0174] The last node 306 performs a padding check: if the preimage fits into N m-bit blocks, the last node 306

[0175]

number

[0176] Match the last block M (N) - so the padding length k + 1 is

[0177]

number

[0178] where m is the block length and N - 1 is the input iteration counter of the final node 306, where b is either 0 or 1. If b = 1, then no extra blocks are used when padding, i.e., the message M is of maximum bit length

[0179]

number

[0180] bit length equal to

[0181]

number

[0182] If the above equation is satisfied, the padding condition may be said to be satisfied.

[0183] To perform the padding check, the final node 306:

[0184]

number

[0185] , b, and / or k as inputs, and the received values ​​are expressed as

[0186]

number

[0187] You can check that the following is satisfied.

[0188] If the required padding does not fit into the final message block, an extra padding block is required. This is because the message length

[0189]

number

[0190] is the message length

[0191]

number

[0192] This is the case if the message length is a multiple of , or if the message length padding bits do not fit into the last message block.

[0193] If extra padding blocks are needed, the final node 306 also receives padding blocks, also called padding pre-image portions. The padding blocks have a length such that when concatenated with the message, the total length is equal to the maximum bit length. The final node 306 runs the compression function again, this time taking as input the state and iteration counter already calculated by the final node 306. The compression function check uses the padding blocks to check that the compression function evaluated correctly. The proof generated by the final node 306 establishes that both instances of the compression function evaluate correctly.

[0194] Otherwise, if no extra padding blocks are needed, the final node 306 outputs the state and proof generated for the last message block of the message, i.e., the final node 306 does not need to run the compression function a second time.

[0195] The final node 306 is the last l max Check that the bits are the binary representation of l. The definition of M depends on whether padding has been added or not, as follows: if no final block has been added, the slice of bits to be checked is

[0196]

number

[0197] while when the final block is added, the bit checked is

[0198]

number

[0199] It's somewhere inside.

[0200] That is, while the correct value of k must be provided as an input to the final node 306, the value of M' may be set to any value if no padding is added, since in the absence of padding, M' is not used for padding enforcement or the second compression function evaluation.

[0201] Note that SHA2 always adds some extra bits (called padding) to the end of the message. The difference is on which blocks the padding check is performed.

[0202]

number

[0203] If is the last block containing bits of the message, then (i) the padding is in the block

[0204]

number

[0205] Either (i) the padding is completely within the

[0206]

number

[0207] In case (ii), padding is performed within M'.

[0208] More generally, the final node 306 receives the final message block and the message length and generates the correct padding for the message based on the message length—Φ pad Step 2 of the method, which may involve generating an extra padding block containing padding information, is then performed by the final node 306, which applies the compression function to the final message block and, if there is an extra padding block, also applies the compression function to the padding block. The final node 306 generates a proof verifying the correctness of the padding and the application of the compression function. The proof is based on the received extra input bits b, which indicate whether an extra block containing purely padding information has been generated and passed through the compression function.

[0209] An intermediate state node 304 can only receive input from another intermediate state node 304 or a first node 402. A digest node 306 can receive input from all types of nodes 302, 304, 402. These input relationships for a SHA2 node are shown in Figure 5.

[0210] The predicate captures these enforcements.

[0211]

number

[0212] The internal gadget Φ is defined as IV , Φ eval , Φ pad is explained below.

[0213] init node 402 (type 1) compliance. Pi init (z in , z loc , z out ): 1. z in .payload as counter and state

[0214]

number

[0215] Parse as 2.z loc The message block

[0216]

number

[0217] Parse as 3.z out .payload as counter and state

[0218]

number

[0219] Parse as 4.z in Check that .type = 0. 5.

[0220]

number

[0221] / / See Figure 4. 6.

[0222]

number

[0223] Check that it is accepted. 7. If all three checks are acceptable, output "accept". Otherwise, output "reject".

[0224] Compliance of intermediate state node 304 (type 2). Pi update (z in , z loc , z out ): 1. z in .payload as counter and state

[0225]

number

[0226] Parse as 2.z loc The message block

[0227]

number

[0228] Parse as 3.z out .payload as counter and state

[0229]

number

[0230] Parse as 4.z inCheck that .type∈{1,2}. 5.

[0231]

number

[0232] Check that it is accepted. 6. If the two checks are acceptable, output "accept". Otherwise, output "reject".

[0233] Digest Node 306 (Type 3) compliance. Pi digest (z in , z loc , z out ): 1. z in .payload as counter and state

[0234]

number

[0235] Analyze as follows. 2.z loc The message block, the extra padded block (if any), the extra hash state (used only if there are extra padded blocks), the counter, the padding length, and a bit indicating whether extra blocks were added.

[0236]

number

[0237] Analyze as follows. 3.z out .payload to the last state

[0238]

number

[0239] and message length

[0240]

number

[0241] Analyze as follows. 4.z in Check that .type∈{0,1,2}. 5. z in If .type = 0,

[0242]

number

[0243] / / See Figure 4. 6. If b = 1, then

[0244]

number

[0245] Check that it is accepted. 7. Otherwise (b = 0, so an extra block is added), check: a.

[0246]

number

[0247] To be accepted by b.

[0248]

number

[0249] To be accepted by 8.

[0250]

number

[0251] Check that it is accepted. If all checks are accepted, output "accept", otherwise output "reject".

[0252] The table below shows:

[0253]

number

[0254] This shows the gadget used internally by the RFC 2 ...

[0255]

number

[0256] , and the initialization vector IV is hard-coded in the description.

[0257] [Table 2]

[0258] 6.1.3 SNARK

[0259]

number

[0260] is the message

[0261]

number

[0262] The proof system for proving knowledge of a SHA2 preimage is a triple SNARK algorithm defined below. preim := (Gen preim , Prove preim , Verify preim )

[0263] Gen preim (λ, CF SHA2 )→(pk, vk). Gen preim is a description of the SHA2 compression function CF with security parameter λ. SHA2 and as input, (CF SHA2 ) proof key pk and (CF SHA2 The output is a verification key vk (including a concise summary of

[0264] Prove preim (pk, (H, M))→π SHA2 Prove preim is the proof key pk and the pair (H, M)∈R SHA2 Take as input and provide a concise proof π SHA2 Steps: 1.

[0265]

number

[0266] Message M is divided into N blocks M (i) Divide k + 1 into M (N) The padding length shall be 2. H (0) := Set IV 3. Pi (0) Set := ⊥ / / empty proof 4. For i = 1 to N: a.H (i) := CF m,d (H (i-1) , M(i) ) / / H (N) Assume = H. b. Configure input, local, and output data: i.z in .payload := (i - 1, H (i-1) ) and set ii. If i < N, then z loc := M (i) and z out .payload = (i, H (i) ) / / Type 1 or Type 2 node (non-digest) iii. Otherwise, if i = N, then z loc := (M (i) , M', H, i, , k, b) and

[0267]

number

[0268] and set c. Set the node type: i. If i = 1 and N≧2, then z in .type = 0 and z out Set .type = 1 / / Init node ii. If i = 2 & N≧3, then z in .type = 1 and z out Set .type = 2 / / First intermediate state node iii. If N > i > 2 and N≧3, then z in .type = 2 and z out Set .type = 2 / / Remaining intermediate state nodes iv. If i = N & N≧3, then z in .type = 2 and z out Set .type = 3 / / Digest node (with input from intermediate state node) v. If i = 2 & N = 2, then z in .type = 1 and z out Set .type = 3 / / Digest node (with input from source node) vi. If i = 1 & N = 1, then z in .type = 0 and z out Set .type = 3 / / Digest node (with input from source node) vii. pk to pk SHA2PCD and interpreted as follows:

[0269]

number

[0270] Calculate 5. Pi SHA2 := π (N) Output

[0271] It is more efficient for the prover to keep the data corresponding to the current iteration in memory and delete the data for older iterations. In this way, the output proof π SHA2 is calculated incrementally.

[0272] Verify preim (H, π SHA2 , vk)→{"accept", "reject"}. Verify preim is the verification key vk, the digest H, and the proof π SHA2 It takes as input H and either accepts the proof or rejects it. Acceptance signals that H was correctly computed using SHA2 from the preimage M (which is not available to the verifier). Steps: 1. vk to vk SHA2PCD Parse as 2.z out .type := 2 (digest node) and z out Set .payload := H 3.

[0273]

number

[0274] If it accepts, it outputs "accept". If not, it outputs "reject".

[0275] FIG. 6 shows an example of how a prover 602 can prove knowledge of a preimage M without revealing the preimage to a verifier 604 .

[0276] In step 1, the verifier 604 preim to generate the proof key pk and the verification key vk based on the compression function. The compression function used is known to both the prover 602 and the verifier 604. The verifier 604 provides or otherwise makes available the proof key pk to the prover 602 in step 2.

[0277] In step 3, the prover 602 obtains a set of preimage blocks M (i) The prover 602 may generate padding blocks as needed in this step.

[0278] In step 4, the prover 602 iterates through the compression function and, for each iteration, generates a corresponding proof that the compression function was executed correctly. Each iteration is executed as described above for nodes 402, 304, and 306 of the transcript 400. The output proof of the final node 306 is set as the preimage proof in step 5.

[0279] In step 6, the prover 602 provides the verifier with the preimage proof and the next state generated by the final node 306, which is the message digest H. The verifier 604 then executes the Verify() method using the received preimage proof and digest and the verification key. preim to verify that the proof is valid for the digest, and therefore verify that the prover 602 has knowledge of the message M.

[0280] Although shown as a single entity, it will be understood that the prover 602 may include multiple computing devices, each including a processor. Each of the computing devices of the prover 602 may be configured to execute one or more nodes of the transcript 400. The output of each node may be sent to the processor of the prover 602 for input to the next node.

[0281] 6.2 Patterns in SHA2 preimages The above method can be modified to prove the existence of a pattern in the preimage of a given digest d. As an example, it may be possible to prove the statement "The first and last bits of the preimage of d are equal to 1." In general, the method below provides a way to prove any bit pattern in the preimage M of a digest d and to verify the enforcement, knowing only d and without knowing M.

[0282] 6.2.1 Patterns We start by defining how we see patterns and how we compute short descriptions (summaries) of patterns.

[0283] Pattern P consists of two

[0284]

number

[0285] Vector of

[0286]

number

[0287] where the first vector P is the pattern and the second vector C is the check bits.

[0288]

number

[0289] The string M is a bit C i = 1, M i = P i The pattern matches if we get . The vector P can take any value for the unchecked bits, for example we can set all the unchecked bits of P to 0. That is, the check bit vector C defines which bits of the message are checked, i.e., compared to the pattern vector P.

[0290] Definition 2 (Pattern and Summary). Let k be a security parameter, and

[0291]

number

[0292] , N, m

[0293]

number

[0294] Hash: {0,1} 2m+k →{0,1} k Let be a collision resistant hash function.

[0295]

number

[0296] P is

[0297]

number

[0298] Vector Pair

[0299]

number

[0300] is.

[0301]

number

[0302] But C j = 1, then the i j Bit p j Let P be an Nm-bit array divided into m-bit blocks obtained from P by setting all bits in P to 0 and all other bits to 0. Similarly

[0303]

number

[0304] Let S be the result of dividing C into m-bit blocks and padding the last block with zeros if necessary. (0) Let P be any k-bit string. A summary of P is a k-bit string S∈{0,1} such that Summary(P) := k is.

[0305]

number

[0306]

number

[0307] is a series of bit pattern array blocks.

[0308]

number

[0309] It is sometimes called a bit pattern array containing

[0310]

number

[0311] is a series of check bit arrangement blocks.

[0312]

number

[0313] It is sometimes called a check bit array containing

[0314] Note: As with SHA2, the construction of a digest S follows the Merkle-Damgard construction. Therefore, the i-th intermediate state S of a digest (i) is the i-th block P (i) , C (i) , and the (i - 1)th intermediate state S (i-1) That is, S (i) := Hash(P (i) , C (i) , S (i-1) )

[0315] 6.2.3 Statements The methods provided herein demonstrate the following statements: "Let (H, P), then H is the digest of message M that matches pattern P."

[0316] More formally, a proof system is provided herein for proving an instance of the following relation (H, P): R SHA2pattern := {((H, P := (P, C); M) | H = SHA2 d,m,IV (M) ∧ M i = P i if C i = 1} Length of the preimage M

[0317]

number

[0318] is given by the length of the pattern vector P.

[0319] 6.2.4 Calculation Transcripts and Compliance To prove variable-length statements, we replace patterns with summaries. The underlying PCD scheme defined herein is suitable for use with pattern summaries instead of working with the full description P. To enforce a pattern P on the i-th message block of a SHA2 vector, P (i) , C (i) Note that only P needs to be known. (i) , C (i) To ensure that is part of the original public pattern P, the previous message block must have been enforced against the previous vector of P (and not against some other pattern).

[0320] To do so, all i - 1 prior vectors of P could be passed as input to the compliance predicate and as output for the next iteration. However, this method requires as many compliance predicates as N (each of which takes inputs of different lengths), and preimages of different lengths require different numbers of compliance predicates. The latter means that to prove patterns for any two preimages, it is necessary to use the same SNARK.pattern This means that the method cannot be used.

[0321] To overcome this problem, the i - 1 intermediate states of the summary are passed and the correct generation of the next summary state is enforced to check for a match with the preceding pattern block. (i) Note that,has a fixed length,k,, and therefore a single compliance predicate is,sufficient.

[0322] Actual construction. The transcript for checking patterns is defined very similarly to the transcript for SHA2 preimages (see Section 6.1.2). The difference is the constraint predicate

[0323]

number

[0324] The contents of the data as well as the edge and node data are The i-th node (iteration) stores the local data

[0325]

number

[0326] and

[0327]

number

[0328] This is in addition to receiving the ith message block.

[0329]

number

[0330] Furthermore, the edge message (outgoing data) now contains the i-th intermediate state of the summary, in addition to the i-th intermediate state of the SHA2 digest and the iteration counter. Thus, z in := (i in , H in , S in ) and z out := (i out , H out , S out ) Predicates in Section 6.1.2

[0331]

number

[0332] Internal subroutine Φ eval The call to pattern is replaced by a call to the subroutine Φ eval is the subroutine Φ pattern It is noted that this is performed as one of the steps.

[0333] The table below shows:

[0334]

number

[0335] Provides a predicate used internally as a subroutine to ensure a pattern matches.

[0336]

number

[0337] ,

[0338]

number

[0339] is calculated as per Definition 1.

[0340] [Table 3]

[0341] That is, each node 304, 306, 402 is configured to perform not only the compression function checks described above, but also pattern checks.

[0342] Each node receives a bit pattern array block and a check bit array block corresponding to the block as additional input. Each node calculates the next summary value S out Generate the current summary value S in , and check that the next summary value evaluates correctly by generating a hash based on the bit pattern array and the check bit array.

[0343] The nodes 304, 306, 402 also check the pattern of the message block they are processing using their respective check bit array blocks and bit pattern array blocks. (i) is the ith check bit array block C (i) Based on the i-th bit pattern array block P (i) It is compared to.

[0344] Φ pattern A zero-knowledge-friendly hash function, Hash, can be used to compute a summary of the pattern. This is done by using the compliance predicate

[0345]

number

[0346] The size of

[0347]

number

[0348] The size of the hash remains closely related to the size of the SHA2 compression algorithm. For example, the Pedersen hash has an R1CS of 2753 constraints. Poseidon has 316 constraints. On the downside, the cryptanalysis of these newer constructions has not been as well studied as the compression capabilities of SHA2.

[0349] 6.2.5 SNARKs

[0350]

number

[0351] is the message

[0352]

number

[0353] The SNARK Proof System is a PCD method for proving the following: pattern := (Gen pattern , Prove pattern , Verify pattern ) is defined in the same way as in the preimage proof system described above.

[0354] The verifier 604 generates a proof key and a verification key as described above, and the proof key is provided to the prover 602 for use in proving knowledge of the preimage M. At each compression function iteration, the prover 602 also computes the corresponding state of the pattern summary S.

[0355] The output provided by the final node 306 of the transcript is the final state H (N) (Digest H), Final Summary S (N) (Summary(P) of a pattern), and pattern proof π patternThis is provided to the verifier 604, which verifies the pattern proof. out .payload = (H, Summary(P)), and the verifier 604 out A given proof of π out To approve

[0356]

number

[0357] Execute.

[0358] 6.3. Merkle Tree Statements Let L be an NP language. The following method provides a way to prove the following statement: "Let H be bytes and e be a non-zero positive integer. Then H is the root of a Merkle tree of depth e whose leaves are in L." Therefore, the statement about all leaves can be proven.

[0359] Proving a Merkle tree statement by sending leaves is inefficient: first, a tree needs to be constructed to match a given root; second, the base relation R b Regarding -- one for each leaf -- 2 e proofs need to be verified. For example, for a tree that stores 1 million leaves, each 1MB, at least 1TB (not considering proofs, only leaf data) would need to be transmitted, which is inefficient and may be impossible. The situation is similar for smaller trees that store larger datasets.

[0360] More formally, the leaf-related relation R b Given, we provide a concise proof system for the following relation:

[0361]

number

[0362] Variable-length statements. The depth e of the tree is not determined by the relations, but is instead part of the instances. Thus,

[0363]

number

[0364] contains Merkle trees of arbitrary depth, which in turn supports the SNARK proof system described below. merkle is the basic relation R b This means that we can prove arbitrarily many instances of

[0365] 6.3.1 Bootstrapping from leaf relationships to a Merkle tree Everything is a basic relationship R b Leaf that is an instance of

[0366]

number

[0367] Start with and enter

[0368]

number

[0369] Consider the transcript resulting from computing the circuit GetRoot for R. The source (leaf) node takes the leaf as input and hashes the leaf. Other (non-leaf) nodes take the two digests (from their two child nodes) as input and hash those digests. R b Since is in NP, it allows SNARKs, and so the circuit can be modified as follows: The source node receives data L and the statement "

[0370]

number

[0371] A valid proof that proves the veracity of b It takes as input

[0372]

number

[0373] This means that the complexity of a SNARK prover depends only on the complexity of the underlying SNARK verifier and hash.

[0374] Remark 1. The approach provided here is to b Another possibility is that the base relation is calculated as the predicate vector

[0375]

number

[0376] and arguments

[0377]

number

[0378] However, the resulting prover may be more complex.

[0379] Remark 2. Proof π b The basic relation R takes as input a verification key vk for verifying b A preprocessing (simple) verifier is used. Thus, a SNARK with the following relationship is provided:

[0380]

number

[0381] R b Verification key

[0382]

number

[0383] teeth,

[0384]

number

[0385] Hard-coded in the description of R b The knowledge soundness of the SNARK verifier is

[0386]

number

[0387] If

[0388]

number

[0389] This simply means that with high probability, evidence from a valid proof can be extracted.

[0390] 6.3.2 Merkle Tree Computation Transcript Hash: {0,1} 2k →{0,1} k Let be a cryptographic hash function. The compliance predicate vector is

[0391]

number

[0392] It is defined as follows.

[0393] 7 provides an example Merkle tree 700 as described herein. Merkle tree 700 is a tree of data blocks L i The leaf data, also called the proof, and the corresponding data block, π i The Merkle tree 700 includes four leaves 702, each defining a block of data and a data block proof. The Merkle tree 700 includes four leaf hash values ​​to which each of the four leaf nodes 704 is mapped, and each leaf node 704 has an associated leaf 702 and is configured to receive block data and data block proofs from the associated leaf 702. The Merkle tree 700 further includes internal hashes to which internal nodes 706 are mapped. The nodes 704, 706 mapped in the Merkle tree 700 are arranged in layers, and the nodes in each layer receive as input the output generated by the node 702, 704 pair in the previous layer.

[0394] Data Block Proof π i is the data block L i satisfies a predefined criterion. For example, the criterion may be that a data block matches a predefined pattern, as in Section 6.2, and the data proof proves that the data block matches the pattern.

[0395] Each leaf node 704 has a corresponding data block L i and its associated data proofs π i Each leaf node 704 receives the received proof π i is valid and hashes the received data block to obtain the data block hash H i := Hash(L i )

[0396] The internal nodes 706 in the first layer of internal nodes 706 each receive the data block hashes generated by two of the leaf nodes 704. These internal nodes 706 generate hashes of the data block hashes, referred to herein as output hashes, and these hashes are provided to the internal nodes 706 in the next layer of internal nodes 706.

[0397] This process is repeated with each internal node 706 receiving the two hash values ​​generated by the internal node 706 in the previous layer until the final internal node 706a, located in the final layer of nodes 704, 706 mapped into the Merkle tree 700, generates its hash value, which is the Merkle root of the Merkle tree 700.

[0398] Each of the nodes 704, 706 may also compute a proof.

[0399] Each leaf node 704 receives a data block L i Related data proof π i , and generates leaf node proofs that prove that the node outputs the hash of the input data and that the node successfully verified the input data proof. That is, each leaf node proof proves that (1) the input leaf proof is valid (the verification algorithm outputs 1 for this proof) and (2) the output block hash is the hash of the input data. Thus, a leaf node proof proves that the input data block L i is a leaf of the Merkle tree 700 and that the data block itself meets the predefined criteria.

[0400] Each internal node 706 in the first layer receives a corresponding leaf node proof along with the leaf hash. These internal nodes 706 generate proofs, referred to herein as output proofs, based on the two received leaf node proofs. Each output proof establishes (1) that the input proof is valid and (2) that the output hash is a hash of the two input hashes.

[0401] In a similar manner to generating the output hash, each internal node 706 in each subsequent layer receives as input the two output proofs generated by the internal node 706 in the previous layer that correspond to the received hash. Each internal node 706 generates an output proof based on the two received proofs. In this way, each output proof proves that the block data value and the previous hash exist and that the leaf data block satisfies the criteria.

[0402] The output proof produced by final node 706a establishes that the output hash is the root of a Merkle tree whose leaves satisfy the criteria. This output proof is sometimes referred to herein as a Merkle tree proof of Merkle tree 700.

[0403] The nodes 704, 706 may be executed by the same computing device. Alternatively, one or more of the nodes may be executed by different computing devices. In this embodiment, the output hash and output proof are sent between the computing devices to generate the Merkle tree proof and the Merkle root. The code defining the Merkle tree may be divided into portions, each portion defining one of the nodes 704, 706 of the Merkle tree 700, and each computing device stores and executes one or more portions of the code corresponding to the node 704, 706 being executed by the computing device.

[0404] Leaf node 704 (type 1). Leaf node 704 contains the statement

[0405]

number

[0406] Data L∈{0,1} 2k and data proof π b Enter z in Take the leaf hash H := Hash(L) and output zout := (H, 0). If L has m < 2k bits, right-pad it with 2k - m zeros before hashing. All these checks are performed using the predicate Π leaf Specifically, π b The validity of is enforced in the SNARK verifier's circuit of the basic relationship (the verification key is hard-coded in the circuit), and the correctness of H is enforced in the Hash circuit.

[0407] Internal node 706 (type 2). Internal node 706 has two inputs

[0408]

number

[0409] and

[0410]

number

[0411] where e≧1 represents the depth of the internal node 706 in the Merkle tree 700, and H (l) , H (r) ∈{0,1} k H := Hash(H (l) || H (r) ) and calculate z out := (H, e). If e = 1, the input comes from two leaf nodes 702. Otherwise, the input comes from an internal node 704 of the previous layer. All these checks are performed by the predicate Π inner is encoded as

[0412] Hash leaf data of size > 2k. The domain of hash is fixed at 2k. Leaf L i can be double hashed for large sizes > k.

[0413]

number

[0414] Hash var is set to a cryptographic hash for which knowledge of the preimage can be progressively proven (e.g., SHA2 with SNARKs in Section 6.1.3). i The statement "Public

[0415]

number

[0416] When given,

[0417]

number

[0418] and (L i , w i )∈R b L as in i , w i The leaf data are not necessarily of the same size. i | ≠ |L j |Please pay attention to this.

[0419] Selection of Hash Function. As with verifying patterns in SHA2 preimages, a hash function suitable for zk, such as Pedersen hash or Poseidon, may be used to construct the Merkle tree. It will be appreciated that any hash function may be used.

[0420] 6.3.3 SNARKs Proof System

[0421]

number

[0422] But the output (H, e) is

[0423]

number

[0424] It is a PCD method that proves that b , P b , V b ) is the base SNARK verifier.

[0425]

number

[0426] The SNARK proof system is a triplet SNARK merkle := (Gen merkle , Prove merkle , Verify merkle )

[0427]

number

[0428] : 1. Base SNARK key := Gb(λ, R b ) 2. Keys to Merkle Tree PCD

[0429]

number

[0430] / / Generate a predicate

[0431]

number

[0432] has the base verification key hardcoded in it. 3. Pk := (pkpcd , pk b ), vk := vk pcd Output

[0433]

number

[0434] : 1. pk:= (pk PCD , pk b ) 2. i = 1 to 2 e Up to π b,i := P b (pk b , L i , w i ) / / Offline prover 3. Compute the output proof of the leaf node, i = 1 to 2 e Do this up to: / / 2 in total e leaf nodes. a.L i , π b,i is the i-th leaf data and the leaf relation R b Let the input of the leaf node be z in,i .payload := (L i , π b,i ) and z in,i Set .type = 0 (source node). b.

[0435]

number

[0436] Assuming that the output node z out,i .

[0437]

number

[0438] and zout,i Set .type = 0 (leaf node). c. Output Proof

[0439]

number

[0440] Calculate 4. Compute output proofs for interior nodes. Iterate for d = 1, ..., e / / from layer d - 1 to layer d. a. Input / Proof 2 e-(d-1) Pairs of pieces

[0441]

number

[0442] Takes as input b.2 e-d Node output payload

[0443]

number

[0444] / / Get

[0445]

number

[0446] Note that c. k = 1 to 2 e-d Do this until: i. Input data

[0447]

number

[0448] If d = 1, the input node is of type 1 (leaf node), otherwise it is of type 2 (internal node). ii. Input proof

[0449]

number

[0450] Set to iii.

[0451]

number

[0452] and set iv. Proof of Output

[0453]

number

[0454] Calculate d.

[0455]

number

[0456] Output

[0457] Verify merkle (vk, (H, e), π merkle )→{"accept", "reject"}. Verify merkle is the verification key vk, the digest and tree depth (H, e), and the proof π merkle As input, H is accepted and the leaf is R. b means that it is the root of a Merkle tree of depth e that is an instance of Steps: 1. vk to vk pcd interpreted as 2.z out .type := 2 (internal node) and z out Set .payload := (H, e) 3.

[0458]

number

[0459] If it accepts, it outputs "accept". If not, it outputs "reject".

[0460] Figure 8 shows the data blocks L i 8 shows an exemplary method for proving that satisfies a criterion. In the example of FIG. 8, the criterion is a predefined pattern.

[0461] In step 1, the verifier 604 obtains a proof key pk b and the verification key vk b The verifier generates a proof key pk pcd and the verification key vk pcd Also generate two proof keys pk b , pk pcd is sent or otherwise made available to the prover 602 in step 2.

[0462] The prover 602 generates a data proof for each of the data blocks in step 3. To generate the proof, the prover 602 checks the respective check bit array block C i Each data block L defined by i The bits of each pattern bit array block P i If the bits match, the data block meets the criteria of the pattern and therefore a proof can be generated.

[0463] In step 4, the prover 602 iterates through the Merkle tree 700. That is, the prover 602 runs through the leaf nodes 704 and interior nodes 706 in step 5 to generate a Merkle root and a Merkle tree proof, as generated by the final node 706a.

[0464] In step 6, the prover 602 generates a Merkle tree proof π merkle and the Merkle root H to the verifier 604. The verifier 604, in step 7, uses the Merkle root and the Merkle root verification key (generated in step 1) to verify the received Merkle tree proof. In this way, the verifier 604 is confident that the data blocks used by the prover 602 to generate the Merkle root and Merkle tree proof meet the pattern criteria.

[0465] Data Block L i It will be appreciated that the criteria that must be met may be any criteria for which a zero-knowledge proof can be generated.

[0466] 6.3.4 Proof Aggregation and Universal Trees The above design has two important properties.

[0467] Summarizing the proof, we have two proofs π for (H, e) and (H', e') when e = e', i.e., when the Merkle trees have the same depth. merkle ,

[0468]

number

[0469] can be merged, and (H'' := Hash(H, H'), e + 1) is the PCD prover.

[0470]

number

[0471] H'' can be generated with a single call to e+1 The leaves are in the basic relationship R b Note that if the trees have different depths, e < e', then the smaller tree is the root H replicated To generate an augmented tree of depth e' with e'-e The proof can be replicated with one dummy leaf and then both proofs can be merged. The correct expansion of the smaller tree can also be proved incrementally.

[0472] Prove any fundamental relation.

[0473]

number

[0474] as part of its description, a particular relation R b Verification key

[0475]

number

[0476] is hard-coded.

[0477]

number

[0478] The description of the basic relation R b Using Universal SNARKs in R b A universal SNARK requires a circuit-independent (universal) verification key vk and a circuit-specific verification key vk.

[0479]

number

[0480] There is a public procedure,specialize,that generates,v,. Thus, a universal,v,k,can be hard-coded into the circuit,

[0481]

number

[0482] The correct specialization to , can be proved as a circuit gadget. This is done by using a circuit-specific verification key

[0483]

number

[0484] can be considered part of the instance. In other words, a single SNARK proof system can prove that the leaves of a Merkle tree are over any NP language. The universal tree relation is:

[0485]

number

[0486] This therefore eliminates the need for the verification key to be changed if the circuit is changed.

[0487] 6.4 Possible modifications Patterns in intermediate hash states. The idea in Section 6.2 is that intermediate state H (i) can be used to prove a pattern in the i-th node (internal) compliance predicate Φ midstatePattern But there is a pattern P and an outgoing intermediate state H (i) In particular, given a d-bit string H mid It can be proven that i is the i-th intermediate state of a given digest H.

[0488] Keyword search, or proving that a string does not appear in the preimage. It is possible to show that a given short string S of at most m bits appears (or does not appear) in some SHA2 message blocks. The idea of ​​a compliance predicate is to loop m - p times shifting the string S to the right by 1 and check whether it matches the corresponding p-bit slice of the message block. For example, this can be used to prove that a transaction with an identifier TxID of unknown size is a P2PKH transaction that matches the pattern (4 bytes) of a P2PKH script, or to prove that the transaction does not contain embedded data indicating the 2-byte string "OP_FALSE OP_RETURN" in the transaction serialization.

[0489] Variable-size Merkle tree proofs. "Given a public (H, e, L, i), I know a certification path ap that proves that L is the i-th leaf of a Merkle tree with root H and depth e. Furthermore, I know that L is a proof that R b Statements of the form "I know a proof w such that w is an instance of ∑ ∑ ∑ w ...

[0490] The leaf relationships depend on their positions on the tree. Thus, the i-th leaf and the j-th leaf are in R b,i , R b,j (not necessarily the same relationship).

[0491] 7. Applications Some exemplary applications of the above-described zero-knowledge proof system are given. It will be understood that these examples are non-limiting. The above-described proof system is particularly useful in applications where large amounts of data are encrypted. In known methods, proving correct encryption of data requires multiple iterations, which is time- and computationally inefficient, and may even be impossible depending on the data size.

[0492] This problem is overcome by the above method by hashing the data and proving that the prover has knowledge of the preimage of the hash.

[0493] 7.1 Scalable Zero-Knowledge Conditional Payments Maxwell's contingent payment scheme. The zero-knowledge contingent payment scheme (ZKCP), known in the art, works in two steps. (1) Buyer Alice specifies the requirements for the data she wants to buy, for example, Φ(data, public) = 1. (2) The seller, Bob, sends the (symmetric) ciphertext, ct, and digest, d, along with a zkSNARK that proves that the ciphertext encrypts data that matches the buyer's requirements and that the symmetric key used for encryption is a preimage of the sent digest.

[0494] Once the buyer verifies the zkSNARK, they set up a hash-time lock (HTLC) transaction on the BSV blockchain for the agreed-upon amount using the digest d. When the seller redeems the funds, they also reveal the symmetric key (the preimage of the digest), allowing the buyer to decrypt the purchased data.

[0495] Examples of real-world use cases for large datasets include: Movies in HD format (or lossless format) Complex proprietary software

[0496] The requirement imposed in both cases is that their SHA256 digest is equal to some known bit string h*, so Φ(data, h*) = 1 if and only if SHA256(data) = h*.

[0497] Source of inefficiency. The problem with this approach is that when the data is large (as in the example above), monolithically proving the correct evaluation of an encryption circuit with zero knowledge is expensive. Encrypting just 1MB of data using a 128-bit block cipher in counter mode like AES-CTR requires 65536 iterations of the block cipher.

[0498] Solution. The encryption of data is proven incrementally. Because the prover is incremental, it can handle arbitrarily large data in a scalable way. More specifically, the data is encrypted with a one-time pad (OTP) encryption scheme. The one-time password derives a key of the same length as the data. To avoid performing HTLC transactions with excessively large keys, a key stretching step can be introduced. Thus, the data is encrypted with output keying material okm, which is an extension of short (e.g., 128 or 256 bits) input keying material ikm using a key derivation function (HKDF).

[0499] HKDF is known in the art and therefore will not be described in detail herein. In summary, HKDF includes two steps: In the first step, a fixed-length pseudorandom key prk is extracted from the input keying material ikm. This step is called HMAC. ext In a second step, the fixed length pseudorandom key is generated by adding some additional pseudorandom keys H i The steps are expanded to multiple HMAC expThe output keying material okm may be implemented by node 908. The output keying material okm may be generated by adding these additional pseudo-random keys H i Includes:

[0500] What is put on-chain is the (short) hash of the ikm, i.e.

[0501]

number

[0502] okm := HKDF(ikm), d := SHA2(ikm) is.

[0503] Figure 9 shows a multi-predicate approach for efficient and scalable ZKCP.

[0504]

number

[0505] of

[0506]

number

[0507] The transcript is shown. Source nodes are represented by open circles and output nodes are represented by filled circles. The data is stored in the data := (pt1, ..., pt N ), and the resulting ciphertext is ct := (ct1, ..., ct N ) is. i and ct i is a block of h bits, where h is the range of the underlying hash function used in HKDF,

[0508]

number

[0509] is.

[0510] The improvement provided by this method is two-fold. 1) Recursive zkSNARKs are used to progressively prove the correct encryption of data. This means that the hardware requirements of the prover are very limited, even when working with large data. More specifically, the correct hashing of input keying material ikm and the XOR of the data with output keying material okm are progressively proven. The transcript for the proof is shown in Figure 9. This transcript distinguishes four types of nodes 906, 908, 910, 912. The key expansion subtranscript 902 corresponds to the HKDF computation and is performed in two types of HMAC nodes. The difference between these nodes is the size of their input, i.e., HMAC ext Node 906 corresponds to the "extract" step of HKDF and performs HMAC exp Node 908 corresponds to the loop of the "extend" step. Both the key extension 902 and the exclusive-or transcript 904 depend on the data length, and this is where the incremental nature of the scheme is exploited. 2)(Circuit Π HMAC' , Π HMAC To further speed up the proof time (governed by the number of constraints in ), a zero-knowledge friendly hash function (e.g., Pedersen or Poseidon) may be used for the HKDF computation (at each HMAC node / iteration 906, 908). This speeds up the proof time compared to proving compliance of a transcript resulting from, for example, AES-CTR.

[0511] Reduce the number of output proofs. A PCD prover generates as many proofs as there are sink (output) nodes in the computation transcript. In Figure 9, the N + 1 output nodes can be collapsed into two nodes as follows: iis considered to be the i-th leaf of a Merkle tree, and then the correct root generation and the correct form of the leaf can be proven using the Merkle tree prover of Section 6.3. The verifier generates a root node proof π merkle and SHA2 node proof π preim , and the ciphertext ct := (ct1, ...., ct N ) to check the well-formedness of ct, the verifier regenerates the Merkle root and tests it against π merkle This compression is also applied when progressively proving that data has been encrypted with a block cipher.

[0512] 10 provides an exemplary method for the above application. In the example of FIG. 10, a data requester 1004 acts as a verifier 604 and a data provider 1002 acts as a prover 602.

[0513] In step 1, the data requester 1004 requests data from the data provider 1002. The requested data may be any large piece of data, such as an HD movie file or a complex computer program. The data requester 1004 also provides the data provider 1002 with proof keys pk for both the preimage SNARK of Section 6.1 and the Merkle tree SNARK of Section 6.3. In some embodiments, a trusted third party provides the proof keys pk to the data requester 1004. The trusted third party may provide the data provider 1002 with a verification key vk corresponding to the proof key pk and may also provide the data provider 1002 with the proof key pk. In this way, a malicious data requester 1004 cannot learn information about the data without purchasing it, simply by inspecting a zk proof generated using a flawed proof key provided by the data requester 1004, which does not preserve zero-knowledge.

[0514] In step 2, the data provider 1002 selects input keying material ikm, derives output keying material okm using HKDF, and uses the output keying material to generate a ciphertext ct of the requested data.i The input keying material is sometimes referred to herein as a data encryption key.

[0515] It will be appreciated that the data provider 1002 may derive the output keying material okm before receiving the data request. The data provider 1002 may also have derived the ciphertext prior to the data request, such that the data provider 1002 stores the ciphertext in memory in association with the data for retrieval when the request for data is received. Private information needed to generate the proof may also be stored in association therewith.

[0516] The data provider 1002 also computes a digest d, also referred to herein as a key hash, by computing a hash of the input keying material i m in step 3. As noted above, the data provider 1002 may derive the digest before receiving the data request and store the digest in memory.

[0517] The data provider 1002 generates a proof based on the proof key pk that attests to both the preimage and the ciphertext. In this way, it is ensured that the ciphertext was generated using a preimage of the SHA2 digest as the symmetric key, such that the proof ensures that the ciphertext and the preimage of the digest are consistent. For example, in step 4, the proof generates a preimage proof π to prove in zero-knowledge that the input keying material i k m is a preimage of the digest d. preim and a Merkle tree proof π to prove that the ciphertext is correctly generated. tree and

[0518] The data provider 1002 provides or otherwise makes available to the data requester 1004 the ciphertext, digests, and certificates corresponding to the requested data in step 5 .

[0519] In step 6, the data requester 1004 verifies the digest and ciphertext using the received certificate and verification key.

[0520] If the data requester 1004 is convinced that the received ciphertext and digest meet its requirements, the data requester 1004 generates a funding transaction in step 7. The funding transaction provides payment to exchange for data in a UTXO. This UTXO is locked to a key corresponding to the data provider 1002. The funding transaction may be an HTLC transaction and may be generated using the digest. The data requester 1004 makes the funding transaction available for storage in the blockchain 150 in step 8.

[0521] To provide the input keying material to the data requester 1004, the data provider 1002 generates a key transaction in step 9. The key transaction unlock script unlocks the funding transaction UTXO and includes the input keying material ikm so that when executed together with the funding transaction lock script, the input keying material is verified to be a preimage of the digest. In this way, the data provider 1002 provides the key needed to decrypt the ciphertext when receiving funds for the data. The key transaction is stored in the blockchain 150 in step 10.

[0522] The data requester 1004 retrieves input keying material from the blockchain 150 in step 11 and uses the input keying material to decrypt the ciphertext in step 12 to obtain the requested data.

[0523] 7.2 A fair and private digital marketplace Atomic swaps between buyers and sellers that simultaneously guarantee fairness and privacy are not possible without a trusted third party (TTP). Zero-knowledge conditional payments (ZKCP) use the blockchain as a TTP to enable such fair and private transactions. However, these interactions occur between two parties, which can be impractical. An intermediary—a digital marketplace—may connect the two parties in exchange for a fee.

[0524] Digital Marketplace: The following design of a digital marketplace may be used. 1. The seller generates two layers of encryption for their data.

[0525]

number

[0526] 2. Additionally, the seller provides a SNARK proof π verifying the correct generation of the outer ciphertext above. (sellerID) Therefore, specifically, the proof is: (i) ct outer (In particular, this is the correct encryption of the outer encryption key k outer (ii) the Φ-compliance of the inner encrypted data with respect to a given predicate Φ, and (iii) the outer ciphertext is encrypted with the inner encryption key k inner ensure that the hash of 3. The marketplace provides a database of sellers with a large number of sellers.

[0527]

number

[0528] Using the scheme in Section 3.3, the marketplace can build a Merkle root proof π that proves the validity of all leaves. merkle Generate. 4. The buyer fetches the tree and approves the root one time. 5. Buyer later wishes to purchase N items from seller sellerID. The buyer contacts the seller and informs the seller of his / her intention to purchase the data items. 6. The seller sends the outer key to the buyer via a private channel.

[0529]

number

[0530] (potentially two or more). 7. The buyer decrypts the outer layer of each received ciphertext to obtain N inner ciphertexts and the hashed inner keys.

[0531]

number

[0532] Note that the buyer implicitly verifies the N encrypted data items by verifying the (single) proof of the Merkle root in step 4. 8. Buyers and sellers use the blockchain to execute fair and private atomic swaps (Maxwell ZKCP protocol). Therefore, a. The buyer establishes an HTLC contract using digest d (in BSV, this can be done in two transactions). b. The seller stores the internal key k in the unlock script. inner The funds are fulfilled by embedding as a preimage of d. c. The buyer reads the blockchain and inner and decrypts the compliant data.

[0533] Federation of Digital Markets. Several digital marketplaces can be federated. One entity, the data aggregator, aggregates the Merkle root proofs of all markets, as described in Section 6.3. Sellers and buyers only need to verify this single master root and upload / download data from different locations.

[0534] 7.3 Editing a Partial Blockchain A mechanism for proving correct transaction compilation can use SNARKs to prove that a public pattern appears in the preimage (transaction) of a given TxID (SHA256 digest). However, this proof scheme is not scalable: to show the pattern that spans each of the transaction's 512-bit blocks, m proofs need to be generated, where m is the number of blocks. For a 1MB transaction, this means verifying 16384 proofs.

[0535] Instead, the SNARK scheme of Section 6.2 can be used to generate a single proof regardless of the size of the transaction. The incremental computational nature of our SNARKs also means that for extremely large transactions (e.g., 1GB of data), the prover can pause proof generation and later resume where they left it.

[0536] 7.4 Efficient Merklized Transactions A transaction identifier, TxID', can be generated by ordering the fields as leaves of a Merkle tree and setting TxID' as the root. Such a data structure allows for the inclusion of fields without revealing the entire transaction to be proven by sending a Merkle tree proof to the verifier.

[0537] Again, the problem is scalability when proving the consistency of a Merkle identifier TxID' with the standard identifier TxID that appears on-chain in a zero-knowledge manner. There are at least as many leaves as there are transaction inputs and outputs. Because the number of I / Os varies for each transaction, circuit-specific SNARKs (which are most efficient) cannot be used; therefore, universal SNARKs must be used instead. Furthermore, proving the consistency of identifiers for transactions with a large number of I / Os consumes time and space beyond practical limits in some cases.

[0538] The SNARK proposed in Section 6.3 (Merkle Tree Statement) allows the integrity of both types of identifiers to be proven in a scalable way, independently of the number of I / Os in each transaction and allowing the choice of a circuit-specific proof system (such as Groth16) if desired. The input proof attached to each of the tree's leaves is the correct SHA2 hash. Again, it is possible to utilize the scalable scheme of Section 6.1 when dealing with leaf hashes of lock script fields that contain large chunks of OP_RETURN data, for example.

[0539] 8. Further Considerations 8.1 Comparing Recursive SNARKs The following metrics are used to categorize existing preprocessing SNARKs with succinct verifiers: Circuit-specific: Proof / verification keys cannot be reused for different circuits (NP relation). If keys can be reused, the scheme is universal. Argument size: small vs. medium vs. large. (Smaller is better.) · Prover execution time: fast vs. medium vs. slow. · Setup: Trusted vs. updatable vs. transparent setup. Trusted: The parties generating the proof and verification keys or structured reference strings (SRS) are in possession of sensitive data that, if publicly disclosed (especially by the prover), would compromise the integrity of the scheme. Trusted setups must be performed in a controlled environment. Updatable: Anyone can update a Structured Reference String (SRS), which limits the risk of breaking integrity in a trusted setup, since the honesty of only one updater is sufficient to maintain integrity (of the generated proofs after an update has been made). Transparent: Any untrusted party can generate the attestation and verification keys or the SRS. Post-quantum security: whether the scheme will be secure in the presence of post-quantum computers.

[0540] [Table 4]

[0541] 8.2 PCD from Pairing-Based SNARKs Recursive proof composition, or proven data, can be constructed from the base SNARK with a succinct verifier (an algorithm whose running time is sublinear in the size of the circuit). It is not possible to have succinct verification without preprocessing, i.e., the verifier must at some point read the circuit that the correct valuation is checking—either at the time of preprocessing or later when given an instance of the relation. What the preprocessing (i.e., the offline verifier) ​​allows is the generation of a short (sublinear) description of the circuit, i.e., a verification key. Such a key is given to the online verifier together with the public input of the circuit.

[0542] Note: There are other ways to construct a PCD that are not considered here, for example with simple accumulators or for circuits whose description is much smaller than the actual computation.

[0543] 8.2.1 Circuit for Compliance Predicates Computational compliance predicate for transcript T

[0544]

number

[0545] Each node is a template circuit C i By proving the satisfiability of i Prove compliance of the predicate Π i is the node data

[0546]

number

[0547] In addition to checking that this holds for

[0548]

number

[0549] Valid proof of entry to demonstrate compliance with

[0550]

number

[0551] also claims the existence of

[0552] [Table 5]

[0553] Ensuring Compliance of Correct Input: How can we ensure that the input complies with the correct predicate? This can be ensured as follows: i. Each compliance predicate Π i indicates which input types it accepts. Hence, the compliance predicate Π i is a subset T in,i ⊆{0, 1, ..., n} for i'∈T in,i i' := z if and only if in,j Accepts input of type . ii. Template circuit C i The first thing to check is the type of the output data out .type is a compliance predicate Π i That is, z out .type = i, which is a valid proof of input z in,j But (because the proof is valid) z in,j Circuit C such that .type := i' i This means that

[0554] Combining both items, the input is T in,i is the current node predicate Π i where i'∈T is the set of allowed input types specified in in,i So that each predicate Π i It can be seen that it is only possible to comply with

[0555] Actual circuits. For clarity, low-level details have been avoided and many optimizations have been applied. The inputs and logic of the circuits are subtly different in practice. Importantly, each circuit C i To make the size of C independent of the number of predicates n, i requires checking the Merkle tree proof within C i Making is well-defined requires moving the verification key to a private input and passing a hash of the verification key as the public input.

[0556] 8.2.2 Proving Circuit Satisfiability SNARKs on elliptic curve cycles. Each circuit C outlined above i Regarding , we consider two preprocessing SNARK schemes (G i,α , P i,α , V i,α ), (G i,β , P i,β , V i,β ) Consider the first method (G i,α , P i,α , V i,α )teeth,

[0557]

number

[0558] We prove the satisfiability of the circuit, which is

[0559]

number

[0560] On the other hand, the second method (G i,β , P i,β , V i,β )teeth,

[0561]

number

[0562] We prove the satisfiability of the circuit, which is

[0563]

number

[0564] cyclic pattern, i.e. the base field of the first curve coincides with the scalar field of the second curve and vice versa,

[0565]

number

[0566] and

[0567]

number

[0568] Please note that

[0569] Two-step proof generation. The first method (G i,α , P i,α , V i,α ) is the circuit C i prove / verify the satisfiability of

[0570]

number

[0571] As a circuit. C i To provide input to the node, we use

[0572]

number

[0573] Input proof of compliance

[0574]

number

[0575] z in,j but i' := zin,j Predicate Π that is .type i' The first prover P i',α But V i',α A proof that can be verified by π α However, the verifier V i',α The circuit

[0576]

number

[0577] The circuit is (V i',α is the first curve

[0578]

number

[0579] It deals with points in the base field

[0580]

number

[0581] Above,

[0582]

number

[0583] In the circuit

[0584]

number

[0585] (it is expensive to imitate the arithmetic of π α is the input π in,j To overcome this, π α Proof that proves the validity of π β(Proof of proof) is generated. More precisely, the "translation" circuit

[0586]

number

[0587] This circuit is constructed as follows: (first verifier V i',α is the base form

[0588]

number

[0589] (Because it is above)

[0590]

number

[0591] circuit, and the second prover P i',β Using

[0592]

number

[0593] Proof of satisfiability of π β Generate C i Given an input proof π in,j is a translation proof π j,β and (in step 3) C i The verifier, which is incorporated as a partial circuit of V i,β This is V i,β but

[0594]

number

[0595] It is now well-defined because it can be represented as a circuit.

[0596] 8.2.3 PCD method generator

[0597]

number

[0598] To generate the certification and verification keys,

[0599]

number

[0600] Let be the compliance predicate. The PCD generator generates a compliance circuit (C1, ..., C n ) and their corresponding translation circuits

[0601]

number

[0602] The PCD generator uses the SNARK method to generate proof / verification keys: (pk i,α , vk i,α )←G α,i (C i , λ) and

[0603]

number

[0604] The PCD generator generates the proof key pk pcd := ((pk 1,α , vk 1,α , ..., pk n,α , vk n,α ), (pk 1,β , vk 1,β , ..., pk n,β , vk n,β ))、 and the verification key vk pcd := (vk 1,β , ..., vk n,β ) Output.

[0605] Prover

[0606]

number

[0607] Predicate Π i To prove node compliance, the prover must provide the node data (input

[0608]

number

[0609] , local z loc , and the output message z out ), input proof

[0610]

number

[0611] , and the corresponding verification key (to verify the input proof)

[0612]

number

[0613] The prover takes pk i,α as the proof key to generate the circuit C i Proof of satisfiability of π α Then the prover generates the proof π α Prove that π β Therefore, the prover "translates" pk i,β as the proof key.

[0614]

number

[0615] The prover proves the satisfiability of π out := π β Output.

[0616] Verifier

[0617]

number

[0618] Predicate Π i Z to out To verify compliance of, the verifier generates output data z out and proof π out The verifier receives the verification key vk i,β Using b := V i,β (z out , π out If b is acceptable, the verifier outputs "accept". Otherwise, it outputs "reject".

[0619] 8.3 Elliptic Curves for Pairing Bases 8.3.1 Which curve family to choose? MNT curves are the only ones PCD with SNARKs on elliptic curves suitable for pairing can be instantiated on a limited number of curves. The following impossibility result can be proved. · Barreto-Naehrig (BN) curves do not have cycles of elliptic curves. · Only cycles on curves of prime order can exist. MNT curves only have cycles of length 2 or 4. The embedding order must alternate between 4 and 6.

[0620] From the above, it can be concluded that the only practical cycle is the MNT4-MNT6 family.

[0621] 8.3.2 Trading Security for Efficiency This problem is called the extension field.

[0622]

number

[0623] It is possible to solve the discrete logarithm problem in any of the original groups if it is simple in the target group, which is a subgroup of p, where p is the prime degree of the base field of the original curve, and k is the embedding degree. k The smaller p is, the easier it is to find the discrete logarithm in the target group. Conversely, the larger p or k is, the less efficient the pairing computation becomes (it is preferable to have a small p and a large k).

[0624] Curves with small embedding degree k or prime number p are desirable for applications suitable for pairing, but for security purposes curves with embedding degree k or prime number p that are not too small are desirable.

[0625] 8.3.3 Security of the MNT Curve As of July 2022, to achieve a conservative 128-bit security level for elliptic curves suitable for pairing, the extension field must be

[0626]

number

[0627] The minimum required length is 5534 bits to withstand modern cryptanalysis of the discrete logarithm in . Other options are possible, as summarized in the table below. As mentioned above, MNT curves can only have embedding degrees 4 or 6. Security must be for curves with smaller degrees (4).

[0628] The table below gives the three MNT cycles along with their corresponding security levels.

[0629] [Table 6]

[0630] 9. Further Special Notes Other variations or use cases of the disclosed technology will be apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

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

[0632] 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, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, network entities may perform the function of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

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

[0634] Even more broadly, all references above to the term "Bitcoin node" 104 may be replaced by the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above in connection with blockchain node 104.

[0635] Some embodiments have been described in terms of blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often called validators. Blockchain nodes may lock up their tokens for a specific amount of time to have a chance to become validators. In general, the node that locks up the largest stake for the longest period of time has the greatest chance to become the next validator.

[0636] It will be appreciated that the above embodiments have been described by way of example only. More broadly, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0637] Statement 1. A computer-implemented method for generating a zero-knowledge proof for proving that each data block of a plurality of data blocks corresponding to a Merkle tree satisfies a predefined criterion, the Merkle tree including a plurality of leaf hash values ​​and a plurality of inner hash values, the plurality of inner hash values ​​being arranged in layers, a plurality of leaf nodes being mapped to the plurality of leaf hash values, and a plurality of inner nodes being mapped to the plurality of inner hash values, the method comprising the steps of: executing a plurality of leaf nodes, each leaf node receiving a respective data block and a corresponding data block proof for proving that the data block satisfies the predefined criterion; verifying the respective data block proof; calculating a data block hash based on the respective data block; and a step of executing a plurality of internal nodes, each of the plurality of internal nodes configured to receive a respective hash value from each of two previous nodes in a Merkle tree, calculate an output hash value based on the respective received hash values, and output the output hash value, wherein the respective received hash values ​​of a first layer of the plurality of internal nodes are respective data block hashes received from respective leaf nodes, the respective received hash values ​​of each of the plurality of internal nodes are respective output hash values ​​received from respective internal nodes, and the output hash value calculated by a final internal node in a final layer of the Merkle tree is a Merkle root corresponding to the Merkle tree.

[0638] Statement 2. The method of statement 1, wherein each leaf node is further configured to generate a leaf node proof based on the data block hash and the corresponding data block proof, and output the leaf node proof.

[0639] Statement 3. The method of statement 2, wherein each internal node is further configured to receive a respective proof from each of two previous nodes and generate an output proof based on the respective received proof and the output hash value, wherein the respective received proofs of a first layer of the plurality of internal nodes are respective leaf node proofs received from respective leaf nodes, and the respective received proofs of each other layer of the plurality of internal nodes are respective output proofs received from respective internal nodes, and the output proof generated by a final internal node of the final layer is a Merkle tree proof corresponding to a Merkle tree, and the Merkle tree proof establishes that the output hash calculated by the final internal node is a Merkle root corresponding to a Merkle tree having a data block that satisfies a predefined criterion.

[0640] Statement 4. The method of statement 3, comprising: receiving a Merkle tree proof key, wherein each leaf node proof and output proof is generated based on the Merkle tree proof key; and making the Merkle proof available to a verifying entity, wherein the verifying entity has access to a Merkle tree verification key corresponding to the Merkle tree proof key.

[0641] Statement 5. The method of any one of the preceding statements, further comprising the step of calculating, for each data block, a corresponding data block proof for proving that the data block satisfies a predefined criterion.

[0642] Statement 6. The method according to any one of the preceding statements, comprising the step of receiving a data block certification key, wherein the data block certification key corresponds to a predefined criterion, and each data block certification is generated based on the data block certification key.

[0643] Statement 7. A method according to any one of the preceding statements, wherein the predefined criteria enforce a predefined pattern, and wherein the step of calculating, for each data block, a corresponding data block proof comprises the steps of obtaining a respective pattern bit array block and a respective check bit array block, wherein the pattern bit array block describes a portion of the predefined pattern corresponding to the respective data block, and the check bit array block defines a bit of the respective data block to be checked; determining that the bit of the respective data block defined by the respective check bit array block is equal to the corresponding bit of the respective pattern bit array block; and generating the data block proof based on the respective pattern bit array block and the respective check bit array block.

[0644] Statement 8. A computer-implemented method for providing data to an entity requesting the data, the method comprising: generating a Merkle proof according to statement 3, wherein each data block of a plurality of data blocks is an encrypted portion of the data encrypted under a data encryption key, the predefined criterion being that the encrypted portion was encrypted under the data encryption key, and the data encryption key is a symmetric key; making the Merkle tree proof and the Merkle root available to the entity requesting the data; making the data blocks available to the entity requesting the data; obtaining a data encryption key request from the entity requesting the data; and making the data encryption key available to the entity requesting the data in response to the data encryption key request.

[0645] Statement 9. The method of statement 8, further comprising the steps of generating a preimage proof associated with the data encryption key, the preimage proof being a zero-knowledge proof for proving knowledge of the data encryption key, and making the preimage proof and a hash of the data encryption key available to an entity requesting the data.

[0646] Statement 10. The method of statement 8 or 9, wherein the data encryption key request is provided in a funding blockchain transaction, and the method further includes the steps of generating a blockchain transaction for providing the data encryption key by providing the private key and the data encryption key in a first unlocking script of the blockchain transaction, wherein the first unlocking script, when executed together with a first locking script of the funding blockchain transaction, is configured to unlock unspent transaction outputs corresponding to the first locking script based on the private key and make the data encryption key available to an entity requesting the data; and making the blockchain transaction available to one or more nodes of a blockchain network.

[0647] Statement 11. The method of any of statements 8 to 10, wherein each encrypted portion of data is derived from a respective portion of data, and the method further comprises the steps of deriving output keying material from a data encryption key, the output keying material comprising a plurality of output keying material portions, and encrypting each respective portion of data with a corresponding output keying material portion to generate a plurality of data blocks.

[0648] Statement 12. The method of statement 11, wherein the output keying material is derived from the data encryption key using a hash-based key derivation function.

[0649] Statement 13. A computer-implemented method for decrypting encrypted data, the encrypted data corresponding to requested data encrypted under a data encryption key, the data encryption key being a symmetric key, the method comprising: obtaining a Merkle tree proof and a Merkle root according to statement 3, wherein each data block of a plurality of data blocks is an encrypted portion of the requested data encrypted under the data encryption key, and the predefined criterion is that the encrypted portion was encrypted under the data encryption key; verifying the Merkle tree proof based on the Merkle root; obtaining the encrypted data; requesting a data encryption key in response to verifying the Merkle proof; obtaining the data encryption key; and decrypting the encrypted data based on the data encryption key.

[0650] Statement 14. The method of statement 13, wherein the request for the data encryption key is provided in a funding blockchain transaction, and the method further includes generating the funding blockchain transaction and making the funding blockchain transaction available to one or more nodes of the blockchain network.

[0651] Statement 15. The method of statement 13 or 14, further comprising the steps of receiving a preimage proof associated with the data encryption key, the preimage proof being a zero-knowledge proof for proving knowledge of the data encryption key, receiving a hash of the data encryption key, and verifying the preimage proof based on the hash of the data encryption key, wherein the data encryption key is requested in response to verifying the preimage proof.

[0652] Statement 16. The method of statement 14 or 15, wherein the funding blockchain transaction includes a first locking script that includes a hash of a data encryption key, and wherein the first locking script, when executed together with a first unlocking script of the blockchain transaction that includes the data encryption key, is configured to generate a hash of the data encryption key of the first unlocking script and verify that the generated hash is equal to the hash of the data encryption key of the first locking script.

[0653] Statement 17. At least one computing device including a memory including one or more memory units and a processing device including one or more processing units, wherein the memory stores one or more portions of code arranged to be executed on the processing device, the code defining a Merkle tree for generating a zero-knowledge proof for proving that each data block of a plurality of data blocks corresponding to the Merkle tree satisfies a predefined criterion, the Merkle tree including a plurality of leaf nodes and a plurality of internal nodes, the plurality of internal nodes being arranged in layers, each of the one or more portions of code defining one of the one or more internal nodes of the plurality of leaf nodes, the processing unit being configured to execute the one or more portions of code, wherein the portion defining one of the plurality of leaf nodes, when executed by the processing device, causes the processing device to generate a zero-knowledge proof for proving that each data block of a plurality of data blocks corresponding to the Merkle tree satisfies a predefined criterion. the portion defining one of the plurality of internal nodes, when executed by the processing device, causes the processing device to receive a respective hash value from each of two previous nodes in a Merkle tree, calculate an output hash value based on the respective received hash values, and output the output hash value, wherein the respective received hash values ​​of a first layer of the plurality of internal nodes are the respective data block hashes received from the respective leaf nodes, the respective received hash values ​​of each of the plurality of internal nodes are the respective output hash values ​​received from the respective internal nodes, and the output hash value calculated by a final internal node in a final layer of the Merkle tree is a Merkle root corresponding to the Merkle tree.

[0654] Statement 18. The computer system of statement 17, wherein the computer system includes a second computing device that executes a portion of code that defines one of the plurality of leaf nodes, the computing device executing a portion of code that defines one of the plurality of interior nodes, and the processing unit of the computing device is further configured to receive the data block hash from the second computing device.

[0655] Statement 19. The computer system of statement 17 or 18, wherein the system further includes a requesting computing device including a memory and a processing unit, the memory storing code arranged to be executed on the processing unit, the code configured to perform the method of any of statements 13 to 16 when on the processing unit.

[0656] Statement 20. A computer program embodied on computer-readable storage and configured to perform the method of any of statements 1 to 16 when executed on one or more processors. [Explanation of symbols]

[0657] 100 systems 101 Packet Switched Network 102 Computer terminals and computer equipment 102a Computer Equipment 102b Computer Equipment 103 Users, Parties, and Agents 103a User, Original User or Entity, First Party, Alice 103b New user or entity, second party, Bob 104 Blockchain nodes, Bitcoin nodes 105 Client Applications, Software 106 Peer-to-peer (P2P) networks, blockchain networks, Bitcoin networks 107 Side Channel 150 Blockchain, Bitcoin Blockchain 151 Blocks of Data Blocks created 151n-1 years ago 151n New Block 152 transactions 152i Predecessor Transaction 152j Current Transaction, New Transaction, Onward Transaction 153 Genesis Block (Gb) 154 Ordered Sets, Ordered Pools 155 Block Pointer 201 Header 202 Input 203 Output, UTXO 302 Source Node 304 intermediate nodes, intermediate state nodes 306 Output node, digest node 400 SHA2 Transcript 402 init node 602 Prover 604 Verifier 700 Merkle Tree 702 leaves 704 leaf nodes 706 internal nodes 706a Last internal node 902 Key Extension Subtranscript 904 Exclusive OR Transcript 906 HMAC ext Node, node 908 HMAC exp Node, node 910 nodes 912 nodes 1002 Data Providers 1004 Data Requester

Claims

1. 1. A computer-implemented method for generating a zero-knowledge proof for proving that each data block of a plurality of data blocks corresponding to a Merkle tree satisfies a predefined criterion, the Merkle tree including a plurality of leaf hash values ​​and a plurality of interior hash values, the plurality of interior hash values ​​being arranged in layers, a plurality of leaf nodes being mapped to the plurality of leaf hash values, and a plurality of interior nodes being mapped to the plurality of interior hash values, the method comprising: executing the plurality of leaf nodes, each leaf node comprising: receiving each data block and a corresponding data block certificate for verifying that the data block satisfies the predefined criteria; Verifying each data block proof; calculating a data block hash based on each data block; outputting said data block hash; and Executing the plurality of internal nodes, each of the plurality of internal nodes comprising: receiving a respective hash value from each of two previous nodes of said Merkle tree; calculating an output hash value based on each received hash value; outputting the output hash value; configured to: the received respective hash values ​​of a first layer of the plurality of internal nodes are respective data block hashes received from respective leaf nodes, and the received respective hash values ​​of other layers of each of the plurality of internal nodes are respective output hash values ​​received from respective internal nodes; the output hash value computed by the last interior node in the last layer of the Merkle tree is the Merkle root corresponding to the Merkle tree.

2. Each leaf node is generating a leaf node proof based on the data block hash and the corresponding data block proof; outputting the leaf node proof; The method of claim 1 , further configured to:

3. Each internal node is receiving a respective certificate from each of said two previous nodes; generating an output proof based on each of the received proofs and the output hash value; Koto and further configured to: the received respective proofs of the first layer of the plurality of internal nodes are respective leaf node proofs received from respective leaf nodes, and the received respective proofs of the other layer of each of the plurality of internal nodes are respective output proofs received from respective internal nodes; 3. The method of claim 2, wherein the output proof produced by the final internal node of the final layer is a Merkle tree proof corresponding to the Merkle tree, the Merkle tree proof establishing that the output hash computed by the final internal node is the Merkle root corresponding to the Merkle tree whose data blocks satisfy the predefined criteria.

4. receiving a Merkle tree proof key, wherein each leaf node proof and output proof is generated based on the Merkle tree proof key; making a Merkle proof available to a verifying entity, said verifying entity having access to a Merkle tree verification key corresponding to said Merkle tree proof key; 4. The method of claim 3, comprising:

5. 5. The method of claim 1, further comprising the step of: for each data block, calculating the corresponding data block proof to prove that the data block satisfies the predefined criteria.

6. 6. The method of claim 1, further comprising receiving a data block certification key, the data block certification key corresponding to the predefined criteria, and each data block certification being generated based on the data block certification key.

7. the predefined criteria enforce a predefined pattern, and for each data block, calculating the corresponding data block proof, obtaining a respective pattern bit array block and a respective check bit array block, wherein the pattern bit array block describes a portion of the predefined pattern corresponding to the respective data block, and the check bit array block defines bits of the respective data block to be checked; determining that the bits of the respective data blocks defined by the respective check bit alignment blocks are equal to corresponding bits of the respective pattern bit alignment blocks; generating the data block certificate based on the respective pattern bit array blocks and the respective check bit array blocks; 7. The method of claim 1, comprising:

8. 1. A computer-implemented method for providing data to an entity requesting the data, comprising: generating a Merkle tree proof as claimed in claim 3, wherein each data block of the plurality of data blocks is an encrypted portion of the data encrypted under a data encryption key, the predefined criterion being that the encrypted portion was encrypted under the data encryption key, and the data encryption key is a symmetric key; making the Merkle tree proof and the Merkle root available to entities requesting the data; making said data blocks available to entities requesting said data; obtaining a data encryption key request from an entity requesting the data; making the data encryption key available to an entity requesting the data in response to the data encryption key request; A method comprising:

9. generating a preimage proof associated with the data encryption key, the preimage proof being a zero-knowledge proof for proving knowledge of the data encryption key; making the preimage proof and the hash of the data encryption key available to an entity requesting the data; 9. The method of claim 8, further comprising:

10. The data encryption key request is provided in a funding blockchain transaction, and the method further comprises: generating a blockchain transaction for providing the data encryption key by providing a private key and the data encryption key in a first unlocking script of the blockchain transaction, wherein when the first unlocking script is executed together with a first locking script of a funding blockchain transaction, unlocking unspent transaction outputs corresponding to the first locking script based on the private key; making said data encryption key available to entities requesting said data; and making the blockchain transaction available to one or more nodes in a blockchain network; 10. The method of claim 8 or 9, further comprising:

11. each encrypted portion of the data is derived from a respective portion of the data, and the method comprises: deriving output keying material from the data encryption key, the output keying material comprising a plurality of output keying material portions; encrypting each respective portion of said data with a corresponding output keying material portion to generate said plurality of data blocks; 11. The method of claim 8, further comprising:

12. The method of claim 11 , wherein the output keying material is derived from the data encryption key using a hash-based key derivation function.

13. 1. A computer-implemented method for decrypting encrypted data, the encrypted data corresponding to requested data encrypted under a data encryption key, the data encryption key being a symmetric key, the method comprising: obtaining a Merkle tree proof and Merkle root according to claim 3, wherein each data block of the plurality of data blocks is an encrypted portion of requested data encrypted under a data encryption key, and the predefined criterion is that the encrypted portion was encrypted under the data encryption key; verifying the Merkle tree proof based on the Merkle root; obtaining the encrypted data; requesting the data encryption key in response to verifying the Merkle proof; obtaining the data encryption key; decrypting the encrypted data based on the data encryption key; A method comprising:

14. 14. The method of claim 13, wherein the request for the data encryption key is provided in a funding blockchain transaction, the method further comprising generating the funding blockchain transaction and making the funding blockchain transaction available to one or more nodes of a blockchain network.

15. receiving a preimage proof associated with the data encryption key, the preimage proof being a zero-knowledge proof for proving knowledge of the data encryption key; receiving a hash of the data encryption key; verifying the preimage certificate based on the hash of the data encryption key; further comprising 15. The method of claim 13 or 14, wherein the data encryption key is requested in response to verifying the preimage certificate.

16. the funding blockchain transaction includes a first locking script that includes the hash of the data encryption key, and when the first locking script is executed together with a first unlocking script of the blockchain transaction that includes the data encryption key: generating a hash of the data encryption key of the first unlock script; verifying that the generated hash is equal to the hash of the data encryption key of the first lock script; 16. The method of claim 14 or 15, wherein the method is configured to:

17. 1. At least one computing device including: a memory including one or more memory units; and a processing device including one or more processing units, wherein the memory stores one or more portions of code arranged to be executed on the processing device, the code defining a Merkle tree for generating a zero-knowledge proof for proving that each data block of a plurality of data blocks corresponding to the Merkle tree satisfies a predefined criterion, the Merkle tree including a plurality of leaf nodes and a plurality of internal nodes, the plurality of internal nodes arranged in layers, each of the one or more portions of code defining one of the plurality of leaf nodes or one of the plurality of internal nodes, and the processing unit is configured to execute the one or more portions of code. Including, The portion defining one of the plurality of leaf nodes, when executed by the processing unit, causes the processing unit to: receiving each data block and a corresponding data block proof; verifying each data block proof; calculating a data block hash based on each data block; outputting said data block hash; Let The portion defining one of the plurality of internal nodes, when executed by the processing unit, causes the processing unit to: receiving a respective hash value from each of two previous nodes of said Merkle tree; calculating an output hash value based on each of the received hash values; outputting the output hash value; Let the received respective hash values ​​of a first layer of the plurality of internal nodes are respective data block hashes received from respective leaf nodes, and the received respective hash values ​​of other layers of each of the plurality of internal nodes are respective output hash values ​​received from respective internal nodes; the output hash value computed by the last interior node in the last layer of the Merkle tree is the Merkle root corresponding to the Merkle tree.

18. 18. The computer system of claim 17, wherein the computer system includes a second computing device that executes the portion of code that defines one of the plurality of leaf nodes, the computing device executing the portion of code that defines one of the plurality of internal nodes, and the processing unit of the computing device is further configured to receive the data block hash from the second computing device.

19. 19. The computer system of claim 17 or 18, wherein the system further includes a requesting computing device including a memory and a processing unit, the memory storing code arranged to be executed on the processing unit, the code configured to execute the method of any one of claims 13 to 16 when on the processing unit.

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

Images