staking pools need separate rewards channel when bonding about rchip-proposals HOT 7 OPEN

We recently discussed this in discord...

@tgrospic writes:

This is interesting. Are you saying that something very simple can be enough to support staking pools, like REV address for rewards?

yes, I believe something very simple can be enough to support staking pools, like REV address for rewards

I'm not sure how risk is shared between pool users and the validator. Is it the case that pool users trust in competence of the validator or they should participate only with the loss of rewards?

in cosmos chains, delegators rely on the competence of the validator; if the validator double-signs and gets slashed, the delegators lose their stake (in proportion)

@zsluedem writes:

That sound like an additional abstract layer wrapping with staking vault.

Well, yes, of course, the staking pool contract is a layer on top.

Are you sure splitting the rewards address from the staking address is enough for the staking pool?

I can't be certain until I have more experience, but I'm pretty sure.

May I ask what would the whole structure of the staking pool with the method you provided above? More concretely, how does the user stake in the staking pool? And how is the relationship between the staking pool and the staking contract(POS contract in dev)?

I expect the user goes to the staking pool and trades REV for tokens representing their stake. And once every epoch, the staking pool contract calls the PoS contract to deposit or withdraw REV so that the total stake matches the sum of what its clients want staked. Something like that.

But what is the role of paying the reward with another rev address playing here?

That way the reward goes from the PoS contract to the staking pool contract.

Do you expect the reward to be paid in every epoch?

I expect users can start a withdrawal at any time; withdrawals take the length of an epoch to complete (21 days is typical in cosmos; I don't know how long an rchain epoch is)

Great~! Thanks very much. I think I got better view about your design now~! Things start to make sense.

from rchip-proposals.

I see this main requirement. From the perspective of a validator who needs to sign a block, it must be "physical" private (public) key in the PoS contract.

from rchip-proposals.

I see... Then perhaps the bond method could take a (required) public key for signing blocks and (optionally) a separate rev address for rewards?

from rchip-proposals.

@jimscarver what do you think of getting this into the PoS contract in time for one of the upcoming hardforks?

from rchip-proposals.

@9rb @tgrospic would you please schedule this on one of the core dev milestones? Does this have sufficient support? Is there any argument against?

Does it help if I make an issue in rchain/rchain?

from rchip-proposals.

@dckc It would be very useful if you can create an issue with possible attack vectors if you can think of any. We discussed about your suggestion in our dev standup. @leithaus said he needs to think if there is some potential misuse but in general we had agreement that we want to implement it in PoS.

I'd like to include it HF2 because we already included some changes scheduled for HF3. If you can help us to write/review some of these changes in Rholang it would mean great deal for us. Please feel free to join any of our dev standup to discuss about details.

from rchip-proposals.

@dckc It would be very useful if you can create an issue ...

OK, will do.

@leithaus said he needs to think if there is some potential misuse but in general we had agreement that we want to implement it in PoS.

I can't think of any attack vectors just now. I'll think it over a bit.

In fact, this seems to be a standard practice in the Cosmos ecosystem:

https://www.mintscan.io/osmosis/account/osmo1hjct6q7npsspsg3dgvzk3sdf89spmlpfqua7lv

I'd like to include it HF2 ...

that would be great!

from rchip-proposals.