Filecoin 🛠 Storage & Retrieval on Filecoin Part 1 - Matt Hamilton

Hello everyone and welcome to the HackFS workshop storage and retrieval on Filecoin part one. Joining us today is Matt Hamilton who will be taking us through this session and with that I'll pass it over to Matt to get the session started. Hello, thanks thanks a lot. So yeah, my name is Matt Hamilton. I'm a developer advocate with Protocol Labs specifically working on FVM at the Filecoin virtual machine.

And the point of this uh series and this is part one of a series of probably two, maybe three sessions going forward is to look in more detail about storage and retrieval on Filecoin specifically with a view of uh storage and retrieval initiated from a smart contract using FVM. So how can you write a smart contract in Solidity and get it to instigate some storage on Filecoin. So hopefully this uh talk will give you a little bit more information on the options you've got available for how you can actually make that happen. So as a quick uh recap here um you may have seen this before on previous talks uh especially in Sarah Tiam's talk uh that was on Friday uh regarding Filecoin and FVM. So the Filecoin master plan is build the world's largest decentralized storage network.

We're pretty much uh on our way there. We've we've we've done that. We're continuing to build out. The network is uh something around about 12 or 13 exabytes of data in size. So it's about the equivalent of about 1% of the total data center storage capacity is available on Filecoin.

Step two is onboard and safeguard humanity's data. So that is bringing on a lot of data from various places, things like scientific data sets, um archival stuff, um NFTs, all this sort of stuff that we want to store on there. And then step three is bringing compute to the data and enable web scale apps. Now, that's kind of the area that we're going to be focusing on today, and that is regarding using FEM to do programmable storage. And what I'm going to do is in this talk, I'm going to show you two uh different approaches to getting data stored on Filecoin from FEM.

And those can serve as a basis for building other things on top. And those other things will have a talk, a part two of this talk. Um my colleague Longfei is going to do a talk on um uh using these these tools for things like self uh replicating storage and self-healing storage. So, we're going to just focus on the basics in this talk here um and sort of where we kind of go from there. So, right at the bottom we've got kind of like IPFS, which is a peer-to-peer network.

It's slightly separate from Filecoin, but it's often used as a sort of staging layer for Filecoin and for pinning data. So, that's why that's mentioned there. Layer zero, Filecoin, the storage layer. Layer one that we're at now, FEM um compute over state. And then layer two, we'll be building storage-related uh dapps on top of that as well.

So, storing data on Filecoin. Uh my colleague Sarah created this great little flowchart, and this is available in the um cheat sheet that we've created, the hackathon cheat sheet, which we'll link to at the very end. Or if you search for FEM uh cheat sheet hackathon cheat sheet, you'll find it on on GitHub, no doubt. Uh but there is a link at the end. So, looking at this, we're starting with the with the the point of view of I want some storage.

So, I want to store some data. Now, there's two ways I can go about it, um programmable storage or programmatic storage or non-programmatic storage. So, non-programmatic storage, uh we can go down the sort of the blue side of this. Uh I'm not going to cover that today. That is doing storage without using FVM, and this has been something that has been available for a while now on Filecoin and using on-ramps like Web3.

Storage, Lighthouse, etc. directly through say an HTTP API and storing data onto Filecoin that way. I'm going to look at the other side, which is using programmatic storage. So, the idea here is I want to instigate some storage happening from a smart contract. Now, there's two different approaches depending upon when you're looking at a smaller amount of data or a larger amount of data.

And that boundary is roughly uh around about the 4 GB size at the moment. So, the reason for that being is that storage providers on the network, of which there's about 3 and 1/2 thousand storage provider systems on the network, storage providers are generally looking to store large amounts of data. The unit they work in called sectors, typically a 32 to 60 or 64 GB sectors. So, they are generally looking for data that will fill one or more sectors. Think of it a bit like they are like the wholesalers of the storage.

If you have a small amount of data, say you've got your 50 KB monkey JPEG, then the storage providers are not going to be interested in storing that to directly. It's too small data for them to store efficiently within a storage deal within a sector. They would have 50 KB of data and then pad out an entire sector out to 32 GB, uh which is you know, a waste of a waste of storage for them and not efficient for them either in terms of compute or in terms of economics for the system. So, if you're using a small amount of data, then you'd want to go via an aggregation service. So, I'm going to talk about Filecoin data tools here, which is one of the aggregation services um in in the system and I'm going to talk about direct deal making.

So, we're going to look at storing small data and we're going to look at storing large data and how you can go through these two areas from this flowchart. So, to kind of summarize the two different approaches here, if you're going less than 4 GB of data, you'll go via an aggregator. If you're going larger than 4 GB of data, you're going for a uh via direct deal. With an aggregator, typically the retrievability is immediate because you can retrieve directly from the aggregator initially um and then via Filecoin once the deal is made. If you're doing a direct deal, typically uh you're not able to access the data until a deal is made or until the aggregator at least has picked up um that contract and published the storage deal.

In terms of flexibility, with an aggregator, your data is combined with a load of other data and stored on the network. So, it's stored as one storage deal. So, you would be using the storage deal parameters that are set by the aggregator. So, in terms of the lifetime of the storage will be set via the aggregator. If you're doing a direct deal, you can set those parameters yourself.

So, you can say when you want it to start, end, how much you're willing to pay, for example. You can set those yourself. In terms of complexity, going via an aggregator is simpler because the aggregator handles a lot of these and you'll you'll see that a little bit when we when we go on further and we look at the um the the commands used to actually instigate this. With the direct deal, the complexity is a bit more advanced, but you have more flexibility there. So, it's that typical engineering trade-off between simplicity and and and flexibility there.

So, technology for the aggregator, what I'm going to show you today is Filecoin data tools. Uh these are the tools There was a service called Estuary and Filecoin data tools are the next evolution of the tooling behind Estuary. So, Filecoin data tools allows you to actually spin up effectively your own version of Estuary uh yourself. So, Estuary version two will be based upon this tooling set known as Filecoin data tools. But, Filecoin data tools you can think of as a as a superset of what Estuary did.

Uh but, the part that we're looking at the moment is uh kind of similar to what some people may have uh covered with Estuary before. And, if you're doing large and four deal uh 4 GB deals, what I'm going to demonstrate today is a thing called the client deal contract. So, to set this in scene, let's have a quick look at what the actual deal flow is. And, looking at this, you might think it's quite complicated. That is the case, and that is why I'm kind of showing you two approaches to dealing with this.

Now, the reason it seems quite complicated is that remember, Filecoin is designed to store vast amounts of data for a long period of time. So, a lot of the process actually happens off-chain because you are dealing with gigabytes, uh terabytes, petabytes of data, and you know, that is not something that is efficient to process on-chain. So, typically, a lot will happen off-chain, and then the final proofs of the data storage are actually put on-chain. So, with the deal flow, typically, a client puts some funds in escrow with the storage market actor, which is a smart contract built-in smart contract on the blockchain. The client then uploads a CAR file to a web server somewhere.

A CAR file is an archive file. Think of it a bit like a zip file, uh but, it is the the file format that is used within Filecoin for aggregating and storing data. It actually stores data as a um as as a DAG, um uh a graph, which means that uh, you can access individual parts of it as well via hashes. The client sends a storage deal proposal to the, um, storage provider. The storage provider is running some software called Boost with the URL of the CAR file.

In step four, Boost checks that the client has enough funds. If so, Boost will accept the storage deal. Step six, Boost will download the CAR file from the web server, publish the storage deal on chain, and then the client can check that it's on chain. Now, that entire process may take hours. It may actually take days for that to actually happen because storage providers don't necessarily, uh, publish storage deals immediately when they come in.

Depending upon the size, they may wait a while until they have enough storage deals to fill a sector. So, it might be that you're waiting a day or two for that whole flow to take place. So, just sort of setting expectations, this is not a flow that happens in in seconds. This is a flow that happens in in hours, typically. So, with aggregation, um, this is a diagram done by the Filecoin data tools team.

Uh, it shows you a bit about aggregation. So, historically, aggregation has happened off-chain. So, services like Estuary, Web3.Storage, uh, Lighthouse have typically been off-chain, but a number of parts of that now, as a result of FEM, are able to move on chain. So, Filecoin data tools here, um, we're going to actually, I'm going to actually show you how you can access that, um, from on chain.

So, typically, what happens is a file is uploaded to a service called Edge, uh, that is part of Filecoin data tools. Edge then will take these multiple files, put them in a bucket, uh, where it is aggregated together. Uh, the files are then stitched together to form a collection of data segments. It generates a proof, and I'll talk about that, uh, towards the end what that proof is used for. And then creates a car file, which is then passed to a tool called Delta, which is another part of Filecoin data tools, that actually will make the storage deal.

So, Edge is Think of Edge as the the HTTP microservice that you can interact with via HTTP, and it does certain things like aggregation, and allows retrieval as well of the data before passing it to Delta for storage. So, I've got two demos I'm going to do now. Um one a direct deal uh going through, and one using an aggregator. So, these are two different approaches, like I said, for a large amount of data, in the case of direct deal, or a smaller amount of data for an aggregator. Now, I'm actually going to demo these on a localnet uh that I'm running here on my laptop.

So, with that localnet, I can actually make a much, much smaller deals. So, I can make deals in the in the range of sort of kilobytes of size, uh because I'm running this locally. Because the sector size that I'm running locally is 2 kilobytes. Like I said, if you're running on uh the calibration testnet or mainnet, then the sector size is 32 or 64 gigabytes in size, so much larger. But, for the purposes of this demo, I'm using this localnet.

It means it can go through much quicker, um and I can kind of show you these things, um and show you both sides, uh both the client side and the storage deal side. So, if you want to get started with localnet, there's a GitHub uh repository you can go to, um and I will put that in the chat here. So, that's a repository you can go to that will allow you, if you've got uh Docker installed, then you can clone this repository, and go into the directory, type Docker compose up, and it will set up a completely brand new, blank Filecoin network for you, running locally on your computer. And you can then connect to that with tools like MetaMask and interact with that directly, right? So, there's instructions there on how to get that all set up.

So, um let's see. Where do we need to go from here? So, I have actually done this. I've got this running uh locally and we have here this instance here. Um this is just the log files kind of going past for the for Lotus.

Uh Lotus is the name of the software node, the reference software node for Filecoin, um and that is that is running here locally on my laptop. So, this is just watching the the log files go by. Now, the other part that I'm going to use for this is um a um uh starter kit. So, we have here the FVM um I haven't actually got it lo- loaded here. FVM Hardhat Starter Kit and that is available there.

So, this uh Hardhat Starter Kit has in it a contract here. It has the deal client contract that we're going to be running here. So, I have actually deployed this deal client uh to my local network. So, I did that I I ran yarn hardhat deploy --network localnet and it has deployed it to my local network and I have this uh contract running locally. So, now that it is running locally, um I can interact with it.

I have uh boost running. So, when I ran that Docker image, one of the things it set up was a thing called boost. And boost I can access uh locally and I can see the storage deals that are on here. Now, for the sake of brevity, I just ran a storage deal about 30 minutes ago um that is run on the network here. So, I can show you here um with that Hardhat Starter kit, um, I can run a command.

Now, you'll see a little bit here when I illustrate and say it's a little bit more complicated, you have to pass a lot of the parameters in yourself. So, I'm running this make deal proposal, um, method, uh, here. Um, and or task, rather, in hardhat. It is connecting to the contract that I have deployed that is at this address here. And I filled in a bunch of information.

So, PCID, piece size, all this kind of stuff to start epoch, end epoch, cost, everything here. Now, where is it going to get this data from? Uh, I have uploaded it to a place called the Lighthouse Data Depot. So, the Lighthouse Data Depot is just a tool. You can do all of this locally.

It's just a convenience tool that allows me to upload a file there. So, I created a file called, uh, hello hackfs. Just a small little text file. I uploaded it to, uh, a file called Data Depot. And it has calculated, it's created a car file and calculated all of these PCIDs and everything that I need here.

So, I was able to then plug those values into this command, and run this command. Now, running this command, contacts that smart contract. That smart contract then emits an event, and Boost, the software, sees that event here. So, we can see here, these are the log files for Boost, and we can see at the bottom here, that Boost has accepted my contract deal proposal. And then looking in Boost, um, we can see here that I have a deal here.

It's accepted it. And we can scroll down and see that it has actually fetched the data, um, from where it needed to come from. Um, and it has actually started the process of sealing this sector, right? And it is now in the state proving. So, what that means is it has taken the data, it has created a sector.

I've run published storage deal here as a storage provider. I can hit published storage deal. There's none left to publish at the moment. But when I did that, it then started the process and we're now in this state proving. So, this means that the data is on the blockchain and every 24 hours the blockchain asks the miner to prove that it still has my data.

Now, I'm going through this quite quickly. If you look on YouTube, you will see some videos where I've gone through this in much more detail and run it locally and gone through all the steps. I'm kind of skipping over the steps here for for for brevity. Um but that has now uh stored that data on there. And I can actually access that data now using a tool called Lassie.

And I have I think I've got it Well, if I got it here. Yes, Lassie. So, Lassie is a tool to fetch data from IPFS or Filecoin. I can say Lassie fetch. Because I'm running it on localhost, I've had to tell it where the provider is.

Normally, you don't need to do this cuz it uses a tool called IPNI, the InterPlanetary Network Indexer. Um but I've had to tell it I'm actually running on localhost here. So, look on localhost. And I've provided there the CID. So, that's the CID of the data.

Um If we look here in the deal ID, we can see this is this root deal CID that ends c o h i and I have that um here. So, if I run that command, Lassie will fetch that data. It's downloaded it. I now have a car file. This car file here named after um the CID.

I can say IPFS car {dash} {dash} unpack. Provide that car file. I'll now have a directory named after that. I can go into that directory and you'll see there's our hello hack FS. I can do that.

Let me just clear the screen so you can see it clearer. Hello hack FS 2023. So that's the file I uploaded, right? So that's going through the deal client process that we that I talked about. So this is a direct deal like I said I'm using local net and the hard hat starter kit.

Now the alternate approach and the approach that you're probably going to use with this hackathon is using the aggregator or using an aggregator. In this case I'm demoing Filecoin data tools and their aggregator and their tools Edge and Delta. Now to do this I've created a very simple um uh tool here called FTD data monitor and that is intended to be just a example that will allow you to um uh to to see what's uh to to actually monitor the chain. So oh I had some details of the direct deal. Um that's the process I went through um there with the direct deal.

Um so just to recap we're sending URL and deal parameters uh to the smart contract that was that big scary command. Um the contract emits deal proposal event. Storage providers running boost see that event and pick up the deal. We saw that in the log files. Storage provider can then fetch the data and publishes it to the chain.

So we saw all of that and we fetched it with Lassie. Um the aggregator we're going to do a slightly similar pattern here. Um we're going to send we're going to have a an aggregator smart contract. Now again this is just an example that I have created just to show you this. Um so there's a a repository here FTT uh deal monitor.

So I'll put that in the chat. And there's a very simple contract in here um that allows you to store a URI, and it will then um allow you to kind of see that data um there. So, what it'll do is it'll you call this store URI with a URI, and it emits a event. And what is actually happening is we have this tool FTD uh data monitor that is monitoring the events. So, this is a JavaScript uh little demon.

Again, this is just an example to show you that is listening to the event, and will then send the data to Edge. Uh so, we send a URL to this example aggregator uh contract. The smart contract emits an Edge uh UR contract event. Uh the local example uh FTD deal monitor demon watching sees the event. Makes request at Edge HTTP.

And Edge will fetch the data, and put it in an aggregation bucket. Once the bucket's full, it'll then create this aggregation proof, and will actually uh pass it to Delta to make the storage deal with the storage provider. So, uh let's see this here. So, that was our direct deal one example. I have this deal monitor here.

And I can run this. I'm running this locally. Um so, I've just checked out this FTD D deal monitor. Run yarn install. Uh to get all dependencies, and I can run just node FTD uh deal monitor ethers.

There's a dot env file in which you need to specify the RPC endpoint and your contract address um in there. So, again, I'm using a local network for this, but you'll probably want to do this on calibration net, which is our main public testnet. I'm doing this locally just for the um speed and efficiency of it for during a a demo. Uh I can now call a much less scary command that basically uh this hardhat store data and I pass it the contract and the URI. So again, this URI is the same URI we used before from uh the data depot on lighthouse storage.

And again, this is the local network. So, when I run that, that is going to make a deal proposal on the local network. And we'll see when that emits an event, we'll see our deal monitor will pick that up. It will see that event. It will then take that URL that's been passed to it, send it to Edge, and Edge will then fetch the data and store it, right?

And we'll see when that comes through. Hopefully, um when you're running on localnet, it's a 15-second block time. When you're running on calibration net and mainnet, it's uh 30 seconds. So, here we go. Um it's sending the payload.

There we go. So, let's just recap what it did here. It called um uh this Edge instance we've got set up specifically for hack FS. Um this URI here, I'll put this in the chat and we'll put this in It may already be in the hackathon cheat sheet. If it's not, we'll add it in there and put it in Discord, as well.

So, it is calling this um API request to fetch the URL. It passes the URL, it goes and gets fetched, and you can see here the response that's come back. It's got an ID. This ID is local to Edge. And uh it has the CID of the data.

But you can see here, inclusion proof is null. So, what is this inclusion proof? Once the aggregator has aggregated a whole series of data and created this aggregate CAR file that it sends to storage provider, one of the things you're going to want to do is be able to prove that your individual file is within that aggregate. And that is what this inclusion proof does. So, once it's aggregated, that will then include um some proof that you can send to an Oracle on chain, and you can actually prove that like your 50 kilobyte monkey JPEG is actually verifiable stored within that 32 gigabyte, say, chunk of data.

All right? Um there's no deal ID because it hasn't made a deal yet. Um it's only just got it. But what we do have is a status here, and um a download. So, I can actually take those.

Uh I can get that download URL, and I can run that as well. So, I could say curl pass that in and pass it to uh whatever out.car. And then I can do IPFS car {dash} {dash} unpack out.car.

Uh da da da Too many terminals. Data makes no sense. Ah, interesting. Okay. Some reason that out.

car Oh, that's because I've got the wrong one. I've got the status there. That's not what I want. That's not the URL I want. Uh I need the actual download URL, which is 1 second here.

I've just copied the wrong one. This one here. Um Ah, so that's just the wrong way around. Where it says status and download, those two labels are back to front there. Um so I need to get those uh those changed.

Um but we can fetch the data still. Let's try this again here. Curl fetch that data out.car. And then IPFS car {dash} {dash} unpack out.

and if we look here, we've again we've got a directory here and you can see it's actually got the same CID. Right? So, if I go into that directory there and look in there hello hack FS there's our file again, right? So, this is going by S3. So, S3 I can fetch the data from S3 there um and it has should have pinned it to my PFS.

We can check the status. Again, if I go back to um our output here, where is it here? So, I can check the status. Like I said, those two labels are back to front, but I can check the status here and I can say uh curl get that status and if I pipe it through jq just to format it. Um we'll see here the status, right?

So, this is telling us the status. Um there's no sub piece information here, no inclusion proof because it hasn't done the aggregation yet. Um and there's no deal information there. Um but if it has gone through all of that, then you'll actually see all of that aggregation data there. Um one of the things our script did after it has done all of that is it's actually updated our smart contract.

So, it has actually contacted our smart contract and passed in the um uh the information that's come from Delta. So, if we look at our smart contract here, it's actually called this update job ID method and passed in the job ID, the CID, and set the status to pinned so that we know it's there. So, I can now look up with this contract and I can actually find out and see what's going on here. So, I could use this as a as a building block. Again, this is just a very minimal example.

I could use this as a building block to then go on and build something like a replication service or a auto healing service or a data dow or whatever it might be. And once we have a deal ID, I can actually call that as well, and I can update the deal ID information here. And my smart contract, once it has a deal ID and it has the proof information, uh it would be able to actually verify on chain that my CID has actually been stored within a deal. All right, so once it's got that information, it can then put that all in there. So, um there we go.

So, that's a view then of going through aggregation. Um I think that's taken us to half an hour. Um here is a number of FEM resources. Uh you can scan this QR code or go to uh linktree. Can I actually get that?

I can't get that. Um I'll put that in the in the chat. Um but yeah, if you go to that QR code or go to linktree/filecoinvm, you'll get um links to the docs, the hackathon cheat sheet, use case ideas, etc. And thanks a lot, and this has been a team effort. This is just some of the people on here, but I'd also like to call out specifically the people within the uh Filecoin data tools team as well, um Alvin, uh Large Cake, who have been working on uh getting all of the stuff that I showed you with with Edge and Delta up and running uh so that we could demo this and have it ready for the hackathon.

So, there we go. Right. Um any questions here? Um I'm just looking in the chat to see um what we've got here. Uh can you send a URL to YouTube video where explained in depth?

Uh yes, uh I will do that. I think actually if you go to um uh YouTube, um IPFS thing. Uh I don't know. You probably find uh find it here. No, I'll find you the I'll find you the link to it.

It's on It's on IPFS things um It's on the on on the IPFS YouTube channel. So, I'll find it there. Um I'll put it in later. Uh can you provide links to where you can go through the aggregator example more slowly as well? Yes.

So, I'll put all of this um tutorial in um or this this talk rather. I'll put the slides in and also this has been recorded as well. You should go back and watch it. A lot of this is very much in flux at the moment and has come about very very quickly literally over this weekend some of this functionality. So, I hope to do a more in-depth slower run-through of it in which we we go through a bit more detail.

Um what I will say is probably the best thing to do is on Thursday uh we have um a live Twitch stream. I'll cover it in that. So, if you go to um uh twitch.tv/philbuilders I'll cover that. That will be at noon Eastern time on Twitch and I'll go through it and if you've got specific questions um as well related to that, you can ask there as well.

So, Madhav asks, "I'm creating a data smart contract. I have a question is when the proposal gets accepted in the contract, how can we store the metadata in Filecoin storage?" Um I store the metadata the JSON file. So, is that related to you want about the metadata specifically for something like an NFT? Um you would store in the same way via um an aggregator.

So, you use the same process there. I hopefully that I'm not sure if that answers your questions. Oh yeah, Rory's put in a link to the IPFS videos there. Thanks a lot Rory. And yeah, in there there's a there's a talk there regarding that um going in more detail.

Brain fried asks, is the CID generated based on the data content? Yes, that is one of the specific things about IPFS and Filecoin is the CID is a is effectively a hash of the data. So if the data changes, the CID changes. And this is one of the the the the really nice things about properties about IPFS and Filecoin is when you fetch the data, you can check it against the CID, i.e.

the address you asked for. So you can actually verify yourself whether the data that's been served to you is the data that you actually asked for. So the same data will create the same CID. Yes, with a slight asterisk. Remember I mentioned that a CID, sorry, a CAR file is actually a DAG, a cyclic a directed acyclic graph.

Well, there's more than one way to generate a graph with the data. So if you think you could go like depth first or breadth first, actually the same data can produce different CAR files, so can produce different CIDs. But yes, with with a once you've got a specific CAR file generated, then the CID would be would would be the same. Um but yeah, some implementations do slightly different approaches to creating the CAR files, i.e.

the the like the chunk sizes they use in the CAR files might be slightly different, so you might get different ones. So you could have potentially multiple CIDs reference the same data because the data is impacted in a CAR file slightly differently between different implementations. But if you've got the the the CID, you can verify that that CAR file is what you're what you're expecting it to do. Uh so, yes, somebody was asking, yes, it's related to NFT. Yeah, so you could store the the the NFT like JSON data file in the same way via an aggregator um there as well.

There's also there's nft.storage, which is uh specifically aimed at NFT. They uh don't yet, as far as I'm aware, allow you to or have a way to get data uh from on-chain into NFT.storage, but you could do the same kind of structure, the same process that I did here with this um deal monitor here. So, this deal monitor is a fairly uh what's it?

It's about 100 lines of JavaScript. And literally what it is doing is it is listening for events on there. It's listening for this store URI event to be emitted. Um once it's emitted, it uh decodes the event, gets the URI from the event, and then it actually sends it to um uh sends it to um Edge. So, this is actually a slightly older version here.

Actually, I just realized I haven't I haven't pushed the latest version um up yet. So, I need to do that just after this this talk here. Um but yeah, it constructs a payload here and sends that payload up to Edge. And it also stores it in a local database as well, just a local JSON database, so you could go back and reference it later. And then it updates the smart contract.

So, yeah, it's extended slightly from the from the GitHub version, but still about 100 lines of code. So, yeah. Okay. Um Yeah, my Discord my Discord and my Twitter uh uh, hammertoe, h a m m e r t o e. So, you can find me on Twitter or Discord.

I'll be hanging around in the um uh, ETHGlobal Discord in the uh, Falcon sponsor channel there. So, if you need any help, then you can come in there, um, and I'll find uh, find you there. Um, can we emit the event in the custom contract and use that? Yeah, that's just an example. So, you can you can you can create whichever event you want, um, and do that.

So. Okay. Uh, right. I think that's it. Um thanks a lot, everybody.

Yeah, thanks thank you much for the great presentation. Thank you everybody for attending. And again, if you have any further questions, please reach out on the Discord or partner channels. So, cheers. Thank you all.

Have a great rest of the day and have a good week. Great. Thanks a lot. Bye.