Skip to main content
const crypto = @import("crypto");
var out = try allocator.alloc(u8, crypto.bls12_381.g1_output_size());
// crypto.bls12_381.g1Mul(input_bytes, out); // prepare proper input
allocator.free(out);

​
title: BLS12-381 description: Consensus-layer-only pairing-friendly elliptic curve for Beacon Chain validator signatures (NOT for application development)

​
BLS12-381

BLS12-381 is a pairing-friendly elliptic curve at the 128-bit security level, designed for BLS (Boneh-Lynn-Shacham) signature aggregation in proof-of-stake consensus systems.

​
Overview

Consensus layer only - Used exclusively in Ethereum’s Beacon Chain for validator signatures. NOT available in execution layer (no EVM precompiles on mainnet, only L2s). Signature aggregation reduces bandwidth from ~100MB to ~1MB per epoch. BLS12-381 is a Barreto-Lynn-Scott pairing-friendly curve specifically designed for blockchain use cases requiring signature aggregation and zero-knowledge proofs. Named after its designers and 381-bit prime field, it has become the standard for Ethereum’s proof-of-stake consensus.

​
Who Should Use This?

Consensus Client Developers: Building Ethereum consensus clients (Prysm, Lighthouse, Teku, Nimbus) NOT for:
  • Smart contract developers (use BN254 for zkSNARKs)
  • DApp developers (use execution layer primitives: secp256k1, keccak256)
  • Most application developers (consensus layer is abstracted away)

​
Why BLS12-381?

Security: 128-bit security level (comparable to 3072-bit RSA or 256-bit ECDSA) Efficiency: Fastest pairing computation among comparable security curves Adoption: Standard across major blockchains (Ethereum 2.0, Zcash, Filecoin, Chia) Signature Aggregation: Unique property enabling compact validator signatures

​
Ethereum Use Cases

  • Validator Signatures: Aggregate thousands of validator signatures into 96 bytes (Beacon Chain only)
  • Sync Committees: Light client proofs with compact signature aggregation (consensus layer)
  • Attestation Aggregation: Reduce consensus message bandwidth by 99%
  • NOT for Smart Contracts: Use BN254 instead for application-layer zkSNARKs and DeFi
  • NOT for DApp Development: Consensus client development only

​
Mathematical Foundation

​
Curve Equation

G1 (base field Fp): 
y² = x³ + 4
G2 (extension field Fp2): 
y² = x³ + 4(1 + i)

​
Field Parameters

Base Field Modulus (p): 381-bit prime 
p = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
Scalar Field Modulus (r): 255-bit prime (curve order) 
r = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001
Embedding Degree: k = 12 Extension Tower: Fp → Fp2 → Fp6 → Fp12

​
Pairing Function

Optimal Ate Pairing: e: G1 × G2 → GT Properties:
  • Bilinearity: e(aP, bQ) = e(P, Q)^(ab)
  • Non-degeneracy: e(G1, G2) ≠ 1 (identity in GT)
  • Efficiency: ~1-2ms computation on modern CPUs
Pairing Check: 
e(P1, Q1) · e(P2, Q2) · ... · e(Pn, Qn) = 1

​
Implementation Details

NOT for Application Development - BLS12-381 is consensus-layer-only infrastructure. Most developers will never directly use this. For smart contract zkSNARKs and privacy-preserving DeFi, use BN254 instead.

​
Access & Availability

Native C ONLY: Via libblst library (production-grade, audited by Trail of Bits and NCC Group) NO JavaScript/TypeScript interface: Consensus layer operations, not exposed to application tier NO WASM: Not needed for application development - used exclusively by consensus client implementations Accessible via: Native Zig bindings only, for consensus client development (Prysm, Lighthouse, etc.)

​
Key Operations

When building consensus clients:
  • G1 point operations: Validator public keys (48 bytes compressed)
  • G2 point operations: BLS signatures (96 bytes compressed)
  • Pairing check: Signature verification using bilinear pairing
  • Multi-signature aggregation: Combine thousands of signatures into one

​
Documentation

​
Core Concepts

  • Signatures - BLS signature scheme, aggregation, batch verification
  • Pairing - Bilinear pairing operation, optimal ate pairing algorithm
  • G1 Operations - Point addition, scalar multiplication, MSM
  • G2 Operations - Extension field operations, public key handling

​
Advanced Topics

​
Implementation

  • Usage Patterns - Ethereum validators, sync committees, zkSNARKs
  • Security - Side-channel resistance, rogue key attacks, best practices

​
Point Formats

​
G1 Points (48 bytes compressed, 96 bytes uncompressed)

Uncompressed Format (128 bytes padded for precompiles): 
| x-coordinate | y-coordinate |
|   64 bytes   |   64 bytes   |
Compressed Format (48 bytes):
  • MSB indicates compression + sign of y-coordinate
  • Remaining 381 bits encode x-coordinate

​
G2 Points (96 bytes compressed, 192 bytes uncompressed)

Uncompressed Format (256 bytes padded for precompiles): 
| x.c0 | x.c1 | y.c0 | y.c1 |
|  64  |  64  |  64  |  64  |
Compressed Format (96 bytes):
  • First 48 bytes: x.c1 (with compression flags)
  • Second 48 bytes: x.c0

​
Implementation Status

​
Native (Production - Consensus Clients Only)

Library: BLST (Supranational)
  • Audited by Trail of Bits, NCC Group
  • Assembly-optimized for x86_64, ARM64
  • Constant-time, side-channel resistant
  • Used in all major Ethereum consensus clients (Prysm, Lighthouse, Teku, Nimbus)
Location: lib/blst/ Access: Native Zig bindings only - NO JavaScript/TypeScript API

​
WASM

Status: Not available (not needed for application development) Rationale: BLS12-381 is consensus-layer infrastructure. Application developers use execution layer primitives (secp256k1, keccak256) or BN254 for zkSNARKs.

​
Security Level

Target Security: 128 bits (classical), 64 bits (quantum) Attack Complexity:
  • Discrete log on G1/G2: ~2^128 operations
  • Pairing inversion: Computationally infeasible
  • MOV attack: Prevented by embedding degree 12
Recommended Until: 2030+ (NIST guidelines)

​
EIP-2537 Precompiles

NOT on Mainnet - Proposed BLS12-381 precompiles for EVM, but NOT activated on mainnet yet. Some L2s may implement them for zkRollup verification.
Status: Proposed (pending mainnet activation) Precompile Addresses (0x0b - 0x13, if activated):
  • G1 operations: ADD, MUL, MSM
  • G2 operations: ADD, MUL, MSM
  • Pairing check
  • Hash-to-curve mappings
Gas Costs (proposed):
  • G1 addition: 500 gas
  • Pairing base: 115,000 gas
  • Pairing per pair: 23,000 gas
Current Reality: Only available on consensus layer (Beacon Chain). For execution layer zkSNARKs, use BN254 precompiles (0x06-0x08) which ARE on mainnet. See full precompile documentation →

​
Performance

Native (BLST on x86_64):
  • G1 addition: ~15 μs
  • G1 multiplication: ~80 μs
  • G2 multiplication: ~200 μs
  • Pairing (single): ~1.2 ms
  • Pairing check (2 pairs): ~2 ms
  • MSM (100 G1 points): ~8 ms
Comparison to BN254:
  • Pairing: ~2x slower
  • Security: 128-bit vs 100-bit
  • Future-proof: Better long-term security
See detailed benchmarks →
  • KZG Commitments - Polynomial commitments using BLS12-381 (consensus layer, EIP-4844)
  • BN254 - USE THIS for execution layer zkSNARKs and smart contracts
  • secp256k1 - Execution layer transaction signatures
  • Precompiles: BLS12-381 - EIP-2537 implementation (NOT on mainnet)

​
References