Bilinear pairing

Abstract

A computer implementation method for generating pairings is provided. Intermediate values ​​are obtained based on initial values ​​provided by the provider. Candidate inverse intermediate values ​​are received from the provider. It is determined whether the candidate inverse intermediate value is equal to the target inverse intermediate value, which is the reciprocal of the intermediate value. If the candidate inverse intermediate value is equal to the target inverse intermediate value, the pairing is calculated based on the intermediate value and the candidate inverse intermediate value.

Description

[Technical Field]

[0001] This disclosure relates to a computer implementation method for generating pairings, a method for generating blockchain transactions for computing pairings, and a method for fulfilling challenges based on pairings. [Background technology]

[0002] Pairing on elliptic curves has a wide range of cryptographic applications. For example, pairing can be used to build signatures, identity-based cryptography, non-interactive zero-knowledge proofs, and highly efficient multi-party key sharing.

[0003] Pairing e is a torsion group

number

number

number

number

[0004] Efficiently implementing pairing in a script is not straightforward. Methods known in the art require a script size of approximately 1.5 MB. This specification provides a method for improving the computational efficiency of pairing calculations and thereby optimizing the resulting pairing script.

[0005] When calculating pairings, the reciprocal of the intermediate value is required. Inverting field elements is the most costly arithmetic operation in pairing calculations.

[0006] To reduce the size of the script and thereby decrease the computational requirements when calculating pairings, a method is provided herein for providing candidate inverse intermediates and determining whether they are reciprocals of intermediates. If they are reciprocals of intermediates, the candidate inverse intermediates can be used in the pairing calculations.

[0007] The script for implementing the check for candidate inverse medians is much smaller in size than the script for inverting field elements.

[0008] According to one aspect disclosed herein, a computer implementation method for generating pairings is provided. This method includes obtaining an intermediate value derived based on an initial value provided by a provider; receiving a candidate inverse intermediate value from the provider; determining whether the candidate inverse intermediate value is equal to a target inverse intermediate value, where the target inverse intermediate value is the reciprocal of the intermediate value; and, if the candidate inverse intermediate value is equal to the target inverse intermediate value, calculating a pairing based on the intermediate value and the candidate inverse intermediate value.

[0009] For the purpose of aiding in the understanding of embodiments of this disclosure and illustrating how such embodiments are carried out, the accompanying drawings are referenced only as examples. [Brief explanation of the drawing]

[0010] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates some examples of transactions that can be recorded on a blockchain. [Figure 3] This figure illustrates point addition and point multiplication on an elliptic curve. [Figure 4] This diagram schematically illustrates the conceptual division of the script used to calculate pairings. [Figure 5] This diagram schematically shows the dependencies of the script that implements the field expansion operation. [Figure 6] This diagram schematically illustrates the relationships between scripts for implementing a mirror loop to compute single or multiple pairings. [Modes for carrying out the invention]

[0011] 1. Elliptic curves and pairing 1.1 Elliptic Curves cubic equation y 2 =x 3 Consider +ax+b. Here, the coefficients a and b are finite fields with q elements.

number

number

number

number

number

number

number

number

[0012] Notation Notation

number

number

number

number

number

number

[0013] 1.1.1 Addition and multiplication of points in affine coordinates An elliptic curve E forms a group under the "tangent and chord" rule. This addition rule causes E to become a group with the identity element at infinity O.

[0014] Figure 3 shows the group laws of elliptic curves. The graph on the left shows the addition of points, and the graph on the right shows the doubling of points.

[0015] To add two points \(P\neq Q\), we need the straight line \(l\) passing through \(P\) and \(Q\) P,Q and the perpendicular line \(v\) passing through the intersection point (i.e., \(-R\) on the left in Figure 3) of \(l\) and an \(E\) that is not \(P\) or \(Q\). R Similarly, to multiply a point \(P\) by a scalar, we need the tangent line \(l\) of \(E\) at \(P\) P,P and the perpendicular line \(v\) passing through the other intersection point of \(l\) and \(E\) (i.e., \(-R\) on the right in Figure 3). R The following are the equations. The left - hand equation corresponds to point addition when \(P\neq Q\), and the right - hand equation corresponds to point multiplication when \(P + P:=2P\).

Table 1

[0016] Note 1. As shown in Section 1.8, the straight line \(g\) passing through \(P\neq Q\), P,Q the tangent line \(g\) at \(P\), P,P and the perpendicular line \(v\) at \(R\) R play important roles in the definition of the pairing. The following table shows the evaluation equations of the "tangent and chord" lines at an arbitrary point \(S\) of \(E\) in affine coordinates.

Table 2

[0017] 1.1.2 Point and Scalar Multiplication For any integer

Number

[0018] 1.2 Projective Coordinates In the point addition explained in the previous section, to calculate the scalar \(\lambda\), elements of the field \((x Q -x P or \(2y PThe coordinates need to be inverted. Inversion is a costly operation, so it is preferable to avoid it. This can be achieved by switching to projective coordinates. Coordinate transformation

number

[0019] 1.3 Torsion group E[r] and embedding order Let n=#E be the order (size) of the elliptic curve. Then, for all P∈E, [n]P=O holds. However, if the scalar is small, points may vanish. For any factor r of n, the r-twist group is the set of points of order r:

number

[0020] r-torsion also forms a group. Therefore, it is a subgroup of E. The structure of the r-torsion group is well known. When r is prime to q,

number

[0021] 1.3.1 Embedding degree of curve E As stated in Section 1.1, the points (and their coordinates) on the elliptic curve E are:

number

number

[0022] Clearly, by definition, the degree of the embedding depends on q and r. Therefore, for any choice of q and r, the corresponding degree of the embedding is k(q,r).

[0023] 1.3.2 Two subgroups of E[r] Pairings on E can be defined on any two subgroups of E[r]. For efficiency reasons, type 3 pairings (see section 1.5.1) are defined on two subgroups following the r-twist.

[0024] 1.3.3 Basis group

number

number

number

number

number

[0025] π is a point

number

number

number

[0026] Note 2. The important thing to remember is:

number

number

number

[0027] 1.3.4 Zero Trace Group

number

number

[0028] The trace map is,

number

number

number

number

[0029] The aTr map described above is an anti-trace map defined as aTr(P) :=[k]P-Tr(P). Since Tr(aTr(P))=O, aTr is a point

number

[0030] Note 3.

number

number

number

number

number

[0031] 1.4 Helical Curves curve

number

number

number

number

number

[0032] The possibility d∈{2,3,4,6} is defined as follows: • Quadratic twist, d=2. Can be used with any curve. E:y 2 =x 3 +ax+b. Therefore, any

number

[0033] An important fact used in the context of pairing is,

number

number

number

number

number

number

number

[0034] Note 4. As stated in Section 1.3,

number

number

number

number

number

number

number

number

number

[0035] 1.5 Pairing Pairing e is a torsion group

number

number

number

number

number

number

number

number

[0036] 1.5.1 Types of Pairing Source files

number

[0037] Type 1. Symmetrical pairing:

number

number

number

number

number

[0038] Type 2.

number

number

number

number

number

[0039] Type 3.

number

number

number

number

[0040] Note 5. Currently, Type 3 pairing is the most studied because it is more efficient than Type 1 and offers more functionality than Type 2. Therefore, Type 3 pairing is used in the script implementation in Section 3.

[0041] 1.6 Elliptic Curve Pairings (Weil, Tate, Optimal Ate Pairings) Simply put, pairing two points P and Q is equivalent to a function f related to P. n,P The task is to construct a model and evaluate it at point Q. The selected f i,P This is a mirror function and is defined as follows: (f n,p ):=n(P)-([n]P)-(n-1)O

[0042] The above equation is the mirror function f n,P This shows that P has zeros, multiplicity n, a pole at [n]P, and a pole at O ​​with multiplicity n-1.

[0043] This initial pairing was by Weil. Since then, several variations have been proposed, with the optimal pairing proving to be the most efficient. These different pairings can be concisely defined as follows: Weil Pairing:

number

number

number

number

number

number

number

number

[0044] 1.7 Curves suitable for pairing Elliptic curves have parameters q, t, r, and k: • q: Prime number. The underlying field.

number

number

[0045] Pairing is,

number

[0046] In cryptographic applications, the source set of order r.

number

number

[0047]

number

number

number

[0048] The specific value of this ratio depends on the progress made in solving these two problems. The parameter ρ measures how efficient the calculations on the elliptic curve are. Ideally, ρ=1 is desirable.

[0049] Note 6. The larger the value of ρ, the larger

number

[0050] 1.7.1 Parameterized Families The values ​​of q, r, and t are parameterized as polynomials q(u), r(u), and t(u).

number

[0051] The most well-known families are BN, BLS12, BLS24, and KSS, but other families are also possible. To achieve 128-bit security, BLS12 is more suitable than BN, considering the latest advances in solving DLPs. Therefore, the script implementation provided here is based on this curve. BLS12 is a family of BLS12-381 and BLS12-440. The former is more efficient but may be affected by improvements in methods for solving DLPs. The latter is less efficient (relatively, type 3, see note 5 above) but is considered more secure. In the near future, it seems unlikely that security will drop below 128 bits due to improvements in methods for solving DLPs. The following table shows the BLS12 curve families.

Table 3

[0052] 1.8 Mirror Algorithm As described in Section 1.6, the optimal Ate pairing requires two steps, namely functions. First

Number

Number

Number

[0053] In the above formula, f j,P is the mirror function, g P,Q is the straight line passing through points P and Q, and v P}]is the perpendicular line at P. It can be seen that the mirror results in a "double-and-add" algorithm that calculates f r,Q in approximately log(r) steps. Without saving f r,Q (a function of degree r), the intermediate function f i,Q is also evaluated iteratively at the (fixed) point P.

Table 4

[0054] Therefore, the mirror algorithm repeatedly uses the above formula in "double-and-add" style to accumulate f j,Q (P), and then

Number

[0055] Note 7. A key optimization technique incorporated is the so-called "denominator elimination." (Vertical line)

number

[0056] 2. Implementation details of the BLS12 family BLS12 has an embedding order k=12, and the equation of the curve is E:y 2 =x 3 +b, and b=4. From Table 1, the parameters q and r are the BLS12-381 polynomial and the curve parameter: u=-2 63 -2 62 -2 60 -2 57 -2 48 -2 16 Please remember that it is derived according to the following. Since a=0, the equation E':y 2 =x 3 +b' allows for a sixth-order twist E' (see Section 2.4). Here, b' = b / ξ, and ξ is

number

number

[0057] 2.1 Body Expression Basal body of the target group (

number

[0058] Expression 1 (quadratic enlargement)

Number

Number

Number

Number

[0059] Expression 2 (sextic enlargement)

Number

Number

Number

[0060] Expression 3 (cubic enlargement)

Number

Number

Number

Number

number

number

number

number

number

number

[0061] 2.1.1 Why three expressions are needed

number

number

number

number

number

number

[0062] The second expression (

number

[0063] The third expression (

number

number

number

[0064] Based on the above explanation, we will specify the arithmetic expressions in the next section. These will serve as the code base for the scripts described in Section 3.

[0065] 2.1.2 Switching between expressions The switching between the first representation (quadratic extension) and the second representation (sixth-order extension) is implicitly used in the exponentiation via Frobenius (see Section 2.8). The output of the mirror loop (element f) is also switched from the first representation to the third representation (cubic extension) before entering the final exponentiation.

[0066]

number

number

number

number

[0067] For example, the switching between quadratic and sixth-degree extensions can be derived as follows: X = x1 + x2w is a quadratic extension.

number

number

number

number

number

[0068] 2.2

number

number

number

number

number

[0069]

number

number

[0070]

number

[0071] 2.3

number

number

number

number

number

number

number

number

[0072] 2.4

number

number

number

number

number

number

[0073] 2.5 Target Field -

number

[0074] 2.5.1 Multiplication as a quadratic extension In the final power of pairing,

number

number

number

number

number

number

number

number

number

number

number

[0075]

number

number

number

[0076] 2.5.2 Powers as Quadratic Extensions The final power method can be said to consist of simple and complex parts. These terms are frequently used in this technique.

[0077] The difficult part of the final multiplication is that we need to raise u and u / 2 (where u is a curve parameter). These multiplications are performed by the general algorithm "signed square-and-multiply". Therefore, the exponent e (either u or u / 2) is in signed binary form, i.e. i It is given by bits ∈{-1,0,1}. This algorithm can only be used for raising the identity element (i.e., the difficult part of the final multiplication). See Table 10. [Table 11]

[0078] 2.5.3 Multiplication as a cubic extension During a mirror loop, the sparsity of the evaluation result of a linear function is utilized.

number

number

number

number

number

[0079] In this expression, X is those three

number

number

number

number

number

number

[0080] The result of the linear calculation, L, is a sparse element, and half of its coefficients are set to zero (see Section 2.7 below). That is,

number

number

number

number

number

number

number

number

[0081] During the mirror loop process, sparse elements are multiplied by each other. The result is a somewhat sparse element (i.e., the third)

number

number

number

[0082] Furthermore, in a mirror loop, sparse

number

number

number

number

number

[0083] While multiplication and squaring are not mandatory in cubic representations, they can be used to avoid unnecessary switching between representations in mirror loops, i.e., the overhead of opcodes. See Table 12. [Table 13]

[0084] 2.6 Twisted curves

number

number

number

number

number

number

[0085] 2.7 Target

number

number

number

number

number

number

number

number

[0086] 2.7.1 Straight line for adding points

number

number

number

number

[0087] The result is three non-zero

number

number

number

number

number

[0088] 2.7.2 Line of Point Multiplication

number

number

number

number

[0089] To reiterate,

number

number

number

[0090] 2.8 Powers by Frobenius Homomorphism In the final exponentiation, given

number

number

number

[0091]

number

[0092] next,

number

number

number

number

[0093]

number

[0094]

number

number

[0095] 2.9 Final power The final exponentiation is,

number

number

[0096] A pairing-friendly body is one where q ≡ 1 mod 12 and q = 2 i 3 j , i≧1,j≧0

number

[0097] Such a pairing-friendly body

number

number

[0098] In BLS12 (and BN), the embedding order is k=12, so the above exponential formula becomes:

number

[0099] The exponent (q 6 -1)(q 2 The part marked with +1) is called the first part, or the simple part.

number

[0100] 2.9.1 Final Power - The First (Simple) Part f

number

number

number

number

number

Table 18

[0101] 2.9.1 Final Exponentiation - Second (Difficult) Part The second part is specific to each curve. Here, the method of performing it for BLS12 will be explained. The output of the first part is

Equation

[0102] The second part is to calculate the exponent

Equation

Equation

Equation

[0103] The above exponentiation is usually performed by an addition chain for specific coefficients of λ i (depending on the parameterization of the prime q, i.e., the characteristics of each curve), and the application of the Frobenius operator to the powers of q, q 2 , and q 3 . The addition chain is optimized for BLS12. Refer to Table 18 for the algorithm. The specific values of λ i for which the addition chain is applied are as follows.

number

[0104] 3 Script The following scripts can be used to implement BLS12 pairing in the script. The script is divided into four main conceptual blocks: the Expansion Field Calculation script 402, the Mirror Loop script 404, the Final Power script 406, and the Pairing script 408. The script used by external users is the Pairing block script 408. The other scripts 402, 404, and 406 are for internal use. The conceptual divisions and dependencies of the scripts are shown in Figure 4.

[0105] Pairings can be computed using some or all of the script blocks. For example, the mirror loop script block 404 can be used with a known last power script that computes the reciprocal. Other combinations of script blocks can also be implemented.

[0106] Scripts 402, 404, 406, and 408 may be referred to as calculation blocks in this specification.

[0107] In the examples provided herein, the script is presented as a blockchain script. However, it will be understood that the script may be any form of computer-readable script. In particular, the script may be any form of bytecode or binary code. In such code, loops are expanded. For example, instead of defining a branching script that includes if statements, each loop can be defined sequentially to generate a script without branching.

[0108] The scripts provided herein minimize the size of scripts without such branching.

[0109] 3.1 Extended Field Arithmetic Script The extended field arithmetic script performs arithmetic operations on the extended fields of the pairing. That is, the field

number

[0110] Available implementations for multiplication and squaring of quadratic or cubic extensions of a given base field use Karatsuba multiplication and the complex square method or Chung-Hasan squaring method, respectively. These algorithms perform fewer multiplications and generally more arithmetic operations on the base field. Therefore, they are faster to execute (i.e., require fewer CPU cycles) but are costly to write in scripts.

[0111] The scripts provided in this specification use algorithms that generate scripts with fewer opcodes. Therefore, these scripts are considered to be size-efficient.

[0112] The arithmetic blocks of the extension are divided into eight groups; see Figure 5. The script in the upper FQ12 group is used in the mirror loop and the final power part of pairing. The inner groups include FQ12(

number

[0113] The scripts provided herein can be used to calculate pairings. Pairings can be calculated by performing a series of subcalculations on the target field. Alternatively, the target field is represented as an extension field, and the subcalculations are performed by subfunctions on the extension field.

[0114] The sub-computation of pairing calculation can be executed by sub-functions that are executed for different extended bodies. The elements output by the sub-functions can be converted to be represented in different extended bodies. By using the sub-functions of the extended bodies, the size of the pairing calculation in the script is reduced, and the computational efficiency of the calculation is improved.

[0115] 3.1.1 FQ

Number

[0116] 3.1.2 FQ2

Number

Number

Table 20

[0117] 3.1.3 FQ4

Number

Number

Number

[0118] 3.1.4 FQ6

number

number

number

[0119] 3.1.5 FQ12 Quadratic

number

number

number

[0120] 3.1.6 FQ12CubicSparse

number

number

number

number

number

number

number

number

[0121] 3.1.7 FQ12Invert

number

[0122] 3.1.8 FQ12Frobenius Using Frobenius

number

[0123] 3.2 Mirror Loop Script Figure 6 shows the relationships between the scripts required to implement a mirror loop using one pairing or a combination of three pairs.

[0124] The mirror loop script consists of a linear function and a squared update function. The output of the linear function is an array of elements, which is provided as input to the squared update function. The linear function accepts curve points Q and P as input.

[0125] Each of these functions consists of multiple loops, the number of which is defined by a curve parameter u, and the number of loops is equal to the bit length of the curve parameter u. The curve parameter is hardcoded in the script, i.e., predefined. Each loop consists of a set of subfunctions that execute a portion of the function.

[0126] In both single-pairing and multi-pairing variations, each loop of the line function can contain one of two different sets of subfunctions, which we will refer to here as the first and second sets of subfunctions. Which of these two sets of subfunctions is used in a particular loop depends on the curve parameter conditions.

[0127] When curve parameters are expressed in binary format, the curve parameter conditions are determined based on the values ​​of the corresponding bits in the curve parameters. In the following example, the first curve parameter condition is satisfied when the corresponding bit is set to 0, and the second curve parameter condition is satisfied when the corresponding bit is set to 1.

[0128] If the corresponding bit of the curve parameter is set to 0, i.e., the first curve parameter is satisfied, the first set of subfunctions is used. On the other hand, if the corresponding bit of the curve parameter is set to 1, i.e., the second curve parameter is satisfied, the second set of subfunctions is used. Since the curve parameters are predefined and hardcoded in the script, the set of subfunctions corresponding to each loop of the line function is also predefined. Therefore, there is no need to branch in the script.

[0129] In the case of a single pairing, the first set of subfunctions is a subset of the second set of subfunctions. That is, all subfunctions in the first set of subfunctions are also subfunctions in the second set of subfunctions.

[0130] In the case of multiple pairings, the first and second sets of subfunctions consist of some identical subfunctions and some different subfunctions.

[0131] The array of elements output by the line function consists of the elements calculated by each loop of the line function, i.e., the output of each loop.

[0132] The line function also includes an initial curve point subfunction that takes a curve point T as input and calculates an initial curve point Q. The first loop of the line function takes the initial curve point as input and updates the curve point T. Each subsequent loop of the line function is configured to take the current curve point T calculated by the previous loop as input, update T, and calculate the next current curve point.

[0133] The elements of the element array computed by a particular loop are calculated based on the current curve point T, i.e., the curve point T received as input to that loop.

[0134] In the single-pairing variation, the squared update function also includes two sets of subfunctions, the specific set used in each loop depending on the conditions of the curve parameters described above. The two possible sets of subfunctions of the squared update function can be referred to herein as the third and fourth sets of subfunctions.

[0135] The third and fourth sets of subfunctions each include a squarer subfunction and a multiplicative subfunction. In the third set of subfunctions, the multiplicative subfunction is the multiplication of a sparse vector and a dense vector, and in the fourth set of subfunctions, the multiplicative subfunction is the multiplication of a slightly sparse vector and a dense vector.

[0136] In variations with multiple pairings, the loop of the square update function consists of the same set of subfunctions, regardless of the curve parameter u. All loops consist of the same squaring subfunction and multiplication subfunction.

[0137] The output of the squared update function is an intermediate value f. This intermediate value f can be used to calculate pairings.

[0138] Tables 26 and 27 show scripts that can be used to perform single-pairing or multi-pairing mirror loops, respectively.

[0139] Executing the mirror loop in this way allows for the calculation of intermediate values ​​by sparse multiplication on the expanded field. Because the operands of sparse multiplication can be written very concisely, the number of opcodes for stack management is reduced, improving computational efficiency. The new formulas for various variations of sparse multiplication are fully shown in Table 11.

[0140] Because the curve parameters are predefined, each loop in each function is also predefined. Therefore, the term "loop" refers to a series of subfunctions that are implemented sequentially within the function. Loops can be thought of as being expanded; that is, rather than a particular set of subfunctions being executed again with different inputs, the same set of subfunctions, or a similar set of subfunctions if the curve parameter conditions are different, is executed using the inputs from the previous set of subfunctions.

[0141] Thus, the mirror loop itself can be considered as being expanded; that is, each subfunction is executed only once.

[0142] 3.2.1 Splitting the mirror loop into two loops To iterate through the mirror loop, the mirror loop (Table 2, steps 1-10) is split into two loops. The first loop calculates the evaluation result of the linear function and returns it to an array of FQ12 elements.

number

number

[0143] By calculating the mirror loop in this way, many multiplications become sparse, making it faster to write (and execute) than standard FQ12 multiplication in scripts. See Table 26 for pseudocode.

[0144] 3.2.2 Multi-pairing A compound mirror loop can also be implemented to enable support for multi-pairing. This specification shows three pairing cases. In this case, three line functions (one for each pair) are computed together, and an array holds the computed result of the combined line function.

number

[0145] Combining line functions allows for a more sparse overall multiplication than calculating them individually, thus improving computation speed. See Table 27 for pseudocode.

[0146] 3.2.3 Adding Points and Pre-calculation of λ and θ for the Point Addition Function In the formula for calculating the point addition function (Table 14), the values ​​λ and θ are the same as in the case of point addition T+Q (Table 13, top). In a mirror loop, these values ​​need to be calculated only once for both operations. Therefore, we can define equivalent routines for point addition and line evaluation that calculate λ and θ first and then take λ and θ as inputs, respectively. [Table 27] [Table 28-1] [Table 28-2]

[0147] 3.2.4 Script There are three types of operations in a mirror loop: 1) Twisted curve

number

number

number

[0148] The script for (3) is described in Section 3.1. The remaining scripts for implementing the mirror loop are listed in Tables 28 and 29. [Table 29]

[0149] 3.3 Final power script 3.3.1 Avoiding Reversal The most costly (visual arithmetic) operation in pairing calculations is,

number

[0150] In the method described herein, f is inverted off-chain, and then the inverted f' := f -1 This is passed as input to the final power calculation script. Therefore, the inversion routine is replaced with a routine that checks f·f'=1. This change significantly simplifies the scripting by eliminating the need for a routine specifically for inversion in intermediate extension fields. See Table 30. [Table 30]

[0151] As described above, the value f can be referred to herein as the intermediate value. The reciprocal of this value, f', is provided as input to the final power script and can be referred to herein as the candidate inverse intermediate value. The step f·f'=1 verifies that the provided reciprocal is the reciprocal of f, and therefore the provided reciprocal is considered the candidate value. This verification has the effect of confirming that the target inverse intermediate value is equal to the target inverse intermediate value which is the reciprocal of the value f.

[0152] In one embodiment, the intermediate value f is the output of the mirror loop script 404. The intermediate value f can be considered to be derived from the initial value, as will be described later.

[0153] 3.3.2 Composition of the first and second power operations The final exponentiation script simply executes the easy part and the difficult part in sequence. Since there are two types of easy parts, there are two final exponentiation scripts. [Final exponentiation]:=[Easy part][Difficult part] [Final exponentiation with reverse check]:=[Easy part with reverse check][Difficult part]

[0154] 3.3.3 Script Table 31 shows the script required for the final exponentiation. [Table 31]

[0155] 3.4 Pairing Script These scripts combine a mirror loop script and a final power script.

[0156] 3.4.1 Switching between expressions The output of the mirror loop is a cubic extension.

number

[0157] 3.4.2 Single Pairing Script There are two variations of the pairing script. Both are functionally equivalent, but the second variation (with inverted checks) is shorter in code. Standard pairing script: [Pairing]:= [Mirror Loop] [From Cubic to Quadratic] [Final Power] Size-efficient pairing script: [Pairing with reciprocal check]:= [Mirror Loop][Third-order to Second-order][Final Exponentiation with Reciprocal Check]

[0158] 3.4.3 Multi-pairing script Similarly, for multi-pairing, two types of pairing scripts can be used, depending on whether the reciprocal is calculated off-chain and checked on-chain. Standard 3-pairing script: [3 pairings]:= [3-Mirror Loop][From Cubic to Quadratic][Final Power] A size-efficient 3-pairing script: [3-pairing with reciprocal check]:= [3-Mirror Loop][Third-order to Second-order][Final Exponentiation with Reciprocal Check]

[0159] 4. Blockchain Implementation The script above can be used in blockchain transactions. The example shown here uses a use case that provides knowledge about a secret value (e.g., a zero-knowledge proof). It will be understood that the pairings generated by executing the script can be used for other purposes known in this art by modifying the lock script to perform the necessary computations.

[0160] Alice, the challenger, generates a blockchain transaction for locking, or challenging. The blockchain transaction for locking consists of a lock script that performs the aforementioned calculations and verifications and calculates the pairing.

[0161] The challenger, Bob, generates an unlocking blockchain transaction. An unlocking transaction may be referred to as a solution or proof blockchain transaction. Bob may also be referred to as the provider or proof generator in this specification. An unlocking transaction consists of an unlocking script that satisfies the requirements of the lock script and provides the necessary inputs to generate the pairing.

[0162] For example, Alice generates a lock script that locks a quantity of UTXOs. This lock script is unlocked by another lock script that proves it knows the secret value using a zero-knowledge proof. To verify the zero-knowledge proof, a bilinear pairing is computed.

[0163] The lock script in this example calculates pairings using scripts 402, 404, 406, and 408 in Figure 4. However, it will be understood that it is also possible to calculate pairings using any combination of these scripts in combination with other appropriate script blocks. For example, the mirror loop script 404 can be used in combination with a known script for calculating the inverse matrix, and the pairings can be calculated using the outputs of these two scripts.

[0164] The unlock script generated by Bob and included in the proof transaction consists of all the elements necessary for the lock script to calculate the pairing, plus any other components necessary to satisfy the requirements of the lock script.

[0165] In this example, the unlock script includes a candidate proof value, also called the initial value, and a candidate reverse intermediate value. The initial value contains points P and Q in the source group used to calculate the pairing. The candidate reverse intermediate value is a point in the target field (an element of field FQ12). The unlock script also includes a signature generated using Bob's private key.

[0166] The lock script includes a mirror loop script 404 configured to perform the linear function and square update function described above. The mirror loop script 404 derives the intermediate value f as described above, based on the proof provided in the unlock script.

[0167] The lock script also includes a final power script 406 configured to verify that the candidate inverse intermediate value f' provided by the unlock script is equal to the reciprocal of the intermediate value f calculated by the mirror loop script 404. This verification can be done as described above.

[0168] The lock script also includes a bilinear pairing script 408 configured to compute pairings. This takes as input an intermediate value f computed by the mirror loop script 404 and a candidate inverse intermediate value f' provided by the unlock script.

[0169] The lock script may include additional computational blocks or scripts configured to verify the proof provided by the unlock script based on the computed bilinear pairing.

[0170] A lock script can be thought of as requesting values ​​necessary to unlock a UTXO, such as candidate inverse intermediate values. In some embodiments, the challenger may send a request off-chain to include the values ​​required for the unlock script.

[0171] It will be understood that the term "proof" is not limited to zero-knowledge proofs. A proof could, for example, be any value that proves eligibility to participate in an exchange.

[0172] The initial values, or proofs, provided by the unlock script consist of pairs of points on an elliptic curve from which bilinear pairings can be computed. Alternatively, these pairs of points on the elliptic curve can be derived from the initial values.

[0173] The lock script for a blockchain transaction can also be used for other calculations involving pairing. For example, the results of a pairing can be used to compute a BLS signature. The initial values ​​provided by the unlock script can consist of a public key and a message (points P and Q where the pairing is computed), or a signature and a curve generator (which may also be denoted as P and Q in the second pairing evaluation).

[0174] Those skilled in the art will be aware of other computations using bilinear pairing and computations that can be implemented using the methods disclosed herein. In each implementation, the initial values ​​are points P and Q on which the pairing is computed. What these points mean will vary depending on the use case, such as proofs in ZK proofs or signature / public keys in signatures, as discussed herein.

[0175] 5 examples 5.1 Estimating Script Size The input is

number

[0176] Roughly speaking, the script size for evaluating one pairing within the script is approximately 121KB.

[0177] If we need to evaluate three pairs and verify their equivalence, the script size would be approximately 180KB (30KB per mirror loop, so 90KB for three mirror loops, plus 90KB for one final power calculation). Currently, the smallest script performing such a comparison claims to be 1.5MB. Even with some stack position management, the script size for the three pair evaluations and equivalence verification shown here is well under 1.5MB.

[0178] Furthermore, the [3-MillerLoop] script mentioned above further reduces the script size. 5.2 BLS12 Parameters (hexadecimal). [Table 35]

[0179] 6. Example of a system overview A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

[0180] Transactions in a blockchain can be used for one or more purposes, such as moving digital assets (i.e., a certain number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indexing of data within transactions. Since there is no predetermined limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0181] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unconsumed transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, we consider pairs of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0182] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the legitimacy criteria applied at each node is that the unlock script satisfies all one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not propagate the target transaction (not as a legitimate transaction, but possibly to register a fraudulent transaction), nor will it include the target transaction in a new block to be recorded on the blockchain.

[0183] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0184] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0185] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0186] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0187] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0188] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming is certainly one common use, but it does not necessarily mean the transfer of a financial asset. More generally, consumption can be described as consuming an output or assigning it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0189] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

[0190] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and handle transaction 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributed to blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. Node software may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0191] Any given blockchain node can be configured to perform one or more of the following actions: transaction verification, transaction storage, transaction propagation to other peers, and consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, a node can specialize in a particular action. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0192] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0193] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain network 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0194] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each entity of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed herein to a given Party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0195] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may be downloaded from a server and provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0196] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0197] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not limited.

[0198] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to inquire about any transaction to which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on blockchain 150, since blockchain 150 is a public institution that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate transaction 152 throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0199] An alternative type of transaction protocol operated by some blockchain networks may be called an “account-based” protocol as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by the nodes of that network and is constantly updated. In such a system, transactions are ordered using the account’s transaction execution record (also called a “position”). This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0200] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction referencing the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

[0201] 7. UTXO Base Model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0202] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unconsumed transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also have a header 201, which may indicate the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0203] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0204] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0205] One or more of the outputs 203 of the preceding transaction Tx0 include UTXO0 and a specific UTXO herein labeled. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining the conditions that must be satisfied by an unlocking script in the inputs 202 of a subsequent transaction in order for the subsequent transaction to be valid, and thus for the exchange of the UTXO to succeed.

[0206] The lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (with a capital S) used by the blockchain network. The lock script specifies what information is required to consume the transaction output 203, e.g., specifying the requirements for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is code written in a domain-specific language that provides the information required to meet the lock script criteria. For example, it may include Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0207] Thus, in the example shown, UTXO0 in the output 203 of Tx0 has a lock script [Checksig P A , which requires Alice's signature Sig P A for the UTXO0 to be exchanged (strictly speaking, for a subsequent transaction attempting to exchange UTXO0 to be valid). [Checksig P A is the public key P from Alice's public key - private key pair AThe input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes a lock release script <Sig P A > comprises Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, by a node protocol, or a combination thereof.

[0208] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

[0209] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0210] Typically, the input to a transaction is the public key P. A This includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific part of the output that the digital signature signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects (and is therefore fixed at the time of signing) which outputs to sign.

[0211] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all application examples of blockchain150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0212] 8. Note: Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

[0213] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may apply in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any reference above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by a reference to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0214] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, distributing, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (as stated above, these entities would not be considered nodes of the preferred Bitcoin network 106).

[0215] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

[0216] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain nodes 104.

[0217] Several embodiments describe blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0218] Please note that the embodiments described above are illustrative. More generally, methods, apparatus, or programs can be provided in accordance with any one or more of the following statements.

[0219] Statement 1. A computer implementation method for generating pairings, comprising the steps of: obtaining an intermediate value derived based on an initial value provided by a provider; receiving a candidate inverse intermediate value from the provider; determining whether the candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the target inverse intermediate value is the reciprocal of the intermediate value; and, if the candidate inverse intermediate value is equal to the target inverse intermediate value, calculating a pairing based on the intermediate value and the candidate inverse intermediate value.

[0220] Statement 2. The method described in Statement 1, where the method is implemented in a script.

[0221] Statement 3. The method according to Statement 1 or 2, wherein the candidate inverse median is equal to the target inverse median by calculating the dot product of the candidate inverse median and the median, and if the calculated dot product is equal to 1, the candidate inverse median is equal to the target inverse median.

[0222] Statement 4. The method according to any of statements 1 to 3, wherein the method further comprises the step of performing a previous calculation block, and the intermediate value is the output of the previous calculation block.

[0223] Statement 5. The method described in Statement 4, wherein the previous computation block includes a mirror loop computation of hyperbolic pairing computation, and the intermediate value is the output of the mirror loop computation.

[0224] Statement 6. The method described in any of statements 1 through 5, wherein the initial value includes a pair of points on which the pairing is calculated.

[0225] Statement 7. The method of any of statements 1 to 6, wherein the initial value is a candidate proof, the provider is a proof generator, and the method further comprises the step of performing the next computation block, the next computation block taking a pairing as input and verifying a candidate proof based on the pairing.

[0226] Statement 8. The method described in Statement 7, wherein the candidate proof is a zero-knowledge proof.

[0227] Statement 9. The method of any of statements 1 to 6, wherein the initial value includes a public key and a message, the method further comprises a step of performing the next compute block, the next compute block receiving a pairing as input and generating a signature based on the pairing.

[0228] Statement 10. The method according to any of statements 1 to 6, wherein the initial value includes a signature and a curve generator, and the method further comprises the step of performing the next computation block, the next computation block receiving a pairing as input and generating a second signature based on the pairing.

[0229] Statement 11. A computer implementation method for generating a challenge blockchain transaction, comprising the step of providing a first lock script in a first output of the challenge blockchain transaction, wherein the first lock script is a first unlock script for a solution blockchain transaction, and the first unlock script, when executed together with the first unlock script, includes an initial value and a candidate inverse intermediate value, obtains an intermediate value derived based on the initial value, obtains a candidate inverse intermediate value from the first unlock script, determines whether the candidate inverse intermediate value is equal to a target inverse intermediate value, and if the target inverse intermediate value is the reciprocal of the intermediate value and the candidate inverse intermediate value is equal to the target inverse intermediate value, calculates a pairing based on the intermediate value and the candidate inverse intermediate value.

[0230] Statement 12. The method according to Statement 11, wherein the first lock script, when executed together with the first unlock script of the unlock blockchain transaction, is further configured to derive intermediate values ​​based on initial values.

[0231] Statement 13. The method according to Statement 11 or 12, wherein the initial value is a candidate proof, and the first lock script is configured to verify the candidate proof based on the pairing when executed together with the first unlock script of the solved blockchain transaction.

[0232] Statement 14. A computer implementation method for satisfying a challenge, wherein the challenge is satisfied based on a pair derived from an intermediate value and the reciprocal of the intermediate value, the intermediate value is derived from an initial value, and the computer implementation method comprises the steps of receiving a request from a verifier for an initial value and a candidate inverse intermediate value, and providing the verifier with an initial value and a candidate inverse intermediate value, wherein the candidate inverse intermediate value is the reciprocal of the intermediate value, and the challenge is satisfied based on a pair derived from the candidate inverse intermediate value and the initial value.

[0233] Statement 15. The method according to Statement 14, further comprising the steps of generating a solution blockchain transaction including a first unlock script, wherein the first unlock script includes an initial value and a candidate reverse intermediate value, and making the solution blockchain transaction available to one or more nodes of a blockchain network.

[0234] Statement 16. The method according to Statement 14 or 15, wherein the method further comprises the step of calculating a candidate inverse median.

[0235] Statement 17. The method of any of statements 14 to 16, wherein the initial value is a candidate proof and the method further comprises the step of computing the candidate proof.

[0236] Statement 18. Computer equipment comprising memory having one or more memory units and a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 17.

[0237] Statement 19. A computer program, embodied on computer-readable storage, configured to perform any method described in Statements 1 to 17 when executed on one or more processors. [Explanation of Symbols]

[0238] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output

Claims

1. A computer implementation method for generating pairings, A step of obtaining intermediate values ​​derived based on initial values ​​provided by the provider, The steps include receiving candidate inverse medians from the aforementioned provider, A step of determining whether the candidate inverse median is equal to the target inverse median, wherein the target inverse median is the reciprocal of the median. If the candidate inverse median is equal to the target inverse median, the step is to calculate the pairing based on the median and the candidate inverse median. A method that includes [a certain feature].

2. The method according to claim 1, wherein the method is implemented in a script.

3. By calculating the dot product of the candidate inverse median and the median, it is determined whether the candidate inverse median is equal to the target inverse median. The method according to claim 1 or 2, wherein if the calculated dot product is equal to 1, the candidate inverse median is equal to the target inverse median.

4. The method according to any one of claims 1 to 3, further comprising the step of performing a previous calculation block, wherein the intermediate value is the output of the previous calculation block.

5. The method according to claim 4, wherein the preceding calculation block includes a mirror loop calculation of a hyperbolic pairing calculation, and the intermediate value is the output of the mirror loop calculation.

6. The method according to any one of claims 1 to 5, wherein the initial value includes a pair of points on which the pairing is calculated.

7. The initial value is a candidate proof, the provider is a proof generator, and the method is The method according to any one of claims 1 to 6, further comprising the step of performing a next calculation block, wherein the next calculation block receives the pairing as input and verifies the candidate proof based on the pairing.

8. The method according to claim 7, wherein the candidate proof is a zero-knowledge proof.

9. The initial value includes a public key and a message, and the method is The method according to any one of claims 1 to 6, further comprising the step of performing a next calculation block, wherein the next calculation block receives the pairing as input and generates a signature based on the pairing.

10. The initial value includes a signature and a curve generator, and the method, The method according to any one of claims 1 to 6, further comprising the step of performing a next calculation block, wherein the next calculation block receives the pairing as input and generates a second signature based on the pairing.

11. A computer implementation method for generating challenge blockchain transactions, A step of providing a first lock script in the first output of the challenge blockchain transaction, wherein the first lock script is configured to perform the method of claim 1 when executed together with a first unlock script of a solution blockchain transaction provided by the provider, the first unlock script includes the initial value and the candidate inverse intermediate value, and the candidate inverse intermediate value is received by obtaining the candidate inverse intermediate value from the first unlock script, The steps include making the aforementioned challenge blockchain transaction available to one or more nodes in the blockchain network. A method that includes [a certain feature].

12. When the aforementioned first lock script is executed together with the first unlock script of the unlock blockchain transaction, The method according to claim 11, further configured to derive the intermediate value based on the initial value.

13. When the initial value is a candidate proof, and the first lock script is executed together with the first unlock script of the solved blockchain transaction, The method according to claim 11 or 12, configured to verify the candidate proof based on the pairing.

14. A computer implementation method for satisfying a challenge, wherein the challenge is satisfied based on a pair derived from an intermediate value and the reciprocal of the intermediate value, the intermediate value is derived from an initial value, and the computer implementation method is The steps include receiving requests for the initial values ​​and candidate inverse intermediate values ​​from the verifier, The step of providing the verifier with the initial value and the candidate inverse intermediate value, wherein the candidate inverse intermediate value is the reciprocal of the intermediate value, A method by which the challenge is satisfied based on the pairing derived based on the candidate inverse median and the initial value.

15. The method comprises the step of generating a decryption blockchain transaction including a first unlock script, wherein the first unlock script includes the initial value and the candidate inverse intermediate value. The method according to claim 14, further comprising the step of making the aforementioned blockchain transaction available to one or more nodes of the blockchain network.

16. The method according to claim 14 or 15, further comprising the step of calculating the candidate inverse median.

17. The method according to any one of claims 14 to 16, wherein the initial value is a candidate proof, and the method further comprises the step of calculating the candidate proof.

18. A memory having one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 17.

19. A computer program, which is implemented on computer-readable storage, and which, when executed on one or more processors, is configured to perform the method described in any one of claims 1 to 17.

Images