Systems and methods for securely sharing cryptographic material

Abstract

A method is provided for multiple participants to generate and exchange quantities based on a shared secret without each of them revealing the shared secret. A method performed by a computing entity includes agreeing, among multiple participants, on a function for mapping finite field elements, generating, for each participant, a polynomial that is evaluated at a set of points, sharing the corresponding polynomial for each participant with the corresponding participant, and evaluating each polynomial at a set of points having non-zero finite field coordinates. Each evaluation value is represented in the group by raising the group's generator to the evaluation value. The method also includes using the received polynomial evaluation values ​​to construct a master polynomial that corresponds to the sum of the polynomials of the multiple computing entities to determine, for each participant, a power of a shared secret s.

Description

[Technical Field]

[0001] The present invention relates generally to computer security and verification, and more specifically to techniques that enable multiple (e.g., more than two) parties to share elements of a group whose exponents and multiplicative coefficients depend on powers of a shared secret. Quantities may be shared such that the multiple parties exchange quantities based on a shared secret (e.g., powers of a shared secret) without revealing the shared secret. The present invention is particularly suited, but not limited to, for use in smart contracts, where the multiple parties may be respective parties to a smart contract that agree on parameters for the smart contract. The present invention may utilize cryptographic and mathematical techniques to share quantities for security-related benefits. [Background technology]

[0002] A blockchain may refer to a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system composed of blocks, which may consist of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured collection of field values ​​containing data and a set of 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 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 usage rights. Examples of digital assets include Bitcoin, Ether, and 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 in a blockchain may include a hash of the previous block, such that blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts that are embedded in their inputs and outputs, specifying how and by what the transaction's outputs can be accessed. In 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 implementing cryptocurrencies, 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 to be able to use blockchain to automate tasks and processes that are not limited to the cryptocurrency realm. Such solutions, while more versatile in their uses, would be able to take advantage of the benefits of blockchain (e.g., persistence, tamper-proof record of events, distributed processing, etc.).

[0004] This disclosure describes technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program may be a machine-readable, executable program recorded in a blockchain transaction. A blockchain-based computer program may include rules that can process inputs to generate results and then cause actions to be performed depending on those results. One area of ​​current research is the use of blockchain-based computer programs for the implementation of "smart contracts." Unlike traditional contracts that are written in natural language, smart contracts may be computer programs designed to automate the execution of the terms of a machine-readable contract or agreement. Summary of the Invention [Problem to be solved by the invention]

[0005] It is therefore desirable to provide a protocol for recording multi-party verification keys on a blockchain by exchanging a quantity 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 a quantity that can be used to determine a common reference string that includes a verification key and an evaluation key. In various embodiments, the techniques described herein enable two or more parties to exchange powers of a shared secret without using cryptographic techniques such as encryption, and further, do not require the parties to establish a communication channel that requires cryptographically verifiable guarantees of confidentiality of data exchanged over the communication channel. Thus, the present invention provides an improved security and verification solution.

[0006] Such an improved solution has been devised. [Means for solving the problem]

[0007] Thus, there is provided herein a system and method as defined in the appended claims.

[0008] According to the present invention, a computer-implemented method may be provided for a node of a blockchain network, the computer-implemented method including: determining, at a participant of a plurality of participants, a function usable to map a finite field element; generating a polynomial that evaluates at a set of points based on a number of participants; distributing the polynomial to corresponding participants of the plurality of participants; determining a sum of the polynomials for each participant of the plurality of participants, the sum corresponding to a power of a secret; and collectively generating blockchain transactions among the plurality of participants based on the secret.

[0009] Preferably, the set of points is a set of elliptic curve points.

[0010] Preferably, the determination of the sum of polynomials is based on Lagrange interpolation.

[0011] The methods described herein may further include determining a common reference string determinable by multiple participants based at least in part on the secret power.

[0012] The methods described herein may further include receiving a corresponding value of the polynomial from each participant of the plurality of participants.

[0013] Preferably, off-chain communication is utilized in distributing the polynomial values ​​to the corresponding participants, which may refer to data communication that is not broadcast to and / or verifiable by the blockchain network.

[0014] Preferably, the functions that can be used to map the finite field elements act as coefficients or exponents of a generator of the group.

[0015] Preferably, the plurality of participants is exactly two participants.

[0016] The secret may be determined based on a sum of polynomials evaluated at a particular point, such as a particular elliptic curve point.

[0017] The particular point may be an intersection point such that the sum of each participant's polynomials constitutes a (master) polynomial, whose intersection with the y-axis is secret.

[0018] The set of points may exclude the intersection point, in other words, in at least some cases the intersection point is not a member of the set of points.

[0019] The polynomial evaluated at the set of points may be of at least second degree.

[0020] Preferably, each point in the set of points is different such that there are no duplicate points in the set of points.

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

[0022] It is also desirable to provide a non-transitory computer-readable storage medium storing executable instructions that, upon execution by one or more processors of a computer system, cause the computer system to perform at least any of the claimed methods. [Brief explanation of the drawings]

[0023] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates a computing environment in which multiple parties to a smart contract agree with a third party to execute the smart contract. [Figure 2] 1 illustrates a computing environment in which a first computing entity and a second computing entity exchange a quantity that can be used to determine the power of a shared secret between two or more parties. [Figure 3] 1 illustrates a computing environment in which a first computing entity and a second computing entity exchange sets of parameters that render zero-knowledge. [Figure 4]1 is a diagram of a protocol based on a two-party common reference string (CRS) and a corresponding proof-of-correctness (POC) or proof of correct execution. [Figure 5] FIG. 1 illustrates a process for generating a two-party common reference string that includes a verification key and an evaluation key, according to one embodiment. [Figure 6] FIG. 1 illustrates a process for sharing an exponentiation of a shared secret between multiple parties, according to at least one embodiment. [Figure 7] FIG. 1 is a simplified block diagram of a computing device that can be used to implement at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

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

[0025] This disclosure describes techniques that may be utilized to implement systems and methods that allow multiple parties to securely share elements of a group whose exponent or multiplicative coefficient depends on the power of a shared secret. A quantity may be shared such that the parties exchange a quantity based on a shared secret (e.g., a power of the shared secret) without revealing the shared secret. Thus, in various embodiments, multiple n participants exchange a representation of the power of the shared secret (e.g., <S in the multiplicative case). i 〉 G Establish.

[0026] In embodiments, the protocol-based techniques and methods described herein are used by two parties to a smart contract to share quantities that can be used by the parties and to determine the exponentiation of a shared secret, without sharing the secret itself and without revealing information that would allow another computing entity (e.g., a computing entity not party to the smart contract) to determine the secret. In one embodiment, the protocol involves a first party to the smart contract calculating a first set of parameters to be sent to a second party to the smart contract, and the second party calculating a second set of parameters and presenting these parameters to the first party, where, upon such exchange of parameters, both parties can calculate an identical common reference string that includes 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 to addresses (e.g., addresses of worker nodes in a blockchain network) and can be unlocked (e.g., spent). 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 maintaining security guarantees (e.g., private keys are not revealed or otherwise determinable based on parameters exchanged by an adversary or other computing entity that is not a party to the smart contract). In one embodiment, the two parties (or, in the more general case, two or more parties) utilize techniques to share powers of a shared secret, in a manner such as described elsewhere herein, e.g., in connection with Figures 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. Systems and methods described herein may relate to protocols for parties to a smart contract to exchange quantities that first and second computing entities can use to calculate an identical common reference string. FIG. 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 allows 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 to which either or both of the computing entities contribute as transaction inputs. The common reference string may include a valuation key 112 and a verification key 114. The smart contract 110 may be published to a blockchain, such as the blockchain 118 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 of or in conjunction with the execution of the smart contract, a 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 the blockchain network acting as a verifier node). In an embodiment, the verification key 114 is used by the fourth computing entity (e.g., a verifier computer system) to verify that the proof published to the blockchain network 118 is correct.

[0028] The first computing entity 102 and the second computing entity 104, according to at least one embodiment, are computer systems that are parties to a smart contract. Parties to a smart contract may refer to two or more computing entities that agree to terms for the execution of the smart contract (e.g., according to user input provided through an associated 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 intercepted by a locking script that can be unlocked (e.g., used) as a result of a worker node providing proof of correct execution of the smart contract. The systems and methods described herein may be implemented such that the locking script provides a verification key V K from modification and checks the validity of the proof π, thereby enabling the execution of zero-knowledge protocols on the blockchain during transaction verification.

[0029] In various embodiments, the first computing entity 102 and the second computing entity 104 agree to a smart contract by exchanging a set of messages that encode the parameters of the smart contract, such as dates, times, conditions, and actions (e.g., transfer of control of a digital asset) used to control the execution of the smart contract, in one embodiment. For example, a smart contract (e.g., an executable program) may insure the parties against a particular flight delay, and 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 providing travel insurance against delays).

[0030] In one embodiment, 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 smart contracts may be encoded using other suitable programming languages. In one embodiment, smart contract 110 is encoded using software such as a compiler, interpreter, and / or assembler to generate field

number

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

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

[0033] A useful variant of a zero-knowledge proof of knowledge is a Succinct Non-interactive ARgument of Knowledge (zk_SNARK). In one embodiment, all pairings-based zk-SNARKs involve a process in which a prover computes multiple group elements using a general group operation and a verifier checks the proof using multiple pairing product equations. In one embodiment, linear interactive proofs operate over finite fields, and the prover's and verifier's messages contain, encode, reference, or otherwise include information usable 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 execution of a smart contract by exchanging a set of messages. Such messages encode proposed parameters for the execution of the smart contract, such as one or more Boolean expressions encoding a set of conditions that, based on the conditions being met, determine whether and / or how to execute the smart contract and a set of operations to be executed. In one embodiment, one computing entity sends a set of parameters to a second computing entity as part of a protocol, and the second computing entity determines whether the 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. Alternatively, 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, once all parties have signaled agreement on the parameters, either computing entity, in one embodiment, can generate a locking transaction, in which one of the outputs is locked programmatically (e.g., a smart contract script) and send it to the other party in 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 reassociates (e.g., transfers ownership and control of) at least a portion of the digital assets represented by the UTXO of a previous transaction to an entity associated with a blockchain address.

[0035] In one embodiment, a first computing entity creates a locking transaction and adds transaction inputs covering the worker fee portion. Note that at this point, the locking transaction is not yet valid because the value of the transaction inputs is not equal to the value of the locking transaction's transaction output. Continuing the example, when a second computing entity receives the locking transaction, the second computing entity validates the smart contract (e.g., verifies the common reference string and parameters for the execution of the smart contract), adds the inputs to the locking transaction, unlocks the UTXO, and forwards it to the issuer who agreed on the digital asset and also agreed on the reward to be paid to the worker for executing the program (e.g., smart contract) and the output having the value of the reward for the worker. When 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 transfer (e.g., exchange or sale) of the smart contract may require certification 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 a prover. In one embodiment, the worker executes the smart contract by performing at least a computational task involving the calculation of a function on an input. In one embodiment, the worker is any suitable computer system to which the owner of the smart contract may delegate a computational task. The input, in one embodiment, includes information verifying 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 to which the first and second computing entities have agreed to transfer digital assets in exchange for successfully completing the computational task. The owner of the smart contract, in one embodiment, receives an input x and an evaluation key E. K 112 to the prover, who uses the evaluation module for a calculation routine to calculate the output y (i.e., y=f(x), where the input is x and the function is f), and obtains the evaluation key E K , generating a proof of correct execution 116. The proof of correct execution 116 may also be referred to elsewhere herein as a proof of correctness. In an embodiment, the operator is a computer system comprising hardware and / or software that includes instructions that, when executed by one or more processors of the computer system, cause the computer system to evaluate values ​​of the internal circuit wires of the QAP and generate an output y of the QAP.

[0037] In an embodiment, the output y, the value of the internal circuit wires (or a subset thereof), and the evaluation key E K is used to generate a proof of validity. The proof π can be stored on the blockchain and verified by multiple parties without the need for the worker to interact with multiple parties separately. In this way, a fourth computing entity (e.g., a verifier computer system) can generate a proof of validity by using the public verification key V. K114 and the proof π can be used to verify the broadcasted transaction, thereby validating the smart contract. In some cases, the owner of the smart contract may reclaim the digital assets that are intercepted by the broadcasted transaction if the verification fails. In some cases, the owner of the smart contract can perform verification of the proof.

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

number

[0039] Verification key V K , proof π and (a1, a2,..., a N ), t(x) divides p(x), so (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) where:

number

number

number

number

number

number

number

number

[0040] Thus, given the notation from the above section and the examples described in this disclosure, validation, according to one embodiment, involves a set of paired checks of the following elements:

number

[0041] 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 that are used to calculate the same common reference string (as illustrated below the horizontal arrows 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, circuits are described by polynomials v, w, and these polynomials are evaluated at a secret s known only to the party that owns / creates those circuits and the corresponding QAP (e.g., the owner of the smart contract).

[0043] More precisely, the client creates the element as described above:

number

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

[0045] In one embodiment, in solutions that require an operator to provide a proof of correctness, there may be an opcode (or equivalent) to verify the proof of correctness against a verification key.

[0046] Throughout this disclosure, unless otherwise stated, polynomials herein are used in the field

number

number

number

number

number

number

[0047] In one embodiment, the universal reference string has the format: v(s)=a0+a1s+a2s 2 +···+a n s n w(s)=b0+b1s+b2s 2 +···+b n sn It is represented by polynomials v(x), w(x) evaluated at the secret s.

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

[0049] According to at least one embodiment, r 〉 G A technique for sharing and distributing n is illustrated in Figure 2. As an example, the case of n=2 is described in more detail below in connection with Figure 2 and should be considered a non-limiting example of sharing a secret exponentiation between parties to a smart contract. Furthermore, it should be noted that various embodiments described herein assume that the equivalent of a threshold is given in advance and initially agreed upon by the required number of participants.

[0050] FIG. 2 illustrates a technique for sharing and distributing the power of a shared secret between two participants, according to at least one embodiment. As illustrated in FIG. 2, according to at least one embodiment, exactly two parties are participants who share the power of the shared secret (i.e., when 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 knows that p1(x i )〉 G sends B and instead sends 〈p2(x i )〉 G (i∈{1,2}). In this way, both can calculate: 〈p(x i )〉 G =〈p1(x i )+p2(x i )〉 G

[0051] Using Lagrange interpolation (Lagrange polynomials, nd), p is calculated in terms of p(x1) and p(x2), and 〈p(x i )〉 G By extension, p(x) G can be expressed by (see WP0559):

number

number

number

[0052] Schematically, the exchange is (some x i (about) may look like this: [Table 2]

[0053] After this exchange (following certain pre-planned transformations), both parties agree that p n (x j )〉 G , especially〈p n (0) G =〈s n 〉 G can be calculated.

[0054] 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 represent zero-knowledge in a protocol such as that described in connection with FIG. 1. According to various embodiments, the public verification key may have the following format:

number

[0055] On the other hand, the security of the proposed solution relies on the parameter s and, in some embodiments, on 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 other entities to know. Thus, in one embodiment, some or all of the remaining parameters used to generate verification key 306 are shared using the techniques described in connection with FIG.

[0056] In one embodiment, polynomials are 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 Figures 1, 2, and 4. Thus, in one embodiment, the first computing entity 302 exchanges a set of elliptic curve points

number

number

[0057] According to one embodiment, G i of

number

number

number

[0058] In one embodiment, the element <α v 〉2,〈α w 〉2,〈α w 〉1,〈α y 〉2, 〈β〉1, 〈β〉2 or any combination thereof is 〈a〉 i =a·G i As in the case of s, i is a polynomial q i Generate and save it as x j , j∈{1,...,m}, and evaluate the q corresponding to participant j. i (x j ) and each participant

number

[0059] In one embodiment, the α parameter is shared by an elliptic curve point, while the other parameters are scalar values. For such values, at least one embodiment uses the Diffie-Hellman scheme to share the scalar parameters between two computing entities without the need to share the parameters themselves. Thus, in one embodiment, P={t1,...,t NLet} be the set of N parameters. In one embodiment, assume that A and B have agreed using a multiplicative group I′ of modulus μ and generator γ, and that the participants (A and B) follow the following steps (exponential notation is used here as an illustrative example, but other suitable notations may be utilized): For each i∈{1,...,N}, the first and second computing entities each generate a (secret) random number v A,i , v B,i Create a (public) element:

number

number

number

number

[0060] Thus, the above technique does not require the first and second computing entities to exchange parameters, but instead

number

[0061] 4 illustrates a diagram 400 of a protocol based on a two-party Common Reference String (CRS) and a corresponding Proof of Correctness (POC) or Proof of Correct Execution. Diagram 400 illustrates a first computing entity 402, a second computing entity 404, and a third computing entity 406, where first computing entity 402 and second computing entity 404 together make a contribution to a smart contract that can be unlocked by third computing entity 406 after 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 described in further detail (e.g., in connection with 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 circuit. In one embodiment, the scheme contemplates an off-chain exchange of data first between A and B, and then between A+B (or either) and a worker C who performs a computational task on behalf of at least one of A and C. To have worker C perform the computational task (e.g., execute a smart contract), A and B both sign a transaction (which may or may not include a specific P2SH-type redeem script) that requires worker C to provide a proof of correctness and prove possession of the correct verification key (VK) to unlock the funds.

[0063] Techniques for implementing protocols presented in this disclosure, in some embodiments, do not require any protocol changes to existing blockchain networks (e.g., they may be implemented on a Bitcoin-based blockchain using existing commands already supported). In some embodiments, extensions to the set of existing commands supported by the Bitcoin protocol are also discussed herein—extensions may include new commands (e.g., new opcodes), which may have various benefits, such as improving the efficiency of smart contract execution and reducing the size of smart contracts (which may reduce the amount of storage space required by nodes in the blockchain network to operate correctly). In some embodiments, the cost of confirming a smart transaction against a blockchain is based at least in part 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 is transferred off-chain. In one embodiment, the verification key is ultimately broadcast via a digital asset exchange or otherwise made available on-chain for work (e.g., smart contract execution) performed by worker C and the two parties (A and B) wishing to evaluate the smart contract. As described herein, several schemes are possible. For example, A and B may or may not both supply the VK or a hash of the VK when preparing the locking transaction. In other words, in one embodiment, the majority of capacity-intensive workloads are performed off-chain.

[0065] In one embodiment, the protocol includes both off-chain and on-chain components, as indicated by the dotted lines illustrated in FIG. 4. The off-chain components may include communication and exchange of data and information that may occur without storing the data on a blockchain ledger. For example, the off-chain components of the protocol may include the exchange of IP packets between a source and a destination (e.g., first computing entity 402 is a source that sends a first set of parameters to a destination, i.e., second computing entity 404). For example, the on-chain components 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 calculates a set of elliptic curve points based at least in part on the first polynomial.

number

number

[0067] In some embodiments, additional data is transmitted that is not 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 also computes 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 quantities can be used to calculate the same common reference string by both the first computing entity 402 and the second computing entity 404. Since the third computing entity 406 must later prove possession of the correct verification key, they may or may not provide the common reference string to the third computing entity (e.g., a worker). 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 to the execution of the smart contract. In one embodiment, the first and second computing entities agree on a contribution ratio and each provide a transaction input that is blocked to the smart contract and can be unlocked by a third computing entity upon execution of the smart contract. This may or may not be a pay-to-script-hash (P2SH) type agreement, where the first and second computing entities both transfer funds to the same address (address C). A P2SH type script uses elements of a verification key or a hash value of the verification key, i.e., h i =HASH(VK i ) in the first and second computing entities 402 and 404. In one embodiment, the key is split 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 serves as a worker reward paid in a ratio agreed upon by the first and second computing entities.

[0071] In one embodiment, a third computing entity 406, also referred to as a worker, unlocks the reward in a second transaction 410 according to the protocols in UK Patent Application No. 1719998.5 and / or UK Patent Application No. 1720768.9, where the third computing entity 406 unlocks the reward for doing the work (correctly executing the circuit) and, in doing so, proves possession of (a) the correct verification key and (b) a valid proof of correctness. The verification may be performed by another computer system (e.g., a blockchain node that is a verifier) ​​and / or by a computing entity that is a participant 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. Part or all of process 500 (or any other process described herein, or variations and / or combinations thereof) may be performed 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, for example, in the form of a computer program including multiple 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 some of the computer-readable instructions usable to perform process 500 are not stored solely using transitory signals (e.g., propagating transitory electrical or electromagnetic transmissions). The non-transitory computer-readable medium may include non-transitory data storage circuitry (e.g., buffers, caches, and queues) within a transceiver of a transitory signal.

[0073] In one embodiment, the system executing process 500 is a computing entity that is party to the smart contract executing the process to at least establish information that can be used to calculate the same common reference string by the system and the parties to the smart contract. The common reference string described in connection with process 500 may be, for example, according to those discussed in connection with Figures 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 It is represented by polynomials v(x), w(x) evaluated at a secret s of the form

[0074] In one embodiment, a first computing entity determines 502 a first polynomial for generating a first set of elliptic curve values. In one embodiment, the system determines 502 a first polynomial for generating a first set of elliptic curve values ​​for some generator G of an associated group (e.g., of elliptic curve points). G =〈a0〉 G +〈a1s〉 G +〈a2s 2 〉 G +···,. Unless otherwise noted, the polynomials in this process 500 are generated in the 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 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:

number

number

number

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

number

[0078] In one embodiment, the system determines 508 an identical common reference string based at least in part on the first and second sets of elliptic curve points. For example, after exchanging the elliptic curve points, Lagrangian interpolation may be used to express p in terms of p(x1) and p(x2). In one embodiment, both parties to the smart contract may use the exchanged points <p i (x j )〉 G By this, the power 〈p n (x)〉 G (In particular, n (0) G =〈s n 〉 G ) can be reconstructed by the power 〈p n (x)〉 G For , the polynomial equations mentioned above may be used:

number

[0079] For example, for 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 and second computing entities, such as in the manner described in relation to FIG. 3, and these parameters are used to calculate the power of the shared secret <s n 〉 G together with the parameters to calculate a verification key and / or an evaluation key. In one embodiment, the parameters are exchanged without reliance on encryption and / or 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 a respective transaction input of the smart contract that 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 entities contribute to the same address (e.g., a worker address). In one embodiment, the P2SH script includes elements of a verification key or a hash value of a verification key. For example, using techniques described in connection with UK Patent Application No. 1719998.5 and / or UK Patent Application No. 1720768.9, a worker (e.g., a third computing entity) may unlock (e.g., unlock) a contribution by providing computationally verifiable proof that the worker has the correct verification and provides a valid proof of authenticity.

[0082] FIG. 6 shows an illustrative example of a process 600 for sharing exponentiation of a shared secret among n parties (e.g., n>2) according to at least one embodiment. Part or all of process 600 (or any other process described herein, or variations and / or combinations thereof) 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, e.g., in the form of a computer program including 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 some of the computer-readable instructions usable to execute process 600 are not stored solely using transitory signals (e.g., propagating transitory electrical or electromagnetic transmissions). The non-transitory computer-readable medium may include non-transitory data storage circuitry (e.g., buffers, caches, and queues) within a transceiver of a transitory signal. In one embodiment, it is assumed that the equivalent of a threshold is given in advance and that the required number of participants agree on it initially. This differs from various existing techniques, such as those described in Shamir's secret sharing (4S), in that secret sharing only works under the constraint of reaching a given threshold.

[0083] The secret sharing can be valid for any number of parties, according to various embodiments. In one embodiment, much of the formalism described in this disclosure can be applied to multi-party (n>2) scenarios. In some embodiments, multi-party systems (n>2) may require certain other parameters, such as the following non-elliptic curve (e.g., scalar) parameters: r v , r w , α v , α w , α y, β, γ) does not need to be hidden. However, if these parameters remain private according to the protocol, a different approach, such as the one described in connection with FIG. 3, can be used to hide r v , r w You can also hide parameters like:

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

number

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

[0086] In one embodiment, each participant has x i A polynomial can be generated 604 that evaluates at a set of points (x1, x2, ...) where ≠0∀i, and the points can be known to all parties. In one embodiment, the sum of each participant's polynomial constitutes a (master) polynomial whose intersection with the y-axis is secret, i.e.,

number

[0087] To establish s, each participant shares the corresponding polynomial evaluated at different points (x1, x2, ...) 606. More specifically, participant i defines p i (x j ) and calculate 〈p i (x j )〉 G Once these quantities are shared, each participant sends the power s of the shared secret. r may be calculated or otherwise determined 608.

[0088] s r When considering this,

number

[0089] <p i (x j )〉 GIt may not be possible to calculate the power of p because the power of the generator is not generally defined. However, all participants can calculate the power of p i (x j )〉 G By〈s〉 G Since we can infer that, it is possible to start by examining the powers of the Lagrangian interpolating polynomial L(x) (since the master polynomial can generally be constructed by Lagrangian interpolation (Lagrangian polynomials, n.d.)).

number

number

number

number

number

number

number

[0090] This means that participant i (the owner / creator of polynomial pi) sends a i (x j )〉G Powers of, i.e., the set:

number

[0091] This means that participant j

number

number

number

[0092] Consider an example in accordance with at least one embodiment where participants use elliptic curves and G is the generator in the corresponding multiplicative representation: For two participants A and B, A has 〈p1(x2)〉 G Send B 〈p2(x1)〉 instead G Therefore, participant A receives 〈p(x1)〉 G =〈p1(x1)+p2(x1)〉 G Similarly, participant B can calculate 〈p(x2)〉 G =〈p1(x2)+p2(x2)〉 G can be calculated.

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

number

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

number

[0095] For m=2, this becomes:

number

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

[0097] The protocol according to process 600 is described below. Each participant:

number

[0098] Without loss of generality, according to at least one embodiment, participant 1 is the one submitting the first elliptic curve point. The protocol, in one embodiment, follows the following steps: 1. Participant 1:

number

number

number

[0099] The lth 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, the process 600 is of the form

number

[0101] The specification and drawings are therefore to be regarded in an illustrative, rather than a restrictive, sense. It will be apparent, however, that various modifications and changes may be made thereto without departing from the scope of the invention as set forth in the appended claims. Likewise, other variations are within the scope of this disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, specific illustrative embodiments thereof have been shown in the drawings and have been described above in detail. It is to be understood, however, that there is no intention to limit the invention to the particular embodiment or embodiments disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the scope of the invention as defined by the appended claims.

[0102] Use of the term "set" (e.g., "set of items") or "subset" should be construed as a non-empty set containing one or more members, unless otherwise stated or contradicted by context. Further, unless otherwise stated or contradicted by context, the term "subset" of a corresponding set does not necessarily indicate an exact subset of the corresponding set, although a subset and a corresponding subset may be equivalent.

[0103] Connective phrases such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" are understood in their general context to indicate that an item, term, etc. can be either A or B or C, or any non-empty subset of the set A, B, and C, unless otherwise stated or clearly contradicted by context. For example, in the illustrative example of a set having three members, the connective 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: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such connective phrases are not generally 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, each be present. Furthermore, unless otherwise stated or clear from context, the phrase "based on" means "based at least in part on," not "based only on."

[0104] The operations of the processes described may be performed in any suitable order unless otherwise specified or clearly contradicted by context. The processes described (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) collectively operating on one or more processors by hardware or a combination thereof. In some embodiments, the code may be stored on a computer-readable storage medium, e.g., in the form of a computer program including a plurality of instructions executable by 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 describe embodiments of the invention and does not impose limitations on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0106] Embodiments of the present disclosure have been described, including the best mode known to the inventors for carrying out the invention. Variations of these embodiments will become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect those skilled in the art to employ such variations as they see fit, and the inventors intend that the embodiments of the present disclosure may be practiced otherwise than as specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the scope of the present disclosure unless otherwise indicated or clearly contradicted by context.

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

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

Claims

1. 1. A computer-implemented method performed by a plurality of computing entities for sharing a power of a shared secret, the method comprising: agreeing among the computing entities on a function that maps finite field elements to finite field elements; generating, by each computing entity of the plurality of computing entities, a respective polynomial based on the function and evaluating the respective polynomial at a set of points having non-zero finite field coordinates; transmitting, by each computing entity to each other computing entity, a polynomial evaluation value comprising said respective polynomial evaluated at said set of points, each evaluation value being represented in a group by raising said evaluation value to the power of said group's generator; receiving, by each computing entity, the polynomial evaluations transmitted by the other computing entities; constructing, by each computing entity, a master polynomial corresponding to the sum of the polynomials of the plurality of computing entities using the received polynomial evaluation values; determining, by each computing entity, based on said master polynomial, a value corresponding to a power of a shared secret expressed as an evaluation of said master polynomial at zero; A method comprising:

2. the function agreed upon by the plurality of computing entities is a polynomial or a function expressible as a polynomial by a generalization of a Taylor expansion; The method of claim 1.

3. The transmitting step may be performed by, for each pair of computing entities i and j, ｉ (x ｊ )) ｃ where P ｉ is the polynomial associated with computing entity i, and x ｊ is one of the set of points and c is a group index. The method of claim 1.

4. constructing the master polynomial includes performing Lagrangian interpolation using the transmitted polynomial estimates. The method of claim 1.

5. Determining the value corresponding to the power of the shared secret is γ ) ｃ where s is the shared secret, γ is a power selected by the plurality of computing entities, and c is an exponent defining a representation in an elliptic curve group. The method of claim 1.

6. the group is an elliptic curve group and the generator is an elliptic curve point; The method of claim 1.

7. generating the respective polynomials includes assigning to each computing entity a respective polynomial of potentially different degrees; The method of claim 1.

8. the set of points used for evaluation comprises a plurality of non-zero finite field points known to all computing entities; The method of claim 1.

9. having each computing entity distribute the powers of its polynomial evaluation value to enable the other computing entities to compute the powers of the master polynomial; The method of claim 1.

10. The distribution of the powers of the polynomial evaluation values ​​is performed by using integer values ​​k that satisfy a predetermined range used for polynomial expansion of the powers of the master polynomial. ｉ Regarding [Equation 1] transmitting a value of the form The method of claim 1.

11. 1. A system including a plurality of computing entities configured to jointly share a power of a shared secret, each computing entity having one or more processors and, when executed, causing said computing entity to: agreeing on a function that maps finite field elements to finite field elements; generating a polynomial and evaluating the polynomial at a set of non-zero points; transmitting the polynomial evaluation value to another computing entity; and receiving a polynomial evaluation value from the other computing entity; and constructing a master polynomial using the received values; and determining a power of a shared secret from the master polynomial; and a memory storing instructions for performing operations including:

Images