Proposal: alter uptime & precommit inclusion incentives

[cwgoes]

(ref #3494, but let's hold this discussion in an issue)

Note: I think it would be helpful to discuss separately the long-run design goals and the short-term plans for the launch of the Hub. I don't think these proposed changes are implementationally risky, but nonetheless it may be the case that we don't want to make any incentive changes prior to Hub launch and would prefer to let governance decide this later.

Desiderata

We assume validators are rational actors and will take the actions which, ceteris paribus, will maximize their expected rewards. I think we want to incentivize four distinct actions:

1. Validators proposing a block, when pending fee-paying transactions are awaiting inclusion
2. Validators voting (sending their precommits) on valid proposed blocks, always
3. Proposers including other validator's votes (from the last commit) in their proposed block, always
4. Validators staying online and continuing to participate in consensus and vote on blocks, always

Current distribution scheme

Presently, we pay collected fees and inflation at the beginning of each block as follows:

• baseProposerReward percent directly to the proposer, regardless of precommit inclusion.
• bonusProposerReward * fractionPrecommits percent to the proposer, where fractionPrecommits is the fraction of precommits the proposer has chosen to include.
• (1 - baseProposerReward - (bonusProposerReward * fractionPrecommits)) percent to all bonded validators proportionally by stake, regardless of whether or not their precommit was included.
• communityTax, plus any unclaimed bonus proposer rewards, percent to the community pool.

We also:

• Track fees collected and inflationary rewards in the same pool, and pay them out simultaneously.
• Slash validators some SlashFractionDowntime percent, after missing n / k (configurable) blocks.

I argue that this scheme partially fails at (1), fails at (2), succeeds at (3), and partially succeeds at (4).

Why?

1. Proposers are rewarded regardless of whether or not their block includes any transactions, so rational proposers will elect to propose empty blocks, which produces no utility (no transactions were confirmed) and imposes a cost on the network (block storage, bandwidth).
2. Validators are rewarded regardless of whether or not they signed a particular block. As long as a validator is confident that they will not be slashed for downtime - and they can miss a substantial fraction of blocks in a row before being slashed for downtime - electing to withhold their votes will decrease the reward given to the proposer at no cost.
3. Proposers opting to include or exclude a given precommit always increase their rewards if they include the precommit (those rewards would otherwise be split among the bonded validators).
4. Validators who remain offline for an extended period of time will be slashed (and jailed) for downtime, although they can intermittently go offline without punishment.

Possible alternatives:

Possibly, we could elect to make the liveness requirements more stringent - perhaps slashing and jailing validators who miss 10% of blocks. That would decrease the likelihood of validators withholding signatures to punish the proposer or infrequently voting to save bandwidth/hardware costs, but it would enable concerning precommit censorship attacks such as in #2522 (the lower the liveness requirements are, the smaller stake cabal could coordinate to censor, slash, and jail validators).

Notes:

Previously, with the "piggy bank" fee distribution system, we were limited in our ability to pay differently to each validator. Now, with F1, we can easily pay different amounts to each validator on each block, and for that reason I think we can construct a distribution scheme which satisfies all of these requirements.

Proposed distribution scheme

I instead propose (credit also to @sunnya97 @jaekwon) that we utilize our new ability to pay each validator differently on each block to restructure distribution to directly incentivize voting on blocks, remove downtime slashing (but retain downtime jailing), and tweak parameters slightly to ensure incentive compatibility between the proposer and block signers.

Collected fees and rewards will still be tracked together, and payed as follows:

• proposerReward * fractionPrecommits percent to the proposer.
• signerReward percent to all validators who signed the block, proportionally to their stake.
• (1 - proposerReward - signerReward - communityTax) percent to all bonded validators (whether or not they signed the block), proportionally to their stake.
• communityTax + (proposerReward * (1 - fractionPrecommits)) to the community pool (the usual community tax, plus any unclaimed proposer reward).

Slashing would be altered:

• Downtime (n / k unsigned blocks) no longer causes a validator to be slashed, but still causes them to be jailed. Since we no longer need to use downtime slashing to punish offline validators, the uptime requirements can be reduced (maybe 1000 / 5000 blocks or something), which means that a 34% (or smaller) cartel could not execute the attack outlined in The 34% cabal & selective precommit censorship #2522 (although they could still execute other kinds of censorship attacks).

I argue that this new scheme partially fails at (1), succeeds at (2), succeeds at (3), and succeeds at (4). On those criteria, that makes it strictly better than our current scheme, and as such I suggest we adopt it.

Why?

1. Unchanged from the current scheme; proposers are still rewarded for proposing empty blocks.
2. Validators are rewarded in part just proportionally to bonded stake, but in part only if they have signed any particular block, so validators who withhold precommits will still succeed in punishing the proposer a bit but will also punish themselves.
3. Proposers opting to include or exclude a given precommit always increase their rewards if they include the precommit (given a particular relation between proposerReward and signerReward, see below); unclaimed proposer rewards go to the community pool.
4. Validators who miss n blocks will be punished exactly proportional to n, for all n, since validators are punished (a tiny bit) in withheld inflation for failing to sign any particular block. Validators who remain offline for an extended period of time will also be jailed (but this should be unnecessary to incentivize liveness, and is primarily useful for kicking offline validators to speedup consensus).

Possible alternatives:

• Separately track transaction fees and inflation, and pay them in different fractions to the proposer and to bonded or signing validators. I think this might make sense in the future when fees are substantial, but in the immediate future we should expect fees to be minimal, so I think if we don't incentivize the behaviours we want with inflation (for example, by paying fees to the proposer proportional to precommits included and inflation to bonded / signing validators) they won't be performed (if the fees were negligible, the proposer would just worry about their fraction of the signatures, and thus censor signatures above 2/3).

Notes:

For the Hub to succeed in incentivizing both (2) and (3), a particular relation must hold between proposerReward and signerReward, which will constrain our choices.

The block proposer receives rewards proportional to:

rewards ~ P * f + S * (t / T) + (1 - P - S - C) * (t / B)

where:

• P = proposerReward
• f = fractionIncluded
• S = signerReward
• t = proposerStake
• T = signingStake
• B = bondedState

T = f * B, by construction, so simplifying:

rewards ~ P * f + S * (t / (f * B)) + (1 - P - S - C) * (t / B)

The proposer chooses f (choosing whether or not to include a precommit), so derive w.r.t f:

drewards/df ~ P - (S * t) / (f^2 * B)

We want this to be positive:

P - (S * t) / (f^2 * B) > 0

Setting the worst-case t = B / 3 and f = 2/3, solving for P:

P > 3S/4.

That gives us a minimum bound on the proposer reward, given a particular signer reward, to maintain the incentive for a proposer to always include signatures.

It remains, of course, to choose the exact proposer reward and signer reward values - we could choose P = 10% and S = 10%, for example - this requirement is only of a ratio between the two, we can choose the "strength" of incentivization relative to just paying bonded validators independently.

🎉 🍌 🚀 - you made it to the end!
Feedback, concerns, questions, or suggestions welcome.

[bneiluj]

I think the alternative to separately track transaction fees and inflation makes a lot of sense.
What would be the inflation rate compared to the fee rate if fees are or not substantial?

[Hyung-bharvest]

There are generally two cases of downtime jail.

1. 1000/5000 downtime happened including "1000 consecutive missing"
2. 1000/5000 downtime happened but there is no "1000 consecutive missing"

Although 34% cartel censorship can make 2 happen, it cannot make 1 happen unless the validator is actually offline or its network is abnormally bad enough. Because in 1000 consecutive blocks, there should exist roughly 66% blocks proposed by non-cartel validators who are not censoring.

Therefore, case 1 and 2 should be dealt differently in my opinion. Case 1 should have a proper slashing punishment because it cannot happen by cartel censorship. Case 2 can happen with censorship therefore it is reasonable not to punish the validator with slashing.

Losing reward when jailed is not an enough punishment for downtime if we want to build more stable and alive network. (When reward is 20%/year, one day reward is only 0.055%) In this way, we can prevent frequent chain halt due to lack of proper punishment on downtime.

For the distribution model, I think it is flexible enough to mitigate most of our incentivizing goal. Thanks for the good suggestion.

[joepindar]

I may not be reading this correctly, but I don't see an explanation of why slashing is removed.

"Validators who miss n blocks will be punished exactly proportional to n, for all n, since validators are punished (a tiny bit) in withheld inflation for failing to sign any particular block." makes it clear that positive 'carrot' rewards will be between 0+, but there is no explanation of removing the 0- slashing 'stick'.

It seems the analysis is from a 'maximising token rewards' view point - however it fails to consider the negative impact of "losing delegators' tokens" over "underperforming other validators" - and the second order impact of attracting future delegations.

Slashing is a key differentiating feature of Cosmos over networks like Tezos, and has been used as justification for the increasing commission and security above Tezos equivalents. Removing slashing for downtime changes fundamental ecosystem economic assumption and behaviours.

[cwgoes]

It seems the analysis is from a 'maximising token rewards' view point - however it fails to consider the negative impact of "losing delegators' tokens" over "underperforming other validators" - and the second order impact of attracting future delegations.

The analysis is indeed from a 'maximizing token rewards' viewpoint, but I don't think loss of rewards which would have been gained and slashing require different viewpoints - both result in a net loss of tokens for the validator and their delegators (since the validator's signing rewards are mostly paid to delegators).

Slashing is a key differentiating feature of Cosmos over networks like Tezos, and has been used as justification for the increasing commission and security above Tezos equivalents. Removing slashing for downtime changes fundamental ecosystem economic assumption and behaviours.

Which fundamental assumptions do you think it would change? Uptime incentivization doesn't relate to security - that's only affected by slashing-for-equivocation (which this proposal does not modify).

It's true that the incentives will change slightly - at present, missing a few blocks isn't punished at all, while missing above a particular threshold is punished quite a bit - whereas if this proposal were adopted missing a few blocks would be punished a little bit, and missing more blocks punished proportionally more. Since the end goals of uptime incentivization - keeping the network live to process transactions, and ensuring many signatures for faster lite client verification - are more continuous and don't have particular thresholds, in my view that seems desirable.

[cwgoes]

I think the alternative to separately track transaction fees and inflation makes a lot of sense.

I think it makes sense in the long run but I'm concerned about using it initially - since the ratio of fees to inflation will be approximately zero until there is substantial network demand, incentivization solely with fees (or the threat of loss of fees) may be inadequate to encourage particular actions.

[rigelrozanski]

Well written @cwgoes 👏 generally in agreement with the approach, I'm not totally positive on the parameterization, however 10% doesn't seem totally unreasonable

(1 - proposerReward - signerReward - communityTax) percent to all bonded validators, proportionally to their stake.

referring to rewards provided to all bonded validators whether they voted or not correct? (may be worth making the bullet point more explicit for this)

---

My only comment on this mechanism is I would suggest that we keep the possibility of downtime slashing intact, even if we choose to not include in in favour or downtime jailing exclusively. - I'd recommend that we keep downtime slashing over large downtime jailing periods - as the opportunity cost for being jailed will likely be a large cost to validators (and hard to quantify) over downtime slashing. I'm not totally sure what the balance should be - but I imagine having both as available options is useful to the network.

The goal for downtime slashing has often been to wean out crappy validators, even if they have a lot of stake... it's possible that this can be accomplished using only inflation rewards as proposed - however that may not be as an extreme mechanism as desired by the network - not to mention that the different validators will react differently to use of a carrot vs. stick

[cwgoes]

Well written @cwgoes clap generally in agreement with the approach, I'm not totally positive on the parameterization, however 10% doesn't seem totally unreasonable

Sure; I'm not arguing for a particular parametrization, that seems like it should be determined a bit more experimentally.

(1 - proposerReward - signerReward - communityTax) percent to all bonded validators, proportionally to their stake.

referring to rewards provided to all bonded validators whether they voted or not correct? (may be worth making the bullet point more explicit for this)

Yes - so clarified.

My only comment on this mechanism is I would suggest that we keep the possibility of downtime slashing intact, even if we choose to not include in in favour or downtime jailing exclusively. - I'd recommend that we keep downtime slashing over large downtime jailing periods - as the opportunity cost for being jailed will likely be a large cost to validators (and hard to quantify) over downtime slashing. I'm not totally sure what the balance should be - but I imagine having both as available options is useful to the network.

The goal for downtime slashing has often been to wean out crappy validators, even if they have a lot of stake... it's possible that this can be accomplished using only inflation rewards as proposed - however that may not be as an extreme mechanism as desired by the network - not to mention that the different validators will react differently to use of a carrot vs. stick

Downtime slashing is compatible with this proposal. I somewhat doubt it will be necessary - I think rewarding directly for signatures will be enough of an incentive - but having the option doesn't hurt.

[joepindar]

I agree with what you are saying from a rational and logical point of view. However as a validator we understand that not all delegators are rational or logical - either permanently or depending on the situation. Which is why standard investing behaviour topics such as Loss Aversion are significant.

Which fundamental assumptions do you think it would change?

Focusing on 'maximizing token rewards' is functionally equivalent to focusing on revenue from a validators viewpoint, however validators are more concerned with profit. Removing downtime slashing means the cost portion of the profit equation is no longer impacted by downtime. This opens the opportunity for an aggressive cost minimisation strategy (e.g. not running a HA validator configuration) which delivers a benefit for the validator (more profit) at the expense of network stability.

Downtime slashing is compatible with this proposal.

I welcome keeping this as an option and actively discussed.

[melekes]

Would it make sense to add numberTxs to proposerReward * fractionPrecommits resulting in proposerReward * fractionPrecommits * numberTxs once we have no-empty-blocks feature?

[osolmaz]

Proposers are rewarded regardless of whether or not their block includes any transactions, so rational proposers will elect to propose empty blocks,

This would happen when there are no transaction fees right?

I'd think users who want their transactions to be included would attach fees that are higher than the marginal cost of including a transaction. That would give us the baseline fee for when the blocks aren't full. This way, rational proposers would elect to include them.

So it seems to me that the sentence above denies the existence of the fee market. Or am I missing a detail?

[cwgoes]

Proposers are rewarded regardless of whether or not their block includes any transactions, so rational proposers will elect to propose empty blocks,

This would happen when there are no transaction fees right?

I'd think users who want their transactions to be included would attach fees that are higher than the marginal cost of including a transaction. That would give us the baseline fee for when the blocks aren't full. This way, rational proposers would elect to include them.

So it seems to me that the sentence above denies the existence of the fee market. Or am I missing a detail?

I agree - my point is that proposers will propose empty blocks right now, because they get the inflation from the proposer reward, but we probably shouldn't reward this because empty blocks are actually a negative externality - they consume space and don't execute anyone's transactions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.