 Hey everyone, welcome, thanks for coming. I'm going to continue drinking coffee for a minute or two. Well, we'll wait for a couple more people to filter in. If you are in Zoom and wanna introduce yourself and say where you're calling in from, feel free to. Or same on YouTube. We're gonna have people, I think Paige is gonna be checking out the YouTube feed. And so if you have any thoughts or questions or comments or wanna introduce yourself there, feel free to do that too. Awesome, let's start walking through things. Welcome everyone to the June Filecoin Green annual virtual meetup. I am 90% sure it's June. And yeah, so what we're gonna do here is I'm going to go through just a few announcements about the Sustainable Blockchain Summit and Hackathon and some new references for tools we're building. Then we're gonna hear from William at Ken Labs talking about the next generation of the Filecoin reputation system. It's this awesome project that's been going on for a while called Pando. Then I'm going to go through the Filecoin Energy Use Model which has been around for a while and I've talked about it in many different contexts before but I've never actually gone through the model publicly and talked in more detail about how it works. Then after we go through all of that, I'm gonna stick around and some people from the Filecoin Green team are gonna stick around and just answer your questions, have sort of an AMA, we'll turn off a live stream for that part and feel free to chat or bring any questions you have. So the Sustainable Blockchain Summit is going to be happening in July. It's going to be happening in Paris right after ECC. This is a event that we are hosting in order to bring people from the sort of broader sustainable Blockchain community together in order to talk about what we can do to use Web3 in order to improve transparency in environmental reporting. So how can we understand what the environmental impacts of Web3 tech are and what can we do to make those impacts transparent and what can we do to reduce and mitigate them? And then how can we build all of that technology in a way that is general enough that it's applicable beyond Blockchains and beyond Web3? So this is the premier event for looking at what can we do to make Blockchains themselves more sustainable and how can we use Blockchains and Web3 tech generally to make the rest of the economy more sustainable and bring it into a better alignment with the natural world? And so this is going to be, like I said, near the end of July, July 22nd through 23rd in Paris. If you are interested in learning more, if you want to attend, if you want to speak, please go to sbs.tech or Paige also dropped in the chat the tickets link on Eventbrite to learn more about what we're doing. It's going to be a really great group of people. Some of the speakers that I confirmed already that I'm super, super excited about are Juan, Kevin O'Walkie from Gitcoin, Sharfi Edimantine from Gainforest, talking about using NFTs to protect the rainforest, Gregory Landua from Regen Network, which is one of the premier REFI projects, Linda Jurowskova from the Rocky Mountain Institute and Rafa from Toucan. There's a bunch more speakers that are coming and we would love you to be there if you are interested in this space and working on something cool, we really want to hear from you. There's also going to be a hackathon that is happening as part of the Sustainable Blockchain Summit. That's going to be happening at the end of this month, going into July, so it's going to be about a month long. If you are hacking on anything in this space, so if you are hacking on anything related to blockchains and sustainability, so either both of those directions that I mentioned before, so either making Web 3 tech more sustainable and more verifiably sustainable, or if you are using anything in Web 3 in order to improve verifiability and sustainability in the broader economy. So this is things like REFI, things like electricity markets, anything you're working on in this space, or if you aren't in this space yet and you just want to hack on some things in this space, we would love you to participate in the Sustainable Blockchain Summit hackathon. So please go to gitcoin.co. slash hackathon slash sustainable or hackathon slash sustainable slash onboard to get more info there and to sign up for this hackathon. Teams of any size are welcome. You can hack by yourself on something related to the theme sustainable blockchains or you can get a group of people together and tackle some of our challenge statements with a team. So please check it out and please do some awesome work in the space. The last thing I wanted to highlight here, it's an update, is the Filecoin Green documentation which is now live. If you go to filecoin-green.gitbook.io, you can check out our new and growing set of documentation that's up there. So there are two major sections here. If you are a storage provider, you can look at this green guidance documentation which is now up, which Mark has spent of probably two months, something like that, working on and really sort of getting feedback from a bunch of different SPs, taking some of the best practices from legacy existing industries. So things like the greenhouse gas protocol and really synthesizing what it means to be a sustainable storage provider and how you can, if you're scoping out a new storage provider operation, how you can make it as sustainable as possible or if you're already a storage provider, how you can make your existing operations as green as possible. So check that out. And then the other section of this documentation is the API docs. So that covers things like what I'm going to be talking about, the Falk Point Green dashboard and energy model. Also, if you want to understand whether an individual storage provider uses renewable energy, that's where you can go to get more information on any of the tools that we're building. And so if anyone has questions about any of this, please drop them in the chat, either in Zoom or in YouTube or reach out to me. And that is it for a quick update. We're now going to go on to William from Ken Labs to talk about the awesome work that they're doing at Pando. Pando is the next generation of the Falk Point reputation system. And it's where you're going to go if you're a client who wants to store data on Falk Point, Pando and the reputation system or where you're going to go to understand things like the reliability of individual storage fighters, but also things like whether they're using renewable energy or what their green credentials are. So William, if you want to talk through the awesome work you're doing at Pando, go for it. Thanks, Adam, thanks for the introduction. Okay, this is William from Ken Labs. It's really my honor to be here and present what we have done so far in Pando to the Falk Point Green project. So you must be wondering what happened and what will happen when Falk Point Green meets Pando? Okay, so what is Falk Point Green? I think most of the folks here are pretty familiar with it. In general, I think we all agree Falk Point Green aims to measure the environmental impact of Falk Point and verifiably drive them below zero building the infrastructure along the way that allows anyone to make transparent and substantive environmental claims. And then what is Pando? So Pando in general is a Web3 database that ensures access to nodalized data. So imagine actually in the network, there are a number of emerging streams of data, including testing or minors by variables like reputation services, availability and demand for data which are not directly hashed or part of the Falk Point chain are foreseen as important to keep associated and available for the ongoing health of the network. The historic state of these data streams are useful for comparative analysis and the understanding of the dynamics of the network and deserve to both be preserved and made available. So we were looking for a sidechain service, metadata service that can take these streams of data, aggregate them into car archives and back them up to Falk Point and provide a lightweight query interface for consumers to read specific points of metadata with higher assurance of the global consistency and the veracity. So eventually we came up with the idea Pando project as a sidechain metadata service. So we can say IPLD will be the first class citizen in Pando. It will keep data storage consistently available and provide the lightweight bias data access. It will also discourage historical revisionism. Okay, so this is the original imagination of the Pando Pando use case. For instance, reports of minor behavior can be used by a reputation system to rank miners which then are used by the clients to select higher quality miners near them. So this data doesn't have to or doesn't make sense to directly embed within Falk Point chain for a couple reasons. It's produced by independent entities. So the data itself does not need to meet same consensus bar as what we would expect in a global chain. And likewise aspects of reputation and the measurements may have aspect of subjectivity. So in the use case shown by this diagram Pando will provide the data storage solution to the reputation system. So let's quickly take a look at the Pando network. Actually, there have been already a number of parties that have integrated with Pando as provider or consumer. For example, there are post metrics to Pando regularly as provider, like data provider to Pando. Firewrap and FireDrive, these projects, they consume the robot metadata as reputation scoring. In terms of Falk Point green, it has a bunch of different types of data in the whole workflow. So far the minor location data collected by the pipeline setup by Gimpic is periodically synchronized to Pando for storage. And in the near future of Pando will support more scenarios for Falk Point green. In terms of more details, it will be covered shortly. So this is the Pando network. So what's the future of Pando? So DeltaDB, probably a new name. So this is a product which will be the ultimate state of Pando. It will not be solely data storage. In DeltaDB, it will be having a lot more features. The data will be represented in IPLD same as what we just mentioned in Pando. So data immutable and the verifiable. BIDs, the decentralized identity will be applied with verifiable credential which enables authentication and the authorization in data access control. So on top of these fundamental IPLD data processing and the computation will be enabled. So this is a key to the success of IPLD data model and decentralized data storage. So how will DeltaDB or Pando serve the Web3? In our understanding and our vision, so DeltaDB will be widely serving products and projects in Web3 which are IPLD driven. In the IPFS and Falk Point ecosystem, there are loads of products that are producing IPLD data. So DeltaDB can empower them to more efficiently store IPLD data utilizing and fulfill their application demands. Actually, we have been serving a bunch of applications. So as we have been integrating with them and the serving their requirements, so we realize the existing IPLD ecosystem including the core libraries, the infrastructure, the implementations and components they are not powerful enough. So the clients of IPLD, they require more processing and the computation power to enable the exciting features. So the repetition system is a great example. So not only for data storage, the computation power is also the key to this product. So this is from the technical perspective to see how DeltaDB will serve the Web3. So in short, DeltaDB will help shift the storage and the computation to off-chain to enable the robust computation and the storage requirements without sacrificing any security or scalability requirements. This is also a very common pattern the layer two protocols may apply. So I'm not going to talk too much details here about the techniques. So this is how the DeltaDB can serve the Web3. This is another view from decentralization point. As a computation is decoupled from the blockchain node, this means the computation can be run as a serverless function. So off-chain computation allows the combination of the blockchain ledger maintain status with serverless function. So you can imagine this network as an ecosystem of the chain node, task orchestrators and the workers, which is then associated with the DeltaDB node network to handle the data. Okay, let's come back to the FireCon Green. So this is a main topic for us today. A bit facts of the project before we look into how Pandora has supported FireCon Green. Currently, the majority of the data flow or the workflow in FireCon Green is still a two-based. So we can see that data is stored in a centralized database. The, for example, the application server, the HTTP server is also a centralized service. And the crucial FireCon Green data require authenticity. And to make reporting radically transparent and very viable. So FireCon Green also require a ledger to manage the data-changer records. So we can see how and what Pandora has done for FireCon Green. Firstly, this is a diagram we can show the work we have done so far. So as I just mentioned, Jim set up a pipeline to collect minus location. So these location data is exposed by a JSON API. So that's what you see on the diagram here is a location API. In order to affect, not to affect the current workflow, so Ken Labs developed a standalone service called GreenSync to periodically synchronize the location data from that JSON API to Pandora. So in this way, Pandora makes the data verifiable and change history trackable. Pandora also enabled curing locations by minor ID. So which is equivalent to what's already supported by the current Web 2 infrastructure. Pandora also enabled it over GraphQL interface. So with this interface, the minor location visualization can be implemented based on the GraphQL API for the interface. So currently the location data is stored somewhere in the cloud. So in the future, once we are confident in using Pandora as the main storage of the location data, we can experiment how to directly push data from Jim's pipeline to Pandora so that the centralized cloud storage will not be needed anymore. So again, in the future, the GreenSync module that standalone service can also be considered should get merged into the Filecoin main system for the direct data push. So far, that's just a very small use case Pandora already supported for Filecoin Green. We are looking forward to seeing great success in Filecoin Green. I also had several rounds of discussion with Alan and Mark. So we also came up with three to six months feature plan of Pandora. So for Filecoin Green, firstly, storage provider should be able to report a crucial metrics to Pandora. And the auditors should be able to go to Pandora, get authenticated and authorized so that they can verify the metrics from Pandora. Then with the verified metrics, Filecoin Green should be able to showcase the improvement made by the storage providers while Pandora and compare it to the estimate based on Filecoin Green methodology that's shown on the Filecoin Green Energy dashboard. If I remember correctly, so Alan already introduced this dashboard in previous meetup, if anybody interested, you can visit Filecoin.energy to see more details. So Kenlabs has put much effort on the verifiable data storage. In the future with the decentralized identity, DID enabled. So we should be able to see a better Pandora which can support the full end-to-end scenarios of Filecoin Green. Okay, so let Pandora make Filecoin Green reporting more transparent and verifiable. Thank you very much. Awesome, thank you, William. There was so much embedded in what you just went through, I think this whole computing paradigm where a function has a CID and the input and output data have CIDs, I think this is like, we're just really starting to develop what computing looks like, where like data and transformations between data are all content-addressed. And it's just like, combining that with the ability to have these like IPLD formatted side chains is just gonna be, it's gonna be like hugely transformational for everything people are doing in this type of space. I'm really excited about it. Sorry, yeah. That's true, so now we already have the storage for the IPLD. So we believe as we put more effort in Pandora, we should be able to give the users some computation power on top of the data. So like in Filecoin Green, so we can move more and more web two scenarios to Pandora or web three so that it can be more verifiable and more truly web three application. Yeah, 100%. As you mentioned, there's already a bunch of data on Pandora right now, including Jim's location data and including other like Filecoin Green data, there's gonna be more end data from the deal bot. If people want to start playing with Pandora and pulling some of this data, where should they go? So the primary place they should go is github.com slash canlabs slash pandos. So that's the main repo and the documentation where we put for Pandora. So if you are interested in integrating with Pandora or consuming data from there, so you can go to our main github. So you will see how to do, firstly, you will learn how to integrate. And if you need it, you can reach out to us to get more details about in terms of the technical details, even on how to consume or what data I can consume. So I believe, so yes, the main repo and the repo should be the place where you go. Feel free to reach out to us if you have any question or doubt. Awesome. Does anyone have any questions about what we just heard? Feel free to type them out in the chat if you do. I'm not sure if you guys can see the chat in the Zoom. I'm looking at the Zoom chat. I think there's a YouTube livestream chat too. Yeah, thanks, Alan. You just painted the links here. So github.com slash canlabs slash pandos, that's it. Awesome. Well, thank you so much for talking to us and walking us through all of this. I think it's gonna be really, really powerful going forward. Thank you. Thanks, Alan. All right, and if people do have questions that come up, feel free to drop in the chat. So next I'm gonna walk through the Filecoin energy use model. I also, one more time, just really wanna plug the Sustainable Blockchain Summit, which is that you can go to sbs.tech. If you wanna learn more, sign up to go, apply to speak, suggest a talk. It's gonna be July 22nd through 23rd in Paris right after EPCC. We have a bunch of really great talks lined up and the Sustainable Blockchain Hackathon is gonna be happening the month leading up to it. Oren is, I believe, in Zoom right now. If you have more questions about the Hackathon, please feel free to drop them in the chat. She's been doing an awesome job working with Gitcoin to organize this whole really awesome hackathon. So yeah, please check it out. Please sign up and let us know or Ayn just mentioned in the chat that she's around and if you have any questions, please drop them in. So the Filecoin Green dashboard that William just mentioned is something that we've used a lot. We've talked about a lot, but I've never actually explained in any detail I've realized in public how this works. And so I wanted to go a little deeper into sort of where the data in the dashboard comes from. And so if you look through here, if you go to the bottom, this is sort of the most like fundamental metrics here, you have the amount of data storage capacity for an individual Filecoin storage provider and in the network and you have the amount of capacity added per day. So this is the ceiling rate. And then we go through and we look at all of these different metrics. So things like cumulative energy use, but then energy use to store data, energy use to seal data. So we're taking ceiling rate and translating that into an amount of energy. So megawatts is a rate of energy use per time. Megawatt hours is the cumulative amount of energy you can see here, or terawatt hours in this case. So there's this question, right? Where does all of this data come from? So on chain, we have information about the amount of data sealed over time and the amount of data that individual storage providers store over time. So these are the main sources of energy use in Filecoin, right? So if I'm a client and I wanna store data on Filecoin I choose a storage provider, maybe using data from Pando to see whether the storage provider is using renewable energy and what the storage providers track record is. So in the past, how reliable they've been in terms of storing other people's data. I choose a storage provider. I transfer the data to that storage provider and then the storage provider has to do two things with it. So there's this initial step, which is called ceiling which allows the storage provider to set up a set of zero knowledge proofs that are going to allow them to prove that they're continuing to store a replica of that data over time. Then they actually have to store that data over time. Right, and so these are the two major phases of Filecoin, operating the Filecoin blockchain that require energy. And if you wanna store data as a storage provider you have to stake some Filecoin to begin with in order to store that data. And you have to continue to submit these storage proofs over time. And if you don't do that, then your stake gets slashed. Right, so that's the fundamental mechanism and that's why these proofs of ceiling and storage are actually included in the Filecoin blockchain. And that's really, really powerful from an energy use perspective because what that means is that we can go to the blockchain and we can see proofs of the computational and storage resources contributed by every individual active storage provider over time. And we can then use those proofs in order to determine what the energy use is for an individual Filecoin storage provider. And so an example here, right? So that's the idea for these numbers in the dashboard. If you enter in an individual Filecoin storage provider we can see all of this data on their energy use that ultimately originates in this ceiling. So data storage capacity added per day, that first step and then the actual amount of data stored over time. So this data storage capacity is sort of the cumulative amount of data sealed over time. That an individual storage provider is storing. So then the question is, okay, how do we go from that information, those proofs on chain to things like energy used to seal data and ultimately the energy consumption rate? So if you go in here, this GitHub repo I'll drop in the chat. This Filecoin energy estimation GitHub repo has the answers to all of that. And so if you look in here, so there's a description here these models are versioned and you can look at these model parameters if you wanna know for a given model version you can go and look at, you know say this more recent model version. And you can see in here these three different parameters in this model. So this parameter for sealing tells you in watt hours per byte how much energy it takes to seal a given amount of data. So that's one of the, one of the parameters that we can use. So we can go in and look in the Filecoin chain we can see on a given day or in a given epoch or over a given month or quarter or a year how much data was sealed by this individual Filecoin storage provider and we can get this minimum this estimate and this maximum and we can take that amount of data multiply it by this constant in order to get the number of watt hours so that cumulative amount of energy that was used in order to seal data over that given amount of time. And I'll talk more about where all of these parameters come from but these are the basic parameters in the model. This is sort of fundamentally how the model works. Then we can do something similar for storage but whereas sealing takes a given amount of data sorry a given amount of data and uses a certain amount of energy in order to seal that data storage is a continuous power draw, right? So sealing is like turning a light on for a given amount of time and then turning it off and then the data is sealed storage just takes more energy to store more data over time. So storage is just like leaving a light on and so that's why the units for the sealing constant are watt hours and the units for the storage constant are watts. So this is a continuous power draw, watts whereas watt hours is just a discrete amount of energy, right? So we can look at the amount of data stored by a given storage fighter multiply it by one of these constants to get an estimate or the minimum or the maximum amount of energy that we think so like the upper bound, lower bound and estimate of the continuous power draw of this following storage fighter based on the amount of data that they're showing. Then this last perimeter here, the PUE is called the power usage effectiveness and that is the ratio of the total amount of energy used by a data center. So that includes all of the systems like cooling and like power conversion losses that you need to operate the data center but don't actually go into the computing hardware. So don't go into the GPUs and CPUs and hard drives and solid state drives just so the PUE is the ratio of the total energy use to the actual energy consumed by that hardware. And so the idea is that if the power usage effectiveness is higher then you're using more energy in all of those other systems. So again, we have a minimum which is pretty efficient which we're saying 1.18 we'll talk about where these numbers come from then we have an estimate as to the average power usage effectiveness of a given data center, data center being a data center that a file one search writer is in and then we have a maximum value which is the least efficient. So the most amount of energy that is being used for these like overhead systems like cooling, right? And so that varies. So this gives you an idea of these basic parameters here and that's how the model works, right? Is the model takes the amount of data sealed over time multiplies it by these numbers then it takes the amount of data stored over time multiplies it by these numbers and then it adds those two that the continuous power consumption for each of those two multiplies that by the power usage effectiveness to account for overhead energy use and that's this like total number that you get in this energy consumption rate. So the upper bound here is the upper bound of all of those numbers. The estimate is the estimate of all those numbers and the lower bound is the lower bound of all those numbers that are parameters in this refill. So that's the actual data if you want to do these calculations for yourself but where does this, where do those numbers come from? So you can go in this File Point Energy Estimation methodology to this write up which talks about the history of this model and where this model came from and explains it. This is that equation that I just walked through which takes the amount of so it takes the ceiling rate multiplies it by some number takes the capacity of a given storage writer multiplies it by some number and then it adds those multiplies those by the power usage effectiveness which I just went over and that's how you get the amount of power used by one of these individual File Point Storage Writers. I'm gonna go more into how each of these how we got each of these parameters, right? But firstly, does anyone have any questions of just what I've went over so far? If you wanna drop them in the chat, questions, ideas, concerns, thoughts, hopes, dreams, you know? Okay, please do feel free to drop a question in the chat somewhere if you have any questions as things come up. But so this is the form of the model, right? Where the ceiling rate we can get from on chain proofs, the capacity, the amount of data stored over time we can also get from on chain proofs. Then the question is in order to determine the power we have to find this constant, this constant and this constant. And so the first thing here is to look at the ceiling energy. And so what we did in order to determine the ceiling energy and the energy used to store data are the first thing that we did is we started with a survey. So we sent a survey out asking, over the past month or so, how much storage capacity have you added? What is the peak power of your ceiling hardware? And what do you estimate is the average power of your ceiling hardware? So we're trying to get information from each of these storage writers who was answering the survey on the amount of energy that they used in order to contribute a given amount of storage capacity to Filecoin. So that is one of the sources of data here. Another source, let's see. So another source of data on all of this is benchmarks. So in addition to the survey data, if you go here, you can go to the Filecoin Benchmarks repo, you go to these community minor hardware profiles and Lotus Benchmarks. So this gives you things like, for a given hardware configuration, what is the amount of time that it took for that hardware to seal, say, a 32 gigabyte sector? Right, so there's a few different sources of information we used. Part of it was Benchmarks and part of it was the survey responses. And then what we found was that this was the distribution of different numbers. So when we took, say, a survey response and we said, what is the amount of energy on average that a given storage writer took to seal one byte of data, we got this range. As you notice, this varies a lot. And on the upper range, on the upper end of the range, we have values that are more than 10 times, probably 100 times, the actually more than 100, spread's pretty high, the lowest values that we got from these surveys. And so here's a summary of this. And this table is the data that's in this chart. And so we looked at this and we tried to understand what the... We tried to sort of make sense of this data, right? Because some of the variation in here comes from differences in hardware, but some of this variation comes from differences in, say, methodology between survey responders, right? So we don't really trust, if someone says that they're using 10,000 times less energy than some of these higher people, we think this is like 10 to the minus 12 number is probably someone who either made an error in responding to the survey or didn't sort of understand what was being asked, right? But so we combined these surveys with some interviews of some individual follow-up on the search fighters, we're able to walk through what is your hardware configuration, what is your software configuration, right? So if you're able to, many search fighters who are more sophisticated are able to, say, parallelize different steps of the ceiling process on multiple threads of the same CPU, right? And so you're able to make this process dramatically more efficient than if you don't parallelize these processes. And we're able to look at, okay, based on a well-substantiated response, where we really got to dig in over the course of talking to them and taking a bunch of data from them and working through all that to really understand their configuration. This is a very efficient follow-up on storage fighter, but we actually do believe that this is a good number. And so we chose this as a lower bound and it was near the lower bound of some other survey responses, right? So this is what we chose as a lower bound for this model. Then another follow-up on storage fighter gave us these numbers and we worked through them as an estimate. We were able to understand why are they getting this performance out of their hardware instead of this performance. And we chose this as an estimate for a typical follow-up on storage fighter that's maybe not as fully optimized as this one, but is getting pretty good performance. And then what we then used for the upper bounds is we tried to understand if you just take some of these benchmarks and you are not optimizing your process and you assume that, say, the CPU is running at what's called a thermal design power. So it's running using its maximum amount of power draw over the entire, you know, say three and a half hour period in order to steal this 32 gigabyte sector. That's an unrealistically high assumption, right? So these in red, we used the benchmarks in order to determine what is a power use number that is too high. And the issue here is that hardware does not run at thermal design power through the entire sealing process, right? It runs approximately at thermal design power for half of the time during the sealing process. And so these two asterisks here are the thermal design power times different benchmarks, right? So we know that these numbers are definitely too high and they're too high. We think by about a factor of two. So these two that are in red, but don't have asterisks, those are survey responders where we're pretty sure the way that they respond to the survey was they took the thermal design power and they took the benchmark and then they just reported that data. So this was not an energy use measurement. This was a, you know, these were, these were actually like unrealistically high numbers, right? And so we chose this upper bound here and said, okay, this is a survey response that is clustered with other reasonable survey responses and interviews, right? So there's this jump here, which is that if you just use the thermal design power, you get a number that we would expect to be about twice as high as the real value, but we chose this upper bound here to be a survey response that is on the high end, but lower than these, these unrealistically high thermal design power values. So that's how we got these three numbers, right? For the lower bound estimate and upper bound of the ceiling constant, right? This number where we take the amount of sealed data, we multiply that by this constant in order to get the number of watt hours. So the amount of energy used to seal that data. So then we did something similar for the amount of energy used to store data over time. And so we asked here in the survey, what is the power consumption and capacity to store a drag in your system? Because we wanted to understand as you are storing data, as you're running these hard drives to store data as a storage rider for clients over time, what is the actual amount of power that goes into storing that? And so as you see here, there's again a pretty wide range. The range in the amount of energy used to store data, right, comes partially from differences in hardware again. And it also comes partially from differences in configuration, right? So if you have a large rate array that is optimized in order to allow you to keep the hard drives off most of the time, you're gonna use drastically less power than if you aren't optimizing your operation very much, right? So if your hard drives actually need to be kept spinning for most of the time, and it's gonna be a very different power usage profile from if they're not spinning most of the time. Another thing that really affects the power usage of hard drives is their age. And the reason that affects their power usage is just that the energy use of keeping a hard drive running goes into spinning the physical hard drive, right? And if you are able to pack more bytes into the same size of disk, then use the same amount of energy to spin that drive, but you're able to store more data in that disk, right? In that like physical disk that you need to spin. And so the amount of energy used to spin the drive compared to the amount of data on that drive decreases as the storage medium gets denser. So that's one of the sources of variation here. And so what we did hear again is we said, okay, here's a very optimized storage fighter operation. And we were able to work with them and really understand what is the hard drive configuration and how are they getting this better performance compared to most of the survey responders? We chose them because we actually do believe that this is a really good, well-considered value for a very optimized storage fighter. Then we got this estimate. This again was from an interview we did where the storage fighter operation was less optimized than this one, but it was pretty good. And so we use this because we know that this is a very well-considered again value where they really are endeavoring to measure the amount of energy that they're using in the storage fighter operation rather than just grabbing something from a spec sheet and using that to respond to a survey. The things up here, we used a recent, so for this upper bound here, we used a spec sheet, right? But we didn't use, we again aren't assuming that this hard drive has kept running the entire time. We are using the average hardware value from the spec sheet. And let's see, so this is 8.1, have 10 to the minus 12. So this is this Western Digital 2019 number two spec sheet. And we said, okay, because storage fighters are frequently able to just keep data in cold storage and just spin up these disks for a few minutes a day in order to read some data from this drive, that's a much lower energy use profile than any of these hard drive manufacturers is going to use for typical hard drive use, right? And so we used from a spec sheet, their typical hard drive use number shows this as the upper bound and said, if our main goal here is to achieve an upper bound for the network such that we know that the network is using less energy than this upper bound, we're pretty confident that when you take all of the storage fighters across the world, many of them who are much more optimized than this, that the overall average energy of the network is going to be significantly less than this upper bound defined by Western Digital's, you know, spec sheet. And so we said, okay, so this is an upper bound that we are confident is much more than the network is using. On average, we think most storage fighters are actually closer to this lower bound maybe near this estimate, right? So that's how we got those two parameters. And it's, I've been talking for a while and I wanna give people time to ask some questions if you have any, but I think the last parameter to go through here is this power usage effectiveness. And so this PUE is the total amount of power, right? It's power total used by this data center operation over the power from IT equipment. So that's the equipment that is actually used. So the CPUs, GPUs, hard drives, all the actual IT equipment that's used to do real work whereas this power total includes things like cooling and includes things like conversion, conversion losses. We assumed that because Falcon storage fighters have operations that look very similar to typical data centers, we assumed that the power usage effectiveness values are going to be in line with typical data centers, right? And so what we did is we got some data from the academic literature. So Massinets data on hyperscale data centers, power usage effectiveness, 1.18. Then his estimate for the power usage effectiveness of traditional data centers. So these are less optimized data centers than hyperscale data centers. About half, a little under half of the amount of energy that they use goes to these overhead sources of energy use. So things like cooling and things like power conversion efficiency. And then we took data from the Uptime Institute in order to get the industry average power usage effectiveness and use to this as our estimate value. And so when you take the amount of... So that's how we got these parameters, right? So you take the ceiling rate, data storage capacity added per day, multiply it by the upper bound, lower bound and estimate of the ceiling values, right? That I just sort of described both where to get them and where they're from. And that's how you get this number, use the same thing for storage energy use. You get this range, this lower bound, this upper bound of this estimate. And then when you add those together and multiply the sum by the power usage effectiveness that accounts for things like cooling and power conversion efficiencies and you get these numbers here. So the last thing to go through here is we've done some work looking at comparing the model outputs to actual storage fighter energy use. And what we find here is that, so the way to read this is for a given storage provider in this given month, what was the actual energy consumption based on data that they've shared with us? What is the minimum of the model? What is the estimate of the model? What is the maximum of the model? And we find for these four storage fighters during these four different months, the maximum is indeed larger than the real amount of energy used. So in this case, it's 170%, 200% or 10% larger or 561% larger. So this variation in overshoot of the max comes from the fact that some of these storage fighters are larger and better optimized. Some of them are smaller and not as well optimized. So for a very optimized data center, we actually get a number that is close to the estimate and the maximum overshoots by a significant amount. The estimate is, it's 20% off, which is actually not that bad given the fact that we're trying to estimate the energy use of this distributed permissionless network. And then the minimum here is still lower than the total amount of energy used by this data center. And you can sort of read through this table and this gives us more confidence that our estimate is reasonably in line with the energy use of medium to large size storage fighters. And crucially, this upper bound really is higher than the amount of energy used by these typical storage fighters. I believe this table is not currently in the data that we've published, but we're gonna publish this. And so people can take a look at it and give us some feedback. And then as we are working with storage fighters, which we've started to do in order to allow SPs to make very strong audited claims about their energy use. So submit a power bill, have a third party auditor look at that power bill and verify it. And then have that third party auditor sign and store on Pando, a record showing the actual amount of energy use by the storage fighter. We're gonna continue to refine this model by taking that audited data, running analyses like this. And as we tune this data, as we get more information, being able to publish new versions of these model parameters, right? So maybe 1.0.2, which should over time have a better estimate of storage fighter energy use and hopefully lower those bounds some as we get more really high quality information. And so our goal here is to build this continuous feedback loop where we're really able to take these on-chain energy use, or these on-chain records of computational resource and translate them into energy consumption estimates that get better over time. Because the last thing to highlight here is that studying the energy use of these permissionless distributed systems is an extremely complex and difficult thing to do. And so what we are aiming to do, right, is take these large bounds, learn more about how the network is evolving over time and just get more data on the current state in the network over time and hopefully lower those bounds while making sure that when we connect this energy use with renewable energy, we're doing a really good job of making sure that we're buying at least as much energy as the network uses. So tying it to that upper bound to make sure that we are buying an adequate amount or over buying or storage fighter making strong renewable claims are buying enough energy to really cover the amount of energy, buying enough renewable energy to really cover the amount of energy that their operation is actually using. So that is a deeper dive than I had done before on the Filecoin Energy Use Model. And I am happy to take any questions about what I just talked about or if you have any questions about Pando that you thought of, I think William had to run, but if you wanna drop anything in the chat, feel free to. And then in a minute, we'll just hang out in the Zoom and see if people wanna talk about anything else.