layer 7: why specific curves are chosen not all elliptic curves have hard discrete log problems. curve selection is security engineering secp256k1 (Bitcoin, Ethereum transactions): → y² = x³ + 7 over a 256-bit prime field → Koblitz curve (a = 0) for efficiency → chosen by Certicom, adopted by Bitcoin early → ~128-bit security against classical attacks BN254 (Ethereum ZK precompiles): → Barreto-Naehrig curve → pairing-friendly (embedding degree 12) → used for Groth16 verification on Ethereum → originally ~128-bit security, now estimated at ~100-110 bits due to improved NFS attacks on the pairing target group F_p^12 → still used because Ethereum precompiles support it and migration is costly BLS12-381 (Ethereum consensus, Zcash): → Barreto-Lynn-Scott curve → pairing-friendly (embedding degree 12) → designed AFTER the NFS improvements that weakened BN254 → 381-bit base field chosen specifically to maintain 128-bit security even with improved attacks → the "12" is the embedding degree, "381" is the field size ed25519 (many non-Ethereum systems): → Edwards curve over a 255-bit field → designed by Bernstein for maximum implementation safety → constant-time arithmetic, no exceptional cases → not pairing-friendly (no pairings possible, which means no Groth16) Pasta curves (Pallas/Vesta, used in Halo 2 and Mina): → designed as a 2-cycle: Pallas's scalar field = Vesta's base field and vice versa → enables efficient recursive proofs without pairings → not pairing-friendly (by design, since the goal is pairing-free recursion) BabyJubJub (used in Circom circuits for in-circuit signature verification): → twisted Edwards curve defined over BN254's scalar field → designed so that curve arithmetic is NATIVE inside BN254 circuits → enables efficient EdDSA signature verification in ZK circuits (~6K constraints vs ~500K for secp256k1 ECDSA) each curve is a specific point in the tradeoff space: → security level (determined by curve parameters and the best known attacks) → pairing support (determines which proof systems are possible) → field compatibility (determines how expensive in-circuit operations are) → implementation safety (determines how easy it is to write bug-free code)