Lodestar light client demo, light client summit

[Music] we are an ethereum consensus implementation and yeah i want to be in the mood of memes i love the pipes it definitely feels like death contracts so i guess you all know the rationale of why we are here but we want to keep the decentralization lady happy and she is not happy we're making money but she's not happy she's not happy at all so what what can we do better so you know the deal we have to run notes it's important we contribute to the networking layer in the future to data availability and all its fun stuff so um the current status um piper describes this perfectly we have this ecosystem where it's very fragmented where some players actually run these very expensive full nodes and then the rest of the user base just use remote or pcs and then we have this empty area that we want to fill somehow with different use cases to give more choice to the users so in the future i see that dabs and at least super users or those that do care about the network and are willing to pay an extra trade-off would be able to fill this space with the technology that we can develop so oh and we are still doing better than traditional finance just fyi so here we have seen a lot of initiatives we are focusing on browser like clients so this is what we are going to present sorry i'm turning around because this is not working i don't see anything what's going on so the journey of a browser like lion is to first acquire the tip of the chain we can do that in different ways but as a consensus implementation we know that we can do better than just trusting some party so we're going to explain how that works once you have the tip of the chain in proof of proof of stake you have to go from that state route which is proof of stake and get some useful data that could look like the ethereum one state route or some blob data and then you go into l2 in this case we just go to execution layer which is what we know and love through minute and then in el territory you get all the fun stuff you can get state you can get balances you can get blogs other things so yeah the first the first part is get the consensus here we do the protocol that ethan has explained really well so we have this altered gadget where there is a smaller subset of validators called the syn committee where they just attest every block was the past block they rotate every day and it's a small so thanks to the large the insane amount of validators that we have and the randomness this is secure enough but at the same time it's small enough that it's pretty cheap to sync and you don't have to validate all the keys but just 512 so it's pretty sweet very light then yeah this is how they rotate but ethan explain better i'm gonna just skip um you can also track the head close we can run some heuristics like i show here if participation drops too much you can assume that this chain is not not safe but yeah you can have all these tricks where you can actually track the head with some probabilistic we can even skip the one block delay if you connect straight to gossip but then it's going to be a bit more expensive but that's also an option then for el now that we have a root we just do merkel proofs from this state route you can get any data that you want in the state in the demo we are gonna just show going to the latest execution header and then for execution layer same thing miracle proofs prove everything you can you can see any data you want then this is the journey summarized consensus it's a honest majority assumption the data requirements are really low so this is where i put this label doable because we can actually build a lot of fun stuff we can do peer-to-peer today and it's it's something that we should go for because it has this honest majority assumption for cl because everything is proofs now we only need someone that gives us data we can prove that this data is correct so we cannot be led into any valid data but we can be censored so here a client server model with multiple riders in my opinion could be sufficient and the same applies to the execution side here i put the heart level because the amount of data that's here is absolutely insane as piper knows very well so yeah this last section will be taken care by the portal network in the future um being fully peer-to-peer but so far we are just doing a centralized model with a client server that again can be multiplexed so you have a bit more resilience against censorship so yeah we in loadster have developed a rest api as it has been hinted in multiple representations where you can do all of this you can you can sync with the proof of stake committees and then we provide proofs so you can jump into the execution layer land and then there we reuse the existing method the eth get proof to get proof in the state so these are the routes to do the first to the consensus yeah i'm not going to go over them then this is the equivalent for peer-to-peer and and yeah so for dcl we are using these get proofs then for el same packet proofs but this is in execution lan and something cool that i want to bring attention and i have talking with this with some people is that we have developed this client that can give you a tip of the chain in a sufficiently decentralized way then you can get the execution proof but to do actual fun stuff and replace metamask and infura that's the dream we need this middleware logic that converts your average json rpc calls like eth get balance if calls into something that you can actually prove so in this diagram the first section is what piper is working on these really cool centralized networks for data provider but then you need this logic to actually translate the json rpc calls into something that you can prove so when i when i'm what we are working now is into doing that now and then we can deliver this trustless but sensorable rpc that it's still much better than the status quo and it's not use it's not useless because then you can just deliver the portal network faster so just keep in mind we can do this so yeah um my point is we are in the status school that sucks we want to go to the portal network land which is awesome but meanwhile we can still do some fun stuff it's not as sexy but it's an it's a significant improvement that can deliver value to the users really soon so we can work on that yeah so my point is start to school sensors sensorable not trustless we can go to the right and we are still sensible but we are trustless this is significantly better so demo time all right so uh it's pretty similar to the mycelium demo we saw earlier but and i think like by now you're probably getting the kind of idea of how the light client serve a light client is used in practice you need a trusted route to start it'll basically bootstrap some small piece of information will progress forward to the head and then we can then start requesting proofs about the beacon the beacon chain so uh select kiln because that's kind of where things can get fun when we can start doing things on the execution side um so uh we'll just fill in the trusted route um with our own trusted back end so we're just trusting something right now but you can fill this in if you go to like the kiln block explorer fill in a beacon block and initialize well that was fast a little too fast but uh so we're synced to the kiln chain now um and uh let's see so behind the scenes again we fetched a snapshot we then fetched updates up to the head and now we are fetching a new update every single new slot and then from here uh we can select an ethereum address um what we're doing here is we are using the existing json rpc we're sending a get proof request to an execution back end and we're retrieving a balance on the on the execution execution right now so this is you know it's not the beacon chain it's all the way down so it's kind of useful it's kind of cool um i think like kind of just like generally looking at like what we what we've been doing here is kind of like incremental progress towards something that can be more and more useful um like ideally like later it's like okay now then we can hook into p2p we can make things more decentralized um we can you know make it better and better but start from something that works and then like move outward from there anything you want to add i think yeah i think you nailed it like we are working for something big um we know the goals but we want to provide value as soon as possible and yeah this is our push for this no i just wanted to go over some of just like the considerations that we have um working in the browser so um we have some limitations working in a browser context we don't we don't have access to um kind of you know lower level networking things it's just just what the browser gives us of course when we go into like browser extensions things get a little bit more uh we get a little bit more but we still have some limitations so tcp cannot do that udp cannot do that um udp especially uh we can't really do that in an extension i think you can can't open a raw tcp socket so um though we're not really exploring that right now then we get to http websockets and web transport these are these are okay i have a yellow dot here it's not green because uh it requires the server that you're connecting to to set up ssl certificates so it's not really like a zero configuration way for a server to like help out you the server kind of the operator needs to do a little additional work um and then there's this thing webrtc uh kind of this uh web specific peer-to-peer protocol i also have this as a yellow dot because this can work but there's a lot of caveats to actually making this practical like you need a signaling server or you may need a signaling server we're doing some research right now to kind of see if we can remove the signaling server and then allow browsers to directly connect to a server using webrtc it's possible there are some caveats uh with what using webrtc it's not it's not usable in uh browser worker web workers or kind of in background workers it's only available in a main thread so it's not great for all browser applications it's kind of workable it's yellow some questions we're asking are we are you going with a client server model are we connecting to a peer-to-peer network we can do both uh we're starting with client server it's easier peer-to-peer is great because maybe there's more peers on a larger network um but maybe and then we need to figure out how we're discovering those peers uh rest that's what we're starting with it's easy it's you know it's very easy to just uh add a new endpoint um but it may be limiting in the sense that you have to now configure specific servers that you're connecting to uh lib p2p yeah that would be great um except the current consensus spec only has a must for the tcp transport which is not expressly browser compatible so if we actually want to make that practically more useful for the consensus network we would want to add additional additional transports as maybe shoulds or something in spec and then this v5 portal it's a udp protocol we are kind of limited there um but uh the ultra ultralight team has been working on a proxy it's really thin kind of proxy and um passing things to a proxy then kind of opens up the world of portal and disk 5. so there's challenges but we're kind of working on things and making incremental progress let's go thank you so yeah we really hope to collaborate um thanks for all the awesome initiatives that have been so far um shout out snowbridge i think they couldn't show in here but they are also using this technology and shield time so yeah lots are we do like clients but our main job is we have a consensus client so if you're interested in joining or running it we are in production we're doing notes everything is going fantastic so if you want to contribute to diversity please consider running loadstar um yeah also these four updates on loadstar and yeah there is a party tonight sponsored by chainsafe so if you want to join you can just use the promo code i think everyone in this room can enter so yeah thank you so much [Music] you