Skip to content

feat: schedule Hoodi Glamsterdam activation - #31

Merged
barnabasbusa merged 2 commits into
mainfrom
bbusa/hoodi-glamsterdam
Oct 9, 2026
Merged

barnabasbusa merged 2 commits into
mainfrom
bbusa/hoodi-glamsterdam

Conversation

@barnabasbusa

@barnabasbusa barnabasbusa commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

Proposes activating Glamsterdam (Gloas + Amsterdam) on Hoodi at epoch 132352 (slot 4235264), timestamp 1793036568 (Mon, 26 Oct 2026 17:42:48 UTC), and raising the gas limit to 200M at the same epoch via GAS_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 version 0x80000910 (matching Lighthouse's built-in Hoodi config) and epoch, the Gloas consensus-spec defaults, a GAS_LIMIT_SCHEDULE entry setting GAS_LIMIT: 200000000 at epoch 132352, amsterdamTime in the Geth and Besu configs, the 13 Amsterdam EIP transition timestamps (0x6adf9118) in the Nethermind chainspec, and the README entry. Timestamp verified as 1742213400 + 132352 * 384.

@jtraglia jtraglia left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming we proceed with this date/time, LGTM 👍

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.
@barnabasbusa
barnabasbusa merged commit ef89989 into main Oct 9, 2026
1 check passed
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>
@jtraglia
jtraglia deleted the bbusa/hoodi-glamsterdam branch October 12, 2026 12:44
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.)
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.
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.
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.