drand & BN254

Plain-language overview

Drand is a network of independent organizations that produce a verifiable random value every three seconds. Each round, member organizations participate in a threshold-BLS signing ceremony: a configured threshold of the members collectively produces one aggregate signature. No single member, and no subset smaller than the threshold, can forge one alone. The signature itself is the randomness — pseudorandom under standard cryptographic assumptions, public and verifiable by anyone.

The federation is called the League of Entropy. It has been producing beacons continuously since 2019. Members include Cloudflare, Protocol Labs, Ethereum Foundation, Kudelski, ChainSafe, EPFL, University of Chile, UCL, and a handful of others. Drand publishes several “chains” in parallel, each with its own group public key and cadence. Alea verifies the evmnet chain: 3-second cadence, BN254 curve, designed specifically for cross-VM verification.

Why threshold-BLS instead of a VRF

A VRF (Verifiable Random Function) lets a single key-holder produce a verifiable random output. The trust story is “the key-holder won’t grind, won’t front-run, won’t withhold.” That’s a real assumption: a VRF operator can refuse to publish a value whose outcome they don’t like.

Threshold-BLS distributes the trust. To bias drand you need to compromise enough member organizations to produce a forged aggregate signature. The federation was deliberately built with adversarial relationships between members across continents and institutional types. If the threshold collude, every drand consumer globally is broken, not just yours. That’s stronger than any single-operator VRF you can get on Solana today.

What “the randomness is the signature” means

A BLS signature on a message m is a single elliptic-curve point. For a fixed group public key, that point is uniquely determined by the inputs: there is exactly one valid signature, nobody can choose between two. Once enough members have signed, the signature is fixed.

The drand convention takes sha256(signature_bytes) as the 32-byte randomness output. Every drand consumer computes the same 32 bytes for the same round number. The bytes Alea returns from verify() are the bytes drand defines. There is no Alea-specific transformation.

This means:

• You can pre-commit to a future round and reveal the randomness deterministically when it publishes.
• You can cross-reference. If round 9,337,227 returns randomness X on Alea, drand on Ethereum, and curl https://api.drand.sh/<chain-hash>/public/9337227, all three return the same X.

The math behind the verify

Notation below. Skip to Pointers if you’re wiring a lottery; read on if you’re auditing the program or porting the verifier to another chain.

Why BN254 for evmnet

Drand’s mainnet chain runs on BLS12-381, which is the modern standard for post-2020 BLS work. BN254 (the Barreto–Naehrig curve, 2005) has weaker concrete security — roughly 100-bit against BLS12-381’s 128-bit — but evmnet picked it for two practical advantages.

On the EVM side, Ethereum has supported pairings over BN254 since EIP-197 in 2017. Verifying a BN254 BLS signature costs around 120K gas. BLS12-381 verification on EVM requires either a custom precompile (only landed in Pectra, 2025) or a far more expensive in-EVM implementation.

On Solana, alt_bn128_pairing exists for the same reason — cheap BN254-compatible cryptography. Verifying a BN254 BLS signature on Solana costs ~250K CU for the pairing call. BLS12-381 has no equivalent syscall; implementing it in pure Rust runs into the tens of millions of CU, which is well past what Solana can execute in one transaction.

BN254’s weaker concrete security is a real tradeoff, not a marketing footnote. 100-bit security doesn’t mean “broken”; it means drand and the consumer accept a wider safety margin against future factoring / discrete-log advances than BLS12-381 consumers do. Whether that margin is large enough for your use case is your call. For randomness feeding a lottery with a one-day settle window, yes. For multi-year immutable commitments anchored to a single BN254 signature, talk to a cryptographer first.

Drand’s evmnet chain is explicitly the cross-VM-friendly chain. Use it when you want the same randomness verifiable cheaply on both EVM and Solana from the same beacon. Use drand’s mainnet (BLS12-381) chain if you want stronger concrete security and your verifier has efficient access to BLS12-381 precompiles.

The verification equation

BLS signature verification reduces to a single pairing check. Let:

• σ ∈ G1 — the aggregate signature (64 bytes uncompressed, what drand publishes)
• pk ∈ G2 — the group public key (128 bytes uncompressed, stored in Config.pubkey_g2)
• G2 — the G2 generator
• m_hash = keccak256(round.to_be_bytes()) — 32 bytes from the 8-byte big-endian round number
• H(m_hash) — hash-to-curve via Shallue–van de Woestijne on G1

A valid signature satisfies:

e(σ, G2) == e(H(m_hash), pk)

Equivalently (what Alea actually evaluates):

e(σ, G2) · e(-H(m_hash), pk) == 1

The alt_bn128_pairing syscall takes a list of (G1, G2) pairs, multiplies their pairings, and returns 1 if the product is 1 in GT. Alea passes two pairs: (σ, G2) and (-H(m_hash), pk). Syscall returns Some(true), the signature is valid; Some(false), invalid; None (syscall Err), inputs were malformed.

Note: the message hashed to the curve is keccak256 of the round bytes, nothing else. No domain separator, no chain_hash concatenation, no RFC 9380 expand_message prefix. This is the evmnet scheme (bls-bn254-unchained-on-g1); changing the preimage would require a different drand chain. Cross-chain substitution is caught at the pairing step, not via message construction — a signature produced against a different group public key simply fails the pairing check.

Hash-to-curve: Shallue–van de Woestijne

Mapping the 32-byte message to a G1 point must be deterministic and admit no manipulable relationship between message and point. The SVDW algorithm does this: a closed-form map from field elements to curve points that covers the curve image evenly and has no known structure a signer could exploit.

Alea’s on-chain implementation is a port of kevincharm/bls-bn254 — the Solidity reference for BN254 BLS verification. The Rust port is in programs/alea-verifier/src/crypto/hash_to_g1.rs. SVDW runs in ~120K CU on Solana, dominated by field-element exponentiations.

Pointers

• drand foundation docs — protocol-level, not Alea-specific
• The original drand paper — Mary Maller et al., 2020
• SIMD-0334 — Solana’s alt_bn128_pairing input-length fix activated March 2026
• EIP-197 — Ethereum’s BN254 pairing precompile
• kevincharm/bls-bn254 — Solidity reference; Alea’s SVDW port source. Same author wrote the BN254 scheme into drand itself, and built Anyrand (the EVM equivalent of what Alea does on Solana).
• randa-mu/bls-solana — Randamu’s BN254 drand verifier prototype for Solana. Proved the shape of the problem; Alea takes it to production. Randamu also runs drand itself.