elliptic curves, pairings, and one host function

BLS12-381 — the pairing-friendly curve under a PLONK-on-Stellar verifier.

A 381-bit Barreto–Lynn–Scott curve with embedding degree $k=12$, two prime-order subgroups $G_1, G_2$, and a non-degenerate bilinear pairing $e: G_1 \times G_2 \to G_T$. That pairing is what makes KZG commitments openable and PLONK proofs checkable in a single on-chain call.

48-byte $G_1$ points, ~128-bit classical security, one CAP-0059 pairing on chain. Broken under Shor — the curve, KZG, PLONK, and BLS signatures collapse together on a CRQC.

381-bit
base field
255-bit
scalar field $F_r$
k = 12
embedding degree
48 / 96 B
$G_1$ / $G_2$ compressed
CAP-0059
soroban host fns

the shape

Two source groups, one target. One bilinear map between them.

A pairing is a non-degenerate bilinear map from two source groups into a target group. On BLS12-381, the source groups $G_1$ and $G_2$ are cyclic subgroups of large prime order $r$; the target $G_T$ is a subgroup of the multiplicative group of $F_{p^{12}}$. The map is computable in polynomial time; inverting it is not.

G₁ order r · 48 B P G₂ order r · 96 B Q e G_T ⊂ F_{p¹²} P ∈ G₁ Q ∈ G₂ e(P,Q)
$G_1$ — KZG commitments & proof bytes
48 B compressed · order r · over $F_p$
Carries every KZG commitment and the group portion of the PLONK proof. Most multi-scalar multiplications happen here.
$G_2$ — verifier-side pairing input
96 B compressed · order r · over $F_{p^2}$
A careful deployment keeps $G_2$ to the right-hand input of the single verifier pairing. Operations are an order of magnitude more expensive than $G_1$.
$G_T$ — where the check happens
subgroup of $F_{p^{12}}^*$ · order r
The pairing check actually compares two values here. Equality in $G_T$ is what tells the verifier the proof is valid.

In-circuit arithmetic lives in $F_r$, the 255-bit scalar field. Every field operation the SNARK encodes is reduced mod $r$ before the prover ever touches a group element.

bilinearity, interactively

Slide the scalars. Watch the exponents rearrange.

The pairing is linear in each argument. Pulling a scalar out of either source group multiplies the exponent in $G_T$. This is the single algebraic property KZG opens its commitments with, and the one PLONK's verifier reduces to.

Symbolic — no actual curve points evaluated. The point is the shape.

multiplicativity
additivity in one argument
non-degeneracy

A KZG opening at point $z$ for a polynomial committed as $[f]_1$ asks the verifier to check $e([f]_1 - [f(z)]_1,\ [1]_2) = e([q]_1,\ [x - z]_2)$. PLONK's full verifier batches several such openings into two pairings — one fixed, one variable. The whole soundness story bottoms out at the identity in the top card.

parameters

Concrete numbers.

All values are fixed by the curve definition or by the deployment's host-function surface. None are tunable knobs.

Curve
BLS12-381
Base-field bit length
381
Scalar-field bit length
255
Embedding degree
k = 12
Approx. classical security
~128 bits
Compressed $G_1$ point
48 bytes
Compressed $G_2$ point
96 bytes
Soroban host functions
Stellar CAP-0059 (Protocol 22)

how it wires into plonk-on-stellar

Three columns: scalar field, group ops, host functions.

In-circuit arithmetic happens in $F_r$. The off-chain prover lifts those values into $G_1$ via multi-scalar multiplications. The on-chain verifier never touches the witness — it calls three host functions and reads one bit of output.

In-circuit · $F_r$
Off-chain prover · $G_1$, MSM
On-chain verifier · Soroban
F_r · 255-bit
Poseidon2 absorption
Sponge updates over $F_r$ — the in-circuit hash that gates state transitions and seeds Fiat-Shamir.
F_r · 255-bit
Witness-encoded signing
EdDSA-style verification represented as constraints in the scalar field; the private key never leaves the circuit.
F_r · 255-bit
Merkle update step
Sibling-path rehash, leaf insertion, root rebind. Same Poseidon2 used as the compression function at each level.
G₁ · MSM
Commit witness polynomials
For each polynomial $f(x)$, compute $[f]_1 = \sum_i f_i \cdot \tau^i \cdot G$ — one MSM per commitment, all in $G_1$.
G₁ · MSM
Quotient & linearization commits
PLONK's quotient $t(x)$ and the opening polynomial reduce to more MSMs; output is a handful of 48-byte $G_1$ points.
G₁ · proof bytes
Pack proof π
$G_1$ commitments plus a few $F_r$ evaluations. The whole proof ships in a few hundred bytes.
CAP-0059
Aggregate verifier MSM
bls12_381_g1_add bls12_381_g1_mul
Reduces all commitments and Fiat-Shamir challenges to two final $G_1$ elements.
CAP-0059
Pairing check
bls12_381_pairing
One call. Returns true iff the proof opens correctly — the KZG identity verified in $G_T$.
cost asymmetry $G_2$ operations are an order of magnitude more expensive than $G_1$. A careful deployment keeps $G_2$ to the single verifier-side pairing — never inside the MSM.

Without these host functions, PLONK on Soroban would be cost-prohibitive in pure WASM. Stellar Protocol 22 added them in CAP-0059; chains without a native pairing precompile cannot host this configuration cost-effectively.

security

Classically conservative. Quantum-fragile.

Two assumptions, two horizons. The classical card is the working margin today; the post-quantum card is the load-bearing caveat — and the one a deployment must say out loud.

classical · holding
~128 bits

Discrete log in $G_1$, $G_2$. q-SDH in the pairing.

Reduces to discrete-logarithm hardness in the source subgroups and the q-strong Diffie–Hellman family used by KZG and PLONK.

  • Pollard rho on $G_1$ and $G_2$ — the best generic attack on the source subgroups; $O(\sqrt{r})$.
  • (Sub-)exponential index calculus on the embedding-degree-12 target group $G_T$.
  • Conservative estimates remain near the 128-bit design target.
post-quantum · broken
Shor

A CRQC recovers discrete logs in $G_1$ in polynomial time.

That single break collapses every BLS12-381-based scheme simultaneously: KZG, PLONK, and BLS signatures all fail together. There is no graceful degradation; there is no equivocation in the literature.

  • Shor (1994) gives a polynomial-time algorithm for discrete log on any abelian group, including elliptic-curve subgroups.
  • The pairing-friendly structure is not a hardening factor — the source-group break is sufficient.
  • Mitigation is a curve change, not a parameter bump: lattice-based polynomial commitments or hash-based SNARKs.

why this curve, not bn254

A curve change in 2016. A host-function vote in 2024.

BLS12-381 is the contemporary default for new pairing-based deployments. Two events made it the default — one cryptanalytic, one ecosystem.

2010s
BN254 was the default.
Tornado Cash, Semaphore, and the first wave of pairing-based zk deployments shipped on BN254 (Barreto–Naehrig, $k=12$, ~254-bit base field) at a ~128-bit security target.
2016
Kim–Barbulescu / ExTNFS.
An extended tower number-field sieve improved the index-calculus attack on the target group of medium-prime pairings. BN254's practical security dropped to ~128 bits ~100 bits.
2017
BLS12-381 published.
A BLS-family curve with the same embedding degree but a 381-bit base field, chosen so the post-ExTNFS security target lands back at ~128 bits. Adopted by Zcash Sapling, Ethereum BLS signatures, and most subsequent pairing-based work.
2024
CAP-0059 lands on Stellar.
Protocol 22 added host functions for $G_1$ add, $G_1$ scalar multiplication, and the pairing. PLONK on Soroban becomes cost-effective for the first time.
now
Contemporary default.
BLS12-381 is the working choice for new pairing-based deployments. The PQ caveat (§6) is the load-bearing footnote.
platform constraint Chains without a native pairing precompile — Solana, Bitcoin — cannot host this configuration cost-effectively. The deployment's feasibility is tied to the presence of CAP-0059 in the host environment.

references

Primary literature.

Four sources. Two for the curve itself, one for the host-function surface, one for the post-quantum baseline.