Lodestar Light Client Prototype - Cayman Nava - [Toronto Ethereum Developers Meetup]

Transcript

so i thought i'd actually do something a little bit different uh than just a an update um and go a little deeper on one of the things that we've been working on um specifically we've been working on the light client prototype uh we got a little taste of that from tim just seeing like that it's a new thing that's going to be up and coming in the in the altair uh hard fork and so um i'll just give us a taste of that so just real quick introduction uh tim already gave me one but i'll go do it again um i'm technical lead on lodestar you can find me on twitter kind of i'm not very active and on github and discord where i'm much more active um happy to interact

there uh real quick we're gonna do do today i'm gonna try to get to number three and number four as quickly as possible but i'm gonna start with just what lodestar is uh i'm gonna go over what the eth2 or consensus like client is from a spec level and then what we're doing as far as prototyping then we'll do a little show and tell of what we have been working on and then we'll leave some time for questions hopefully enough time for questions so what is load star lodestar is chain safe's um eth2 initiative uh it's a basically uh we're aiming to be a typescript an assembly script ecosystem

for all of ethereum consensus layer so we're completely open source mostly apache for a lot of underlying libraries and a few things that we have lgpl we have a full ethereum consensus client that as of right now is validating on on mainnet we've got two validators running uh under chainsafe management so it's a beacon node and a validator um both running and uh powering the speaker node and validator are 23 plus packages that we've built that are under or maintaining on npm and um

we think that the a lot of these are going to be useful just on their own and um we've built them to be as useful and reasonable as they can and uh just about the whole project we we're very community oriented uh we take a very community oriented approach and how we develop things we do all of our work out in the open we mostly communicate on discord and on github and we welcome anyone who's interested to hop on in all of the full-time members of lodestar all came to the project just basically searching through github and being interested in ethereum so that's just the ethos of the project and we hope to continue that

so let's let's dive into uh the ethereum the eth2 or the consensus like client i'll go and just keep it at our high level we're not going to go really deep into the technical details but just to give you kind of a sense of like what you're going to see in this prototype it would really help if you kind of have a sense of what's going on and we'll then get to some like open questions and um how how we're solving them right now so i'm just going to assume everyone kind of knows what a light client is it's a client that's supposed to be very light but can track a blockchain so here we have the beacon chain

and uh it's got block after block um and a light client what they do is um at least what's specified by the spec the eth2 specs is the light client has a snapshot of the of the beacon state uh snapshot is not the full beacon state it's just a tiny piece and it can find updates or get updates from somewhat some way that it can then validate and that will end up allowing them to produce a new snapshot that is synced to a further point in in the chain and so just at a very high level

we are a light client has a snapshot it can apply updates and then move to a newer point in the in the chain if we look into what this snapshot is uh it is a beacon block header so it just basically keeps track of a certain beacon block header uh in the of you know of the beacon chain and it keeps track of the current and next sync committee which is a small group of validators so we can use this state route from the

beacon block header to verify proofs these are going to be in updates or or otherwise and we can use these sync committee pub keys to verify signatures and we basically use a combination of vertical proofs and pls signatures to drive forward this sync process so these updates are you know they're given the kind of the green check by a combination of verifying proofs and verifying signatures so now once once we're synced to a certain point in the chain

we can then begin to request pieces of data about the chain so just thinking that the chain is not interesting usually from a client's perspective they want to know what their balance is they want to know various things about the about the chain so once they have the state route they can then request a miracle proof and verify the proof against the state route that they trust so this this proof can be approved for like the validator balance this is kind of as far as we can go right now with the beacon chain but after the merge that might be the execution route so like the eth1 state route and then from there you might be able to get something you're more interested in your you know your d5 balance or what

have you after after starting this proof might be approved to a shard data route so you the usually a light client like this is kind of the part that's more dynamic because uh every user probably has a different part of the state that they're interested in so some some of the some of the open questions here like what i just presented was as far as the the spec shows it doesn't really get into the practicalities of how the light client actually operates like in the real world so some kind of just questions that you might have so what what is a light client server how does like how do these updates and snapshots

kind of come into existence like how does a light client discover a server like where does it go to get this data um that you know that it can that it can use how are the snapshots and updates served is there a p2p network is there a traditional client server or relationship do i just go to infiera or you know how does that work and then how are the proofs served so these are all still um open questions and uh for our purposes as far as just building out a prototype that can kind of prove out the basic uh protocol we decided to start with a very simple approach so our answers are

what is the light client server well it is our own custom beacon node so we just use load star and we're building off of it the load start beacon node how does light client server discover a server well for right now we're just going to say the user inputs input to url in the future maybe we can hook into ethereum's discovery protocol and it can you know search through the p2p network and find peers that can serve the data how are snapshots updated and served well in both cases for updates and the proofs are served over custom rest endpoints so for snapshots and updates we

pre-compute these updates and then for these more dynamic proofs we generate these proofs on demand so enough of this explanation let's let's go see a prototype and uh this is actually open source so if you want to follow along um uh you can you know go here afterwards so i've actually got this uh i've actually you know cloned this repo down and got it running and that's i believe it's running on my local host

so let's navigate here live live demos are always kind of scary so bear with me if things go don't go right we got it preloaded here with um a beacon node this beacon node is running just a random devnet it's a single node running its own test net there's no um real value behind it but it's running it's running its own little altair fork so we get has enough infrastructure to be able to serve us some data that we want if we start initialize from a trusted node we're just going to say tell the node like we trust it give us as much data as you need to let us bootstrap so

we just downloaded a snapshot and then we also downloaded um several updates and we can see the latest our latest uh snapshot is at slot 97024 and we have a state route here so now that we're synced at a certain point uh up to the the latest finalized in this case um we can begin to request different parts of the beacon state so this is where things kind of break down and as far as usability for most people right now right now you can only

request data that's in the beacon chain which is just consensus data so validator balances things like that so in this case um we've got a um we we request these this data as a list of paths so right now we're going to request the slot we're going to request the zeroth validator's balance and the first validators balance and we'll submit oh hey i'm glad this worked um yeah so here's here's the data that we requested um so it turns out that the [Music]

the state that we requested at is at this specific slot and here is the zeroth ballot validator's balance here's the second validator's balance we could um you know uh we could add more data if we were so inclined is there a second validator i don't i actually don't know how many validators are attached here okay there are so we can you know you can we can we can create a more of a dynamic this is you know you can have a dynamic query here and query anything we would want um and then down below here we have the actual proof this is not super helpful for humans but just to give you like a taste like or

give you a sense all the data here is being verified at every step so you know all the hashes are checked and um so we're you know we're this is kind of like the full uh like client experience here um doing all these checks and that's that's kind of all on this on this uh on this demo uh we can pull back here to some questions if anyone has any amazing thank you cayman for showing us the demo of um of the like client and lodestar um if anyone has any questions

um um johnny ray asks is it possible to run lodestar in a browser uh i guess is this like the full the full beacon note i i don't think so um there might be well at least not not quite right now um there's probably a few modifications we need to do to make that work like within right now i think like disk e5 is you know a udp protocol and we use that to discover peers so if maybe you kind of could bootstrap the node with some known p2p peers i think the other issue is that most of the nodes on the network

uh are don't have like a websocket um an op like a lib p2p protocol they don't support web sockets on lip pgp and so i think that's like the probably would be the protocol that's easiest for the browser if if you had some some beacon nodes in the network that supported the web sockets um then then we'd be a large large way there yeah philip you had a question yeah um okay man so um just thinking outside more in like the economics aspect of it i know one of the um problems that a lot of people have when they decide to run an ethereum a node is that a lot of the

times there is no incentive to actually do so what do you think um we could do potentially just open a question here about um incentivizing people to run like a light client server yeah um so i think ideally like step one would be like make the like line serving infrastructure as cheap as possible so we broke down the like line into the sinking part and then the requesting the proofs like if you can have these updates be as cheap as possible to produce or maybe they can be even produced by a

smaller subset of the network but may be verified by everybody so maybe you can if you can broadcast updates on the gossip channel um can make it really cheap to get these these uh updates then you might not have to like incentivize them as far as proofs go like i think the pr generating proofs is kind of is something that's a little more uh specialized because you you need the the full beacon state ideally as a like full navigatable uh merkle tree and i don't know that all the clients store the state that way um

so what could you do for incentivization i i know that that um there's an ethereum foundation researcher uh his name is zolt folby i believe um he's been he's been working on like client incentivization model uh that basically tries to figure out the kind of what a market would look like where between light clients and like client servers where there could be some sort of guarantees that light clients could have with these cert with a server um some kind of guarantee that the server would have getting paid by the by a by a light client but i think it get paying for for data

that's kind of uh i would feel like as a last resort ideally we can um figure something out that uh doesn't require like pay explicit payments um for like a base level of service great um thank you we have also two more questions on slido um first one is how effective is load start on mainnet yeah uh good question um we are uh basically just as uh profitable as as the other other clients um i would say where we fall down is we do use a little bit more memory than some of them

um and a little bit more uh cpu but as far as um you know your validator profitability uh we're right up there with with uh with all the other clients nice um and then another question is are the load star nodes on main net new or did you migrate them if so how was the process great question um we migrated them so we were using uh these were chain safes nodes uh they were using a lighthouse beacon node and validator and these were it was a dockerized setup it was really painful actually um i did

this with greg the other day and it took us like probably an hour and a half of like we were on a screen share and uh we were you know dealing with docker set up and like really taking our time really trying to not mess things up because you know a lot of money was on the line um we realized that there's a lot that could be done to improve the experience of doing a migration uh like a lot of things that it was pretty standard but we just had to type it out by hand and some of these things could be maybe not turned into a tool but at least written down like you have a docker compose file that could just

export in a docker compose file that can import keys and like having those things handy could save people a lot of time wicked um johnny ray asks in the chat box uh do you have a bounty program for load store exploits we don't um yet question mark or that's a uh uh we gotta talk to talk to some of the talk of the chain save people and we'll we'll we'll see about that i do want johnny attacking lodestar so let's see what we can do

that's a good question um if there's any more questions um you can ask it in the chat box and i'm sure cayman will answer in the chat box or you know oh greg's like any element finance bounties um cool okay cayman thank you for um thank you for stopping by really appreciate your time um and yeah thanks for yeah thanks for thanks for inviting me