Description
When a GenerateAggchainProof request is built for a block range [last_proven_block, requested_end_block], both claims (imported_bridge_exits) and unclaims (unclaims) are collected for all events that fall within that range.
The problem arises when the block range is reduced:
A bridge exit was claimed at block X, where X ≤ end_block' → the claim remains in imported_bridge_exits.
That same claim was later unclaimed at block Y, where end_block' < Y ≤ original_end_block → the unclaim is now outside the new range and gets dropped from unclaims.
The result is an inconsistent certificate: it contains an imported_bridge_exit (claim) with no corresponding unclaim, even though on-chain the claim was reversed. The proof circuit requires that claim/unclaim pairs are coherent within the block range — a claim whose unclaim falls outside the range cannot be safely included, because the verifier would see a net claimed bridge exit that was actually cancelled.
In short: reducing the block range can silently split a claim/unclaim pair across the range boundary, leaving an orphaned claim in the certificate whose cancellation is invisible to the proof. This makes the proof either unprovable or incorrect with respect to the actual on-chain state.
Proposed solution: early rejection with a suggested cutoff hint
Instead of proceeding with an expensive proof generation for a block range known to be invalid, aggkit-prover will detect the inconsistency upfront — specifically, that reducing the range to end_block would drop an unclaim whose paired claim is still included — and immediately return an error to the caller.
The error includes the problematic cutoff block (end_block) as context, signalling to aggsender that this particular range boundary is unsafe. aggsender can then search for a new cutoff point strictly below end_block — one that either includes both the claim and its unclaim, or excludes both — and resubmit the GenerateAggchainProof request with the corrected range.
This avoids the cost of running a ZK proof (which involves SP1 network proving time and resources) only to produce an invalid or unprovable certificate. The validation is cheap and happens at the service boundary before any proving work begins.
In short: fail fast at the RPC layer with an actionable hint, rather than failing deep inside the prover after significant compute has already been spent.
Description
When a
GenerateAggchainProofrequest is built for a block range [last_proven_block,requested_end_block], both claims (imported_bridge_exits) and unclaims (unclaims) are collected for all events that fall within that range.The problem arises when the block range is reduced:
A bridge exit was claimed at block X, where X ≤ end_block' → the claim remains in imported_bridge_exits.
That same claim was later unclaimed at block Y, where end_block' < Y ≤ original_end_block → the unclaim is now outside the new range and gets dropped from unclaims.
The result is an inconsistent certificate: it contains an imported_bridge_exit (claim) with no corresponding unclaim, even though on-chain the claim was reversed. The proof circuit requires that claim/unclaim pairs are coherent within the block range — a claim whose unclaim falls outside the range cannot be safely included, because the verifier would see a net claimed bridge exit that was actually cancelled.
In short: reducing the block range can silently split a claim/unclaim pair across the range boundary, leaving an orphaned claim in the certificate whose cancellation is invisible to the proof. This makes the proof either unprovable or incorrect with respect to the actual on-chain state.
Proposed solution: early rejection with a suggested cutoff hint
Instead of proceeding with an expensive proof generation for a block range known to be invalid,
aggkit-proverwill detect the inconsistency upfront — specifically, that reducing the range toend_blockwould drop an unclaim whose paired claim is still included — and immediately return an error to the caller.The error includes the problematic cutoff block (
end_block) as context, signalling to aggsender that this particular range boundary is unsafe.aggsendercan then search for a new cutoff point strictly belowend_block— one that either includes both the claim and its unclaim, or excludes both — and resubmit the GenerateAggchainProof request with the corrected range.This avoids the cost of running a ZK proof (which involves SP1 network proving time and resources) only to produce an invalid or unprovable certificate. The validation is cheap and happens at the service boundary before any proving work begins.
In short: fail fast at the RPC layer with an actionable hint, rather than failing deep inside the prover after significant compute has already been spent.