Beneficiary address for miners

[steven004]

This is to propose a beneficiary address to take finance control of a miner from owner.
See the discussions from #253

[jennijuju]

(haven't done a full pass yet - will 👁️ more later this week.

[anorth]

Thanks. I like this proposal, my comments are relatively minor. The only high importance one is confirming the beneficiary address to prevent the accidental loss of rewards.

I'll be pleased to approve this after that's addressed.

[anorth]

Great! I think this is good to land as draft status.

[hunjixin]

filecoin-project/specs-actors#1571

[anorth]

@kaitlin-beegle and FIP editors, can we please review and merge this PR?

@arajasek and @magik6k this proposal would really benefit from your review too (doesn't have to block this PR, you can make comments in #253)

[anorth]

I realised something else we should have here: a GetBeneficiary method to read the beneficiary address, quota, and expiration from the miner. I'm thinking forward to FVM smart contracts here: a contract beneficiary will need to be able to on-chain confirm that it is indeed the beneficiary and for how long.

[steven004]

I think I have a question here is whether a contract needs to call an actor's method to get its status, or states can be gotten via system calls? e.g. we have a state structure standard (like JSON format as an example, or simply read a IPLD path), any actor's state can be read via a syscall if it follows the standard.

[anorth]

No, actors cannot read each other's state. They must call methods (so an actor's internal state is abstracted). It's not very explicit in Go because we control all the actors, but will be enforced in the FVM.

[anorth]

We should add GetProposedBeneficiary too so that a contract or UI can read the proposal in order to submit matching configuration to confirm it.