Swap, Swear, and Swindle Games

okay welcome so I'm gonna talk about swaps where and swindle which many of you might already know from our early orange papers on the incentive structure for content distribution and content storage but it has evolved quite considerably since then to be a framework for incentivizing all kinds of distributed services as Victor was alluding to and I'm gonna go through the story of how this platform developed so I'm gonna spend a lot of time talking about our checkbook payment contract which grew from a very simple micro payment contract into the more complete platform that were well we're building it's not finished yet but where do i target this turn it on okay that's better okay so well we don't I'll this is sort of our outline of the paper I'm going to start with the swap which is the peer-to-peer accounting protocol so swap is the protocol by which nodes keep track of the services provided and consumed and in a decentralized system you have to have a perp here accounting of everything you do and and everything is on a per connection basis because of course there's no central providers so notes keep track of the services consumed for every peer and I gave the following example in our swarm update on the main stage I said the basic first use case of swarm supplying app data decentralized way would work as follows you type in a swarm address in your url bar and that would be resolved by ens into a Content hash and that's the only thing we need the blockchain for and for data provision because once we have the hash we can query query our peers for that data and be sure that we gonna get the correct data and then step four was I said you receive the data from the peers and you compensate them accordingly and in this compensate them accordingly that's where the entire payment infrastructure was hidden so I'm gonna talk about that and of course Step five was render the DAP so how does it work under the hood a node so I always have these two nodes today it's node 1 and node 2 they half way through the slides they turn it to node a and node B don't know how that happened so no to requests data and it gets delivered and instead of paying for every chunk because that make a very unusable protocol you actually allow a bit of leeway and you have more data but after a certain while if too much service gets consumed no two would have to pay node a in some sense and I said it pays by sending a check using our checkbook contract it's an off chain payment and I'll get more I'll talk a lot more about that terms of balance out consumption so if node 1 and node 2 consume services from each other and it's balanced you never actually need payment so it's not always service for payment it could be a service for service exchange and the swap takes into account all of these scenarios so internally this is a representation of what a swap channel might look like when we start we're here neither node owes any node anything and as one node consume services our internal balance tilts towards the side and within within this range we're happy to move back and forth if we move too far to one side you have to initiate a payment so this is our current status if node 2 consumes more data we'll end up here and at that point it has to pay to get us back to sort of the balanced channel state if we go too far to the side we disconnect that's the penalty so how does this basic checkbook work you have a swarm node it has a checkbook contract deployed and this checkbook contract has some balance now at this point node 1 can pay Note 2 by issuing a check so writes a check referencing its checkbook contract an amount here it's one ether and at this point note 2 has the option of cashing in that check so cashing in the check means sending that check to the to the blockchain to that contract and that contract will send one ether to node B oh no - the alternative is not to cash the check right we're trying to save on transaction costs and the trick here is that the check payments from node 1 to node 2 are cumulative so you can keep collecting more and more checks and each new check kind of makes the previous one unnecessary and you only ever have to cash the last one so how that works is the first check was for one ether and that second check if node one wants to pay another two it would issue a check which has a total of 3 on it and if one then wants to pay another 7 is we should check not one that says 7 but one that says 10 and when no two cashes checks well let's assume we've already cashed the first check and so the contract remembers how much node1 has already caught - as cash so when it sends in a supplementary check it gets paid the difference so in that sense you can only only ever need to cash at the last check so what do I have if a wants to send be another three ether creates a check with a total of 13 which when cashed initiates a payment of three so what that means is that node B really has the option of pay of cashing checks anytime they give immediate unchain payments but B can choose how frequently to cash checks so maybe we renew and business I might cash your checks frequently but if we have a connection and share data for months on end after a while they might just catch them once a day or once a week it's really a matter of trust so the more often I catch them the higher my security guarantees but also the higher my costs are so but that's up to me yeah so a sectional negative check so we want to extend this checkbook perhaps in the following scenario what can happen if we have a swap channel that has a lot of variance so it tilts one way and then it tilts the other way a lot we end up getting uncashed checks accumulating on both sides and really be nice if we could sort of play them off against each other so in this case I have on my slide here an 18 here and a 5 there but as well you know I'm continuing my example we've already cashed 13 so what this represents is both nodes or each other five and so why the can't we just cancel that out instead of having to do two on chain payments so that's what this sort of- checks ideas about we want to avoid this situation so we extend the checkbook in the following way the checks now have a serial number so you see check number four from A to B has the thirteen ether total and the checkbook remembers not just how much was cashed but what the last check serial number that was cashed was so now another change is that cashing checks is no longer instantaneous we need a security delay which is not surprising if you any work on payment channels always has these secured she delays so Nobi holds a check worth 13 so it means it can get paid out another three and now suppose the channel goes the other way and nobody needs to pay note a 1.5 ether it can create a check that was the old method send a check worth 1.5 or what it can do is it can take this check number for superseded with a check number five so it's got serial number five with a new total of 11.5 ether so it's reduced its total so it can cash that check whenever it would like still works and you know get the 1.5 difference and if node B tries to cheat by sending in the earlier check well that's where the security delay comes in node a would send the check which is signed by B to show no that's not correct and the serial number keeps track of which one is the newest one so this method allows us to do a lot of business accumulating a bunch of uncashed checks some serial number and some total and then if the bounce goes the other way we can go keep going keep going keep going until all this balance is used up and we're effectively back at zero and we can do all of that without ever cashing a check so so that's that's that's really useful for doing repeated payments off chain and yeah and only once we've hit zero here do we ever have to send checks the other way so they accumulate on one side and then D accumulate and then maybe accumulate on the other and D accumulate but sort of this goes back and forth and we're trying to avoid ever using the blockchain or use it as little as possible yeah the benefits are we can reduce the transaction costs much more than just the simple payment contract a single checkbook and yes it's better suited for high variance swap channels because it's high variance where you have the cheques piling up and this might actually be a common use case when you are running a swarm node you continually providing little bits of data to your peers and then you sit down and watch a movie and that's when you really you know use up a lot of bandwidth so this kind of high variance is actually as we're assuming it's gonna be typical yeah and this method can be further extended to support payment channels now what do I mean by that so payment channels a little bit different than checkbook and the difference is in terms of security so let me talk about the security of checkbook payments how secure is a check well the answer is they're not really secure and I mean the sort of baby example is the following a has a checkbook with a hundred on it sends me a check worth one B is happy I can cash this cheque whenever I want a creates a check to itself pays out the full hundred B tries to cash the check and there is no collateral left right it's pooled there's a hundred here was pooled over all the outstanding checks that is issued and we have no idea what those checks are they could be you know I mean there's more to be said here because if these checkbooks are long-running and you can see over you know the past month past year past five years that no day has issued checks and honored all of them you've got an on chain credit history of no day and if it ever issues checks that are not covered you know that would be visible for all future so it the security is more implicit based on you know credit history and Trust but it's not hard-coded into any smart contract so suppose we wanted more hard guarantees so we have the same guarantees as a payment channel that would work as follows instead of having one collateral for all outstanding checks the checkbook has subtotals of that reserved for certain peers so I'd have a hundred for all my outstanding checks but locked for B is thirty lot for C is ten and locked for D is three meaning that B can be sure that any checks they hold will be honored up to and including 30 because whenever somebody tries to take you no more than if suppose you want to empty no day's checkbook and there's an outgoing transaction for a hundred at that point note B can say no I still have this check hand it in and they take they have press take precedence so that's a security guarantee and if we also use this method of checks going up and down in balance you can see that this is already functionally equivalent to a payment channel well it's only half a payment channel because it starts out with only payments from to be but if we have one of these on both sides a and B have checkbooks with amounts locked for each other then this is functionally equivalent to a payment channel right what did I want to say oh yeah so a bit of nomenclature we're calling this the in our upcoming paper we're writing all of these up this payment infrastructure so this is called a channel deposit actually we're calling this a hard channel deposit because there's a twist to this where we can have something else called soft channel deposits that I want to talk about very briefly so suppose we have collateral that's pulled over several names so we might have B has a 30 either locked with it as beneficiary but we could all say well C and D together have a guarantee of 13 and how much of that is actually for C and how much of that is actually for D can change with time and the idea we want to do is we want to rebalance payment channels off chain right right now payment channels are great for repeated payments but if one channel is depleted and another one fills up you need on chain payments to rebalance and this is a scheme to try to even do that rebalancing without ever needing to go on chain and it works as long as your families of payment channels are small you have a few peers but within a swarm network there's a limited number of peers with which you do repeated business so as long as nodes a the checkbook owner and the beneficiary C and D agree on how much of that soft channel deposit covers the each text then we're good so maybe we start out with C having three F guaranteed and write with 10 for C and 3 for D and then to change that a would send a message saying okay from the next epoch and there's epochs or of time periods so in the next epoch we want to change this so that now seven are guaranteed for C and six are guaranteed for D and that message is signed by a that's not yet enough because C and D have to agree as well you know as long as there's consensus within that small group of peers they can rebalance yeah they can rebalance their payment channels without ever going on chain so with those ingredients we believe that this checkbook infrastructure really does allow for a network of payment channels with rebalancing without ever really needing to go on chain or very very rarely so it's good for a lot of repeated micro transactions and this rebalancing by the way is important because of variants so if we expect a lot of payments to flow in one way you might need to increase the guarantees for one peer and then later as it flows the other way we can decrease that guarantee increase another and all of these kind of games you want to play without needing to go on the blockchain so yeah it requires consensus from all the name parties to function securely and if you any one of those peers drops offline well and you then you need to go on chain to start a new cycle with a new set of peers probably but the details of that are still being written up it's all a question of how to reach consensus amongst your peers on what everyone's guarantee is right some point I can alright I so this this idea of the checkbook that I've introduced so far is gonna be the basis for a much wider range of payments so it's not just about storage and data retrieval we wanted you know we want to enable peer-to-peer services of many different kinds as I mentioned and we wanted to fit into the same infrastructure so the checkbook is really easily extendable to allow different kinds of payments different kinds of financial instruments so for I'm not just gonna list a few examples promissory notes and bonds they work just like cheques that can be cashed at a future time so they have a valid from and valid until date that means only during that time can they be cashed and again they don't really have to be cashed at that time as long as you they're subsumed within some swap messages but so bonds works recurring payments as well a recurring payment if I pay you if I give you a check with the rule that you can cash it once a week for the next five months and that's a recurring payment and again it doesn't have to go on chain as long as within a swap channel both parties agree that a payment happened it happened Bounty's yes bounties are called conditional bonds or conditional checks so I can issue you a check that you cannot cash unless some other condition is met and that condition is separate to this game like it's yeah there's a little hook in the check which says evaluate some third contract which tells you whether the condition happened yes or no so maybe that condition is an Oracle of telling you whether some github issue had been closed with the you as a author of a PR whatever it is and then that cash can be checked so bounties work in this case loans as well I can agree to reduce the swap balance between us effectively loaning you something in exchange for a check that is only valid in future which is the repayment yeah so it's very flexible and there's many other checks with many other forms we can we can imagine including and so even swans long-term storage requests this is kind of where we started developing these ideas they fit into this framework long-term storage is a payment that you can only unlock by giving repeated proofs of custody the proof of custody is the condition saying you still have the data and that gives you the payment and it also just takes the form of a conditional check yeah in our upcoming paper we have an overview of the kind of things you can do bounties deposits conditional loans it's very flexible and well we're still writing it all up but it's it's coming soon briefly swear what is swear in this context swear is a contract where you can tie up collateral to promise that you're gonna behave well according to certain service provisions and be penalized if you don't it's also registration to indicate what services you want to offer you can register yourself with the storage service register yourself with ID no some database provision service so swear handles and registrations and yeah so the the swear contract tell this the registrations tell the swap contracts what kind of conditional bonds are allowed within the swap channel and it's supposed to be really flexible so I could choose to be just a relaying note I could choose to be a storing node I could choose to be any other node and the only ones that have to do is register with the appropriate square contract and then the swap channels are now allowing payments of that type conditional checks of that type and the other ingredient swindle swindle the swindle contracts are the enforcers of these these contracts so you register with swear and swindle is really the logic it's the evaluating the conditions of the conditional payments so well swear tells us what kind of services were offering and what kind of conditional bonds were accept swindle allows us to enforce those conditions so again the original example was long-term storage the swindle contract evaluates the proof of custody do I really still have the data or you know punishes me if I don't and to be fair the swindle contract doesn't actually do this the swindle contract only handles the logic of accusing someone evaluating an accusation and handling accordingly and the contract that handles the proof of custody is a sort of hook in to the swindle system the swindle system is just the court system itself right since this is sort of a little bit of an overview of the interaction between the three contracts you know the swindle contract is the is a judge trying to evaluate whether something happened it in turn can call sentencing it can cause swears collateral to be burned that's you know the original example it handles the verification of notes this is where I said you know our proof of custody would be on this level conditional bonds evaluated by swindle and commitments to services to deposit so this is these three sort of interact nicely and they're extensible extendable that's that's that's really important so anytime you can define on chain what it means to provide a service if you can write a contract that can understand what that can give you a yes or no answer whether a service was provided then it can be tied into this payment infrastructure and Oracle's of course are really important down here plugging in an Oracle that tells you whether something happen allows you to make conditional payments based on that Oracle and it should fit in really smoothly on our infrastructure so we're writing all that up that's upcoming it's work in progress and do you want to say a few words come on Thanks so just a few things to to complement what Aaron said so far so the whole context of this optional swindle games is of course to have proper service networks over a large number of nodes so the idea is here is that the the security of the swap channels is is really based on the idea that the the nodes that setup a swamp channel between themselves engage in repeated dealings so so because because of the the accumulated micro payments is is what allows us to to hold out for example your own chain caching of checks and and that's why it's it's it's really important that that the the the nodes that engaging in instructional dealings have have recurring interaction with each other however the whole point of all of this is is that if you have a academia topology of nodes like a proper graph where when you can guarantee that each node is reachable from from every other node then you can extend the service interactions between peers in in two ways first of all you can extend them in in terms of frequency so you can have one of ad hoc transactions between peers instead of repeated dealings because you can you can you can have indirect transactions which go through like individual hops which correspond to the swap channels and also not in its so in terms of a talk and one-off payments and also in terms of you know and in terms of any note like any two nodes can interact it's not not just your your direct peers and the whole point is that with with such a CAD immediate apology each node is connected to a to like a small constant set of of nodes at any one time so they so the the there are interactions and and and they are having contracts with each other is kind of feasible and at the same time the it allows if you combine them into into this swap channel networks then you can guarantee that any two nodes can interact with each other in even even talk one of fashion and and so so one example of this is that when for example payments between nodes can be extended to to any two nodes based on these hops which is basically a lightining network or Radin sty network falls out from paradigm the other the other important thing that I would like to talk about this is that such service networks allow zero cost entry to a twister service because the moment you can you you are allowed to provide service to to your peers the peer can basically commit to pay you by creating the checkbook contract for you in what once once they they consumed enough service so that you know that your your service covers the cost of of creating a contract and so so basically a notes can bootstrap themselves in such a service system without having any ether balance and that's that's a quite nice property because you can help you can have an entry point to the ecosystem without going through exchanges and all kinds of news which is usually quite serious but enact a lot of people especially those who have problems with like banking services in the country or region so so one one important thing is the service network extension of this option swindle games and maybe maybe the other aspect that I need to mention is them it's how this how the swindle contract works so as I remain shinned the the idea is that the swinger contract is just a generic contract that knows how to orchestrate a trial basically knows how to conduct a trial we we chose to conceptualize this as as as a finite state automaton because the in the finite state automaton the the the states correspond to stages of a trial for example that a trial is in the face of evaluating the first accusation and and cause a witness contract that testifies to the particular evidence that submitted to a contract this abstraction allows for like quite quite varied types of evidence to be evaluated by the contracts and at the same time keeps keeps the the logic of the of the floor the try are quite quite succeed and quite easy to argue about and so the the the as the finite state automaton is progressing so in in one stage it it calls a witness contract and and and according to the to the testimony of that contract whether the evidence is is confirms the accusation or or refutes that it progresses the trial in the next stage and and at the end of the trial the end state of the automaton is of course the guillotine on guilty verdict that we with the help of which the execution is given back to the spur contract which can then confiscate the the the deposit the collateral the pin your promise to comply with with the service provision conditions so so with this with this intricate interaction between the three contracts basically the hope is that we provide a base layer infrastructure for supporting all kinds of service economies most notably incentivization in terms of rewards on the one hand so positive incentive is Asian for actual services provided and on the other hand service guarantees so if so guarantees to service consumers that if certain promises of a continuing service person are not met then then you can have individual punitive measures enforced on on the on the on the service providers which gives very strong guarantees usually that that that services is provided properly as an emergent so this is this is it basically so thank you for your attention [Applause] [Music]