System and method for multi-party generation of blockchain-based smart contract

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 among multiple (e.g., more than two) parties. More specifically, a verification key for a smart contract is collectively generated by two or more parties of the smart contract, and a third party (e.g., a worker node of a blockchain network) is utilized to execute the smart contract in a computationally verifiable manner. A third computing entity may generate a proof of correct execution of the smart contract that can be used to unlock digital assets blocked by a first computing entity and a second computing entity. The present invention is particularly suitable for use in blockchain networks such as Bitcoin-based blockchain networks, but is not limited thereto.

Background Art

[0002] A blockchain may refer to a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, where a block can be composed of transactions and other information. In some examples, a "blockchain transaction" refers to an input message encoding a structured collection of field values including a set of data and conditions, where satisfying the set of conditions is a prerequisite for the set of fields to be written to the blockchain data structure. For example, in Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. In some embodiments, "digital assets" refer to binary data associated with the right of use. Examples of digital assets include Bitcoin, Ethereum, Litecoin. In some implementations, transferring control of a digital asset can be performed by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block of the blockchain may include the hash of the previous block so that the blocks will be chained together and create a permanent and immutable record of all transactions written to the blockchain from its beginning. Transactions include small programs known as scripts incorporated into their inputs and outputs that specify how and by what the outputs of the transaction can be accessed. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0003] Blockchain technology is most widely known for its use in cryptocurrency implementations, but digital entrepreneurs are beginning to explore the use of both the Bitcoin-based cryptocurrency security system and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if the blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions, while their uses are more extensive, could take advantage of the benefits of the blockchain, such as permanence, an event tamper-proof record, 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 be able to process inputs to generate results and may then include rules that can cause actions to be executed 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. Summary of the Invention Problems to be Solved by the Invention

[0005] Accordingly, it is desirable to provide a protocol for recording verification keys of multiple parties on a blockchain by exchanging quantities that can be used to determine the power of a shared secret among two or more parties. In various embodiments, it may be desirable for two or more parties of a smart contract to exchange quantities that can be used to determine a common reference string including verification keys and evaluation keys. 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 further do not require those parties to establish a communication channel that requires cryptographically verifiable guarantees of the confidentiality of data exchanged over the communication channel.

[0006] Such an improved solution has been devised.

Means for Solving the Problems

[0007] Accordingly, according to this specification, a system and method defined in the appended claims are provided.

[0008] According to the present invention, a computer-implemented method for a node of a blockchain network may be provided. The computer-implemented method includes, at a first computing entity, determining a set of elliptic curve points for a second computing entity, at least partially based on a first polynomial and at least two elliptic curve points; 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 a second polynomial; determining a power of a secret, at least partially based on the first and second sets; determining a common reference string including a verification key and an evaluation key, at least partially based on the power of the secret, wherein the common reference string is also determinable by the second computing entity as a result of the first computing entity providing the subset to the second computing entity; 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 a third computing entity can generate a blockchain transaction using the output of the smart contract as a result of correctly executing the smart contract.

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

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

[0011] Preferably, the above subset is a set of elliptic curve points. Further, unless otherwise specified or inconsistent with the context, the term "subset" of a corresponding set does not necessarily denote an exact subset of the corresponding set, but the subset and the corresponding set may be equal.

[0012] Secrets may be shared between a first computing entity and a second computing entity without using an encrypted 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 determining, based on a third polynomial and at least two elliptic curve points, a third set of elliptic curve points for a second computing entity; making available to the second computing entity a second subset of the third set of elliptic curve points; receiving a fourth set of elliptic curve points; and determining a parameter based at least in part on the third and fourth sets, the parameter 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 the determination of the common reference string is further based at least in part on the parameter.

[0015] Preferably, some or all of the methods described herein may further include 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 exchanging scalar parameters between a first computing entity and a second computing entity using the Diffie-Hellman method (e.g., using the Diffie-Hellman key exchange algorithm).

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

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

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

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

[0021] It is also desirable to provide a system comprising a processor and a memory including executable instructions that cause the system to execute any of the methods according to the claims as a result of execution by the processor.

[0022] It is also desirable to provide a non-transitory computer-readable storage medium storing executable instructions that cause a computer system to execute at least any of the methods according to the claims as a result of execution by one or more processors of the computer system.

Brief Description of the Drawings

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

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0024] FIG. 1 illustrates a blockchain environment in which various embodiments can be implemented.

[0025] The present disclosure describes techniques that can be utilized to implement a system and method that enables multiple parties to securely share elements of a group where an exponent or multiplicative coefficient depends on powers of a shared secret. Quantities may be shared such that multiple parties exchange quantities based on a shared secret (e.g., powers of a shared secret) without disclosing the shared secret. Thus, in various embodiments, a plurality of n participants establish an expression of a power of a shared secret (e.g., in the multiplicative case <S i 〉 G ).

[0026] In an embodiment, the protocol utilization techniques and methods described herein are used by two parties of a smart contract to share a quantity that can be used by these parties without sharing the secret itself and without revealing information that would allow another computing entity (e.g., a computing entity that is not a party to the smart contract) to determine that secret, and to determine a power of the shared secret. In one embodiment, the protocol includes a first party of the smart contract calculating a first set of parameters to be sent to a second party of the smart contract, and the second party calculating a second set of parameters and presenting these parameters to the first party, where upon exchange of the parameters as described above, both parties can calculate the same common reference string including a verification key. The parties may then agree on a transaction, in such a transaction, the parties make proportionate contributions of digital assets to a smart contract that can be locked and unlocked (e.g., used) for an address (e.g., the address of a miner node of a blockchain network). In one embodiment, off-chain communication between parties of a smart contract is limited to the exchange of parameters used to generate the common reference string, but security guarantees are maintained (e.g., based on parameters exchanged by an adversary or other computing entity that is not a party to the smart contract, the private key is not revealed or otherwise determinable). In one embodiment, two parties (or more generally, two or more parties) utilize techniques for sharing a power of a shared secret in a manner described elsewhere herein, e.g., in connection with FIGS. 1-7.

[0027] Reference may be made to FIG. 1, which illustrates an exemplary computing environment in which various embodiments of the present disclosure may be implemented. The systems and methods described herein may relate to a protocol for the parties to a smart contract to exchange quantities that can be used by a first and a second computing entity to compute the same common reference string. FIG. 1 illustrates a computing environment 100 that includes a first computing entity 102 and a second computing entity 104 that exchange a set of parameters. Such a set of parameters enables both the first computing entity and the second computing entity 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 of the 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 against a blockchain 118 as illustrated in FIG. 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 or in relation to the execution of the smart contract, the third computing entity (e.g., a worker) may generate a proof of correct execution 116 of the smart contract based at least in part 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 a blockchain network operating 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 a proof issued to the blockchain network 118 is correct.

[0028] According to at least one embodiment, the first computing entity 102 and the second computing entity 104 are computer systems that are parties to a smart contract. A party to a smart contract may refer to two or more computing entities that agree to the conditions for the execution of the smart contract (e.g., in accordance with user input provided through a related user input device). The first computing entity 102 and the second computing entity 104 may both agree to the smart contract and contribute transaction inputs to the smart contract, whereby each transaction input of the smart contract is blocked (e.g., used) as a result of the worker node providing proof of correct execution of the smart contract by a locking script. The systems and methods described herein enable the locking script to protect the verification key V K from being modified, check the validity of the proof π, and thereby enable the execution of a zero-knowledge protocol for the blockchain during transaction verification.

[0029] In various embodiments, the first computing entity 102 and the second computing entity 104, in one embodiment, agree to the smart contract by exchanging a set of messages that encode parameters of the smart contract, such as dates, times, conditions, and actions (e.g., transfer of control of digital assets), used to control the execution of the smart contract. For example, a smart contract (e.g., an executable program) may undertake to insure a party against the delay of a particular flight, and the execution of the program may include using external data such as flight information of a particular commercial flight on a particular day to determine whether that particular flight was delayed. If the flight is delayed, the party to the program may receive a transfer of assets (e.g., a smart contract providing travel insurance for the delay).

[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 convert the smart contract 110 into an arithmetic circuit consisting of "wires" that carry values from fields

Number

[0031] Verifiable computation is a technique that enables the generation of a proof of computation. In one embodiment, such a technique is utilized by a client to outsource the evaluation of a function f with respect to an input x to another computing entity, referred to herein as a prover. In some cases, the client may be computationally limited such that it is impossible for the client to execute the evaluation of the function (e.g., the predicted runtime of the computation using the computing resources available to the client exceeds an acceptable maximum threshold), although this is not necessarily the case, and the client may generally delegate the evaluation of the function f with respect to the input x based on any suitable criteria such as, for example, the computation runtime, the computation cost (e.g., the financial cost of allocating computing resources to execute 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 the present disclosure. In one embodiment, the prover (e.g., a blockchain node) evaluates the function f with respect to the input x and generates an output y and a proof π of the correctness of the output y that can be verified by the client and / or other computing entities such as other nodes of the blockchain network as described above. The proof, which may also be referred to as an argument, can be verified faster than performing the actual computation, and thus, the computational overhead can be reduced (e.g., reducing the power overhead and the cost associated with powering and executing the computing resources) by verifying the correctness of the proof instead of recomputing the function f with respect to the input x to determine the correctness of the output generated by the prover as described above. In zero-knowledge verifiable computation, the prover provides the client with a proof that the prover knows an input having certain properties.

[0033] An effective variant 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 where the prover computes multiple group elements using general group operations and the verifier checks the proof using pairing product equations. In one embodiment, linear interactive proofs function over finite fields, and the prover's and verifier's messages contain, encode, reference, or otherwise include information that can be used to determine vectors of field elements.

[0034] In one embodiment, the first computing entity and / or the second computing entity agree on the terms of the execution of the smart contract by exchanging a set of messages. Such messages encode a proposed set of parameters for the execution of the smart contract, such as one or more boolean expressions that encode a set of conditions that determine whether and / or how to execute a set of smart contracts and operations to be performed, for example, based on conditions that are satisfied. In one embodiment, a computing entity sends a set of parameters to a second computing entity as part of a protocol, and the second computing entity determines whether those parameters are acceptable for the smart contract. If the parameters are not acceptable, the second computing entity may provide a different set of parameters to the first computing entity as a second set of proposed parameters for the execution of the smart contract. Also, the second computing entity may provide a signal that the first set of parameters was not acceptable, and the first computing entity determines a second set of parameters to provide. In either case, when all parties signal agreement on the parameters, in one embodiment, either computing entity can generate a locking transaction, where 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 can enable an unlocking transaction. In some examples, an "unlocking transaction" refers to a blockchain transaction that re-associates (e.g., transfers ownership and control of) at least a portion of a digital asset represented by a UTXO of a previous transaction to an entity associated with a blockchain address.

[0035] In one embodiment, the first computing entity generates a locking transaction and adds a transaction input that encompasses the worker fee portion. Note that at this point, the locking transaction is not yet valid. This is because the value of the transaction input is not equal to the value of the transaction output of the locking transaction. Continuing with the example, when the second computing entity receives the locking transaction, the second computing entity verifies the smart contract (e.g., verifies the common reference string and the parameters for the execution of the smart contract), adds the input to the locking transaction, unlocks the UTXO, agrees on the digital asset, and transfers it to the issuer that also agrees on the output having the reward to be paid to the worker for the execution of the program (e.g., smart contract) and the value of the reward for the worker. If both the first computing entity and the second computing entity contribute transaction inputs to the smart contract, the smart contract may be jointly owned by both parties, and the transfer (e.g., exchange or sale) of the smart contract may require certificates from both parties.

[0036] The smart contract 110 may be executed by a third computing entity 106, such as a node of a blockchain network. The third computing entity 106 may be referred to as an operator or prover. In one embodiment, the operator executes the smart contract by at least performing a computing task involving the calculation of a function on an input. In one embodiment, the operator is any suitable computer system on which the owner of the smart contract may delegate the computing task. The input includes, in one embodiment, information proving the identity of the operator, such as a digital signature generated using a private key associated with the operator. In one embodiment, the operator is a computing entity with which the first and second computing entities have agreed to transfer digital assets in return for successfully completing the computing task. The owner of the smart contract provides, in one embodiment, the input x and the evaluation key E K 112 to the prover, and the prover calculates the output y using an evaluation module for the computing routine (i.e., y = f(x), where the input is x and the function is f), and generates a proof 116 of correct execution using the evaluation key E K . The proof 116 of correct execution may also be referred to as a proof of validity elsewhere in this specification. In an embodiment, the operator is a computer system comprising hardware and / or software that, when executed by one or more processors of the computer system, causes the computer system to evaluate the values of the internal circuit wires of the QAP and generate the output y of the QAP.

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

[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, and one of the five pair checks includes an additional pairing multiplication, and 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] Thus, considering the notations from the above sections and the examples described in this disclosure, verification, according to one embodiment, includes a set of pair checks of the following elements:

Number

[0041] FIG. 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 among two or more parties. The first computing entity and the second computing entity 204 may exchange quantities used to compute the same common reference string (as illustrated below the horizontal arrows shown in FIG. 2). In one embodiment, the first computing entity and the second computing entity are nodes of a blockchain network according to that described in connection with FIG. 1. According to at least one embodiment,

Number

Number

Number

Number

Number

Number

Number

Number

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

[0043] More precisely, as described above, the client generates elements:

Number

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

[0045] In one embodiment, in a solution that requires an operator to provide proof of validity, there may be an opcode (or equivalent) for verifying the proof of validity against a verification key.

[0046] Throughout this disclosure, unless otherwise stated, the polynomials in this specification are defined over a field

Number

Number

Number

Number

Number

Number

[0047] In one embodiment, the common reference string has the form: 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 with the secret s.

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

[0049] Techniques for sharing and distributing 〈s r 〉 G according to at least one embodiment are illustrated in FIG. 2. As an example, the case of n = 2 is described in more detail below in connection with FIG. 2 and should be considered a non-limiting example of sharing a secret power among the parties to a smart contract. Further, note that in the various embodiments described herein, something corresponding to a threshold is given in advance and it is assumed that the required number of participants first agree.

[0050] FIG. 2 illustrates techniques for sharing and distributing a shared secret power in the case between two participants according to at least one embodiment. As illustrated in FIG. 2, according to at least one embodiment, exactly two parties are the participants sharing the shared secret power (i.e., in the case of 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 sends 〈p1(x i )〉 G to B and in return receives 〈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 in terms of p(x1) and p(x2), and 〈p(x i )〉 G to extend 〈p(x)〉 G as (see WP0559):

Number

Number

Number

Table 1

[0052] Typically, the exchange may look like this (for some x i ):

Table 2

[0053] After this exchange (following certain pre-scheduled transformations), both parties can calculate <p n (x j )〉 G , and in particular <p n (0)〉 G = <s n 〉 G .

[0054] FIG. 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 connection with FIG. 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 the parameter s, and in some embodiments, making public the remaining (r v , r w , α v , α w , α y , β, γ) may 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. Thus, in one embodiment, some or all of the remaining parameters used to generate the verification key 306 are shared using the techniques described in connection with FIG. 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) according to techniques described elsewhere in this disclosure, such as those described in connection with FIGS. 1, 2, and 4. Thus, in one embodiment, the first computing entity 302 computes a set of elliptic curve points

Number

Number

[0057] According to one embodiment, let G i be

Number

Number

Number

[0058] In one embodiment, the elements 〈α v 〉2, 〈α w 〉2, 〈α w 〉1, 〈α y 〉2, 〈β〉1, 〈β〉2 or some combination thereof are of the form 〈a〉 i = a·G i . Similar to the case of s, i generates a polynomial q i , evaluates it at x j , j ∈ {1,..., m}, and shares the corresponding q i (x j ) with participant j. Each participant

Number

[0059] In one embodiment, the α parameter is shared by elliptic curve points, while the other parameters are made as scalar values. For such values, according to at least one embodiment, without the need to share the parameter itself, the Diffie-Hellman scheme is used to share scalar parameters between two computing entities. Thus, according to one embodiment, P = {t1,..., t N} is a set of N parameters. In one embodiment, A and B have agreed using the multiplicative group Γ of the modulus μ and the generator γ, and the participants (A and B) are assumed to follow the following steps (where exponential notation is used as an illustrative example here, but other suitable notations may be used): For each i ∈ {1,..., N}, the first and second computing entities each create a (secret) random number v A,i v B,i and both derive the (public) elements:

Number

Number

Number

Number

[0060] Thus, the above technique enables the first and second computing entities to exchange

Number

[0061] FIG. 4 illustrates a protocol diagram 400 of a common reference string (CRS) for two parties and a corresponding proof of correctness (POC) or proof of proper execution. Diagram 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 contribute to a smart contract that can be unlocked by the third computing entity 406 after the execution of the smart contract. In one embodiment, the protocol is implemented at least in part using a blockchain network.

[0062] According to the present disclosure, as will be described in more detail (e.g., in relation to FIG. 4), a scheme and protocol for two participants A and B may be utilized to generate a shared secret and thus a shared common reference string (CRS) that can be used to verify the correct execution of the associated circuitry. 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 a worker C who executes a computational task instead of at least one of A or C. To have the worker C execute a computational task (e.g., execution of a smart contract), both A and B require a transaction (which may or may not include a specific P2SH-type redeem script) in which the worker C provides a proof of correctness and proves possession of the correct verification key (VK) to unlock the funds.

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

[0064] In one embodiment, the exchange and transfer of elliptic curve points and other data related to the common reference string are transferred off-chain. In one embodiment, the verification key is ultimately broadcast via the exchange of digital assets or otherwise made on-chain for the work (such as the execution of a smart contract) to be performed by worker C and the two parties (A and B) desiring the evaluation of the smart contract. As described herein, several schemes are possible. For example, A and B may or may not supply the VK or the hash of the VK when preparing the locking transaction. In other words, in one embodiment, most of the capacity-intensive workload is performed off-chain.

[0065] In one embodiment, the protocol includes both off-chain and on-chain components, as indicated by the dotted line shown in FIG. 4. The off-chain component may include 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 (e.g., the first computing entity 402 is the source that sends a set of first parameters to the destination, i.e., the second computing entity 404). For example, the on-chain protocol of the protocol may include broadcasting data to the blockchain ledger made available to the nodes of the blockchain network.

[0066] In one embodiment, the first computing entity 402 calculates a set of elliptic curve points based at least in part on a first polynomial. The first computing entity 402 may send data to a second computing entity 404 that includes at least a portion of the set of elliptic curve points. For example, the first computing entity 402 may send the complete set of elliptic curve points. As a second example, the first computing entity 402 may send a subset of the elliptic curve points

Number

Number

Number

Number

[0067] In some embodiments, additional data is sent that may not be required to maintain the secrecy of the shared secret s but may be required to present zero knowledge to the system. For example

Number

Number

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

Number

Number

Number

[0069] In one embodiment, the exchanged quantity can be utilized by both the first computing entity 402 and the second computing entity 404 to calculate the same common reference string. Since the third computing entity 406 will later have to prove ownership of the correct verification key, they may or may not provide the common reference string to the third computing entity (e.g., the operator). The determination of the same common reference string by the first and second computing entities may be executed 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 the smart contract. In one embodiment, the first and second computing entities agree on the ratio of the contributions and each provide a transaction input that is locked by the third computing entity during the execution of the smart contract and can be unlocked by the third computing entity. This may or may not be a pay-to-script-hash (P2SH) type of agreement when both the first and second computing entities transfer funds to the same address (the address of C). The P2SH type of script may or may not include an element of the verification key or the hash value of the verification key, i.e., h i =HASH(VK i ). In one embodiment, the key is split into chunks. The smart contract functions as a worker reward paid in the ratio agreed upon by the first and second computing entities, and is 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.

[0071] In one embodiment, a third computing entity 406, also referred to as an operator, unlocks the rewards within the second transaction 410 according to the protocol in UK Patent Application No. 1719998.5 and / or UK Patent Application No. 1720768.9. The third computing entity 406 unlocks the rewards for work (correct execution of the circuit), and in doing so, proves that it owns (a) the correct verification key and (b) a valid proof of legitimacy. The verification may be performed by another computer system (e.g., a node of the blockchain that is a verifier) and / or by both or either of the computing entities that are participants in the smart contract.

[0072] FIG. 5 shows an illustrative 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. Some 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 including, for example, a plurality of computer-readable instructions executable by one or more processors. The computer-readable storage medium may be a non-transitory computer-readable medium. In some embodiments, at least a portion of the computer-readable instructions usable to execute process 500 are not stored using merely a transient signal (e.g., a propagating transient electrical or electromagnetic transmission). The non-transitory computer-readable medium may include non-transitory data storage circuits (e.g., buffers, caches, and queues) within a transceiver of the transient signal.

[0073] In one embodiment, the system that executes process 500 is a computing entity that is a party to the smart contract that executes the process, at least to establish 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 connection with process 500 may, for example, follow that discussed in connection with FIGS. 1-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 represented by polynomials v(x), w(x) evaluated at a secret s of the form

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

Number

Number

Number

Number

Number

Number

Number

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

Number

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

Number

Number

Number

[0077] The second computing entity is also a party to the smart contract, but separately generates a set of elliptic curve points for the same input point (for example, generates elliptic curve points

Number

[0078] In one embodiment, the system determines a 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, Lagrange interpolation may be utilized to represent p with respect to p(x1) and p(x2). In one embodiment, both parties to the smart contract use the exchanged points 〈p i (x j )〉 G to reconstruct the power 〈p n (x)〉 G (in particular, 〈p n (0)〉 G = 〈s n 〉 G ). The polynomial equation described above may be utilized for the power 〈p n (x)〉 G :

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 a first computing entity and a second computing entity in a manner such as that described in relation to FIG. 3, for example, and those parameters are used, along with the power of the shared secret <s n 〉 G to compute a verification key and / or an evaluation key. In one embodiment, the parameters are exchanged without reliance on encryption and / or without reliance on a communication channel that provides cryptographically verifiable guarantees of confidentiality.

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

[0082] Figure 6 shows an illustrative example of a process 600 for sharing a power of a shared secret among n parties (e.g., n > 2) according to at least one embodiment. Some 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 using computer-executable instructions, 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 including, for example, a plurality of computer-readable instructions executable by one or more processors. The computer-readable storage medium may be a non-transitory computer-readable medium. In some embodiments, at least a portion of the computer-readable instructions usable to execute process 600 are not stored using merely a transient signal (e.g., a propagating transient electrical or electromagnetic transmission). The non-transitory computer-readable medium may include non-transitory data storage circuits (e.g., buffers, caches, and queues) within a transceiver of the transient signal. In one embodiment, something equivalent to a threshold is provided in advance, and it is assumed that the required number of participants first agree. This is different from various existing techniques such as those described by Shamir's secret sharing method (4S), where secret sharing only functions under the limitation of reaching a given threshold.

[0083] According to various embodiments, secret sharing is effective for any number of parties. In one embodiment, most of the formalism described in this disclosure can be applied to a multi-party (n > 2) scenario. In some embodiments, a multi-party system (n > 2) has certain other parameters (e.g., the following non-elliptic curve (e.g., scalar) parameters: r v r w α v α w α yIt is not necessary to hide some or all of α, β, γ. However, if these parameters remain private according to the protocol, different approaches such as those described in relation to Figure 3 can be utilized to hide parameters such as r v , r w and the like.

[0084] In one embodiment, all participants agree on a function

Number

[0085] Thus, using the techniques described herein, it can be guaranteed that all participants have the same <f(s)> G . For example, in the protocol described according to at least one embodiment, <f(s)> G = <a0> G + <a1s> G + <a2S 2 > G + ···, so for any integer power r, <s r > GBy publicly distributing points in the form of, the same EQ_FSG can be shared among two or more participants (i.e., n > 1), where G is a generator (e.g., an elliptic curve point) of the group under discussion.

[0086] In one embodiment, each participant can generate a polynomial evaluated at a set of points (x1, x2,...) where x i ≠ 0 ∀i, and the points can be known to all parties. In one embodiment, the sum of the polynomials of each participant constitutes a (master) polynomial, and its intersection with the y-axis is secret, i.e., [Number] However, P(0) = s, where m is the number of participants. The above intersection with the y-axis may be referred to as the intersection point.

[0087] To establish s, each participant shares the corresponding polynomial evaluated at different points (x1, x2,...). More specifically, participant i creates / calculates p i (x j ) and sends <p i (x j )〉 G to j. When these quantities are shared, each participant can calculate or otherwise determine the shared secret power s r .

[0088] s r When considering, this amounts to [Number] sharing the expression of, so a little more scrutiny is needed.

[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, since all participants can infer <s> by <p i (x j )〉 G (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 )〉G a power, i.e., a set: [Number] which means that it can provide

[0091] This enables participant j to [Number] (and similarly, [Number] ) etc. to be calculated. In one embodiment, the participant [Number] calculates an expression in the form of

[0092] Consider an example where, according to at least one embodiment, the participant uses an elliptic curve and G is the generator in the corresponding multiplication expression. For two participants A and B, A sends <p1(x2)> G to B and receives <p2(x1)> G in return. Thus, participant A can <p(x1)> G = <p1(x1) + p2(x1)> G calculate, and similarly, participant B can <p(x2)> G = <p1(x2) + p2(x2)> G calculate.

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

[0094] Each participant has the exchanged point <p i (xj )〉 G By which, 〈p(x)〉 G (In particular 〈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 , in particular 〈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 the steps below: 1. Participant 1 [Number] Distribute to all participants where i≠1, where k1 = 1,...,n and j = 1,...,m, where m is the number of participants here. 2. Participant 2, for k1 = 0,...,n - 1, k2 = 1,...,n and j = 1,...,m,

Number

Number

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

Number

[0100] In one embodiment, process 600 includes a plurality of m participants (e.g., more than two participants) that exchange a set of points of the form

Number

[0101] This specification and the drawings are, therefore, to be regarded in an illustrative rather than a limiting sense. However, it is obvious that various modifications and changes may be made thereto without departing from the scope of the invention as set forth in the claims. Similarly, other variations are within the scope of the disclosure. Accordingly, the disclosed technology is susceptible to various modifications and alternative constructions, although the specific illustrative embodiments thereof are shown in the drawings and described in detail above. However, it is not intended to limit the invention to the one or more specific embodiments disclosed, and on the contrary, it is intended to cover all modifications, alternative constructions, and equivalents within the scope of the invention as defined by the appended claims.

[0102] The use of the term "set" (e.g., "set of items") or "subset" shall be construed as a non-empty set containing one or more members, unless otherwise specified or inconsistent with the context. Further, unless otherwise specified or inconsistent with the context, the term "subset" of a corresponding set does not necessarily denote a proper subset of the corresponding set, but the subset and the corresponding subset may be equal.

[0103] Conjunctive phrases such as "at least one of A, B, and C" or "at least one of A, B, and C" are understood in the context as commonly used to indicate that an item, term, etc. can be any one of A or B or C, or any non-empty subset of the set of A and B and C, unless otherwise specified or clearly inconsistent with the context. For example, in an illustrative example of a set with three members, the conjunctive 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 conjunctive phrases are generally not intended to imply that a particular embodiment requires at least one of each of at least one of A, at least one of B, and at least one of C to be presented. Further, unless otherwise specified or not apparent from the context, the phrase "based on" means "based at least in part on" rather than "based solely on".

[0104] The operations of the described process can be performed in any suitable order unless otherwise specified or clearly inconsistent with the context. The described process (or its variations and / or combinations) can be executed under the control of one or more computer systems configured with executable instructions and implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that collectively operate 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 including a plurality of instructions executable by, for example, one or more processors. In some embodiments, the computer-readable storage medium is non-transitory.

[0105] The use of any and all examples or exemplary language provided (e.g., "such as") is merely intended to better illustrate embodiments of the present invention and does not impose a limitation on the scope of the present invention unless otherwise claimed. No language in this specification should be construed as indicating any unclaimed element as essential to the practice of the present 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 upon reading the foregoing description. The inventors expect those skilled in the art to appropriately use such variations, and the inventors intend for the embodiments of the present invention to be practiced in other ways than specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the appended claims as permitted by applicable law. Further, any combination of the above-described elements in all possible variations thereof is included within the scope of the present disclosure unless otherwise stated or clearly contradicted by context.

[0107] All references, including the publications, patent applications, and patents cited, are incorporated by reference to the same extent as if each reference had been individually and specifically incorporated by reference and were set forth in its entirety.

[0108] Note that the above-described embodiments are illustrative rather than limiting of the present invention, and those skilled in the art can design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of those means cannot be advantageously used.

Claims

1. 1. A computer-implemented method, comprising: determining a set of elliptic curve points for the second computing entity based at least in part on the first polynomial and the at least two elliptic curve points; making available a subset of the set of elliptic curve points to the second computing entity; receiving a second set of elliptic curve points generated using a second polynomial; determining a common reference string comprising a verification key and an evaluation key, said common reference string also determinable by the second computing entity as a result of the first computing entity providing said subset to said second computing entity; generating a smart contract comprising a first transaction input provided by the first computing entity and a second transaction input provided by the second computing entity, where correct execution of the smart contract by a third computing entity enables the third computing entity to generate a blockchain transaction using an output of the smart contract; A method comprising:

2. the set of elliptic curve points includes corresponding elliptic curve points for powers of the first polynomial. The method of claim 1.

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

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

5. a secret is shared between the first computing entity and the second computing entity without using a cryptographically protected communications channel; A method according to any one of claims 1 to 4.

6. the first computing entity and the second computing entity collectively determine a first digital asset and a second digital asset.

6. The method according to any one of claims 1 to 5.

7. 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; making available a second subset of the third set of elliptic curve points to the second computing entity; receiving a fourth set of elliptic curve points; determining a parameter based at least in part on the third set and the fourth set, the parameter 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 wherein determining the common reference string is further based at least in part on the parameters.

7. The method according to any one of claims 1 to 6.

8. sharing elliptic curve parameters between the first computing entity and the second computing entity using Shamir's secret sharing scheme; The method of claim 1 , further comprising:

9. exchanging scalar parameters between the first computing entity and the second computing entity using Diffie-Hellman; The method of claim 1 , further comprising:

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

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

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

13. the at least two elliptic curve points are two different elliptic curve points; 13. A method according to any preceding claim.

14. 1. A system comprising: A processor; a memory containing executable instructions which, upon execution by the processor, cause the system to perform the computer-implemented method of any one of claims 1 to 13; Including, the system.

15. A non-transitory computer readable storage medium storing executable instructions which, when executed by a processor of a computer system, cause the computer system to perform at least the computer-implemented method of any one of claims 1 to 13.

Images