Set pre-commit deposit to uniform value of maximum sector storage pledge (FIP-0034)

[anorth]

A pre-commit deposit (PCD) is an amount staked by a provider between the pre-commit and prove-commit stages of sector onboarding. It secures PoRep by making attempts to cheat very expensive, and so irrational on expectation. The PCD value is currently set approximately equal to the sector's initial pledge. Re-use of the initial pledge calculation was originally for conceptual simplicity, but also serves to ensure the provider always has sufficient pledge at PoRep, because they have just unlocked a slightly greater amount from PCD. The PCD value is set approximately equal to the sector storage pledge (approximately because the true initial pledge value depends on the activation epoch, which is not yet known). When the sector is committed, the provider must then stake the sector initial pledge (a greater amount).

A sector's initial pledge is made up of "storage pledge" and "consensus pledge". Roughly:

• storage pledge := 20-day projection of expected reward to be earned by the sector
• consensus pledge := pro-rata share of 30% of circulating money supply

As of January 2022, for a 32GiB sector these calculations give (also roughly):

EpochReward := 22.54 * 5 = 112.25
NetworkPower := 16.0954 * 10^9
CirculatingSupply: 229 * 10^6

// Sector quality = 0
StoragePledge := 0.0128
ConsensusPledge := 0.1365
PreCommitDeposit := StoragePledge = 0.0128
InitialPledge := StoragePledge + ConsensusPledge = 0.1494

// Sector quality = 10 (note values are appox 10x greater)
StoragePledge := 0.1285
ConsensusPledge := 1.3658
PreCommitDeposit := StoragePledge = 0.1285
InitialPledge := StoragePledge + ConsensusPledge = 1.4944

Using storage pledge as PCD causes a notable design/efficiency problem:

• the storage pledge calculation requires information about the verified deals in a sector, which requires loading deal metadata from the market actor (complex, expensive)

The storage pledge value makes up just 8.6% of the initial pledge that will be required to commit the sector today. In general, we expect this proportion to continue to fall, as (a) storage pledge decreases as the expected reward to a fixed-size sector in a growing network falls, and (b) consensus pledge rises as the circulating supply expands.

Proposal
Calculate pre-commit deposit as the 20-day projection of expected reward earned by a sector with a sector quality of 10 (i.e. full of verified deals), regardless of sector content. Continue to require the full initial pledge when the sector is proven.

This proposal sets a uniform pre-commit deposit regardless of sector content. The PCD is set for the "worst case" of a sector that is fully occupied by verified deals. This is more than the current pre-commit deposit requirement for CC sectors, but still less than the initial pledge that will be required on PoRep. Removing consideration of sector content from the calculation will remove the need to load deal information from the market actor for pre-commit, only to load it again at PoRep. This in turn simplifies the interactions necessary between the miner, market and FIL+ verified registry actors when onboarding sectors, which makes it easier to refactor these interactions to allow alternative storage markets to be implemented on the FVM (see #241). In particular, deal information is only required at PoRep time, to compute QA-power.

Discussion
Following from the numbers above, this would set PCD equal to 0.1285 (the storage pledge for quality=10) for all sectors. This is approximately 10x larger for CC sectors, but no change for fully-verified sectors.

For CC sectors, this deposit would be significantly more than that strictly required by PoRep security, but I think the uniformity and simplicity enabled by ignoring deals is worthwhile. A slightly more complex scheme could allow the provider to, say, commit to some maximum sector quality at pre-commit (without specifying the actual deals involved), and thus put a smaller deposit at risk.

Since PCD is a time-limited deposit, the sum of PCD across the system makes up a very small part of the money supply. Increasing it will have only a negligible effect on the circulating supply.

This proposal is a pre-requisite for a larger actor architectural change I intend to propose shortly.

@nicola @zixuanzh @arajasek

[Edited 2022-02-08 to resolve incorrect statement about the current calculation]

[zixuanzh]

On the network level, PCD is a transitory lock-up (tokens get unlocked into initial pledge soon after at ProveCommit) and only accounts for a very small percentage of the circulating supply.

Currently, PCD is set to be just initial storage pledge (20BR), not the full initial pledge. By using 20BR assuming the sector is fully occupied by Filecoin Plus deals makes SPs more indifferent between CC and FIL+, hence encouraging more SPs to take on FIL+ deals. It also further reduces token velocity on a macro level (despite not by much). It may increase the cashflow burden for SPs by requiring a bigger reserve for PCD. However, it does not make a difference if the SPs are taking FIL+ deals anyways and the amount locked in PCD will soon be released for initial pledge (which is still higher than PCD after the proposed change).

Note that this proposal will also subtly increase the network bandwidth/TPS further (unclear by the amount) since the PreCommit operation becomes cheaper.

[anorth]

Thanks, I had an incorrect statement about the current calculation in the OP. I've edited to fix that now.

[anorth]

I have drafted a FIP here: #307

One possible variation, not explored in the draft, would be to allow a provider to specify a lower PCD value for a sector (e.g. 2x theCC value rather than 10x), in return for being prevented from proving the sector with power greater than the PCD they staked. In the case of pure CC sectors, this means they could nominate to keep the old PCD, but then must have 1x verified deal weight when proving. We might even be able to do so without storing additional state. @nicola @irenegia I would like to discuss this with you to understand if it introduces an incentive to cheat.

In fact, for the special case of a sector with no deals, we could detect this at pre-commit (because no deal IDs are provided) and automatically lower the requirement, without consulting the market actor. But note that in my proposed new architecture for programmable markets #298, the miner wouldn't get deal ID (or FIL+ data cap allocation IDs) until PoRep anyway.

[irenegia]

I have drafted a FIP here: #307

One possible variation, not explored in the draft, would be to allow a provider to specify a lower PCD value for a sector (e.g. 2x theCC value rather than 10x), in return for being prevented from proving the sector with power greater than the PCD they staked. In the case of pure CC sectors, this means they could nominate to keep the old PCD, but then must have 1x verified deal weight when proving. We might even be able to do so without storing additional state. @nicola @irenegia I would like to discuss this with you to understand if it introduces an incentive to cheat.

In fact, for the special case of a sector with no deals, we could detect this at pre-commit (because no deal IDs are provided) and automatically lower the requirement, without consulting the market actor. But note that in my proposed new architecture for programmable markets #298, the miner wouldn't get deal ID (or FIL+ data cap allocation IDs) until PoRep anyway.

I think we can not do this because of the possibility of upgrading a CC sector to a one with deals later on (thanks to SnapDeal).
A rational miner will always do pre-commit with a PCD of a pure CC sector, and then, after prove-commit passed, calls SnapDeal.
In this way we have a sector with deals that had a PCD at pre-commit time that is too low for our security requirements.

[irenegia]

About FIP #307 (as described in the first message), it is fine no security issues with it, but I would like to propose an edited version.


The analysis we did before launch says that PCD should be greater than
10 x ER(max sector lifetime) / (2^10-1)

(where ER is the expected reward for the sector and takes the sector quality as input).

In the current code, we assume that max lifetime is 5 years and since 5years/(2^10 -1) ~ 2 days, and we use the approximated formula PCD = ER(20 days). 
Since we are going to touch the PCD calculation anyway, I am proposing that with this FIP we update PCD to be the original (more precise) formula.
Now, about making PCD independent from the sector quality. 
The 10x in the formula above was put there as safety margin, and it is good the we did that! Indeed now the 10x covers the case that the PCD was done for a CC sector then is now upgraded to a sect with verified deals (eg, via snap deal).

So, in principle the FIP could propose to have
PCD = 10 x ER(max sector lifetime) / (2^10-1) assuming always a sector of quality 1 for any sector
But if we do this, we don’t have any safety margin for future changes. 
So I reccomend keeping the margin and having
PCD = 10 x ER(max sector lifetime) / (2^10-1) for a sector of max quality for any sector.

[Kubuxu]

An alternative to taking the maximum possible sector quality is to allow Storage Providers to declare the sector quality they will use during the ProveCommit stage. This would take the form of accepting an additional parameter to PreCommit MaximumQaulity which would determine the PCD required. During ProveCommit the quality of the sector will be calculated and compared with MaximumQuality declared during PreCommit.
If the MaximumQuality is higher or equal to the actual quality the sector passes ProveCommit, if the MaximumQuality is lower than actual quality then the sector fails ProveCommit.

The safe strategy is to set the MaximumQuality to 1 if the sector doesn't contain FIL+ deals and 10 if the sector contains FIL+ deals but SP can calculate the actual quality of the sector during PreCommit and use it instead.

The MaximumQuality data is discarded past the ProveCommit.

[Kubuxu]

This is not planned as increased PCD is a minimal cost to SPs, while this solution increases complexity and introduces another failure point.

[Kubuxu]

Discarding MaximumQuality doesn't work due to ReplicaUpdate.
So we could still do it but would need to keep the MaximumQuality around.

[Kubuxu]

One adjustment that has to be made is CommD needs to be "revealed" during PreCommit. Today, this is enforced by verifying deals during PreCommit, which forces reveal their CommPs and sizes which reveals CommD.

With this proposal, DealIDs won't be checked up until ProveCommit, which means someone could report DealIDs that are currently not allocated and then allocate them after randomness is revealed, thus allowing for grinding on ReplicaID.

I propose that in addition to DealIDs, CommD of the sector is included in the PreCommit message. This change necessitates adding two methods (PreCommit and PreCommitBatch) with updated parameters. The old methods should be deprecated and disabled at a later date.

During ProveCommit, CommD should be recalculated from PieceInfos, and compared to the one committed to during PreCommit.

In theory, DealIDs could be moved to the ProveCommit message, but that would require changes to params of ProveCommit and ProveCommitAggregate.

[anorth]

Ack, sounds good. Some complications to work through:

• do this without a migration that back-calculates CommD for pre-commits already made (should be fine, I think, since they already committed to CommD via deals)
• do this in a way backwards compatible so the old way keeps working for a while after the upgrade (I think this'll be ok too - the old method needs to keep calculating CommD from deals)

[anorth]

Code is WIP at filecoin-project/specs-actors#1575 (thanks @Kubuxu 🏆 )

[anorth]

I have updated the FIP draft after feedback from the Lotus team.

• Restored the ergonomic deal validity checks during pre-commit, to prevent loss of PCD
• Use this validation check call to also compute CommD, and store that in SectorPreCommitOnChainInfo
• Saves gas by removing a redundant third loading of the deal metadata to compute the CommD during ProveCommit

[anorth]

FYI @arajasek @ZenGround0

This makes a migration of PreCommits necessary (we'll code it), but that's only a small piece of state.

[jennijuju]

This FIP (FIP-0034) is moved to Last Call on July 13th and will remain in Last Call through end-of-day on Wednesday, July 27. Core devs and the community should review the FIP and raise any concerns before then.

[jennijuju]

Things that might impact last call here

cc @AxCortesCubero @kaitlin-beegle

[steven004]

Do we really need to stick on the idea to set PCD equal to the sector storage pledge (supposing the highest QAP a sector could have)?
The PCD is to secure the process and make attempts to cheat very expensive. If we believe our PoRep algorithm is good enough and the possibility to make a fake proof is negligible, the attack to the network is more related to network resources consuming by precommit messages, which is not related to QAP much. If this is true, a uniform value of PCD is reasonable, and we might be able to keep the same even the SectorDurationMultiplier is implemented later.

[Kubuxu]

@steven004 the possibility is not cryptographically negligible, which is the reason why PCD exists.

[anorth]

My assumption is that the SectorDurationMultiplier can change in future based on the following in the FIP (but it is quite an imprecise description):

This same policy will apply at Sector Upgrade and Extension.

Right. And since the PCD already accounts for a maximum sector life of 5 years, that probably remains. @vkalghatgi the PCD must be set according to the maximum duration the sector could have. Your proposal doesn't specify prohibiting extension if an initial commitment was less than 5 years. If a provider could immediately extend to 5 years (and gain the multiplier) then that's the value we need to take.

[nicola]

Hey team, we should treat this as an independent FIP.

• This change is correct and needed for the current version of Filecoin.
• The team working on Introducing a Sector Duration Multiple for Longer Term Sector Commitment #390 will have to add this consideration in their FIP (and there is no alternative strategy known currently that avoid this change)

In other words, we need this change whether #390 is in or not.

[kaitlin-beegle]

Thanks, @nicola! That seems correct to me as well.

Want to confirm, then, that this FIP will continue with Last Call (which is scheduled to end on Wednesday this week) uninterrupted.

[f8-ptrk]

this will slow down on boarding as FIL will be unavailable to a greater extend. just saying. there seem to be people wondering why on boarding went down when the gas usage was raised in the last upgrade - this FIP will do the same.

[anorth]

when the precom expires - will this recheck with the market to only burn what was burned before

No, we must burn the full deposit in order for this to function as an effective check in attempts to cheat PoRep. Otherwise malicious SP would only pay the smaller penalty for sectors that fail, and immediately ReplicaUpdate to gain 10x when they occasionally succeed. We need them to risk the full penalty every time.

lock x1 by default and then calculate the final pledge at commit time

The final pledge is calculated at commit time, but the PCD protects against attacks on pre-commit, and must be a function of the maximum total earnings possible for the sector.

[f8-ptrk]

makes kind of sense.

#386 might have severe implications as we have to lock up x50 precoms then, right?

[anorth]

Yes, #386 as I understand it right now will lock up a very large precommit for sectors that an honest SP intends to be only CC. They'll have to factor in expected failure rates. I have asked the proposers of #386 to model this.

[f8-ptrk]

from an ops perspective this might be an ugly one:

• if it gets too risky to keep precoms' around for a long time on a raid0 one might switch to a raid1
• if i switch to a raid1 i half my nvme space
• if i half my nvme space i cannot batch precom's anymore to the extend i did before
• if i do not batch as before the base fee might go up
• ....

:(

[f8-ptrk]

even in the x10 case we increase the financial risk of sealing sectors and it most likely will lower on boarding rates