Hello and welcome to Filecoin Crypto Economics Day here at DevConnect in sunny Amsterdam. My name is Karla Kirstenow and I'm the lead of the Network Research Team at Protocol Labs, where I've had the pleasure of working closely with the crypto economics researchers at Crypto Econ Lab. We've assembled a fabulous lineup of speakers today to lead you on a whirlwind tour of the fast-paced world of crypto economics and the Filecoin ecosystem. Filecoin is a decentralized storage system designed to store humanity's most important knowledge and Filecoin's unique crypto economic system is central to its design. Since Filecoin launch, the network has grown to include over 4,000 storage providers with more than 16 expedites of storage and the network's momentum continues to grow. Along the way, we've designed a functional two-sided decentralized marketplace, created an innovative first deployment of EIP 1559 and championed scalable Layer 1 research. We're building data-driven analytics for network governance and evolution, developing Filecoin to become a data availability layer for Web3 blockchains and introducing new Web3 building blocks with new business opportunities in reputation, retrieval markets, data dows, compute over data, and other exciting areas. And so Protocol Labs Crypto Econ Lab decided to put this event together to share our research findings, opportunities, and challenges with the broader Web3 community. So we'll have about 11 speakers today, that's enough to round out either an American or European football team on a variety of topics, exciting topics related to crypto economics. Each talk will be about 20 minutes long, including time for questions. If you're participating virtually, please put your questions in the chat, and then they'll be relayed to me and I'll read them out loud to the speakers, if time permits. And so, without further ado, let's introduce our first speakers, ZX Zhang. ZX leads Crypto Econ Lab at Protocol Labs, where he studies the intersection of networks, incentives, and optimization. He'll be giving us an introduction to Filecoin, crypto economics, and its opportunities and challenges. Welcome ZX. Thank you, Karola. And well, my name is ZX, and I lead Crypto Econ Lab at Protocol Lab. I'm super, super excited to be here. Thank you for all the organizers for putting together this amazing event, and thank you to all the speakers and you for coming to our event. The goal of today really is to like kind of showcase, or my talk is to showcase the scope and this range of topics covered by Filecoin Crypto Econ, and its amazing opportunities and challenges. Here's our rough agenda. So we start with what is Filecoin to bring everybody onto the same page, and then we talk through some on a high level, some of the crypto econ challenges that we face when designing and governing the network. Then we talk about some of these latest exciting opportunities, and many of these could be either start opportunities or like just interesting research ventures. And then lastly, we just covered the agenda of a Crypto Econ day today. Just before we get started, we are hiring a Crypto Econ Lab. Our aspiration is to be this hub that goes from research to protocol, and then protocol to product. We start with work with university and research groups and all the general incentive research topics that is central to Web 3 and Crypto Econ. And the other really interesting exciting aspect working in Crypto Econ in the Protocol Lab network is with us there are always many new interesting upcoming protocol and research in cryptography consensus, which you guys will hear about some aspect of that today. And they always call for the need for new incentives. Of course, there's always protocol improvement in governance, and then we also participate very actively downstream in the network analytics and ecosystem. After all, the success of an economy really depends on the success of this ecosystem. So that we're hiring across the board from research engineering to product, if there's no road that suits you, feel free to email us and then we can always carve something out. And then we sort of also pioneer champion this Crypto Econ process, design, validation, deployment, and governance. So this is something that we kind of like apply this systematically in thinking about new problem, and how do we model them, how do we design around it, and how do we know our design is good. And then Crypto Econ is really interdisciplinary, as we can see from this diagram here, and then we are looking for collaborators from different backgrounds and experience. Without further ado, let's dive right in. So what is Filecoin? So there are many definitions of what Filecoin is, and here I'm giving one that from our take at Crypto Econ Lab, where Filecoin is besides being a storage network, we think of it as like a layer one protocol that starts with data. And then it's also a multi-sided marketplace enabled by blockchain, which also makes working in crypto economics on Filecoin so interesting, because there's suddenly tremendous scope. It's like a live economy running with different kinds of marketplaces emerging on this system. It's also an island economy. People are massing cloud resources and building new experiences. I want to highlight new experiences. As much as like storage is really cheap and competitive on Filecoin today, I think for Web3 to win, it's not about cost. It's always about the new experience, and thinking about new incentive structure, new marketplaces, and that's why it makes it such an interesting place. It's also an Airbnb for cloud services. It's a platform where anyone can become a storage provider, or a compute provider, or a connectivity provider, which we'll hear more speakers talking about later today as well. People will come together on this island, amassing different resources, and then offering this network of utility to the outside world. It's a really passionate research, engineering, and product community. I hope after today, you learn more about our unique opportunity and challenges, you will choose to work with us. Here's a stakeholder diagram of different participants on the Filecoin network, where storage providers provide reliable and useful storage and get rewarded by the blockchain work. We could incentivize other things as well in a decentralized manner, but the other things are much harder to prove. There are many teams in our ecosystem working online, improving the verifiability of these metrics, which you will also hear about later today. In some setting, let's say we can't verify completely, can we design a new incentive, a new market structure, reputation, and metrics? There are other teams that will talk about this today as well. Then our client today, they can only store data on Filecoin, but they will soon be able to do a lot more when a user defines EVM smart contract coming to Filecoin. We also hear different teams talking about that today as well, and developers actually have to build new experiences. As I mentioned earlier, it's not about cost, it's about something new. That's what all these exciting opportunities come from. Tokenholder State Filecoin, which is another big opportunity, and the ecosystem partner create a myriad of initiatives to jump stop the ecosystem. This is like a comparison in terms of Filecoin with other storage networks, as we can see within the Web3 space, that pretty much is like a dominant pair. However, from our ecosystem perspective, it's not about Web3.us versus them, but more about how can we bring even greater adoption from the traditional Web. In comparison to AWS, well, I think we're only another 10x to go to catch up to the size of AWS. Also just to call out, all this capacity and adoption was only a massive study over a year, which showed this tremendous power of crypto-economic incentives. But we are still just getting started in our quest to build greater adoption on a Web2 scale. Filecoin is a layer one. We implemented a version of EIP-1559, roughly a year before Ethereum mainnet. Back then, we had a set of requirements of our gas model and it checked the boxes. This is the network transaction fee on Filecoin since launch at its peak. As we can see, it's actually consumed more than 200,000 Filecoin in a day. And then there's an interesting dip here, which I think some of us are going to talk about this as well. And how do we really design basically the short context here in the interest of time is Filecoin introduced an upgrade that scaled the network 10 to 25x at this point in time, but then some other things happened such that the network ended up consuming less fees. But we believe this is long-term good for the network because that makes it cheaper to participate in the network. And this kind of touch and tie into something more interesting about blockchain gasses in a world where scalability is no longer a constraint. One of our researchers will talk about that. How do we think about the new gas model from a crypto-econ standpoint when blockchain scalability is no longer a constraint? So with this brief overview of Filecoin is a layer one. It's a marketplace and Airbnb for cloud services. There are many things we can provide beyond just storage. Now we want to talk a bit more about what makes working on Filecoin crypto-econ challenging. I think it really boils down to we try to do some of the network as a whole or also the protocol lab network as a whole in vision to build a network of utility where we want to make blockchain useful and then we want to make blockchain internet-scale. So instead of the blockchain merely just execute a transaction, there is something that blockchain wants to do. It's about building an economy to create something of value about empowering traditional businesses. So that's what a lot of our goals and constraints challenges come from. I want to do it in a decentralized permissionless and a trustless ways as much as possible. And this is where a lot of constraints come in. But it's a progress as a community. We have like more than 4,000 storage providers, more than 10,000 developers building our ecosystem, and then we exceed the 16 exabyte of storage capacity with more than 70 petabyte of data stored. And then you have a global community of storage providers. And also something that struck me during this DevConnect was, I think maybe like a year or two ago, the crypto-econ community was tiny. But I think during this time in Amsterdam, we actually see multiple projects working on very similar issues within the Web3 ecosystem. And we hope that throughout our talk today, we get more people excited and interested in working in Web3. So I don't talk through some of the high-level key economic policy that we picked and some of the concerns that went with Powerpoint just to give people a glimpse of some of the trade-off and considerations that have gone into it. So the biggest lever that we have is the block reward policy. Before Filecoin, most of the crypto system kind of adopts something of a flavor of an exponential decay where it came from the Bitcoin land. The early adopter gets disproportionate reward and then goes down from there. We identified a few issues and constraints with this early on. Sometimes when you give the most reward at the beginning, the network is the least mature and it's also the smallest in adoption. We want the network minting to kind of be aligned with the network's utility. Together with our collaborator at BlockScience, we innovatively came up with this mechanism called baseline minting, where the block reward is minting based on the network KPI. And then in the case of Filecoin, because storage is the only thing that we can prove, we have this exponentially increasing baseline, which is a target, the KPI, that the network needs to hit in order for the minting to be at its maximum potential. So in reality, the network will be minting somewhere in between these two bands. We are minting based on the utility that a participant provides to the network. So this is like a series of empirical data we are more than one year in. So the network started with below the baseline and it catches up to the baseline in April last year. And then we can see like the block reward was kind of the daily, the per e-part reward slow in the beginning and then slowly climbs up and then now it's following exponential decay based on the initial promise once the network is crossing over the baseline. So the area under this curve, which is this part is invisible here, this whole section, our reward, they were not minted because the network was not hitting its KPI. And this, all the reward here are being spread across to give more sustainable reward in the future. The other important policy is collateral. We want to align all the sort of providers incentive with the network. So we want to make sure the storage is reliable, which turned out to be pretty reliable. We want to make sure people are not violating the consensus security of the network. So there's both the initial storage collateral, but there's also the initial consensus pledge collateral. So this is how I love how people mind become participants of sort of providers on file point, right? They are barred to token, they kind of like commit, let's say like when you have the supply of storage, but there's no demand for it. You basically put that into a storage container. We call them committed capacity. You put this on file point as well and then you commit to the network and say, hey, we are going to prove this amount of storage on the network. And here's my collateral. And then when demand comes around, people can then say, oh, and I will take out my container, and then I can slot in the demand, I can slot in the deals. This analogy here is like empty Uber car driving on the road to demonstrate, hey, we have demand for all this, we have supply for all this capacity. And then when a client comes around, they can flag down a Uber and say, hey, I want to get into the car. So this is made even more true with snap deals. Now people can just slot in their useful data into the capacity on file point. And then one year in, like we lock I think more than 120 million file point on the network as collateral. If you compare that with like any of the DeFi protocol, you'll be easily ranked as among the top five across all web three. But this is another aspect that people don't talk so much about file point. And then this is also the percentage of the circulating supply being locked in file point. Again, there's also major opportunities here as well. But I think some others speak a little bit, they will speak more about them. Then the other interesting aspect is like slashing policy, right? This is also pretty interesting. So people before Falcon launch, people always talk about, oh, how do we guarantee some kind of quality of service on the permissionless network? And then it turns out crypto econ is to the rescue. So on the high level, the Falcon blockchain will come around every storage provider and ask them, hey, you said you're storing my data, where is it? So the provider will say, hey, here's a proof of me storing it. And then the blockchain will check, okay, good, you have it. If not, oh, no, you don't have it. And then you get slash for not, for not storing the data that you promise to both the clients and the network. So on the right side, this is the chart of like the daily thoughts of Falcon, as we can see the share of this chart highly correlated with the daily fault penalties on the Falcon network. And then later on, I think there's another talk that talks about a penalty and how how incentive is doing a really good job is making sure the file coin storage is super reliable. And then there's also gas policy, because after all, it's a layer one, right? Like we implemented, yeah, it's a different variant. And then like we had like two other variations here. One is this over estimation, we started since Genesis, basically, it has to do with how the VM execute messages without going to details. And then we also introduced a batching dynamic because file coin is a very, that's my personal take is one of the most scalable chain out there. Sometimes like from the crypto econ land, we sometimes will ask our engineer, hey, can we slow down the scalability so that we let the man catch up to the chain, right? But we introduced this like 10 x 25 x improvement in scalability earlier last year. And then we also introduced a batching dynamic to kind of like to to balance out the balance of the incentive misalignment. There's a whole separate talk there that we're not going into. But that's something interesting, some of this, some of this innovation that we did a modification that we have done to the gas policy. There will be another talk, I think, by the block science team on gas today as well. So another challenge with so we talk about all the policy side. But unfortunately, as like crypto economists, our job is not done. Once the protocol goes live, there's still like governance analytics. So we also developed this like Falcon improvement protocol and thinking about governance, how do we decide what policy go into the system? So FIP model after EIP, Ethereum improvement protocol, anyone can propose a fit. But then sometimes it's like a fit could be seemingly innocent, or it could be universally positive, but then they actually have a very profound people you call impact, right? So we also develop a governance process within crypto econ lab. And we just we start from we first take a look at the idea we perform a smell test that the smell good for the overall economy. And then we we do an impact surface assessment, right? Like if it's a very small impact surface, but it's also a very big improvement, there's no brainer. But then sometimes a big impact also comes with big impact surface. And then we need to go into a lot more considerations. And then we do analytical analysis, where sometimes we just modeling writing out the analytical equation, which you will see quite a lot from our colleague today in the various aspects of the work. And then and then once that further, sometimes we do modeling and simulation as well. The challenge with crypto econ sometime is there's no right or wrong answer. And then the outcome can also depend on many external factors as we can see from some of the hyper drive example. But of course, we also invest a lot in analytics to make sure that whatever policy we pick as a community, we have like real time feedback and how we're doing and analytics can also inform what are the most needed areas of the network and how can we improve network governance as a whole. We hear from a starboard team later to talk about how we apply analytics in network governance. There's a dashboard and then there's also both from the network level dashboard and also from the actual level dashboard. And this is also like about how people behave and stand in the network. And this is something another call to action here. In a traditional web world, people already study data to its bone, right? Like everything is going to analyze on a traditional web. And the case of web three, everything is public, right? Everything is public. But people, but we are not spending nearly the amount of effort to understand what's going on and how do we use those insights to make better informed decisions and how do we improve the welfare of everyone in the ecosystem. So there will be more talks on this topic today as well, but I highly encourage you guys to check it out too. Now that we talk about all the challenges between crypto, Ecoin and Filecoin, let's also talk about the opportunities. So as I mentioned earlier, Filecoin is one of the most scalable chains out there. Even today, Filecoin is the largest deployed snack network in the world, right? Like we hear talks from our cryptography team later today as well, talking about some new direction that they are checking out. And also, as I mentioned earlier, we did this 10 to 25 X increase in scalability earlier last year. And then there are more up in our researchers, up in our research team's sleeves. Given this kind of increase in scalability and the parallel to the Ethereum world would be like, what happened to Ethereum after all the roll-up solution comes online, right? Like, how would it impact the macro of Ethereum as a whole, right? So this presents lots of interesting questions from a crypto economic point of view that's not frequently asked. And later today, there will be a, I think right after this talk, there will be a talk on how we're thinking about new guest models in the post-scalability world. Another unique value of Filecoin, in my opinion, is really like this verifiability of data, and you have a proof that data is online every 24 hours, right? So in some sense, in my mental model, where a CID, which is a content identifier, which is a unique hash of the content of a piece of data, right? Like in my mental model, an NFT is nothing more than a unique representation of some digital content, right? You can technically create new interactions beyond just trading on NFTs, and then you bring the value back to the content itself, right? So you have this pretty unique building block that's coming onto Web3, where you have like verifiable content that's being proven every 24 hours. And what are some new interactions that we can build with this? And I think we have another talk today that dedicate towards this as well. And then this is another interesting building. This is kind of illustrated what we were talking about earlier. You have this IPFS layer of like, of a CID, which is the hashes of the content. And then you have the Filecoin layer, which bring you the proof and the internet level scalability, right? Previously, people can try to do bridges to other smart contract platform where you can do the business logic that opens the door to a whole range of business applications. But even more, even more, as an even more exciting updates, user-defined EVM smart contracts also come into Filecoin, right? So this is what we call FEM project, where now you have smart contract and also like provable storage. So kind of a challenge to the audience is Web3 evolves in waves, right? Every time there is a new building blocks, we always have, we get excited about them, but sometimes we haven't figured out what do we do with them. This is the case of ICO in 2017, and then that gave us a DeFi and CryptoKitties and FTs. The challenge here is now we have a new unique building block. What are some new experiences can we build? And then we have some other speakers sharing their kind of perspective and ideas here as well. And lastly, we have massive amounts of data being capacity, massive amount of data being stored, and then how can we, and then now people are also building different retrieval markets on top of that to really retrieve this data and then put in the context and use cases that they're using, right? So my personal take here, the retrieval is really context dependent as well. It depends on the use case, on a technological level, nothing that stops you from, that stops data from being retrieved. It's more so like a business use case, more so like a product market, that kind of question. But the good news is there are many, many teams working on this, and then we also hear another talk today by Patrick talking about retrieval markets on Falcone. And yeah, lastly, today is Falcone CryptoEcon Day. Today is the day you guys at the right spot. I'm very happy to have all of you here as a fashion earlier, where like in maybe just two years ago, it's very hard to pull together a CryptoEcon event. There aren't that many people in this space. I'm super, super excited. Now we have more and more talent, developer, researchers, mind share, interested in CryptoEcon, and I hope I have sufficiently convinced you in the context of Falcone, there are so many exciting opportunities and challenges with CryptoEcon. And with that, thank you for your attention. Great. Thanks for that, ZX. That was a great introduction and overview to the content that we'll be enjoying today. I don't think we have time for questions directly to ZX, but I'd like to point out that we have several members of the CryptoEconomics Lab here today, if you want to ask them in person during the break. And many of the things you may have questions about will be covered in the upcoming talks. So we'll move on to our next speaker, Axel Cortes-Cubaro, who is a research scientist at CryptoEcon Lab with a background in statistical physics. And he'll be speaking to us today about a gas model for a post-scarcity era. Take it away, Axel. Right, so, okay, so I, everyone here is making? Okay. Right, so I want to, my goal here is to introduce you a problem that maybe you don't know you have, and then not give you the solution to that problem. But I just want to, like, introduce the possible space of solutions for this kind of problem, which is, in short, it is like, maybe there's a lot of people focusing on how do we scale the blockchain, make it more powerful, more powerful, but basically to understand what could be the problems associated with that, or if we want to think maybe not just scale as much as we can, but scale as much as we should. That's the question. So I just, I'll talk a bit about gas in general. So, just very briefly, so gas is, what I mean by gas is just like a unit of computational effort in the blockchain. So, like, all these transactions, all the nodes need to validate that it takes effort, everything that is included in the blockchain. So, it is the amount of gas that you could have in every block, that you could use in every block is precious. It's scarce, so there's only, you cannot put all you want in there because everyone needs to validate this. So the point is, it's scarce, so it should be optimally used, utilized in a sense. So, the idea is that there should be an optimal block size that you should, so this is like the amount of gas that we can all fit in a block and we can handle it. Anything more than that, and it's too much for the whole network to process. Anything less than that, and the network is being utilized and that's not efficient, so it should be used better. So, the idea is that you should price, so it should be used optimally, and the way that it's done is basically it should be priced at a market clearing price. So, the idea is that the amount of what you should pay for a unit of gas should be the optimal value such that only the amount of transactions that fit in the block size that you're aiming for can afford this price. So, anything else would be priced out. So, the idea is that you want to select only the most valuable transactions to be included on the block. So, you move the price until you reach that price that only this exact block size makes it through the market clearing price. So, this is a normal like limited blockchain where you have scarce gas like only this amount of block size available. So, the next question is, so how do we kind of reach this market clearing price? There's different approaches to this, so there's like the original Bitcoin approach is just a first price auction which basically amounts to like everyone just makes a guess about what is the market clearing price. So, you submit your transaction and you make a guess this is what I think this is worth and everyone out there makes a guess and those with the higher guesses get through. That's how this works and that's a mechanism that has worked. Okay, but the idea is that this tends to be very volatile and people aren't great at estimating or so you might end up overpaying and the prices can fluctuate more. So, the approach we're using in Falcon and Ethereum as well is this called EIP 1559 where the idea is that as you price gas not just by the amount everyone voluntarily guesses but you have a base fee which is set by the network. So, this is posted, this is the base amount of fee that you need to pay for your gas and you can put something on top which is meant to be just like to cover the marginal costs for the miner to include your transaction. And then this base fee the idea is that this is now not paid to the to the miner but this is burned and this evolves in some like definite algorithmic way with the point being that this is adjusted based on demand on the network. So, in this case you allow the block size to be a little bit flexible but you set a target block size. So, this is the optimal block size that I want and if in a given block I spend too much gas then I raise the price so that the next block will be closer to where I want it to be. So, this adjust the base fee such that the idea is that this mechanism should equilibrate close enough to the appropriate market clear place because these are different options. Yeah, but so this is what we are using about. So, one point is that so this price doesn't come from this mechanism. So, one of these shouldn't this EIP 1559 will not make your transactions cheaper or anything where this price comes from is just from supply and demand. So, these are two mechanisms just to try to find out what the price is but they are not what is used to determine the price. So, the price is simply just supply. So, in a fixed blockchain like we are talking about with a fixed with a target blocks size supply is fixed. So, this is the amount of gas I have for block then if more people want to use this if there's more demand that will lead to a change in the price. So, this is basically the kind of a symbolic equation showing the the dynamics of so if there's a change in demand if demand increases then I should increase the market during price such that I remain at my target block size and if it's demand reduces I should reduce the price. So, one question that we think about for the script economists that maybe many engineers think less about is like do we actually want to decrease the market during price. So, this is a big complaint okay gas fees are too expensive so and so we could tell the engineers okay make it scale everything make it better make the blocks larger so we can feed more stuff and that should give us a lower market clearing price right and and that's something like CX describe is kind of what happened with this hyperdrive that suddenly we have this boom hour now we can process a 35x times the the amount of gas in the block and the question is this something we should do is this a good deal right and then we need to think about what is a good deal right and the reason why you might think that makes sense so let's make it everything more scale up we can include more stuff but but there's something you're losing by by this collaborative which is you are reducing your your market clearing price right so miners were complaining oh why did you make it so scalable now I'm making less money is the idea. So, yes I want to think a bit about so I want you to think about this question of what is a what is a good deal for the network should I always scale or what should I do so one one strictly economic way to to think about this question is just to think about the the total network revenue right so the idea is that if I increase the supply the the market clearing price will be reduced so this is bad right people are making less money but the idea is that now more transactions can get processed such that sure each one will will cost less but but there's more being processed so that's a net good right so so you can think of it so what is the there's this total network revenue it's just like what is the the current price times the amount of transactions that that you could process right so so if I scale and this gets lowered but this gets increased enough that overall this is this increases and that's what I would call a good deal economically okay so for instance this is what didn't happen right away in this hyperdrive that CX talks about so you scaled everything the base fees went down and the demand to reach that level that we needed the 25x is still working to reach that level so that's what could be considered a bad deal you might you might question like is this are we being superficial here that we're just like a good deal is just make more money but for now we'll leave it okay so this this is something to think about but that's that's one goal we could use to to work on but I think it's not that superficial in the sense that so what we want is we want to have like a healthy and very useful and active network and that involves miners being motivated right so so if the rewards if the revenue is good and rewards are good the miners will be there will be more miners or storage providers in our case in in in Filecoin joining and they need to be properly motivating to bring more miners and make it a good network so so so the general principle that I guide myself with is so the supply that we have that we provide by all these scaling solutions should be just appropriate for the level of demand of the network not like much higher than the demand record yes so just a little summary here of kind of a typical scaling solution that that we can see in the blockchain space but it's just like making a roll up or a side net on the on the so the idea is that as if you have your main net your Filecoin or your Ethereum or whatever and this is too expensive to use you can like make your own little side net where you run run your your your sub transactions in there so this is what happens like an exchange or something so okay so this exchange is going to make all these transactions and then only at the end report the the the final result of that to the main net and this allows you to do like more transactions maybe at a faster scale you can do more things without reporting each one of those without using gas on the main net for each one of those right so you only spend it here and then report report only the result after after that and so that has a result so that that so having many side nets like this could take some some demand away from the main net because these are all transactions that could have been performed on the main net but now they don't need to be performed there so that's something to to think about right at one point of this is that right so the side net that you're running your sub transactions in should have a lower market hearing price that the main net if not like user for just go back to the original net but the tradeoff is that the main net is expected to be like the with the higher security and a better reputation right so that's why you want to report back your your your final results to the main net and make them more permanent there so this is the idea so the subnets should be cheaper but less security and less reputation and so on so that brings me to this is a this is a project that we're working with is mainly consensus labs of a project that it's a solution we are working in in falcon that this could be what scalability looks like for falcon which is what they call hierarchical consensus and the idea is similar to to to this stuff about about side side nets that I talk about but just more hierarchical I guess so so here you have your main net which I guess this represents time or something but anyway so here you have falcoin let's say and then I need I have more demand that I can handle here so I spawn a subnet here so it's so you can spawn a subnet and here I process transactions fast and then I am checkpointing total results back to the main net but not everything that happens here so similar to the to the side net roll up kind of thing and so here this one has two subnets but then the idea is that when there's too much demand here also these ones can spawn their own subnets so and then these ones again could spawn their own subnets if they want and so on so so this this idea of of hierarchy of of nets that how they are connected is basically so this this one runs their own sub transactions and then periodically they post their checkpoints back to the to their parent net right so so this interaction subnets checkpoint back with their parents so the subnets remove some demand from the parent but then they also ask for something because they need to spend some gas on checkpointing with the so there are checkpointing gas fees when they checkpoint with the parents and and the rest of the idea is also that the the parent chain should provide some level of security and reputation through to the subnets by keeping track of their checkpoints right so they're saying oh this this there is some more permanence to these transactions and also there will be a collateral that can be slashed to start running this net so so you guys okay so I want to start a subnet if I want to start an official subnet with this parent I need to freeze some some amount of collateral that may be slashed by the parent if I do something bad this idea of hierarchy process sorry right so the idea is so now the the hierarchy is is limitless in principle so I can keep spawning more subnets whenever I need it there's no supply problem anymore all scalability is solved right so there's the idea of this so I grow the the hierarchy grows as needed and then right so if I'm a parent chain that have my own subnets I can kind of pull on them if I feel so I have some controls over my children nets by the checkpointing fees that I charge them and by the collaterals so I say if you want to start a subnet under me you have to pay a higher collateral so if these fees are high it could discourage the creation and survival of such subnets right so so I make it things too expensive for the subnets to to survive or if I want to spawn a lot of new subnets to take care of all this demand then I make these things cheap and they and they can join and then the idea is that while the whole hierarchy is limitless there's no there's no scarcity anymore each of the nets in the hierarchy is a finite net that each each of them should be utilized optimally and then kind of the guiding principle we want to use is that the overall total network revenue of the whole hierarchy should be maximum so growing this hierarchy should be in the name of it being better for the whole hierarchy so that's the idea uh right so so we can think of the model here what what we can do about this so this is the traditional model I I told you about about like a single chain that more demand brings higher prices and this is kind of how how this works in 1559 that this is the market clearing prices adjusted by depending if the block size was bigger than the target block size and I increased the price and so on so this is so this is this dynamic for the simple case and what we're looking at now looks more something like this so this is for a given chain for a given net in the hierarchy so these are kind of the the knobs that you have here you have your your base fee your normal gas fees that you charge for transactions you have your checkpoint in fees and you have your collateral and you should adjust this this fees based on what's happening with the hierarchy so this is the data that you read to to make your choice here how to adjust this right so this is kind of the solution space I was talking about that so right so so each of these nets must keep their they have an individual goal of like keeping the optimal block size for myself for that one given net so there can be a a IP 1559 like mechanism but then also they should have in mind like what's happening with the whole network so it's a collective goal so okay the total network revenue is increasing and if that happened because I see that more so this is the total amount of gas being spent in the network if more gas was was burned in the network and that was good for the revenue then I want to incentivize that more so I would make this fees checkpointing and collateral lower right to invite more growth and if growth was bad then I want to pull back so this is kind of the idea and so you can so this is the main picture here and and this is not the main the solution because we still I'm not showing you like an exact formula like this how to play but there's many options of what we could do that will look like this but this is should come from something like this so so this is my final answer so how large should the hierarchy grow so it should be large enough and maybe a bit larger to maybe induce a bit more demand but it shouldn't be larger than it is to be that's about all I have to say great thanks for that Axel and I think we have time for a couple of questions actually to the speaker um so we'll do this Oprah style if you raise your hand I will come at you with the mic or I will lead with my own question you mentioned that subnets inherent reputation and security features from the main net are is the reputation and security features of the sudden subnets are they strictly dependent on the main net is there any way for subnets to compete on features other than price if you start a subnet without a reason so but what I mean by this borrowing of reputation is just that you check points so you have a level of permanence that you know okay so the users of this stuff that knows there's something more permanent happening in the apparent net and also that that you that you know this subnet paid some collateral that can be slashed if they misbehave so you know they're motivated to behave it could also become the subnet could become more valuable than that by providing a valuable service so you also that subnet becomes a good subnet that is doing something good people want to use it so this is kind of a minimum value that you know that the user knows the subnet will have but the subnet can grow even above these values that is the idea fantastic thanks again Axel one more question over here I'm thinking about like the collective goal of maximizing the revenue of the network and wondering if there's any ambiguity and like how to measure that either what the elements of the network are not just miners computers but humans and like how you measure revenue is it only in file coin or are there other currencies right so this this this I guess this comes back to the question of the superficial goal or not so so the the idea here is kind of I'm assuming so right so the different subnets can actually do different tasks right so let's say we have file coin that is about storage and then let's say you you you make a subnet that is focused on retrieval market and you're incentivizing people who retrieve files and so on they're doing different things but they're kind of what join them what what we can measure them equally with is the amount of gas that they spent so so it's just like on the computational power required for for each of these things so we are assuming that the computational power of all of them can be measured and compared and yeah so this is one simple goal which is okay so this is my definition but now kind of so now in the hierarchy version this would be a sum of these guys over all the subnets in the hierarchy so what's the market clearing price of each of them and the block size of each of them yeah so this is again like a very cold economic target but it's one to to work with could be yeah it's it's also open to maybe this is not the right target thanks again for that answer I think now we'll have to move on and introduce our next speaker also from the crypto econ lab we have tom melin who comes to crypto econ lab from a background in theoretical physics and computational chemistry he spent the last couple of years modeling infectious disease and now he will be talking to us about fair prices for perpetual storage take it away tom cheers thanks very much carilla uh yeah so i'm going to talk about a fair price for perpetual utility so what does this mean so i'm just going to change my screen because we seem to be sharing the percent of you no problem give me one second okay there we are no problem okay so a fair price for perpetual utility what does this mean okay so utility first of all from the user perspective this is the expectation of access to a service now or at some time in the future from the perspective of the storage provider or what you might think of as a minor and other networks utility block rewards essentially are one in proportion to the the utility provided so utility what we're thinking about here on the on the file calling l1 it's data storage which gives a decentralized and robust and efficient foundation for humanities information but elsewhere it could be other things so it could be off-chain compute it could be networking it could be uh tension um but focus here is on data storage okay so perpetual what do i mean by this so perpetual is a pretty high target um i mean keep things in context i mean i think it was like in the 50s that when when shockly got the Nobel prize for the transistor uh you know progress has been absolutely massive so who knows where we'll be in 50 years but as an absolutely serious target we do need reliable long-term storage i mean you can you can see the kind of motivation from this in terms of this societal value i mean if you want to store important information election results humanitarian data environmental records you need to do this in a long-term way and this this kind of relies on securing a chain of evidence relies on immutability and it relies to be able to store on a scale of decades to ideally hundreds of years okay so price price we're going to talk about a little bit i'm going to skip over this slide for now but there are different things to think about there i think um an interesting aspect of this is what what we think of as the fair price so okay sure you can just say the fair price this is kind of the market equilibrium between supply and demand but um i think you know we can do a bit better than that i mean in in order to come up with a fair price you have to be able to give some assessment of what the underlying factors are that determine the price and what this is likely to be in the future and that's not simple at all so in order to come up with a fair price i think we have to be informed and we have to have sufficient models and information to do this so there's fairness in this aspect but there's also kind of a wider point as well so fairness generally has not been the domain domain um of economics as pointed out here by kahneman and taylor but i think to make a kind of wider point we have an opportunity to do something something different here um in general web two economies have been based on this kind of principle of information asymmetry you don't really know how your information is being used um take for example aws for one example i mean it's easy to get your data in there very low cost but getting your data out kind of different story and this this same story is seen across web two but i think with web three we have a chance to do something completely different everything is is it is is written in code in a transparent way and the incentives are are laid down in a completely transparent way that's much more equitable to the different parties involved so i think there is really an opportunity to to have a much fairer take on on long-term storage and other things in web three generally okay so that's kind of the background um some of the things that we can think about whenever we try to examine long-term storage are sure there's the mission this is what's motivating motivating us we want to have uh long-term storage for humanity's most important data and to an extent the principles but with which we will develop this is is motivated by fairness um and and encoded in the crypto economic incentives in the carrots and in the stick in the in the collateral and how this is slashed um and the block rewards that are earned um but some other aspects that we have to kind of drill down into if we want to price something like perpetual storage fundamentally you're relying on people having hardware having disks buying bandwidth having physical facilities so that is something we we have to consider if we're going to think about price as well as other things like redundancy and how we might might use some defi ideas or funding ideas to to structure how um the long-term storage is paid for okay so first of all the basics of the crypto economic incentives um storage providers and block rewards in order for in order from storing information but if they don't store it reliably their collateral can be slashed so you can see here that if we examine the chain you can see how how effective these incentives are so okay sure anybody can have a fault even good miners a hard disk can fail or electricity can can be cut but you can see here the the incentives are effective because for example for this minor sector that's shown I don't know if you could see it well but for this minor sector that's shown okay there's a fault but then that fault is recovered the next day and then okay there's another fault but it's it's recovered again so the the incentives are incredibly effective they're virtually always fixed but there's also sufficient slackness in the system that good miners if something breaks they don't get penalized uh straight away so this is kind of basics of crypto economic incentives and determining these parameters and how big the faults uh fee should be and what the delays are this is something we try to determine through simulation but I'm not going to go into that today I just wanted to set out the basics of the incentives okay so how do these incentives actually um affect the price so one aspect of this is hardware costs and this is kind of an interesting little problem that came up when I was in Las Vegas last week talking to some of the storage miners one of the things they were telling me about is okay we've got these hard drives and these hard drives fail sometimes and they have a warranty and the warranty is three years and they so there's different kind of options they can take they can have a strategy where okay they replace it with a warranty or they just wait as long as possible and let the disk fail um or but you know there's a kind of different outcome from each of these these strategies because if the disk fails then you know it takes some time to replace and then you're open to a losing block rewards and b getting your collateral slashed um so it's kind of like under under these kind of different trade-offs like if you buy the buy a new disk too early then you got to pay more if you wait too long of course you've got to pay less for disks but you've got more chance of having an unplanned failure and getting slashed so so under this kind of situation what's the optimal strategy so one way uh so part of what I'm doing here is I'm not going to give you a price that is $10 for uh storing something forever but I'm going to set out some of the methodologies to think about this so one way you can approach this this kind of optimal strategy problem is to treat it as a renewal reward process so as time goes on disks can fail uh after a random amount of time and they can fail it with different uh they can stop working uh by a different mode so they can fail or they can be retired and whenever this happens uh there's different ways that you can realize costs it can be through having to buy a new disk or the slashing or block rewards so to make progress in this we can use the renewal reward theorem which is given here um and okay so yeah we can use this renewal reward theorem which states uh that the expectation of this process is given in terms of the expectation of the costs divided by the expectation of the disk lifetime so good but expectation over what expectation over some distribution so we can model this distribution as the kind of classic uh failure uh distribution um from reliability modeling which is this kind of bathtub shift curve as you see here now to actually model it we can model it as a stretch dot beta distribution okay fine we can do that uh so now our optimization problem is we want to optimize this functional how can we do this um so we can't do it straight away because we don't know what the expected cost is and we don't know what the expected lifetime is but if we break it up into the different modes of in which that the expected lifetime can be realized uh then we then we can work these things out so if we if we kind of expand that expected expected cost into the different thing different ways that it can occur and we expand the expected lifetime into the different ways that that can occur as well then we've got something that we can easily evaluate and if we do this we can find this optimization problem plug in some numbers okay warranties two years three years whatever and and find an optimal replacement policy for that disk so this kind of feeds into uh knowing how long you should keep your disks for uh informing uh miners and of course it can feed into cost models so another approach we can take to think about factors that affect price over a long period of time again is hardware and so for hardware physical media we have we have price information so we have this kind of Moore's law-esque time series data I mean as you can see here over the past 20 years on this log scale it's it's effectively linear no will this continue I don't know but you you have to assume something you always have to have assumptions in models and if we if we have this assumption can we somehow use it to inform what the price of the file coin dealers might be in the future so file coin dealers I mean they've only been around for about a year so it's kind of difficult to imagine how they might go in the future but of course hardware is an underlying factor so can we use this historical data to inform what the price might look like in the in the future and yeah sure you can so we can make it like a simple generalized linear model and if we do this and we have some partial pooling of the coefficients in the model so we can say okay we're going to let the slopes of the historical data for for disk drives inform what the deal prices might look like then we can we can come up with some kind of trend for the future yeah thanks so we can we can do this and of course we can we get a distribution if we integrate these these forecasts in the future over all of the different realizations from the mc mc inference then we can work at a distribution for costs of storage in the future but of course this kind of limited cost this is not the only factor that affects deal prices there's there's so many other things you've got to think about electricity you got to think about bandwidth as well as well as just a market perception of what the demand might be okay so let's one factor mostly what i'm doing here is kind of setting out some tools and frameworks or ways that we might think about this so slight change of direction another factor is trying to consider how we might fund this so one way to fund it is in terms of a yield bearing token or some kind of bond so how does this work this works so instead of paying for the the price of the storage fully upfront is there some way that we can distribute the the payments into the future using the interest from from a bond for example so it's going to be something that's very stable that produces a yield every year and that can continuously be drawn from so if we if we invest in a bond we expect to get something something like this where the value of that grows over time and stated here now this kind of growth sort of satisfies this simple differential equation but what if we don't just let the bond grow and instead we deplete it over time by using it the interest to pay storage providers so instead we get this kind of little differential equation like at the bottom so now the kind of question becomes okay so if the client who wants to store data buys this bond and uses the interest on it just to pay the storage provider what does this look like so how much do you need to put up for the initial bond in order to to to pay for the storage so this effectively comes down to saying something like okay can you solve this equation under conditions for example like what I want is the bond to pay for the storage and for this to be completely depleted over the lifetime of the storage for example a hundred years so we can solve this we can solve it but only if we make a lot of assumptions so we still need some kind of model for what the storage is going to look like in the in the future for what the the deal prices are going to be but if we assume that the the storage price goes down very slowly then we're kind of got this scenario yeah so if we if we do make assumptions that it goes down very slowly then we're in this kind of regime where okay you've got you've got to pay a lot if you're if you have low interest rates or if you've got a very high interest rate you can pay less and you can work out what these curves are and where you sit on it but fundamentally we have a kind of tricky problem in that a we don't exactly know what the the risk-free rate of return should be and b we don't precisely know what the fundamental costs that feed into determining the price of storage in the future are going to be so these are all things that are assumed but sure we can we can come up with with a model that changes the funding and how other cost is distributed over time but there's there's more to it than that I guess that's what I'm saying yeah so I think those are the kind of key points that I wanted to make today and if you want to think about very long-term storage for sure we should absolutely do this is completely critical and very important and there's a lot of fundamental things we have to think about in terms of hardware prices and bandwidth and electricity that go into determining this and we can make a lot of progress on this and we can make a lot of progress on the funding side as well but I think there's still some way to go but yeah we're going in the right direction so I'll finish it with that thank you thanks a lot for that time for a nice reflection on the difficulties and complexities inherent in modeling this sort of perpetual storage these sorts of long-term questions speaking of long-term questions do we have any questions to the speaker thanks so much that was super super interesting and I'm curious I mean I think some of these things where you're like oh there's a ton of assumptions to consider and and it's just like very hard to do I think insurances do it right like all the time they like model very uncertain events and then there's still some price that they set to determine that you know this is what I'm willing to accept as a price and then sometimes they make wrong wets I'm curious and then our weave exists right and they have I think articulated some price where they're like you pay for the first 200 years with 30 percent of whatever you put down and then the rest goes into an endowment that I guess is similar to what you're describing that then yield some interest and assume some price decline for other things what's your take on and how they're approaching the pricing I know it's like a different model in that there's like only probabilistic guarantees for storage still being around versus in fact we're not deterministic but just curious and like right like our weave has has kind of tried to address that and has come up with some kind of mechanism to price it or curious what do you take us there yeah so it's kind of an interesting question I mean I think there's two ways to think about this in general I think there's a research aspect and looking into all of these details and you can go into definitely a lot more detail than is in the our weave paper which is kind of a relatively simple model and makes quite hardcore assumptions and trying to look into some of this sort of sub problems and sub details is what I'm doing here and that's kind of more of a research question and then there's kind of a more of a business side which is like okay we've got this idea we're going to release it there is going to be some risk associated with it it might work it might not yeah so it's kind of like two sides I don't know if that answers your question exactly but that's kind of what I feel you know you can jump into doing it but it's 100 percent not going to be guaranteed there is going to be a little bit of risk associated with it yeah right so I think you know a lot of this we're thinking having a proof of storage every day right but some of these older data they really probably don't require that necessarily so you know what what are the requirements if you want to really put it in a glacier type storage environment you know yeah so I mean I guess that's kind of an interesting question that maybe touches on some of the kind of deeper protocol level aspects that we might want to think about in the future so that you know currently we have proofs of storage that go every 24 hours maybe for very long term storage that's that's not even something we necessarily have to have you could have proofs that are only submitted once a week or something like that which might change the cost as well so I mean I think that kind of touches on quite an interesting idea for sure well thanks again Tom for a great talk and for giving us again that long-term perspective yeah we'll move on now to our next speaker who will be joining us virtually uh Edward Sheep Edward's a data scientist at starboard where he's part of the network analytics team that designs products and pipelines to support network governance in the file coin ecosystem he's passionate about geometry and number theory but today he'll be talking to us about file coin analytics for network governance take it away Edward thank you thank you for the introduction uh hello everyone this is Edward from starboard uh today I'm going to give a talk about file coin analytics for network governance all right so let me begin by my talk by making a simple observation that file coin has actually become the most vibrant data economy in the web three space with a committed storage capacity over 15 eib and active like amount of client storage deals over 70 pib now one of the key issues arising from such being such a huge complex adaptive system is that how do we properly govern governance such a huge complex adaptive system especially with a case that you know we're adopting a community driven democratized sort of governance framework here so like there is in some way there's really a strong need for an accurate comprehensive and open sourced data analytics infrastructure upon which collective decision making real-time collective decision making can be made so um in particular right um we as a team we've identified a few key challenges uh in transit not only to the file coin governance sort of framework but also to web three governance in general and we believe that you know these common challenges uh for for those data analytics is precisely the key solution to addressing those challenges so let me go go through them one by one firstly observe that each web three network is essentially an island economy that evolves decision making from individuals and organizations with essentially different preferences goals and horizons therefore what this means for the governance team is that they really need to understand how to balance the trade-offs of different decisions giving that agency in the environment basically have different press preferences goals and horizons for instance right say the governance team wants to introduce a follow-up improvement proposal uh we commonly know as fit you know they need to have a very clear understanding like whose benefits whose expenses you know how will this particular fit introduction impact the sort of entire network not only from aggregate but also from actor specific level um secondly you know despite everything is publicly available on chain public information is actually not properly diffused this is a key problem so if if i ask you a question like what is the current state of a network what are some population statistics you know what are some of the micro trends and issues existing in the network um there we need expertise or we need a middle layer to actually extract that kind of on-chain data insights from the blockchain architecture and make them available to the general public uh third key challenge that's observation is that you know governance doesn't have to be emotional and political the key really is to have an accurate and robust data analytics upon which the community can make informed decisions for their shared goals and values all right so uh what i just talked about is basically establishing that file uh network analytics is important for governance but how do we proceed right um how do we proceed go from the first principles into actually building data pipelines that should basically making the insights into product well we start from the following two initial observations uh specific to the following and we actually derive some systematic strategies from these two observations firstly notice that similar to web 2 data solutions cloud going is a data economy consisting of a globally distributed network of servers and clients this implies that like web 2 services like aws or azure we need to track operational intelligences traditional to the web 2 uh data service provisions things like storage uptime uh reliability metrics which is also tied to the fantastic talk talk tom just gave uh we need those like metrics right to to actually properly evaluate the effectiveness of of the web 2 like actually the storage provision service we also need a very clear kyc things like you know who are the top you know agencies that are making the most interactions on the network now uh on the other level right this is a second observation unlike web 2 solutions file coin is the words data center what does that mean is that essentially it's a decentralized layer one protocol right uh basically trying to democratize entire storage provision data centers or data economy services to everybody uh in this uh participants on the network this means that we also need to track intelligence or intel specific to the blockchain analytics stuff metrics like circulating supply gas block rewards right those are the concepts or matrix statistics in uh basically native to the blockchain uh ecosystem that are not traditionally available in web 2 basically services right uh so now we we've actually uh move on from the observations here's our roadmap sort of deriving derived from that uh two observations so here's what we we did and we thought is a good roadmap for making everything happening firstly we need to understand the file coins protocol structure and basically build expertise in analyzing the state synchronized data right so basically we need to uh you know call some rpcs and grab a data out build databases uh next we're going to map the blockchain data to the corresponding protocol features and design specifications right those are available usually in the source code or open source uh in the spec we're going to map the blockchain data to different parts of specific features or protocol then we're going to translate the know house into actionable uh insights charts of statistics that actually support decision making for relevant stakeholders in the ecosystem uh last point is the most important right after we did the first three steps we need to build a comprehensive data analytics platform that provides intelligence across different angles across all of different fidelity so with the principles and methods and roadmaps discussed above very probably we introduced the network house dashboard so this is a our factory product that usually you know basically try to analyze views like analyze the network's house state through different angles all of the things we just I've just talked about discuss the principles and methods it's all either so the best way we're actually trying to provide a section-based user journey where through the different sections we provide a very clear way on how we think uh the governance team should approach uh analyzing the current state of the network and so the best way to summarize the product this is a one-stop comprehensive intelligence platform that provides not only current but also historical data analytics for the ecosystem especially for the governance team so let me just briefly give a tour introduce each subsection and the information we capture so we're looking right now at the first section which is the which is the capacity and service this is the place where we track you know information related to storage provision on the network we ask questions like you know for storage state right what is the active amount of storage currently existing in the network how many sector commitment storage capacity commitment has been sort of uh committed on a daily basis we also track uh reliability indices right um the the stuff tom just talked about you know if there are thoughts happening right how quickly are those thoughts getting recovered uh what is the average fault time distribution overall on an aggregate level uh for the network we also track uh service provision economics which tells us about you know if i'm a storage provider i want to you know put a storage into this network you know what is the rate of investment versus return what are some of the current block rewards i'm going to like get if i if not now i want to like basically commit so um moving on we have the next section which is the circuit in support right this is this actually tells you about the token flow how many fill uh let's say for for example gets mined how many fill gets vested how many fill gets locked or burned on a daily basis and you also you can also do data drilling right that's the purpose of of the entire uh the process you can understand you can basically read about the component breakdowns for the aggregate statistics that you find interesting for instance you can have a uh detailed look into the different components of fill locked the amount of fill get burned all of those like detail breakdowns are there according to the protocol specification so moving on we have storage demand and deals right this is the demand side of equation here we track stuff like you know what is the deal inflow what is the deal outflow current and historical we also track stuff like you know how do we do pyc uh even in a relatively anonymous environment you know we want to identify the top adversities that are making the most deals uh out within the ecosystem uh next is exciting topic network usage and gas uh we track uh you know what what is the current uh base fee and and also tracing back to the like past 24 hours uh corresponding to the eib equivalent to the eib 1559 uh you know what is you know we we kind of see the base fee right we also want to understand you know if there is a let's say if there is a base fee spike what is the gas uh usage that actually contributes uh basically can be attributed to that particular base fee spike uh so this is where we put things like gas usage breakdown by methods telling you a volume comparison we also track stuff like aggregation right basically aggregation is a stability technology innovation uh the team has made um the PL5 team has made uh for approval storage you know want to track you know once this innovative fantastic technology is out how often are people actually using this storage provider actually using this to reduce the amount transaction cost uh so i've just talked about like a lot about the structure the theory the principles let me just give a particular use case on how the sort of product such can help with like web three governance so um this is a real real life use case so in the past few months starting january 2022 there has been various initiatives in the five point ecosystem focusing on driving five point plus deals adoption uh and in basically increasing the network utility for those of you who are not familiarized with the term five point plus deals are deals with a better deep KYC and tighter identity verification uh so let's just imagine that if i'm a business analyst and i'm asked to write a report on the initiatives uh trying to drive a five point plus adoptions but at the same time i'm asked to quantify basically quantify the impact of the various strategies uh developed to drive the adoption here's i can how i can use the dashboard next page so the first place i'm going to go to when i wake up in the morning uh is i'll go to the deal storage deal section uh in the in the dashboard and i'll observe that this chart called newly committed deals this actually tells you you know how many deal gets flow into the system on a daily basis this actually tells me as a hypothetical analyst that you know over the last three months five point plus deals has actually taken over majority of the deal growth as you can see you know by the green amount of green area presented in this chart and it's not actually five point plus deals now accounts for over 70% of all of the active source deals uh outstanding so um you know i'm a curious analyst right i don't just want to stop there i want to go to the other different parts of a protocol and basically build a multi-dimensional analysis this is where i can go check into the storage uh provision section and see that you know uh doing the past months or so we actually also see some uh spike in sector onboarding activities which tells us right like there is a event correlating with a higher deal adoption is that actually uh more storage providers are thinking about you know it's either extending or like joining the ecosystem to provide like a more service provision coming meanwhile if i look going to the gas and usage section and if i analyze closely the daily network fee breakdown i'll also realize that another thing correlating to higher deal adoption is that the network is actually getting busy again uh judging from the amount of like fees activities which is a direct indicator signal telling you how busy the network is uh next so if say our analyst right uh is not satisfied with the overall statistics or trends and wants to do a more careful KYC well i can just then track the actual highlight and basically identify the top addresses that have the highest amount of participation so here on the screen we're seeing well what are top 10 clients uh classified by verified deal bytes also for the top providers actually actively taking five point plus deals uh okay next so uh if our analyst wants to further drill right wants really to get to the bottom of this uh he or she can track basically the individual client page and identify the protocol specific behavior and patterns uh this is actually really incentive design right we were seeing here on the screen is a three-stage uh basically uh KYC funnel this is called five point plus verification protocol in which there is a note three who allocates uh who sort of approves clients initiatives to actually you know store verify storage deals in the system so uh we thought about you know how can we capture the transaction patterns in terms of graphic based method is graph based method is a great way to basically concentrate our analysis on and basically build a local level transaction graph analysis for each of the client existing in the system so if our analyst wants to dig further that's where he or she can roll all right um open source insights you know we're in web three all of the insights are supposed to be open source right remember I talked about you know not all of the public information are properly diffused but now that we have done the like the middle middle layer work in between we can just build open source these things like for everybody to participate in the ecosystem so we're currently testing we're actually released a bunch of but we have like very positive feedbacks from people's from Masari basically we're open sourcing insights in terms of data field notebooks and charts onto this platform called observable HQ so for everyone who wants to build their own analysis they can just treat us as basically a do an analytics type of style of like api and just download the data do their own analysis so exciting opportunities uh we like as I said right five point is such a fantastic ecosystem there are so many uh aspiring challenges data science challenges uh the engineering challenges like crypto cryptography challenges we can do but some of the stuff are more related to my line of work is we we have tons of visualization modeling analysis uh just as tom just presented right there's tons of problem in terms of intelligent sector reliability profiling engineering uh we have the data available and just about how we can build the best model offers there is also questions related to computational game theory incentive design evaluations and evolutionary games and also so I just gave a quick snapshot that we can do a lot of transaction graph analysis on this sort of open public chain uh as well so I'll also stay tuned for five point virtual machine which I believe I want the next speakers will get into more costs thank you all please we're hiring so you can visit us at our website and contact us and I just you know hopefully hopefully more people will join in a collective build a fantastic ecosystem thank you wonderful thanks for that Edward for that really this is very exciting opportunities for anybody who's interested in data science or data visualization definitely that last slide about exciting opportunities very true we have time for questions to the speaker so I love the dashboards that you guys set up and can you talk a little bit about how people are using it already like are are you seeing some good responses are people engaging it with it are they building on top of it I'm just curious what kind of interest you're seeing from the community in these kinds of visualizations and insights uh yes okay uh so a couple of examples right uh basically we have seen basically uh people inside ecosystem right mainly the governance team I I actually know like a few uh stakeholders on the governance side who check out dashboard on a daily basis and uh there's a lot of stories how uh they begin first observing a couple of changes uh in the in the charts they find interesting and that ends up in the ecosystem wide uh discussion on you know what is the current thing what is the top like strategies the entire system to focus so one example is we've actually throughout dashboard uh one of our a few stakeholders has actually realized you know while there's a lot of sector retirement or exploration taking in starting January and after after they saw that particular signal change on the dashboard um they sort of very quickly responded to it and just you know uh start building more initiatives on five point plus deal adoption and also sector high onboarding rate this is a I think is a perfect example illustrating this we also have external adoption of people outside ecosystems uh for instance Masari when they write the first stage five point analysis analysis report they were using our like observable sq api to build their own analysis yeah any other questions while you're thinking then I have one actually about consumption patterns of your data um you mentioned that you have both current and historical data available for the falcon ecosystem do you have a sense of how long data stays fresh are people still making a lot of requests for data from your mainnet launch is it mostly closer closer in time that's actually a fantastic question you know uh right now the main there's like a year and a half right since the mainnet launch and we've actually seen a request from stakeholders let's keep everything historical now now as the ecosystem develops right as the network develops there will be the amount of the amount of like data the data size right plus duration is going to be a challenge for us so we've actually been discussing internally how our engineers we can you know basically design a good ux experience for people you know for instance right when you guys first arrive you will see like three months or six months snapshot of the charts you'd like to see but there are also options uh on the on the on the ux side that supports you know if you want to see the full historical we can also show that yeah but so far given the short time frame everybody's like let's just do historical great thanks again Edward any other questions to the speaker before we move on seeing none then I'll thank Edward one more time for a great presentation and introduce that's right applause our next two speakers we have a tag team coming up that's right things are getting more and more exciting momentum is building Jamshid Shorish and Andrew Clark Dr. Shorish is CEO and founder of Shorish Shorish Research and a senior advisor to the Uberling Corporation a technology firm which developed Voson the virtual observatory for the study of online networks he also works with the australian national university's Voson lab where Voson is used for research research tool development teaching and training Andrew Clark is a data economist at block science with a background in financial and technology auditing with a focus on building machine learning auditing systems and together they will present an empirical study of file coin gas and some ongoing research I'll turn the mic over to Jamshid and Andrew great thank you very much for the introduction and welcome thank you for the invitation also to to zx and alex it's a pleasure to be able to present some of the extent work that block science has been cooperating with and through the crypto e-con lab my colleague Andrew should be online momentarily but in the meantime I will go ahead and just kind of give an overview of what it is that we're doing from the block science side of things and how it applies to two extent research directions that we're working on one of them having to do with the gas dynamics of the file coin network and the other one through a pass through of a simulation framework that we have into an assessment of a particular type of protocol update around the batch a batch fee and the batch balancer so we'll be looking at very quickly in our time available today is to start with a section on gas dynamics where we'll be looking at the way in which data was surfaced how that gas usage was decomposed into its pieces and then extrapolate using using that particular decomposition to understand and inform how it is that we can extrapolate forward gas usage given a particular time series of the network that in itself is extremely useful for building out a simulation framework that actually goes on a macro level step by step through the file coin network and acts as a digital twin digital twin which is built in the CAD CAD simulation framework of block science is one of the workhorses by which we can understand how for example different types of activities that may have occurred or different types of scenarios that we would like to know what might be happening can pass through the network and allow us to have actionable insights utilizing both the digital twin and the gas dynamics analysis will then go into a very quick application area which has to do specifically with the batch balancing system where we'll look at kind of what batch balancing is in a very quick snapshot and then kind of wrap up with extent research on utilizing the the framework of the digital twin and the gas dynamic systems to move forward into actually selecting among a very large class of possible batch balancing frameworks one which may meet the criteria that we would like to be most interested in for being able to assess when it is optimal to aggregate different messages and when it is optimal to keep them as separate messages so that's kind of the overview of what we've got for moving forward I'm checking to see now whether or not Andrew is available I'll do a quick check here otherwise I will jump in and take over a section ah he's coming online now very good okay Andrew I'm going to give the floor over to you I'll continue to drive just in the interest of time to make sure that we have ample time available for the rest of the talk okay that sounds good thank you um so what we started with was it looks like it's between slides oh perfect um we started with an exploratory data analysis around the gas mechanism to understand kind of how what was driving gas usage and and gas limits and other things and understand a lot of the key components to drive it um we did a lot of different methods and different aggregations um you know do our own blocks or do we do it by seconds by days um and tried to see um how the how the trends were happening um all of that kind of information to really understand what the key drivers were so the types of analysis we did if you go to the next slide please was also checking the change of actor methods we created our own data dictionary based off of what the storage minor five means for instance so we went and through the file coin code and figured out what those things were so we could see the percentage change in message counts for instance between different times like this right here is a weak percentage change between uh week of september second it was an example of this storage minor seven had a massive increase in the number of messages over this course and we did these types of analysis to really see what we're driving during in combined with macroeconomic variables we also use things such as Fourier transformation which is on the right hand side here to disaggregate the data into a frequency domain um and be able to see what the components were and see the trends we can start and then we did phase shift analyses and and things like this all to try and understand what were the key drivers so we could understand the intuition for building um predictive models off of the system so it as we're going to get into the digital twin and how that whole system works um we wanted to make sure that we could understand what the key signals were so we could drive specific models to be more predictive as we get into system identification which we'll we'll get into in a little bit for how we're forecasting states forward as the different actors are are interacting and getting very accurate gas usage from the bottom up approach one of the main techniques we use if you go to the next slide please um was something called uh grandeur causality which is a very interesting method that we used to create our vector auto regression models by what what grandeur causality does this allows us to understand if certain variables um from a var model which is uh it's just an auto regressive model with you determine the number of lags and you can have many different factors what this heat map shows here on the right is we can determine like at the top here is base fee burn does that cause um one of the actor methods to have a higher count and what grandeur causality does essentially is it's it's a way of trying to infer the causality of does this variable cause this other variable based on the on the lag from a var model so what you can see here is based off the the p values and the statistical um relationships the green are the variables if you intersect from uh the column in row you can see which variables are have that factor so what we were trying to do is based on the time period we had which is one of the key considerations we'll get into in a moment based on we were using the sentinel filecoin database that is truncated at specific periods of time um so we don't we didn't have a massive back history especially if we're doing daily data for how these different methods classes work um as we're the most likely as we're looking at it like an operational digital twin to drive business insights we kind of want daily values for these things um we had a dimensionality problem of having way too many um different actors and their different gas usage it was way too wide of data for the amount of rows we had so that's a dimensionality issue where you it's had as a very hard time training models traditionally we would use something called a var max model where it's the vector auto regression is the endogenous variables what we're trying to predict would be the gas usage of these different actors methods and then we pull in macroeconomic variables as the exogenous um in this case the macroeconomics would be you know base fee burn and some of these these higher things if we're trying to predict and all the different signals from the filecoin network minor penalty pledges that kind of thing or anything that we think is relevant that we've can derive here um to be able to predict what this gas usage would be so because we ran into this difficulty and you can actually see on the left hand side here some of our our plots of the end model we ended up with we're not going to go into all the specifics of how we have it we have a little bit more information the appendix we can definitely follow up offline we use something called a uh if you go to the next slide please um a var x model that dr shor came up with is which is essentially by using this grander causality we can understand what the key macroeconomic variables were and then we ran them as a normal var model instead of this normal var or max model and then this allowed us for based on this analysis as well we found what were the key drivers because there's so many different actor method classes we only need some of them to be doing in um you know parado principle for doing an accurate digital twin that's performant um and we can see here what the different gas usage uh per day from these different accounts um so we use this this this method that was faster that got around the computational limitations allowed us to build this integrated digital twin that allows us to get the previous state predict the next state from our operational DT as we were building this out um uh you can go to the next slide um we started running oh um yeah that works so we started running into issues as we're building into the digital twin um issues with data uh long longitudinal data for back testing and things like that nature um and be able to really fully build a model we needed a longer period of time of the data uh and we were with sentinel was truncating that data um as the operational digital twin you know we want to perform health metrics we want to inform decisions we want to semi check behavior expect behavior we need a long period of high fidelity data in order to do this um and this was the goal of all of that analysis we were building towards was being able to make this gas dynamics for extrapolation digital twin that helps make decisions for for the power point network and helps doing parameterizations and things and when we when we started really taking that initial analysis we did which we knew we had limitations based on how far we could go back in the data and then based on what the goals were here um if you go to the next slide please we created this operational digital twin infrastructure uh ourselves we're basically what we did here was we went back and got all lily data fields we got um all these different data sources and and sentinel um because of we lacked the the fidelity um and and the longitudinal data that we needed for our our analysis so there is a Filecoin did also have an internal research database but didn't quite have the right fields of things as the different aggregation layers we're using um and and all of the different uh signals we needed based on our our EDA analysis of the different macroeconomic signals for the for from our Rx analysis with that that heat map with the that we showed we had to build our own internal um infrastructure which is now up and running that that allows us to basically every night batch data from um sentinel after we back filled with lily we then can use sentinel and then aggregate into our digital twin um data fields and aggregations we need so then when we have this operational digital twin that's used by Filecoin stakeholders they're pulling directly the refined data fields from the block science RDS here that's a lot more efficient than trying to ETL and do all of these analyses each time because the code that ETL from the raw sentinel production parsed messages for instance into the the daily level or epoch level uh gas usage data that we needed is a long process and takes a long time to run so we've now ETL all of that um here so we can have build this operational digital twin with the health metrics and the ability to do what if analysis and counterfactuals and parametrizations and have that into a solid state so I'll hand over here back to Dr. George for for going forward I'll talk about how some of the gas dynamics then moved into the batch balancer right thanks very much Andrew uh so what we're going to look at now is a very quick application of this uh digital twin infrastructure with the gas dynamics extrapolation exercise built into it uh in order to understand one particular feature of the the Filecoin protocol uh that has the potential for being uh for being updated for being updated so this is an active area of research we're currently working on on actually building out the the functional form representations that we're testing in the digital twin just as a quick overview of what the batch balancer is doing what's happening in this particular environment is as many of you know that there is the opportunity for messages to be aggregated or batched in order to be able to to save gas and in particular for the largest gas usage messages of pre-commit and proof commit messages for for the proof of replication the intuition is that as the network use becomes high then batching is incentivized in order to improve efficiency and the mechanism by which this is being done which is raised initially in in 513 and then and then updated once in 524 is to have a batch fee surcharge with two different degrees of freedom one of which is a batch balancer which enables individuals to make a trade-off between what the base fee would be for a single message submission and what would be happening if you actually aggregated things together and on the other side a batch discount which is a way of incentivizing a little bit of a shaving or a little bit of a haircut on that on that surcharge depending upon how the system is performing and in these two particular degrees of freedom what we're going to see is that currently these are being set at once and then updated through governance and what is being investigated is whether or not we can actually endogenize what are both of these to respond to network conditions but just to give a very quick idea of what the file point batch balancer would be set up to implement in this particular context we would have a pool of messages that are coming in from storage onboarding as you want to have these sectors being sealed they would come into a batch decision the question of whether or not to aggregate then depends upon the state of the system at that time the base fee that is available and then what the batch balancing surcharge would be then it would be a decision on batching or not batching if you do batch then you get less gas per message but then you have the batch surcharge which is applied if you do not batch then you send messages singly you have more gas than per message but then no surcharge and they lead to different types of outcomes on the the stress let's say of the of the network if you aggregate and batch things at once then you're able to accumulate you're able to use less gas and utilize less of the network and there's a lower chance of network congestion whereas if you have individual messages that are singly being submitted if there is already a high level of network utilization then this will add to the burden to to congest and so the idea from the batch balancer is that if you have for example high network use then what would be chosen in an environment where the parameters of that batch balancer are already being specified is to say yes I would prefer to batch in that situation collect everything together sort of use less gas and then lower the network pressure so this is from the point of view of the network what would we like to see and of course we want to ensure that there's an incentive underlying this for each of the storage providers to do so by contrast if it was in the low network utilization environment we would say well it's not so interesting then to batch let's not incentivize batching as much let individuals use the network as in single messages and then perhaps raise the network usage and so we ended with kind of an equilibrating regulator system that's put into place but it's predicated upon those two degrees of freedom that I mentioned the batch balancer value in the batch discount now how those are updated presently well those are updated by governance and by introducing a fifth so as we move from 5th 13 to 5th 24 what's being introduced is a change to one or both of those parameters on the basis of what has been seen in between the two points which these have been last updated so we look over the interval and say well maybe it makes sense now that we increase the surcharge by a slight amount or perhaps we decrease the discount by a certain amount this is a way in which you can use expert knowledge to drive the update that occurs but of course it means that you cannot respond in the immediacy of a change in network conditions because you have to wait until you have an appropriate amount of time for review in the fifth to be accepted so by contrast the idea here is the active research we're looking at is to see whether or not we can put into place a functional form representation that explicitly depends upon but with state of the network and then dynamically adjusts one or both of those parameters and so if there is actually say high network utilization that this dynamic batch balancer would then take that into consideration and then adjust in total that batch surcharge and influence the incentivization of individual storage providers accordingly so by introducing a dynamic batch balancer framework you let's say not necessarily eliminate the need for having governance because you may want to change the form of that particular mechanism depending upon its performance but it does mean that you don't have to change those parameters every single time through a governance process the regulator system now has been endogenized so the challenge of course is to create such a dynamic batch balancer that responds to network behavior autonomously while continuing to incentivize batching for the storage provider when network usage is high and our current research agenda is to assess a parameterized dynamic batch balancer functional form within the digital twin the operational digital twin of the file coin network that Andrew introduced the goals in that case that are to select using the digital twin and understanding different scenarios a parameterization that is informed by simulations that we engage an employee for various storage on boarding rates or various types of demand activities for file coin services and that assists then in the recommendations for a fit to implement the dynamic batch balancer upon conclusion of those simulations these are simulations that are ongoing at the moment and finally the idea here for the batch balancing is to incorporate all of the information that we can about the existing network that is to ensure that we understand not just the laws of motion about the system as a whole but actually to understand what would the system like to have so we know for example from a storage provider's point of view they want to make a batching decision predicated on cost but from the network as a whole optimal batching is predicated upon network efficiency there's a trade-off between the network becoming too congested on the one side and not having enough of the let's say protocol revenue of the of the gas being burned on the other so the digital twin implementation allows us to model the entire network as a macro system that selects message batching in the simulated framework based upon network use and the gas usage from message traffic according to this batch balancer functional form so we dovetail in the gas dynamics on the one side into the digital twin on the other conditional upon this functional form examine the scenario simulations that occur and by using different metrics assess which one or another parameter constellations are optimal for that particular implementation of the functional form of the batch balancer that we would be suggesting so by the simulations we actually look at various storage onboarding scenarios high storage onboarding low storage onboarding high network congestion low network congestion to understand that impact of the different message traffic rates and we combine those scenarios with the gas dynamics laws of motion that Andrew Hitch uncovered in the first part of the talk to be able to run those simulations conditional upon as close to an understanding of how those gas dynamics are influencing things like the burn rates for different messages as possible in order to be able to combine those two together we then perform what is part of the engineering design work process parameter selection under uncertainty to be able to figure out a range usually of parameter values for which the dynamic batch balancer can be then recommended okay i think that's everything that we have the time available i know we went through fast fast and furious for different research opportunities but please thank you for your attention and naturally if you want to have any more information you definitely contact box lines and either of us individually so thank you very much great thanks to gem sheet and andrew for a great illustration of the power of the digital twin model for modeling and simulation and for a nice illustration of the relationship between empirical observation and mechanism design in the file coin ecosystem we have time for a couple of questions to the speakers i'll run up to you like opera don't be shy okay i'll get it started then i noticed in one slide you made reference to an intuition that you had about the system you were modeling when you were describing uh when you're designing the batch mechanism batching mechanism where um where do these intuitions come from are there any real world or digital systems that you find are fruitful sources of intuition when you're building these kinds of models and when you're doing these kinds of studies that's a great question uh so some of the kinds of environments that we look at are our control systems whether or not we're looking at open loop or closed loop feedback systems a feedback system which says that we would like to respond to a particular state of the system by taking an action that reinforces a criteria such as stability or a minimal set of volatility these become ways in which we can kind of understand the trade-offs that must exist for an individual of their own volition completely of their own choice to make decisions that affect the network as a whole in a positive fashion and so it is of course a long-standing and open question about whether or not individuals when doing their own thing will do things such that they don't end up working against the community as a whole so there is a lot of tension when you're trying to aggregate up from a micro decision to a macro decision the idea within the context of the the batching system is to say we want to make sure that people understand that they can batch when it suits them at any time but that we would see on the margin that they would decide to batch more often under conditions which benefit the network for example under conditions of high network congestion there is actually an empirical fact that we have individuals who like to batch even when there's absolutely no network congestion they batch a certain amount all the time maybe thinking it's just simply an efficiency gain even though they aren't necessarily earning any kind of savings from this because the network level is so low the base fee is so low this may call into question strategic issues of whether or not they are looking forward and saying oh maybe i'm actually going to change perhaps my my impact today changes the base fee in the future and therefore when i actually have my time tomorrow to actually engage in mess traffic i actually save money on that and part of what we're investigating in this macro model is to actually model those types of strategic decisions which are motivated from game theory but are built into a macro model of the trade-off between the current benefit and the future benefit so this is one of the ways in which we utilize that that intuition behind driving the micro level to the macro level to build such systems thank you for that we have another question what kind of changes to the system would make it way easier to measure a lot of the things that you want to measure and make it easier to either run experiments or simulations and so on i imagine a lot of this is sort of rate limited by the ability to like do experiments or design different kinds of potential systems and so on are there any kind of changes that could come into the text like itself to make it easier um good question i i'll defer also to to andrew if he has an answer to this from from my side it is the more information that you can get exposed about the distributions of things that occur in the system the better a lot of the challenge from from the data side is to be able to build let's say a model of the distribution of the things that you're not totally under your control so exogenous effects for example on the tighter bounds that you can place on that so the greater the data fidelity is to be able to run some sort of a parametric or non-parametric estimation the better off you are because then you can close the error bounds a little bit over a wide range of different simulations that you might have but let me also defer to to andrew if you want to add something to that it's a great question yes completely agree with with what you just said the other thing we we are working on to make it so it is more accessible and easier to use for the analysis on the tech stack is moving it to docker images because there's setting this type of thing up is a lot of different dependencies and things so one of the next steps that we have in the operational digital twin is like we have the data already set up in a specific way we can keep keep making it so we can do the different distributions and as many as many pre-knowledge we have but also the ability to then run this from a docker container without the full setup allows us to crowdsource a little bit more some of the analysis versus like if if we're like here here's a repo with all of this code it's going to take a long time to set that up versus like if you have docker we can package all this so then you can go in and change programs and do more experimentation so from a tech stack perspective specifically moving to the full digital twin to docker will definitely and aid the crowdsourcing of of analysis great thanks and do we have any other questions to the speakers I think in the architecture you showed like a lot of the data originated in a like sentinel database redshift or something like what would be the tradeoffs if you were sourcing that data from um uh Filecoin or IPFS directly or would yeah would that help at all or hurt and that's that's the key thing is so we also used a lily which is our s it was s3 dumps of data from actual Filecoin chain we used a lot of that as the basis of our backfilling as well for the digital twin a lot of times we're looking at a little bit more of an aggregated view then specifically from the chain and internally at block science we are looking at creating a system where we can basically etl directly from different blockchains so at that point we could actually go from the ethereum IPFS um Filecoin system but for the if we're doing operational dt for making decisions about how to structure the economics going to that level of fidelity versus relying on like an aggregation that's even epoch level or or daily or even second level that kind of data is more what we need for operational dt so at the moment it's not going to create a for the amount of additional work to hit directly from the ethereum chain is not going to outweigh the costs because of where uh it's not going to create the benefit based on on what the aggregated data we need but definitely is something we're long-term looking towards the the closer we can get to the actual data and then have an aggregation layer the better and that's a long-term research project we're working on across all block science clients great thanks again to Andrew and Jamshid for that presentation and we're right on time to move on to our next speaker Nikola Greco heads crypto net lab at protocol labs where he works to build technological empowerment through providing secure building blocks for web 3 technologies today he'll be speaking to us about his work on the Filecoin data retrievability consortium welcome Nikola hello everyone it's a pleasure to be here i am actually representing iran and it was meant to give this presentation but uh due to last minute issues uh she couldn't join and uh this is most of iran's work and i'm here just to uh present this uh right so the key topic of this uh presentation is how can we guarantee retrieval from decentralized storage networks there are several storage networks like Filecoin which do offer retrieval but not a retrieval as a guarantee and we will dive into this more and it's very important that the retrieval the retrievability of files from decentralized storage network must be web-scaled so we can't just have a small decentralized storage network with a small amount of file that can be retrieved anything on the web should be able to be retrieved and also this allows not just the unbounded retrieval of storage but unbound unbounded onboarding of new um of files in our network uh we're going to cover four topic and talk briefly about kryptonite and then about data availability and friends data retrievability the topic of this conversation and then our one of our proposals uh we if we work on data retrievability uh it's because it's we believe it's important but it doesn't mean that uh the other topics that we will look into like data availability and proof of storage are not important we're also working on this uh for context kryptonite is a uh cryptography applied research group where we do uh fundamental crypto research and vector commitments snarks and so on but also protocol design and our goal is to have our group of researchers to collaborate with several other researchers to grants or collaborations and out of these collaborations we will have new researchers dows new projects and so on uh in through time we published several papers in the academic world related to uh proof of storage uh consensus protocols and so on but also we made the substantial improvements to the file calling network uh some of the most most notable were snark by co snark deal and one of the things that we also do is uh we gather a lot of ideas and start conversations on potential new protocol design and all of our work is public all the work all the work that we do with other organizations is public and you can see our kryptonite notebook which is where we post down ideas the moment they come to us some of these ideas like the one that we're presenting uh make into products as well so let's talk in high level about the protocols of the availability can be divided in two steps one is dispersed and one is retreat dispersed protocol works more or less like this uh the node that wants to distribute the data distributes to uh several nodes majority of the nodes approve that they have seen the data and then the protocol can continue if majority of the nodes don't give approval of the data being seen then the protocol holds or wait until uh there is a disapproval why because it's very important for data availability protocols the data is distributed and the data had the chance to be distributed to enough nodes so such that when we want to retrieve there is at least one of n in some protocols or m of n in other protocols uh available nodes honest nodes they're willing to serve the data this is perfect for sorry this is perfect for roll up data or blockchain data because we this data doesn't have to be preserved for a long time it can be proven and we need to make sure that at the moment of distribution not only a few miners saw it but as many nodes as possible but there is some negative aspects of data availability as a theoretical problem one is that it requires honesty assumption the node will serve the data there is in most protocols there is no guarantee that these nodes will be will be willing to serve the data later on and the second problem is that it requires consensus on dispersal which means that um there's a limit of the throughput of new data that can be dispersed in a consensus protocol why one of the core properties of a consensus protocol is that data gets distributed well enough so that everyone can verify that something has happened the correct way and in fact most of these protocols uh aim at one to four megabytes per second which is unfortunately not web-scaled if you want to uh if you want to do a storage network or or guarantee retrieval a reminder the retrieval is not guaranteed in these settings then there is another approach which is the proof of storage approach which is the one that we mostly use in phycoin and many other protocols use this as well the idea is that the node distributes the data to as many nodes that they feel that they're willing to replicate the data to this works in phycoin and it's different for other protocols and then from this moment onwards storage providers generate a proof on a daily basis in the case of phycoin to prove that they kept on storing the file but even in this case there is not strong cryptographic guarantee that the file will be searched the way we guarantee in phycoin of course is that there's always a we believe that if you distribute your file in a with several storage providers or if you pick storage providers that do the reputation then these storage providers will do a great job and and and that's how we get that's how most protocols guarantee that people and this guarantees on board the throughput because we don't have to have an agreement or like a consensus over consensus on the fact that a file has been distributed it's the role of the client to make sure that the miners the storage providers have received the file um so the durability is trying to solve these two problems unbounded um onboarding and the guaranteeing of retrieval which doesn't rely on assumption of one of M nodes are honest also most of these protocols are not really uh designed uh for providing retrieval long term and while most of the previous uh most while the availability uh it's great for solutions are great for rollups they might not be great for say NFTs if especially if we think that NFTs may be the standard for any digital asset then one to four megabytes per second is not going to be enough plus we don't want our data to be pruned in the future we want to make sure that data can still be retrieved uh later on so can we have a proof of delivery so someone gives you a file and I have a proof that they can give me a file otherwise I would prove that they cannot give me a file well we can't really have this without adding other assumptions if we were other assumptions so for example there is a third party that checks that these exchanges been done then that would be perfect uh but without trusted party assumptions then this is not possible so let's look at some attempts on how we go around um guaranteeing retrieval one way the naive way is to use the blockchain as a weakness so if we if we assume that data in the blockchain is always going to be served uh by nodes in the network then what we can do we can do the following we ask data to the storage provider the storage provider doesn't give the data to us we force them to post the data on chain now clearly we can post a hash on chain we can't post one megabyte file so this will never work for files there are or data there is a gigabytes big so this this technology so storing data on chain doesn't work for large data the other alternative idea is proof of retrieval is a beautiful primitive that as you query the storage providers to give you proof of the retrieval they leak data but it takes a very long time to leak a full file so the idea would be to keep on querying the miners with proof of retrieval until they give you a full file this works for small data this doesn't work for large data so the alternative is to have a trusted single party but that wouldn't be a deal and can we have a trusted third party that is decentralized and this is pretty much the approach that other oracles take so for example chain link as a network of users that agree on the price that they see across exchanges for bitcoin and in a very similar way we are proposing an oracle which says whether or not a file can be retrieved or not in high level it works like this so the node asks for the retrieval to several storage providers none of them gives them the file and then the node goes to the oracle that says I didn't receive the file go check if you can receive the file the oracle goes and check and if they don't receive the file then they slash the storage provider assuming that there is some collateral that the storage provider must put in order to participate in this protocol if they receive the file well then the retrievability oracle has seen the file and the retrievability oracle can serve the file back to the node and this is in high level one of the simple solutions that we're proposing the there are many big questions we will not cover in this conversation on how can we make an oracle these are true through telling incentivize the network the MVP which we will show at the end is having the oracle as a network of referee and the clients and provider agree on our retrievability deal you can think of this almost as an insurance contract on a retrieval of a file when the client requires the request the file and it doesn't get it back then it appeals to the referee the referee or the oracle the referee committee then we have a particular protocol where instead of putting the entire committee we query a subset even a single node as a single committee node they go and check if they if they can retrieve the file if yes they serve it back if not after k attempts of different referees then the provider is penalized this is the state machine of what i just discussed soon we're going to have a very nice diagram but we're working towards a prototype that is going to show in the next few slides there are other several steps in the protocol which is to sign up the provider must sign up we have a sampling of the referee which follows a particular protocol and then the retrieval deal the goal of the retrieval deal is that it can be possible and change the beauty of this protocol is that it could be cross-chain also the appeal works very simply in the in the as i described before and there are two retrieval two retrieval steps the retrieval step number one is that the leader doesn't get the file and so if the leader doesn't get the file then they propagate a message saying that they didn't get the file and and and they go to the next step if the leader sees the file then they share the files to the rest of the to the rest of the committee and the majority of the committee signs that they've seen the file and that's how we skip posting the file on chain we just sample a smaller a smaller network to check that the file is being it is available and propagated and it can be witnessed if the oracle can receive the file this means that the file was there from the storage provider it can then be propagated to the to the client if there is enough if there are key messages where the file was not well distributed then the storage provider gets lashed and you can think of this slashing almost like an insurance contract where this the retrieval ability deal in the retrieval ability deal the clients puts a premium that the money will get if they're always honest at the end of the period and when that one deal expires and if the deal is still active and the guest and the file is not being delivered to the client then they get lashed with a prototype of this smart contract and it's we we deployed this smart contract as three days ago and it it's live on on Ethereum Testnet and you can create deals and the way you create and you can create deals you can see where are the live deals you can cancel create them withdraw funds from contracts and and there's a slashing process and right now we have a small set of retrieval nodes that are part of the referee notes that are part of the comedy and this is how it's going to look like and this UX is just for the MVP and anyone can put any FFAC ID in here they can put what is the value of the deal the premium and then what is the duration of of the deal and so for example someone wants to make sure that they can complete the deal throughout the course of a month and then you will be able to manage your deals deals will deals are stored as NFTs and so you can think of that you that you could be you will be able to see NFTs in your in your in your wallet that shows which files you wanted to ensure the goals of this project is that we don't want to be a new network by any meaning we want to be able to compose with every network we want to give the ability for anyone they want to ensure sorry we want to give the ability for anyone to ensure ipfs files and any any node not just phycon nodes should be able to provide this service of course this we want to target phycon first and although the although the smart contract is being deployed on a video as soon as we're going to have the fdm this is going to be native in phycon as well and another goal is that it must compose with other retrievability solutions and that we are ourselves protocol labs and in crypto net are in particular are also working on and and the goal is that there will be a set of smart contracts that other other future providers can pack up and offer a single optimal ability solution and we want to give flexibility on pricing so clients and storage provider can choose the premium and the slashing and then finally we want to be web-scale we want to make sure that any file on any data on phycon can be insured and also this data from other storage providers this is the qr code for the data retrievability oracle project as i said before i'm just representing the project this has been worked from luca and iran and kryptonite with the help from sebastiano at yomo digital and john are from had and you can enjoy and you can join the conversations on the news like channel that we created which is called retrievability oracle and more broadly there is a lot of work that we're working on kryptonite from snap research to vector commitments to threshold network and phycon improvement proposals and we're always looking for great engineers to join our team and in particular product managers that can take some of these ideas and turn them into products so if you're interested in that contact us if you're working on similar solutions and you want to integrate with our with the retrievability oracle but also with other projects that you're working on future challenge so thank you nikola and luca and arena for that interesting overview of your work on retrievability really exciting news about that prototype look forward to seeing it deployed on fvm and for giving us some insight into your future goals about composability and scalability in the retrieval retrieval research we have time for a few questions and we've got one over here i'm just curious if what you would consider like prior art in the third um like what have you been inspired by on the retrieval on the sort of retrieval insurance thing um i think that um so let me put it in this way uh since 2017 some of us have been thinking about these problems and in the past five years we looked into a lot of different things from um so i've been influenced personally by a lot of people that crossed through product labs even in in in person in the company but also at events like this there has been several things that we didn't think that would work in the past uh and uh and then they got wide adoption and then there are there's a there's a protocol that is changing i think they do oracle really well and what's very interesting about that is that the economics works out such that um in order to um fake the oracle so fake an oracle outcome you need to buy a large amount of tokens in the in changing and that's very expensive and and so the question is it's a it's a solved problem to do an oracle for for getting values of websites it's very difficult to do an oracle that retrieves the storage from storage providers or even from ipfs nodes and then search the data back so that's a little bit more of an oracle and most of the most of the i think changing has inspired a lot of this in a way and then also in other solutions that we had uh that we have a protocol apps that some that didn't make and some that are working in a in a different way and for example five con saturn is a great example to look into and this is just a different take on retrieval believing and this by not mean the the best way this one of the many and it provides a specific service which is insurance on retrieval thanks one more question cheers thanks very much for the really good talk Nicola I was just going to ask you to expand a little bit more if you wouldn't mind about the the insurance model and how you're thinking about the pricing and what kind of factors and how that's structured uh yeah so uh let me tell you some of our team are we're a team of researchers and not a team of economists and so what we decided was that instead of writing inside of the inside the the protocol what would be a good price for insurance we left it open or what is the tool and the needs to be used for insurance we decided to leave it open to the to the market and this gives of course a lot of flexibility in the and I'm sure in the MVP we're gonna pick some members we're working with uh I think with some people from block science and trying to understand what would be a good value or a good pricing mechanism but there's one so to answer you I don't have a good answer on what would be a good price there are too many factors to be taken into consideration and there's still analysis that needs to be built through this but there's one thing that is important is that it doesn't mean that the the the search provider is necessary using dollars or or filecoin it could even be that the search provider puts um as coll