spec: should we update the valid value for a round that has finished?

[cason]

The logic of line 36 of the arXiv paper updates the validValue_p and validRound_p upon receiving, for the first time, a value v and 2f + 1 Prevotes for id(v) in current round round_p. If, in addition, the validator has not yet issued a Precommit, we also update lockedValue_p and lockedRound_p a Precommit for id(v).

While the logic is restrictive in the paper, in my opinion because the same logic is used to update valid and locked values and rounds, there should be no objection to state the logic as following:

upon 〈PROPOSAL, hp , r, v, ∗〉 from proposer(hp , r) AND 2f + 1 〈PREVOTE, hp, r , id(v)〉with valid(v) and r <= round_p
   if r > validRound_p
      validRound_p ← r
      validValue_p ← v

This means, in few words, that when a node is already in round round_p = 2 but it receives 2f + 1 〈PREVOTE, hp, 1 , id(v)〉 for a full value v the node knows, it would update valid round to r = 1 and value value to v. I don't think we can do that for messages from future rounds, for instance, if r = 3, but I don't see any restricting for doing that for previous rounds.

What is the goal? The goal is to produce ValidValue events even when a node only realizes that a value has became valid after the round where this has happened, due to asynchrony mostly. When a value becomes valid we are pretty sure that this is the value that must be decided on that height, except for some particular corner case. In particular, this is a value that we should retain, as it is very likely to be the end decision value for the height.

[cason]

@josef-widder, is there a way to update the model with this change and verify it everything works as previously?

[josef-widder]

If I understand correctly, the ValidValue event you talk about is issued by the driver to tell the outside world (gossip?) that there is a polka. I am not sure why we should funnel this information through the consensus state machine. The driver could just always report whenever the votekeeper tells it that there is a new certificate.

I am not in favor of the change, because

• it changes the algorithm
• there are weird behaviors, a proposer could start a round with validValue == nil, then prevotes a different block, and later validValue could be set by the new rule. I don't think this would break something, but I feel uneasy ;-)
• similarly, in a round, this new rule could be executed multiple time for multiple values, round (with increasing round numbers. Again, this seems complex.

So if the requirement on the ValidValue event is as described, I would prefer to handle it without touching consensus. But I am happy to discuss.

[cason]

The only role of ValidValue is for the proposer to re-propose it once we know one. So essentially what I am proposing is an optimization that may render the decision of multiple-rounds instances faster in the case where the network is slow (i.e., before GST).

There are no changes in the update of LockedValue, where we need to update it, if it is the case, to a value proposed on the current round.

[cason]

Just want to bring this discussion back in the context of the analysis of liveness of Tendermint.

While it clearly does not solve the problem, as shown in the problematic run discussed in #956, in practice it would allow a faster converge on having new proposers re-proposing a value once it gets locked by someone.

I think the changes in the algorithm are minimal. I understand that we may have multiple updates of validValue and validRound within a round, but the content of this variables is only important when the process becomes a proposer of a round.

Notice also that for liveness purposes we need validRound from the proposer to be >= lockedRound from any correct process. When this condition is met, we cannot update validRound since it is already set to the maximum possible value.

I discussed this with @nenadmilosevic95, I know he has some concerns, but I really don't see why we need to be so strict when updating this field. I mean, if a round r value was valid while a process was in round r, it is still valid when the process just moved to round r + 1.