[Tracking] EIP-2537: BLS12-381 precompiles

[meyer9]

spec

• EIP-2537: Precompile for BLS12-381 curve operations specs#509

rust

op-revm

• EIP-2537: BLS precompile gas repricing bluealloy/revm#1942
• feat(optimism): implement BLS precompiles for isthmus bluealloy/revm#2000
• feat(optimism): Isthmus Precompiles bluealloy/revm#2038

kona

• feat(client): Accelerate BLS12-381 precompile op-rs/kona#946
• feat: ensure BLS precompiles are all accelerated op-rs/kona#1000

Go

• fix: isthmus e2e test utils and withdrawal root fix optimism#13933
• feat: accelerate BLS precompiles optimism#14154

op-program

• op-program: implement accelerated BLS precompiles for Isthmus optimism#13975

op-geth

• feat: add Isthmus fork rules op-geth#471
• feat: add Isthmus BLS precompiles op-geth#472
• feat: add BLS precompile size limits for Isthmus op-geth#490

[meyer9]

Planning on working on fault proofs accelerated precompile tests soon, and testing Reth precompiles as well later this week.

[emhane]

seems no changes are needed for op-reth and op-alloy to make this work, right? neither for op-program or kona right? removing the headings from the issue to reflect that @meyer9

[emhane]

this doesn't require any engagement from solidity devs, but it does require deployment of same contract as on l1, right @janjakubnanista ?

[janjakubnanista]

@emhane not sure here

[emhane]

would you tag someone who would know pls @janjakubnanista ?

[janjakubnanista]

@zhwrd / @mslipper possibly

[meyer9]

I think we need to add the BLS operations as accelerated precompiles to op-program: https://github.com/ethereum-optimism/optimism/blob/7bb33f991d90ecde978fa2937cbee0b0f3804a64/op-program/client/l2/engineapi/precompiles.go#L58-L71

op-program could also execute these independently of L1 technically, but these operations are generally pretty expensive and would benefit greatly by calling out to L1. This will prevent us from affecting challenger performance much by making these changes. secp256k1 was one precompile that needed to be implemented in op-program instead of accelerated because it doesn't exist on L1 and it caused a big performance hit in op-program.

Created this issue: ethereum-optimism/optimism#13975

[emhane]

does this mean that some change is also needed in kona @meyer9 ? cc @clabby

[clabby]

Yes @emhane, we'll need to add it as a new "accelerated precompile."

These are registered in the client program here, and the BLS precompile will also need to be added into the host here.

We'll also need to be cognizant of the ability to reproduce the precompile call on L1 via the PreimageOracle contract's loadPrecompilePreimagePart function. The BLS12-381 precompile accepts variable-length inputs, so it'll have variable gas, and we'll need to cap this within both the client software and the proof. We did the same thing for the ecPairing precompile in the Granite hardfork, since it's also accelerated in the proof + has dynamic gas consumption based on the input.

[meyer9]

Need to accelerate Kona precompiles: op-rs/kona#1000

[meyer9]

Added link to PR for geth change also: ethereum-optimism/optimism#14154

[emhane]

closing, implementation done. moving acceptance test pr to root tracking issue in order to document the incremental progress that implementation and unit testing is done.