feat: not inclusive start block

[invocamanman]

Description

We use the start_block as the first block that's proved. That would mean that the block proven follows the [start_block, finalBlock] convention.

Usually in rollups is used the (start_block, finalBlock] convention, so, start block not inclusive.
This is useful usually to check that the last finalBlock matches the start_block of the next proving block.

As an example of our current and new approach given a scenario with 2 range proofs. The first proof proves the block 1 and 2 and the second one proves the block 3:

Current Approach

Proof	start_block	end_block
Proof 1	1	2
Proof 2	3	3

---

New Convention

Proof	start_block	end_block
Proof 1	0	2
Proof 2	2	3

Additions and Changes

I fix a condition and add comments regarding this change
Mainly i think this will be relevant in the upcoming PRs.

For example now instead of doing this kinda minus one scenarios we will be able to use start_block right away

It's similar to the common convention with the rollups and personally i find it more intuitive ( maybe bc i work on a rollup for a while :P)

PR Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added or updated tests that comprehensively prove my change is effective or that my feature works

[atanmarko]

@invocamanman I find this very confusing.
It makes more sense that start_block..end_block gets into the proof (inclusive).

EDIT - if this is how other count proof ranges, then ok.

[iljakuklic]

Wondering why was this convention introduced, as it's quite different from the usual [start, end) convention which may cause unintended off-by-one errors.

[Freyskeyd]

How does it integrate with the aggsender ? cc @arnaubennassar
And what's about the fer-proposer ? cc @vcastellm

[goran-ethernal]

How does it integrate with the aggsender ? cc @arnaubennassar And what's about the fer-proposer ? cc @vcastellm

In regards to the aggsender, we are using approach 1 (the old approach). One question I have about this:

• if we are going to use the new approach, does that mean we will not be sending the merkle proofs, imported bridge exits, and what not, for the start block?

[vcastellm]

LGTM

[hadjiszs]

if we are going to use the new approach, does that mean we will not be sending the merkle proofs, imported bridge exits, and what not, for the start block?

yeah I believe no witness for the start block because they would have already been provided as part of the end block of the previous request

[arnaubennassar]

IMO it makes more sense to be inclusive, it's more intuitive... If I request a proof from block 10 to 20, I expect a proof from block 10 to 20, not from 11 to 20 😅

[Freyskeyd]

For this subject, after discussing with different members, it appears that we've not an agreement on this.

Question: @vcastellm, I remember when discussing this with you that the fep-proposer is expecting an exclusive range of block number, right?
Meaning that the fep-proposer is expecting to act like:

Received	Returned
0 ... 10	1 ... 10

---

To do some pros and cons, for both solution:

Inclusive

As @arnaubennassar said, when reading the API, it is expected that the caller receive a proof from start...end.

Pros

• Clear from the caller perspective that the received proof is starting at start
• Common practice in general

Cons

• The aggkit-prover needs -1 the start in order to fetch the previous LER etc
• The fields received by the aggkit-prover will not match the one sent to the fep-proposer

Exclusion

Pros

• Same parameters from aggkit-prover to fep-proposer, easier to debug
• Common practice in rollups

Cons

• The aggkit-prover needs +1 the start after fetching the previous LER etc
• Less clear for the caller as it'll receive a proof starting from start + 1

---

I think both options have good and valid points, something that can be a third option is to refactor how we think the API.
Instead of defining: "Give me a proof starting at this block up to this block if possible"
Why not define this as: "Here's the last block that has been proven, give me a proof up to this block if possible"

The change is how we define the start:

Current

// The request message for generating aggchain proof.
message GenerateAggchainProofRequest {
  // The start block for which the aggchain proof is requested.
  uint64 start_block = 1;
  // The max end block for which the aggchain proof is requested.
  uint64 max_end_block = 2;
  ...
}

Updated

// The request message for generating aggchain proof.
message GenerateAggchainProofRequest {
  // The latest proven block
  uint64 lastest_proven_block = 1;
  // The max end block for which the aggchain proof is requested.
  uint64 max_end_block = 2;
  ...
}

What do you think?

cc @invocamanman @arnaubennassar @vcastellm @agglayer/agglayer-developers