 Well, while we're waiting for the slides to load, we're going to be talking about Swarm, which many of you probably know as just vaguely as just sort of the content storage part of the holy Ethereum trinity of the blockchain and the whisper and Swarm. Swarm is actually going to be a lot more than that. We can do directed message routing. We can use it for communication and content publication, content delivery. And today, we're going to be talking about the incentive structure built into Swarm to make it a good content delivery network and content storage network. That's the holy trinity. All right, so content delivery I'll be talking about. Victor will talk about content storage because they have different use cases. There's different incentive structure built into it. So first of all, let's say you're using Swarm and you're just trying to get data out, which is what anyone using a DAP would do if the DAP stores its data on the Swarm. In Swarm, everything has an ID. A node has an ID. Data has an ID. We should all share the same address space. So if these are some Swarm nodes, you're one of them. You'd have an address. And if you try to get some piece of data, you would get that data's address. And that location, that's where you're going to look for the data. Now, what does that mean? Everything is peer to peer. So everything is stored when up here. So what it means, we look at the node that is closest to that address space. And that's the node that's supposed to be storing the data. So that's what we're going to have to retrieve it. And the retrieval process is what gets the data to you. And instead of talking to that node, you're going to just be talking to the peers you're already connected to. So this is how it will work. This is the retriever. Here's the data address. And this is the closest node. And that orange chunk down there, that's the data we're interested in. The way that the routing works in Swarm, we have a bunch of peers we're connected to. There will always be one that is closer to the data than you are. You're going to send it a request. It's going to forward the request to nodes that are closer. And it will continue on this way until the request hits the closest node. And the data is passed back node to node until the retriever has the data. So that's the method for delivering data. So how do we account for it? How do we do the incentives? The Swarm accounting protocol is the protocol that accounts for all the data delivered, data requested. And it's a peer-to-peer accounting system. It has to be in this context. So if your node and you're connected to a peer, all you can really keep track of is how much data you've given the node and how much data you've requested from the node. And the difference, if that becomes too lopsided, that means you owe the other nodes some payment or the other node owes you. We cannot pay for every chunk of data. That's just too many transactions, too much blockchain bloat. We can't even pay in batches. So we really, really need to limit the number of transactions for this to be viable. And what we're doing in Swap is a checkbook smart contract. Checkbook works just like your checkbook in a bank. You write checks and at any time, your counterparty can take that check and cash it. Of course, if you cashed every single check, that would still be a lot of transactions. So the way this is designed is you can just keep collecting checks from your peer and whenever you feel like it's getting too much, you want to make sure this transaction will go through, you cash it in on the blockchain, but you only ever need to cash the last check received, they're cumulative. So that is a way to really reduce the number of transactions. And if this sounds like a payment channel, it sort of is, soon we will have payment channels. We're working with the raiding guys to implement payment channels. I just want to highlight the difference. Both payment channels and checkbook move transactions off chain. The checkbook has a very low barrier to entry because if I have a checkbook contract deployed, I can start paying every one of you and you can all use my checks and send them to the checkbook contract in order to cash in the check. Whereas in payment channels, everyone would have to have joined the payment channel network. The downside is a check can bounce. I can write millions of checks but my checkbook doesn't have the required balance. So that's sort of the trade-off but we find it's a good way to get people on board to just get things started. But as I said, payment channels are coming too. So what does this get us? Swarm with the swap accounting system allows us to program the incentives of every node. So we're assuming every node is profit maximizing rational actor. And one of the effects of the way we've designed it so far is that as a content delivery network, the swarm will be automatically scaling. So if you remember in our retrieval, there's no trying to retrieve, there's the data, there are a bunch of nodes involved that orange chunk was being passed along as it responds to the requests. The nodes in the middle along the sequence, they didn't really make a profit. In the swap on one side they had to pay, on the other side they got paid, they're just sort of passing it along. The node that had the data got paid and the one that wanted the data had to pay. Now the nodes along the way they can cash the data, they can keep it or they can delete it. It's up to them. But they have an interest to keep popular stuff because if another node comes along and wants to access the same data and then a retrieval request hits a node that had it cashed, that node can now deliver it and earn the profit. So popular data you're likely to cash. In fact, you're likely to fill up your space with anything that goes through you on the off chance that you can sell it so that way you maximize your profit. But on the flip side, if you look at the network as a whole it means that popular content will automatically be widely distributed and latency and bandwidth, latency will reduce, bandwidth will increase certainly. So that's what I mean by auto scaling and it's one of those features when if you can program everyone's incentives, you can get really nice emergent behavior on the swarm overall. And that might be great for popular content but if I have unpopular content that I need stored for a long time, we're gonna need a different system and I'll hand over to Victor for that. Can you hear me in this mic? Is this good enough? Okay, fantastic. So if you don't mind I stay seated because I'm a bit unstable on my feet at the moment. So the storage incentives, this talk has two parts and two authors, it's quite lucky. So storage incentives are pretty different animal from the bandwidth incentives. It's because they are not immediately settable. It's not a good that you immediately have and you can pay for. It's something that is basically a promise. So while swap guarantees the emergent behavior of like healthy operation of the swarm, which means low latency retrieval of content, it really only works for popular content because although the swarm has maximum utilization at all points, when an unpopular content is uploaded and you have a lot more popular content coming in, you'll be inclined to delete the stuff that's not requested often. And this is exactly how the algorithm should work and how rational agents should behave. So what do we do with it? Well, we have to somehow make sure that those content that I really want to keep for a longer term is not gonna get deleted by the time I need it. So what do we do? Well, we pay to nodes like to store us to store my content, like basically buy their promise. Well, it sounds like, okay, so if you want your baby to be taken care of, like you pay the babysitter, that's not a very big invention, but the problem is that first of all, you don't know who the babysitter will be. And second of all, you might not, you might not want to completely trust the babysitter and you want to check on the baby at some time. So what do you do? How do you do that? Sorry, I'm going the wrong way. So the basic idea is that, basically commit a particular amount of payment that is needed for storing that chunk or that piece of content for a while. And, but you release it periodically in installments in response to certain proof that your content exists. So in the baby's case, you basically call the babysitter every day for the week that they're there, and you want to check like whether they are okay. So this particular type of constructs, they call proof of custody constructs, which make sure that you can actually have a very good level of security telling your content is stored by a store without actually having to retrieve the full set of data. This constructs are analyzed and a suggestion of like which one to use is written in the orange paper that we released about this topic. So once again, these payments for the storage are released in installments and they can be actually integrated in the payment channel logic. How? Well, as basically escrow release conditions, what this means is that you can have an automated process which can make sure that the proof of custody is valid. And if that verification can be done, then the release of the installment can be conditional on that, which means that smart contracts are ideal to implement this kind of logic. So we call the logic that determines whether in a particular incentive scheme like a promise is kept, it's called a judge contract and this whole pattern of using the smart contract as a judge is gonna come in various forms in a lot of incentive systems. So far, we can make sure that the babysitter is not getting paid if our baby goes missing. Are you happy? Well, I'm a bit in two minds. So I think we really need in this case some sort of punitive measure added to that. So withholding the positive reward as an incentive is nice, is almost necessary, but it's not sufficient. And therefore we need to introduce these punishments. So how do we do that? So first of all, we need a component where I expect the nodes to be registered in order to make sure that they have something on the line. They have something to stake. So if they make a mistake, then they lose their stake. In this case, we call it security deposit. And this component of the system is called a swear contract. It's kind of double meaning. It means that you swear to keep to the rules of the game and you stand to lose your deposit and therefore your reputation and participation network, at least with that identity for a while in case you found to misbehave. So how do you get the receipts? That's the question. So this one, we already talked about the retrieval process. Basically the same routing mechanism is used for this process called syncing. Syncing makes sure that the content finds the appropriate address that it should be stored at. So you have the owner who puts up like upload the chunk or a piece of data to the network, then it has to arrive at the chunk's address and basically have to be stored by the node that's closest to that address. How does it get there? Well, as I mentioned, there's always a node that's closer to the any address than you. This is the property of the Cadamlia network. It's this particular network topology that makes sure that this is the case. Then you pass the chunk to that peer which is directly connected to you and that peer does the same. So through a series of relay nodes and through a process of forwarding, the chunk ends up as the closest node. So what happens when we are to ensure the storage? Like how do we talk about that? Well, it's very simple. We just enrich this process with a reverse, basically a reverse process whereby on each swap, the transaction where the peer forwards the chunk, they get a receipt back. And with that receipt, what can we do? Well, for every peer that you can use the receipt to sue against losing the chunk. So if you have the receipt, then you can start the litigation process. This is gonna be the next kind of component that we talk about. So the litigation process is in very short, it means that it makes sure that if the data is lost, then the sued store gets, loses their deposit. It's the litigation is done by challenge, which means that whoever holds a valid receipt for a chunk and they don't find the chunk, they are allowed to launch a process of litigation, which basically means to on the blockchain. It's sending a particular transaction to the Swindler contract that handles the swarming incentive system. And once it gets to this stage, the only way that a peer can defend themselves against this challenge is like basically two ways. Like one is to show the chunk that here you go. So like, your baby is actually here, like please believe me, it's okay, they are not lost. Or they actually do some finger pointing. Essentially it means they're shifting the blame to the next node, which, sorry, it was the previous slide. So the next node that they forwarded it to. So these local interactions in the end make sure that the litigation leads to a correct result. And at the same time give the very interesting property of the system that the storage promise contract is immediately settled when the node uploads the content to its peer. Why? Because once your peer gives you the receipt, you can always at the later point litigate with that receipt and you don't need to know who the actual store was. So it's like going through a series of agents for baby sitter, you actually don't know who the baby sitter is and who takes care of your kid. Okay, so this pattern makes sure that you have immediate settlement and the correct accountability for the store simultaneously in the system. And this generic pattern for this programmable incentives which we kind of playfully called Swap's Wear and Swindle. I would like for the Chinese translation with this. This is a, basically captures this whole idea that you have local interactions on the one hand, you have protection against foul play with the security deposit and the registration and you have a provable, verifiable way to tell whether you misbehaved. So it's in this case like it's basically expecting a valid proof of custody and if you don't have that then the judge can fairly say that you didn't fulfill your promise and therefore the punishment is fair. So there's a lot of details about this system. Obviously you might have a lot of questions immediately arising which relates maybe to the complex economic setting in which like the whole system applies these rules like what kind of emergent properties can occur and whether they are in line with the intended operation of this network. So some of these are discussed in more detail in the two orange papers that we released in May. These are kind of draft versions and we still would like to have some more thorough peer review although a lot of people read it that we would like to have some more in depth in the feedback on this. Just to quickly use my one minute up. Maybe you want to hear a little bit about the status of this one because I'm not sure I was well prepared to say that in the first panel. So the most important bit that I left out was that there's the test net running in which we can actually check on the large scale, like relatively larger scale operation of this network. And this is starting on the Microsoft Azure cloud. It's gonna have like 100 plus nodes operated by us but once the public is welcome to join then we can grow it up to like thousands of nodes if you guys contribute and would welcome developers to contribute to that. And just to conclude, like a few links that you can visit and I would really happy to put all those names up on the board who contributed to this fantastic project that I'm very enthusiastic about. So you will hear a little bit more about the next stage plans in my second talk which I give in an hour. Thank you very much.