Integrating Geth into the proof-of-stake light client ecosystem, light client summit

[Music] i'm going to talk about well where i i'm planning to take the goetherium light client how i want to basically integrate it into this new e2 beacon chain proof of stake ecosystem and well yes so basically uh yeah so what we have right now is this kind of ancient kind of still experimental alias protocol in ingot that versus proof of work and obviously this needs to be changed now and so uh i i have like a short term and longer term plans about this uh first of all of course i want to make a go ethereum light mode work with proof of stake and well the easiest way to do this is still to basically improve alias bring out the new alias version that somehow works uh together with the beacon chain and works uh with proof of stake uh also uh there's going to be some advantages of doing this in addition to the work because it needs a lot less bandwidth to sync the beacon chain and therefore maybe we can already instantly improve the server bandwidth availability problems that have been usually present with alias and uh later since since this is always already going to be a major overhaul uh i also have a plans to finally move away a little bit from this old client server architecture so like some data can be propagated through multiple steps if needed and yeah i will talk about that later more also since alias is based on this all the dev b2p stack i don't want to necessarily stick to that forever uh also now there's the portal network emerging and and and it has this uh very uh reasonable design with the with the utp over udp or disk v5 whatever but it makes sense i think for for for especially for state access it's uh it can be very good so so uh yeah uh over time we can probably move away from the uh def b2p stack also and and uh and so these are just the transport protocols it's let's just use whatever is more practical for everyone and yeah a little bit more about how this is going to be how beacon chain is going to be integrated into get so uh earlier we had the uh the light server which is a get full node and has all had all the data and the client just connected to it and that was fine if it happened and yeah now the now there's there's the beacon chain it has its own light client api which provides the uh sync committees and and and and and the the singer i mean committee updates and everything so uh one possibility here on this little drawing on the right side to so either to have every alias client to connect to an alias server through the dev ptp protocol and uh also somehow connect to a uh the like client trust api and maybe since already there are some some some connection policies and and and limitations systems uh in space in lds which actually helped quite a lot with the server server availability stuff and like having a different two connection models for one client would be like a problem usually so it's maybe easier and that's how i'm currently implementing this thing is that alias servers connect to their own so usually phonos will have a beacon node connected anyway and if they provide a light client api which i know that the low star or it does so i right now i'm experimenting with a loss test client but uh i know that the other kinds of implementations are working on this too so maybe at one point this can be properly standardized and everything but uh so thing is that uh somehow the beacon node provides an api and the alias servers will fetch the important data from there and for the time being yeah we take the new formats as is that everything and then encode it in rlp which is funny but uh if this can change later or whatever it's it's just more practical right now and it will be served to the earliest clients yeah as i mentioned uh there's also also like like advantages of this chain a change because earlier we needed to header thing to verify consensus and this was expensive both the cpu wise and also bandwidth especially bandwidth wise it was like almost 600 bytes for each execution header and and and if you wanted to sync up after several weeks or months of being offline then it was quite a lot of time and quite a lot of bandwidth and usually the connection was broken before you could even properly sync up so now you have to sync one sync committee which is about 25 kilobytes per 8k slot so it's basically about three bytes per slot to do this uh forward syncing and then there are the the header announcements uh signed by by the sync committee now these are beacon header announcements of course but the beacon header has the beacon state which has the reference to the execution header so yeah this is just a technicality but this can prove the also the execution headers and um yeah there are also the also new new new client modes become possible so earlier we just had a light server and live client and yeah we had a kind of unfinished ultra-light client mode also which didn't really do anything useful until now but basically what this this so proof of stake will allow us to make this make this work properly so so uh the so if you only want to be a client then it's going to be a lot cheaper also it's possible possible to run like the funnel server with a beacon not connected but there's it's also possible to basically be a light client on the beacon chain and run a full node of the on the execution layer which will allow the node operators to run get through node without a beacon node and basically get the new headers from from from the light protocol or well also it's a possibility to run a light client that's so with so a lifeline that doesn't do execution chain processing but uh it downloads all the uh blocks and and provides them to the previously mentioned four nodes and yeah a lot of combinations are possible and probably in the first iteration uh we want um like uh offer like millions of of of combinations of client modes because that would be just a chaos so we should probably test this and everything but there are new possibilities and we'll see what we can realize and what will be useful in practice now uh just a quick a few words about what this this design needs from the from the beacon node apis basically nothing really special so yeah it needs beacon headers the beacon head updates here i want to mention that in the current designs usually the uh in in each beacon and beacon block the last beacon header signed by the sync committee is included which is fine and this means that the vincon had a beacon chain api provides a signed header for the last slot which is kind of okay but here i would propose some improvements so it would be possible to basically be connected to the to the sync committee gossips all the time and and and gather all the all the other signatures and and continuously uh aggregate them and and basically provide a signed header as soon as possible which would probably be a few seconds after it was uh proposed so yeah so right now with the f with this first implementation we have one one block delay with the light clients but that's avoidable and uh yeah basically uh we need of course the the sync committee updates and some parts of the beacon chain but since the light server is uh constantly syncing from the the beacon node api we don't need to access anything that's old because i know that the beaconers usually don't store all the beacon states but the alias design won't need this because as soon as blocks are processed it will just fetch all the beacon state that's needed and store it locally at least the parts which will be needed for for for serving clients okay now i don't want to like go into yeah all the details with this but just uh real quickly so uh what what type of new data structures are needed uh to uh work with the work with the beacon chain so yeah obviously there are the sync committee proofs which are basically a beacon header signed by the previous committee which has a reference to the next committee route and ideally it is also like a finalized header so basically there's a there's a signed header that references the finalized header which refers to the next committee route and yeah so these are needed for the forward thinking obviously there are these signed headers which are propagated through alias and there are these previously mentioned parts of the beacon state that are needed so usually for each slot we need the this latest execution payload header data block hash value which references the execution header and yeah for some reason the latest block header is also listed because because internally the headers are the slots are referenced by state route but yeah that's just details and there are some fields that are only needed for recent slots for that because uh we i will alias only uses this historic roots and state rooster structures because from the latest latest beacon header you can only prove the latest exact header and i want to get to stay fully functional which means it has access to it can prove earlier uh blocks in the canonical chain that might be necessary because you want to find another transaction and if you want to find the transaction by hash then the server can prove that okay it's included in this block and it's canonical and for this we are storing basically basically get internally updates this uh all the state route trees merkle trees and uh and and and and uh stores the references to the root hashes of these trees from the beacon state and if if it needs to prove an old block by by number then basically it internally finds the the slot the beacon chain slot where it was referenced and and gives the proofs to that through this history he can stick to structures and then proves the actual execution header from that so yeah and also there are this uh there's this init data which is needed for starting uh from a checkpoint and so these are only stored like once per epoch uh similarly to how it works with the beacon chain clients and yeah so this is just basically the genesis data and and and for data and and and the stream committee references to start with and yeah there are always these trees that i mentioned that are internally updated the historic trees and yeah that's what is needed for serving a fully functional get light client now i also mentioned that um i also i also want to kind of move away from the old client server topology because uh so earlier i had this idea to fully rely on incentivization monetary incentivization and now i don't think that's such a good idea it might be useful for some use cases but it would be better to just be a bit more flexible and also since now lots of new client and server roles are possible it just makes sense to make the new version of lds ls5 kind of be able to move in both directions and and yeah so uh so so all this all this all this beacon chain data uh can be propagated in a way that they so the server can serve it in a form that another node can also use it for serving for the clients and yeah the central part of the whole proof-of-stake proof-of-stake logic which is the sync committee thinker and the signed head propagator that's also designed in a way that it doesn't even really care about whether it's running in a server or client any node can basically propagate this data to further nodes if the nature of the connection allows this and yeah basically that's all about it and again i don't want to like go into the fine details but just to give a quick overview so this is this is this this is what the new uh alias requests are so there are some requests for uh advertising like new uh committee proofs and and transmitting them so uh and also for for for propagating the signed beacon headers and yeah there are the get beacon slots and beacon slots uh request pair is for propagating the data that is uh that can be used for serving further clients and an exam an example of that is this drawing in the middle which is basically uh so from from the recent state route of the recent header uh through these state routes or historical structures you can prove a we can prove a range of uh state routes earlier state routes and some fields of the the beacon state are transmitted uh depending on where it is in the chain uh if it's recent than than than all the data is is transmitted like this this is historical references and everything if it's older than only the exact header and like whatever is needed for actually approving the exact header and for once an import so the init data is transmitted here so yeah this this data structure i just talked about and there's the get exact headers and exec headers uh request pair which basically transmits so this this this so all of this what this drawing show are basically ssd multi-proofs and yeah even when proving execution headers now we used using as i said multi-proof to prove in the simple case like on the left side there's like just we've proved from starting from the state route of the beacon header this latest execution playload headers block hash and from there we also transmitting the same exact headers response we transmit the execution header and from there on it's the same story as like with all the alias versions so the execution data can be inserted from the exact header and on the right side drawing this there's a longer proof chain which is an example for approving an all the exact block execution block so from the state route there's the historical rule structure and then there's this historical base structure which proves another order state root structure which is contains 8k 8 000 all state routes and yeah from there we prove an old execution header so yeah this is basically the kind of proofs we provide now and yeah we are almost done so uh and quickly about uh like future plans so so propagating the state is kind of easy because it's linear and and it just adds new data every block and and and yeah so it's going to be even cheaper and then even the topology will be better so hopefully there won't be any more bandwidth problems with the chain but for heavy state users i have plans to integrate the portal network state protocol maybe later also for the chain and everything so yeah it's already talked about this but uh yeah so so this so uh we can we can we can we can we can also like slice up the chain and and and the full notes can can propagate uh like sizes of the of the i mean not the state slices of the state to the portal network uh and yeah basically over time probably it will be also fully inter areas uh get get litecoin will also be fully interfaced to the portal network and yeah basically that's it thank you [Music]