proposing we don't support individual gas limits post gloas#86
Closed
james-prysm wants to merge 1 commit into
Closed
proposing we don't support individual gas limits post gloas#86james-prysm wants to merge 1 commit into
james-prysm wants to merge 1 commit into
Conversation
Merged
4 tasks
Collaborator
Author
|
seems like people are mostly against this |
pull Bot
pushed a commit
to All-Blockchains/prysm
that referenced
this pull request
Jun 15, 2026
…ide (OffchainLabs#16762) **What type of PR is this?** Bug fix **What does this PR do? Why is it needed?** - **New schema version**: `ProposerSettingsPayload.version = 2`. Existing v1/unset files keep working — the loader preserves them as-is, but a deprecation warning is logged at startup when gloas is scheduled on the network. The validator runtime upgrades v1 → v2 in place (`Settings.UpgradeToV2`) once gloas is **active** (`currentEpoch >= GloasForkEpoch`), via `upgradeProposerSettingsToV2` called from `PushProposerSettings` / `submitProposerPreferences`: `builder.gas_limit` is promoted to the top-level `gas_limit` (default config **and** per-validator entries, unless a top-level value is already set), all builder blocks are dropped, and the upgraded settings are persisted to the DB. The upgrade is deliberately deferred until the fork — not earlier — because the pre-gloas relay-registration path still reads the builder block. Settings already on v2 are never rewritten. - **`gas_limit` is a new top-level field on `ProposerOptionPayload` (v2)**: the target gas limit signed into gloas proposer preferences, honored per-validator and in `default_config`. Resolution: per-validator `gas_limit` → `default_config.gas_limit` → chain default (zero values fall through). - **Two independent gas limit signals**: relay registrations (mev-boost, pre-gloas) always read `builder.gas_limit`; proposer preferences always read the top-level `gas_limit`. A v2 file migrated before gloas can keep its `builder` block (`enabled`, `relays`, `gas_limit`) for registrations while declaring the preferences target at the top level — the two never mix. - **Keymanager gas-limit API is version-aware**: on v1 settings it keeps managing the builder gas limit (registration signal); on v2 it manages the top-level gas limit (preferences signal). ~~ethereum/keymanager-APIs#86 updated here~~ people did not favor this Beacon-node changes are not in this PR. ### Example files v1 (legacy — unchanged, still supported): ```json { "proposer_config": { "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": { "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3", "builder": { "enabled": true, "gas_limit": "45000000", "relays": ["https://example-relay.com"] } } }, "default_config": { "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A", "builder": { "enabled": true, "gas_limit": "40000000" } } } ``` v2 (new format — the `builder` block is optional and keeps its registration meaning until gloas): ```json { "version": 2, "proposer_config": { "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": { "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3", "gas_limit": "45000000", "builder": { "enabled": true, "gas_limit": "45000000", "relays": ["https://example-relay.com"] } } }, "default_config": { "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A", "gas_limit": "40000000" } } ``` ### Behavior matrix "Registrations" = signed validator registrations to builder relays (pre-gloas only). "Preferences" = signed gloas proposer preferences (submission begins one epoch before the fork for next-epoch duties). | Schema | Builder block | Before gloas | At/after gloas | |---|---|---|---| | v1 | with builder (enabled) | Registrations sent with `builder.gas_limit`. Preferences (from gloas−1) use the chain default — the builder gas limit isn't consulted for preferences until the migration promotes it. Startup deprecation warning (when gloas is scheduled). | Auto-migrated to v2 on the first settings push: `builder.gas_limit` promoted to top-level `gas_limit` (unless already set), builder blocks dropped, persisted to DB. Registrations stop; preferences carry the promoted gas limit. | | v1 | without builder | No registrations. Preferences use the chain default. | Auto-migrated to v2 (version bump only). Preferences use the chain default; fee recipients unchanged. | | v2 | with builder (enabled) | Registrations sent with `builder.gas_limit`, exactly as on v1. Preferences use the top-level `gas_limit`. | Registrations stop at the fork; builder block becomes inert. Preferences use the top-level `gas_limit`. | | v2 | without builder | No registrations — explicit opt-out. Preferences (from gloas−1) use the top-level `gas_limit`. | Steady state: preferences only. | **test kurtosis** check that proposer preferences are updated correctly, snooper is enabled. ``` extra_files: proposer-config-v2.json: | { "version": 2, "default_config": { "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A", "gas_limit": "40000000" } } participants_matrix: el: - el_type: ethrex el_image: ethpandaops/ethrex:glamsterdam-devnet-4 cl: - cl_type: prysm cl_image: gcr.io/offchainlabs/prysm/beacon-chain:latest vc_image: gcr.io/offchainlabs/prysm/validator:latest cl_extra_params: - --verbosity=debug vc_extra_mounts: /proposer: proposer-config-v2.json vc_extra_params: - --enable-beacon-rest-api - --verbosity=debug # Point prysm vc at the mounted v2 proposer settings file. - --proposer-settings-file=/proposer/proposer-config-v2.json count: 2 network_params: fulu_fork_epoch: 0 gloas_fork_epoch: 2 seconds_per_slot: 6 genesis_delay: 40 additional_services: - dora - spamoor # spamoor generates load so payloads are non-empty: eoatx for normal EL txs, blobs to exercise the # blob/KZG path through the stateless envelope Contents flow. spamoor_params: spammers: - scenario: eoatx config: throughput: 10 - scenario: blobs config: throughput: 2 keymanager_enabled: true global_log_level: debug ``` ``` curl -s -H "Authorization: Bearer $TOKEN" $URL/eth/v1/keystores | jq -r '.data[].validating_pubkey' PK=<pubkey> curl -s -H "Authorization: Bearer $TOKEN" $URL/eth/v1/validator/$PK/gas_limit curl -s -X DELETE -H "Authorization: Bearer $TOKEN" $URL/eth/v1/validator/$PK/gas_limit ``` **Note** beacon node updates are not part of this pr. **Which issues(s) does this PR fix?** Fixes # **Other notes for review** **Acknowledgements** - [x] I have read [CONTRIBUTING.md](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md). - [x] I have included a uniquely named [changelog fragment file](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md#maintaining-changelogmd). - [x] I have added a description with sufficient context for reviewers to understand this PR. - [x] I have tested that my changes work as expected and I added a testing plan to the PR description (if applicable). --------- Co-authored-by: Jun Song <87601811+syjn99@users.noreply.github.com>
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
1 participant
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.
adding the ability to configure gas limits on a per validator basis on a validator client seems flawed telling the validator client to drastically shift between values potentially, I'm porposing post gloas we should just make the endpoint update the global default...