A system and method for authenticating off-chain data based on 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] This invention generally relates to blockchain technology, and more particularly to generating proof-of-conversation that can be verified with Bitcoin scripts, and also to providing information that can be used in recourse. Proof that a given communication occurred during a conversation may utilize a Merkle tree. Data from a conversation or communication may be used as input to correctly execute a program or script. This invention is particularly suited to, but not limited to, use in the generation and execution of smart contracts. [Background technology]

[0002] In this document, the term “blockchain” may refer to any of several 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 also been proposed and developed. For convenience and illustrative purposes, Bitcoin may be mentioned as a useful application of the technology described herein, but Bitcoin is only one of many applications to which the technology described herein 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, also fall within the scope of the present invention. For example, the technology described herein would also benefit from utilizing other blockchain implementations that have similar limitations to Bitcoin regarding the execution of programs or scripts published on blockchain networks that may rely on external data for the blockchain.

[0003] Blockchain can refer to a peer-to-peer electronic ledger, implemented as a computer-based, decentralized system composed of blocks, which may consist of transactions and other information. In some examples, a “blockchain transaction” refers to an input message encoding a structured collection of field values, including data and a set of conditions, the satisfaction of which is a prerequisite for writing to the blockchain data structure with respect to the set of fields. For example, in Bitcoin, each transaction is a data structure encoding the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. In some embodiments, a “digital asset” refers to binary data associated with the right to use. Specific examples of digital assets include Bitcoin, Ether, and Litecoin. As used herein, the term “Bitcoin” is used to include any protocol that is a variation of the Bitcoin protocol. In some implementations, the transfer of control of a digital asset can be accomplished by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block in the blockchain contains the hash of the preceding block, and blocks, together with their predecessors, form a chain, creating a permanent and unchangeable record of all transactions that have been written to the blockchain since its inception.

[0004] In some examples, “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. On a stack, values ​​can be pushed to the top of the stack or popped (removed) from the top of the stack. Various operations performed to manipulate a stack may result in pushing or popping one or more values ​​to or from 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 equal, or 0 if unequal) to the top of the stack. Other operations performed on a stack, such as OP_PICK, may allow items to be selected from locations other than the top of the stack. In some scripting languages ​​used in some embodiments of the present application, there may be at least two stacks: a main stack and an alternate stack. Some operations in the scripting language can move items 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 not, in some cases, be strictly limited to last-in, first-out (LIFO) operations. For example, a stack-based scripting language may support operations that copy or move the nth item in a stack to the top (e.g., OP_PICK and OP_ROLL in Bitcoin, respectively). Scripts written in a stack-based scripting language may be pushed onto a logical stack that can be implemented using any suitable data structure, such as vectors, lists, or stacks.

[0005] Transactions written to the blockchain must be "validated." Network nodes (mining nodes) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. Nodes can have different validity criteria than other nodes. Since validity in the blockchain is consensus-based, a transaction is considered valid if a majority of nodes agree that it is valid. Software clients installed on nodes perform this verification work for transactions that refer to partially unused transaction outputs (UTXOs) by executing UTXO locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, and if other verification conditions are met, where applicable, the transaction is validated by the node. Validated transactions are propagated to other network nodes, and mining nodes can choose to include the transaction in the blockchain. Therefore, for a transaction to be written to the blockchain, it must: i) be verified by the first node receiving the transaction—if the transaction is verified as valid, the node relays it to other nodes in the network; ii) be added to a new block constructed by mining nodes; and iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered approved when a sufficient number of blocks have been added to the blockchain to the point where it is effectively impossible to revoke the transaction.

[0006] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to explore 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 automated tasks and processes not limited to the realm of cryptocurrency. Such solutions would leverage the advantages of blockchain (e.g., persistent, tamper-proof records of events, distributed processing, etc.) while enriching the versatility of their applications.

[0007] This disclosure discloses the technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program may be a machine-readable and executable program recorded in a blockchain transaction. A blockchain-based computer program may contain rules that are capable of processing inputs to produce results, and that then cause 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 written in natural language, a smart contract may be a computer program designed to automate the execution of machine-readable contract or agreement terms.

[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 confidential or secret items can be represented by tokens that do not have a recognizable meaning or value. Thus, tokens act as identifiers that allow real-world items to be referenced from the blockchain.

[0009] In some embodiments, interactions with a particular entity can be encoded in specific steps of a smart contract, but the smart contract can be automatically executed and self-enforced in other ways. This is machine-readable and executable. In some examples, automatic execution refers to the execution of a smart contract that is successfully executed to enable the transfer of a UTXO. Note that in such examples, the “entity” capable of triggering the transfer of a UTXO refers to an entity capable of creating an unlocking script without being required to prove any secret information. In other words, an unlocking transaction can be validated without verifying that the data source (e.g., the entity that created the unlocking transaction) has access to cryptographic secrets (e.g., private asymmetric keys, symmetric keys, etc.). Also in such examples, self-enforcement refers to the execution of an unlocking transaction by a validation node on the blockchain network, in accordance with the constraints. In some examples, “unlocking” a UTXO refers to creating an unlocking transaction that references the UTXO and executes it as valid.

[0010] Blockchain transaction output includes a locking script and information about ownership of a digital asset, such as Bitcoin. A locking script, sometimes referred to as an encumbrance, "locks" a digital asset by specifying the conditions that must be satisfied in order to transfer a UTXO. For example, a locking script can require certain data to be provided in an unlocking script in order to unlock the associated digital asset. In Bitcoin, a locking script is also known as a "scriptPubKey." The technique of requiring parties to provide data to unlock a digital asset involves embedding a hash of the data within the locking script.

[0011] The present invention can be described as a system and method for executing smart contracts on a blockchain capable of utilizing zero-knowledge proofs. Execution of smart contracts can be performed as part of transaction verification. As part of smart contract execution, it may be desirable to obtain access to data outside the blockchain (e.g., off-chain data), such as data relating to real-world states and events. The technology described herein may be used when data provided by a data source is authenticated and used to execute a program or script, such as a smart contract, which is then exposed to the blockchain network. While digital assets may be used as cryptocurrencies in some embodiments, in embodiments, digital assets are assumed to be additionally or alternatively usable in other contexts. It should be noted that while the present invention is applicable to the control of digital assets, by its nature it is technical and can be used in other contexts utilizing blockchain data structures that do not necessarily involve the transfer of digital assets. [Overview of the project]

[0012] Therefore, it is desirable to provide methods and systems that improve blockchain technology in one or more of these aspects. Such improved solutions have now been devised. That is, according to the present invention, the methods defined in the appended claims are provided.

[0013] Such improved solutions have now been devised.

[0014] In other words, the present invention provides a system and method as defined in the appended claims.

[0015] According to the present invention, it is possible to provide a method for running on a computer for blockchain nodes, and the method for running on a computer is: Steps to establish a cryptographically secure communication session with a computing entity; A step of receiving communications containing input data that controls the execution of a program published on a blockchain network, within a cryptographically protected communication session; A step of receiving first proof that a set of communications, including data, occurred in a cryptographically protected communication session; Based at least partially on the received input data, the proper execution of the program is determined. The steps involve generating a proof and a second proof that the data was received from the data source; This includes the step of providing a proof of the proper execution of the program to another computer system.

[0016] The present invention may be described to include, additionally or alternatively, the following steps: Steps to establish a cryptographically secure communication session with a computing entity; A step of receiving communications containing input data that controls the execution of a program published on a blockchain network, within a cryptographically protected communication session; A step of receiving first proof that a set of communications, including data, occurred in a cryptographically protected communication session; A step of generating a proof of the proper execution of the program and a second proof that the data was received from a data source, based at least in part on the received input data; and This is a step that provides proof of the program's proper execution to other computer systems.

[0017] The first proof is that the root node of a Merkle tree may have a value that is at least partially based on the root node, and the Merkle tree includes a group of leaf nodes determined from a group of communications and a group of salt values.

[0018] A communication within a group of communications may include a corresponding intermediate node, determined based on whether the communication was received or transmitted. In some cases, each communication within a group of communications may include such a corresponding intermediate node.

[0019] The value of the first proof is at least partially based on the cryptographic hash output generated from at least the root node of the Merkle tree and the time interval of a group of communications. A specific 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 at least partially based on the Merkle path of a Merkle tree, the Merkle path containing the values ​​of the set of nodes of the Merkle tree, and the values ​​of the set of nodes sufficient to compute the value of the root node of the Merkle tree.

[0021] Preferably, the set of nodes in a Merkle path contains at most one node at each depth that is neither a leaf nor the root of the Merkle tree. In some cases, a Merkle path contains exactly one node at each depth that is neither a leaf nor the root 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 a step of selecting one or more computing entities to establish cryptographically secure communication with at least one of the two parties.

[0023] Preferably, this method A step of detecting a blockchain transaction including a first transaction output and a second transaction output, wherein the first transaction output includes a first locking script, the first digital asset associated with the first transaction output is unlocked by an unlocking script, and the unlocking script is: Public keys associated with computing entities, A digital signature that encodes an expected value, the authenticity of the digital signature is cryptographically verifiable using a public key, and authentication credentials can be used to generate the expected value. The second transaction output encodes instructions for a proof of proper execution; and This may include a step of unlocking the first digital asset by providing at least a public key, digital signature, and authentication information.

[0024] Blockchain transactions are further, Transaction inputs digitally signed using private keys associated with other computer systems; A third transaction output containing a second unlocking script, wherein the second digital asset associated with the third transaction output is unlockable using a private key; The second transaction output may include identifiers associated with other computer systems, which further encodes them.

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

[0026] The data may include binary data indicating whether or not an event occurred.

[0027] The data may include information whose authenticity cannot be verified based on other data on the blockchain.

[0028] Preferably, the first proof is a digital signature, and the authenticity of the digital signature can be verified using a cryptographic public key associated with the computing entity.

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

[0030] Furthermore, it is desirable to provide a non-temporary, computer-readable storage medium containing executable instructions, which, as a result of execution by one or more processors of the computer system, cause the computer system to perform at least one of the methods for which protection is claimed.

[0031] Additionally or alternatively, the present invention may provide improved blockchain programming tools or support means. These may provide improved, efficient, and optimized configurations that facilitate or enable distributed, verifiable computations. [Brief explanation of the drawing]

[0032] These and other aspects of the present invention will be apparent from and will be illustrated by reference to the embodiments described herein. Herein, embodiments of the present invention are described with reference to the accompanying drawings as merely illustrative.

[0033] [Figure 1] This demonstrates a blockchain environment where various implementations are possible.

[0034] [Figure 2] This describes a computing environment that may be used to implement the protocol according to various embodiments.

[0035] [Figure 3] This diagram shows an environment suitable for performing verifiable calculations.

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

[0037] [Figure 5] This diagram shows a protocol for retrieving data from a data source used to execute a program or script.

[0038] [Figure 6] A diagram of a Merkle tree according to an embodiment is shown.

[0039] [Figure 7] A diagram of the Merkle path according to an embodiment is shown.

[0040] [Figure 8] A diagram of a protocol for generating and verifying proofs, used in relation to various embodiments, is shown.

[0041] [Figure 9] A diagram of a reputation transaction according to an embodiment is shown.

[0042] [Figure 10] This is a diagram illustrating the process of generating a communication proof.

[0043] [Figure 11] This is a diagram illustrating the process of executing a program or script using authenticated data.

[0044] [Figure 12] This document describes a computing device that can be used to implement at least one embodiment of the present disclosure. [Modes for carrying out the invention]

[0045] First, refer to Figure 1, which shows an exemplary blockchain network 100 relating to a blockchain according to an embodiment of the present disclosure. In the embodiment, the exemplary blockchain network 100 includes blockchain nodes implemented as peer-to-peer distributed electronic devices, each node running an instance of software and / or hardware that performs operations in accordance with a blockchain protocol agreed at least partially among the operators of the nodes 102. In some examples, “node” refers to a peer-to-peer electronic device distributed across the blockchain network. An example of a blockchain protocol is the Bitcoin protocol.

[0046] In some embodiments, node 102 can be composed of any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, laptop computer, tablet computer, smartphone, etc.), multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device such as computing device 800 in Figure 8). In some embodiments, node 102 has an input for receiving data messages or objects representing a proposed transaction, such as transaction 104. In some embodiments, the node is queryable for information held by the node (e.g., information about the state of transaction 104).

[0047] As shown in Figure 1, several nodes 102 are communicatively connected to one or more other nodes 102. Such communication connections can include one or more wired or wireless connections. In this embodiment, each node 102 maintains at least a portion of the "ledger" of all transactions in the blockchain. In this way, the ledger becomes a distributed ledger. Transactions processed by nodes that affect the ledger are verifiable by one or more other nodes so as to maintain the integrity of the ledger.

[0048] Regarding which node 102 can communicate with which other nodes, assuming that the blockchain protocol indicates that a message should be forwarded, it is possible that each node in the exemplary blockchain network 100 is able to communicate with one or more other nodes 102, and as a result, messages passed between nodes are propagated throughout the exemplary blockchain network 100 (or a significant portion of it). One such message may be the publication 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 publication of a new block proposed for inclusion in the blockchain.

[0049] In this embodiment, at least some of the nodes 102 are miner nodes that perform complex computations, such as solving cryptographic problems. The miner nodes that solve the cryptographic problems create a new block for the blockchain and broadcast the new block to the other nodes 102. The other nodes 102 verify the work of the miner nodes and, based on the verification, accept the block into the blockchain (for example, 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., hash) and a timestamp of the previous block. In this way, each block can be linked to the previous block, thereby creating a "chain" that links the blocks of the blockchain. In this embodiment, valid blocks are added to the blockchain by consensus of the nodes 102. Also in some examples, the blockchain contains a list of verified blocks.

[0050] In one embodiment, at least some of the nodes 102 operate as verification nodes that verify 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 Bitcoin) and conditions for accepting or transferring ownership / control of the digital asset. In some examples, “unlocking transaction” refers to a blockchain transaction that reassociates at least some of the digital assets specified by a preceding UTXO with an entity associated with a blockchain address (e.g., transfers ownership or control). In some examples, “preceding transaction” refers to a blockchain transaction that includes the UTXO referenced by the unlocking transaction. In some embodiments, a 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, a blockchain address is an alphanumeric string associated with an entity from 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 the public key associated with the entity and the blockchain address. In some embodiments, transaction verification involves verifying one or more conditions specified in a locking script and / or an unlocking script. Upon successful verification of transaction 104, the verification node adds transaction 104 to the blockchain and propagates it to node 102.

[0052] The system and method described herein involve a locking script verifying key V KThis relates to protecting against modification, enabling verification of the validity of Proof π, and thereby allowing the execution of the Zero Knowledge Protocol on the blockchain during transaction verification.

[0053] Verifiable computation is a technique that enables the generation of proofs of computations. In embodiments, such a technique is used by a client to outsource the evaluation of a function f with respect to an input x to another computing entity, referred to herein as a prover. In some cases, the client may have limited computational resources, and as a result, it may be impossible for the client to perform the evaluation of the function (for example, the expected runtime of the computation using the computing resources available to the client may exceed a maximum allowable threshold) (although this is not always the case), and the client may generally delegate the evaluation of the function with respect to an input x based on any appropriate criteria such as computation runtime and computational cost (for example, the financial cost of allocating computing resources to perform the evaluation of the function).

[0054] In embodiments, the prober is any suitable computing entity, such as a blockchain node, as described in more detail elsewhere in this disclosure. In embodiments, the prober (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 accuracy of the output y, which can be verified by the client and / or other computing entities, such as other nodes in the blockchain network. The proof, also referred to as an argument, can be verified faster than performing the actual computation, i.e., computational overhead can be reduced by verifying the accuracy of the proof instead of recalculating the function f for input x to determine the accuracy of the output generated by the prober described above (e.g., power overhead, power-related costs, and computing resources being used can be reduced). In zero-knowledge verifiable computation, the prober provides the client with an attestation that the prober knows an input having a particular property.

[0055] An efficient variation of the zero-knowledge proof for knowledge is zk_SNARK (Succcinct Non-interactive ARgument of Knowledge). In embodiments, all pairing-based zk-SNARKs involve a process in which a prober computes a large number of group elements using a general group operation, and a verifier verifies the proof using a large number of pairing-product equations. In embodiments, the linear interactive proof operates over a finite field, and the prober and verifier messages contain, encode, reference, or otherwise include information that can be used to determine the vector of field elements.

[0056] In embodiments, the systems and methods described herein enable a blockchain mining node to perform a computation (e.g., an evaluation of a function f with respect to an input x) once and generate a proof that can be used to verify the accuracy of the output, where evaluating the accuracy of the proof is less computationally expensive than evaluating the function. In this context, the cost of an operation and task (i.e., how expensive it is) can refer to the complexity of the computation required to perform the operation or task. In embodiments, computational complexity can refer to the average or worst-case computational cost of performing a classification algorithm, for example, both the heapsort and quicksort algorithms have an average computational cost of O(n logn), while quicksort has an average computational cost of O(n logn). 2 While heapsort has a worst-case computational cost of (n log n), heapsort has a worst-case computational cost of (n log n). In embodiments, the average computational cost and / or worst-case computational cost for evaluating a function f with respect to input x is less than the cost for evaluating the accuracy of the proof. Thus, the use of the systems and methods described herein is highly advantageous, for example, because more computationally intensive and high-cost contracts can be executed, since such contracts do not proportionally increase the time required to verify the 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 when evaluating the accuracy of the proof.

[0057] In this embodiment, verification key V K Or a part thereof, generated during the setup phase of the zero-knowledge protocol and used with proof π, and extracted from input / output data to verify the proof of the claimed correctness of the proper calculation provided by the proofer. For example, as described in the detailed descriptions above and below, the system and method use verification key VK This protects against modification, enables a locking script to verify the validity of proof pi, and allows the execution of a zero-knowledge protocol on the blockchain during transaction verification. Accordingly, this disclosure provides a system and method for performing a verification phase using a blockchain script (e.g., a Bitcoin-based network) to store the elements used to verify the computation.

[0058] Figure 2 shows a computing environment 200 that can be used to implement the protocol in various embodiments. This protocol may be implemented using blockchain technology to store proof-of-correctness and combine "collect-by-construction" cryptography with smart contracts. In embodiments, the publicly verifiable computing scheme includes three phases: a setup phase, a computing phase, and a verification phase.

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

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

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

[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, function operators (e.g., functors), conditions and loops, arithmetic and bitwise logical operators. In an embodiment, the compiler 202 does not support the entire set of commands that conform to the programming language standard (this may be intended to prevent certain algorithms from being executed in smart contracts, such as prohibiting recursive algorithms in some cases). In an embodiment, the compiler extends the representation of the source code into an arithmetic gate language and generates arithmetic circuits. The implementation of the circuit has been previously discussed in the following literature: 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 arithmetic circuit may be used to construct a quadratic arithmetic problem (QAP) by compiler 202 or any other suitable hardware, software, or a combination thereof (e.g., a software module not shown in Figure 2). The quadratic program is compiled, according to the embodiment, into a set of cryptographic routines for the client (e.g., key generation and verification) and the proofer (e.g., calculation and proof generation).

[0063] In an embodiment, when the key generator 204 is executed by one or more processors of a computer system, it is hardware, software, or a combination thereof that includes executable code for causing the system to generate an evaluation key and a verification key from a quadratic program. Techniques for encoding computations as quadratic programs are discussed in the following literature: "Quadratic Span Programs and Succinct NIZKs without PCPs" by Gennaro, R., et al. (2013). In an embodiment, the 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)} Here, 0 ≤ k ≤ m. A target polynomial t(x) is also defined. Given a function f that takes n elements of F as input and outputs n' elements (where N = n + n'), when {c1,..., c N} ∈ F N is a valid specification of the input and output groups of f, and there exists a list of coefficients {c N+1 ,..., c m} such that p(x) is divisible by t(x), Q computes f:

Equation

[0064] In an embodiment, constructing the QAP of an arithmetic circuit involves picking an arbitrary root r g ∈ F for each multiplication gate g in the circuit and setting t(x) = Π g (x - r gThis involves defining the target polynomial such that ). In the embodiment, the index k ∈ {1...m} is associated with each input of the circuit and each output from the multiplication gate. The polynomial of 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 k-th wire is the left input to gate g, then v k (r g ) = 1, otherwise v k (r g ) = 0. Therefore, a specific gate g and its root r g With respect to this, the preceding equation can be simplified as follows:

number

[0065] In this embodiment, QAP is in field F p Defined above, where p is a large prime number. In the embodiment, it is desirable that the QAP on Fp efficiently compute any function that can be expressed by addition and multiplication modulo p. The arithmetic partition gate is [0,2 k-1 It is possible to design an operational wire a∈Fp known to be [0,2] to be converted into k binary output wires. Thus, it follows the fact that Boolean functions can be represented using operational gates. For example, NAND(a,b)=1-ab. Each incorporated Boolean gate has only one multiplication cost. Furthermore, new gates such as split can be defined as standalone and constructed with other gates. k-1 Given an input a∈Fp known to be within ], the split gate is Σ k 2 i-1 ai a1, ..., a of the binary digits of a such that = a k Output k wires that hold a i It is either 0 or 1.

[0066] Finally, the public parameters to be used by all proofers and verifiers are generated by the system as part of the setup phase. Evaluation Key E K and verification key V K It should be noted that this is derived using a secret value selected by the client. The key generator 204 uses evaluation key E K 210 and verification key V K To generate 212, a quadratic operation program (QAP) can be used in relation to the key generation algorithm.

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

[0068] In this embodiment, each polynomial v of the quadratic program k (x)∈F is an element g within a bilinear group vk(s) It is mapped to, where s is a secret value selected by the client, g is the group generator, and F is the field of the discrete logarithms of g. In an embodiment, for a given input, the prober is the coefficient c of the quadratic program. i The circuit is evaluated to obtain the output and value of the corresponding internal circuit wires. Therefore, the prober is 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 evaluation key i and g s(i) Using g h(s) It is possible to calculate the proof of correctness 218. In the embodiment, the proof of correctness 218 is (g v(s) ,g w(s) ,g y(s) ,g h(s) The proof includes a bilinear map to verify p(s) = h(s)·t(s). In an embodiment, proof π can be stored in blockchain 222 for later use or can be verified by multiple parties without requiring the proof to interact with each of them individually. In an embodiment, the evaluation of proof-of-correctness circuit memory may be performed to unlock resources (e.g., digital assets) that are restricted by the transaction locking script.

[0069] In this embodiment, proof π is broadcast to the blockchain network, and verifier 220 is used to verify the proof. In this embodiment, verifier 220 is any suitable computing entity, such as a node on the blockchain. Furthermore, in some cases, evaluation key E K and verification key V KIt should also be noted that the same computing entity that generates the proof also verifies the proof. In this embodiment, a node in the blockchain verifies the proof key E. K It is possible to verify locking transactions using proof π, and if verification is successful, the contract is activated. One requirement of the protocol is that the proofer will not accept invalid proofs, even if the verification key V K Even if we knew about it, we couldn't provide it. Therefore, in this protocol, the Common Reference String (CRS) is provided by the client, or at least the evaluation key E K and verification key V K It is generated by a trusted third party that issues it. In this embodiment, the publicly disclosed verification key V K This can be used by any computing entity to verify calculations.

[0070] Using the techniques described herein, a client can partially obscure transaction data, such as the identifier of the recipient of a blockchain transaction. In embodiments, 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 being transferred) may be visible to nodes in the blockchain network. In embodiments, the cryptographic techniques described above and below are used by the client to convert the locking script into a quadratic program, and a proofer to solve the program and generate a proof.

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

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

number

[0073] Given verification key V K , Proof π, (a1, a2, ..., a N Under ), divide p(x) by t(x), and therefore (x) = f(x N+1 ,...,x m To verify that this is true, the verifier proceeds as follows: First, it checks all three alpha terms:

number

number

number

[0074] Accordingly, considering the notation in the above sections and the embodiments described herein, verification includes a set of checks for the following pairs of elements according to the embodiments:

number

[0075] Figure 3 shows Figure 300 for tuning the performance of a verifiable computation. The client 302, prober 304, and verifier 306 may be nodes of a blockchain network. The client 302 may be any suitable computer system capable of containing executable code, which, when executed by one or more processors of the computer system, causes the computer system to receive the 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, it is possible to use software such as a compiler, interpreter, and / or assembler to convert the smart contract 308 into an arithmetic circuit 310, which consists of "wires" that carry values ​​from body F and connect to addition and multiplication gates. It should be noted that the arithmetic circuit may refer to a logic circuit that can be realized by a physical circuit that includes a series of physical gates connected by physical wires (e.g., those using transistor-to-transistor logic (TTL) integrated circuits such as 7400 series gates, flip-flops, buffers, decoders, and multiplexers). The execution of the smart contract 308 is described in the context of Figure 3 and other parts, but the use of a smart contract is only a non-exclusive example of source code that can be translated into an arithmetic circuit. In the embodiment, the 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 the execution of the task is delegated to the prober 304. Generally, the verifier 306 can perform tasks related to determining that the prober 304 has performed the task correctly, for example, by verifying the validity of the proof of correctness generated by the prober 304.

[0076] In some embodiments, client 302 provides the prober 304 with an arithmetic circuit 310, and data provider 318 provides the prober with an input 312 to the circuit. In some cases, the input 312 may be data such as data relating to real-world states and events. Circuit 310 may be used to generate a quadratic program Q containing a set of polynomials that provide a complete description of the original circuit. In any case, the prober 304 executes the circuit C or the quadratic program Q with respect to the input 312 and may produce one or more intermediate outputs and one final output. In some embodiments, the prober is expected to obtain as an output a valid transcript of {C,x,y}, which is the assignment of the input wires to the 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 output to be sought is incorrect (i.e., y≠P(x)), there is no valid transcript for {C,x,y}. In one embodiment, the puller is expected to provide a subset of the values ​​of the circuit wires, the selected subset of the circuit wire values ​​being known to the puller in advance.

[0077] In this embodiment, the output y, the value of the internal circuit wire (or a subset thereof), and the evaluation key E are used. K This is used to generate proof of correctness 316. Proof π is stored in the blockchain and can be verified by multiple parties without the proofer 304 needing to interact with each party individually. In this way, the proofer 306 uses the public verification key V K It is possible to verify the locking transaction using proof π and thereby verify the contract. In some cases, client 302 may request the return of the digital assets restricted by the locking transaction if verification fails. In some cases, the verifier 306 and client 302 are the same computer system.

[0078] Figure 4 shows Figure 400 of an embodiment of the present disclosure. Specifically, Figure 4 shows an environment in which data provided by a data source is authenticated and used to execute a program or script, such as a smart contract, which is exposed to a blockchain network. In the embodiment, the client 402, the prober 404, and the data provider 406 are computer systems. In the embodiment, the client 402 refers to a computer system that outsources or delegates the execution of computational tasks to another computer system referred to herein as the prober. In the embodiment, computational tasks refer to things like evaluating functions and executing smart contracts. In the embodiment, executing a computational task involves calculating a circuit and an output based on one or more inputs, the calculation being performed by the prober on behalf of the client. The circuit can be generated from source code, which is a formal expression of the terms of the contract.

[0079] As described in more detail elsewhere in this disclosure, protocols for executing smart contracts on a blockchain may utilize zero-knowledge proof. In embodiments, smart contract execution can occur as part of transaction verification. For this purpose, public parameters generated during the protocol setup phase are used together with proof and input / output data to verify the validity of contract execution by verifying the claimed proof of good computation provided by the proofer. In some embodiments, the contract execution phase may rely on external input / output data for the blockchain. Generally speaking, external data refers to information that is not available on the blockchain or cannot be verified from data accessible via the blockchain. External data can be obtained from various 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 in securities (e.g., interest rates, derivatives, bonds) that require access to market price feeds for asset and financial applications (e.g., interest rates); peer-to-peer insurance smart contracts that require access to external data (e.g., flight information for which parties are insured against delays, weather data for financial derivative contracts that use weather data feeds instead of price indices for crop insurance); trading smart contracts that require GPS data for shipments; and gambling contracts that require access to random number generators.

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

[0081] Furthermore, data provider 406 may be referred to as an oracle, which retrieves and / or provides external data, such as data relating to real-world conditions and events, and makes the external data available to the blockchain. An oracle may refer to a computing entity containing executable code that, when executed on one or more processors of a computer system, causes the computer system to generate blockchain-compatible data and / or data feeds, which act as a trusted link between the blockchain and the network (e.g., the internet). An oracle can retrieve 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 shipments, aerial information (e.g., flight status information), etc.

[0082] In this embodiment, the prober 404 obtains external data from the data provider 406 as follows: establishes an encrypted communication session with the data provider 406 and makes a request through the encrypted communication session; the data provider provides the data in response to the request; the prober receives the data and, in response to receiving the data, requests an attestation of the communication between the parties; and the data provider provides a cryptographically verifiable proof π of the communication between the prober and the data provider during the encrypted communication session. Communications The proof is calculated and digitally signed with the data provider's private key; the proof 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 the proofer and the data provider). In embodiments, the proof can be used to verify the content of communications between the client and the server, but it should be noted that in some cases, parts of the communications may be edited, for example, by replacing edited information with obscure information (e.g., information in an encrypted or hashed format) or by replacing it with a predetermined default value (e.g., information whose disclosure is subject to legal restrictions). In embodiments, the proof is determined at least in part on the root value of a Merkle tree as described in Figure 6. In embodiments, the proof (e.g., a proof of communication) is digitally signed with an encrypted private key accessible to the data provider 406. An entity such as a certification authority can issue a digital certificate that certifies the encrypted public key corresponding to the private key. To the extent of this disclosure, a proof of communication is π Communications While it is commonly referred to using the notation, the proof of proper execution is π Prover It should be noted that it may also be referred to more simply as π.

[0083] The certification authority 410 can refer to a computing entity that generates and / or distributes digital certificates that prove 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 a public key may be used in a variety of situations, such as encrypting data for secure communication with the data provider or verifying the authenticity of a digital signature supposedly signed by the data provider. Figure 4 shows an embodiment in which client 402 has a trust relationship with certification authority 410 (for example, the client treats a digital certificate properly signed and / or issued by certification authority as authentic), but any suitable trusted computing entity such as a key management system or key registry may be utilized.

[0084] Prover 404 performs π in the manner described above in relation to Figure 2. Prover Input data is used to generate π. In the embodiment, π Prover The data can be stored on Blockchain 408 for later use, or it can be verified by multiple parties without requiring a proofer to interact with each of them individually. For example, the execution of a smart contract to guarantee parties against flight delays could rely on official flight data obtained from an official aviation authority (e.g., the US Federal Aviation Administration or the UK Civil Aviation Authority) as input data. Generally speaking, the input data does not necessarily have to be from government sources, and the parties to the smart contract can agree on a list of entities from which the input data is obtained, and therefore the data source could be any suitable computing entity that the client can trust to obtain the data. The client may specify different lists of trusted entities for different inputs. The list of trusted entities can be selected and / or truncated based on the value of the contract.

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

number

[0086] In other words, a proof of a communication is calculated using a cryptographic hash function, and the root value (h') of the Merkle tree is obtained. final ) and communication time interval (W Time In this embodiment, the start time of the encrypted communication session and the time when proof of communication was requested (encoded) are input to a cryptographic hash function. In this embodiment, the inputs to the cryptographic hash function are concatenated or otherwise joined. The Merkle tree is W Time It is possible to generate a proof of communication based at least in part on the records exchanged between the parties during the time interval indicated by W. A proof of communication can be digitally signed using the cryptographic private key of the data source. In an embodiment, the time during which the conversation takes place is W Time =[T SessionStart ,T ProofRequestThe proof of communication is defined as a proof of communication generated by a server (e.g., data source 504) and is included as part of the proof of communication. In addition to sending the proof of communication to client 402, and / or instead, the proof may be stored in a secure server (e.g., encrypted under a public key associated with client 402) or 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 appropriate reference that can be used to retrieve the proof of communication from the data repository. For example, a proofer 402 performing a recurring task (e.g., capturing flight data for one or more routes over several days) aggregates the captured data into a container in the data repository, so that the client can retrieve historical flight data (e.g., for a particular route) over a time interval.

[0087] In this embodiment, client 402 receives a proof of communication and a digital signature of the proof of communication. The client verifies that the digital signature is claimed to have been signed by the data provider, obtains a public key associated with the data provider (for example, obtained from a digital certificate issued by the certification authority 410), and can 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; otherwise, the proof of communication and the digital signature may be discarded. After verifying the proof of communication, client 402 can verify proof of correctness in the manner described in relation to Figures 2 and 3.

[0088] In some embodiments, client 402 generates a reputation transaction indicating that the external data retrieved from a particular prober 404 was correct (for example, that the data was the same data provided by the data provider). The reputation transaction indicates whether provider 404 performed the computation task correctly and / or whether provider 404 used the external data received from the data provider to perform π Prover The calculation performed may be mined into blockchain 408 as a record of whether it was genuine. After the smart contract is executed, the client will have π Prover To verify that the input data used to generate it was provided by the data provider, π Communications It is possible to use this. Reputation transactions can be mined into the blockchain, indicating reviews of the services provided by the prober, and positive results may give the prober an incentive to act honestly and may be used to select the prober for subsequent smart contract execution. Reputation transactions are π Prover The system may include a first unlocking script that allows the proofer to unlock the reputation transaction, provided that sufficient evidence is provided that the input data used is coming from a data provider, and a second unlocking script that allows the client to withdraw the review. The reputation transaction shown in Figure 4 may follow those described elsewhere in this disclosure, for example, those described below in relation to Figure 9.

[0089] Generally speaking, in the scenario shown in Figure 4, the client creates a request Req(src,τ,q) specifying the target source src, time τ, and query q. If src is a web server, a cryptographically protected communication session, such as a TLS session, may be required. In embodiments, any cryptographically protected communication session may be used, which provides cryptographically verifiable assurance of authenticity, where messages between parties are authenticated by a Message Authentication Code (MAC), which is both generated and verified using the same secret key. This means that the server and the message recipient must agree on the same key, and therefore any user capable of verifying the MAC can generate MACs for other messages as well. In contrast, a digital signature can provide that a particular message has been signed by the holder of a particular private key. An approach to authenticating communication is considered by Hajjeh and M. Badra in "TLS Sign," which defines a new subprotocol called TLSSignOnOff, where the client and server notify the peer 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 can be used to authenticate the recorded data of cryptographically protected communication sessions (e.g., storing session records and signing the conversation as cryptographically verifiable evidence of the authenticity and / or completeness of the recorded communications), for which 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” These define an evidence window that begins when a client makes a request, and when either party closes the evidence window, the message hash and the timestamp of the evidence generation are signed by the server, optionally with a confidential record hidden.

[0090] Figure 5 is an exemplary Figure 500 of an embodiment in which a prober 502 retrieves data from a data source 504. In this embodiment, an encrypted communication session is established between the prober 502 and the data source 504. Specific examples of encrypted communication sessions include TLS (Transport Layer Security) and SSL (Secure Sockets Layer) sessions. Encrypted communication sessions can be used to provide a secure connection between parties. In this context, a secure connection may refer to cryptographically verifiable guarantees of authenticity, integrity, privacy, or any combination thereof. Authenticity may refer to a guarantee that the message was created by the person claiming to be the author of the message. Integrity may refer to a guarantee that the received message has not been altered from its original form when the message was sent, either intentionally (e.g., by a malicious actor) or unintentionally (e.g., as a result of signal loss during transmission). Confidentiality may refer to the encryption of part or all of the message before transmission. In the embodiment, the client (e.g., Prover 502) and the server (e.g., Data Source 504) exchange information during a first phase called the handshake 508, and a hybrid of asymmetric and symmetric encryption is used to ensure security. The handshake shown in Figure 5 may be a four-way handshake following the TLS handshake protocol. In the embodiment, the client (e.g., Prover 502) sends a ClientHello message containing parameters such as client version, session ID, additional functionality by additional extensions, or a combination thereof. In the embodiment, the handshake begins with a signal message to 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, which continues until it receives a subsequent request to generate a proof of the communication.In this internal state, data source 504 may record the content (or part thereof) of communications between prober 502 and data source 504, which are exchanged over an encrypted communication session.

[0091] After the handshake (for example, during the recording protocol), the outgoing message is divided into blocks, while the incoming message is reconstructed. In the embodiment, the conversation between the parties of a cryptographically protected communication session is recorded in multiple records R1,...R i These records can be used to generate proof of communication, for example, by generating a Merkle tree containing a set of leaf nodes, where the set of leaf nodes are records R1,...R i This includes the records illustrated and described in relation to Figure 5, which can be used to generate a Merkle tree, such as the one described in relation to Figure 6.

[0092] In embodiments, the record refers to requests and responses that form a conversation between the prober 502 and the data source 504 as part of a cryptographically protected communication session. In some cases, the requests and responses may include more information than necessary (e.g., information irrelevant to determining the input data that the prober 502 needs for the execution of the smart contract). In embodiments, the server (e.g., the 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 might have fields for location, date, and temperature. In the embodiment, the request for flight data may include the flight status, flight identifier, and date, for example in the form of {"flightInfo":{"data":{"id":"BA886":[{"validDate":"2017-11-01T07:00:00+0000"},"status":"On time"}]}.

[0093] Once the handshake is complete, the parties (e.g., the prober 502 and the data provider 504) can transmit a record 510 between them containing data. For example, the prober 502 may request data from the data provider 504 that can be used as input to evaluate a circuit and generate an output as part of the execution of a smart contract. After the prober 502 has received enough data to evaluate the circuit, the prober may request a proof 512 of the session from the data provider 504. The data provider 504 may also be a computer system that has a trust relationship with a client (e.g., the client as described in relation to Figures 3 and 4), where the client trusts the data generated and / or provided by the data provider, and in this context, the client trusting data from other entities may mean that the client accepts the data obtained from the entities as correct, and / or that the data published from trusted sources with valid security proofs is genuine and accurate. In embodiments, the server (e.g., the data source 504) π from the completion of the handshake protocol Communications It generates a proof of communication 516 consisting of hash roots 514 of all records exchanged between the parties during the recording protocol until a request to generate it is received. In embodiments, the execution of data depends on the input being collected at a specific time (for example, a smart contract for flight insurance that provides protection against delays for a specific flight number on a specific day), W Time It is also hashed along with the record.

[0094] In the embodiment, the client (e.g., puller 502) is π Communications The data provider requests all records that have been concatenated, hashed, and digitally signed with the private key of the data source, and W TimeReturns the final value of the hash chain obtained from the 's commit. Thus, the data included 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 supplied to the initial smart contract and can be 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] In connection with FIG. 5, an embodiment is described where the session client requests a proof from the session server, but it should be noted that this is not essential, and the techniques described in the present application may be applied such that the server of the TLS session requests a proof of the communication from the client of the TLS session.

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

[0097] In an embodiment, the client computer system and the server computer system establish a communication session protected by encryption, such as a TLS session, and exchange messages (e.g., records). One or more records R1...R communicated between the parties of the session iThis can be recorded by the server within a specified period, for example, from the completion of the 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, which, when executed by one or more processors of the server, causes the server to: detect an instruction to begin recording communication between the client and the server; store records sent and received via cryptographically protected communication; detect an instruction to generate a proof of communication; and generate a Merkle tree based at least partially on the stored records. Various alternatives and extensions to the process described above are possible. The Merkle tree may be such that each leaf node of the Merkle tree is a hash of a data record, and each non-leaf node may point to a data structure derived at least partially from the child nodes of the non-leaf node, using at least a cryptographic hash function. However, it should be noted that the technology contained herein utilizes a structure similar to a Merkle tree to verify that certain data is part of a Merkle tree, for example, in an embodiment, the technology contained herein is applied to a structure in which the leaf nodes of the tree are data records, and the non-leaf nodes are derived at least partially from the child nodes 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. Figure 6 shows an example of an unbalanced Merkle tree, but it should be noted that in some embodiments, the leaf nodes of the Merkle tree are arranged so that the tree is balanced or substantially balanced (for example, a substantially balanced tree may have all its leaves at a particular depth of the tree).

[0098] In this embodiment, the Merkle tree contains one or more records R1...R stored (e.g., cached by the server in short-term memory such as RAM). iWhen instructions are detected that generate a proof of communication, the records are selected chronologically as leaf nodes in the Merkle tree. Each record is cryptographically hashed with a random salt value that may be derived from a handshake traffic secret, such as a TLS pre-master secret or master secret. The salts may be pseudorandom or random numbers generated using any appropriate stochastic process. These salts may be selected so that they are not reused in any particular Merkle tree context, or so that the probability of any two salts being the same value is below a threshold probability.

[0099] The first salt and the first record can be input to a cryptographic hash function, which is then concatenated and hashed (for example, using the SHA-256 cryptographic hash algorithm). Generally speaking, where a cryptographic hash function is indicated, a pre-image resistant function such as a one-way function may be used. In the exemplary example shown in Figure 6, a salt is used, but generally speaking, the record may be augmented with a nonce, an initialization vector, and any other suitable cryptographic primitive. The 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 a client or a service of the session. For example, Figure 6 shows an embodiment in which client-related information is prepended to the hash output, in which case the client is the sender of the record, and service-related information is prepended to the hash output, in which case the service is the sender of the record. The prepended / postpended information can be any suitable information, and fixed client values ​​(e.g., zero) and fixed server values ​​(e.g., 1) may be used:

number

[0100] In an embodiment, the tree structure is fixed, and values related to the client or service (e.g., the IP address or MAC address related to the sender) are added before / after the Merkle tree. In such an example (not shown in FIG. 6), it is as follows:

Number

[0101] Additional records transmitted via an encrypted communication session are created in the manner described above and can be sequentially hash - combined to generate the root - node value. In the example shown in FIG. 6, each node generates an intermediate node value:

Number

[0102] In an embodiment, the final hash value is calculated as h’ Rlast = H(h Rlast-1 , h Rlast ) and this is the root of the Merkle tree. In an embodiment, h’ Rlast is the proof of communication. In an embodiment, h’ Rlast is enhanced by additional information such as a time interval (e.g., W Time , R1 and R last time stamps related to it), and these can be hash - combined together to form the proof of communication. The proof of communication may be digitally signed by the private key related to the service of the encrypted communication session, and that service is an entity trusted by the smart - contract client (e.g., as described in relation to FIGS. 3 and 4).

[0103] Figure 7 is an exemplary figure 700 of Merkle paths in various embodiments described herein. Merkle paths can be used to provide cryptographically verifiable assurance that a particular record (more generally, a particular piece of particular data or information) has been communicated during a conversation between a client and a service in a cryptographically protected communication session. Merkle paths can consist of a Merkle tree, as described in relation to Figure 6, and can be used in the context of the embodiments described in relation to Figures 2 to 5.

[0104] In an embodiment, the prover receives data from a data source, uses the data as input to solve an arithmetic circuit, and generates a proof of correct execution based at least partially on the output of the circuit. The prover can additionally generate a proof that the data used to solve the arithmetic circuit was contained in a set of communications between the prover and the data source. In an embodiment, the proof is a Merkle path, which contains a set of node values ​​of a Merkle tree sufficient to compute the root value of the Merkle tree. The Merkle path may contain all or some of the leaf node values ​​of the Merkle tree, or none at all. The Merkle path may contain information about the location of 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 is a proof of correctness π Prover It may be encoded as follows.

[0105] In this embodiment, a computing entity can verify that the content of a particular communication was included in a set of communications between two other computing entities by: receiving a digital signature and a Merkle tree root node value generated using the private key of the trusted entity from the trusted entity; verifying the authenticity of the digital signature using the public key of the trusted entity; receiving a Merkle path containing a set of node values ​​(where the nodes in the set correspond to the particular communication that is claimed to have been communicated); calculating the claimed root value from the set of node values; and comparing the claimed root value with the verified root node value.

[0106] Consider the Merkle path 702 shown in Figure 7. This is derived, in embodiments, based on the Merkle tree described in relation to Figure 6. The Merkle path 702 shown in Figure 7 can be used 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 embodiments, the final hash value is encoded within the Merkle path indicating the order in which the values ​​were hashed together, or generated based on additional information associated therewith. For example, the Merkle path 702 shown in Figure 7 can be hashed together to generate a final hash value as shown in Figure 7. R4 =H(H(h' R2 ,H(0,H(salt C3 ,R3))),h R4 It can be used to calculate the square root value (e.g., h' in Figure 6). Rlast If this matches, the computing entity determines that record R3 was included as part of a set of communications between the parties to the conversation.

[0107] Generally speaking, a Merkle path can refer to a set of nodes (or the values ​​of those nodes) in a Merkle tree sufficient to compute the value of the root node. The root node may be the root node of the Merkle tree shown in Figure 7, or a subtree of such a tree. A Merkle path like the one shown in Figure 7 can encode the values ​​of two leaf nodes, so that at each depth of the Merkle tree from a leaf node to the root node, exactly one value corresponds to exactly one node in the Merkle tree. However, this is not mandatory: another suitable Merkle path may include the value of each leaf node in the Merkle tree, but such a Merkle path may have larger storage requirements than the other Merkle path shown in Figure 7.

[0108] Figure 8 shows Figure 800 of a computing environment that may be used to implement the protocol according to various embodiments. The protocol may be implemented using blockchain technology to store proof of correctness generated based on data outside the blockchain. In embodiments, the prober 802, data source 804, client 806, certification authority 808, and blockchain 810 are as described elsewhere in this disclosure, and these components can be implemented as a computing system.

[0109] In this embodiment, the prober 802 is a computer system containing executable code, which, 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 can be any suitable computing entity that has 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 on a specific date (e.g., delays, cancellations, on-time arrivals, etc.). The data source 804 can provide the requested data upon request, and the request can be provided in any suitable format, such as a datagram, web page, or JSON format. In this embodiment, the prober receives the data and, in response to determining that the data has been 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, which provides a cryptographically verifiable guarantee that the data has been provided to the prober by the data source. A proof of the communication can be digitally signed with the private key of the data source, and the authenticity of the digital signature may be verified using the public key associated with the data source. A digital certificate containing the public key may be issued by a certification authority 808. The proofer 802 and the data source 804 can communicate over a cryptographically protected communication session 814, such as a TLS session, which provides cryptographically verifiable guarantees of authenticity, integrity, and confidentiality.

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

[0111] The execution of smart contracts involving off-chain data (e.g., real-world data) depends on varying degrees of trust between the parties. To gain trust, the proofer may indicate to the client (or some other system that verifies the honesty of the proofer) that a specific conversation took place between the proofer and a data source trusted to generate the data. In embodiments, the proofer provides the client with a Merkle path (e.g., as described in relation to Figure 7) containing a record containing input data used to evaluate the proof of communication and arithmetic circuits (818). The client receives the Merkle path and the proof of communication; obtains a public key associated with the trusted data source (e.g., by requesting a digital certificate from a certification authority 808 containing the public key of the data source); verifies that a particular record (or the data of the record) was part of a communication with the trusted data source by verifying the authenticity of the digital signature generated in the proof of communication (820); generates a hash output from the Merkle path; and verifies that the generated hash output matches the received proof of communication. In this way, the client can determine that the input to the smart contract was provided by a trusted source.

[0112] In embodiments, the client verifies proof of correctness using methods as described elsewhere in this disclosure and / or the techniques described in UK Patent Application No. 171998.5 (822). The client also generates a reputation transaction (824), which is recorded on the blockchain (826), and can broadcast a client review to the blockchain network indicating whether the proofer acted in good faith in carrying out the execution of the particular smart contract described above. In this context, “good faith” may mean that the proofer, unlike a dishonest entity, uses the same data provided by the data source to execute the smart contract, which would use different inputs to execute the smart contract, thereby, in some embodiments, producing different results from the execution of the smart contract.

[0113] Figure 9 is an exemplary Figure 900 of a reputation transaction 902 that can be used in various situations, such as the embodiments described in relation to Figures 4 and 8. In embodiments, the reputation transaction is a type of ex-post contract execution verification that assumes the prober is honest. This type of verification, in embodiments, does not affect the execution of the contract but is used as a metric that contributes to the prober's reputation. Once a smart contract is executed, clients have the opportunity to consider the prober's services, with the incentive that encouraging the prober will improve the performance of the smart contract market. Conversely, probers are incentivized to act correctly, as whether they act in this way directly affects their reputation and their future potential clients, and clients may choose a prober based on their reputation (or lack thereof).

[0114] In an embodiment, a client (e.g., as described in relation to Figure 4) creates a transaction with input to 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 a reputation transaction. A reputation transaction has three outputs. The output of verification 906 may have an associated unlocking script that takes a public key, a signature, and a Merkle path as input. During verification, the Merkle path can be used to prove that a record belongs to a conversation proof signed and sent by a trusted entity (e.g., a data provider described in relation to Figure 4). Generally speaking, the output of verification 906 is a transaction output containing the expected value and credentials that can be used to generate the expected value, the expected value is digitally signed, and the authenticity of the digital signature is verifiable using the public key, as described above. The credentials are, in an embodiment, a Merkle path that can be used to generate a root hash value. A second output may be the output of revocation 908 containing an address belonging to the client. In embodiments, unlocking the retraction output symbolizes that the review is canceled or retracted. The reputation transaction may also encode the review metadata 910 as a third transaction output containing information about the prober's identity (e.g., the prober's address), the smart contract executed by the prober, and the instruction for a positive review. In Bitcoin-based embodiments, the reputation metadata 910 is implemented as an OP_RETURN output. In embodiments, the output may have a nominal amount of digital assets (e.g., dust values) or may have no value at all (in the case of an OP_RETURN output that cannot be consumed). A Bitcoin-based system may have a reputation transaction implemented as follows in embodiments: [Table 1]

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

[0116] Figure 10 is an illustrative diagram of process 1000 for generating proof of communication. In embodiments, process 1000 is implemented using hardware, software, or a combination thereof. A suitable system for performing the process includes a data provider, such as those described in relation to Figure 4. Generally speaking, the system performing process 1000 may be any suitable system trusted by a computing entity that delegates the execution of a smart contract or other computational task to another computing entity. In this context, trust may mean that a computing entity accepts data originating from and / or broadcast by that trusted entity as true, and / or that data published from a trusted source, along with valid security proof, is authentic and accurate.

[0117] In an embodiment, the system executing process 1000 includes executable code, which, when executed by one or more processors of the system, causes the system to establish a cryptographically secure communication session with a computing entity such as a prober. The client may have a list of trusted sources for the data used in the execution of the smart contract, and that list may be made public (for example, as part of the smart contract, in connection with it, or elsewhere on the blockchain). An example of a cryptographically secure communication session is a TLS session.

[0118] The system may detect an instruction to initiate authentication of communication between the system and the other party (1004). The instruction may be implicitly defined as part of a protocol, for example, the system may initiate authentication of communication upon completion of a four-way handshake protocol. In embodiments, the instruction is received by the system as a message by a recording protocol, and the message indicates that authentication of communication is to be initiated. Note that authenticated communication may refer to authenticated communication and / or conversation between two or more computing entities. As part of the instruction to initiate authentication of communication, the system may record a timestamp of the time the system initiated authentication of communication.

[0119] Following an instruction to initiate authentication of a 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 as a data structure in any suitable format, such as short-term memory. The stacked boxes shown in relation to the reception and transmission of data indicate that multiple records may be received and transmitted, but this is not mandatory, and in one embodiment, only a single record is received and / or transmitted.

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

[0121] In embodiments, the system generates a proof of communication based on records (or a portion thereof) transmitted and / or received during the authentication period (i.e., from the time the system initiates authentication of communication until it terminates authentication) (1010). The system can generate a proof of communication by generating a Merkle tree in the manner described in relation to Figure 7. The root of the Merkle tree can be the proof of communication. In embodiments, the proof of communication is determined based on a Merkle tree encoding the time interval in which the authenticated communication occurred and the root of W_time. The proof of communication can be digitally signed by the system using a private key, the corresponding public key being accessible by a predetermined authentication authority that issues digital certificates. In embodiments, the system is a data provider described in relation to Figures 3-5 and 8. Once the proof of communication is generated, the system may send the proof of communication to the session partner (e.g., a prober) and / or other entities (e.g., a client specified by the prober during the session) (1014).

[0122] Figure 11 is an illustrative diagram of process 1100, which executes a program or script using authenticated data, such as a smart contract published on a blockchain network. In this embodiment, external data (e.g., data about real-world events) is authenticated (trusted), but data obtainable from the blockchain is not authenticated. The data referred to in this context may refer to input data used as part of the evaluation of an arithmetic circuit to generate the output used in the smart contract. In this embodiment, process 1100 is implemented using hardware, software, or a combination thereof. A suitable system for performing this process includes a puller, such as those described in relation to Figures 2-4 and 8.

[0123] In an embodiment, the system determines that external data should be retrieved in order to execute a smart contract on behalf of the client. The system may identify a computing entity from which the data can be retrieved (1102), which is an entity trusted by the client. The client may publish a list of trusted entities in or elsewhere on the smart contract or blockchain, and the system may select any appropriate trusted entity from there to retrieve the external data. In an embodiment, the system establishes a cryptographically secure communication session with the data source (1104). An example of a cryptographically secure communication session is a TLS or SSL session.

[0124] In the embodiment, the system requests external data from a source and receives data from the data source via an encrypted communication session (1106). The 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., weather data in financial derivative contracts that use weather data feeds instead of price indices for crop insurance, such as flight information that parties can insure against delays); trading smart contracts that require GPS data for shipments; and gambling contracts that require access to random number generators.

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

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

[0127] In the context of this disclosure, pre-image resistant functions include one-way functions, which refer to functions for which calculating the current value may not be computationally difficult, but determining the previous value from the current value may not be computationally trivial. In some cases, one-way membership functions are not mathematically proven / cannot be proven as one-way, but nevertheless possess computationally complex properties that make the function pre-image resistant. One-way functions (also called “effective 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., passwords are at least partially based on plaintext and cryptographic keys), and other secure random functions that may, but 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 a cryptographic key as input and have pre-image resistance such that the probability of randomly generating an input is below a certain threshold, pre-image resistance of kind 2 (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 yielding the same output is below a certain threshold).

[0128] Figure 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 to be used as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 12, the computing device 1200 can, in embodiments, include 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 memory subsystem 1208 and a file / disk storage subsystem 1210, and a storage subsystem 1206 comprising 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 enables various components and subsystems of the computing device 1200 to communicate with each other as intended. Although the bus subsystem 1204 is schematically shown 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. In some embodiments, the network interface subsystem 1216 functions as an interface for receiving data from the computing device 1200 and sending data to other systems. In some embodiments, the bus subsystem 1204 is used to communicate data such as details and search terms.

[0130] In some embodiments, the user interface input device 1212 includes 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 touchscreen integrated into a display; a voice input device such as a voice recognition system or microphone; and other types of input devices. Generally, the 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 user interface output device 1214 includes a non-visual display such as a display subsystem, printer, or audio output device. In some embodiments, the display subsystem includes a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light-emitting diode (LED) display, or projection or other display device. Generally, the 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 that perform described processes and their variations, 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 configurations that provide functionality for at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) provide functionality for one or more embodiments of the present disclosure when executed by one or more processors in some embodiments, and 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 some embodiments, the memory subsystem 1208 includes a number of memories, such as main random-access memory (RAM) 1218 for storing instructions and data during program execution, and / or read-only memory (ROM) 1220 in which fixed instructions can be stored. In some embodiments, the file / disk storage subsystem 1210 provides non-temporary 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 representing the number of ticks that have occurred since a particular start date, and in some embodiments, is integrated within the computing device 1200. In various embodiments, the local clock 1224 can be 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 the data center. In another embodiment, the local clock is a programmable interval timer.

[0134] The computing device 1200 can be any type of device, including portable computer devices, tablet computers, workstations, or any other devices described below. Furthermore, in some embodiments, the computing device 1200 can include other devices that can 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 optical fiber connectors. Thus, in some embodiments, this device converts optical signals into electrical signals, which are transmitted to the computing device 1200 via the ports to which the device is connected for processing. Due to the constantly changing nature of computers and networks, the description of the computing device 1200 shown in Figure 12 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations with more or fewer components than the system shown in Figure 12 are also possible.

[0135] It should be noted that the embodiments described above are illustrative and not limiting to the present 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, no reference numerals enclosed in parentheses shall be construed as limiting the claims. The words “equipped with” and “comprising” do not exclude the existence of elements or steps other than those enumerated in any claim or the entire specification. In this specification, “equipped with” means “includes or consists of,” and “comprising” means “includes or consists of.” A single reference to an element does not exclude multiple references to such element, and vice versa. The present invention may be implemented by hardware comprising several individual elements and by a appropriately programmed computer. In a claim for an apparatus that enumerates several means, some of these means may be embodied by a single identical hardware item. The mere fact that certain items are described in different dependent claims does not imply that combinations of these items cannot be advantageously utilized.

[0136] (Note 1) A method that is performed on a computer: Steps to establish a cryptographically secure communication session with a computing entity; A step of receiving, in the cryptographically protected communication session, a communication containing input data that controls the execution of a program published on the blockchain network; A step of receiving first proof that a set of communications including the aforementioned data occurred in the cryptographically protected communication session; A step of executing the program using the aforementioned data, wherein the execution of the program results in the generation of a proof of the proper execution of the program; A step of generating a second proof that the data was received from the data source, based at least in part on the received input data; and A step of providing a proof of the proper execution of the program to another computer system; Methods that are performed on a computer, including [specific examples]. (Note 2) The first proof is a computer-based method as described in Appendix 1, wherein the first proof has a value at least partially based on the root node of a Merkle tree, and the Merkle tree includes a group of leaf nodes determined from a group of communications and a group of salt values. (Note 3) A method performed on the computer described in Appendix 2, wherein each communication in the group of communications includes a corresponding intermediate node determined based on whether the communication was received or transmitted. (Note 4) The method performed on a computer as described in Appendix 2 or 3, wherein the value of the first proof is at least further based in part on the time interval of the group of communications and the cryptographic hash output determined from the root node of the Merkle tree. (Note 5) The method, performed on a computer as described in any one of the appendices 2 to 4, wherein the second proof is at least in part based on a Merkle path of the Merkle tree, the Merkle path includes the values ​​of a group of nodes of the Merkle tree, and the values ​​of the group of nodes are sufficient to compute the value of the root node of the Merkle tree. (Note 6) The computer-based method described in Appendix 5, wherein the group of nodes in the Merkle path contains exactly one node at a depth that is neither a leaf nor the root of the Merkle tree. (Note 7) The program comprises a set of rules agreed upon by two or more parties, and the method further comprises the step of selecting the computing entity from one or more computing entities trusted by at least one of the two or more parties, the method being performed on a computer as described in any one of Annexes 1 to 6. (Note 8) A step of detecting a blockchain transaction comprising a first transaction output including a first locking script and a second transaction output encoding an instruction that the proof of proper execution is valid, wherein a first digital asset associated with the first transaction output is unlockable by an unlocking script, and the unlocking script is: The public key associated with the aforementioned computing entity; A digital signature that encodes an expected value, wherein the authenticity of the digital signature is cryptographically verifiable using a public key; and Authentication information that can be used to generate the aforementioned expected value; The steps encoding; and A step of unlocking the first digital asset by providing at least the public key, the digital signature, and the authentication information; A method performed on a computer as described in any one of the appendices 1 to 7, which further includes the above. (Note 9) The aforementioned blockchain transaction further: Transaction inputs digitally signed using private keys associated with the aforementioned other computer systems; A third transaction output comprising a second unlocking script, wherein the second digital asset associated with the third transaction output is unlockable using the private key; A method executed on the computer described in Appendix 8, wherein the second transaction output further encodes an identifier related to the other computer system. (Note 10) The method performed on the computer described in Appendix 8 or 9, wherein the authentication information includes a Merkle path of a Merkle tree, and the expected value is at least partially based on the root node of the Merkle tree. (Note 11) The aforementioned data includes binary data indicating whether or not an event occurred, and is executed on a computer as described in any one of the appendices 1 to 10. (Note 12) The aforementioned data is data that contains information that cannot be verified based on other data in the blockchain, and the method is performed on a computer as described in any one of the appendices 1 to 11. (Note 13) The first proof is a digital signature, and the authenticity of the digital signature can be verified using a cryptographic public key associated with the computing entity, by a method performed on a computer as described in any one of the appendices 1 to 12. (Note 14) Processor; and Memory containing executable instructions; A system comprising the above, wherein the instruction causes the system to perform a method performed on a computer as described in any one of the appendices 1 to 13, as a result of being executed by the processor. (Note 15) A non-temporary, computer-readable storage medium storing executable instructions, wherein the instructions, as a result of being executed by the processor of the computer system, cause the computer system to perform at least one of the computer-executable methods described in any one of the appendices 1 to 13.

Claims

1. A method performed on a computer in the certifier's computer system, the method being performed on a computer: Steps to establish a cryptographically secure communication session with a computing entity; A step of receiving a first communication containing input data that controls the execution of a program in the cryptographically protected communication session; A step of receiving a first proof that a group of communications occurred in the cryptographically protected communication session, wherein the group of communications includes the first communications which include the input data, the first proof which has a value which is at least partially based on the root node of a Merkle tree, and the Merkle tree which includes a group of leaf nodes which are determined from the group of communications and a group of salt values; A step of generating, at least in part, a proof of the proper execution of the program and a second proof that the input data was included in the first communication, wherein the second proof is at least in part based on a Merkle path of the Merkle tree, the Merkle path includes the values ​​of a group of nodes in the Merkle tree, and the values ​​of the group of nodes are sufficient to calculate the value of the root node of the Merkle tree; A step of broadcasting proof of the proper execution of the aforementioned program to the blockchain; and Steps include sending the second certificate to the client's computer system; Methods that are performed on a computer, including [specific examples].

2. The method performed on a computer according to claim 1, wherein each communication in the group of communications includes a corresponding intermediate node determined on the basis that the communication has been received or transmitted.

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

4. The computer-based method according to any one of claims 1 to 3, wherein the group of nodes in the Merkle path includes exactly one node at a depth that is neither a leaf nor the root of the respective Merkle tree.

5. The method to be performed on a computer according to any one of claims 1 to 4, wherein the program includes a set of rules agreed upon by two or more parties, and the method further includes the step of selecting the computing entity from one or more computing entities trusted by at least one of the two or more parties.

6. The method performed on a computer according to any one of claims 1 to 5, wherein the data includes binary data indicating whether or not an event occurred.

7. The method executed on a computer according to any one of claims 1 to 6, wherein the data includes information that cannot be verified based on other data in the blockchain.

8. A method performed on a computer according to any one of claims 1 to 7, wherein the first proof is a digital signature, and the authenticity of the digital signature can be verified using a cryptographic public key associated with the computing entity.

9. Processor; and Memory containing executable instructions; A system comprising the above, wherein the instruction causes the system to execute a method performed by a computer according to any one of claims 1 to 8, as a result of being executed by the processor.

10. A non-temporary, computer-readable storage medium storing executable instructions, wherein the instructions, as a result of being executed by the processor of the computer system, cause the computer system to perform at least one of the computer-executed methods described in any one of claims 1 to 8.

Images