Cosmos-sdk: Allow Genesis Validators without Self-Delegation Atoms

[rigelrozanski]

As discussed in meeting, create-validator (aka. declare candidacy) should allow you to pay the fees for your friends/family create-validator transaction - however not to be able to give them self-delegation coins

this is achieved by allowing integrating use of an --owner flag. If the owner is the same as the transaction sender they may self-delegation coins, if it is different they may not have any self bond.

Simultaneously, we need to allow for validators to persist without any self-delegation coins - this is a feature which should be turned off by governance at some point once send transactions are enabled

Edit: This transaction should also enforce that there is a delegation from the "fee-payer" of this transaction to ensure that the newly created validator has some stake - even though it won't be self delegation

[ebuchman]

Need to include update in spec too

[ValarDragon]

Do we want to do this? I'd personally prefer that we have zero power validators auto-unbonded. (I think it makes it clearer)

Allowing 0 power validators in genesis is an edge case that it isn't critical to support. We could just have those validators declare candidacy once the network begins. The only difference here is that they can no longer be delegated to from block 1 (delegations have to wait until said validators get enough atoms to pay gas for candidacy declarations)

I think this is the sort of thing that may be convenient to have at launch, but isn't going to have much long term benefit / will complicate the code base. Since sends aren't going to be enabled any way right when we launch, I don't think its critical that this be supported.

[rigelrozanski]

@ValarDragon

I'd personally prefer that we have zero power validators auto-unbonded. (I think it makes it clearer)

Me too, unfortunately we need this _during an introduction phase_ of launch - this feature should absolutely be turned off as soon as sends are enabled. As per the problem we want to address of allowing for early validators to join even if they don't have any atoms to even declare-candidacy with.

Allowing 0 power validators in genesis is an edge case that it isn't critical to support. We could just have those validators declare candidacy once the network begins. The only difference here is that they can no longer be delegated to from block 1 (delegations have to wait until said validators get enough atoms to pay gas for candidacy declarations)

Incorrect, the problem is not for being a validator at genesis - it's for being a validator during the send-disabled period after launch which is going to be a decent chunk of time (If I had to guess on the order of month) - we want to engage new validators during this period and build a strong validator set here.

Since sends aren't going to be enabled any way right when we launch, I don't think its critical that this be supported.

As mentioned I think this is the exact reason why we _should_ have zero-self-bond validators at launch - doesn't mean it should persist.

---

I do agree that it will make the code base more complicated to have and that this is an edge case for launch, but I don't see any other way around which doesn't include preferential treatment (which sounds a lot worse that a little bit more code)

[ValarDragon]

Oh you're right, I didn't mentally connect that no sends means you can't get atoms to declare-candidacy. You're completely right, thanks for clearing that up in such detail :)

[rigelrozanski]

Convo with @cwgoes - I think we should actually not allow for ZERO stake ever, smoothest transition, we can still keep all the desirable properties which this issue first introduced by requiring that the "fee-payer" of the transaction is also the first delegator:

cwgoes
https://github.com/cosmos/cosmos-sdk/issues/1513#issuecomment-403020895
If we want to support zero-self-bond validators, I think we might need a different strategy
Even with the current staking implementation, if you sponsor someone else's validator declaration transaction, they'll end up with zero power (which might not be handled correctly) until someone delegates to them
Another option would be to have an explicit "withdrawCandidacy" transaction - the only way a validator record gets deleted - and otherwise just ignore zero-power validators in the UpdateBondedValidators logic
rige
how about we make it that you have to delegate to them at the same time?
So they actually do start with power (it’s just not self bond power)

cwgoes
We could do that - although if you later undelegate their validator record gets deleted and they'd have to ask you to "sponsor" them again (prior to transfers being enabled)
rige
Yeah I mean that sounds totally fair
However, if anyone else has also delegated to this validator - then that validator would not be deleted
we kind of need to be depending on out-of-band agreements for this one I think
^ I think this is the simplest way to achieve what we want
Not sure it’s ever a good idea to allow for validators with zero power from the the get-go
Then we get to keep that fun invariant that everything that is in the state has power associated with it (the state-space is more spamable otherwise)

cwgoes
I don't know if spam is a problem; all transactions that would create validator entries cost a fee and we never iterate over all the validators (just ranked by power, for which we keep an index)
But that solution seems reasonable too, we'll just have to add a special Msg to combine declare-candidacy-for-other and delegate-to-other (edited)
rige
OH
and this is great because we don’t even need to turn this off ever when we enable sending
so the transition will be smooth

[zmanian]

I think #1600 closes this issue.

[cwgoes]

Verily.