 Okay, welcome. So I'm going to talk about Swap, Swear 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 going to go through the story of how this platform developed. So I'm going to 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 we're, well, we're building. It's not finished yet, but where do I, where do I target this? Turn it on. Okay, so, well, we don't, this is sort of our outline of the paper. I'm going to start with 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 per peer accounting of everything you do, and everything is on a per connection basis, because of course there's no central providers. So nodes 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 in a 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, for data provision, because once we have the hash, we can query our peers for that data and be sure that we can 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 going to 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 one and node two. They halfway through the slides, they turn into node A and node B. Don't know how that happened. So node two requests data and it gets delivered. And instead of paying for every chunk, because that would 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, node 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 to sort of balance out consumption. So if node one and node two 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 this range, we're happy to move back and forth. If we move too far to one side, we have to initiate a payment. So this is our current status. If node two consumes more data, it'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 one can pay node two by issuing a check. So it writes a check, referencing its checkbook contract, an amount. Here it's one ether. And at this point, node two has the option of caching in that check. So caching in the check means sending that check to the blockchain, to that contract, and that contract will send one ether to node two. The alternative is not to cache the check. We're trying to save on transaction costs. And the trick here is that the check payments from node one to node two 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 cache the last one. So how that works is the first check was for one ether. And the second check, if node one wants to pay another two, it would issue a check which has a total of three on it. And if one then wants to pay another seven, it will issue a check, not one that says seven, but one that says 10. And when node two caches checks, well, let's assume we've already cached the first check. And so the contract remembers how much node one has already cached, node two has cached. So when it sends in a supplementary check, it gets paid the difference. So in that sense, you can only ever need to cache the last check. So what do I have? If a wants to send b another three ether creates a check with a total of 13, which when cached initiates a payment of three. So what that means is that node b really has the option of pay of caching checks anytime. They give immediate on chain payments, but b can choose how frequently to cash checks. So maybe if we're new in business, I might cash your checks frequently. But if we have a connection and share data for months on end, after a while, I might just cash them once a day or once a week. It's really a matter of trust. So the more often I cash them, the higher my security guarantees, but also the higher my costs are. So but that's up to me. Yeah, so a section on negative checks. 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 variants? So it tilts one way and then it tilts the other way a lot. We end up getting uncached checks accumulating on both sides. And it would 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 five there. But as well, I'm continuing my example. We've already cashed 13. So what this represents is both nodes owe each other five. And so why can't we just cancel that out instead of having to do two on chain payments? So that's what this sort of negative checks idea is 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 13 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 caching checks is no longer instantaneous. We need a security delay, which is not surprising. If you any work on payment channels always has these security delays. So node B holds a check with 13. So it means it can get paid out another three. And now suppose the channel goes the other way and node B needs to pay node A 1.5 ether. It can create a check. That was the old method. Send a check with 1.5. Or what it can do is it can take this check number four 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 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 uncached checks, some serial number and some total. And then if the balance goes the other way, we can 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 caching a check. So that's really useful for doing repeated payments off chain. And yeah, 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 de-accumulate and then maybe accumulate on the other and de-accumulate. But sort of this going 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, the single checkbook. And yes, it's better suited for high variance swap channels because it's high variance where you have the checks piling up. And this might actually be a common use case. Like when you are running a swarm node, you're 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, is going to 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 100 on it, sends B a check worth one, B is happy, I can cash this check whenever I want. A creates a check to itself, pays out the full 100, B tries to cash the check, and there is no collateral left, right? It's pooled. There's 100 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, to be fair, 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 node A has issued checks and honored all of them, you've got an on chain credit history of node A. And if it ever issues checks that are not covered, that would be visible for all future. So 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 100 for all my outstanding checks, but locked for B is 30 locked for C is 10 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 know, more than I suppose you want to empty node A's checkbook and there's an outgoing transaction for 100. At that point, node B can say, no, I still have this check handed in and they take they have press take precedent. 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 A to B. 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 ether 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, 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 checks, then we're good. So maybe we start out with C having three F guaranteed and wait, 10 for C and three for D. And then to change that, A would send a message saying, okay, from the next epoch, and there's epochs 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. As long as there's consensus within that small group of peers, they can rebalance, 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 variance. So if we expect a lot of payments to flow in one way, we 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 kinds of games we 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 any one of those peers drops offline, well, 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. At some point, I can, all right. So this idea of the checkbook that I've introduced so far is going to be the basis for a much wider range of payments. So it's not just about storage and data retrieval. We want to, you know, we want to enable peer to peer services of many different types, as I mentioned, and we want it 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 I'm just going to list a few examples. Promissory notes and bonds, they work just like checks 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. Bounties, 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 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 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, many other forms we can we can imagine including. And so even the Swam's long term storage request, 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, 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 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 going to behave well according to certain service provisions and be penalized if you don't. It's also a registration to indicate what services you want to offer. You can register yourself with a storage service, register yourself with I don't know, some database provision service. So swear handles the registrations. And yeah, so the swear contract, 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 node. I could choose to be a storing node. I could choose to be any other node. And the only changes that have to do is register with the appropriate swear contract. And then the swap channels are now allowing payments of that type conditional checks of that type. And the other ingredients swindle. Swindle, the swindle contracts are the enforcers of these contracts. So you register with swear and swindle is really the logic. It's the evaluating the conditions of the conditional payments. So while swear tells us what kind of services we're offering and what kind of conditional bonds we 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. And so this is sort of a little bit of an overview of the interaction between the three contracts. You know, the swindle contract is the judge of trying to evaluate whether something happened. It in return can call sentencing. It can cause swears collateral to be burnt. That's, you know, the original example. It handles the verification of notes. This is where I said, you know, proof of custody would be on this level. Conditional bonds evaluated by swindle and, yeah, commitments to services to credit deposit. So this is these three sort of interact nicely. And they're extensible, 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, that can give you a yes or no answer whether a service was provided, then it can be tied into this payment infrastructure. And oracles, of course, are really important down here. Plugging in an oracle that tells you whether something happened 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 complement what Aaron said so far. So the whole context of these software and swindle games is of course to have proper service networks over a large number of nodes. So the idea here is that the security of these swap channels is really based on the idea that the nodes that set up a swap channel between themselves engage in repeated dealings. So because of the accumulated micro payments is what allows us to hold out, for example, you know, on-chain caching of checks. And that's why it's really important that the nodes that engage in swap channel dealings have recurring interaction with each other. However, the whole point of this is that if you have a cadamely topology of nodes like a proper graph where you can guarantee that each node is reachable from every other node, then you can extend the service interactions between peers in two ways. First of all, you can extend them in terms of frequency. So you can have one-off ad hoc transactions between peers instead of repeated dealings. Because you can have indirect transactions which go through individual hops which correspond to the swap channels. And also in terms of ad hoc and one-off payments, and also in terms of any node, like any two nodes can interact. It's not just your direct peers. And the whole point is that with such a cadamely topology, each node is connected to like a small constant set of nodes at any one time. So their interactions and their having contracts with each other is kind of feasible. And at the same time, it allows, if you combine them into this swap channel networks, then you can guarantee that any two nodes can interact with each other in like even an ad hoc one-off fashion. And so one example of this is that when, for example, payments between nodes can be extended to any two nodes based on these hops, which is basically a lightening network or a Raiden-style network which can force out from this paradigm. The other important thing that I would like to talk about is that such service networks allow a zero cost entry to a service because the moment you are allowed to provide service to your peers, the peer can basically commit to pay you by creating the checkbook contract for you once they consumed enough service so that your service covers the cost of creating a contract. And so basically nodes can bootstrap themselves in such a service system without having any ether balance. And that's quite a nice property because you can have an entry point to the ecosystem without going through exchanges and all kinds of things, which is usually quite a serious bottleneck to a lot of people, especially those who have problems with like banking services in their country or region. So one important thing is the service network extension of these hops and Swindler games. And maybe the other aspect that I need to mention is how the Swindler contract works. So as Aron mentioned, the idea is that the Swindler contract is just a generic contract that knows how to orchestrate a trial, basically knows how to conduct a trial. We chose to conceptualize this as a finite state automaton because in the finite state automaton, the states correspond to the stages of a trial. For example, that a trial is in the face of evaluating the first accusation and cause a witness contract that testifies to a particular evidence that's submitted to a contract. This abstraction allows for quite a varied types of evidence to be evaluated by the contracts and at the same time keeps the logic of the flow of the trial quite succinct and quite easy to argue about. So as the finite state automaton is progressing, so in one stage it causes a witness contract and according to the testimony of that contract, whether the evidence confirms the accusation or refutes that, it progresses the trial in the next stage. And at the end of the trial, the end state of the automaton is of course the guilty or non-guilty verdict that with the help of which the execution is given back to the swear contract which can then confiscate the deposit, the collateral that underpins your promise to comply with the service provision conditions. So 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 incentivization for actual services provided and on the other hand, service guarantees, so guarantees to service consumers that if certain promises of a continuing service provision is not met, then you can have individual punitive measures enforced on the service providers which gives a very strong guarantees usually that that service is provided properly as an emergent property of these networks. So this is it basically. So thank you for your attention.