feat: send GER inclusion proofs to aggchain prover

[goran-ethernal]

Description

This PR adds the functionality of sending GlobalExitRoot inclusion proofs to the aggchain prover since it is needed to generate a correct auth proof.

To do this, when aggsender is in AggchainProof mode, we collect injected GERs in L2 by directly calling the L2 contract to collect InsertGlobalExitRoot events in a given block range.

Before calling the aggchain prover to generate the auth proof, aggsender will get the last finalized l1 info tree root. After that, it will get the all injected GERs from the L2 contracts for the block range for which it is building the certificate, and it will generate the inclusion proofs for each injected GER based on the last finalized l1 info tree root.

Also, it will provide the prover with imported bridge exits we are adding to the certificate, but only data in imported bridge exits like:

• bridge exit
• token info
• global index.

After that it will call the aggchain prover so that it can generate the auth proof.

Also, important note is, we now will use the last finalized l1 info tree root in the AggchainProof mode to generate all the inclusion proofs for every claim (imported bridge exit), since this is a prerequesite, since the aggchain prover uses that root to generate the proof.

This PR adds a new field called custom_chain_data to the certfificate. It is a random byte array returned by the aggchain prover, and we need to send it to the agglayer in the certificate.

Fixes # (issue)

[arnaubennassar]

If I remember well, the lastgersync only stores the GERs that are "latest" in terms of index, but not necessarily all the injections...

Please review if the logic of this sycner does what you expect.
We may need to heavily change how the syncer works, if this is the case just go ahead and simplify the syncer to "just" index the GERs injections, and we will figure out later how we deal with the birdge service, as this syncer was meant to be used by it originally

[goran-ethernal]

If I remember well, the lastgersync only stores the GERs that are "latest" in terms of index, but not necessarily all the injections...

Please review if the logic of this sycner does what you expect. We may need to heavily change how the syncer works, if this is the case just go ahead and simplify the syncer to "just" index the GERs injections, and we will figure out later how we deal with the birdge service, as this syncer was meant to be used by it originally

@arnaubennassar I think we are good here. What the lastGER syncer does is it constantly gets what is the last index it has in its db, then gets what is the last root the l1 info tree has, and gets all the indexes it missed. After that it does sanity check to see if all of the GERs it got are injected on L2.

[joanestebanr]

Some comments:

• Make sense to store on DB the L1InfoTreeRoot choosen for proves.. may be it can be extracted from certificate, I'm not sure

[goran-ethernal]

Some comments:

• Make sense to store on DB the L1InfoTreeRoot choosen for proves.. may be it can be extracted from certificate, I'm not sure

I mean we could, but we would only use it for resending the InError certificate, and its basically just a call to the l1 info tree sync db. Maybe it is not worth it, since it is already stored in another db. WDYT?

[joanestebanr]

Some comments:

• Make sense to store on DB the L1InfoTreeRoot choosen for proves.. may be it can be extracted from certificate, I'm not sure

I mean we could, but we would only use it for resending the InError certificate, and its basically just a call to the l1 info tree sync db. Maybe it is not worth it, since it is already stored in another db. WDYT?

In which DB do you mean? I think that for debug can be useful to known the choosen root.. WDYT?

[goran-ethernal]

Some comments:

• Make sense to store on DB the L1InfoTreeRoot choosen for proves.. may be it can be extracted from certificate, I'm not sure

I mean we could, but we would only use it for resending the InError certificate, and its basically just a call to the l1 info tree sync db. Maybe it is not worth it, since it is already stored in another db. WDYT?

In which DB do you mean? I think that for debug can be useful to known the choosen root.. WDYT?

I agree, I will add it.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
87.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud