Cannot self-delegate after being removed from val set
gamarin2 opened this issue · 10 comments
Summary of Bug
When you are ejected from active validator set because another validator got more voting power, it is not possible to increase voting power by increasing self-delegation (via a delegate tx). The delegate tx from validator to validator commits, associated steak disappears, but voting power remains unchanged.
Also, being ejected does not make the validator transition to revoked state (should it?).
The transactions:
There were two transactions. I'm posting them below @cwgoes.
First tx:
gaiacli stake delegate --address-delegator cosmosaccaddr18thamkhnj9wz8pa4nhnp9rldprgant57ryzag7 --address-validator cosmosaccaddr18thamkhnj9wz8pa4nhnp9rldprgant57ryzag7 --chain-id=gaia-7003 --from=delegate-now --amount 40steak
Defaulting to account number: 212
Defaulting to next sequence number: 3
Password to sign with 'delegate-now':
Committed at block 27480. Hash: C9D19EC5B2188BDDAB06B09C6FC038EA022A8C1F
Second tx:
gaiacli stake delegate --address-delegator cosmosaccaddr18thamkhnj9wz8pa4nhnp9rldprgant57ryzag7 --address-validator cosmosaccaddr18thamkhnj9wz8pa4nhnp9rldprgant57ryzag7 --chain-id=gaia-7003 --from=delegate-now --amount 100steak
Defaulting to account number: 212
Defaulting to next sequence number: 2
Password to sign with 'delegate-now':
Committed at block 27438. Hash: 5D1175FC2078513CDFA129C94900B9EF541B10EF
Steps to Reproduce
Get kicked out of active val set because of insufficient voting power. Then try to pass a delegate tx with --addr-delegator = val_address and --addr-validator = val_address
For Admin Use
- Not duplicate issue
- Appropriate labels applied
- Appropriate contributors tagged
- Contributor assigned/self-assigned
Also, being ejected does not make the validator transition to revoked state (should it?).
No, it should not - revoked is a separate state, entered when a validator is slashed for double-signing or for downtime.
The delegate tx from validator to validator commits, associated steak disappears, but voting power remains unchanged.
This is a bug, although I don't think it's true in the general case (we test that) but rather a symptom of a lower-level issue - probably #1857.
@gamarin2 Are the transactions referenced in #1872 (comment) the ones you're referring to with this report?
@gamarin2 Are the transactions referenced in #1872 (comment) the ones you're referring to with this report?
Yes, sorry. Adding them to the post.
No, it should not - revoked is a separate state, entered when a validator is slashed for double-signing or for downtime.
How is this state different from unbonding?
How is this state different from unbonding?
It has nothing to do with voting power - just whether or not a validator is "in jail" for having recently committed a protocol fault (downtime or double-signing). See #1466 (comment).
It has nothing to do with voting power - just whether or not a validator is "in jail" for having recently committed a protocol fault (downtime or double-signing). See #1466 (comment).
Do you become unbonded after 3 weeks in jail? Also, it seemed like you still take a spot in the top 100 validators if you're in jail. Like if there are 100 vals and you get jailed, there are 99 vals and 1 jailed. The 101 val does not enter validator set. At least that's behaviour I observed in testnet, not sure it's desired.
No, it should not - revoked is a separate state, entered when a validator is slashed for double-signing or for downtime.
Ok so what state do you enter when you get kicked out? Unbonding? Bec. you should still be slashable for 3 weeks after you get kicked out.
Do you become unbonded after 3 weeks in jail? Also, it seemed like you still take a spot in the top 100 validators if you're in jail. Like if there are 100 vals and you get jailed, there are 99 vals and 1 jailed. The 101 val does not enter validator set. At least that's behaviour I observed in testnet, not sure it's desired.
While in jail, you're always unbonded (you cannot sign blocks) regardless of voting power. When you leave jail, you may or may not be rebonded depending on whether or not you have enough stake to be in the top hundred validators. The duration of the unbonding period doesn't have anything to do with jail; we can choose independently how long validators are jailed for double-signing and for downtime.
I'm not entirely sure what you mean by "take a spot in the top 100 validators" - being "in jail" has nothing to do with how much stake you have, it's just a state a validator forcibly enters after committing a protocol fault and can leave only by submitting an "unrevoke" transaction after a period of time.
Ok so what state do you enter when you get kicked out? Unbonding? Bec. you should still be slashable for 3 weeks after you get kicked out.
Yes, unbonding - ref #1676.
While in jail, you're always unbonded (you cannot sign blocks) regardless of voting power.
So being slashed seems like a way to become unbonded without going through the unbonding period. Being in jail should make you in unbonding, not unbonded mode. Otherwise you can double sign and then try to get slashed for downtime to avoid being slashed for double signing.
I'm not entirely sure what you mean by "take a spot in the top 100 validators"
I'm asking that because when my Friend got kicked out because of insufficient voting power, there were 102 active validators and 38 jailed validators. So he got kicked out of the val set when total number of val was 140 (the limit?). I'm just saying that the 38 should not take a "spot" in the top X of vals.
So being slashed seems like a way to become unbonded without going through the unbonding period. Being in jail should make you in unbonding, not unbonded mode. Otherwise you can double sign and then try to get slashed for downtime to avoid being slashed for double signing.
Indeed - you're exactly correct - unfortunately "unbonded" is an overloaded term, I just meant "not bonded".
I'm asking that because when my Friend got kicked out because of insufficient voting power, there were 102 active validators and 38 jailed validators. So he got kicked out of the val set when total number of val was 140 (the limit?). I'm just saying that the 38 should not take a "spot" in the top X of vals.
The 38 should not take a spot; if they did that's a bug.
The 38 should not take a spot; if they did that's a bug.
Ok, let's see if it happens again in current testnet or if I imagined it.
Indeed - you're exactly correct - unfortunately "unbonded" is an overloaded term, I just meant "not bonded".
Wait, so when you get slashed you enter "unbonding" state right? Because i don't see a difference between unbonded and not bonded.
Wait, so when you get slashed you enter "unbonding" state right? Because i don't see a difference between unbonded and not bonded.
There are three distinct states: "Bonded", "Unbonding", "Unbonded" - https://github.com/cosmos/cosmos-sdk/blob/develop/types/stake.go#L13. When slashed, you should enter the unbonding state - stakeKeeper.Slash() just updates validator power and calls UpdateValidators(), so no additional logic is necessary - but the unbonding state hasn't been fully implemented yet - #1676.
I don't think we've managed to replicate this, closing for now. If anyone does replicate, please reopen.