System and method for authenticating off chain data on the basis of proof verification

Abstract

To provide a method and a system related to a block chain technology, generating a proof of conversation that can be verified with a script, and providing information that can be used in the event of a recourse.SOLUTION: A computer-implemented method: establishes a communication session protected by an encryption with a computing entity; receives a communication comprising input data controlling execution of a program published on a block chain network in a communication session protected by an encryption; receives a first proof that one group of communications containing data is generated in the communication session protected by the encryption; generates a second proof that a proof of an appropriate execution of the program and data being received from data source based at least partially on received input data; and provides the proof of the appropriate execution of the program to another computer system.SELECTED DRAWING: Figure 11

Description

[Technical field]

[0001] The present invention relates generally to blockchain technology, and more particularly to generating proofs of conversations that can be verified by Bitcoin scripts, and also to providing information that can be used in the event of recourse. Proofs that a given communication occurred during a conversation may utilize Merkle trees. Data from a conversation or communication may be used as input to correctly execute a program or script. The present invention is particularly suited for use in, but not limited to, the creation and execution of smart contracts. [Background technology]

[0002] In this document, the term "blockchain" may refer to any of a number of types of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and purposes of explanation, Bitcoin may be mentioned as a useful application of the technology described in this application, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the technology described in this disclosure may provide benefits for the use of other blockchain implementations that have similar limitations as Bitcoin with respect to the execution of programs or scripts published to the blockchain network that may rely on data external to the blockchain.

[0003] A blockchain may refer to a peer-to-peer electronic ledger, implemented as a computer-based, decentralized, distributed system composed of blocks, which may consist of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured collection of field values ​​that includes data and a set of conditions, the satisfaction of which is required before a set of fields can be written to the blockchain data structure. For example, in the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants of the blockchain system, and includes at least one input and at least one output. In some embodiments, a "digital asset" refers to binary data that is associated with rights to use. Examples of digital assets include Bitcoin, Ether, and Litecoin. The term "Bitcoin" as used herein is used to include any protocol that is a variation of the Bitcoin protocol. In some implementations, transferring control of a digital asset can be performed by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block on the blockchain contains a hash of the previous block, and blocks are chained together with their predecessors, creating a permanent, immutable record of all transactions that have been written to the blockchain since its inception.

[0004] In some examples, a "stack-based scripting language" refers to a programming language that supports various stack-based or stack-oriented execution models or operations. That is, a stack-based scripting language can utilize a stack, where values ​​can be pushed onto the top of the stack or popped off the top of the stack. Various operations performed to manipulate the stack can result in pushing or popping one or more values ​​onto or off the top of the stack. For example, the OP_EQUAL operation takes the top two items from the stack, compares them, and pushes the result (e.g., 1 if they are equal or 0 if they are not equal) onto the top of the stack. Other operations performed on the stack, such as OP_PICK, can allow an item to be selected from a location other than the top of the stack. In some scripting languages ​​used in some embodiments of the present application, there can be at least two stacks, a main stack and an alternate stack. Some operations in the scripting language can move an item from the top of one stack to the top of another stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the alternate stack. It should be noted that stack-based scripting languages ​​may in some cases not be limited to operations in a strictly last-in-first-out (LIFO) fashion. For example, a stack-based scripting language may support operations to copy or move the nth item in the stack to the top (e.g., OP_PICK and OP_ROLL, respectively, in Bitcoin). Scripts written in stack-based scripting languages ​​may be pushed onto a logical stack, which may be implemented using any suitable data structure, such as a vector, list, or stack.

[0005] For a transaction to be written to the blockchain, it must be "validated". Network nodes (mining nodes) perform work to ensure that each transaction is valid, and transactions that are not valid are rejected from the network. Nodes can have different standards for validity than other nodes. Since validity in the blockchain is consensus-based, a transaction is considered valid if a majority of nodes agree that the transaction is valid. A software client installed on a node performs this validation work for transactions that reference partially unspent transaction outputs (UTXOs) by executing UTXO locking and unlocking scripts. A transaction is validated by a node if the execution of the locking and unlocking scripts evaluates to TRUE, and if other validation conditions are met, if applicable. Validated transactions are propagated to other network nodes, and mining nodes can choose to include the transaction in the blockchain. Thus, for a transaction to be written to the blockchain, it must: i) be verified by the first node that receives it---if the transaction is verified as valid, the node relays it to other nodes in the network; ii) be added to a new block that is constructed by mining nodes; and iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed when it has been added to the blockchain in enough blocks to make it effectively irreversible.

[0006] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to consider leveraging both the cryptographic security system on which Bitcoin is based, and the data that can be stored on the blockchain, to implement new systems. It would be highly advantageous if blockchain could be used for automating tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be able to exploit the benefits of blockchain (e.g., permanent tamper-proof record of events, distributed processing, etc.) while allowing for rich diversity in their applications.

[0007] This disclosure discloses technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program may be a machine-readable, executable program recorded in a blockchain transaction. A blockchain-based computer program may include rules capable of processing inputs to generate results and then causing actions to be performed depending on those results. One area of ​​current research is the use of blockchain-based computer programs for the implementation of "smart contracts." Unlike traditional contracts that are written in natural language, smart contracts may be computer programs designed to automate the execution of the provisions of a machine-readable contract or agreement.

[0008] Another area of ​​interest related to blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Thus, the tokens act as identifiers that allow real-world items to be referenced from the blockchain.

[0009] In embodiments, interactions with specific entities may be encoded in specific steps of a smart contract, but the smart contract may otherwise be automatically executed and self-enforced, which may be machine-readable and executable. In some examples, automatic execution refers to the execution of a smart contract that is successfully executed to allow the transfer of a UTXO. Note that in such examples, an "entity" capable of causing the transfer of a UTXO may refer to an entity capable of creating an unlocking script without being required to prove any secret information. In other words, an unlocking transaction may be verifiable for validity without verifying that the source of the data (e.g., the entity that created the unlocking transaction) has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Also, in such examples, self-enforcement refers to a validating node of a blockchain network being forced to enforce the unlocking transaction according to the constraints. In some examples, "unlocking" a UTXO refers to creating an unlocking transaction that references the UTXO and executes as valid.

[0010] A blockchain transaction output contains a locking script and information about the ownership of a digital asset, such as Bitcoin. The locking script, which may also be referred to as an encumbrance, "locks" the digital asset by specifying conditions that must be satisfied in order for the UTXO to be transferred. For example, a locking script may require that certain data be provided in the unlocking script to unlock the associated digital asset. Locking scripts are also known as "scriptPubKeys" in Bitcoin. Techniques for requiring a party to provide data to unlock a digital asset include embedding a hash of the data within the locking script.

[0011] The present invention may be described as a system and method for executing smart contracts on a blockchain that may utilize zero-knowledge proofs. Execution of the smart contract may occur as part of transaction validation. As part of the execution of the smart contract, it may be desirable to gain access to data outside the blockchain (e.g., off-chain data), such as data about real-world states and events. The techniques described herein may be used where data provided by a data source is authenticated and used to execute a program or script, such as a smart contract, that is published to the blockchain network. While digital assets may be used as cryptocurrency in some embodiments, it is contemplated that in embodiments, digital assets may additionally or alternatively be used in other contexts. It is noted that the present invention, while applicable to the control of digital assets, may be used in other contexts that utilize blockchain data structures that are technical in nature and do not necessarily involve the transfer of digital assets. Summary of the Invention

[0012] It is therefore desirable to provide a method and system that improves blockchain technology in one or more of these aspects. Such an improved solution has now been devised. Namely, in accordance with the present invention, there is provided a method as defined in the accompanying claims.

[0013] Such an improved solution has now been devised.

[0014] Thus, in accordance with the present invention there is provided a system and method as defined in the accompanying claims.

[0015] According to the present invention, it is possible to provide a computer implemented method for a node of a blockchain, the computer implemented method comprising: establishing a cryptographically secured communications session with a computing entity; receiving, in a cryptographically secured communications session, a communication including input data for controlling execution of a program published to the blockchain network; receiving a first verification that a group of communications including the data occurred in a cryptographically secured communications session; determining whether the program is executing properly based at least in part on the input data received; generating a proof and a second proof that the data was received from the data source; Providing proof of proper execution of the program to another computer system.

[0016] Additionally or alternatively, the invention may be described as including the steps of: establishing a cryptographically secured communications session with a computing entity; receiving, in a cryptographically secured communications session, a communication including input data for controlling execution of a program published to the blockchain network; receiving a first verification that a group of communications including the data occurred in a cryptographically secured communications session; generating a proof of correct execution of the program based at least in part on the received input data and a second proof that the data was received from a data source; and It is the step of providing proof of the correct execution of a program to another computer system.

[0017] The first proof may have a value based at least in part on a root node of a Merkle tree, the Merkle tree including a set of leaf nodes determined from a set of communications and a set of salt values.

[0018] A communication in the set of communications may include a corresponding intermediate node that is determined based on whether the communication was received or sent, and in some cases, each communication in the set of communications includes such a corresponding intermediate node.

[0019] The value of the first proof is based at least in part on a cryptographic hash output generated from at least a root node of the Merkle tree and a time interval between the set of communications. An example of a cryptographic hash algorithm suitable for generating the cryptographic hash output is the SHA-256 cryptographic hash algorithm.

[0020] The second proof may be based at least in part on a Merkle path of the Merkle tree, the Merkle path including values ​​of a set of nodes of the Merkle tree, the values ​​of the set of nodes sufficient to compute a value of a root node of the Merkle tree.

[0021] Preferably, the set of nodes of a Merkle path includes at most one node at each non-leaf, non-root depth of the Merkle tree. In some cases, a Merkle path includes exactly one node at each non-leaf, non-root depth of the Merkle tree.

[0022] The program may include a set of rules agreed upon by two or more parties, and the method may include selecting a computing entity for establishing cryptographically secured communications with one or more computing entities trusted by at least one of the two parties.

[0023] Preferably, the method comprises the steps of: Detecting a blockchain transaction including a first transaction output and a second transaction output, the first transaction output including a first locking script, and a first digital asset associated with the first transaction output is unlocked by an unlocking script, the unlocking script comprising: A public key associated with the computing entity; and a digital signature that encodes an expected value, the authenticity of which is cryptographically verifiable using the public key and the authentication information can be used to generate the expected value; the second transaction output encoding instructions for a proof of proper execution; and The method may include unlocking the first digital asset by providing at least the public key, the digital signature, and the authentication information.

[0024] Blockchain transactions can also: Transaction inputs that are digitally signed using a private key associated with another computer system; a third transaction output including a second unlocking script, where a second digital asset associated with the third transaction output is unlockable using the private key; and the second transaction output further encodes an identifier associated with the other computer system.

[0025] Preferably, the authentication information includes a Merkle path of a Merkle tree, and the expected value is based at least in part on a root node of the Merkle tree.

[0026] The data may include binary data that indicates whether an event has occurred or not.

[0027] The data may include information whose authenticity is not verifiable based on other data on the blockchain.

[0028] Preferably, the first proof is a digital signature, the authenticity of which is verifiable using a cryptographic public key associated with the computing entity.

[0029] It is also desirable to provide a system comprising a processor and a memory containing executable instructions which, upon execution by the processor, cause the system to perform any of the methods for which protection is claimed.

[0030] It is also desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon which, upon execution by one or more processors of a computer system, cause the computer system to perform at least any of the methods for which protection is claimed.

[0031] Additionally or alternatively, the present invention may provide improved blockchain programming tools or aids, which may provide improved, efficient and optimized configurations that facilitate or enable distributed, verifiable computation. [Brief description of the drawings]

[0032] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment(s) described hereinafter, which are described, by way of example only, with reference to the accompanying drawings, in which:

[0033] [Figure 1] 1 illustrates a blockchain environment in which various embodiments may be implemented.

[0034] [Diagram 2] 1 illustrates a computing environment that may be utilized to implement protocols in accordance with various embodiments.

[0035] [Diagram 3] 1 shows a diagram of an environment suitable for performing verifiable computations.

[0036] [Figure 4] 1 illustrates an exemplary diagram of an environment in which a prover utilizes data obtained from a data source in connection with the execution of a program or script.

[0037] [Diagram 5] FIG. 1 illustrates a protocol for acquiring data from a data source that is used to execute a program or script.

[0038] [Figure 6] 1 illustrates a diagram of a Merkle tree according to an embodiment.

[0039] [Figure 7] 1 illustrates a diagram of a Merkle path according to an embodiment.

[0040] [Figure 8] 1 shows a diagram of a protocol for generating and verifying proofs utilized in connection with various embodiments.

[0041] [Figure 9] 1 illustrates a diagram of a reputation transaction according to an embodiment.

[0042] [Figure 10] FIG. 2 is an illustration of a process for generating a proof of communication.

[0043] [Figure 11] FIG. 13 is an explanatory diagram of a process for executing a program or script using authenticated data.

[0044] [Figure 12] 1 illustrates a computing device that can be used to implement at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0045] Reference is first made to FIG. 1, which illustrates an example blockchain network 100 associated with a blockchain according to an embodiment of the present disclosure. In an embodiment, the example blockchain network 100 includes blockchain nodes implemented as peer-to-peer distributed electronic devices, each of which executes instances of software and / or hardware that perform operations according to a blockchain protocol agreed upon at least in part among operators of the nodes 102. In some examples, a "node" refers to a peer-to-peer electronic device distributed across a blockchain network. One example of a blockchain protocol is the Bitcoin protocol.

[0046] In some embodiments, node 102 may comprise any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), a plurality of computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device such as computing device 800 of FIG. 8). In some embodiments, node 102 has an input for receiving data messages or objects representing proposed transactions, such as transaction 104. In some embodiments, the node is queryable for information it maintains (e.g., information on the state of transaction 104).

[0047] As shown in Figure 1, some nodes 102 are communicatively coupled to one or more other nodes 102. Such communication connections may include one or more wired or wireless communications. In an embodiment, each node 102 maintains at least a portion of a "ledger" of all transactions in the blockchain. In this manner, the ledger is a distributed ledger. Transactions processed by a node that affect the ledger are verifiable by one or more other nodes such that the integrity of the ledger is maintained.

[0048] With regard to which nodes 102 can communicate with which other nodes, assuming the blockchain protocol indicates that messages should be forwarded, it may be sufficient that each node in the exemplary blockchain network 100 can communicate with one or more other nodes 102, such that messages passed between nodes are propagated throughout (or a substantial portion of) the exemplary blockchain network 100. One such message may be the announcement of a proposed transaction by one node 102, such as node 102A, which propagates along a path, such as path 106. Another such message may be the announcement of a proposed new block for inclusion in the blockchain.

[0049] In an embodiment, at least some of the nodes 102 are miner nodes that perform complex calculations, such as solving a cryptographic problem. A miner node that solves the cryptographic problem creates a new block for the blockchain and broadcasts the new block to other nodes 102. The other nodes 102 verify the work of the miner node and, based on the verification, accept the block into the blockchain (e.g., by adding it to the blockchain's distributed ledger). In some examples, a block is a group of transactions, often marked with a "fingerprint" (e.g., a hash) and a timestamp of the previous block. In this manner, each block can be linked to the previous block, thereby generating a "chain" that links the blocks of the blockchain. In an embodiment, a valid block is added to the blockchain by consensus of the nodes 102. Also, in some examples, the blockchain includes a list of validated blocks.

[0050] In one embodiment, at least some of the nodes 102 operate as validating nodes that validate transactions as described in this disclosure. In some examples, a transaction includes data that provides proof of ownership of a digital asset (e.g., some bitcoins) and conditions for accepting or transferring ownership / control of the digital asset. In some examples, an "unlocking transaction" refers to a blockchain transaction that reassociates (e.g., transfers ownership or control) at least a portion of a digital asset specified by a prior UTXO to an entity associated with a blockchain address. In some examples, a "prior transaction" refers to a blockchain transaction that includes a UTXO referenced by the unlocking transaction. In some embodiments, the transaction includes a "locking script" that restricts the transaction with conditions that must be met before ownership or control is transferred (unlocked).

[0051] In some embodiments, the blockchain address is an alphanumeric string associated with an entity to which control of at least some digital assets is being transferred / reassociated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between public keys associated with an entity and blockchain addresses. In some embodiments, validating the transaction includes verifying one or more conditions specified in the locking script and / or the unlocking script. Upon successful validation of the transaction 104, the validating node adds the transaction 104 to the blockchain and spreads it to nodes 102.

[0052] The system and method described herein is a method for storing a locking script that stores a verification key V Kfrom modification and makes it possible to check the validity of the proof π, thereby enabling the implementation of a zero-knowledge protocol on the blockchain during transaction validation.

[0053] Verifiable computation is a technique that allows for the generation of a proof of computation. In an embodiment, such techniques are utilized by a client to outsource the evaluation of a function f on an input x to another computing entity, referred to herein as a prover. In some cases, the client may have limited computational overhead, such that the client is unable to perform the evaluation of the function (e.g., the expected runtime of the computation using the computational resources available to the client may exceed a maximum acceptable threshold), but this is not necessarily the case; the client may generally delegate the evaluation of the function on the input x based on any suitable criteria, such as computation runtime, computational cost (e.g., the financial cost of allocating computational resources to perform the evaluation of the function), etc.

[0054] A prover, in embodiments, is any suitable computing entity, such as a blockchain node, as described in more detail elsewhere in this disclosure. In embodiments, a prover (e.g., a blockchain node) evaluates a function f with respect to an input x and generates an output y and a proof π of the correctness of the output y, which can be verified by other computing entities, such as the client and / or other nodes of the blockchain network. The proof, also referred to as an argument, can be verified faster than performing an actual computation, i.e., by verifying the correctness of a proof instead of recomputing the function f with respect to the input x to determine the correctness of the output generated by the prover, computational overhead can be reduced (e.g., power overhead, costs associated with power, and computational resources during execution can be reduced). In a zero-knowledge verifiable computation, a prover provides a client with an attestation that the prover knows an input that has a particular property.

[0055] A streamlined variant of a zero-knowledge proof of knowledge is a succinct non-interactive ARgument of knowledge (zk_SNARK). In an embodiment, all pairing-based zk-SNARKs involve a process in which the prover computes a number of group elements using a common group operation, and the verifier verifies the proof using a number of pairing product equations. In an embodiment, linear interactive proofs operate in finite fields, and the prover and verifier messages contain, encode, reference, or otherwise include information usable to determine a vector of field elements.

[0056] In embodiments, the systems and methods described herein enable mining nodes of a blockchain to perform a computation (e.g., evaluating a function f on an input x) once and generate a proof that can be used to verify the correctness of the output, where evaluating the correctness of the proof is less computationally intensive than evaluating the function. In this context, the cost of operations and tasks (i.e., how expensive they are) can refer to the computational complexity of performing the operation or task. In embodiments, computational complexity refers to the average or worst-case computational cost of performing a sorting algorithm, e.g., heapsort and quicksort algorithms both have an average computational cost of O(n logn), while quicksort has an average computational cost of O(n logn). 2 ), whereas heapsort has a worst-case computational cost of (n log n). In an embodiment, the average and / or worst-case computational cost of evaluating the function f on the input x is less than the cost of evaluating the correctness of the proof. Thus, use of the systems and methods described herein is highly advantageous, for example, because more computationally intensive and expensive contracts may be executed, since such contracts do not proportionately increase the time required to verify a blockchain. Further advantages may include reduced power consumption of the verifier system, thereby improving the efficiency of the verifier computer system and reducing the energy costs associated with operating such a verifier computer system in evaluating the correctness of a proof.

[0057] In an embodiment, the verification key V K or a portion thereof, verifies a proof of the alleged correctness of a correct computation provided by a prover, the proof being derived from public parameters and input / output data generated during the setup phase of the zero-knowledge protocol and used with the proof π. For example, as described above and in the detailed description below, the systems and methods may include a verification key VK This allows for a locking script that protects the proof π from modification and confirms the validity of the proof π, allowing for the execution of a zero-knowledge protocol on the blockchain during transaction validation. Accordingly, the present disclosure provides systems and methods for performing a validation phase using a blockchain script (e.g., a Bitcoin-based network) to store elements used to validate a computation.

[0058] 2 illustrates a computing environment 200 that may be utilized to implement a protocol according to various embodiments. The protocol may be implemented using blockchain technology to store proofs-of-correctness and combine "correct-by-construction" cryptography with smart contracts. In an embodiment, the publicly verifiable computation scheme includes three phases: a setup phase, a computation phase, and a verification phase.

[0059] The setup phase may be performed as part of a process to outsource the execution of a computational task. As described below, a client may refer to an entity, such as a customer or a client computer system, which may be a different computer system, that delegates the execution of a computational task to a prover. In general, a client may delegate the execution of a computational task for a variety of reasons, including, but not limited to, computational resources, a lack of computational resources, economic costs associated with utilizing the client computer system to perform a task, energy costs associated with utilizing the client computer system to perform a task, etc. (e.g., a mobile device or laptop that relies on a battery for power may utilize a prover to perform computationally intensive tasks, thereby conserving power and extending the usage time of the battery-powered device).

[0060] In one embodiment, the setup phase includes a client, customer, employee of an organization, or any other suitable entity writing a contract in a semantically formal language. The contract may be written in a high-level programming language such as C or Java. In general, the contract may be expressed in any language or syntax that is in or can be converted into a format that can be processed by a computer system. In an embodiment, for limited purposes, a domain-specific language may provide type safety and a restricted representation may be utilized. The generated source code may be an accurate description of the contract.

[0061] The compiler 202 may be any hardware, software, or combination thereof that includes executable code that, when executed by one or more processors of a computer system, causes the system to take source code 206 as input and generate a circuit. The compiler 202 may refer to a computer program that executes or performs instructions based on instructions that have been compiled into a machine-readable format, such as binary code. Although a compiler 202 is shown, it should be noted that interpreters, assemblers, and other suitable software and / or hardware components may be utilized to convert source code into a circuit. In an embodiment, the circuit is an arithmetic circuit that includes wires that carry values ​​from a field F and connect to logic gates and / or arithmetic gates. In an embodiment, the circuit is a ... C is the original circuit C is used by the system to generate a quadratic program Q208 that contains a set of polynomials that provides a complete description of

[0062] In one embodiment, the compiler 202 is capable of recognizing essential parts of a programming language such as C or Java, including, but not limited to, preprocessor directives, static initializers, global and local functions, block scope variables, arrays, data structures, pointers, function calls, functional operators (e.g., functors), conditionals and loops, arithmetic and bitwise logical operators, etc. In an embodiment, the compiler 202 does not support the entire set of commands that conform to the programming language standard (which in some cases may be intended to prevent certain algorithms from being executed in a smart contract, such as disallowing recursive algorithms). In an embodiment, the compiler extends the representation of the source code into an arithmetic gate language and generates arithmetic circuits. Circuit implementations have been previously discussed by Campanelli, M., et al. (2017) in “Zero-Knowledge Contingent Payments Revisited: Attacks and Payments for Services” and by Tillich, S. and Smart, B in “Circuits of Basic Functions Suitable For MPC and FHE.” The computational circuitry may be utilized by a compiler 202 or any other suitable hardware, software, or combination thereof (e.g., software modules not shown in FIG. 2) to construct a quadratic computation problem (QAP). The quadratic program is compiled into a set of cryptographic routines for the client (e.g., key generation and verification) and the prover (e.g., computation and proof generation) according to an embodiment.

[0063] In an embodiment, the key generator 204 is hardware, software, or a combination thereof that includes executable code that, when executed by one or more processors of a computer system, causes the system to generate evaluation and verification keys from a quadratic program. Techniques for encoding computations as quadratic programs are discussed in “Quadratic Span Programs and Succinct NIZKs without PCPs” by Gennaro, R., et al. (2013). In an embodiment, a Quadratic Assignment Problem (QAP) Q encodes a circuit C with respect to a field F and includes a set of m+1 polynomials: V={v k (x)},W={w k (x)},Y={y k (x)} where 0 ≤ k ≤ m. The target polynomial t(x) is also defined. Given a function f that takes n elements of F as input and n' elements as output, (N=n+n'), {c1,...,c N}∈F N is a valid specification of the input and output groups of f, and we divide p(x) by t(x) by the list of coefficients {c N+1 ,...,c m}, then Q computes f:

number

[0064] In an embodiment, constructing a QAP of an arithmetic circuit involves providing an arbitrary root r for each multiplication gate g in the circuit. g Pick up ∈F and set t(x)=Π g (xr g), in an embodiment, an index k∈{1...m} is associated with each input of the circuit, and each output from the multiplication gate. The polynomial in V encodes the left input to each gate, W encodes the right input to each gate, and Y encodes the output. For example, if the kth wire is the left input to gate g, then v k (r g )=1, otherwise v k (r g ) = 0. Therefore, for a particular gate g and its route r g For , the preceding equation can be simplified to:

number

[0065] In an embodiment, the QAP is a field F p is defined above, where p is a large prime number. In an embodiment, it is desirable for a QAP over Fp to efficiently compute any function that can be expressed by addition and multiplication modulo p. The arithmetic split gate is k-1 A Boolean gate can be designed to convert an operation wire a∈Fp, known to be [0,2 ], into k binary output wires. Thus, it follows from the fact that Boolean functions can be expressed using operation gates. For example, NAND(a,b)=1-ab. Each built-in Boolean gate costs only one multiplication. Furthermore, new gates such as split can be defined as standalone and composed with other gates. k-1 For a given input a ∈ Fp, known to be in Σ k 2 i-1 ai = a, where a1,...,a are the binary digits of a such that a k Output k wires that hold each a i is either 0 or 1.

[0066] Finally, the public parameters to be used by all provers and verifiers are generated by the system as part of the setup phase. K and the verification key V K It should be noted that the evaluation key E is derived using a secret value selected by the client. K 210 and verification key V K To generate 212, a quadratic arithmetic program (QAP) can be utilized in conjunction with the key generation algorithm.

[0067] In an embodiment, performing the computational task includes computing a function on the input 216 by the prover (i.e., the process of evaluating f(x)). In an embodiment, the prover is any suitable computer system to which a client may delegate a computational task. The input 216, in an embodiment, includes information verifying the identity of the prover, such as a digital signature generated using a private key associated with the prover. In an embodiment, the prover is a computer system to which, as a result of success, the client transfers a digital asset. The client, in an embodiment, receives the input x and an evaluation key E K to the prover, which uses the evaluation module 214 to compute an output y (i.e., y=f(x), where the input is x and the function is f) and generate an evaluation key E K 210 to generate a proof of correctness 218. The evaluation module, in an embodiment, is hardware and / or software that includes instructions that, when executed by one or more processors of a computer system, cause the computer system to evaluate values ​​of the internal circuit wires of the QAP 208 and generate an output y of the QAP.

[0068] In an embodiment, each polynomial v of the quadratic program k (x)∈F is an element g in the bilinear group vk(s) where s is a secret value selected by the client, g is the generator of the group, and F is the field of discrete logarithms of g. In an embodiment, for a given input, the prover maps the coefficient c i Evaluate the circuit to obtain the outputs and values ​​of the internal circuit wires that correspond to g v(s) To obtain v(s)=Σ k∈{m} c k ·v k Evaluate (s); calculate w(s) and y(s); h(x) = p(x) / t(x) = Σ d h i x i Calculate h in the evaluation key. i and g s(i) Using g h(s) In an embodiment, the proof of correctness 218 is calculated as (g v(s) ,g w(s) ,g y(s) ,g h(s) ), where the verifier uses a bilinear map to check p(s)=h(s)·t(s). In an embodiment, the proof π may be stored in the blockchain 222 for later use or may be verified by multiple parties without requiring the prover to interact with each of them individually. In an embodiment, evaluation of the circuit storage of the proof of correctness may be performed to unlock resources (e.g., digital assets) that are restricted by the transaction's locking script.

[0069] In an embodiment, the proof π is broadcast to the blockchain network and a verifier 220 is used to verify the proof. In an embodiment, the verifier 220 is any suitable computing entity, such as a node on the blockchain. Further, in some cases, an evaluation key E K and the verification key V KIt should be further noted that the same computing entity that generates the proof also verifies the proof. In an embodiment, the nodes of the blockchain generate a verification key E K and the proof π can be used to verify the locking transaction, and if the verification is successful, the contract is validated. One requirement of the protocol is that a prover must be able to verify an invalid proof, even if the verification key V K Therefore, in this protocol, the common reference string (CRS) is provided by the client, or at least by the evaluation key E K and the verification key V K In an embodiment, a public verification key V K It can be used by any computing entity to validate computations.

[0070] Using the techniques described herein, a client can partially obfuscate transaction data, such as the identities of recipients of a blockchain transaction. In an embodiment, the unlocking script does not reveal the recipient's address and the recipient's public key. However, in some cases, the value of the transaction (e.g., the amount of digital assets transferred) may be visible to nodes of the blockchain network. In an embodiment, the cryptographic techniques described above and below are used by the client to convert the locking script into a quadratic computation program, and by the prover to solve the computation program to generate a proof.

[0071] In general, a client may use standard transactions such as P2PK and P2PKH (e.g., standard transactions as defined in a Bitcoin-based blockchain network) to make payments to a counterparty or prover. For example, in embodiments, a client converts a P2PK locking script into an arithmetic circuit and broadcasts a locking transaction that includes a puzzle derived from the circuit. The counterparty or prover receives the circuit, provides appropriate inputs (e.g., information that proves the prover's identity, such as a secret shared between the client and the prover, or a digital signature generated using the prover's secret key), and runs the circuit to generate a proof of correctness π. In embodiments, the proof is used to unlock a resource (e.g., a digital asset), and further information identifying the counterparty or prover (e.g., a public key and / or a digital signature associated with the counterparty or prover) may not be recorded on the blockchain in an unambiguous format.

[0072] In an embodiment, the verification key and corresponding proof are generated according to the techniques described above and / or below. Thus, the verifier is provided with a given verification key V K and given the proof π:

number

[0073] Given a verification key V K ,Proof π,(a1,a2,...,a N ), divide p(x) by t(x), so (x) = f(x N+1 ,...,x m ), the verifier proceeds as follows. First, it checks all three α terms:

number

number

number

[0074] Thus, taking into account the notation according to the examples described in the above section and in this disclosure, the validation includes a set of checks of the following pairs of elements according to an embodiment:

number

[0075] FIG. 3 illustrates a diagram 300 for tuning the performance of a verifiable computation. The client 302, the prover 304, and the verifier 306 may be nodes of a blockchain network. The client 302 may be any suitable computer system capable of including executable code that, when executed by one or more processors of the computer system, causes the computer system to receive a smart contract 308. In an embodiment, the smart contract 308 is encoded in a high-level programming language as source code, such as C, C++, or Java. In an embodiment, software such as a compiler, interpreter, and / or assembler may be utilized to convert the smart contract 308 into arithmetic circuitry 310, which is comprised of "wires" that carry values ​​from a field F and connect to addition and multiplication gates. It should be noted that an operational circuit may refer to a logical circuit that may be realized by a physical circuit including a series of physical gates (e.g., using transistor-transistor logic (TTL) integrated circuits, such as 7400 series gates, flip-flops, buffers, decoders, multiplexers, etc.) connected by physical wires. Although execution of smart contracts 308 is described in the context of FIG. 3 and elsewhere, use of smart contracts is merely one non-limiting example of source code that may be converted into an operational circuit. In an embodiment, client 302 (e.g., alone or in combination with other entities) determines source code for performing a task defined by a set of operations, and execution of the task is delegated to prover 304. In general, verifier 306 may perform tasks related to determining that prover 304 performed the task correctly, such as by verifying the validity of a proof of correctness generated by prover 304.

[0076] In an embodiment, client 302 provides prover 304 with computational circuitry 310, and data provider 318 provides prover with inputs 312 to the circuitry. In some cases, inputs 312 may be data, such as data about real-world states and events. Circuit 310 may be used to generate a quadratic program Q, which includes a set of polynomials that provide a complete description of the original circuit. In either case, prover 304 may execute circuit C or quadratic program Q on inputs 312 and generate one or more intermediate outputs and one final output. In some embodiments, the prover is expected to obtain as output a valid transcript of {C,x,y}, which is the assignment of input wires to circuit wires, where the values ​​assigned to the input wires are for x, the intermediate values ​​correspond to the correct operation of each gate in C, and the values ​​assigned to the output wires correspond to y; if the desired output is incorrect (i.e., y≠P(x)), then there is no valid transcript for {C,x,y}. In an embodiment, the prover is expected to provide a subset of the circuit wire values, and the selected subset of the circuit wire values ​​is not known in advance to the prover.

[0077] In an embodiment, the output y, the values ​​of the internal circuit wires (or a subset thereof), and the evaluation key E K is used to generate a proof of correctness 316. The proof π is stored in the blockchain and can be verified by multiple parties without the prover 304 having to interact with the parties individually. In this way, the verifier 306 generates a public verification key V K and the proof π can be used to verify the locking transaction, thereby verifying the contract. In some cases, the client 302 may reclaim the digital assets restricted by the locking transaction if the verification fails. In some cases, the verifier 306 and the client 302 are the same computer system.

[0078] FIG. 4 illustrates a diagram 400 of an embodiment of the present disclosure. Specifically, FIG. 4 illustrates an environment utilized to execute programs or scripts, such as smart contracts, where data provided by data sources is authenticated and published to a blockchain network. In an embodiment, the client 402, the prover 404, and the data provider 406 are computer systems. In an embodiment, the client 402 refers to a computer system that outsources or delegates the execution of a computational task to another computer system, referred to herein as a prover. In an embodiment, the computational task refers to the evaluation of a function, the execution of a smart contract, etc. In an embodiment, executing the computational task includes the calculation of a circuit and an output based on one or more inputs, where the calculation is performed by the prover on behalf of the client. The circuit can be generated from source code, which is a formal representation of the terms of a contract.

[0079] As described in more detail elsewhere in this disclosure, protocols for smart contract execution on a blockchain may utilize zero-knowledge proofs. In embodiments, smart contract execution may occur as part of transaction validation. To this end, public parameters generated during the setup phase of the protocol are used along with the proof and input / output data to verify the purported correct computational proof provided by the prover and to validate the execution of the contract. The execution phase of the contract may, in some embodiments, rely on input / output data that is external to the blockchain. Generally speaking, external data refers to information that is not available on the blockchain or that cannot be verified from data accessible via the blockchain. External data may be obtained from a variety of sources, such as data feeds and application programming interfaces (APIs). External data may be used in a variety of contexts surrounding smart contracts, including, but not limited to: smart contracts used with securities (e.g., interest rates, derivatives, bonds) that require access to market price feeds for assets and financial applications (e.g., interest rates), peer-to-peer insurance smart contracts that require access to external data (e.g., flight information where the parties are insured against delays, weather data in financial derivatives contracts that use weather data feeds instead of price indexes for crop insurance), trading smart contracts that require GPS data regarding shipments, gambling contracts that require access to random number generators, etc.

[0080] In embodiments, determining when and / or how to execute a smart contract relies on access to external data, such as data about real-world conditions and events. In embodiments, a data provider 406 provides such data, and may in some cases be referred to as a smart oracle. The data returned by the oracle may be in a variety of formats and types, such as a Boolean form indicating whether certain information specified by a party contains specified text, or specified information. In embodiments, this data may be used to organize bets (e.g., the outcome of a binary event, such as the outcome of a boxing match). Floating point values ​​may be used in the context of exchange rates between currencies (including cryptocurrencies) and may be read from the API of some bitcoin exchanges. This type of data may be useful for organizing options and hedging contracts.

[0081] Data provider 406 may also be referred to as an oracle that retrieves and / or provides external data, such as data about real-world conditions and events, and makes the external data available to the blockchain. An oracle may refer to a computing entity that includes executable code that, when executed on one or more processors of a computer system, causes the computer system to generate data and / or data feeds that are compatible with a blockchain (e.g., Bitcoin, Ethereum, and others) that act as a trusted link between the blockchain and a network (e.g., the Internet). An oracle may obtain data from websites, feeds, databases, and other data sources and provide the external data to the blockchain. The external data may include, for example, temperature information, GPS coordinates of a shipment, aeronautical information (e.g., flight status information), and the like.

[0082] In an embodiment, the prover 404 obtains external data from the data provider 406 by: establishing a cryptographically secured communications session with the data provider 406 and making a request over the cryptographically secured communications session; the data provider provides the data in response to the request, the prover receives the data, and in response to receiving the data, requests an attestation of the communications between the parties, and the data provider provides a cryptographically verifiable proof π of the communications between the prover and the data provider during the cryptographically secured communications session. Communications , and digitally signs the proof with the data provider's private key; the prover receives the proof of communication. Generally speaking, a proof of communication is a cryptographically verifiable proof that one or more communications have taken place between a client and a server (e.g., between a prover and a data provider). In an embodiment, the proof may be used to verify the content of a communication between a client and a server, although it should be noted that in some cases, parts of the communication may be redacted, for example, by replacing the redacted information with obscure information (e.g., information in an encrypted or hashed format) or by replacing it with a predefined default value (e.g., information whose disclosure is subject to legal restrictions). In an embodiment, the proof is determined at least in part based on a root value of a Merkle tree as described according to FIG. 6. In an embodiment, the proof (e.g., a proof of communication) is digitally signed using a cryptographic private key accessible to the data provider 406. An entity, such as a certification authority, may issue a digital certificate attesting to a cryptographic public key corresponding to the private key. For the purposes of this disclosure, a proof of communication may be defined as a proof of communication that is at least partially based on π Communications While it is commonly referred to using the notation π Prover It should be noted that it may also be referred to simply as π.

[0083] A certification authority 410 may refer to a computing entity that generates and / or distributes digital certificates that attest that a particular cryptographic key belongs to a particular entity. For example, a digital certificate containing a data provider's public key may be obtained by a computing entity, and such public key may be used in a variety of contexts, such as to encrypt data for secure communications with the data provider, to verify the authenticity of a digital signature purportedly signed by the data provider, etc. While FIG. 4 illustrates an embodiment in which a client 402 has a trust relationship with the certification authority 410 (e.g., the client treats digital certificates properly signed and / or issued by the certification authority as authentic), any suitable trusted computing entity, such as a key management system or key registry, may be utilized.

[0084] The prover 404 performs a π Prover In an embodiment, the input data is utilized to generate π Prover can be stored on the blockchain 408 for later use or verified by multiple parties without requiring a prover to interact with each of them individually. For example, execution of a smart contract to insure parties against flight delays can rely on official flight data obtained from an official aviation authority (e.g., the Federal Aviation Administration in the United States or the Civil Aviation Authority in the United Kingdom) as input data. Generally speaking, the input data does not necessarily have to be from a government source; the parties to the smart contract can agree on a list of entities from which the input data is obtained, and thus the data source can be any suitable computing entity that the client indicates can be trusted to obtain data. The client may specify different lists of trusted entities for different inputs. The list of trusted entities can be selected and / or pruned based on the value of the contract.

[0085] The prover 404 may send the proof of communication to the client 402. In some cases, the data provider 406 may send the proof of communication to the client 402, for example, based on a command from the prover. As discussed above, the proof of communication may be derived based at least in part on the root value of the Merkle tree. For example, the proof of communication may encode information specifying the time interval during which the communication occurred. In one embodiment, as follows:

number

[0086] In other words, the proof of communication is computed using a cryptographic hash function, which is the root value of the Merkle tree (h' final ) and communication time interval (W Time In an embodiment, the inputs to the cryptographic hash function are concatenated or otherwise combined. A Merkle tree is a set of W Time The proof of communication may be generated based at least in part on records exchanged between the parties during a time interval represented by W. The proof of communication may be digitally signed using a cryptographic private key of the data source. In an embodiment, the time during which the conversation takes place is represented by W. Time =[T SessionStart ,T ProofRequest] and is included as part of the proof of communication generated by a server (e.g., data source 504). Note that in addition to and / or instead of transmitting the proof of communication to client 402, prover 404 may store the proof in a secure server (e.g., encrypted under a public key associated with client 402) or in a data storage service of a computing resource service provider. In an embodiment, client 402 stores the proof of communication in a data repository (e.g., a data storage service) and provides client 404 with a uniform resource identifier (URI) or other suitable reference that can be used to retrieve the proof of communication from the data repository. For example, prover 402 performing a recurring task (e.g., capturing flight data for one or more routes over a number of days) may aggregate the captured data into a container in the data repository so that a client can retrieve historical flight data over a time interval (e.g., for a particular route).

[0087] In an embodiment, client 402 receives the proof of communication and a digital signature of the proof of communication. The client can verify that the digital signature is purported to have been signed by the data provider, obtain a public key associated with the data provider (e.g., obtained from a digital certificate issued by certification authority 410), and use the public key to verify the authenticity of the digital signature. If the digital signature is determined to be authentic, client 402 trusts that the proof of communication was generated by the data provider; if not, the proof of communication and the digital signature may be discarded. After verifying the proof of communication, client 402 can verify the proof of correctness in a manner such as that described in connection with FIGS. 2 and 3.

[0088] In some embodiments, a client 402 generates a reputation transaction that indicates that the external data obtained from a particular prover 404 was correct (e.g., the data was the same data provided by a data provider). The reputation transaction indicates whether the provider 404 performed a computational task correctly and / or whether the provider 404 was able to use the external data received from the data provider to perform a computation. Prover After the smart contract is executed, the client may mine π into the blockchain 408 as a record of whether the computation was true or false. Prover π to verify that the input data used to generate the Communications Reputation transactions can be mined into the blockchain indicating reviews of services provided by provers, and positive results can incentivize provers to act honestly and can be used to select provers for subsequent smart contract execution. Reputation transactions are calculated using the Prover 4 may include a first unlocking script that allows a prover to unlock the reputation transaction upon providing sufficient evidence that the input data used in came from the data provider, and a second unlocking script that allows a client to revoke the review. The reputation transaction shown in FIG. 4 may follow those described elsewhere in this disclosure, such as those described below in connection with FIG. 9.

[0089] Generally speaking, in the situation of Figure 4, a client makes a request Req(src, τ, q) that specifies a target source src, a time τ, and a query q. If src is a web server, a cryptographically secured communication session, such as a TLS session, may be required. In embodiments, any cryptographically secured communication session that provides cryptographically verifiable guarantees of authenticity may be used, where messages between the parties are authenticated by Message Authentication Codes (MACs) that are both generated and verified using the same secret key. This means that the server and the recipient of the message must agree on the same key, so that any user capable of verifying a MAC can also generate MACs for other messages. In contrast, a digital signature can provide that a particular message was signed by the holder of a particular private key. An approach to authenticating communications is discussed by Hajjeh and M. Badra in "TLS Sign", which specifies a new sub-protocol called TLSSignOnOff, where the client and server inform their peers when they start or stop sending signed data. After the stop message, the server collects a hash of the conversation and signs it. Various other approaches for authenticating recorded data of cryptographically secured communication sessions can be used (e.g., storing a record of the session and signing the conversation as cryptographically verifiable evidence of the authenticity and / or integrity of the recorded communication), see the following technical literature: “R. Housley and M. Brown, “Transport Layer Security (TLS) Evidence Extensions” and by H. Ritzdorf, K. Wu ..st, A. Gervais, G. Felley, and S. Capkun, “TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing for Disintermediation” They define an evidence window that begins when the client makes a request, and when one of the parties closes the evidence window, a hash of the message and a timestamp of the creation of the evidence are signed by the server, optionally with a secret record hidden.

[0090] FIG. 5 is an exemplary diagram 500 of an embodiment in which a prover 502 obtains data from a data source 504. In an embodiment, a cryptographically secured communication session is established between the prover 502 and the data source 504. Examples of cryptographically secured communication sessions include Transport Layer Security (TLS) and Secure Sockets Layer (SSL) sessions. A cryptographically secured communication session can be utilized to provide a secure connection between the parties. In this context, a secure connection may refer to a cryptographically verifiable assurance of authenticity, integrity, privacy, or any combination thereof. Authenticity may refer to an assurance that a message was created by the party who claims to be the creator of the message. Integrity may refer to an assurance that a received message has not been altered, either intentionally (e.g., by a malicious party) or unintentionally (e.g., as a result of a dropped signal during transmission), from its original form when the message was sent. Confidentiality may refer to encryption of some or all of the message before transmission. In an embodiment, the client (e.g., prover 502) and server (e.g., data source 504) exchange information during a first phase called handshake 508, where a hybrid of asymmetric and symmetric encryption is used to ensure security. The handshake shown in FIG. 5 may be a four-way handshake following the TLS handshake protocol. In an embodiment, the client (e.g., prover 502) sends a ClientHello message that includes parameters such as a client version, a session id, additional features from additional extensions, or a combination thereof. In an embodiment, the handshake begins with a message signaling the server (e.g., data source 504) to begin recording a proof for the conversation. As a result, the server (e.g., data source 504) enters an internal state related to proof generation that lasts until it receives a subsequent request to generate a proof for the communication.In this internal state, the data source 504 may record the content (or portions thereof) of the communications between the prover 502 and the data source 504 exchanged via the cryptographically secured communications session.

[0091] After the handshake (e.g., during the record protocol), outgoing messages are split into blocks, while incoming messages are reconstructed. In an embodiment, the conversation between the parties in a cryptographically protected communication session is stored as a number of records R1,...R i These records can be used to generate proofs of communication, for example by generating a Merkle tree containing a set of leaf nodes, each of which is a record R1,...R i The records shown and described in connection with FIG. 5 can be used to generate a Merkle tree such as the one described in connection with FIG.

[0092] In an embodiment, a record refers to requests and responses that form a conversation between a prover 502 and a data source 504 as part of a cryptographically secured communication session. In some cases, the requests and responses include more information than necessary (e.g., information that is irrelevant to determining the input data the prover 502 requires for execution of a smart contract). In an embodiment, a server (e.g., a data source 504) fills in a template (e.g., in the form of a JSON node with specific fields). The template may be specified during the handshake. As an example, a template for obtaining weather data may have fields for location, date, and temperature. In an embodiment, the request for flight data may include flight status, flight identifier, and date, for example in a format such as {"flightInfo":{"data":{"id":"BA886":[{"validDate":"2017-11-01T07:00:00+0000"},"status":"On time"}]}.

[0093] Once the handshake is complete, the parties (e.g., prover 502 and data provider 504) may send records 510 between each other that include data. For example, the prover 502 may request data from the data provider 504 that can be used as input to evaluate the circuit and generate outputs as part of the execution of the smart contract. After the prover 502 has received enough data to evaluate the circuit, the prover may request a proof of session 512 from the data provider 504. The data provider 504 may be a computer system that has a trust relationship with a client (e.g., a client as described in connection with FIGS. 3 and 4), where the client trusts data generated and / or provided by the data provider; in this context, the client's trust of data from another entity may refer to the client's acceptance of data obtained from the entity as correct and / or the client's acceptance that data published from a trusted source with valid security proofs is authentic and accurate. In an embodiment, the server (e.g., data source 504) may receive π from the completion of the handshake protocol. Communications 5. Generate a proof of communication 516 consisting of a hash root 514 of all records exchanged between the parties during the record protocol until a request to generate a proof of communication 516 is received. Also, in embodiments, in cases where the execution of the data depends on inputs being collected at a particular time (e.g., a flight insurance smart contract that provides protection against delays for a particular flight number on a particular day), Time is also hashed along with the record.

[0094] In an embodiment, a client (e.g., prover 502) Communications The data provider then sends all records and records that have been concatenated, hashed, and digitally signed with the data source's private key. TimeThe final value of the hash chain obtained from the commitments of the parties is then returned. Thus, the data contained in the records communicated between the parties can be used in the execution of the smart contract. The proof of this communication, π Communications can also be fed into an initial smart contract and verified by a dedicated function, thus eliminating the need for a skeptical prover. In an embodiment, the records are hashed together in a Merkle structure, in the manner described in connection with FIG. 6.

[0095] It should be noted that although an embodiment is described in which a session client requests a proof from a session server with respect to FIG. 5, this is not required, and the techniques described herein may also be applied such that a TLS session server requests a proof of communication from a TLS session client.

[0096] 6 is an example diagram 600 of a Merkle tree that may be constructed and / or utilized in accordance with various embodiments described in this disclosure. For example, such a Merkle tree may be constructed in the context of the embodiments described in connection with FIGS.

[0097] In an embodiment, a client computer system and a server computer system establish a cryptographically protected communications session, such as a TLS session, and exchange messages (e.g., records). One or more records R1...R ican be recorded by the server, for example, within a specified time period from completion of a handshake protocol until the server receives a request from the client to generate a proof of communication. In an embodiment, the server includes executable code that, when executed by one or more processors of the server, causes the server to: detect instructions to initiate recording of communications between the client and the server; store records sent and received in the cryptographically secured communications; detect instructions to generate a proof of communication; and generate a Merkle tree based at least in part on the stored records. Various alternatives and extensions to the above process are contemplated. A Merkle tree may refer to a data structure in which each leaf node of the Merkle tree is a hash of a data record, and each non-leaf node is derived, at least in part, from the child nodes of the non-leaf node, using at least a cryptographic hash function. However, it should be noted that the techniques described herein may utilize structures similar to Merkle trees to verify that a particular piece of data is part of a Merkle tree; for example, in an embodiment, the techniques described herein are applied to a structure in which leaf nodes of the tree are data records and non-leaf nodes are derived at least in part from the children of the non-leaf nodes using at least a cryptographic hash function. In an embodiment, the tree data structure described herein is a binary tree. It should be noted that while FIG. 6 illustrates an example of an unbalanced Merkle tree, in some embodiments, the leaf nodes of a Merkle tree are arranged such that the tree is balanced or substantially balanced (e.g., a substantially balanced tree may have all the leaves at a particular depth in the tree).

[0098] In an embodiment, a Merkle tree is a set of one or more records R1...R2 stored (e.g., cached by a server in short-term memory such as RAM). iUpon detecting an indication to generate a proof of communication, records are chronologically selected as leaf nodes of a Merkle tree. Each record is cryptographically hashed with a random salt value, which may be derived from a handshake traffic secret, such as a TLS pre-master secret or master secret. The salt may be a pseudorandom or random number generated using any suitable stochastic process. These salts may be selected such that they are not reused within the context of a particular Merkle tree, or such that the probability that any two salts are the same value is below a threshold probability.

[0099] The first salt and the first record may be input to a cryptographic hash function, and the first salt and the first record are concatenated and hashed (e.g., using a SHA-256 cryptographic hash algorithm). Generally speaking, where a cryptographic hash function is shown, a pre-image resistant function such as a one-way function may be used. Although a salt is used in the illustrative example shown in FIG. 6, generally speaking, the record may be augmented with a nonce, an initialization vector, and any other suitable cryptographic primitive. A first output is generated by running a cryptographic hash algorithm using the first salt and the first record as input. The first output may be hashed with information indicating whether the first record was sent by the client or the service of the session. For example, FIG. 6 shows an embodiment in which information related to the client is prepended to the hash output, in which case the client is the sender of the record, and information related to the service is prepended to the hash output, in which case the service is the sender of the record. The prepended / postpended information may be any suitable information, and fixed client values ​​(e.g., zero) and fixed server values ​​(e.g., one) may be used:

number

[0100] In an embodiment, the tree structure is fixed and values ​​associated with the client or service (e.g., the IP address or MAC address associated with the sender) are prepended / postpended to the Merkle tree. One such example (not shown in FIG. 6) looks like this:

number

[0101] Additional records sent over the cryptographically secured communications session can be created in the manner described above and sequentially hashed together to generate a root node value. In the example shown in Figure 6, each node generates an intermediate node value:

number

[0102] In an embodiment, the final hash value is h' Rlast =H(h Rlast-1 ,h Rlast ), which is the root of the Merkle tree. Rlast is the proof of communication. In an embodiment, h' Rlast is the time interval (e.g., W Time , R1 and R last The proof of communication may be augmented with additional information, such as a timestamp relating to the cryptographic communication session, which may be hashed together to form a proof of communication. The proof of communication may be digitally signed by a private key associated with the service of the cryptographic communication session, where the service is an entity trusted by the smart contract client (e.g., as described in connection with Figures 3 and 4).

[0103] 7 is an example diagram 700 of a Merkle path according to various embodiments described in this disclosure. A Merkle path can be utilized to provide cryptographically verifiable assurance that a particular record (or, more generally, a particular piece of data or information) was communicated during a conversation between a client and a service of a cryptographically secured communication session. A Merkle path can be constructed from a Merkle tree as described in connection with FIG. 6 and can be utilized in the context of the embodiments described in connection with FIGs. 2-5.

[0104] In an embodiment, the prover receives data from a data source, uses the data as input to solve the computational circuit, and generates a proof of correct execution based at least in part on the output of the circuit. The prover may additionally generate a proof that the data used in solving the computational circuit was included in a set of communications between the prover and the data source. In an embodiment, the proof is a Merkle path, the Merkle path including a set of node values ​​of the Merkle tree sufficient to compute a root value of the Merkle tree. The Merkle path may include all, some, or none of the leaf node values ​​of the Merkle tree. The Merkle path may include information about the location of the node values ​​in the Merkle tree. It should be noted that the root node value may be the root node value of a subtree of a larger Merkle tree. The proof may be a proof of correctness π Prover may be encoded into

[0105] In an embodiment, a computing entity may verify that the contents of a particular communication were included in a set of communications between two other computing entities by: receiving from the trusted entity a digital signature over the root node value generated using the private key of the trusted entity and the root node value of the Merkle tree; verifying the authenticity of the digital signature using the public key of the trusted entity; receiving a Merkle path that includes a set of node values, where a node in the set of nodes corresponds to a particular communication that is asserted to have been communicated; calculating an asserted root value from the set of node values; and comparing the asserted root value to the verified root node value.

[0106] Consider the Merkle path 702 shown in FIG. 7, which in an embodiment is derived based on the Merkle tree described in connection with FIG. 6. The Merkle path 702 shown in FIG. 7 can be utilized to verify that a particular record R3 was included as part of a set of communications between a client and a server (e.g., a TLS session). The set of values ​​in the Merkle path 702 can be hashed together to generate a final hash value. In an embodiment, the final hash value is generated based on additional information encoded within or associated with the Merkle path that indicates the order in which the values ​​were hashed together. For example, the Merkle path 702 shown in FIG. 7 can be utilized to verify that a particular record R3 was included as part of a set of communications between a client and a server (e.g., a TLS session). R4 =H(H(h' R2 ,H(0,H(salt C3 ,R3))),h R4 ) can be used to calculate the root value (e.g., h' in FIG. 6). Rlast ), the computing entity determines that record R3 was included as a communication among a set of communications between the parties to the conversation.

[0107] Generally speaking, a Merkle path may point to a set of nodes (or the values ​​of these nodes) of a Merkle tree that are sufficient to compute the value of the root node. The root node may be the root node of a Merkle tree such as that shown in FIG. 7, or a subtree of such a tree. A Merkle path such as the one shown in FIG. 7 may encode the values ​​of two leaf nodes, such that at each depth in the Merkle tree between the leaf node and the root node, exactly one value corresponds to exactly one node in the Merkle tree. However, this is not required: another suitable Merkle path would include the values ​​of each leaf node of the Merkle tree, but such a Merkle path may have larger storage requirements than other Merkle paths such as those shown in FIG. 7.

[0108] 8 illustrates a diagram 800 of a computing environment that may be utilized to implement the protocol according to various embodiments. The protocol may be implemented using blockchain technology to store proofs of correctness that are generated based on data external to the blockchain. In an embodiment, the prover 802, data source 804, client 806, certification authority 808, and blockchain 810 are in accordance with those described elsewhere in this disclosure, and these components may be implemented as a computing system.

[0109] In an embodiment, the prover 802 is a computer system including executable code that, when executed by one or more processors of the computer system, causes the computer system to request data from a data source 804. The data source 804 may be any suitable computing entity having a trust relationship with the client 806. The data may relate to real-world events or, more generally, data that is not available on the blockchain. An example of data that may be requested may be the status of an airline flight for a particular date (e.g., delays, cancellations, on-time arrivals, etc.). The data source 804 may provide the requested data upon request, and the request may be provided in any suitable format, such as in the form of a datagram, a web page, a JSON format, etc. In an embodiment, the prover receives the data and, in response to determining that the data was received, submits a second request to the data source 804 for a proof of communication. The data source 804 generates a proof of communication 812 that provides a cryptographically verifiable assurance that the data was provided to the prover by the data source. The proof of communication may be digitally signed with the private key of the data source, and the authenticity of the digital signature may be verified using a public key associated with the data source. A digital certificate including the public key may be issued by a certification authority 808. The prover 802 and the data source 804 may communicate via a cryptographically secured communication session 814, such as a TLS session, that provides cryptographically verifiable assurances of authenticity, integrity, and confidentiality.

[0110] In an embodiment, the prover 802 receives an operational circuit from a client 806 that encapsulates the terms of a smart contract. The prover 802 is capable of performing computations, where the computations are performed based at least in part on data obtained from a data source 804. The prover 802 takes an output and generates a proof 814 of the correct execution of the circuit that is broadcast and recorded on the blockchain network 810, thereby enabling nodes of the blockchain to verify the smart contract.

[0111] Execution of smart contracts involving off-chain data (e.g., real-world data) depends on different degrees of trust between the parties. To gain trust, a prover can indicate to a client (or some other system that verifies whether the prover is honest) that a particular conversation took place between the prover and a data source that it trusted to generate the data. In an embodiment, the prover provides (818) to the client a Merkle path (e.g., as described in connection with FIG. 7) that includes a record that includes the proof of communication and input data used to evaluate the computation circuit. The client receives the Merkle path and the proof of communication; verifies (820) that a particular record (or data in the record) was part of a communication with the trusted data source by obtaining a public key associated with the trusted data source (e.g., by requesting a digital certificate from a certification authority 808 that includes the public key of the data source) and verifying the authenticity of the digital signature generated with the proof of communication; generates a hash output from the Merkle path; and verifies that the generated hash output matches the received proof of communication. In this way, clients can determine that the inputs to a smart contract were provided by a trusted source.

[0112] In embodiments, the client verifies the proof of correctness (822) using methods as described elsewhere in this disclosure and / or techniques described in UK Patent Application No. 171998.5. The client also generates a reputation transaction (824), which is recorded on the blockchain (826), and may broadcast the client's review to the blockchain network indicating whether the prover acted honestly in fulfilling the execution of said particular smart contract. In this context, "honestly" may refer to the prover using the same data provided by the data source to execute the smart contract, unlike a dishonest entity that uses different inputs to execute the smart contract, thereby resulting in a different outcome of the execution of the smart contract in some embodiments.

[0113] FIG. 9 is an example diagram 900 of a reputation transaction 902 that can be utilized in various contexts, such as the embodiments described in connection with FIG. 4 and FIG. 8. In an embodiment, a reputation transaction is a type of ex post contract execution verification with the assumption that the prover is honest. This type of verification does not affect the execution of the contract, but rather is utilized in an embodiment as a metric that contributes to the prover's reputation. Once the smart contract is executed, clients have the opportunity to consider the services of the prover with the incentive to incentivize the prover and thus improve the performance of the smart contract marketplace. Conversely, provers are incentivized to behave correctly, as whether they do so will directly affect their own reputation and their future potential clients, and clients may select provers based on their reputation (or lack of reputation).

[0114] In an embodiment, a client (e.g., as described in connection with FIG. 4) creates a transaction with an input from a reviewer 904. The reviewer input may be a transaction input signed using the client's private key. Generally speaking, the reviewer input may be any information that provides publicly verifiable proof that the client is a reviewer of the reputation transaction. The reputation transaction has three outputs. The output of Verify 906 may have a public key, a signature, and an associated unlocking script that takes as input a Merkle path. Upon verification, the Merkle path can be used to prove that the record belongs to a conversation proof that was signed and sent by a trusted entity (e.g., a data provider described in connection with FIG. 4). Generally speaking, the output of Verify 906 is a transaction output that includes authentication information that can be used to generate the expected value and the expected value, where the expected value is digitally signed and the authenticity of the digital signature can be verified using the public key, as described above. The authentication information, in an embodiment, is a Merkle path that can be used to generate a root hash value. A second output may be the output of Revoke 908 that includes an address that belongs to the client. In an embodiment, unlocking the revocation output symbolizes that the review is cancelled or revoked. The reputation transaction may also encode the review metadata 910 as a third transaction output that includes information about the prover's identity (e.g., the prover's address), the smart contract the prover executed, and the instructions for the positive review. In a Bitcoin-based embodiment, the reputation metadata 910 is implemented as an OP_RETURN output. In an embodiment, the output may have a nominal amount of digital assets (e.g., dust values) or may have no value at all (as is the case for non-spendable OP_RETURN outputs). A Bitcoin-based system may have a reputation transaction that, in an embodiment, is implemented according to the following: [Table 1]

[0115] It should further be noted that OP_CAT may refer to any opcode, routine, command, or function suitable for concatenating two strings.

[0116] FIG. 10 is an illustration of a process 1000 for generating a proof of communication. In an embodiment, the process 1000 is implemented using hardware, software, or a combination thereof. A suitable system for performing the process includes a data provider as described in relation to FIG. 4. Generally speaking, a system for performing the process 1000 may be any suitable system that is trusted by a computing entity to delegate the execution of a smart contract or other computational task to another computing entity. In this context, trust may refer to a computing entity accepting data originating from and / or broadcast by the trusted entity as correct and / or that data published from a trusted source with valid security proof is authentic and accurate.

[0117] In an embodiment, a system performing process 1000 includes executable code that, when executed by one or more processors of the system, causes the system to establish a cryptographically secured communication session with a computing entity, such as a prover. A client may have a list of trusted sources for data used in the execution of a smart contract, which may be published (e.g., as part of or in association with the smart contract or elsewhere on the blockchain). An example of a cryptographically secured communication session is a TLS session.

[0118] The system may detect (1004) an indication to initiate authentication of a communication between the system and the other party. The indication may be implicitly defined as part of a protocol, e.g., the system may initiate authentication of the communication upon completion of a four-way handshake protocol. In an embodiment, the indication is received by the system as a message according to a recording protocol, the message indicating initiating authentication of the communication. Note that an authentication communication may be referred to as an authentication communication and / or conversation between two or more computing entities. As part of the indication to initiate authentication of the communication, the system may record a timestamp of the time the system initiated authentication of the communication.

[0119] Following an instruction to initiate authentication of the communication, the system may receive and / or transmit data as part of a recording protocol (1006), and the communication (or the data contained therein) may be recorded in any suitable format, such as in short-term memory as a data structure. The stacked boxes shown in association with receiving and transmitting data indicate that multiple records may be received and transmitted, although this is not required, and in one embodiment a single record is received and / or transmitted.

[0120] In an embodiment, after receiving an instruction to begin authenticating a communication, the system may receive an instruction to terminate authentication of the communication with the other party (1008). In an embodiment, the system records a timestamp of when a request to terminate the authenticated communication is detected. In some cases, the termination is detected implicitly, such as by the end of a cryptographically protected communication session.

[0121] In an embodiment, the system generates (1010) a proof of communication based on records (or portions thereof) sent and / or received during the authentication period (i.e., from when the system starts authenticating the communication to when it finishes authenticating the communication). The system may generate the proof of communication by generating a Merkle tree in the manner described in connection with FIG. 7. The root of the Merkle tree may be the proof of communication. In an embodiment, the proof of communication is determined based on the root of the Merkle tree and W_time, which encodes the time interval during which the authenticated communication occurred. The proof of communication may be digitally signed by the system using a private key, and a corresponding public key is accessible by a predefined certification authority that issues digital certificates. In an embodiment, the system is a data provider as described in connection with FIGS. 3-5 and 8. Upon generating the proof of communication, the system may transmit (1014) the proof of communication to the other party of the session (e.g., the prover) and / or other entities (e.g., clients designated by the prover during the session).

[0122] FIG. 11 is an illustration of a process 1100 for executing a program or script using authenticated data, such as a smart contract published to a blockchain network. In an embodiment, external data (e.g., data related to real-world events) is authenticated (trusted), but data obtainable from the blockchain is not. Data referred to in this context may refer to input data used as part of the evaluation of a computational circuit to generate an output used in a smart contract. In an embodiment, process 1100 is implemented using hardware, software, or a combination thereof. Systems suitable for performing this process include provers, such as those described in connection with FIGS. 2-4 and 8.

[0123] In an embodiment, the system determines that external data should be obtained to execute the smart contract on behalf of the client. The system may identify a computing entity from which the data may be obtained (1102), where the computing entity is an entity trusted by the client. The client may publish a list of trusted entities in or associated with the smart contract or elsewhere on the blockchain, and the system selects any suitable trusted entity from which to obtain the external data. In an embodiment, the system establishes a cryptographically secured communications session with the data source (1104). An example of a cryptographically secured communications session is a TLS or SSL session.

[0124] In an embodiment, the system requests external data from a source and receives the data from the data source via a cryptographically secured communication session (1106). External data may be used in a variety of contexts surrounding smart contracts, including but not limited to smart contracts used in securities (e.g., interest rates, derivatives, bonds) that require access to market price feeds for assets and financial applications (e.g., interest rates); peer-to-peer insurance smart contracts that require access to external data (e.g., flight information where parties are insured against delays, weather data for financial derivatives contracts that use weather data feeds instead of price indexes for crop insurance); trading smart contracts that require GPS data for shipments; gambling contracts that require access to random number generators, etc.

[0125] After the system receives the external data, the system may provide instructions to the data source to provide a first attestation that the set of communications occurred as part of a cryptographically secured communications session, the set of communications including that the system received the external data from the trusted data source. The system may receive (1108) the first attestation. The first attestation may be a proof of the communications that is a hash root of a Merkle tree. The first attestation may be a digital signature, the authenticity of which is verifiable by a public key associated with the trusted data source.

[0126] In an embodiment, the system generates a proof (1110) using the data as an input x to an operational circuit C, which is used to generate a secondary program to generate one or more outputs y. In an embodiment, the system (e.g., a prover) obtains as output a valid transcript for {C, x, y}, which is an assignment of values ​​to the circuit wires, such that the value assigned to the input wire is that of x. The system may also generate a proof that the data used as an input to the operational circuit was data obtained from a trusted source. The proof may be a Merkle path, as described elsewhere in this disclosure, such as in connection with FIGS. 6 and 7. The system may broadcast the proof of correct execution of the smart contract to the blockchain (1112). The system may transmit the second proof (e.g., a Merkle path), the first proof (i.e., a proof received from a data source, such as a proof of communication), a public key associated with the trusted entity, or some combination thereof.

[0127] Note that in the context of this disclosure, a pre-image resistant function includes one-way functions, which refers to functions that may not be computationally difficult to compute for their current value, but may not be computationally trivial to determine their previous value from their current value. In some cases, one-way membership functions have not been mathematically proven / provable as one-way, but nevertheless have computationally complex properties that make the function pre-image resistant. One-way functions (also called "valid one-way functions") include, but are not limited to: cryptographic hash functions such as message authentication codes (e.g., hash-based message authentication codes (HMAC)), key derivation functions such as PBKDF2 and bcrypt (e.g., where a password is based at least in part on a plaintext and a cryptographic key), and other secure random functions that may, but do not necessarily have a domain (set of possible inputs) larger than their range (possible outputs). Other functions suitable for various embodiments include, but are not limited to: functions that accept at least plaintext and an encryption key as input, and that have the property of pre-image resistance, such that the probability of randomly generating the input is below a certain threshold, a second type of pre-image resistance (i.e., given an input x1, the probability of randomly generating a different input x2 such that f(x1)=f(x2) is below a certain threshold), and / or collision resistance (e.g., the probability of two different inputs resulting in the same output is below a certain threshold).

[0128] FIG. 12 is an exemplary simplified block diagram of a computing device 1200 that can be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 1200 can be used to implement any of the systems described above. For example, the computing device 1200 can be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 12, the computing device 1200 can include, in an embodiment, one or more processors 1202 that communicate with and are operably coupled to a number of peripheral subsystems via a bus subsystem 1204. In some embodiments, these peripheral subsystems include a storage subsystem 1206 that includes a memory subsystem 1208 and a file / disk storage subsystem 1210, one or more user interface input devices 1212, one or more user interface output devices 1214, and a network interface subsystem 1216. Such a storage subsystem 1206 can be used for temporary or long-term storage of information.

[0129] In some embodiments, the bus subsystem 1204 provides a mechanism that allows the various components and subsystems of the computing device 1200 to communicate with each other as intended. Although the bus subsystem 1204 is shown generally as a single bus, alternative embodiments of the bus subsystem utilize multiple buses. In some embodiments, the network interface subsystem 1216 provides an interface to other computing devices and networks. The network interface subsystem 1216, in some embodiments, serves as an interface for receiving data from the computing device 1200 and transmitting data to other systems. In some embodiments, the bus subsystem 1204 is utilized to communicate data such as details, search terms, etc.

[0130] In some embodiments, the user interface input devices 1212 include one or more user input devices such as a keyboard; a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen integrated into a display; an audio input device such as a voice recognition system, a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 1200. In some embodiments, the one or more user interface output devices 1214 include a display subsystem, a printer, or a non-visual display such as an audio output device. In some embodiments, the display subsystem includes a flat panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 1200. One or more user interface output devices 1214 can be used, for example, to present a user interface and facilitate user interaction with applications performing the described processes and variations thereof, where such interaction is appropriate.

[0131] In some embodiments, the storage subsystem 1206 provides a computer readable storage medium for storing basic programming and data constructs that provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which in some embodiments when executed by one or more processors, provide functionality of one or more embodiments of the present disclosure, are stored in the storage subsystem 1206 in some embodiments. These application modules or instructions can be executed by one or more processors 1202. In various embodiments, the storage subsystem 1206 further provides a repository for storing data used in accordance with the present disclosure. In some embodiments, the storage subsystem 1206 includes a memory subsystem 1208 and a file / disk storage subsystem 1210.

[0132] In an embodiment, memory subsystem 1208 includes multiple memories, such as a main random access memory (RAM) 1218 for storing instructions and data during program execution, and / or a read-only memory (ROM) 1220 in which fixed instructions may be stored. In some embodiments, file / disk storage subsystem 1210 provides non-transient, persistent (non-volatile) storage for program and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media.

[0133] In some embodiments, the computing device 1200 includes at least one local clock 1224. In some embodiments, the local clock 1224 is a counter that represents the number of ticks that have occurred since a particular starting date, and in some embodiments is integrally located within the computing device 1200. In various embodiments, the local clock 1224 is used to synchronize data transfers within the processor and subsystems contained therein for the computing device 1200 with a particular clock pulse, and can be used to coordinate synchronized operation between the computing device 1200 and other systems in a data center. In another embodiment, the local clock is a programmable interval timer.

[0134] The computing device 1200 may be of any of a variety of types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 1200 may, in some embodiments, include other devices that may be connected to the computing device 1200 via one or more ports (e.g., USB, headphone jack, lighting connector, etc.). In embodiments, such devices include ports that accept fiber optic connectors. Thus, in some embodiments, the device converts optical signals to electrical signals that are transmitted to the computing device 1200 via the ports connecting the devices for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 1200 shown in FIG. 12 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations having more or fewer components than the system shown in FIG. 12 are possible.

[0135] It should be noted that the above-described embodiments are illustrative rather than limiting of the invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be interpreted as limiting the scope of the claims. Words such as "comprises" and "comprises" do not exclude the presence of elements or steps other than those listed in any claim or in the specification as a whole. In this specification, "comprises" means "includes or consists of" and "comprises" means "includes or consists of". A single reference of an element does not exclude a plurality of references of such elements and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain items are recited in mutually different dependent claims does not indicate that a combination of these items cannot be used to advantage.

[0136] (Appendix 1) 13. A computer-implemented method comprising: establishing a cryptographically secured communications session with a computing entity; receiving a communication over the cryptographically secured communications session, the communication including input data for controlling execution of a program published to a blockchain network; receiving a first verification that a set of communications including the data occurred in the cryptographically secured communications session; executing the program utilizing the data, the execution of the program resulting in the generation of a proof of correct execution of the program; generating a second proof that the data was received from the data source based at least in part on the received input data; and providing said proof of correct execution of said program to another computer system; A computer-implemented method comprising: (Appendix 2) 2. The computer-implemented method of claim 1, wherein the first proof has a value based at least in part on a root node of a Merkle tree, the Merkle tree including a set of leaf nodes determined from the set of communications and a set of salt values. (Appendix 3) 3. The computer-implemented method of claim 2, wherein each communication in the group of communications includes a corresponding intermediate node that is determined based on whether the communication is received or sent. (Appendix 4) 4. The computer-implemented method of claim 2 or 3, wherein the value of the first proof is further based at least in part on a time interval of the group of communications and a cryptographic hash output determined from a root node of the Merkle tree. (Appendix 5) 5. The computer-implemented method of claim 2, wherein the second proof is based at least in part on a Merkle path of the Merkle tree, the Merkle path including values ​​of a set of nodes of the Merkle tree, the values ​​of the set of nodes being sufficient to compute a value of the root node of the Merkle tree. (Appendix 6) 6. The computer-implemented method of claim 5, wherein the set of nodes of the Merkle path includes exactly one node at a depth that is neither a leaf nor a root of the Merkle tree. (Appendix 7) 7. The computer-implemented method of any one of claims 1 to 6, wherein the program includes a set of rules agreed to by two or more parties, the method further comprising selecting the computing entity from one or more computing entities trusted by at least one of the two or more parties. (Appendix 8) Detecting a blockchain transaction including a first transaction output including a first locking script and a second transaction output encoding an indication that the proof of proper execution is valid, where a first digital asset associated with the first transaction output is unlockable by an unlocking script, the unlocking script comprising: A public key associated with said computing entity; a digital signature that encodes an expected value, the authenticity of which is cryptographically verifiable using the public key; and Credentials that can be used to generate said expected value; encoding the unlocking the first digital asset by providing at least the public key, the digital signature, and the authentication information; 8. The computer-implemented method of any one of claims 1 to 7, further comprising: (Appendix 9) The blockchain transaction further comprises: A transaction input digitally signed using a private key associated with that other computer system; a third transaction output including a second unlocking script, wherein a second digital asset associated with the third transaction output is unlockable using the private key; 9. The computer-implemented method of claim 8, wherein the second transaction output further encodes an identifier associated with the other computer system. (Appendix 10) 10. The computer-implemented method of claim 8 or 9, wherein the authentication information includes a Merkle path of a Merkle tree, and the expected value is based at least in part on a root node of the Merkle tree. (Appendix 11) 11. The computer-implemented method of any one of claims 1 to 10, wherein the data includes binary data indicating whether an event has occurred or not. (Appendix 12) 12. The computer-implemented method of any one of claims 1 to 11, wherein the data includes information that cannot be verified based on other data in the blockchain. (Appendix 13) 13. The computer-implemented method of any one of claims 1 to 12, wherein the first proof is a digital signature, the authenticity of which is verifiable using a cryptographic public key associated with the computing entity. (Appendix 14) A processor; and memory containing executable instructions; wherein the instructions, when executed by the processor, cause the system to perform a computer-implemented method according to any one of claims 1 to 13. (Appendix 15) A non-transitory computer-readable storage medium having executable instructions stored thereon which, when executed by a processor of a computer system, cause the computer system to at least perform a computer-implemented method according to any one of claims 1 to 13.

Claims

1. 1. A computer-implemented method comprising: establishing a cryptographically secured communications session with a computing entity; receiving a first communication over the cryptographically secured communications session, the first communication including input data for controlling execution of a program; receiving a first proof that a group of communications occurred in the cryptographically secured communications session, the group of communications including the first communication that includes the input data; generating, based at least in part on the received input data, a proof of correct execution of the program and a second proof that the input data was included in the first communication; broadcasting a proof of correct execution of the program onto the blockchain; and transmitting said second proof to a party to said program; A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the first proof has a value based at least in part on a root node of a Merkle tree, the Merkle tree including a set of leaf nodes determined from the set of communications and a set of salt values.

3. The computer-implemented method of claim 2 , wherein each communication in the group of communications includes a corresponding intermediate node that is determined based on whether the communication is received or sent.

4. 4. The computer-implemented method of claim 2 or 3, wherein the value of the first proof is further based at least in part on a time interval of the group of communications and a cryptographic hash output generated from a root node of the Merkle tree.

5. 5. The computer-implemented method of claim 2, wherein the second proof is based at least in part on a Merkle path of the Merkle tree, the Merkle path including values ​​of a set of nodes of the Merkle tree, the values ​​of the set of nodes being sufficient to compute a value of the root node of the Merkle tree.

6. 6. The computer-implemented method of claim 5, wherein the set of nodes of the Merkle path includes exactly one node at a depth that is neither a leaf nor a root of each of the Merkle trees.

7. 7. The computer implemented method of claim 1, wherein the program includes a set of rules agreed to by two or more parties, the method further comprising the step of selecting the computing entity from one or more computing entities trusted by at least one of the two or more parties.

8. The computer implemented method of any preceding claim, wherein the data comprises binary data indicating whether an event has occurred or not.

9. 9. The computer-implemented method of claim 1, wherein the data includes information that cannot be verified based on other data in the blockchain.

10. 10. The computer-implemented method of claim 1, wherein the first proof is a digital signature, the authenticity of which is verifiable using a cryptographic public key associated with the computing entity.

11. A processor; and a memory containing executable instructions; 11. A system comprising: the instructions, when executed by the processor, cause the system to perform the computer-implemented method of any one of claims 1 to 10.

12. A non-transitory computer readable storage medium having executable instructions stored thereon, the instructions, when executed by a processor of a computer system, causing the computer system to at least perform the computer implemented method of any one of claims 1 to 10.

Images