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

WIP: Alter uptime incentive design, prove precommit inclusion incentive compatibility #3494

Closed
wants to merge 22 commits into
base: develop
from

Conversation

Projects
None yet
10 participants
@cwgoes
Copy link
Contributor

cwgoes commented Feb 4, 2019

Closes #2522

Ready for review, I'm going to write up (and double-check) the math separately in a better document, we can wait for that to merge this or not. I don't know whether this pays the proposer enough to be a concern - it pays the proposer more than at the moment, but I think the proof that they will be incentivized to include precommits is worth quite a bit. If it's a concern, we have another free parameter: we can pay some fraction of the block reward to all validators regardless of whether or not they signed the block (which incentivizes neither precommit inclusion nor voting, but decreases the possible variability of proposer rewards).

Alter the block signing incentive structure as follows:

  • Remove slashing for downtime (retain jailing), and change the default minimum signed ratio to 0.1.
  • Remove distribution parameters BaseProposerReward and BonusProposerReward.
  • Add new distribution parameter ProposerReward.
    ProposerReward determines which fraction of the total reward (fees collected plus inflation, less the community tax) is paid to the proposer of the block proportionally to the fraction of precommits they include. The default value is 75% (see below). Total rewards less the proposer reward are then distributed to all validators which signed the block proportionally to their stake.

I argue that with a sufficiently high ProposerReward a rational validator will elect to include the maximum number of precommits in a block. The total rewards (inflation) in a given block are constant, and the proposer's rewards are proportional to the following formula (modulo rewards less community tax, which is constant):

rewards ~ ((P * F) + ((1 - (P * F)) * (S / T)))

where P is the proposer reward parameter, F is the fraction of precommits included, S is the proposer's stake, and T is the total stake of included precommits.

T = AF, where A is the total bonded stake, by construction. Simplifying:

rewards ~ PF + (S / AF) - (PS / A)

Taking the derivative with respect to F:

d(rewards)/dF ~ P - (S / AF^2) = P - S / (AF^2)

We want this derivative to be positive, so solving for P where S > 0, 2/3 <= F <= 1, and A > 0:

P >= (S / (AF^2))

We want this to hold for all F, so taking the lower bound F = 2/3 which will lower bound the minimum P:

P >= (9 S) / (4 A).

Now we have a choice of parameters, according to what maximum-stake proposer we want to be incentivized to include precommits. Setting S/A = 1/3, after which point they could break BFT safety, and solving:

P >= 3/4.

Standard checklist:

  • Linked to github-issue with discussion and accepted design OR link to spec that describes this work.
  • Wrote tests
  • Updated relevant documentation (docs/)
  • Added entries in PENDING.md with issue #
  • rereviewed Files changed in the github PR explorer

For Admin Use:

  • Added appropriate labels to PR (ex. wip, ready-for-review, docs)
  • Reviewers Assigned
  • Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

@cwgoes cwgoes added this to the v0.31.0 (Launch RC) milestone Feb 4, 2019

@cwgoes cwgoes requested review from ebuchman and rigelrozanski as code owners Feb 4, 2019

cwgoes added some commits Feb 4, 2019

@cwgoes cwgoes changed the title WIP: Remove downtime slashing WIP: Alter uptime incentive design Feb 4, 2019

cwgoes added some commits Feb 4, 2019

@@ -15,6 +15,7 @@ BREAKING CHANGES
- `--tls` is now used to enable secure layer.

* Gaia
* \#3494 Alter liveness incentives to prevent 34% cabal attack and encourage uptime on a per-signature basis

This comment has been minimized.

@jackzampolin
@codecov

This comment has been minimized.

Copy link

codecov bot commented Feb 4, 2019

Codecov Report

Merging #3494 into develop will increase coverage by <.01%.
The diff coverage is 12.12%.

@@             Coverage Diff             @@
##           develop    #3494      +/-   ##
===========================================
+ Coverage    59.66%   59.66%   +<.01%     
===========================================
  Files          131      131              
  Lines         9681     9670      -11     
===========================================
- Hits          5776     5770       -6     
+ Misses        3565     3560       -5     
  Partials       340      340

@cwgoes cwgoes added ready-for-review and removed WIP labels Feb 4, 2019

@cwgoes cwgoes changed the title WIP: Alter uptime incentive design R4R: Alter uptime incentive design Feb 4, 2019

@cwgoes cwgoes changed the title R4R: Alter uptime incentive design R4R: Alter uptime incentive design, prove precommit inclusion incentive compatibility Feb 4, 2019

@alessio alessio removed this from the v0.31.0 (Launch RC) milestone Feb 4, 2019

@alexanderbez
Copy link
Contributor

alexanderbez left a comment

Went through the concept with @cwgoes and the changes look reasonable to me.

reward := feesCollected.MulDec(voteMultiplier).MulDec(powerFraction)

validator := k.stakingKeeper.ValidatorByConsAddr(ctx, vote.Validator.Address)
k.AllocateTokensToValidator(ctx, validator, reward)

This comment has been minimized.

@alexanderbez

alexanderbez Feb 5, 2019

Contributor

is this call expensive? perhaps we can keep track of total rewards and do a AllocateTokensToValidator at the end.

This comment has been minimized.

@cwgoes

cwgoes Feb 5, 2019

Author Contributor

Most calls will be to unique validators - but yes, we could do that for a bit of an efficiency gain.

@dlguddus

This comment has been minimized.

Copy link

dlguddus commented Feb 5, 2019

Hi. Could anyone explain to me why ((1 - (P * F)) * (S / T))) is needed in the equation? If it is not there, every thing is so simple.

And do you think 42.8% is intuitively making sense to you?

Thank you. I don't understand this change intuitively.

edit) I understood what those are for.
Those are reward besides "proposer reward" for the proposer to precommit his own block.
NVM this comment.

cwgoes added some commits Feb 5, 2019

@cwgoes

This comment has been minimized.

Copy link
Contributor Author

cwgoes commented Feb 5, 2019

To-do:

  • Add free parameter to pay some fraction based on just bonded stake
  • Pay unclaimed proposer reward to the community pool instead of to validators who signed
@joepindar

This comment has been minimized.

Copy link

joepindar commented Feb 6, 2019

This seems like a rather foundational change to the economics of running a validator in a Cosmos network being slipped in at the very last minute before mainnet release.

Please can you:

  • engage with the validator community before making such a significant change
  • document what compensating controls (technical or non-technical) were considered to solve issue #2522, before deciding on this solution.
@hendrikhofstadt

This comment has been minimized.

Copy link
Contributor

hendrikhofstadt commented Feb 6, 2019

So I'm trying to understand the reason for this change:

The problem before was that the proposer was not strongly incentivized to include precommits while the voters were not at all incentivized to vote (encouraging proposer censorship).

With this change, the proposer is slightly incentivized to add more precommits while as a voter you are incentivized to get your precommit in.


In both situations the cabal 33% censorship is a problem since we have jailing.

A cabal would only censor if it knew it had more than 33% power so it will also not be affected by the change in incentives here and could still gain more power - lowering the min signed ratio to 0.1 does not help as the cabal could simply censor all block proposals from non-members and could thereby cause 100% downtime for their target since there is no polka on the blocks that contain it's precommits.

The cabal would rather profit from the new incentives as it could selectively censor proposals to massively reduce another validator's reward (due to the change in proposer reward).

Another problem is the now massively increased incentive to prevent a validator from proposing by DDoS or other means.

Something I could also see coming is money laundering using the 75% proposer bonus. It would make it easy for a malicious entity to launder 75% of their fee tokens using a single validator and exceptionally high fee transactions. Thats a more indirect result but still to consider.


So I don't really see how this closes #2522

@dlguddus

This comment has been minimized.

Copy link

dlguddus commented Feb 6, 2019

I raise some doubt on this distribution changes for different perspective.

Occasional missing normally happens with 3-level high security setup with HW validator located at the edge of the world. It is mostly because of timeout setup or huge network delay of some mal-functioning proposers.

Direct punishment on occasional missing will force validators to use light(security-wise) setup to gain low latency so that they can get in top 67% precommits. This meaningless competition on milliesecond latency will lead to low standard of over-all cosmos network's security.

Therefore I think this distribution change is misleading the community. Some percentage of missing should not affect any reward distribution in my opinion.

I also agree on hendrik's comment about ddos targetted to proposer. Because proposer selection is deterministic and proposer reward default is so big that there exists great incentives for attacker to attack the proposer when they propose.

@cwgoes cwgoes changed the title R4R: Alter uptime incentive design, prove precommit inclusion incentive compatibility WIP: Alter uptime incentive design, prove precommit inclusion incentive compatibility Feb 6, 2019

@cwgoes cwgoes added WIP and removed ready-for-review labels Feb 6, 2019

@zmanian

This comment has been minimized.

Copy link
Member

zmanian commented Feb 6, 2019

My expectations that un advertized validator to validator connections will mitigate the proposer dos entirely.

@cwgoes

This comment has been minimized.

Copy link
Contributor Author

cwgoes commented Feb 6, 2019

Thanks for the feedback all - please note that this PR is not yet done (I've relabeled it), as a second parameter needs to be added which will adjust the amount of proposer rewards and signing-proportional validator rewards. I'll add a detailed discussion of the reasons for proposing incentive changes later today - and of course debate is welcome, this hasn't been merged yet.

@fkbenjamin

This comment has been minimized.

Copy link

fkbenjamin commented Feb 6, 2019

I also see this as a very sensitive topic that needs more discussion.

In addition to the arguments mentioned by my fellow validators above, I see another issue: Regarding the 75% proposer bonus, this could also result in validators not broadcasting transactions that include a high fee because they want to include them in their own blocks (to get a high percentage of that fee). This would lead to high-fee transactions actually taking longer than low-fee transactions, which is quite counter-intuitive.

@winslyn

This comment has been minimized.

Copy link

winslyn commented Feb 7, 2019

rewards ~ ((P * F) + ((1 - (P * F)) * (S / T)))
where P is the proposer reward parameter, F is the fraction of precommits included, S is the proposer's stake, and T is the total stake of included precommits.

Proposers could censor validators with high voting power to get enough F while decreasing T.
Censoring the top 1 validator who owns 10% voting power out of 100 validators would increase the proposer's reward.

@cwgoes

This comment has been minimized.

Copy link
Contributor Author

cwgoes commented Feb 7, 2019

rewards ~ ((P * F) + ((1 - (P * F)) * (S / T)))
where P is the proposer reward parameter, F is the fraction of precommits included, S is the proposer's stake, and T is the total stake of included precommits.

Proposers could censor validators with high voting power to get enough F while decreasing T.
Censoring the top 1 validator who owns 10% voting power out of 100 validators would increase the proposer's reward.

Fraction is stake-proportional (not just the number of precommits).

@cwgoes

This comment has been minimized.

Copy link
Contributor Author

cwgoes commented Feb 7, 2019

Hi all, especially @joepindar @hendrikhofstadt @dlguddus @fkbenjamin @winslyn -

I've written up a longer discussion of the current incentive scheme and suggested changes at #3529 - would appreciate your feedback.

I'm going to close this for now since the top comment no longer reflects what this PR actually does, and it would be better to discuss first, but I think we should be careful to avoid "status quo" preference and consider equanimously the upsides & downsides of both current & proposed systems.

@cwgoes cwgoes closed this Feb 7, 2019

@cwgoes cwgoes referenced this pull request Feb 7, 2019

Open

WIP: Liveness incentive work, second try #3534

0 of 5 tasks complete

@cwgoes cwgoes deleted the cwgoes/liveness-incentive-alterations branch Feb 7, 2019

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