Replies: 1 comment
-
I'm afraid that correct syntax is |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
What is Snap Deal?
Filecoin Network v15 OhSnap upgrade will introduce FIP-0019 - Snap Deals, which is a protocol for updating eligible CC sectors with deals with a single message to the filecoin blockchain.
Unlike the current CC upgrade, in which a new sector will be created and the sector will go through the entire sealing pipeline(AP, PC1/2, C1/2 & etc..) to get the deal sealed, snap deals allows a deal to be placed in a CC sector with a shorter, less expensive compute pipeline (UpdateReplica, ProveReplicaUpdate). According to the latest results from the testnest, this reduces deal activation time from 5-6 hours to 1-hour or less. Of course these results are hardware dependent, let us know how fast you may get data through the snap deals pipeline and into in the Filecoin network here!
Things You Should Know Before You Snap Via Lotus
Say Goodbye to mark-for-upgrade
2 days before the OhSnap upgrade epoch, the existing upgrading path will be deprecated.
That being said, if you run
lotus-miner sectors mark-for-upgrade
:OhSnap is coming soon, please use
snap-upto upgrade your cc sectors after the network v15 upgrade!
.classic cc upgrades disabled v15 and beyond, use
snap-up``.Configuration
There are a couple configuration worth calling out:
ExpectedSealDuration
applies to both Snap Deal process or regular sealing pipeline.MaxWaitDealsSectors
,MaxSealingSectorsForDeals
,WaitDealsDelay
,AlwaysKeepUnsealedCopy
applies to all Deal sectors, including SnapDeal sectorsAllowReplicaUpdate
andAllowProveReplicaUpdate
with true/false to allow/disallow corresponding job.MaxCommitGasFee
andCommitControl
address are applied toProveReplicaUpdate
as well.Snap Sector States
All Snaps start with an active CC sector, and under happy path, it will go through the following states (that shows in
lotus-miner sectors list
):SnapDealsWaitDeals
: the CC sector is snapped and is waiting for deals. It will move to the next states ifWaitDealsDelay
is hitSnapDealsAddPiece
: same withAddPiece
SnapDealsPacking
: same withPacking
UpdateReplica
: move to the next state if all pieces pass validation(size, expiration and so on) and snap deal replica update is generated successfullylotus-worker run --replica-update=true
orlotus-worker tasks enable RU
/.lotusminer/update-cache/s-<minerid>-<secNum>
and/.lotusminer/update/s-<minerid>-<secNum>
file being created during this processProveReplicaUpdate
: this sealing FSM state does two worker callsProveReplicaUpdate1
generates the vanilla proofProveReplicaUpdate2
generates the replica update with vanilla proof and proves that snap deals replica was done correctly, then it will move to the next statesProveReplicaUpdate1
is enabled by default on sealing workerslotus-worker run --prove-replica-update2=true
orlotus-worker tasks enable PR2
ProveReplicaUpdate2
SubmitReplicaUpdate
: submit theReplicaUpdate
message to the chain with sector information, including updated sealed sector cid, deal IDs, replica proof and so on along with the collateral(if applicable)ReplicaUpdateWait
: wait for the message land onchain successfully then move to the next stateFinalizeReplicaUpdate
: moves sector data to long term storage and cleans up the update cacheUpdateActivating
&ReleaseSectorKey
: clear the cached files safely then your sector will be ready forProving
againHow to Snap?
It's super simple, run
lotus-miners sectors list | grep CC
to find your all your CC sectors, then runlotus-miner sectors snap-up <secNum>
- that's it! Now you should see your sector status has turned intoSnapDealsWaitDeals
and ready for deals!How to Undo a Snap?
To undo a Snap, run
lotus-miner sectors update-state --really-do-it=true AbortUpgrade
anytime. Note: this will remove all the deal pieces and turn any sector to CC sector in aProving
state.You can then snap-up it again as desired.
CAUTION Doing this after
SubmitReplicaUpdate
can lead to a sector fault. This command should only be called if you are sure your UpdateReplica message has not made it to the chainBeta Was this translation helpful? Give feedback.
All reactions