[Gloas] Light Client API support timeline for ePBS (EIP-7732)?

[yoshidan]

Question

We are planning to use the Light Client API (/eth/v1/beacon/light_client/finality_update) on Gloas/ePBS devnets and testnets.

Currently, the API returns stale pre-Gloas data after the fork transition and does not update.

We would like to know:

1. Is there a plan to support Light Client API for Gloas/ePBS?
2. If so, what is the expected timeline? (e.g., before Sepolia fork, before mainnet, etc.)

We are aware that there is no Light Client spec under https://github.com/ethereum/consensus-specs/tree/master/specs/gloas yet.

Context

We observed the following in epbs-devnet-1:

• persistPostBlockImportData has an early return for Gloas blocks with TODO comment:

  // TODO GLOAS: Light-client updates for Gloas are pending spec work.
  if (ForkSeq[fork] >= ForkSeq.gloas) {
    return;
  }

• After Gloas epoch, finality_update returns the last pre-Gloas values indefinitely
• Gloas removes latestExecutionPayloadHeader from BeaconState, which affects LightClientHeader structure

[matthewkeil]

We just started to talk about this yesterday. There is currently no spec yet as you mentioned. We will see what we can do to push that spec forward but cannot give a timeline as there is still a lot of Gloas stuff left to do.

cc @nflaig @ensi321

[ensi321]

We probably won't have a gloas light client spec for at least 1-2 months.

We had this conversation a while ago: https://discord.com/channels/595666850260713488/874767108809031740/1442323269041520733
So we will need to get epbs to stabilized first (probably devnet 2 or 3), then we have a decision on the remaining CFI'ed EIPs for gloas in ACDC, then we will see a gloas light client spec.

[yoshidan]

@matthewkeil

Hi, just following up on this.

I noticed that the Gloas light client spec has now been merged into consensus-specs:
https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/light-client/sync-protocol.md

Key changes in the spec:

• LightClientHeader now contains execution_block_hash (Hash32) and execution_branch instead of the full execution payload
• New generalized index (832) for Gloas merkle branch verification

Is there any update on the implementation timeline for Lodestar?

[nflaig]

@yoshidan sorry for the delay, we have just merged #9687 (thanks to @spiral-ladder for working on this), you can use our chainsafe/lodestar:next image (or run from unstable branch), if you wanna test this on plataberget (devnet-8) then you can simply run a node via --network plataberget flag

[yoshidan]

Thanks @nflaig — confirmed working. I ran chainsafe/lodestar:next against plataberget and the Gloas light client data checks out: the execution_branch verifies against beacon.body_root at EXECUTION_BLOCK_HASH_GINDEX_GLOAS (2856) and execution_block_hash matches the block's signed_execution_payload_bid.message.parent_block_hash.

I did hit one problem while testing, though. GET /eth/v1/beacon/light_client/bootstrap/{root} only works for the current finalized checkpoint — a root that answers 200 turns into 500 syncCommitteeWitness not available about one epoch later, once the archiver passes it, and it never comes back:

epoch=4718 slot=150976 -> 500
epoch=4719 slot=151008 -> 500
epoch=4720 slot=151040 -> 200   <- newest, not archived yet

It looks like the archiver treats the sibling payload variants of canonical blocks as non-canonical and deletes their light client data by blockRoot. I have a small fix and I'll open a PR with the details — but is this known, or expected behaviour for now?

(#9991 seems to be a different, self-healing case about the checkpoint-sync anchor.)

[nflaig]

It looks like the archiver treats the sibling payload variants of canonical blocks as non-canonical and deletes their light client data by blockRoot. I have a small fix and I'll open a PR with the details — but is this known, or expected behaviour for now?

cc @spiral-ladder

[yoshidan]

Found the cause and fixed it locally — bootstrap now answers at every archived epoch boundary.
Opened #10017 in case it's useful — no obligation to take it, happy to close it if you'd rather handle it differently.

[nflaig]

thanks @yoshidan for testing our code and fixing bugs :)

[spiral-ladder]

@yoshidan thanks for testing :)

I have a small fix and I'll open a PR with the details — but is this known, or expected behaviour for now?

No, this seems like a bug i didn't discover during testing