# Light Client Support in Prysm | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 12:05
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-ZAU0kJJut54
- YouTube: https://www.youtube.com/watch?v=ZAU0kJJut54

## Description

Showcasing the addition of Light Client server support to the Prysm consensus client.

Speaker(s): Bastin, Rupam
Skill level: Intermediate
Track: [CLS] EPF Day
Keywords: EPF, Consensus, Light Clients

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] so hey everyone I'm Bas this is yeah hey everyone I'm rupam and we have been working on uh integrating light CL server size support in prism uh and for the project intro like light nodes are basically uh nodes which you can run which you use significantly less resources than a full node but there are some drop backs uh how a light client works is basically they maintain this chain of block headers until the latest block header yeah uh we get this trusted block route which is available in the network and using that we can fetch a range of updates after that we get the root hash which is which can basically be used to determine the uh latest block header so uh there's this reference of the like Clans after the merge by itan it was covered in Def six I guess yeah so uh you can check it out it's really nice and yeah yeah so um if we're looking at what a light client update looks like it's a simple structure it contains the blog header so the light client can uh basically save that blog header it has the current sync committee public Keys uh the sync committee is the 52 uh validators that signed each block header and and uh the light clients basically verify that blog Header by checking the sync committee signature and there's also something else called the uh Sy committee uh bits which shows which of these uh 512 uh validators actually did sign the block header and also there is this uh next sync committee which is the sync committee the 512 sync committee for the next period so you can basically check when you get the next block header that the signature uh checks out and this is actually part of the chain uh yeah so uh how the network works right now is that uh we have this uh Beacon Network which Full nodes uh talk to each other and connect to each other and we have a light node on the side which basically asks one of the full nodes for these updates over and over again to be able to uh stage synced and then we have this RPC provider that uh we might not trust so what a light no what a light client actually does is that it uh gets that RP gets the data from that RPC but uh instead of just trusting it it checks it against the state route that it gets from the full notes yeah yeah and what we did in this project was basically implementing that part which is how the light node talks to a full node and gets those updates uh yeah and there are four end points the first one uh the bootstrap using the block rout you have the trusted block route in the network and you can just call the bootstrap on that block route and uh after that next yeah you'll get you get a range of three updates let's say three here and when the uh like has synced up to the latest block header uh you can just keep calling optimistic update or finality update according to it needs yeah so uh the project faces that we had was uh we got familiar with prism and how light clients work and then uh we started implementing the specs and then going back and forth uh with testing and debugging this is nice but this is a lie this is how it actually is so everything was uh weird but uh yeah so the current state of the project is that we implemented uh the four RPC endpoints and we uh implemented that for uh like Forks after alter which is all the forks that support light clients uh we implemented uh two databases one for light client updates and one for light client bootstraps to store them and and not have to manually like comp compute them each time and yeah and also we implemented saving updates and bootstrap when receiving new blocks unfortunately not still uh Haven we haven't still implemented uh saving them while syncing and also the P2P events and topics were implemented so it's so these uh functions are not only exposed through the beacon RPC they are exposed to the P2P uh Network as well and uh these are all visible on the uh EP of FL CL branch on prism demo oh oh yeah we have a uh well kind of demo so uh these are old but this is the Nimbus uh server and this is our server uh if we reload them at the same time if we are lucky we get the same result yeah kind of the same result and uh so the difference as you can see is is that we have this buike which uh gives us three more execution branches and we have to debug and see why uh yeah but uh mainly we can see that this is just one of the uh RPC and points but uh this is for the demo uh they're mainly uh working correctly okay uh yeah as of the next steps uh we do have some work left and the first of of all would be we would we would need to test it out on a test net and of course like measure the test performance and optimize it according to that as also basan said before like uh we still don't save updates or boot stress while syncing which would be nice to have so we do plan to add that too and after that yeah adding leline stuff to e2a tests and kosis yeah that's for mainly for all testing for all the forks uh so that's for the next steps and and yeah almost all consensus layers support light CL now including Nimbus lar so yeah prism is also into the game now and special thanks to radic and Jo and Mario for the cohort uh and radic for the awesome mentoring here thank you thank you very much thank you very much guys yeah uh I really appreciate you sharing all of this uh do we have any question for Baston rupam yeah uh there uh excuse me I have to screen um do you know if there's any plans to add in points to generate proofs uh sorry add what um to add proofs so like the light line data said is very limited um there's proofs to like prove the execution branch and the finalize header but say you wanted to prove something else in the beacon State like block Roots um what would be super useful if um there was an end point to say I want to approve block Roots at this index and just return the hash I feel like that's super missing from the lifeline spec yeah um um so the there are multiple eips uh open right now that work on adding uh getting proofs from the execution clients not the consensus clients but uh yeah there are multiple uh open PRS I think at least four that uh point to different parts of uh the block where you can get uh different proofs and then uh validate them using uh all these roots that are in the block header okay so but no Beacon State proofs yet Beacon State proofs we will we have the state root hash in the block header so if you have the proofs and if you have the data you can check that against the state Roo yeah but so what I mean is like say you want to prove anything in the beacon State at the moment you need to download the whole Beacon State s a z yeah right and then you have to like create the tree and then generate the proof ashes yourself but like for instance load star has a npoint where you can say I want to proove this piece of the beacon State and then they just return the proof that would be really cool if all the clients can add it because I think um sometimes the apps using the light line data can't get to all the data that you'd actually need um for instance so um I work on a bridge project um and we need to prove if you have a finalized header that another header is a ancestor of that block and you need the block Roots proofs to do that but it's missing from the light line data yeah that is true I don't think that's in there is such a thing in prism right now but uh maybe hi I'm from Prism so yeah the recently actually we had another person asking us the same question so we are actively looking into that so even if it this is not in a uh official light client um like a future you know plans for official specification it's definitely an end point I would like to add so we can talk to ners how they do that and uh yeah I think in in the next few months we we should I hope we will have something to share with uh with everyone awesome that's great news thanks thank you so much R yeah and yeah just wanted to say thank you for for this project I had lost all hope of prism ever supporting the like client so thank you yeah awesome yeah okay quite quick question maybe my understanding can proves and stuff quite limited but can you for example bootstrap your light note from consensus client and then start to query uh the RPC uh provider for the latest data so you you would unload basically all this RPC cloes for RPC calls for from uh consensus clients uh so the yeah so you could use uh if I'm understanding your question correctly you're asking if you can uh instead of uh asking the RPC providers for data ask a consensus note for data way okay the other way around the as suit you get the latest block data like fin BL head latest block headers from the consensus node yes but can you do is from RPC clients well uh yes I think so you can do that but like the point is that uh you basically check and verify all these updates uh one by one using the sync commity signature so it doesn't really matter where you get those updates from as long as they like you have everyone in order like uh from where you start and uh if this is all dependent on if your your uh first trusted block routs is actually part of the chain so if you've been tricked to use something that's not on the chain and is like on a fake chain then you will keep up on that and you won't know what's wrong but yeah you can definitely get the updates from uh anywhere and just verify them one by one okay awesome thank you so much guys uh maybe one more question or comment or anything otherwise uh yeah huge thanks again uh thank you so much for all your work all your contributions yeah and the presentation thanks thank you very much uh