-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
As a part of this, we need to make sure F3 is robust against missing state. |
How about we put an optional initial power table into the manifest? If it is set, use it; otherwise, use chain. |
Hm. I don't want to include the entire power table, but we could include just the hash of it. |
(because we rebroadcast this manifest) |
Replaced by #485. |
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:
The text was updated successfully, but these errors were encountered: