Repository navigation
feat: schedule Hoodi Glamsterdam activation - #31
Merged
Merged
Conversation
jtraglia
approved these changes
Oct 8, 2026
jtraglia
left a comment
There was a problem hiding this comment.
Assuming we proceed with this date/time, LGTM 👍
barnabasbusa
marked this pull request as ready for review
October 8, 2026 14:07
This was referenced Oct 8, 2026
wemeetagain
approved these changes
Oct 8, 2026
nflaig
approved these changes
Oct 8, 2026
rolfyone
approved these changes
Oct 8, 2026
nflaig
pushed a commit
to ChainSafe/lodestar
that referenced
this pull request
Oct 8, 2026
**Motivation** Schedule the Glamsterdam fork (Gloas on the CL) on Hoodi so operators can upgrade ahead of activation and Lodestar ships the fork timing in a release. **Description** Sets `GLOAS_FORK_EPOCH` to `132352` in the Hoodi network config, activating Glamsterdam at: - Epoch: `132352` - Slot: `4235264` - Timestamp: `1793036568` (Mon, 26 Oct 2026, 17:42:48 UTC) `1742213400 + 4235264 * 12 = 1793036568`, epoch-aligned with Hoodi genesis. `GLOAS_FORK_VERSION` (`0x80000910`) already matches upstream. Also adds a `GAS_LIMIT_SCHEDULE` entry raising the gas limit to 200M at the fork, same as Sepolia (#10172): ```yaml GAS_LIMIT_SCHEDULE: - EPOCH: 132352 GAS_LIMIT: 200000000 ``` Mirrors [eth-clients/hoodi#31](eth-clients/hoodi#31). The remaining Gloas params in that PR match the mainnet defaults Hoodi already inherits. The Lighthouse, Teku, and Nimbus Hoodi interop fixtures used by the `assertEqualParams` test are updated to the scheduled Gloas epoch and version, same as #8435 did for Fulu on Holesky.
2 tasks done
daniellehrner
approved these changes
Oct 8, 2026
jangko
approved these changes
Oct 9, 2026
yperbasis
approved these changes
Oct 9, 2026
tersec
approved these changes
Oct 9, 2026
pk910
approved these changes
Oct 9, 2026
ilitteri
approved these changes
Oct 9, 2026
nalepae
approved these changes
Oct 9, 2026
michaelsproul
approved these changes
Oct 9, 2026
flcl42
approved these changes
Oct 9, 2026
5 of 14 tasks
prestonvanloon
approved these changes
Oct 9, 2026
1 task
rjl493456442
approved these changes
Oct 10, 2026
mergify Bot
pushed a commit
to sigp/lighthouse
that referenced
this pull request
Oct 12, 2026
## Proposed Changes Schedule Gloas/Glamsterdam on Hoodi per: - eth-clients/hoodi#31
methakon
pushed a commit
to methakon/prysm
that referenced
this pull request
Oct 12, 2026
Sets the Hoodi Gloas fork epoch to 132352 (2026-10-26 17:42:48 UTC) and adds the matching 200M gas limit schedule entry, per eth-clients/hoodi#31. Co-authored-by: james-prysm <90280386+james-prysm@users.noreply.github.com>
daniellehrner
added a commit
to besu-eth/besu
that referenced
this pull request
Oct 12, 2026
* Schedule Amsterdam on Hoodi Sets amsterdamTime to 1793036568 (Mon 26 Oct 2026 17:42:48 UTC, Gloas epoch 132352) to match eth-clients/hoodi#31, and updates the expected Hoodi fork ids accordingly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: daniellehrner <daniel@lehrner.me> * Add PR number to CHANGELOG entry Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: daniellehrner <daniel@lehrner.me> --------- Signed-off-by: daniellehrner <daniel@lehrner.me> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
AskAlexSharov
pushed a commit
to gophersg/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.
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.
codeForEatingEverything
pushed a commit
to codeForEatingEverything/ethrex
that referenced
this pull request
Oct 15, 2026
**Motivation** Glamsterdam (Gloas on the consensus layer, Amsterdam on the execution layer) is proposed for Hoodi at epoch **132352**, timestamp **1793036568**, **2026-10-26 17:42:48 UTC**, after the Sepolia fork. The date is proposed in [ethereum/pm#2263](ethereum/pm#2263), which was on the [ACDE lambdaclass#247](ethereum/pm#2234) agenda on 2026-10-08. The client configuration is [eth-clients/hoodi#31](eth-clients/hoodi#31), merged 2026-10-09; `metadata/genesis.json` on its main branch now carries `amsterdamTime: 1793036568`. pm#2263 is still open at the time of writing, and EIP-7773 has no Hoodi activation time yet. pm#2263's table gives `1793134872` as the Unix time for epoch 132352, but that is the start of epoch 132608 (its second option). eth-clients/hoodi#31 has the correct value: `1742213400 + 132352 * 384 = 1793036568`. **Description** - `amsterdamTime: 1793036568` added to the Hoodi preset, after the Osaka and BPO times, exactly as eth-clients/hoodi#31 does in `metadata/genesis.json`. - No blob-schedule change. Upstream leaves it unchanged, Amsterdam inherits the BPO2 parameters, and the preset carries no Amsterdam blob entry, the same shape as Sepolia. - The EIP-2124 fork ID changes with the new scheduled fork: the Hoodi fork-ID test rows after BPO2 now advertise `next = 1793036568`, and a head at or past Amsterdam gets fork hash `0x3d068b59`. That is CRC32 continued from BPO2's `0x23aa1351` over the big-endian timestamp; the same method reproduces `0x23aa1351` from BPO1's hash. The usual just-before/at pair was added for the new fork. - A test pins the activation timestamp on the parsed preset so it cannot drift silently. The Hoodi genesis-hash test is unaffected, since the chain config is not part of the genesis header. - The `eth_config` RPC test reads the Hoodi preset, so its `last` entry is now Amsterdam: the new activation time and fork ID, the BPO2 blob schedule carried over, and the EIP-8282 `BUILDER_DEPOSIT_CONTRACT_ADDRESS` / `BUILDER_EXIT_CONTRACT_ADDRESS` predeploys. These names, addresses and the precompile set match what a public Sepolia RPC serves now that Sepolia is past its Amsterdam fork. - The forks roadmap now lists the Hoodi schedule; only mainnet is still TBD upstream. - The 200M `GAS_LIMIT_SCHEDULE` entry in eth-clients/hoodi#31 is consensus-layer configuration. The CL passes the gas limit through `targetGasLimit` in the payload attributes, so there is nothing to add on the execution side, same as Sepolia. **How to Test** ```sh cargo test -p ethrex-config cargo test -p ethrex-common --lib fork_id cargo test -p ethrex-rpc --lib eth_config ``` Ten preset tests pass, including `test_hoodi_amsterdam_activation` and the unchanged `test_hoodi_genesis_block_hash`. `fork_id` passes 8/8 and `ethrex-rpc` 188/188. Removing `amsterdamTime` from the preset fails `test_hoodi_amsterdam_activation` and `hoodi_test_cases`. **Checklist** - [ ] Updated `STORE_SCHEMA_VERSION` (crates/storage/lib.rs) if the PR includes breaking changes to the `Store` requiring a re-sync. (Not needed: no schema change.)
This was referenced Oct 19, 2026
samcm
added a commit
to ethpandaops/xatu
that referenced
this pull request
Oct 19, 2026
go-ethereum v1.17.6 (and current releases/master) ship a Hoodi chain config without amsterdamTime, so the bootstrap Status advertised 0x23aa1351/0 and the fork filter would reject upgraded peers once Hoodi forks at 1793036568 (eth-clients/hoodi#31). Use a copy of params.HoodiChainConfig with AmsterdamTime set when the bundled config lacks it, so this becomes a no-op once go-ethereum ships the timestamp. Hoodi now advertises 0x23aa1351/1793036568 before the fork and 0x3d068b59/0 after it; mainnet and Sepolia are unchanged.
samcm
added a commit
to ethpandaops/xatu
that referenced
this pull request
Oct 19, 2026
go-ethereum v1.17.6 (and current releases/master) ship a Hoodi chain config without amsterdamTime, so the bootstrap Status advertised 0x23aa1351/0 and the fork filter would reject upgraded peers once Hoodi forks at 1793036568 (eth-clients/hoodi#31). Use a copy of params.HoodiChainConfig with AmsterdamTime set when the bundled config lacks it, so this becomes a no-op once go-ethereum ships the timestamp. Hoodi now advertises 0x23aa1351/1793036568 before the fork and 0x3d068b59/0 after it; mainnet and Sepolia are unchanged.
This was referenced Oct 19, 2026
MegaRedHand
added a commit
to lambdaclass/ethlambda
that referenced
this pull request
Oct 20, 2026
eth-clients/hoodi scheduled Gloas at epoch 132352 (2026-10-26 17:42:48 UTC) in eth-clients/hoodi#31. The built-in Hoodi config is that repo's file byte for byte, so this copies it again at ef89989. A build that claims the GLOAS_* keys needs this to follow Hoodi across the fork: without it, the node keeps the fulu fork digest past epoch 132352 and falls off the chain there. A build that does not claim them only reports the new keys as ignored, the same as it already does for Sepolia.
1 task
zexoverz
pushed a commit
to zexoverz/ethlambda
that referenced
this pull request
Oct 22, 2026
…led ahead of the directory (lambdaclass#677) ## Motivation Hoodi schedules Glamsterdam: Gloas activates at epoch **132352**, fork version `0x80000910`, at **2026-10-26 17:42:48 UTC** ([eth-clients/hoodi#31](eth-clients/hoodi#31)). Our built-in Hoodi config is eth-clients' file byte for byte, and our copy predates that PR. Picking up the new schedule exposed a second problem. A beacon resume compared the fork schedule for equality, so every existing Hoodi directory would have been refused (`ConfigChanged`) the first time it started with the new config. Scheduling a fork always edits exactly those fields, after every node has already initialized its directory. ## Description ### 1. Hoodi config (`10eec50f`) `bin/ethlambda/assets/hoodi/config.yaml` is copied again from `eth-clients/hoodi` at `ef89989`: | Section | Keys | |---|---| | Forking | `GLOAS_FORK_VERSION: 0x80000910`, `GLOAS_FORK_EPOCH: 132352` | | Time | `MIN_BUILDER_WITHDRAWABILITY_DELAY`, `*_DUE_BPS_GLOAS`, `PAYLOAD_DUE_BPS`, `PAYLOAD_ATTESTATION_DUE_BPS` | | Validator cycle | `CHURN_LIMIT_QUOTIENT_GLOAS`, `CONSOLIDATION_CHURN_LIMIT_QUOTIENT`, `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT_GLOAS` | | Networking | `MAX_REQUEST_PAYLOADS` | | New section | `GAS_LIMIT_SCHEDULE` (200M gas at the fork epoch) | Every value except `GAS_LIMIT_SCHEDULE` matches the Gloas block Sepolia's config already carries, and the mainnet defaults a gloas build uses for an absent key. `bootstrap_nodes.yaml` already matches upstream. On this branch the only visible effect is a longer ignored-keys warning. On a build that claims `GLOAS_*` (lambdaclass#634 and up), this is what lets a Hoodi follower cross the fork. ### 2. Resume across a fork scheduled ahead of the directory (`d182ae2b`) `first_config_difference` takes `processed_through`: the latest epoch the directory holds a block or state of. That is the highest `LiveChain` slot, or the finalized state's slot when it is later (a checkpoint-sync anchor advanced through empty slots). | Change to a fork's version/epoch | Before | Now | |---|---|---| | Unset → scheduled ahead of the chain | refused | **accepted** | | Moved, old and new epoch both ahead | refused | **accepted** | | Moved onto or off a processed epoch | refused | refused | | `genesis_fork_version` changed | refused | refused (phase0 is always processed) | `BLOB_SCHEDULE` follows the same rule: entries up to `processed_through` must match. Every other compared field is still compared for equality. Accepting the change is not enough on its own, because the node runs on the **persisted** config. A resume that passes now writes the config file over `Metadata["config"]` with the new `Store::replace_config`, which panics unless its `Store` holds the only handle to the cached config, so a clone cannot go on serving the old one. As a result, the file's values (`CONFIG_NAME` included) are what the node runs on and reports after a resume. Before, the stored values silently won for every uncompared field. ## Merging into the gloas stack The yaml merges cleanly. `main.rs` conflicts in `first_config_difference`'s `compare!` list, where the gloas branches add `gloas_fork_version`/`gloas_fork_epoch`. Resolve it by taking this side and dropping those two lines: the per-fork loop walks `ForkName::ALL`, which includes Gloas there. Keeping them in `compare!` would bring back the refusal. ## How to test ```bash cargo test -p ethlambda --bins --profile release-fast cargo test -p ethlambda-storage --lib --profile release-fast -- config cmp bin/ethlambda/assets/hoodi/config.yaml <(curl -s https://raw.githubusercontent.com/eth-clients/hoodi/ef89989/metadata/config.yaml) ``` New tests: `a_resume_follows_a_fork_scheduled_ahead_of_the_directory` (anchor with fulu unset, resume with it scheduled, check the new schedule is served and persisted), `a_fork_schedule_may_change_only_ahead_of_what_was_processed`, `a_blob_schedule_entry_may_be_added_only_ahead_of_what_was_processed`, and two `replace_config` tests in storage. `a_resume_with_an_edited_config_names_the_field_that_changed` used to move electra, which a genesis-anchored directory has not reached and which is now accepted. It now moves altair onto epoch 0.
MegaRedHand
added a commit
to suna4/ethrex
that referenced
this pull request
Oct 27, 2026
**Motivation** [eth-clients/hoodi#33](eth-clients/hoodi#33), merged 2026-10-22, unschedules the Hoodi Glamsterdam fork planned for **2026-10-26 17:42:48 UTC** (epoch 132352, `amsterdamTime` 1793036568). It removes `amsterdamTime` from `metadata/genesis.json`, restoring the files to their state before eth-clients/hoodi#31. If ethrex keeps the timestamp, it advertises an EIP-2124 fork ID with `next = 1793036568` that other clients no longer announce, and on the 26th it activates Amsterdam alone and forks itself off Hoodi. **Description** Reverts lambdaclass#7391: | File | Change | |---|---| | `cmd/ethrex/networks/hoodi/genesis.json` | drop `amsterdamTime` | | `crates/common/config/networks.rs` | drop `test_hoodi_amsterdam_activation` | | `crates/common/types/fork_id.rs` | Hoodi rows after BPO2 go back to `0x23aa1351`, `next = 0` | | `crates/networking/rpc/rpc.rs` | `eth_config` test: `last` is BPO2 again (no builder predeploys) | | `docs/roadmaps/forks-roadmap.md` | note that Hoodi was unscheduled; mainnet still TBD | The automatic revert merged `rpc.rs` by also moving an unrelated `handle_get_heap` stub. I reapplied only the test hunk, so the diff touches nothing outside the test. **How to Test** ```sh cargo test -p ethrex-config cargo test -p ethrex-common --lib fork_id cargo test -p ethrex-rpc --lib eth_config ``` All pass locally: 9 config tests (including `test_hoodi_genesis_block_hash`), 8 `fork_id` tests, and the `eth_config` test. **Checklist** - [ ] Updated `STORE_SCHEMA_VERSION` (crates/storage/lib.rs) if the PR includes breaking changes to the `Store` requiring a re-sync. (Not needed: no schema change.) Co-authored-by: Ivan Litteri <67517699+ilitteri@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
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.
Proposes activating Glamsterdam (Gloas + Amsterdam) on Hoodi at epoch
132352(slot4235264), timestamp1793036568(Mon, 26 Oct 2026 17:42:48 UTC), and raising the gas limit to 200M at the same epoch viaGAS_LIMIT_SCHEDULE. The change mirrors Sepolia's Glamsterdam scheduling (eth-clients/sepolia#126) and its 200M gas limit schedule (eth-clients/sepolia#130): it adds the Gloas fork version0x80000910(matching Lighthouse's built-in Hoodi config) and epoch, the Gloas consensus-spec defaults, aGAS_LIMIT_SCHEDULEentry settingGAS_LIMIT: 200000000at epoch132352,amsterdamTimein the Geth and Besu configs, the 13 Amsterdam EIP transition timestamps (0x6adf9118) in the Nethermind chainspec, and the README entry. Timestamp verified as1742213400 + 132352 * 384.