Alex NorthCould we implement the ability to upgrade a non-verified deal to verified after it’s already been sealed into a sector?
Background
In the present system, a prospective deal client first obtains a data cap allocation from FIL+ notaries. Then, when proposing a deal to a provider they can set the verified flag to true. When that deal is posted to the storage market actor, the client’s data cap is consumed. When the deal is subsequently sealed into a sector, the miner actor asks the market actor to compute the weight (space ⨉ time) of the deals. This deal weight translates into sector quality (depending on the life of the sector), which boosts power and hence reward.
Future direction
Unrelated to this proposal, we are aiming to decouple the miner, market and FIL+ registry actors to boost flexibility and support the development of third-party markets and storage-related contracts. The direction for this is to remove the market actor from mediating FIL+ data cap, so that we don’t need to trust it. Miners will verify data cap with the FIL+ registry directly.
See Architecture for programmable storage markets
Design ideas
A deal’s verified status is record in two place:
- the on-chain deal metadata in the market actor
- this is never actually used after the deal is activated
- the sector’s weight, power, pledge, penalty parameters (indirectly)
Updating the market
Updating the deal metadata in the market actor is straightforward. Following the current scheme, the market could deduct the data cap from the FIL+ registry (but note that this flow much change in the future). We need a call or signed message from the client granting the use of data cap.
Updating the sector
Blessing a deal as FIL+ after the fact has some similarity to adding updating a sector with new deals. The quality, power etc can only increase, so the QA power calculations are tractable.
If we take the deal to be verified only from the epoch that the upgrade is requested/approved (rather than backdated to the deal’s start epoch), then the verified space-time will fit within the sector’s remaining space-time, and quality will be at most 10.
Recompute sector weight and quality as:
SectorTotalTerm = Sector.Expiration - Sector.Activation
SectorRemainingTerm = SectorExpiration - CurrentEpoch
// Compute deal weight to carry over from existing deals.
// This is similar to extending sector lifespan.
UnspentDealWeight = SectorDealWeight * SectorRemainingTerm / SectorTotalTerm
// Compute weight of the upgrade deal as if it started now.
UpgradedDealWeight = DealSize * (DealEndEpoch - CurrentEpoch)
NewSectorWeight = UnspentDealWeight + UpgradedDealWeightFrom this new sector weight, a new (higher) value for power, initial pledge, and penalty values may be made as if the sector was starting afresh at the current epoch.
Implementation
We need three new calls: one for the client to approve data cap, one for the miner to claim it, and one for the miner worker to trigger this flow.
In the market actor
- Add a new method
VerifyDeal(dealID), called by the deal client - Read the deal’s size, check it’s not expired etc
- Deduct the data cap from the verified registry
- Record the deal’s verified status as
unclaimedin a new flag in deal state - Set the
verifiedflag to true in the deal metadata (or maybe defer this until its claimed) - Add a new method
ClaimVerifiedDeal(dealID)called by the miner actor - Check that the deal’s verified status is
unclaimed - If so remove that status, and return the deal’s weight (size * duration) from now until expiration
- Otherwise fail
In the miner actor
- Add a new method
UpgradeDeal(dealID), called by the miner worker - Call the
ClaimVerifiedDeal()on the market actor, fail if it returns false - Recalculate sector weight, adding the verified deal weight returned by the market actor
- Recalculate pledge, power etc and update the right places
Future implementation
After planned programability changes, markets and FIL+ will be decoupled. Claiming FIL+ verification will be independent of the market actor.
The draft architecture proposal already includes two of the three required new methods but they are on the FIL+ registry actor rather than the market actor. ApproveDataCap is analogous to VerifyDeal above, and CommitDataCap analogous to ClaimVerifiedDeal. If we implement them on the market actor now, that will add a bit to the drag on the new architecture.
The third new method is for the miner to claim verified status after the fact. This new method would be similar, except that it would be in terms of PieceCID rather than Deal ID, and confirm the data cap with the verified registry actor rather than the miner. This new method is hard, because we can’t prove that a piece is sealed into a particular CommR without doing a SnapDeals-like SNARK.