Realizing the Light Client Dream in Eth2.0

Transcript

hello everyone [Applause] [Music] [Applause] who is excited about ethereum too because i'm just gonna shield the [ __ ] out of the technology that we are using in this talk okay so hey welcome to my talk i'm gonna explain how load star we are realizing the ethereum two dream actually not ethereum two please consensus layer we're going to make danny ryan happy with the new terminology so we all know that now in ethereum you either go all the way centralized and using fiora alchemy

or you run nodes it's great you contribute to the network but that's not something everyone should do anyway so piper did this amazing talk in fcc showing this problem that you have two extremes like you can either go full infuria or full full nodes but we really want something in the middle some this pink unicorn happy thing that's kind of a middle ground between both because we don't really know what users want maybe there's a huge demand for that but because no one has successfully developed and promoted that we don't know so you were saying oh wait like lions exist already les the

light ethereum super protocol but it has never worked because essentially it's a parasitic participant there are no incentives so it has never worked the dubno team we know that very well we tried with bipnote it didn't work but yeah just go to piper's talk he talks about this issue in great detail it's great so i'm a consensus developer and i care about my consensus layer so when we are moving now to the merge to proof of stake it gets even harder to support my clients because now improve work if you want to track the head that's the first thing you want to

do in a client no what's the head what's the current data you just gather your headers you modify the proof of work and voila the longest chain is your chain however now with proof of stake you have to run the full lmd ghost on all the boats you have to get all what the validators are saying compute the active set it's very expensive essentially you are a full likelihood that's not light but i'll tear to the rescue so in this hard fork we are introducing syncomidis and what they allow is that instead of tracking the whole validator set you just track this small subset of validators that you trust

and then you can like trustly get the chain get the head so the sync committee is tiny 512 validators doesn't sound like a lot but there is security guarantees that this number is sufficient to not be corruptable when we get to sharding this is what the sizes would be for the shark committees so it should be good enough and one day it's like not so long that it will be expensive to sing but also not so short that it could be corruptable so you have this in committee you get selected randomly now what you have to do you have to sign the head every slot and everyone in the same committee does that then you you can go as a like lion

and aggregate the signatures and you get this blob that we call the aggregate signature at block n that is your head so once you have this you are not done yet now you have this thing that you have to validate the signature so as a light client you have some trusted sync committee that you have seen with a trusted checkpoint or from an init proof and then you validate the sync aggregate the thing aggregate says validator number one number three number 400 has signed this thing you add the public keys you run bls magic and then you validate the signature next step you have to get the block header they have signed

from there you get the state route down to the finalized header and then you get that header and then to the straight route you get to the next in committee and boom you have successfully synced to the next in committee so it sounds complex but it's not too bad there is some problems with gaining all this data that we will discuss now so the key here is that you know and love your 512 sync committee members you trust them whenever they sign you will believe it but the whole point is like to progress down the chain to sync so you start with your sync committee number one they are signing stuff and the key point is that they have to sign something that

says the new sync committee number two is the right one and then you can trust them and then you move from day one to day two and now the scene committee two becomes active and you repeat all over again and this is what happens all the time when you want to sing and brush the head so there are some edge cases that i want to note and are very important we handle them what happens if there is no finality during this period so a key point that you noted here is that we only consider the next sync committee of a finalized header otherwise what could happen is you think that the next thing committee would be sync committee number

one but then there is a reorg and now it's another one and you are screwed because now the whole chain of trust breaks and you can no longer sing and that's a fatal failure so if unfortunately there is a back like it has happened sometimes and there is no finality during a whole day it would happen that you have to trust a non-finalizing committee to move forward and yeah we take that into account and it's also important to take into account that a syn committee is completely independent from the network so the security guarantees are different the notion of finality is not the same you can really choose what you want if you want to trust hey 50

being honest is good for me or maybe i'm an exchange and i need 66 percent or 80 percent but it's kind of adjustable towards your requirement in terms of security so to make all that process that i said before possible bls is absolutely key if you don't know about this technology it's fantastic and it's the reason why we have ethereum two today it scales fantastically uh with a constant size complexity of proofs this is how we can have 250 000 millions of validators signing stuff and still being manageable and in our case we it's very useful because the thing aggregate has one signature regardless of how many

validators and we have an implementation of wasm that's fast hell yeah also if you guys are familiar with execution layer aerial p has been great but it's not great for like clients it's quite expensive and the most efficient implementation of binary trees are binary trees so ssz uses that our implementation also supports merkel multi-proofs and some goodies that makes the whole process i described before good and fast so we have come up with a proposal to serve like clients this is implemented i would show it in a bit but essentially you as a like client

this could be a wallet an application or a browser just starts over and first it has to get an init proof this is the from a trusted checkpoint um that would be like a research levity i'm not sure if you guys are familiar with that concept from eth2 but you get your first snapshot then you use the best updates to sing from period one to video two to video three to period four to grade five up until the last one and then you can pull the last two methods to be up to date and get the most recent chain data that you're interested in so i want to note many of you would know loadstar is a javascript client and many people ask us

why do you do that why it's implemented in javascript well it turns out that javascript is a great language for tree structural sharing and that's an essential feature to serve like clients because we can afford to keep a very large amount of states in memory and have like really fast arbitrary proof generation and this is not supported for all the clients like prism or lighthouse that they do binary sorry a linear hashing cache that's not supported so we do that and it's working great for us so demo we have built ui functional ui with the rest endpoint

and everything that we have explained so far you're going to see in practice [Music] [Applause] hell yeah so in this website this is a proof of technical leash thing this is not how things will work in real life but just to show that this thing works first you need some sort of anchor of truth something you trust in this case i'm going to simulate that with a drastic checkpoint so i'm going to go over to beacon sha and in this case i'm just going to pick the latest finalized checkpoint and copy the root of the blog for that

hopefully in the future there would be better tooling and it will not be so obscure as just going here and copying this but just to give you a flavor that you go to some place that you trust it could also be a friend or something else and you put it here and then we hit analyze and now it's going to get the init proof start the snapshot sync to the latest sync period in this case is two and getting a header that they trust and now we have this state route that we have trustlessly synced and we can ask for data so in this case this would be supported with some sort of web3 js or etherjs wrapper to ask the data that you want

but in this case we have this text area at the bottom where we will request just some data in this case the slot and the balances of validator 0 and validator 1 it serializes this request in in a path format and when we hit submit we would get a response with the data and the whole mergle multi-proof of these two things boom there we go and now you have successfully consumed data in a trustless way so hell yeah [Applause] so yeah the

we just showed some tooling but uh in loadstart we have developed an other great suite of tools that we are super proud of so yeah just check them out use them and okay so now what as i said i'm a consensus guy i work on the bottom layer but i wanted to build this to kind of illustrate you how the whole like client stack would look like as i said the first thing you want to know what's ahead that's soft that's what we did to today together once you know what's the head now you have to get some data from the state that's this new box i call the beacon state proof provider

um i we simulated this today with a special rest endpoint but this could be maybe in the future some protocol of the centralized data by levity like portal network and now is when you get into the fun stuff what you want l1 data awesome you can go to the alias protocol or the portal network and then you could actually build a trustless metamask today if these things were available portal network is almost there the last protocol we are working on it to making it stand alone so it can be browser consume at least um for a technical proof and then we have l2 so shard data l2 you know what jordy explained today we can connect to that and have a

trustless robot client that would be super cool too so to reiterate what i am passionate about building and i think it can be done next year would be a metamask that's still sensorable but trustless so to get to the point that we are not sensible we would have to somehow hack a p2p protocol into the browser but there are already research efforts into that and it's going to be way more expensive you can see at a factor of a thousand but i think it's okay i would do it i would take the trade off so yeah next steps

integrated portal network we'll keep doing research on p2p so exciting super exciting so if you find this exciting come join us i mean you can see i'm so passionate about this is so crazy i love it so if you are too please come join us we are an awesome family and yeah last but not least lodestar is production ready [Music] yeah thank you to everyone the team and the researchers that have been working for years to make this happen i'm so happy to be considered like the fifth production ready client please come to our discord we will

help you set up or just come do a test net whatever try it and yeah thank you so much for your attention today