Proposal: do not vote on empty hash

[fed-franz]

Summary

See here

Currently, when a provisioner does not receive a candidate within the timeout, it votes NIL. However, this is somewhat similar to not accepting votes for previous iterations: it's perfectly possible that the candidate exists and we just don't know it (yet).

This DIP proposes the following behavior:

• if no candidate is received, do not vote
• if a invalid candidate is received, vote NIL on the candidate

This is also related to having votes expressed in a separate field from the block hash (this could be included in this dip or in a separate one).

[goshawk-3]

However, this is somewhat similar to not accepting votes for previous iterations: it's perfectly possible that the candidate exists and we just don't know it (yet).

In the tagged PR, if the candidate does exist and it arrives with a delay then it's collected by the node regardless of NIL votes already sent for it.

[fed-franz]

However, this is somewhat similar to not accepting votes for previous iterations: it's perfectly possible that the candidate exists and we just don't know it (yet).

In the tagged PR, if the candidate does exist and it arrives with a delay then it's collected by the node regardless of NIL votes already sent for it.

Meaning the node can potentially generate two votes for the same block: one NIL and one hash (if the block is valid).

[goshawk-3]

Meaning the node can potentially generate two votes for the same block: one NIL and one hash

No, an elected provisioner may send two votes one for a valid candidate and one for an empty hash. (this is not two votes for the same block)

[fed-franz]

Meaning the node can potentially generate two votes for the same block: one NIL and one hash

No, an elected provisioner may send two votes one for a valid candidate and one for an empty hash. (this is not two votes for the same block)

It is, if it's for the same round and step. Nodes can choose either vote when counting for Reduction

[fed-franz]

This is assuming we do not (currently) distinguish between voting NIL for an invalid candidate and voting NIL on a missing candidate.

[fed-franz]

As an additional motivation for this DIP, voting on an empty hash cannot distinguish among forks: if a fork exists, and we receive a NIL vote on empty hash for round R and step S, we couldn't tell which fork it refers to.

[goshawk-3]

As an additional motivation for this DIP, voting on an empty hash cannot distinguish among forks: if a fork exists, and we receive a NIL vote on empty hash for round R and step S, we couldn't tell which fork it refers to.

IMO, this is pretty rare situation without any significant impact.
Anyway, that could be easily addressed by having prev_block_hash in the vote for empty hash.

[fed-franz]

As an additional motivation for this DIP, voting on an empty hash cannot distinguish among forks: if a fork exists, and we receive a NIL vote on empty hash for round R and step S, we couldn't tell which fork it refers to.

IMO, this is pretty rare situation without any significant impact. Anyway, that could be easily addressed by having prev_block_hash in the vote for empty hash.

I think the impact is quite relevant, since the same vote can be counted for two different blocks and it can produce an non-deterministic situation.
The fact that this is an edge case (but not so remote IMO) doesn't mean it shouldn't be taken into account (quite the opposite in fact).

I agree that including prev_block_hash in the Header would solve this issue.
In fact, this could also be helpful in other fork situations.

[goshawk-3]

Currently, when a provisioner does not receive a candidate within the timeout, it votes NIL. However, this is somewhat similar to not accepting votes for previous iterations: it's perfectly possible that the candidate exists and we just don't know it (yet).

Implementation-wise, regardless of any NIL vote received, current implementation (PR) does the following:

• collects votes and candidates for any former iteration
• vote for candidates (if a committee member) of any former iteration

NB: Former iterations means any iteration from 1st to the current one. Not to be confused with previous iteration which includes only the (current_iteration -1 )