 Luca is here, Luca Nazzardo, I'm pleased to welcome. He is a cryptography researcher in Protocol Labs CryptoNet Lab, where his research interests include vector commitments, contingent payments, and zero knowledge proof systems. And today he will be speaking to us about storage metric style. Welcome Luca. Hey, thanks for having me. It's a pleasure to give this talk. Thanks for the introduction. I hope you can hear me well. I'm a researcher in the CryptoNet Lab, that as you know, since Nicola gave a presentation a few hours ago, it's an applied cryptography working group inside the Protocol Labs. And in particular, in the last few months, I have been working on protocol opportunities, which is basically a working group that is working towards improving protocols for Web3. And this presentation is about one of the projects that we have been working on in the last few months. And it's about storage metrics for retriever incentives. So the main question that we want to answer here is how to incentivize high quality of service. So we know that Filecoin already takes care of file being stored in the network. But if I am a client and I want to basically put my data in Filecoin, I also want to be sure that when I want my data back, the data is gonna be back in my hands. And so just to, I mean, a question that we could ask ourselves is who should I store my file with? Like how do I pick my storage providers? And this project tries to answer this question and we will see where we are, moving towards and how can we get there. So the goals that we have in this project are first, having some on-chain metrics for storage providers that are realistic and objective and that are on-chain. If we have this kind of metrics, then we can use them to reward storage providers accordingly. Not only that, we want that storage providers optimize toward these metrics because it's rational for them to do so. So it's gonna be convenient for them to give high quality of service because our protocol will make it possible. We will put in place a reward system that we aim to build as interoperable with others. Everyone can build some reward system on top of ours and make it work with ours, improve it, refine it and basically do whatever you want. And not only that, we are not focusing only on Filecoin specifically, but we think that our metrics Dow could be also useful in many other applications in Web3. For example, there are other applications that are computing over data that could profit by having some sort of metrics Dow on top of it in order to make reputation systems for service providers, not only storage. So what's the long-term plan? We want of course this metric network to be decentralized like no central authority involved open, meaning that both on the auditor side and on the service provider, storage provider side, it should be incentivized in order to be sustainable on both sides. And it should be resistant to auditor collusions. Like we do not really want auditors to kind of be allowed to set up a cartel and influence these metrics in one way or another. In essence, what we are targeting is like having honest reporting as the best strategy for auditors. And this is as we will see in what follows not so trivial to achieve. How do we get there? So we imagine a network of auditors that scan a network according to some metrics that we identified and that we can update on the way whenever we think that it's the right moment. There is also an incentive to report through metrics and that's in order to make, as I was saying before, honest reporting as the rational strategy. We also need to have a system to aggregate metrics on chain because it's not feasible that, you know, as long as the auditor set scales, we, everyone post is on result on chain. And of course, there is also an incentive for storage providers that provide good service because if not, there is no point in all of this. So which are the metrics that we identified? For now, we identified three basic metrics about retrieval that are time-to-first bytes, average retrieval speed and retrieval success rate, but we are opening the future to introduce more metrics to be taken into account. And of course, this protocol would like to be, I mean aims to be metric agnostic in a sense that you can plug in the metrics that you want and make it work. So what's the overview of the protocol that we have in mind? Talking at high level, we imagine a committee of auditor that query ideally each storage provider individually. The second step is auditors taking part to a survey, which basically is, you can think of it as like answering some questions about storage providers' performances. Each individual, the individual servers are then aggregated, final and aggregated results is extracted and posted on chain. And then both storage providers and auditors are rewarded for providing good service. On the storage provider side, this will have to do with the metrics that they got in the aggregated results. And with the auditors, that would be according to the accuracy of the metrics that they provided to the auditor network. So of course we cannot, you know, get everything in one shot. And we have identified four milestones to make this project happen. The first milestone is the milestone we are actually in today, and it's the initial consortium one. So the first thought on our side was there are a lot of people and a lot of entities that are already scanning the FAQ network for their own purposes, for building a reputation system based maybe not on retrieval, but on other parameters. And so we basically have an ongoing open call for partners that are interested in joining forces with us with the aim of building this auditing consortium. Of course at this stage, even if you know the data that each entity has is kind of partial, they do not really scan the entire network, they do not test retrieval on all the storage providers. At this particular stage, it's fine. We think that it's better to start and to refine everything on the way. And the result of this first stage would be to have a non-chain reputation system for storage services based on the observation of this initial consortium. We envision this initial consortium to be kind of small like five to 10 entities working together as a sort of auditing league. And querying storage providers of Filecoin for technical reasons. The second milestone is to open to anyone to join the storage metrics DAO as a retrieval provider. So basically in the second phase, we are not focusing only on Filecoin storage providers, but ideally anyone, for instance, an APFS node can become a retrieval provider being audited by the network. And we can get there by, for example, using some project that protocol labs is developing internally like indices where people are basically publishing a list of files of deals that they are willing to provide on request. The third milestone is actually introducing incentives for storage providers and retrieval providers. And that would be like where actually we are testing our protocol in the real life, like seeing how the storage providers are reacting to our auditing services. And the fourth milestone would be, of course, creating a reward program for auditors and that will need like crypto economics insights and also allow anyone to become an auditor. So we are basically passing through from a phase where we have a few entities that kind of, you know, are already working on Filecoin metrics to some extent or on storage metrics to some extent to open it to anybody that can join as an auditor like in order to make the auditor league going at scale. So now, which are the very next question that we need to answer in order to advance? The first one is how to structure the final survey protocol. And basically the main issue that we have, I mean that everyone that is working on such topics have is supporting collusion. So we started this journey by investigating some Bayesian truth serum-like mechanism which are used usually in psychology in order to test behavior of people. And we thought at the beginning that that could be something that we could apply in practice because these mechanisms are rewarding unexpected results. So we were thinking that maybe this could basically force people to say unexpected truth and to find unexpected behaviors of storage providers. But unfortunately, I mean, either internally and also collaborating with external researchers, we figured out that such tools were not designed to support collusion. And so they're not kind of applicable to scenarios where, you know, there are entities that are communicating daily together and they can exchange or they can have interest in exchanging information. So the main focus is making collusion irrational for the auditors or at least detectable and in general, making honest reporting being the best strategy. The second question that we have is should we anonymize auditors or making them indistinguishable from generic clients? Why do I say that? So the key question that we want to answer is the key point that we want to answer is we want these metrics to be reliable. And in order to be reliable, basically, we should avoid storage providers to behave in a different way when they're talking with an auditor and when they're talking with, let's say, clients that are not auditors. So here we have two options. The first option is more, let's say, protocol heavy, which is the protocol by itself that anonymizes the auditors. And the second option is auditors actually are, is in their interest to put in place mechanisms for which they can spot such behavior from the storage providers. And basically at this stage, we can evaluate in the future maybe, but at this stage, we are leaning towards option two. And the reason is that it's of interested of anybody that these metrics are accurate. And so auditors can actually either cooperate themselves, they cooperate with clients, they can set up multiple identities in order to make this detection more difficult. But we think that the system is like self-governing himself at some point. The second thing, the other thing that we can, that the one can argue is like most of the metrics that we want to measure depend or are influenced by proximity. And again, we have different options on the table. We can brainstorm about that if anyone has ideas. But one option could be like divide storage providers in clusters depending on the location or like auditors having multiple nodes in different location. And that's something that some organization already have for other purposes. The thing that I want to stress is like all this project works well for everybody and especially for auditors if the measures are accurate. And so it's on auditors' interest to make the measures as accurate as possible because this will maximize their reward. So how can you get updates on this project? We are working in the open. You can go to the Notion page of this project and you can find all the updates that happen over time. The team is composed by myself. You find me on Falcon's Luck on the end of Luca. It's composed by Irene and Nicola. And then we have also external research collaborators focused more on game theory from the Oris University and we have internal engineering support by the Bedrock team. Thank you and let me know if you have any questions. Thanks Luca. Any questions for Luca? Storage metrics down. You kind of touched on this with the voting protocol but I guess are there any other ideas you all have for making sure the auditors don't collude? So that's a really good question and that's something that we are actually actively working on. There are different contour measures. These protocols are basically divided in two steps which are like voting rules and rewarding and payment rule where payment is like the reward that the auditors are getting. And so one intuition that we have is like if you have for example a per round fixed reward and this is like actually your payment rule this would like not encourage you to share your observation with others. Why? Because basically if you are confident that your observation is accurate sharing your knowledge with other people would in the long term lower down your per round reward. Of course this is only an intuition for now but we are kind of confident that we can put this in place. And the other thing on the voting rules are like there are results that add some sort of redundancy and randomness in the voting algorithm that could help making collusion ineffective somehow. We will post news on the website but I mean feel free to reach out if you want to know more. This is something that we are particularly working with our external collaborators on game theory. So I would be much than happy to keep talking about that. So we have time for a few more. Is there any prior art that exists in other projects? Either other decentralized projects like you said research in other areas that would have to deal with auditors and service providers not colluding? So kind of surprisingly it's the best of my knowledge it's not that common to have people studying such kind of protocols. And indeed we try to get around some limitation of the BKS protocol. And actually after talking with many people which is not our primary area of expertise so we had to basically ask other experts. It's kind of an unexplored land and we really think that in the web tree setting it would be an interesting research direction to pursue. And we are actually trying to understand if like a long-term research plan on this is something that maybe we can get into in the future. But it's not the thing is like long story short is like all the work that has been done in doing this kind of surveys did not take into account collusion because basically people were not really interested in getting other people's opinion. One classic example is like you are in a department store and people tell you do you like more this book or this other book and you want to basically build the survey on that for this kind of situation there are BKS mechanism that work pretty well and force people to tell the truth. But if you think about this for a second you are not really interested in what other people are liking like you are happy with what you like. While instead here and when you basically put incentives on top and when you basically enter in systems like blockchain where people communicate and exchange information all the time it's much more difficult to come up with something that is kind of effective. We have time for a couple more questions. Any other questions to Luca? If not then I have one. There was a mention you mentioned the auditor system their identities they want to work on sort of a secret shopper model with the storage providers maybe so they don't have to there might be some identity obfuscation there. Can you walk me through again who knows who the auditors are? Is there who's holding that kind of information? I mean, that's exactly the point. There are two options here that is the option where nobody knows who the auditor are especially when they run the survey. Like maybe you know that there is some organization who is an auditor who is auditing the network but you don't know like under which identity is auditing the network but you can always backtrack and do this kind of thing. So either you enforce this by protocol but this adds some sort of complexity burden to the whole protocol or you basically play under the assumption that since being undetectable and having reliable metrics is uninterested of all the auditors then the auditor themselves would put in place their own countermeasures which can mean making deals with like clients which would mean like having different clusters that query different storage providers and so on and so forth. And for now we are basically leaning towards the second option. Wow, thanks again Luka for walking us to that very complex system and the system design.