-
Notifications
You must be signed in to change notification settings - Fork 2.6k
BEEFY: gossip finality proofs #13727
BEEFY: gossip finality proofs #13727
Conversation
Gossip finality proof in _both_ cases of reaching finality threshold through votes: 1. threshold reached through self vote, 2. threshold reached through incoming vote.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
justif = gossip_proofs.next() => { | ||
if let Some(justif) = justif { | ||
// Gossiped justifications have already been verified by `GossipValidator`. | ||
if let Err(err) = self.triage_incoming_justif(justif) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just checking - the justification is verified by GossipValidator
and we know it is valid. But equivocations are detected here, by BeefyWorker
. And unless I'm missing something, they're only detected when we handle incoming votes. I wonder if it is possible for validator to make two votes and stay unnoticed because the second vote will be gossiped using finality proof? I believe that even if I'm right in my assumption, it is very unlikely scenario (given enough validators set length), so maybe something for the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, for a validator set of size N
, it's possible now for m
voters to "undetectably equivocate" by sending a vote for mmr_root_2
, then including another vote for mmr_root_1
in a proof alongside 2*N/3
other votes for mmr_root_1
.
- Because the precondition of required
2*N/3
"good" votes before being able to "undetectably equivocate", it meansm
can be at mostN/3
in "perfect" network conditions where coordination of who sees what gossipped votes is 100% controlled by dishonest validators. - Even in these perfect conditions where
m=N/3
, best you could do is partition the network to getN/3
honest voting onmmr_root_1
, anotherN/3
honest voting onmmr_root_2
andN/3
dishonest equivocating both => at least one validator will have to visibly equivocate to get over threshold.
Also, because BEEFY is based on GRANDPA, finality point.2 above is not possible, honest validators cannot be convinced to vote on anything other than what GRANDPA finalized.
Ergo, I believe this is not a problem/risk.
…ossip-justifications
@serban300, I've addressed all comments |
* sc-consensus-beefy: add justifications to gossip protocol * sc-consensus-beefy: voter gossips finality proofs * sc-consensus-beefy: add finality proof gossip test * sc-consensus-beefy: always gossip finality proof Gossip finality proof in _both_ cases of reaching finality threshold through votes: 1. threshold reached through self vote, 2. threshold reached through incoming vote. * address comments
* sc-consensus-beefy: add justifications to gossip protocol * sc-consensus-beefy: voter gossips finality proofs * sc-consensus-beefy: add finality proof gossip test * sc-consensus-beefy: always gossip finality proof Gossip finality proof in _both_ cases of reaching finality threshold through votes: 1. threshold reached through self vote, 2. threshold reached through incoming vote. * address comments
* sc-consensus-beefy: add justifications to gossip protocol * sc-consensus-beefy: voter gossips finality proofs * sc-consensus-beefy: add finality proof gossip test * sc-consensus-beefy: always gossip finality proof Gossip finality proof in _both_ cases of reaching finality threshold through votes: 1. threshold reached through self vote, 2. threshold reached through incoming vote. * address comments
Adds gossiping BEEFY finality proofs to the BEEFY gossip protocol.
round_num >= current_best_beefy
,threshold
validator signatures.Fixes #13733