feat(l1): conditional sequencer checkpoint rewards (PoC) - #25175
Draft
spalladino wants to merge 3 commits into
Draft
feat(l1): conditional sequencer checkpoint rewards (PoC)#25175spalladino wants to merge 3 commits into
spalladino wants to merge 3 commits into
Conversation
Proof of concept: gate the sequencer share of the checkpoint reward on an eligibility probe of the coinbase (a contract answering true to isEligible()). Only the eligible sequencers' share is claimed from the reward distributor; the prover share is unaffected.
…ion committee The proposer of each checkpoint is derived at proof time from the committee already reconstructed during attestation verification, so no committee sampling, extra calldata, or stored state is needed. Only the sequencer share of eligible checkpoints is claimed from the reward distributor.
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
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.
Proof of concept for making the sequencer's checkpoint reward conditional on a property of the validator that proposed the checkpoint. The condition is evaluated on the withdrawer of the proposer (looked up in the GSE), matching how ATP stakers register validators: the attester key is arbitrary, but the withdrawer is the ATP's staker contract.
Approach
At proof time,
submitEpochRootProofalready reconstructs the full committee from the end checkpoint's attestations and checks it against the stored per-epoch committee commitment. Since the committee is stable for the whole epoch, each checkpoint's proposer is derived from that same in-memory committee with onecomputeProposerIndexkeccak — no committee sampling, no extra calldata, and no stored state.verifyAttestationsnow returns the committee it already built, andRewardLibuses it to compute per-checkpoint eligibility.The eligibility test itself is a placeholder: the proposer's withdrawer must be a contract answering
truetoisEligible(). The probe is a gas-capped staticcall where no code, revert, or a malformed return all read as ineligible, so a hostile withdrawer cannot block proof submission.Only what is owed is claimed from the reward distributor: the prover share for every checkpoint plus the sequencer share for eligible ones. Ineligible sequencers' shares never leave the distributor; prover rewards are unaffected. If the distributor cannot cover the full amount, both pots scale proportionally.
Gas
Measured with
test/benchmark/happy.t.sol::test_100_validators(32-slot epochs, target committee size 48, 100 validators, forge gas-report averages). Baseline:propose324,981,submitEpochRootProof1,581,276.¹ all-eligible / all-ineligible. All-ineligible epochs are cheaper than baseline because the 32 sequencer-reward SSTOREs are skipped.
The benchmark's validators share a single withdrawer; with 32 distinct withdrawers the all-eligible proof delta grows by roughly 2.6–5k per checkpoint (cold account + storage per withdrawer), i.e. ~+400k total.
Caveats