Retrieve epoch numbers from chain-id

[AdityaSripal]

Epoch numbers must be encoded into chain-id so that validators implicitly commit to them.

However different clients may have a range of restrictions wrt chain-id, ref here: #7184 (comment)

Need some discussion on how to handle this in IBC. Seems like we cannot force all Tendermint clients to adopt a canonical chain-id format?

cc: @fedekunze @cwgoes @colin-axner

[cwgoes]

We can attempt to parse the epoch from the chain ID and force a default epoch if we fail; this should be safe.

This is all for safe future upgrades per cosmos/ibc#445.

[ValarDragon]

Epoch as I understand it relates to the in-consensus stake value for validators being fixed for a number of blocks.

In that case, do txs need to sign over the epoch number? (They currently sign over the chain ID for cross-chain relay protection) Is this intentional? It seems like a better solution if unintentional would be to get Tendermint to expose an additional "data to sign over" field for validators, rather than using the chain-ID.

(There is a claim that it is good for tx signers to do this to cause large divergences in state when applying weak subjectivity attacks)

If thats not the case, I suggest re-naming epoch to describe what its an epoch for.

[cwgoes]

This is a separate concept of "epoch"; see cosmos/ibc#445 & cosmos/ibc#439. Perhaps we should rename it.

The point about separate data to sign over still holds, though.

[ValarDragon]

Per my understanding of two linked issues, it seems accurate to me to rename epoch to lite client version number?