AggLayer: Store `hash(GER)` instead of the full GER

[mmagician]

A couple of comments on these:

• Do we actually need to store the full GER? it seems like, the claim note inputs can be used to compute the GER and then, we just need to check if the GER computed from the note matches the GER in the bride. For this, we just need to store GER commitment (i.e., RPO hash). This would mean we need only one storage slot.
• Maybe we should make the storage slot into a map: hash(ger) |-> 1/0. This way, given a GER, we can compute its hash to reduce it to a single word, and then do a lookup to check if the GER is known or not.
• It feels a bit odd that GER update functionality is in the bridge_in module. It probably would make sense to have a separate bridge_operator module for things like this.

Originally posted by @bobbinth in #2333 (comment)

[mmagician]

This might not be ideal, because the ClaimManager needs to know when it is ready to submit the CLAIM note. To do this, it needs to know if a GER on which a claim depends has already been included onchain on Miden.

One workaround is for the ClaimManager to hash the GER in the same way as we would on Miden, and then query the bridge contract storage to see if it's already included in the GER tree.

cc @mandrigin have I described the requirement of the ClaimManager correctly? And if so, would that be feasible to adapt it to the described flow where we store hash(GER) instead?

---

Separately, we still have to store a hash chain of the GERs as a double word.

[bobbinth]

This might not be ideal, because the ClaimManager needs to know when it is ready to submit the CLAIM note. To do this, it needs to know if a GER on which a claim depends has already been included onchain on Miden.

One workaround is for the ClaimManager to hash the GER in the same way as we would on Miden, and then query the bridge contract storage to see if it's already included in the GER tree.

I'm imagining that there is some method that looks something like - is_ger_available(GER), and then in this method we'd read the bridge storage to check if the provided GER is in fact in the storage. If it is in fact so, hopefully, adding an extra call to hash the GER in this function would be too problematic.

Separately, we still have to store a hash chain of the GERs as a double word.

For this we just need to allocate two storage slots, right? If so, I think that's not a problem.

[mmagician]

closed in #2388