FIPxxxx: add PT Lookback to Power Actor

Creator

Irene

Created

Feb 23, 2024 10:57 AM

Simple Summary

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

Abstract

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):

• Power Actor today has PowerTable which is read by consensus with PTLookback (equal to finality = 900 epoch) delay;
• Remove the delay from reading and make the Power Actor track and manage the delay.

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.

Motivation

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:

• Be more flexible and agnostic wrt the consensus protocol employed in Filecoin;
• Ensure there is a long enough time to react to major security issue which can possibly happen to the network. Note that we are not in presence of any security issue today, but it is something the networks needs to be protected against.

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.

Specification

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:

• PTClockTick = number of epochs in a “tick” (set 60, number of epochs in 30 minutes)
• PTQueueLength = number of power tables (ie, elements in the queue) stored by the Power Actor;
• PTLookBack = PTClockTick * PTQueueLength, represents the number of epochs expressing the delay of the power user for leader election (i.e. at each epoch e, leader election protocol selects SPs proportionally to their quality adjusted power at epoch e-PTLookback);
• Set PTQueueLength to 10080 to get a PTLookBack of 1 week.

Rationale [WIP]

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:

• Keep power table lookback equal to finality but activate a sector after 7 WindowPost proofs.

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

Backwards Compatibility

\\TODO

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

Test Cases

\\TODO

Security Considerations

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.

Incentive Considerations

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.

Product Considerations

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.

Implementations

\\TODO

Copyright Waiver

Copyright and related rights waived via CC0.