search

rchain / rchip-proposals

Where RChain improvement proposals can be submitted
Apache License 2.0
8 stars 5 forks source link

staking pools need separate rewards channel when bonding #32

Open dckc opened 3 years ago

dckc commented 3 years ago

The proof of stake contract uses public keys to represent parties who stake REV. As far as I can tell, this excludes the use of multisig or other smart contracts as staking entities. Can you confirm? If so, I can evolve this into a concrete proposal...

If PoS used REV Addresses, we could use addresses from RevAddress.fromUnforgeable connected to multisigs, staking pools, etc.

See also https://github.com/rchain-community/rstake

tgrospic commented 3 years ago

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.

dckc commented 3 years ago

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

dckc commented 2 years ago

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

dckc commented 2 years ago

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.

dckc commented 2 years ago

@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?

tgrospic commented 2 years ago

@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.

dckc commented 2 years ago

@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:

image

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

I'd like to include it HF2 ...

that would be great!