On-chain BLS curve cryptography support

[cygnusv]

Research support for running BLS curve cryptography methods on-chain, either on the Ethereum EVM (check state of EIP-2537), or other EVM-compatible rollups. The rationale for this is to verify validity of PVSS instances (i.e., DKG rituals metadata) on-chain.

[piotr-roslaniec]

ZK-rollup implementations:

• NethermindEth/optimized_ecc_cairo
• 0xNonCents/cairo-bls12-381 - Deprecated

Workarounds

• Accessing EIP-2537 precompiles on a forked node
• Verifying BLS signatures inside a zkSNARK and then verifying that proof on-chain

Optimizations

• Optimized BLS multisignatures on EVM - Irrelevant, BN128 curve

[cygnusv]

Still waiting for the state of EIP-2537. It's being discussed for inclusion in the next Shanghai hardfork (see https://github.com/ethereum/pm/issues/343, https://github.com/ethereum/pm/issues/652), but there's still a lot of uncertainty.

Verifying BLS signatures inside a zkSNARK and then verifying that proof on-chain

This is super cool, but it's important to note that all that hard work is to compute a single pairing, while we would need to compute 2 pairings to verify each transcript, so 2*N pairings for a full DKG ritual. Perhaps it could be very useful for an optimistic verification protocol, i.e., all DKG transcripts are assumed correct unless someone posts a fault proof. In such case, the fault proof will be only for an incorrect transcripts, so the zkSNARKs approach could be applicable.

Optimized BLS multisignatures on EVM

Unfortunately, this is for BLS signatures on BN128 curve (which have precompiles on Ethereum), but not for BLS12-381 curve.

[piotr-roslaniec]

Perhaps it could be very useful for an optimistic verification protocol

This could present a very interesting design trade-off if we decide to use L1/L2 for verification. On a different note, there is a trend out there where more expressive zk proofs are being used to implement complex algorithms, and then simpler zk constructions are used to "compress" the former. Imagine rolling a STARK into a Groth16 for example. This is firmly in the R&D space thought.

Still waiting for the state of EIP-2537

According to the latest Ethereum Core Devs meeting, we need another few weeks for a final decision to be reached

@cygnusv Any thoughts on this one? NethermindEth/optimized_ecc_cairo

[piotr-roslaniec]

We decided to wait for the activation of the EIP-2537, and hence this issue is blocked.

[cygnusv]

According to hearsay, EIP 2537 may be activated in the Pectra soft fork in late 2024.

See https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-181/

[piotr-roslaniec]

Confirmed to be a part of Pectra: https://eips.ethereum.org/EIPS/eip-7600