Beneficiary address for miners

FIPS/fip-0028.md

@@ -0,0 +1,141 @@
+fip: "to be assigned"
+title: Beneficiary address for storage providers
+author: Steven Li(@steven004)
+discussions-to: https://github.com/filecoin-project/FIPs/issues/213
+status: draft
+type: Technical
+category: Core
+created: 2021-12-09
+spec-sections: v6.0.x
+---
+
+
+<!--You can leave these HTML comments in your merged FIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new FIPs. Note that a FIP number will be assigned by an editor. When opening a pull request to submit your FIP, please use an abbreviated title in the filename, `fip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.-->
+
+To provide more flexibilities for Filecoin finance market, a new role *beneficiary* is proposed for a storage provider, which takes over the financial control from the owner.
+
+## Abstract
+<!--A short (~200 word) description of the technical issue being addressed.-->
+
+There are several keypairs associated with a given storage provider address for different operational purpose, including a worker and zero or more controllers block producing, making deals, onboarding sectors and proving storage. There is also the owner keyapir that is used for a SP administration and fund withdraws, to be more specific, currently **only the owner address can withdraw the funds from the miner actor.
+
+The beneficiary role is to take financial control from owner, i.e. only financiary role could withdraw filecoin from a storage provider node, and the owner keep other controls.
+
+## Change Motivation
+<!--The motivation is critical for FIPs that want to change the Filecoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.-->
+
+Filecoin's pledge collateral mechanism creates opportunities for a lending market. We already see some projects launched to solve the problem, e.g. Coinlist is running lending business to Filecoin storage providers while asking excess pledge paid in other digital currency. However, the filecoin node itself has great value including pledge collateral and locked rewards, which, ideally, can be used as collateral for filecoin lending. Some Filecoin service providers are doing this by providing collateral for their customers whole holding owner addresses.
+
+The problem is the owner of a Filecoin node has full control of the node, including changing worker and controllers, withdraw balance or terminate sectors. This proposal is to separate the node control and financial benefit into different roles, that's how the beneficiary comes in.
+
+
+## Specification
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Filecoin implementations. -->
+
+There are a few parts to be implemented to achieve the beneficiary separation and related security matters, including: 1) miner-state change to accommodate benefiary and its state; 2) methods added to miner-actor to support beneficiary change; 3) Date and/or quota experition support for beneficiary.
+
+The following channges apply to specs-actors module:
+
+#### 
+- Add **Beneficiary** address into **MinerInfo** structure
+- Add **BeneficiaryInfo** structure into **MinerInfo** structure to include `{beneficialQuota (attoFIL), beneficialExpiration(Height), usedQuota(attoFIL)}`. 
+- The **Beneficiary** is set to the same address of **Owner** when initiating a miner without specifying a beneficiary address (for back-compatibility)
+- The **Beneficiary** address could be a signable address, or multisig address, or actor address (for smart contract)
+- The **WithdrawBalance** method of a miner can be called by the miner's **Beneficiary** or **Owner**, but the balance always being sent to the beneficiary. The total balance withdrawed to a beneficiary address could not exceed the quota if it is set.
+
+- Add **ChangeBeneficiary** method to miner actor to propose or confirm a change of beneficiary address and/or beneficiaryInfo. When changing beneficiaryInfo, the exprireDate needs to be the future, and the quota should be larger than the usedQuota. The beneficiaryChange is following a proposal/confirmation manner. There are different scenarios under which the proposal and confirmation steps are different, as below:
+    1) The current beneficiary address is the owner, the ChangeBeneficiary just can be sent by the Owner
+        - ChangeBeneficiary command needs to propose a new beneficiary address, at the same time, the beneficiaryInfo can be set at the same time
+        - The new beneficiary should send the same command to confirm, and then it can take effect. In addition, the usedQuota is set to 0 since it's new.
+    2) The beneficiary (not the owner) is expired or the quota is used up, the ChangeBeneficiary command can only be sent by the owner
+        - When the new beneficiary is back to owner, the BeneficiaryInfo is set to default, and the change takes effect immediately
+        - When the beneficiary address keeps the same, only beneficiaryInfo is set. In this case, the usedQuota keeps no change, and the new Quota should be larger than or equal to the usedQuota
+        - When there is a new beneficiary (not the owner itself), after the owner sent the ChangeBeneficiary command to change the beneficiary and beneficiaryInfo, the new beneficiary should send the same command to confirm, and then it can take effect. In addition, the usedQuota is set to 0 since it's new.
+    3) The beneficiary (not the owner) is not expired and quota is not used up, the ChangeBeneficiary command is also firstly sent by the owner, and next confirmed by the beneficiary(ies) to take effect.
+        - When the beneficiary address does not change, i.e. only change beneficiaryInfo, thus, only need the beneficiary to send the same command to confirm (like what we do for owner change)
+        - When there is a new beneficiary address is proposed. It requires the current beneficiary to send the same command to confirm, and followed the new beneficiary confirmation command the the same parameters. In this case, the usedQuota is set to 0, and the newly set quota is counted from 0.  
+- Add a **ProposedBeneficiaryInfo** structure into **MinerInfo** structure to record the `ChangeBeneficiary` information and progress, including parameters and who has approved it.
+
+
+Some related API changes are required for all the Filecoin implementations, e.g. miner information query, beneficiary status query (expiration data, quota, current status etc.) 
+
+Related command lines are better to provided in Filecoin implementations. This part can be designed by the implementation maintanancers.
+
+
+## Design Rationale
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+Mainly there are two scenarios for the beneficiary address being separated from owner address based on the current design.
+
+1. Enable lending market using the node rewards as collateral. This is actually done by some Filecoin network service providers, but, currently, it only works when the lender is the service provider. When we have the beneficiary address, the lender could be anybody else who value the node itself.
+2. For storage provider internal use, there are lots of advantages when having a separated beneficiary address, which can be controlled by the finance department, while owner be controller by the maintenance/engineering team.
+
+But, there are more use cases can be developed when this is in place. E.g.
+
+- Block Reward pooling design: Rewarding sharing is a very good thing for small/medium storage providers since it can provide much more certainty of income. Almost in all mining pool design, the small/medium miners need to hand over the beneficiary address to the pool provider. In Filecoin, Owner address need to be transferred if there is no another beneficiary address, which is too risky, since owner has fully control of the node. A separated beneficiary address makes it much safer.
+- Reward pooling can be integrated with Smart Contract when it is available, in this case, the beneficiary address could be transferred to an trustless actor. We can not transfer the owner to a smart contract address, since it is hard to change it back. But we can do it with beneficiary address with a good design.
+
+In addition, if we have the security feature, it will protest the storage provider from the beneficiary owner mistake (loss or expose of private key), or any other risks, e.g. bankruptcy, to some degree.
+
+**ChangeBeneficiary** design
+- Security is one of the main considerations when desigining the `ChangeBeneficiary` process, especially when beneficiary can be transferred to the lending part. The basic idea is that every change of beneficiary information is based on the agreement among related parties, so the design includes proposal and confirmation process, and every part need to be involved to make it happen.
+- `beneficialQuota` and `usedQuota` is used to track the financial setting and status for a beneficiary. An altenative of this design is to use only one parameter - `remainingQuota` to record the status. Considering that people want to control total `beneficialQuota` in most cases, especially in lending market. The 2 parameters' design is more user-friendly.
+
+
+## Backwards Compatibility
+<!--All FIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The FIP must explain how the author proposes to deal with these incompatibilities. FIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
+
+This FIP changes actors behavior so it requires a new filecoin network version.
+
+From functionalities point of view, since the owner is also the beneficiary by default, it is fully backwards compatible.
+
+## Test Cases
+<!--Test cases for an implementation are mandatory for FIPs that are affecting consensus changes. Other FIPs can choose to include links to test cases if applicable.-->
+
+This proposal has no consensus changes, there should be no impact for chain sync and block generation logic.
+* The default beneficiary is the owner
+* The expiration and quota criteria set and work well
+* Beneficiary change logic works fine
+* Beneficiary support signable, multisig and actor address (this might be test later when FVM is in place)
+
+
+## Security Considerations
+
+This FIP does not touch consensus, block generation.
+
+There is a concern that the beneficiary address might be controlled by people who are not so familiar with Filecoin, which may lead to some mistake of private key loss. Basically this can not be really handled well if using a signable address as a beneficiary, but the multisigs support could mitigate this as we did for owner. In addition, the expiration date and quota setting is for kind of pretectioins.
+
+
+## Incentive Considerations
+<!--All FIPs must contain a section that discusses the incentive implications/considerations relative to the proposed change. Include information that might be important for incentive discussion. A discussion on how the proposed change will incentivize reliable and useful storage is required. FIP submissions missing the "Incentive Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Incentive Considerations discussion deemed sufficient by the reviewers.-->
+
+The primary motivation of this proposal is to provide more flexibility for storage providers from financial point of view by separating beneficiary from owner. There is almost no impact to incentivation if the beneficiary is controlled by the owner or sharing address with the owner. The question is whether it mitigate the incentivation for the network if the beneficiary is transferred to antoher party for collareral or any other reasons.
+
+* From the whole network point of view, this proposal creates a possibility to pledge the future rewards as collateral for storage providers to get FIL for power growth, which lowers the capital barrier for (small/medium) storage providers to join ths market. Thus, it could accelerate network power growth, and improve decentralization. It's a great thing for the network reliability and security.
+* For a particular storage provider, when she transfers the beneficiary to a lender to get token as pledge collateral, her investment into her node is less since the lender paid some. The penalty on her will be less too if she stop to maintain the node, though the overall penalty keeps no change. This would be a mitigation of storage maintenance incentives. This should be acceptable due the following two reasons:
+    - The lending market is already there without this proposal fulfilment. Some of them transferring owner instead, which is more risky. This proposal mitigates the risks comparing transferring owner.
+    - The lender will consider this since she will pay the penalty if the borrower does not maintain the node well. It is a reasonable assumption that the leader will minimize the risk of her token loss in their agreements neogotiation.
+* The possible beneficiary key loss, or the beneficiary is transferred to an unintended one, which makes the owner loss control. In this case, the expiration mechanism design could mitigate this risk to some degree, at the same time, this is not worser than lossing owner's key or transferring owner's address to an unintended one. 
+
+## Product Considerations
+<!--All FIPs must contain a section that discusses the product implications/considerations relative to the proposed change. Include information that might be important for product discussion. A discussion on how the proposed change will enable better storage-related goods and services to be developed on Filecoin. FIP submissions missing the "Product Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Product Considerations discussion deemed sufficient by the reviewers.-->
+
+The implementation of separating beneficiary from owner will bring the ecosystem more flexibilities, including the lending market and the finance management. The lending market could be centralized, e.g. by institutional capitals, or decentralized by smart contracts. When the FVM is available and the user defined actors is possible, there could be differnt finance agreements for user to choose. The most important thing is, all filecoin hodlers could join to get interest by staking. 
+
+
+## Implementation
+Specs-actors PR: https://github.com/filecoin-project/specs-actors/pull/1571
+
+The overall flow chart of the ChangeBeneficiary proposal process: 
+![The proposal process of ChangeBeneficiary by the owner](https://user-images.githubusercontent.com/10411723/151310919-daaba17d-0d05-4f11-a141-34f50a98584c.png)
+
+The overall flow chart of the ChangeBeneficiary approval process: 
+![The approval process by the beneficiary(ies)](https://user-images.githubusercontent.com/10411723/151311059-4721eb2e-5bc9-40ee-9977-8cf941dea954.png)
+
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+