feat(l1): track which prover first proved each checkpoint - #25389
Merged
Conversation
Adds a `firstProvenBy` mapping to the rollup store, written whenever an epoch proof advances the proven tip. Only the checkpoint the proof ended at gets an entry, so entries are sparse; `getFirstProvenBy` walks forward from the requested checkpoint to the next entry, which is bounded by the epoch duration since a proof covers at most one epoch. A second proof of an already proven range cannot advance the tip, so it never overwrites the original prover.
spalladino
force-pushed
the
spl/first-proven-by
branch
from
September 4, 2026 18:56
110d44e to
3465731
Compare
spalladino
marked this pull request as ready for review
September 4, 2026 18:58
solhint's ordering rule rejects a using-for declaration after a constant, so the constant belongs with the other library constants.
RewardLib's imports and Rollup's external pure getters were already failing solhint on the base branch.
The protocol fee margin test built a bare FeePredictor and awaited getPredictedMinFees(), which is synchronous. That tripped @typescript-eslint/await-thenable and failed yarn-project's `lint --check`, and the unrefreshed predictor would have thrown at runtime anyway. Use makeRefreshedPredictor() like the sibling getManaMinFeeAt test does, so the margin set just above is picked up.
Collaborator
Flakey Tests🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry. |
spalladino
added a commit
that referenced
this pull request
Sep 10, 2026
There was no on-chain record of who proved a given checkpoint. `L2ProofVerified` carries the prover, but there is nothing queryable, and the reward accounting only tracks per-epoch submissions. Adds a `firstProvenBy` mapping to `RollupStore`, written in `submitEpochRootProof` whenever a proof advances the proven tip. Only the checkpoint the proof ended at gets an entry, so entries are sparse: proofs of 1-10 and then 11-20 record entries at 10 and 20, with nothing in between. Because a proof of an already proven range cannot advance the tip, it never reaches the write and the original prover is preserved. `getFirstProvenBy(checkpointNumber)` resolves an arbitrary checkpoint by walking forward to the next entry. The first entry at or after the requested number belongs to the earliest proof that covered it, since the proven tip only ever advances; the walk is bounded by the epoch duration because a proof covers at most one epoch. The mapping stores the address in its lower 160 bits and sets bit 160 as a presence flag, so `address(0)` remains distinguishable from a sparse, unwritten entry. The getter reverts with `Rollup__CheckpointNotProven` for checkpoint 0 or a checkpoint ahead of the proven tip. The getter is routed through `RewardExtLib` (alongside the other STF getters) rather than inlined in `Rollup.sol` — the Rollup deployed bytecode is within 800 bytes of the size limit. New `IRollup.getFirstProvenBy(uint256) returns (address)` and `Errors.Rollup__CheckpointNotProven(uint256 proven, uint256 requested)`. Fixes A-1927
spalladino
added a commit
that referenced
this pull request
Sep 10, 2026
There was no on-chain record of who proved a given checkpoint. `L2ProofVerified` carries the prover, but there is nothing queryable, and the reward accounting only tracks per-epoch submissions. Adds a `firstProvenBy` mapping to `RollupStore`, written in `submitEpochRootProof` whenever a proof advances the proven tip. Only the checkpoint the proof ended at gets an entry, so entries are sparse: proofs of 1-10 and then 11-20 record entries at 10 and 20, with nothing in between. Because a proof of an already proven range cannot advance the tip, it never reaches the write and the original prover is preserved. `getFirstProvenBy(checkpointNumber)` resolves an arbitrary checkpoint by walking forward to the next entry. The first entry at or after the requested number belongs to the earliest proof that covered it, since the proven tip only ever advances; the walk is bounded by the epoch duration because a proof covers at most one epoch. The mapping stores the address in its lower 160 bits and sets bit 160 as a presence flag, so `address(0)` remains distinguishable from a sparse, unwritten entry. The getter reverts with `Rollup__CheckpointNotProven` for checkpoint 0 or a checkpoint ahead of the proven tip. The getter is routed through `RewardExtLib` (alongside the other STF getters) rather than inlined in `Rollup.sol` — the Rollup deployed bytecode is within 800 bytes of the size limit. New `IRollup.getFirstProvenBy(uint256) returns (address)` and `Errors.Rollup__CheckpointNotProven(uint256 proven, uint256 requested)`. Fixes A-1927
spalladino
added a commit
that referenced
this pull request
Sep 10, 2026
There was no on-chain record of who proved a given checkpoint. `L2ProofVerified` carries the prover, but there is nothing queryable, and the reward accounting only tracks per-epoch submissions. Adds a `firstProvenBy` mapping to `RollupStore`, written in `submitEpochRootProof` whenever a proof advances the proven tip. Only the checkpoint the proof ended at gets an entry, so entries are sparse: proofs of 1-10 and then 11-20 record entries at 10 and 20, with nothing in between. Because a proof of an already proven range cannot advance the tip, it never reaches the write and the original prover is preserved. `getFirstProvenBy(checkpointNumber)` resolves an arbitrary checkpoint by walking forward to the next entry. The first entry at or after the requested number belongs to the earliest proof that covered it, since the proven tip only ever advances; the walk is bounded by the epoch duration because a proof covers at most one epoch. The mapping stores the address in its lower 160 bits and sets bit 160 as a presence flag, so `address(0)` remains distinguishable from a sparse, unwritten entry. The getter reverts with `Rollup__CheckpointNotProven` for checkpoint 0 or a checkpoint ahead of the proven tip. The getter is routed through `RewardExtLib` (alongside the other STF getters) rather than inlined in `Rollup.sol` — the Rollup deployed bytecode is within 800 bytes of the size limit. New `IRollup.getFirstProvenBy(uint256) returns (address)` and `Errors.Rollup__CheckpointNotProven(uint256 proven, uint256 requested)`. Fixes A-1927
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
There was no on-chain record of who proved a given checkpoint.
L2ProofVerifiedcarries the prover, but there is nothing queryable, and the reward accounting only tracks per-epoch submissions.Approach
Adds a
firstProvenBymapping toRollupStore, written insubmitEpochRootProofwhenever a proof advances the proven tip. Only the checkpoint the proof ended at gets an entry, so entries are sparse: proofs of 1-10 and then 11-20 record entries at 10 and 20, with nothing in between. Because a proof of an already proven range cannot advance the tip, it never reaches the write and the original prover is preserved.getFirstProvenBy(checkpointNumber)resolves an arbitrary checkpoint by walking forward to the next entry. The first entry at or after the requested number belongs to the earliest proof that covered it, since the proven tip only ever advances; the walk is bounded by the epoch duration because a proof covers at most one epoch. The mapping stores the address in its lower 160 bits and sets bit 160 as a presence flag, soaddress(0)remains distinguishable from a sparse, unwritten entry.The getter reverts with
Rollup__CheckpointNotProvenfor checkpoint 0 or a checkpoint ahead of the proven tip.The getter is routed through
RewardExtLib(alongside the other STF getters) rather than inlined inRollup.sol— the Rollup deployed bytecode is within 800 bytes of the size limit.API changes
New
IRollup.getFirstProvenBy(uint256) returns (address)andErrors.Rollup__CheckpointNotProven(uint256 proven, uint256 requested).Fixes A-1927