Make {TERM, b} messages count towards {BVAL, b} thresholds #38
Conversation
This prevents slow nodes not sending an AUX because they don't count
{TERM, b} towards 2f+1 {BVAL, b} messages. This also prevents f+1
{BVAL, b} messages from triggering a send of {BVAL, b} if it has not
already been sent.
Additionally don't lose the fact that we broadcast a bval value.
Pull Request Test Coverage Report for Build 368
💛 - Coveralls |
| @@ -149,7 +149,7 @@ handle_msg(_Data, _J, _Msg) -> | |||
| bval(Data=#bba_data{f=F}, Id, V) -> | |||
| %% add to witnesses | |||
| Witness = add_witness(Id, V, Data#bba_data.bval_witness, true), | |||
| WitnessCount = maps:get({val, V}, Witness, 0), | |||
| WitnessCount = maps:get({val, V}, Witness, 0) + maps:get({val, V}, Data#bba_data.terminate_witness, 0), | |||
There was a problem hiding this comment.
I have some safety concerns here. This implementation allows nodes to effectively vote twice for a value. I think that this is only safe if the witness tracks the source and only allows one vote per node.
There was a problem hiding this comment.
Which kind of vote, it is technically valid, I think, for a node to vote for a bval value twice?
There was a problem hiding this comment.
I guess I was thinking that a malign set of nodes could emit both immediately, which would push the node over the threshold I think?
There was a problem hiding this comment.
add_witness has an 'allow union' flag that prevents changing your vote in the case of a TERM message. BVAL votes are allowed to be made for both values (as the node will emit a {BVAL, b} message once it sees f+1 {BVAL, b} messages).
I'm not clear how many AUX messages can be emitted per round. I think just one, but I'm not sure. Currently it allows a node to propose both.
CONF messages don't use add_witness, but they probably should. and they should allow only a single vote from a node per round.
There was a problem hiding this comment.
I have added a commit to prevent more than one AUX or CONF message per round. TERM was already limited and BVAL should allow multiples.
This prevents slow nodes not sending an AUX because they don't count
{TERM, b} towards 2f+1 {BVAL, b} messages. This also prevents f+1
{BVAL, b} messages from triggering a send of {BVAL, b} if it has not
already been sent.
Additionally don't lose the fact that we broadcast a bval value.