Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: alter uptime & precommit inclusion incentives #3529
(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.
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:
Current distribution scheme
Presently, we pay collected fees and inflation at the beginning of each block as follows:
I argue that this scheme partially fails at (1), fails at (2), succeeds at (3), and partially succeeds at (4).
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).
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:
Slashing would be altered:
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.
For the Hub to succeed in incentivizing both (2) and (3), a particular relation must hold between
The block proposer receives rewards proportional to:
The proposer chooses
We want this to be positive:
Setting the worst-case
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
This was referenced
Feb 7, 2019
There are generally two cases of downtime jail.
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.
I may not be reading this correctly, but I don't see an explanation of why slashing is removed.
"Validators who miss
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.
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).
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.
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.
Well written @cwgoes
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
Sure; I'm not arguing for a particular parametrization, that seems like it should be determined a bit more experimentally.
Yes - so clarified.
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.
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.
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.
I welcome keeping this as an option and actively discussed.