-
Notifications
You must be signed in to change notification settings - Fork 46
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
Accountable Safety Protocol #10
Comments
For now let's focus on the "answering queries" portion. There are roughly two kinds of queries to answer (more details in paper).
This is easy to answer as long as we keep all votes for that round.
For this, we will want a way to mark which votes we had seen at the time when we prevoted and which we had seen at the time when we precommitted. To answer this query, we would simply query the DB and get the relevant set, and return it to it. This implies that for each round r, a reasonable schema would be to store something like a struct HistoricalVotes {
seen: Vec<Message>, // in order received
prevote_idx: Option<usize>, // the length of `seen` at the time we prevoted, if we have.
precommit_idx: Option<usize>, // the length of `seen` at the time we precommitted, if we have.
} |
This is not necessary. The answer to a challenge should be a set S of votes of the same type (all pre-votes or all pre-commits) and of the same round (for some round previous to the one referenced in the challenge) and with the property that "it is impossible for S to have a supermajority for B". But this property is preserved when we add new votes to S (see Lemma 2.2 (ii) in the Grandpa paper). So, if you saw such a set of votes at any point in the past, and you added some votes to that set since then, then the resulting set still has this property. Hence we just need to store all votes seen, for the last K rounds, for some large enough parameter K. |
Responding implies that we are able to return sets of votes such that we have some observable property. That probably means storing messages on disk in the order that we received them, and marking the points at which we voted. We will have to mark on the current and prior rounds, because one kind of query requires justification of the prior round's estimate at the point of voting.
The text was updated successfully, but these errors were encountered: