DBFT reinitialization after chain height change #261

New issue

Closed

opened 2025-12-28 17:12:43 +00:00 by sami · 0 comments

sami commented

2025-12-28 17:12:43 +00:00

Owner

Originally created by @roman-khimov on GitHub (Feb 13, 2020).

Originally assigned to: @roman-khimov on GitHub.

If there was a new block accepted and added to the chain of consensus node, the consensus process should restart on this new height regardless of its stage (it's obsolete anyway). #641 fixed a part of this problem in that eventually (on timer expiration) the process will be restarted, but it can take some unpredictable time (especially with timer extensions like in nspcc-dev/dbft#24) and node can easily miss the next consensus round.

At the same time it shouldn't lead to node restarting consensus on every block added during the initial sync, so probably we also need to redefine consensus readiness from "minimum number of peers connected" to "no known peer has better last block index" (which can be a definition of node being in sync with the network).

Originally created by @roman-khimov on GitHub (Feb 13, 2020). Originally assigned to: @roman-khimov on GitHub. If there was a new block accepted and added to the chain of consensus node, the consensus process should restart on this new height regardless of its stage (it's obsolete anyway). #641 fixed a part of this problem in that eventually (on timer expiration) the process will be restarted, but it can take some unpredictable time (especially with timer extensions like in nspcc-dev/dbft#24) and node can easily miss the next consensus round. At the same time it shouldn't lead to node restarting consensus on every block added during the initial sync, so probably we also need to redefine consensus readiness from "minimum number of peers connected" to "no known peer has better last block index" (which can be a definition of node being in sync with the network).