Is your feature request related to a problem? Please describe.
In #3661, we simplified validator voting power calculation by measuring it in units of staking tokens. However, CometBFT imposes a hard limit of $2^{60} - 1$.
This is not hugely problematic. Assuming a staking token denomination unit of $10^6$, integral staking token quantities take at least 20 bits to represent. This leaves 40 bits (or $10^{12}$) to represent the quantity of tokens (a trillion).
However, we should document this in the specification. If this ever becomes a problem, for example for some re-using the penumbra blockchain stack with parameters that work for them, there is always the option of using a constant factor to rescale the voting power so that it fits the CometBFT limit.
It would generally be good to have a "Getting started" guide accompanied by a list of known limitations/workaround for prospective users of the penumbra stack.
Is your feature request related to a problem? Please describe. In #3661, we simplified validator voting power calculation by measuring it in units of staking tokens. However, CometBFT imposes a hard limit of $2^{60} - 1$.
This is not hugely problematic. Assuming a staking token denomination unit of $10^6$, integral staking token quantities take at least 20 bits to represent. This leaves 40 bits (or $10^{12}$) to represent the quantity of tokens (a trillion).
However, we should document this in the specification. If this ever becomes a problem, for example for some re-using the penumbra blockchain stack with parameters that work for them, there is always the option of using a constant factor to rescale the voting power so that it fits the CometBFT limit.