Progressing toward the Ethereum Light Client

Transcript

[Music] I've been working on the like client implementation and in this presentation I would like to talk about how far we have already progressed with that and also uh discuss the uh future uh ways of uh development concerning scalability security and decentralization I am proud to announce that we already have a proof of concept implementation of the light client protocol as many of you probably already know a the purpose of a light client is to Pro provide safe access to the

ethereum network without having to uh download and process every block and uh keep and update an entire copy of the state locally uh for all these purposes we have developed the uh last protocol uh it's a the there's a topology shown on in the slide uh which shows that uh uh just the blue diamonds who represent traditional full notes and the green diamonds who are light notes connecting to them and uh and uh the green light notes are downloading only block headers as each new block appears in the blockchain which is a uh lot less Network traffic

uh than downloading entire blocks and uh they only uh download uh block and state data uh as it is required by uh the applications uh this so This protocol is for for for on demand retal and block and state data and uh also uh it can uh relay transactions to the E consensus Network because the L network is uh somewhat separated from the from from the consensus network uh the full nodes definitely support both e and less protocol serving the light nodes and the light notes are only communicating with with the uh last protocol uh this structure is uh working

and it is uh uh quite efficient at a with a low number of light nodes but uh as the network grows we we will come into scalability and centralization issues because as you can see in the picture uh light not currently can only connect to full noes and uh uh this is also both a performance uh battl neck and uh after some time even uh a can be a security uh issue so uh it would be beneficial if we uh consider consider uh serving serving light the service that if uh light notes could become uh providers of the service

too uh if we are talking about centralization problems in the context of a light client uh we have to address two important questions one of them is the concern of security uh how can we uh trust our headers because uh the light cents work in a way that uh for the patri structure ensures that if we download any block of State data we can check its validity by uh by checking a mer proof and uh and uh checking it against the root hashes found in the block headers so if we have correct headers we have a secure access to the network but as we are not processing light noes are not

processing the blocks they cannot directly check the validity of the headers so we definitely need some security uh measures to prevent attacks uh one obvious way is uh checking the proof of work and later proof of stake found in the block headers uh which makes it harder and more expensive to forge false blocks or headers uh proof of stake will definitely uh provide a better level of security in this aspect but uh proof of work will also be sufficient even uh and if we can also incre increase its security if we de demand a few confirmations before we accept each other we can also increase security by

fetching headers from multiple peers preferably randomly selected peers and only accept headers as part of the canonical chain when we have received them from the majority of of our peers the other question brings us to the main topic of my presentation the efficient uh distribution uh of uh the blockchain the block and state data uh and the the uh general idea about this was originally that uh uh the light no should collectively run a DHT Service uh either swarm or ipfs or whatever and uh and and store

the state data in the DHD uh this approach is demonstrated on this next slide where uh one node shown on the left tries to uh do a uh uh State retrial he wants to retrieve a key starting with B4 F3 whatever ever uh he once needs to retrieve the the state TR node take the hash from the element B of the of the node and then use it as a hash and retrieve that node and uh sequentially retrieve retrieve try noes until it finds the final node which is the value it is looking for uh there are

lot of other light notes shown on this picture because if we are putting the state on DHT well dhts use some uh most dhts use a the So-Cal cadamia structure which is a great and efficient DHD topology both swarm and ipfs use it and uh uh it uh requires uh uh uh nodes uh to access a few intermediate other nodes before before finding the node that can serve the data they are looking for they are getting closer to the looking uh the address they are looking for and even closer and even closer after some time they're finding the data so uh this DHD approach is great it has one minor uh drawback that uh ad DH look up is not

not particularly fast I don't want to give any estimates of how fast it is but uh it it takes some time and uh it is usually not a problem with a general purpose data storage application where we if you are looking for lot of small pieces of data you can usually do that lookups uh those lookups in parallel but this is not the case with the tri lookup because you only get to know the hashes sequentially so uh a state lookup could uh take pretty long uh well uh so uh to address this problem uh let me present a an an alternative uh approach which is a which is quite similar to the DHD approach actually and it can use much most of the mostly the

same same code base is just a slight modification but a great Improvement in efficiency see so uh while in a DHT uh nodes each node is assigned a range of hashes and stores data whose hash falls into into that range we can uh modify this approach to be more uh State try specific and uh assign each node a range of the state Keys State addresses so uh basically each Pier uh would uh store and constantly observe and update a slice of the state basically technically few adjacent sub trees which

is uh quite uh efficient in terms of storage and updating uh and the advantage of this approach uh is uh pretty obvious because these notes can be organized in a cadamia table the same way the DHD notes can be organized basically with the same code same same implementation and uh it it only takes one uh one Global lookup which is expensive to uh to find a node who can serve us an entire mercur proof which is basically uh all the nodes starting from the state route up to the value node

this uh this picture shows uh two such nodes uh uh one of them is observing the KE range which is B4 C to b4f the other one is observing the right one is observing uh B e0 to B E7 prefixes and this next slide shows how this approach actually works would work uh each uh each node uh uh as as new blocks blocks appear in the canonical chain each uh each peer can uh update their part of the part of the try from a

node who is observing the same or larger uh key range uh and in this uh aspect full nodes are uh are are nodes who are observing the entire entire state of course but even light notes can choose to observe the uh the entire state but not process blocks just downlo states there is a a big advantage of this this approach in addition to increased performance uh which is the fact that uh if you are updating your try downloading the new TR noes that the uh that exist in the new version of the state in that uh slice of the triy uh you can exactly know when you have red all those uh all those

nodes uh this is basically similar to uh checking downloading and checking a Merle proof it's just uh works for an entire range of keys an entire sub tree but it can be similarly checked against the state rout found in the block header this is big this is a big Advantage because uh this way uh we can easily uh measure the equality of the service if we consider serving uh either sub trees or individual keys which is well which is a service and which eventually uh no will be paying for then it is uh it is very beneficial if he can exactly measure its uh it's it's uh this the value of the service

the quality of the service and this is uh especially beneficial for smaller ndes uh because uh uh if they are choosing uh a key range that is not yet so heavily served they can provide a service that that is just as valuable as the service of the full notes of course with a smaller volume and uh uh I so far I have only talked about uh the uh distribution and storage of the state and we we also have to uh uh

made make the the the the actual blockchain accessible which uh includes the uh transactions and the receipts belonging to those transactions for each block this is a much easier problem than Distributing the state for this the the uh the traditional DH approach is just as efficient as as any but uh maybe if we we we uh we already have uh have peers uh who are who who have ranges assigned to them uh it it is it might be beneficial to store every transaction and especially rece it uh by uh referenc by the block block hash of the block

they are belonging to because uh if we are uh uh processing logs yeah SL cents definitely need to process logs efficiently uh then then log processing consists of checking Bloom filters and if we are uh finding a positive match we have to download all the receipts belonging to a to a block so uh storing storing the the the receips belonging to one block at one place might be a good idea uh and it is also uh worth mentioning that uh uh the relaying of transaction transactions uh can be uh how how how we

how we should approach this problem in a network where we have a lot of light nodes uh if we have much more light noes than full nodes which will hopefully be the case in a healthy network uh we can um we we will probably have to propagate every new transaction to the Network through multiple multiple light nodes uh because most of them won't have direct access to a full node and if we do that it it would be beneficial to demand that every new transaction is propagated uh through the peers whose address ranges include the account that has signed the actual transaction the uh it is it is very useful because this way every every propagating every forwarding peer can

check the validity of the transaction uh because they have information about the account that has signed it and the checking the validity mostly consists of checking the available uh funds uh of the the signer and uh and the transaction nors so if every propagating light note can uh uh both check the account balances and nones and also do some filtering and ordering by the gas price of the uh by the transaction Creator uh this this forms a very effective spam protection for the from the consensus network uh by only forwarding

transactions to the main Network which will probably be actually included in the in the canonical chain and uh finally to uh conclude my uh presentation uh I would like to to uh uh talk about our future B uh give a quick road map of uh of of of of of the future developments as I currently see it we have planned several stages of release uh the first stage uh which is which should hopefully be ready pretty pretty pretty soon uh may be released in our next version of the go etherum client we

already be able to uh retrieve data on demand to the first version of the last protocol uh right now only from from Full nodes and probably also be able to relay transactions uh this will be a more or less usable light client but uh full functionality will be reached at stage two which will also be able to process and filter logs and uh probably the uh multi sampling header retal will also be included which is what I talked about before uh fetching headers from multiple PS to increase security uh this release will uh still have uh uh will still have

centralization issues with very great networks but for for the time coming I think it will be it will be quite sufficient and uh in the subsequent stages of uh development uh we should definitely address the scalability issues uh it is uh it will still it should still be up for discussion whether we try to go with the regular traditional DHT approach or the uh uh State splitting by by by state Keys approach whatever we have to we have to uh develop a distributed service which all which which also includes a simple microp payment system and for this purpose we can probably use the So-Cal

swap protocol swarm counting protocol which is a a very simple but very useful uh uh useful uh kind of payment Channel implementation that is used by swarm and uh we can also use it for for like client services and uh by uh when when the uh development of developments of the proof of State consensus protocol uh Advance we can also uh uh employ those mechanisms uh so basically porting the light client to proof of sake will provide a much better protection against uh uh against fraudulent nodes and the Cil attacks basically it works as a

reputation system because nodes with a stake that they can lose by trying to attack it it it it it gives them some kind of reputation and definitely makes attempted attacks more expensive so by the time uh uh we we will reach the point we can switch over to the proof of the consensus consensus protocol uh we will hopefully also have a massively scalable and and secure light client Network too and I think this is all I could tell you about this these uh developments in 20 minutes so thank you for your attention [Applause]