[Bug]: halt-height handling behavior changed on v0.50

[MSalopek]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

In previous versions (< v0.50.x) the nodes would stop at halt-height, whereas in v0.50 the chain produces one more block after the specified halt height causing confusion among developers and operators.

There seems to be off-by-one error in cosmos-sdk v0.50 resulting in unexpected behavior.
This PR refactored the halt-height handling for some of the cosmos-sdk releases.

It can be seen that the following lines use >= when comparing halt-height and halt-time:

• uint64(header.Height) >= app.haltHeight
• header.Time.Unix() >= int64(app.haltTime)

The latest changes use > which leads to incorrect and unexpected behavior:

• uint64(height) > app.haltHeight
• time.Unix() > int64(app.haltTime)

This behavior can lead to weird network forks in case of a co-ordinated upgrade that does not go through governance (e.g. when fixing state issues or handling security concerns).

Cosmos SDK Version

0.50.x

How to reproduce?

Start a local node (using simd) and specify a halt-height. It can be observed that the node progresses and halts one block after the specified halt-hight.

e.g.

#  cosmos-sdk v0.47
halt-height = 100 # chain does not produce block 100 and halts

# cosmos-sdk v0.50
halt-height = 100 # chain produces block 100 and halts

cc @stana-miric @dasanchez