New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fip0081 gradual activation #967
base: master
Are you sure you want to change the base?
Fip0081 gradual activation #967
Conversation
FIPS/fip-0081.md
Outdated
SectorInitialConsensusPledge = PledgeLockTarget * (0.3 * SectorSimpleShare + 0.7 * SectorBaselineShare) | ||
activation_len_days = int(365) | ||
current_day = 0 | ||
update_day = (datetime(2024,6,1) - datetime.today()).days |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by 2024.060..1 do you mean upgrade day of when this FIP is running on Filecoin mainnet? if so, can we just put datetime(FIP_activation_date) there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep - that was what was intended here, let me update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is now updated per your recommendation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing something obvious but introducing a state machine here seems like unnecessary complexity and state, e.g.
- Do we really need a pre-activation state given it's... erm... pre-activation?
- Why not compute a gamma directly from activation, length, and date, thereby avoiding not just the state but the numerical considerations you mention? Something like
$\gamma=0.7+\min(\max(0.3*\frac{(FIP \textunderscore activation \textunderscore date+activation \textunderscore len \textunderscore days) -datettime.today().days}{activation \textunderscore len \textunderscore days},0),0.3)$
Also, the while loop is underspecified as it could run with any frequency, but that's a bit pedantic esp. given your note on needing to choose a period. Regardless of the granularity, this should likely all be defined in epochs (i.e. activation epoch, activation_len_epochs, ...) to not be sensitive to clocks.
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. |
FIPS/fip-0081.md
Outdated
@@ -79,10 +79,28 @@ a reasonable lower bound on network collateral. | |||
|
|||
## Specification | |||
Factor the per-sector initial consensus pledge into two parts: a 70% share which divides by the baseline function like today, | |||
and a smaller 30% "simple" share which does not divide by the baseline function. | |||
and a smaller 30% "simple" share which does not divide by the baseline function. Gradually activate the change from the current | |||
to the target. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small ask, but can we also describe the activation period? It's helpful to have the qualitative description as well as the pseudocode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, added, but if unclear or could use further revision lmk and I can update!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. This is helpful in communicating the high level intention of a phase-in to humans. However the pseudocode as written can't function as a specification for implementers due to assuming a context for computation that doesn't match the chain's (which the PR description acknowledges). As such, I don't think we should merge this.
If we do want to merge something as a stepping stone to a full specification, I'd suggest avoiding pseudocode and just writing prose, with a TODO to actually specify how to implement that intent.
I've updated the description and removed the pseudocode. Is it clearer now? |
@@ -236,9 +281,5 @@ so the supply of storage is more than adequate to demand. | |||
|
|||
To be provided. | |||
|
|||
## TODO | |||
|
|||
- Implementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still TODO. The description of intent is clear enough, but this currently lacks specification of how to achieve it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 👍 |
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 tobreak
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: