Store G2 onchain

[RonTuretzky]

Rationale:

• Maintaining arbitrary block range log indexing offchain is very expensive (rpc calls), error prone, and introduces a lot of bug vectors
• The added gas cost in comparison to the rest of the transaction is negligible
• This would enable retrieving all information needed for the checkSignatures entrypoint from a view function, instead of needing to maintain offchain indexing services coupled to signature verification for an arbitrary submitter of signatures

cc @stevennevins @supernovahs

[gpsanant]

I agree, this should be kept in storage to avoid needing in indexer.

Main think missing in this PR is a way for an admin to overwrite the G2 key map for existing registries that are already live.

[RonTuretzky]

I agree, this should be kept in storage to avoid needing in indexer.

Main think missing in this PR is a way for an admin to overwrite the G2 key map for existing registries already live.

Another way you can do it is that the operator address could update this

The problem is you need to also verify the g1 matches the g2
I would take this off scope, as this naturally resolves itself by having a fresh middleware deploy or mass ejecting operators and asking them to re-register.

We can also just "trust" the operators to update the correct g2...

[RonTuretzky]

@samlaf this would simplify eigenda services that index the g2 keys

[gpsanant]

Another way you can do it is that the operator address could update this

The problem is you need to also verify the g1 matches the g2 I would take this off scope, as this naturally resolves itself by having a fresh middleware deploy or mass ejecting operators and asking them to re-register.

We can also just "trust" the operators to update the correct g2...

Mass ejection not an option for EigenDA and trusting the operator requires AVSs to still run an indexe in case operators mess around.

Viable options imo are:

• admin sets it
• permissionless to set it, but proof of equivalence with g1 key is checked: e(pubkey_g1, 1) = e(1, claimed_pubkey_g2)

admin seems easier especially since this is only needed on an upgrade which already requires administrative involvement

[RonTuretzky]

will add the admin option, @rubydusa how easy would it be to implement the check? and how gas intensive?
is there a snippet that's already in an existent audited codebase for this?

[rubydusa]

@rubydusa how easy would it be to implement the check?

Should be fairly straight forward, as @gpsanant wrote it's literally e(pubkey_g1, 1) = e(1, claimed_pubkey_g2)

and how gas intensive?

above the 100k units because of two pairing operations

[RonTuretzky]

If we enable admins to do it, but also operators to update it in case of admin error that's good, especially if it's straightforward to implement

[stevennevins]

I can add this to your PR @RonTuretzky

it should be this input to the precompile

input = [1, 2, pubkeyG2[1], pubkeyG2[0], pubkeyG2[3], pubkeyG2[2], pubkeyG1[0], pubkeyG1[1], N_G2_X1, N_G2_X0, N_G2_Y1, N_G2_Y0];

[stevennevins]

lgtm

@RonTuretzky would you mind forge fmting

i had more autoformat on save off when i Pr'd to your branch

[RonTuretzky]

@stevennevins should be good now!