New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delegation in Game of Stakes #2726

Closed
gamarin2 opened this Issue Nov 7, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@gamarin2
Copy link
Contributor

gamarin2 commented Nov 7, 2018

We may need to do a small adjustment to delegation for GoS. Here are the reasons:

  • If delegation is allowed in GoS, then a very proficient validator might collude with a less proficient one so that the latter delegates to the former. This would be beneficial to both since rewards for winning the game are not linear. Another concern is that maybe a validator had a friend declare intention to participate in GoS only to delegate to them once the game starts. I don't think these are fair techniques to gaining an advantage.
  • If delegation is not allowed, but only in the guidelines (not in protocol), then we open the way for validators to grief other validators.
  • If delegation is not allowed in protocol, then we have the problem that validators still need to be able to increase their self-bond from the rewards they make, and that happens through a delegate message. This means we would probably have to add a check that --from address is the same as --validator address when processing a delegate message. I think this is probably the best solution

cc @cwgoes @rigelrozanski @sunnya97 @alexanderbez @jaekwon

@cwgoes

This comment has been minimized.

Copy link
Contributor

cwgoes commented Nov 8, 2018

Hmm. I think we want Game of Stakes to be as close to "real" a simulation as possible - I don't disagree with the scenarios you mention, but I think they could also happen on mainnet (with the exception of Sybil-attacking the limited KYC process for starting stake, but I don't think we can do much about that)!

If they do indeed happen in Game of Stakes, it would be useful information for us to see. I'm a bit less concerned about such actions "ruining" the game - the ICF has fiat power and can distribute the Atom prize pool however it sees fit, so if we think certain actions are not engendering a useful simulation we can alter the reward function.

If we do want to change anything in protocol it would be challenging - the kind of collusion you mention isn't stopped by prohibiting delegation while allowing self-delegation, since the "lesser" validator can just transfer the "greater" one their stake and have some off-chain agreement for payments to be sent back.

@gamarin2

This comment has been minimized.

Copy link
Contributor

gamarin2 commented Nov 8, 2018

Hmm. I think we want Game of Stakes to be as close to "real" a simulation as possible - I don't disagree with the scenarios you mention, but I think they could also happen on mainnet.

I agree with the first part of the sentence! I think my problem here is that we create different incentives than mainnet with the GoS rewards curve. There is a much clearer benefit for a single non-proficient validator to delegate to a very proficient one in the GoS.

If they do indeed happen in Game of Stakes, it would be useful information for us to see. I'm a bit less concerned about such actions "ruining" the game - the ICF has fiat power and can distribute the Atom prize pool however it sees fit

I agree, but then we should clearly communicate that it is prohibited behaviour. Otherwise validators that did collude can say in good faith that this was not prohibited, and validators that did not could feel this is not a fair way of winning. Or we could do no such things, but I'm not sure the community will like that (I may be wrong!).

If we do want to change anything in protocol it would be challenging - the kind of collusion you mention isn't stopped by prohibiting delegation while allowing self-delegation, since the "lesser" validator can just transfer the "greater" one their stake and have some off-chain agreement for payments to be sent back.

Yes, we'd have to disable/prohibit transfer as well if we were to go with this solution.

@cwgoes

This comment has been minimized.

Copy link
Contributor

cwgoes commented Nov 8, 2018

There is a much clearer benefit for a single non-proficient validator to delegate to a very proficient one in the GoS.

Wouldn't the very-proficient validator just set a higher commission rate, and the supply/demand balance out? It's true that the GoS rewards curve is non-linear while the in-protocol rewards on mainnet should be linear, but I think the social reputation of validators in attracting real-world delegation is probably also non-linear.

I agree, but then we should clearly communicate that it is prohibited behaviour. Otherwise validators that did collude can say in good faith that this was not prohibited, and validators that did not could feel this is not a fair way of winning.

Yes, definitely. Let's cover this in the webinar - maybe we could also release a written set of guidelines before the game begins. We could also have "warning" / "enforcement" periods if we change the rules mid-Game.

Yes, we'd have to disable/prohibit transfer as well if we were to go with this solution.

I think that would prevent many attacks or behaviors we might want to see - one validator splitting up their stake into multiple validators, bribing other validators to coordinate attacks, stealing funds if they successfully compromised a key, etc.

@gamarin2

This comment has been minimized.

Copy link
Contributor

gamarin2 commented Nov 8, 2018

Wouldn't the very-proficient validator just set a higher commission rate, and the supply/demand balance out?

Yes, but the higher commission rate does not come into play in GoS, because there are no non-validator delegators. I agree that there is other mechanisms at play, but I'm just arguing that we are introducing a specific incentive in GoS that does not exist in mainnet.

Yes, definitely. Let's cover this in the webinar - maybe we could also release a written set of guidelines before the game begins. We could also have "warning" / "enforcement" periods if we change the rules mid-Game.

👍

I think that would prevent many attacks or behaviors we might want to see - one validator splitting up their stake into multiple validators, bribing other validators to coordinate attacks, stealing funds if they successfully compromised a key, etc.

Ok, let's agree not to go with this solution then, and just provide guidelines!

@ValarDragon

This comment has been minimized.

Copy link
Member

ValarDragon commented Nov 9, 2018

Yes, definitely. Let's cover this in the webinar - maybe we could also release a written set of guidelines before the game begins. We could also have "warning" / "enforcement" periods if we change the rules mid-Game.

I'm confused, this was known and is part of the desired things to test. As i noted in the slack conversation, I'm certain this was known. (Its the obvious thing to do...) We'd want to simulate the system with different initial stakes. Here the initial stake you possess is directly proportional to the amount of effort you put in at the start.

@cwgoes

This comment has been minimized.

Copy link
Contributor

cwgoes commented Nov 29, 2018

@gamarin2 Anything else we should communicate here or can we close this?

@gamarin2

This comment has been minimized.

Copy link
Contributor

gamarin2 commented Nov 29, 2018

We can close

@gamarin2 gamarin2 closed this Nov 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment