"Set timer to running" appears four times in algorithms 1-3 (twice in algorithm 3), and we need better understanding of the set timer functionality, for example the one in algorithm 2 - why is it necessary to start another timer, if the timer from algorithm 1 (after START) or 3 (after ROUND-CHANGE) should still be running?
We should consider adding more details about the actual changing to a new round - when exactly it happens (immediately after broadcasting ROUND-CHANGE? More cases?)? Is the node limited to "be" only in a single round at a time? Will we be able to see "current round" in the logs? And how messages from non-current rounds (both past and future) are processed?
"Validation of PREPARE messages received from other nodes is achieved by checking that the message format is correct, and that a slashable event will not be caused if the data in the PREPARE message will be signed" - are there more validation methods?
"the node that received the Frc will broadcast a ROUND-CHANGE message with the smallest r value among the r values of the Frc set (referred to as r(min))" - why r(min) is chosen?
In Qrc, pv and pr can be different between the individual ROUND-CHANGE messages - why is it possible to have different pv values for the same instance?
"Before broadcasting the PRE-PREPARE message of a new round, the new leader (see “Leader Choosing” section) must first perform justification on the quorum of ROUND-CHANGE messages Qrc" - it's not really explained what happens if justification of Qrc is failed - is the Qrc simply discarded, and the node just "waits" for the timer to expire (this could either be the timer set during START or a new timer set when\if the leader broadcasted ROUND-CHANGE - we're not completely sure what the accurate timer setting behavior is, see issue 1 above)?
Round change - what if the new leader hasn't received a quorum of PREPARE messages before receiving Qrc (if it's even possible)? How will the leader justify the Qrc? Most likely there should be a "back sync" in case rounds are missed, but this mechanism isn't explained (when the validator node goes back online, should it wait until the attached Eth2 node catches up, and then start processing messages?).
"Set timer to running" appears four times in algorithms 1-3 (twice in algorithm 3), and we need better understanding of the set timer functionality, for example the one in algorithm 2 - why is it necessary to start another timer, if the timer from algorithm 1 (after START) or 3 (after ROUND-CHANGE) should still be running?
We should consider adding more details about the actual changing to a new round - when exactly it happens (immediately after broadcasting ROUND-CHANGE? More cases?)? Is the node limited to "be" only in a single round at a time? Will we be able to see "current round" in the logs? And how messages from non-current rounds (both past and future) are processed?
"Validation of PREPARE messages received from other nodes is achieved by checking that the message format is correct, and that a slashable event will not be caused if the data in the PREPARE message will be signed" - are there more validation methods?
"the node that received the Frc will broadcast a ROUND-CHANGE message with the smallest r value among the r values of the Frc set (referred to as r(min))" - why r(min) is chosen?
In Qrc, pv and pr can be different between the individual ROUND-CHANGE messages - why is it possible to have different pv values for the same instance?
"Before broadcasting the PRE-PREPARE message of a new round, the new leader (see “Leader Choosing” section) must first perform justification on the quorum of ROUND-CHANGE messages Qrc" - it's not really explained what happens if justification of Qrc is failed - is the Qrc simply discarded, and the node just "waits" for the timer to expire (this could either be the timer set during START or a new timer set when\if the leader broadcasted ROUND-CHANGE - we're not completely sure what the accurate timer setting behavior is, see issue 1 above)?
Round change - what if the new leader hasn't received a quorum of PREPARE messages before receiving Qrc (if it's even possible)? How will the leader justify the Qrc? Most likely there should be a "back sync" in case rounds are missed, but this mechanism isn't explained (when the validator node goes back online, should it wait until the attached Eth2 node catches up, and then start processing messages?).
Note - the algorithms are in this doc - https://arxiv.org/pdf/2002.03613.pdf