Caller-specified proving deadline for NI-PoRep

[anorth]

NI-porep is adding a new onboarding method. This is an opportunity to give SPs control over what window post deadline their sectors are scheduled for. We failed previously to enable support for moving between deadlines after onboarding, but specifying the deadline during onboarding will be much easier.

Let's add a parameter for that now? FIP-0090 is already accepted, so we need another one to modify it. But in either case if we want to do it, we want to ship the code for it once when NI-porep is first enabled. It will be a pain to add later.

I propose adding a single ProvingDeadline parameter to ProveCommitSectorsNIParams:

• the same deadline for all sectors onboarded in a single invocation
• must be specified; no fallback to on-chain calculation to automatically smoothly allocate across 24 hrs (deprecate existing behaviour)
• the deadline cannot be the current or next to be proven (same restriction on terminating sector).

[anorth]

Draft FIP: #1008

[rvagg]

Regarding the security model:

The existing automatic scheduling was motivated by a caution about overloading the network at particular times of day with too many Window PoSTs due at the same time. However, since the introduction of the FVM and a robust gas model, the network itself is not at much risk from this anymore.

Is there not a possible attack from a large adversary or coalition of adversaries (perhaps a group of disgruntled SPs) to focus scheduling on a specific deadline and "overload" the network? Gas might be an incentive for the rational actor to avoid particularly costly deadlines, but what about the adversarial actor with access to a large number of sectors? What would "overload" look like, if it's at all possible?

[anorth]

Overload would look like the gas bandwidth available within the deadline being insufficient to process all of the window posts due at that deadline. Before this threshold was actually crossed, the gas price would likely rise dramatically. The result would be that SPs with proof due at this deadline would fail to meet their Window PoST, lose power, and (the second consecutive time) pay fault fees. So it's a bit of an own-goal.

It might be somewhat self-limiting in that once a partition has faulted, it's not due for another window post until an explicit recovery (which can take place outside the deadline window).

[anorth]

Pulling out a comment from review of #1008.

Do we still want to support automatic deadline placement in case SP doesn't care?

The discussion OP says

no fallback to on-chain calculation to automatically smoothly allocate across 24 hrs (deprecate existing behaviour)

I don't think we should support automatic assignment. The motivation is to remove complexity from the built-in actors. We can delete the code for it when other onboarding methods are deprecated. This complexity can live off-chain instead. SPs with more than a partition of sectors should be sophisticated enough that they do care about when their Window PoST system is expected to be online.