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

Dynamic Manifest: Ship a trusted instance 0 #484

Closed
Stebalien opened this issue Jul 18, 2024 · 5 comments
Closed

Dynamic Manifest: Ship a trusted instance 0 #484

Stebalien opened this issue Jul 18, 2024 · 5 comments

Comments

@Stebalien
Copy link
Member

Problem: We need to know where F3 "starts" in order to validate the chain. If we have the Filecoin state-tree at the F3 genesis epoch, this is trivial (we can just use that power table to validate the first finality certificate). Unfortunately, if we're restoring from a snapshot, we won't have that state.

Ideally the snapshot would contain the F3 chain. But that requires altering the snapshot format. Even better, clients should ship with a baked-in initial power table, but that's not possible until F3 genesis has happened.

For now (for testing), we should handle this using the dynamic manifest server. Basically, in addition to the dynamic manifest, we need to also broadcast the first finality certificate (once it has been produced). That way new nodes can join without having the relevant historical state:

  1. Node tries to start, fails to load the appropriate power table.
  2. Node receives a message from the dynamic manifest server containing the first instance.
  3. Node uses the finality exchange protocol to fetch the initial power table, validating that it matches the power table of the base tipset in the 0th finality certificate
  4. Finally, the node can start F3, catching up with the finality exchange protocol.
@Stebalien
Copy link
Member Author

As a part of this, we need to make sure F3 is robust against missing state.

@Kubuxu
Copy link
Contributor

Kubuxu commented Jul 18, 2024

How about we put an optional initial power table into the manifest? If it is set, use it; otherwise, use chain.
We can then broadcast sequence number 1 manifest for normal bootstrap, and then after that, sequence number 2 could include the power table.

@Stebalien
Copy link
Member Author

Hm. I don't want to include the entire power table, but we could include just the hash of it.

@Stebalien
Copy link
Member Author

(because we rebroadcast this manifest)

@Stebalien
Copy link
Member Author

Replaced by #485.

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

No branches or pull requests

2 participants