Networking in light clients, light client summit

[Music] so i will talk about how to bring this beacon chain light client data onto the network like the previous presentation showed how to access it over this rest api and just to briefly understand what we are actually trying to put on the network a couple key concepts that we need to understand like everyone knows the basic time units of the beacon chain it's this 12 second slot and 32 slot combination of them is six and a half minute is an epoch so what altair introduced last year is the concept of the sun committee period which is like just a bit over one day and this is the period at which the student committee gets reselected so in a block currently we have a proposer who signs the block with a signature and the signature is for the current block and then the other ones can use the signature to verify that it's indeed coming from the proposer and they also have to verify the entire block and then they can apply it and attest to it so the problem is you need to know the public key of the proposer to verify it and the like client doesn't have that so the live client needs an alternate mechanism to verify blocks and this is where the sync committee comes in it's an additional signature that signs the previous block and they also not just signed the block randomly but they also confirmed that they actually did the verification so if this string committee signature if there is like a higher than a two-third participation the idea is that because it's a blockchain you can trust the entire chain back to genesis from the previous block so there is a specification on github in consensus backstreet but that sort of describes the concepts how a light client can use this in committee signatures to um sync with the network but the problem is that specification like you cannot just put those structures on the network as is like there is a lot of stuff missing and also this rest api from loadstar did a couple changes to it so i will also have to do a couple changes here on the slides for the network presentation so this data here we want to put it on the network so at the very basics uh we need like this signature block a tested block and put this in a in an object so we have this optimistic light client header update which contains the signature and some information about if it's from the current period and the next one and the previous a tested block with this parent root signature that we have seen before so the problem here is still the light client needs a way to obtain this the student committee that is signing this otherwise it's the same public key problem so there is this concept of full light client updates that also include the next june committee um with a miracle proof inside the structure so as long as the light client can obtain any light client update per day like persian committee period they can follow this next twin committee chain to verify the next one and the next one there is still the problem at the start of each sync committee period that is sort of unclear which of the forks will become the finalized one so there can be multiple next in committees um they only find like you only know that it's the finalized one once you have at least one finalized block in a new period so there is also this concept of um including the next gen committee from a finalized block and then you have two merkle proofs like one of them that puts the next gen committee into the verified block and then you have to verify this finalized checkpoint pointer from the previous block to the finalized block and then you have to verify that this um yeah also the the signature of this uh syncomity for the attested block so this structure is the full one that is also in the spec in this way and i just like use this highlighting to to make it clear like where the merkle proofs are rooted because that's always like one of the question where it's unclear like the next twin committee is is rooted in the finalized book to solve this problem at the start of a period so combined with the other structure like this optimistic like client update there is still one piece missing which is like the initials in committee and for that one you usually configure the light client with a trusted block root it can be any block root of the last week's objectivity period would be best but you can also use an older one and that one can be used to obtain the initial synchromity and also the header to verify that it's in there so these are all the structures that we want to put on the network and then a light client themselves can use this to sync from a trusted block root to this light client bootstrap with the initial sync committee then they download one full light client update per period with the next in committee until they are in the current period then they get a final one to get to the latest finalized head and then they can just follow these optimistic light client updates to keep track of the latest slot latest slots parents so to say you cannot get to the latest slot at this time so the problem with light client data is servers do not really benefit from it usually so it's difficult to convince servers to serve it so what's happening here is that those structures are really small like 25 kilobyte for a bootstrap or for an update and the optimistic updates are just 300 bytes so it's a very small network load and then there is the problem that you need all of these merkle proofs about the historic data which is a bit difficult to compute on the server so you should cache them and this is about six megabytes for half a year and it's bounded by half a year because the older data can be pruned so the servers can serve this data for free it's just static data for the history it doesn't change anymore and the latest one they have already in memory anyway it's just a subset of the blocks there is no proofs in it so yeah anyone can surf this protocol and then what i did is like i made a pull request to the consensus specs that basically puts this on the p2p layer so it's just like the four requests you have the bootstrap request you can get the best uh best light client update for each period you can get the latest one if you want the latest finalized head and then you can follow these optimistic updates to keep track of the latest head so this is the pull request here if someone wants to comment on it or review it it's welcome actually this is already deployed on pratter and kiln by nimbus notes so the only change is that you use version 0 here and this underscore v0 suffix for the gossip subtopic so this can already be used for experiments and it's fully functional this rest protocol that was mentioned in the previous talk from lodestar is also compatible with this the naming is a bit different so what's called snapshot in the load star protocol is this bootstrap the committee updates are like the full updates the head update is is the optimistic like client update but besides these terminology changes that still need some synchronization it's functionally the same thing it's the same structures conceptually it's the same so there is no additional concepts introduced here it's just putting this same data onto lip2p so now how is this useful like what can a light client do with it and there is this additional fork that comes up soon like called the merge and this incorporates an upgrade to the beacon chain called bellatrix and what it does is that it sort of has it links the execution layer and the consensus layer together using this api like the execution api so um during this uh like the the beacon uh layer like the consensus layer takes over instead of the miners that such as blocks it's now this uh consensus layer so there is like the the el can no longer sync on its own because it needs like a source to the latest blocks um to to use this existing efficient syncing mechanism but the problem is also the consensus layer needs the el to verify blocks because they contain an execution payload so the cl needs a synced execution layer and the execution layer needs the latest blocks to to be synced so right now there is this proposal called the optimistic sync and in there the cl starts by syncing blocks but they only partially verify them like they skip verification of this execution payload and then they pass it to the el and then the el can use whatever fancy mechanisms they have to sync to the latest head and then you can verify the latest execution payload and if destroying as well the entire thing before is also valid again because it's a blockchain so the problem here is there have been some complaints about the complexity of this because it introduces this concept of partially verified blocks and the lite client can help with it so how can it help with it so what it introduces is this fast access to the latest header so you can get the latest finalized header and the latest optimistic header and from that you can just download the latest and blocks and pass them to the el and then it can sync and from then on you can just verify everything so much simpler you get the happy panda here so what can also be done like beside offering a replacement for optimistic sync is that you can use you can run an el without a cl now because the light client itself is sufficient to sync the el and you get access to the finalized and optimistic eth1 state routes as well through merkle proofs and the only thing that you cannot do with this is use the current head because you are always one behind and this also means that you cannot really follow the validator duties with a light client because um you need access to the shuffling and also the current block like yeah the student committee always sends the previous one so to the other side like what can happen is can we run a cl without the nia like yes so you can also use this to just trust the latest finalized head and then use dislike as your trusted checkpoint and sync backwards from there so in this situation you can get up to speed much quicker because you no longer have to verify the blocks fully you only have to verify the proposer signatures so you can get up to the current head very quickly if you if you initialize using this live client sync protocol this is useful like if you want to swing from the altair start or if you want if you are offline for a couple days you can get get the latest head very quickly and as soon as you are there um you reconstruct the entire state and think you can do full validator duties if you also have a cdl um security wise it's very unclear like how to judge it because it sort of depends like how likely it is for the student committee to accept bribes so but at the very least there is no additional failure modes being introduced so if the student committee somehow convinces you to a incorrect head the worst thing that can happen is that you get a beacon chain notification on your phone that says that you are no longer attesting to the correct chains like me standardization and then you just do whatever you already do when this happens you just resync without without this feature the same as if you start from outside the week's objectivity period which is only like two weeks it can also happen the exact same thing so to summarize um the light client data these bootstrap the updates are very small objects anyone can serve them they can be put only p2p and rest i i heard that there is also like a jrpc one from prism i think they can also be put into the portal network relatively straightforward and the use cases that we get from this is that it is a solution for the optimistic sync we can run standalone els without cls and we can accelerate the cl sync in case of down times or syncing new nodes and we can get to the validate is much more quickly so this is the discord if you want to discuss this and also the other specs from before the qr codes are just linking there thank you [Applause] [Music] you