Proving Period Adjustments on Faults

[whyrusleeping]

The current state of ‘late penalties’ for PoSts is that you have to pay an increasing fee up until the ‘ultimate deadline’ (which is currently one proving period).

Under the current logic, if a miner submits a PoSt late, say at deadline+ half a proving period, then they now only have half a proving period to complete their next PoSt and submit it on time. This is problematic.

One approach is to reset the proving period to the block that the miner submits their post into. This is weird drift that is likely to affect the security model of PoSt.

Another option is to allow PoSts of different lengths, and in the case where you have a late submission, your next PoSt will be shorter. This is difficult from a practical perspective, different lengths of PoSts will require different zkSNARK circuits entirely.

cc @nicola @porcuquine (also can someone tag Luca? I don’t know his github handle)

[dignifiedquire]

@lucaniz

[porcuquine]

If we don't batch the constituents of PoSt, but instead just have one SNARK per polling period, then the problem with different lengths goes away. I mention this because it is a direction we should explore as a worst-case fallback. We need to define the proof-size requirements so we can think about this avenue.

[whyrusleeping]

@nicola says:

When a miner runs into a fault, what happens? do they run a new proof on a new CommA? do they report the sector and skip it? Check if this reduces security.

[pooja]

We reviewed and discussed current construction and decided to leave this as is for now.

[nicola]

The proving period has a fixed schedule and submitting late won't alter it.