PROPOSAL: Lower unbonding time to 21days

[Galadrin]

Update staked CRO unbonding from 28 days to 21 days.
Unbonding period is meant to prevent long-range attacks and not to discourage monetary flow.
The 28 days unbonding period is not understandable compared to other Comos ecosystem chains.
most of them use the default value of 21 days.
some of them use lower value like 14days or 10days.

Many peoples wont stake their CRO because they don't like the too long period of 28 days but understand the security needs of a period longer than 7 days.

The proposal is to align the unbonding period to Cosmos period at 21days.

The Cros-nest team

[eeldivad]

Agreed, but curious what CDC's stance on this is since they control majority votes.

[samuel-tay]

I agree too. In fact, I think 14 days would be sufficient too.

[tomtau]

Thank you for the proposal. There are two things to note:

1. The proposal must adjust the consensus evidence "max age" network parameters accordingly as well (they need to match the unbonding time). The proposal could either explicitly lower all the parameters or, if this can happen implicitly, point to the Cosmos SDK code that would automatically update them.
2. Different pieces of functionality depend on the unboding time (staking, evidence handling, IBC light client's trusting period...) -- so while OK in theory, given Murphy's law and the fact that on-the-fly changing of these parameters may not have been done (I don't know if any production networks, at least on the latest Cosmos SDK with IBC connections etc., adjusted these network parameters via a governance proposal), it would be preferable to do more testing on non-production networks.

[tomtau]

one related doc: https://github.com/cosmos/ibc-go/blob/v1.0.0-rc0/docs/ibc/upgrades/quick-guide.md

Changing the UnbondingPeriod: Partially Supported, chains may increase the unbonding period with no issues. However, decreasing the unbonding period may irreversibly break some counterparty clients. Thus, it is not recommended that chains reduce the unbonding period.

[Galadrin]

Thank's for the review.
the IBC is a blocking point... we cannot stop the IBC transfer for 28days to be sure to have every evidences.

when is the next hard-fork ? we should be able to change these parameters in this case without any risk

[tomtau]

AFAIK that IBC quick guide recommendation applies to hard forks (i.e. upgrades via state transitions) as well, so there is always this risk of breaking counterparty clients.
As mentioned, this will need more testing... and I guess a more throughout assessment of how things could break and some clear contingency plans (in the case of IBC, I hope the potentially broken counterparty clients could be fixed via substitute clients from that client update gov proposal type).

[greg-szabo]

Regarding IBC concerns: the main restriction that applies at all times is that the IBC trust period has to be less than the unbonding period. Ideally maybe 2/3 of it.
So if the decision is to lower the unbonding period to 21 days, you can safely set the IBC trust period to 14 days even now and deal with the network parameter change in governance.

Clarification: the trust period is configurable in the relayer.

[tomtau]

For reference:

colin axnér — Yesterday at 11:45 PM
All IBC clients have a trusting period which must be less than the unbonding period. The trusting period is non-upgradeable. If a chain lowers its unbonding period below the trusting period, this will break the counterparty client

Also a bit more here: https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/developer-guide.md

Counterparty clients can upgrade securely by using all of the chain-chosen parameters from the chain-committed UpgradedClient and preserving all of the old client-chosen parameters. This enables chains to securely upgrade without relying on an honest relayer, however it can in some cases lead to an invalid final ClientState if the new chain-chosen parameters clash with the old client-chosen parameter. This can happen in the Tendermint client case if the upgrading chain lowers the UnbondingPeriod (chain-chosen) to a duration below that of a counterparty client's TrustingPeriod (client-chosen). Such cases should be clearly documented by developers, so that chains know which upgrades should be avoided to prevent this problem. The final upgraded client should also be validated in VerifyUpgradeAndUpdateState before returning to ensure that the client does not upgrade to an invalid ClientState.

So I guess one TODO item will be to go through mainnet ClientStates with Osmosis, Cosmos Hub, etc. and check with relayer operators about their settings -- fyi @lezzokafka .

[Volodia12]

I totally agree! For 21 days more people will be wet!

[reefValidator]

totally agree! at least 21 days.. better are 14 days

[chleeab]

Any update on this issue?
I totally agree to reduce the unbonding period to 21 days.
Is the IBC problem solved?

[zanglang]

Hi, I would like to bring attention to this proposal again. In fact, we noticed that Kris especially agreed that the bonding period was too long for end users in his last AMA: https://youtu.be/nGusvoArLmI?t=1036

With increased transparency coming from tools like https://relayers.smartstake.io/network/CRO and https://ibc.iobscan.io/chains, it should have become fairly trivial to reach out to the majority of the relayers handling channels for the Crypto.org chain and synchronizing the trust period configuration change necessary.

We should be able to test this configuration change on Croeseid and a Cronos testnet easily as well, as well.

[MakeCROGreatAgain]

Time to reopen this PROPOSAL!