Zero-knowledge proofs

Abstract

A computer-implemented method for generating a zero-knowledge proof that proves knowledge of a preimage value is obtained. A series of preimage blocks that, when combined, form the preimage value is obtained. A series of nodes are executed, each node in the series being configured to receive a respective current state and a respective current iteration counter, evaluate an instance of a predefined compression function based on the respective current state to calculate a respective next state, increment the respective current iteration counter to generate a respective next iteration counter, determine that the instance of the predefined compression function has evaluated correctly based on each next preimage block in the series of preimage blocks, and output a proof that proves that the instance of the predefined compression function has evaluated correctly. The proof generated by the final node in the series proves knowledge of the preimage value.

Description

[Technical Field]

[0001] The present disclosure relates to a method for generating a zero-knowledge proof for proving knowledge of a preimage value, 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 distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain includes a chain of blocks of data, each containing one or more transactions. Each transaction points to a preceding transaction in the sequence, which may span one or more blocks, tracing back to one or more coinbase transactions, except for so-called "coinbase transactions," which are described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are created through a process often referred to as "mining," which involves multiple nodes competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and block publication may be achieved simply through the publication of block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to transfer digital assets (i.e., multiple digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to time-order index pointers. Blockchains may also be utilized to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow additional user data or indexes to data to be stored within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore increasingly complex data may be incorporated. For example, this may be used to store electronic documents or audio or video data on the blockchain.

[0004] Nodes (often referred to as "miners") in a blockchain network perform a distributed transaction registration and validation process, which will be described in more detail below. Briefly, in this process, a node validates a transaction, inserts it into a block template, and attempts to identify a valid proof-of-work solution for it. Once a valid solution is found, a new block is propagated to other nodes in the network, thereby allowing each node to record a new block on the blockchain. To record a transaction on the blockchain, a user (e.g., a blockchain client application) submits the transaction to be propagated to one of the nodes in the network. Nodes that receive the transaction may compete to find a proof-of-work solution that will incorporate the validated 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 or incorporated into blocks. Assuming the transaction is validated and thereby accepted onto the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that distributes a digital asset amount, i.e., a number of tokens. The detection and rejection of invalid transactions is enforced by the activities of competing nodes, who act as agents of the network and are incentivized to report and block illegal activity. Public disclosure of information allows users to continuously audit node performance. The mere publication of block headers allows participants to ensure the continued integrity of the blockchain.

[0006] In an “output-based” model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset derivable from an ongoing sequence of transactions. A spendable output is sometimes referred to as a UTXO (or “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 necessary to validate and transfer a digital token or asset. Each input in a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such output in a preceding transaction and may further include an unlocking script to unlock the pointed-to output’s locking script. 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 on the blockchain, one of the validity criteria applied by each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction, and another is that the output of the first transaction has not already been redeemed by another, previous, valid transaction. A node that finds the target transaction invalid according to any of these conditions neither propagates it (as a valid transaction, but possibly to register an invalid transaction) nor includes it in a new block to be recorded on the blockchain.

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

[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 consistent with a Merkle root, typically prove knowledge of either a witness taken from a fixed domain or a witness of variable size but bounded by a small constant. This relies on a monolithic approach: expressing the entire computation as a single circuit and then proving the satisfiability of this circuit in a single computation. In fact, 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 by a graph). Each node (i) proves the correct evaluation of a predicate Π(z in ,z loc ,z out )=1 and that the proof attached to the input data is valid. Due to the recursive nature of proof generation (verifying the incoming proofs), the verifier only needs to verify the proof generated by the last (sink) node in the computation transcript.

[0011] There are two focuses: a) Interpret the entire computation as a "distributed" computation. Thus, a potentially large computation is broken down into a series of small subroutines (which yield manageable circuits). Each node executes only a given subroutine instantiation -- in particular, if a subroutine is a step in a loop, there will be as many nodes as there are iterations of the loop. b) Leveraging an existing PCD scheme against a compliant computational transcript as detailed, constructing the resulting SNARK (which internally invokes the PCD algorithm).

[0012] Any PCD scheme can be used for step (b). Section 8.1 describes the choice of curve when working with pairing-based pre-PCD. [Means for solving the problem]

[0013] According to one aspect disclosed herein, there is provided a computer-implemented method for generating a zero-knowledge proof that proves knowledge of a preimage value, the method including obtaining a series of preimage blocks that, when combined, form the preimage value; and executing a series of nodes, each of which is configured to receive a respective current state and a respective current iteration counter, evaluate an instance of a predefined compression function based on the respective current state, calculate a respective next state, increment a respective current iteration counter, and generate a respective next iteration counter, determine that the instance of the predefined compression function has been correctly evaluated based on the respective next preimage block of the series of preimage blocks, and output a proof, the proof establishing that the instance of the predefined compression function has been correctly evaluated; and the proof generated by a final node of the series of nodes proves knowledge of the preimage value.

[0014] This disclosure provides Succinct Zero-Knowledge Arguments Of Knowledge (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 1 GB or even larger), the memory requirements for the prover may be the same as for proving knowledge of a 512-bit preimage. The proof system provided herein can be used to prove knowledge of preimages of any size; that is, the same can be used as a proof system for any preimage size.

[0015] In general, the running time of the prover scales with the size of the secret input (the witness - which could be, for example, a large preimage or many leaves of a Merkle tree), which means that there are no strong 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 across many nodes that know only a portion of the secret input. This can be achieved due to the incremental nature of the SNARKs provided herein.

[0017] The simplicity of SNARKs also guarantees that the proof size is constant regardless of the size of the witness (or simply logarithmic in the size of the witness).

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

[0019] [Figure 1]FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates a schematic of some example transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 illustrates a schematic of a computational transcript for a function f(x,y):=(2(x+y),3(x+y)) with bounded noise. [Figure 4] FIG. 1 illustrates a schematic of a SHA2 transcript. [Figure 5] FIG. 10 is a diagram illustrating an example of an outline of the input relationship of a SHA2 node. [Figure 6] FIG. 1 illustrates an exemplary method for proving knowledge of a preimage using zero-knowledge proofs. [Figure 7] FIG. 1 illustrates a schematic diagram of a Merkle tree for generating a zero-knowledge proof that proves that each leaf of the Merkle tree satisfies a criterion. [Figure 8] FIG. 1 illustrates 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 comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not illustrated, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0021] Each blockchain node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing unit 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 a non-transitory computer-readable medium. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0022] A blockchain 150 includes a chain of blocks of data 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers 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 a digital asset in its possession, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock it and thereby be redeemed or spent). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0023] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain, defining a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer to a previous transaction, defining an order for the sequence of transactions (note: the sequence of transactions 152 is allowed to branch). 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 rather than 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 its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to the ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated to not accept any other transactions that attempt to consume the same output.

[0025] For a given current transaction 152j, the (or each) input contains a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of a financial asset, although that is certainly one common use. More generally, consuming may be described as consuming an output or allocating it to one or more outputs in another, further transaction. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. A preceding 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 preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to a preceding element in a logical sequence linked by a pointer, not necessarily at the time of creation or transmission in the temporal sequence, and thus does not necessarily preclude a transaction 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i can equally be referred to as a previous transaction or a preceding transaction.

[0026] The input of the current transaction 152j also includes an input 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. The current transaction 152j can therefore transfer to the new user or entity 103b the amount defined in the input of the previous transaction 152i as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction can 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 output-based transaction protocols such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to establish a new transaction 152j (either manually or through an automated process employed by the party), the establishing party transmits the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately transmits this transaction to one or more 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 party 103 establishing a new transaction 152j transmits this transaction directly to one or more blockchain nodes 104 and, in some instances, does not transmit it 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 typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that the 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 previous transaction 152i that the new transaction consumes (or "allocates"), which condition typically includes at least checking that the cryptographic signature or other authorization in 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. This condition may be defined at least in part by a script included in the output of the previous transaction 152i.Alternatively, it may simply be modified by the blockchain node protocol, or it may result from a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same blockchain node protocol and applying the same tests, 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 the output-based model, the definition of whether a given output (e.g., a UTXO) has been allocated (or "spent") is whether it has already been validly redeemed by an input of another, further transaction 152j, according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated due to a warning) or recorded in the blockchain 150. This protects against double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Again, because there is a defined order of transactions, the account balance has a single defined state at any given time.

[0029] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions in a process commonly referred to as mining, supported by "proof of work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition could be that the hash output has a certain predefined number of leading zeros. 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 an input. Therefore, this search can only be performed by brute force, thus consuming a substantial amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0030] The first blockchain node 104 to solve the puzzle publishes it to the network 106, providing the solution as a proof that can be easily checked by other blockchain nodes 104 in the network (given the hash solution, it is easy to check that it matches the hash output). The first blockchain node 104 propagates the block to a threshold consensus of other nodes, who accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n, pointing to a previously created block 151n-1 in the chain. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, indicates the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0031] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that have not yet been published at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. Blockchain nodes 104 then compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving any "forks" that may occur, which is when two blockchain nodes 104 solve the puzzle within such a short time of each other that opposing views of the blockchain are propagated between the nodes 104. In essence, whichever branch of the fork grows the longest becomes the definitive blockchain 150. Note that this should not affect users or agents of the network when 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 accepted 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 to another). This special type of transaction is typically referred to as a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” It typically forms the first transaction of a new block 151n. The proof of work indicates the node constructing the new block’s intent to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a redemption period, e.g., 100 blocks, before this special transaction can be redeemed. 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 typically referred to as a “transaction fee” and is described below.

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

[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 one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any activity 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] Also connected to the network 101 are computing devices 102 for each of a number of participants 103 who act as consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some participants may act as storage entities that store copies of the blockchain 150 (e.g., obtaining copies of the blockchain from blockchain nodes 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 referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the necessary roles of blockchain nodes. Instead, each participant 103 interacts with the blockchain network 106 by connecting to (i.e., communicating with) a blockchain node 106, thereby utilizing the blockchain 150. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that many more such participants 103 and their respective computer devices 102 may exist and participate in the system 100, but are not illustrated for convenience. Each participant 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0037] The computing device 102 of each participant 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing device 102 of each participant 103 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. 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 on the computing device 102 of each participant 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing device. It will be understood that any activity attributed to a given participant 103 herein may be performed using software executing on the processing device of the respective computing device 102. The computing device 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 network-connected resources, such as cloud computing resources accessed via a user terminal.

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

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

[0040] NOTE: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead any client function described herein may instead be implemented as a set of two or more different applications, for example, interfaced via an API or plugged into one another. More generally, client functions may also be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following description will be given with respect to 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 operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or indeed to inspect the transactions of other parties in the blockchain 150, since in embodiments the blockchain 150 is a public facility that provides trust in transactions, in part through its public visibility). The wallet functionality on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward the transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol goes hand in hand with a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0042] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from 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 most connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable per transaction via a script included in the transaction 152. Alternatively, this condition could simply be a built-in feature of the node protocol or be 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., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 further to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, then, assuming the transaction 152j is valid, this means that it will quickly propagate throughout the network 106.

[0044] After being admitted into the ordered pool of pending transactions 154 maintained by a given blockchain node 104, that blockchain node 104 begins a race to solve a proof-of-work puzzle with the latest version of each pool 154 that contains the new transaction 152. (Remember, other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions 154, but whoever gets there first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) After proof-of-work has been done for the pool 154 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 contains a pointer to the previous transaction, so the order of the transactions is also immutably recorded.

[0045] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is "valid," with one instance being published in a new block 151, before 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 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 it originally accepted (i.e., the one not published in block 151).

[0046] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the transfer amount not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing an absolute account balance. 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 the "position"). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may refer to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0047] 2. UTXO-based Model Figure 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 limited to all possible embodiments. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but may equally be implemented on other exemplary blockchain networks.

[0048] In the UTXO-based model, each transaction (“Tx”) 152 comprises 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) that can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which it 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 embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0049] For example, Alice 103a wants to create transaction 152j to transfer an amount of digital assets of interest to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of digital assets locked for Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could also refer to any preceding (i.e., previous) transaction that still has unspent outputs 203 locked for Alice.

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

[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 validated and therefore the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines unlocking conditions, including a condition that the unlocking script in 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 fragment 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 in blockchain networks. A lock script specifies the information needed to consume a transaction output 203, for example, Alice's signature requirements. An unlock script appears within a transaction's output. An unlock script (aka scriptSig) is a fragment of code written in a domain-specific language that provides the information needed to satisfy the lock script's criteria. For example, this could include Bob's signature. An unlock script appears within a transaction's input 202.

[0053] Thus, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Requires a lock script [Checksig P A ] is equipped. [Checksig P A] is Alice's public key P from her public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer to Tx1 (e.g., using 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 distinguish it from any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that contains Alice's cryptographic signature, created by Alice applying the 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 the lock script, or by the node protocol, or by a combination of these.

[0054] When new transaction Tx1 arrives at blockchain node 104, the node applies its node protocol, which involves running the lock script and unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts as follows: <Sig P A > <P A > || [Checksig P A ] where "||" denotes concatenation, "<...>" means putting data on the stack, and "[...]" is a function composed by the lock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. Athat the unlock script in the input of Tx1 contains Alice's signature, signing the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data includes the entirety of Tx1 (and thus there is no need to include a separate element specifying the signed portion of the data in plaintext, 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, given 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, so that anyone holding the public key can authenticate the signature. Thus, it should be noted that references herein to signing a particular data portion, transaction portion, etc., can, in embodiments, mean signing a hash of that data portion or transaction portion.

[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 and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby propagating throughout the network 106. After Tx1 is validated and entered into the blockchain 150, it defines Tx0 to UTXO0 as spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, a blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on transactions 152. Indeed, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 have been spent in which transactions 152, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0057] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another criterion for invalidity in most transaction models. Therefore, such a transaction will not be propagated and will not be included in block 151.

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

[0059] In practice, Alice is typically required to include a fee for any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 will be rejected by the blockchain node 104 and, thus, while technically valid, will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept the transaction 152 if they do not wish to do so). 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 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, a pointer to UTXO0 is only an input to Tx1, which has only one output, UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or consumed) by the node 104 that won 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 the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the responsibility of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, further transaction. This can be done by querying a copy of the blockchain 150, such as that stored in one of the Bitcoin nodes 104.

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

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

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

[0064] 3. Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 102b may each include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 allows for the exchange of data away from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively, or in addition, 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 in addition, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, a side channel 107 referenced anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data “off-chain,” i.e., separate from the blockchain network 106. When multiple links are used, the bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data or the like over a side channel 107, this does not necessarily imply that all pieces of this data must be transmitted over the exact same link or the same type of network.

[0066] 4. SHA2 Hash SHA2 is

[0067]

number

[0068] message

[0069]

number

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

[0071]

number

[0072] The length of the digest 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 steps. First,

[0074]

number

[0075] The message M is divided into N blocks of fixed size m. For this, 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 1 to the end of M, followed by k zeros. Then,

[0079]

number

[0080] Add a block, which

[0081]

number

[0082] The result of padding is the addition of at most one extra block.

[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 the compression function CF m,d :{0,1} m x{0,1} d ->{0,1} d is applied iteratively on the input to the message block and the previous compression value. The first compression value is the initialization vector IV, which is set to a specific d-bit constant 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 following table provides the parameters for the SHA256 and SHA512 functions.

[0089] [Table 1]

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

[0091] The associated NP relation R is given by the instance / witness pairs that we allow program P to accept, and is as follows: R:={(x,w)|P(x,w)=1}

[0092] A concise non-interactive proof of knowledge system (SNARK) preprocessing for the correct execution of a program P is the algorithmic triplet SNARK:=(Gen, Prove, Verify), as follows: Gen(λ,P)→(pk,vk): Takes security parameters λ and a description of program P as input and outputs a pair of proof and verification keys. Prove(pk, x, w) → π: Takes the proof key, public input x, and secret input w as input and outputs the proof π. Verify(vk, x, π) → b∈{0,1}: Given a verification key, a public input x, and a proof π, either accept or reject 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 on an input pair (x, w) of public / private inputs that a program P would accept. It is sound if, for all public inputs x that do not have a secret input w that P would accept, the verifier rejects with very high probability any proof π for x. Additionally, a proof is said to be knowledge-sound if it is possible (within negligible error—knowledge error) to efficiently compute (extract) a witness from a valid proof π and the randomness used by the (potentially cheating) prover to generate π. A proof π is zero-knowledge if it reveals no information about w.

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

[0095] 5.2 Proven Data Proven Data (PCD) schemes provide a means for proving the integrity, or correctness, of dynamic computations distributed among nodes that may not trust each other. They differ from multi-party computation protocols in two key respects: the number of nodes is not fixed, and privacy of the computation is not an issue. The latter allows PCD to be more lightweight (no node communication overhead).

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

[0097]

number

[0098] , output 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 computational transcript is a triplet T:=(G, TYPE, LOC, PAYLOAD): G=(V,E) is a directed cyclic graph TYPE:

[0102]

number

[0103] is a node label (the compliance predicate to which the node conforms). LOC:V→{0,1} * is the labeling of another node (local data). PAYLOAD:E→{0,1} * are edge labels (data flows to and from nodes).

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

[0105] Conformance of transcripts and outputs. A vector of conformance predicates is

[0106]

number

[0107] Let Transcript T be

[0108]

number

[0109] is true if the following holds: i. Let s∈V. 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 input message to v,

[0112]

number

[0113] is the output message,

[0114]

Number

[0115] Take it as local data. Then

[0116]

Number

[0117] it will be. (Therefore, the node must conform to the predicates given by its type.)

[0118] Message z is

[0119]

Number

[0120] is because there exists a transcript T such that z ∈ out(T)

[0121]

Number

[0122] a transcript T exists.

[0123] Figure 3 shows a schematic of a computational transcript for the 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 one intermediate node 304. All non-source nodes 304, 306 enforce different compliance predicates for the inputs and outputs. The “+”-node (intermediate node 304) is allowed to introduce a bounded noise addition ||e||2 < B as local data for its computation.

[0124] 5.2.2 Preprocessing PCD Syntax. The preprocessing PCD scheme is a triple of algorithms

[0125]

number

[0126] and the generator

[0127]

number

[0128] is a referential 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] receives data z as input in and a proof that proves compliance of the parent node (provided it is a non-source node)

[0133]

number

[0134] , local data z loc , and the output data z out Receive and certify

[0135]

number

[0136] Generate a verifier.

[0137]

number

[0138] takes as input the output data and a proof, and either approves or rejects it. Typically, PCDs are built from succinct zero-knowledge proof systems (SNARKs) that can be run recursively. Existing schemes suitable for recursion are presented and compared in Section 8.1.

[0139] Security (knowledge integrity). Output data

[0140]

number

[0141] A set of proofs for

[0142]

number

[0143] If accepted, the output (sink) node outputs the data

[0144]

number

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

[0146]

number

[0147] Computational transcript T (and

[0148]

number

[0149] ) exists. Therefore, the output proof set

[0150]

number

[0151] demonstrates compliance of the entire computational transcript.

[0152] 6. Scalable SNARKs for Hash-Based Statements 6.1 Knowledge of an Arbitrarily Large SHA2 Preimage SNARKs are based on the following NP relation:

[0153]

number

[0154] is defined as:

[0155] therefore,

[0156]

number

[0157] Knowledge of the preimage M (secret input) is sufficient for a given public digest H and length

[0158]

number

[0159] This relationship is proved for the digest size d, block size m, and maximum message length

[0160]

number

[0161] , and is parameterized by the initialization vector IV, which is implicitly used in the evaluation of the SHA2 function.

[0162] 6.1.1 Computational Transcript The SHA2 evaluation can be seen as a transcript of a dynamic computation. The i-th node takes as input the current iteration counter i-1 and the current state H (i-1) , which is also referred to as 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

[0163]

number

[0164] Using the last block M (N) Pad and H (N) Output.

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

[0166] A message M is a sequence of message blocks M (i) To, M:=(M (1) ||...||M (N) ) and padding block M '(N) If necessary, M '(N) :=pad(M (N) ) is defined by

[0167] Digest H is H=SHAd(M) is defined as:

[0168] The message M is referred to herein as a preimage, and the message block M (i) may be referred to as a pre-image block.

[0169] 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.

[0170] 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 takes as input the current state H (i-1) and apply the compression function to the next state H (i) They also take as input the current iteration counter i-1 and increment it to calculate the next iteration counter i.

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

[0172] In this way, each of the nodes 402, 304, 306 performs a single iteration of the compression function. This allows proofs to be generated iteratively, which reduces the computational requirements of the prover, improving the efficiency of the process and allowing proofs for arbitrarily large messages to be generated. The output of the final node 306 is the digest H and a preimage proof π, which, 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.

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

[0174] The first node 402 performs an initialization check to check that the received initialization vector IV, received as part of the input, is correct. The received initialization vector is used to determine the current state for the first node 402, i.e., H (0) The received initialization vector IV may be referred to as IV = IV. The received initialization vector IV is compared to 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 initial node 302. The initial node 302 may determine whether the current iteration counter received at the initial node 302 has the initial iteration count value, i.e., i in = 0. In some embodiments, the initial iteration count value may be 1.

[0175] The last node 306 performs a padding check: if the preimage fits into N m-bit blocks, the last node 306 checks the last block M (N) of

[0176]

number

[0177] --so the padding length k+1 is

[0178]

number

[0179] where m is the block length and N-1 is the input iteration counter for the final node 306. Here, b is either 0 or 1. If b=1, there are no extra blocks when padding is used, i.e., the message M is 1 bits long.

[0180]

number

[0181] which has a maximum bit length

[0182]

number

[0183] If the above formula is satisfied, we say that the padding condition is met.

[0184] To perform the padding check, the final node 306 takes as input:

[0185]

number

[0186] , b, and / or k, and the received value is the expression

[0187]

number

[0188] It can be checked that

[0189] Extra padding blocks are required if the required padding does not fit into the final message block. This is because the message length

[0190]

number

[0191] is the message length

[0192]

number

[0193] or if the message length padding bits do not fit into the last message block.

[0194] If extra padding blocks are needed, the final node 306 also receives padding blocks, also referred to as padding preimage 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 again executes the compression function, but this time receiving 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 is evaluated correctly. The proof generated by the final node 306 establishes that both instances of the compression function are evaluated correctly.

[0195] Instead, 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.

[0196] The final node 306 is the final l maxCheck that the bits are the binary representation of l. The definition of M depends on whether padding has been added, as described below. That is, if no final block has been added, the slice of bits to be checked is

[0197]

number

[0198] , but the final block has been added, the bit checked is

[0199]

number

[0200] It's somewhere in there.

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

[0202] Note that SHA2 always adds some extra bits (called padding) to the end of the message. The difference is in which block the padding check is enforced. The last block containing bits of the message is

[0203]

number

[0204] If (i) the padding is a block

[0205]

number

[0206] Either (i) the padding will fit completely in the

[0207]

number

[0208] In case (ii), padding is forced in M', whereas in case (ii), padding is forced in M'.

[0209] 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—Φ, as described below. pad Step 2 of the procedure, which may involve generating an extra padding block containing the padding information. The final node 306 then applies the compression function to the last message block and any extra padding blocks. 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 bit b, which indicates whether an extra block containing purely padding information was generated and passed through the compression function.

[0210] An intermediate state node 304 can only receive input from another intermediate state node 304 or an initial 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 illustrated in FIG.

[0211] The predicate captures these constraints.

[0212]

number

[0213] The internal gadget Φ is defined asIV , Φ eval , Φ pad is stated below.

[0214] initNode402Compliant(Type1). Pi init (z in ,z loc ,z out ): 1. z in .payload as counter and state

[0215]

number

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

[0217]

number

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

[0219]

number

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

[0221]

number

[0222] / / See Figure 4. 6.

[0223]

number

[0224] Check that it is accepted. 7. If all three checks pass, output "accept", otherwise output "reject".

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

[0226]

number

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

[0228]

number

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

[0230]

number

[0231] Parse as 4.z in Check that .type∈{1,2}. 5.

[0232]

number

[0233] Check that it is accepted. 6. If these two checks pass, output "accept", otherwise output "reject".

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

[0235]

number

[0236] 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.

[0237]

number

[0238] Parse as 3.z out .payload to the last state

[0239]

number

[0240] and message length

[0241]

number

[0242] Parse as 4.z in Check that .type∈{0,1,2}. 5. If z_in.type=0,

[0243]

number

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

[0245]

number

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

[0247]

number

[0248] is accepted b.

[0249]

number

[0250] is accepted 8.

[0251]

number

[0252] Check that it is accepted.

[0253] If all checks pass, it outputs "accept", otherwise it outputs "reject".

[0254] The following table shows

[0255]

number

[0256] The gadgets used internally by the RFC 2 ...

[0257]

number

[0258] , and the initialization vector IV are hard-coded in the description.

[0259] [Table 2]

[0260] 6.1.3 SNARK

[0261]

number

[0262] Please leave a message

[0263]

number

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

[0265] Gen preim (λ,CF SHA2 ) → (pk,vk). This takes as input a security parameter λ and a description of the SHA2 compression function CF SHA2 Receive the proof key pk(CF SHA2 ) and verification key vk(CF SHA2 output (including a brief summary of the

[0266] Prove preim (pk,(H,M))→π SHA2 It takes as input a proof key pk and a pair (H,M)∈R SHA2 and a concise proof π SHA2 Steps: 1.

[0267]

number

[0268] A message M is divided into N blocks M each of m bits. (i) Divide k+1 into M (N) The padding length is 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) ) is set ii. If i < N, z loc := M (i) and z out .payload = (i, H (i) ) are set / / Type 1 or Type 2 node (non - digest) iii. Otherwise, if i = N, z loc := (M (i) , M', H, i,, k, b) and

[0269]

Number

[0270] is set c. Set the node type: i. If i = 1 & N ≥ 2, z in .type = 0 and z out .type = 1 are set / / Init node ii. If i = 2 & N ≥ 3, z in .type = 1 and z out .type = 2 are set: / / First intermediate state node iii. If N > i > 2 & N ≥ 3, z in .type = 2 and z out .type = 2 are set: / / Remaining intermediate state nodes iv. If i = N & N ≥ 3, z in .type = 2 and z out .type = 3 are set / / Digest node (including input from intermediate state nodes) iv. If i = 2 & N = 2, z in .type = 1 and z out .type = 3 are set: / / Digest node (including input from source node) vi. If i = 1 & N = 1, z in .type = 0 and zout Set .type=3 / / Digest node (contains input from source node) vii. pk to pk SHA2PCD Interpreted as

[0271]

number

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

[0273] 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.

[0274] Verify preim (H,π SHA2 ,vk) → {"accept","reject"}, which takes as input a verification key vk, a digest H, and a proof π SHA2 , and accept or reject the proof. Acceptance indicates 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.

[0275]

number

[0276] If it is accepted, it outputs "accept". Otherwise it outputs "reject".

[0277] FIG. 6 illustrates an exemplary method for a prover 602 to prove knowledge of a preimage M without revealing the preimage to a verifier 604 .

[0278] 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 the proof key pk to the prover 602 in step 2 or makes it available in some other way.

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

[0280] In step 4, the prover 602 iterates through the compression function, generating for each iteration a corresponding proof that the compression function executed correctly. Each iteration is performed 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.

[0281] The prover 602 provides the verifier, in step 6, with the preimage proof generated by the final node 306, which is the message digest H, and the next state. The verifier 604 then uses the received preimage proof and digest, as well as the verifier key, to verify the next state. preim to verify that the proof is valid for the digest, and therefore verify that the prover 602 has knowledge of the message M.

[0282] Although shown as a single entity, it will be understood that the prover 602 may comprise 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.

[0283] 6.2 Patterns in SHA2 preimages The methods described above can be modified to prove the presence 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 methods described below provide a way to prove any bit pattern in the preimage M of a digest d and verify a coercion knowing only d and not M.

[0284] 6.2.1 Patterns We start by defining how to view patterns and how to compute a short description (summary) of the pattern.

[0285] Pattern P consists of two

[0286]

number

[0287] Vector

[0288]

number

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

[0290]

number

[0291] Column M is bit C i Whenever M = 1 i =P i The pattern matches if P = 0. The vector P can take any value for the bits that are not checked, for example, set all non-checked bits of P to zero. That is, the check bit vector C defines which bits of the message are checked, i.e., compared to the pattern vector P.

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

[0293]

number

[0294] ,N,m,

[0295]

number

[0296] Let Hash be an integer such that: Hash:{0,1} 2m+k →{0,1} k Let be a collision-resistant hash function.

[0297]

number

[0298] P is

[0299]

number

[0300] Vector Pair

[0301]

number

[0302] is.

[0303]

number

[0304] C j = 1, then i j The pth bit j Let be an Nm-bit array divided into m-bit blocks obtained from P by setting P to zero otherwise. Similarly,

[0305]

number

[0306] is the result of dividing C into m-bit blocks and padding the last block with zeros if necessary. (0) Let be any k-bit string. The summary of P is

[0307]

number

[0308] k-bit string Summary(P):=S∈{0,1} k is.

[0309] In this specification,

[0310]

number

[0311] is a series of bit pattern array blocks

[0312]

number

[0313] As used herein, the bit pattern array may be referred to as a bit pattern array including:

[0314]

number

[0315] is a series of check bit array blocks

[0316]

number

[0317] The check bit sequence may be referred to as a check bit sequence.

[0318] Note: As with SHA2, the construction of a digest S follows the Merkle-Dangard construction. Therefore, the i-th intermediate state S of the 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) )

[0319] 6.2.3 Statements The methods provided herein comprise the statement "Let (H,P), then H is the digest of a message M consistent with pattern P" Prove that.

[0320] More formally, in this specification, the relation R SHA2pattern:={((H,P:=(P,C);M) | H=SHA2 d,m,IV (M)∧M i =P i if C i A proof system is provided to prove instances (H,P) of {H = 1}. The length of the preimage M is

[0321]

number

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

[0323] 6.2.4 Calculation Transcript and Compliance Substituting Patterns with Abstracts to Prove Variable-Length Statements. The basic PCD scheme defined here is suitable for use with pattern abstracts instead of dealing with the full description P. To enforce a pattern P on the i-th message block of a SHA2 preimage, we use the i-th vector P of P. (i) , C (i) Note that only P (i) , N (i) To ensure that is part of the original public pattern P, the previous message block must be coerced against the previous vector of P (and not against some other pattern).

[0324] To do so, all i-1 preceding vectors of P can be passed as input to a conformance predicate and output for the next iteration. However, this method requires as many conformance predicates as N (each of them taking inputs of different lengths), and preimages of different lengths require different numbers of conformance predicates. The latter means that the same SNARK can be used to prove patterns on any two preimages. pattern This means that it will not be possible to use the scheme.

[0325] To overcome this problem, the i-1 intermediate state of the summary is passed to check the consistency of the preceding pattern block to force the correct generation of the next summary state. (i) It turns out that has a fixed length k, and therefore a single reference predicate is sufficient.

[0326] The actual structure. The transcript for checking patterns is defined in a similar way to the SHA2 preimage (see Section 6.1.2). The difference is the constraint predicate

[0327]

number

[0328] in the internals as well as edge and node data. Specifically: The i-th node (iteration) has the following local data:

[0329]

number

[0330] and

[0331]

number

[0332] , which joins in receiving the i-th message block.

[0333]

number

[0334] Furthermore, the edge message (output data) will contain the i-th intermediate state of the summary, which will be added to the i-th intermediate state of the SHA2 digest and the iteration counter. Therefore, z in :=(iin ,H in ,S in ) and z out :=(i out ,H out ,S out ) Predicates from Section 6.1.2

[0335]

number

[0336] Internal subroutine Φ eval The call to is made to the subroutine Φ defined below. pattern is replaced by a call to the subroutine Φ eval is the subroutine Φ pattern Note that this is performed as one of the steps.

[0337] The following table shows

[0338]

number

[0339] Presents a predicate used internally as a subroutine to ensure pattern consistency.

[0340]

number

[0341] ,

[0342]

number

[0343] is calculated according to Definition 1.

[0344] [Table 3]

[0345] That is, each node 304, 306, 402 is configured to perform the pattern checks as well as the compression function checks described above.

[0346] Each node receives as additional input a bit pattern array block and a check bit array block corresponding to the block. 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.

[0347] 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.

[0348] Φ pattern Optimize the size of . A zero-knowledge friendly hash function Hash can be used to compute the pattern summary. This is based on the conformance predicate

[0349]

number

[0350] The size and

[0351]

number

[0352] For example, the Pedersen hash has an R1CS of 2753 constraints. Poseidon has 316 constraints. The downside is that cryptanalysis research on these new constructions has been slower than on the SHA2 compression function.

[0353] 6.2.5 SNARK

[0354]

number

[0355] Please leave a message

[0356]

number

[0357] The SNARK proof system is a PCD scheme that proves pattern :=(Gen pattern ,Prove pattern ,Verify pattern ) is defined similarly to the preimage proof system described earlier.

[0358] The verifier 604 generates a proof key and a verification key as described above. 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.

[0359] The output provided by the final node 306 of the transcript is the final state H (N) (Digest H), Final Summary S (N) (Pattern Summary(P)), and Pattern Proof π pattern This is provided to the verifier 604, which verifies the pattern proof based on z out .payload=(H,Summary(P)), and the verifier 604

[0360]

number

[0361] Run z out A given proof π for out Validate the

[0362] 6.3 Merkle Tree Statements Let L be an NP language. The following method is "Let H be a byte array 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" provides a method for proving Therefore, statements about all leaves can be proven.

[0363] Proving a Merkle tree statement by sending leaves is inefficient: first the tree needs to be constructed to perform the check against a given root, and then 2 e The proof of the base relation R b (one for each leaf). For example, for a tree that stores 1 million leaves of 1MB each, at least 1TB (consisting of only the leaf data, not including the proofs) would need to be transmitted, which is inefficient and may not be possible. The situation is similar for smaller trees that store larger datasets.

[0364] More formally, the relation R for leaves b Given, the relation

[0365]

number

[0366] A concise proof system for

[0367] Variable-length statements. The depth e of the tree is not specified by the relation, but is instead part of the instance. Thus,

[0368]

number

[0369] contains a Merkle tree of arbitrary depth, which can then be used in the SNARK proof system described below. merkle But the base relation R b This means that we can prove arbitrarily many instances of

[0370] 6.3.1 Bootstrapping from leaf relations to a Merkle tree All base relationships R b Leaf is an instance of

[0371]

number

[0372] Starting with, enter

[0373]

number

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

[0375]

number

[0376] A valid proof of the truth of b This is

[0377]

number

[0378] This means that the complexity of a SNARK prover for depends only on the complexity of the base SNARK verifier and Hash.

[0379] Remark 1. In the approach presented here, the leaf proof π b Separately, the base relation is predicate vector

[0380]

number

[0381] Assuming we have a PCD scheme containing

[0382]

number

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

[0384] Note 2. Receive the verification key vk as input and prove π b Verify the base relation R b A preprocessing (simple) verifier for the relation

[0385]

number

[0386] SNARKs for

[0387] R b Verification key for

[0388]

number

[0389] teeth,

[0390]

number

[0391] It is hard-coded in the description of R b The SNARK verifier's knowledge soundness is

[0392]

number

[0393] If so, there is a high probability

[0394]

number

[0395] This means that we can extract witnesses from proofs that are valid with high probability.

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

[0397]

number

[0398] is defined as:

[0399] 7 presents an example Merkle tree 700 as described herein. The Merkle tree 700 includes four leaves 702, each of which defines leaf data, which are referred to herein as data blocks L i and the corresponding data block proof π i The Merkle tree 700 comprises four leaf hash values ​​to which four leaf nodes 704 are respectively mapped, with each leaf node 704 having an associated leaf 702 and configured to receive block data and data block proofs from the associated leaf 702. The Merkle tree 700 further comprises inner hashes to which inner nodes 706 are mapped. The nodes 704, 706 mapped in the Merkle tree 700 are arranged in layers, with each layer receiving as input the output produced by a pair of nodes 702, 704 from the previous layer.

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

[0401] Each leaf node 704 has a corresponding data block L i and its associated data proof π 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 )

[0402] The inner nodes 706 in the first tier of inner nodes 706 each receive the data block hashes generated by two of the leaf nodes 704. These inner nodes 706 generate hashes of the data block hashes, referred to herein as output hashes, which are then provided to the inner nodes 706 in the next tier of inner nodes 706.

[0403] This process is repeated, with each inner node 706 receiving the two hash values ​​generated by the inner nodes 706 in the previous layer, and terminating with the final inner node 706 a, arranged in the final layer of nodes 704, 706 mapped into the Merkle tree 700, generating a hash value that becomes the Merkle root of the Merkle tree 700.

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

[0405] Each leaf node 704 receives a data block L i Data proof associated with π 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 data block L i is a leaf of the Merkle tree 700, and that the data block itself meets the predefined criteria.

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

[0407] In a manner similar to generating an output hash, each leaf node 706 in each subsequent layer receives as input two output proofs generated by an inner node 706 in the previous layer that correspond to the received hash. Each inner 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 meets the criteria.

[0408] 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 may be referred to herein as a Merkle tree proof for Merkle tree 700.

[0409] 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 proof are transmitted between computing devices to generate the Merkle tree proof and Merkle root. The code defining the Merkle tree may be divided into several parts, each part defining one of the nodes 704, 706 of the Merkle tree 700, and each computing device storing and executing one or more parts of the code, corresponding to the nodes 704, 706 being executed by the computing device.

[0410] Leaf node 704 (type 1). The leaf node 704 is a node for data L∈{0,1} 2k and statement

[0411]

number

[0412] Data proof for π b Enter z in and calculate the leaf hash H:=Hash(L) and z out:=(H,0). If L has m<2k bits, pad it on the right with 2k-m zeros before hashing. All these checks are performed using the predicate Π leaf Specifically, π b The validity of is enforced by the SNARK verifier's circuit against the base relation (the verification key is hard-coded in the circuit), and the correctness of H is enforced by the circuit against Hash.

[0413] Inner node 706 (type 2). Inner node 706 has two inputs

[0414]

number

[0415] and

[0416]

number

[0417] where e≧1 represents the depth of the inner 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 inner node 704 in the previous layer. All these checks are performed using the predicate Π inner is encoded as

[0418] Hashing of leaf data whose size is > 2k. The size of the hash is fixed at 2k. Leaf L i If has a size > k, then it can be double hashed.

[0419]

number

[0420] Hash var is set to a cryptographic hash that allows incremental proof of knowledge of the preimage (e.g., SHA2 with the SNARK from Section 6.1.3). i The statement "Given public

[0421]

number

[0422] there exists L i ,w i such that

[0423]

number

[0424] and (L i ,w i )∈R b .'. The leaf data are not necessarily of the same size, |L i |≠|L j Please note that |

[0425] Hash Function Selection. As in the case of verifying patterns in SHA2 preimages, a zk-friendly hash function, such as Pedersen hash or Poseidon, can be used in Merkle tree construction. It will be understood that any hash function can be used.

[0426] 6.3.3 SNARK Proof System

[0427]

number

[0428] The output (H, e) is

[0429]

number

[0430] This is a PCD scheme that proves that (G b ,P b ,V b ) is the base SNARK verifier.

[0431]

number

[0432] The SNARK proof system for merkle := (Gen_merkle, Prove_merkle, Verify_merkle) is.

[0433]

number

[0434] : 1. Base SNARK(pk b ,vk b ):=G b (λ,R b ) to generate a key 2. Merkle Tree PCD

[0435]

number

[0436] Generate a key for / / predicate

[0437]

number

[0438] is the base verification key vk hardcoded in b It has. 3. pk:=(pk pcd ,pk b ),vk:=vk pcd Output

[0439]

number

[0440] : 1. pk:=(pk pcd ,pk b ) 2. i=1 to 2 e Regarding π b,i :=P b (pk b ,L i ,w i ) / / Offline prover 3. Compute the output proof for the leaf nodes, i=1 to 2 e Do the following about : / / Total 2 e leaf nodes. a.L i ,π b,i The leaf relation R b Let the i-th leaf data and valid proof for z in,i .payload:=(L i ,π b,i ), and z in,i Set .type=0 (source node). b.

[0441]

number

[0442] and the output node is z out,i .

[0443]

number

[0444] and z out,i Set .type=0 (leaf node). c. Output Proof

[0445]

number

[0446] Calculate. 4. Compute the output proofs of the inner nodes. Repeat for d=1,…,e / / from layer d-1 to layer d. a. As input, input / proof 2 e-(d-1) Pairs of pieces

[0447]

number

[0448] receive b.2 e-d Node output payload

[0449]

number

[0450] take / /

[0451]

number

[0452] Note that c. k=1 to 2 e-d For: i. Input data

[0453]

number

[0454] The type of the input node is 1 (leaf node) if d=1, otherwise the type is 2 (inner node). ii. Input proof

[0455]

number

[0456] Set to. iii.

[0457]

number

[0458] Set. iv. Proof of Output

[0459]

number

[0460] Calculate. d.

[0461]

number

[0462] Output.

[0463] Verify merkle (vk,(H,e),π merkle ) → {"accept","reject"}, which takes as input a verification key vk, a digest and the tree depth (H, e), and a proof π merkle Acceptance is when H receives R b means that ∑ i is the root of a Merkle tree of depth e that has leaves that are instances of ∑ i . Steps: 1. vk to vk pcd interpret as 2.z out.type:=2 (inner node) and z out Set .payload:=(H,e). 3.

[0464]

number

[0465] If accepted, it outputs "accept". Otherwise, it outputs "reject".

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

[0467] In step 1, the verifier 604 determines the proof key pk against the criteria that the leaf data must satisfy. 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.

[0468] 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 satisfies the pattern criteria and therefore a proof can be generated.

[0469] 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 proof of the Merkle tree, as generated by the final node 706a.

[0470] 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 satisfied that the data blocks used by the Prover 602 to generate the Merkle root and Merkle tree proof meet the pattern criteria.

[0471] 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.

[0472] 6.3.4 Proof aggregation and universal trees The above design has two important properties.

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

[0474]

number

[0475] are merged, and the proof π'' for (H'':=Hash(H,H'),e+1) merkle But PCD certifier

[0476]

number

[0477] can be generated with a single call. Note that H'' has 2 e+1 leaves that are the root of the Merkle tree in the base relation R b . If the trees have different depths, i.e., e < e', the smaller tree is replicated with 2 e'-e dummy leaves, thereby generating an extended tree of depth e' with root H replicated such that both proofs can be merged. The correct extension of the smaller tree can also be proven incrementally.

[0478] Prove any base relation. The relation

[0479]

Number

[0480] is the verification key for a specific relation R that is hard-coded as part of its description b for the relation R

[0481]

Number

[0482] has. The relation

[0483]

Number

[0484]

[0485] b b

Number

[0486] There exists a public procedure specialization that generates vk. Therefore, the universal vk is hard-coded in the circuit,

[0487]

number

[0488] The correct specialization to can be proved as a circuit gadget, which is a circuit-specific verification key

[0489]

number

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

[0491]

number

[0492] is.

[0493] This therefore eliminates the need for the verification key to change when the circuit is changed.

[0494] 6.4 Possible Modifications Patterns of intermediate hash states. The idea from Section 6.2 is that the intermediate state H (i) can be used to prove a pattern in the (inner) reference predicate Φ of the i-th node. midstatePattern is the intermediate output state H (i) with the pattern P. In particular, for a given d-bit string H mid It can be proved that is the i-th intermediate state of a given digest H.

[0495] Proof of keyword search or proof that a sequence does not appear in the preimage. It is possible to show that a given short sequence S of at most m bits appears (or does not appear) in some SHA2 message blocks. The idea for a conformance predicate is to right-shift the sequence S by one bit mp times 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 unknown size identifier TxID is a P2PKH transaction that matches the pattern of a P2PKH script (4 bytes), or to prove that the transaction serialization does not contain embedded data indicating the presence of the 2-byte sequence "OP_FALSE OP_RETURN".

[0496] Variable-size Merkle tree proofs. Given public (H,e,L,i), I know an authentication path app proving that L is the i-th leave of a Merkle tree with root H and depth e. Furthermore, I know a witness w such that L is an instance of R b " statements can also be considered. Similar to the Merkle tree statement from Section 6.4, the secret authentication path is variable-sized. This means that accounts may be used in zk-rollup that are leaves of the Merkle tree, and transfers of accounts prove knowledge of the Merkle tree proof. Variable-sized Merkle tree proofs allow zk-rollup to process batches of different sizes (i.e., batch size is independent of the instantiation of the underlying SNARK system).

[0497] The relationship between each leaf depends on its position in the tree. Thus, the i-th leaf and the j-th leaf are in R b,i R b,j are instances of (not necessarily in the same relationship).

[0498] 7. Applications Several exemplary applications for the above-described zero-knowledge proof system are presented. 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. With known methods, proving correct encryption of data requires multiple iterations, which is time- and computationally inefficient and may even be impossible for some data sizes.

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

[0500] 7.1 Scalable Zero-Knowledge Contingent Payments Maxwell's Contingent Payment Scheme. A Zero-Knowledge Contingent Payment Scheme (ZKCP), as known in the art, is implemented in two steps: (1) Buyer Alice specifies the requirements for the data she wants to purchase, saying Φ(data, public)=1. (2) 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 transmitted digest.

[0501] After the buyer verifies the zkSNARK, the seller uses the digest d to set up a hash timelock (HTLC) transaction on the BSV blockchain for the agreed amount. When the seller redeems the funds, they also reveal the symmetric key (a preimage of the digest), allowing the buyer to decrypt the purchased data.

[0502] Real-world use case examples for large datasets include: · Movies in HD format (or lossless format), Complex proprietary software Includes:

[0503] The requirement in both cases is that the SHA256 digest must be some known bit string h * Therefore, Φ(data,h * )=1 iff SHA256(data)=h * is.

[0504] A 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 exactly 1MB of data using a 128-bit block cipher in counter mode, such as AES-CTR, requires 65536 iterations of the block cipher.

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

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

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

[0508]

number

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

[0510] Figure 9 shows

[0511]

number

[0512] The transcript shows an efficient and scalable multi-predicate ZKCP.

[0513]

number

[0514] The source nodes are shown as white circles and the output nodes are shown as black circles. The data is N ), and the resulting ciphertext is ct:=(ct1,...,ct N ) is. i and ct i is an h-bit block, where h is the HKDF and

[0515]

number

[0516] The range of underlying hash functions used in

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

[0518] Reduce the number of output proofs. The 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: i is considered to be the i-th leaf of the Merkle tree, and then the Merkle tree prover from Section 6.3 can be used to prove the correct root generation and that the leaf is well-formed. The verifier generates a root node proof πmerkle , proof π against SHA2 nodes preim , and the ciphertext ct:=(ct1,...,ct N To check the correctness of ct, the verifier regenerates the Merkle root and calculates π merkle This compression also applies when incremental proof data is encrypted with a block cipher.

[0519] An exemplary method for the above application is presented in Figure 10. In the example of Figure 10, a data requester 1004 acts as the verifier 604 and a data provider 1002 acts as the prover 602.

[0520] 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 a proof key 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 key pk to the data requester 1004. The trusted third party may provide the data provider 1002 with a verification key vk, which corresponds 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 obtain information about the data without purchasing it, simply by inspecting the zk proof, which is generated using a flawed proof key provided by the data requester 1004 and does not preserve zero-knowledge.

[0521] The data provider 1002 selects input keying material ikm, derives output keying material okm using HKDF, and in step 2 uses the output keying material to generate a ciphertext ct for the requested data. i The input key material may be referred to herein as a data encryption key.

[0522] It is understood that the data provider 1002 may derive the output key material okm before receiving a data request. The data provider 1002 may also have already derived the ciphertext before the data request, and thus the data provider 1002 stores the ciphertext in memory in association with the data for retrieval when a request for the data is received. Secret information needed to generate the proof may also be stored in association therewith.

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

[0524] 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 the preimage of the SHA2 digest as the symmetric key, and the proof thereby guarantees that the preimages of the ciphertext and the digest match. For example, the proof may be a preimage proof π to prove with zero-knowledge that the input key material i m is the preimage of the digest d. preim and in step 4, we create a Merkle tree proof π to prove that the ciphertext is correctly generated. tree and

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

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

[0527] If the data requester 1004 is satisfied 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 in UTXO to exchange for data. 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 available for storage on the blockchain 150 in step 8.

[0528] To provide the input key material to the data requester 1004, the data provider 1002 generates a key transaction in step 9. This key transaction's unlock script unlocks the funding transaction's UTXO and includes the input key material ikm, which, when executed together with the funding transaction's lock script, verifies that the input key material is a pre-image of the digest. In this way, the data provider 1002 provides the key needed to decrypt the ciphertext when receiving funds for the data. In step 10, the key transaction is stored on the blockchain 150.

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

[0530] 7.2 Fair 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 Constraint Payments (ZKCP) leverages the blockchain as a TTP to enable such fair, private transactions. However, because these exchanges are bilateral, they may not be very practical. An intermediary—a digital marketplace—can bring the two parties together in exchange for a fee.

[0531] Digital Marketplace. The following design of a digital marketplace may be used: 1. The seller generates a two-layer encryption of their data.

[0532]

number

[0533] 2. In addition, the seller must provide a SNARK proof π that verifies the correctness of the outer ciphertext. (sellerID) Therefore, specifically, this proof is outer (In particular, this is the correct encryption of the outer encryption key k outer (ii) the Φ-compliance of the inner encrypted data is for a given predicate Φ; (iii) the outer ciphertext is encrypted with the inner encryption key k inner Ensure that the hash of 3. The marketplace creates its own database of offers from a large number of sellers.

[0534]

number

[0535] This allows us to use the scheme from Section 3.3 to prove the validity of all leaves with a proof π for the Merkle root merkle Generate. 4. The buyer fetches the tree and validates the root this time. 5. The buyer later wishes to purchase N items from seller sellerID. The buyer contacts the seller and expresses their desire to purchase the data items. 6. The seller sends the outer key to the buyer via a private channel.

[0536]

number

[0537] Send (potentially multiple). 7. The buyer decrypts the outer layer of each received ciphertext to obtain N inner ciphertexts and the hashed inner keys.

[0538]

number

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

[0540] Federation of digital markets. Several digital marketplaces can be federated. A single entity, the data aggregator, aggregates the proofs of the Merkle roots of all the markets, as described in Section 6.3. Buyers and sellers only need to verify this single master root and upload / download data from different locations.

[0541] 7.3 Partial deletion and modification of the blockchain A mechanism for proving correct transaction deletions and modifications can use SNARKs to prove that a public pattern appears within the preimage (transaction) of a given TxID (SHA256 digest). However, this proof scheme is not scalable; m proofs must be generated to demonstrate the pattern distributed across each of the transaction's 512-bit blocks, where m is the number of blocks. For a 1MB transaction, this means verifying 16384 proofs.

[0542] 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 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 off.

[0543] 7.4 Efficient Merkle Transactions A transaction identifier, TxID', can be generated by ordering the fields as leaves of a Merkle tree and setting TxID' at 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 a verifier.

[0544] The problem here is again scalability when proving the consistency of the Merkle identifier TxID' and the standard identifier TxID appearing on the chain with zero-knowledge. There are at least as many leaves as there are inputs and outputs of the transaction. Because the number of I / Os varies for each transaction, circuit-specific SNARKs (which are the 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 requires a long time and large area, likely exceeding practical limits.

[0545] The Merkle tree statement algorithm (SNARK) proposed in Section 6.3 allows the integrity of both types of identifiers to be proven in a scalable way. Circuit-specific proof systems (such as Groth16) can be chosen if desired, regardless of the number of I / Os in each transaction. The input proof attached to each of the tree's leaves is a correct SHA2 hash. Here too, it is possible to utilize the scalable scheme from Section 6.1 when dealing with leaf hashes of lock script fields that contain large chunks of OP_RETURN data, for example.

[0546] 8. Further Considerations 8.1 Comparing Recursive SNARKs The following criteria are used to classify existing pre-processing 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. Proof size: small, medium, large. (Smaller is better.) Prover execution time: fast, medium, slow. · Setup: Reliable, updatable, transparent setup. o Trusted: The parties generating the proof and verification keys or Structured Reference Strings (SRS) are in possession of sensitive data whose public disclosure (especially by the prover) would compromise the integrity of the scheme. The trusted setup must be performed in a controlled environment. o Updatable: Anyone can update a Structured Reference String (SRS), which limits the risk of compromising the integrity of the trusted setup, since a single honest updater is sufficient to maintain the integrity (of the proofs generated after an update has been made). Transparent: Untrusted parties can generate the attestation and verification keys or SRS. Post-quantum security: whether the scheme will be secure in the presence of post-quantum computers.

[0547] [Table 4]

[0548] 8.2 PCD from Pairing-Based SNARKs Recursive proof synthesis, or proven data, can be constructed from a base SNARK with a concise verifier (an algorithm whose running time is sublinear in the size of the circuit). Without preprocessing, it is not possible to have concise verification, i.e., the verifier must at some point read the circuit whose correct evaluation is being checked—either at the time of preprocessing or at a later time when an instance of the relation is given. What preprocessing (i.e., an 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 along with the public input of the circuit.

[0549] Note: There are other approaches to constructing PCDs that are not considered here, such as via concise accumulators, or circuits whose description is much smaller than the actual computation.

[0550] 8.2.1 Circuits for Reference Predicates Compute the conformance predicate of a transcript T

[0551]

number

[0552] Each node is a template circuit C i By proving the satisfiability of i This circuit also demonstrates compliance with the predicate Π i is the node data

[0553]

number

[0554] Check that the above holds, which means it is a valid input proof.

[0555]

number

[0556] He also claims the existence of

[0557]

number

[0558] This demonstrates compliance with the

[0559] [Table 5]

[0560] Ensuring Correct Input Compliance How can we ensure that the input conforms to the correct predicate? This is ensured as follows: i. Each referential predicate Π ispecifies what input type is accepted. So this is i':=z in,j The input .type is accepted if it is a subset T in,i ⊆{0,1,…,n} for i'∈T in,i Only if: ii. Template circuit C i The first thing that checks is the output data z out The type of .type is a conforming predicate Π i That is, z out .type=i, which means that input z has a valid proof. in,j But z in,j Circuit C such that .type=i' i' This means that (since the proof is valid)

[0561] Putting both items together, if the input is i'∈T in,i For each predicate Π such that i' where T in,i is the current node predicate Π i The set of allowed input types is specified in

[0562] Actual circuits. For clarity, low-level details have been avoided and many optimizations have been made. In reality, the inputs and logic of the circuits will be slightly different. Importantly, each circuit C i To make the size of C independent of the number of predicates n, i requires checking the inner Merkle tree proof of C i Defining ∑ i = ...

[0563] 8.2.2 Proving Circuit Satisfiability SNARKs on elliptic curve cycles. Each of the above circuits C i For , we propose two preprocessing SNARK schemes (G i,α ,Pi,α ,V i,α ), (G i,β ,P i,β ,V i,β ) is considered. The first scheme (G i,α ,P i,α ,V i,α )teeth,

[0564]

number

[0565] Prove the satisfiability of circuits and elliptic curves

[0566]

number

[0567] Above, but the second scheme (G i,β ,P i,β ,V i,β )teeth

[0568]

number

[0569] Prove the satisfiability of circuits and elliptic curves

[0570]

number

[0571] Above. Notice the cycle pattern: the basis field of the first curve coincides with the scalar field of the second curve, and vice versa.

[0572]

number

[0573] and

[0574]

number

[0575] is.

[0576] Two-step proof generation. The first scheme (G i,α ,P i,α ,V i,α )teeth,

[0577]

number

[0578] Circuit C, which is a circuit i Prove / verify the satisfiability of C i To provide input to, we use input proofs.

[0579]

number

[0580] This is the node's input

[0581]

number

[0582] z in,j is the predicate Π i' According to i':=z in,j Assume that the first prover P i',α is V i',α A proof that can be verified by π α However, π α directly to C i Input to π in,j , but it cannot be used as a verifier V i',α The circuit for

[0583]

number

[0584] Because it is a circuit (V i',α is the first curve

[0585]

number

[0586] We deal with points in the base field

[0587]

number

[0588] Located above,

[0589]

number

[0590] Arithmetic operations

[0591]

number

[0592] (Emulating it in a circuit is expensive.) To overcome this, α Proof that proves the validity of π β is generated (proof of proof). More precisely, the "translation" circuit

[0593]

number

[0594] which is constructed as

[0595]

number

[0596] circuit (first verifier V i',α is the base body

[0597]

number

[0598] (Because it is above), the second prover P i',β Using

[0599]

number

[0600] Proof of satisfiability for π β Generate C i Given an input proof π in,j is a translation proof π j,β and C i The verifier (in step 3) is embedded as a subcircuit of V i,β This is V i,β but

[0601]

number

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

[0603] 8.2.3 PCD Scheme generator

[0604]

number

[0605] To generate the verification and validation keys:

[0606]

number

[0607] is the compliance predicate. The PCD generator takes as input a compliance circuit (C1,...,C n ) and their corresponding translation circuits

[0608]

number

[0609] This is the SNARK scheme:(pk i,α ,vk i,α )←G α,i (C i ,λ) and

[0610]

number

[0611] Generate the proof / verification key using 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,β ) is output.

[0612] Prover

[0613]

number

[0614] Predicate Π i To prove node conformance to: this takes as input the node data (input

[0615]

number

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

[0617]

number

[0618] and the corresponding verification key

[0619]

number

[0620] (to validate the input proof), which is pk i,α as the proof key to generate the circuit C i Proof of satisfiability of π α This then yields the proof π α to π β So this translates to pk i,β as the proof key.

[0621]

number

[0622] This proves the satisfiability of π out :=π β Output.

[0623] Verifier

[0624]

number

[0625] Predicate Π i Z to outTo validate compliance with: this takes as input the output data z out and prove π out This is the verification key vk i,β Using b:=V i,β (z out ,π out If b is acceptable, output "accept". Otherwise, output "reject".

[0626] 8.3 Elliptic Curves for Pairing Bases 8.3.1 Which curve family to choose -- Stuck on MNT curves PCD via SNARKs on pairing-friendly elliptic curves can be instantiated over a limited number of curves. The following impossibility result can be proved. · The Barreto-Naehrig (BN) curve does not contain any elliptic curve cycles. · Cycles are possible only on curves of prime order. MNT curves only have cycles of length 2 or 4. The embedding order must alternate between 4 and 6.

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

[0628] 8.3.2 Efficiency vs. Security Trade-Off Solving the discrete logarithm problem in one of the source groups implies that the problem is

[0629]

number

[0630] where p is the prime order of the base field of the source curve and k is the embedding degree. kThe 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 computationally efficient the pairing becomes (small p and large k are preferred).

[0631] Curves with a small embedding degree k or prime number p are desirable for pairing-friendly applications, but from a security perspective, being too small is undesirable.

[0632] 8.3.3 Security of the MNT Curve As of July 2022, to achieve a conservative 128-bit security level on pairing-friendly elliptic curves,

[0633]

number

[0634] To withstand state-of-the-art cryptanalysis of the discrete logarithm in , the extension field must be 5534 bits. Other options are possible, summarized in the table below. As noted above, MNT curves can only have embedding degrees 4 or 6. The security must be that of a curve with a smaller degree (4).

[0635] The following table shows the three MNT cycles and their corresponding security levels:

[0636] [Table 6]

[0637] 9. Further Notes Other modifications or use cases of the disclosed technology will become apparent to those skilled in the art after reading the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

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

[0639] 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 functions of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered nodes of the preferred Bitcoin network 106).

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

[0641] More generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware using the same methods as described above with reference to blockchain node 104.

[0642] Some embodiments have been described in terms of a blockchain network implementing a proof-of-work consensus mechanism to protect the security of the underlying blockchain. However, proof-of-work is merely 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-age. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often referred to as a validator. A blockchain node can lock tokens for a certain period of time to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time has the best chance of becoming the next validator.

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

[0644] Statement 1. A computer-implemented method for generating a zero-knowledge proof that proves knowledge of a preimage value, comprising: obtaining a series of preimage blocks that, when combined, form the preimage value; executing a series of nodes, each node in the series of nodes configured to: receive a respective current state and a respective current iteration counter; evaluate an instance of a predefined compression function to calculate a respective next state based on its respective current state; increment its respective current iteration counter to generate a respective next iteration counter; determine, based on each next preimage block in the series of preimage blocks, that the instance of the predefined compression function has evaluated correctly; and outputting a proof, the proof establishing that the instance of the predefined compression function has evaluated correctly; wherein the proof generated by a final node in the series of nodes proves knowledge of the preimage value.

[0645] Statement 2. The method of statement 1, wherein a first node of the set of nodes is further configured to determine that each current state includes an initialization vector equal to the predefined initialization vector and to determine that each current iteration counter has a first iteration count value.

[0646] Statement 3. The method of Statement 1 or 2, wherein a final node in the series of nodes is further configured to receive a padding preimage portion and determine whether the padding preimage portion is required to satisfy a padding condition, and if it is determined that a padding preimage portion is required, the final node is further configured to evaluate a second instance of a predefined compression function to calculate a final state based on respective next states calculated by the final node based on the received respective current states, increment respective next iteration counters to generate final iteration counters, and determine, based on the padding preimage portion, that the second instance of the predefined compression function is correctly evaluated, the proof further establishing that the second instance of the predefined compression function is correctly evaluated, and if it is determined that a padding preimage portion is not required, the respective next states calculated by the final node are final states and the respective next iteration counters calculated by the final node are final iteration counters.

[0647] Statement 4. The method according to statement 3, wherein the final state includes a hash of the preimage value.

[0648] Statement 5. The method of Statement 3 or 4, wherein the final node is further configured to define a message and determine a final number of bits of the message to be a binary representation of a bit length of the preimage value, where the final number of bits is equal to the maximum bit length, wherein the message is defined as a respective next state calculated by the final node if the bit length of the preimage value is equal to the maximum bit length, and wherein the message is defined as a padding preimage portion if the bit length of the preimage value is less than the maximum bit length.

[0649] Statement 6. The final node is the expression

[0650]

number

[0651] is satisfied, where:

[0652]

number

[0653] is the bit length of the preimage value,

[0654]

number

[0655] is the maximum bit length, m is the length of each preimage block, and i out is the final iteration counter and k is

[0656]

number

[0657] and

[0658]

number

[0659] is a positive integer equal to the difference between a and b, and b is a padding indicator,

[0660]

number

[0661] b=1 if

[0662]

number

[0663] 6. The method of any one of statements 3 to 5, further configured to determine if b=0.

[0664] Statement 7. The method of statement 6, wherein the final node is further configured to concatenate each next state calculated by the final node with the padding preimage portion and check that the last k bits of the concatenation each have a value of 0 and the preceding bits have a value of 1.

[0665] Statement 8. The method of any one of statements 1 to 7, wherein for each of the second through final nodes in the series of nodes, the respective current state is received from a previous node in the series of nodes.

[0666] Statement 9. The method of any one of statements 1 to 8, wherein each respective next state includes a hash value.

[0667] Statement 10. The method of any one of statements 1 to 9, wherein the proof is generated based on a proof key, the proof key including a predefined compression function.

[0668] Statement 11. The method of statement 10, wherein the method further includes providing the proof generated by the end node to a verifying entity, the verifying entity having access to a verification key associated with the proof key.

[0669] Statement 12. The method of any one of Statements 1 to 11, wherein the proof generated by the final node further proves the presence of a predefined pattern in the preimage, the predefined pattern being described by a pattern bit array including a plurality of pattern bit array blocks, the check bit array defining bits of the pattern bit array defined by the predefined pattern and including a plurality of check bit array blocks, and wherein each node in the series of nodes is further configured to receive a respective next pattern bit array block and a respective next check bit array block, evaluate a respective next summary value, the respective next state including a respective next summary value, determine that the respective next summary value evaluates correctly based on the respective current summary value, the pattern bit array, and the check bit array, and determine that the respective next preimage block hash matches a respective portion of the predefined pattern based on the respective next pattern bit array block and the respective next check bit array block.

[0670] Statement 13. The method of statement 12, wherein determining that each next digest value is evaluated correctly includes calculating a hash value based on each current digest value, the pattern bit array, and the check bit array, and comparing the calculated hash to each evaluated next digest value, wherein each next digest value is evaluated correctly if the calculated hash is equal to the each evaluated next digest value.

[0671] Statement 14. The method of any one of statements 1 to 13, wherein the preimage value is equal to the concatenation of a series of preimage blocks.

[0672] Statement 15. The method of any one of statements 1 to 14, wherein the current state and the next state are digest values ​​corresponding to respective ones of a pre-image block in a sequence of pre-image blocks.

[0673] Statement 16. A computer system, comprising: at least one computing device comprising a memory including one or more memory units; and a processing device including one or more processing units, the memory storing one or more portions of code configured to execute on the processing device, the code defining a series of nodes for generating a zero-knowledge proof for proving knowledge of a preimage value, each of the one or more portions of code corresponding to one of the series of nodes, each of the one or more portions of code when executed causing the processing device to obtain a respective next preimage block of the series of preimage blocks, the series of preimage blocks when combined forming the preimage value. a computer system that performs the steps of: obtaining a respective current state and a respective current iteration counter; evaluating an instance of a predefined compression function based on the respective current states to calculate a respective next state; incrementing the respective current iteration counters to generate a respective next iteration counter; determining that the instance of the predefined compression function has been correctly evaluated based on each next preimage block in the series of preimage blocks; and generating a proof, the proof establishing that the instance of the predefined compression function has been correctly evaluated, wherein the proof generated by the final node in the series proves knowledge of the preimage value.

[0674] Statement 17. The computer system of statement 16, wherein the portion of the code corresponding to a first node of the set of nodes, when executed by the processor, further causes the processor to determine that each current state includes a component equal to a predefined initialization vector and that each current iteration counter has a first iteration count value.

[0675] 18. The computer system of statement 16 or 17, wherein the portion of code corresponds to a final node in the series of nodes and, when executed by the processing unit, further causes the processing unit to receive a padding preimage portion and determine whether the padding preimage portion is required to satisfy a padding condition; if it is determined that a padding preimage portion is required, the final node further causes the processing unit to evaluate a second instance of a predefined compression function based on a respective next state calculated by the final node based on the received respective current state, increment a respective next iteration counter to generate a final iteration counter, and determine, based on the padding preimage portion, that the second instance of the predefined compression function is correctly evaluated; the proof further establishes that the second instance of the instance of the predefined compression function is correctly evaluated; if it is determined that a padding preimage portion is not required, the respective next state calculated by the final node is a final state, and the respective next iteration counter calculated by the final node is a final iteration counter.

[0676] Statement 19. The computer system of statement 18, wherein the portion of code corresponds to a final node in the series of nodes and, when executed by the processor, further causes the processor to: define a message; and determine that a final number of bits of the message is a binary representation of a bit length of the preimage value, where the final number of bits is equal to a maximum bit length; wherein the message is defined as a respective next state computed by the final node if the bit length of the preimage value is equal to the maximum bit length; and wherein the message is defined as a padding preimage portion if the bit length of the preimage value is less than the maximum bit length.

[0677] Statement 20. The portion of code corresponds to the final node of a series of nodes and, when executed by the processing unit, provides the processing unit with the formula

[0678]

number

[0679] is satisfied, where:

[0680]

number

[0681] is the bit length of the preimage value,

[0682]

number

[0683] is the maximum bit length, m is the length of each preimage block, and i out is the final iteration counter and k is

[0684]

number

[0685] and

[0686]

number

[0687] is a positive integer equal to the difference between a and b, and b is a padding indicator,

[0688]

number

[0689] b=1 if

[0690]

number

[0691] 20. The computer system of statement 18 or 19, further causing determining if b=0.

[0692] Statement 21. The computer system of statement 20, wherein the portion of code corresponds to a final node in the series of nodes and, when executed by the processor, further causes the processor to concatenate the padding preimage portion with each next state calculated by the final node and check that the final k bits of the concatenation each have a value of 0 and the preceding bits have a value of 1.

[0693] Statement 22. The computer system of any one of statements 16 to 21, wherein the processing unit is configured to receive the respective current states and the respective current iteration counters from a second computing device executing a second portion of the one or more portions of code.

[0694] Statement 23. The computer system of any one of statements 16 to 22, wherein the proof generated by the final node further proves the presence of a predefined pattern in the preimage, the predefined pattern being described by a pattern bit array including a plurality of pattern bit array blocks, the check bit array defining bits of the pattern bit array defined by the predefined pattern and including a plurality of check bit array blocks, wherein each of the one or more portions of code when executed further causes the processing unit to receive a respective next pattern bit array block and a respective next check bit array block; evaluate a respective next summary value, the respective next state including the respective next summary value; determine that the respective next summary value evaluates correctly based on the respective current summary value, the pattern bit array, and the check bit array; and determine that the respective next preimage block hash matches a respective portion of the predefined pattern based on the respective next pattern bit array block and the respective next check bit array block.

[0695] Statement 24. The computer system of statement 23, wherein determining that each next digest value is evaluated correctly includes calculating a hash value based on each current digest value, the pattern bit array, and the check bit array, and comparing the calculated hash with each next evaluated digest value, wherein each next evaluated digest value is evaluated correctly if the calculated hash is equal to the each next evaluated digest value.

[0696] Statement 25. The computer system of any one of statements 16 to 24, wherein the system further includes a verification entity, the verification entity including a memory and a processing unit, wherein the memory of the verification entity stores code that, when executed by the processing unit of the verification entity, causes the processing unit to obtain a verification key, the verification key being associated with a proof key and a predefined compression function; receive from the processing unit executing the one or more nodes a proof generated by the final node; and verify that the proof is valid based on the received proof and the verification key.

[0697] Statement 26. The method or computer system of any one of statements 1 to 25, wherein the preimage value corresponds to a digest calculated by applying a SHA2 hash function to the preimage value. [Explanation of symbols]

[0698] 100 systems 101 Packet Switched Network 102 Computer Equipment 102a Computer Equipment 102b Computer Equipment 103 users 103 Stakeholders 103a Originating User or Entity 103a First Person 103a Alice 103b New User or Entity 103b Second Person 103b Bob 104 blockchain nodes 104 Bitcoin nodes 105 Client Applications 106 Peer-to-Peer (P2P) Networks 106 Bitcoin Network 107 Side Channel 150 Blockchain 151 Blocks of Data 151n Block 151n-1 Block 152 transactions 152i Preceding Transaction 152j New Transaction 153 Genesis Block (Gb) 154 Ordered Sets 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output 301 Side Channel 302 Source Node 304 Intermediate Node 306 Output Node 306 Digest Node 306 Digest (output) node 400 SHA2 Transcript 402 init node 602 Prover 604 Verifier 700 Merkle Tree 702 leaves 704 leaf nodes 704, 706 nodes 706 inner nodes 706a Last Node 902 Key Stretching Subtranscript 904 Exclusive OR Transcript 906 HMAC ext node 908 HMAC exp node 906, 908, 910, 912 nodes 1002 Data Providers 1004 Data Requester

Claims

1. 1. A computer-implemented method for generating a zero-knowledge proof that proves knowledge of a preimage value, comprising: obtaining a series of pre-image blocks which, when combined, form said pre-image value; Executing a series of nodes, each node in the series of nodes comprising: receiving a respective current state and a respective current iteration counter; evaluating an instance of a predefined compression function based on the respective current states to calculate a respective next state; incrementing said respective current iteration counters to generate respective next iteration counters; determining that the instance of the predefined compression function evaluates correctly based on each subsequent preimage block in the series of preimage blocks; outputting a proof, said proof establishing that the instance of said predefined compression function evaluates correctly; and Including, A computer-implemented method, wherein the proof produced by the final node in the series of nodes proves knowledge of the preimage value.

2. A first node in the series of nodes comprises: determining that each current state includes an initialization vector equal to a predefined initialization vector; determining that each current iteration counter has a first iteration count value; The method of claim 1 , further configured to:

3. The final node in the series of nodes is receiving a padding pre-image portion; determining whether the padding pre-image portion needs to satisfy a padding condition; further configured to: If it is determined that the padding pre-image portion is necessary, the final node: evaluating a second instance of the predefined compression function to calculate a final state based on the respective next states calculated by the final node based on the respective received current states; incrementing each subsequent iteration counter to generate a final iteration counter; determining that the second instance of the predefined compression function evaluates correctly based on the padding preimage portion; and further configured to: the proof further establishes that the second instance of the predefined compression function instance evaluates correctly; If it is determined that the padding pre-image portion is not required, 3. The method of claim 1, wherein the respective next states calculated by the final nodes are final states, and the respective next iteration counters calculated by the final nodes are final iteration counters.

4. The method of claim 3 , wherein the final state includes a hash of the preimage value.

5. The final node is Defining a message; determining a final number of bits of the message that is a binary representation of a bit length of the preimage value, the final number of bits being equal to a maximum bit length; further configured to: the message is defined as the respective next state computed by the final node when the bit length of the preimage value is equal to the maximum bit length; The method of claim 3 or 4, wherein if the bit length of the preimage value is less than the maximum bit length, the message is defined as the padding preimage portion.

6. The final node is represented by the formula [Equation 1] is satisfied, where: [Equation 2] is the bit length of the preimage value, [Equation 3] is the maximum bit length, m is the length of each preimage block, and i out is the final iteration counter, and k is [Equation 4] and [Equation 5] is a positive integer equal to the difference between a and b, and b is a padding indicator, [Equation 6] b=1 if [Equation 7] If b=0, determine 6. The method of claim 3, further comprising:

7. The final node is concatenating the padding preimage portion with the respective next states calculated by the final nodes; checking that the last k bits of said concatenation each have a value of 0 and the preceding bits have a value of 1; The method of claim 6 , further configured to:

8. 8. The method of claim 1, wherein for each second through final node in the series of nodes, the respective current state is received from a previous node in the series.

9. The method of claim 1 , wherein each respective next state comprises a hash value.

10. The method of claim 1 , wherein the proof is generated based on a proof key, the proof key including the predefined compression function.

11. 11. The method of claim 10, further comprising providing the proof generated by the final node to a verifying entity, the verifying entity having access to a verification key associated with the proof key.

12. The proof generated by the final node further proves the existence of a predefined pattern in the pre-image, the predefined pattern being described by a pattern bit array comprising a plurality of pattern bit array blocks, a check bit array defining the bits of the pattern bit array defined by the predefined pattern and comprising a plurality of check bit array blocks, and each node in the set of nodes: receiving a respective next pattern bit array block and a respective next check bit array block; evaluating each next summary value, wherein the each next state includes the each next summary value; determining that each of the next digest values ​​is correctly evaluated based on each of the current digest values, the pattern bit sequence, and the check bit sequence; determining, based on the respective next pattern bit array block and the respective next check bit array block, that the respective next pre-image block hash matches a respective portion of the predefined pattern; 12. The method of claim 1, further comprising:

13. determining that each of the next summary values ​​is correctly evaluated; calculating a hash value based on the respective current digest values, the pattern bit array, and the check bit array; comparing the calculated hash with each of the evaluated next digest values; Including, The method of claim 12 , wherein the respective next digest value is evaluated correctly if the calculated hash is equal to the respective next evaluated digest value.

14. The method of claim 1 , wherein the pre-image value is equal to the concatenation of the series of pre-image blocks.

15. 15. The method of claim 1, wherein the current state and the next state are digest values ​​corresponding to respective ones of the series of pre-image blocks.

16. 1. A computer system comprising: at least one computing device comprising a memory including one or more memory units; and a processing unit including one or more processing units, the memory storing one or more portions of code configured to execute on the processing unit, the code defining a set of nodes for generating a zero-knowledge proof that proves knowledge of a preimage value, each of the one or more portions of code corresponding to one of the set of nodes, and each of the one or more portions of code, when executed, causing the processing unit to: obtaining each subsequent pre-image block in a series of pre-image blocks, the series of pre-image blocks, when combined, forming a pre-image value; obtaining a respective current state and a respective current iteration counter; evaluating an instance of a predefined compression function based on the respective current states to calculate a respective next state; incrementing said respective current iteration counters to generate respective next iteration counters; determining that the instance of the predefined compression function evaluates correctly based on each subsequent preimage block in the series of preimage blocks; generating a proof, the proof establishing that the instance of the predefined compression function evaluates correctly; Let The proof produced by the final node in the series of nodes proves knowledge of the preimage value.

17. The portion of code corresponding to a first node of the series of nodes, when executed by the processing unit, causes the processing unit to: determining that each current state includes an element equal to a predefined initialization vector; determining that each current iteration counter has a first iteration count value; The computer system of claim 16 further comprising:

18. The portion of code corresponds to a final node in the series of nodes and, when executed by the processing unit, causes the processing unit to: receiving a padding pre-image portion; determining whether the padding pre-image portion needs to satisfy a padding condition; Further, If it is determined that the padding pre-image portion is necessary, the final node may instruct the processing unit: evaluating a second instance of the predefined compression function to calculate a final state based on the respective next states calculated by the final node based on the respective received current states; incrementing each subsequent iteration counter to generate a final iteration counter; determining that the second instance of the predefined compression function evaluates correctly based on the padding preimage portion; and Further, the proof further establishes that the second instance of the predefined compression function instance evaluates correctly; If it is determined that the padding pre-image portion is not required, 18. The computer system of claim 16 or 17, wherein the respective next states calculated by the final nodes are final states, and the respective next iteration counters calculated by the final nodes are final iteration counters.

19. The portion of code corresponds to a final node in the series of nodes and, when executed by the processing unit, causes the processing unit to: Defining a message; determining a final number of bits of the message that is a binary representation of a bit length of the preimage value, the final number of bits being equal to a maximum bit length; Further, the message is defined as the respective next state computed by the final node when the bit length of the preimage value is equal to the maximum bit length; 20. The computer system of claim 18, wherein if the bit length of the preimage value is less than the maximum bit length, the message is defined as the padding preimage portion.

20. The portion of code corresponds to a final node in the series of nodes and, when executed by the processing unit, causes the processing unit to: formula [Equation 8] is satisfied, where: [Equation 9] is the bit length of the preimage value, [Equation 10] is the maximum bit length, m is the length of each preimage block, and i out is the final iteration counter, and k is [0011] and [0012] is a positive integer equal to the difference between a and b, and b is a padding indicator, [0013] b=1 if [0014] If b=0, determine 20. The computer system of claim 18 or 19, further comprising:

21. The portion of code corresponds to a final node in the series of nodes and, when executed by the processing unit, causes the processing unit to: concatenating the padding preimage portion with the respective next states calculated by the final nodes; checking that the last k bits of said concatenation each have a value of 0 and the preceding bits have a value of 1; The computer system of claim 20 further comprising:

22. 22. The computer system of claim 14, wherein the processing unit is configured to receive the respective current states and the respective current iteration counters from a second computing device executing a second portion of the one or more portions of code.

23. the proof generated by the final node further proves the existence of a predefined pattern in the preimage, the predefined pattern being described by a pattern bit array comprising a plurality of pattern bit array blocks, a check bit array defining the bits of the pattern bit array defined by the predefined pattern and comprising a plurality of check bit array blocks, each of the one or more portions of code, when executed, causing the processing unit to: receiving a respective next pattern bit array block and a respective next check bit array block; evaluating each next summary value, wherein the each next state includes the each next summary value; determining that each of the next digest values ​​is correctly evaluated based on each of the current digest values, the pattern bit sequence, and the check bit sequence; determining, based on the respective next pattern bit array block and the respective next check bit array block, that the respective next pre-image block hash matches a respective portion of the predefined pattern; 23. The computer system of claim 16, further comprising:

24. determining that each of the following summary values ​​is correctly evaluated; calculating a hash value based on the respective current digest values, the pattern bit array, and the check bit array; comparing the calculated hash with each of the evaluated next digest values; Including, 24. The computer system of claim 23, wherein the respective next digest value is evaluated correctly if the calculated hash is equal to the respective evaluated next digest value.

25. The system further includes a verification entity, the verification entity including a memory and a processing unit, the memory of the verification entity storing code that, when executed by the processing unit of the verification entity, causes the processing unit to: obtaining a verification key, the verification key being associated with an attestation key and the predefined compression function; receiving the proof generated by the final node from the processing device executing the one or more nodes; verifying that the certificate is valid based on the received certificate and the verification key; 25. A computer system according to any one of claims 14 to 24,

26. 26. The method or system of claim 1, wherein the preimage value corresponds to a digest calculated by applying a SHA2 hash function to the preimage value.

Images