-
Notifications
You must be signed in to change notification settings - Fork 170
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
think about upgrading proofs #132
Comments
@porcuquine Can you help provide some thoughts here? Thanks! |
My initial thoughts: We should continue to support already-sealed sectors for as long as necessary (until they expire). That would mean having a versioned PoSt and would imply that we need to be able to know what version of Seal was used. I think we can keep this simple by only ever supporting one version of Seal. That would mean we know what kind of PoSt a sector needs based on when it was sealed (that will never change). If a miner doesn't like having to run two PoSts, they can reseal. This doesn't require any extra support. I don't think I'm introducing anything new, just answering @whyrusleeping's questions and expressing a preference for a particular strategy. |
We should document how resealing a live deal would work. The trickiest bits are:
(can probably make a new issue to discuss that) |
We should consider how PoSts will work if we have to upgrade how (for example) Seals work. Will miners have to re-seal all their data? Will we have to run two PoSts in parallel for a while? will we do a 'soft upgrade' that just doesnt allow adding new seals of the old kind?
The action item for this issue isnt necessarily to solve all the problems, but we need to brainstorm potential situations and plan for them.
The text was updated successfully, but these errors were encountered: