Description

In the msg_server.go file of the finality module, the code compares fp.HighestVotedHeight (a uint32 in the database) with req.BlockHeight (a uint64 from the message):

if fp.HighestVotedHeight < uint32(req.BlockHeight) {
    ...
}

Strictly speaking, this comparison is safe as long as the block height never exceeds the 32-bit integer limit. However, it introduces an inconsistency between the types used in the message (uint64) and the types used for storing the height in the database (uint32). If a network were to run for decades or have extremely rapid block production such that the block height could approach or exceed the uint32 maximum, this mismatch might lead to incorrect comparisons.

Impact

The likelihood of reaching uint32 overflow for the block height is extremely low in typical deployments (e.g., 10-second blocks would still take decades to exhaust the limit). Nonetheless, this is not best practice and could theoretically cause unexpected behavior if ever triggered. It may also lead to confusion in code maintenance due to the inconsistent use of uint32 vs uint64 across modules.

Recommendations

Standardize the block-height type. If the protocol uses uint64 in messages, store the height as uint64 in the database for consistency — or vice versa.

Remediation

This issue has been acknowledged by Babylon Labs, who considers uint32 sufficient for block-height storage. The current design is that the block height is expected to remain well below $2^{32}$ within the foreseeable operational lifetime (on the order of several decades). They acknowledge this is a minor inconsistency but do not view it as a security risk worth restructuring major parts of the code. The client therefore accepts the minor mismatch and does not plan any changes unless block-frequency assumptions significantly shift.