2026-11-04 –, Workshop 2
Teku did not have server side light client support, which meant light clients could not sync from it. Over EPF Cohort 7 I implemented that support end to end, i.e, the Altair spec layer, update generation, and persistence. The talk covers how a consensus client produces light client updates and serve them.
Light client discussions usually focus on the client side. This talk covers the server side, i.e, what a consensus client computes, when, and where the results are stored.
Updates come from three independent triggers. A head advancing produces an optimistic update, checkpoint finalization produces a finality update, and a sync committee period boundary produces the full update a client bootstraps from.
I will walk through the storage design, i.e, why a dedicated database column was preferred over flat SSZ files on disk, the atomicity gained by writing the update in the same transaction as the block, and the measured cost.
I'm Abhivansh, an EPF Cohort 7 fellow. I've contributed across the client ecosystem - Teku, Besu, Lighthouse, Nethermind, Ream. I am currently building out server-side light client support in Teku as part of my EPF project.