EIP-1962: EC arithmetic and pairings with runtime definitions for Shanghai-candidate

EIP-1962 is to add general EC arithmetics support for SNARK proof verification. Compared with EIP-2537, it is not limited to the BLS12-381 curve, but also other curves.

EIP-1962 is certainly a complicated one, but there is something that EIP-1962 can do, but EIP-2537 alone is insufficient. Here, let me cite three examples from the work from our teams.

  • verification of ed25519 signatures in SNARK: when we do such verification on BLS12-381 or BN254, we have to resort to nonnative field arithmetics, which is very costly. If we use some application-specific curves, such as Yafa-108/146 in the following note, then the cost of scalar multiplication on ed25519 drops significantly.

  • verification of secp256k1 signatures in SNARK: as it is observed before, secq256k1 (“q”) can verify secp256k1 efficiently, and secp256k1 (“p”) can verify secq256k1 efficiently, which forms a cycle for proof systems based on inner-product arguments to work

  • computation over SNARK-friendly twisted Edwards curves of BN254 and BLS12-381, such as Jubjub, Baby Jubjub, and others, which may be useful for interoperability with other systems, here, between SNARK-based L2 and L1 as well as zkBridges

    • Same link above
    • See page 17 for some discussion about these SNARK-friendly primitives

In other words, the necessity about EIP-1962 (instead of EIP-2537) is now materially different from the use cases cited in EIP-1962.

Since this EIP was previously tentatively approved, and we know EIP-2537, which is for BLS12-381 is “likely going to be merged” since it already stays in the codebase, and EIP-1962 shares a lot of code with EIP-2537, maybe, it is a good idea to expand EIP-2537 to the scope of EIP-1962.

Even if this is unlikely going to be included in the Shanghai candidate due to its complexity, I feel it useful to bring this one up “every” one or two years to revisit.

Related: EIP-2537 seems to move forward a lot: