Provide the ability for an external module to block the unbonding of validators until they approve

[AdityaSripal]

In CCV, the validator stake that gets unbonded on the parent chain for a particular ValidatorSetChange cannot be unbonded until the child chains all approve of the unbonding.

Thus, even if the unbonding period has elapsed on the parent chain, the staking module must wait until the child chains also affirm that the unbonding period has elapsed on their respective chains before the stake can be released.

The staking module must expose some form of hook/interface that the CCV module can use to approve the final unbonding.

From my understanding of x/staking, this function:
https://github.com/cosmos/cosmos-sdk/blob/86b0c0ac8eea06c32198cfea328e0433d54c75cc/x/staking/keeper/validator.go#L396

Must wait for CCV

Perhaps we can add some logic that checks for a particular flag to be set by CCV, and we only unbond once the validators have matured on our chain and the flag controlled by CCV is set.

[AdityaSripal]

cc: @alexanderbez @marbar3778

[alexanderbez]

Yeah this totally makes sense. But this also lines up with my sentiment expressed in the other issue regarding governance tallying/hooks -- I would discourage expanding up or tuning the SDK's existing x/staking module to fit these specific needs of CCV.

Instead, I would ensure that whatever APIs are necessary to make this work are public in the SDK's x/staking and then simply extend or embed x/staking the CCV repo where you overwrite any fields or business logic necessary to make this work 👍

[robert-zaremba]

How urgent this is? I'm putting it in v0.46 for now because we are closing the scope for v0.45... unless there will be a contributor who will like to handle this task.

[alexanderbez]

IMO, I don't think this belongs in the SDK at all. So nothing to plan.

[AdityaSripal]

Instead, I would ensure that whatever APIs are necessary to make this work are public in the SDK's x/staking and then simply extend or embed x/staking the CCV repo where you overwrite any fields or business logic necessary to make this work 👍

I don't understand how to make this work. Do you mean that we should "fork" the staking module in CCV and do our custom logic there.

I agree that all the logic regarding when CCV should release stake will be housed in CCV. However, there does need to be some way to communicate that information back to x/staking.

As far as I can tell, that communication will need to be implemented as some API in x/staking, otherwise staking will just unbond the parent stake once the unbonding period is over without waiting for CCV to approve

[alexanderbez]

You create your own x/staking and embed the SDK's x/staking module and overwrite any method(s) you wish. Now this approach can be used to a certain limited extent. If all you need is to overwrite a few methods and not have to really change any internals, this approach is simple and will work. Otherwise, you might actually have to copy/fork the entire module.

For an example of this approach, see how umee "embeds" the ICS20 module: https://github.com/umee-network/umee/tree/main/x/ibctransfer

[AdityaSripal]

Hmm but this would mean that any parent chain would have to use this custom wrapped staking module

So the Hub presumably would be hooked to the custom module and not directly to the staking module in the SDK

[alexanderbez]

Correct.