Lightning Fast Light Clients for the Future of Ethereum by Zsolt Felföldi

[Applause] [Music] so so is this device service available times and I've been implementing this model in the GUI theory also called alias but it's also applicable in any model or any for any photos wetness those turns out to be workable than it could also serve as a proof of concept for our future Network protocols so what I was trying to realize is a truly needy surprise the service found the very presence of the server's can do resource allocation and vocalizing based purely on market signals can take care of their own interests and putting themselves against attackers at the course and force because and so the most obvious issues such a system has to solve is that in a peer-to-peer network promises are nothing forcible so anyone can get away at any point including server-side after receiving payment so we can have some kind of verification mechanism and then in this case in this followed this will look like so servers have to first provide the pre-service and after there's a high demand for the pre-service and try to touch the server they can start operating the money in order to also the market mechanism themselves are time dependent and what works on a longer time scale might not work people evolve the short of time still simply because the information that actors are trying to base the decision stone might need some time to become a reliable like service quality age and responsibility stakes and service difficulty measurements are very nice things and you just have to collect a certain amount of data in order to able to make good decisions and I have problems in not high-frequency trading which I do every day disconnect from any market fundamentals stuff that he provided activity bags to price fluctuations so this would also like to avoid a food price preparations because surprises I believe are practically meaningless on a net short enough time scale prestigious and so in order to make things a bit more stable and predictable in this talk I will show you how the server's camera but I happen to be to allocating their serving capacity and how science can do load balancing based on a server feedback and also the longer time scale can evaluate server performance and choose the best service for the money so for toaster let's look at how these servers and manage their own serving capacity and the response times servers so the server still have their own token accounting and so they they have been of service tokens which are meant to be based on the actual physical serving request and they should be unrelated to any market the prices or conditions and the universe the costs are always dominated in the service topaz and basically usually the server's can freely decide is the cost of any individual request but there are previously announced the maximum cost of is electric Rufus time and we also defined capacity as a service to answer spendable a time unit and we assign a capacity to each client which basically means a request rate limiting and we also set an upper limit on the total capacity of all connected clients and this is the drinkie goal of this is to avoid the transient overlords by which I'm in a situation where we have a lot of requests in the same time and the response time start to rise very quickly and so maybe set up some criteria for detecting this and we can maybe not always avoid this part they reduce its frequency of its consistently adjusting the total capacity llamas so the real frustration within method of attack in ESS for the price side of control and as I said it's based on the capacity to each client that also requests butter and the server to assist request it can remove the cost of the request from the buffer and also reach out to buffer at the rate that's proportional to the capacity and in every very bind and it also includes the interpreter tables and this is what the clients can use as a feedback for know that I'm saying because if they have multiple server connections I can always send a text request to a server but it may have the best value and yeah now a few words about how service tokens are being so so so basically we belong to a service to be able to sell some of them they have tokens in advance but not too many of them because the spending the selling rate of the tokens it's also limited and it is always the service interested in the answer there stability of the consciousness power of its own organs because as we will see later that the clients will pay attention to this and and the service will do the reputation it so what is a service should I do to do is limit the total outstanding about its service to ants by controlling the selling price of tokens so there's a base price and as issues Morimoto castle can arise of the total price if we are limiting the amount of tokens we should also enforce spending of little pants by sending an expiration time on them or by making them inflationary was some combination of these and this was important mention here that whenever a currency transfer is accepted by the server it's not automatically converted to service tokens that's something the client has to explicitly explicitly initiate and and this is also when the expiration starts to Kingdom so it's always optional to buy a significant amount of service tokens in advance that's an option for clients that has a national course but it also has a benefit one benefit is that they eat or is a further price to fluctuations of even more importantly that this is a commitment to spending the tokens and using the service in the near future and the server this is a very valuable information for the server and the server will deliver this by it not being they're more stable connections of how it's done so so we are going to the client connection priority model the service obviously the number of clients to be connected cycle there is limited so Victor have some had priorities and the private dividing using this model is a token balance / requested capacity and I'm not going to explain missing the nice property of this is that it rewards commitment commitment so the client promised to use the service in the near future that the server is to let the client use this service in the near future and another nice property is that it lets us integrate the free service very nicely and smoothly into the whole model and this is all something that already works in their big night servers that even plants we don't have a token palace they have a virtual negative balance which is associated to IP address also it's a expire this one actually over along another kind but so this is to ensure that three clients can it's also know the client who has used the service lesson recently and has a higher chance to connect so tree service is also important and the server also has to ensure that the free service is a regular did not always but regular regularly available for two reasons one of them is that this is what helps reputation building new customers and the other one is at the same condition that allows free service to be unavailable it also ensures that the service demands are all spendable in a limited time frame so there's another control mechanism healed that controls the base token price based on whether the service free service is possible or not if it is possible then it reduces the price and other I say it is slowly exponentially increases the base price yeah this is about it for the server mechanism and now let's take a look at the right hand side so this is going to be going to every individual here but there's a subjective value measurement from the find side which is ideally it should be a mirror of the server side token accounting so basically the clients will try to somehow put a number on how much service they receive and this is also based on serve the requests and currently capacities and it also modified by a service quality factor which is based on which response times and how response times are probably per serving but it depends on the expectations of response times which depends on price factors and everything so basically it's possible to if they find has to make a decision on who to pay for it can map out the whole available market as a price versus every expected response time and function which is nice and if you easy to understand for human users so if we have a regular groom and we have an expected response time then we can convert our quality statistics into a single scalar value and I'd like to mention here that the various constants can even about as a negative by for clients because we have to incentivize reliably with response times and this service value is what we kind started up trying to get all their money basically and finally there's the tricky part of this because if the fight wants to make a statement about who to pay for than what it really was like to do is predict the service value received after making the payment and before the next payment is requested so so theoretically if they can trust the server this is not so hard because we expect the service against purchasing power to be more or less stable and the client has an idea of how well your the service service depends were in the past and there's a token price at the moment so it should be predictable but of course the client cannot blindly trust any server so this is how the recognition building magnesium works we have three predictors we have a base value which is a very simple as paranoid and all uses by the things that the Defiant knows for sure so it's basically takes the service value received so far and the payments and so far and the payment expected currently and it just does a linear extrapolation which is which converges to something over the long term is not very good but also not suitable and as the trusted by a predictor it does what I already described it believes the server and this token accounting at token prices and the stability of these tokens and to make the final judgment there's a third a superb predictor which initially takes for it returns the predictions of the base predictor and the overtime is the trusted predictor process and they gives the better estimates of service value received after making a payment then it will allow more and more deviation from the whispered base with predictors value in the direction of the attractive predictors prediction and so this is this this allowed deviation this represents the reputation of the server and this job is going to be ruined if the server doesn't all these promises and doesn't keep its service and buy a device table and yeah I feel thanks so now just just just about few words about the current state of implementation and the roadmap so as I already said the most of the most of the components living material and I so far mostly focused on implementing the server-side because that's what the first that's what we first need in order to even start experimenting and recently and server India has been implemented it's going to come out in one of the subsequent get releases and this with this you can already play with the client priorities and you can assign priorities to your own or your friends or customers nodes and there's the outer conceal mechanism is working progress but I really hope I can finish it and we can release it and by the end of this year and this will mean that by the end of this year we are going to have a thin and fully booking payment enabled light servers and which anyone can start up and start earning money and on the tight side there's going to be some manual have maybe like a revised list for servers who we can pay for but the the client side side it's also already partially implemented and I really hope that by the middle of next year we are going I'm going to be able to show some results that you can try of course this is going to be an ongoing research and yeah so if you if you have any feedback contact me I'm going to they're pretty the community man's about the details of this model because I heard that I didn't answer and an advocate questions it is short talk but I'm going to put up to that when you documents to my github page and I'm going to announce them on Twitter and everywhere and I would really like to make this model usable vote for for going to even the Gateway plant and also for our future light bands of material - and that was it thank you for your attention one thread I do a mystery how the payments work well so this business model is so it had worked with any kind of payment technologies I was looking into using radar and now this whole team also has a base web protocol that's also a an interesting dimension of technology but I think we can even start is because I said simple payments which are really easy to do and yes also the model doesn't depend on the payment technology just service to testament and notes also every server has also spoken and they are only a country locally on the server and I'm not sure yet whether they should be tradable transferable that's what's that yes so the server will so if you stand either to a server or die or whatever but this are we want to accept that then we are going to have an ether or die or the server and as I said you have to explicitly say okay now I have eaten with you and I want to work some of it [Applause] you