FIPxxxx: add PT Lookback to Power Actor

This proposal aims to change the value of the Power Table (PT) lookback, making it independent from consensus finality.

Today consensus power is granted at least finality blocks after a sector is onboarded onchain via one of the methods implementing ProveCommit.

https://excalidraw.com/#room=bab31e12e8d36a7d50a2,4oBBk_8g5Yl81VYayu9HSA

More in details: a sector is activated right after the first WindowPoSt but power is not granted right at that moment. Indeed, at each epoch e, leader election protocol selects SPs proportionally to their quality adjusted power at epoch e-PTLookback; and currently the value of PTLookback is set to finality. This means that the minimum delay in power activation is indeed finality blocks after the sector is onboarded (note that this happens if WindowPost happens right after the ProveCommit message. Any time window elapsed from ProveCommit to the first WindowPost defers sector power acquisition accordingly).

We propose to decouple the Power Table (PT) lookback from consensus, setting the value of PTLookback to EpochsInOneWeek (i.e., independent from finality). Note that to get to this, in theory we could simply change function GetWinningPoStSectorSetLookback by setting the output value to EpochsInOneWeek. However this change would entail a too high memory overhead (see Design Rationale section for more detail). Instead, we propose the following more efficient solution (i.e., explicitly adding the PT lookback to Power Actor):

Finally, note that having a PT lookback larger than today does not diminish the time sector’s power is accounted for leader election, given that power of each sector will be counted for PT lookback epochs after sector termination. In essence, there will be a one week shift for power accounting.

The aforementioned delay in power activation (PTLookback) is needed (and needs to be larger than finality) to avoid the following attack: a malicious SP creates sybils with different VRF keys to increase the chances of election and then forks the chain to assign power to those keys.

While having PT lookback equal to finality is enough for security and allows for minimising the delay between sector onboarding and power activation, decoupling it from consensus (while keeping it greater than finality) is important for the following reasons:

Indeed, while on one hand reducing finality is one of the goals of consensus improvements (in terms of chain “efficiency”), having a long enough power table lookback is crucial in order to fix potential major security issue which could arise all in a sudden (for instance, due to a bug found in the future in one of the network components), via a network upgrade.

Today, having the power table lookback set to finality implies that this buffer of time is of 900 epochs, which can be too short in order to address a major event via network upgrade.

Even if currently there is no major security risk which needs a network upgrade to be fixed, we want to be in the best possible position to address such a potential issue in the future, if needed.

We add a new data structure to the Power Actor to store the information of power over a range of time (from “now” to PTLockback). Since storing the Power Table (PT) for each epoch is too expensive, we consider “clock tick” (ie, groups of epochs) and for each tick the actor stores the PT at the beginning of that tick. In other words, the Power Actor gains a queue and does the following: every “tick” (eg, every 30 epochs) it pushes the current PT onto the queue, pulls out the delayed PT from the queue and sets it as the one used for current leader election PT. We introduce the following parameters for the Power Actor:

Current finality is 900 epochs (7.5h given current Filecoin blocktime of 30 seconds) and will be reduced once Granite is shipped. We consider 7.5h (or lower) to be not sufficient in order to ensure a network upgrade can be successfully shipped in case of a major security issue, preserving network security. We are convinced 7 days is the optimal interval length in order to be able to safely ship a network upgrade while not harming SPs operations with respect to the status quo.

Before proposing this FIP, we considered the following alternative approach:

We preferred a longer lookback to this approach in order to maximise SPs profit. Indeed a simple back-of-the-envelope calculation, shows that the longer PT lookback is the option where SP profit is higher. Say a sector has a duration of days, $BR$ is the reward for a day and $CS$ the cost of storing for a day. In the case of a longer lookback (assuming the SP keeps storing the sector for extra 7 days after sector terminates) the profit is $d\cdot BR - (d+7)\cdot CS$ . In the case when power is given after 7 windowPoSts, the profit is $(d-7)\cdot BR - d\cdot CS$. And since $BR\geq CS$, then the first profit is always larger than the second one.

TODO: add different approaches for the power actor

\\TODO

The change consists in a parameter update and will not present any compatibility issue.

\\TODO

This change will allow to significantly augment network security in case of a major security issue.

Keeping the PT lookback equal to chain finality (while eventually finality is reduced by independent FIPs, see for example FIP0086) would make a real time fix in case of a security issue infeasible.

Sector's power will be deferred by one week changing the speed at which power enters the network. Nevertheless, this power is "shifted” only, meaning that sector's power will be retained for the seven days after sector expirations (assuming the sector is stored for extra 7 days after termination). Note that this is needed not for being selected as a leader, but to answer potential WinningPoSt challenges and being elected leader. Nevertheless, after termination sectors won't need to be proven (via WindowPoSt) for the 7 days after termination.

We are expanding the power activation delay which we already have (from 7.5h to 7 days). We are also extending the storage needs after termination (same window of time). For example, for a sector with 1.5 year duration, storing 7 extra days means adding a storage cost of less the 1.3%. We believe that this small extra costs is bearable in order to get a strong security guarantee for the entire network.

\\TODO

Copyright and related rights waived via CC0.