 Yeah, so I'm going to speak today about the crypto economics of retrieval. It's crypto economics day and there is definitely a huge intersection between what we look at in retrieval markets and some of the amazing stuff which the team crypto econ are working on. And I've got a spaceman here. I guess we've just heard a lot about IPFS going to space and he's just looking to retrieve some stuff. He's just looking out and he just wants to retrieve some data. Okay, so I actually spoke at the crypto econ day in Amsterdam in April. So I'm going to start with a recap of what I spoke about there, but I'm going to try not to cover too much of the same material because it's all on the YouTube and then I'm actually not going to introduce the rest of the sections yet because I think it doesn't really make sense to yet. Okay, so for the recap firstly, what is a retrieval market? A retrieval market is assessing in which entities, people, nodes, they can come together and they can provide their services to create fast and performant reliable economic retrievals of data to those who are requesting them and essentially they are forming a decentralized CDN around the Fargoin network. And so CDNs that you may have heard of, CloudFront, Cloudflare, Akamai, those are the traditional ones. We're focusing here really on decentralized CDNs. And when we talk about decentralized CDNs, if you spend a little bit of time thinking about what sort of building blocks might constitute such as CDN, it immediately breaks down into lots of different parts. And these are the kind of things we look at in the retrieval markets group. I'm not going to go through them now because we haven't got enough time, but we'll focus on crypto economics, obviously. At the end of my previous talk, we ended on this diagram and there's a link to the previous talk in this slide. But since watching one of Huan's more recent presentations, he actually expressed the diagram in a much tidier way. So I have his diagram is on the right and I've taken that and sort of turned it into my theme. And I'm going to talk through this diagram quickly because I think it's really important to understand this in terms of what we're going to talk about today. So top left, we've got the content publishers, sometimes called storage clients. They're the people who want to actually store data in the Filecoin network. And they give their data to deal in distribution services such as Estuary, such as NFT storage, sometimes called aggregation services, some also Fillmine. And then these aggregators, they store it in storage providers. The storage providers can also create indexes, which will live in the index nodes, index provider nodes. It's given in red here. And that's the storage flow of the network. Then we've got the retrieval flow. So down bottom left in yellow, we've got the retrieval clients who are looking to fetch stuff into their browsers or into their game consoles, their video streaming platforms. And they want to talk to retrieval providers to have a really good experience retrieving that data. And the retrieval providers, hopefully they have it stored in their cache. And if not, they can cache miss to a storage provider, and they can even look up where it is from the index and nodes. So this is at the moment sort of a representation of the storage and retrieval of the Filecoin network. Oh, sorry, I'll go back quickly. There you go. No pressure. OK, so we're now going to talk about retrieval provider incentives. In this previous diagram, I'll go back again actually now. What will cause a retrieval provider to actually join the network and contribute their resources? They have to be incentivized to do so. We've heard a bit about impact evaluators from Huan as well. So we could sort of frame it in that way, although I'm not prepared to do so quite yet. So yeah, what are the incentives to get a retrieval provider to enter the retrieval market? So we're going to begin by a really naive retrieval protocol. And this is where we have the retrieval client on the left who wants to fetch a file from the retrieval provider. And quite simply, they make a Filecoin transaction, and then once the retrieval provider has received that transaction, it returns the file. Now, this is a very, very simple protocol, and it's even more simple than anything that's in the Filecoin network. It's just a kind of, if you were really thinking out loud about how this would work, you could say, OK, the retrieval provider wants to do this, because it's going to earn some Filecoin for this protocol. But I've written out a few constraints on this. Firstly, the retrieval client must have a Filecoin wallet to be able to pay and some Filecoin in order to pay the provider. And secondly, it must know how much that the retrieval provider wants for that, for the transfer. It needs to know the cost of this file. And then we've also got the problem that a Filecoin transaction takes a while to reach finality on chain. So we've got some technical problems which we can try and optimize as well. All these things we can improve, we already have improved the time that it takes to set up payment channels and exchange vouchers and do these things in the primary retrieval market against storage providers, as I spoke about in the previous talk. But aside from the technical things we can improve, there's sort of an initial product question which is, will retrieval clients actually pay directly for retrievals? Whenever we use our browsers, we don't pay to retrieve files, we don't pay to fetch websites, the web 2 business model is not predicated on the fact that you're going to pay microtransactions for every single file of retrieval. So I think that's a great place to start. And I've started this decision tree which we're going to build throughout this talk. And the first question we ask is, should the retrieval client pay directly for the retrieval? And so that brings us to the next section. So yeah, we've got the decision tree and we've got the very simple protocol diagrams here. And there are some use cases for when a retrieval client might pay directly for a retrieval. Perhaps if we want to incentivize index providers to join the network around the world, we could pay for indexes with microtransactions, or paying a reputation provider, or an L1 cache node in a CDN, paying an L2 cache node. All these are server-to-server retrievals, so it's much easier for the retrieval client to have a wallet set up to have a far coin balance and to make these micropayments. The last use case I put is web 3 browser retrievals, and there's a question mark at the end because this is what we're really wondering about. Will people be happy to attach a wallet to their browser and start paying micropayments for retrievals? Before we go into the yes side of the decision tree, sorry, some examples of it, there are some benefits to this direct payment of retrievals. It's a very simple economic model, and each retrieval is settled between the retrieval client and the retrieval provider. So you don't have to have any third-party arbitrate over this. It's exactly how the retrievals work from storage providers at the moment, this optimistic fair exchange protocol. And because it's so simple, it reduces lots of attack vectors that you might see on the system. There's a cost to actually retrieving a file, so the retrieval client isn't going to make any retrieval that it doesn't mean to. It's not going to do a Sibyl attack or a DDoS attack on a retrieval provider because of the cost of a retrieval. So in the retrieval market working group, we've seen a few teams start to work on this side of the decision tree, where you're paying for retrievals. The first team is Magmo. They are building scalable multi-hot payment channels. I'm going to go to the next slide to actually look at a diagram of what they're working on. So on the left-hand side, we've got retrieval clients who have to make payment channels to storage providers in order to retrieve a file in the current Filecoin setup. But this has to be pairwise between a retrieval client and a storage provider. So that's a lot of payment channels. And also, if you want to retrieve something from a storage provider from whom you haven't retrieved something from before, you have to set that up, which is an on-chain transaction, and it adds a lot of latency to your retrieval. So Magmo are working on this setup on the right whereby every client can connect to what I've called a hot hub, although they don't use that term, it just was quite short for the diagram. So they connect with a payment channel to a hot hub, and then we have all the hot hubs have a completely connected web with the payment channels between them, and then a payment channel between each storage provider and a hot hub. And then what you can do is create these virtual channels between retrieval clients and storage providers, and once you exchange vouchers on the virtual channel, you can then reconcile what's been exchanged across the three hops between those two nodes. And this means you don't have to create a new payment channel every time someone wants to retrieve from a new storage provider. We also have Myel. They're working on a very symmetric peer-to-peer retrieval network for when the client pays. Their philosophy, although I don't want to put words into their mouth, is that they want to see a paradigm shift Web 3 where it really is about people paying microtransactions from their browser or from wherever their retrieval clients are. And having a truly symmetric peer-to-peer network where you don't have any notion of clients and servers, really, is just everyone's helping each other out and acting both as a client and a server. So there's some really interesting work there, and it's leveraging a lot of the protocol lab stack. There's also loads of opportunities. So leaning on the magmo work of multi-hot payment channels and on the work of Ken Labs who have built Pando and the protocol labs team who have built the indexer node, we could come up with some proposals for how we can do these micropayments to incentivize people to run these, I guess, off-chain services in the network. And more generally, the hot pubs, which we spoke about, or ceiling as a service, or any of these other what I call off-chain services, we could look at how we can incentivize them to join the network through these off-chain microtransactions. We've also got the opportunity for a proposal for how best to pay for a retrieval from a browser. There's obviously security concerns once you start to have a wallet in a browser. So how best can we have a Filecoin wallet in a browser? How best can we manage those microtransactions? What's the UX flow of such a solution? And also something I mentioned earlier, a proposal for how a client wouldn't even know how much to pay for a retrieval. These retrievals, we want them to be very, very quick, and if you're having to find out how much a deal costs before you even start retrieving the file, it's an extra round trip, it's a bit more latency. So proposals around how we can not lose the speed we want, but also find out this kind of metadata around a retrieval deal from the retrieval client. So yeah, loads of opportunities in this, the client directly pays side of the decision tree. We now move to the other side of the decision tree. So follow it in yellow and we're now going down the no side. So the retrieval client is now not going to pay directly for the retrieval. And this means that I've had to zoom out to the original overall diagram of the Filecoin network, because we're now saying if the retrieval client is not going to pay, then who is going to pay? And the first thing is, okay, perhaps we could have block rewards for retrieval. Perhaps these retrieval providers could prove that they are serving retrievals. Irene spoke about it in the last talk and showed that there were some impossibility results about proofs of delivery or proofs of retrieval. But supposing we could, perhaps they could be block rewards. I think going down that path is a bit dangerous. And so I think for this talk, we're not going to go in that direction. I think what we have to really find is an underlying economic model, whereby value is flowing around the network to retrieval providers without us having to sort of build it into a block reward. And so what we end up doing is leaning on the Web 2 model, whereby the content publishers, the storage clients, they're the ones who want to store the data and they're the ones who want to have that data accelerated by a CDN to the retrieval clients. And so we can see this kind of squirrely green line to show that we need value to transfer between those two parts of the network, but we're not quite sure how yet. From now on as well, the white arrows are how data is flowing and the green arrows is how tokens are flowing around the network. So yeah, we've got these retrieval providers who are serving retrievals and we need to then prove to the content publishers, or I guess some of the node in the network that could be an intermediary, what sort of service they've provided. And the service can be measured in a few ways. And I guess this again leads back to the impact to evaluate the stuff. Like what should we be measuring to measure how performant a retrieval provider is? The two things that really come to mind and what we're thinking about more and more with the Saturn team and with other teams is simply a measure of how many retrievals have been served and also how fast the retrievals have been served. So I think what people in the industry say how much bandwidth has been shared from these retrieval providers. However, as we saw on the other side when the client pays, it's a very secure process where there's a responsibility on the retrieval client to pay for it and thus the attack vectors shrink. Here we're opening up loads of different attack vectors on the network where people can try and find ways to prove that they've served retrievals that perhaps they haven't, which we'll see in a second. So to build the decision tree out a little bit further, we're now saying that the retrieval client is not going to pay directly for the retrieval and now the second question we ask is how does each retrieval provider prove its contribution to whoever's going to be footing the bill. And that brings us on to Saturn and we've got Ansgar in the audience here, the tech lead for Saturn. Thank you for joining. So Saturn is in this camp of the retrieval client doesn't pay. And the idea here is that the retrieval providers, they will serve retrievals to the clients and they are going to self-report what they've been up to. They're going to send logs. You can see the white arrow saying logs. They're going to be sending logs of each retrieval to the Saturn Augustrator. And then the Saturn Augustrator is going to be aggregating over those logs and it's going to decide how much each retrieval provider should be rewarded for their service. And the Saturn Augustrator on the other side is going to be taking tokens or value in from the content publisher either via the deal and distribution service or perhaps directly and managing the market that way. But I'm sure everyone is already thinking that there's some pretty obvious attack vectors here. Why wouldn't a retrieval provider just create loads of logs which didn't even happen? Or perhaps they might collude with a retrieval client and say why didn't you retrieve this file a thousand times? Or they might spin up a whole bunch of different retrieval clients and do a civil attack and say right we're going to pretend that we've got all of this activity going. We've done all these retrievals. And so we are beginning some work with the CryptoEcon team with Maria who's recently joined. She's going to be looking at fraud detection on this log database and understanding exactly what is a normal sort of level of activity for these nodes that are spread around the world and what's an abnormal level of activity. And I think we're going to get some really interesting insights out of that. And that's that fraud detection module that I've added to the Saturn orchestrator. Two minutes left. Okay, I'm going to have to be really quick then. There's quite a lot to go through getting carried away. So there's also this other approach where which a lot of other teams have reached for Titan, Meson, Media and the CryptoNet lab with the Retrievability Oracle. I think it's now called Retrievability Oracle DAO where we have these validator nodes which are also known as hunters or guards or auditors or referees who are going to be making retrievals against the retrieval provider and testing that they are serving what they should be serving. And then reporting that back either to a centralized hub, to a smart contract or to a DAO in order to penalize those nodes or reward them based on their performance. And then it's the old question of who will guard the guards? How do we know the validators are acting appropriately? We saw Irene describe a way that they're going to do that as part of a DAO but there are obviously those questions that have to be asked and different attack vectors come up in the system. So this is the overall decision tree that we've built. We've seen teams working in all different spaces based on I guess what I've tried to simplify into this diagram and these particular questions. And I'll finish up by just saying there are a few opportunities for teams who want to get into the retrieval market space. One is using self-sovereign identity and DIDs and verifiable credentials as a way to sort of get this middle ground between the retrieval client not paying and paying by actually signing and issuing verifiable credentials to retrieval providers and then building up a sort of reputation around their decentralized identity in order to have a mechanism for rewarding someone based on how many verifiable credentials they've gathered from different clients. And there's also loads of opportunities around how we can manage the quantity of transactions. For example, let's say satin which will start off centralized. Let's say it moved to a smart contract. We've got a record for every single retrieval in the network and we're going to have to look at ways we can manage that the sheer number of transactions we're going to face there either with hierarchical consensus or roll-ups. And there's also opportunities around how we could use probabilistic payments and credit networks to reduce the number of transactions we have to record. On the ledger, I won't go into definitions of those now. And just to say there are open positions on the retrieval market team and on the satin team, head to retrieval.market to find out more or scan that QR code or head to the retrieval market filecoin Slack to find out more as well.