Reduce miner state size by removing expected_storage_pledge from sectorOnChainInfo

[jennijuju]

(discovered in a random convo by @arajasek @ZenGround0 )
Simple summary: It's possible to reduce miner state size by removing expected_storage_pledge from sectorOnChainInfo, and calculate the value of it via expected_day_reward * 20 * Epoch_In_Days.

In each miner actor, sectors info are stored as a AMT[SectorNumber]SectorOnChainInfo . In SectorOnChainInfo, the following info is stored:

 /// Expected one day projection of reward for sector computed at activation time
     pub expected_day_reward: TokenAmount,
  /// Expected twenty day projection of reward for sector computed at activation time
     pub expected_storage_pledge: TokenAmount,

From the description, it seems like expected_storage_pledge = expected_day_reward * 20 * Epoch_In_Days.

in built-in actor:

   new_sector_info.expected_day_reward = expected_reward_for_power(
                        &rew.this_epoch_reward_smoothed,
                        &pow.quality_adj_power_smoothed,
                        &qa_pow,
                        fil_actors_runtime::network::EPOCHS_IN_DAY,
                    );
  new_sector_info.expected_storage_pledge = expected_reward_for_power(
                        &rew.this_epoch_reward_smoothed,
                        &pow.quality_adj_power_smoothed,
                        &qa_pow,
                        INITIAL_PLEDGE_PROJECTION_PERIOD,
                    );

where INITIAL_PLEDGE_FACTOR = 20

pub const INITIAL_PLEDGE_PROJECTION_PERIOD: i64 =
    (INITIAL_PLEDGE_FACTOR as ChainEpoch) * EPOCHS_IN_DAY;

.

two values share the same calculation algo expected_reward_for_power and the only difference is projection_duration with a 20x difference. So seems like potentially we can remove the expected_storage_pledge from state and just use expected_day_reward to calculate it.

@ZenGround0 may help confirm the hypothesis, and suggest the potential state savings.

[arajasek]

@jennijuju Thank you for starting this! I also want to mention that the value in question (expected_storage_pledge) is only used when assessing termination penalties. Thus, removing it will only affect this calculation (we hope negligibly), without having any bearing on more frequently calculated values such as Window PoSt fault fees, PCD, IP, etc.

I think a good next step would be to quickly examine the impact of this proposal. I would consider iterating over all sectors in state, and calculate their termination penalty today, and compare it against their termination penalty if we replace expected_storage_pledge with expected_day_reward * 20. If we find that the delta is large, this will need more discussion (though might still be feasible). If the delta is small, then I think this is fairly promising!

[anorth]

I haven't gone deep on this, but projecting over 20 days is not identical to projecting over 1 day and multiplying. The projection is a non-linear function.

[ZenGround0]

Definitely true but the bound on the difference and hence impact might be small enough to justify removing this from state

[steven004]

I would agree it is doable to simplify the calculation like this:
expected_storage_pledge = expected_day_reward * 20 * Epoch_In_Days.

[AxCortesCubero]

Currently these block rewards projections are done using the position and velocity estimates from the alpha-beta filters, for the total new rewards $x_r, v_r$, respectively, and for total network QAP, $x_q, v_q$. The block reward estimate for a period $\Delta t$ is calculated with the following formula

$$BR(\Delta t)=v_r\Delta t-\frac{(v_r x_q-v_q x_r)}{v_q}\left[\log\left(v_q \Delta t+x_q\right)-\log(x_q)\right].$$

From this it can be quantified what would be lost by replacing $BR(20d)$ with $20*BR(1d)$, in day as the time unit:

$$20*BR(1)-BR(20)$$

$$=\frac{(v_r x_q-v_q x_r)}{v_q}\left[\log\left(v_q 20+x_q\right)-20\log\left(v_q +x_q\right)+19\log(x_q)\right]$$

Whether this difference is large or small, will depend on the current trends, positions and velocities, as well as what our tolerance is for what we consider small.

Another note is that given these formulas, we would need to keep four separate numbers (positions and velocities, or four different time projections), to reproduce from that all the possible time projections we would like. Keeping only one number, however, is not enough information to calculate all other projections from it.

[AxCortesCubero]

This actually simplifies a bit further, rearranging a bit,
$$BR(\Delta t)=v_r\Delta t-\frac{(v_r x_q-v_q x_r)}{v_q}\left[\log\left(1+\frac{v_q}{x_q} \Delta t\right)\right].$$

Now if we expand this for small $\frac{v_q}{x_q} \Delta t$, we have
$$BR(\Delta t)\approx \frac{v_q x_r}{x_q}\Delta t.$$
In this limit, it is perectly valid to say that
$$X*BR(\Delta t)=BR(X*\Delta t),$$
as proposed here.

The justification is then having small $\frac{v_q}{x_q} \Delta t$, and your proposal is valid, up to order $(\frac{v_q}{x_q} \Delta t)^2$ corrections.

[anorth]

I don't think we should resolve the issue as written. Instead, we should reconfigure the termination fee calculation to not require any historical inputs and remove them all from sector state at once.

[anorth]

Ref #795 and #691 (comment)

[steven004]

To follow the Design Goal mentioned in #691 (Comment), we may consider remove all these fields below in the SectorOnChainInfo, and have these calculated at the miner level.

/// Remove all of these
    pub initial_pledge: TokenAmount,
    /// Expected one day projection of reward for sector computed at activation / update / extension time
    pub expected_day_reward: TokenAmount,
    /// Expected twenty day projection of reward for sector computed at activation / update / extension time
    pub expected_storage_pledge: TokenAmount,
    /// Maximum day reward this sector has had in previous iterations (zero for brand new sectors)
    pub replaced_day_reward: TokenAmount,

While we have the information at miner level, it not only save a lot of space, but we will implement no protocol bias between sectors. That also means the miner pledge collaterals for all its sectors, and the penalty for fault will only based on the a general rule, possibly based on the conditions when faults happen.

There might be a concern of security like that the previous pledges may not be enough to safeguard the sectors based on the new pledge requirement per sector if it is increasing to some degree. However, it may not be a big issue if the highest penalty is much lower than the total initial_pledge.