Filecoin Snap Deals - Lotus, 26 Feb 2022

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Lotus Snap Deals Demo 01: How to snap up CC sectors with deals

Description

With the Filecoin network v15 OhSnap upgrade storage providers now can literally store client's data in the committed capacities sectors on Filecoin within a Snap. In this tutorial series, zenground0 from lotus team will explain to you how to upgrade your cc sectors with Snap Deals using lotus!

More resources:
- Network v15 OhSnap: https://github.com/filecoin-project/community/discussions/74?sort=new#discussioncomment-1922550
- Lotus: https://github.com/filecoin-project/lotus
- What is Snap deals: https://lotus.filecoin.io/docs/storage-providers/snap-deals/
- Snap Deal Tutorial For Storage Providers: https://github.com/filecoin-project/lotus/discussions/8141

Follow @lotus-web3(https://twitter.com/lotus_web3) for the latest updates from the lotus team!

A

Welcome to the snapdeals demo, we're going to here run through a full snapdeals update, so you can see I have a minor setup running a 2k sector devnet and then on the bottom right. I've got a terminal to work in and on the left. We have a view on the sectors and deals that this miner has uh going for it so to get started.

A

Let's take a look at the new command for marking a ct sector as ready for schedules.

A

It's called snap up. All you do is submit an id of the sector that you want to snap up, so we can see that id6 is a proving sector, that's active and it's cc. So it's a perfect candidate for snap deals. So I'm going to run that and watch the state. So the fsm now marks the sector as being in the snap deals weight deal state. So this means it's ready to wait for deals.

A

I should note that while we are transitioning through the snapdeal states, the sector is still preserved. Nothing is changing internally yet and in general, the fsm works to keep the sector safe, so that window posts and winning posts are totally undisrupted during the process.

A

So let's make a deal using this little tool, I have in order to fill that sector up and get the snapdeal update going. So this is going to take a while. You can monitor the bottom left to see the deal coming in while we wait. Let's talk about what happens, because since this is a 2k devnet, it happens pretty fast.

A

So when the data is ingested into the fsm and directed towards this upgrading sector, it's going to get packed as usual into the sector and padded, and then it's going to transition into the snapdeals pipeline, which broadly consists of two phases. So there's the snapdeals replica update, which does the actual computing of the new replica and storing that data, and then there is the proof of that which uses the gpu hardware.

A

If it's there and takes uh yeah, it takes a little bit longer, we'll probably see we probably won't even see the first phase and we'll see the second phase. Just because again, this is a quick 2k sector, so things happen fast.

A

Once the proof gets computed, then we'll submit a message to the chain which establishes that the sector id should be proving over the snapdeal replica and uh cool. So now we're actually in the pipeline, like I thought we see the prove replica update, but trust me, the replica. The update replica step did happen.

A

So, while we're waiting for this to finish and go to the chain, let me show you some of the internals. So if you see in the bottom right, we now have a along with the sealed, unsealed and caches. We have these new update directories.

A

So if we go into here, you can see uh that we have some nice 2048 uh replica updates, so that process just created this last file here and you can see if you look back on the left- that we're now waiting for the chain to accept the proof that we've done the update correctly.

A

And you'll see that we've now transitioned on the top left into the update activating state. This is a finalization state. It means that we are now expected to prove and in fact proving with the fsm the replica update.

A

However, we are still keeping track of the sealed up replica, the original one that we just updated, also known as the sector key after this update.

A

So we have a lot more replicas than updated replicas, but we can see that the one that we care about, which is 6 is in fact here.

A

And again, 2048, because this is a 2k sector, so we can see that the sealed replica is still here. This is going to be the case until update activating uh is finished, in which case six will then be transitioned all the way back to proving. Why do we keep it around? Well, the answer is winning post, so window post is now totally going over the replica update, but because winning post operates on a finality, look back. We need to keep the field sector around for a while.

A

So that's that's really. It yeah thanks for watching.

A