BLS12-381

Goal

By the end of this chapter, you should understand what BLS12-381 is, why it is called pairing-friendly, what the names $G_1$, $G_2$, and $G_T$ mean, and why base fields, scalar fields, extension fields, cofactors, subgroup checks, and serialization all matter.

This is a high-level chapter. It distinguishes the BLS curve family from the specific BLS12-381 parameter set, but it does not implement the curve.

Prerequisites

You should know:

• finite fields and extension fields
• elliptic curve groups
• cofactors and subgroup checks
• bilinear pairings
• BLS-style verification equations at a conceptual level

What BLS12-381 Is

BLS12-381 is a specific pairing-friendly elliptic curve parameter set. It is in the Barreto-Lynn-Scott family of curves, but the name "BLS" here refers to the curve family, not the Boneh-Lynn-Shacham signature scheme. The two names are historically related only by acronym overlap.

The "12" refers to embedding degree $12$. The "381" refers to the approximate bit size of the base field modulus. Sean Bowe's original Electric Coin Company post gives the selected parameter values and explains the design target for Zcash's Sapling work: BLS12-381: New zk-SNARK Elliptic Curve Construction.

BLS12-381 is useful for pairing-based protocols because it supports efficient bilinear pairings while targeting a modern security level for many deployed applications.

Pairing-Friendly Curves

A pairing-friendly curve is an elliptic curve chosen so that a bilinear pairing can be computed efficiently.

For BLS signatures, we want groups:

$$G_1,\quad G_2,\quad G_T$$

and a pairing:

$$e : G_1 \times G_2 \to G_T$$

with bilinearity:

$$e(aP, bQ) = e(P, Q)^{ab}$$

Ordinary elliptic curves used for signatures such as ECDSA do not need this pairing structure. BLS12-381 is chosen for protocols that do.

Embedding Degree 12

The embedding degree describes where the target group of the pairing lives. For BLS12-381, the relevant target group is related to an extension field of degree $12$ over the base field.

Informally:

$$G_T \subset \mathbb{F}_{p^{12}}^\times$$

This does not mean users normally manipulate raw elements of $\mathbb{F}_{p^{12}}$ by hand. It means the pairing output lives in a multiplicative group inside a large extension field.

The IETF pairing-friendly curves draft gives BLS curve parameter descriptions and BLS12-381 serialization reference material: draft-irtf-cfrg-pairing-friendly-curves.

Base Field

The base field is the field used for coordinates of the main curve. For BLS12-381, this field is usually written:

$$\mathbb{F}_q$$

or:

$$\mathbb{F}_p$$

depending on the source's notation.

The base field modulus is a large prime of about 381 bits. The Electric Coin Company post lists the concrete hexadecimal value for this modulus and the curve equation:

$$E(\mathbb{F}_q): y^2 = x^3 + 4$$

For this textbook, the important point is not to memorize the modulus. The important point is that BLS12-381 arithmetic is finite-field arithmetic.

Scalar Field

The scalar field is the field used for scalars that multiply group elements. Its modulus is the large prime subgroup order, usually written $r$.

If $P$ is a point in the intended prime-order subgroup, then scalar multiplication uses values modulo $r$:

$$kP = (k \bmod r)P$$

The base field and scalar field are different fields. Confusing them is a common source of implementation and explanation errors.

$G_1$

$G_1$ is a prime-order subgroup associated with the BLS12-381 curve over the base field.

At a high level, elements of $G_1$ are elliptic curve points. In many BLS signature deployments, public keys are represented as $G_1$ points.

For Chia's historical BLS library documentation, a G1Element is a public key and is serialized as 48 bytes in the minimum-pubkey-size convention: Chia-Network/bls-signatures. Chia's docs likewise state that public keys are points in G1: keys and signatures.

$G_2$

$G_2$ is another prime-order subgroup. It is associated with a twist of the curve over an extension field, commonly described over $\mathbb{F}_{q^2}$.

In the same Chia minimum-pubkey-size convention, signatures are represented as $G_2$ points and serialized as 96 bytes. Other protocols can choose the opposite convention, with public keys in $G_2$ and signatures in $G_1$.

The group choice is not just notation. It affects serialization sizes, hash-to-curve choices, and verification conventions.

$G_T$

$G_T$ is the target group of the pairing:

$$e : G_1 \times G_2 \to G_T$$

It is written multiplicatively and is related to the extension field $\mathbb{F}_{q^{12}}$.

Verification equations compare elements of $G_T$. For example, a simplified BLS verification equation has the shape:

$$e(\sigma, P) = e(H(m), PK)$$

depending on which group contains signatures and which contains public keys.

Field Extensions

BLS12-381 pairing computations use extension fields. The original BLS12-381 description includes:

$$\mathbb{F}_{q^2} = \mathbb{F}_q[i]/(i^2 + 1)$$

and a twist curve:

$$E'(\mathbb{F}_{q^2}) : y^2 = x^3 + 4(i + 1)$$

Higher extension fields are used in pairing computation and in the target group. Implementations often organize these fields as towers for efficiency.

Cofactors

The full curve group does not necessarily have prime order. Instead, its order can have the form:

$$h r$$

where $r$ is the large prime subgroup order and $h$ is a cofactor.

The IETF pairing-friendly curves draft describes BLS curves as having curve orders divisible by a large parameterized prime $r$, with cofactors. This is why protocols must distinguish "a point on the curve" from "a point in the correct subgroup."

Subgroup Checks

A subgroup check verifies that a point is in the intended subgroup. A conceptual check is:

$$rP = \mathcal{O}$$

where $r$ is the subgroup order.

Subgroup checks matter for public keys, signatures, and any externally supplied point. A point that decodes and satisfies a curve equation can still be outside the subgroup a protocol expects.

RFC 9380 includes BLS12-381 hash-to-curve suites and discusses cofactor clearing for BLS12-381 G2: RFC 9380.

Serialization Sizes at a High Level

Compressed serialization stores enough information to recover a point while omitting one coordinate. For BLS12-381, common compressed sizes are:

• G1 point: 48 bytes
• G2 point: 96 bytes

The IETF pairing-friendly curves draft describes the Zcash-style BLS12-381 serialization format and these compressed sizes. Chia's key documentation also states private keys are 32 bytes, public keys 48 bytes, and signatures 96 bytes for its BLS usage.

Serialization is not only about byte length. It also includes metadata bits, point-at-infinity handling, subgroup expectations, and canonical encodings.

Canonical means there is one accepted byte representation for a value. Without canonical encodings, the same mathematical point might be represented in multiple byte strings, which can create ambiguity for validation and hashing.

Chia Connection

Chia uses BLS signatures, and its documentation describes Chia keys as BLS-12-381 private keys following the IETF specification and EIP-2333 key derivation. It states that public keys are points in G1 and signatures are points in G2.

For this textbook, that means BLS12-381 is the concrete curve setting behind the later BLS signature and spend-bundle chapters. The mathematical objects introduced earlier now have protocol roles:

• scalar field elements become private-key-like scalars
• G1 points can represent public keys
• G2 points can represent signatures in Chia's convention
• pairings verify signature equations
• subgroup checks and serialization rules protect protocol boundaries

Always check current Chia source and documentation for implementation details.

Common Pitfalls

Confusing BLS the curve family with BLS the signature scheme. BLS12-381 is a curve parameter set. BLS signatures are a signature scheme that can use this curve.

Confusing base field and scalar field. Coordinates and scalars live in different fields.

Thinking every curve point is a valid protocol point. Protocols usually require membership in a specific prime-order subgroup.

Ignoring cofactors. Cofactors are why subgroup checks and cofactor clearing exist.

Assuming every protocol uses the same G1/G2 convention. Some put public keys in G1 and signatures in G2; others reverse that.

Treating serialization as just length. Valid encodings also need canonical representation, metadata interpretation, and point validation.

Exercises

1. In your own words, explain what the "12" and "381" in BLS12-381 refer to.
2. What is the difference between the base field and the scalar field?
3. Which group is written multiplicatively: $G_1$, $G_2$, or $G_T$?
4. Explain why a valid-looking curve point may still need a subgroup check.
5. Why are G2 compressed encodings larger than G1 compressed encodings at a high level?
6. Give one reason a protocol specification must state whether signatures live in G1 or G2.
7. Describe how cofactors relate the full curve group to the intended prime-order subgroup.
8. Read one linked source in this chapter and identify one fact that should not be guessed from notation alone.

Further Reading

• BLS12-381: New zk-SNARK Elliptic Curve Construction
• IETF draft: Pairing-Friendly Curves
• RFC 9380: Hashing to Elliptic Curves
• Chia keys and signatures documentation
• Chia-Network/bls-signatures archive