System and method for authenticating off-chain data based on proof verification

Abstract

Determining when and / or how to execute a program or script published to a blockchain network may rely on data external to the blockchain (i.e., external data), such as data about real-world states and events. A prover (e.g., a node of a blockchain network) may perform one or more computations (e.g., execution of a program) on behalf of a client. In order to properly execute a program, a prover may rely on external data, which the prover may obtain from a data provider with which the client has a trust relationship (e.g., the client accepts valid data provided by a trusted data provider). A prover may utilize the systems and methods described herein to provide cryptographically verifiable assurance of the authenticity of input data allegedly obtained from a data provider for execution of a program or script published to a blockchain network.

Description

Technical Field

[0001] The present invention relates generally to blockchain technology, and more specifically to the generation of proofs of conversations that can be verified in a script, and also provides information that can be further utilized in the event of recourse. Proofs of certain communications that occurred during a conversation can use a Merkle tree. The data of the conversation or communication can be used as input to correctly execute a program or script. The present invention is particularly suitable for, but not limited to, the generation and execution of smart contracts. Background Art

[0002] As used herein, the term "blockchain" may refer to any electronic, computer-based distributed ledger. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variations. It should be noted that the present invention is not limited to use with alternative blockchain implementations and protocols, including non-commercial applications, which also fall within the scope of the present invention. For example, the techniques described in this application will provide advantages for use with other blockchain implementations.

[0003] Blockchain can refer to a peer-to-peer electronic ledger that is implemented as a computer-based, decentralized system consisting of blocks, which in turn can consist of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured set of field values ​​including data and a set of conditions, where satisfying the set of conditions is a prerequisite for writing the field set to the blockchain data structure. For example, each transaction is a data structure that encodes the transfer of control of digital assets between participants in a blockchain system, and includes at least one input and at least one output. In some embodiments, "digital assets" refers to binary data associated with usage rights. In some implementations, control of digital assets can be transferred by reassociating at least a portion of a digital asset from a first entity to a second entity. Each block of the blockchain can contain a hash of the previous block, so that the blocks are linked together to create a permanent, unchangeable record of all transactions that are written to the blockchain since the blockchain was born. The digital assets herein do not include encrypted virtual currencies.

[0004] In some examples, a "stack-based scripting language" refers to a programming language that supports various stack-based or stack-oriented execution models and operations. That is, a stack-based scripting language can utilize a stack. Using a stack, values ​​can be pushed to or popped from the top of the stack. Various operations performed to manipulate the stack may result in one or more values ​​being pushed or popped from the top of the stack. For example, the OP_EQUAL operation pops the first two items from the stack, compares the two items, and pushes the result (e.g., 1 if equal, 0 if unequal) to the top of the stack. Other operations performed on the 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, there may be at least two stacks: a main stack and an alternate stack. Some operations of the scripting language may 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 in some cases, a stack-based scripting language may not be limited to a strict Last-in-First-out (LIFO) approach. 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, respectively). Scripts written in a stack-based scripting language may be pushed onto a logical stack, which may be implemented using any suitable data structure (e.g., a vector, a list, or a stack).

[0005] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. A node can have different validity criteria than other nodes. Since the validity of the blockchain is based on consensus, a transaction is considered valid if a majority of nodes agree that it is valid. The software client installed on the node performs this validation work in part by executing the unspent transaction output (UTXO) locking and unlocking scripts for transactions that reference UTXO. If the execution of the locking and unlocking scripts evaluates to true (TRUE), and other validation conditions are met (if applicable), then the transaction is validated by the node. Validated transactions are propagated to other network nodes, which can then choose to include the transaction in the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must be: i) validated by the first node that receives the transaction (if the transaction is validated, the node relays the transaction to other nodes in the network); ii) added to a new block; iii) the transaction is added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible.

[0006] Digital entrepreneurs have begun exploring the use of cryptographically secure systems and data that can be stored on blockchains to implement new systems. It would be very beneficial if blockchains could be used to automate tasks and processes. Such solutions would be able to leverage the advantages of blockchains (e.g., permanent tamper-proof records of events, distributed processing, etc.) while being more versatile in their applications.

[0007] This application describes 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 include rules that may process inputs to produce results, and actions may then be performed based on those results. One area of ​​current research is the use of blockchain-based computer programs to execute "smart contracts." Unlike traditional contracts written in a natural language, a smart contract may be a computer program designed to automate the execution of a machine-readable contract or agreement terms.

[0008] Another area of ​​blockchain-related interest is the use of "tokens" to represent real-world entities and transfer them via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no apparent meaning or value. Thus, the token acts as an identifier that allows the real-world item to be referenced from the blockchain. The tokens in this article do not refer to encrypted virtual currencies.

[0009] In an embodiment, while interactions with specific entities may be encoded in specific steps of a smart contract, smart contracts may be automatically executed and self-enforced. Smart contracts are machine-readable and executable. In some examples, automatic execution refers to the successful execution of a smart contract to effect the transfer of UTXO. Note that in such examples, an "entity" that can cause a UTXO transfer refers to an entity that can create an unlocking script without proving knowledge of certain secrets. In other words, the unlocking transaction can be verified without verifying that the data source has access to cryptographic secrets (e.g., private asymmetric keys, symmetric keys, etc.). In addition, in such examples, self-enforcement refers to the implementation of unlocking transactions by verification nodes of a blockchain network according to constraints. In some examples, "unlocking" UTXO refers to creating an unlocking transaction that references UTXO and is executed as a valid execution.

[0010] Blockchain transaction outputs include a locking script and information about the ownership of a digital asset. The locking script (also known as an encumbrance) "locks" a digital asset by specifying the conditions that must be met to transfer the UTXO. For example, a locking script may require certain data to be provided in an unlocking script to unlock the associated digital asset. The locking script is also known as a "scriptPubKey". The technique of requiring a party to provide data to unlock a digital asset involves embedding a hash of the data within the locking script.

[0011] The present invention may be described as a system and method for executing smart contracts on a blockchain, which may utilize zero-knowledge proofs. The execution of smart contracts may be performed as part of transaction verification. As part of executing smart contracts, it is desirable to obtain access to data external to the blockchain (e.g., off-chain data), such as data about real-world states and events. The techniques described herein may be used to authenticate data provided by a data source and to authenticate and utilize data provided by a data source in the execution of a program or script (e.g., a smart contract published to a blockchain network). In an embodiment, digital assets may be used additionally or alternatively in other circumstances. Note that the present invention, while applicable to the control of digital assets, is technical in nature and may be used in other environments using blockchain data structures without involving the transfer of digital assets. Summary of the invention

[0012] It is therefore desirable to provide methods and systems that improve blockchain technology in one or more of these aspects. Such an improved scheme has now been devised. Therefore, according to the present invention, there is provided a method as defined in the accompanying claims.

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

[0014] Thus, according to the present invention, there is provided a system and method as defined in the appended claims.

[0015] According to the present invention, a computer-implemented method for a node of a blockchain network may be provided, the computer-implemented method comprising: establishing a cryptographically protected communication session with a computing entity; receiving, through the cryptographically protected communication session, a communication including input data, the input data controlling the execution of a program published to the blockchain network; receiving a first attestation of a communication set occurring through the cryptographically protected communication session, the communication set including the input data; generating, based at least in part on the received input data, a proof that the program was correctly executed and a second attestation that the input data was received from a data source;

[0016] and providing proof of the correct execution of a program to another computer system.

[0017] Additionally or alternatively, the invention may be described as comprising the following steps:

[0018] establishing a cryptographically protected communication session with a computing entity;

[0019] receiving, via the cryptographically protected communication session, a communication including input data that controls execution of a program posted to the blockchain network;

[0020] receiving first credentials that a communication set occurred through the cryptographically protected communication session, the communication set including the input data;

[0021] Based at least in part on the received input data, generating:

[0022] Proof of correct execution of the program; and

[0023] The input data is a second credential received from a data source; and

[0024] Providing proof that a program executed correctly to another computer system.

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

[0026] A communication of a communication set may have a corresponding intermediate node determined based on whether the communication is received or sent. In some cases, each communication in the communication set has such a corresponding intermediate node.

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

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

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

[0030] The program may include a set of rules agreed upon by two or more parties, and the method may include selecting a computing entity from one or more computing entities trusted by at least one of the two parties to establish cryptographically protected communications with the computing entity.

[0031] Preferably, the method may include detecting a blockchain transaction including a first transaction output and a second transaction output, wherein the first transaction output includes a first locking script, wherein a first digital asset associated with the first transaction output can be unlocked by an unlocking script, the unlocking script encoding the following: a public key associated with a computing entity, a digital signature encoding an expected value, the authenticity of the digital signature can be cryptographically verified using the public key, and authentication information that can be used to generate the expected value; the second transaction output encodes an indication that the proof of correct execution is valid; and unlocking the first digital asset by providing at least the public key, the digital signature and the authentication information.

[0032] The blockchain transaction may also include a transaction input that is digitally signed using a private key associated with another computer system; and a third transaction output that includes a second unlocking script, wherein a second digital asset associated with the third transaction output can be unlocked using the private key;

[0033] And the second transaction output further encodes an identifier associated with the other computer system.

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

[0035] The input data may include binary data indicating whether an event occurred.

[0036] Input data may be data that includes information whose accuracy cannot be verified based on other data on the blockchain.

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

[0038] It is also desirable to provide a system comprising: a processor; and a memory containing executable instructions, the executable instructions causing the system to perform any of the methods as claimed in the claims due to being executed by the processor.

[0039] It is also desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by one or more processors of a computer system, causes the computer system to at least perform any of the methods as claimed in the claims.

[0040] Additionally or alternatively, the present invention may provide an improved blockchain programming tool or auxiliary tool. It may provide an improved, efficient and optimized setting that facilitates or implements distributed, verifiable computing. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] These and other aspects of the invention will become apparent and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0042] Figure 1 A blockchain environment in which various embodiments may be implemented is shown;

[0043] Figure 2 shows a computing environment that may be used to implement a protocol according to various embodiments;

[0044] Figure 3 A diagram showing an environment suitable for performing verifiable computations;

[0045] Figure 4 An example diagram of an environment in which a prover utilizes data obtained from a data source related to the execution of a program or script is shown;

[0046] Figure 5 A diagram showing a protocol for obtaining data from a data source for execution of a program or script;

[0047] Figure 6 shows a diagram of a Merkle tree according to an embodiment;

[0048] Figure 7 A diagram showing a Merkle path according to an embodiment;

[0049] Figure 8 A diagram showing a protocol for generating and verifying attestations used in conjunction with various embodiments;

[0050] Fig. 9 A diagram showing a reputation transaction according to an embodiment;

[0051] Fig.10is a schematic diagram of a process for generating a proof of communication;

[0052] Fig.11 is a schematic diagram of the process of executing a program or script using authenticated data; and

[0053] Fig.12 A computing device is shown that can be used to practice at least one embodiment of the invention. DETAILED DESCRIPTION

[0054] First, refer to Figure 1 , which shows an example blockchain network 100 associated with a blockchain according to an embodiment of the present invention. In this embodiment, the example 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 that follow a blockchain protocol that is at least partially agreed upon between operators of the nodes 102. In some examples, a "node" refers to a peer-to-peer electronic device distributed in a blockchain network.

[0055] In some embodiments, node 102 may be implemented by any suitable computing device (e.g., by a server in a data center, by a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), by multiple computing devices in a distributed system of a computing resource service provider, or by any suitable electronic client device (e.g., a server in a data center, by a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), by multiple computing Figure 8 The computing device 800) is composed of.

[0056] In some embodiments, node 102 has an input for receiving a data message or object representing a proposed transaction, such as transaction 104. In some embodiments, a node can query the information it maintains, such as the state information of transaction 104.

[0057] like Figure 1 As shown, some nodes 102 are communicatively coupled to one or more other nodes 102. Such communicatively coupling may include one or more of wired or wireless communications. In this embodiment, each node 102 maintains at least a portion of a "ledger" of all transactions in the blockchain. In this manner, the ledger will be a distributed ledger. Transactions processed by a node affecting the ledger may be verified by one or more other nodes, thereby maintaining the integrity of the ledger.

[0058] As to which nodes 102 can communicate with which other nodes, it is sufficient that each node in the exemplary blockchain network 100 is able to communicate with one or more other nodes 102 so that messages passed between nodes (assuming that the message is one that the blockchain protocol indicates should be forwarded) can propagate through the exemplary blockchain network 100 (or some significant portion thereof). One such message might be the publication of a proposed transaction by one of the nodes 102 (e.g., node 102A), which would then propagate along a path (e.g., path 106). Another such message might be the publication of a new block proposed for inclusion in the blockchain.

[0059] In one embodiment, at least some of the nodes 102 are network nodes that perform complex computations (e.g., solving cryptographic problems). The network nodes that solve the cryptographic problems create new blocks for the blockchain and broadcast the new blocks to the other nodes 102. The other nodes 102 verify the work of the network nodes and, upon verification, accept the block into the blockchain (e.g., by adding it to the distributed ledger of the blockchain).

[0060] In some examples, a block is a group of transactions, usually marked with a timestamp and a "fingerprint" of the previous block.

[0061] (e.g., hashing). In this way, each block can be linked to the previous block, creating a "chain" of linked blocks in the blockchain. In an embodiment, valid blocks are added to the blockchain by consensus of nodes 102. Also in some examples, the blockchain includes a list of verified blocks.

[0062] In one embodiment, at least some nodes 102 serve as validation nodes for validating transactions, as described in the present invention. In some examples, the transaction includes data providing proof of ownership of the digital asset and conditions for accepting or transferring ownership / control of the digital asset. In some examples, an "unlocking transaction" refers to a blockchain transaction that reassociates (e.g., transfers ownership or control) at least a portion of a digital asset (indicated by a previously traded UTXO) to an entity associated with a blockchain address. In some examples, a "previous transaction" refers to a blockchain transaction that contains a UTXO referenced by an unlocking transaction.

[0063] In some embodiments, transactions include a "locking script" that is used in the ownership /

[0064] Conditions that must be met before control can be transferred (unlocked) to encumber a transaction.

[0065] In some embodiments, a blockchain address is an alphanumeric string associated with an entity to which control of at least a portion of a digital asset is being transferred / reassociated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between a public key associated with the entity and the blockchain address. In some embodiments, verification of a transaction involves verifying one or more conditions specified in a locking script and / or unlocking script. Upon successful verification of transaction 104, the verification node adds transaction 104 to the blockchain and distributes it to nodes 102.

[0066] The systems and methods described herein relate to enabling a locking script to protect a verification key V K It cannot be altered and verifies the validity of the proof π, allowing zero-knowledge protocols to be executed on the blockchain during transaction verification.

[0067] Verifiable computation is a technique that allows for the generation of proofs of computation. In one embodiment, a client utilizes this technique to outsource the evaluation of a function f with input x to another computational entity (referred to herein as a prover). In some cases, the client is computationally constrained such that the client cannot perform the evaluation of the function (e.g., the expected runtime of the computation using the client's available computational resources exceeds a maximum acceptable threshold), although this is not necessarily the case. In general, the client can delegate the evaluation of the function f with input x based on any suitable criteria, such as computational runtime, computational cost (e.g., the financial cost of allocating computational resources to perform the function evaluation), etc.

[0068] In one embodiment, the prover is any suitable computing entity (e.g., a blockchain node as described in more detail elsewhere in this application). In one embodiment, the prover (e.g., a blockchain node) evaluates a function f with an input x and generates an output y and a proof π of the correctness of the output y, which can be verified by other computing entities (e.g., clients and / or other nodes of the blockchain network as described above). Proofs (also referred to as arguments) can be verified faster than performing actual computations, and thus computational overhead (e.g., reducing power overhead and costs associated with powering and running computing resources) can be reduced by verifying the correctness of the proof rather than recomputing the function f on the input x to determine the correctness of the output generated by the above prover. In zero-knowledge verifiable computation, the prover provides a client with a credential that the prover knows an input with specific properties.

[0069] An effective variant of zero-knowledge proofs is zk_SNARK (Succinct Non-interactive ARgument of Knowledge). In one embodiment, all pairing-based zk SNARKs include a process in which the prover uses universal group operations to compute several group elements, and the verifier uses several pairing product equations to verify the proof. In one embodiment, linear interactive proofs work over finite fields, and the prover and verifier's messages include information that encodes, references, or otherwise includes vectors that can be used to determine field elements.

[0070] In one embodiment, the systems and methods described herein allow a blockchain network node to perform a computation (e.g., evaluate a function f with an input x, and generate a proof that can be used to verify the correctness of an output, where evaluating the correctness of the proof is computationally less expensive than evaluating the function. In this case, the cost (i.e., how expensive) of an operation or task can refer to the computational complexity of performing the operation or task. In one embodiment, the computational complexity refers to the average computational cost or the worst-case computational cost of performing a sorting algorithm, for example, the average computational cost of a heapsort algorithm and a quicksort algorithm are both O(nlogn), but the worst-case computational cost of quicksort is O(nlogn). 2 ), while the worst-case computational cost of a heap sort is O(nlogn). In one embodiment, the average computational cost and / or the worst-case computational cost of evaluating the function f with the input x is higher than the average computational cost and / or the worst-case computational cost of evaluating the correctness of a proof. Thus, using the systems and methods described herein is highly advantageous and may, for example, allow for the running of computationally more expensive contracts because such contracts do not proportionally increase the time required to verify a blockchain. Further advantages may include reducing the power consumption of a verifier system, thereby increasing the efficiency of a verifier computer system, and reducing the energy costs associated with running such a verifier computer system to evaluate the correctness of a proof.

[0071] In one embodiment, the verification key V can be extracted from the public parameters K or part thereof, the public parameters are generated in the setup phase of the zero-knowledge protocol and used together with the proof π and the input / output data to verify the so-called proof of correctness computation provided by the prover. For example, as described above and in more detail below, the systems and methods that allow locking scripts to protect the verification key V KThe proof π is not altered and verifies the validity of the proof π, thereby allowing the execution of zero-knowledge protocols on the blockchain during transaction verification. Therefore, the present application presents a system and method for performing the verification phase using a blockchain script for storing elements used in the verification of a computation.

[0072] Figure 2 A computing environment 200 that can be used to implement the protocol according to various embodiments is shown. The protocol can be implemented using blockchain technology to store proofs of correctness and combine a "correct-by-construction" cryptographic approach with smart contracts. In one embodiment, the public verifiable computation scheme includes three phases: a setup phase, a computation phase, and a verification phase.

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

[0074] In one embodiment, the setup phase involves a client, customer, employee of an organization, or any other suitable entity writing a contract using a formal language with precise semantics. The contract can be written in a high-level programming language, such as C or Java. In general, the contract can be expressed in any language or syntax that can be converted to a format that can be processed by a computer system. In one embodiment, a domain-specific language with a limited purpose can provide type-safety and can utilize limited expressive power. The generated source code may be an accurate description of the contract.

[0075] Compiler 202 may be any hardware, software, or combination thereof including executable code that, if executed by one or more processors of a computer system, causes the system to take source code 206 as input and generate a circuit. Compiler 202 may refer to a computer program that executes or completes instructions based on instructions that have been compiled into a machine-readable format (e.g., binary code). It should be noted that although compiler 202 is shown, interpreters, assemblers, and other suitable software and / or hardware components may be utilized to convert source code into a circuit. In one embodiment, the circuit is an arithmetic circuit that includes wires that carry values ​​from field F and are connected to logic and / or arithmetic gates. In one embodiment, the system uses circuits To generate a secondary program Q 208, the secondary program Q208 includes providing the original circuit The set of polynomials that fully describe .

[0076] In one embodiment, compiler 202 is capable of recognizing a substantial subset of a programming language (e.g., C or Java), including, but not limited to: preprocessor directives, static initializers, global and local functions, block-scoped variables, arrays, data structures, pointers, function calls, function operators (e.g., functors), conditional and loop statements, and arithmetic and bitwise Boolean operators. In one embodiment, compiler 202 does not support the entire command set according to the standard of the programming language (in some cases, this may be intended to prevent certain types of algorithms from being executed in smart contracts, e.g., prohibiting recursive algorithms). In one embodiment, the compiler expands the expression of the source code into an arithmetic gate language to generate arithmetic circuits. Campanelli, M. et al. (2017) in “Zero-Knowledge Contingent Payments Revisited: Attacks and Payments for Services” and Tillich, S. and Smart, B in “Circuits of Basic Functions Suitable For MPC and FHE” have all envisioned circuit implementations. The operational circuit may be implemented by the compiler 202 or any other suitable hardware, software, or combination thereof (e.g., Figure 2The software module (not shown) is used to construct a quadratic arithmetic problem (Quadratic Arithmetic Problem, referred to as QAP). According to an embodiment, the quadratic program is compiled into a set of cryptographic programs for the client (e.g., key generation and verification) and the prover (e.g., calculation and proof generation).

[0077] In one embodiment, key generator 204 is hardware, software, or a combination thereof including executable code that, if executed by one or more processors of a computer system, causes the system to generate evaluation keys and verification keys to form a quadratic program. Techniques for encoding computations as quadratic programs are contemplated in Gennaro, R. et al. (2013), "Quadratic Span Programs and Succinct NIZKs without PCPs". In one embodiment, a quadratic arithmetic problem (QAP) Q is a circuit on a field F. Encoded, and contains a set of m+1 polynomials:

[0078] V={v k (x)},W={w k (x)},Y={y k (x)}

[0079] where 0≤k≤m. The target polynomial t(x) is also defined. Given a function f that takes n elements of F as input and outputs n' elements, where N = n+n'. Then, if {c 1 ,…,c N}∈F N is a valid assignment of the input and output sets of f and there exists a coefficient list {c N+1 ,…,c m}, then Q calculates f such that t(x) divides p(x):

[0080]

[0081] Therefore, in one embodiment, there must exist some polynomial h(x) such that h(x)·t(x)=p(x). The size of Q is m, and its degree is the degree of t(x).

[0082] In one embodiment, constructing a QAP for an arithmetic circuit includes selecting an arbitrary root r for each multiplication gate g in the circuit. g ∈F, and define the target polynomial as t(x) = ∏ g (xr g). In one embodiment, an index k∈{1...m} is associated with each input of the circuit and each output of a multiplication gate. The polynomial in V encodes the left input of each gate, W encodes the right input of each gate, and Y encodes the output. For example, if the kth wire is the left input of gate g, then v k (r g )=1, otherwise v k (r g ) = 0. Therefore, for a particular gate g and its root r g , the previous equation can be simplified as follows:

[0083]

[0084] The output value of a gate is equal to the product of its inputs. The divisibility test is decomposed into deg(t(x)) separate tests, where each gate g and root r of t(x) g There is a test such that p(r g ) = 0. The addition gate and the multiplication constant gate have no effect on the size and number of QAPs.

[0085] In one embodiment, a QAP is defined over a field Fp, where p is a large prime number. In one embodiment, it is desirable that a QAP over Fp efficiently computes any function that can be expressed as addition and multiplication modulo p. The operation separation gate can be designed to separate the operation wire a∈Fp (known to be in [0,2 k-1 ]) into k binary output wires. Therefore, it can be seen that arithmetic gates can be used to represent Boolean functions. For example, NAND(a,b) = 1–ab. Each embedded Boolean gate requires only one multiplication operation. In addition, new gates such as split can be defined independently and combined with other gates. Given an input a∈Fp (known to be in [0,2 k-1 ]), the separation gate outputs the binary digit a that holds a 1 ,...,a k k wires, so that ∑ k 2 i-1 a i =a, each a i Is 0 or 1.

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

[0087] In one embodiment, performing the computational task includes computing a function (i.e., a process for evaluating f(x)) by the prover with input 216. In one embodiment, the prover is any suitable computer system to which the client can delegate the computational task. In one embodiment, input 216 includes information confirming the identity of the prover, such as a digital signature generated using a private key associated with the prover. In one embodiment, the prover is a computer system to which the client successfully transferred the digital asset. In one embodiment, the client provides the prover with the input x and the evaluation key E. K , the prover uses the evaluation module 214 for the computational procedure to compute the output y (i.e., y=f(x), where the input is x and the function is f), and uses the evaluation key E K 210 to generate a correctness proof 218. In one embodiment, the evaluation module is hardware and / or software including instructions that, if executed by one or more processors of a computer system, cause the computer system to calculate the values ​​of the internal circuit wires of QAP 208 and generate an output y of the QAP.

[0088] In one embodiment, each polynomial v of the quadratic program k (x)∈F is mapped to an element g in the bilinear group vk (s) , where s is a secret value chosen by the client, g is the generator of the group, and F is the field of discrete logarithms of g. In one embodiment, for a given input, the prover evaluates the circuit to obtain the output and the coefficients c corresponding to the quadratic program i The value of the internal circuit wire. Therefore, the prover can verify v(s) = ∑ k∈{m} c k ·v k (s) is evaluated to obtain g v(s) ; Calculate w(s) and y(s); Calculate h(x) = p(x) / t(x) = ∑ d h i ·x i ; and use h in the evaluation key i and g s(i) Calculate g h(s) In one embodiment, the correctness proof 218 includes (g v(s) ,g w(s) ,g y(s) ,g h(s)), and the verifier uses a bilinear map to verify that p(s)=h(s)·t(s). In one embodiment, the proof π is stored on the blockchain 222 for later use, or can be verified by multiple parties without requiring the prover to interact with each of these parties individually. In one embodiment, the evaluation of the circuit storage of the correctness proof can be performed to unlock the resource (e.g., digital asset) locked (encumbered) by the transaction's locking script.

[0089] In one embodiment, the proof π is broadcast to the blockchain network, and a verifier 220 is used to verify the proof. In one embodiment, the verifier 220 is any suitable computing entity, such as a node on the blockchain. It should also be noted that in some cases, the evaluation key E is generated. K and verification key V K The same computing entity that verifies the proof also verifies the proof. In one embodiment, the nodes of the blockchain can use the verification key V K and prove π to verify the lock transaction, thereby verifying the contract if the verification succeeds. One requirement of the protocol is that even if the prover knows the verification key V K , nor can it provide incorrect proof. Therefore, in this protocol, the common reference string (CRS) is provided by the client or by at least one person who has published the evaluation key E. K and verification key V K In one embodiment, any computing entity can use the published verification key V K To verify the calculation.

[0090] By using the techniques described herein, a client is able to partially obfuscate transaction data, such as the identity of a recipient of a blockchain transaction. In one embodiment, the unlocking script does not disclose the recipient's address and the recipient's public key. However, in some cases, the value of the transaction (e.g., the amount of digital assets transferred) may be visible to nodes of the blockchain network. In one embodiment, the client converts the locking script into a quadratic arithmetic program using the cryptographic techniques described above and below, and the prover solves the arithmetic program using these cryptographic techniques to generate a proof.

[0091] In general, a client is able to pay a counterparty or prover using a standard transaction. For example, in one embodiment, a client converts a locking script into an operational circuit and broadcasts a locking transaction that includes a puzzle derived from the circuit. The counterparty or prover receives the circuit, provides appropriate input (e.g., information that verifies the identity of the prover (e.g., a secret shared between the client and the prover, or a digital signature generated using the prover's private key)), and runs the circuit to generate a correctness proof π. In one embodiment, the proof is used to unlock a resource (e.g., a digital asset). In addition, it may be the case that information identifying the counterparty or prover (e.g., a public key and / or digital signature associated with the counterparty or prover) is not recorded to the blockchain in an unobfuscated format.

[0092] In one embodiment, the verification key and corresponding certificate are generated according to the techniques described above and / or below. K And prove π:

[0093]

[0094] The verifier is made to compute multiple elliptic curve multiplications (eg, one elliptic curve multiplication for each public input variable) and five pairwise checks, where one pairwise check includes an additional pairwise multiplication.

[0095] Given a verification key V K , prove that π and (a 1 ,a 2 ,…,a N ) to verify that t(x) is divided by p(x), so (x N+1 ,…,x m )=f(x 0 ,…,x N ), the verifier performs the following operations. First, check all three α terms:

[0096]

[0097]

[0098] in, and Then, the validator verifies project β:

[0099]

[0100] and Finally, the verifier checks the divisibility requirement:

[0101]

[0102] in

[0103] and

[0104] Therefore, according to one embodiment, after considering the notations from the above section and the examples described in this application, the verification includes a set of pair checks of the following elements:

[0105]

[0106] Figure 3 A diagram 300 for coordinating the execution of a verifiable computation is shown. Client 302, prover 304, and verifier 306 may be nodes of a blockchain network. Client 302 may be any suitable computer system that may include executable code that, if executed by one or more processors of the computer system, causes the computer system to receive a smart contract 308. In one embodiment, smart contract 308 is encoded as source code in a high-level programming language, such as C, C++, or Java. In one embodiment, software such as a compiler, interpreter, and / or assembler may be used to convert smart contract 308 into an operational circuit 310 that is composed of a processor carrying a domain name. It should be noted that an arithmetic circuit refers to a logic circuit that can be implemented by a physical circuit that includes a series of physical gates connected by physical wires (for example, using transistor-transistor logic (TTL) integrated circuits (e.g., 7400 series gates, flip-flops, buffers, decoders, multiplexers, etc.). Although in Figure 3 Execution of smart contracts 308 is described in the context of and elsewhere, but the use of smart contracts is merely a non-limiting example of source code that can be converted into operational circuits. In one embodiment, client 302 (e.g., alone or in conjunction with another entity) determines source code for performing a task defined by a set of operations, where the execution of the task is delegated to prover 304. In general, verifier 306 can perform tasks associated with determining that prover 304 correctly performed the task, such as by verifying the validity of a proof of correctness generated by prover 304.

[0107] In one embodiment, client 302 provides computational circuit 310 to prover 304, and data provider 318 provides input 312 of the circuit to prover. In some cases, input 312 may be data (e.g., data about real-world states and events). Circuit 310 may be used to generate a quadratic program Q that includes a set of polynomials that provide a complete description of the original circuit. In either case, prover 304 may execute circuit 310 on input 312. or a quadratic program Q to generate one or more intermediate outputs and a final output. In some embodiments, the prover is expected to obtain is output as a valid copy of , which is an assignment of values ​​to the circuit wires so that the values ​​assigned to the input wires are The intermediate value corresponds to For each gate in the correct operation, the value assigned to the output line is If the requested output is incorrect (i.e., ), then it does not exist In one embodiment, the prover is expected to provide a subset of the values ​​of the circuit conductors, wherein the selected subset of the values ​​of the circuit conductors is not known in advance by the prover.

[0108] In the example, the output The value of the internal circuit wire (or a subset thereof) and the evaluation key E K Used to generate a correctness proof 316. This proof π can be stored on the blockchain and verified by multiple parties without requiring the prover 304 to interact with each party separately. In this way, the verifier 306 can use the public verification key V K The client 302 may verify the lock transaction by verifying the lock transaction and proving π. In some cases, if the verification fails, the client 302 may reclaim the digital assets encumbered by the lock transaction. In some cases, the verifier 306 and the client 302 are the same computer system.

[0109] Figure 4 FIG400 shows an embodiment of the present application. Specifically, Figure 4 An environment is shown in which data provided by a data source is authenticated and used in the execution of a program or script (e.g., a smart contract published to a blockchain network). In one embodiment, client 402, prover 404, and data provider 406 are computer systems. In one embodiment, client 402 refers to a computer system that outsources or delegates the execution of a computing task to another computer system, referred to herein as a prover. In one embodiment, a computing task refers to the evaluation of a function, the execution of a smart contract, etc. In one embodiment, performing a computing task involves the computation of an output based on a circuit and one or more inputs, which is performed by the prover on behalf of the client. The circuit can be generated from source code, which is a formal representation of the terms of the contract.

[0110] As described in more detail elsewhere in this application, the protocol for executing smart contracts on the blockchain can utilize zero-knowledge proofs. In one embodiment, the execution of smart contracts can occur as part of transaction verification. To this end, the public parameters generated in the protocol setup phase are used together with the proof and input / output data to verify the so-called correct computation proof provided by the prover and verify the contract execution. In some embodiments, the execution phase of the contract can rely on input / output data external to the blockchain. In general, external data refers to information that is not available on the blockchain or cannot be verified from data accessible to the blockchain. External data can be obtained from various sources, such as data feeds and application programming interfaces (APIs). External data can be used in a variety of contexts around smart contracts, including but not limited to: smart contracts for securities (e.g., rates, derivatives, bonds) that require access to market price feeds for assets and financial applications (e.g., interest rates); peer-to-peer insurance smart contracts that require access to external data (e.g., flight information for which a party has taken out delay insurance; weather data for a financial derivative contract that uses a data feed for weather rather than a price index for crop insurance); trade smart contracts that require GPS data about freight; and contracts that need access to random number generators, etc.

[0111] In one embodiment, determining when and / or how to execute a smart contract relies on access to external data (e.g., data about real-world states and events). In one embodiment, data provider 406 provides such data, and in some cases, may be referred to as an oracle. The data returned by the oracle may be in various formats and types, such as in the form of a Boolean value indicating whether certain information specified by the parties contains specified text or specified information. In one embodiment, the data may be used to organize venture capital investments (e.g., the outcome of a binary event, such as the outcome of a boxing match). Floating-point values ​​may be used in the context of exchange rates between currencies and may be read from certain APIs. Such data may be useful in organizing options and hedging contracts.

[0112] Data providers 406 may also be referred to as oracles, which retrieve and / or provide external data (e.g., data about real-world states and events) and make the external data available to the blockchain. An oracle may refer to a computing entity including executable code that, if executed on one or more processors of a computer system, causes the computer system to generate blockchain-compatible data and / or data feeds that serve as a trusted link between the blockchain and a network (e.g., the Internet). An oracle may obtain data from websites, feeds, databases, and other data sources to provide external data to the blockchain. External data may include, for example, temperature information, GPS coordinates of shipments, aviation information (e.g., flight status information), and the like.

[0113] In one embodiment, the prover 404 obtains external data from the data provider 406 by: establishing a cryptographically protected communication session with the data provider; making a request through the cryptographically protected communication session; the data provider providing data in response to the request; the prover receiving the data and requesting a credential for communication between the parties in response to receiving the data; the data provider computing a cryptographically verifiable communication certificate π between the prover and the data provider during the cryptographically protected communication session. Communications , and digitally signs the credential with the private key of the data provider; the prover receives the communication proof. In general, the communication proof is a cryptographically verifiable credential that one or more communications occurred between the client and the server (e.g., between the prover and the data provider). In one embodiment, the credential can be used to verify the content of the communication between the client and the server, although it should be noted that in some cases, a portion of the communication (e.g., information that is subject to legal restrictions on disclosure) can be edited or replaced with a predetermined default value, such as by replacing the edited information with an obfuscation of the information (e.g., information in an encrypted or hashed format). In one embodiment, the credential is based at least in part on the root value of the Merkle tree (such as a hash value based on the root value of the Merkle tree). Figure 6 In one embodiment, the credential (e.g., proof of communication) is digitally signed using a cryptographic private key accessible to the data provider 406. An entity such as a certificate authority may issue a digital certificate that certifies that a cryptographic public key corresponds to a private key. It should be noted that within the scope of this application, the symbol π is generally used. Communications to refer to the proof of communication, and the proof of correct execution can be referred to as π Prover Or more simply called π.

[0114] Certificate authority 410 may refer to a computing entity that generates and / or distributes digital certificates that certify that a particular cryptographic key belongs to a particular entity. For example, a computing entity may obtain a digital certificate containing a data provider's public key, and such a public key may be used in a variety of contexts—e.g., to encrypt data for secure communications with the data provider, to verify the authenticity of a digital signature purporting to be signed by the data provider, etc. Figure 4 An embodiment is shown in which client 402 has a trust relationship with certificate authority 410 (e.g., the client regards digital certificates properly signed and / or issued by the certificate authority as authentic), but any suitable trusted computing entity, such as a key management system or key registry, may be used.

[0115] In one embodiment, prover 404 generates π using input data Prover , for example, Figure 2 In one embodiment, π Prover Stored on blockchain 408 for later use, or can be verified by multiple parties without the prover having to interact with each of the multiple parties individually. For example, the execution of a smart contract that provides flight delay insurance to a party may rely on official flight data obtained from an official aviation agency as input data. In general, the input data does not need to come from a government source, (the parties to the smart contract can agree on a list of entities from which the input data can be obtained) therefore, the data source can be any suitable computing entity that the client indicates it can trust to obtain data. The client can specify different lists of trusted entities for different inputs. The list of trusted entities can be selected and / or pruned based on the value of the contract.

[0116] Prover 404 may send a communication proof to client 402. In some cases, data provider 406 may send a communication proof to client 402, for example, based on a command from the prover. As previously described, the communication proof may be derived based at least in part on the root value of the Merkle tree. For example, the communication proof may also encode information specifying the time interval over which the communication occurred. In one embodiment:

[0117] W Time =[T SessionStart , T ProofRequest ]

[0118] π Communications =H(h′ final , W Time )

[0119] In other words, a cryptographic hash function is used to compute the communication proof, where the root value of the Merkle tree (h′ final ) and the communication time interval (WTime , which in one embodiment encodes the start time of the encrypted communication session and the time when the communication proof is requested) is the input to the cryptographic hash function. In one embodiment, the inputs to the cryptographic hash function are concatenated or otherwise combined. The Merkle tree can be based at least in part on the Time The communication proof may be digitally signed using the cryptographic private key of the data source. In one embodiment, the time at which the conversation occurred is defined as W Time =[T SessionStart , T ProofRequest ] and is included as part of the communication proof generated by the server (e.g., data source 504). It should be noted that in addition to and / or as an alternative to sending the communication proof to the client 402, the prover 404 can store the proof on a secure server (e.g., encrypted under a public key associated with the client 402) or in a data storage service of a computing resource service provider. In one embodiment, the client 402 stores the communication proof in a data repository (e.g., a data storage service) and provides the client 402 with a uniform resource identifier (URI) or other suitable reference that can be used to obtain the communication proof from the data repository. For example, a prover 404 that performs a repetitive task (e.g., capturing flight data for one or more routes over several days) aggregates the captured data into containers in the data repository so that the client can obtain historical flight data (e.g., a specific route) over time intervals.

[0120] In one embodiment, client 402 receives the communication certificate and the digital signature on the communication certificate. The client can determine the digital signature purporting to be signed by the data provider, obtain the public key associated with the data provider (e.g., obtained from a digital certificate issued by certificate authority 410), and use the public key to verify the authenticity of the digital signature. If the digital signature is determined to be authentic, client 402 believes that the communication certificate was generated by the data provider; otherwise, the communication certificate and the digital signature may be discarded. After verifying the communication certificate, client 402 can verify the correctness proof, such as with Figure 2 and 3 Related discussion methods.

[0121] In some embodiments, client 402 generates a reputation transaction that indicates that the external data obtained from a particular prover 404 is correct (e.g., the data is the same as the data provided by the data provider). The reputation transaction can be added to the public ledger of past transactions of blockchain 408 as a proxy for whether the prover 404 performed the computation task correctly and / or whether the prover 404 performed the computation task honestly using the external data received from the data provider. Prover After executing the smart contract, the client can use π Communications To verify the use of generating π Prover The input data is the input data provided by the data provider. Reputation transactions can be added to the public ledger of past transactions on the blockchain that represents a review of the services provided by the prover (positive results can incentivize the prover to act honestly) and can be used to select provers to execute subsequent smart contracts. Reputation transactions can include a first unlocking script and a second unlocking script, the first unlocking script allowing the prover to unlock the prover after providing sufficient evidence (i.e., in π Prover The second unlocking script allows the client to undo the review when the input data used in is the evidence from the data provider. Figure 4 The reputation transactions shown in can be consistent with the transactions described elsewhere in this application. For example, the following Fig. 9 Transactions of related description.

[0122] Generally speaking, Figure 4In the case shown, the client issues a request Req(src,τ,q) specifying a target source src, a time τ, and a query q. If src is a network server, a cryptographically protected communication session (e.g., a TLS session) may be required. In one embodiment, any cryptographically protected communication session can be utilized that provides cryptographically verifiable authenticity guarantees, where messages between parties are authenticated by message authentication codes (MACs) that are generated and verified using the same key. This means that the server and the recipient of the message must agree on the same key, so any user who can verify a MAC can generate MACs for other messages. In contrast, a digital signature can specify that a message is signed by the holder of a private key. Hajjeh and M.Badra envisioned a method for notarizing communications in "TLS Sign", which defines a new subprotocol called TLSSignOnOff, in which clients and servers notify each other when they start or stop transmitting signed data. Upon receiving the stop message, the server collects a hash of the conversation and signs it. Various other methods of notarizing recorded data of cryptographically protected communication sessions may be used (e.g., saving a record of the conversation and signing the conversation with a cryptographically verifiable attestation of the authenticity and / or integrity of the recorded conversation), such as the techniques described in "Transport Layer Security (TLS) Evidence Extensions" by R. Housley and M. Brown and "TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing for Disintermediation" by H. Ritzdorf, K. Wust, A. Gervais, G. Felley, and S. Capkun, which define an evidence window that starts when the client makes a request and when one of the parties closes the evidence window, the server signs a hash of the message and a timestamp of the evidence generation and optionally hides sensitive records.

[0123] Figure 5500 is a schematic diagram of an embodiment in which a prover 502 obtains data from a data source 504. In one embodiment, a cryptographically protected communication session is established between the prover 502 and the data source 504. Examples of the cryptographically protected communication session include Transport Layer Security (TLS) and Secure Sockets Layer (SSL) sessions. The cryptographically protected communication session can be used to provide a secure connection between parties. In this case, a secure connection can refer to a cryptographically verifiable guarantee of authenticity, integrity, privacy, or any combination thereof. Authenticity can refer to a guarantee that a message is created by a party claiming to be the author of the message. Integrity can refer to a guarantee that a received message has not been intentionally (e.g., by a malicious party) or unintentionally (e.g., due to signal loss during transmission) modified in its original form when it is transmitted. Confidentiality can refer to encrypting part or all of a message before transmission. In one embodiment, a client (e.g., prover 502) and a server (e.g., data source 504) exchange information during a first phase (referred to as a handshake 508), in which a mixture of asymmetric and symmetric encryption is issued to ensure security. Figure 5 The handshake shown can be a 4-way handshake according to the TLS handshake protocol. In one embodiment, the client (e.g., prover 502) sends a Client Hello message (ClientHellomessage), which includes parameters (such as client version, session id, additional functions implemented by adding extensions, or some combination thereof). In one embodiment, the handshake begins with a message that sends a signal to the server (e.g., data source 504) to start recording proof of the conversation. As a result, the server (e.g., data source 504) will enter an internal state associated with proof generation, which will last until it receives a subsequent request to generate communication evidence. While in this internal state, data source 504 can record the communication content (or part thereof) exchanged between prover 502 and data source 504 through an encryption-protected communication session.

[0124] After the handshake (e.g., during the record protocol), outgoing messages are divided into chunks and incoming messages are reassembled. In one embodiment, the conversation between the parties of the cryptographically protected communication session includes multiple records R 1 …R i These records can be used to generate proof of communication, for example by generating a Merkle tree including a set of leaf nodes including the record R 1 …R i . Figure 5 The records shown and described can be used to generate a Merkle tree such as Figure 6 Those described.

[0125] In one embodiment, a record refers to a request and response that forms a conversation between the prover 502 and the data source 504 as part of a cryptographically protected communication session. In some cases, the request and response include more information than required (e.g., information that is irrelevant to determining the input data required by the prover 502 when executing the smart contract). In one embodiment, the server (e.g., the data source 504) populates a template (e.g., in the form of a JSON node with specified fields). The template can be specified during the handshake. For example, a template for obtaining weather data can have fields for location, date, and temperature. In one embodiment, a request for flight data can include flight status, flight identifier, and date, such as the following format: {"flightInfo":{"data":{"id":"BA886":[{"validDate":"2017-11-01T07:00:00+0000"},"status":"On time"}]}.

[0126] Once the handshake is complete, the parties (e.g., prover 502 and data provider 504) may transmit records 510 including data between each other. For example, prover 502 may request data from data provider 504, which may be used as input to evaluate a circuit and generate output as part of executing a smart contract. After prover 502 receives enough data to evaluate a circuit, prover 502 may request a session certificate 512 from data provider 504. It should be noted that data provider 504 may be a client (e.g., Figure 3 and Figure 4 A client (described in the description) has a computer system with a trust relationship, wherein the client trusts the data generated and / or provided by the data provider. In this case, a client trusting data from another entity may refer to a client that accepts data obtained from the entity as correct and / or a client that receives data published from a trusted source with a valid security certificate as authentic and accurate. In one embodiment, a server (e.g., data source 504) generates a communication proof 516, which consists of a hash root 514 of all records from the completion of the handshake protocol until the receipt of the generated π Communications The records of the requests are exchanged between the parties during the protocol. In one embodiment, W Time It is also hashed along with the record, such as in cases where the execution of the data depends on inputs collected at a specific time (e.g., a smart contract for flight insurance against delays for a specific flight number on a specific date).

[0127] In one embodiment, a client (eg, prover 502) requests π Communications, and the data provider returns the final value of the hash chain obtained from the commitments of all records and W concatenated, hashed, and digitally signed using the private key of the data source Time Thus, the data included in the record of communication between the parties can be used for the execution of the smart contract. This communication proves π Communications It can also be fed into the initial smart contract and verified by a dedicated function, eliminating the need for a semi-trusted prover. In one embodiment, these records are hashed together in a Merkle structure, such as Figure 6 Related description methods.

[0128] It should be noted that although Figure 5 An embodiment is described in which a session client requests proof from a session server, but this need not be the case, i.e., the techniques described herein may be modified such that a server of a TLS session requests communication proof from a client of a TLS session.

[0129] Figure 6 600 is a schematic diagram of a Merkle tree that can be constructed and / or utilized according to various embodiments described herein. For example, such a Merkle tree can be constructed and / or utilized in accordance with various embodiments described herein. Figure 2-5 The described embodiments are constructed in an environment.

[0130] In one embodiment, the client computer system and the server computer system establish a cryptographically protected communication session (eg, a TLS session) and exchange messages (eg, records). One or more records of communication between the parties to the session are 1 …R iThe communication between the client and the server may be recorded by the server for a specified duration (e.g., from the completion of the handshake protocol until the server receives a request from the client to generate a communication proof). In one embodiment, the server includes executable code that, if executed by one or more processors of the server, causes the server to: detect an indication to start recording communications between the client and the server; store records of communications transmitted and received protected by encryption; detect an indication to generate a communication proof; and generate a Merkle tree based at least in part on the stored records. Various alternatives and extensions to the above process are contemplated. A Merkle tree may refer to a data structure in which each leaf node of the Merkle tree is a hash of a data record, and each non-leaf node is derived from a child node of the non-leaf node at least in part based on the use of at least a cryptographic hash function. However, it should be noted that the techniques included herein may utilize a structure similar to a Merkle tree to verify that a particular data fragment is part of a Merkle tree. For example, in one embodiment, the techniques included herein are applied to a structure in which the leaf nodes of the tree are data records, and the non-leaf nodes are derived from the child nodes of the non-leaf nodes at least in part based on the use of at least a cryptographic hash function. In one embodiment, the tree data structure described herein is a binary tree. It should be noted that although Figure 6 Examples of unbalanced Merkle trees are shown, but in some embodiments, the leaf nodes of the Merkle tree are arranged in a balanced or substantially balanced tree (eg, a substantially balanced tree may have all leaves at a particular depth in the tree).

[0131] In one embodiment, a Merkle tree is a collection of one or more records R stored in 1 …R i The Merkle tree is generated (e.g., cached by the server in a short-term memory such as RAM), and when an indication to generate a proof of communication is detected, the records are selected in chronological order as leaf nodes of the Merkle tree. Each record is cryptographically hashed with a random salt value, which can be derived from a handshake traffic secret (e.g., a TLS pre-master key or master key). The salt can be a random number or pseudo-random number generated using any suitable random process. Salts can be selected so that they are not reused in the context of a particular Merkle tree, or can be selected in a way that the probability that any two salts are the same value is below a threshold probability.

[0132] The first salt and the first record may be inputs to a cryptographic hash function, where the first salt and the first record are concatenated and hashed (e.g., using the SHA 256 cryptographic hash algorithm). Generally, where a cryptographic hash function is shown, a pre-image resistant function (such as a one-way function) may be utilized. Although in Figure 6 In the illustrative example shown, a salt is used, but in general, a random number, an initialization vector, and any other suitable cryptographic primitive may be used to augment a record. A first output is generated by executing a cryptographic hash algorithm using a first salt and a 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 a session. For example, Figure 6 An embodiment is shown where information associated with the client is appended to the hash output, where the client is the sender of the record, and information associated with the service is appended to the hash output, where the service is the sender of the record. The prepended / appended information may be any suitable information, i.e., a fixed client value (e.g., 0) and a fixed server value (e.g., 1) may be utilized:

[0133]

[0134] In one embodiment, the tree structure is fixed and a value associated with the client or service (e.g., an IP address or MAC address associated with the sender) is prepended / appended to the Merkle tree. In one such example ( Figure 6 Not shown):

[0135]

[0136] Other records transmitted via cryptographically protected communication sessions can be created in the above manner and hashed together in sequence to generate the root node value. Figure 6 In the example shown, each node generates an intermediate node value:

[0137]

[0138] In one embodiment ( Figure 6 Not shown):

[0139] In one embodiment, the final hash value is calculated as and is the root of the Merkle tree. In one embodiment, In one embodiment, the communication is verified by, for example, a time interval (e.g., W Time , R 1 and R last timestamp) to expand This additional information can be hashed together to form a proof of communication. The proof of communication can be digitally signed by a private key associated with the service that encrypted the communication session, where the service is an entity that the smart contract client trusts (e.g., Figure 3 and 4 described above).

[0140] Figure 7 700 is a schematic diagram of a Merkle path according to various embodiments described herein. A Merkle path can be used to provide cryptographically verifiable assurance that a particular record (or more generally, particular information or particular data) is transmitted during a session between a client and a service that cryptographically protects the communication session. A Merkle path can be composed of Figure 6 The Merkle tree described is constructed and can be used with Figure 2-5 Used in the context of describing embodiments.

[0141] In one embodiment, the prover receives data from a data source and uses the data as input to solve an operational circuit and generates a proof of correct execution based at least in part on the output of the circuit. In addition, the prover can generate a credential, i.e., a credential that the data used to solve the operational circuit is included in a communication set between the prover and the data source. In one embodiment, the credential is a Merkle path, wherein the Merkle path includes a set of node values ​​of a Merkle tree that is sufficient to calculate the root value of the Merkle tree. The Merkle path may include some, all, or none of the leaf node values ​​of the Merkle tree. The Merkle path may include information about the location of the node value 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 credential may be encoded in the correctness proof π Prover middle.

[0142] In one embodiment, a computing entity is able to verify that the content of a particular communication is included in a set of communications between two other computing entities by: receiving a root node value of a Merkle tree and a digital signature on the root node value generated using a private key of the trusted entity from a trusted entity; verifying the authenticity of the digital signature using a public key of the trusted entity; receiving a Merkle path including a set of node values, wherein nodes in the node set correspond to a particular communication claimed to have been communicated; calculating a so-called root value from the set of node values; and comparing the so-called root value to the verified root node value.

[0143] consider Figure 7 The Merkle path 702 shown in FIG. 1 is based on the Merkle path 702 of FIG. 1 . In one embodiment, the Merkle path 702 is based on the Merkle path 702 of FIG. 1 . Figure 6 Describes the Merkle tree export. Figure 7 The Merkle path 702 shown can be used to verify a particular record R 3 The set of values ​​in Merkle path 702 may be hashed together to generate a final hash value. In one embodiment, the final hash value is generated based on additional information encoded in or associated with the Merkle path that indicates the order in which the values ​​were hashed together. For example, Figure 7 As shown, Figure 7 The Merkle path 702 shown can be used to calculate the final value If the final value is equal to the root value (for example, Figure 6 of Match), the computing entity determines that the record R 3 As a communication is included in the collection of communications between the parties to the conversation.

[0144] In general, a Merkle path can refer to a set of nodes (or values ​​of these nodes) of a Merkle tree that is sufficient to compute the value of the root node. The root node can be Figure 7 The root node of the Merkle tree shown, or a subtree of such a tree. Figure 7 The Merkle path shown in Figure 1 can encode the values ​​of two leaf nodes, and at each depth of the Merkle tree between a leaf node and the root node, there is exactly one value corresponding to a node of the Merkle tree. However, this is not the case: another suitable Merkle path includes the value of each leaf node of the Merkle tree, however, such a Merkle path may be more complex than other Merkle paths (e.g. Figure 7 ) have greater storage requirements.

[0145] Figure 8 A diagram 800 of a computing environment that can be used to implement a protocol according to various embodiments is shown. The protocol can be implemented using blockchain technology to store correctness proofs generated based on data external to the blockchain. In one embodiment, the prover 802, data source 804, client 806, certificate authority 808, and blockchain 810 are consistent with those described elsewhere in this application, and these components can be implemented as a computing system.

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

[0147] In one embodiment, the prover 802 receives a computational circuit from a client 806, the computational circuit encapsulating the terms of the smart contract. The prover 802 may perform a computation, wherein the computation of the data is performed based at least in part on the data obtained from the data source 804. The prover 802 may obtain an output and generate (814) a proof of correct execution of the circuit, which is broadcast and recorded (816) on the blockchain network 810, thereby enabling nodes of the blockchain to verify the smart contract.

[0148] The execution of smart contracts that include off-chain data (e.g., data about the real world) relies on different levels of trust between the parties. To gain trust, the prover can prove to the client (or any other system that verifies the prover's honesty) that a certain conversation occurred between the prover and the trusted data source that produced the data. In one embodiment, the prover provides (818) the client with a Merkle path (e.g., Figure 7As described above, the Merkle path includes a record including a communication proof and input data for evaluating an operation circuit. The client receives the Merkle path and the communication proof and verifies (820) that a particular record (or recorded data) is part of a communication with a trusted data source by obtaining a public key associated with the trusted data source (e.g., by requesting a digital certificate 808 including the public key of the data source from a certificate authority), verifies the authenticity of a digital signature generated by the communication proof, generates a hash output from the Merkle path, and verifies that the generated hash output matches the received communication proof. In this way, the client is able to determine that the input to the smart contract is provided by a trusted source.

[0149] In one embodiment, the client verifies (822) the proof of correctness, for example in a manner described elsewhere in this application and / or using the techniques described in UK Patent Application No. 1719998.5. The client may also generate (824) a reputation transaction, which is recorded (826) to the blockchain, and broadcasts the client's review to the blockchain network, indicating whether the prover acted honestly when executing the above-mentioned specific smart contract. In this case, honestly can mean that the prover uses the same data provided by the data source to execute the smart contract, rather than a dishonest entity using different inputs to execute the smart contract, thereby changing the execution result of the smart contract in some embodiments.

[0150] Fig. 9 is possible in various environments (such as Figure 4 and Figure 8 Schematic diagram 900 of reputation transaction 902 used in embodiments described in the related description. In one embodiment, reputation transaction is a post-contract execution verification under the assumption that the prover is honest. In one embodiment, this type of verification does not affect the execution of the contract, but is used as a metric that contributes to the reputation of the prover. Once a smart contract is executed, clients have the opportunity to review the prover's service and are incentivized to improve the performance of the smart contract market by promoting well-behaved provers. Conversely, provers are incentivized to behave correctly because whether they do so directly affects their reputation and their potential future clients, i.e., clients can choose provers based on their reputation (or lack thereof).

[0151] In one embodiment, a client (e.g., Figure 4904 input. The reviewer input can be a transaction input signed using the client's private key. In general, the reviewer input can be any information that provides publicly verifiable credentials that prove that the client is a reviewer of the reputation transaction. The reputation transaction includes three outputs. The verification 906 output can have an associated unlocking script that takes as input the public key, signature, and Merkle path. When verifying, the Merkle path can be used to prove that the record belongs to a trusted entity (e.g., Figure 4 In general, the verification 906 output is a transaction output that includes an expected value and authentication information that can be used to generate the expected value, the expected value can be digitally signed, and the authenticity of the digital signature can be verified using the public key as described above. In one embodiment, the authentication information is a Merkle path that can be used to generate a root hash value. The second output can be a revocation 908 output, which includes an address belonging to the client. In one embodiment, unlocking the revocation output is a symbol that the review is canceled or revoked. The reputation transaction can also encode the review metadata 910 as a third transaction output, which includes information about the identity of the prover (e.g., the address of the prover), the smart contract executed by the prover, and an indication of a positive review. In an embodiment, the reputation metadata 910 is implemented as an OP_RETURN output. In one embodiment, the output can have a nominal amount of digital assets (e.g., dust values) or no value at all (in the case of an OP_RETURN output that cannot be spent).

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

[0153] Fig.10 1 is a schematic diagram of a process 1000 for generating a communication certificate. In one embodiment, the process 1000 is implemented using hardware, software, or a combination thereof. Suitable systems for performing the process include a data provider (e.g., Figure 4 In general, the system performing process 1000 can be any suitable system trusted by a computing entity that delegates the execution of a smart contract or other computing task to another computing entity. In this context, trust can refer to a computing entity accepting that data originating from and / or broadcast by a trusted entity is correct, and / or accepting that data published from a trusted source with a valid security certificate is authentic and accurate.

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

[0155] The system may detect (1004) an indication to begin authentication communication between the system and the transaction counterparty. The indication may be implicitly defined as part of the protocol. For example, the system may begin authentication communication upon completion of a 4-way handshake protocol. In one embodiment, the system receives the indication as a message in accordance with a record protocol, the message indicating the start of authentication communication. It should be noted that authentication communication may also be referred to as notarizing communications and / or conversations between two or more computing entities. As part of the indication to begin authentication communication, the system may record a timestamp of when it began authenticating the communication.

[0156] After indicating the start of the authentication communication, the system may receive and / or transmit (1006) data as part of a recording protocol, and the communication (or the data contained therein) may be recorded in any suitable format (e.g., as a data structure in short-term memory). It should be noted that the stacked boxes shown in connection with the reception and transmission of data indicate that multiple records may be received and transmitted, although this need not be the case, i.e., in one embodiment, a single record is received and / or transmitted.

[0157] In one embodiment, after receiving the instruction to start authentication communication, the system may receive (1008) an instruction to end authentication communication with the transaction counterparty. In one embodiment, the system records a timestamp when the request to end authentication communication is detected. In some cases, the end is detected implicitly, such as by the termination of an encryption-protected communication session.

[0158] In one embodiment, the system generates (1010) proof of communication based on records (or portions thereof) transmitted and / or received during the authentication period (i.e., the time between when the system detects the start of authentication and when authentication communications are ended). The system may generate (1011) proof of communication based on records (or portions thereof) transmitted and / or received during the authentication period (i.e., the time between when the system detects the start of authentication and when authentication communications are ended). Figure 7The communication proof is generated by generating a Merkle tree in the manner described above. The root of the Merkle tree may be the communication proof. In one embodiment, the communication proof is determined based on the root of the Merkle tree and W_time, which encodes the time interval in which the authenticated communication occurred. The communication proof can be digitally signed by the system using a private key, where the corresponding public key can be accessed by a certificate authority that issues digital certificates. In one embodiment, the system is Figure 3-5 and Figure 8 After generating the communication proof, the system can send (1014) the communication proof to a counterparty to the session (eg, the prover) and / or another entity (eg, a client as specified by the prover during the session).

[0159] Fig.11 is a schematic diagram of a process 1100 for executing a program or script using authenticated data (e.g., a smart contract published to a blockchain network). In one embodiment, external data (e.g., data about real-world events) is authenticated, while data available from the blockchain is not authenticated. Data referred to in this context may refer to input data that is used as part of the evaluation of an operational circuit to generate an output used in the smart contract. In one embodiment, the process 1100 is implemented using hardware, software, or a combination thereof. Suitable systems for performing the process include a prover (e.g., Figure 2-4 and Figure 8 those provers described).

[0160] In one embodiment, the system determines that external data should be obtained to execute a smart contract on behalf of a client. The system can identify (1102) a computing entity from which data can be obtained, the computing entity being an entity trusted by the client. The client can publish a list of trusted entities, such as entities in or related to the smart contract, or other entities on the blockchain, and the system selects any suitable trusted entity from which to obtain external data. In one embodiment, the system establishes (1104) a cryptographically protected communication session with the data source. An example of a cryptographically protected communication session is a TSL or SSL session.

[0161] In one embodiment, the system requests external data from a source and receives (1106) data from the data source via a cryptographically protected communication session. External data can be used in a variety of contexts around smart contracts, including but not limited to: smart contracts for securities (e.g., interest rates, derivatives, bonds) that require access to market price feeds for assets and financial applications (e.g., interest rates); peer-to-peer insurance smart contracts that require access to external data (e.g., flight information for which a party has taken out delay insurance; weather data for a financial derivative contract that uses a data feed of weather instead of a price index for crop insurance); trade smart contracts that require GPS data on freight; and contracts that require access to random number generators, etc.

[0162] After the system receives the external data, the system can provide an instruction to the data source to provide a first credential proving that a communication set occurred as part of a cryptographically protected communication session, wherein the communication set includes the system receiving the external data from a trusted data source. The system can receive (1108) the first credential. The first credential can be a communication proof, which is a hash root of the Merkle tree. The first credential can be digitally signed, and the authenticity of the digital signature can be verified by a public key associated with the trusted data source.

[0163] In one embodiment, the system generates (1110) and uses the data as an operational circuit The circuit is used to generate a quadratic program to generate one or more outputs In one embodiment, a system (eg, a prover) obtains As output, the valid copy is an assignment of values ​​to the wires of the circuit such that the value assigned to the input wire is x. The system can also generate a credential that proves that the data used as input to the computational circuit is data obtained from a trusted source. The credential can be as described elsewhere in this application (e.g. Figure 6 and 7 ). The system may broadcast (1112) proof of correct execution of the smart contract to the blockchain. The system may transmit (1114) a second credential (e.g., a Merkle path), a first credential (i.e., a credential received from a data source, such as proof of communication), a public key associated with a trusted entity, or some combination thereof.

[0164] It should be noted that in the context of this application, pre-image resistant functions include one-way functions, which refer to functions that are computationally not difficult for the current value, but are computationally not easy for determining the previous value from the current value. In some cases, a one-way membership function is not mathematically proven / cannot be proven to be one-way, but still has computational complexity 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 (HMACs)), key derivation functions (such as PBKDF2 and bcrypt (e.g., with a password based at least in part on plaintext and an encryption key)) and other secure randomization functions that can, but do not necessarily, have a domain (a possible set of inputs) that is larger than their range (possible outputs). Other suitable functions for various embodiments include, but are not limited to: a function that accepts at least plaintext and an encryption key as input and has a pre-image resistance property such that the probability of a randomly generated input is below a specified threshold, second pre-image resistance (given an input x1, the probability of randomly generating a different input x2 such that f(x1) = f(x2) is below a specified threshold) and / or collision resistance (for example, the probability that two different inputs result in the same output is below a specified threshold).

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

[0166] In some embodiments, bus subsystem 1204 provides a mechanism for enabling various components and subsystems of computing device 1200 to communicate with each other as expected. Although bus subsystem 1204 is schematically shown as a single bus, alternative embodiments of the bus subsystem can utilize multiple buses. In some embodiments, network interface subsystem 1216 provides interfaces to other computing devices and networks. In some embodiments, network interface subsystem 1216 is used as an interface to receive data from other systems and send data from other systems of computing device 1200. In some embodiments, bus subsystem 1204 is used to transmit data such as details, search terms, etc.

[0167] 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 touch screen incorporated into a display; an audio input device (such as a voice recognition system, a microphone), and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information to the computing device 1200. In some embodiments, one or more user interface output devices 1214 include a display subsystem, a printer, or a non-visual display (such as an audio output device), etc. 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 a projection display or other display device. In general, 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. For example, one or more user interface output devices 1214 can be used to present a user interface to facilitate user interaction with an application that performs the described process and its variations when the interaction is appropriate.

[0168] In some embodiments, the storage subsystem 1206 provides a computer-readable storage medium for storing basic programming and data structures of the functions of at least one embodiment of the present application. In some embodiments, when the application (program, code module, instruction) is executed by one or more processors, the functions of one or more embodiments of the present application are provided, and in an embodiment, the application is stored in the storage subsystem 1206. These application modules or instructions can be executed by one or more processors 1202. In various embodiments, the storage subsystem 1206 additionally provides a repository for storing data used according to the present application. In some embodiments, the storage subsystem 1206 includes a memory subsystem 1208 and a file / disk storage subsystem 1210.

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

[0170] In some embodiments, computing device 1200 includes at least one local clock 1224. In some embodiments, local clock 1224 is a counter that represents the number of ticks that have elapsed since a specific start date, and in some embodiments, local clock 1224 is integrally located within computing device 1200. In various embodiments, local clock 1224 is used to synchronize data transfers in processors of computing device 1200 and its included subsystems with specific clock pulses, and can be used to coordinate synchronization operations between computing device 1200 and other systems in a data center. In another embodiment, the local clock is a programmable interval timer.

[0171] The computing device 1200 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 1200 may include another device, which in some embodiments may be connected to the computing device 1200 via one or more ports (e.g., USB, headphone jack, lightning connector, etc.). In some embodiments, such a device includes a port that accepts a fiber optic connector. Thus, in some embodiments, the device converts optical signals into electrical signals and transmits these electrical signals via the port that connects the device to the computing device 1200 for processing. Due to the ever-changing nature of computers and networks, there is a need for Fig.12 The description of the computing device 1200 depicted in FIG. 1 is intended only as a specific example to illustrate a preferred embodiment of the device. Fig.12 Many other configurations are possible having more or fewer components than the system depicted.

[0172] It should be noted that the above embodiments illustrate rather than limit the present invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. The words "comprising" and "comprises" and the like do not exclude the presence of other elements and steps as a whole, even though these elements and steps are not listed in any claim or specification. In this specification, "comprises" means "includes or consists of...", and "comprising" means "including or consists of...". The singular reference of an element does not mean to exclude the plural reference of these elements, and vice versa. The present invention can be implemented by means of hardware comprising several different elements, and by means of a suitably programmed computer. In a device claim that lists several means, several of these means may be embodied by the same component of hardware. The indisputable fact is that certain methods are listed in mutually different dependent claims, which does not mean that the combination of these methods cannot achieve beneficial effects.

Claims

1. A computer-implemented method comprising: On the prover computing system: establishing a cryptographically protected communication session with a computing entity; receiving, via the cryptographically protected communication session, a communication including input data that controls execution of a program posted to a blockchain network; receiving a first credential for a set of communications occurring through the cryptographically protected communications session, the set of communications including the input data; executing the program using the input data, wherein execution of the program results in generation of a proof of correct execution of the program; generating, based at least in part on the received input data, a second credential that the input data is received from a data source; providing evidence of correct execution of the program to another computer system; and providing the first credential and the second credential to a client computing system; and On the client computing system: verifying, using the first credential and the second credential, that the input data used to generate the proof of correct execution was received from the computing entity; and A reputation transaction is generated, wherein the reputation transaction is a record of the prover computing system executing the program using the input data received from the computing entity.

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

3. The computer-implemented method of claim 2, wherein: Each communication in the set of communications has a corresponding intermediate node, the corresponding intermediate node being determined based on whether the communication is being received or transmitted.

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

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

6. The computer-implemented method of claim 5, wherein: The node set of the Merkle path includes only one node at each non-leaf and non-root depth of the Merkle tree.

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

8. The computer-implemented method of claim 1 , wherein: The input data includes binary data indicating whether an event occurs.

9. The computer-implemented method of claim 1 , wherein: The input data is data including information that is not verifiable based on other data on the blockchain.

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

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

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

Images