testnet: lengthen trusting period on testnets for ibc relayers

[conorsch]

The trusting period for IBC is 1/3 the unbonding period. On Testnet 77, unbonding period is roughly 3h, which means our trusting period for IBC is 1h. That poses problems for chain upgrades, because it's sometimes difficult to get all nodes migrated and the RPC endpoints restored in that time. Missing the window means that we cannot use the genesis-restart logic, and we're forced to create new channels for Hermes, changes which must then percolate through the prax-registry and into the web extension.

What if we greatly increased the unbonding delay, to say 24h? Then the trusting period would be ~8h and we'd have more time to perform maintenance without clients expiring.

(Tried to capture discussion out-of-band discussion with @avahowell, please edit for clarity.)

[avahowell]

Note that the trusting period is set to 2/3 of the unbonding period (specified in our staking parameters by unbonding_delay):

https://github.com/penumbra-zone/hermes/blob/b0b65b24427d5c9d260414d6e28ec21f4e3252ea/crates/relayer/src/chain/penumbra/chain.rs#L1463

We shouldn't change the trusting period, as there are complex integration issues between unbonding, PoS long range attacks, and light clients. We should instead decide what we want the unbonding period to be, for testnets and for mainnet. For reference, Osmosis has an unbonding period of 14 days.

[hdevalence]

I submitted prop 10 to extend the unbonding period.

[conorsch]

I submitted prop 10 to extend the unbonding period.

That prop failed. I resubmitted it as 11, and delegator-voted on it, but it still failed. I think we'll need to fix #4540 before we can make this change.

[conorsch]

Now that 0.77.2 has been fixed, we're unblocked on this change. However, @avahowell raised some really good points in IBC sync today, advocating for a long unbonding delay. Crucially, whatever unbonding delay exists at time of client creation will apply to channels created by that client forever: even if the unbonding delay is tweaked later. So I'm not rushing a proposal out for the testnet, but rather seeking consensus on what a reasonable, useful value is for us. Once we decide that, we can get things moving quickly.

[avahowell]

1 week seems fine to me.

[hdevalence]

I think 24-48h is a good value for the testnet in order to make testing staking flows faster

[avahowell]

There's two concerns there, one is that we want the testnet to provide minimal friction for testing various aspects of the system. Another concern is that we want the testnet to have a similar set of constants to any higher-assurance deployments, in order to get some forward assurance that the system behaves correctly with those constants. One week strikes a balance between those two, airing on the side of being more accurate to a choice that any higher assurance deployment would make.

[hdevalence]

Cool!

[conorsch]

Word, I'll go for 1w then. I'll prepare this today and submit it, documenting it here. Once it passes we can do the client-creation/channel-creation again. @avahowell would love your help with the latter.

[conorsch]

This is done:

❯ pcli q governance proposal 12 definition
id = "12"
title = "raise unbonding_delay to 1w"
description = "Increasing the unbonding delay also increases trusting period for IBC clients"

[[parameterChange.changes]]
component = "stakeParams"
key = "unbondingDelay"
value = "\"120960\""

❯ pcli q chain info -v | rg -i unbonding
 Unbonding delay (# of blocks)        120960

We're now unblocked to create new, longer-lived clients via Hermes, and try out IBC with fees.