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

[cwgoes]

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)

[jackzampolin]

++

[codecov]

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

[alexanderbez]

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

[alexanderbez]

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

[cwgoes]

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

[Hyung-bharvest]

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]

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 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 The 34% cabal & selective precommit censorship #2522, before deciding on this solution.

[hendrikhofstadt]

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

[Hyung-bharvest]

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.

[zmanian]

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

[cwgoes]

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]

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.

[1xCL]

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]

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]

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.