Building The Light Client Ecosystem - Zsolt Felfoldi

okay hello everyone I hope you're all really excited to hear the latest news about the light client well the good news is that it's already in public beta testing stage we are behaving it's being prepared for the official release if you would like to try it I will show the necessary links at the end of my presentation yeah if you haven't tried it yet the first thing you will notice is that it syncs absolutely fast this is of course mainly because it doesn't have to process state transitions just download and Jack headers processing headers is a lot faster than processing entire blocks our current implementation can process up to five to ten thousand headers per second on a good desktop computer to improve sinking even further it is possible to start sinking from a trusted checkpoint which is represented by the root of a mercury containing all previous block hashes it's called a canonical history this structure also allows to access all the headers that hasn't been downloaded during initial sync which could be useful for searching for old logs or accessing all transactions currently there is such a checkpoint hard-coded into into the client but in the future if we can make this these checkpoints or some equivalent information a part of the consensus then it will be possible to obtain these checkpoints from the servers in a safe and trust this way in addition to a fast thinking another important to feature of the light client is that it has generally low resource requirements since everything can be flashed on demand the database basically acts like a cash it can be kept really small memory requirements are also significantly lower than with a good foo node mainly because we don't have to process entire it this aspect of the get implementation can be improved even further and still it provides an aqueous interface that is compatible with the existing phone or the interface it's not perfect yet but it's it can already work with mist hopefully tomorrow you will also see a nice missed demo using the lifeline by Alex several people have already successfully tested in on smaller devices to this picture is from Martin Brooks syncing with an int'l Addison and this screenshot is from a Raspberry Pi using running mr. using the light client got to see of John Gary's who by the way also donated a lie server to help the public testing and like other community members provided a lot of useful feedback during testing he in addition to basic protocol functionality another important question is whether all of this can work in a large scale with good performance the basic client strategy is simple it always tries to have a few active server connections selected randomly from a suitable pair set whenever one of them seems slow or unresponsive it drops it and looks for another one servers they can take care of themselves by limiting the bandwidth spent benefit of clients and dropping also dropping them if necessary mmm they so they limit the time and resources spent on on on serving serving clients for limiting client bandwidth oh we needed some smarter mechanism than simply delaying request replies because that would ruin the user experience of the client which depends heavily on so it quick survey responses this is why we created client side for control which is a simple feedback mechanism Thank that can tell clients when they can send the next request so that the client can better distribute their requests among the few server connections they have if they send a crust too early they would get the immediately disconnected they shouldn't do that but these strict rules have the advantage that requests never get queued up on the server side and therefore they can be answered immediately this mechanism can ensure a good distribution of server load throughout the entire network but we also need some market forces to incentivize the running of good servers in theory micropayment is the ideal way to incentivize high quality service and responsible use of resources but on the other hand which we should also take into consideration that the requiring payment for all Elias requests would seriously hinder the adoption of the protocol and also a limit its usefulness you couldn't even sync up to make your first payment using a lifeline and then so another important question is whether it is possible to create a an ecosystem we're both free and paid services have their place and purpose fortunately I believe the answer is yes with a service like this demand changes very rapidly while the available server capacity is a change is relatively slowly so if you want to provide high quality service you have to have a lot of reserve capacity and you easily get a low utilization ratio which means of course that the servers can is sad the remaining capacity at a lower priority and a lower price so basically our model is that clients are buying priority from the servers and on the lowest possible priority level if the service still have some free capacity they can basically give it away for free which of course still wouldn't insure that they actually do this but we angry at the service model and they will have a natural incentive to do so pre-service is a good indicator of reserve capacities which are necessary for providing a high quality service that is actually it is actually worth paying for so in our model pre-service can act as an as an advertisement and also as I protection against the scam for clients so so the it can protect them from for from paying for and then getting those service in return so the basic client strategy should be that even if you are willing to pay for services if if you find a new server through peer discovery first you always evaluate it for free collectors and statistics about availability and average delays and then if the statistics I'll acceptable then you can start paying for it and I wanted to talk about the new discovery protocol we're working on unfortunately there's no time for many details it's a new feature is an advertisement in a feature where nodes can advertise their capabilities they can a big multiple category identifier or so-called topics and advertise them under under these categories and of course they can also look for notes who advertise themselves under certain topics of course one of such topics will be light server and finally I would quickly like to talk about one of my future development plans which could greatly enhance the performance and reflective respective flexibility of the light protocol by allowing clients to run complex operations on the server side in theory basically a suckfest can provide any information a client needs but if they want to evaluate something more complex like and a contract the accessor function that accesses 8,000 state entries that would also mean a thousand consecutive arias requests which would take a very long time usually evaluating complex data structures on server side could be orders of magnitude faster and I don't only want to evaluate contact mashup of contract functions I would like to create a universal virtual machine that can access anything anything from the block chain including block headers transactions receipts logs everything and allow clients to run any code in such a virtual machine on server side so that basically they can ask any question about the blockchain that a foo not can possibly answer of course if we are running code on the server side we have to make sure that the client can somehow know that they are getting the correct answer and there are two possible approaches to achieve this and I would like to make both of these options available for clients to choose according to their priorities one of such one of these approaches is a that when a certain in the server runs a virtual machine code it collects all the data it accesses and creates more proofs for all of them and returns this proves to the client so that client can with one request and one imply the client can rerun the entire function and have other data available another approach might be useful than processing large amounts of data and it's a more generalized option computing approach very much like what a crystal was talking about yesterday basically it's about server signing statements saying that I guarantee that running this function with this block chain as an input returns in this many clock cycles with these results the client can ask multiple randomly selected servers to answer the same question evaluate the same function hopefully all of them were returned the same and then the client can believe it in the unlikely case when they return different results of course at least one of them will be false and the client should post the statements to a judge contract which can which will then request the intermediate states of off of this vm execution from the from the signing parties until it finds the one single instruction that has been executed differently and punish that one which has been lying by taking away a security deposit this both of these approaches have their advantages and disadvantages but whichever one the clients are choosing this remote virtual machine execution he will basically be the ultimate flexible Elias request which can minimum emission minimalize any gap between the capabilities of full and light plants which I believe will bring us closer to realizing our original vision we had with athyrium so we already and thank you for your attention and if you as I promised here are some links there's a gator channel you that I am / 18 / light client and this is the main forum of the where you can follow the developments you can ask questions and whatever news I have I always posted there and there's also a wiki page with with with the instructions for two to try the current beta version so please please stay tuned for much development in the near future I was so lot of documentation is coming soon because another good news is that now both parity and C++ wants to implement the light protocol so of course we have to improve specifications better because so far I have concentrated mostly on on code thank you