Description

Adds a limit for the number of proofs to fetch. When the fetcher reaches that limit or when the proofs for the batch surprass that limit the fetching stops and the last aggregated block us updated to the block number of that log so that the next aggregation starts at that block.

Considerations:

Currently, we are limited by the blob size:

• Each blob has a capacity of (4096 * 32) = 131.072 bytes
• But, since we need to pad it with a 0x0 byte to not surpass the field modulus we are left with (4096 * 31) = 126.976
• Each proof commitments takes 32 bytes hash

So we can aggregate as much proofs as 126.976 / 32 = 3968 per blob.

We could increase the capacity by:

• Running the aggregator more frequently
• Adding the logic to send a vector of blobs instead of only one

Type of change

Please delete options that are not relevant.

• New feature

Checklist

• “Hotfix” to testnet, everything else to staging
• Linked to Github Issue
• This change depends on code or research by an external entity
  • Acknowledgements were updated to give credit
• Unit tests added
• This change requires new documentation.
  • Documentation has been added/updated.
• This change is an Optimization
  • Benchmarks added/run
• Has a known issue
  • Link to the open issue addressing it
• If your PR changes the Operator compatibility (Ex: Upgrade prover versions)
  • This PR adds compatibility for operator for both versions and do not change batcher/docs/examples
  • This PR updates batcher and docs/examples to the newer version. This requires the operator are already updated to be compatible