Vote accumulation and round-estimate logic#2
Conversation
gnunicorn
left a comment
gnunicorn
left a comment
There was a problem hiding this comment.
Minor comment requests. Ready to merge on your own after.
src/round.rs
Outdated
| if occupied.get().0 != vote { | ||
| return Err(Equivocation { | ||
| round_number: 0, | ||
| identity: id, |
There was a problem hiding this comment.
the clone self.votes.entry(id.clone()) { above is unnecessary if you did here: identity: occupied.key().clone(). Then we'd only clone in case of of an equivocation.
src/round.rs
Outdated
|
|
||
| /// Stores data for a round. | ||
| pub struct Round<Id: Hash + Eq, H: Hash + Eq, Signature> { | ||
| graph: VoteGraph<H, VoteCount>, |
There was a problem hiding this comment.
pub struct fields should probably have some docs, no?
There was a problem hiding this comment.
can't hurt, but the fields aren't pub so my convention is not to add doc comments. in this case I will add a few because the code isn't easy to understand without
src/round.rs
Outdated
| } | ||
| } | ||
|
|
||
| /// Import a prevote. Has no effect on internal state if an equivocation. |
There was a problem hiding this comment.
- "or if signature is not by any current voters".
AlistairStewart
left a comment
AlistairStewart
left a comment
There was a problem hiding this comment.
We need to be dealing with equivocations correctly. If some Byzantine guy v votes for both B_1 and B_2, then maybe some honest guy saw only one vote or the other before they vote/finalise blocks. Then the way to deal with this correctly is to count v's vote weight towards B_1, B_2 and all their ancestors. Which means we need logic to add vote weight to B_2's ancestors but only those that don't already get it from the B_1 vote.
src/round.rs
Outdated
| } | ||
| } | ||
|
|
||
| /// Import a prevote. Has no effect on internal state if an equivocation. |
There was a problem hiding this comment.
This also means that we need to a +self.faulty_weight in the expression for remaining_commit_votes since if we saw v vote for B_2, that doesn't rule out there being a vote for B_1 which could be used to finalise a block.
|
@AlistairStewart We will address that in a follow-up issue because this PR is fairly monumental already #4 |
Upgrade to stable futures (#2).
3 participants
Specifically this section from the latest hackmd document. Can be found in c9d922c
We define
E_r,v, v's estimate of what might have been finalised in round r, to be the last block in the chain with headg(V_r,v)that it is possible forC_r,rto have a supermajority for. If eitherE_r,v<g(V_r,v)or it is impossible forC_r,vto have a supermajority for any children ofg(V_r,v), then we say that (v sees that) round r is completable.E_0,vis the genesis block (if we start at r=1).