Add cached PTCs to the state by potuz · Pull Request #4992 · ethereum/consensus-specs

potuz · 2026-03-09T15:32:50Z

Alternative to #4979 that only keeps track of 2 committees (8KB per state)

potuz · 2026-03-09T15:33:29Z

specs/gloas/beacon-chain.md

    # [New in Gloas:EIP7732]
    payload_expected_withdrawals: List[Withdrawal, MAX_WITHDRAWALS_PER_PAYLOAD]
+    # [New in Gloas:EIP7732]
+    ptc_lookbehind: Vector[Vector[ValidatorIndex, PTC_SIZE], 2]


Could be previous_ptc, current_ptc which is ugly as well, but more like previous forks structures.

I've just made this change. I prefer this.

potuz · 2026-03-09T15:34:36Z

specs/gloas/beacon-chain.md

+            process_epoch(state)
+        state.slot = Slot(state.slot + 1)
+        # [New in Gloas:EIP7732]
+        state.ptc_lookbehind = [state.ptc_lookbehind[1], compute_ptc(state)]


Could be moved to process_slot but it's uglier.

specs/gloas/beacon-chain.md

ensi321 · 2026-03-09T22:47:45Z

Personally prefer this over #4979 . It's a balance between state size and spec simplicity.

specs/gloas/fork.md

potuz · 2026-03-10T01:06:59Z

specs/gloas/fork.md

    # [New in Gloas:EIP7732]
    onboard_builders_from_pending_deposits(post)
+    # [New in Gloas:EIP7732]
+    ptc_lookbehind[1] = compute_ptc(post)


Added outside because compute_ptc should only make sense on Gloas states.

potuz · 2026-03-10T01:07:43Z

specs/gloas/validator.md

-given slot. To check for PTC assignments, use
-`get_ptc_assignment(state, epoch, validator_index)` where `epoch <= next_epoch`,
-as PTC committee selection is only stable within the context of the current and
-next epoch.


This sentence was factually wrong which is what started this issue. Removed the helper entirely since there is no need to specify it.

potuz · 2026-03-10T12:05:25Z

Personally prefer this over #4979 . It's a balance between state size and spec simplicity.

I wouldn't be so certain, the PR that adds the full lookahead has a single point where this computation is carried and no synchronization with process slots that happens at time on wall clock. The total data added per state is 0.08% (that's 0.0008) of a current beacon state in mainnet.

jihoonsong · 2026-03-13T14:35:25Z

specs/gloas/validator.md

-next epoch.
-
-```python
-def get_ptc_assignment(


Leaving a note that get_ptc_assignment is still being used in three sections below.

jihoonsong · 2026-03-13T14:35:50Z

specs/gloas/validator.md

+current slot by checking if their validator index is in `get_ptc(state)`. PTC
+committee selection is only stable within the context of the current epoch.

 ### Lookahead


This doesn't seem to hold anymore.

Right above it says:

PTC committee selection is only stable within the context of the current epoch.

which means there is no 1 epoch lookahead.

The committee selection is stable within the context of the current epoch, it doesn't mean that the epoch needs to be cached in the state. It means that any validator that wants to check if it has PTC duties in the current epoch, can do so at the beginning of the epoch. Clients will most likely implement this and cache it no matter which lookahead/lookbehind system we implement in-state.

Lookahead section states that PTC is stable for next epoch.

which section? I'm replying only to your comment that is based on the sentence:

current slot by checking if their validator index is in `get_ptc(state)`. PTC committee selection is only stable within the context of the current epoch.

Lookahead section states that PTC is stable for next epoch.

Lookahead section. I left this comment on Lookahead section.

Ah, yeah what Github shows is confusing.

L77-L78:

get_ptc_assignment should be called at the start of each epoch to get the
assignment for the next epoch (current_epoch + 1). A validator should plan for

oh yeah that's definitely wrong.

ensi321 · 2026-03-16T07:40:50Z

specs/gloas/beacon-chain.md

-    return compute_balance_weighted_selection(
-        state, indices, seed, size=PTC_SIZE, shuffle_indices=False
-    )
+    assert slot == state.slot or slot + 1 == state.slot


I think this change makes get_ptc to be too restrictive on the range of slot it accepts. Validator's PTC assignment should still be determined ahead on a per-epoch basis instead of per-slot basis.

I think we should accept slot [previous slot, end slot of state's current epoch]. Maybe something like

def get_ptc(state: BeaconState, slot: Slot) -> Vector[ValidatorIndex, PTC_SIZE]: epoch = get_current_epoch(state) epoch_start_slot = compute_start_slot_at_epoch(epoch) epoch_end_slot = epoch_state_slot + SLOTS_PER_EPOCH assert slot >= state.slot - 1 and slot < epoch_end_slot if slot == state.slot: return state.current_ptc if slot + 1 == state.slot: return state.previous_ptc return compute_ptc(state, slot)

So get_ptc_assignment can still take advantage of this.

clients are free to simply pass the slot to conpute_ptc for caching purposes. Why should we have these off-protocol elements leaking in the spec?

OTOH one think that should be considered IMO is that if clients will anyway cache them, then most likely having the full cache in the spec is more efficient than keeping it in an ad-hoc in-memory cache that needs to be in-sync with the head state.

sauliusgrigaitis · 2026-03-17T11:40:53Z

Grandine has a similar cache implemented already, so we would need to remove our cache implementation and switch to this. But my question is why do we need such a cache in the state (and specification)? Clients have a lot of other caches that are part of the client (not specification). So why is this time different?

potuz · 2026-03-17T14:16:13Z

Grandine has a similar cache implemented already, so we would need to remove our cache implementation and switch to this. But my question is why do we need such a cache in the state (and specification)? Clients have a lot of other caches that are part of the client (not specification). So why is this time different?

Because the state is flawed currently: PTC attestations are cast in slot 31, validation of gossip uses get_ptc for that state at that slot. Then those attestations are included in the block at slot 32, and validation of the block uses get_ptc for the state at slot 32 which can return a different ptc than the previous slot's

nflaig · 2026-03-17T23:20:40Z

Grandine has a similar cache implemented already, so we would need to remove our cache implementation and switch to this. But my question is why do we need such a cache in the state (and specification)? Clients have a lot of other caches that are part of the client (not specification). So why is this time different?

you can handle that with separate caches in the client but one problem is that if you load a state you can't compute the previous PTC as you'd need the effective balances of the previous epoch, having the previous_ptc as part of the state makes this a lot simpler

Alternative to ethereum#4992 that addresses ethereum#4979's epoch-boundary PTC bug with minimal state changes: - Add single `previous_ptc` field to BeaconState (~4KB vs 8KB/ethereum#4992, 256KB/ethereum#4979) - New `compute_ptc(state, slot)` extracted from `get_ptc` for on-demand computation - New `process_ptc_update` at START of `process_epoch` (before balance updates) - Modified `get_ptc` returns cached `previous_ptc` for epoch boundary case - No per-slot rotation in `process_slots` (unlike ethereum#4992) - Preserves `get_ptc_assignment` validator duties API (unlike ethereum#4992) - Tightened `get_ptc_assignment` assert to `current_epoch <= epoch <= next_epoch` Key insight: only the PTC for the last slot of the previous epoch needs caching because `process_payload_attestation` enforces `data.slot + 1 == state.slot` and effective balances only change at epoch boundaries. Co-authored-by: Nico Flaig <nflaig@users.noreply.github.com>

jihoonsong · 2026-03-23T14:23:30Z

Closing in lieu of #4979.

Add PTC Lookbehind

a99e003

potuz commented Mar 9, 2026

View reviewed changes

github-actions bot added the gloas label Mar 9, 2026

kevaundray reviewed Mar 9, 2026

View reviewed changes

specs/gloas/beacon-chain.md Outdated Show resolved Hide resolved

kevaundray reviewed Mar 9, 2026

View reviewed changes

specs/gloas/beacon-chain.md Show resolved Hide resolved

Deal with the fork and remove get duties helper

215962a

potuz commented Mar 10, 2026

View reviewed changes

nflaig mentioned this pull request Mar 11, 2026

Remove next epoch lookahead from PTC duties ethereum/beacon-APIs#586

Merged

jtraglia added 2 commits March 11, 2026 10:02

Run make lint & improve ptc_lookbehind initialization

f00224c

Fix heze state & add some basic tests

141a77a

github-actions bot added testing CI, actions, tests, testing infra heze labels Mar 11, 2026

jtraglia added 4 commits March 11, 2026 10:51

Fix test_process_payload_attestation_too_old_slot test

3622fc2

Check that PTCs are different in tests

69c1db1

Split PTC lookbehind into two fields

b60f6f9

Add extra fork comment to be extra explicit

d76a278

jtraglia changed the title ~~Add PTC Lookbehind~~ Add cached PTCs to the state Mar 12, 2026

jtraglia approved these changes Mar 12, 2026

View reviewed changes

jtraglia mentioned this pull request Mar 13, 2026

Add cached PTC window to the state #4979

Merged

twoeths mentioned this pull request Mar 13, 2026

[gloas] computePayloadTimelinessCommitteesForEpoch performance issue ChainSafe/lodestar#9013

Open

jihoonsong reviewed Mar 13, 2026

View reviewed changes

ensi321 reviewed Mar 16, 2026

View reviewed changes

nflaig mentioned this pull request Mar 16, 2026

feat: add cached PTCs to the state ChainSafe/lodestar#9047

Closed

danceratopz mentioned this pull request Mar 17, 2026

All Core Devs - Testing (ACDT) #75, March 23, 2026 ethereum/pm#1976

Closed

4 tasks

ralexstokes mentioned this pull request Mar 17, 2026

All Core Devs - Consensus (ACDC) #176, Mar 19, 2026 ethereum/pm#1941

Closed

4 tasks

lodekeeper mentioned this pull request Mar 18, 2026

feat: minimal PTC caching with single previous_ptc field lodekeeper/lodestar#13

Closed

nflaig mentioned this pull request Mar 19, 2026

Add PTC lookbehind minimal state change #5020

Closed

jihoonsong closed this Mar 23, 2026

Conversation

potuz commented Mar 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ensi321 commented Mar 9, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

potuz commented Mar 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ensi321 Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sauliusgrigaitis commented Mar 17, 2026

Uh oh!

potuz commented Mar 17, 2026

Uh oh!

nflaig commented Mar 17, 2026

Uh oh!

jihoonsong commented Mar 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

ensi321 Mar 16, 2026 •

edited

Loading