EIP-2537: Precompile for BLS12-381 Curve Operations

EIP-2537 upgrades Ethereum by integrating the BLS12-381 curve, enhancing cryptographic security and adding precompiles for efficient operations like MSM and pairing checks. Here we will highlight its improvements in security, performance, scalability, and their impact on Ethereum’s consensus mechanisms.

• EIP-2537 adds support for BLS12-381 curve operations to Ethereum. This improves cryptographic security from ~80-bit (BN254) to 128-bit, meeting modern standards.
• It introduces seven new precompiles for efficient execution of operations like point addition, multi-scalar multiplication (MSM), and pairing checks.
• Motivation: The existing BN254 curve is insufficient for long-term security. BLS12-381 is crucial for BLS signatures (used in Ethereum for validator attestation aggregation) and zkSNARKs.
• Benefits: Precompiles avoid expensive Solidity implementations, enhancing performance and enabling scalable consensus mechanisms by reducing verification time.
• Gas Schedule: Pricing for operations like MSM and pairing is designed to reflect computational costs and encourage efficient batching.
• Security: The EIP mandates subgroup membership validation for most operations to prevent cryptographic attacks.
• Rationale: A dedicated MSM precompile optimizes aggregate signature verification, and a separate single multiplication precompile is not needed as MSM handles it.

This Ethereum Improvement Proposal (EIP) adds support for operations over the BLS12-381 pairing-friendly curve through a dedicated precompile. The curve, designed for efficiency and security, is widely used in BLS signature schemes and zkSNARKs. Before Pectra Upgrade, Ethereum only supported BN254, a curve offering ~80-bit security, which is insufficient for long-term cryptographic robustness. This EIP, launched in the Ethereum Pectra Upgrade, provides a 128-bit security level, using BLS12-381 curve, aligning Ethereum with modern cryptographic standards and practices.

By exposing low-level cryptographic operations as precompiles, developers can avoid expensive and inefficient implementation of elliptic curve operations in Solidity or Yul. This enhances performance, encourages adoption of verifiable computation techniques, and lays a secure foundation for advanced consensus mechanisms.

The Ethereum Virtual Machine (EVM) currently includes precompiles for elliptic curve operations on the BN254 curve, primarily used in Groth16 zkSNARK verifications. While BN254 has served its purpose in early zk-based applications, its 80-bit security level is now widely regarded as inadequate for medium to long-term cryptographic assurance.

Modern cryptographic systems require at least 128-bit security to meet regulatory standards and ensure resilience against advances in computing power, including those posed by quantum threats. BLS12-381 addresses this need by offering a pairing-friendly elliptic curve with 128-bit security, superior performance in pairing operations, and wide standardization across the blockchain ecosystem.

BLS signatures, in particular, benefit significantly from this precompile. They allow multiple signatures to be aggregated into a single compact proof, reducing bandwidth and storage requirements. Additionally, batch verification of BLS signatures drastically improves computational efficiency, especially in systems with a large number of participants, such as validators in Ethereum.

This section formalizes the cryptographic properties and definitions of BLS12-381 used in the precompile. It includes the base field, curve equation, extension field, group definitions, and pairing parameters.

This EIP introduces seven new precompiles to the Ethereum Virtual Machine, each targeting a specific cryptographic operation over the BLS12-381 curve. These operations are designed to be accessible via low-level call instructions (CALL, STATICCALL) and have well-defined addresses within the precompile address space.

Each precompile facilitates a distinct type of operation:

• Point addition in G1 and G2 allows for combining two points on the elliptic curve.
• Multi-scalar multiplication (MSM) is a core operation in BLS signature aggregation and batch verification.
• Pairing checks validate the bilinearity condition across multiple point pairs.
• Field-to-curve mappings are required to hash messages to elliptic curve points in BLS signature schemes.

This modular approach allows for optimal gas pricing and avoids overhead from composing operations manually using lower-level primitives.

To ensure interoperability and alignment with EVM expectations, all precompiles use standardized input and output encoding formats. These are designed to match 32-byte word alignment and are compatible with Solidity types such as uint256 or bytes32 arrays.

• Scalars are encoded as 32-byte big-endian unsigned integers, consistent with typical Ethereum ABI encoding.
• Field elements (Fp and Fp2) are encoded using 64 or 128 bytes, respectively. The additional zero-padding ensures the encoded values are always less than the modulus.
• Curve points are encoded as concatenated field elements: 128 bytes for G1 (x, y) and 256 bytes for G2 (x, y) using their Fp2 representation.
• Points at infinity, or identity elements, are represented using all-zero byte strings, a convention that simplifies detection of special values during execution.

These encoding schemes are critical for validating input correctness and preventing malformed input from bypassing cryptographic constraints.

Each precompile expects a well-defined binary input format and returns an equally structured output. Inputs are structured to reflect one or more operations (e.g., scalar multiplications or point pairs) and the total input length is used to infer how many operations are being performed.

Key behaviors:

• If input data does not conform to the expected length (e.g., not divisible by the tuple size), the precompile will reject it.
• Empty inputs to variable-length operations (e.g., MSM, pairing) are disallowed.
• For MSMs, each input group contains a point (G1 or G2) and a scalar.
• For pairing checks, each tuple contains a G1 and a G2 point, and the operation returns true or false as a 32-byte output.

This strict ABI design avoids ambiguous interpretations and ensures that clients can safely rely on precompile results.

Gas pricing is a critical design aspect of this EIP. The goal is to reflect actual computational costs while avoiding underpricing (which can lead to DoS vectors) or overpricing (which discourages usage).

Fixed-cost operations (e.g., G1ADD, G2ADD) are priced based on empirical benchmarking.

Correctness and cryptographic security depend on ensuring that inputs reside in the correct subgroup of the elliptic curve. Small subgroup attacks can compromise security if unchecked.

The EIP enforces that:

• All MSM and pairing operations must validate subgroup membership.
• Field-to-curve mappings must ensure output lies on the correct curve, but not necessarily in the correct subgroup.

Implementations may use optimized techniques such as cofactor clearing or endomorphism-based checks. Failing to validate subgroup membership is grounds for rejecting the input and burning all provided gas.

Security considerations also include gas-based denial-of-service protection, achieved through bounded gas formulas and avoidance of unbounded loops in implementation.

The design decisions in this EIP balance performance, simplicity, and compatibility:

To ensure mathematical correctness, the EIP defines a list of algebraic properties that implementations must satisfy. These properties serve as a test suite specification for both correctness and compliance.

EIP-2537 provides Ethereum with essential cryptographic functionality for BLS12-381, enabling modern cryptographic systems to execute efficiently and securely on-chain. It paves the way for scalable and provable consensus mechanisms, BLS-based voting systems, zkSNARK verification, and efficient signature aggregation.

The proposal defines precise interfaces, gas pricing, and correctness constraints, ensuring safety and interoperability across clients. It is a critical step toward Ethereum’s cryptographic maturity in the post-merge, proof-of-stake world.

• Ethereum Improvement Proposals, no. 2537
• Electric Coin Co.: BLS12-381: New zk-SNARK Elliptic Curve Construction
• IETF: Pairing-Friendly Curves