Light Client Support in Prysm

So, hey everyone, I'm Preston. Hey everyone, I'm Rupam. We have been working on integrating life's client server-side support in Prism. For the project intro, 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 line works is basically they maintain this chain of block headers until the latest block header. 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 like clients after the merge by Ethan.

It was covered in Defcon six, I guess. Yeah. So you can check it out. It's really nice. Yeah, so if we're looking at what a Lite Client update looks like, it's a simple structure.

It contains the block header, so the Lite 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 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 checks out, and this is actually part of the chain.

So how the network works right now is that we have this beacon network, which full nodes 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 stay synced. And then we have this RPC provider that we might not trust. So what a light node, what a light client actually does is that it gets the data from that RPC. But instead of just trusting it, it checks it against the state route that it gets from the full nodes.

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. Yeah. And there are four endpoints. The first one, the bootstrap using the block route. You have the trusted block route in the network and you can just call the bootstrap on that block route and after that, yeah, you get a range of three updates, let's say three here, and when the light client has synced up to the latest block header, you can just keep calling optimistic update or finality update according to your needs.

Yeah, so the project faces that we had was we got familiar with Prism and how light clients work. And then we started implementing the specs and then going back and forth with testing and debugging. This is nice, but this is a lie. This is how it actually is. So everything was weird.

But, yeah, so the current state of the project is that we implemented the four RPC endpoints and we implemented that for like forks after alter, which is all the forks that support light clients. We implemented two databases, one for light client updates and one for light client bootstraps to store them and not have to manually compute them each time. And also we implemented saving updates and bootstrap when receiving new blocks. Unfortunately we haven't still implemented saving them while syncing. And also the P2P events and topics were implemented.

So these functions are not only exposed through the beacon RPC, they are exposed through the P2P network as well. And these are all visible on the EPF Lite Client branch on Prism. Oh yeah, we have a, well, kind of demo. So these are old, but this is the Nimbus server, and this is our server. If we reload them at the same time, if we are lucky, we get the same result.

Yeah, kind of the same result. And so the difference, as you can see, is that we have this bug which gives us three more execution branches, and we have to debug and see why. Yeah, but mainly we can see that this is just one of the RPC endpoints, but this is for the demo. They're mainly working correctly. Okay.

Yeah. As of the next steps, we do have some work left. And the first of all would be we would need to test it out on a testnet. And, of course, like, measure the test performance and optimize it according to that. As also Bastian said before, like, 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, adding like client stuff to E2A tests and code doses, yeah. That's for mainly for testing for all the forks. So that's what the next steps and yeah almost all consensus layers support like lines now including Nimbus, Loadstar. So yeah Prism is also into the game now.

A special thanks to Radek and Josh and Mario for the cohort and Radek for the awesome mentoring here. Thank you Thank you very much Thank you very much guys. Yeah, I really appreciate you sharing all of this. Do we have any question for Bustin Rupam? Yeah Excuse me, I have to scream.

Do you know if there's any plans to add endpoints to generate proofs? Sorry, add what? To add proofs. So, like the light line data set is very limited. There's proofs to prove the execution branch and the finalized header.

But say you wanted to prove something else in the beacon state, like block roots. What would be super useful if 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 lifeline spec. So there are multiple EIPs open right now that work on adding, getting proofs from the execution clients, not the consensus clients. But yeah, there are multiple open PRs, I think at least four, that point to different parts of the block where you can get different proofs and then validate them using all these routes that are in the block header.

Okay, but no beacon state proofs yet? Beacon state proofs? 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 root. 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 as a 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 is a Z, right? And then you have to like create the tree and then generate the proof ashes yourself. But like for instance, load star has an 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 sometimes the apps using the light line data can't get to all the data that you'd actually need. For instance, I work on a bridge project and we need to prove, if you have a finalized header, that another header is an 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 there is such a thing in Prism right now. But maybe...

Hi, I'm from Prism. So, yeah, recently, actually, we had another person asking us the same question. So we're actively looking into that. So even if it's not in an official light client, like future plans for official specification, it's definitely another point I would like to add. So we can talk to Nimbus how they do that.

And I think in the next few months, I hope we will have something to share with everyone. Awesome. That's great news. Thanks. Thank you so much, Radek.

I just wanted to say thank you for this project. I had lost all hope of Prism ever supporting the Light Lion, so thank you. Awesome. Okay, quite a quick question. Maybe my understanding in proofs and stuff is quite limited, but can you, for example, bootstrap your light node from consensus client and then start to query the RPC provider for the latest data?

So you would unload basically all the RPC calls from consensus clients? So you could use, if I'm understanding your question correctly, you're asking if you can, instead of asking the RPC providers for data, ask consensus node for data? No? Okay. asking the RPC providers for data, ask consensus node for data.

No? Okay. The other way around. As I understood, you get the latest block data, like finalized... Block header.

Latest block headers from the consensus node, yes. But can you do this from RPC clients? Well, yes, I think so. You can do that. But the point is that you basically check and verify all these updates one by one using the sync committee signature.

So it doesn't really matter where you get those updates from as long as you have everyone in order from where you start. And this is all dependent on if your first trusted block route is actually part of the chain. So if you've been tricked to use something that's not on the chain and is 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 anywhere and just verify them one by one. Okay, awesome.

Thank you so much, guys. Maybe one more question or comment or anything? Otherwise, yeah, huge thanks again. Thank you so much for all your work, all your contributions and the presentation. Thanks.

Thank you very much.