# 'State of Light Client Sync' - Sina Mahmoodi

- Channel: [ETHGlobal](https://streameth.org/ethglobal)
- Date: 2021-10-09
- Duration: 28:43
- Topics: Ethereum, Sina Mahmoodi, Light client, ETHOnline
- Watch: https://streameth.org/watch/yt-OXMINRtWWhI
- YouTube: https://www.youtube.com/watch?v=OXMINRtWWhI

## Description

Sina is a member of the Ewasm team, and his talk is about improving the user experience for light clients.

## Transcript

xena who is with the ewesome team and his talk will be about how to improve user experience for light clients welcome xena oh it wasn't mute hello everyone um this is cena i don't know what time zone you're in but um it's an evening here in berlin and you got to give me a minute to share my slides and we'll jump right into it i'm sorry this is just going to take a few seconds no worries take your time yeah google is asking for capture okay um can you guys see the slides that looks wonderful okay perfect so um yeah this evening i wanted to talk to you guys about um flight clients and this is a topic that i care about because um my work on the protocol started with the javascript implementation of the evm and i really like it to become a lighthand in the browser one day and so i decided to to work on this topic and i feel like this is a topic that's not being discussed as much recently even though it has good synergies with stateless ethereum and the recent discussions around client diversity with light plans we can have clients that don't have as much implementation complexity they don't need to implement all the old hard pro logics they have a simpler networking stack and yeah it's um good to have to be able to have nodes running in the browser or on a mobile without relying on third-party services so one of the light plans face multiple challenges although we have les that that's running uh one of the the main challenges that they face is that in order to have the right client you need a light server and the servers need to respond to requests from from the clients and currently this is an interactive process so my mobile has to send a request to the server saying hey give me this data and this causes these servers to become easily overloaded and therefore although most of them are currently altruistic we need complex instant in incentivization uh schemes for for them to to work in scale so um the the kind of the ideal scenario that that i was uh imagining and this is not this was first expressed by by others like uh turboget uh team is to have another sub sub network um with mostly light plants but but some full nodes that just broadcast data so that the light plants don't have to request data but let's say a new block comes in the full nodes broadcast the block itself and and the stateless block witness as well as a short proof that shows the the difficult the total difficulty of that chain and this is this will be the focus of our talk so we'll talk more about that later on and this allows the the light plants to be able to um follow the tip of the chain in a few seconds and the amount of data that light clients will have to request from the servers would be minimized so as i said the our focus here is um is determining the canonical chain uh with that i mean let's say we have a couple of competing forks and we want the light plane to be able to safely detect which one is the the correct one the one that everybody is using and currently the way that this is done so the the most uh safe and but also most demanding way of doing this is to simply download all of the headers from genesis until the last block and verify all of them and this is this would be just verifying the header not the not executing the body itself this is what the full nodes are doing but for light plants you don't really need to do this um especially when you consider that the total size of the block headers is somewhere between five and eight gigabytes so if you wanna have a client on the mobile or a browser this is already a non-starter and the current les protocol uh works around this by kind of hard for uh um hard coding some some checkpoints um in the client in the form of chts and um then you don't need to really verify the blockheaders from the beginning but from the last checkpoint but we want to see if we can kind of avoid this having this hard work hard coded checkpoints all right so um our design space is i i broke it into a simple spectrum and these these four items that you see are kind of what we will be discussing during this talk uh we have full verification that is very not complex at all um in implementation-wise but it requires the most bandwidth of of all and then we have a hypothetical zero knowledge protocol we have flight client and we have eip 2935 that is being discussed for berlin or the the hard torque after that so let's jump uh right into uh zkp uh this is a hypothetical approach i'm not uh it's not being really suggested as um being implemented in if if one mainly because uh zero knowledge protocols are really complicated and we want to avoid bringing them into consensus so but the approach would be that uh each block would come with a short zero knowledge proof that proves um that there is a chain like an unbroken chain of blocks from genesis to to this last block and that the block headers of all of these blocks are valid according to the consensus rules and it also tells us the total difficulty of the chain and we use this total difficulty to be able to choose between forks um what i want to wanna what i want you to take away uh from from this approach is the ideal properties that we are looking for and these are um ideally short proofs so for um zk snarks this is definitely less than one kilobyte uh and importantly non-interactive proof so you don't need to communicate with the client with the generating or the miner to um to verify that so somebody like a miner can produce this proof and just send it to everybody and everybody can verify it on their own and of course security is important and zero knowledge proofs have with very high probability good security and now to the flight plan and this was a paper published in 2019 i think by benedict uh boons and it offers uh some some good features uh like it offers uh short and non-interactive proofs of around uh 500 kilobytes to two megabytes it depends depending on some configurations i think this was a 500 kilobytes was in their paper for 7 million blocks it's secure with a really high probability um it was recently activated on zcash and it's being built uh by default in some other blockchains i think on grin and beam as well and it can be configurated to tolerate more or less dishonest mining power um but of course flight client protocol needs uh some changes to be made in in consensus and it boils down to adding a new field to the block header and this this new field is the root of of a tri of a tree that includes the block hash of all the blocks since genesis and the tree in question is not a normal norcal tree it's a customized merkle mountain range let's call it the difficulty mmr just as a refresher this is how a normal merkle mountain range looks like and the the color of the leaves don't have a semantic meaning uh that's just because here it's already autumn so the the leaves have changed their colors and uh this is an append only data structure so and here we have 15 leaves uh inserted from left to right so you can see kind of that it it it turns into multiple uh binary tri uh trees next to each other and um it's very efficient insertions are very efficient in this data structure and um you get very short proofs uh when the leaf that you're interested is in is uh very recent so the older blocks would have longer proofs but the more recent ones would have shorter proofs which is perfect for for our use case and now um in in flight client they've changed this mmr to include some additional metadata and the more important ones are regarding um difficulty and the time it took to produce that block and so on and here you see like a really simple example of a difficulty mmr with a simplified difficulty mmr with three leaves and you can see that the leaves have the block hash itself but also let me actually turn on the pointer yeah so you can see that this block this leaf has a difficulty of five and um this one has a difficulty of seven and when you go up then you add the difficulty to get a difficulty of 12. so this way you add the root of of each of these trees you have the the total difficulty accumulated in all of those those blocks which is a great property and this this is used extensively in the protocol um now how do you use this uh tree to to actually sync a light client let's say we have two competing forks we have an honest minor who's advertising a total difficulty of 700 and we have a shady looking guy um who's advertising uh a higher total difficulty of of 1000 and the like line doesn't know which one is the canonical chain um so what it does is like first sorts them by total difficulty so the one that has a thousand it will check it first this work first and the the gist of the protocol is just to do random sampling of the box so you don't verify all of them you just do you check some of them randomly and uh you can see that okay this this this fork like this chain has forked off um at this point here and we've we're checking some of them like if you see the ones that have a green circle uh circle around them let's say we are checking those randomly and in fact we've checked three and one of them is an invalid block so we caught you uh mr shady and okay so the the core of flight fan is in the in the sampling strategy as you can as you can imagine just doing a uniform sampling won't be really efficient or sufficient the the goal of the sampling strategy is to maximize the cha the chance of catching an invalid block uh regardless of the adversary's strategy like whatever strategy they're using we want to maximize the chance of finding if there's an invalid block in there and the way it turns out is that it's a like a probability distribution where we sample more from the end of the chain like we sample a few from the beginning and as you go to towards the end we sample more and more this is just because um an attacker could fork later on to use the the work that was accumulated by honest miners and the an important thing to note is that we are not uh sampling in the block number space so we're not saying let's say we have a chain of 10 million blocks we're not saying give me the block 5 million rather we're saying give me the block with half of the total work and we can do this because in in the merkle mountain range we're storing that extra metadata that tells us the total uh difficulty of each uh subtree um the other point to to consider is that each each sampling step is independent so they are not so you don't have to like first get one block and then depending on whether it's valid or not and check another one they're all independent so what we can do is use the fiat chamier heuristic to make this process non-interactive and um that's great because um then the miner can just when there's a new block um just produce a short proof of all these using some public source of randomness for example the previous the parent block is hash um so it uses this parent blocks hash to get a random seed and and get the list of blocks that have to be included in the proof and and send that to the to the light plans along with the the necessary miracle proofs in the in the merchantman range tree next we have eip2935 and this this is an erp by by vitalik and it it's a much simpler change um compared to to fly client in terms of consensus complexity and the difference is that we're not this time storing the uh the command range in the block header rather we are using the existing uh ethereum try to store these these block hashes so um as as you probably know we have the let's say this is a this is a block and the block has a state root field which is the root of the account try so what we do is like we hard code an address uh we say this specific address is a special like a system contract let's call it the history contract and this has a like story slots like normal contracts and in the storage slots of this account we store the hashes of the blocks and the blocks since the hard fork and not not since genesis this is an important distinction distinction so we're reusing a lot of the um data structures that are already part of consensus namely the markov patricia uh tree so the motivations of this eip were stated as light plane sync what we were discussing now but it's not limited to this neither neither this eip nor flight client they both are good for other purposes as well another one is for example like layer two state providing networks let's say uh clients like get start pruning history so you don't as a new client and you don't have access to the older blocks and when there's a commitment to the block hashes in the in the state then what you can do is ask a third party um to to give you that block along with the proof so that you can be sure that this block is indeed the third block in the chain let's say and you can this product this layer two solution can be incentivized as well um you can also use this for stateless witnesses because you have the block hash out code so block hashes of previous blocks need to be included in the witness and here uh so what what we want to address here is if we can build a light plan sync protocol on top of this eip and we'll consider two approaches two variants a one is very similar to li to flight clients and it's a random sampling approach the other one is a super block approach and super block i'm borrowing the term from nipple power another light client think paper so first let's see what advantage does this eip bring let's say we don't have this the eip2935 let's say right now why can't we do random sampling the reason is that the delight client doesn't know um when when it's asking for a random block let's say block 7 million it doesn't know that these blocks that he's asking for are actually chained together the the the attacker could just give some random blocks that are not even part of a single chain and but committing to to the whole chain um in the state it makes it um harder for attackers to do uh to do something like this um but there are also some challenges in doing random something on top of this eip um as you saw earlier in in in flight clients we we query in the difficulty space so we are asking what is the the block that has let's say half of the total work and this is important because um otherwise an attacker could create a long chain with many low difficulty blocks but but valid like from a point proof of work point of view um and hide a few high difficulty but invalid blocks in the middle and when you're randomly sampling it's really hard to find them if you're something in the block number space again because we're not using the mmr and we are stuck with the merkle patricia tree we can't do uh sub-range checks so we can't say let's say when we're verifying an old block we can't really check that this this old block is actually the tip of us of a chain that is a prefix of the bigger chain that like the canonical chain um again with a merkle patricia tree this is a really inefficient thing to do so we're kind of stuck with doing uniform something and in order to you like you if you want to have good security with uniform sampling you need to sample a lot so this means doing uh disappro this approach either entails higher bandwidth requirements or it has a lower security guarantees so as an alternative to the to to random sampling vitalik propose an alternative um which here i'm calling super block based sync and the intuition here is um that so as you might know the blocks in ethereum they have a kind of a difficulty target and a proof of work is that a proof-of-work solution is valid only if it's exceeding this target and normally most of the blocks as you can see here i have so this red line here let's say that's the target over time and these blocks they barely pass that that target but sometimes by chance some blocks have a much higher target and this is there is a like there's a relation so um blocks that have a thousand times more difficult difficulty than than the target are a thousand times rare more rare and so so the idea is to use these these really lucky blocks as a way of compressing the chain and he estimates the the proof sizes so let's say the idea would be just send all of the lucky blocks that have a thousand times more difficulty than the targets as a way of showing that this chain is canonical because and and a minor an attacker with lower mining power cannot generate so many superplugs and he uh so so proof sizes of including all of these here's uh vitalik estimates them to be around 25 megabytes and this includes all the the the super blocks but also a few thousand blocks at the tip of the chain and we might need to double this estimate because we also need to send the parent headers to be able to verify each block um so regarding security um nippo power is was out of advertised for constant difficulty chains um if the difficulty of a chain is constant over time then an another adversary with less than 50 mining power has a really low chance of being able to produce more silver blocks but in ethereum difficulty can be adjusted it can be changed over time by five percent over time each block maximum so a sketch for an attack could be that the attacker tries to bring down the difficulty um so that they can produce more superplugs but this can be easily avoided by modifying the fourth choice rule um at the tip of the chain as i mentioned before so these these blocks that have thousand times more difficulty they are kind of rare so um it could be that the last few thousand blocks um don't have any of these super blocks uh so we have two options either send all of the blocks after the last super block as part of the proof another one is to send super blocks of lower degrees or lower levels let's say lucky blocks that have 500 times the difficulty or 100 times and so on so in this talk we saw all the spectrum from full verification to zero knowledge proofs but i think in the middle between full verification and zkp's we can find some good middle ground uh flight client has good features it has multiple use cases but it has somewhat higher consensus complexity um eip 2935 has lower complexity it might need higher bandwidth um the algorithms that we discussed are haven't been formally analyzed so this is something that has to be done but it might surprise to replace chds and in future uh what what we plan to do is come up with more detailed algorithm for the super block approach and prototype them protect both the super block approach and the flight planned approach and compare them quantitatively for for more exact comparison so um that was it um there is also a text format for the same uh presentation you can find the link on this page and otherwise if you have questions i'll be available on the chat or on twitter feel free to reach out and i'll be happy to take any questions amazing thank you so much zina i think we have time to take one more question from the chat and i believe there was also some more discussion going on which you can then um maybe take offline after the talk but one question that we want to ask is from trx314 what are the implications of this architecture in terms of privacy for the users of the light client i don't believe there should be a negative effect on privacy uh for for any of these approaches in fact it might be better because we're trying to reduce this request a response uh mechanism so when you request something when you request a block that's an information being leaked to the full full node but when you make it broadcast only then the full node doesn't know who's getting this message uh disprove and what they're doing with it so i believe it might be better for privacy um but yeah i'll be happy to think more about the privacy consequences okay amazing um yeah i think there was some discussion going on in the chat also so maybe you want to have a look um and then we will wrap this up here thanks so much for joining us and thank you