Improve cross-bond/unbond process

[maurolacy]

Improve cross-bonding by:

• Avoiding bonding to an inexistent validator. This can be easily checked before processing a cross-bond.
• Avoiding bondings to a tombstoned validator. This can also be checked before processing a cross-bond.

Improve cross-unbonding by:

• Automatically cross-unbonding from a tombstoned validator. This may require some coordination with the remote chain, as unbonded assets might not be released yet, at the time of processing a tombstoning.
• Allow for immediate unbonding from 'unbonded' validators. These are validators that are not in the active set, but that are not jailed nor tombstoned (just unfunded). This would require keeping track and storing of validator state (Valset update: validator state #118).

[uint]

Avoiding bonding to an inexistent validator. This can be easily checked before processing a cross-bond.

Could be missing something, but the cross-bonding improvements seem to already be there. This seems to error on an attempt to stake when the validator state is anything other than active, so as long as the states are synced up, it should work?

[maurolacy]

Yes, you're right.

[uint]

Automatically cross-unbonding from a tombstoned validator. This may require some coordination with the remote chain, as unbounded assets might not be released yet, at the time of processing a tombstoning.

The only way I figured out how to do this is to:

1. add unbonding_period: u64 to virtual-staking::Config,
2. have virtual-staking keep track of tombstoned validators for who we want to cross-unbond delegators,
3. process those cross-unbonds (extra IBC message to external-staking?) in handle_epoch, after the unbonding period has passed.

This feels like complexity, storage and communication overhead for a rather minor feature. Wouldn't a better place for this sort of thing be in some off-chain service, assuming this is something Osmosis really wants? For other cases, unstaking is a 2-step process anyway (as far as contracts are concerned).

[uint]

Allow for immediate unbonding from 'unbonded' validators.

Is this possible in all scenarios when a validator is marked unbonded? I imagine a validator who fell out of the valset is unbonded immediately, but still has to wait for the release of their stake?

[maurolacy]

Allow for immediate unbonding from 'unbonded' validators.

Is this possible in all scenarios when a validator is marked unbonded? I imagine a validator who fell out of the valset is unbonded immediately, but still has to wait for the release of their stake?

unbonded here means 'not in the active set because of not having enough funds'. It doesn't mean the validator has been actually unbonded, i.e. its funds released.

[uint]

unbonded here means 'not in the active set because of not having enough funds'. It doesn't mean the validator has been actually unbonded, i.e. its funds released.

Yeah, but they could fall out of the valset because a threshold changed or something like that, I think?

[maurolacy]

Yes. But in that moment, they are Unbonded. You mean, that the risk is, they could be changed to Jailed or Tombstoned afterwards? That cannot happen AFAIK, as only active validators can be jailed / tombstoned.

[uint]

Yes. But in that moment, they are unbonded. You mean, if they would be changed to Jailed or Tombstoned afterwards?

No. I was worried it's possible to have a validator state change to Unbonded without funds being released yet (having to wait out the unbonding period). I understand it's not, so I'm good!

[maurolacy]

Yes. But in that moment, they are unbonded. You mean, if they would be changed to Jailed or Tombstoned afterwards?

No. I was worried it's possible to have a validator state change to Unbonded without funds being released yet (having to wait out the unbonding period). I understand it's not, so I'm good!

I see. This is something that will in the end require testing / fine tuning over a real Consumer blockchain. At this point, we're assuming that funds will be there, and the unbonding process will simply release them without delay in the case of validators that are In the 'unbonded' state.

[uint]

We've talked in depth with Mauro and I think I finally have a grasp on this. For the third point, what we really need to do is test how the staking module behaves in the wild (does it only release immediately the funds for tombstoned validators, or does it also perform a send?) and adjust tests/code accordingly. For now, it's pending.

[maurolacy]

Yes. Created an issue for that, so that we don't forget about it: #154.

[maurolacy]

Closed by #152

[maurolacy]

Closed by #152.