Bilinear pairings

Abstract

A computer-implemented method for generating an elliptic curve pairing is provided. An intermediate value, derived based on an initial value provide by a provider, is obtained. A candidate inverse intermediate value is received from the provider. It is determined if the candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the target inverse intermediate value is an inverse of the intermediate value. If the candidate inverse intermediate value is equal to the target inverse intermediate value, the pairing is computed based on the intermediate value and the candidate inverse intermediate value. The goal is an elliptic curve pairing calculation using a short script.

Description

TECHNICAL FIELD The present disclosure relates to a computer-implemented method for generating a pairing, a method for generating a blockchain transaction for computing a pairing, and a method for satisfying a challenge which is satisfied based on a pairing. BACKGROUND Pairings over elliptic curves span a large number of cryptographic applications. For example, with pairings it is possible to construct signatures, identity-based encryption, non-interactive zero-knowledge proofs, and communication-efficient multi-party key agreement. A pairing e is a bilinear map defined over two group source elements G1; G2 in a torsion group £(1^)1 / ]. It maps a pair of elements to an element in a target group GT ■= F*fc: e:    X G2 -* Gf. SUMMARY Efficiently implementing a pairing in script is not trivial. Methods known in the art require script sizes of around 1.5MB. Provided herein are methods for improving the computational efficiency of a pairing computation, and thereby optimising a resultant pairing script. When computing a pairing, an inverse of an intermediate value is required. Inverting field elements is the most expensive arithmetic operation in the pairing calculation. To reduce the size of the script, and therefore reduce the computational requirements when computing the pairing, a method is provided herein in which a candidate inverse intermediate value is provided, and a check carried out to determine if it is the inverse of the intermediate value. If it is, the candidate inverse intermediate value can be used in the pairing computation. The script for implementing the check on the candidate inverse intermediate value is much smaller in size than the script for inverting a field element. According to one aspect disclosed herein, there is provided a computer-implemented method for generating a pairing, the method comprising: obtaining an intermediate value derived based on an initial value provide by a provider; receiving, from the provider, a candidate inverse intermediate value; determining if the candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the target inverse intermediate value is an inverse of the intermediate value; and if the candidate inverse intermediate value is equal to the target inverse intermediate value, computing the pairing based on the intermediate value and the candidate inverse intermediate value. BRIEF DESCRIPTION OF THE DRAWINGS To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which: Figure 1 is a schematic block diagram of a system for implementing a blockchain, Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain, Figure 3 illustrates point addition and point doubling in an elliptic curve, Figure 4 schematically illustrates a conceptual division of scripts for computing a pairing, Figure 5 schematically illustrates dependencies of scripts implemented extension field arithmetic, and Figure 6 schematically illustrates relationships of scripts for implementing a Miller loop for computing a sing pairing or a multi-pairing. DETAILED DESCRIPTION OF EMBODIMENTS 1. ELIPTICAL CURVES AND PAIRINGS 1.1 Elliptic Curves Let a cubic equation y2 = x3 + ax + b where the coefficients a, b are taken from a finite field of q elements. An elliptic curve is the set of affine points P ■= (x,y) that satisfy the above equation along with an extra point at infinity denoted with 0: ElFq := {P ■= (x,y) | y2 = x3 + ax + b] U {(9}. F„ is the field of definition of the curve, that is, a, b G F„, and E is over F„. The coordinates x,y of points P 6 £”|Fq do not necessarily lie in Fq, they can be defined over an extension field F k (of qk elements). Notation. The notation El Fq: y2 = x3 + ax + b means an elliptic curve over Fq with equation y2 — x3 + ax + b. E ■ y2 = x3 + ax + b is written if the field of definition is understood from context but there is a want to stress which is the cubic equation. E can be written if both the field of definition and the equation are understood from context; it denotes all points in the elliptic curve (that is, points P ■= (x,y) with coordinates x,y in any possible extension field). E(Fq) denotes the set of points whose coordinates are in Fq. Likewise, E(F k) denotes the set of points with coordinates in the extension F k. 1.1.1 Adding and Doubling Points in Affine Coordinates An elliptic curve E forms a group under the 'tangent and chord' rule. This addition rule makes E a group with identity element the point at infinity (9. Figure 3 illustrates group law in elliptic curve. The left-hand graph illustrates point addition, while the right-hand graph illustrates point doubling. To add two points P Q the line £P Q passing through P, Q and the vertical line vR passing through the intersection point with E that is not P or Q (i.e., —R in Figure 3, left) are needed. Likewise, to double a point P, the tangent line £PP of E at P and the vertical line vR passing through the other intersection point with E (-R in Figure 3, right) are needed. The 5 formulas are given below, with the left-had formulas corresponding to point addition for P Q, and the right-hand formulas corresponding to point doubling for P + P ■= 2P . A _ yP - xP xq — Xp If P Q then P + Q := (xR,yR) have coordinates: ,2          (yp-xP\ Xr := A— Xp — Xq = 1 ------- 1 — Xp — Xq \Xq      / yR := A(xP - Xr) - yP yp- xP ■= _v (Xp Xr) yP Xq Xp 3x1 A:= — 2yP P + P := (xR,yR) have coordinates: □        yp~xP\ xR := A2 — 2xP = I-------) — 2xP \Xq    P J yR := A(xP - Xr) - yP yp- xP ■= _v (Xp Xr) yP Xq Xp Note 1. As is shown in section 1.8, the line gP Q passing through P Q, the tangent line 10 gP P at P, and the vertical line vR at R play an important role in the definition of a pairing. The formulas are given in the table below, which provide the evaluation of 'tangent-and-chord' lines at an arbitrary point S of E in affine coordinates. Evaluation of line gP Q passing through P ■= (xp,yp) Q := (xq^q) at point S = (x,y): 9p.q (x, y) := y - (Ax + yP - AxP) := y - yP-xP xq — xp yP-xP yp-- Xq — Xp Evaluation of tangent line gPP(S} at points := (x,y) 3xp (3xP        3xP gp,p(.x,y) := y — (Ax + yP - AxP) := y - -—x + yP - -—xP \2yP        2yP Evaluation of vertical line passing through P at point S := (x, y) vP y) := x — xP 1.1.2 Multiplying Points by a Scalar Let any integer m G Z and a point P, the scalar multiplication [m]P is defined by adding m times P to itself (or adding — P in case m is negative.) [m]P := P + —I- P. m times 1.2 Projective Coordinates Point addition as described in the above section requires inverting field elements (either xQ — xP or 2yP) to compute the scalar A. Inverting is an expensive operation and therefore it is desirable to avoid it. This can be achieved switching to projective coordinates. The X Y change of coordinates x = -,y = - allows for working with points? := (X,Y,Z) and rewriting the formulas for elliptic curve arithmetic of Figure 3 without inverting field elements. 1.3 The torsion Group £Tr1 and the Embedding Degree Let n = #E be the order (size) of the elliptic curve. Then, it holds that [n]P = 0 for every P G E. However, points may vanish for smaller scalars. For any divisor r of n, the r-torsion group is the set of points of order r: E[r] := {P G E | [r]P = 0}. The r-torsion also forms a group. It is therefore a subgroup of E. The structure of the r-torsion group is well known. If r is prime to q, then Efr] = x Zr. This means that #E[r] = r2 and it has r + 1 cyclic subgroups of order r. 1.3.1 The Embedding Degree of a Curve E Recall from Section 1.1 that (the coordinates of) points of an elliptic curve E lie in an extension field Ft of the field of definition Fo. This also means that torsion points might Q                                   4 are in an extension field. The embedding degree k tells where the entire torsion group E[r] lies. The following two equivalent conditions define k: • k is the smallest positive integer such that r divides qk — 1. • k is the smallest positive integer such that E[r] c E(F k). Cleary, by definition, the embedding degree depends on q and r. Thus, for any choice of q,r the corresponding embedding degree is k(q,r). 1.3.2 Two Subgroups of E|r] Pairings over E can be defined over any two subgroups of E[r], For efficiency reasons, type-3 pairings (see Section 1.5.1) are defined over the following two subgroups of the r-torsion. 1.3.3 The Base-Field Group G1 < E[r] This is the only subgroup of E[r] that lies entirely in E(Fq). The base-field group Gx is defined as the r-torsion elements in the eigenspace of the Frobenius map n\ E -> E, (x, y) ■-> (x^y^). Thus: Gx := E(Fqk)[r] n ker (n - [1]). Since tt fixes a point P G E(F k), namely P = n^P), if and only if P 6 E(Fq), then Gx = E(Fq)[r]. This group is sometimes called the group of rational points of order r. Note 2. What is important to remember is that coordinates of points in Gx are always in Fq, and hence elliptic-curve arithmetic in G-Js as efficient as possible. 1.3.4 The Zero-Trace Group G? < E[r] This is a subgroup of E[r] with an important property. Any point of the torsion group can be mapped to a point in £2. That is, there exists an explicit (computable) homomorphism aTr, such that for all P E E[r], aTr(P) G G2. The trace map is defined as Tr(P) := 2.1=0 (xql,ywhere P ■= (x,y). The trace map actually maps any point in E into E(Fq). The zero-trace elements are points that are mapped to 0. Thus, G2 is the eigenspace: G2 := £"(Fqfc)[r] A ker (Tr - [q]). The aTr map mentioned above is the anti-trace map defined as aTr(P) := [k]P — Tr^P). It holds that Tr^aTr^P)^ = 0, and therefore aTr maps points to G2. Note 3. Performing arithmetic in G2 is expensive because points P, Q G G2 have coordinates in F„k. It is not essential to work with Ft directly, but instead with a smaller 1 /                                                                                       1 / field Wnk / d using the twist of the curve (see Section 1.4.) 1.4 Twisted Curves Let a curve E / Wq\ y2 = x3 + ax + b. The twist E' is given by the equation: E'\ Wqk / d: y2 = x3 + aa)4 + bw6, for some G Ft. Note that E' is defined over Wnk / d, where d is the degree of the twist. 1 /                                                                                 1 / x' y' Both curves are isomorphic through E' E given by TCx^y') := (“,“)■ the possibilities d G {2,3,4,6} is defined as follows: • Quadratic twists, d = 2. They are available for any curve. E: y2 = x3 + ax + b. Thus, for any a, b G F?. • Cubic twists d = 3. They are available for curves E\y2 = x3 + b. Thus a = 0. • Quartic twists, d = 4. They are available for curves E:y2 = x3 + ax. Thus b = 0. • Sextic twists d = 6. They are available f or curves E: y2 = x3 + b. Thus a = 0. An important fact that will be used in the context of pairings is that the preimage under 47 of the zero-trace group G2 in FIF k is the base-field group G^ in the twist EJ Fqk / d. That is, arithmetic in G2 can be done instead in its twist G^ and then the result mapped back to G2. Note 4. Recall from Section 1.3 that arithmetic in G2 is expensive. What is important to remember is that if P + Q for P, Q G G2 needs to be computed, R' ■= ^-1^) + 47-1(Q) can be computed and then use — P + Q whenever is needed in the Miller loop of the pairing computation (see Section 1.6). This improves efficiency because 47-1 (P), 47-1 (Q) G Gi have coordinates in Fnk / d (instead of in the larger F„k). A further improvement can be provided by avoiding the map 47-1 by implicitly replacing G2 with its twist G^ when defining the domain of a pairing, perform point addition (or point doubling) with points P', Q' G G\, and then map the result to G2 via 47 whenever the result is needed. Computing 47 only requires two multiplications. 1.5 Pairings A pairing e is a bilinear map defined over two group source elements G1; G2 in the torsion group ^(Fpfc)^]. It maps a pair of elements to an element in the target group GT := F*fc: e: G-, X G2 —> Gr, such that: 1. For each (^,^) G Gx x G2 and each (a, h) G Z2: e(a-gltb-g2) = e{g1,g2)ab. 2. If (^1-^2) is a generator of Gx x G2 then e(g\,g2) is a generator of GT. 3. The pairing is efficiently computable. 1.5.1 Types of Pairings Depending on how the source groups G1; G2 are chosen there are three types of pairings. Type 1. The symmetric pairing: = G2 := / ^F^fr], thus the base-field group (see Section 1.3). The curve must be supersingular, meaning there exists a distortion map 0 that takes points in ^(F^) into F(F k). It is known how to hash into         and sample random elements. All known pairings (see Section 1.3) require P and Q in different groups, so the pairing is defined as e(P, Q) ■= e(P, $>(&)). The drawback is that the condition E being supersingular hinders the efficiency of the pairing. Type 2.    := (Fq)[r], the base-field group and G2 Gp In this setting the existence of an isomorphism from G2 on is required, namely the trace map tr (see Section 1.3). This means that G2 cannot be the zero-trace group (because it is mapped to the identity element 0 via tr). The drawback is that it is not clear how to hash or sample random elements in G2, which restricts functionality. One benefit is that proving security is possible due to the efficient isomorphism tr. Type 3.    := (Fq)[r], the base-field group and G2 := <p-1(£'(F( / k)[r] 0 ker(Tr — [q])), the preimage of the zero-trace group under the twist cp. There is not known (efficient) isomorphism from G2 on G-p which affects security, but in this setting, it is clear how to hash and sample random elements in G2 (using the anti-trace map aTr). Note 5. Nowadays, type 3 pairing is the one that is studied the most because it is more efficient than type 1 and gives more functionality than type 2. Therefore, type 3 pairings are used herein for Script implementation in Section 3. 1.6 Weil, Tate, and Optimal Ate Pairings In layman words, pairing two points P, Q consists in constructing a function fnP related to P and then evaluate it at point Q. The selected fiP is a Miller function and it is defined as: := n(P) - ([n]P) -(n- 1)(9. The above formula says that a Miller function fnP has a zero at P with multiplicity n, a pole at [n]P, and a pole at (9 with multiplicity n — 1. The original pairing is due to Weil. Since then, several flavours have been proposed, with the optimal ate pairing the most efficient one. The different pairings can be defined succinctly as follows: Weil pairing: w(P,Q) := (-l)Vr,p(Q) / / r,<?(?)■ Tate pairing: t(P, Q) := fr,p{QYqk~^ / r ■ Optimal Ate pairing: aopt(P, Q) :=    (p')^-1) / 7'^ for some such that log(r) « log (» / <?■ • The Weil and Tate pairing require finding a function fr P, which roughly has a degree of r, the order of the groups Gp G2, GT. For cryptographic applications, r is large, say 256 bits or more, and hence computing a function of degree « 2256 is a huge task. In Section 1.7, it is shown how to compute this efficiently (i.e. in « log (r) steps). • The Weil pairing is typically not used because it requires computing two Miller functions (evaluated at P and at Q). The Tate pairing and the optimal Ate pairing require just one function evaluation (at P). • The optimal Ate pairing requires a Miller function of much lower degree £ than the Tate pairing, and hence is more efficient to compute than the Tate pairing. For this reason, all known implementations use the optimal Ate pairing, as is also done herein. However, observe that the exponentiation to (qk — 1) / r does not change and the Miller function depends on Q (instead of P). In the type 3 setting, Q is a point in the twist of the zero-trace group, hence with coordinates in Wnk / d. 1.7 Pairing-Friendly Curves An elliptic curve has parameters q, t, r, k: • q: A prime integer. The size of the underlying field Fq. • r : The size of the three groups G1( G2, GT • k the embedding degree • t: The trace of Frobenius. (Needed for the optimal ate pairing only) As the pairing entails performing arithmetic in Ft, an elliptic curve is 'pairing-friendly' if the embedding degree k is not too large. Typically, k = 6,12,24. For cryptographic applications, it must be difficult to compute the elliptic-curve discrete logarithm (ECDLP) in the source groups G-p G2             of order r and the discrete logarithm problem (DLP) in the target group, namely the r-roots of unity pr < F*k for the optimal ate pairing. This imposes a trade-off between the size of q and the size of r, The DLP in F*fc is easier than ECDLP and the groups sizes are chosen accordingly to resist (EC)DLP solvers in all groups. The ratio between the size of F*fc and G£ is log(q^) _ klogQq) _ , log(r) log(r) The concrete value of this ratio is determined by the progress on solving these two problems. The parameter p measures how efficient arithmetic in the elliptic curve is. Ideally, one wants p = 1. Note 6. Larger values of p means working with a larger Fq. The focus herein is to minimize the number of instructions and not CPU cycles in the pairing computation. Thus, larger p are not necessarily a bad choice. Put differently, pairings over non-optimal curves might render scripts of smaller sizes. The embedding degree and the degree of the twist seem more important parameters in our context. 1.7.1 Parameterized Families The values of q,r, t are parameterized as polynomials q(u),r(u), t(u). For a concrete value of it G Z, values q, r,t are obtained. Depending on the shape of the polynomials, there are different families. The most famous families are BN, BLS12, BLS24 and KSS, although other families are possible. To achieve 128 bit of security BLS12 is preferred over BN given latest advances on solving DLP. Thus, the script implementation provided herein is based over this curve. BLS12 being a family, between BLS12-381 and BLS12-440. The former being more efficient but could suffer from improvements in solving DLP. The latter is less efficient (relatively, still type 3, see Note 5 above), but considered more secure: it seems unlikely that improvements in solving DLP will be seen in the near future to decrease its security below 128 bits. The table below describes the BLS12 curve family. BLS12 family: k = 12, p « 1.5 (u — l)2(u4 — u2 + 1) q(u) =-------------------+ u, t(u) = u + 1 r(u) = u4 — u2 + 1, Table 1: Parametrisation ofBLS12 curves. 1.8 Miller Algorithm Recall from Section 1.6 that the optimal Ate pairing requires two steps, or functions. First compute f := fe^fP), then exponentiate / C^-1) / / f can be computed iteratively using the formulas: / 0 = 1 e 5 9[i]Q,Q V[i + 1]Q fi + l,Q fi,Q Vpi]Q Above, fj P is the Miller function, gP Q is the line passing through points P, Q and vP the vertical line at P. Miller observed that the above gives raise to 'double-and-add' algorithm 10 to compute fr Q in roughly log (r) steps. To avoid storing fr Q (which is a function of degree r), the intermediate functions fiQ are evaluated at (the fixed) point P iteratively too. Optimal Ate pairing over BLS curve Input: Q e G2>P e curve parameter u Steps: 1. f := 1 2. T ■= Q 3. For i := [log(u)J — 1 down to 0 do: 4.    f := f2 5-    f := f ' 9w(7">,w(r)(.P) 6.    T := [2]T 7.     If U; = 1 then: 8- f := f ’ 9w(t),w(q)(P) 9. T := T + Q 10. f := f 11. Return / Table 2: Optimal Ate pairing in BLS. Point Q e E / IF^ / c / d), P e E (Fq), and f e IF* V is the twist 'P-. E’ -> E. EC arithmetic is done in the twist E'(JF k / d). .Computing line evaluations and f is done in IF^ / c. 15 Thus, Miller algorithm accumulates f^Q^P) iteratively using the above formulas in a 'double-qk — 1 and-add' style, and after that exponentiates f ■= f^CP), to which is the result of the pairing, as shown in the table above. Note 7. An important optimization that is incorporated is the so-called 'denominator elimination'. It is not necessary to compute the evaluation of the vertical lines V[i+1^Q, V[2i]Q, as those terms will be mapped to 1 in the final exponentiation step. This optimization is only available to the Tate pairing and its variants in the type 3 setting, but not for the Weil pairing, because it uses the twisted curve and the final exponentiation step. 2. BLS12- FAMILY IMPLEMENTATION DETAILS BLS12 has embedding degree k = 12, and the curve has equation: E : y2 = x3 + b, with b = 4. Recall from Table 1 that parameters q, r are derived accordingly to the BLS12-381 polynomials and curve parameter: u = -263 - 262 - 260 - 257 - 248 - 216. Since a = 0 it admits a sextic twist E' (see Section 2.4) with equation: E'-y2 =x3 +b'. Here b' = b / l, where is a non-square, non-cube element of Fq2. Assuming p = 3 mod 8, := 1 + V^T . 2.1 Fields Representation The underlying field of the target group (F 12) is represented with three different towers of extension fields. Representation 1 (Quadratic extension) Fq2 = FqM / Cu2 + 1) fly = ^^1 / (^-0 Fqi2 = F^efw] / ^2 — v) In this representation, elements in Fqi2 are given as a pair of elements in Fq6 (which are triplets of Fq2 elements). Representation 2 (Sextic extension) F,2 = F,[u] / (u2 + 1) F,>2 =F,2[t] / (t6-f) Here elements in F„i2 are given as a vector of six elements in F„2. *7                                                                                                             *7 Representation 3 (Cubic extension) Fq2 = FqM / Cu2 + 1) F^2 =^M / (r3-s) In this last representation elements in F 12 are given as a triplet of elements in Fq4 (which are pairs of Fq2 elements). Herein, F„ may be referred to as a first filed, F„2 a second field, F„4 a third field, F„6 a fourth field, and F„i2 fifth field. The fifth field F„i2 is the target field. 2.1.1 Why Three Representations In Fqi2, only the multiplication and inversion of elements is needed (the latter only for the easy part of the final exponentiation in the pairing computation). There exist well-known efficient algorithms for inversion over quadratic and cubic extensions. This means the first representation can be used, wherein Fqi2 is a quadratic extension over Fq6 (and Fq6 is a cubic extension over Fq2, and Fq2 is a quadratic extension over Fq). That is, arithmetic in Fq2 and in Fq6 is needed. Namely, addition subtraction, multiplication, negation, and inversion. Further, in this representation inversion of unitary Fqi2 elements a + bw (that arise during the computation of the second part of the final exponentiation) can be computed by simple conjugation (a + bw)-1 ■= (a — bw). The second representation (Fqi2 as a sextic extension over Fq2), is useful to exponentiate to powers of q using the Frobenius operator (for the final exponentiation). Frobenius is significantly more efficient than the standard square-and-multiply algorithm for q powers, requiring only 5 multiplications (with precomputations). The third representation (F 12 as a cubic extension over Fq4 ), will be used to perform multiplication in Fqi2 in the Miller loop. The reason is that the result of the line functions can be represented very sparsely in the third representation. This fact can be used to split the Miller loop into two subroutines that exploit the sparsity in the prescribed multiplications within the loop. The varieties of sparse multiplications in Fqi2 can be distinguished using this. Based on the above remarks, the arithmetic formulas are specified in the following sections. They will serve as the codebase for the scripts detailed in Section 3. 2.1.2 Switching Between Representations Switching between the first representation (quadratic extension) and the second one (sextic extension) will be used implicitly in exponentiations via Frobenius (see Section2.8). The output of the Miller loop (the f element) is also switched from the first representation to the third one (cubic extension) before entering the final exponentiation. Fq2 elements are pairs of Fq elements. Ultimately, Fqi2 elements are always vectors of six Fq2 coefficients, but depending on the representation the rules governing the arithmetic are different. Switching representations just moves around the coefficients of a given element in Fqi2. The table below provides the precise permutation of the coefficients to switch among representations. Switching between the three representations Quadratic: X := ((a, b, c),         G Fq6[w] / (w2 — v) Sextic: X := (a, d, b, e, c, f) G Fq2 [t] / (t6 — £ ) Cubic: X := ((a, e), (d, c), (b, f)) G Fq4 [r] / (r3 — s ) Table 3: Switching between representations of Fqi2 by moving around the Fq2 -coefficients a,b,c,d,e,f. Example. The switch between quadratic and sextic extension representations can be derived as set out below. Let X = x± + x2w be an element of the quadratic extension Fqi2 = Fq6 [w] / (w2 — v). The coefficients are elements in Fq6 := F£?e[w] / (w2 — v), and can be written as: x± := a + bv + cv2 x2 ■= d + ev + dv2 where a, b, c, d,e,f 6 Fq2. Using that t = w and v = t2, X can be expressed in the sextic extension Fqi2 := F£?2[t] / (t6 — £) by just switching around the F^-coefficients: X := x0 + xtw = x0 + x}t = (a + bv + cv2) + (d + ev + fv2)t = a + dt + bt2 + et3 + ct4 + ft5 2.2 Arithmetic in F72 - The Twisted Curve Elements in Fq2 are polynomials X of degree one modulo u2 + 1. X can be identified with its two Fq-coefficients X ■= (x0, x^. Fq2 := {X := Xo + X±U | XO'X1 e Fq, U2 = —1}. Addition, subtraction, and scalar multiplication in Fq2 are defined in the natural way. Thus, addition and subtraction is component-wise, and scalar multiplication multiplies each component by the scalar A 6 F 2. All operations are done modulo q. Add in F?2 Input: X := (x^xj,? := (y0,yi) Output: X + Y := (x0 + y0,x1 + yj Negate in F?2 Input: X := (x0,xf) Output: —X: = (—x0 , —x^ Subtract in F?2 Input: X := (Xo.xJ.Y := (y0,yi) Output: X — Y := (x0 — y0,x1 — y,) Multiply by scalar in F?2 Input: X := (xQ,xA), A Output: AX: = (Ax^Ax^ Table 4: Addition, subtraction, and negation in Fq2 := Wq[u] / (u2 + 1 ). ). Here Xi,yi,A £ Fq and arithmetic is modulo q. Multiplication of elements in Fq2 := Fq [it] / (it2 + 1) is defined in the table 5 below. Squaring and multiplication by f := it + 1 as separate routines are also described. Multiply in F?2 Input: X := (x0,xJ,Y := (y0,yi) Output: X • Y := (xoyo — x^, xoy1 + xiyj Square in F?2 Input: X := (xQ,xA) Output: X2 ■= (xq — x2 , 2X0X-J Multiply by / := 1 + u in Fg2 Input: X := (xq.Xt) Output: X • ( := (x0 — 1, Xg+Xi) Invert in F?2 Input: X := (xq.Xt) Output: X’1 :=   (x0 , —x-J 1. d0 := Xo 2.     := x2 3. a0 := a0 + ar / / Always nonzero 4. ar := Qq 1 / / Inversion in Fq Table 5: Multiplication, squaring, and inversion of elements in Fq2 := Fq [u] / (u2 + 1 ). Here x^y^ £ Fq and arithmetic is modulo q. Also, cy (x0 , —xx) is multiplication by scalar in Fq2 (see table 4, bottom right). 2.3 Arithmetic in Fg4 Elements in Fq4 = Fq2 [s] / (s2 — f) are polynomials X of degree 1 modulo s2 — := {X := x0 + XiS G F^, s2 = O X is identified with its two Fq2-coefficients X :=         Thus, xt G Fq2. The formulas for arithmetic in Fn4 in terms of F„2 arithmetic are given in the table below. Subtraction, negation, and inverse in Fq4 are omitted as these are not needed for computing a pairing. Multiply in F?4 Input: X :=         := GWi) Output: X • Y := (z0, z^ • zQ := xQ • y0 +    • y± • £ • Zi := x0 • yi + %i • y0 Square in F?4 Input: X := (^0,¾) Output: X2 := (%o — x2 , 2x0 • x^ Multiply by scalar in F?4 Input: X := (xo,^), A Output: AX: = (A • x0, A • x-J Multiply by s in F?4 Input: X := (^0,¾) Output: X • s := (¾ • x0) Add in F?4 Input: X := (x0,%i), Y := (y0,yi) Output: X + Y: = (x0 + y0,   + Table 6: Arithmetic in Fq4 := JFQz [s] / (s2 — ¢). Here Xi.yi.A are in Fq2. See Section 2.2 for arithmetic in Fq2. Also, x ■ ( is multiplication by f (see table 5, bottom left). 2.4 Arithmetic in Fg6 Elements in Fq6 = F^fvl / Cv3 — f) are polynomials X of degree 2 modulo v3 — Fq6 := {X := Xo + X±V + X2V2 \xt G Fq2, V6 = (} X can be identified with its three Fq2-coefficients X := (x0, ^,^)-The formulas for arithmetic in Fne in terms of F„2 arithmetic are given in table 7 and table 8. 4                  4 Add in F?b Input: X := (x0,Xi,%2)^ := (yo-Ti-^) Output: X + Y := (x0 + y0,   + y1; x2 + Negate in F?& Input: X := (x0,Xi,x2) Output: —X: = (—x0, —x1; —x2) Subtract in F?b Input: X := (x0,:= ^0^1^2) Output: X - Y := (x0 — y0,   — ylr x2 — Multiply by scalar in F?& Input: X := (x^x-J, A Output: X- X\ = (A • x0,A • xt) Table 7: Addition, subtraction, and negation in Fq6 := Fq2 [v] / (v3 — Here x^y^A G Fq2. See Section 2.2 for the arithmetic in Fq2. Multiply in F?& Input: X := (x0,          := (y0,yi,y2) Output: X ■ Y := (z^z-p^) •  z0 := x0 • y0 + (¾ • y2 + *2 • yi) • C •   Zi := x0 •   + Xi • y0 + x2 • y2 • £ •   z2 := x0 • y2 + Xi •   + x2 • y0 • Square in F?& Input: X := (x0,*i,*2) Output: X2 := (^,^,¾) • Z0 := Xq +2xr-x2-^ • Zx := 2x0 • Xt + X2 • • Z2 := 2x0 • X2 + X^ Multiply by v in F^b Input: X := (¾¾¾) Output: X ■ v := (x2 • ^,^0,¾) Invert in F^b Input: X := (¾¾¾) Output: X-1 := (z^z^Z;,) 1. a := Xq — x± • x2 • 2. b := xl • - x0 • Xi 3. C := X2 — Xo • X2 4. d := x± • • c + x0 • a + x2 • • b 5. e := d-1 / / Inversion in FQ2 • Zq •— Cl • 6 •      := b • e • z0 := c • e Table 8: Multiplication, squaring, and inversion of elements in Fq6 := Fq2 [v] / (v3 — f). Here Xi,y,, a, b, c.f,^ G Fq2. See Section 2.2 for the arithmetic in Fq2. Also, x ■ f is multiplication by f (see Table 5, bottom left). 2.5 Arithmetic in Fqi2 - The Target Field In the target filed, vectors have 12 components. Herein, a sparse vector is considered to have at least 6 elements set to zero, while a some-what spare vector has at least 2 elements set to zero. 2.5.1 Multiplication as a Quadratic Extension In the final exponentiation of the pairing, Fqi2 is given as a quadratic extension over Fq6. Namely, Fqi2 = Fq6 [w] / (w2 — v). In this representation, elements are polynomials X of 5 degree 1 modulo w2 — v with coefficients in Fq6 := Fq2 [v] / (v3 — ^). Thus: Fqi2 := {X := XQ + X±W \xt 6 F^e, W2 = v}. X is identified with its two F^-coefficients X := (x^x^. Recall that x(- is a vector of three Fq2 elements, x0 := (a,b, c) and x± := (d, e, / ). Thus, X is a vector of six Fq2 10 coefficient, seen as a pair of triplets: X := (x0, x-J := ((a, b, c), (d, e, / )). The formulas for multiplication, squaring and inversion in Fqi2 in terms of Fq6 arithmetic are given in Table 9. Inversion of unitary elements is done via conjugation, which is very 15 efficient. This is an advantage of representing Fqi2 as a quadratic extension in the final exponentiation. Multiply in F?i2 Input: X := (Xo,^),? := (y0,yi) Output: X • Y := (x0 • y0 - Xi • y1; x0 • y1 + x1 • y0) Square in Fqiz Input: X := (x^xj Output: X2 := (Xq — x2 , 2x0 • xt) Invert in F?i2 Input: X := (x0,y) Output: X-1 ■■= ai(x0 , -¾) 1. a0 := Xq 2. ar := x2 3. a0 := a0 — ar • v / / Always nonzero 4.     := Qq1 / / Inversion in F^6. Conjugate / / Inversion of unitary elements Input: X := (x^x-J Output: X := (x0, —xT) Table 9: Multiplication, squaring, and inversion of elements in Fqi2 := Fq6[w] / (iv2 —vf Here Xi.yi.di.v e Fq6. See Section 2.4 for the arithmetic in Fq6. Also, a^Xg , —x-f) is multiplication by scalar in Fq6 (see Table 7,Error! Reference source not found, bottom right) and • v is multiplication by v (see Table 8, bottom left). 22 2.5.2 Exponentiation as a Quadratic Extension The final exponentiation may be said to be comprised of an easy part and a hard part. These terms are used in the art. 5 In the hard part of the final exponentiation, exponentiation to u and u / 2 is required (u is the curve parameter). These exponentiations are done through the generic algorithm 'signed square-and-multiply'. Thus, the exponent e (either u or u / 2) is given in binary signed format, i.e. with bits in et 6 {—1,0,1}. The algorithm can only be used to 10 exponentiate unitary elements (i.e. in the hard part of the final exponentiation). See Table 10. Exponentiate unitary element in F?i2 / / Fixed exponent e = Sf=o ei^1 with et e {—1,0,1} Input: f e Fqi2 := Fq6[w] / (w2 — v ) s.t. = 1 (unitary element) Output: fe e Fqi2 1- 9 := f 2. For j := — 2 down to 0 do: 3- g == g2 4. If = 1 then 9-=9-f 5. Else if e, = —1 then: g := g • f / / Compute inverse of unitary / via conjugation: / -1 = / 6. End if 7. End for 8. Output g Table 10: Exponentiation of unitary elements in Fqi2. Multiplication, squaring, and conjugation are defined in Table 9. 2.5.3 Multiplication as a Cubic Extension 15 During the Miller loop, different formulas for multiplying in Fqi2 are used that exploit the sparsity of the results of the line function evaluations. For this, Fqi2 is represented as a cubic extension over F^4 := IF^2 [s] / (s2 — Namely F^i2 := IF^M / Cr3 — s ). Thus, elements in Fqi2 are seeing as polynomials X of degree 2 modulo r3 — s. Fqi2 := {X ■= x0 + x}r + x2r2 |Xj 6 F 4, r3 = s}. In this representation, X is identified with its three F(?4-coefficients X ■= (x0,Xp^)- Since each X; 6 F„4 is a vector of two F„2 elements, X is a vector of six F„2 coefficients, seen as a triplet of pairs: X := (xo,x!,x2) = (a,b),(c,d),(e, / )). The results L of the line calculations are sparse elements, with half of their coefficients set to zero (see Section 2.7 below). Namely, Fqi2 elements are given in the form: 5 = ((a, b),(c, 0),(0,0)), where the third Fq4 element is zero (e, / ) = (0,0), and so is the second component of the second F„4 element d = 0. These are held in vectors of just three F„2-coefficients: Xs := (a, b, c) / / Sparse representation of L In the course of the Miller loop, sparse elements are multiplied by sparse elements. The result is a somewhat sparse element (i.e. the second component of the third Fq4 coefficient set to zero, f = 0) of the form: Xsw := (A b> C’ d, e). Also, during the Miller loop, either a sparse S or a somewhat sparse S' is multiplied by a standard (dense) element X. In this way, the sparsity of S and S' is exploited in these types of multiplications. The different types of multiplications are given in Table 11. Note that, in order to exploit the sparsity, the formulas are low level, i.e. they are given in terms of Fq2 arithmetic. Multiply sparse by sparse in F?i2. Input: • XS1 ■= (a,, b1, c,) / / sparse + brs + crr • Xs,2 := (d2,b2,c2) / / sparse Output: Xsw :=     • XSi2 := (a3, b3, c3, d, e)) / / somewhat-sparse a3 + b3s + c3r + dsr + er2 • a3 := aAa2 + b-^b2^ • b3 := b^ + • c3 := c}a2 + aAc2 • d:= crb2 + brc2 • e •= cAc2 Multiply somewhat-sparse by somewhat-sparse in Fg^ Input: • Xsw,i := («i, ^1, Q, dlt / / somewhat-sparse a, + b^s + (¾ + d1s)r + e}r2 • Xsw2 := («2,   c2, d2,62) / / somewhat- sparse Output:XswA • Xsw2: = (a3, b3, c3, d3, e3,f) / / a3 + b3s + c3r + d3sr + (e3 + fs)r2 • a3 :=     + b-^b^ + e^d2^ + d^e2^ • b3 := brd2 +^^-1- erc2 + cre2_ • c3 := c^d2 + d^c2 + dyb2^ + b^d2^ ® d3 •— d'^CL2 -I- c1b2 -I-13,¾ -J- a±d2 -I- ^^^2 • ^3 :=     + Q^2 + ^1^2^ + d.1e2 • f ■.= erb2 +     + crd2 + Multiply sparse by somewhat-sparse in F?i2 Input: • Xs := (^, b±, q) / / sparse •       := («2,   c2, d2, / / somewhat- sparse Output: Xs -Xsw-.= (a3,b3,c3,d3,e3,f) / / dense •  a3 := a±a2 + b-^b2^ •  b3 := b^ + arb2 + cre2 •  c3 := cra2 +     + b^d2^ •  d3 := c1b2 + b,c2 + ard2 •  e3 :=     + a^e2 • f :=    + b^ Multiply somewhat-sparse by dense in F?i2 Input: • ^-sw := («1. ^1. Ci, di, ei) / / somewhat-sparse • Xd := (a2, b2, c2, d2, e2,f2) / / dense Output: Xsw -Xd-. = (a3,b3,c3,d3,e3,f3) / / a3 + b3s + c3r + d3sr + (e3 + f3s)r2 • d3 := drd2 + b^z^ + e-^d^ + d^^ + • b3 := b^ + d^ +   + cre2 + d^ • c3 := cra2 +     + d-^b^ + b-^d^ + •          dyCi2 H-      H-1)1¾ "I- •   ¢3 I—       H-      "I"                 + •   / 3 := elb2 + dlC2 + Cld2 + ble2 + al / 2 Table 11 Multiply sparse by dense in F?i2. Input: • Xs :=    b^ c-J / / sparse • Xd := (a2,b2,c2,d2,e2,f2) 11 dense Output: Xs • Xd: = (a3, b3,c3, d3, e3, f3) / / dense • a3 :=    + b^^ + • b3 := b^ + drb2 + cj2 • c3 :=     + dlc2 + b-^d^ • d3 :=     + b1c2 + ard2 • e3 := £^2 + «1^2 + • / 3 := Cid2 + b1e2 + cii / 2 Table 11 (cant.): Multiplication in Fqi2 := Fq4[r] / (r3 — s) for elements containing some sparsity. Here di, bi, di, di.fi e Fq2. See section 2.2 for arithmetic over Fq2. Multiplying and squaring in the cubic representation is not essential, but it may be used to avoid unnecessary switching between representations in the Miller loop, that is to avoid introducing opcodes overhead. See Table 12. Multiplication in F?i2 in Miller loop. Square in F?i2 in Miller loop. Input: X := (x0,x^yx := (y0,yi,y2) Output: X -Y := (Zq.z^z^ • z0 := xoyo + x^s + x^s • zr := x}y0 + xoy} + x2y2s • z2 := x2y0 + x^ + x0y2 Input: X := (xa,Xi,x2) Output: X2 ■= (zq.z^z-z) • ZQ := Xq + 2¾ ■ X2 ■ S • Zx := 2%0 ■ xt + X2 ■ S • Z2 := 2%0 • x2 + X^ Table 12: Multiplication and squaring, in Fqi2 := Fq4 [r] / (r3 — s). Here Xi,yi,Zi,s e Fq4. See Section 2.3 for the arithmetic in Fq4. Also, x ■ s is multiplication by s (see Table 6, centre right). 2.6 EC Arithmetic in the Twisted Curve E’(¥ 2) Let two points T ■=            Q ■= (x2,y2) in the twisted curve Thus T, Q are in the second source group G2. Note that T is in projective coordinates, and Q in affine coordinates. Regardless of how they are expressed, points in the twisted curve E'(Wq^ have coordinates in Fq2. The points T + Q and [2]T can be computed according to the formulas shown in Table 13. Point addition in E'(Fqz) Input:? := (%i,yi,Zi),Q := (%2,y2) Output:? + Q := (x3,y3,z3) • x3 := A • (A3 + zr ■ 02 — 2xr ■ A2) • 7s := 0 • (3¾ • A2 — A3 - zr • 02 } — yr • A3 • z3 := Zi • A3 Where X •= x± — x2 ’ zr and 0 := yi — y2 • zr Point doubling in E’(Fq2) Input: T := (%i,yi, Zi) Output: [2]? := (x3,y3,z3) • ^3 ==1¾-7i(7i -9 / j' z2) •  73==(^(71+9^-¾2)) -27b’2-z^ • Z3 == 271 • Z1 Where b! := and := (1,--) in Fq2 := Fq[^] / (^2 -2^ + 2). Table 13: Top: Point addition in the twisted curve. Bottom: Point doubling. T is in projective coordinates and Q in affine coordinates. Here x^y^Zi e Fq2, see Section 2.2 for arithmetic over Fq2. 5 2.7 Evaluation Line Functions in the Target Field Fqi2 Let two points T ■= (^,^,^), Q := (x2,y2) 'n the twisted curve ^'(F^) in projective and affine coordinates, respectively. Also, let a point P := (xP,yPj in ^(Fg) in affine coordinates. The point P is in the first source group and has coordinates in Fq. The 10 points T, Q are in the second source group G2 and have coordinates in Fq2. 2.7.1 Line for Point Addition .qy, The evaluation at P of the line           that passes through the untwisted points ^(7) and ^(Q) is computed. The result of the evaluation in Fqi2 := Fq4 [r] / (r3 — s ) can be expressed as follows: (xQ ■= (a, b) 6 Fq4 x± ■= (c, 0) 6 Fq4 X2 := (0, 0) e Fq4 The result is a sparse polynomial only with three nonzero F^-coordinates. Therefore, gw(T),'¥(Q)(P) can be represented in sparse form as a vector of three F^-coordinates: gw(T),'¥(Q)(P) sparse form := (a, b, c ). Table 14 provides explicit formulas which can be used to calculate the coefficients a, b, c. Evaluate point addition line Input: T := (%i,yi,zi), Q := (x2,y2>), P := (xP,yP) Output:               := (a, b, c) / / sparse form • a := (a0,    := — yPX = — yp(x} — x2 ■ z^) • b := (b0, b^ := —xP9 = (yr - y2 • zj • x2 -    - x2 • zj • y2 • c ■=        ■= 6 ■ x2 - A ■ y2 =-xp(y± - y2 ■ z±) Figure 1: Formulas for computing the line evaluation of a point addition in Fj2 := Fq4[r] / (r3 -s). Here xt.yt.Zi e Fq2, and xP,yP e Fq are scalars. Also A, 0 are the same as in point addition (Tablet4, top). See Section2.2 for arithmetic over Fq2. 2.7.2 Line for Point Doubling .qwcTywcr) Likewise, the formula to compute the evaluation of the tangent line           at P 'n Fqi2 := Fq4[r] / (r3 — s) is given by: {x0 := (a',b') 6 Fq4 := (c', 0) 6 Fq4 X2 := (0, 0) e Fq4 Again, g^^yv^^P^) can be represented succinctly as a vector of three Fq2-coordinates (a!, b', c'). See Table 15 for the formulas to calculate coefficients a', b', c'. Evaluate point doubling line Input:? := (x,y,z),P ■= (xP,yP) Output: g^(T),w(r)(P) := (a',b',c'y. / / sparseform • a! := -2ypy1 • zx • b' := 3br • z3 — y3 • c' := 3xpx2 Where b' := and := (a + I)-1 = (|, — |) in Fq2 := Fq [a] / (a2 + 1). Table 15: Formulas for line evaluation of point doubling in F,2 := Fq4[r] / (r3 - s). Herex,y,z e Fq2, ano xP,yP e Fq are scalars. See Section 2.2 for arithmetic over Fq2. 2.8 Exponentiation via Frobenius Endomorphisms 2      3 During the final exponentiation, powers of the form Xq,Xq ,Xq for a given Fqi2-element X are computed. These computations can be done efficiently, in just 5 multiplications over F_2, as set out below. Fqi2 is represented as a quadratic extension (first representation), thus X := x0 + xrt. To compute (x0 + x}t)q, when expanding out the expression, powers less than q vanish because they have a coefficient that is multiple of q (the field characteristic). 2l                 2l—1 Next, for an Fq2 element a := a± + a2u, it can be seed that aq = a and aq = a, where a := a± — a2u is the conjugate of a. Last, t = w, and that in the first representation t6 = so tq =          which means that for i = 1,2,3,4,5, tiq = y^t1, where ylt ■= Therefore: Xq = (x0 + x-^w^ = (x0 + x^t)q = ((a + bv + cv2) + (d + ev + fv2)^ = (a + dt + bt2 + et3 + ct4 + ft6>)q 11 Switch to sextic extension (See Table 3.) = d + dy^t + by12t2 + eyli3t3 + cy1At4 + fy^t5 = (a + by12v + cy14v2) + (dy1;1 +      + / / 1,5172)^7 / / Switch back to quadratic extension 2             3 Computing Xq and Xq is done similarly. See Table 16 for the formulas. It is observed that the F^-elementsyjj for j = 1,2,3, i = 1,2,3,4,5 are precomputed and hard-coded it in the algorithms. q-Frobenius / / Define y^ := Input: X := (%i,%2) e Fq6[w] / (w2 — v) • %! := (a, b, c) • x2:=(d,e4) Output: Xq := (^1,^2) 6 Fq6[w] / (w2 — v) • x\ := (a, b • y^, c • yM) • x'2 := (d -y^.e q2-Frobenius / / Define y24 := y14 • y14 Input: X := (%i,x2) e Fq6[w] / (w2 — v) • xt := (a, b, c) • x2 := (d, e, f) Output: Xq2 := (x'px'2) G Fq6[w] / (w2 — v) • x\ := (a, b • y2 2, c • y2 4) • x’2:= (d-72>i,e-72>34 -72,5) q3-Frobenius / / Define 7^ := yt f • 72 i Input: X := (%i,x2) e Fq6[w] / (w2 — v) • xy := (a, b, c) • x2 := (d, e, f) Output: Xq := (^1,^2) 6 Fq6[w] / (w2 — v) • x\ := (a, b • y3 2, c • y34) • x’2:= (d -y^e -73,34 - / 3,5) Table 16: q-powers via Frobenius. Elements a,b,c,d,e,f, yjt are in Fq2. See Section 2.2 for arithmetic in Fq2. Elements yj^ are precomputed. Also, x denotes the conjugate ofx. 2.9 Final Exponentiation The final exponentiation computes f ■= f^q12 in F k. The exponent can be expressed as: qk-l e: =---- r 1V-11 La’fcCqOJ L r J' where is the fc-th cyclotomic polynomial. A pairing friendly field may be defined as an extension F k with q = 1 mod 12 and q = > l,j > 0. In such a pairing-friendly field Ft, the exponent can be expressed as follows: e = (QW - 1)(,W + In BLS12 (and in BN for that matter), the embedding degree is k = 12, so the above formula for the exponent becomes: e= {q6-lW + 1)^^- The part (q6 — 1)(q2 + 1) of the exponent is referred to as the first, or easy, part. The part — ¢7^ + 1 d ■=-------is referred to as the second, or hard, part. They are computed differently, as r set out below. 2.9.1 Final Exponentiation - First (Easy) Part Representing f as an element in Fqi2 = Fqe[w] / (w2 — v), the power fq& is just its conjugate f. Thus, if f = a + bw, then fq& = f ■= a — bw. This means that the first part of the exponent is computed as y(q6-l)(q2+l) =           +1 =            = Raising to q2 is done with the Frobenius operator. See Table 17 for the algorithm to compute the easy part. This part is common to BN curves. Exponentiate easy part: Input: / := (x, y) e Fqi2 := Fq6[w] / (w2 — v) Output: g := (x1,^ = f^6~^2 < L ^:=r 2. / 2 := f = (x, -y) / / Conjugate f 3- / 3 := / 1 • / 2 2 4. / 4 :=     11 q2-Frobenius. See Table 16, top right. 5- 9 := / 3 • / 4 Tablet 7: Easy part of the final exponentiation. Multiplication and inversion is carried over F?i2 as a quadratic extension (see Table 9). 2.9.1 Final Exponentiation - Second (Hard) Part The second part is specific for each curve. Herein, it is explained how to do it for BLS12. The output of the first part is g ■= / -1)^2 +1). 4.      7 . - -^1               ।                 ■     ■                        ,                                 a ,         , q -q + 1 _. The second part consists in computing the exponentiation g where d ■=-------. First, r the exponent is expressed as the sum d = Ao + A^q + A2q2 + A3q3, where the coefficients At are integers. This means that the result of the final exponentiation is: _ gd _ g70+71q+72q2+73q3 The above exponentiation is typically done with an addition chain for specific coefficients of Ai (which depend on the parameterization of the prime q, hence on the specifics of each curve) and applying the Frobenius operators for the powers q, q2, and q3. An addition chain is used which is optimized for BLS12. See Table 18 for the algorithm. The concrete values of Ai for which the addition chain applies are: Ao = A^u + 3 A^ — A2U A3 A2 — Au A3 = it2 — 2it + 1 where it is the curve parameter. Exponentiate hard part: / / curve parameter u hard-coded Input: 9 := (x,y) e Fq12 := F^efw] / (w2 — v) / / The output of the easy part. (Table 17) q4-q2+l Output: p := g r / / The pairing output. 1. t0 := g2 1.    :=    11 See Table 10 3. t2 := t“ / 2 / / See Table 10 4. t3 := g (= q-1) / / Conjugate - see Table 9 bottom right. 5.      := t3 • 6.     :=    (= ti1 ) 7. ti = ti • t2 8. t2 := 9- t3 := 10. tl :=   (= tr1) 11. t3 =    • t3 12.   :=   (=     ) 3 13.   ■=    11 q3-Frobenius. See Table 16 bottom. 2 14. t2 :=    11 q2-Frobenius. See Table 16 top right. 15.    :=    • t2 16. t2 := := 18. t2 := ^2 ’ 9 19. ti := ti • t2 20. t2 :=   11 q-Frobenius. See Table 16 top left. 21. p := ti • t2 Table 18: Hard part exponentiation. The algorithm uses five temporary variables tt. Multiplication is given in Table 9 and exponentiation byu,u / 2 in Table 10. 3 SCRIPTS The scripts which may be used to implement a BLS12 pairing in Script are provided below. The scripts are broken into four major conceptual blocks: extension field arithmetic scripts 402, Miller loop scripts 404, final exponentiation scrips 406, and pairing scripts 408. The scripts to be used by external users are those in the pairing block 408. The other scripts 402, 404, 406 are internal. The conceptual division and dependence of scripts is shown in Figure 4. Some or all of script blocks may be used to compute the pairing. For example, the Miller loop script block 404 may be used together with a known final exponentiation script which computes the inverse. Other combinations of the script blocks may be implemented. The scripts 402,404, 406, and 408 may be referred to herein as computational blocks. In the examples provide herein, the scripts are presented as blockchain scripts. However, it will be appreciated that the scripts may be any form of computer readable scripts. In particular, the scripts may be any form of bytecode or binary code. In such codes, any loops are expended. For example, instead of defining a branching script comprising if statements, each loop is defined consecutively to generate a script with no branching. The scripts provided herein minimise the size of such branchless scripts. 3.1 Extension Field Arithmetic Scripts The extension field arithmetic scripts perform arithmetic over the extension fields of the pairing. Namely, arithmetic over fields Fq, Fq2, Fq4, F^e, Fqi2. Available implementations to multiply and square over quadratic or cubic extensions of a given base field use Karatsuba multiplication, and the squaring complex method or Chung-Hasan squaring, respectively. These algorithms use few multiplications but more arithmetic operations over the base field in general. Thus, they are faster to execute, i.e. require fewer CPU cycles, but more costly to describe in scripts. The scripts provided herein use algorithms that yield scripts with fewer opcodes. Therefore, these scripts are considered to be size-efficient. The extension field arithmetic block is split into eight groups - see Figure 5. The scripts of the upper FQ12 groups are used in the Miller loop and final exponentiation parts of the pairing. The inner groups contain scripts necessary to implement operations in FQ12 (Fqi2 ). The scripts provided herein may be used to compute a pairing. The pairing may be computed by executing a set of sub-computations in a target field. Instead, the target field may be represented as an extension field and a sub-computation performed by a subfunctions over the extension field. Sub-computations of the pairing computations may be performed by subfunctions executed over different extension fields. The elements output by the subfunctions can be transformed to be represented in a different extension field. By using the subfunctions in extension fields, the size of the pairing computation in script is reduced, and therefore the computational efficiency of the computation increased. 3.1.1 FQ Arithmetic over Fq. An FQelement is an integer x modulo q. Thus, 0 < x < q. Implementation of addition, subtraction, negation, multiplication and squaring of modular integers can be done easily. Bitcoin Script supports modular arithmetic with native opcodes such as OP_ADD, OP_SUB, OP_MUL, OP_MOD. 3.1.2 FQ2 Arithmetic over Fq2 := JFq[u] / (u2 + 1 ), with f := it + 1. An FQ2 element is a pair of integers x = (x0, x-J where 0 < xt < q. Table 19 lists the scripts. Scripts Description Pseudocode reference [FQ2 add] [FQ2 subtract] Add two elements. Subtract two elements. Table 4 [FQ2 negate] [FQ2 multiply by scalar] [FQ2 multiply] Negate an element. Multiply by an element in Fq. Multiply two elements. Table 5 [FQ2 square] Square an element. [FQ2 multiply by xi] Multiply an element by element Table 19: Scripts of Fq2 arithmetic 3.1.3 FQ4 5 Arithmetic over Fq4 := Fq2 [s] / (s2 — ^ ). An FQ4 element is a pair of FQ2 elements x = (^0,¾) where xt 6 Fq2. Table 20 lists the scripts. Scripts Description Pseudocode reference [FQ4 add] [FQ4 multiply] [FQ4 square] [FQ4 multiply by scalar] [FQ4 multiply by s] Add two elements. Multiply two elements. Square an element. Multiply by an element in FQ2 . Multiply an element by element 5. Table 6 Table 10: Scripts for Fq4 arithmetic 10   3.1.4 FQ6 Arithmetic over Fq6 := F^fv] / ^3 — An FQ6 element is a triplet of FQ2 elements x = where xt 6 Fq2. Table 21 lists the scripts. Scripts Description Pseudocode reference [FQ6 add] [FQ6 subtract] [FQ6 negate] [FQ6 multiply by scalar] [FQ6 multiply] [FQ6 square] Add two elements. Subtract two elements. Negate an element. Multiply by an element in FQ2 . Multiply two elements. Square an element. Table 7 Table 8 [FQ6 multiply by v] Multiply an element by element v. Table 21: Scripts for Fq6 arithmetic 3.1.5 FQ12Quadratic Multiplication over Fqi2 := F^w] / ^2 — v). Namely, a quadratic extension over F^e. An FQ12Quadratic element is a pair of FQ6 elements x = (^,¾) where xt 6 F^e. Table 22 lists the scripts. Scripts Description Pseudocode reference [FQ12Quadratic multiply] [FQ12Quadratic square] i Multiply two elements. : Square an element. ...........; Table 9 Table 22: Scripts for Fqi2 multiplications as a quadratic extension. 3.1.6 FQ12CubicSparse Sparse multiplication and squaring over Fqi2 := Fq4[r] / (r3 — s'). Namely, a cubic extension over Fq4. The following types of elements are distinguished: • FQ12CubicSparse. A triplet of FQ2 elements xs = (a, b, c) where a,b,c 6 Fq2- • FQ12CubicSomewhatSparse. Five FQ2 elements xsw = (a, b, c, d, e) where a, b, c,d,e 6 F„2 • FQ12CubicDense. Six FQ2 elements xd = ((a, F), (c, d), (e, / )) where a, b, c, d,e,f 6 Fq2 (Standard element in FQ12 as a cubic extension) Table 23 lists the scripts. Scripts Description Pseudocode reference [FQ12Cubic multiply sparse by sparse] Multiply two sparse elements. Table 11 [FQ12Cubic multiply sparse by somewhat-sparse] Multiply a sparse         [ element by a somewhat- i sparse element. [FQ12Cubic multiply sparse by dense] Multiply a sparse element by a dense element. [FQ12Cubic multiply somewhat-sparse Multiply two somewhat by somewhat-sparse] sparse elements. [FQ12Cubic multiply somewhat-sparse Multiply a somewhat- by dense] sparse element by a dense element. [FQ12Cubic multiply] Multiply a (dense) element. ______________________________________________________________________] Table 12 [FQ12Cubic square] Square a (dense) element. Table 23: Scripts for 12 sparse multiplications as a cubic extension. 3.1.7 FQ12lnvert Inversion algorithms of elements in Fqi2. Inversion involves the following types of elements 5 (defined in the previous sections): • FQ element • FQ2 element • FQ6 element • FQ12Quadratic element Table 24 lists the scripts to invert elements. Scripts Description Pseudocode reference [FQ invert] [FQ2 invert] [FQ6 invert] Invert an element in Fq. Invert an element in IF 2. Invert an element in F„6. Table 5 Table 8 [FQ12Quadratic invert] Invert an element in F„i2. 4 [FQ12Quadratic conjugate] Invert a unitary element in Table 9 1111 Table 24: Scripts to invert elements 3.1.8 FQ12Frobenius Exponentiation of an Fqi2 element to the powers q, q2, q3 using Frobenius. Scripts Description Pseudocode reference [q-Frobenius] [q2-Frobenius] [q3-Frobenius] Exponentiate an element in F^ to q. Exponentiate an element in FQi2 to q2. Exponentiate an element in F^ to q3. Table 16 Table 25: Exponentiation via Frobenius 3.2 Miller Loop Script Figure 6 shows the relationships of the scripts needed to implement the Miller loop for single pairing, or three pairings combined. The Miller loop script comprises a line function and a square-and-update function. The output of the line function is an array of element, which are provided as input to the square-and-update function. The line function receives as inputs the curve points Q and P. Each of these functions comprises multiple loops, the number of loops being defined by a curve parameter u, with the number of loops being equal to a bitlength of the curve parameter u. The curve parameter is hard-coded into the script, that is it is predefined. Each loops comprise a set of subfunctions for executing a portion of the function. In both the single pairing and multi-pairing variations, each loop of the line function may comprise one of two different sets of subfunctions, referred to herein as a first set of subfunctions and a second set of subfunctions. Which of these two sets of subfunctions to be used in a particular loop is dependent on a curve parameter condition. When the curve parameter is represented in a binary form, the curve parameter condition is based on a value of a corresponding bit of the curve parameter. In the examples below, a first curve parameter condition is met if the corresponding bit is set to 0, and a second curve parameter condition is met if the corresponding bit is set to 1. If the corresponding bit of the curve parameter is set to 0, that is the first curve parameter is met, the first set of subfunctions is used. If instead the corresponding bit of the curve parameter is set to 1, that is the second curve parameter is met, the second set of subfunctions is used. Since the curve parameter is predefined and hard-coded in the script, the corresponding set of subfunctions for each loop of the line function is also predefined. There is, therefore, no need for branching in script. 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 of the first set of subfunctions are also subfunctions of the second set of subfunctions. In the case of a multi-pairing, the first and second set of subfunctions comprises some same subfunctions and some different subfunctions. The array of element output by the line function comprises an element computed by, i.e. an output of, each loop of the line function. The line function also includes an initial curve point subfunction, which takes as input the curve point Q and computes an initial curve point T. The first loop of the line function takes the initial curve point as input and update the curve point T. Each subsequent loop of the line function takes a current curve point T computed by a previous loop as input and is configured to update T to compute a next current curve point. The element of the array of elements computed by a particular loop is computed based on the current curve point T, that is the curve point T received as input to said loop. In the single pairing variation, the square-and-update function also comprises two sets of subfunctions, with the particular set used for each loops being dependent on the curve parameter conditions as set out above. The two possible sets of subfunctions of the square-and-update function may be referred to herein as a third and fourth set of subfunctions. Each of the third and fourth set of subfunctions comprise a squaring subfunction and a multiplication subfunction. In the third set of subfunctions, the multiplication subfunction is a sparse-by-dense vector multiplication, whereas in the fourth set of subfunctions, the multiplication subfunction is a somewhat-sparse-by-dense vector multiplication. In the multi-pairing variation, the loops of the square-and-update function comprise the same set of subfunctions irrespective of the curve parameter u. All loops comprise the same squaring subfunction and multiplication subfunction. The output of the square-and-update function is an intermediate value f. The intermediate value f can be used to compute a pairing. The scripts which may be used to execute a Miller loop for single or multi pairings are shown in Tables 26 and 27 respectively. By executing the Miller loop in this way, the intermediate value can be computed via sparse multiplication in the extension field. The operands of sparse multiplications can be described very succinctly, which reduces the number of opcodes for stack management, and therefore improves efficiency of computation. Novel formulas for different variations of sparse multiplications are set out fully in Table 11. As the curve parameter is predefined, each loop of each function is predefined. The term loop, therefore, refers to a set of subfunctions within the function which are implemented sequentially. The loops may be considered to be unrolled. That is, a specific set of subfunctions is not executed again with different inputs, but rather an identical set of subfunctions, or a similar set of subfunctions in the event that curve parameter conditions is different, is executed using inputs from a directly previous set of subfunctions. In this way, the Miller loop itself can be considered to be unrolled. That is, each subfunction is executed only once. 3.2.1 Breaking the Miller Loop in Two Loops To iterate over the Miller loop, the Miller loop (Table 2, steps 1-10) is broken into two loops. The first loop calculates and stores the results of the line function evaluations in an array g of FQ12 elements. The main (second) loop takes as input the stored results g and updates and squares the element f. [Miller loop]:= [Line functions loop] [Main loop] By computing the Miller loop in this way, many multiplications are sparse, which are faster to describe (and execute) than standard FQ12 multiplication in script. See Table 26 for the pseudocode. 3.2.2 Multi-Pairings A combined Miller loop can also be implemented which enables support for multi-pairings. The case of three pairings is provided herein. In this case, three line functions (one for each pairing) are calculated together resulting in an array g holding the combined line functions calculations. Then, update and square the combined f value. [3-miller loop]:= [3-line functions loop] [3-main loop] Combining the line functions together allows to do more sparse multiplications overall than if they are calculated separately, therefore, increasing the speed of computation. See Table T1 for the pseudocode. 3.2.3 Precomputing A, 6 for Adding Points and Point Addition Function In the formula to calculate the point addition function (Table 14), the values A and 6 are the same as for point addition T + Q (Table 13, top). In the Miller loop, these values only need to be computed once for both operations. Therefore, A, 6 can be computed first and equivalent routines defined for point addition and line evaluation, respectively, that take A and 6 as input. Script [Line functions loop] / / curve parameter u hard-coded Input: Q := (x,y) e E'CF^ ), P := (xP,yP) £ Output: An array g of [log(u)J FQ12 elements. • If j-th bit U; = 0, then gt = bt, / / Sparse FQ12Cubic element • Else if U; = 0 then gt = (^, bi, c^, di, / / Somewhat-sparse FQ12Cubic element Steps: 1. T := (x,y, (1,0)) / / Set Q in projective coordinates 2. / / For i := [log(u)J — 1 down to 0 do (unrolled loop: fixed u): 3. [Point doubling line] / / gt := ^(7),^(7)( / 3) / / Sparse 4. [Double point] / / T := [2]T 5.    / / If U; = 1 then: / / Branchless If (fixed ut) 6. [Compute A and 0] / / Precompute A, 0 7. [Point addition line with input A, 0] / / t'[ ■= g^^^^Q^P) / / Sparse 8. [FQ12Cubic sparse by sparse mult] 11 gL := gL • t-11 Somewhat-sparse 9. [Add points with input A, 0] / / T := T + Q 10. / / End if 11. / / End for Script [Main loop] / / curve parameter u hard-coded Input: An array g of [log(u)J FQ12 elements (from [Line functions loop] output above). • If j-th bit U; = 0, then g, = bi, / / Sparse FQ12Cubic element • Else if = 0 then g, = (^, bt,ct, d,,    / / Somewhat-sparse FQ12Cubic element Output: f := (x0,   x2) := ((¾ ^), (c d), (e, / )) / / FQ12Cubic dense element Steps: 1. f := ^[[log^)] — 1] / / Set initial value of f (First iteration of Miller loop) 2. / / For j := [log(u)J — 2 down to 0 do (unrolled loop: fixed u): 3. [FQ12Cubic square] / / f-=f2 4. / / If Ui = 0 then ^[j] is a sparse FQ12 element / / Branchless If (fixed u / }. 5. [FQ12Cubic sparse by dense mult] / / f := g, • f 6. / / Else Ui = 1 and ^[j] is somewhat-sparse 7. [FQ12Cubic somewhat-sparse by dense mult] / / f’-=gi-f 8. / / End If 9. / / End for Table 26: Miller loop (see Table 2, steps 1-10) expressed as two loops and with sparse multiplication Script [3-line functions loop] / / curve parameter u hard-coded Input: Qj := e ^'(F^ ),Pj := (xP.,yP.) e E(FQ) for; = 1,2,3. Output: An array g of [log(u)J FQ12Cubic dense elements. Steps: 1. Tj := (Xj,yj, (1,0)) / / Set Qj in projective coordinates for j = 1,2,3 2. / / For i := [log(u)J — 1 down to 0 do (unrolled loop: fixed u): 3. [Point doubling line] / / tij :=     )^(7 )(^) f°r J = 1'2,3 (Sparse) 4. [Double point] 11 Tj := [2]7) for j = 1,2,3 5.    / / If U; = 0 then: / / Branchless If (fixed uj 6. [FQ12Cubic sparse by sparse mult] 11 g^ :=   • ti2 (Somewhat-sparse) 7. [FQ12Cubic sparse by somewhat-sparse mult] / / gi := ti 3 • g^ (Dense) 8. / / If U; = 1 then: 9. [Compute Aj and 6)] / / Precompute Aj, 6j for j = 1,2,3 10. [Point addition line with input Aj,0j] 11 i,j'•=                for j = 1,2,3 (Sparse) 11. [FQ12Cubic sparse by sparse mult] / / :=   • t-j for j = 1,2,3 (Somewhat- sparse) 12. [FQ12Cubic somewhat-sparse by somewhat-sparse mult] / / gi :=   • ti2 (Dense) 13. [FQ12Cubic somewhat-sparse by dense] 11 g^ := ti3 • g^ (Dense) 14. [Add points with input Aj, 9j] / / Tj := Tj + Qj for j = 1,2,3 15. / / End If 16. / / End for Script [3-main loop] / / curve parameter u hard-coded Input: An array g of [log(u)J FQ12Cubic dense elements (from [Line functions loop] output above). Output: f := (x0, xlt x2) := ((a, b), (c, d), (e, / )) / / FQ12Cubic dense element Steps: 1. f := <9[iog(u)]—1 / / Set initial value of / (First iteration of Miller loop) 2. / / For i := [log(u)J — 2 down to 0 do (unrolled loop: fixed u): 3. [FQ12Cubic square] Hf'-=f2 4. [FQ12Cubic multiply] Hf-—f'gi 5. / / End for Script [3-Miller loop] / / curve parameter u hard-coded Input: Qj := (xpyf) G E'(Fqz ),Pj := (xPfyPj) G E(FQ) for) = 1,2,3 Output: f := (x0, xlt x2) := ((¾ ^), (c, df (e, / )) / / FQ12Cubic dense element Steps: 1. [3-line functions loop] / / Calculate array g of line calculations 2. [3-main loop] / / Update and square f Table 27: Combined Miller loop for three pairings with sparse multiplication 3.2.4 Scripts The Miller loops has three types of operations: 1) Point addition / point doubling in the twisted curve E'(Wq2 ). 2) Line functions evaluations in the target field Fqi2. 3) Sparse multiplications and squaring in Fqi2. Scripts for (3) have been covered in Section 3.1. The remaining scripts for implementing the Miller loop are listed in Table 28 and Table 29. Scripts Description Pseudocode reference [Compute A, 0] Precompute A, 0 for point addition and line function. [Add points with inputs A, 0] Add points T + Q in j Table 13 [Double point] Double point [2]T in [Point addition line with inputs A, 0] Compute g^^^P) in Table 14 [Point doubling line] Compute            in | Table 15 Table 28: Elliptic curve arithmetic and line function evaluation scripts Scripts Description Pseudocode reference [Line functions loop] [Main loop] Compute array g of line functions evaluations. Update and square f. Table 26 [Miller loop] Compute the Miller loop. [3-line functions loop] Compute array g for three line functions evaluations combined. [3-main loop] Update and square f. Table 27 [3-Miller loop] Compute the combined Miller loop for three pairings Table 29: Miller loop scripts 5   3.3 Final Exponentiation Scripts 3.3.1 Avoiding inversion The most expensive (field arithmetic) operation in the pairing calculation is computing an inverse in Fqi2. During the second part of the final exponentiation, inverses can be avoided via conjugation, but in the first part this is not possible. Therefore, the output f of the Miller 10 loop must be inverted to compute the pairing. In the method described herein, f is inverted off-chain and then the inversion f ■= f-1 is passed as an input to the final exponentiation script. Thus, the inversion routine is replaced by instead checking f • f = 1. This change results in a significant saving when describing 15 the script, as all routines dedicated to inversions in the intermediate extension fields are not needed anymore. See Table 30. Exponentiate easy part with inverse check: Input: • f ■= (x,y) e Fqi2 := Fq6[w] / (w2 — v) / / Output of Miller loop • f G Fq12 := Fq6[w] / (w2 — v) / / The purported inverse of f Output: g := (x'.y'} = y (^6-+1) 1. Assert f ■ f = ^ / / All coefficients set to zero except constant coefficient %0 := 1 2- / 2 := f =   -y) / / Conjugate f 3. 2 4. / 4 :=     11 q2-Frobenius. See Table 16, top right. 5- g-=h- A Table 30: First part of the final exponentiation with inverse check. Multiplication is carried over Fqi2 as a quadratic extension (see Table 9). As above, the value f may be referred to herein as the intermediate value. The inverse of this value, f as provided as input to the final exponentiation script may be referred to herein as a candidate inverse intermediate value. The provided inverse is considered a candidate value since the step f • f = 1 checks that the provided inverse is the inverse of f. This check has the effect of verifying that the target inverse intermediate value is equal to a target inverse intermediate value, with the target inverse intermediate value being the inverse of the value f. In one embodiment, the intermediate value f is an output of the Miller loop script 404. The intermediate value f can be considered to be derived from an initial value, as described later. 3.3.2 Composing First and Second Exponentiations The final exponentiation script simply runs sequentially the easy and hard parts. Since there are two flavours for the easy part, there are two final exponentiation scripts. [Final exponentiation]— [Easy part] [Hard part] [Final exponentiation with inverse check]:= [Easy part with inverse check] [Hard part] 3.3.3 Scripts 5 Tabh 2 31 lists the necessary scripts for the final exponentiation. Scripts Description Pseudocode reference [Conjugate] Compute the inverse of a [ Table 9, bottom right unitary element in FQ12. [Exponentiate to u] Exponentiate a unitary element to the curve parameter u. The exponent u is hard-coded in the script, and the loop unrolled. Table 10 [Exponentiate to^] As above but with exponent [Easy part] Compute / (^6-1)^2 +1), where f is the output of the Miller loop. [Table 17 [Easy part with inverse check] As above but without inverting f. (It takes extra input f := / -1) | Table 30 [Hard part] q^-q^+l Compute g r t where g is the output of the easy part. [Table 18 [Final exponentiation] Outputs the pairing [ Concatenation of easy [ and hard parts [Final exponentiation with Outputs the pairing [ Concatenation of easy inverse check] [ (with inverse check) [ and hard parts _______________________________________________________________ Table 31: Final exponentiation scripts 3.4 Pairing Scripts These scripts combine the Miller loop scripts with the final exponentiation scripts. 3.4.1 Switching representations The output of the Miller loop is an element f in Fqi2 as a cubic extension. The final exponentiation expects the same f but represented as an element of the quadratic extension. From cubic to quadratic Input f := ((a, b), (c, d), (e, / )) e Fqi2 := Fq4 [r] / (r3 - s ) Output f ■= ((a, e, d), (c, b, / )) e Fqi2 := Fq6 [w] / (w2 — v) Table 32: Switching from cubic to quadratic representations. See also Table 3. 3.4.2 Single Pairing Scripts Two variations for the pairing script may be used. They are functionally equivalent, but the second one (with inverse check) is shorter to describe. Standard pairing script: [Pairing] := [Miller loop] [From cubic to quadratic] [Final exponentiation] Size-efficient pairing script: [Pairing with inverse check] := [Miller loop] [From cubic to quadratic] [Final exponentiation with inverse check] 3.4.3 Multi-Pairing Scripts Likewise, for multi-pairings, two variations of pairing scripts may be used, depending on whether or not inverses are computed off-chain and checked on-chain: Standard 3-pairing script: [3-pairing] := [3-Miller loop] [From cubic to quadratic] [Final exponentiation] Size-efficient 3-pairing script: [3-pairing with inverse check]:= [3-Miller loop] [From cubic to quadratic] [Final exponentiation with inverse check] 4 BLOCKCHAIN IMPLEMENTATIONS The scripts above may be used in blockchain transactions. The example provided herein uses the use case of providing knowledge of a secrete value, e.g. a zero-knowledge proof. It will be appreciated that the pairing generated by executing the scripts may be used for other purposes as known in the art by modifying the locking script to execute the required computations. Alice, a challenger, generates a locking, or challenge, blockchain transaction. The locking blockchain transaction comprises a locking script, which causes the computations and verifications discussed above to be executed, and a pairing computed. Bob, a challengee, generates an unlocking blockchain transaction. The unlocking transaction may be referred to as a solution or proof blockchain transaction. Bob may also be referred to herein as a provider or a proof generator. The unlocking transaction comprises an unlocking script which provides the inputs required for satisfying the requirements of the locking script and generating the pairing. For example, Alice generates a locking script which locks an amount of UTXO. The locking script is unlocked by a locking script which proves knowledge of the secret value using a zero-knowledge proof. To verify the zero-knowledge proof, a bilinear pairing is computed. The locking script of the present example computes the pairing using each script 402, 404, 406, 408 of Figure 4. However, it will be appreciated that any combination of these scripts may be used together with other suitable script blocks to compute the pairing. For example, the Miller loop script 404 may be used together with a known script for computing an inverse, and the output of these two scripts used to compute the pairing. The unlocking script generated by Bob and included in the proof transaction comprises all elements required, by the locking script, to compute the pairing, as well as any other components required to satisfy the requirements of the locking script. In this example, the unlocking script comprises a candidate proof value, also referred to as an initial value, and a candidate inverse intermediate value. The initial value comprises points P, Q in the source groups used for computing the pairing. The candidate inverse intermediate value is a point in the target field (an element of field FQ12). The unlocking script also comprises a signature generated using Bob's private key. The locking script comprises the Miller loop script 404, configured to execute the line function and square-and-update function as described above. The Miller loop script 404 derives the intermediate value f as set out above, based on the proof provided in the unlocking script. The locking script also comprises the final exponentiation script 406, configured to check that the candidate inverse intermediate value f provided in the unlocking script is equal to the inverse of the intermediate value f computed by the Miller loop script 404. This check can be achieved as set out above. The locking script also comprises the bilinear pairing script 408, configured to compute the pairing. This takes as input the intermediate value f computed by the Miller loop script 404 and the candidate inverse intermediate value f provided in the unlocking script. The locking script may comprise a further computational block or script configured to verify the proof provided in the unlocking script based on the computed bilinear pairing. The locking script may be considered to provide a request for the values required for unlocking the UTXO, such as the candidate inverse intermediate value. In some embodiments, the challenger may send a request off-chain for the inclusion of the required values in the unlocking script. It will be appreciated that the term "proof" is not limited to a zero-knowledge proof. The proof may instead be some value which proves eligibility for partaking in an exchange, for example. The initial value, or proof, provided in the unlocking script comprises a pair of elliptic curve points from which the bilinear pairing can be computed. Alternatively, the pair of elliptic curve point may be derived from the initial value. The locking script of the blockchain transaction may be used for other computations using the pairing. For example, a BLS signature may be computed using the result of the pairing. The initial value, provided in the unlocking script, may comprise the public key and the message (points P, Q for which the pairing is computed), or the signature and the curve generator (also seen as P, Q for a second pairing evaluation). The skilled person would be aware of other computations which use bilinear pairings, and which may be implemented using the methods disclosed herein. In each implementation, the initial value is points P, Q over which the pairing is computed. What these points mean depends on use case: a proof in zk-proofs, signature / public key in signatures etc. as discussed herein. 5 EXAMPLES 5.1 Script Size Estimation The input is 6 elements in Fq, representing two points P and Q. That is, roughly 6 x 50 = 300 bytes. Line Functions Loop Estimation (bytes) Number of loops Total [Point doubling line] 50 65 3250 [Double point] 120 65 7800 [Compute A and 6] 24 5 120 [Point addition line with input A and 6] 70 5 350 [FQ12Cubic sparse by sparse mult] 90 5 450 [Add points with input A and 0] 170 5 850 12820 Table 33 Main Loop Estimation (bytes) Number of loops Total [FQ12Cubic Square] 70 65 4550 [FQ12Cubic sparse by dense mult] 190 60 11400 [FQ12Cubic somewhat-sparse by dense mult] 330 5 1650 17600 Table 34 Exponentiate easy part with inverse check Estimation (bytes) Number of times Total Assert correctness of inverse 370 1 370 [FQ12 dense by dense with FQ6-tower] 350 2 700 Q2 Frobenius 300 1 300 Conjugate 30 1 30 1400 Table 35 Exponentiate hard part Estimation (bytes) Number of times Total Squaring 240 1+65+64+65+65+65 78000 multiplication 350 4x5 + 8 9800 Q2 Frobenius 300 1 300 Q Frobenius 300 1 300 Q3 Frobenius 300 1 300 Conjugate 30 4 120 88820 Table 36 5 As a estimation, the script size is roughly 121 KB for evaluation of one pairing in script. If three pairing evaluation is required and check for equality, then the script size is roughly 180 KB (30 KB for one Miller loop, hence 90 KB for three Miller loops, and one final exponentiation of 90 KB). The current smallest script for such comparison is 1.5 MB claimed 10 by sCrypt. Even with some stack position management, the script size for three pairing evaluation and equality verification provided herein is significantly less than 1.5 MB. It is noted that the [3-Miller Loop] script set out above provides further script size savings. 15   5.2 BLS12 Parameters in hexadecimal. q: 0xla0111ea397fe69a4blba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabf ffebl53ffffb9feffffffffaaab r: 0x73eda753299d7d483339d80809ald80553bda402fffe5bfeffffffff00000001 x: 0xl7fld3a73197d7942695638c4fa9ac0fc3688c4f9774b905al4e3a3fl71bac586c55e 83ff97alaeffb3af00adb22c6bb y: 0x08b3f481e3aaa0fla09e30ed741d8ae4fcf5e095d5d00af600dbl8cb2c04b3edd03cc 744a2888ae40caa232946c5e7el h: 0x396c8c005555el568c00aaab0000aaab b: 4 x'_0: 0x024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3dl770bac 03 2 6a805 b befd48056c8cl21bd b8 x' 1: 0xl3e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334 cfl!213945d57e5ac7d055d042b7e VLO: 0x0ce5d527727d6ell8cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160dl2c923a c9cc3baca289el93548608b82801 OxO6O6c4aO2ea734cc32acd2bO2bc28b99cb3e287e85a763af267492ab572e99ab3f37 0d275cecldalaaa9075ff05f79be h1: 0x5d543a95414e7fl091d50792876a202cd91de4547085abaa68a205b2e5a7ddfa628 flcb4d9e82ef21537e293a6691ael616ec6e786f0c70cflc38e31c7238e5 b': 4*(u + l) 6. EXAMPLE SYSTEM OVERVIEW A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network") and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called "coinbase transactions", points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers. The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to timeorder index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data. In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer 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 for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction. In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be that the output of the first transaction has not already been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain. An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly. Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104. Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. 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 comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and / or an optical medium such as an optical disk drive. The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so 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, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout. A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output. In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction. Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together. The memory of each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these. Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, performing consensus (e.g. proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations. Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 104). Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his / her respective computer equipment 102a, and a second party 103b and his / her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party" respectively. The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, e.g. 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 comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal. The client application 105 may be initially provided to the computer equipment 102 of any given party 103 on suitable computer-readable storage medium or media, e.g. downloaded from a server, or 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 a removable optical drive, etc. The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question. Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting. The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all the nodes 104 in the network 106. An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field. Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable linking between transactions. As another example, an account-based transaction contains a "recipient" field (in which a receiving address of an account is specified) and a "value" field (in which an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an outputbased transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an output-based transaction which, typically, includes a signature for the transaction. When both types of transaction are submitted to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contact" refers to a transaction that contains a script configured to perform one or more actions (e.g. send or "release" a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) meeting one or more conditions defined by the smart contact's script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction. 7. UTXO-BASED MODEL Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks. In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104. Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled “Txi". It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled "Txo” in Figure 2. Txo and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice. The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent transaction or "parent") will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and / or node behaviour. One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions. So in the example illustrated, UTXOo in the output 203 of Txo comprises a locking script [Checksig Pa] which requires a signature Sig Pa of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig Pa] contains a representation (i.e. a hash) of the public key Pa from a publicprivate key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo). The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig Pa> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these. When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria). Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain. Typically an input of a transaction contains a digital signature corresponding to a public key Pa. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing). The locking script is sometimes called "scriptRubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred. 8. FURTHER REMARKS Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims. For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104. However it will be appreciated that the bitcoin blockchain is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and / or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above. In preferred embodiments of the invention, the blockchain network 106 is the bitcoin network and bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (recall that these entities are not considered nodes of the preferred bitcoin network 106). In other embodiments of the invention, the blockchain network 106 may not be the bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. For instance, on those other blockchain networks a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes. Even more generally, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element", wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 104. Some embodiments have been described in terms of the blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However proof-of-work is just one type of consensus mechanism and in general embodiments may use any type of suitable consensus mechanism such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a particular example, proof-of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator. It will be appreciated that the above embodiments have been described by way of example only. More generally there may be provided a method, apparatus or program in accordance with any one or more of the following Statements. Statement 1. A computer-implemented method for generating a pairing, the method comprising: obtaining an intermediate value derived based on an initial value provide by a provider; receiving, from the provider, a candidate inverse intermediate value; determining if the candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the target inverse intermediate value is an inverse of the intermediate value; and if the candidate inverse intermediate value is equal to the target inverse intermediate value, computing the pairing based on the intermediate value and the candidate inverse intermediate value. Statement 2. The method of statement 1, wherein the method is implemented in script. Statement 3. The method of statement 1 or statement 2, wherein it is determined if the candidate inverse intermediate value is equal to the target inverse intermediate value by computing a dot product of the candidate inverse intermediate value and the intermediate value; wherein the candidate inverse intermediate value is equal to the target inverse intermediate value if the computed dot product is equal to one. Statement 4. The method of any preceding statement, wherein the method further comprises implementing a previous computational block, wherein the intermediate value is an output of the previous computational block. Statement 5. The method of statement 4, wherein the previous computation block comprises a Miller loop computation of a bilinear pairing computation, wherein the intermediate value is an output of the Miller loop computation. Statement 6. The method of any preceding statement, wherein the initial value comprises a pair of points over which the pairing is computed. Statement 7. The method of any preceding statement, wherein the initial value is a candidate proof, wherein the provider is a proof generator, wherein the method further comprises: implementing a next computational block, wherein the next computation block receives the pairing as an input and verifies the candidate proof based on the pairing. Statement 8. The method of statement 7, wherein the candidate proof is a zero-knowledge proof. Statement 9. The method of any of statements 1 to 6, wherein the initial value comprises a public key and a message, wherein the method further comprises: implementing a next computational block, wherein the next computation block receives the pairing as an input and generates a signature based on the pairing. Statement 10. The method of any of statements 1 to 6, wherein the initial value comprises a signature and a curve generator, wherein the method further comprises: implementing a next computational block, wherein the next computation block receives the pairing as an input and generates a second signature based on the pairing. Statement 11. A computer-implemented method for generating a challenge blockchain transaction, the method comprising: providing, at a first output of the challenge blockchain transaction, a first locking script, wherein the first locking script is configured, when executed together with a first unlocking script of a solution blockchain transaction, wherein the first unlocking script comprises an initial value and a candidate inverse intermediate value, to: obtain an intermediate value derived based on the initial value; obtain, from the first unlocking script, the candidate inverse intermediate value; determine if the candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the target inverse intermediate value is an inverse of the intermediate value; and if the candidate inverse intermediate value is equal to the target inverse intermediate value, compute a pairing based on the intermediate value and the candidate inverse intermediate value; and make the challenge blockchain transaction available to one or more nodes of a blockchain network. Statement 12. The method of statement 11, wherein the first locking script is further configured, when executed together with the first unlocking script of a solution blockchain transaction, to: derive, based on the initial value, the intermediate value. Statement 13. The method of statement 11 or statement 12, wherein the initial value is a candidate proof, wherein the first locking script is further configured, when executed together with the first unlocking script of a solution blockchain transaction, to: verify the proof based on the pairing. Statement 14. A computer-implemented method for satisfying a challenge, wherein the challenge is satisfied based on a pairing derived from an intermediate value and an inverse of the intermediate value, wherein the intermediate value is derived from an initial value the method comprising: receiving, from a verifier, a request for the initial value and a candidate inverse intermediate value; and providing, to the verifier, the initial and the candidate inverse intermediate value, wherein the candidate inverse intermediate value is the inverse of the intermediate value; wherein the challenge is satisfied based on the pairing derived based on the candidate intermediate value and the initial value. Statement 15. The method of statement 14, wherein the method further comprises generating a solution blockchain transaction comprising a first unlocking script, wherein the first unlocking script comprises the initial value and the candidate inverse intermediate value, and making the solution blockchain transaction available to one or more nodes of a blockchain network. Statement 16. The method of statement 14 or statement 15, wherein the method further comprises: computing the candidate inverse intermediate value. Statement 17. The method of any of statements 14 to 16, wherein the initial value is a candidate proof, wherein the method further comprises computing the candidate proof. Statement 18. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 1 to 17. 5 Statement 19. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 1 to 17.

Claims

1. A computer-implemented method for generating a pairing, the method comprising: obtaining an intermediate value derived based on an initial value provide by aprovider;receiving, from the provider, a candidate inverse intermediate value;determining if the candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the target inverse intermediate value is an inverse of the intermediate value; andif the candidate inverse intermediate value is equal to the target inverse intermediate value, computing the pairing based on the intermediate value and the candidate inverse intermediate value.

2. The method of claim 1, wherein the method is implemented in script.

3. The method of claim 1 or claim 2, wherein it is determined if the candidate inverseintermediate value is equal to the target inverse intermediate value by computing a dot product of the candidate inverse intermediate value and the intermediate value;wherein the candidate inverse intermediate value is equal to the target inverse intermediate value if the computed dot product is equal to one.

4. The method of any preceding claim, wherein the method further comprises implementing a previous computational block, wherein the intermediate value is an output of the previous computational block.

5. The method of claim 4, wherein the previous computation block comprises a Miller loop computation of a bilinear pairing computation, wherein the intermediate value is an output of the Miller loop computation.

6. The method of any preceding claim, wherein the initial value comprises a pair of points over which the pairing is computed.

7. The method of any preceding claim, wherein the initial value is a candidate proof, wherein the provider is a proof generator, wherein the method further comprises:implementing a next computational block, wherein the next computation block receives the pairing as an input and verifies the candidate proof based on the pairing.

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

9. The method of any of claims 1 to 6, wherein the initial value comprises a public keyand a message, wherein the method further comprises:implementing a next computational block, wherein the next computation block receives the pairing as an input and generates a signature based on the pairing.

10. The method of any of claims 1 to 6, wherein the initial value comprises a signature and a curve generator, wherein the method further comprises:implementing a next computational block, wherein the next computation block receives the pairing as an input and generates a second signature based on the pairing.

11. A computer-implemented method for generating a challenge blockchain transaction, the method comprising:providing, at a first output of the challenge blockchain transaction, a first locking script, wherein the first locking script is configured, when executed together with a first unlocking script of a solution blockchain transaction, wherein the first unlocking script comprises an initial value and a candidate inverse intermediate value, to:obtain an intermediate value derived based on the initial value;obtain, from the first unlocking script, the candidate inverse intermediate value;determine if the candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the target inverse intermediate value is an inverse of the intermediate value; andif the candidate inverse intermediate value is equal to the target inverse intermediate value, compute a pairing based on the intermediate value and the candidate inverse intermediate value; andmaking the challenge blockchain transaction available to one or more nodes of a blockchain network.

12. The method of claim 11, wherein the first locking script is further configured, when executed together with the first unlocking script of a solution blockchain transaction, to: derive, based on the initial value, the intermediate value.

13. The method of claim 11 or claim 12, wherein the initial value is a candidate proof, wherein the first locking script is further configured, when executed together with the first unlocking script of a solution blockchain transaction, to:verify the proof based on the pairing.

14. A computer-implemented method for satisfying a challenge, wherein the challenge is satisfied based on a pairing derived from an intermediate value and an inverse of the intermediate value, wherein the intermediate value is derived from an initial value the method comprising:receiving, from a verifier, a request for the initial value and a candidate inverse intermediate value; andproviding, to the verifier, the initial and the candidate inverse intermediate value, wherein the candidate inverse intermediate value is the inverse of the intermediate value;wherein the challenge is satisfied based on the pairing derived based on the candidate intermediate value and the initial value.

15. The method of claim 14, wherein the method further comprises generating a solution blockchain transaction comprising a first unlocking script, wherein the first unlocking script comprises the initial value and the candidate inverse intermediate value, and making the solution blockchain transaction available to one or more nodes of a blockchain network.

16. The method of claim 14 or claim 15, wherein the method further comprises: computing the candidate inverse intermediate value.

17. The method of any of claims 14 to 16, wherein the initial value is a candidate proof, wherein the method further comprises computing the candidate proof.

18. Computer equipment comprising:memory comprising one or more memory units; andprocessing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 17.

19. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 17.

Images