 Today in this fork we are going to focus on a way we can guarantee retrieval from for users that are storing their data in a decentralized storage network and in particular while we're thinking about how we want to solve this problem we want to solve this problem for any kind of data so we want to be a web scale we want to assume that we are dealing with the entire data from the web and this in particular means that we don't want to have any constriction of the onboarding throughput of the data for these kind of solutions. This is the agenda for my talk and basically the first topic I want to talk very briefly is Kryptonet. Kryptonet is the lab I'm a researcher in a protocol lab and we are an open distributed research lab this means that we are a small set of researchers that try to not just we worked on research and primitives especially photographic primitives that are the building blocks for web 3n and distributed storage but in particular we also try to bring this work to the entire community and influence the entire research community to what we in the direction we think are important for for web 3 and this some of the results from this lab are papers like here you see some of the published papers there are more on submission from DZRs another line of work brings improvement for the five coin protocol many fibs the last one for example snap dealers knockback you may heard of them if you are following five coin protocol but more in general we have like a lot of ideas we open in we work in the open so all the ideas that we even are just brainstormed you can find them in our website in our notebook and the nice thing is that some of these ideas they manage to become a first protocol protocol design work and then real product one of these is the project that I'm going to present today the data retrievability consortium before speaking about data retrievability I want to spend a bit of time on related problem and concept like data retrievability in order to build up the the the definition of data retrievability and understand it better so if you are like following recent scanning solution for xarium or in general for blockchain you may hear about the data variability data variability is a protocol that has two steps this dispersed and retrieval steps and it's about first you disperse the data in the storage in the in the storage network and this means that the the the owner of the data the client will do some processing of the data and process the data and then basically you can think split the data in many blocks and and send this to the network of the storage providers this is going to be some kind of depends on the protocol some kind of agreement on the fact that this dispersal was was done in the correct way so that enough notes received enough blocks and if this is is this step is successful then we can have later on when is needed the retrieval step that is giving back the data so oops sorry what what we have here is basically a protocol that gives you also retrieval but only when the dispersed is successful and also has to assume for the retrieval tool to happen in a successful way that a fraction and how much depends really on the the specific protocol that they know that receive the data in the first step are are honest and willing to serve the data so this this protocols there are many protocols that are very efficient that works very well but they work well with some specific data like for example as I said they are good for for roll-up solution because they work well for small data like status the roll-up the data you need for roll-ups because you mean the you still have to go to these these dispersed steps first of all that requires a consensus or some kind of like consensus so this limits your throughput of data so you can think about using this for web scale data and of course as I said the retrievability is not fully covered in the sense that that it works only if there is an honest provider or not in a provider network that is going to to serve the data something related to to data variability is the more general proof of storage proof of storage for example is the building block of five coin and here you can think you still have two steps so you have the source step where actually now it's it's like the client going to many different providers or not in the network and with each one of them is going to create a storage deal to store the data then these miners they're going to use these data the fact that they have the data to create this proof of storage okay each one of them that can take their own proof of storage and the proof of storage then is used to it is registered is appears on a blockchain for example five coin and is used to mine to mine the the native coin there the native token there and and this gives incentive to these providers to actually keep storing this data so there is a strong incentive mechanism here that assure this step is done in the correct way and the retrievability is again just live as an assumption that there are if you client to store your data with enough providers and there is going to be some of them that are available to sell back the data when you need so the nice thing of this solution that the incentive economics first of all and second gives you unbounded throughput so this this client in there can now really upload any data very fast is not is not bounded by any consensus algorithm on the data itself and and but as I said the retrievability is again somehow let me say under specified so it's just say okay we there are going to be one provider willing to serve the data this our assumption okay so now that we have seen these two problem I think it's clear that there is some maybe missing point here or like something that we miss that is how we can go to the retrieve step and make it stronger not just assuming that there is some honest note that is going to serve but that we can have a strong incentive exactly how like we have for the second one store so that is exactly this we think that we can create we want to create an incentive system for the the provider to serve back the data to retrieve the data how we can do that well if we can have something like similar to the proof of storage let's call it proof of delivery then we can basically do almost the same same same scenarios the real problem is that there is not a proof of delivery this is like almost we can call it that there is there are impossibility results in this research area that says that if you have just a client provider and they start to complain that the client asked the data but the the provider didn't give it back you don't know which one of the two is lying unless there is some other assumption and we need the the assumption that we need someone that is the witness of this delivery so let's let's see a bit better what kind of assumption we we we can have and and by the way I didn't say it at the beginning sorry but like I'm if there are questions in the middle feel free to stop me sending the chat or some way and I'd like you to to to stop an answer in the middle if it's more useful uh so let's see some of this uh some of the assumptions that we can have to this scenario's client provider to make it uh data retrievability possible one first idea that we can have is use the blockchain itself uh as a witness that is meaning forces that are provided to store everything on chain the chain sees the data and the data are then we can retrieve the data from the chain this is unfortunately too expensive for large data this can work for very specific small uh type of data um another idea is using a proof of retrievability proof of retrievability is something that is known in the literature and and it's like an interactive protocol it's a proof system basically between the approver and a verifier there is a protocol that they need to to to follow uh there are actually many different flavor of this of these primitives and and the property of these primitives says that at some point if prover and verifier like client or provider follow this protocol basically after some repetition of the protocols the answer that the the provider is giving to the client that is checking the storage of the supervisor will leak the entire data the problem of this solution is that again as the same as before we need too many it's not it's not efficient because we need the really many interactions so it's going to be a retrievability that is very slow and through time it's not one shot say retrievability um so what we we we tried to to to come up was like some easy way to have a witness an oracle of the retrieval exchange why uh why that having this oracle that is that is a witness of the of the exchange works because say that you have your client doing the the the deals with many providers but then no one of them is actually answering the retrieval query from this provider if we have an oracle the client can appeal can ask to the oracle to basically repeat this retrieval request to the all the providers or one in particular okay and this oracle is kind of trusted to answer what he really is going to see the answer that is really going to see from the provider um and if the provider is in this case not going to answer since we trust him we know that the client is the honest one and is is claim about i'm not getting my data back is is a is a call that is a truthful one and we can do some action for example we can punish we can do some apply some penalties with the provider if the provider is going instead to give back the data to the oracle we are at the same way because this at this point you can just assume that the oracle is going to send back to the client the data so in this way we basically construct the way or where the data are given back to the to the client or the provider going to be slashed so we can some guarantees like we can say hey provider are going to to send back the data to do the retrieval serving the correct way because they don't want to be slashed so the question now is how do we implement this nice guide oracle we don't want to have a clearly a centralized party to do this so what we did we create basically a solution that has a small trusted set of practice that we call the referees this is what we called it this our solution is the data retrievability consortium and is based on having this referive committee so you can think of this about the network of special notes called the referees it can be doesn't have to be very large size can be small like 20 25 notes is enough we don't have to trust all of them we need to trust a fraction of them for example in our prototype we assume we trust half of them and now the protocol goes like this and basically client provider they will agree of chain they can do a retrievability deal means deal means that they agree on the duration of so for how long they contact is is valid some payment for this service from the client to the provider and some collateral so the provider is going to lock down some collateral that will guarantee the retrieval okay and it's actually the one that we are going to take from the provider if it doesn't do that uh so if the client is satisfied with the retrieval service nothing happens if the client doesn't get requested for service for for a deal for a data that he has a deal on it can appeal to this small nectar of referees and this nectar will basically just they will do what I just explained before with the article they try to retrieve the file with the provider if they succeed okay fine the forward the file to the client if they don't they're able to take the collateral that was locked down and basically uh born in or like just just remove it from the balance of the provider so this is the high level what is really important how at least we spend a lot of time to optimize how the real the trial so the what happens after the appeal from the referee by the referees how this is done because first of all we want to guarantee that you know even if some of the referees are somehow are malicious and they collude maybe with the malicious clients would provide them as no slush and we want to guarantee that if some referees are not online provided that the doesn't get slushed the good ones so we have to think and also we want to be efficient we don't want to like just go all 20 referees go and ask the file and the provider to answer to all of them this kind of situation we we want to we wanted to avoid those so after some some research we we can come up with the protocol that has actually actually rounds in each round only one of the referees to ask the file back so the provider has to answer only one referee and then the referees is responsible to convince the others that the correct file was was obtained and we actually need like several referees to say okay this provider is really bad and then only after some of them like say again a fraction one third of them that really agreed then we really slush the the provider so we have all these like a security measurement in place and what I want to say is that we have a in April we managed to have a small prototype of this that is implemented basically by a smart contract that is live on an Ethereum test neck and thanks to the smart contract there is the smart contract then three only for this prototype referees that are simulated by by by by us basically you know in some of our by our code in some of our machines and the smart contract is can be used to create the deal that is going to be posted on chain and can manage the deals that can do this lashing so we drove the funds from the funds from the provider you can play with the prototype with this client demo that we have a plgl.dev and if you if you go to this website and you connect your metamask wallet you can play I see create a deal and manage your deals after that after the test of the prototype now we are working for shipping a real test product so and the plan is to ship something at the end of October so end of this year we have some intermediate milestones the the first one is to actually have the product ready I'll say a bit more about it now what we mean by going from prototype to product and the second one intermediate milestone is actually to find and board partners and find the right product marketplace so if you think you can be a partner or this like provider or especially you want to be a referee please contact us as soon as possible because we are super interested in this kind of collaboration and going from prototype to product means that we want to make this more usable and and more more flexible for example we are working on adding NFT collections for showing the deals so if you are a provider you are doing deals you are all these deals will appear in a specific NFT collection so it's going to be very easy for you to show that you have many deals active and to manage your deals you can even create a market of these deals later on we are working on adding an admin function to the contract to change the parameters that we are putting there we are working on a reputation score based on how good you are in doing this refurbished deals as a provider and we are working on for example working having an idea not just for one specific file but for a collection let's say a folder of file all these are features that we think are important to really make this something that we can use in in the other storage scenario and we also have some planning about documentation and a website and that's that's it thank you a lot for information for your attention any any question I'm very happy to answer I want to thank all the team and this is not my project is a fit to net project and I work on this with Luca and Nicola but I also want to thank Alex and Nicola for the feedback and the implementation is done by Yomi Digital and we have Jonathan from the helping for PM and also thank you a lot for the crypto economic team for all the review the crypto income review part and especially to Danilo