Benchmark nv23 migration

[jennijuju]

• Update go-state-types
• Migration Integration
• rerunning the migration using lotus-shed with the latest RC
• Ensuring correctness (run state invariants check) and that it's fast enough
• Running the migration in "online" mode -- this means letting the premigration happen while the lotus daemon is syncing the chain, making sure the time and memory usage are okay
• Param finalization: based on time and memory usage of the experiments, we need to settle on the correct number of and epochs for premigration

[BigLep]

@jennijuju : below are some questions for a newbie. I'm fine to get a verbal brain dump if that is quicker for you (and I can then expand the text). Here are the questions I have:

Update go-state-types

Does that mean updating lotus to use the latest go-state-types release (as part of updating lotus dependencies)

Migration Integration

Is there an example PR of this in the past to refer to?

rerunning the migration using lotus-shed with the latest RC

Do we have docs on this (e.g., sample commands that have been run in the past)? It's fine if not, but I would want to capture this. My thinking is we need to capture what we do manually today so we can have multiple people do it and potentially automate.

Ensuring correctness (run state invariants check)

What are the commands to run?

and that it's fast enough

Do we have more guidance on what "fast enough" means?

Running the migration in "online" mode

What network do we do this on, and what hardware?

making sure the time and memory usage are okay

Does this mean that there should be no degradation when the migration is happening?

Param finalization

Where does this get proposed/discussed? (Is there an example post from the past?)
Where does this get announced? (Is there an example post from the past?)

---

General questions:

1. When in the network rollout should this happen? Is it the Butterfly phase, the Calibration phase?

[jennijuju]

Migration Integration

the basic one is a part of the go state type upgrade skeleton & different FIP may have different needs. we have done this for nv23

rerunning the migration using lotus-shed

not docs it a cli: lotus-shed migrate-state --repo=<> <network version>

What are the commands to run?

./lotus-shed migrate-state --check-invariants (probably needs to update invariants first

Do we have more guidance on what "fast enough" means?

for this upgrade i expect it to be less than 5 sec if its not .. 1sec lolol. for more complicated migration we would like to be within 10-20sec range for the final migration, cuz anything beyond that is v close to block time -> miner may lose block or network wise we have null blocks

What network do we do this on, and what hardware?

mainnet - cuz it has the most states. yah whatever machine folks are using to sync the chain is sufficient for this. (some maybe slower some maybe faster, but its a part of the benchmark gathering imho)

Does this mean that there should be no degradation when the migration is happening?

for this one, yes.

When in the network rollout should this happen? Is it the Butterfly phase, the Calibration phase?

can do one as soon as we have the most code needed; def should do one before final calib release to catch any state invariant mismatch that may point out bugs