Verify snapshot evidence on join/recover#1925
Merged
Merged
Conversation
added 15 commits
November 18, 2020 14:09
jumaffre
commented
Nov 25, 2020
|
verify_snapshot_evidence@16422 aka 20201208.29 vs master ewma over 50 builds from 15593 to 16397 |
…to verify_snapshot_evidence
added 2 commits
November 27, 2020 16:43
added 2 commits
November 27, 2020 16:54
achamayou
reviewed
Nov 30, 2020
achamayou
reviewed
Nov 30, 2020
achamayou
approved these changes
Nov 30, 2020
…to verify_snapshot_evidence
…to verify_snapshot_evidence
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #1539
When joining/recovering from a snapshot, we used to automatically accept the snapshot, even if the snapshot evidence wasn't present in the ledger. We now verify that the snapshot evidence is present in the ledger and that there is proof that this evidence was committed, i.e. that there's a signature that proves that the commit seqno was greater than the evidence seqno.
On recovery, this is pretty much the same scheme as before but we make sure the snapshot evidence is in the ledger when recovering the public part. On join, we now apply the snapshot in public mode when on start-up and deserialise the ledger suffix (in public mode) until we've found the proof of the snapshot evidence.
Operation-wise, this now means that node joining from a snapshot should have access to the ledger suffix containing the snapshot evidence (+ signature proving that the evidence was committed). I'll update the documentation accordingly in a follow-up PR.
The Python infra requires some changes when joining/recovering from a snapshot. In particular, we now wait for the latest available snapshot to have ledger proof of the commit of its evidence (see inline comment).