# Light Client Support in Prysm

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 12:05
- Watch: https://streameth.org/watch/yt-d7j5WwTkZYs
- YouTube: https://www.youtube.com/watch?v=d7j5WwTkZYs

## Description

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

## Transcript

So, hey everyone. I'm Baston. This is Yeah, hey everyone. I'm Rubam and we have been working on integrating light client support server side support in Prism. And for the project intro, like light nodes are basically nodes which you can run which you use significantly less resources than a full node. But there are some drawbacks. How a light client works is basically they maintain this chain of block headers until the latest block header. Yeah. We get this trusted block root 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 latest block header. So there's this reference of the light clients after the merge by Ethan. It was covered in Devcon 6, I guess. Yeah. So you can check it out. It's really nice and yeah. Yeah. So if we're looking at what a light client update looks like, it's a simple structure. It contains the block header so the light client can basically save that block header. It has the current sync committee public keys. The sync committee is the 512 validators that sign each a block header. And the light clients basically verify that block header by checking the sync committee signature and there's also something else called the sync committee bits which shows which of these 512 validators actually did sign the block header. And also there is this 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 stay synced. And then we have this RPC provider that uh we might not trust. So, what a light node what a light client actually does is that it uh gets that RP gets that data from that RPC, but uh instead of just trusting it, it checks it against the state root that it gets from the full nodes. Yeah. Yeah, and what we did in this project was basically implement that part, which is how the light node talks to a full node and gets those updates. Okay. Yeah. Uh yeah, and there are four endpoints. The first one uh the bootstrap using the block root. You have the trusted block root in the network and you can just call the bootstrap on that block root. And uh after that Excellent. Yeah, you will get you get a range of three updates, let's say three here. And when the uh light client has synced up to the latest block header, uh you can just keep calling optimistic update or finality update according to your needs. Yeah, so uh the project phases 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 Altair, 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. Uh and yeah. And also, we implemented saving updates and bootstrap when receiving new blocks. Unfortunately, not still uh have 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 through the P2P uh network as well. And uh these are all visible on the uh EPF light client branch on prism. Is there a 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 list results. Yeah, kind of the same result. And uh so, the difference, as you can see, is that we have this bug, 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 uh this is just one of the uh RPC endpoints, 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 all would be we won't uh we would need to test it out on a testnet. And of course, like measure the test performance and optimize it according to that. We as also Bastien said before, like uh we still don't save updates or bootstrap while syncing, which would be nice to have. So, we do plan to add that, too. And after that, yeah, uh adding light client stuff to e2e tests and kodos, yeah. That's for mainly for all of testing for all the forks. Uh so, that's for the next steps. And yeah, almost all consensus layers support light clients now, including Nimbus, Lodestar. So, yeah, Prism is also into the game now. Uh and special thanks to Radek and Josh and Mario for the cohort. Uh and Radek 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 Bastien and Roopam? Yeah, uh there. Uh Excuse me. I have to scream. Um do you know if there's any plans to add endpoints to generate proofs? Uh sorry, add what? Um to add proofs. So, like the light client data set is very limited. Um there's proofs to like prove the execution branch and the final last header. But say you wanted to prove something else in the beacon state, like block roots. Yeah. What would be super useful if um there was an endpoint to say, "I want to prove block roots at this index." and just return the hash. I feel like that's super missing from the light client spec. Yeah. 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? Well, we have the state root hash in the block header. So, if you have the proofs and you if you have the data, you can check that against the state root. Yeah, but so what I mean is like uh say you want to prove anything in the beacon state, at the moment you need to download the whole beacon state is a Z, right? And then you have to like create a tree and then generate the proof hashes yourself. But like for instance, Lodestar has a endpoint where you can say I want to prove 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 lightline 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 lightline data. Yeah, that is true. I don't think that's and the there is such a thing in Prism right now. But uh yeah, maybe Hi, I'm from Prism. So, yeah, the recently actually yeah, we had another person asking us the same question, so we're actively looking into that. So, even if it does not in a uh official light client um like a future you know, plans for official specification, it's definitely an endpoint I would like to add. So, we can talk to Nimbus how they do that and uh yeah, I think in the in the next few months we we should we I hope we will have something to share with uh with everyone. Awesome, that's great news. Thanks. Thank you so much, Roderick. Yeah, and Yeah, I just wanted to say thank you for for this project. I had lost all hope of Prism ever supporting the light client, so thank you. Yeah, awesome. Yeah. Okay, uh quite quick question. Maybe my understanding can prove some stuff quite limited, but can you, for example, bootstrap your light node from consensus client and then start to query uh their PC uh provider for the latest data? So, you you would uh unload basically all the RPC loads for RPC calls for from uh consensus clients. 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 uh consensus node for data. No. Okay. The other way around here. Uh they I say I understood you get the latest block data like a Block headers. Latest block headers from the consensus node, yes. But can you do this from RPC clients? Well, uh yes, I think so. You can do that, but like the point is that you basically check and verify all these updates uh one by one using the uh sync committee 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 uh first trusted block root 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 right. 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 and your contributions. Yeah, and the presentation. Thanks. Thank you very much. Uh oh