One validator switching to ML-DSA keys can stop old IBC clients of its chain

CometBFT v0.38.25 can’t read an ML-DSA public key. Its `PubKeyFromProto` knows Ed25519 and secp256k1, and its `MaxSignatureSize` is 64 bytes, while an ML-DSA-65 signature is 3,309. That’s the version Gaia v29.0.1 runs, and the v29.1.0 release candidate from Monday keeps it. The Quarterly says post-quantum consensus keys shipped with SDK v0.55 and CometBFT v0.40, and that the Hub moves to v30 once ibc-go carries v0.55. Before any chain lets its validators use those keys, I wanted to know what breaks on the other side of its IBC connections, so I read the rotation code and the light clients. The SDK docs already say every counterparty must upgrade before the first validator rotates. This is what I’d add to that. v0.38.26 is enough for a Go counterparty The docs ask counterparties for CometBFT v0.40. On the 0.38 line there’s a smaller step. v0.38.26 (13 August, PR 6028 ) backports only ML-DSA decoding and verification, “for the purposes of verification of IBC connections with counterparty chains that are on v0.40”, and raises `MaxSignatureSize` to 3,309. It doesn’t let the chain itself use the key. So a chain on SDK v0.53 doesn’t need the v0.55 migration for its own clients of…

Excerpt (1198 of 3878 characters). Read the whole post on the forum ↗