FIPs
FIPs copied to clipboard
Fip0081 gradual activation
This pull request updates FIP0081 to include a ramped activation.
Pseudocode is provided for how a ramped activation could be realized. The pseudocode is written from the perspective of how to set the Gamma value (gamma_day
) for each day of the network. This implies that there is a controller that is setting the Gamma value for each day and that controller would be active forever. It is possible to break
out of the loop after Gamma reaches the target value of 0.7.
This pseudocode omits several realities that need to be taken into account when implementing in the network, including:
- Absolute datetime or epoch numbers, due to the need for this to work in both testnet and mainnet
- What entity/object is computing and setting the Gamma value
- Whether Gamma changes every epoch or every day during the ramping period
I might be missing something obvious but introducing a state machine here seems like unnecessary complexity and state, e.g.
I don't disagree with anything you've stated, but this is just pseudocode. It likely has no correlation to how this would actually be implemented in Lotus, since things such as absolute dates are not available. I wrote it as a state machine because I thought it would be easy to understand.
I've updated the description and removed the pseudocode. Is it clearer now?
I tried to view the attached PDF, but could only see 9 blank pages. Can someone else check this? @kkarrancsu do you want to try sending me the file by another channel too?
Hmm, not sure what happened there but I pushed a new pdf that is hopefully uncorrupted. Will also share directly with you.
I tried to view the attached PDF, but could only see 9 blank pages. Can someone else check this? @kkarrancsu do you want to try sending me the file by another channel too?
Hmm, not sure what happened there but I pushed a new pdf that is hopefully uncorrupted. Will also share directly with you.
The new one works for me.
New PDF 👍
I've added a link to the draft implementation in the builtin-actors repository. Is it OK to move this FIP forward for consideration, while we continue to refine the draft implementation?
I've added a link to the draft implementation in the builtin-actors repository. Is it OK to move this FIP forward for consideration, while we continue to refine the draft implementation?
Hi @jennijuju - gentle ping on this post Eth-CC!
I've added a link to the draft implementation in the builtin-actors repository. Is it OK to move this FIP forward for consideration, while we continue to refine the draft implementation?
What do you mean by move this FIP forward?
My original objection here still stands. The FIP does not specify how to achieve its outcome. From the draft implementation, I know that it has now been worked out how this can be achieved, but it's not represented in this document. This needs to be specified in the FIP. Linking to the code doesn't suffice for this.
This document must specify:
- changes to state data structures
- changes to actor APIs
- briefly how those new state and APIs are used to get the right values to the right place to compute pledge amounts (prose is fine)
- migration
I can lift my objection and allow this to merge as a draft, but the FIP will still not be ready for last call, so I don't want to mislead by doing that.
@kkarrancsu - i agree with anorth, lmk if you want to do a pass tgt sometime this week!
@kkarrancsu - i agree with anorth, lmk if you want to do a pass tgt sometime this week!
Hi @jennijuju - I've updated the Specification section to include a description of the necessary changes. Can you review and also help me understand how to think about Migration?
Hi @anorth @jennijuju - I think that the remaining changes are completed, can you take a look to see if it's ready to move to the next step?