Decoupling proveCommit and deadline assignment of a sealed sector #570
Replies: 4 comments 4 replies
-
|
Thanks for starting this, @steven004. It's worth noting that there are, separately, desires for SPs to have more control over which deadline their sectors are assigned to, so they can cluster WindowPoSt time around an operationally-convenient time of day. It may be worth considering these needs at the same time, if we're to add new miner methods that afford additional control in this way.
At present the deal is activated at the ProveCommit message. As I understand it, you're proposing this be done by the sealer, and before the sector is moved to the eventual owner and scheduled for WindowPoSt (when it will also gain power). This could be a problem for market assurances, since the built-in market implicitly assumes that a sector will be subject to WindowPoSt from the moment it is activated. This proposal at the moment would allow a deal to be satisfied despite the sector being dropped immediately and never "on-boarded". I believe there are other lower-level protocol ideas that could permit transfer of sectors between pre-commit and prove-commit (by reducing the intermediate data needs), which would solve this problem, at least. |
Beta Was this translation helpful? Give feedback.
-
|
The "other protocol ideas" are the no-buffer PoRep type (#603). Non-interactive PoRep could remove PreCommit entirely (but I haven't thought through how this could play nicely with sealing as a service). But the easy solution to my problem of markets is to move the deal activation to |
Beta Was this translation helpful? Give feedback.
-
|
Great idea! Not sure if useful, but I had previously written a proposal that works only for CC-sector (assuming that then deals can be snapped into it) The basic idea is to:
In that world a sealer can seal, precommit, provecommit and then has all the time to transfer that sector elsewhere. |
Beta Was this translation helpful? Give feedback.
-
|
Related: https://www.notion.so/Inactive-CC-for-a-CC-market-1b4dc0f7ec194cfca41e20962d3e6235
|
Beta Was this translation helpful? Give feedback.
-
Would it be possible to move the activation of a deal to the time of the first successful windowPoSt? |
Beta Was this translation helpful? Give feedback.
-
|
Right now I think it's storage client who defines the start epoch of a deal. The protocol would need to be updated to check if the "the first successful windowPoSt" is either before or after the start epoch to maintain current deal flow logic. |
Beta Was this translation helpful? Give feedback.
-
|
@irenegia It would be very complicated. We wouldn't want to be doing any of the market notification stuff suggested in #298 during Window PoSt. I think we do have the not-yet-posted sector list in state so it could potentially be queried for. But all up, it would make things really complex. I think there are much simpler changes we could make by moving the deal start to whatever message commits a sector to a deadline and subsequent Window PoSt. E.g. a proposed |
Beta Was this translation helpful? Give feedback.
-
|
Non-interactive PoRep (#603) would be a real winner here. This would remove the chain interaction for pre-commit, and the deposit risk. There'll still be a maximum duration between the chain randomness sample and when the sector must be proven, but missing it wouldn't involve any on-chain costs or risk a pre-commit deposit. |
Beta Was this translation helpful? Give feedback.
-
Author: Venus Team
Simple Summary
Decoupling proveCommit and deadline assignment of a sealed sector.
Abstract
Given the limitations on current state of network infrastructure across the globe, in order to achieve any meaningful Sealing-as-a-Service in scale, we need to leave enough time to move sealed sector from a SaaS provider to SPs through either online transferring or offline transport. In this discussion, we propose new sector proving methods that separate sector proveCommit and on-chain sector power activation to allow longer buffer time for data movement between SaaS provider and SPs.
Motivation
Sealing-as-a-Service has grown from an idea summarized in a Google doc to one of the priorities among Filecoin data-onboarding roadmap. There are many potential merits of SaaS which includes lowering entry to Filecoin network, further separation of roles, and the possibility of creating new line of business.
As both Lotus and Venus team are working on SaaS APIs designs and make adjustments to support SaaS, there is one thing left in the puzzle to be solved before SaaS business can be done in scale - the time window is too short for a on-chain proved sector to be moved from one place to another. For any active sector, the SP has to do WindowedPoSt within 24 hours or less, or it will be declared as faulty. It is evident that 24 hour is not practical for sectors to be moved from a SaaS provider to an SP.
In the current protocol design, we have already separated proveCommit from the first WindowedPoSt during storage power onboarding. This proposal tries to make it more explicit.
Design Rationale
The problem is that every proveCommitted sector is put into a partition of a particular deadline, which will be checked periodically if WindowedPoSt is done in a particular timeframe. All sectors will be scanned every 24 hours.
There are two design we see that could realize the goal of this proposal.
Design 1
Taking advantage of the 30-day maximum waiting period between the preCommit and proveCommit, a SaaS provider could withhold proveCommit message and only send the message until the data is transferred to its client (SP) successfully. But there are some drawbacks of this mechanism:
Design 2
Second design is to separate the proveCommit and deadline assignment of a sector into different methods, so that the SaaS provider could generate proofs of a sector and put it on chain without assigning a deadline to it. Once the sectors are transferred to the SP, the SP can then invoke another method to add the sector into a deadline.
This design allows the SaaS provider to submit ProveCommit first, and the client can then verify data using onchain information before assign proveCommitted sectors into deadlines. We think that this might be preferred design as it is less destructive to current protocol implementation and have great backwards compatibility.
Implementastion
To be discussed
In the initial thinking, there are three new methods to be added (following design 2):
Discussion
This should be no problem for CC sectors to arbitrary buffer between the PoRep and first PoSt, however, for a sector having deals, as in the current mechanism, the sector should be onboarded before the earliest StartEpoch of all the deals in the sector, otherwise, it fails.
The question is that whether we should support the StartEpoch change in an unactivated deal? It will definitely help SaaS if this change is allowed. This requirement is for further discussion and is out of scope of this proposal.
Consideration
The implementation of this proposal will be simply add two more methods to the miner actor (?), therefore no impact to the current system. In other words, it is fully back-compatible.
Comments and suggestions are welcomed!
Beta Was this translation helpful? Give feedback.
All reactions