EIP-2537 introduces BLS12-381 precompiles to Ethereum

EIP-2537 introduces seven precompiles for BLS12-381 curve operations to the Ethereum execution layer. This addition replaces the 80-bit security provided by the existing BN254 precompile with 120 bits of security for pairing-friendly curve operations. Because BLS12-381 provides 120 bits of security compared to the 80 bits offered by BN254, developers can now implement cryptographic primitives that meet modern safety requirements for zero-knowledge proofs and multi-signature aggregation. Many zero-knowledge protocols, including Groth16 and PlonK, require this level of security for stable operation. The BLS12-381 curve also powers the signature algorithm used by hundreds of thousands of validators on the Ethereum Beacon Chain. Developers can now perform operations like signature verification more efficiently without depending on custom third-party libraries. This security upgrade addresses the limitations of the BN254 curve, which many zkRollup projects have identified as insufficient for advanced scalability solutions like data availability and multi-signature aggregation.

Precompile operations and encoding formats

The seven new precompiles enable specific operations including point addition, multi-scalar-multiplication (MSM), pairing checks, and field-to-curve mappings. Each operation uses specific encoding formats for field elements and curve points. A base field element (Fp) uses 64 bytes via BigEndian encoding, where the top 16 bytes are always zeroes due to the 381-bit modulus. Elements of the quadratic extension field (Fp2) use 128 bytes through the concatenation of two Fp elements, $c_0$ and $c_1$. G1 points require 128 bytes of encoding, whereas G2 points require 256 bytes. For operations involving multiple points, such as G1 addition, the call expects 256 bytes of input to represent two 128-byte points. G2 addition calls require 512 bytes to represent two 256-byte points. Scalars for multiplication operations use 32-byte BigEndian encoding. If an input cannot be a valid encoding of field elements, the precompile returns an error. The point of infinity is represented by a sequence of 128 or 256 zero bytes. The mapping functions only perform field arithmetic to map a field element into a curve point and do not handle the mapping of byte strings into field elements.

The BLS12 curve is defined by specific parameters where the coefficient A equals 0 for all curves. Field Fp is the finite field of size p with elements represented as integers between 0 and $p-1$. Field Fp2 is defined as $F_p[X]/(X^2-nr^2)$ with elements $e_l = c_0 + c_1 \cdot v$, where $v$ is the formal square root of $nr^2$ represented as integer pairs. Group G1 consists of Fp pairs $(x,y)$ and Group G2 consists of Fp2 pairs $(x’,y’)$. For these groups, the point $(0,0)$ is not on the curve, so a sequence of 128 or 256 zero bytes encodes the point of infinity.

MSM operations utilize Pippenger’s algorithm to provide a speedup over naive multiplication. For pairing checks, the call expects $384 \cdot k$ bytes of input, where $k$ is the number of (G1, G2) pairs.

Gas pricing and hardware benchmarks

The current gas schedule for these precompiles does not always align with real-world computation time. On a Ryzen 7840U, mapping an element to a G2 point achieves 702.17 MGas/s. However, on an older Intel i5-5257U, that same operation only achieves 230 MGas/s. The G2 functions are severely overcosted. For pairing checks, the current price is $32600 \cdot k + 37700$ gas, but some testers suggest the price should move to $8600 \cdot k + 13000$ gas. This is because the current price is five times the actual cost. For MSMs, the cost is calculated using a formula that includes a discount factor based on the number of pairs $k$ and a multiplier of 1000. For example, G1MSM with 2 pairs costs 21312 gas, while G1MSM with 128 pairs costs 267264 gas. On a 15W CPU without assembly, most operations can achieve 60 MGas/s.

You already know the distinction between the execution and consensus layers, so I will skip the background on how Pectra connects them. The gas schedule for pairing functions depends on the input length. If a call to a precompile results in an error, the gas supplied along with the CALL or STATICCALL is burned. Will the current gas schedule for G2 operations eventually undergo the same revisions suggested by independent benchmarks?

Cryptographic applications in smart contracts

EIP-2537 allows for practical implementation of high-performance cryptographic applications. A DAO with 1,000 members can aggregate signatures off-chain into one. The smart contract only verifies a single collective signature on-chain to validate all votes. This reduces the gas cost for each voter and encourages participation in governance. The precompiles also support zero-knowledge proof (ZKP) verification for Layer 2 solutions. Verifying a BLS12-381 based ZK proof with a Solidity implementation can cost over 140,000 gas per operation. A full privacy transfer requiring three to five such operations would be virtually unusable on a mainnet without these precompiles. With EIP-2537, these costs can be reduced to just a few thousand gas.

Helios, a ZK Ethereum light client, uses these precompiles to verify 512 signatures for the sync committee. This process dropped from 6 billion cycles to 50 million cycles. The BLS12-381 curve also supports KZG commitments, which are used for blob verification in EIP-4844. This provides the infrastructure needed for Ethereum to adopt future scalability technologies. By enabling efficient pairing operations, the precompiles allow for faster processing of cryptographic proofs in multi-chain environments. The introduction of EIP-2537 provides the necessary cryptographic security for ZK-based scaling, but the current gas pricing for G2 operations remains inefficiently high.