Repository navigation
chainspec, clparams: schedule Glamsterdam on Hoodi - #24847
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The execution and consensus schedules align, and the affected configuration outputs are covered by tests.
0 open findings
What changed in this PR
Schedules Hoodi’s Glamsterdam activation across execution and consensus configuration.
Changes:
- Sets Amsterdam activation to timestamp
1793036568. - Configures Gloas epoch/version and the 200M gas-limit target.
- Updates fork-ID and Beacon API expectations.
| File | Description |
|---|---|
execution/chain/spec/chainspecs/hoodi.json |
Adds the Amsterdam timestamp. |
cl/clparams/config.go |
Adds Hoodi Gloas and gas-limit configuration. |
p2p/forkid/forkid_test.go |
Covers fork IDs around activation. |
cl/beacon/handler/config_test.go |
Verifies Beacon API schedule output. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
yperbasis
marked this pull request as ready for review
October 13, 2026 14:19
yperbasis
requested review from
anacrolix,
domiwei,
mh0lt,
sudeepdino008 and
taratorio
as code owners
October 13, 2026 14:19
yperbasis
enabled auto-merge
October 13, 2026 14:19
lystopad
approved these changes
Oct 13, 2026
Bruce039
pushed a commit
to Bruce039/erigon
that referenced
this pull request
Oct 14, 2026
Schedule Glamsterdam on Hoodi for **26 October 2026, 17:42:48 UTC**, following [eth-clients/hoodi#31](eth-clients/hoodi#31). - Set Amsterdam to timestamp `1793036568`. - Set Caplin's Gloas epoch to `132352` and fork version to `0x80000910`. - Schedule the gas-limit target at `200,000,000` from epoch `132352`. - Update the existing fork-ID cases before, at, and after activation and the Beacon API gas-limit schedule test. This is a configuration-only change. The updated fork-ID and Beacon API tests failed before the configuration changes and passed afterward.
rayjun
pushed a commit
to rayjun/erigon
that referenced
this pull request
Oct 23, 2026
Reverts erigontech#24847 following [eth-clients/hoodi#33](eth-clients/hoodi#33), which unscheduled Hoodi's Glamsterdam activation planned for 26 October 2026 at 17:42:48 UTC (epoch `132352`). Removes Hoodi's Amsterdam timestamp, Gloas activation settings, and 200,000,000 gas-limit schedule, and restores the previous test expectations. Co-authored-by: Alex Sharov <AskAlexSharov@gmail.com>
keithchew
pushed a commit
to keithchew/erigon
that referenced
this pull request
Oct 29, 2026
…eferences in the epoch before the fork (erigontech#24869) Cherry-pick of erigontech#24809 to release/3.7. Clean pick, no release/3.7-specific adaptations. Worth having on 3.7.x: release/3.7 has the same three gaps in the handling of `proposer_preferences` in the epoch before the Gloas fork. It ignores every preference from a peer before decoding it, because the topic is registered with a Gloas version condition that the gossip validator checks against the current epoch; it joins the Gloas digest's topics only 8 slots before the fork; and it publishes preferences submitted through the beacon API on the current (Fulu) digest, to which Prysm and Lighthouse do not subscribe for this topic. So at a Gloas activation a 3.7.x node misses the peers' preferences for the first Gloas epoch that are gossiped in the epoch before it, and, unless it gets a matching preference another way, ignores the execution payload bids for those proposers' slots, so it neither keeps nor relays them; and the preferences that its validator client submits in that epoch do not reach Prysm and Lighthouse nodes. Sepolia, the only built-in network of release/3.7 with a Gloas fork epoch, passed it at epoch 353024, so this matters for the next activations, such as Hoodi (main schedules it at epoch 132352 in erigontech#24847, which is not on release/3.7 yet), and for devnets. For a running node, the early join of the next digest's `proposer_preferences` topic, one epoch before the change instead of 8 slots, also applies to later fork digest changes, for example a BPO fork after Gloas, where Prysm publishes a preference on the digest of its proposal epoch. As before, a node whose startup straddles a digest change (service registration still sees the old digest, the fork-check loop already the new one) does not join the new digest's topics, including `proposer_preferences`; this change does not address that, and its tests do not cover that startup order. The change also fixes `subscribeUpcomingTopics`, which stopped at a target topic that already existed and could leave the topics after it unsubscribed. And `POST /eth/v1/beacon/pool/proposer_preferences` and `POST /eth/v1/validator/proposer_preferences` now report a failed publish (a failure entry for that index and 400, or 500 when the fork digest cannot be computed) instead of answering 200 and, with the proposer preferences service configured (as in normal operation), publish an identical retry of a stored preference again. The fallback without the service still acknowledges an identical retry without publishing it. Testing: - With the release/3.7 versions of `register.go`, `gossip_manager.go`, `gossip_subscription.go` and `epbs.go`, plus a compile-only shim (an empty `subscribeUpcomingProposerPreferences` method on `GossipManager`), these fail: both cases of `TestRegisterGossipServicesProcessesGloasPreferencesOneEpochEarly` (the Fulu case with `validation ignored`, the Gloas case with `topic not found`, because the topic is not joined at registration), `TestGossipManagerSubscribesProposerPreferencesOneEpochEarly`, `TestRegisterGossipServiceSubscribesProposerPreferencesForNextEpochImmediately`, `TestSubscribeUpcomingTopicsSubscribesExistingTargetAndContinues` (`topic already exists`), `TestTopicSubscriptionsGetReturnsSnapshot`, the three cases of `TestPostProposerPreferencesPublishResultsAndDigest`, the `service=true` cases of `TestPostProposerPreferencesAcknowledgesOnlyIdenticalRetries`, and both cases of `TestPostProposerPreferencesWithoutServiceConcurrentRequests` and `TestPostValidatorProposerPreferencesGloasForkBoundary` (unexpected `Publish`, missing `PublishToForkDigest`). The `service=false` cases of `TestPostProposerPreferencesAcknowledgesOnlyIdenticalRetries` pass with both versions. All pass with this backport. - `go test -p 2 -count=1 ./cl/phase1/network/registry/ ./cl/phase1/network/gossip/... ./cl/beacon/handler/` - `go test -p 2 -count=1 -race ./cl/phase1/network/registry/ ./cl/phase1/network/gossip/...` - `make lint` - `make erigon integration`
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.
Schedule Glamsterdam on Hoodi for 26 October 2026, 17:42:48 UTC, following eth-clients/hoodi#31.
1793036568.132352and fork version to0x80000910.200,000,000from epoch132352.This is a configuration-only change. The updated fork-ID and Beacon API tests failed before the configuration changes and passed afterward.