G.BN254 Pairings, Number by Number

This one needs a wider screen.

The page derives a BN254 pairing one operation at a time and keeps three things side by side while it does: the step being executed, every number that step produced, and which field each of those numbers lives in. Read apart, they are just digits.

It needs at least 1024 × 560 logical pixels — a landscape tablet, a laptop, or a desktop.

this screen: —

On a tablet, turning it to landscape is usually enough.

Read what it does instead →
G. BN254 Pairings, Number by Number G₁ · G₂ · G_T derivation
Speed 160 ms
ready
step 0 / 0
Your scalars — Fr
Any integers in [1, r−1] — decimal, or 0x‑prefixed hex.

Routine

click to jump

This step

Where each value lives

four different sets

Running state

Cost so far

Progress

BN254 — the specification this page implements

Every number on this page is computed in the browser, in BigInt arithmetic, from the single Barreto–Naehrig parameter x below. Nothing is hard-coded except x and the two generators; the moduli, the twist constant, the Frobenius constants, the loop parameter and the final-exponentiation exponent are all derived at load time and shown here as the page computed them.

BN254 goes by several names for the same curve: alt_bn128 in the EVM (EIP‑196 / EIP‑197), bn256 in some Go libraries, bn_snark1 elsewhere. They are all this curve, with this tower and this pairing.

The curve family

A BN curve is generated from one integer x. Everything else is a polynomial in it, which is what makes the family pairing-friendly at embedding degree 12.

The field tower

Pairing values live in Fp12, which is never built as a degree-12 extension directly. It is built in three cheap steps, and the choice of each step is forced by arithmetic that has to stay fast.


    

p ≡ 3 (mod 4), so u2 + 1 is irreducible over Fp and Fp2 can be built as the Gaussian integers mod p — the cheapest possible quadratic extension. The element ξ = 9 + u is then chosen because it is neither a square nor a cube in Fp2, which is exactly what makes both v3 − ξ and w2 − v irreducible, and because 9 + u has small coefficients so multiplying by it costs a few additions rather than a multiplication.

This page carries Fp12 flat, as six Fp2 coefficients against 1, w, w2, …, w5, with w6 = ξ. That is the same field — v = w2 — written in the basis in which the line functions of the Miller loop are visibly sparse.

Fr — the scalar field

This is the field a circuit computes in, and the field the two scalars on the input bar belong to. It is not the field curve coordinates live in. The two moduli are both 254 bits and their top 61 bits are identical, which is precisely why they get confused — and why confusing them produces bugs that survive small tests.

G1

G2

G2 is defined as the p-eigenspace of Frobenius in E[r] over Fp12, but nobody stores it there. Because 6 | 12 and the curve has j-invariant 0, E admits a sextic twist E′ defined over Fp2 whose r-torsion is isomorphic to G2. Points are stored on the twist — four Fp elements instead of twenty-four — and untwisted only implicitly, inside the line functions.

BN254 uses the D-type twist, y2 = x3 + b/ξ. The untwisting map is ψ(x, y) = (x·w2, y·w3), and it is this map that makes the line functions sparse in the w-basis.

GT

GT is not a curve. It has no points, no x and no y, and no group law of chords and tangents. It is the set of r-th roots of unity inside the multiplicative group of Fp12, and its group operation is field multiplication. A GT element is one field element — written here as twelve Fp coordinates, because that is what an Fp12 element is made of.

The habit of calling e(P,Q) a “pairing point” comes from G1 and G2 being point groups. It is worth breaking: the whole security argument for pairing-based proofs rests on GT being a subgroup of a finite field, which is why it is attacked by index calculus and why BN254's security estimate moved.

Three sets, three sizes — the distinction this page is built around

ObjectLives inMade ofUncompressed

The pairing is the only thing that moves between them, and it moves one way: e : G1 × G2 → GT, bilinear, so e([a]G1, [b]G2) = e(G1, G2)ab with the exponent taken mod r. Scalars go in as exponents and never come out.

Routine 1 — [a]·G1, and where MSM fits

Scalar multiplication on this page is plain left-to-right double-and-add, in affine coordinates, so that every step shows a real slope λ and a real modular inverse rather than a projective bookkeeping variable. That is a deliberate trade: affine is the readable form, and it is what the textbook group law says, but it is not what a prover runs — see the honesty section below.

double-and-add, MSB first
  R ← G₁                       // the leading 1 bit
  for each remaining bit b of a:
      R ← 2R                    // tangent
      if b = 1: R ← R + G₁      // chord

the group law, affine
  doubling   λ = 3x² / 2y            x₃ = λ² − 2x         y₃ = λ(x − x₃) − y
  addition   λ = (y₂−y₁)/(x₂−x₁)      x₃ = λ² − x₁ − x₂    y₃ = λ(x₁ − x₃) − y₁

The bit strip beside the ladder is the scalar itself: one cell per bit, most significant first, with the set bits marked — those are exactly the ones that cost an extra addition. Clicking a cell jumps to the step that consumes it.

A real prover almost never computes one [a]G. It computes a multi-scalar multiplication, i [ai]Pi over millions of terms, with Pippenger's bucket method: split each scalar into c-bit windows, and for each window keep 2c−1 buckets. Every point is added into the bucket named by its digit — no multiplication at all — and the buckets are then collapsed by a single downward sweep that accumulates a running sum, costing two additions per bucket. The binary ladder shown here is the n = 1, c = 1 corner of that picture; Pippenger is the same windowing idea shared across all the points at once, which is why its cost grows like n/log n rather than n.

Reading the expansions

Any operation in an extension field can be opened. The button on a row says what you will see: + F on an Fp12 operation, + Fp on an Fp2 one. They nest, so a single Fp12 multiplication can be followed all the way down to base-field multiplications. Each expansion is headed by the identity it is carrying out — the formula that textbooks assume and never print.

The three rules underneath everything on this page:

Routine 2 — [b]·G2 over Fp2

The algorithm is identical to routine 1. Only the ring underneath changes, and this routine exists to make that concrete: every line in the step panel opens into the Fp multiplications and additions it really is.

F multiply  (a₀+a₁u)(b₀+b₁u) = (a₀b₀ − a₁b₁) + (a₀b₁ + a₁b₀)u          // 4 F_p mults, schoolbook
F square    the same, with b = a
F inverse   N = a₀² + a₁²   ∈ Fp                               // the norm
                 a⁻¹ = (a₀·N⁻¹) − (a₁·N⁻¹)u                        // one F_p inverse, two mults

Schoolbook multiplication is shown rather than Karatsuba (which trades one multiplication for three additions) because the point here is what the operation is, not the fastest way to spell it. A production library uses Karatsuba throughout the tower.

Routine 3 — the optimal ate pairing

The pairing computed here is the optimal ate pairing, the standard choice for BN curves and the one the EVM's ecPairing precompile implements. It has two halves.

e(P, Q) = f6x+2,Q(P) (p12−1)/r

Miller loop  // double-and-add on Q, recording a line at every step
  f ← 1 ;  T ← Q
  for each bit b of 6x+2 after the leading one:
      f ← f² · ℓT,T(P) ;   T ← 2T
      if b = 1:  f ← f · ℓT,Q(P) ;   T ← T + Q
  // two correction steps: 6x+2 is not the full order
  f ← f · ℓT,π(Q)(P)  ;   T ← T + π(Q)
  f ← f · ℓT,−π²(Q)(P) ; T ← T − π²(Q)

The line function is the piece that pairing papers state symbolically and never evaluate. Untwisting T and Q with ψ(x,y) = (xw2, yw3) turns the slope λ ∈ Fp2 into λw, and the line through the untwisted points, evaluated at an Fp-rational P = (xP, yP), collapses to three terms:

ℓ(P) = yP  −  (λ·xP)·w  +  (λ·xT − yT)·w³

  ℓ₀ = yP                 // in F_p, not just F_p²
  ℓ₁ = −λ·xP
  ℓ₃ = λ·xT − yT
  ℓ₂ = ℓ₄ = ℓ₅ = 0            // which is why f·ℓ costs 18 F_p² mults, not 36

The two Frobenius steps exist because 6x+2 is shorter than the order it would need to be for a plain ate pairing. On G2 the p-power Frobenius acts as multiplication by p, and on twist coordinates it is a conjugation and two constant multiplications — so the two corrections cost two line steps instead of two full scalar multiplications. γ2,3 is exactly −1, which is why subtracting π2(Q) is written as an addition with the y-coordinate left alone.

The final exponentiation

The Miller value is not the pairing. It depends on which representative of the Miller function was used, so it is not even well defined as a pairing value. Raising it to (p12−1)/r kills everything whose order is not r, and what survives is canonical. The exponent factors, and each factor is handled differently.

(p12−1)/r  =  (p6−1) · (p2+1) · d          where  d = (p4 − p2 + 1)/r

easy part
  f ← f̄ · f⁻¹        // ^(p⁶−1) : f̄ is conjugation w ↦ −w. one inverse, no exponentiation.
  f ← f(p²) · f       // ^(p²+1) : one Frobenius, one multiply
  // f is now cyclotomic: f·f̄ = 1, so from here inversion IS conjugation

hard part  // d written in base p — three of the four terms become Frobenius maps
  d = λ₃p³ + λ₂p² + λ₁p + λ₀
      λ₀ = −36x³ − 30x² − 18x − 2
      λ₁ = −36x³ − 18x² − 12x + 1
      λ₂ = 6x² + 1
      λ₃ = 1
  fd = (f)λ₃ · (f)λ₂ · (fp)λ₁ · fλ₀     // 761 bits become 192, 192, 127, 1

The page verifies this decomposition twice: once as an integer identity (λ3p3 + λ2p2 + λ1p + λ0 = d exactly), and once by comparing the result against a direct 761-bit exponentiation of the same input. Both are shown in the last two steps of routine 3.

Frobenius constants

γn,k = ξk(pn−1)/6, computed at load time. Applying a ↦ apn to an Fp12 element means conjugating each Fp2 coefficient (for odd n) and scaling the wk coefficient by γn,k.

What this page does not do

It is a derivation reference, not a library, and the gap between the two is worth stating plainly so nobody ships the former:

Security

BN254 was designed for a 128-bit security level, under the assumption that discrete log in Fp12 costs about as much as the field size suggests. The extended tower number field sieve (Kim–Barbulescu, 2016) improved that attack against exactly this shape of field, and the revised estimates put BN254 near 100 bits, not 128. The curve remains in wide use — it is fixed in the EVM by EIP‑197 and cannot be swapped — but new designs at the 128-bit level generally choose BLS12‑381 or a larger BN curve instead. Nothing about the arithmetic on this page changes; the security claim attached to it does.

Self-test

These run in your browser, against the code that drew every number on this page.

The generator of GT, gT = e(G1, G2), is listed in the GT card above as this page computes it. It matches the value produced by the Ethereum Foundation's py_ecc reference implementation after the change of basis between its flat degree-12 representation (w12 − 18w6 + 82) and the tower used here — the two are the same field, since u = w6 − 9.

Keyboard

spacestep back enterrun / pause Rreset Ejump to end 123routine Xexpand all ?this panel

References