 Hello, and welcome back to the second portion of the program for the Filecoin Crypto Economics Day here at DevConnect in sunny Amsterdam. Now it is my pleasure to introduce our next speaker, Patrick Woodhead. Patrick is the Technical Program Manager for the Retrieval Markets Initiative, which will of course be crucial to the further expansion of the Filecoin ecosystem. And he's going to talk to us today about, you guessed it, retrieval markets. Take it away, Patrick. Thank you very much, Karola. Right, yeah. Today we'll be talking about retrieval markets. And as it's Crypto Econ Day, we'll have a particular focus on the Crypto Economics of the Retrieval Market as well. Going to begin with some motivation. So, a statistic. By 2025, the global CDN market, that's Content Delivery Network Market, is expected to be twice as large as the Cloud Object Storage Market. So, Cloud Object Storage, think AWS S3, CDN, you're thinking CloudFront, Cloudflare, Akamai. Now, when you first think about this, you might think, oh, that's actually remarkable, you store files in a classic traditional cloud, and then you kind of accelerate them as like an extra benefit. So, why would it be such a bigger market? But actually, when you think about it some more, you realize the engineering involved and the hardware, the kind of points of presence around the world that are needed to create a great experience for everyone retrieving files to all of their browsers, their games, consoles, et cetera. And they expect an amazing experience. They expect web pages to load instantly. That's a big engineering challenge. And because of that, companies are happy to pay a large amount to create such a good experience. So, what I'm trying to say here really is that retrieval, I forget about storage, we've been talking about storage all day. Let's talk about retrieval for a bit, because it's pretty important. Okay, so what is a retrieval market? It's the name of the talk and the name of this team, but it's good just to try and get a definition sorted here. So, for me, a retrieval market is a setting where anyone can come along and they can provide retrievals, file retrievals, to those who are demanding those files. So, I'd say that those traditional cloud CDNs like Cloudflare, Cloudfront Akamai, they're working in a retrieval market. But we're looking here at decentralized CDNs, and in particular, the Filecoin Retrieval Market. So, Filecoin Retrieval Market, we want to enable a decentralized CDN or DCDN to emerge around the Filecoin network so that we can have performant, reliable, economic retrievals of Filecoin data. So, there's lots of different topics that contribute to creating a healthy and vibrant retrieval market. In the interest of time, I might not go through all of these particular building blocks right now, but we're going to focus instead on crypto economics. Okay, so this diagram here is my attempt to draw up what's happening in what I call the primary retrieval market of Filecoin. So, on the right hand side in green, we've got the storage provider who's storing some content. And when a retrieval client over in blue on the left wants to retrieve a file from the storage provider, they have to do a few things. It's not as simple as just a browser making an HTTP request for a file. They have to set up a payment channel on the Filecoin ledger, and then they have to do what is called this optimistic fair exchange protocol, whereby the retrieval client will send, say, one voucher in exchange for one byte of the file, and then two vouchers in exchange for two bytes because these two entities, they don't trust each other, and they have to build up this trusted relationship. And eventually, the retrieval client will send some vouchers over and retrieve the last bytes of the file. The reason this is optimistic is because there's no sort of dispute mechanism. If the retrieval client doesn't get some bytes back for the vouchers it sent, it can't go and complain to anyone, it's just lost out on those vouchers, and that's why we build up trust. And eventually, the storage provider can redeem these vouchers that it's retrieved from the, or got from the retrieval client on the network. So, the reason that we have to have this off chain, well, when you set up a payment channel and then using vouchers instead of Filecoin, is because we have to have to have to have them really quickly. We don't want to have to have a blockchain transaction every time we want to retrieve a few bytes, and that's why this whole mechanism is in place. But it does mean that this retrieval client, there's lots of barriers to entry to being a retrieval client. You need to be able to talk to the Filecoin ledger, and you also need to be able to speak graph so you can do this exchange protocol, which means that the majority of clients around the world who want to retrieve files are sort of counted out from this. For a browser to do this, it's pretty difficult. So, yeah, essentially we can't, the demand for all of these files is very difficult for that to match that to the supply in the storage providers. What's more, these storage providers are not really equipped to satisfy all this demand. They can take the odd retrieval, but they're not like a CDN where they can take millions of requests a day. So this primary retrieval market, this is how Filecoin launched, and what we're starting to see emerge now is what I've tried to capture in this diagram. So we'll start down in the bottom left. We have these content publishers, so you can think of, say, an NFT marketplace being a content publisher, and they want to accelerate their files and create a great experience for someone who's looking at NFT media, whether videos, images, et cetera. Now they could go straight to the storage providers and green and create lots of deals to store that data, but what we're seeing happen is they actually speak to a deal, what I've called a deal and distribution service, and we can think of Estri as such an example. So they give the data they want to store to this deal and distribution service, and then this deal and distribution service can create deals with storage providers to store that data on Filecoin. And in the case of Estri, I believe it's six replicas or with six different storage providers. But then what we get is what Estri offers IPFS retrievals. So it's saying, okay, you can store it on Filecoin, and then we'll make it available through an IPFS gateway, which is great. You've now got a retrieval story, which is available to browsers and other usual devices that we use to fetch files. However, I think from a crypto economic perspective and also a decentralization perspective, there's just a few things that are not, we all want to kind of improve in this diagram. So it'd be nice to see sort of a link between the storage side and the retrieval side. It feels like you're kind of putting something in the storage, into Filecoin storage, and it doesn't then speak to the retrieval part of the architecture. In terms of value flow, the content publishers will be paying to store stuff with Filecoin as part of a deal. The storage providers can earn block rewards for those storage, but in terms of this model here, the IPFS is sort of run by whoever wants to run IPFS nodes or whoever's paying the bill for running an IPFS gateway. So that takes us on into the secondary retrieval market. So when I say secondary retrieval market, the primary one is retrieving from the storage providers and the secondary one is where we can cash stuff outside of the storage providers and we can start to retrieve between what we're gonna call retrieval providers in blue. And the reason we've got a ring of them around the storage providers is just alluding to Saturn, which is gonna be introduced later on and the rings of Saturn. Though it wasn't, I just got a bit carried away with a copy and paste. So yeah, we've got some of the boxes from the previous slide. We've got the content publishers again who are going to be giving content to the deal and distribution service and they're gonna be creating deals with the storage providers. But also we can now connect the retrieval providers to the storage providers and we can then enable some value flow between those two entities and also the deal and distribution service rather than just making it accessible to the IPFS gateway, which they could also do. They can start to contact these retrieval providers and starts to break the retrieval flow through these more decentralized offerings. So yeah, this means that we can have retrieval providers spun up by anyone, which is a requirement of this secondary retrieval market to be completely decentralized. The only, I guess the only requirement that we're adding back onto our clients is that they really need to verify what files are gonna get back. If it's an IPFS gateway, you're sort of trusting that gateway to give you the right file. But if anyone can spin up a retrieval provider, then how can you trust they're gonna give you back the right file? I might ask for a huge video and get returned like a tiny image and that's not great. So there needs to be some way that I can kind of prove that the file that I've retrieved is right. And there we reach for content addressing, which is the answer for lots of things in the Filecoin network. And we can then verify that file, but browsers don't verify content address files very easily. So we have to add some extra mechanisms, perhaps in a browser, but whatever the client is, we're gonna have to add that level of verification. And we can also then start to try and work on the properties which current cloud CDNs offer, such as traffic spikes and eDOS attacks, that sort of thing, and protect the storage providers from those internet scale phenomenons. And yeah, just much lower hardware costs to contribute to the Filecoin network. That's really important because we want it to be permissionless and decentralized, but if you have to own a data center to get involved, then it's not particularly decentralized. So we wanna allow anyone to join who's just got some devices or spare devices, which they could contribute to the network. So then we get to the question of how should a retrieval provider earn? We've got storage providers who can earn block rewards by doing proofs of storage. And they can also earn a small amount during doing deals with people who want to store data. What I should mention here as well, though, is that the deals to store data can actually be negatively priced, which is a phenomenon only available in Web3, because the storage providers, they're so keen to get this Filecoin Plus subsidies that they just wanna take valuable verified data. So they might even pay the deal in distribution service to say, give me good data. And perhaps that could then be used to pay for some of the retrieval providing. In general, though, we wanna find a way that these retrieval providers can earn without, well, by linking it to the demand, because if we just, let's say one of the ideas we've looked at for how retrieval providers can earn is proving bandwidth. So you're just proving that you're online and you're up, and you can receive some sort of block rewards for proofs of bandwidth. But that doesn't, again, link retrieval providers to demand, to the number of retrievals that they're serving. And so we might end in a situation where people are optimizing to win these block rewards, again, for retrieval providing, but it's not linked to actually network demand. And so one of the questions that we're talking about a lot at the moment is whether your rewards as a retrieval provider, how dependent they should be on exactly how many retrievals you're serving, because that's what we wanna really promote in this network, is for them to serve as many retrievals as possible. And if we go back again to this diagram, if I'm not mistaken, I think the IPFS gateway run by protocol labs receives something like a billion requests a week or something in that order of magnitude. So there is demand for these content address files. So then if we're doing on how many retrievals a provider has served, at a network level, that's kind of makes sense. We can try and gather a list of retrievals made and then remunerate each retrieval provider based on that. But the issue then becomes that that's sort of centralized again. So retrieval providers, should they be then paid for each individual retrieval in a sort of a localized way to keep things decentralized? But again, then we're putting requirements onto the clients who are retrieving stuff from the retrieval providers to actually be able to pay for it as a sort of pay as you go approach. So there's lots of trade-offs that we've, there's lots of trade-offs that we're facing with these retrieval providers to try and link them up to the usual clients that people use, such as browsers, but also be able to live in a completely decentralized context and earn rewards appropriate to what service they're providing. So yeah, we're seeing a bunch of different retrieval networks emerge in this retrieval market, which I've tried to crudely put on this web two to web three access. And that sort of involves all these trade-offs that we've been talking about. So on the one hand, we have IPFS gateway and the recent release NFT.storage gateway, which they sort of, they're aiming to really compete with those web two offerings in terms of performance and reliability, but giving up on verification or content-addressable nature of the data. And then moving across to the far right-hand side, the web three side, we have some more purists in this decentralized CDN space who are trying to reinvent the way that we retrieve data. And one I want to talk about in particular is Saturn. We've actually got the team building Saturn here today who do a much better job than I would at introducing it. So yeah, Filecoin Saturn is exactly that. It's the decentralized CDN for Filecoin. At the moment, the way that it's structured is we have gateway nodes and station nodes forming two rings of Saturn around the center of gravity of data in the Filecoin network. The gateway nodes, they are in order for browsers to be able to communicate with this retrieval network. And as such, they have to have a slightly more centralized touch where we're kind of certifying them such that browsers can talk to them and also requiring that they have a very high bandwidth and high availability requirements. But we've also got this notion of a station node. And a station node is going to be a desktop app so that anyone can download this app and start contributing to the network. And Saturn is currently testing in v0. And yes, just to mention now on Tuesday we have a Retrieval Markets Workshop which is an introduction to Filecoin Saturn. So if anyone's interested in peer-to-peer networking, some of the web browser protocols like WebRTC, that sort of thing, some of the crypto-economic ideas I talked about already or just Web3 CDNs in general, then I'll be sharing some links to this later or just come find me and come get involved on Tuesday if you're still around. And I think I'm probably out of time. Okay, well, I just put this in just in case there was a bit of time. And a lot of our time in Retrieval Markets and with the Saturn team, we spend discussing these trade-offs and what the real benefits are of this Web3 CDN compared to Web2 CDN. And I think for me, just if I would just pick one thing out of the slide, I think what's really powerful and it's something actually which Tom mentioned in his talk earlier, it's about creating a more symmetric network rather than asymmetric network. It means that rather than it being client-server, I'm retrieving a file from CloudFare, et cetera. Instead, I can retrieve a file from other peers in the network and then I can even earn. I think that is an innovation which you don't get in the Web2 space that users can retrieve and then earn while sharing that file with others in the network and act as a much more symmetric node in a distributed network. And I will stop there. Yeah, thanks, any questions? Excellent, thank you, Patrick. We started off by saying, forget about storage. Let's talk about retrieval, echoing Eminem. Forget about Dre. Bold words from bold men. Questions to the bold man in front of you. Does the hierarchical consensus mechanism that's currently being researched at Protocol Labs have anything to do with the Saturn project or is there any thought of integrating the two or maybe it's too early along to say? That's a great question. And I would say that, I'm going to be honest, we haven't thought about it yet. I haven't been in touch with them, but it's a great idea. What we have thought about is how we could use, once FEM launches, layer two solutions to them, because there's been so many retrievals. How do we govern all of these retrievals? So like roll ups, that sort of thing, enter the picture. So yeah, lots of ideas about how we can start to manage the sheer number of retrievals we hope to serve. I noticed that you had on the spectrum of web two to web three, myel or myel network, are this right? Can you explain why that is and whether it's desirable for Saturn to be further to the right than anything else? Yeah, sure. I mean, I don't want to speak for the myel guys, but I think the reason I put them further along the axis is because they feel that it should be, each transaction should be paid for in that, just be a local transaction between the client and the person who's serving the retrieval and not be governed more centrally. And so if we want to transact, no one else is involved. We're just, I'll be paying you for a retrieval and you'll be giving me a file, kind of similar to the primary retrieval market. But that puts a lot of constraints on what clients can operate because it makes it very difficult for browsers in their current setup to be able to communicate like that. So in order for a browser to operate as it does now, you have to have a few concessions to more centralized approaches. And I would say that the Saturn team, that's exactly what we've gone for. We've said, okay, we're just going to concede on these few things for now and hopefully we're going to tweak it and make it more centralized, more web three as we build. But we just got to use the browser as is now and try not to change it because that could be quite hard. Excellent. Thanks again to Patrick.