The problem seems to be caused by an implementation related to emptyBlockPeriod. Since our network does not currently use emptyBlockPeriod, we have patched it as follows
We think the cause is the above fixed module (consensus/istanbul/qbft/core/request.go).
In this module, sendPrepareMsg is executed asynchronously by time.AfterFunc. Because it is executed asynchronously, it is possible for startNewRound to be executed first.
This causes the Validator, which should be the Proposer of N+1 blocks, to mistakenly consider itself the Proposer of N blocks, and sent a PRE-PREPARE message.
As a result, the consensus after the N+1 block is stuck.
System information
GoQuorum version: v22.7.6 OS & Version: Linux
Bug Details
In networks running on QBFT consensus, there is a problem with consensus stopping when using v22.7 nodes.
For more information, please see the following issue
The problem seems to be caused by an implementation related to emptyBlockPeriod. Since our network does not currently use
emptyBlockPeriod
, we have patched it as followsWe think the cause is the above fixed module (consensus/istanbul/qbft/core/request.go).
In this module,
sendPrepareMsg
is executed asynchronously bytime.AfterFunc
. Because it is executed asynchronously, it is possible forstartNewRound
to be executed first.This causes the Validator, which should be the Proposer of N+1 blocks, to mistakenly consider itself the Proposer of N blocks, and sent a PRE-PREPARE message.
As a result, the consensus after the N+1 block is stuck.