 I'm going to present you an instantization model for an estimate for a build-to-build purpose, client-to-server relationship like purpose, and live client purpose. Talking about the live clients, most people usually think about end user use cases and very lightweight use cases, and I believe in the near future, we work towards scalability. Even our core network protocols and systems will depend more and more on some kind of live bank protocols or asymmetrical protocols, so having a reliable solution for incentivizing them is really important. So I've been working on a model that is capable of long-term trust-building, with clients and servers in a totally decent, right-and-trust-less environment, and can incentivize predictably service availability and consistent response times. And I've been implementing this model in the GUI theory, like client protocol, also called alias, but it's also applicable in any model or for any protocol, and when this turns out to be workable, then it could also serve as a proof of concept for our future network protocols. So what I was trying to realize is a truly desensitized service cloud where clients and servers can do resource allocation and multi-lensing based purely on market signals and can take care of their own interests and protect themselves against attackers and frauds because no one else will look for them. And so one of the most obvious issues such a system has to solve is that in a peer-to-peer network, promises are not enforceable, so anyone can get away at any point, including servers right after receiving the payment. So we have to have some kind of reputation mechanism, but in this case in this model this will look like so servers have to first provide a free service and after there's a high demand for that free service and clients try to transfer the server, they can start offering the money in order to get priority. I also wanted this model to have a low network overhead and ideally it could even be workable with any kind of payment technology, including on-chain payments, but of course with a more advanced payment technology. So the best way to understand this approach is through the timing. The timing used to be key on any market and this one is no exception. After all, I would like to talk about the importance of your response times, but also the market mechanism themselves for the time dependent and what works on a longer time scale might not work equally well on a shorter time scale, simply because the information that actors are trying to base their decisions on might need some time to become reliable, like service quality and response time statistics and serving difficulty measurements is a very noisy thing and we just have to collect a certain amount of data in order to be able to make good decisions and I would like to run into problems similar to high frequency trading, which I believe can really disconnect from any market fundamentals and disrupt any meaningful market activity by extreme price fluctuations. So in this model, we would also like to avoid the high price fluctuations because the prices, I believe, are practically meaningless on a short enough time scale and so in order to make things a bit more stable and predictable in the stock, I will show you how servers can plan ahead a little bit with their allocating their serving capacity and how clients can do load balancing based on server feedback and also on a longer time scale how clients can evaluate server performance and choose the best service for their money. So for first, let's look at how the servers can manage their own serving capacity and ensure good response times. Servers... Oh, sorry. So servers have their own token counting and so they have their own service tokens which are meant to be based on the actual physical serving difficulty of request and they should be unrelated to any market prices or conditions and the request costs are always illuminated in the service tokens and basically usually servers can freely decide the cost of any individual request but there are previously announced maximum cost limits for each request type and we also define capacity as service tokens spendable per 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 the goal of this is to avoid transient overloads by which I mean a situation where we have a lot of requests in the same time and response times start to rise very quickly and so we set up some criteria for detecting this and we can maybe not always avoid this but reduce its frequency of its occurrences by finally adjusting the total capacity allowance. So the request rate limiting method applied in LAS is called the client-side fall control and as I said it's based on the capacity to each client and also request cost buffer and the server when it receives the request it can remove the cost of the request from the buffer and also reach out to the buffer at a rate that's proportional to the capacity and in every reply it also includes the current buffer status and this is what the clients can use as a feedback for local balancing because if they have multiple server connections they can always send the next request to the server where they have the best buffer value and now a few words about how service tokens are being sold so basically we really want the servers to be able to sell some of their tokens in advance and not too many of them because the spending rate of tokens is also limited and it is always the servers interested to ensure the stability of the purchasing power of its own tokens because as we will see later the clients will pay attention to this and the servers will do the reputation if they are paid to do so and what the servers should ideally do is limit the total outstanding amount of its service tokens by controlling the selling price of tokens so there's a base price and as it issues more and more tokens it can rise up the token price and if we are limiting the amount of tokens we should also enforce spending of the tokens by setting an expiration time on them or by making them inflationary and it's also important to 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 initiate and this is also when the expiration starts ticking so it's always optional to buy a significant amount of service tokens in advance for clients that has a potential cost but it also has a benefit one benefit is that it avoids further price fluctuations but 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 very valuable information for the server and the server will reward this by granting more stable connections and let's look into details of how it's done so we are now looking into the client connection priority model obviously the number of clients to be connected simultaneously is limited so we have to have some kind of priorities and the priority value we are going to use in this model is token balance divided by requested capacity and I'm not going to explain this in detail now but the nice property of this is that it rewards commitment so the client commits to use the service in the near future then the server commits to let the client use the service in the near future and another nice property of this is that it lets us integrate the free service very nicely and smoothly into the whole model and this is something that already works in the Goitirian light servers that even clients who don't have token balance they have a virtual negative balance which is associated to IP address and also it's expired exponentially over a longer time but so this is to ensure that free clients can so the client who has used the service less in the recent week and has a higher chance to connect and so free service is also important and the server also has to ensure that free service is regularly, not always but regularly available for two reasons, one of them is that this is what helps reputation building and getting new customers and the other one is that the same condition that allows free service to be unavailable it also ensures that the service clients are always spendable in a limited time frame so there's another control mechanism here that controls the base token price based on whether the free service is possible or not if it is possible then it reduces the price and otherwise it slowly exponentially increases the base price and yeah this is about it for the server mechanism and now quickly let's take a look at the client side mechanisms so this is a complex topic and also I can't go into every little detail here but there's a subject value measurement on the client side which is ideally it should be a mirror of the server side token accounting so basically the clients try to somehow put a number on how much service they receive and this is also based on server requests and guaranteed capacities and it's also modified by a service quality factor which is based on response times and how response times are converted to server it depends on the expectations on response times which depends on price factors and everything so basically it's possible to if the client has to make a decision on who to pay for it can map out the whole available market as a price versus average expected response time function which is nice and intuitive and easy to understand for human users so if we have an equilibrium and we have an expected response time we can convert our quality statistics into a single scalar value and I'd like to mention here that the very long response times can even map out as a negative value for clients because we want to incentivize reliably good response times and this service value is what the clients are trying to get for their money basically and finally there's a tricky part of this because if the client wants to make a decision about who to pay for then what it really would like to do is to predict the service value received after making the payment and before the next payment is requested so theoretically if we can trust the server this is not so hard because we expect the service token's purchasing power to be more or less stable and the client has an idea of how valuable the service tokens 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 reputation building mechanism works we have three predictors we have a base value predictor which is very simple and paranoid and only uses things that the client knows for sure so it basically takes the service value received so far and the payment sent so far and the payment expected currently and it just does a linear extrapolation which covers just something meaningful over the long term it's not very good but also not cheatable and there's the trusted value predictor which does what I already described and it's stable with the server and the token accounting and token prices and the stability of the tokens and to make the final judgment there's a third ensemble predictor which initially returns the predictions of the base predictor and over time with the trusted predictor consistently gives better estimates of service value received after making a payment then it will allow more and more deviation from the base predictors value in the direction of the trusted predictor's prediction and so this allowed deviation this represents the reputation of the server and this is what is going to be ruined if the server doesn't hold its promises and doesn't keep its service token value stable and I have a lot of time so now just a few words about the current state of implementation and the roadmap so as I already said most of the components or many of the components are already implemented in Ethereum and I so far mostly focused on implementing the server side because that's what we first need in order to even start experimenting and recently a server API has been implemented it's going to come out in one of the subsequent get releases and with this you can already play with client priorities and you can assign priorities to your own nodes or your friends or customers' nodes and there's the automatic token mechanism it's working progress but I really hope I can finish it and we can release it by the end of this year and this will mean that by the end of this year we are going to have a fully working payment enabled light servers and anyone can start up and start earning money and this still means that on the client side there's going to be some manual help needed like a vitalist for servers who we can pay for but the client side management project it's also already partially implemented and I really hope that by the middle of next year we are going to be able to show some results that you can try because this is going to be an ongoing long research and yeah, so please give if you have any feedback then contact me I'm going to release new documents about the details of this model because I didn't answer every question in this short talk but I'm going to put out a new documents to my GitHub page and I'm going to announce them on Twitter and Reddit and everywhere and I would really like to make this model a usable bot for Go Ethereum and the GATLite client and also for our future light plans of Ethereum 2 and yeah, that was it, thank you for your attention maybe there's time for one question or two new questions How do payments work? Sorry, how do payments work? How do payments work? Well, so this model is... so it can work with any kind of payment technologies I was looking into using Radar and now this form team also has this web protocol that's also an interesting payment channel technology but I think we can even start experimenting because I said it's simple engine payments which are really easy to do and yeah, so the model doesn't depend on the payment technology All right, but the job is manageable you could pay for something that works for any server or... Just service tokens, you mean? No, so every server has its own service token and they are only accounted locally on the server and I'm not sure yet whether they should be tradable or transferable, that's... well, that's... let's leave it as a future research topic whether that's a good idea or not So if you do an untrained transaction you have to pre-pay and hope that they're like... Yeah, so the server will... so if you send ether to a server or die or whatever the server wants to accept then you are going to have ether or die on the server and as I said, you have to explicitly say okay, now I have ether with you and I want to convert some of it to service tokens now and my time is up and thank you very much