feat: only verify new headers

[alexghr]

This PR changes the checkpoint header verification from always verifying from index 0 (in the epoch) up to the current proven tip to verifying from the last proven index to up the new proven tip. This reduces the gas cost for partial epoch proofs by about ~3-4k per previously verified checkpoint header.

Fix A-1802

[alexghr]

this is the whole patch.

[spalladino]

Looks good, left one question.

Also, how much could we save by not sending the headers? Calldata gas is cheap but not that cheap. If that header prefix is ignored, maybe we don't even need to send it at all?

[spalladino]

When would these two differ?

[alexghr]

This covers when proofs for epoch N land in epoch N + 1.

Assuming N = 1, epoch 1 covers checkpoints 1..32, epoch 2 covers checkpoints 33..64

We could receive proofs for epoch 1 during epoch 2's lifetime while epoch 2 is partial proven. Let's assume we've proven the first 3 checkpoints of epoch 2 when another epoch 1 proof lands:

// uint256 provenPrefixLength = provenBeforeSubmission - _args.start + 1;
uint256 provenProfixLength = 35 - 1 + 1; // proven tip is 35 (ie after the first three checkpoints in epoch 2), args.start is 1 because that's the start of epoch 1's range

// uint256 accountedPrefixLength = RewardLib.getLongestProvenLength(endEpoch);
uint256 accountedPrrefixLength = 32; // we're strictly looking at the epoch to be proven, it's fully proven otherwise we couldn't accept proofs for epoch 2 so this'll return that all 32 checkpoints have had their rewards accounted for.

// firstHeaderToVerify = provenPrefixLength < accountedPrefixLength ? provenPrefixLength : accountedPrefixLength;
firstHeaderToVerify = 35 < 32 ? 35 : 32; // ie 32

[spalladino]

But is there any scenario where accountedPrefixLength is greater than provenPrefixLength? Can't we just use RewardLib.getLongestProvenLength(endEpoch)?

[spalladino]

Astra here (the AI assistant), posting this explanation at Santiago's request; this is my analysis, not Santiago writing.

@alexghr Your example makes sense: the global proven tip can include checkpoints from the next epoch, so provenPrefixLength can exceed this epoch's accountedPrefixLength. Following up on Santiago's question, though, can the reverse ever happen? The min only changes the result relative to using accountedPrefixLength directly if accountedPrefixLength > provenPrefixLength.

For a smaller example, suppose epoch A contains checkpoints 1–4 and epoch B contains 5–8. Each row below is a successive submission; the counters are their values before that submission:

Submission	Global proven tip	Accounted length for the submitted epoch	Headers needing hash verification
Prove A: 1–2	0	0	1–2
Extend A: 1–4	2	2	3–4
Prove B: 5–6	4	0	5–6
Another prover submits A: 1–4, while still within its submission window	6	4	None

In the last row, the current calculation gives:

provenPrefixLength = 6 - 1 + 1; // 6
accountedPrefixLength = 4;
firstHeaderToVerify = min(6, 4); // 4

The 6 includes checkpoints from B, whereas the value we need is simply how many checkpoints in A were already proven and accounted for.

From the production state transitions I reviewed, the invariant appears to be:

• An epoch's longestProvenLength is extended only through successful proof submission.
• That submission also advances the global proven tip to at least the submitted end checkpoint. Both updates commit atomically; a revert during reward handling rolls back the tip update too.
• Pruning does not roll back the proven tip.

Therefore, whenever the epoch has an accounted prefix, the global proven tip must already cover that prefix. If the tip is before the epoch's start, its accounted length should be zero. I don't see a reachable state through normal completed submissions where accounting gets ahead of proving.

Could we consequently replace the tuple/conditional/min block with:

Epoch endEpoch = assertAcceptable(_args.start, _args.end);
uint256 firstHeaderToVerify = RewardLib.getLongestProvenLength(endEpoch);

That would also let assertAcceptable return just endEpoch; its internal proven-tip acceptance check would remain unchanged.

A shorter repeat proof is also worth considering: if A already has accounted length 4 and someone submits A: 1–2, starting verification at index 4 simply skips the loop, since both submitted headers were already verified. The existing header-count validation remains in place.

Is there a production path that breaks this invariant? If not, using the epoch-local accounted length directly seems equivalent and easier to follow.