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: https://github.com/cosmos/cosmos-sdk/pull/7184#issuecomment-682465762
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
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 https://github.com/cosmos/ics/issues/445.
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.
This is a separate concept of "epoch"; see https://github.com/cosmos/ics/issues/445 & https://github.com/cosmos/ics/issues/439. Perhaps we should rename it.
The point about separate data to sign over still holds, though.
Per my understanding of two linked issues, it seems accurate to me to rename epoch to lite client version number?
Most helpful comment
Per my understanding of two linked issues, it seems accurate to me to rename epoch to lite client version number?