The latest confirm epoch number rollback frequently in testnet, almost once per minute

[wangdayong228]

The latest confirm epoch number rollback frequently in testnet, almost once per minute. The peer internet connection delay of ping is almost between 50ms~100ms. So is there any reason may lead to this case?

That makes the latest confirm epoch not stable, could config the confirmationRisk in config.toml file to give user chance to set long confirm period to ensure latest confirm epoch stable?

[fanlong]

I think make confirmationRisk configurable is possible

[ChenxingLi]

I guess this is because the current estimate_confirmation_risk skims a check: "where such block has been followed by all the honest nodes".

Besides, even if we have a correct implementation for estimate_confirmation_risk, it is not guaranteed that the confirmed epoch height does not rollback. We only guarantee that once an epoch height is confirmed, it will be reverted in the future with a really small probability (<1e-8), under predescribed attacker's computing power.

[Thegaram]

I imagine this "rollback" happens when an epoch's confirmation risk is very low (<1e-8) then it temporarily increases (e.g. to 1e-7). Still, when we talk about an epoch being confirmed, we mean that we consider it practically impossible for it to be reverted. I am not familiar with the confirmation meter module, but we could consider adding some logic to remember the highest confirmed epoch number and making sure it is monotonically increasing.