Skip to content
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

implement the migration for FIP0081 #313

Closed
jennijuju opened this issue Sep 19, 2024 · 4 comments
Closed

implement the migration for FIP0081 #313

jennijuju opened this issue Sep 19, 2024 · 4 comments
Assignees

Comments

@jennijuju
Copy link
Member

filecoin-project/builtin-actors#1557

@BigLep
Copy link
Member

BigLep commented Sep 24, 2024

@rvagg : @rjan90, @ZenGround0 , and I chatted during 2024-09-24 triage. There are two parts to this issue: 1) writing the migration and 2) testing the migration in Lotus. Per https://github.com/orgs/filecoin-project/projects/125/views/1, the migration code (not the Lotus testing) needs to complete by 2024-10-01 ("Actor/FVM Code Freeze"). Can you please take this up when you return?

Separately, @ZenGround0 is going to add notes about how to do the testing and there is also related pledge API updates: filecoin-project/lotus#12494

@BigLep BigLep moved this from 📌 Triage to 🐱 Todo in FilOz Sep 24, 2024
@ZenGround0
Copy link
Contributor

Testing on devnets presents some challenges since the mainnet parameter for ramping up the change is 1 year.

Basic test that pledge has changed

We can still probably detect these slight differences in the pledge calculation with these parameters. The approach is to compute both the old and new pledge functions and check that pledge after the migration matches the new function.

Ramp test

In order to efficiently test that the ramping up eventually completes we would need non-mainnet parameters in the power actor state. Today builtin actors does not define the ramp start and ramp duration parameters it only consults the power actor state. The migration code gets to define these parameters. We could change the migration interface to pass these parameters in. Then lotus could keep track of these params, for example as a build constant the same way block time is tracked.

I'm not sure if we need the ramp test given the existing coverage in builtin actors. But it might be better to have the ramp constants defined in lotus then only in the go-state-types migration code.

@ZenGround0
Copy link
Contributor

Note that we won't expect to see ANY change between the calculations for 1052 epochs (1/1000 * 1 year of epochs) given that fip 0081 is implemented with per mille precision.

@rjan90
Copy link
Contributor

rjan90 commented Sep 27, 2024

The PR implementing the migration for FIP-0081 is here: #314

@rjan90 rjan90 moved this from 🐱 Todo to ⌨️ In Progress in FilOz Sep 27, 2024
@rjan90 rjan90 moved this from 🥞 Todo to 🏃 In Progress in nv24 Track Board Sep 27, 2024
rvagg added a commit that referenced this issue Sep 30, 2024
@rvagg rvagg closed this as completed in 33a664c Oct 3, 2024
@github-project-automation github-project-automation bot moved this from ⌨️ In Progress to 🎉 Done in FilOz Oct 3, 2024
@github-project-automation github-project-automation bot moved this from 🏃 In Progress to ✅ Done in nv24 Track Board Oct 3, 2024
@rjan90 rjan90 moved this from 🎉 Done to ☑️ Done (Archive) in FilOz Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ☑️ Done (Archive)
Status: ✅ Done
Development

No branches or pull requests

5 participants