It would take a few hundred years to cause my use case (one version per Tendermint block) any problems, but it currently we overflow various of our nodedb prefixes well before we overflow the underyling int64 type used for versions:

https://github.com/tendermint/iavl/blob/master/nodedb.go#L24-L30

IAVL used to load every node from previous versions:

v0.9.2...v0.10.0#diff-6d87913bee304887177dad726b816faeR256

Once we get past version 9999999999 then we will not be able to load newer versions because of the behaviour of Sscanf: https://github.com/tendermint/iavl/blob/master/nodedb.go#L344.

We'll actually still save them because the corresponding Sprintf will include digits outside the padding. But we'll hit this error when loading a large version: https://github.com/tendermint/iavl/blob/master/mutable_tree.go#L248

It would make sense to use a prefix that is 8 bytes - we could use raw big-endian padded bytes or we could use 16 chars of hex so that we maintain the lexicographical sorting we need for iteration. At least things blow up at the same time (and a significantly larger number) as well as it being neater to concede the same version bound.

Note the lazy-loading added by 0.10.0 makes it cheap to store a large number of versions, which is nice.