Adapt the handling of the 2 FEP vkey hash

[hadjiszs]

Context

The aggchain proof requires 2 vkey hash:

1. range vkey commitment
2. aggregation vkey hash

Both referring to the FEP verified within the aggchain proof.

Before #183

• those vkey hash were hardcoded within the aggchain proof program, hence completely tied to the aggchain proof vkey/version.

After #183

• the vkeys are now in the aggchain proof public inputs, so no need to be hardcoded anymore.

Question

• How do we want to handle those vkey hashes?

Suggestions from @Freyskeyd:

I see multiple options here:

1. Either we stick to have this vkey as constant in the docker image, meaning that if they're changing, we need to rebuild the docker image even if there are no changes
2. Do a sanity check at the start of the aggkit-prover to assert that we're aligned with the L1 vkeys by calling the contract that hold them. The vkeys are still "constant" in the docker image, and it's need to be rebuilt every time one of those key changes.
3. For every aggchain-proof that we're generating, we retrieve those vkey hashs from L1 contract to use them, making the aggkit-prover not dependant of those vkey

WDYT?

Originally posted by @Freyskeyd in #183 (comment)

[hadjiszs]

I think the vkeys won't need to be hardcoded anymore even on the provers side, and could be dynamically fetched from L1 contracts, so basically I'm up for @Freyskeyd's option 3.

For debugging I think simply logging them to know which ones were considered would be good enough

[hadjiszs]

and could be dynamically fetched from L1 contracts

Ah no, I forgot about the fact that we need to have the actual vkey (and not the hash) in order to build the sp1 stdin.

Then I wonder if that could be good to have it as config value + cross check on the vkey hash from L1 values?

[Freyskeyd]

We could have those vKeys serialize in config, parsed when starting and have a sanity check of their hash using L1 value.

[hadjiszs]

Confirmed in meeting:

• Add two optional config fields for:
  • the full aggregation vkey which defaults to: proposer_elfs::aggregation::VKEY.vkey()
  • the range vkey commitment which defaults to: proposer_elfs::range::VKEY_COMMITMENT

This will enable us to _not have to rebuild a new docker image just to update those values.

Then, under this same ticket we can also:

• Retrieve the aggregation vkey hash and the range vkey commitment from the contracts to cross check with those that are considered by the aggkit prover.