-
Notifications
You must be signed in to change notification settings - Fork 23
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
Specify Lightweight Checkpointing #447
Comments
So far, the envisioned scheme would be activated by the presence of an arbitrary list of points, with the semantics that the given hash is the only valid header/block in given slot. For context: we anticipate that some kind of real-world event would trigger some stakeholders to cooperate off-chain in order to determine and publicize a "blessed" set of such points as useful and compatible with the majority of caught-up (honest) stake. |
Very rough sketch: For a given point SLOT HASH, an incoming block in a slot >=SLOT is invalid unless its hash equals HASH or a predecessor of it does. Edit: likely simpler to implement if the list is BLOCKNO HASH pairs (no existing term for this) instead of SLOT HASH pairs (aka points). |
We think a block- and/or protocol-combinator (a la |
Closed by #898, see the approach described there |
A subsequent ticket should compare and contrast this with Mithril.
This Issue is to specify the motivations and requirements for a lightweight checkpointing scheme. By lightweight, we mean that it does not replace any of the work today's node would normally do while syncing the chain and it requires only minimal changes to the node.
The text was updated successfully, but these errors were encountered: