EP4736363A1 - Bilinear pairings - Google Patents

Abstract

A computer-implemented method for computing a pairing in script is provided. Computing the pairing comprises at least one sub-computation executed in a target field, wherein the target field is represented as an extension field. A script is generated which comprises at least one subfunction configured to perform the sub-computation as an extension over the extension field.

Description

BILINEAR PAIRINGS TECHNICAL FIELD The present disclosure relates to a computer-implemented method for computing a pairing in script. 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 ^ is a bilinear map defined over two group source elements ^_^, ^_^ in a torsion group ^(^ ) ^∗ ^^ [^]. It maps a pair of elements to an element in a target group ^_^ ≔ ^_^^ : ^: ^_^ × ^_^ → ^_^. 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. Known methods for computing pairings use field arithmetic, such as Karatsuba multiplication, to minimize CPU cycles during the execution. This comes at the cost of increasing the overall number of mathematical operations, that is there are less multiplications at the cost of more additions, which are faster to execute. According to one aspect disclosed herein, there is provided a computer-implemented method for computing a pairing in script, the method comprising generating a script, wherein computing the pairing comprises at least one sub-computation executed in a target field, wherein the target field is represented as an extension field, wherein the script comprises at least one subfunction configured to perform the sub-computation as an extension over the extension field. The use of extension fields for performing portions of the pairing computation allows multiplications, instead of additions, to be implemented, and therefore the size of the script is reduced. 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 ^^{^} = ^^{^} + ^^ + ^ where the coefficients ^, ^ are taken from a finite field ^_^ of ^ elements. An elliptic curve is the set of affine points ^ ≔ (^, ^) that satisfy the above equation along with an extra point at infinity denoted with ^: ^{^^ is the field of definition of the curve, that is, ^, ^ ∈ ^^, and it can be said that ^ is over} _{^^. The coordinates ^, ^ of points ^ ∈ ^|^^ do not necessarily lie in ^^, they can be defined} over an extension field ^_^^ (of ^^{^} elements). Notation. The notation ^| ^_^: ^^{^} = ^^{^} + ^^ + ^ means an elliptic curve over ^_^ with equation ^^{^} = ^^{^} + ^^ + ^. ^ ∶ ^^{^} = ^^{^} + ^^ + ^ is written if the field of definition is understood from context but there is a want to stress which is the cubic equation. ^ 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 ^ ≔ (^, ^) with coordinates ^, ^ in any possible extension field). denotes the set of points whose coordinates are in ^_^. Likewise, ^(^_^^) denotes the set of points with coordinates in the extension ^_^^. 1.1.1 Adding and Doubling Points in Affine Coordinates An elliptic curve ^ forms a group under the ‘tangent and chord’ rule. This addition rule makes ^ a group with identity element the point at infinity ^. 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 ^ ≠ ^ the line ℓ_",# passing through ^, ^ and the vertical line $_% passing through the intersection point with ^ that is not ^ or ^ (i.e., −& in Figure 3, left) are needed. Likewise, to double a point ^, the tangent line ℓ_"," of ^ at ^ and the vertical line $_% passing through the other intersection point with ^ (−& in Figure 3, right) are needed. The ^{formulas are given below, with the left-had formulas corresponding to point addition for} _{^ ≠ ^, and the right-hand formulas corresponding to point doubling for ^ + ^ ≔ 2^ .} 0 ≔ ^{^" − ^" 3^^} ^ ^{0 ≔ "} # _{− ^"} ^{2^"} I_{f ^ ≠ ^ then ^ + ^ ≔} ⁽ _{^%, ^%} ⁾ _{have ^ + ^ ≔ (^%, ^%) have coordinates:} coordinates: ^ ^{− ^ ^ ^ ^" − ^"} _{^% ≔ 0} ^{^} _{− 2^" = 1} ^{" ^"} ^ _{− ^ 3} − 2^_{" ^% ≔ 0 − ^" − ^# = 1 ^ 3} − ^_" − ^_{# # " # − ^"} ^^{% ≔ 0(^" − ^%) − ^ ^% ≔ 0(^" − ^%) − ^ ^ " ^ " −} _{≔ "} ^{− ^} _{" (^" − ^%) − ^" ≔ "} ^{^} _{" (^ − ^ ) − ^# − ^" ^ − ^ " % ^" # "} ^{Note 1. As is shown in section 1.8, the line '",# passing through ^ ^, the tangent line} _{'"," at ^, and the vertical line $% at & 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 * of ^ in affine coordinates. ^ ^{Evaluation of line '} _",# ^{passing through ^ ≔ (^} _" ^{, ^} _" ^{) ≠ ^ ≔ (^} _# ^{, ^} _# ^{) at point * =} (_{^, ^):} ' (^, ^) ≔ ^ − (0^ + ^ − 0^) ^{^" − ^" ^" − ^"} "_{,# " "} ≔ ^ − 1 ^ _{− ^} ^ + ^_" − ^ ^_"3 # _{" # − ^"} ^ Evaluation of tangent line '_","(*) at point * ≔ (^, ^) ' ⁽ _{^, ^} ⁾ _≔ ^{3^^ ^ " 3^"} "_{," ^ −} ⁽ _{0^ + ^" − 0^"} ⁾ _{≔ ^ − 1 2^ ^ + ^" − ^"3 " 2^"} ^ ^{Evaluation of vertical line passing through ^ at point * ≔ (^, ^)} $_{"(^, ^) ≔ ^ − ^"} 1.1.2 Multiplying Points by a Scalar Let any integer - ∈ ℤ and a point ^, the scalar multiplication [-]^ is defined by adding - times ^ to itself (or adding −^ in case - is negative.) [-]^ ≔ ^ + ⋯ + ^. - times 1.2 Projective Coordinates ^{Point addition as described in the above section requires inverting field elements (either} _{^# − ^" or 2^") to compute the scalar 0. Inverting is an expensive operation and therefore} it is desirable to avoid it. This can be achieved switching to projective coordinates. The change of coordinates ^ = ⁵ 6 , ^ = ⁷ 6 allows for working with points ^ ≔ (8, 9, ;) and rewriting the formulas for elliptic curve arithmetic of Figure 3 without inverting field elements. 1.3 The torsion Group and the Embedding Degree ^{Let < = #^ be the order (size) of the elliptic curve. Then, it holds that [<]^ = ^ for every} _{^ ∈ ^. However, points may vanish for smaller scalars. For any divisor ^ of <, the ^-torsion} group is the set of points of order ^: ^[^] ≔ {^ ∈ ^ | [^]^ = ^}. The ^-torsion also forms a group. It is therefore a subgroup of ^. The structure of the ^- ^{torsion group is well known. If ^ is prime to ^, then ^[^] ≅ ℤ@ × ℤ@. This means that} _{#^[^] = ^^ and it has ^ + 1 cyclic subgroups of order ^.} 1.3.1 The Embedding Degree of a Curve ^ Recall from Section 1.1 that (the coordinates of) points of an elliptic curve ^ lie in an extension field ^_^^ of the field of definition ^_^. This also means that torsion points might are in an extension field. The embedding degree B tells where the entire torsion group ^[^] lies. The following two equivalent conditions define B: ^ B is the smallest positive integer such that ^ divides ^^{^} − 1. ^ B is the smallest positive integer such that ^[^] ⊂ ^(^_^^). Cleary, by definition, the embedding degree depends on ^ and ^. Thus, for any choice of ^, ^ it can be seen that the corresponding embedding degree is B(^, ^). 1.3.2 Two Subgroups of Pairings over ^ can be defined over any two subgroups of ^[^]. For efficiency reasons, type- 3 pairings (see Section 1.5.1) are defined over the following two subgroups of the ^-torsion. 1.3.3 The Base-Field ^_^ ≤ ^[^] This is the only subgroup of ^[^] that lies entirely in ^ . The base-field group ^_^ is ^{defined as the ^-torsion elements in the eigenspace of the Frobenius map E: ^ →} _{^, (^, ^) ↦ (^^, ^^). Thus:} ^{Since E fixes a point ^ ∈ ^(^^^), namely ^ = E(^), if and only if ^ ∈ ^(^^), then ^^ =} _{. This group is sometimes called the group of rational points of order ^.} Note 2. What is important to remember is that coordinates of points in ^_^ are always in ^_^, and hence elliptic-curve arithmetic in ^_^is as efficient as possible. 1.3.4 The Zero-Trace Group ^_^ ≤ ^[^] This is a subgroup of ^[^] with an important property. Any point of the torsion group can be mapped to a point in J_^. That is, there exists an explicit (computable) homomorphism ^K^, _{such that for all ^ ∈ ^[^] , ^K^} ⁽ _^ ⁾ _{∈ ^^.} The trace map is defined as K^(^) (^, ^). The trace map actually maps any point in ^ into ^ . The zero-trace elements are points that are mapped to ^. Thus, ^_^ is the eigenspace: _{The ^K^ map mentioned above is the anti-trace map defined as ^K^} ⁽ _^ ⁾ _≔ ^[ _B ^] _{^ − K^(^). It holds that K^H^K^} ⁽ _^ ⁾ _{I = ^, and therefore ^K^ maps points to ^^.} Note 3. Performing arithmetic in ^_^ is expensive because points ^, ^ ∈ ^_^ have coordinates in It is not essential to work with ^_^^ directly, but instead with a smaller field ^_^^/S using the twist of the curve (see Section 1.4.) 1.4 Twisted Curves Let a curve ^/^_^: ^^{^} = ^^{^} + ^^ + ^. The twist ^′ is given by the equation: for some V ∈ ^_^^. Note that ^′ is defined over ^_^^/S , where Z is the degree of the twist. th curves are isomorphic through Ψ: ^ → ^ given ^{^_ _} Bo ^{U b} ≔ (_{`a</sub> ,<sub>`c}). the possibilities Z ∈ {2,3,4,6} is defined as follows: ^ ^{Quadratic twists, Z = 2. They are available for any curve. ^: ^^ = ^^ +} ^_{^ + ^. Thus, for any ^, ^ ∈ ^^.} ^ ^{Cubic twists Z = 3. They are available for curves ^: ^^ = ^^ + ^. Thus ^ =} 0_. ^ ^{Quartic twists. Z = 4. They are available for curves ^: ^^ = ^^ + ^^. Thus} ^ _{= 0.} ^{^ Sextic twists Z = 6. They are available f or curves ^: ^^ = ^^ + ^. Thus ^ =} 0_. An important fact that will be used in the context of pairings is that the preimage under Ψ of the zero-trace group ^_^ ^U is the base-field group ^′_^ in the twist ^ | ^_^^_/g. That ^{is, arithmetic in ^} _^ ^{can be done instead in its twist ^} _^ ^{U and then the result mapped back to} _^^. Note 4. Recall from Section 1.3 that arithmetic in ^_^ is expensive. What is important to remember is that if ^ + ^ for ^, ^ ∈ ^_^ needs to be computed, &′ ≔ Ψ^{N^(}^⁾ + Ψ^{N^}(^) can be computed and then use Ψ⁽&′⁾ = ^ + ^ whenever is needed in the Miller loop of the ^{pairing computation (see Section 1.6). This improves efficiency because N^ Ψ (^) ∈} _{^U ^ have coordinates in ^^^/S (instead of in the larger ^^^). A further improvement can be} provided by avoiding the map Ψ^{N^} by implicitly replacing ^_^ with its twist ^_^ ^U when defining the domain of a pairing, perform point addition (or point doubling) with points ^^U, ^^U ∈ ^′_^, and then map the result to ^_^ via Ψ whenever the result is needed. Computing Ψ only requires two multiplications. 1.5 Pairings A pairing ^ is a bilinear map defined over two group source elements ^_^, ^_^ in the torsion group ^(^ )[^]. It maps ^∗ ^_^ a pair of elements to an element in the target group ^_^ ≔ ^_^^ : ^: ^_^ × ^_^ → ^_^, such that: 1. For each ('_^, '_^) ∈ ^_^ × ^_^ and each (^, ^) ∈ ℤ^{^} : ^⁽ _{^ ⋅ '^, ^ ⋅ '^} ⁾ _{= ^} ⁽ _{'^, '^} ^)ij _. 2. If ('_^, '_^) is a generator of ^_^ × ^_^ then ^('_^, '_^) is a generator of ^_^. 3. The pairing is efficiently computable. 1.5.1 Types of Depending on how the source groups ^_^, ^_^ are chosen there are three types of pairings. Type 1. The symmetric pairing: thus the base-field group (see Section 1.3). The curve must be supersingular, meaning there exists a distortion map l that takes points in into ^H^_^^I. It is known how to hash into [^] and sample random elements. All known pairings (see Section 1.3) require ^ and ^ in different groups, so the _{pairing is defined as ^} ⁽ _{^, ^} ⁾ _{≔ . The drawback is that the condition ^ being} supersingular hinders the efficiency of the pairing. Type [^], the base-field group and ^_^ In this setting the existence of an isomorphism from ^_^ on is required, namely the trace map n^ (see Section 1.3). This ^{means that ^^ cannot be the zero-trace group (because it is mapped to the identity element} _{^ via n^). The drawback is that it is not clear how to hash or sample random elements in ^^,} which restricts functionality. One benefit is that proving security is possible due to the efficient isomorphism n^. Type ≔ H^_^I[^], the base-field group and ^_^ ≔ o^{N^}(^H^_^^I[^] ∩ B^ ^(K^ − [^])), the preimage of the zero-trace group under the twist o. There is not known (efficient) isomorphism from ^_^ on ^_^, which affects security, but in this setting, it is clear how to hash and sample random elements in ^_^ (using the anti-trace map ^K^). 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 ^, ^ consists in constructing a function p_q," related to ^ and then evaluate it at point ^. The selected p_O," is a Miller function and it is defined as: The above formula says that a Miller function p_q," has a zero at ^ with multiplicity <, a pole at [<]^, and a pole at ^ with multiplicity < − 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: X} ⁽ _{^, ^} ⁾ _≔ ⁽ ₋₁ ^)@ _{p@,"(^)/p@,#(^).} Tate pairing: ^{Optimal Ate pairing: ^s^t(^, ^) for some ℓ such that log(ℓ) ≈} _{log (^)/o.} ^ The Weil and Tate pairing require finding a function p_@,", which roughly has a degree of ^, the order of the groups ^_^, ^_^. For cryptographic applications, ^ is large, say 256 bits or more, and hence computing a function of degree ≈ 2^{^zY} is a huge task. In Section 1.7, it is shown how to compute this efficiently (i.e. in ≈ ~^' (^) steps). ^ The Weil pairing is typically not used because it requires computing two Miller functions (evaluated at ^ and at ^). The Tate pairing and the optimal Ate pairing require just one function evaluation (at ^). ^ 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 − 1)/^ does not change and the Miller function depends on ^ (instead of ^). In the type 3 setting, ^ is a point in the twist of the zero-trace group, hence with coordinates in . 1.7 Pairing-Friendly Curves An elliptic curve has parameters ^, n, ^, B: ^ ^: A prime integer. The size of the underlying field ^_^. ^ ^ : The size of the three groups ^_^, ^_^ ^ B the embedding degree ^ n : The trace of Frobenius. (Needed for the optimal ate pairing only) As the pairing entails performing arithmetic in an elliptic curve is ‘pairing-friendly’ if the embedding degree B is not too large. Typically, B = 6,12,24. For cryptographic applications, it must be difficult to compute the elliptic-curve discrete logarithm (ECDLP) in the source groups [^] of order ^ and the discrete logarithm problem (DLP) in the target group, namely the ^-roots of unity ^_@ ≤ ^^∗ ^_^ for the optimal ate pairing. This imposes a trade-off between the size of ^ and the size of ^, The DLP in ^^∗ ^_^ 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 ^^∗ ^_^ and ^_O is ^^{^^H^^I} @₎ = ^{^^s^(^)} ^_{^^ ( ^^^ (@)} The concrete value of this ratio is determined by the progress on solving these two problems. The parameter ^ measures how efficient arithmetic in the elliptic curve is. Ideally, one wants ^ = 1. Note 6. Larger values of ^ means working with a larger ^_^. The focus herein is to minimize the number of instructions and not CPU cycles in the pairing computation. Thus, larger ^ 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 ^, ^, n are parameterized as polynomials ^} ⁽ _^ ⁾ _{, ^} ⁽ _^ ⁾ _{, n(^). For a concrete value} of ^ ∈ ℤ , values ^, ^, n can be 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: B = 12, ^ ≈ 1.5 (^{^ − 1)^(^W ^ ) ^(^) = − ^ + 1 + ^, ^(^) = ^W − ^} 3 ^{^ + 1,} n_{(^) = ^ + 1} Table 1: Parametrisation of BLS12 curves. 1.8 Miller Algorithm Recall from Section 1.6 that the optimal Ate pairing requires two steps, or functions. First compute p ≔ then exponentiate p p can be computed iteratively using the formulas: _{pQ = 1 ∈ ^^^ p} ^'[O]#,# O_{^^,# ≔ pO,# ⋅ $[O^^]#} Above, p_^," is the Miller function, '_",# is the line passing through points ^, ^ and $_" the vertical line at ^. Miller observed that the above gives raise to ‘double-and-add’ algorithm ^{to compute p@,# in roughly ~^' (^) steps. To avoid storing p@,# (which is a function of degree} _{^), the intermediate functions pO,# are evaluated at (the fixed) point ^ iteratively too.} Thus, Miller algorithm accumulates iteratively using the above formulas in a ‘double- and-add’ style, and after that exponentiates p ^{^^N^} 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 $[O^^]#,} _{$[^O]#, 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 B = 12, and the curve has equation:} ^ _{∶ ^^ = ^^ + ^,} with ^ = 4. Recall from Table 1 that parameters ^, ^ are derived accordingly to the B^{LS12-381 polynomials and curve parameter:} ^ _{= −2Y^ − 2Y^ − 2YQ − 2z^ − 2W^ − 2^Y.} S^{ince ^ = 0 it admits a sextic twist ^U (see Section 1.4) with equation:} ^_{U: ^^ = ^^ + ^′.} ^{Here ^U = ^/ξ where ^ is a non-square, non-cube element of ^^a. Assuming ^ = 3 -^Z 8,} _{^ ≔ 1 + √−1 .} 2.1 Fields Representation The underlying field of the target group (^_^^a) is represented with three different towers of extension fields. ^{Representation 1 (Quadratic extension)} ^_{^^a = ^^^[X]/(X^ − $)} In this representation, elements in ^_^ ^{^a} are given as a pair of elements in ^_^ ^{^} (which are triplets of ^_^ ^a elements). Representation 2 (Sextic extension) ^{^ a = ^ [^]/( ^ ^ ^ ^ + 1 )} ^_{^^a = ^^a[n]/(nY − ^ )} Here elements in ^_^^a are given as a vector of six elements in ^_^a . ^{Representation 3 (Cubic extension)} ^_{^^a = ^^^[^]/(^^ − ^ )} In this last representation elements in ^_^ ^{^a} are given as a triplet of elements in ^_^ ^{^} (which are pairs of ^_^a elements). Herein, ^_^ may be referred to as a first filed, ^_^a a second field, ^_^^ a third field, ^_^^ a fourth field, and ^_^^a fifth field. The fifth field ^_^^a is the target field. 2.1.1 In ^_^^a , 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 ^_^^a is a quadratic extension over ^_^^ (and ^_^^ is a ^{cubic extension over ^^a , and ^^a is a quadratic extension over ^^). That is, arithmetic in} _{^^a and in ^^^ is needed. Namely, addition subtraction, multiplication, negation, and} inversion. Further, in this representation inversion of unitary ^_^^a elements ^ + ^X (that arise during the computation of the second part of the final exponentiation) can be computed by simple conjugation (^ + ^X)^{N^} ∶= (^ − ^X). The second representation (^_^^a as a sextic extension over ^_^a ), is useful to exponentiate to powers of ^ using the Frobenius operator (for the final exponentiation). Frobenius is significantly more efficient than the standard square-and-multiply algorithm for ^ powers, requiring only 5 multiplications (with precomputations). The third representation (^_^^a as a cubic extension over ^_^^ ), will be used to perform multiplication in ^_^ ^{^a} 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 ^_^ ^{^a} 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 Between 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 p element) is also switched from the first representation to the third one (cubic extension) before entering the final exponentiation. ^{^^a elements are pairs of ^^ elements. Ultimately, ^^^a elements are always vectors of six} _{^^a 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 ^_^^a . The table below provides the precise permutation of the coefficients to switch among representations.

Example. The switch between quadratic and sextic extension representations can be ^{derived as set out below. Let 8 = ^^ + ^^X be an element of the quadratic extension} _{^^^a = ^^^[X]/(X^ − $). The coefficients are elements in ^ ^ ^^ ≔ ^^^[X]/(X − $), and} ^{can be written as:} ^ _{≔ ^ + ^$ ^ ^ + ^$} where ^, ^, ^, Z, ^, p ∈ ^_^a. Using that n = X and $ = n^{^}, 8 can be expressed in the sextic ^{extension ^^^a ≔ ^^a[n]/(nY − ^ ) by just switching around the ^^a-coefficients:} 8 _{≔ ^Q + ^^X = ^Q + ^^n = (^ + ^$ + ^$^) + (Z + ^$ + p$^)n} = ^ + Zn + ^n^{^} + ^n^{^} + ^n^W + pn^z 2.2 Arithmetic in ^_^^ – The Twisted Curve Elements in ^_^a are polynomials 8 of degree one modulo ^^{^} + 1.8 can be identified with ^{its two ^^-coefficients 8  ≔ (^Q, ^^).} Addition, subtraction, and scalar multiplication in ^_^a are defined in the natural way. Thus, addition and subtraction is component-wise, and scalar multiplication multiplies each component by the scalar 0 ∈ ^_^a. All operations are done modulo ^. Add in ^_^a Negate in ^_^a I_{nput: 8   ≔ (^Q, ^^), 9   ≔ (^Q, ^^) Input: 8   ≔ (^Q, ^^) Output: 8   + 9   ≔ (^Q + ^Q, ^^ + ^^) Output: −8   : = (−^Q , −^^)} Subtract in ^_^ ^a Multiply by scalar in ^_^a I_{nput: 8   ≔} ⁽ _{^Q, ^^} ⁾ _{, 9   ≔ (^Q, ^^) Input: 8   ≔ (^Q, ^^), 0 Output: 8   − 9   ∶= (^Q − ^Q, ^^ − ^^) Output: 08   : = (0^Q, 0^^)} Multiplication of elements in ^_^ ^a ≔ ^_^ ^[^^]/(^^{^} + 1) is defined in the table 5 below. Squaring and multiplication by ^ ≔ ^ + 1 as separate routines are also described. Multiply in ^_^a Square in ^_^ ^a I_{nput: 8   ≔ (^Q, ^^), 9   ≔ (^Q, ^^) Input: 8   ≔} ⁽ _{^Q, ^^} ^{) Output: 8  ⋅ 9  ≔ (^Q^Q − ^^^^, ^Q^^ +} _{Output: 8}  ^{^} _∶= ⁽ _^Q ^{^} _{− ^^} ^{^} _{, 2^Q^^} ⁾ ^_^^Q) Multiply by ^ ≔ 1 + ^ in ^_^ ^a Invert in ^_^a I_{nput: 8   ≔} ⁽ _{^Q, ^^} ⁾ _{Input: 8   ≔ (^Q, ^^) Output: 8   ⋅ ^ ∶= (^Q − 1 , ^Q+^^) Output: 8}  ^{N^} _{∶= ^^(^Q , −^^)} 1. ^_Q ≔ ^_Q ^{^} 2. ^_^ ≔ ^_^ ^{^} 3. ^_Q ≔ ^_Q + ^_^ // Always nonzero 4. ^_^ ≔ ^_Q ^{N^} // Inversion in ^_^ 2.3 Arithmetic in ^_^^ ^{Elements in ^ ^ = ^ a[^]/(^^ − ^) are polynomi ^ ^ ^ als 8 of degree 1 modulo ^ −} _{8 is identified with its two ^^} ^a _{-coefficients 8   ≔} ⁽ _{^̅Q, ^̅^} ⁾ _{. Thus, ^̅O ∈ ^^} ^a _{. The formulas for} arithmetic in ^_^^ in terms of ^_^a arithmetic are given in the table below. Subtraction, negation, and inverse in ^_^^ are omitted as these are not needed for computing a pairing. Multiply in ^_^^ Square in ^_^^ I_{nput: 8   ≔ (^̅Q, ^̅^), 9   ≔ (^ Q, ^ ^) Input: 8   ≔ (^̅Q, ^̅^) Output: 8   ⋅ 9   ≔} ⁽ _{£Q̅, £^̅} ⁾ _{Output: 8}  ^{^} _∶= ⁽ _^̅Q ^{^} _{− ^̅^} ^{^} _{, 2^̅Q ⋅ ^̅^} ⁾ ^ £_Q̅ ≔ ^̅_Q ⋅ ^ _Q + ^̅_^ ⋅ ^ _^ ⋅ ^ ^ £_^̅ ≔ ^̅_Q ⋅ ^ _^ + ^̅_^ ⋅ ^ _Q Multiply by scalar in ^_^^ Multiply by ^ in ^_^^ I_{nput: 8   ≔ (^̅Q, ^̅^), 0̅ Input: 8   ≔ (^̅Q, ^̅^) Output: 0̅8   : = (0̅ ⋅ ^̅Q, 0̅ ⋅ ^̅^) Output: 8   ⋅ ^ ∶=} ⁽ _{^̅^ ⋅ ^, ^̅Q} ⁾ Add in ^_^^ I_{nput: 8   ≔} ⁽ _{^̅Q, ^̅^} ⁾ _{, 9   ≔} ⁽ _{^ Q, ^ ^} ⁾ O_{utput: 8   + 9   : = (^̅Q + ^ Q, ^̅^ + ^ ^)} 2.4 Arithmetic in ^_^^ ^{Elements in ^ ^ = ^ a[$]/($^ − are poly ^ ^ ^ nomials 8 of degree 2 modulo $ −} 8 can be identified with its three ^_^a-coefficients 8  ≔ (^̅_Q, ^̅_^, ^̅_^). The formulas for arithmetic in ^_^ ^{^} in terms of ^_^ ^a arithmetic are given in table 7 and table 8. Add in ^_^^ Negate in ^_^^ I_{nput: 8   ≔ (^̅Q, ^̅^, ^̅^), 9   ≔ (^ Q, ^ ^, ^ ^) Input: 8   ≔ (^̅Q, ^̅^, ^̅^) Output: 8   + 9   ≔} ⁽ _{^̅Q + ^ Q, ^̅^ + ^ ^, ^̅^ + Output: −8   : =} ⁽ _{−^̅Q, −^̅^, −^̅^} ⁾ Subtract in ^_^^ Multiply by scalar in ^_^^ I_{nput: 8   ≔} ⁽ _{^̅Q, ^̅^, ^̅^} ⁾ _{, 9   ≔} ⁽ _{^ Q, ^ ^, ^ ^} ⁾ _{Input: 8   ≔ (^̅Q, ^̅^), 0̅ Output: 8   − 9   ≔} ⁽ _{^̅Q − ^ Q, ^̅^ − ^ ^, ^̅^ − Output: 0̅ ⋅ 8   : = (0̅ ⋅ ^̅Q, 0̅ ⋅ ^̅^)} Multiply in ^_^ ^{^} Square in ^_^ ^{^} I_{nput: 8   ≔} ⁽ _{^̅Q, ^̅^, ^̅^} ⁾ _{, 9   ≔} ⁽ _{^ Q, ^ ^, ^ ^} ⁾ _{Input: 8   ≔} ⁽ _{^̅Q, ^̅^, ^̅^} ⁾ O_{utput: 8   ⋅ 9   ≔ (£Q̅, £^̅, £^̅) Output: 8}  ^{^} _{∶= (£Q̅, £^̅, £^̅)} ^ £_Q̅ ≔ ^̅_Q ⋅ ^ _Q + (^̅_^ ⋅ ^ _^ + ^̅_^ ⋅ ^ _^) ⋅ ^ ^ £_Q̅ ≔ ^̅_Q ^{^} + 2^̅_^ ⋅ ^̅_^ ⋅ ^ ^ £_^̅ ≔ ^̅_Q ⋅ ^ _^ + ^̅_^ ⋅ ^ _Q + ^̅_^ ⋅ ^ _^ ⋅ ^ ^ £_^̅ ≔ 2^̅_Q ⋅ ^̅_^ + ^̅_^ ^{^} ⋅ ^ ^ £_^̅ ≔ ^̅_Q ⋅ ^ _^ + ^̅_^ ⋅ ^ _^ + ^̅_^ ⋅ ^ _Q ^ £_^̅ ≔ 2^̅_Q ⋅ ^̅_^ + ^̅_^ ^{^} ^ Multiply by $ in ^_^^ Invert in ^_^^ I_{nput: 8   ≔ (^̅Q, ^̅^, ^̅^) Input: 8   ≔ (^̅Q, ^̅^, ^̅^) Output: 8   ⋅ $ ∶= (^̅^ ⋅ ^, ^̅Q, ^̅^) Output: 8}  ^{N^} _{∶= (£Q̅, £^̅, £^̅)} 1. ^  ≔ ^̅_Q ^{^} − ^̅_^ ⋅ ^̅_^ ⋅ ^ 2_{. ^   ≔ ^̅^} ^{^} _{⋅ ^ − ^̅Q ⋅ ^̅^} 3. ^̅ ≔ ^̅_^ ^{^} − ^̅_Q ⋅ ^̅_{^ 4. Z̅ ≔ ^̅^ ⋅ ^ ⋅ ^̅ + ^̅Q ⋅ ^  + ^̅^ ⋅ ^ ⋅ ^}   5. ^̅ ≔ Z̅^{N^} // Inversion in ^_^a ^ £_Q̅ ≔ ^  ⋅ ^̅ ^ _{£^̅ ≔ ^   ⋅ ^̅} ^ £_Q̅ ≔ ^̅ ⋅ ^̅ 2.5 Arithmetic in ^_^¤^ – 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, ^_^^a is given as a quadratic extension over ^_^^ . Namely, ^_^ ^{^a} = ^_^ ^{^[}X^]/(X^{^} − $). In this representation, elements are polynomials 8 of d^{egree 1 modulo X^ − $ with coefficients in ^^^ ≔ ^^a[$]/($^ − ^). Thus:} 8 _{is identified with its two ^^} ^{^} _{-coefficients 8   ≔} ⁽ _{^Q, ^^} ⁾ _{. Recall that ^O ∈ ^^} ^{^} _{is a vector of three ^^} ^a _{elements, ^̅Q ≔ (^ , ^   , ^̅) and ^̅^ ≔ (Z̅, ^̅, p)̅. Thus, 8   is a vector of six ^^} ^{a coefficient, seen as a pair of triplets:} The formulas for multiplication, squaring and inversion in ^_^^a in terms of ^_^^ arithmetic are given in Table 9. Inversion of unitary elements is done via conjugation, which is very efficient. This is an advantage of representing ^_^ ^{^a} as a quadratic extension in the final exponentiation. Multiply in ^_^^a Square in ^_^^a I_{nput: 8   ≔ (^̅Q, ^̅^), 9   ≔ (^ Q, ^ ^) Input: 8   ≔ (^̅Q, ^̅^) Output: 8   ⋅ 9   ≔ (^̅Q ⋅ ^ Q − ^̅^ ⋅ ^ ^, ^̅Q ⋅ ^ ^ + ^̅^ ⋅ ^ Q) Output: 8}  ^{^} _{∶= (^̅Q} ^{^} _{− ^̅^} ^{^} _{, 2^̅Q ⋅ ^̅^)} Invert in ^_^^a Conjugate // Inversion of unitary elements I_{nput: 8   ≔ (^̅Q, ^̅^) Input: 8   ≔} ⁽ _{^̅Q, ^̅^} ⁾ O_{utput: 8}  ^{N^} _{∶= ^ ^} ⁽ _{^̅Q , −^̅^} ⁾ _{Output: 8} ^¥ _{∶= (^̅Q, −^̅^)} 1. ^ _Q ≔ ^̅_Q ^{^} 2. ^ _^ ≔ ^̅_^ ^{^} 3. ^ _Q ≔ ^ _Q − ^ _^ ⋅ $ // Always nonzero 4. ^ _^ ≔ ^ _Q ^{N^} // Inversion in ^_^^. 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. In the hard part of the final exponentiation, exponentiation to ^ and ^/2 is required (^ is the curve parameter). These exponentiations are done through the generic algorithm ‘signed square-and-multiply’. Thus, the exponent ^ (either ^ or ^/2) is given in binary signed format, i.e. with bits in ^_O ∈ {−1,0,1}. The algorithm can only be used to exponentiate unitary elements (i.e. in the hard part of the final exponentiation). See Table 10. E^{xponentiate unitary element in ^} _^ ^{^a // Fixed exponent ^ = ∑ℓ} O_P ^N Q^{^ ^} _O ^{2O with ^} _O ^∈ {_−1,0,1} Input: p ∈ ^_^^a ≔ ^_^^[X]/(X^{^} − $ ) s.t. p^{^^^^} = 1 (unitary element) Output: p^¦ ∈ ^_^^a 1. ' ≔ p 2. For ^ ≔ ℓ − 2 down to 0 do: 3. ' ≔ '^{^} 4. If ^_O = 1 then ' ≔ ' ⋅ p 5. Else if ^_O = −1 then: ' _{≔ ' ⋅ p} ^§ _{// Compute inverse of unitary p via conjugation: p} ^{N^} _{= p} ^§ 6. End if 7. End for 8. Output ' Table 10: Exponentiation of unitary elements in ^_^^a. Multiplication, squaring, and conjugation are defined in Table 9. 2.5.3 Multiplication as a Cubic Extension During the Miller loop, different formulas for multiplying in ^_^¤^ are used that exploit the sparsity of the results of the line function evaluations. For this, ^_^¤^ is represented as a _{cubic extension over ^ Namely ^ ^a ≔ ^ ^} ^[ _^ ^{] ^} ^_{^ ^ ^ /(^ − ^ ). Thus,} ^{elements in ^ ^a are see ^ ^ ing as polynomials 8 of degree 2 modulo ^ − ^.} In this representation, 8 is identified with its three ^_^^-coefficients 8  ≔ (^̅_Q, ^̅_^, ^̅_^). Since each ^̅_O ∈ ^_^^ is a vector of two ^_^a elements, 8  is a vector of six ^_^a coefficients, seen as a ^{triplet of pairs:} The results ¨ of the line calculations are sparse elements, with half of their coefficients set ^{to zero (see Section 2.7 below). Namely, ^^^a elements are given in the form:} *_{̅ = ((^ , ^ ), (^̅, 0 ), (0 , 0 )), where the third ^^^ element is zero = (0   , 0   ), and so is the second component of the} ^{second ^^^ element Z̅ = 0 . These are held in vectors of just three ^^a-coefficients:} _{8 © ≔ H^ , ^ , ^̅I // Sparse representation of ¨} 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 ^_^^ coefficient ^{set to zero, p̅ = 0 ) of the form:} _{Also, during the Miller loop, either a sparse *} ^̅ _{or a somewhat sparse *} ^̅U _{is multiplied by a standard (dense) element 8   . In this way, the sparsity of *} ^̅ _{and *} ^̅U _{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 ^_^a arithmetic.

Multiply sparse by sparse in ^_^^a. ^{Multiply somewhat-sparse by somewhat-sparse in} ^_^^a Input:     Input: ^ ⁸ _©,^ ^{≔ H^}  _^ ^{, ^} _^ ^{, ^} _^̅ ^{I // sparse ^} _^ ^{+ ^} _^ ^{^ +} ^_{^^ ^ 8   ©ª,^ ≔ (^ ^, ^   ^, ^^̅, Z̅^, ^̅^) // somewhat- ^ 8   ©,^ ≔ H^ ^, ^   ^, ^^̅I // sparse sparse ^ ^ + ^   ^^ + H^^̅ + Z̅^^I^ + ^̅^^} ^{^} _{Output: 8   ©ª ≔ 8   ©,^ ⋅ 8   ©,^ ≔ (^ ^, ^   ^ 8}   ^_{, ^^̅, Z̅, ^̅)) ©ª,^ ≔ (^ ^, ^   ^, ^^̅, Z̅^, ^̅^) // somewhat-} sparse /^{/ somewhat-sparse ^ ^ + ^ ^^ + ^^̅^ +} _{Output:8   ©ª,^ ⋅ 8   ©ª : = (^  , ^   , ^ , Z̅ , ^̅ , p} ^̅ _{) Z̅^^ + ^̅^^ ,^ ^ ^ ^̅ ^ ^} // ^ + ^ ^{^} ^ _{^ ^ ≔ ^ ^^ ^ + ^   ^ ^}^ + ^_^^ + Z_^^^ + (^_^ + p^)^ ^_{^   ^ ^ ^   ^ ≔ ^   ^^ ^ + ^ ^^   ^ ^ ^ ^ ^ ≔ ^ ^^ ^ + ^   ^^   ^^ + ^̅^Z̅ ^ + Z̅ ^̅ ^ ^̅ ^̅ ^} + ^ _^^_{^̅ ^ ^   ^ ≔ ^   ^ ^ ^} ^ ^ ≔ ^^ _{^^ ^ + ^ ^^   + ^̅ ^ + ^ ^̅ ^̅   ^   ^ ^ ^ ^̅ ^̅ ≔ ^^̅^ ^ + ^ ^^ + Z̅ ^   ^̅ ^̅ ^ + ^   ^ ^ Z̅ ≔ ^ ^ + ^ ^ ^ ^ Z̅ ^ ^̅ ^̅ ^ ^ ^ ^   ^̅ ^   ^ ^ ^ ^} ^ ^̅ ≔ ^^ _{^ Z̅ ≔ Z̅ ^  + c  b + b^^^̅ + ^ ^Z̅^ + ^̅^^̅^} ^ ^̅_^ ≔ ^̅_^^ _^ + ^_^̅^_^̅ + Z̅_^Z̅_^^ + ^ _^^̅_{^ ^ p} ^̅ _{≔ ^̅^^   ^ + Z̅^^^̅ + ^^̅Z̅^ + ^   ^^̅^} Multiply sparse by somewhat-sparse in ^_^^a Multiply somewhat-sparse by dense in ^_^^a Input: Input: ^ _{8   © ≔ (^ ^, ^   ^, ^^̅) // sparse ^ 8   ©ª ≔ (^ ^, ^   ^, ^^̅, Z̅^, ^̅^) // somewhat- ^ 8   ©ª ≔ (^ ^, ^   ^, ^^̅, Z̅^, ^̅^) // somewhat-} sparse sparse _{^ 8   g ≔ (^ ^, ^   ^, ^^̅, Z̅^, ^̅^, p^̅) // dense Output: 8   © ⋅ 8   ©ª: = (^ ^, ^   ^, ^^̅, Z̅^, ^̅^, p} ^̅ _{) Output: 8   ©ª ⋅ 8   g: = (^ ^, ^   ^, ^^̅, Z̅^, ^̅^, p^̅)} //dense // ^_^ + ^_^^ + ^_^^ + Z_^^^ + (^_^ + p_^^)^^{^} ^ _{^ ^ ≔ ^ ^^ ^ + ^   ^^   ^^} ^{^ ^}  _^ ^{≔ ^}  _^ ^{^}  _^ ^{+ ^}  _^ ^{^}  _^ ^{^ + ^̅ Z̅ ^ + Z̅ ^̅ ^ +}   _{^   ^ ^ ^ ^ ^ ^ ≔ ^^^ ^ + ^ ^^   ^ + ^^̅^̅^ ^^̅p^ ^ ^^̅ ≔ ^^̅^ ^ + ^ ^^^̅ + ^   ^Z̅^^ ^ ^   ^̅ ^ ≔ ^   ^^ ^ + ^ ^^   ^ + ^̅^^^̅ + ^^̅^̅^ + Z̅^p^̅^ ^ Z̅^ ≔ c ^b   ^ + b   ^^^̅ + ^ ^Z̅^} ^{^ ^^̅ ≔ ^^̅^ ^ + ^ ^^^̅ + Z̅^^ ^^ + ^ ^Z̅^^ +} ^ ^̅_^ ≔ ^_^̅^_^̅ + ^ _^^̅_{^ ^̅^p^̅^ ^ p} ^̅ _{≔ ^^̅Z̅^ + ^   ^^̅^ ^ Z̅^ ≔ Z̅^^ ^ + c ^b   ^ + b   ^^^̅ + ^ ^Z̅^ + ^̅^^̅^} ^ ^{^̅^ ≔ ^̅^^ ^ + ^^̅^^ + Z̅ Z̅ ^ + ^  ^̅ +   ̅ ^ ^ ^ ^} ^_{^p^̅^ ^ p} ^­ _{^ ≔ ^̅^^   ^ + Z̅^^^̅ + ^^̅Z̅^ + ^   ^^̅^ + ^ ^p^̅} Table 11 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. 2.6 EC Arithmetic in the Twisted Curve ®′(^_^^) Let two points K ≔ (^̅_^, ^ _^, £_^̅), ^ ≔ (^̅_^, ^ _^) in the twisted curve ^′(^_^ ^a). Thus K, ^ are in the second source group ^_^. Note that K is in projective coordinates, and ^ in affine coordinates. Regardless of how they are expressed, points in the twisted curve ^′(^_^ ^a) have coordinates in ^_^a. The points K + ^ and ^[2^]K can be computed according to the formulas shown in Table 13. 2.7 Evaluation Line Functions in the Target Field ^_^¤^ Let two points K ≔ (^̅_^, ^ _^, £_^̅), ^ ≔ (^̅_^, ^ _^) in the twisted curve ^′(^_^ ^a) in projective and affine coordinates, respectively. Also, let a point ^ in affine coordinates. The point ^ is in the first source group and has coordinates in ^_^. The points K, ^ are in the second source group ^_^ and have coordinates in ^_^a. ^{2.7.1 Line for Point Addition '} _¯(^),¯(#) The evaluation at ^ of the line '_^(^),^(#) that passes through the untwisted points Ψ(K) is computed. The result of the evaluation in ^_^¤^ ≔ ^_^^[^]/(^^{^} − ^ ) can be expressed as follows: ^{The result is a sparse polynomial only with three nonzero ^^a-coordinates. Therefore,} _{can be represented in sparse form as a vector of three ^^a-coordinates:} Table 14 provides explicit formulas which can be used to calculate the coefficients ^ , ^ , ^̅. 2.7.2 Line for Point ^{Likewise, the formula to compute the evaluation of the tangent line '^(^),^(^) at ^ in} _{^^¤^ ≔ ^^^[^]/(^^ − ^ ) is given by:} ^{Again, '^(^),^(^)(^) can be represented succinctly as a vector of three ^^a-coordinates} _{(^ U, ^ U, ^̅U). See Table 15 for the formulas to calculate coefficients ^ ′, ^ ′, ^̅′.} Evaluate point doubling line I_{nput: K ≔} ⁽ _{^̅, ^ , £̅} ⁾ _{, ^ ≔} ⁽ _{^", ^"} ⁾ O_{utput: '^(^),^(^)} ⁽ _^ ⁾ _{≔ (^}  ^U _{, ^}  ^U _{, ^̅} ^U _{): // sparse form} ^ ^ ′ ≔ −2^_^^ _^ ⋅ £_{^̅ ^ ^   ′ ≔ 3^} ^U _{⋅ £^} ^{^} ̅ _{− ^ ^} ^{^} ^ ^̅′ ≔ 3^_"^̅_^ ^{^} Where ^′ ≔ ^^^{N^} and ^^{N^} ≔ (¸ + 1)^{N^} = (^{^ ^} ^ , −_^) in ^_´a ≔ ^_^[¸]/(¸^{^} + 1). 2.8 Exponentiation via Frobenius Endomorphisms During the final exponentiation, powers of the form 8^{^}, 8^{^a} , 8^{^c} for a given ^_^^a-element 8 ^{are computed. These computations can be done efficiently, in just 5 multiplications over} _{^^a, as set out below. ^^^a is represented as a quadratic extension (first representation), thus 8 ≔ ^Q + ^^n. To} compute ⁽^_Q + ^_^n^{)^}, when expanding out the expression, powers less than ^ vanish because they have a coefficient that is multiple of ^ (the field characteristic). M ^{M Next, for an ^ a a ¹^ ^a element ^ ≔ ^ ^ ^ ^ + ^^^, it can be seed that ^ = ^ and ^ = ^º, where} _{^º ≔ ^ − ^ ^ is the conjugate of ^. Last, n = X, and that in the first repre Y ^ ^ sentation n =} so n^{^} = ^^{(^N^)/Y}n, which means that for ^ = ^{Therefore: 8^ = (^ + ^ X)^ ( )^ Q ^ = ^Q + ^^n} = _{(^ + Zn + ^n^ + ^n^ + ^nW + pnY)^ // Switch to sextic extension (See} T^{able 3.)} _{Switch back} to quadratic extension Computing 8^{^a} and 8^{^c} is done similarly. See Table 16 for the formulas. It is observed that the ^_^a-elements »_^,O for ¼ = 1,2,3, ^ = 1,2,3,4,5 are precomputed and hard-coded it in the algorithms. ^-Frobenius // Define »_^,O ≔ ^^{O(^N^)/Y} ^^{^}-Frobenius // Define »_^,O ≔ »_^,O ⋅ »º_^,O Input: 8 ≔ (^̅_^, ^̅_^) ∈ ^_^^[X]/(X^{^} − $) _{Input: 8 ≔} ⁽ _{^̅^, ^̅^} ⁾ _{∈ ^^} ^{^[} _X ^] _/(X ^{^} _{− $) ^ ^̅^ ≔} ⁽ _{^, ^, ^} ⁾ ^ ^̅_^ ≔ (^, ^, ^) ^ ^̅_^ ≔ (Z, ^, p) _{^ ^̅^ ≔} ⁽ _{Z, ^, p} ⁾ Output: 8^{^} ≔ (^̅′_^, ^̅′_^) ∈ ^ ^a ^^[X]/(X^{^} − $) _{Output: 8} ^{^} _≔ ⁽ _{^̅′^, ^̅′^} ⁾ _{∈ ^^} ^{^[} _X ^] _/(X ^{^} _{− $) ^ ^̅′^ ≔ H^º, ^} ^¥ _{⋅ »^,^, ^̂ ⋅ »^,WI} ^{^ ^̅′} _^ ^≔ _H ^{^, ^ ⋅ »} _^,^ ^{, ^ ⋅ »} _{^,WI ^ ^̅′^ ≔ HZ} ^§ _{⋅ »^,^, ^̂ ⋅ »^,^, p} ^§ _{⋅ »^,zI} ^ ^̅′_^ ≔ HZ ⋅ »_^,^, ^ ⋅ »_^,^, p ⋅ »_^,zI ^^{^}-Frobenius // Define »_^,O ≔ »_^,O ⋅ »_{^,O Input: 8 ≔} ⁽ _{^̅^, ^̅^} ⁾ _{∈ ^^^} ^[ _X ^] _/(X ^{^} _{− $)} ^ ^̅_^ ≔ (^, ^, ^) ^ _{^̅^ ≔} ⁽ _{Z, ^, p} ⁾ O_{utput: 8} ^{^} _{≔ (^̅′^, ^̅′^) ∈ ^^^} ^[ _X ^] _/(X ^{^} _{− $) ^ ^̅′^ ≔ H^º, ^} ^¥ _{⋅ »^,^, ^̂ ⋅ »^,WI ^ ^̅′^ ≔ HZ} ^§ _{⋅ »^,^, ^̂ ⋅ »^,^, p} ^§ _{⋅ »^,zI} Table 16: q-powers via Frobenius. Elements ^, ^, ^, Z, ^, p, »_^,O are in ^_^a. See Section 2.2 for arithmetic in ^_^a. Elements »_^,O are precomputed. Also, ^º denotes the conjugate of ^. 2.9 Final Exponentiation The final exponentiation computes p ≔ p^{(^^aN^)/@} The exponent can be expressed as: is the B-th cyclotomic polynomial. ^{A pairing friendly field may be defined as an extension ^^^ with ^ ≡ 1 -^Z 12 and ^ =} _{2O3^, ^ ≥ 1, ¼ ≥ 0.} In such a pairing-friendly field the exponent can be expressed as follows: In BLS12 (and in BN for that matter), the embedding degree is B = 12, so the above formula for the exponent becomes: _{The part} ⁽ _^ ^Y _{− 1} ⁾⁽ _^ ^{^} _{+ 1} ⁾ _{of the exponent is referred to as the first, or easy, part. The part} Z ≔ ^{^^N^a^^} @ is referred to as the second, or hard, part. They are computed differently, as set out below. 2.9.1 Final Exponentiation – First (Easy) Part Representing p as an element in ^_^^a = ^_^^[X]/(X^{^} − $), the power p^{^^} is just its _{conjugate p.̅ Thus, if p = ^ + ^X, then p} ^{^^} = _p ^§ _{≔ ^ − ^X. This means that the first part of} the exponent is computed as Raising to ^^{^} 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: p ≔ (^̅, ^ ) ∈ ^_^^a ≔ ^_^^[X]/(X^{^} − $) O_{utput: ' ≔} ⁽ _{^̅′, ^ ′} ⁾ _{= p} ^{H^^N^IH^a ^^I} 1. p_^ ≔ p^{N^} 2_{. p^ ≔ p} ^§ _{= (^̅, −^ ) // Conjugate p} 3. p_^ ≔ p_^ ⋅ p 4. p ^a _^ ^ W ≔ p_^ // ^^{^}-Frobenius. See Table 16, top right. 5. ' ≔ p_^ ⋅ p_W Table17: Easy part of the final exponentiation. Multiplication and inversion is carried over ^_^ ^{^a} 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 The second part consists in computing the exponentiation '^g where Z ≔ @ . First, ^{the exponent is expressed as the sum Z = 0Q + 0^^ + 0^^^ + 0^^^, where the coefficients} _{0O are integers. This means that the result of the final exponentiation is:} ^{The above exponentiation is typically done with an addition chain for specific coefficients of} _{0O (which depend on the parameterization of the prime ^, hence on the specifics of each} curve) and applying the Frobenius operators for the powers ^, ^^{^}, and ^^{^}. An addition chain ^{is used which is optimized for BLS12. See Table 18 for the algorithm. The concrete values of} _{0O for which the addition chain applies are:} where ^ is the curve parameter.

Exponentiate hard part: // curve parameter ^ hard-coded Input: ' ≔ (^̅, ^ ) ∈ ^_^^a ≔ ^_^^[X]/(X^{^} − $) // The output of the easy part. (Table 17) Å^{^¹ÅaÆ^} Output: ^ ≔ ' ^Ç // The pairing output. 1. n_Q ≔ '^{^} 2. n_^ ≔ n_Q ^È // See Table 10 3. n_^ ≔ n^{È/^} ^ // See Table 10 4. n_^ ≔ 'º (= '^{N^}) // Conjugate – see Table 9 bottom right. 5. n_^ ≔ n_^ ⋅ n_^ 6. n_^ ≔ n̂_^ (= n_^ ^{N^} ) 7. n_^ = n_^ ⋅ n_^ 8. n_^ ≔ n_^ ^È 9. n_^ ≔ n_^ ^È 10. n_^ ≔ n̂_^ (= n_^ ^{N^}) 11. n_^ = n_^ ⋅ n_^ 12. n_^ ≔ n̂_^ (= n^{N^} ) . n_^ ≔ n ^c _^ 13 ^{^} ^ // ^^{^}-Frobenius. See Table 16 bottom. 14. n_^ ≔ n^{^a} ^ // ^^{^}-Frobenius. See Table 16 top right. 15. n_^ ≔ n_^ ⋅ n_^ 16. n_^ ≔ n_^ ^È 17. n_^ ≔ n_^ ⋅ n_Q 18. n_^ ≔ n_^ ⋅ ' 19. n_^ ≔ n_^ ⋅ n_^ 20. n_^ ≔ n^{^} ^ // ^-Frobenius. See Table 16 top left. 21. ^ ≔ n_^ ⋅ n_^ Table 18: Hard part exponentiation. The algorithm uses five temporary variables n_O. Multiplication is given in Table 9 and exponentiation by ^, ^/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 ^_^, ^_^ ^a, ^_^ ^{^}, ^_^ ^{^}, ^_^ ^{^a}. 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 (^_^^a ). 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 ^_^. An FQ element is an integer ^ modulo ^. Thus, 0 ≤ ^ < ^. 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 ^_^a ≔ ^_^[^]/(^^{^} + 1 ), with ^ ≔ ^ + 1. An FQ2 element is a pair of integers ^̅ = (^_Q, where 0 ≤ ^_O < ^. Table 19 lists the scripts. Scripts Description Pseudocode reference [FQ2 add] Add two elements. [FQ2 subtract] Subtract two elements. Table 4 [FQ2 negate] Negate an element. [FQ2 multiply by scalar] Multiply by an element in ^_^. [FQ2 multiply] Multiply two elements. Table 5 [FQ2 square] Square an element. 3.1.3 FQ4 ^{Arithmetic over ^^^ ≔ ^^a[^]/(^^ − . An FQ4 element is a pair of FQ2 elements ^̅ =} w_{here ^̅O ∈ ^^a. Table 20 lists the scripts.} Scripts Description Pseudocode reference [FQ4 add] Add two elements. [FQ4 multiply] Multiply two elements. [FQ4 square] Square an element. [FQ4 multiply by scalar] Multiply by an element in ^_^a . Table 6 [FQ4 multiply by Ê] Multiply an element by element ^. Table 10: Scripts for ^_^^ arithmetic 3.1.4 FQ6 ^{Arithmetic over ^^^ ≔ ^^a[$]/($^ − . An FQ6 element is a triplet of FQ2 elements ^̅ =} _{(^̅Q, ^̅^, ^̅^) where ^̅O ∈ ^^a. Table 21 lists the scripts.} Scripts Description Pseudocode reference [FQ6 add] Add two elements. [FQ6 subtract] Subtract two elements. Table 7 [FQ6 negate] Negate an element. [FQ6 multiply by scalar] Multiply by an element in ^_^a . [FQ6 multiply] Multiply two elements. Table 8 [FQ6 square] Square an element. [FQ6 multiply by Ë] Multiply an element by element $. Table 21: Scripts for ^_^^ arithmetic Multiplication over ^_^^a ≔ ^_^^[X]/(X^{^} − $). Namely, a quadratic extension over ^_^^. An FQ12Quadratic element is a pair of FQ6 elements ^̅ = where ^̅_O ∈ ^_^ ^{^}. Table 22 lists the scripts. Scripts Description Pseudocode reference [FQ12Quadratic multiply] Multiply two elements. Table 9 [FQ12Quadratic square] Square an element. Table 22: Scripts for ^_^ ^{^a} multiplications as a quadratic extension. 3.1.6 FQ12CubicSparse Sparse multiplication and squaring over ^_^^a ≔ ^_^^^[^^]/(^^{^} − ^ ). Namely, a cubic extension over ^_^^. The following types of elements are distinguished: ^ ^{FQ12CubicSparse. A triplet of FQ2 elements ^̅} _© ^{= (^ , ^ , ^̅) where ^ , ^ , ^̅ ∈} ^_^a. ^ ^{FQ12CubicSomewhatSparse. Five FQ2 elements ^̅©ª = (^ , ^ , ^̅, Z̅, ^̅) where} ^ _{, ^ , ^̅, Z̅, ^̅ ∈ ^^a} ^ ^{FQ12CubicDense. Six FQ2 elements} ^ _{, ^ , ^̅, Z̅, ^̅, p̅ ∈ ^^a (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 Table 11 elements. [FQ12Cubic multiply sparse by Multiply a sparse somewhat-sparse] element by a somewhat- 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 ^_^^a sparse multiplications as a cubic extension. 3.1.7 FQ12Invert Inversion algorithms of elements in ^_^^a . Inversion involves the following types of elements (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] Invert an element in ^_^. [FQ2 invert] Invert an element in ^_^a. Table 5 [FQ6 invert] Invert an element in ^_^^. Table 8 [FQ12Quadratic invert] Invert an element in ^_^ ^{^a}. [^{FQ12Quadratic conjugate] Invert a unitary element in Table 9} ^_{^^a .} Table 24: Scripts to invert elements 3.1.8 FQ12Frobenius Exponentiation of an ^_^^a element to the powers ^, ^^{^}, ^^{^} using Frobenius. Scripts Description Pseudocode reference [^-Frobenius] Exponentiate an element in ^_^^a to ^. [_^ ^{^} _-Frobenius] ^{Exponentiate an element in ^} _^ ^{^a to ^^.} _{Table 16} [^^Ì-Frobenius] Exponentiate an element in ^_^^a to ^^{^}. 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 ^ and ^. Each of these functions comprises multiple loops, the number of loops being defined by a curve parameter ^, with the number of loops being equal to a bitlength of the curve parameter ^. 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 ^ and computes an initial curve point K. The first loop of the line function takes the initial curve point as input and update the curve point K. Each subsequent loop of the line function takes a current curve point K computed by a previous loop as input and is configured to update K 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 K, that is the curve point K 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 ^. All loops comprise the same squaring subfunction and multiplication subfunction. The output of the square-and-update function is an intermediate value p. The intermediate value p 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 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 ' of FQ12 elements. The main (second) loop takes as input the stored results ' and updates and squares the element p. [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- 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 ' holding the combined line functions calculations. Then, update and square the combined p 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 27 for the pseudocode. µ for Adding Points and Point Addition Function In the formula to calculate the point addition function (Table 14), the values 0 and µ are the same as for point addition K + ^ (Table 13, top). In the Miller loop, these values only need to be computed once for both operations. Therefore, 0, µ can be computed first and equivalent routines defined for point addition and line evaluation, respectively, that take 0 and µ as input. Script[Line functions loop] // curve parameter ^ hard-coded Input: ^ ≔ (^̅, ^ ) ∈ ^′(^_^ ^a ), ^ ≔ (^_", ^_") ∈ ^(^_^) Output: An array ' of ⌊log(^)⌋ FQ12 elements. ^ _{If ^-th bit ^O = 0, then 'O = H^ O, ^   O, ^O̅I // Sparse FQ12Cubic element ^ Else if ^O = 0 then 'O = H^ O, ^   O, ^O̅ , Z̅O, ^̅OI // Somewhat-sparse FQ12Cubic element} Steps: 1. K ≔ (^̅, ^ , (1,0)) // Set ^ in projective coordinates 2_{. // For ^ ≔} ^⌊ _log ⁽ _^ ^)⌋ _{− 1 down to 0 do (unrolled loop: fixed ^):} 3. [Point doubling line]// '_O ≔ '_^(^),^(^)(^) // Sparse 4. [Double point] // K ≔ [2]K 5. // If ^_O = 1 then: // Branchless If (fixed ^_O) 6. [Compute 0 and µ] // Precompute 0, µ 7. [Point addition line with input 0, µ] // n′_O ≔ '_^(^),^(#)(^) // Sparse 8. [FQ12Cubic sparse by sparse mult] // '_O ≔ '_O ⋅ n_O ^U // Somewhat-sparse 9. [Add points with input 0, µ] // K ≔ K + ^ 10. // End if 11. // End for Script[Main loop] // curve parameter ^ hard-coded Input: An array ' of ⌊log(^)⌋ FQ12 elements (from[Line functions loop] output above). ^ _{If ^-th bit ^O = 0, then 'O = H^ O, ^   O, ^O̅I // Sparse FQ12Cubic element ^ Else if ^O = 0 then 'O = H^ O, ^   O, ^O̅ , Z̅O, ^̅OI // Somewhat-sparse FQ12Cubic element Output: p ≔ (^̅Q, ^̅^, ^̅^) ≔ ((^ , ^   ), (^̅, Z̅), (^̅, p} ^̅ _{)) // FQ12Cubic dense element} Steps: 1. p ≔ '[⌊log(^)⌋ − 1] // Set initial value of p (First iteration of Miller loop) 2_{. // For ^ ≔} ^⌊ _log ⁽ _^ ^)⌋ _{− 2 down to 0 do (unrolled loop: fixed ^):} 3. [FQ12Cubic square] // p ≔ p^{^} 4. // If ^_O = 0 then '[^] is a sparse FQ12 element // Branchless If (fixed ^_O). 5. [FQ12Cubic sparse by dense mult]// p ≔ '_O ⋅ p 6. // Else ^_O = 1 and '[^] is somewhat-sparse 7. [FQ12Cubic somewhat-sparse by dense mult] // p ≔ '_O ⋅ p 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 ^ hard-coded Input: ^_^ ≔ (^̅_^, ^ _^) ∈ ^′(^_^a ), ^_^ ≔ (^_"Í, ^_"Í) ∈ ^(^_^) for ¼ = 1,2,3. _{Output: An array ' of} ^⌊ _log ⁽ _^ ^)⌋ _{FQ12Cubic dense elements.} Steps: 1. K_^ ≔ (^̅_^, ^ _^, (1,0)) // Set ^_^ in projective coordinates for ¼ = 1,2,3 2. // For ^ ≔ ⌊log(^)⌋ − 1 down to 0 do (unrolled loop: fixed ^): ^{3. [Point doubling line]// n} _O,^ ^{≔ '} _{^H^ÍI,^H^ÍIH} ^{^} _^I ^{for ¼ = 1,2,3 (Sparse)} 4. [Double point] // K_^ ≔ [2]K_^ for ¼ = 1,2,3 5. // If ^_O = 0 then: // Branchless If (fixed ^_O) 6. [FQ12Cubic sparse by sparse mult] // '_O ≔ n_O,^ ⋅ n_O,^ (Somewhat-sparse) 7. [FQ12Cubic sparse by somewhat-sparse mult] // '_O ≔ n_O,^ ⋅ '_O. (Dense) 8. // If ^_O = 1 then: 9. [Compute 0_^ and µ_^] // Precompute 0_^, µ_^ for ¼ = 1,2,3 10. [Point addition line with input 0_^, µ_^] // n′_O,^ ≔ '_{^H^ÍI,^H#ÍI}(^_^) for ¼ = 1,2,3 (Sparse) 11. [FQ12Cubic sparse by sparse mult] // n_O,^ ≔ n_O,^ ⋅ n_O ^U ,_^ for ¼ = 1,2,3 (Somewhat- sparse) 12. [FQ12Cubic somewhat-sparse by somewhat-sparse mult] // '_O ≔ n_O,^ ⋅ n_O,^ (Dense) 13. [FQ12Cubic somewhat-sparse by dense] // '_O ≔ n_O,^ ⋅ '_O (Dense) 14. [Add points with input 0_^, µ_^] // K_^ ≔ K_^ + ^_^ for ¼ = 1,2,3 15. // End If 16. // End for Script[3-main loop] // curve parameter ^ hard-coded Input: An array ' of ⌊log(^)⌋ FQ12Cubic dense elements (from[Line functions loop] output above). _{Output: p ≔ (^̅Q, ^̅^, ^̅^) ≔ ((^ , ^   ), (^̅, Z̅), (^̅, p} ^̅ _{)) // FQ12Cubic dense element} Steps: 1. p ≔ '_{⌊^^^(È)⌋N^} // Set initial value of p (First iteration of Miller loop) _{2. // For ^ ≔} ^⌊ _log ⁽ _^ ^)⌋ _{− 2 down to 0 do (unrolled loop: fixed ^):} 3. [FQ12Cubic square] // p ≔ p^{^} 4. [FQ12Cubic multiply] // p ≔ p ⋅ '_O 5. // End for Script[3-Miller loop] // curve parameter ^ hard-coded Input: ^_^ ≔ (^̅_^, ^ _^) ∈ ^′(^_^ ^a ), ^_^ ≔ (^_"Í, ^_"Í) ∈ ^(^_^) for ¼ = 1,2,3 O_{utput: p ≔ (^̅Q, ^̅^, ^̅^) ≔ ((^ , ^   ), (^̅, Z̅), (^̅, p} ^̅ _{)) // FQ12Cubic dense element} Steps: 1. [3-line functions loop] // Calculate array ' of line calculations 2. [3-main loop] // Update and square p 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 ^′ ). 2) Line functions evaluations in the target field ^_^^a . 3) Sparse multiplications and squaring in ^_^^a . 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 Î, Ï] Precompute 0, µ for point addition and line function. [^{Add points with inputs Î, Ï] Add points K + ^ in} Table 13 ^_{′(^^a ).} [^{Double point] Double point [2]K in} ^_{′(^^a ).} [^{Point addition line with inputs Compute '^(^),^(#)(^) in} T_{able 14 Î, Ï] ^^^a.} [^{Point doubling line] Compute '^(^),^(^)(^) in} T_{able 15 ^^^a.} Table 28: Elliptic curve arithmetic and line function evaluation scripts Scripts Description Pseudocode reference [Line functions loop] Compute array ' of line functions evaluations. [Main loop] Update and square p. Table 26 [Miller loop] Compute the Miller loop. [3-line functions loop] Compute array ' for three line functions evaluations combined. [3-main loop] Update and square p. Table 27 [3-Miller loop] Compute the combined Miller loop for three pairings Table 29: Miller loop scripts 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 ^_^^a. 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 p of the Miller loop must be inverted to compute the pairing. In the method described herein, p is inverted off-chain and then the inversion p′ ≔ p^{N^} is passed as an input to the final exponentiation script. Thus, the inversion routine is replaced by instead checking p ⋅ p′ = 1. This change results in a significant saving when describing the script, as all routines dedicated to inversions in the intermediate extension fields are not needed anymore. See Table 30. As above, the value p may be referred to herein as the intermediate value. The inverse of this value, p′ 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 p ⋅ pU = 1 checks that the provided inverse is the inverse of} _{p. 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 p. In one embodiment, the intermediate value p is an output of the Miller loop script 404. The intermediate value p 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 Table 31 lists the necessary scripts for the final exponentiation. Scripts Description Pseudocode reference [Conjugate] Compute the inverse of a u_{nitary element in ^^^a.} ^{Table 9, bottom right} [Exponentiate to Ð] Exponentiate a unitary element to the curve parameter ^. The exponent ^ is hard-coded in the script, Table 10 and the loop unrolled. [_{Exponentiate to} ^Ð ^_] ^{As above but with exponent} È _^. [^{Easy part]} _{Compute p} ^{H^^N^IH^a ^^I} _, Table 17 where p is the output of the Miller loop. [Easy part with inverse check] As above but without inverting p. (It takes extra ^{Table 30} i_{nput pU ≔ pN^)} [^{Hard part] Å^¹ÅaÆ^} C_{ompute ' Ç , where '} Table 18 is the output of the easy part. [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 p in ^_^^a as a cubic extension. The final exponentiation expects the same p but represented as an element of the quadratic extension. From cubic to quadratic I_{nput p ≔ (} ⁽ _{^, ^} ⁾ _, ⁽ _{^, Z} ⁾ _, ⁽ _{^, p} ⁾ _{) ∈ ^^} ^{^a} _{≔ ^^} ^{^[} _^ ^] _/(^ ^{^} _{− ^ )} O^{utput p′ ≔} _H ^{(^, ^, Z), (^, ^, p)} _I ^{∈ ^} _^ ^{^a ≔ ^} _^ ^{^[X]/(X^ − $)} 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 ^, ^ 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 p 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 p′ provided in the unlocking script is equal to the inverse of the intermediate value p 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 p computed by the Miller loop script 404 and the candidate inverse intermediate value p′ 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 ^, ^ for which the pairing is computed), or the signature and the curve generator (also seen as ^, ^ 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 ^, ^ 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 ^} _^ ^{, representing two points ^ and ^. That is, roughly 6 × 50 =} _{300 bytes.} Line Functions Loop Estimation (bytes) Number of loops Total [Point doubling 50 65 line] 3250 [Double point] 120 65 7800 [Compute 0 and µ] 24 5 120 [Point addition line ^{70 5} w_{ith input 0 and µ] 350} [FQ12Cubic sparse 90 5 by sparse mult] 450 [Add points with ^{170 5} i_{nput 0 and µ] 850} 12820 Table 33 Main Loop Estimation (bytes) Number of loops Total [FQ12Cubic 70 65 4550 Square] [FQ12Cubic sparse 190 60 11400 by dense mult] [FQ12Cubic 330 5 1650 somewhat-sparse by dense mult] 17600 Table 34 Exponentiate easy part with inverse check Estimation (bytes) Number of times Total Assert correctness 370 1 370 of inverse [FQ12 dense by 350 2 700 dense with FQ6- tower] 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 4 × 5 + 8 9800 Q2 Frobenius 300 1 300 Q Frobenius 300 1 300 Q3 Frobenius 300 1 300 Conjugate 30 4 120 88820 Table 36 As an 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 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. 5.2 BLS12 Parameters in hexadecimal. q: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabf ffeb153ffffb9feffffffffaaab r: 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001 x: 0x17f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e 83ff97a1aeffb3af00adb22c6bb y: 0x08b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc 744a2888ae40caa232946c5e7e1 h: 0x396c8c005555e1568c00aaab0000aaab b: 4 x'_0: 0x024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac 0326a805bbefd48056c8c121bdb8 x'_1: 0x13e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334 cf11213945d57e5ac7d055d042b7e y'_0: 0x0ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923a c9cc3baca289e193548608b82801 y'_1: 0x0606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f37 0d275cec1da1aaa9075ff05f79be h': 0x5d543a95414e7f1091d50792876a202cd91de4547085abaa68a205b2e5a7ddfa628 f1cb4d9e82ef21537e293a6691ae1616ec6e786f0c70cf1c38e31c7238e5 b': 4 * (u + 1) 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 time- order 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 output- based 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 “Tx₁”. 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 “Tx₀” in Figure 2. Tx₀ and Tx₁ are just arbitrary labels. They do not necessarily mean that Tx₀ is the first transaction in the blockchain 151, nor that Tx₁ is the immediate next transaction in the pool 154. Tx₁ 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 Tx₀ comprises a particular UTXO, labelled here UTXO0. 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, UTXO₀ in the output 203 of Tx₀ comprises a locking script [Checksig P_A] which requires a signature Sig P_A of Alice in order for UTXO₀ to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXO₀ to be valid). [Checksig P_A] contains a representation (i.e. a hash) of the public key P_A from a public- private key pair of Alice. The input 202 of Tx₁ comprises a pointer pointing back to Tx₁ (e.g. by means of its transaction ID, TxID₀, which in embodiments is the hash of the whole transaction Tx₀). The input 202 of Tx₁ comprises an index identifying UTXO₀ within Tx₀, to identify it amongst any other possible outputs of Tx₀. The input 202 of Tx₁ further comprises an unlocking script <Sig P_A> 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 Tx₁ 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 P_A. In embodiments this is based on the ECDSA using the elliptic curve secp256k1. 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 “scriptPubKey” 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 computing a pairing in script, the method comprising generating a script, wherein computing the pairing comprises at least one sub-computation executed in a target field, wherein the target field is represented as an extension field, wherein the script comprises at least one subfunction configured to perform the sub-computation as an extension over the extension field. Statement 2. The method of statement 1, wherein the sub-computation is one of: a multiplication operation; and an inverse operation. Statement 3. The method of statement 1 or statement 2, wherein the target field is a field of a Barreto-Lynn-Scott, BLS, family curve with an embedding degree of 12. Statement 4. The method of any preceding statement, wherein a second field ^_^ ^a is a quadratic extension over a first field ^_^, wherein a third field ^_^^ is a quadratic extension over the second field ^_^^, wherein a fourth field ^_^^ is a cubic extension over the second field ^_^ ^a, and wherein a fifth field ^_^ ^{^a} is: a sextic extension over the second field ^_^ ^a; a cubic extension over the third field ^_^^; or a quadratic extension over the fourth field ^_^^. Statement 5. The method of statement 4, wherein the fifth field ^_^^a is the target field. Statement 6. The method of statement 4 or statement 5, wherein the second field ^_^a is a twisted field. Statement 7. The method of statement 4 or any statement dependent thereon, wherein the script comprises a plurality of subfunctions, wherein at least one subfunction of the plurality of subfunctions is configured to perform a sub-computation in each of: the sextic extension over the second field ^_^a; the cubic extension over the third field ^_^^; and the quadratic extension over the fourth field ^_^ ^{^}. Statement 8. The method of statement 4 or any statement dependent thereon, wherein the script comprises a Miller loop subscript configured to execute a Miller function for a predefined number of inputs, wherein the Miller loop subscript is configured to compute an intermediate value, wherein the pairing is computed based on the intermediate value. Statement 9. The method of statement 8, wherein the Miller loop subscript comprises at least one sparse vector multiplication subfunction, wherein the least one vector multiplication subfunction is executed in the cubic extension over the third field ^_^^. Statement 10. The method of statement 9, wherein the least one vector multiplication subfunction is a sparce vector multiplication subfunction. Statement 11. The method of any of statements 8 to 10, wherein the Miller loop subscript comprises at least one point addition or point doubling subfunction, wherein the point addition or point doubling subfunction is executed in the second field ^_^a. Statement 12. The method of any of statements 8 to 11, wherein the Miller loop subscript comprises at least one line subfunction, wherein the at least one line function is executed in the cubic extension over the third field ^_^^. Statement 13. The method of statement 4 or any statement dependent thereon, wherein the script comprises an exponentiation subscript is configured to verify a received candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the exponentiation subscript comprises a set of subfunctions executed in the quadratic extension over the fourth field ^_^^. Statement 14. The method of statement 13 when dependent on statement 8, wherein the exponentiation subscript receives as input the intermediate value computed by the Miller loop subscript, wherein the intermediate value is an element in the cubic extension of the third field ^_^^, wherein the exponentiation subscript is configured to: convert the intermediate value from an element in the cubic extension of the third field ^_^^ to an element in the quadratic extension over the fourth field ^_^ ^{^}. Statement 15. The method of statement 13 or statement 14, wherein the exponentiation subscript comprises a conjugate subfunction configured to compute an inverse of a unitary element in the target field. Statement 16. The method of any of statements 13 to 15, wherein the exponentiation subscript comprises at least one exponentiate to a constant value subfunction configured to exponentiate a unitary element to the constant value via Frobenius endomorphisms, wherein the exponentiate to a constant value subfunction is configured to execute a plurality of multiplication over the second field ^_^a. Statement 17. A computer-implemented method for computing a pairing, wherein the method comprises generating a script configured to execute the method of any preceding claim. Statement 18. The method of statement 17, wherein the script is a blockchain script, wherein the method further comprises: generating a challenge blockchain transaction, wherein the challenge blockchain transaction comprises a first locking script comprising the script; and backing the challenge blockchain transaction available to one or more nodes of a blockchain network. Statement 19. 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 18. Statement 20. 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 18.

Claims

CLAIMS 1. A computer-implemented method for computing a pairing in script, the method comprising generating a script, wherein computing the pairing comprises at least one sub- computation executed in a target field, wherein the target field is represented as an extension field, wherein the script comprises at least one subfunction configured to perform the sub-computation as an extension over the extension field.

2. The method of claim 1, wherein the sub-computation is one of: a multiplication operation; and an inverse operation.

3. The method of claim 1 or claim 2, wherein the target field is a field of a Barreto- Lynn-Scott, BLS, family curve with an embedding degree of 12.

4. The method of any preceding claim, wherein a second field ^_^ ^a is a quadratic extension over a first field ^_^, wherein a third field ^_^^ is a quadratic extension over the second field ^_^^, wherein a fourth field ^_^^ is a cubic extension over the second field ^_^a, and wherein a fifth field ^_^^a is: a sextic extension over the second field ^_^a; a cubic extension over the third field ^_^^; or a quadratic extension over the fourth field ^_^^.

5. The method of claim 4, wherein the fifth field ^_^ ^{^a} is the target field.

6. The method of claim 4 or claim 5, wherein the second field ^_^a is a twisted field.

7. The method of claim 4 or any claim dependent thereon, wherein the script comprises a plurality of subfunctions, wherein at least one subfunction of the plurality of subfunctions is configured to perform a sub-computation in each of: the sextic extension over the second field ^_^a; the cubic extension over the third field ^_^^; and the quadratic extension over the fourth field ^_^^.

8. The method of claim 4 or any claim dependent thereon, wherein the script comprises a Miller loop subscript configured to execute a Miller function for a predefined number of inputs, wherein the Miller loop subscript is configured to compute an intermediate value, wherein the pairing is computed based on the intermediate value.

9. The method of claim 8, wherein the Miller loop subscript comprises at least one sparse vector multiplication subfunction, wherein the least one vector multiplication subfunction is executed in the cubic extension over the third field ^_^^.

10. The method of claim 9, wherein the least one vector multiplication subfunction is a sparce vector multiplication subfunction.

11. The method of any of claims 8 to 10, wherein the Miller loop subscript comprises at least one point addition or point doubling subfunction, wherein the point addition or point doubling subfunction is executed in the second field ^_^a.

12. The method of any of claims 8 to 11, wherein the Miller loop subscript comprises at least one line subfunction, wherein the at least one line function is executed in the cubic extension over the third field ^_^^.

13. The method of claim 4 or any claim dependent thereon, wherein the script comprises an exponentiation subscript is configured to verify a received candidate inverse intermediate value is equal to a target inverse intermediate value, wherein the exponentiation subscript comprises a set of subfunctions executed in the quadratic extension over the fourth field ^_^^.

14. The method of claim 13 when dependent on claim 8, wherein the exponentiation subscript receives as input the intermediate value computed by the Miller loop subscript, wherein the intermediate value is an element in the cubic extension of the third field ^_^^, wherein the exponentiation subscript is configured to: convert the intermediate value from an element in the cubic extension of the third field ^_^^ to an element in the quadratic extension over the fourth field ^_^^.

15. The method of claim 13 or claim 14, wherein the exponentiation subscript comprises a conjugate subfunction configured to compute an inverse of a unitary element in the target field.

16. The method of any of claims 13 to 15, wherein the exponentiation subscript comprises at least one exponentiate to a constant value subfunction configured to exponentiate a unitary element to the constant value via Frobenius endomorphisms, wherein the exponentiate to a constant value subfunction is configured to execute a plurality of multiplication over the second field ^_^a.

17. A computer-implemented method for computing a pairing, wherein the method comprises generating a script configured to execute the method of any preceding claim.

18. The method of claim 17, wherein the script is a blockchain script, wherein the method further comprises: generating a challenge blockchain transaction, wherein the challenge blockchain transaction comprises a first locking script comprising the script; and backing the challenge blockchain transaction available to one or more nodes of a blockchain network.

19. 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 claims 1 to 18.

20. 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 18.