Skip to content

Latest commit

 

History

History
94 lines (62 loc) · 10.6 KB

fip-0021.md

File metadata and controls

94 lines (62 loc) · 10.6 KB
fip title author discussions-to Status type category created review-period-end spec-sections
0021
Correct quality calculation on expiration
@Stebalien, @ZX, @Zenground0
Final
Technical
Core
2021-09-20
2021-10-11

FIP-0021: Correct quality calculation on expiration

Simple Summary

Sector quality is defined as a spacetime average of the quality of the deals stored in the sector. The current protocol implementation does not work as expected when sectors are extended because deal spacetime is overcounted. This leads to minor incentive issues. This FIP fixes the discrepancy.

Abstract

DealWeight and VerifiedDealWeight in a sector's past is no longer included in the quality calculation for the extended sector. Instead the past spacetime of the sectors is "spent" and only the remaining deal spacetime of the sector's original life is counted.

To avoid extending the market actor interface for a small change this FIP proposes getting an approximate value for the remaining spacetime of deals and verified deals. A good approximation is to multiply deal weight by the fraction of sector lifetime remaining.

Change Motivation

@Stebalien proposed this solution after noticing that the following scenario is possible today:

  1. A storage provider accepts a 6 month deal and stores it in a sector for 6 months with a 10x multiplier
  2. The day before the sector expires the storage provider extends the lifetime for 6 months (the minimum extension). The power will now be 5x.
  3. Again, the day before the sector expires again, the storage provider extends the lifetime for 6 months at 3.33x power.

This is problematic because it goes against the design intention of rewarding verified deal weight proportional to the active deals in a sector. This bug encourages complex behavior in order to game the sector quality system. Sector expiration should not have gameable incentives and verified deal weight should not have more relative power than designed compared with cc sectors.

Specification

During sector extension a storage provider specifies the sector to be extended and the new expiration. The sector info on chain contains the activation and current expiration epoch. It is trivial to compute the remaining fraction of the sector's lifetime with arithmetic: remainingFrac = (currentExpiration - currentEpoch) / (currentExpiration - activation). Multiply this number by the DealWeight and VerifiedDealWeight fields of the sector info before rewriting to the Sectors array. In practice this should be done as a big Int multiplication of the deal weights with the numerator and then a division by the denominator as the last step. All miner actor sector quality calculations first read the sector info so this is a sufficient change to propagate correct sector power information.

Design Rationale

An alternate approach that would more accurately tie together sector quality and value provided through active verified deals in a sector is to ask the market actor for an updated weight calculation during sector extension. This would require some changes to the market actor since weight calculation and activation checks are currently coupled together in one method and by definition deals in active sectors may have passed their start time and will not in general be valid for activation.

While it is not an exact fix the chosen approach is simple requiring no state or method signature changes. The fix is not exact because it will assign deal weights greater than 0 to sectors with deals that have all finished. This type of reasoning about average deal spacetime across the sector's life is essential to the concept of deal weight and sector quality. The same tradeoffs are shared by the existing design and are therefore acceptable.

Backwards Compatibility

This changes specs-actors behavior so will need a network upgrade. No migration is needed -- the new rules will not be applied retroactively only on new expirations.

Test Cases

  • A test should cover the motivating example described in the motivation section. A sector with verified deal weight taking up entire space time for 6 months followed by an extension on the last day of lifetime twice in a row. With one day remaining during extension after the second extension this should be about 512 GiBepochs of verified deal weight and a sector quality of (10 * 512 GiB * epoch + 1 * 53000 GiBepoch / 53512 GiB * epoch) ~ 1.08.
  • Include both deals and verified deals. Check sector info for propagation of both DealWeight and VerifiedDealWeight changes
  • Start a sector with a low deal weight and extend very close to expiration so that deal weight becomes fractional mathematically. And implementation should set deal weight to 0.

Security Considerations

The current bug can be considered as a minor security issue because verified deal weight of extended sectors unfairly inflates storage provider power. There is no significant associated risk today however, allowing this issue to be publically disclosed through a FIP

Incentive Considerations

This FIP should remove the unfair benefits of extending sectors with verified deals. Removing unfair advantage from verified deal data will balance the relative power of verified and unverified/cc data as designed. In the context of the proposed snap deals construction this will strengthen the incentive for miners to store new cc sectors that can be made available for snap deals rather than extending sectors with deals that have completed and cannot add snap deals.

Because this solution does not extend the market actor and instead uses an approximation to recalculate deal weight there will still be a small extra incentive to extend verified deal sectors over adding new cc sectors. But it will be greatly reduced and should be negligible.

Product Considerations

Assuming the snap deals FIP is accepted Incentive pressure away from extending sectors with expired deals towards new cc sectors available for snap deals should only benefit the experience of data storage users.

Since this change is restoring a fair allocation of power to storage providers it should not degrade storage provider experience either. Sector extension should not be more expensive in terms of gas or state churn as the sector info is already modified at the Expiration field and written to state during sector extension.

Implementation

specs-actors PR TODO

Copyright

Copyright and related rights waived via CC0.