Incentive parameters

We have a couple of tasks that a validator is expected to accomplish:

• Vote on the source
• Vote on the target
• Vote on the head
• Vote in a timely fashion (or at least, get included in a timely fashion)
• Download crosslink data (bit challenge game)
• Keep custody of crosslink data (chunk challenge game)
• Keep their key private (early reveal game)

We can consider them from two angles:

• Microeconomics/relative rewards: how rewards tally up with respect to each other, whether they incentivise an honest rational behaviour.
• Macroeconomics/absolute rewards: the “magnitude” of the rewards.

See also annotated spec and design rationale.

Microeconomics

Assuming validators are rewarded additively (one weighted reward for each task accomplished), we know the feasible set for the coefficients associated to each task. For instance, we might expect that any reward $r > 0$ is sufficient to incentivise validators to vote correctly on the FFG data (source/target). For others, the feasible set is more complex, e.g., the bit and chunk challenge games.

Yet we know that some couplings/interactions exist between these tasks:

• The correctness of any of these tasks is basically ignored whenever the source is incorrect. A recent proposal suggests to get rid of the source reward.
• It is rational for an attester to sometimes trade off timeliness (deviating from the honest spec) against correctness (waiting for the correct head), see e.g., this notebook
• others?

Thus, when attributed linearly, the rewards for these tasks can fail. For instance, one might want to condition the inclusion delay reward on the correctness of the head to avoid the deviation presented above. Additionally, a validator can still get a pretty good return while not performing all its functions.

More generally, with the increasing number of tasks that a validator is expected to perform, we are looking for a principled approach to setting the rewards.

If we look for an optimal way to do so, we need to define what we are actually trying to optimise for. Ideally, we want the punishments to be gradual, with the order:

• Honest validator (no punishment)
• Honest validator who makes an honest mistake (low punishment)
• Censored validator (perhaps equally punished as honest mistaking)
• Lazy validator (some more punishment)
• Malicious validator (the highest punishment)

An optimisation approach would account for the levels of punishment required by each type of validator.

See also

• A proposal to make the end of inactivity leak less sudden

Macroeconomics

A recent report stressed the low yields for DIY, hardware-based validators (arguably the biggest contributors to overall decentralisation) at low values of ETH price. Meanwhile, validator infrastructures with larger economies of scale (e.g., exchanges running several thousand validators) are more robust to such macroeconomic factors. The recommendations of the report include:

• Tuning up the size of the rewards by doubling the BASE_REWARD_FACTOR parameter.
• Allowing the protocol a path to updating the parameters of the rewards, e.g., the BASE_REWARD_FACTOR. The value of BASE_REWARD_FACTOR could also be tied to e.g., the length of the exit queue, triggering an increase in reward size when many validators want to exit, or tying its value to the total ETH staked.

We could attempt a model of the different validator populations following evolutionary game theory tools. This could help stress the centralising forces as well as analyse long term distributions of validators among the various populations. It also opens the door to simulations.