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

snapshot: augment Filecoin snapshots with F3 information #480

Open
Stebalien opened this issue Jul 16, 2024 · 9 comments
Open

snapshot: augment Filecoin snapshots with F3 information #480

Stebalien opened this issue Jul 16, 2024 · 9 comments
Labels

Comments

@Stebalien
Copy link
Member

Stebalien commented Jul 16, 2024

We need to store the following in our Filecoin snapshots once we pass the F3 bootstrap epoch.

  1. The current F3 manifest.
  2. The power table for the bootstrap epoch - 900.
  3. All finality certificates we currently have.
  4. Power table deltas for all epochs between the last finality certificate and the first epoch included in the snapshot (if any). This should only be required if F3 falls behind EC.
  • I've dropped the F3 manifest because this will be baked into clients (normally). This will cause a few issues when testing (nodes may start with the wrong manifest), but they'll quickly receive the correct manifest from the network and switch to it).
  • I've dropped the initial power table. Eventually, this will be shipped with clients (first release after F3 genesis) but, for now, it can be fetched over the network given the first finality certificate.
@jennijuju
Copy link
Member

Moved to milestone 2 as i dont think this is mandatory for nv23. This needs yo be tracked by chainsafe infra team as well.

@jennijuju
Copy link
Member

@Stebalien does lotus import-snapshot logic needs to get updated as well?

@aatifsyed
Copy link

Do you have a sketch for a new layout @Stebalien?
It sounds like an increment of the CarHeader version would be appropriate :)

@Stebalien
Copy link
Member Author

We don't need a new car format, just an additional root for the F3 data (which we can IPLDize and store the same way we do the rest of the chain).

This doesn't need to happen before nv23 but, if it doesn't, anyone restoring from a snapshot will be unable to join F3.

@Stebalien
Copy link
Member Author

It's also possible to partially solve this without touching the snapshot format by instead fetching the required information over the network. We still need to change the snapshot format for point (4), but that's less critical.

@Stebalien
Copy link
Member Author

(moving back into milestone 0 until we've actually figured out what to do here)

@Stebalien
Copy link
Member Author

Power table deltas for all epochs between the last finality certificate and the first epoch included in the snapshot (if any). This should only be required if F3 falls behind EC.

An alternative is to require that snapshots include all state up until the last F3 finalized epoch. Unfortunately, if there's an issue with F3 at any point, that could grow.... large.

Given that this is kind of an "emergency measure" kind of thing, we could also just distribute these power tables separately if/when necessary.

@Stebalien
Copy link
Member Author

Status:

  1. I've dropped items 1 & 2 as they aren't critical.
  2. Not having item 4 is... annoying, but not the end of the world while testing (we can just start F3).
  3. Not having item 3 is problematic unless we build a way to start F3 in the middle. But, given the difficulty in changing the snapshot format at the last minute... I think we're going to need to do just that.

@Stebalien
Copy link
Member Author

Actually, we can solve 3 with the dynamic manifest (for now): #484. I'm moving this issue to milestone 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Todo
Development

No branches or pull requests

3 participants