For view change, the view change ID is the key to determine which node
will be next leader. In our original algorithm, the view ID always increased one step
at a time. The view change period increased exponetially based on the square of
the gap between current view changing ID and previous known block view change ID.
However, it is very slow to converge the view change if multiple nodes are offline and
view change can't be reached. Especially, during the shard down event, multiple nodes
are offline and other nodes have advanced their current view changing ID.
The new time-baed synchronuous view change algorithm uses the local timestamp and
the timestamp of the block to calculate the expected view changing ID. In this case,
offline nodes can immediately catch up with the latest view changing ID as long as
the offline nodes have the latest sync'ed block and relatively acturate local
clock. This algorithm will converge the view change faster in one or two view change
duration.
Signed-off-by: Leo Chen <leo@harmony.one>
retry is needed, as the next leader may not enter view change mode immediately
when other validators already sent out view change messages.
Then the new leader may not collect enough signatures for the new view before
timeout.
This can speed up the view change process.
Signed-off-by: Leo Chen <leo@harmony.one>
[viewchange] new view change struct
move all view change data structure to a new viewchange struct
[viewchange] wrap functions in viewchange struct
[viewchange] newView process can not be reentrant
[viewchange] additional debug
[viewchange] always add m3 message to bitmap
[viewchange] shorten the duration for view change
[viewchange] further cleanup of onNewView func
[viewchange] add validpayloadlength const
[viewchange] only add m3 message if valid m1/m2 received
[viewchange] set next leader to any key
[viewchange] print more error message in log
[viewchange] get leader pubkey from coinbase
[viewchange] rename files back for easy review
[viewchange] fix nil pointer in getNextLeader
[viewchange] fix review comments
[viewchange] squash single used function
[viewchange] code re-org
[viewchange] clean up functions
[viewchange] minor typo fix
[viewchange] code clean up and more comments
Signed-off-by: Leo Chen <leo@harmony.one>
next leader can be any leader depending on the gap of the view ID
do not change current pubkey unless leader change succeeded
Signed-off-by: Leo Chen <leo@harmony.one>
[viewchange] encapsulate view ID in the State struct
do NOT ues consensus.current directory to set/get viewID
use the following functions
consensus.SetCurViewID, consensus.SetViewChangingID
consensus.GetCurViewID, consensus.GetViewChangingID
Signed-off-by: Leo Chen <leo@harmony.one>
Rongjian Lan
Leo Chen