Light Client Design in Eth2

Transcript

hey everyone this talk is called lighter than air we're going to look at consensus layer like clients of the ethereum network so first a little bit about me i'm alex stokes i do research and development at the ethereum foundation lately i've been focused on the altair beacon chain upgrade which we'll hear more about the rest of this talk and also security and testing of the different beacon chain client implementations if you want to reach out to me directly twitter is probably the best way to do that uh there's my handle r alex oaks please reach out with whatever you have so in this talk hopefully we can answer these questions uh you know what are like clients in the first place how do they work with ethereum's consensus layer

and why should you care and you may ask that last one because you you know you come to the space and you hear all these things like throwing you suddenly there's like mining nodes or validating nodes full nodes light nodes even things like stateless nodes and it can be really confusing uh the point is is that we have this shared data with the blockchain and it turns out you know there's a huge design space all these trade-offs we can make in terms of how we access that data and for like clients in particular right we can actually trade off security for the resource construction of processing the chain so we'll start with some history uh this goes all the way back to the bitcoin white paper with simplified

payment verification um the the basic idea and this is the general design of all proof work like clients is you just keep track of the headers so the headers are summaries of the transactions in the block so they're much smaller than the full block uh so again as a like client you have much less to download and if you need to like make any queries about the state of the blocks or the chain at that point at a given point in time uh there's some way to do that maybe with like miracle proofs or something like this uh we've had uh for a while right we've had les and our def p2p networking stack and ethereum um and yeah it works today you can go run an lis clients both client or server and yeah just to round out some of the

intuition uh as a like client right you only have the block headers as a like client you basically are following the header the chain of headers with the most work so each of these headers commits to a difficulty which gives you some sense of how much hash power went in to sort of seal the block and let a minor append to the chain uh they also commit to a merkle root right so by following the longest chain we know what the canonical one is and then by using this miracle root we can then ask trustlessly for example was my transaction included in this block and we have something called a merkle proof that lets us do this with you know not too much overhead we can know yes or no based on the data i trust in the header

i receive if the transaction was there or not and in ethereum this generalizes right to the full state and you can have all sorts of sophisticated queries um cool stuff so then yeah we can ask about the security model right so we're only tracking the chain of headers and for like fire that's great because it's way less the process however uh we're now reliant on a majority of the hash power to be honest and what that means here right is that if there is uh you know if the set of miners and bitcoin for example is corrupted then like they could append some malicious block to the chain and not show us another block or even just only give us the malicious block and as a likelihood we wouldn't actually know so in order for this to be sound

we need to require that a majority of these miners are honest otherwise they could do things like this this is a pretty classic attack so as a minor i'm go along let's say i make this malicious block the first one i add it to the chain and i just make a fake transaction that gives me 21 million bitcoins on top of you know however many claims there already are as a like client this is all i see and so i wouldn't actually know that this malicious transaction was included uh which is actually quite bad um so that's why you do have this like very strong requirement that the majority of whoever's giving you this this consensus data is honest but again it's a trade-off because now as long as you can assume that then you

now don't need to bother with a bunch of transaction data so right you don't get anything for free but uh you know if you're making smaller day-to-day transactions then this actually could be plenty of security and again this is the trade-off you're making uh i'm sure you've heard of this by now right uh we have a very celebrated move to proof of stake on the way uh we launched the beacon chain it's driven by a proof of stake consensus instead of a work consensus and it aims to be a more secure scalable and sustainable home for ethereum i took this snapshot here from the website beacon chain and it has some stats on the beacon chain right now

so you can see we have epochs and slots which are units of time so it's been going for a while uh this is pretty cool right over 20 000 active validators so um a lot i believe that's actually orders of magnitude more than any other proof-of-stake network at the moment um almost 7 million you know more than seven million stick ether uh it's pretty incredible and now you know the design changes a bit uh because we don't have this proof of work header change for line anymore uh we can still have a header chain but there's no hash power or difficulty that we can use to figure out what the canonical chain is so instead we're going to rely on the validators and then require validators to make cryptographic signatures

on this canonical chain so they just sign you know the chain every so often even as often as every block and then as like clients we consume that and we say oh this is the chain because you know it's the chain with the most stake that has that i've seen rather than the most work but okay so we we take this like very naive design uh and we kind of already run into a problem uh because uh you know in ethereum we strive for a very broad decentralized ecosystem and this is a great strength um but one way we realize this is we have a very large validator set for the beacon chain right it was over 20 000 validators so that kind of is confusing right if we wanted to design a light client because

we just said we want the whole set to sign off on the whole chain so you have you know over 20 000 signatures every block like that actually sounds quite heavy uh so what are we going to do and it turns out we have this pretty cool technique that we use in many places over the beacon chain but the idea is rather than having the whole validator set we're going to have subsets and we call these subsets of committee right so you randomly sample different subsets of the validator set and so i tried to model this here there's like all the validators represented with this like blue gray circle then we have like random subsets and like the purple green and orange and for the sync committees which are these committees we're going to use to

facilitate the like clients uh what they're going to do is rotate every day and they're still going to sign off on each block but they're going to do it well it'll happen in a way that is much smaller for like clients because it's a much smaller set of validators so let me let me explain this picture here so it makes more sense uh the the blocks here at the bottom so this is representing the chain and then the line here with like the the vertical marks that's representing time so then it's like every day we're gonna have a different random subset of validators uh perform this duty to to sign off on the chain right so you have this purple committee move to the green committee

move to the orange committee and uh that's going to be sort of our primitive here as we make this sync committee that is randomly called from the full set uh they're going to serve for about a day of signing the chain and those signatures are end up going to like clients like clients except a majority of these signatures um in order to know you know what the canonical chain is at a given point in time and we still have this honest majority assumption and so you know our task now is to make sure that it's really hard to corrupt the sync committee and there's a number of ways we do this right so first off there's just a huge validator set like i said before over 200 000 validators and that number's just getting bigger so

first off there's just many validators to pick from and hopefully the more there are the less coordinated they are the way this this shuffling works is that it's driven by randomness on chain and you only have maybe a day or loss of look ahead right so what that means is that basically you you might not even know until it's too late for you to pull off an attack who you need to even target in the attack and then yeah along with that right we have the frequent rotation where again this period is only like a day so even if you do know the committee and they come to serve their terms so to speak you only have so much time to actually like coordinate them and if it's this like large randomly sampled set like it becomes quite hard to imagine how you even like start doing that

the committees let us do other cool things uh so for example they facilitate sync and like actually quite efficient sync so the way this works is that not only are each committee going to sign off on a block they're also going to sign off on the next committee and so what that means is we actually kind of need one update per period to know hey the state of the chain was this and also the next committee was this and because we know that we can actually use that to skip committee to sorry we can use that to skip from committee to committee stumbling over that one uh i don't know if it's called this but just to give you some intuition we'll call it skip sync and the idea is rather than having to go block by block and say okay figure out who the

purple committee is get all of their signatures and then for each block figure out the block and then move forward we can just go once per period and so i put these gold blocks here to like you know highlight that all i need to do when i'm syncing is even starting from genesis i only have to go one block per period because one update you know will give me the block it will also tell me who the next committee is and so that way i can skip forward period to period and then i can do this all the way up until like the current period say the orange committee is in the current period where then i can say okay now i go block my block so it's a really efficient sync uh you know other than a more naive method where you do have to

go you know do all the blocks and if you synced a full node on ethereum you know that it can actually take quite a while so this is pretty cool uh to give you a sense how this all ties together because not only do we want to know the head of the chain we actually want to know the state of the chain right and so uh these light plan updates i was talking about right so if you go period by period you go gold block to gold block you get these updates which are headers of those gold blocks the headers have been signed so you know they're valid the headers then contain a state route to the beacon state which is the state of the beacon chain this state route then

you can authenticate to a particular beacon state with merkel proofs like we could with spv setup after the merge the beacon state will contain an execution payload header which again is the header we know from ethereum today that header contains a state route this is the ethereum stage that we all know and love has things like token balances uh nft auction state uh you know unit swap pools all that fun stuff so the point being as a light client you can have a really efficient sync to get to the head of the chain you can then via you know this whole tower of merkle proofs ask really you know precise things about the state of the network and get it sort of authenticated right in this like very trustless fashion

so and that unlocks a lot of use cases like even today right uh the obvious one right is like having an ethereum client on your phone or in your browser uh rather than having meta mask reach out to infira metams can like wrap a light client which then is reaching out to this decentralized network uh it also facilitates stressless bridges so basically all the bridge designs that you hear about this is how they work is you know if cheney wants to talk to chain b then you know it's a like client of the other chain and vice versa um so you know if you want to bridge solana or avalanche or whatever other chains are out there these days right you can uh you know you basically want to have a like client of the beacon chain to bridge to the ethereum network

uh this work also you know is a really exciting foundation for tomorrow uh in the same way that we talked about like authenticating data with all these merkle roots we could imagine similarly authenticating computation so i could even say like hey i'm a light client i want to know you know some some token route to make like a trade on uniswap to sushi swap back and you know for some reason i want someone to do that for me so then i could actually say hey here are the inputs here's like a chunk of webassembly code i want you to execute the inputs against you get an output and you could even give back some authentication that here's the output and also the computation is done correctly and of course this can be extended you can compress that verification with snarks and techniques like that

it also serves as foundation for what i'd say is the broader vision of web3 right where these networks are permissionless that permissionlessness leads to innovation the innovation then leads to like hopefully greater opportunity for everyone um what that looks like is your like client can like trustlessly request a decentralized front end for example like openc on ipfs the like clan itself serves as like your web3 endpoint as a decentralized backend and suddenly you don't have this reliance on you know platforms that may censor you or you know choose to try and control your behavior in other ways so hopefully that piqued your interest uh you're like cool i want to get involved what can i do

and there's a ton so on the research side there's plenty of specifications and like work we can do to improve that there there's an issue even on the specs repo you can check out there's this uh pretty cool design with with cello called the ultralight client where basically you make a snark for those light client uh those committee jumps so that's worth looking into also there's this whole question of incentivizing the light server so we didn't talk too much about that uh but that's i'd say a problem with las today is that there's aren't enough server nodes so it's hard to operate a like client if you are more engineering side of things you know anything i just talked about could be prototyped all tears on the way we'll

need like plant prototypes you know the light client itself has a relatively small footprint so you could even try you know working on a hackathon over the weekend and see where you get uh maybe you're like hey like that's super technical but i'm just here i'm super enthusiastic what can i do and i just say like run nodes uh especially nodes that have a minority of the network share right uh and this basically just leads to like a stronger networking layer which is the foundation for like everything else so it's it's very good for network health to do this and yeah thanks uh if you wanna talk to me more please reach out on twitter there's a protocol r d we have for research and development there also a lot of the stuff is talked about on this

eath research forum thanks everyone