Compute circulating supply in cron

[Stebalien]

Filecoin uses the current estimated circulating supply to compute certain penalties and pledges. Unfortunately, this value is computed by the client every epoch which means:

1. Clients need to compute the circulating in the exact same way or the network will fork.
2. The FVM needs to expose this information via a special syscall (network::total_fil_circ_supply).

Proposal:

1. Compute this information at the end of cron in the power actor. It's not particularly expensive to compute. I.e., right here: https://github.com/filecoin-project/builtin-actors/blob/86d7c892295f6f05c133ad6910f2d1ce60f116ca/actors/power/src/lib.rs#L231-L240
2. Store the information in the power actor and return it from the CurrentTotalPower method. We're already returning pledge collateral here, so this won't matter too much.

This will actually reduce gas fees in most cases as it'll save a syscall. Any method that calls this sycall already calls CurrentTotalPower on the power actor.

[Stebalien]

Alternative: we could, alternatively, store this information in the reward actor. But given that we're already handling pledge in the power actor, I feel that there's little point.

[Stebalien]

It looks like this can be computed purely in terms of:

1. The burnt funds actor's balance.
2. The market + power locked totals.
3. Some hard coded vesting schedules plus the epoch.

If/when we remove market pledge from this calculation (insignificant anyways), we should be able to compute this from information already available. I.e., CurrentTotalPower, the burnt balance, and some constants. So we likely don't even need to add anything to cron.

[aarshkshah1992]

@jennijuju @Stebalien Can I pick this one up.....please ?

[aarshkshah1992]

Is this a priority for the FVM team ?

[jennijuju]

@aarshkshah1992 - re priority: I think it is reasonable for you to look into how much optimization this could give us.

[Stebalien]

Well, this isn't an optimization. It's a priority for the FVM team because it removes a filecoin-specific wart from the FVM, bringing us one step closer to being a general-purpose VM. That's it.

[maciejwitowski]

@aarshkshah1992 did you pick it up in the end? (asking, since I'm still tracking it as "FVM item" and maybe I shouldn't anymore)

[aarshkshah1992]

Hey @maciejwitowski I still haven't picked it up. Apologies for not updating the issue.

[arajasek]

So I'm pretty sure we've considered this before (maybe just in my head?). My biggest opposition to this idea is the introduction of the details of the vesting schedule to the actors (or even the FVM) code. That is very, very specific to Filecoin mainnet, and rips up the idea that these codebases should be "generic system actors".

Having said that, I'd love to get this out of clients :P

[anorth]

If we put the vesting schedule in state, the actor code will remain generic and configurable to other geneses.

[Stebalien]

Hm. We could put it in state but then we'd probably need to record it in, e.g., the power actor's state (I think?).

[Stebalien]

Really, we have three ways to go:

1. Hard-code the vesting schedule in code.
2. Record the vesting schedule in some actor's state.
3. Record the multisigs that affect the vesting schedule in some actor's state.

I'm happy with any one of these (although I prefer option 2). But, in the second two cases, I would perform the circulating supply calculation in cron (instead of on-demand as described in #777 (comment)).