Bilinear pairing

Abstract

A computer implementation method for calculating pairings within a script is provided. The calculation of pairings includes at least one sub-calculation performed on a target field, the target field being represented as an extension field. A script is generated which includes at least one sub-function configured to perform the sub-calculation as an extension onto the extension field.

Description

[Technical Field]

[0001] This disclosure relates to a computer-implemented method for calculating pairings in a script. [Background technology]

[0002] Pairing on elliptic curves spans numerous cryptographic applications. For example, pairing can be used to construct signatures, identity-based encryption, non-interactive zero-knowledge proofs, and highly efficient multi-party key agreements.

[0003] Pairing e is a torsion group

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] Known methods for calculating pairings use field operations such as Karatsuba multiplication to minimize the number of CPU cycles performed. This comes at the cost of increasing the overall number of mathematical operations; that is, fewer multiplications are performed at the expense of more additions, resulting in faster execution. [Means for solving the problem]

[0006] According to one aspect disclosed herein, a computer-implemented method for computing pairings in a script is provided, the method comprising generating a script, the computing of pairings comprising at least one sub-computation performed in a target body, the target body being represented as an extension body, and the script comprising at least one sub-function configured to perform the sub-computation as an extension to the extension body. Using extended fields to perform parts of pairing calculations allows for the implementation of multiplication instead of addition, thus reducing the size of the script. [Brief explanation of the drawing]

[0007] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the following accompanying drawings are referenced merely as examples. [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] Here are some schematic examples of transactions that can be recorded on the blockchain. [Figure 3] This demonstrates point addition and point doubling on an elliptic curve. [Figure 4] A conceptual breakdown of the script for calculating pairings is outlined below. [Figure 5] The dependencies of the script that implements the field expansion operation are outlined below. [Figure 6]Schematically shows the relationship of a script for implementing a mirror loop for calculating single pairing or multi - pairing.

Mode for Carrying Out the Invention

[0008] 1. Elliptic curves and pairing

[0009] 1.1 Elliptic Curves Consider the cubic equation y notation , , ,

[0010] obtained from the finite field F of q elements. 2 = x 3 + ax + b. The elliptic curve is the set of affine points P := (x, y) that satisfy the above equation, together with an additional point at infinity denoted by O.

Number

Number

[0010] notation means the elliptic curve over F with the equation y q = x 2 + ax + b. When the field of definition is understood from the context, but one wants to emphasize that it is a cubic equation, then E: y 3 = x 2 = x 3 + ax + b q means the elliptic curve over F with the equation y 2 = x 3It is written as +ax+b. It can be written as E if both the field and the expression are understood from the context. It represents all points on an elliptic curve (i.e., a point P := (x,y) with coordinates x,y in any possible extension field). E(F q ) is when the coordinates are F q This represents the set of points that lie within it. Similarly,

number

number

[0011] 1.1.1 Adding and doubling points in affine coordinates An elliptic curve E forms a group under the "tangent and chord" rule. By the addition rule, E becomes a group with identity element at point O, which is at infinity.

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

[0013] To add two points P≠Q, we need to use a line l passing through P and Q. P,Q And the vertical line v passing through the intersection point with E that is neither P nor Q (i.e., -R on the left side of Figure 3) R This is necessary. Similarly, to double point P, the tangent line l to E at P is needed. P,P And the vertical line v passing through the other intersection point with E (i.e., -R on the right side of Figure 3) R The following is necessary. The formulas are shown below. The formula on the left corresponds to the addition of points for P≠Q, and the formula on the right corresponds to doubling of a point for P+P :=2P.

number

[0014] Note 1 As shown in Section 1.8, the line g passing through P≠Q P,Q , tangent line g at P P,P, and the vertical line v in R R This plays an important role in the definition of pairing. The formula is shown below. This provides an evaluation of the "tangent and chord" line at any point S of E in affine coordinates.

number

[0015] 1.1.2 Scalar multiplication of a point For any integer m ∈ Z and point P, the scalar multiple [m]P is defined by adding P to itself m times (or adding -P if m is negative). [m]P := P + ... + P. m times

[0016] 1.2 Projection Coordinates The point summation described in the section above is performed by calculating the scalar λ using an element of the field (x Q -x P or 2y P This requires finding the reciprocal of ). Since reciprocal calculation is a costly operation, it is desirable to avoid it. This can be achieved by switching to projective coordinates. By changing the coordinates x=X / Z, y=Y / Z, we can work with point P :=(X,Y,Z) and rewrite the elliptic curve arithmetic formula in Figure 3 without calculating the original reciprocal of the field.

[0017] 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, for smaller scalars, the points may be zero. For any divisor r of n, the r-skew group is the set of points of order r: E[r] := {P∈E|[r]P=O}. The r-torsion group also forms a group. Therefore, it is a subgroup of E. The structure of the r-torsion group is well known. When r is relatively prime to q,

number

[0018] 1.3.1 Embedding degree of curve E A point (or its coordinates) on an elliptic curve E is defined as a field F. q Enlarged version

number

number

[0019] 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 the following two subgroups of the r-twist:

[0020] 1.3.3 Fundamental body group G 1 ⊆E[r] This is completely E(F q It is the only subgroup of E[r] that exists within ). The base field group G1 is the Frobenius map.

number

number

[0021] Note 2 The important thing is that the coordinates of a point within G1 are always F q It is located within the G1, and therefore, elliptic curve arithmetic in G1 is as efficient as possible.

[0022] 1.3.4 Zero Trace Group G 2 ⊆E[r] This is a subgroup of E[r] with important properties. Any point in the torsion group is

number

[0023] Trace maps are,

number

number

[0024] The above aTr map is an antitrace map defined as aTr(P) :=[k]P-Tr(P). Tr(aTr(P))=O holds, and therefore aTr maps the point to G2.

[0025] Note 3Points P,Q ∈ G2 are Fq k Because it has internal coordinates, performing arithmetic operations on G2 is costly. Direct Fq k Working with it is not essential; instead, use a curve twist to create a smaller body

number

[0026] 1.4 Curves with a twist Curve E / F q :y 2 =x 3 Consider +ax+b. The twist E' is given by the following equation.

number

number

[0027] The possibility d∈{2,3,4,6} is defined as follows: • Quadratic twist, d=2. Any curve E:y 2 =x 3 This is applicable to ax + b. Therefore, any a, b ∈ F q This concerns... • Third-order twist, d=3. Curve E:y 2 =x 3 It is usable for +b. Therefore, a = 0. • Fourth-order twist, d=4. Curve E:y 2 =x 3 It is usable for +ax. Therefore, b=0. • Sixth-order twist, d=6. Curve E:y 2 =x 3It is usable for +b. Therefore, a = 0.

[0028] An important fact used in the context of pairing is E|Fq k The preimage of the zero-trace group within the Ψ is twisted E'|Fq k / d This means that it is the base field group G'1 within G2. In other words, arithmetic operations in G2 are instead performed within its twisted G1', and the results can be remapped back to the original G2.

[0029] Note 4 From Section 1.3, it should be recalled that arithmetic operations within G2 are expensive. It is important to remember that if P,Q ∈ G2 and P+Q must be computed, then R' := Ψ -1 (P)+Ψ -1 This means that (Q) can be calculated in advance, and then Ψ(R')=P+Q can be used whenever needed in the mirror loop of the pairing calculation (see Section 1.6). -1 (P), Ψ -1 (Q)∈G'1 is (larger Fq) k (Not inside) Fq k / d This improves efficiency because the coordinates are internal. Further improvements can be made by implicitly replacing G2 with its twisted G'1 when defining the pairing domain, performing point addition (or point doubling) using points P',Q'∈G'1, and mapping the result to G2 via Ψ whenever the result is needed. Only two multiplications are required to calculate Ψ.

[0030] 1.5 Pairing Pairing e is the torsion group E(Fp k This is a bilinear map defined for two group source elements in [r]. This maps the pair of originals to the target group

number

number

[0031] 1.5.1 Pairing Type Depending on how source groups G1 and G2 are selected, there are three types of pairings. Type 1 Symmetric pairing: G1=G2:=E(F q )[r], therefore the base field group (see Section 1.3). The curve must be hyperspecific. This is E(F q The point inside the parentheses is E(Fq k This means that there is a distortion map that transfers to E(F). q It is known whether to hash in [r] and sample random elements. Since all known pairings (see Section 1.3) require P and Q in different groups, the pairing is

number

[0032] Note 5 Currently, Type 3 pairing is the most well-studied because it is more efficient than Type 1 and offers more functionality than Type 2. Therefore, we will use Type 3 pairing here for the Script implementation in Section 3.

[0033] 1.6 Weil, Tate and the Optimal Eight Pairing Simply put, the pairing of two points P and Q is a function f related to P. n,P This consists of constructing and evaluating it at point Q. The selected f i,P This is a Miller function and is defined as follows:

number

[0034] The original pairing was by Weil. Since then, several variations have been proposed, with the optimal eight-pairing being the most efficient. The various pairings can be concisely defined as follows:

number

[0035] In Weil pairing and Tate pairing, the degree is approximately r, i.e., groups G1, G2, G T The order of the function f r,PWe need to find this. For cryptographic applications, r is large, for example, 256 bits or more, and therefore the degree is 2 256 Computing a function of this magnitude is a huge task. Section 1.7 shows how to do this efficiently (i.e., in log(r) steps). Weil pairing is not typically used because it requires the computation of two mirror functions (one evaluated at P and one evaluated at Q). Tate pairing and optimal Ate pairing require only one function evaluation (at P). • In optimal eight-pairing, the required order l of the Miller function is much lower than in Tate pairing, and therefore the computation is more efficient than Tate pairing. For this reason, all known implementations use optimal eight-pairing, as they do here as well. However, (q k Note that the exponentiation of -1) / r remains unchanged, and the mirror function depends on Q (not P). In the Type 3 setting, Q is a point in the twist of the zero-trace group, and therefore Fq k / d It has coordinates within it.

[0036] 1.7 Curves that make pairing easy Elliptic curves have the following parameters: q, t, r, k. • q: A prime integer. The underlying field F. q Size ·r: Three groups G1, G2, G T Size ·k: degree of embedding • t: Frobenius trace (only necessary for optimal eight-pairing)

[0037] Pairing is Fq k Since the operation needs to be performed in this context, elliptic curves are "easy to pair" as long as the embedding degree k is not too large. Typically, k = 6, 12, 24.

[0038] For cryptographic applications, for optimal eight-pairing, the source groups G1, G2 of order r ⊆ E(Fq k The elliptic curve discrete logarithm (ECDLP) problem in [r] and the discrete logarithm problem (DLP) in the target group, i.e., the r-th root of unity μ r ⊆F*q k Calculating this must be difficult. This imposes a trade-off between the size of q and the size of r.

[0039]

number

number

[0040] Note 6 The larger the value of ρ, the larger the F q This means working with. The focus here is not on the CPU cycles in the pairing calculation, but instruction The goal is to minimize the number of ρs. Therefore, a larger ρ is not necessarily a bad choice. In other words, pairing on an inoptimal curve may result in a smaller script size. In this context, the embedding order and twist order seem to be more important parameters.

[0041] 1.7.1 Parameterized families The values ​​of q, r, and t are parameterized as polynomials q(u), r(u), and t(u). For specific values ​​of u ∈ Z, the values ​​q, r, and t can be obtained. Depending on the shape of the polynomials, there are various families.

[0042] The most well-known families are BN, BLS12, BLS24, and KSS, although other families are possible. To achieve 128-bit security, considering the latest advancements in DLP solutions, BLS12 is preferred over BN. Thus, the script implementation provided here is based on this curve. BLS12 is a family between BLS12-381 and BLS12-440. The former is more efficient, but the DLP solution may be hampered by improvements. The latter is less efficient (relatively, still Type 3, see Note 5 above), but is considered to be more secure. That is, it is considered unlikely that there will be an improvement in the DLP solution in the near future that would reduce its security below 128 bits. The following table describes the BLS12 curve family.

Table 1

[0043] 1.8 Mirror Algorithm Recall from Section 1.6 that the optimal eight pairing requires two steps or functions.

Number

[0044] In the above, 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 was observed that the mirror gives a "doubling and adding" algorithm that computes f r,Q in approximately log(r) steps. To avoid storing f r,Q (which is a function of degree r), the intermediate function f i,Q is also evaluated sequentially and iteratively at the (fixed) point P.

Table 2

[0045] Thus, the Miller algorithm sequentially and iteratively accumulates f i,Q (P) using the above formula in a "double-and-add" fashion, and then sets f := f l,Q (P) raised to the power of (q k - 1) / r. This is the result of the pairing, as shown in the above table.

[0046] Note 7 . The important optimization incorporated is the so-called "denominator cancellation". There is no need to calculate the evaluation of the vertical lines v [i+1]Q , v [2i]Q because these terms map to 1 in the final exponentiation step. This optimization is only available for Type 3-setting Tate pairings and their variants. In the case of the Vayu pairing, this is not available because it uses a twisted curve and a final exponentiation step. [[ID=​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ 2.1 Body representation Target group

number

number

number

number

number

[0049] 2.1.1 Why are there three expressions? Fq 12 Therefore, only element multiplication and reciprocal calculation are required (the latter only for the simple part of the final power of the pairing calculation). For reciprocal calculation on quadratic and cubic extensions, there are well-known efficient algorithms. Fq 12 Fq 6 The above is a quadratic extension (and Fq 6 is Fq 2 The above is a cubic extension, Fq 2 is F qThis means that the first representation (which is a quadratic extension above) can be used. In other words, Fq 2 and Fq 6 Arithmetic is required in this case; that is, addition, subtraction, multiplication, negation, and reciprocal calculation. Furthermore, in this representation, the unitary Fq (which occurs during the calculation of the second part of the final power) is used. 12 The reciprocal of an element a+bw is calculated using the simple conjugate (a+bw). -1 It can be calculated using :=(a-bw).

[0050] Second expression (Fq 12 is Fq 2 The above 6th-order extension is useful for raising a number to the power of q using the Frobenius operator (for the final power). Frobenius is far more efficient than the standard "square and multiply" algorithm for raising a number to the power of q, requiring only five multiplications (with pre-computation).

[0051] Third expression (Fq 12 is Fq 4 The above cubic extension is Fq in the Miller loop. 12 It is used to perform multiplication in Fq. The reason is that the result of a linear function can be represented very sparsely in the third representation. Using this fact, the mirror loop can be divided into two subroutines that take advantage of the sparsity in the defined multiplication within the loop. 12 The various types of sparse multiplication in can be distinguished using this.

[0052] Based on the comments above, the following sections specify arithmetic formulas. These will serve as the codebase for the scripts detailed in Section 3.

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

[0054] Fq 2 The element is F q It is a pair of elements. Ultimately, Fq 12 The elements are always 6 Fq 2 Although it is a vector of coefficients, the rules governing the operation differ depending on the representation. Switching between representations is done using Fq. 12 We simply change the coefficients of the given elements in the expression. The following table gives the exact permutations of coefficients to switch between representations. [Table 3]

[0055] example The switching between quadratic and sixth-degree extensions can be derived as shown below. X = x1 + x2w is a quadratic extension.

number

number

number

number

[0056] 2.2 Fq 2 A curve with arithmetic twist in Fq2 The elements inside are u 2 X is a linear polynomial modulo +1.

number

number

[0057] Fq 2 Addition, subtraction, and scalar multiplication in this context are defined in a natural way. Thus, addition and subtraction are component-wise, and scalar multiplication is defined for each component by a scalar λ∈Fq. 2 Multiply by q. All operations are performed modulo q. [Table 4]

[0058] Fq 2 :=F q [u] / (u 2 Element multiplication in (+1) is defined in Table 5 below. Squaring and multiplying by ξ := u+1 are also described as separate routines. [Table 5]

[0059] 2.3 Fq 4 Arithmetic in Fq 4 =Fq 2 [s] / (s 2 The elements in -ξ) are s 2 X is a linear polynomial modulo -ξ.

number

number

number

[0060] 2.4 Fq 6 Arithmetic in Fq 6 =Fq 2 [v] / (v 3 The elements in -ξ) are v 3 X is a quadratic polynomial modulo -ξ.

number

number

[0061] 2.5 Fq 12 Arithmetic in target field In the target field, a vector has 12 components. Here, a sparse vector is considered to have at least 6 elements set to 0. On the other hand, a some-what spare vector has at least 2 elements set to 0.

[0062] 2.5.1 Multiplication as a quadratic extension In the final power of the pairing, Fq 12 is given as a quadratic extension over Fq 6 . That is, Fq 12 = Fq 6 [w] / (w 2 - v). In this representation, an element is a polynomial X of degree 1 modulo w 6 := Fq 2 [v] / (v 3 - ξ) with coefficients in Fq 2 . Thus,

Number

Number

Number

Number

[0063] Fq 6 formulas for multiplication, squaring, and reciprocal calculation in Fq using 12 arithmetic are given in Table 9. The reciprocal calculation of unitary elements is done via a very efficient conjugate. This is an advantage of representing Fq 12 as a quadratic extension in the final power.

Table 9

[0064] 2.5.2 Powers as Quadratic Extensions It can be said that the final power consists of an easy part and a hard part. These terms are those used in the art.

[0065] The hard part of the final power requires powers u and u / 2 (where u is a curve parameter). These powers are performed through the general algorithm "squaring and multiplying with a sign". Thus, the exponent e (either u or u / 2) is in binary signed form, i.e., e i It is given using bits within ∈{-1,0,1}. This algorithm can only be used to raise the unit element to a power (i.e., the hard part in the final power). See Table 10. [Table 10]

[0066] 2.5.3 Multiplication as a cubic extension During the Miller loop, we utilize the sparsity of the result of the linear function evaluation, Fq 12 Various formulas are used for multiplication. Therefore, Fq 12 is, Fq 4 :=Fq 2 [s] / (s 2 It can be expressed as a cubic extension over -ξ). That is, Fq 12 :=Fq 4 [r] / (r 3 -s) Therefore, Fq 12 The elements are, 3 We are viewing this as a quadratic polynomial X modulo -s.

number

[0067] The result L from the linear calculation is a sparse element with half of its coefficients set to 0 (see Section 2.7 below). In other words, Fq 12 The elements are given in the following form:

number

[0068] In the mirror loop process, sparse elements are multiplied by sparse elements. The result is a quasi-sparse element of the following form (i.e., a third Fq). 4The second component of the coefficient is set to 0, i.e., $\overline{f} = \overline{0}$ (the bar on top is sometimes denoted like this for convenience).

Number

[0069] Also, between the mirror loops, a sparse $\overline{S}$ or a quasi-sparse $\overline{S}'$ is multiplied by a standard (dense) element $\overline{X}$. In this way, the sparsity of $\overline{S}$ and $\overline{S}'$ is utilized in these types of multiplications. Various types of multiplications are given in Table 11. Note that these formulas are given at a low level, i.e., using Fq 2 arithmetic.

Table 11-1

Table 11-2

[0070] Multiplication and squaring in the cubic representation are not essential but can be used to avoid unnecessary switching between representations in the mirror loop, i.e., to avoid introducing opcode overhead. See Table 12.

Table 12

[0071] 2.6 Twisted curve E'(Fq 2 EC arithmetic in ) Two points on the twisted curve E'(Fq 2 ) are

Number

[0072] 2.7 Target Object Fq 12 Evaluation of the linear function in Twisted curve E'(Fq 2 Two points in )

number

[0073] 2.7.1 Line g for point addition Ψ(T),Ψ(Q) A straight line g passing through points Ψ(T) and Ψ(Q) without twist. Ψ(T),Ψ(Q) The evaluation at P is calculated. Fq 12 :=Fq 4 [r] / (r 3 The results of the evaluation in -s) can be expressed as follows:

number

[0074] The result is a non-zero Fq 2 It is a sparse polynomial with only three coordinates. Therefore, g Ψ(T),Ψ(Q) (P) is a sparse form with three Fq 2 It can be represented as a coordinate vector:

number

[0075] Table 14 shows explicit formulas that can be used to calculate the coefficients ￣a, ￣b, and ￣c. [Table 14]

[0076] 2.7.2 Line g for doubling a point Ψ(T),Ψ(T) Similarly, Fq 12 :=Fq 4 [r] / (r 3 -s) Tangent line g at P Ψ(T),Ψ(T) The formula for calculating the evaluation of is given by the following equation:

number

number

number

[0077] 2.8 Exponentiation by Frobenius endomorphism In the final power, given Fq 12 About the elements

number

[0078] Fq 12 This can be expressed as a quadratic extension (first representation), and therefore X := x0 + x1t. (x0 + x1) tTo calculate this, when expanding the expression, powers less than q disappear because the coefficients are multiples of q (the characteristic of the field).

[0079] Next, Fq 2 Regarding element a := a1 + a2u, the following can be observed.

number

[0080] therefore,

number

[0081]

number

[0082] 2.9 Final power The final power is

number

number

[0083] A body that is easy to pair with is expanding

number

number

[0084] In BLS12 (and BN, for that matter), the embedding order is k=12, so the above formula for the exponent becomes:

number

[0085] 2.9.1 Final power - First part (easy part) f is Fq 12 =Fq 6 [w] / (w 2 Expressed as an element within -v),

number

[0086] 2.9.1 Final Exponentiation - Part 2 (Difficult Part) The second part is specific to each curve. Here we will explain how to do this for BLS12. The output of the first part is

number

[0087] The second part is the power g d It is constructed by calculating . Here, d:=(q 4 -q 2 The formula is (+1) / r. First, the exponents are the sum d = λ0 + λ1q + λ2q 2 +λ3q 3 It is expressed as follows: Here, the coefficient λ i is an integer. This means that the result of the final power is as follows:

number

[0088] The above powers typically depend on the parameterization of the prime number q, which affects the details of each curve (λ). i The addition chain for a specific coefficient of and the power q, q 2 , q 3 This is done using the application of the Frobenius operator to λ. An optimized addition chain for BLS12 is used. See Table 18 for the algorithm. The addition chain is applied to λ i The specific values ​​are as follows:

number

[0089] 3 Script The following scripts are available for implementing BLS12 pairing in Script. These scripts are divided into four main conceptual blocks: the Extended Field Arithmetic script 402, the Mirror Loop script 404, the Final Exponentiation script 406, and the Pairing script 408. The script used by external users is script 408 within the Pairing block. The other scripts 402, 404, and 406 are internal. The conceptual division and dependencies of the scripts are shown in Figure 4.

[0090] Pairings can be calculated 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 calculates the reciprocal. Other combinations of script blocks can also be implemented.

[0091] Scripts 402, 404, 406, and 408 are referred to as computation blocks in this specification.

[0092] In the examples provided herein, scripts are shown as blockchain scripts. However, it will be understood that these scripts can be any form of computer-readable script. In particular, these scripts can be any form of bytecode or binary code. In such code, arbitrary loops are consumed. For example, instead of defining a branching script that includes if statements, one can define each loop sequentially to generate a script without branching.

[0093] The script provided here minimizes the size of such non-branching scripts.

[0094] 3.1 Extended Field Arithmetic Scripts The extension field arithmetic script performs arithmetic operations on the paired extension fields Fq,Fq 2 Fq 4 Fq 6 Fq 12The above is an arithmetic operation.

[0095] Available implementations for multiplication and squaring on a given quadratic or cubic extension of a base field use Karatsuba multiplication and the square method of complex numbers or Chung-Hasan squaring, respectively. These algorithms generally use fewer multiplications and more arithmetic operations on the base field. Therefore, they are faster to execute, meaning they require fewer CPU cycles, but they are more expensive to write in scripts.

[0096] The scripts provided here use an algorithm that provides scripts with fewer opcodes. Therefore, these scripts are considered size-efficient.

[0097] The extended field arithmetic block is divided into eight groups. See Figure 5. The script for the upper FQ12 group is used in the pairing mirror loop and the final power part. The inner group is FQ12(Fq 12 Includes the scripts necessary to implement the operations in ).

[0098] The script provided here can be used to compute pairings. Pairings can be computed by performing a set of sub-computations on the target field. Alternatively, the target field can be represented as an extension field and sub-computations performed by sub-functions on that extension field.

[0099] Sub-computations of pairing computations can be performed by sub-functions executed on different extension fields. The elements output by these sub-functions can be transformed to be represented on different extension fields.

[0100] Using subfunctions in extension fields reduces the size of pairing calculations in the script, thus improving the computational efficiency of the calculations.

[0101] 3.1.1 FQ F q The arithmetic above. The FQ element is an integer x modulo q. Therefore, 0 ≤ x <qである。 Implementing addition, subtraction, negation, multiplication, and squaring of modular integers is straightforward. Bitcoin Script supports modular arithmetic using native opcodes such as OP_ADD, OP_SUB, OP_MUL, and OP_MOD.

[0102] 3.1.2 FQ2 Fq 2 :=F q [u] / (u 2 Arithmetic on +1) where ξ := u+1. The elements of FQ2 are pairs of integers.

number

[0103] 3.1.3 FQ4 Fq 4 :=F q 2 [s] / (s 2 -ξ) Arithmetic. FQ4 elements are pairs of FQ2 elements.

number

[0104] 3.1.4 FQ6 Fq 6 :=F q 2 [v] / (v 3 -ξ) Arithmetic on the FQ6 element. The FQ6 element is a triplet of the FQ2 element.

number

[0105] 3.1.5 FQ12 secondary Fq 12 :=F q 6 [w] / (w 2 Multiplication on -v). That is, Fq 6 The above is a quadratic extension. FQ12 quadratic elements are pairs of FQ6 elements.

number

[0106] 3.1.6 FQ12 tertiary sparse Fq 12 :=F q 4 [r] / (r 3 Multiplication and squaring on -s). That is, Fq 4 The above is a cubic extension. The following types of elements are distinguished:

number

[0107] 3.1.7 FQ12 Reciprocal Calculation Fq 12 The algorithm for calculating the reciprocal of elements in [the specified context]. The reciprocal calculation involves elements of the following types (as defined in previous sections): FQ element • FQ2 element • FQ6 elements • FQ12 secondary elements Table 24 lists scripts that invert (calculate by reciprocal) elements. [Table 24]

[0108] 3.1.8 F12 Frobenius Using Frobenius, powers q, q of Fq12 elements 2 ,q 3 Exponentiation by . [Table 25]

[0109] 3.2 Mirror Loop Script Figure 6 shows the script relationships required to implement a mirror loop for a single pair or a combination of three pairs.

[0110] The mirror loop script includes a line function and a square-and-update function. The output of the line function is an array of elements, which are provided as input to the square-and-update function. The line function takes curve points Q and P as input.

[0111] Each of these functions contains 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 contains a set of subfunctions to perform a portion of the function.

[0112] In both single-pairing and multi-pairing variations, each loop of the linear function may contain one of two distinct sets of subfunctions, referred to herein 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.

[0113] When curve parameters are represented in binary format, the curve parameter conditions are based on the values ​​of the corresponding bits of the curve parameters. In the following examples, 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.

[0114] 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. Conversely, 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 corresponding set of subfunctions for each loop of the linear function is also predefined. Therefore, there is no need to branch in the script.

[0115] For 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.

[0116] In the case of multiple pairings, the first and second sets of subfunctions will contain some identical subfunctions and some different subfunctions.

[0117] The array of elements output by the linear function contains the elements calculated by each loop of the linear function, i.e., the output.

[0118] The linear function also includes an initial curve point subfunction that takes a curve point Q as input and calculates an initial curve point T. The first loop of the linear function takes the initial curve point as input and updates the curve point T. Each subsequent loop of the linear 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.

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

[0120] In the single-pairing variation, the squared-update function also includes two sets of subfunctions, the specific set used for each loop depends on the curve parameter conditions as described above. The two possible sets of subfunctions of the squared-update function described above may be referred to herein as the third and fourth sets of subfunctions.

[0121] The third and fourth sets of subfunctions each contain a squaring subfunction and a multiplication subfunction. In the third set of subfunctions, the multiplication subfunction is sparse multiplication by dense vector multiplication, whereas in the fourth set of subfunctions, the multiplication subfunction is semi-sparse multiplication by dense vector multiplication.

[0122] In the multipairing transformation, the loops of the squaring and updating function contain the same set of subfunctions, regardless of the curve parameter u. All loops contain the same squaring and multiplication subfunctions.

[0123] Squaring the output of the update function gives us the intermediate value f. This intermediate value f can be used to calculate the pairing.

[0124] Scripts that can be used to run a mirror loop for a single or multiple pairing are shown in Tables 26 and 27, respectively.

[0125] By performing the mirror loop in this manner, intermediate values ​​can be computed by sparse multiplication on the extended field. The operands of sparse multiplication can be written very concisely, which reduces the number of opcodes for stack management and thus improves computational efficiency. The new formulas for various variations of sparse multiplication are fully shown in Table 11.

[0126] Since the curve parameters are predefined, each loop in each function is also predefined. Therefore, the term "loop" refers to a set of subfunctions within the function that are implemented sequentially. The loop can be considered unrolled; 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 inputs from the previous set of subfunctions.

[0127] In this way, the mirror loop itself can be considered as being loop-expanded; that is, each subfunction is executed only once.

[0128] 3.2.1 Splitting the mirror loop into two loops To iterate through the mirror loop sequentially, the mirror loop (Table 2, steps 1-10) is divided into two loops. The first loop calculates the evaluation result of the linear function and stores it in an array g of FQ12 elements. The main (second) loop takes the stored result g as input and updates and squares the element f. [Mirror Loop] := [Linear Function Loop] [Main Loop] ~ By calculating the mirror loop in this way, many multiplications become sparser, making it faster to write (and execute) than standard FQ12 multiplication in scripts. See Table 26 for pseudocode.

[0129] 3.2.2 Multi-pairing A compound mirror loop can also be implemented to enable support for multiple pairings. Here, we give the case of three pairings. In this case, three linear functions (one for each pairing) are computed together, and an array g is given that holds the computed combined linear functions. Then, the combined f-values ​​are updated and squared. [3 Mirror Loop] := [3 Linear Function Loop] [3 Main Loop] Combining various linear functions allows for more sparse multiplications overall compared to calculating them separately, thus improving computation speed. See Table 27 for pseudocode.

[0130] 3.2.3 Pre-calculation of λ and θ for point addition and 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 (upper row of Table 13). In the Miller loop, these values ​​only need to be calculated once for both operations. Thus, λ and θ can be calculated first, and equivalent routines can be defined for point addition and line evaluation, respectively, taking λ and θ as inputs.

[0131] [Table 26]

[0132] [Table 27-1] [Table 27-2]

[0133] 3.2.4 Script The mirror loop has the following three types of operation: 1) Curve with twist E'(Fq 2 Point addition / double point in ) 2) Target body Fq 12 Linear function evaluation. 3) Fq 12 Sparse multiplication and squaring.

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

[0135] 3.3 Final Power Script

[0136] 3.3.1 Avoiding reciprocal calculations The most costly (field arithmetic) operation in pairing computation is Fq. 12 This is a reciprocal calculation in the case of . While the reciprocal can be avoided by conjugate during the second part of the final power, this is not possible in the first part. Therefore, in order to calculate the pairing, it is necessary to calculate the reciprocal of the output f of the mirror loop.

[0137] In the method described here, f is reciprocated off-chain, and its reciprocal f' := f -1 This is passed as input to the final power calculation script. Therefore, the reciprocal calculation routine is replaced by checking f·f'=1 instead. This change eliminates the need for all routines dedicated to reciprocal calculation in intermediate extension fields, resulting in significant savings when writing scripts. See Table 30. [Table 30]

[0138] As described above, the value f may be referred to here as the intermediate value. The inverse f' of this value, provided as input to the final power script, may be referred to here as the candidate reciprocal intermediate value. The provided reciprocal is considered a candidate value because the step f·f'=1 checks that the provided reciprocal is the inverse of f. This check has the effect of verifying that the target inverse intermediate value is equal to the target reciprocal intermediate value, which is the reciprocal of the value f.

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

[0140] 3.3.2 Composition of the First and Second Powers The final power script simply executes the easy and hard parts sequentially. Since there are two flavors for the easy part, there are two final power scripts. [Final power]:=[Easy part][Difficult part] [Final exponentiation by reciprocal check]:= [Easy part using reciprocal check] [Difficult part]

[0141] 3.3.3 Script Table 31 lists the necessary scripts for the final power calculation. [Table 31]

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

[0143] 3.4.1 Switching between expressions The output of the Miller loop is Fq as a cubic extension. 12 It is the element f within the function. The final power is the same f, but we expect it to be expressed as an element of a quadratic extension. [Table 32]

[0144] 3.4.2 Single Pairing Script Two variations can be used for the pairing script. These are functionally equivalent, but the second one (using reverse checking) is shorter in description. Standard pairing script: [Pairing]:= [Mirror Loop] [From cubic to quadratic] [Final power] Size-efficient pairing script: [Pairing using reverse check]:= [Mirror Loop][Third-order to Second-order][Final Exponentiation Using Reverse Check]

[0145] 3.4.3 Multi-pairing script Similarly, for multi-pairing, two variations of the pairing script can be used, depending on whether the reciprocal is computed off-chain and checked on-chain.

[0146] Standard 3-pairing script: [3 pairings]:= [3-Mirror Loop] [Third-order to Second-order] [Final Power] A size-efficient 3-pairing script: [3 pairs with reverse check] := [3-Mirror Loop][Third-Order to Second-Order][Final Exponentiation Using Reverse Check][3-Mirror Loop][Third-Order to Second-Order][Final Exponentiation Using Reverse Check]

[0147] 4. Blockchain Implementation The script described above can be used in blockchain transactions. The examples provided herein use use cases that provide knowledge of secrets, such as zero-knowledge proofs. It will be understood that the pairings generated by running the script can be used for other purposes, as is known in the art, by modifying the lock script to perform the necessary computations.

[0148] Alice, the challenger, generates a lock or challenge blockchain transaction. The lock blockchain transaction includes a lock script that performs the calculations and verifications described above and calculates the pairing.

[0149] Bob, the challenger, generates an unlock blockchain transaction. An unlock transaction is sometimes called a solution or proof blockchain transaction. Bob is sometimes referred to here as the provider or proof generator. The unlock transaction includes an unlock script that satisfies the requirements of the lock script and provides the necessary inputs to generate the pairing.

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

[0151] The lock script in this example uses scripts 402, 404, 406, and 408 in Figure 4 to calculate the pairing. However, it will be understood that any combination of these scripts may be used with other appropriate script blocks to calculate the pairing. For example, the mirror loop script 404 may be used with a known script for calculating the reciprocal, and the outputs of these two scripts may be used to calculate the pairing.

[0152] The unlock script generated by Bob and included in the proof transaction contains all the elements required by the lock script to calculate the pairing, as well as any other elements required to satisfy the requirements of the lock script.

[0153] In this example, the unlock script includes a candidate proof value, also called the initial value, and a candidate inverse intermediate value. The initial value includes points P and Q in the source set used to compute the pairing. The candidate inverse 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.

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

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

[0156] 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 in the unlock script.

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

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

[0159] It should 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.

[0160] The initial values ​​or proofs provided in the unlock script include pairs of elliptic curve points from which bilinear pairings can be computed. Alternatively, the pairs of elliptic curve points may be derived from the initial values.

[0161] The lock script for a blockchain transaction may be used for other calculations that use pairing. For example, the results of pairing may be used to calculate a BLS signature. The initial values ​​provided in the unlock script may include a public key and message (points P,Q for which pairing is calculated), or a signature and curve generator (also seen as P,Q for a second pairing evaluation).

[0162] Those skilled in the art will recognize other computations that may be implemented using bilinear pairings and the methods disclosed herein. In each implementation, the initial values ​​are points P,Q for which pairings are computed. What these points mean depends on the use case, such as proofs in zk-proofs or signatures / public keys in signatures, as discussed herein.

[0163] 5 examples

[0164] 5.1 Estimating Script Size The input is F q The six elements within represent two points P and Q. Therefore, it takes approximately 6 × 50 = 300 bytes. [Table 33] [Table 34] [Table 35] [Table 36]

[0165] As an estimate, the script size for evaluating one pairing within the script is approximately 121KB.

[0166] If a 3-pairing evaluation is required and equality is checked, the script size is approximately 180KB (30KB for one mirror loop, so 90KB for three mirror loops, and 90KB for one final power). The current smallest script for such a comparison is 1.5MB, as published by sCrypt. Even with some stack position management, the script size for the 3-pairing evaluation and equality verification provided here will be significantly smaller than 1.5MB.

[0167] Note that the above [3-mirror loop] script offers further script size savings.

[0168] 5.2 BLS Parameters in hexadecimal. q: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab r: 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001 x: 0x17f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb y: 0x08b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1 h: 0x396c8c005555e1568c00aaab0000aaab b: 4 x'_0: 0x024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb8 x'_1: 0x13e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e y'_0: 0x0ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801 y'_1: 0x0606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be h': 0x5d543a95414e7f1091d50792876a202cd91de4547085abaa68a205b2e5a7ddfa628f1cb4d9e82ef21537e293a6691ae1616ec6e786f0c70cf1c38e31c7238e5 b': 4*(u + 1)

[0169] 6. Illustrative System Overview Blockchain refers to a form of distributed data structure. Copies of the blockchain are maintained on each of the multiple nodes within a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain contains a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," refers to a previous transaction in a sequence spanning one or more blocks that leads 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." This process involves multiple nodes competing to perform a "proof of work." In other words, they solve a cryptographic puzzle based on a defined representation of an ordered, validated, pending set of transactions waiting to be included in a new block of the blockchain. Note that a blockchain may be pruned by several nodes, and block publication can be achieved simply by publishing the block header.

[0170] Transactions within a blockchain can be used for one or more of the following purposes: to transmit digital assets (i.e., a number of digital tokens); to order a set of entries in a virtualized ledger or registry; to receive and process timestamp entries; and / or to time-order index pointers. Blockchains can also be used to add additional functionality on top of them. For example, a blockchain protocol may allow the storage of additional user data or indices within the data of a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction. Therefore, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data within the blockchain.

[0171] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any available output includes an element specifying the amount of digital asset that can be derived from the ongoing sequence of transactions. Available outputs are sometimes called UTXOs (unspent transaction output). Outputs may further include a lock script that specifies the conditions for the output's future redemption. A lock script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction, and may further include an unlock script to unlock the lock script of the pointed output. Thus, consider a pair of transactions, which we will call the first and second transactions (or "target" transactions). The first transaction includes at least one output specifying the amount of digital asset and a lock script that defines one or more conditions for unlocking the output. A second target transaction includes at least one input containing a pointer to the output of the first transaction, and a lock release script for unlocking the output of the first transaction.

[0172] 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 validity criteria applied at each node is that the unlock script satisfies all of one or more conditions defined in the lock script of the first transaction. Another is that the output of the first transaction has not already been redeemed by another previous valid transaction. Any node that finds a target transaction to be invalid according to any of these conditions will not propagate it (it will not propagate it as a valid transaction, but it may propagate it to register an invalid transaction) and will not include it in a new block recorded on the blockchain.

[0173] Another type of transaction model is the account-based model. In this case, each transaction is defined not by defining the amount transferred by referencing the UTXO of the previous transaction in a sequence of past transactions, but by referencing the absolute account balance. The current state of all accounts is stored and constantly updated by a node separate from the blockchain.

[0174] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may include a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 may include multiple blockchain nodes 104 (often called "miners") which can 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 nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0175] Each blockchain node 104 includes the computer equipment of its peers, with different nodes 104 belonging to different peers. Each blockchain node 104 includes processing equipment, including one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of non-temporary computer-readable media or media. Memory may include one or more memory units using one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or EEPROMs; and / or optical media such as optical disc drives.

[0176] Blockchain 150 contains a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the distributed blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, blockchain 150 may be pruned, as long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction refers to a type 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.

[0177] Blockchain node 104 may be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Blockchain node 104 may also be configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Blockchain node 104 may also maintain 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 a “mempool.” This term, as used herein, is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that node 104 accepts as valid and is therefore obligated not to accept any other transactions that node 104 would otherwise attempt to consume the same output.

[0178] In a given current transaction 152j, its (or each of its) inputs include a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "used" in the current transaction 152j. Use or redemption does not necessarily mean the transfer of a financial asset, but it is certainly one general use. More generally, use can be described as consuming an output or allocating it to one or more outputs in another preceding 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 have to exist when the current transaction 152j is created or even when it is sent to network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Therefore, "preceding" here refers not necessarily to the time of creation or transmission in the time sequence, but to the preceding transaction in the logical sequence linked by the pointer, and thus does not necessarily preclude transactions 152i and 152j from being created or transmitted out of order (see the following discussion on orphaned transactions). The preceding transaction 152i may similarly be called the predecessor or precursor transaction.

[0179] Due to the resources involved in transaction verification and publication, each blockchain node 104 typically takes the form of a server, including 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 networked together.

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

[0181] Any given blockchain node may be configured to perform one or more operations among transaction verification, transaction storage, transaction propagation to other peers, and consensus (e.g., proof of work) / mining operations. In some examples, each type of operation is performed by a different node 104; that is, a node may specialize in a particular operation. For example, node 104 may focus on transaction verification and propagation, or on block mining. In some examples, blockchain node 104 may perform several of these operations in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0182] Furthermore, the network 101 is connected to the computer equipment 102 of several parties 103, each acting as a consumer user. These users can interact with the blockchain network 106, but do not participate in transaction verification or block construction. Some of these users or agents 103 can act as senders and receivers of transactions. Other users can interact with the blockchain 150 without necessarily acting as a sender or receiver. For example, some parties may act as storage entities that store copies of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0183] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) can be said to be part of the system, including the blockchain network 106. However, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 can utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (and communicating with) the blockchain nodes 106. For illustrative purposes, two parties 103 and their respective devices 102 are shown: a first party 103a and their respective computer devices 102a, and a second party 103b and their respective computer devices 102b. Much more such parties 103 and their respective computer devices 102 could exist and participate in the system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For purely illustrative purposes, in this specification we will refer to the first party 103a as Alice and the second party 103b as Bob, but we will not be limited to this, and it will be understood that references to Alice or Bob may be replaced with “the first party” and “the second party,” respectively.

[0184] Each computer device 102 of Party 103 includes one or more processors, each processing unit including, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further includes memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium or media. This memory may include one or more memory units using 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 on each computer device 102 of Party 103 stores software including each instance of at least one client application 105 configured to run on the processing unit. It will be understood herein that any action attributed to a given Party 103 may be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 includes 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.

[0185] The client application 105 is first provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium or media, for example, by being downloaded from a server, or by being provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or magnetic tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0186] The client application 105 includes at least a “wallet” function, which has two main functions. One of these is to enable each party 103 to create, approve (e.g., sign) a transaction 152, send it to one or more Bitcoin nodes 104, and then propagate it throughout the network of blockchain nodes 104 so that it can be included in blockchain 150. The other is to report to each party the amount of digital assets they currently own. In an output-based system, this second function includes matching the amount defined in the output of various 152 transactions scattered throughout blockchain 150 that belong to the party in question.

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

[0188] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transaction in which each party 103 is the recipient (or in fact to view the transactions of other parties within the blockchain 150; because, in an embodiment, the blockchain 150 is a public facility that provides trust in transactions, partly through its public visibility). The wallet function on each computer device 102 is configured to form and send transaction 152 according to the transaction protocol. As described 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 throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol corresponds to a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all 152 transactions within blockchain 150. The same node protocol is used by all 104 nodes within network 106.

[0189] An alternative type of transaction protocol operated by several blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In an account-based protocol, each transaction is defined not by referring to the amount transferred by referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored separately from the blockchain and constantly updated by the nodes of that network. In such a system, transactions are ordered using the account's running transaction aggregate (also called "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may also be signed in the transaction. This data field can refer to the previous transaction, for example, if the previous transaction ID is included in the data field.

[0190] Several account-based transaction models share some similarities with the output-based transaction models described herein. For example, as mentioned above, the data fields of an account-based transaction can point to a previous transaction, which is equivalent to the input of an output-based transaction that references the output point of the previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction includes a “recipient” field (where the recipient's address in the account is specified) and a “value” field (where the amount of digital asset may be specified). Both the recipient and value fields are equivalent to the output of an output-based transaction that can be used to allocate a certain amount of digital asset to a blockchain address. Similarly, an account-based transaction has a “signature” field that contains the signature of the transaction. The signature is generated using the sender’s private key and confirms that the sender has approved this transaction. This is equivalent to the input / unlock script of an output-based transaction, which typically includes a signature for the transaction. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction containing a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined by the smart contact's script. A smart contract exists as a transaction on the blockchain and can be invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to an output-based transaction lock script, which can be triggered by a subsequent transaction and checks whether one or more conditions defined by the lock script are met by the input of the subsequent transaction.

[0191] 7. UTXO-based models Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. 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 output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be similarly implemented in other exemplary blockchain networks.

[0192] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unused transaction output (UTXO). The UTXO can be used as a source for the input 202 of another new transaction (if that UTXO has not yet been redeemed). The UTXO contains a value that specifies the amount of digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also include the transaction ID of the transaction in which it occurred, among other information. The transaction data structure may also include a header 201, which may include an indicator of the size of the input fields (one or more) 202 and the output fields (one or more) 203. The header 201 may also include 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.

[0193] For example, suppose Alice 103a wants to create transaction 152j to transfer a certain amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". This retrieves 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 it to Bob. In Figure 2, the preceding transaction 152i is labeled "Tx0". 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 refer to any preceding (i.e., earlier) transaction that still has unused output 203 locked in Alice.

[0194] In this specification, the terms “preceder” and “successor” as used in the context of transaction sequences refer to the order of transactions in a sequence defined by transaction pointers specified in a transaction (such as which transaction points to which other transaction). These can be replaced with “preceder” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily mean the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) that points to a preceder transaction (previous transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that arrives at blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain period of time to wait for its parent, depending on the node protocol and / or node behavior.

[0195] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, hereby labeled UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a lock script, the lock script defining the conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus successfully redeemed for the UTXO.

[0196] A lock script (also known as scriptPubKey) is a piece of 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 blockchain networks. The lock script specifies what information is needed to use transaction output 203, for example, the requirement for Alice's signature. The lock script appears in the transaction output. An unlock script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. The unlock script appears in transaction input 202.

[0197] Therefore, in the illustrated example, the UTXO0 in output 203 of Tx0 is signed by Alice's SigP because the UTXO0 is redeemed (more precisely, because a subsequent transaction attempting to redeem the UTXO0 is valid). A Lock script that requires [ChecksigP A ] includes. [ChecksigP A ] is the public key P from Alice's public key-private key pair. A It includes a representation (i.e., a hash). Input 202 of Tx1 includes a pointer to Tx1 (for example, by its transaction ID, TxID0 (which in this embodiment is a hash of the entire transaction Tx0)). Input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify it among other possible outputs of Tx0. Input 202 of Tx1 includes the lock release script <SigP A >Furthermore, this script contains Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predefined portion of 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, a node protocol, or a combination thereof.

[0198] When a new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol. This involves executing the lock script and unlock script together and checking whether the unlock script satisfies the conditions defined in the lock script (these conditions may include one or more criteria).

[0199] It should be noted that script code is often expressed in general terms (i.e., without using precise terminology). For example, operation codes (opcodes) can 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 a non-consumable output of a transaction that stores data within the transaction and thereby records the data in a way that prevents modification on blockchain 150. For example, the data may include documents that are desired to be stored on the blockchain.

[0200] 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 elliptic curve secp256k1. The digital signature signs specific portions of the data. In some embodiments, for a given transaction, the signature signs portions of the transaction input and portions or all of the transaction output. The specific portions of the output it signs depend 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 signing) which outputs are signed.

[0201] A lock script is sometimes called a "scriptPubKey," a designation referring to the fact that it typically contains the public key of the party whose transaction is being locked. An unlock script is sometimes called a "scriptSig," a designation referring to the fact that it typically provides the corresponding signature. However, more generally, in all applications of Blockchain 150, it is not mandatory for the condition for a UTXO to be redeemed to include signature authentication. More generally, one or more arbitrary conditions can be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0202] 8. Further comments Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein. The scope of this disclosure is not limited by the embodiments described herein, but is limited only by the appended claims.

[0203] For example, some of the embodiments described above have been explained in relation to Bitcoin Network 106, Bitcoin Blockchain 150, and Bitcoin Node 104. However, it will be understood that Bitcoin Blockchain is just one specific example of Blockchain 150, and the above description can be applied in general to any blockchain. That is, the present invention is by no means limited to Bitcoin Blockchain. More generally, the above references to Bitcoin Network 106, Bitcoin Blockchain 150, and Bitcoin Node 104 can be replaced with references to Blockchain Network 106, Blockchain 150, and Blockchain Node 104, respectively. Blockchains, Blockchain Networks, and / or Blockchain Nodes can share some or all of the described characteristics of Bitcoin Blockchain 150, Bitcoin Network 106, and Bitcoin Node 104 as described above.

[0204] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs all of the described functions of creating, publishing, propagating, and storing at least one block 151 of the blockchain 150. This does not preclude the existence of other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (it should be recalled that these entities are not considered nodes of the preferred Bitcoin network 106).

[0205] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, a node may perform at least one or more of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150, but does not exclude performing all of them. For example, in these other blockchain networks, “node” can be used to refer to a network entity configured to create and publish blocks 151, but not to store and / or propagate these blocks 151 to other nodes.

[0206] More generally, the above reference to the term "Bitcoin node" 104 can 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, propagating, and storing blocks. The functionality of such network entities / elements can be implemented in hardware in the same manner as described above with respect to blockchain nodes 104.

[0207] Several embodiments have been described in relation to 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 generally, embodiments can use any type of appropriate consensus mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-time. As a specific example, 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 over a period of time to have the opportunity to become a validator. Generally, the node that locks the largest stake over the longest period of time is most likely to become the next validator.

[0208] It will be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs can be provided according to one or more of the following statements.

[0209] [Statement 1] A computer-implemented method for computing pairings in a script, the method comprising generating a script, the computing of pairings comprising at least one sub-computation performed on a target body, the target body being represented as an extension body, and the script comprising at least one sub-function configured to perform the sub-computation as an extension on the extension body. [Statement 2] The method according to Statement 1, wherein the sub-calculation is either a multiplication operation or a reciprocal calculation operation. [Statement 3] The method according to statement 1 or 2, wherein the target field is a field of Barreto-Lynn-Scott (BLS) family curves of embedding order 12. [Statement 4] Second field Fq 2 The first body F q It is a quadratic extension field with respect to the third field Fq 4 is the second field Fq 2 It is a quadratic extension field with respect to the fourth field Fq 6 is the second field Fq 2 It is a cubic extension field of the fifth field Fq. 12 is the second field Fq 2 The sixth-degree extension field of the above field Fq; the third field Fq 4 A tertiary extension of the field; or the fourth field Fq. 6 A secondary extension of the method described in any one of statements 1 to 3. [Statement 5] The fifth field Fq 12 The method according to statement 4, wherein the target body is the aforementioned target body. [Statement 6] The second field Fq 2 The method according to statement 4 or 5, wherein the form is in twisted form. [Statement 7] The script includes a plurality of subfunctions, and at least one of the plurality of subfunctions is the second field Fq 2 The sixth-degree extension field of the above field Fq; the third field Fq 4 A tertiary extension of the field; and the fourth field Fq 6 A method of statement 4 or any statement subordinate thereto, configured to perform subcalculations in each of the quadratic extensions for each of them. [Statement 8] The method according to Statement 4 or any statement subordinate thereto, wherein the script includes a mirror loop subscript configured to perform a mirror function for a predefined number of inputs, the mirror loop subscript is configured to calculate intermediate values, and the pairing is calculated based on the intermediate values. [Statement 9] The mirror-loop subscript includes at least one sparse vector multiplication subfunction, the at least one vector multiplication subfunction is the third field Fq 4The method of statement 8, which is performed in a tertiary extension of the body. [Statement 10] The method according to statement 9, wherein the at least one vector multiplication subfunction is a sparse vector multiplication subfunction. [Statement 11] The mirror-loop subscript includes at least one point-addition or point-doubling subfunction, and the point-addition or point-doubling subfunction is the second field Fq 2 The method described in any one of statements 8 to 10, as performed in [location]. [Statement 12] The mirror loop subscript includes at least one linear subfunction, and the at least one linear function is the third field Fq 4 The method described in any one of statements 8 to 11, which is performed in a tertiary extension of [the subject]. [Statement 13] The script includes a power subscript configured to verify that the received candidate inverse median is equal to the target inverse median, and the power subscript verifies the fourth field Fq 6 A method of statement 4 or any statement dependent thereon, comprising a set of subfunctions performed in a quadratic extension field with respect to . [Statement 14] The power subscript receives the intermediate value calculated by the mirror loop subscript as input, and the intermediate value is the third field Fq 4 The elements in the cubic extension field of the third field Fq are: the intermediate value of the third field Fq 4 From the elements in the cubic extension field, the aforementioned fourth field Fq 6 The method of Statement 13 when citing Statement 8, which is configured to convert into elements in a quadratic extension for . [Statement 15] The method according to statement 13 or 14, wherein the exponentiation subscript includes a conjugate subfunction configured to compute the reciprocal of the unit element in the target body. [Statement 16] The exponentiation subscript includes at least one constant exponentiation subfunction configured to raise the unit element to a constant power via a Frobenius autohomomorphism, wherein the constant exponentiation subfunction is the second field Fq 2 The method described in any one of statements 13 to 15, configured to perform multiple multiplications on the above. [Statement 17] A computer-implemented method for calculating pairings, the method comprising generating a script configured to perform the method according to any one of claims 1 to 16. [Statement 18] The method according to Statement 17, wherein the script is a blockchain script, and the method further comprises: a step of generating a challenge blockchain transaction, the challenge blockchain transaction comprising a first lock script which includes the script; and a step of making the challenge blockchain transaction available to one or more nodes of the blockchain network. [Statement 19] Computer equipment comprising a memory including one or more memory units and a processing unit including one or more processing units, wherein the memory stores code configured to be executed by the processing unit, and the code is configured to perform the method described in any one of statements 1 to 18 when on the processing unit. [Statement 20] A computer program that is embodied on a computer-readable storage device and configured to perform the method described in any one of statements 1 through 18 when executed on one or more processors.

Claims

1. A computer-implemented method for computing pairings in a script, the method comprising generating a script, the computing of pairings comprising at least one sub-computation performed on a target body, the target body being represented as an extension body, and the script comprising at least one sub-function configured to perform the sub-computation as an extension on the extension body.

2. The aforementioned subcalculation is: Multiplication operation; and Reciprocal calculation The method according to claim 1, which is one of the two.

3. The method according to claim 1, wherein the target body is a field of Barreto-Lynn-Scott (BLS) family curves of embedding order 12.

4. Second field Fq 2 is the first body F q It is a quadratic extension field with respect to the third field Fq 4 is the second field Fq 2 It is a quadratic extension field with respect to the fourth field Fq 6 is the second field Fq 2 It is a cubic extension field of the fifth field Fq. 12 but: The second field Fq 2 A sixth-degree extension of a field; the third body Fq 4 a cubic extension body for; or The fourth field Fq 6 It is a quadratic extension field for, The method according to claim 1.

5. The fifth field Fq 12 The method according to claim 4, wherein the target body is the object.

6. The second field Fq 2 The method according to claim 4, wherein is a twisted body.

7. The script includes multiple subfunctions, and at least one of the subfunctions is: The second field Fq 2 A sixth-degree extension of a field; The third field Fq 4 A tertiary extension of; and The fourth field Fq 6 Secondary extension field for The method according to claim 4, wherein each of the is configured to perform a sub-calculation.

8. The method according to claim 4, wherein the script includes a mirror loop subscript configured to perform a mirror function for a predefined number of inputs, the mirror loop subscript configured to calculate intermediate values, and the pairing is calculated based on the intermediate values.

9. The mirror loop subscript includes at least one sparse vector multiplication subfunction, the at least one vector multiplication subfunction is the third field Fq 4 The method according to claim 8, which is performed in a tertiary extension of the body.

10. The method according to claim 9, wherein the at least one vector multiplication subfunction is a sparse vector multiplication subfunction.

11. The mirror loop subscript includes at least one point addition or point doubling subfunction, and the point addition or point doubling subfunction is the second field Fq 2 The method according to claim 8, as performed in [location].

12. The mirror loop subscript includes at least one linear subfunction, and the at least one linear function is the third field Fq 4 The method according to claim 8, which is performed in a tertiary extension of the body.

13. The script includes a power subscript configured to verify that the received candidate inverse median is equal to the target inverse median, and the power subscript verifies the fourth field Fq 6 The method according to claim 4, comprising a set of subfunctions performed in a quadratic extension field with respect to .

14. The script includes a power subscript configured to verify that the received candidate inverse median is equal to the target inverse median, and the power subscript verifies the fourth field Fq 6 It includes a set of subfunctions that are performed in the quadratic extension field for , The power subscript receives the intermediate value calculated by the mirror loop subscript as input, and the intermediate value is the third field Fq 4 The elements in the cubic extension of are: The aforementioned intermediate value is the third body Fq 4 From the elements in the cubic extension field, the aforementioned fourth field Fq 6 It is configured to transform into an element in a quadratic extension field for the given object. The method according to claim 8.

15. The method according to claim 13, wherein the exponentiation subscript includes a conjugate subfunction configured to calculate the reciprocal of the unit element in the target body.

16. The exponentiation subscript includes at least one constant exponentiation subfunction configured to raise the unit element to a constant power via a Frobenius autohomomorphism, wherein the constant exponentiation subfunction is the second field Fq 2 The method according to claim 13, configured to perform multiple multiplications on the above.

17. A computer-implemented method for calculating pairings, the method comprising generating a script configured to perform the method according to any one of claims 1 to 16.

18. The aforementioned script is a blockchain script, and the method further: A step of generating a challenge blockchain transaction, wherein the challenge blockchain transaction includes a first lock script which includes the script; The steps include making the aforementioned challenge blockchain transaction available to one or more nodes of the blockchain network. The method according to claim 17.

19. Memory including one or more memory units; A processing apparatus including one or more processing units A computer device comprising: a memory storing code configured to be executed on the processing device, and the code configured to execute the method according to claim 1 when on the processing device.

20. A computer program that is implemented on a computer-readable storage device and configured to perform the method described in claim 1 when executed on one or more processors.

Images