Why BN254, and when to switch off it

Dax the Dev

Why BN254, and when to switch off it

15 April 2026 10 min read verified human-written

Last updated: 15 April 2026

Print view

Sections

The minimum cryptography you need
Where the 128 bits went
The migration hierarchy
Why the IETF still hasn’t picked one
Pairing arithmetic, by hand
What changes if we move to BLS12-381
Where this lands in the stack
Further reading

Every production ZK system you can name in 2026 — Zcash Sapling, Aleo, Mina, Filecoin’s PoRep, Solana’s alt_bn128_* syscalls, the Ethereum precompile at 0x06/0x07/0x08, zera-sdk — runs Groth16 over the same curve. BN254. A Barreto–Naehrig curve with a 254-bit base field, embedding degree 12, and a pairing that has been the default in pairing-based cryptography for nearly two decades.

It is also the curve that has lost the most bits of advertised security in the last ten years.

This post is the long answer to two questions that come up in every cryptography review I run with a serious team: why is BN254 still the default in 2026, and when do we get off it.

The minimum cryptography you need

A pairing is a bilinear map

e : \mathbb{G}_1 \times \mathbb{G}_2 \to \mathbb{G}_T

with $\mathbb{G}_1, \mathbb{G}_2$ cyclic groups of prime order $r$ on an elliptic curve $E$ , and $\mathbb{G}_T$ a multiplicative subgroup of an extension field $\mathbb{F}_{p^k}$ . Bilinear means

e(a P, b Q) = e(P, Q)^{ab}

for any $a, b \in \mathbb{Z}_r$ and generators $P, Q$ . That single equation is the entire reason pairing-based cryptography exists — it lets you “multiply in the exponent” across two different groups, which is exactly what Groth16’s verification equation needs.

Two parameters drive everything. The embedding degree $k$ is the smallest integer with $r \mid p^k - 1$ ; it sets the size of the target field $\mathbb{F}_{p^k}$ . The base field characteristic $p$ sets the cost of every operation in $\mathbb{G}_1$ . The security of the pairing rests on:

The discrete log problem (DLP) in $\mathbb{G}_1$ and $\mathbb{G}_2$ — protected by Pollard’s rho, cost $\sqrt{r}$ , so we want $r \approx 2^{256}$ for 128-bit security.
The DLP in $\mathbb{F}_{p^k}^*$ — protected by the number field sieve, cost subexponential in $p^k$ , so we want $p^k$ large enough that NFS is no easier than $\sqrt{r}$ .

The trick of pairing-friendly curve design is to find $(p, r, k)$ where both DLPs are hard and $p$ is small enough that field operations don’t dominate. BN curves use the parameterisation

p(t) = 36 t^4 + 36 t^3 + 24 t^2 + 6 t + 1,

r(t) = 36 t^4 + 36 t^3 + 18 t^2 + 6 t + 1,

with $E: y^2 = x^3 + 3$ defined over $\mathbb{F}_p$ and embedding degree $k = 12$ . Pick $t$ such that $p$ and $r$ are both prime, and you get a curve. BN254 is the choice $t = 4965661367192848881$ — an integer carefully chosen so $p$ has 254 bits and $r$ has 254 bits, and so the resulting field arithmetic is reasonably efficient.

Where the 128 bits went

When BN254 was deployed in 2010-2015, the security argument was: $p^{12} \approx 2^{3048}$ , the NFS algorithm at the time required $\approx 2^{128}$ field operations to break the DLP in $\mathbb{F}_{p^{12}}^*$ , and Pollard’s rho on $\mathbb{G}_1$ required $\approx 2^{127}$ . Both legs landed at 128-bit security. Done.

Then Kim and Barbulescu (2016) introduced exTNFS, an extended Tower NFS variant that exploits the structure of $\mathbb{F}_{p^k}$ when $k$ has a non-trivial factorisation (which $k = 12 = 4 \cdot 3$ does). The complexity of NFS dropped, and the Barbulescu-Duquesne (2019) update re-estimated the security of BN254 at roughly 100-110 bits — depending on which constant in the NFS asymptotic you trust.

That is the gap. The curve is not broken. The pairing still works. But “BN254 = 128-bit security” was the marketing line, and after 2016 it should have been “BN254 ≈ 100 bits.”

The honest table:

Option	Cost	Latency	Blast radius	Notes
BN254	~254-bit base field; cheapest pairing in production	Best verifier perf; ~3ms Groth16 verify on Solana	~100-110 bits actual security after exTNFS	Default in Ethereum precompile, Solana, Zcash Sprout, zera-sdk. Fine for 2026; not a forever choice.
BLS12-381	~381-bit base field; ~50% slower pairings	Verifier ~5-7ms typical	~120-126 bits actual security	Ethereum 2.0 BLS signatures, Zcash Sapling, Filecoin. The realistic upgrade target.
BLS12-446	~446-bit base field; ~80% slower than BN254	Verifier ~7-9ms	~128 bits with margin	Theoretically clean 128-bit choice; minimal deployment as of 2026.
BLS24-509	Larger base, embedding degree 24, very fast G_T arithmetic	Verifier ~6-8ms	~128 bits, more conservative NFS margin	Niche; competes with BLS12-381 on perf, more on paper than in production.
Post-quantum (lattice / hash / code)	No pairings; structurally different	STARK-style verification, larger proofs	Quantum-secure (still active research)	When pairing-based cryptography retires, this is what replaces it. Not 2026, probably 2030+.

The blast-radius column is the load-bearing one. BN254 is not broken in 2026. A 100-bit security level still costs an attacker $\sim 2^{100}$ field operations, which is not within the budget of any actor we model. But it is also not a curve you start a fresh decade-long deployment on.

The migration hierarchy

The pairing-friendly curve landscape, drawn as a hierarchy of “what would I deploy next”:

flowchart TD
BN254[BN254 — current default, ~100-110 bit security after exTNFS] --> BLS381[BLS12-381 — ~120-126 bit, Ethereum/Filecoin/Sapling]
BLS381 --> BLS446[BLS12-446 — clean ~128 bit with margin]
BLS381 --> BLS24[BLS24-509 — embedding degree 24, niche]
BLS446 --> PQ[Post-quantum candidates: lattice (Falcon/Dilithium), STARK-based]
BLS24 --> PQ
BN254 -.-> PQ
classDef now fill:#1a1a1a,stroke:#4ade80,color:#4ade80
classDef next fill:#1a1a1a,stroke:#a3a3a3,color:#e8e8e8
classDef long fill:#1a1a1a,stroke:#737373,color:#a3a3a3
class BN254 now
class BLS381,BLS446,BLS24 next
class PQ long

The bottom row is what kills pairing-based cryptography eventually. Shor’s algorithm runs in polynomial time on a sufficiently large quantum computer, the discrete log breaks, and every curve in the diagram above goes to zero overnight. The realistic time horizon for that is not 2026 — the largest credible quantum factorisation as of last year is still toy-scale — but it is the reason you build a hash function migration story into your protocol from day one. We did this in zera-sdk by isolating the curve choice to a single crates/zera-sdk-core/src/curve.rs module. A future migration to BLS12-381 is one type alias and a regenerated .zkey. A migration to a lattice-based scheme is a bigger lift but the seam is clean.

Why the IETF still hasn’t picked one

The IETF CFRG has been running a pairing-friendly curves working group since 2018. As of draft 11, the recommendation lists BLS12-381 and BN462 as the two curves with 128-bit security after exTNFS. BN254 is explicitly not recommended for new deployments — the draft notes:

The BN curves with smaller parameters such as BN254 should not be used for applications requiring 128-bit security level due to the recent improvements of the number field sieve algorithm. Implementations targeting the 128-bit security level SHOULD use BLS12-381 or BN462.

IETF CFRG, pairing-friendly-curves draft ↗ source

The reason BN254 is still the production default in 2026 despite this is one part path-dependence (the Ethereum precompile is BN254 and rewriting that is a hard fork) and one part cost (BLS12-381 is roughly 50% slower per pairing and 50% larger per group element). For a privacy pool that is already paying tens of milliseconds per proof, the trade-off is real.

The clean argument: BN254 today, BLS12-381 next, lattice-based when the quantum threat becomes credible. That ordering is what every serious protocol designer I’ve talked to in the last year converges on.

Pairing arithmetic, by hand

The pairing itself is a Miller-loop algorithm followed by a final exponentiation. It is unreasonable to derive in a blog post — go read Barreto, Galbraith, Ó hÉigeartaigh, Scott (2007) for the optimal-Ate construction — but the bilinearity check is one line and worth seeing:

e([a]P, [b]Q) = e(P, Q)^{ab}

The toy below verifies this property over a tiny pairing-friendly toy curve. It uses a synthetic group and a synthetic pairing — not BN254, because computing a real BN254 pairing in 60 lines of TypeScript is not honest pedagogy. The shape of the relations is real. The numbers are not.

sandbox [ vanilla-ts ]

run

Runnable playground (requires JavaScript)

/index.ts

// Toy "pairing" demonstration over a tiny modular group.
// This is NOT a real pairing — there is no curve here, no Miller loop,
// no final exponentiation. It demonstrates the algebraic SHAPE of
// bilinearity: e(aP, bQ) == e(P, Q)^{ab}.
//
// For real BN254 / BLS12-381 pairings, use arkworks or blst.

const Q = (1n << 31n) - 1n; // small Mersenne prime
const G = 7n;               // a generator of the multiplicative group
const ORD = Q - 1n;         // group order = Q-1 since Q prime

function modpow(a: bigint, e: bigint, m: bigint): bigint {
let r = 1n, base = a % m, exp = e;
while (exp > 0n) {
  if (exp & 1n) r = (r * base) % m;
  base = (base * base) % m;
  exp >>= 1n;
}
return r;
}

// "G_1" and "G_2" are both the same multiplicative group here for the
// demo. In real pairing curves they're DIFFERENT EC subgroups.
function scalarMul(P: bigint, k: bigint): bigint {
return modpow(P, k, Q);
}

// "Pairing": e(P, Q) = (P^Q) -- not real, just a synthetic bilinear map.
// Real pairings are far more involved; this is the algebra.
function pair(P: bigint, R: bigint): bigint {
// We model e(g^a, g^b) = g^{ab} by pairing exponents.
// Recover a, b via baby-step (only feasible because Q is tiny).
const a = babyStepGiantStep(P);
const b = babyStepGiantStep(R);
return modpow(G, (a * b) % ORD, Q);
}

function babyStepGiantStep(target: bigint): bigint {
// tiny demo helper — fine for Q ~ 2^31.
const m = 1n << 16n;
const table = new Map<string, bigint>();
let cur = 1n;
for (let j = 0n; j < m; j++) { table.set(cur.toString(), j); cur = (cur * G) % Q; }
const factor = modpow(modpow(G, m, Q), ORD - 1n, Q); // G^{-m}
let gamma = target;
for (let i = 0n; i < m; i++) {
  const hit = table.get(gamma.toString());
  if (hit !== undefined) return (i * m + hit) % ORD;
  gamma = (gamma * factor) % Q;
}
throw new Error("no log");
}

(async () => {
const out = document.getElementById("out")!;
const lines: string[] = [];

const a = 17n, b = 23n;
const P = scalarMul(G, a);
const R = scalarMul(G, b);

// Direct: e(P, R)
const direct = pair(P, R);
// Bilinear factor: e(G, G)^{ab}
const eGG = pair(G, G);
const expected = modpow(eGG, (a * b) % ORD, Q);

lines.push(`a = ${a}, b = ${b}`);
lines.push(`P = G^a = ${P}`);
lines.push(`R = G^b = ${R}`);
lines.push(`e(P, R)         = ${direct}`);
lines.push(`e(G, G)^{ab}    = ${expected}`);
lines.push(`bilinear holds: ${direct === expected}`);

// Try with mismatched scalars to confirm the structure.
const P2 = scalarMul(G, 5n);
const R2 = scalarMul(G, 11n);
lines.push("");
lines.push(`e(G^5, G^11)    = ${pair(P2, R2)}`);
lines.push(`e(G, G)^{55}    = ${modpow(eGG, 55n, Q)}`);

out.textContent = lines.join("\n");
})();

/index.html

<!DOCTYPE html>
<html>
<body>
  <pre id="out" style="font-family: 'Geist Mono', ui-monospace, monospace; padding: 1rem; background: #0a0a0a; color: #4ade80; line-height: 1.6;">running...</pre>
  <script type="module" src="/index.ts"></script>
</body>
</html>

Open the vanilla-ts template on codesandbox.io

The Rust shape of a real pairing — using arkworks — is much closer to a one-liner once the curve is in scope:

bilinearity (skeleton) [ rust ]

open

Runnable playground (requires JavaScript)

src/main.rs

// Skeleton showing how arkworks expresses bilinearity. Won't compile here
// without the ark-bn254 / ark-ec deps; this is the SHAPE of the production
// code in zera-sdk-core/src/pairing.rs.

// use ark_bn254::{Bn254, Fr, G1Affine, G2Affine};
// use ark_ec::{pairing::Pairing, PrimeGroup};

fn main() {
  // let g1 = G1Affine::generator();
  // let g2 = G2Affine::generator();
  // let a = Fr::from(17u64);
  // let b = Fr::from(23u64);
  //
  // let p1 = (g1 * a).into();
  // let q1 = (g2 * b).into();
  //
  // let lhs = Bn254::pairing(p1, q1);
  // let rhs = Bn254::pairing(g1, g2).pow(&[(a * b).into_bigint().0[0]]);
  //
  // assert_eq!(lhs, rhs); // bilinearity
  //
  // The whole Groth16 verifier reduces to a constant number of these
  // pairings — three for Groth16, plus a multi-pairing-product check.
  println!("see crates/zera-sdk-core/src/pairing.rs for the real code");
}

Open this snippet on the Rust Playground

The real implementation lives in arkworks-rs/algebra and supranational/blst. The latter is what production Ethereum and Solana ZK code links against — blst is the BLS12-381 pairing library written by Pierre-Yves Strub and Sergey Vasilyev, audited, and with constant-time multi-scalar multiplication that beats anything else in the open source.

What changes if we move to BLS12-381

The migration cost is not the curve. The migration cost is everything that touches the curve.

Re-run the trusted setup. Groth16 needs a per-circuit setup. Migrating to BLS12-381 means a fresh ceremony for every circuit. That is non-trivial — a Powers-of-Tau ceremony runs for months — but it is also not blocked on cryptography.
Regenerate the verifying keys. Every on-chain verifier ships a verifying key (a few KB of curve points). Those have to be regenerated and re-deployed. On Solana, that’s a program upgrade. On Ethereum, that’s a fresh contract deploy.
Update every prover. snarkjs, rapidsnark, the Rust prover in zera-sdk-core — all of them. The ff and pairing crate ecosystem in Rust is curve-generic, so this is an ark-bn254 → ark-bls12-381 swap and a recompile. The TypeScript side is harder because circomlibjs is BN254-pinned in places.
Eat the verifier-cost hit. A BLS12-381 pairing is roughly 50% more expensive than BN254. On Solana that’s 1500 extra compute units per pairing-based verification. Multiplied by the four pairings in a typical multi-input transfer proof, that’s 6000 CUs — meaningful but absorbable.

We’ve scoped this work for zera-sdk v2 but not yet committed to a date. The bet is: BN254 carries us through 2027 deployments comfortably, and the BLS12-381 migration is a clean lift the moment the broader Solana ecosystem standardises on it (the alt_bls12_381_* syscalls have been in cargo-audit feature flags since 2025).

Where this lands in the stack

In crates/zera-sdk-core/src/curve.rs the curve is a single type alias:

// Currently:
pub type Curve = ark_bn254::Bn254;
pub type Fr = ark_bn254::Fr;
pub type G1 = ark_bn254::G1Affine;
pub type G2 = ark_bn254::G2Affine;

// Future:
// pub type Curve = ark_bls12_381::Bls12_381;
// pub type Fr = ark_bls12_381::Fr;
// ...etc

The whole SDK reads from Curve, Fr, G1, G2. The migration is a four-line swap and a re-ceremony. The cleanliness is on purpose — see Building the Zera SDK: Day One for why we boxed the curve choice the way we did.

What I tell people who ask “should I deploy on BN254 or BLS12-381?”: deploy on BN254 if you need to compose with the Ethereum precompile or the Solana alt_bn128_* syscall today, deploy on BLS12-381 if you don’t and you want the security headroom. The math is the math. The deployment surface is what makes the call.

The minimum cryptography you need

Where the 128 bits went

The migration hierarchy

Why the IETF still hasn’t picked one

Pairing arithmetic, by hand

What changes if we move to BLS12-381

Where this lands in the stack

Further reading

Related

Recursive proof composition without the abyss: Halo to Nova

Poseidon, by hand and by code

Range proofs in 80 lines: Pedersen commitments and a tiny Bulletproof

Merkle inclusion proofs over compressed account state on Solana