Validators fails to produce blocks at the beginning of a new period

[phuctd95]

On November 13th 00:00 UTC, 2024, the chain experienced a halt at block 39,871,600, just before transitioning to a new period. We promptly created a hotfix release and applied it to the Sky Mavis GV validator, enabling it to resume block production. This allowed other nodes to catch up and continue to produce blocks.
Subsequently, other validator nodes also upgraded to the hotfix release to prevent similar issues in the future.

Version: Goda (v2.8.3)

Root cause: Following the implementation of the rotating validator feature, we have introduced a period definition into the Ronin network. The starting block of each period is required to contain the candidates' address, BLS public key, and vote weight. However, block 39,871,600 was produced by validator nodes without including this information. As a result, the block was was rejected when other node verify the block header.

To determine if a block marks the beginning of a new period, the IsPeriodBlock function is used. This function relies on the block header's timestamp. However, in the Prepare function, the block header’s timestamp is calculated after IsPeriodBlock is called. This means that IsPeriodBlock in Prepare is actually based on the timestamp of block 39,871,599. Hence, in the block production path (Prepare function), block 39,871,600 was not marked as the beginning of a new period; however, in the block reception path (VerifyHeader function), this block was identified as the start of a new period. This issue occurs when the first block of an epoch (in this case, block 39,871,600) is the first block to pass midnight (00:00 UTC).

Fix: To fix this issue, we move the timestamp calculation before the IsPeriodBlock logic in the Prepare function.
PR: #629
Release: https://github.com/axieinfinity/ronin/releases/tag/v2.8.3-hotfix