project proposal by AbolareRoheemah · Pull Request #280 · eth-protocol-fellows/cohort-seven

AbolareRoheemah · 2026-08-02T22:27:41Z

LH decentralized CL checkpoint sync project proposal

taxmeifyoucan

Thank you for the proposal, it seems well researched! My main comment is to be clear about how you plan to divide the work when collaborating between fellows

taxmeifyoucan · 2026-08-03T11:27:23Z

+- Fixed-size chunks (e.g., 256KB) rather than logical field boundaries. The beacon state is dozens of MB — not GBs — so it can be transferred, but not in a single chunk that would monopolize bandwidth.
+- Each chunk carries a Merkle multi-proof against the state root, allowing independent verification.
+- Parallel fetching from multiple peers, with immediate rejection and re-request of any chunk that fails verification.
+- The chunking strategy should align with SSZ's natural tree layout to avoid extra hashing.


this part sounds like it needs more research and specs. SSZ merkle tree is over typed fields, not over byte ranges. Chunks can span multiple SSZ fields, it can be pretty convoluted. It's ok if you don't have a precise idea how to do it but it should be flagged as possible challenge/open question

Hmm. Thanks for flagging this. I had previously discussed this with Etan and I think the method that seems feasible is making each chunk correspond to a field in the BeaconState and then have it come with its merkle proof (as seen in the screenshot below). So, I'll revise Phase 3 to start with field-aligned chunking and probably update the proposal to flag byte-range chunking explicitly as a challenge or open question. 🤔

Yeah, it's worded fine. The chunking should be based on the tree, not based on the byte range, e.g., "first 1000 validators", "next 1000 validators" etc., so that it fits within convenient sizes.

taxmeifyoucan · 2026-08-03T11:28:22Z

+| Phase 1a | Week 7 – 8 | Implement post-sync backfill task; remove historical data gaps in `LightClientUpdate` and `SyncCommitteeBranch` storage |
+| Phase 1b | Week 8 – 10 | Implement on-demand fallback for `get_light_client_bootstrap` and `get_light_client_updates`; pass consensus-specs data collection tests |
+| Phase 2 | Week 10 – 12 | Design and prototype `LightClientBeaconSnapshot` endpoint (state root + Merkle proof) |
+| Phase 3 | Week 12 – 14 | Design beacon sync chunking protocol (fixed-size chunks with Merkle multi-proofs); prototype p2p endpoint |


I guess you have some extra space after but this sounds like much bigger effort than those 2 weeks

I guess I was being overly optimistic on this. 😅

Checking out the timeline again, I'm really not sure whats the best way to allocate time but I guess I'll discuss with the team and revert

taxmeifyoucan · 2026-08-03T11:29:43Z

+
+### Fellows
+
+- [Roheemah](https://github.com/AbolareRoheemah)


With this many fellows, there needs to be some clear strategy and division of labor. Please elaborate in roadmap how do you divide roles and responsibilities, how do you coordinate the work..

Yes, we've had talks on who works on what before Yee joined, so now we had another discussion, and I'll be updating the proposal based on that. 🙏

etan-status · 2026-08-05T11:49:02Z

+}
+```
+
+This is an optimization. When Lighthouse is syncing old blocks, it skips notifying the light client server to avoid extra computation. The assumption was: "nobody needs light client data for old blocks." That assumption now stands as a barrier to what this project aims to achieve.


Hmm, could also fetch from others once we have backfill!

You're saying once we have a mechanism for nodes to backfill LC updates, a peer can request this data from other peers in the network (I'm guessing through the light client update by range function) right?

It would need a new endpoint (to be defined), but if it's available one could backfill using that one :-)

But, it's still useful to have the capability to collect historical data locally, at least from the initial checkpoint to present

Thanks for clarifying @etan-status 🫡

etan-status · 2026-08-05T11:59:40Z

+) -> Result<Option<(LightClientBootstrap<T::EthSpec>, ForkName)>, BeaconChainError> {...}
+```
+
+Even if you synced old blocks, Lighthouse doesn't retroactively compute and store the `sync_committee_branch`. It only stores this for the blocks you processed while already synced.


sync_committee_branch is rooted in BeaconState, not in the old block, that's why it is not possible to re-create it when the old states are gone. e.g., any node that checkpoint syncs only has states from that point onward.

Oh I think I get you. So this has nothing to do with blocks.

I guess this is the reason for the LightClientBeaconSnapshot and fetching the state for the state_root it provides. Since with that state we can recreate the sync_committee_branch. 🤔

Well, historical states are not generally stored

etan-status · 2026-08-05T12:23:11Z

+
+**Data Collection Test Handler (Aarish)**
+
+The `light_client_data_collection` test handler has been implemented in `testing/ef_tests/src/cases/light_client_data_collection.rs`. The handler follows Lighthouse's `LoadCase` + `Case` trait pattern:


Generally, I'm not sure how useful specific file references are in a project proposal.
Yes, LLM generated text frequently does that, but such references tend to go stale quite quickly.

It's great that you already have a draft PR going 👍

Thanks for flagging this. I felt it was nice to mention the specific file since Aarish had already created it and started working on it.
So you think just adding the link to the PR is fine?

Generally, I'm not sure how useful specific file references are in a project proposal. Yes, LLM generated text frequently does that, but such references tend to go stale quite quickly.

It's great that you already have a draft PR going 👍

Really appreciate the feedback. I will remove the file path and just keep the PR link. Makes sense how that would go stale.

If the file is under your own control, obviously it's alright to refer to it, as you control when it goes stale.

remove the file path from project proposal.

project proposal

f74d5b0

taxmeifyoucan reviewed Aug 3, 2026

View reviewed changes

changed chunking strategy, assigned fellows to tasks

9f0c656

etan-status reviewed Aug 5, 2026

View reviewed changes

aarishnaiyer and others added 2 commits August 5, 2026 08:39

remove the file path from project proposal.

9e03505

Merge pull request #1 from aarishnaiyer/patch-9

0d838c0

remove the file path from project proposal.

taxmeifyoucan merged commit c0ea950 into eth-protocol-fellows:main Aug 7, 2026
1 check passed


		Data Collection Test Handler (Aarish)

		The `light_client_data_collection` test handler has been implemented in `testing/ef_tests/src/cases/light_client_data_collection.rs`. The handler follows Lighthouse's `LoadCase` + `Case` trait pattern:

Uh oh!

Conversation

AbolareRoheemah commented Aug 2, 2026

Uh oh!

taxmeifyoucan left a comment

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!

AbolareRoheemah Aug 3, 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!

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!

Choose a reason for hiding this comment

Uh oh!

etan-status Aug 5, 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!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

AbolareRoheemah Aug 3, 2026 •

edited

Loading

etan-status Aug 5, 2026 •

edited

Loading