System and method for generating multi-party blockchain-based smart contracts

Abstract

To describe systems and methods related to techniques that allow for multiple parties to jointly generate or jointly agree upon parameters for generation of a smart contract, such as a verification key.SOLUTION: Execution of a smart contract may be performed by a third party, for example, a worker node on a blockchain network. Techniques described herein may be utilized as part of a protocol in which parties of the smart contract share a power of secret in a manner that allows each party to determine an identical common reference string, agree on parameters for the smart contract, and / or make proportionate contributions the smart contract, and combinations thereof. The smart contract may be published to a blockchain network (e.g., Bitcoin Cash). The protocol may be a zero- knowledge protocol.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention generally relates to the execution of smart contracts between multiple (e.g., more than two) parties, and more specifically to an implementation in which a verification key for a smart contract is collectively generated by two or more parties to the smart contract, and the smart contract is executed in a computationally verifiable manner using a third party (e.g., a worker node on a blockchain network). The third computing entity may generate a proof of correct execution of the smart contract, which can be used to unlock digital assets that are being obstructed by the first and second computing entities. The present invention is particularly suited for use on blockchain networks such as Bitcoin-based blockchain networks, but is not limited thereto. [Background technology]

[0002] A blockchain can refer to a peer-to-peer electronic ledger implemented as a computer-based, decentralized system composed of blocks, which can consist of transactions and other information. In some examples, a “blockchain transaction” refers to an input message that encodes a structured collection of field values ​​containing a set of data and conditions, in which case satisfying the set of conditions is a prerequisite for the set of fields to be written to the blockchain data structure. In Bitcoin, for example, each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and includes at least one input and at least one output. In some embodiments, a “digital asset” refers to binary data associated with a right of use. Examples of digital assets include Bitcoin, Ethereum, and Litecoin. In some implementations, the transfer of control of a digital asset can be accomplished by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block in the blockchain may contain a hash of the previous block so that the blocks, when chained together, create a persistent and immutable record of all transactions written to the blockchain from the beginning. A transaction includes small programs known as scripts embedded in its inputs and outputs, specifying how and by what means the transaction's output can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0003] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to explore the use of both the cryptocurrency security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the realm of cryptocurrency. Such solutions, while having a wider range of applications, would be able to leverage the advantages of blockchain (e.g., persistence, tamper-proof event records, distributed processing, etc.).

[0004] This disclosure describes the technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program may be a machine-readable and executable program recorded within a blockchain transaction. A blockchain-based computer program may include rules that can process inputs to produce results, and then perform actions depending on those results. One area of ​​current research is the use of blockchain-based computer programs for the implementation of “smart contracts.” Unlike traditional contracts written in natural language, a smart contract may be a computer program designed to automate the execution of machine-readable contract or agreement terms. [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] Therefore, it is desirable to provide a protocol for recording multi-party verification keys on a blockchain by exchanging quantities that can be used to determine the power of a shared secret between two or more parties. In various embodiments, it may be desirable for two or more parties to a smart contract to exchange quantities that can be used to determine a common reference string containing a verification key and an evaluation key. In various embodiments, the techniques described herein enable two or more parties to exchange the power of a shared secret without using cryptographic techniques such as encryption, and furthermore, these parties do not need to establish a communication channel that requires the confidentiality of cryptographically verifiable guarantees of the data exchanged over the communication channel.

[0006] Such improved solutions have been devised. [Means for solving the problem]

[0007] Accordingly, according to this specification, systems and methods as defined in the appended claims are provided.

[0008] According to the present invention, a computer implementation method for nodes of a blockchain network may be provided. A computer implementation method includes the steps of: determining a set of elliptic curve points for a second computing entity based at least in part on a first polynomial and at least two elliptic curve points in a first computing entity; making a subset of the set of elliptic curve points available to the second computing entity; receiving a second set of elliptic curve points generated using the second polynomial; determining a power of a secret based at least in part on the first and second sets; determining a common reference string including a verification key and an evaluation key based at least in part on the power of a secret, wherein the common reference string is also determinable by the second computing entity as a result of the first computing entity providing a subset to the second computing entity; and generating a smart contract including a first transaction input provided by the first computing entity and a second transaction input provided by the second computing entity, wherein as a result of the correct execution of the smart contract by the third computing entity, the third computing entity can generate a blockchain transaction using the output of the smart contract.

[0009] The set of elliptic curve points described above may include corresponding elliptic curve points for the powers of the first polynomial (e.g., elliptic curve points for each polynomial power).

[0010] Preferably, the first polynomial may be of at least degree 2.

[0011] Preferably, the subset described above is a set of elliptic curve points. Furthermore, unless otherwise specified or inconsistent with the context, the term “subset” of a corresponding set does not necessarily refer to an exact subset of the corresponding set, although the subset and the corresponding set may be equivalent.

[0012] The secret may be shared between the first computing entity and the second computing entity without using a cryptographically protected communication channel.

[0013] The first computing entity and the second computing entity may collectively determine both the first digital asset and the second digital asset.

[0014] Preferably, some or all of the methods described herein include the steps of: determining a third set of elliptic curve points for a second computing entity based on a third polynomial and at least two elliptic curve points; making a second subset of the third set of elliptic curve points available to the second computing entity; receiving a fourth set of elliptic curve points; determining parameters at least in part on the third and fourth sets, the parameters also being determinable by the second computing entity as a result of the first computing entity providing the second subset to the second computing entity; and determining a common reference string further at least in part on the parameters.

[0015] Preferably, some or all of the methods described herein may further include the step of sharing elliptic curve parameters between a first computing entity and a second computing entity using Shamir's Secret Sharing Scheme.

[0016] Preferably, some or all of the methods described herein may further include the step of exchanging scalar parameters between a first computing entity and a second computing entity using a Diffie-ellman cheme (for example, using a Diffie-ellman key exchange algorithm).

[0017] The smart contract may include a Pay-To-Script-Hash (P2SH) type unlocking script that enables a third computing entity to unlock both the first and second digital assets in response to providing valid proof of correct execution.

[0018] The first computing entity may make a subset of the set of elliptic curve points available to the second computing entity via an off-chain communication channel.

[0019] The second polynomial does not need to be accessible to the first computing entity.

[0020] Preferably, at least two elliptic curve points are two different elliptic curve points.

[0021] Furthermore, it is desirable to provide a system comprising a processor and memory containing executable instructions that, as a result of execution by the processor, cause the system to execute any of the methods claimed in the patent.

[0022] Furthermore, it is desirable to provide a non-temporary computer-readable storage medium that stores executable instructions that cause the computer system to execute at least one of the methods claimed in the patent as a result of execution by one or more processors of the computer system. [Brief explanation of the drawing]

[0023] These and other aspects of the present invention will become apparent from the embodiments described herein and will be elucidated in connection with those embodiments. Embodiments of the present invention will now be described, merely illustrative, in connection with the accompanying drawings: [Figure 1] This diagram illustrates a computing environment in which multiple parties to a smart contract agree with a third party to execute the smart contract. [Figure 2] This figure shows a computing environment in which a first computing entity and a second computing entity exchange quantities that can be used to determine the power of a shared secret between two or more parties. [Figure 3] This diagram shows a computing environment in which a first computing entity and a second computing entity exchange a set of parameters that render zero-knowledge. [Figure 4] This is a diagram of a protocol based on a common reference string (CRS) used by two parties and its corresponding proof of correctness (POC) or proof of correct execution. [Figure 5] This figure shows a process for generating a two-party common reference string, including a verification key and an evaluation key, according to one embodiment. [Figure 6] This figure shows a process for sharing the power of a shared secret among multiple parties, according to at least one embodiment. [Figure 7] This is a simplified block diagram of a computing device that can be used to carry out at least one embodiment of the present disclosure. [Modes for carrying out the invention]

[0024] Figure 1 illustrates a blockchain environment that can implement various embodiments.

[0025] This disclosure describes techniques that may be used to implement a system and method that enable multiple parties to securely share elements of a group whose exponent or multiplicative coefficient depends on the powers of a shared secret. Quantities may be shared so that multiple parties exchange quantities based on the shared secret (e.g., powers of the shared secret) without disclosing the shared secret. Thus, in various embodiments, multiple n participants share an expression of the power of the shared secret (e.g., in the multiplicative case, <S i > G To establish.

[0026] In embodiments, the protocol utilization techniques and methods described herein are used by two parties to a smart contract to share a quantity that can be used by these parties and to determine a power of a shared secret, without sharing the secret itself and without revealing information that would enable another computing entity (e.g., a computing entity that is not a party to the smart contract) to determine the secret. In one embodiment, the protocol includes the first party to the smart contract computing a first set of parameters to be sent to the second party to the smart contract, and the second party computing a second set of parameters and presenting these parameters to the first party, where, during the exchange of parameters as described above, both parties can compute an identical common reference string including a verification key. The parties may then agree to a transaction in which the parties make proportional contributions of digital assets to the smart contract that are locked against an address (e.g., the address of a worker node on a blockchain network) and can be unlocked (e.g., used). In one embodiment, off-chain communication between parties to a smart contract is limited to the exchange of parameters used to generate a common reference string, while security guarantees are maintained (for example, the secret key cannot be opened or otherwise determined based on parameters exchanged by an adversary or other computing entity that is not a party to the smart contract). In one embodiment, two parties (or more generally, two or more parties) utilize a technique for sharing a power of a shared secret in a manner described elsewhere in this specification, for example in relation to Figures 1 to 7.

[0027] You can refer to Figure 1, which illustrates an exemplary computing environment in which various embodiments of this disclosure may be implemented. The systems and methods described herein may relate to a protocol for parties to a smart contract to exchange quantities that can be used by first and second computing entities to compute the same common reference string. Figure 1 illustrates a computing environment 100 including a first computing entity 102 and a second computing entity 104 exchanging a set of parameters. Such a set of parameters enables both the first and second computing entities to determine a common reference string 108. The common reference string may be used by the parties to generate a smart contract 110 that locks digital assets contributed by either or both computing entities as transaction inputs. The common reference string may include an evaluation key 112 and a verification key 114. The smart contract 110 may be issued to a blockchain such as the blockchain 118 illustrated in Figure 1. The smart contract 110 may be executed by a third computing entity 106 that is not a party to the smart contract 110. As part of or in connection with the execution of a smart contract, a third computing entity (e.g., a worker) may generate a proof of correct execution 116 of the smart contract, at least in part, based on the evaluation key of the common reference string. The proof of correct execution 116 may be computationally verifiable by any suitable computing system (e.g., a party to the smart contract, or a node of the blockchain network acting as a verifier node). In an embodiment, the verification key 114 is used by a fourth computing entity (e.g., a verifier computer system) to verify that the proof issued to the blockchain network 118 is correct.

[0028] The first computing entity 102 and the second computing entity 104 are, according to at least one embodiment, computer systems that are parties to a smart contract. Parties to a smart contract may refer to two or more computing entities that agree on the conditions for the execution of the smart contract (for example, according to user input provided through a relevant user input device). Both the first computing entity 102 and the second computing entity 104 may agree to the smart contract and contribute transaction inputs to the smart contract, thereby preventing each transaction input of the smart contract from being blocked by a locking script, which can be unlocked (e.g., used) as a result of a worker node providing proof of the correct execution of the smart contract. The systems and methods described herein involve a locking script with a verification key V K This relates to enabling protection from modification, checking the validity of proof π, and thereby allowing the execution of zero-knowledge protocols against the blockchain during transaction verification.

[0029] In various embodiments, the first computing entity 102 and the second computing entity 104 agree on a smart contract by exchanging a set of messages that encode parameters of the smart contract, such as a date, time, condition, and action (e.g., transfer of control of a digital asset), which are used to control the execution of the smart contract. For example, a smart contract (e.g., an executable program) may underwrite insurance for the parties against delays of a particular flight, and the execution of the program may include using external data, such as flight information for a particular commercial flight on a particular day, to determine whether that particular flight was delayed. If the flight is delayed, the parties to the program may receive a transfer of assets (e.g., a smart contract that provides travel insurance against delays).

[0030] In one embodiment, the smart contract 110 is encoded as source code in a high-level programming language such as C, C++, or Java®. These are merely illustrative examples, and the smart contract may be encoded using other suitable programming languages. In one embodiment, software such as a compiler, interpreter, and / or assembler is used to process the smart contract 110 into fields.

number

[0031] Verifiable computation is a technique that enables the generation of proofs of computations. In one embodiment, such a technique is used by a client to outsource the evaluation of a function f for an input x to another computing entity, which is referred to herein as the prover. In some cases, the client may be computationally constrained and therefore unable to perform the evaluation of the function (e.g., the expected runtime of the computation using the computing resources available to the client exceeds an acceptable maximum threshold), but this is not necessarily the case, and the client may delegate the evaluation of the function f for an input x based on any appropriate criteria, such as computation runtime, computation cost (e.g., the financial cost of allocating computing resources to perform the evaluation of the function), etc.

[0032] The prover is, in one embodiment, any suitable computing entity, such as a blockchain node, which is described in more detail elsewhere in this disclosure. In one embodiment, the prover (e.g., a blockchain node) evaluates a function f for an input x and generates an output y and a proof π of the correctness of the output y, which can be verified by other computing entities, such as the client and / or other nodes in the blockchain network as described above. The proof, sometimes also called an argument, can be verified faster than the actual computation and thus computational overhead can be reduced by verifying the correctness of the proof instead of recalculating the function f for the input x to determine the correctness of the output generated by the prover described above (e.g., reducing power overhead and the costs associated with powering and running computing resources). In zero-knowledge verifiable computation, the prover provides the client with a proof that the prover knows an input having certain characteristics.

[0033] A valid variation of the zero-knowledge proof of knowledge is zk_SNARK (Succinct Non-interactive ARgument of Knowledge). In one embodiment, all pairings-based zk_SNARKs involve a process in which the prover computes multiple group elements using common group operations, and the verifier checks the proof using multiple pairing product equations. In one embodiment, a linear interactive proof works for a finite field, and the prover's and verifier's messages contain, encode, reference, or otherwise contain information that can be used to determine the vector of field elements.

[0034] In one embodiment, a first computing entity and / or a second computing entity agree on the terms of executing a smart contract by exchanging a set of messages. Such messages encode proposed parameters for executing the smart contract, such as one or more Boolean expressions encoding a set of conditions, which determine whether and / or how to execute a set of smart contracts and operations to be executed, based on the conditions that are met. In one embodiment, one computing entity sends a set of parameters to the second computing entity as part of a protocol, and the second computing entity determines whether those parameters are acceptable to the smart contract. If the parameters are unacceptable, the second computing entity may provide the first computing entity with a different set of parameters as a second set of proposed parameters for executing the smart contract. Alternatively, the second computing entity may provide a signal that the first set of parameters was unacceptable, and the first computing entity determines the second set of parameters to provide. In either case, once all parties have signaled agreement on the parameters, either computing entity may, in one embodiment, generate a locking transaction in which one of the outputs is locked by a program (e.g., a smart contract script) and sent to the counterparty of the smart contract. A locking transaction may refer to a transaction that initializes constraints that enable an unlocking transaction. In some examples, an "unlocking transaction" refers to a blockchain transaction that reassociates at least a portion of the digital assets represented by the UTXO of a previous transaction with an entity associated with a blockchain address (e.g., transferring ownership and control).

[0035] In one embodiment, the first computing entity generates a locking transaction and adds transaction inputs that cover the worker fee portion. Note that at this point, the locking transaction is not yet valid because the values ​​of the transaction inputs are not equal to the values ​​of the transaction output of the locking transaction. Continuing the example, when the second computing entity receives the locking transaction, it verifies the smart contract (e.g., the common reference string and the parameters for executing the smart contract), adds the inputs to the locking transaction, unlocks the UTXO, and forwards it to the issuer, who has agreed on the digital asset and also agreed on an output containing the value of the remuneration to be paid to the worker for executing the program (e.g., the smart contract) and the remuneration to that worker. If both the first and second computing entities contribute transaction inputs to the smart contract, the smart contract may be jointly owned by both parties, and the transfer of the smart contract (e.g., exchange or sale) may require certificates from both parties.

[0036] The smart contract 110 may be executed by a third computing entity 106, such as a node in a blockchain network. The third computing entity 106 may be referred to as a worker or prover. In one embodiment, the worker executes the smart contract by performing at least a computation task that involves calculating a function on an input. In one embodiment, the worker is any suitable computer system to which the owner of the smart contract can delegate the computation task. The input, in one embodiment, includes information that proves the identity of the worker, such as a digital signature generated using a private key associated with the worker. In one embodiment, the worker is a computing entity with which the first and second computing entities have agreed to transfer digital assets in exchange for successfully completing the computation task. In one embodiment, the owner of the smart contract is the input x and the evaluation key E K Provide 112 to the prover, who uses the evaluation module to compute the output y against the computation routine (i.e., y = f(x), where the input is x and the function is f), and evaluate key E K A proof of correct execution 116 is generated using this. The proof of correct execution 116 may also be referred to as a proof of legitimacy elsewhere in this specification. In embodiments, the worker is a computer system comprising hardware and / or software, which, when executed by one or more processors of the computer system, includes instructions that cause the computer system to evaluate the values ​​of the internal circuit wires of the QAP and generate an output y of the QAP.

[0037] In this embodiment, the output y, the value of the internal circuit wire (or a subset thereof), and the evaluation key E are used. K This is used to generate proof of legitimacy. Proof π can be stored on the blockchain and verified by multiple parties without the need for an operator to interact with multiple parties separately. In this way, a fourth computing entity (e.g., a verifier computer system) can use the public verification key V. KUsing 114 and Proof π, broadcast transactions can be verified, thereby enabling smart contracts to be verified. In some cases, the owner of the smart contract may retrieve digital assets obstructed by the broadcast transaction if the verification fails. In some cases, the owner of the smart contract can perform proof verification.

[0038] In one embodiment, the verification key 114 and the corresponding proof 116 are generated according to the techniques described above and / or below. Thus, the verifier calculates, for the verifier, a plurality of elliptic curve multiplications (e.g., one for each public input variable) and five pair checks, with one of the five pair checks including an additional pairing multiplication, for the following verification key V K and Proof π are given:

Number

[0039] Verification key V K , Proof π and (a1, a2,..., a N ), given t(x) divides p(x), and thus (x N+1 ,..., x m ) = f(x0,..., x N ), the verifier proceeds as follows. First, check all three α terms: e(α v r v V mid (s)P, Q) = e(r v V mid (s)P, α v Q) e(α w r w W mid (s)P, Q) = e(α w P, r w W mid (s)Q) e(αy r y Y mid (s)P,Q)=e(r y Y mid (s)P,α y Q) Here,

number

number

number

number

number

number

number

number

[0040] Therefore, given the notation from the above section and the examples described in this disclosure, verification, according to one embodiment, includes a set of pair checks of the following elements:

number

[0041] Figure 2 illustrates a computing environment 200 in which a first computing entity 202 and a second computing entity 204 exchange quantities that can be used to determine the power of a shared secret between two or more parties. The first computing entity and the second computing entity 204 may exchange quantities used to compute identical common reference strings (as shown below the horizontal arrows illustrated in Figure 2). In one embodiment, the first and second computing entities are nodes of a blockchain network as described in relation to Figure 1. According to at least one embodiment,

number

number

number

number

number

number

number

number

[0042] As shown, the circuits are described by polynomials v, w, and these polynomials are evaluated by secrets s known only to the party that owns / creates those circuits and the corresponding QAPs (e.g., the owner of the smart contract).

[0043] More precisely, as mentioned above, the client generates the element:

number

[0044] On the other hand, the security of the proposed solution depends on parameter s, and in some embodiments, the remaining (rv ,r w ,α v ,α w ,α y Disclosing β,γ) could reveal information that does not present zero knowledge to the system and / or information that the client does not want to disclose to other entities.

[0045] In one embodiment, in a solution where an operator is required to provide proof of legitimacy, there may be an opcode (or equivalent) for verifying proof of legitimacy against a verification key.

[0046] Throughout this disclosure, unless otherwise stated, polynomials in this specification are field

number

number

number

number

number

number

[0047] In one embodiment, the common reference string is in the format: v(s) = a0 + a1s + a2s 2 +···+a n s n w(s) = b0 + b1s + b2s 2 +···+bn s n It is represented by polynomials v(x) and w(x) evaluated in terms of a secret s, which are expressed as follows:

[0048] In one embodiment, the technique described herein relates to a generator of a related group (e.g., elliptic curve points) in the form: <v(s)> G =〈a0〉 G +〈a1s〉 G +〈a2s 2 > G It is used to determine and share the elliptic curve points of +···. Therefore, in one embodiment, the system and method described herein are used for any integer power r, s r G=〈s r > G It is used to determine and distribute.

[0049] According to at least one embodiment, <s r > G A technique for sharing and distributing is illustrated in Figure 2. As an example, the case n=2 is described in more detail below in relation to Figure 2 and should be considered a non-limiting example of sharing a secret power between parties to a smart contract. Furthermore, it should be noted that in the various embodiments described herein, a threshold is given in advance and it is assumed that the required number of participants agree at the beginning.

[0050] Figure 2 illustrates a technique for sharing and distributing a power of a shared secret between two participants, according to at least one embodiment. As illustrated in Figure 2, according to at least one embodiment, exactly two parties are participants sharing a power of a shared secret (i.e., n=2). The first and second computing entities may be referred to as A and B, respectively. In one embodiment, A and B may exchange the following information: A is <p1(x i )〉 G Send to B, and instead <p2(x i )〉 GReceive it (i ∈ {1, 2}). In this way, both parties can calculate: 〈p(x i )〉 G =〈p1(x i ) + p2(x i )〉 G

[0051] Using Lagrange interpolation (Lagrange polynomial, n.d.), p can be expressed with respect to p(x1) and p(x2), and by 〈p(x i )〉 G to extend 〈p(x)〉 G as (see WP0559):

Number

Number

Number

Table 1

[0052] i For some x, the exchange may appear as follows:

Table 2

[0053] Following this exchange (following a specific pre-planned conversion), both parties <p n (x j )〉 G , especially <p n (0) G =〈s n > G It is possible to calculate this.

[0054] Figure 3 illustrates a computing environment 300 in which a first computing entity 302 and a second computing entity 304 exchange a set of parameters that present zero knowledge to a protocol such as that described in relation to Figure 1. According to various embodiments, the public verification key may have the following form:

number

[0055] On the other hand, the security of the proposed solution depends on parameter s, and in some embodiments, the remaining (r v ,r w ,α v ,α w ,α y Disclosing β,γ) could reveal information that does not present zero knowledge to the system and / or information that the client does not want to disclose to other entities. Therefore, in one embodiment, some or all of the remaining parameters used to generate the verification key 306 are shared using the technique described in relation to Figure 3.

[0056] In one embodiment, the polynomial is exchanged between a first computing entity 302 and a second computing entity 304 (sometimes referred to as A and B, respectively) in accordance with techniques described elsewhere in this disclosure, such as those described in relation to Figures 1, 2, and 4. Thus, in one embodiment, the first computing entity 302 is a set of elliptic curve points.

number

number

[0057] According to one embodiment, G i of

number

number

number

[0058] In one embodiment, element <α v >2,〈α w >2,〈α w >1, <α y >2, <β>1, <β>2 or any combination thereof is i =a·G i It is of the form of . Similar to the case of s, i is a polynomial q i Generate and then x j Evaluate j ∈ {1, ..., m} and select participant j and corresponding q i (x j ) share. Each participant,

number

[0059] In one embodiment, the α parameter is shared by elliptic curve points, while other parameters are represented by scalar values. According to at least one embodiment, for such values, the scalar parameter is shared between two computing entities using the Diffie-Hellman scheme without the need to share the parameter itself. Thus, according to one embodiment, P = {t1,...,t} N Let} be the set of N parameters. In one embodiment, A and B agree using the modulus μ and the multiplicative group Γ of the generator γ, and assume that the participants (A and B) proceed as follows (exponential representation is used here as an explanatory example, but other appropriate representations may be used): For each i ∈ {1,...,N}, the first and second computing entities each have a (secret) random number v A,i , v B,i Create and both sides have (public) elements:

number

number

number

number

[0060] Therefore, the above technology allows the first and second computing entities to perform the task without needing to exchange parameters, instead,

number

[0061] Figure 4 illustrates Figure 400 of a protocol based on a Common Reference String (CRS) between two parties and a corresponding proof of legitimacy (POC) or proof of correct execution. Figure 400 illustrates a first computing entity 402, a second computing entity 404, and a third computing entity 406, where the first computing entity 402 and the second computing entity 404 together make a contribution to the smart contract, which can be unlocked by the third computing entity 406 after the smart contract has been executed. In one embodiment, the protocol is implemented using a blockchain network at least in part.

[0062] As described in more detail (for example in relation to Figure 4) according to this disclosure, schemes and protocols for two participants A and B may be used to generate a shared secret and thus a shared common reference string (CRS) that can be used to verify the correct execution of the relevant circuits. In one embodiment, the scheme assumes an off-chain exchange of data, first between A and B, and then between A+B (or either) and worker C, who performs a computational task on behalf of at least one of A or C. In order to have worker C perform the computational task (e.g., execution of a smart contract), A and B both sign a transaction (which may or may not include a redeem script of a particular P2SH type) that requires worker C to provide proof of legitimacy and prove possession of the correct verification key (VK) to unlock the funds.

[0063] The techniques for implementing the protocols presented in this disclosure do not require any changes to the protocol on existing blockchain networks (for example, they can be implemented on Bitcoin-based blockchains using existing commands that are already supported) in some embodiments. In some embodiments, extensions to the existing set of commands supported by the Bitcoin protocol are also discussed herein—extensions may include new commands (e.g., new opcodes) that may have various advantages, such as improving the efficiency of smart contract execution or reducing the size of smart contracts (reducing the amount of storage space required by nodes on the blockchain network to function correctly). In some embodiments, the cost of verifying smart transactions against the blockchain is based at least in part on the size of the smart contract.

[0064] In one embodiment, the exchange and transfer of other data related to elliptic curve points and common reference strings are transferred off-chain. In one embodiment, the verification key is ultimately broadcast via the exchange of digital assets or otherwise made available on-chain for work to be performed (e.g., execution of the smart contract) by worker C and two parties (A and B) who wish to evaluate the smart contract. Several schemes are possible, as described herein. For example, when A and B prepare the locking transaction, they may or may not each supply a VK or a hash of a VK. In other words, in one embodiment, the majority of the capacity-intensive workload is performed off-chain.

[0065] In one embodiment, the protocol includes both off-chain and on-chain components, as shown by the dotted lines illustrated in Figure 4. The off-chain component may include the communication and exchange of data and information that can occur without storing data in the blockchain ledger. For example, the off-chain component of the protocol may include the exchange of IP packets between a source and a destination (for example, a first computing entity 402 is a source that sends a first set of parameters to a destination, i.e., a second computing entity 404). For example, the on-chain protocol of the protocol may include broadcasting data to the blockchain ledger, which is made available to nodes in the blockchain network.

[0066] In one embodiment, the first computing entity 402 is a set of elliptic curve points based at least partially on the first polynomial.

number

number

[0067] In some embodiments, additional data is transmitted that is not necessary to maintain the confidentiality of the shared secrets but may be necessary to present zero knowledge to the system. For example.

number

number

[0068] In one embodiment, the second computing entity 404 similarly uses a set of elliptic curve points based on a polynomial that may be different from the one used by the first computing entity 402.

number

number

number

[0069] In one embodiment, the exchanged quantities can be used by both the first computing entity 402 and the second computing entity 404 to compute the same common reference string. The third computing entity 406 may or may not provide the common reference string to the third computing entity (e.g., the worker), as it must later prove ownership of the correct verification key. The determination of the same common reference string by the first and second computing entities may be performed off-chain.

[0070] Continuing with the protocol, according to one embodiment, the first and second computing entities agree on a transaction in which they make proportional contributions for the execution of a smart contract. In one embodiment, the first and second computing entities agree on the proportion of contribution and each provides a transaction input that is hindered by the smart contract and can be unlocked by the third computing entity when the smart contract is executed. This may or may not be a P2SH (pay-to-script-hash) type agreement if both the first and second computing entities transfer funds to the same address (address C). A P2SH type script is an element of a verification key or a hash value of a verification key, i.e., h i =HASH(VK i ) may or may not include. In one embodiment, the key is divided into chunks. The smart contract may be broadcast to the blockchain as a first transaction 410 having a first transaction input contributed by the first computing entity 402 and a second transaction input contributed by the second computing entity 404, which serve as worker compensation paid in a ratio agreed upon by the first and second computing entities.

[0071] In one embodiment, a third computing entity 406, also called a worker, unlocks the reward in the second transaction 410 in accordance with the protocol in UK Patent Application No. 1719998.5 and / or UK Patent Application No. 1720768.9, and the third computing entity 406 unlocks the reward for the work (correct execution of the circuit), and in doing so proves that it possesses (a) the correct verification key and (b) a valid proof of legitimacy. Verification may be performed by another computer system (e.g., a blockchain node acting as a verifier) ​​and / or by both or either of the computing entities that are participants in the smart contract.

[0072] Figure 5 shows a descriptive example of a process 500 for generating a two-party common reference string including a verification key and an evaluation key, according to one embodiment. Part or all of process 500 (or any other process or its variations and / or combinations described herein) may be executed under the control of one or more computer systems configured with computer-executable instructions, and may be implemented as code (e.g., computer-executable instructions, one or more computer programs, or one or more applications) that operates together on one or more processors by hardware, software, or a combination thereof. The code may be stored on a computer-readable storage medium in the form of a computer program containing, for example, a plurality of computer-readable instructions executable by one or more processors. The computer-readable storage medium may be a non-temporary computer-readable medium. In some embodiments, at least a portion of the computer-readable instructions available for executing process 500 are not stored using merely temporary signals (e.g., propagating temporary electrical or electromagnetic transmissions). The non-temporary computer-readable medium may include non-temporary data storage circuits (e.g., buffers, caches, and queues) within a transceiver of temporary signals.

[0073] In one embodiment, the system executing process 500 is a computing entity that is a party to the smart contract executing the process, in order to establish at least information that can be used by the system and the parties to the smart contract to compute the same common reference string. The common reference string described in relation to process 500 may be, for example, one that is discussed in relation to Figures 1 to 4. In one embodiment, the common reference string is: v(s) = a0 + a1s + a2S 2 +···+a n s n w(s) = b0 + b1s + b2S 2 +···+b n s n It is expressed by polynomials v(x), w(x) evaluated in terms of a secret s of the form .

[0074] In one embodiment, the first computing entity determines a first polynomial to generate a first set of elliptic curve values. In one embodiment, the system determines <v(s)> for some generator G of the associated group (e.g., elliptic curve points). G =〈a0〉 G +〈a1s〉 G +〈a2s 2 > G Generates elliptic curve points of the form +···,. Unless otherwise specified, the polynomials in this process 500 are field

number

number

number

number

number

number

number

[0075] The first computing entity may make a set of elliptic curve points available to the second computing entity.504 In one embodiment, the system does not need to make the entire set of elliptic curve points available to the second computing entity; rather, in one embodiment, the system may make a subset of the elliptic curve points available to the second computing entity.

number

[0076] For example, according to at least one embodiment, when n=2, the first computing entity is

number

number

number

[0077] The second computing entity is also a party to the smart contract, but it generates a separate set of elliptic curve points for the same input points (e.g., elliptic curve points)

number

[0078] In one embodiment, the system determines the same common reference string based on at least a portion of the first and second sets of elliptic curve points.508 For example, after the exchange of elliptic curve points, Lagrangian interpolation may be used to represent p with respect to p(x1) and p(x2). In one embodiment, both parties to the smart contract agree that the exchanged point <p i (x j )〉 G Therefore, power <p n (x)〉 G (especially, <p n (0) G =〈s n > G ) can be reconstructed. Power <p n (x)〉 G The above polynomial equation can be used for this:

number

[0079] For example, when m=2, this becomes:

number

[0080] In one embodiment, additional parameters (e.g., scalar values ​​and / or elliptic curve points) are exchanged between the first computing entity and the second computing entity in a manner such as that described in relation to Figure 3, and these parameters are the power of the shared secret <s n > G They are used to compute a verification key and / or evaluation key. In one embodiment, the parameters are exchanged without reliance on encryption and / or without reliance on a communication channel that provides a cryptographically verifiable guarantee of confidentiality.

[0081] In one embodiment, the first and second computing entities agree on a transaction and each create a contribution to each transaction input of the smart contract, which can be unlocked by a third computing entity (e.g., a worker) that correctly executes the smart contract.510 In one embodiment, either of the computing entities provides a proportional worker fee. A P2SH type agreement may or may not exist, in which both contribute to the same address (e.g., an address for the worker). In one embodiment, the P2SH script includes elements of a verification key or a hash value of a verification key. By using the techniques described, for example, in relation to UK Patent Application No. 1719998.5 and / or UK Patent Application No. 1720768.9, the worker (e.g., the third computing entity) may unlock (e.g., unlock) the contribution by providing a computationally verifiable certificate that the worker has correct verification and provides a valid proof of legitimacy.

[0082] Figure 6 shows a descriptive example of process 600 for sharing a shared secret power among n parties (e.g., n>2) according to at least one embodiment. Part or all of process 600 (or any other process or its variations and / or combinations described herein) may be executed under the control of one or more computer systems configured with computer executable instructions, and may be implemented as code (e.g., computer executable instructions, one or more computer programs, or one or more applications) operating together on one or more processors by hardware, software, or a combination thereof. The code may be stored on a computer-readable storage medium in the form of a computer program containing, for example, a plurality of computer-readable instructions executable by one or more processors. The computer-readable storage medium may be a non-temporary computer-readable medium. In some embodiments, at least a portion of the computer-readable instructions available for executing process 600 are not stored using merely temporary signals (e.g., propagating temporary electrical or electromagnetic transmissions). The non-temporary computer-readable medium may include non-temporary data storage circuits (e.g., buffers, caches, and queues) within a transceiver of temporary signals. In one embodiment, a threshold equivalent is given in advance, and it is assumed that the required number of participants agree first. This differs from various existing techniques, such as Shamir's secret sharing (4S), in that the sharing of secrets only works under the constraint of reaching a given threshold.

[0083] The sharing of secrets is effective for any number of parties according to various embodiments. In one embodiment, most of the formalism described herein can be applied to multi-party (n>2) scenarios. In some embodiments, the multi-party system (n>2) is defined by certain other parameters (e.g., the following non-elliptic curve (e.g., scalar) parameters: r v , r w , α v , α w , α yThere is no need to hide some or all of β and γ. However, if these parameters remain private according to the protocol, a different approach can be used, such as the one described in relation to Figure 3, for example. v , r w You can hide parameters like these.

[0084] In one embodiment, all participants are a function that maps finite field elements to other finite field elements.

number

[0085] Therefore, by utilizing the techniques described herein, all participants can have the same <f(s)> G It can be guaranteed that it has. For example, in the protocol described according to at least one embodiment, <f(s)> G =〈a0〉 G +〈a1s〉 G +〈a2S 2 > G +···, therefore, for any integer power r, <s r > GBy publicly distributing points in the form of EQ_FSG, the same EQ_FSG can be shared among two or more participants (i.e., n>1), where G is the generator (for example, of elliptic curve points) of the group being discussed.

[0086] In one embodiment, each participant is x i It is possible to generate a polynomial that evaluates to a set of points (x1, x2, ...) ≠ 0 for all i, where the points are known to all parties. In one embodiment, the sum of the polynomials of each participant constitutes a (master) polynomial, whose intersection with the y-axis is secret, i.e.,

number

[0087] To establish s, each participant shares a corresponding polynomial evaluated at different points (x1, x2, ...). More specifically, participant i has p for i, j ∈ {1, ..., m}. i (x j ) create / calculate and <p i (x j )〉 G Send to j. Once these quantities are shared, each participant will have a shared secret powered to s. r 608 can be calculated or determined by other means.

[0088] s r When considering this, this is

number

[0089] <p i (x j )〉 GThere may be a possibility that the power cannot be calculated. This is because the power of a generator is generally not defined. However, all participants can infer <s> from the exchanged <p i (x j )〉 G (since the master polynomial can generally be constructed by Lagrange interpolation (Lagrange polynomial, n.d.)), it is possible to start by examining the power of the Lagrange interpolation polynomial L(x). Lagrange interpolation can be G written as

Number

Number

Number

Number

Number

Number

Number

[0090] This means that participant i (the owner / creator of the polynomial pi) gives <p i (x j )〉 to participant jG Powers, that is, sets:

number

[0091] This is because participant j,

number

number

number

[0092] Consider an example in at least one embodiment where the participant uses an elliptic curve and G is the generator in the corresponding multiplication representation. 2. In the case of participants A and B, A is <p1(x2)> G Send to B, and instead use <p2(x1)> G Participant A receives. Therefore, Participant A, <p(x1)> G =〈p1(x1)+p2(x1)〉 G It is possible to calculate this, and similarly, participant B, <p(x2)> G =〈p1(x2)+p2(x2)〉 G It is possible to calculate this.

[0093] Using Lagrangian interpolation, p can be expressed in terms of p(x1) and p(x2):

number

[0094] Each participant exchanged points <p i (xj )〉 G By which, 〈p(x)〉 G (Especially 〈p(0)〉 G ) can be reconstructed. 〈p n (x)〉 G For higher powers of, polynomial equations from the previous section may be utilized: [Number]

[0095] For m = 2, this becomes: [Number]

[0096] After this exchange (following certain pre - scheduled transformations), both parties can calculate 〈p n (x j )〉 G , especially 〈p n (0)〉 G = 〈s n 〉 G .

[0097] The protocol by Process 600 is described below. Each participant [Number] Since it is necessary to obtain expressions of the form, ordering may be required when exchanging points. Here, we describe such a solution.

[0098] Without loss of generality, according to at least one embodiment, Participant 1 presents a first elliptic curve point. The protocol, in one embodiment, follows these steps: 1. Participant 1 [Number] We distribute this to all participants i≠1, where k1=1,...,n and j=1,...,m, where m is the number of participants. 2. Participant 2 considers k1=0,...,n-1, k2=1,...,n, and j=1,...,m,

number

number

[0099] The l-th participant in the sequence is k for i∈{1,...,l-1} i =0,...,n-1, k l For =1,...,n and j=1,...,m,

number

[0100] In one embodiment, process 600 is,

number

[0101] This specification and the drawings should therefore be considered illustrative, not restrictive. However, it is clear that various modifications and alterations may be made thereto without departing from the scope of the invention as described in the claims. Similarly, other variations are also within the scope of this disclosure. Thus, the disclosed art is susceptible to various modifications and alternative structures, though its particular exemplary embodiments are shown in the drawings and described in detail above. However, it should be understood that there is no intention to limit the invention to one or more specific embodiments disclosed, but rather to cover all modifications, alternative structures and equivalents that fall within the scope of the invention as defined in the appended claims.

[0102] The terms “set” (e.g., “set of items”) or “subset” should be interpreted as a non-empty set containing one or more members, unless otherwise specified or the context contradicts it. Furthermore, unless otherwise specified or the context contradicts it, the term “subset” of a corresponding set does not necessarily refer to an exact subset of the corresponding set, although a subset and a corresponding subset may be equivalent.

[0103] Linking phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" are generally understood in context to indicate that an item, term, etc., may be A, B, or C, or any non-empty subset of the set A, B, and C, unless otherwise specified or clearly contradictory from the context. For example, in the descriptive example of a set having three members, the linking phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: namely {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such linking phrases are generally not intended to imply that a particular embodiment requires that at least one of A, at least one of B, and at least one of C be presented, respectively. Furthermore, unless otherwise specified or clearly from the context, the phrase "based on" means "at least partially based," not "based solely on."

[0104] The operations of the described process may be performed in any suitable order unless otherwise specified or unless clearly contradicted by the context. The described process (or variations and / or combinations thereof) can be executed under the control of one or more computer systems, which consist of executable instructions, and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that operates collectively on one or more processors by hardware or a combination thereof. In some embodiments, the code can be stored on a computer-readable storage medium in the form of a computer program containing, for example, multiple instructions executable by one or more processors. In some embodiments, the computer-readable storage medium is non-temporary.

[0105] The use of any and all example or illustrative language provided (e.g., “like”) is intended solely to better illustrate embodiments of the invention and, unless otherwise requested, does not impose any limitation on the scope of the invention. No language herein should be construed to indicate that any unclaimed element is essential for the practice of the invention.

[0106] Embodiments of the present disclosure are described, including the best mode known to the inventors for carrying out the present invention. Variations of these embodiments will be apparent to those skilled in the art by reading the foregoing description. The inventors expect that those skilled in the art will appropriately use such variations, and the inventors intend that embodiments of the present invention will be carried out in ways other than those specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter described in the appended claims, as permitted by applicable law. Furthermore, any combination of the elements described above in all possible variations thereof is encompassed by the scope of the present disclosure unless otherwise specifically stated or unless it is clearly inconsistent with the context.

[0107] All references, including cited publications, patent applications, and patents, are incorporated by reference to the same extent as if they were described in whole, with each reference specifically incorporated by reference.

[0108] The embodiments described above are illustrative and not limiting to the present invention, and it should be noted that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. The mere fact that certain means are described in different dependent claims does not imply that combinations of those means cannot be used advantageously.

Claims

1. A computer implementation method, wherein in a first computing entity, A step of determining a first set of elliptic curve points for a second computing entity, based at least partially on a first polynomial and at least two elliptic curve points, The steps include making a subset of the first set of elliptic curve points available to the second computing entity, The steps include receiving a second set of elliptic curve points generated using the second polynomial, A step of determining a common reference string including a verification key and an evaluation key based on at least a portion of a first set of elliptic curve points and at least a portion of a second set of elliptic curve points, wherein the common reference string can also be determined by the second computing entity as a result of the first computing entity providing the subset to the second computing entity. A step of generating a smart contract including a first transaction input provided by the first computing entity and a second transaction input provided by the second computing entity, wherein the correct execution of the smart contract by the third computing entity enables the third computing entity to generate blockchain transactions using the output of the smart contract. Methods that include...

2. The first set of elliptic curve points includes the corresponding elliptic curve points for the power of the first polynomial, The method according to claim 1.

3. The first polynomial is at least of degree 2. The method according to claim 1 or 2.

4. The subset is the first set of elliptic curve points, The method according to any one of claims 1 to 3.

5. Secrets are shared between the first computing entity and the second computing entity without using a cryptographically protected communication channel. The method according to any one of claims 1 to 4.

6. The first computing entity and the second computing entity collectively determine the first digital asset and the second digital asset. The method according to any one of claims 1 to 5.

7. A step of determining a third set of elliptic curve points for the second computing entity based on a third polynomial and the at least two elliptic curve points, The steps include making a second subset of the third set of elliptic curve points available to the second computing entity, The steps include receiving the fourth set of elliptic curve points, A step of determining parameters based at least in part on the third set and the fourth set, wherein the parameters are also determinable by the second computing entity as a result of the first computing entity providing the second subset to the second computing entity. Furthermore, determining the common reference string is at least partially based on the parameters, The method according to any one of claims 1 to 6.

8. A step of sharing elliptic curve parameters between the first computing entity and the second computing entity using Shamir's secret sharing scheme, The method according to any one of claims 1 to 7, further comprising:

9. A step of exchanging scalar parameters between the first computing entity and the second computing entity using the Diffie-Hellman method, The method according to any one of claims 1 to 8, further comprising:

10. The smart contract includes a P2SH type unlocking script that enables the third computing entity to unlock the first and second digital assets in response to providing valid proof of correct execution. The method according to any one of claims 1 to 9.

11. The first computing entity makes the subset available to the second computing entity via an off-chain communication channel. The method according to any one of claims 1 to 10.

12. The second polynomial is not accessible to the first computing entity. The method according to any one of claims 1 to 11.

13. The aforementioned at least two elliptic curve points are two different elliptic curve points. The method according to any one of claims 1 to 12.

14. It is a system, Processor and A memory containing an executable instruction that causes the system to execute the computer implementation method described in any one of claims 1 to 13 as a result of execution by the processor, A system that includes this.

15. A non-temporary computer-readable storage medium that stores executable instructions that, as a result of being executed by the processor of a computer system, cause the computer system to perform at least one of the computer implementation methods described in any one of claims 1 to 13.

Images