Properties of issuance level: consensus incentives and variability across potential reward curves

Introduction

Thank you, yes, it is a good succinct summary. The suggestion of tripling penalties for source votes and target votes seems like a well-balanced way of preserving micro incentives if the issuance yield is reduced by a bit more than half at the present D and REV, e.g., an outcome somewhere in between 0.25<y_a/y<0.5. However, I do not believe that increasing penalties is the right approach for Ethereum to effectively “solve” the problems associated with failed micro incentives with an issuance curve that approaches zero (or negative) beyond some level. At the minimum, such a solution requires a rather substantial rebalancing of the micro incentives and increases analytical complexity. My response will explain why this is the case and why the post instead discusses a staking fee taken out each epoch as a means to retain relevant micro incentives if lower issuance yields are desirable: specifically, the staking fee promotes incentive invariance. I believe it can be useful to go into quite some detail in my comment since other researchers have made statements favoring zero rewards and increased penalties (outside of this forum). The purpose is to promote a good understanding within the Ethereum community of the complexities involved when shifting the relative magnitudes of consensus penalties and rewards.

It can be clarifying to start by reviewing specific attacks that can be executed when penalties and rewards are tilted to favor some specific consensus role, for example either the attester or proposer. Such attacks can arise or become more severe under a regime of increasing penalties. The reader may also wish to familiarize themselves with the concept of discouragement attacks, although the discussion will be kept at a basic level throughout this comment.

Minority discouragement attack against sync-committee attestations

There exist several (some undisclosed) minority discouragement attacks against present Ethereum. One of these is the censorship of sync-committee attestations by proposers. The proposer selectively censors sync-committee attestations, for example from a competing SSP, to profit under equilibrium by attaining a higher yield. The theoretical idea is that delegators of the censored SSP (or for that matter any attacked solo staker) may stop staking (raising the equilibrium yield) or shift over to the more profitable SSP (raising the income). The attack has a “griefing factor” of G=14. For every ETH that the attacker loses out on, the censored validators will lose out on 14 ETH. This happens because the attester loses out on 7 times as much ETH as the proposer when the attestation is not included, and additionally takes a penalty 7 times higher than the ETH lost by the proposer. It turns out that the attacker can then hold a rather small minority of the stake (but not insignificant) while still profiting from the attack (a discussion beyond the scope of this comment). The attack with an attacker in red and honest validators in green is shown in Figure 1 below.

AltairAttackSync

Figure 1. A minority discouragement attack against honest attesters in green by an attacking proposer in red. The attacker selectively censors the sync-committee attestations “(C)” of the honest attesters. Honest attesters then lose out on 14 times more ETH than the attacker, half due to the censored attestation and half due to the associated penalty (black cross).

While this attack is concerning in itself, the reality is that the threat of high out-of-band repercussions against an attacker makes the small and speculative profit rather irrelevant. So although it is desirable to rectify the issue, it is not system-critical at this point. However, relying on out-of-band recourses turns the proof-of-stake mechanism into a “proof-of-social alignment”/“proof-of-social slashing” mechanism. Ethereum should reserve such fallbacks to majority attacks, and always make it hard for small minorities to profit by diverging from the intended consensus process.

The reason for bringing up this attack is that a regime of penalties for retaining micro-incentives when rewards fall will obviously exacerbate the condition. If tripling the penalty for sync-committee attestations relative to rewards, the griefing factor would increase to 28. Such an increase would not be acceptable. With a zero reward (and zero penalty) for the proposer, any relevant penalty (or reward) for the attester gives an infinite griefing factor. The proposer loses nothing, and an economic pressure emerges on proposers to grief attesters, since they may be griefed themselves when the roles are reversed.

There are options for Ethereum to try to retain incentives for sync-committee attestations under a regime of increased penalties. One solution is to simply avoid reducing rewards for these attestations, but this would then not allow rewards to fall to zero. Another solution is to avoid increasing penalties for them as rewards fall, but then sync-committee attestations indeed become rather irrelevant. There was presumably a reason for giving them some weight in the first place. A third solution is to also give the proposer higher rewards for sync-committee attestations (but this is once again not commensurate with zero issuance) or to assign penalties to the proposer for missed sync-committee attestations. These solutions increase protocol complexity and the protocol may need to change between different regimes across the reward curve, etc. A staking fee instead allows Ethereum to retain the same relative micro incentives as today (or some other weighting) across the entire reward curve. The outlined solutions with an increased penalty can also increase relative reward variability for solo stakers under some circumstances (either in terms of penalties when offline or rewards when online and selected for special duties).

Minority discouragement attack during inactivity leak

Another example of a minority discouragement attack consists of attesters withholding attestations during an inactivity leak to spoil the proposer’s rewards for timely head attestations. Attesters do not receive rewards during the inactivity leak anyway, and must just ensure that the attestation is included within 2-5 slots to avoid penalties on the source vote. The griefing factor then becomes infinite. Even better, if the attester is assigned as proposer within 2-5 slots, it can pick up rewards for the attestation itself and will thus directly profit from the attack. The attack is illustrated in the figure below, once again with the attacker in red and honest validators in green.

AltairAttackWithheldLeak

Figure 2. A minority discouragement attack by attesters against the proposer in slot n+1. The attacker delays its attestation to spoil rewards for the proposer, instead picking up rewards for the attestation itself in slot n+2.

The discussion highlights how a consensus mechanism can unravel when rewards and penalties are altered without consideration for discouragement attacks under equilibrium. Interestingly, the motive for dropping attestation rewards during the inactivity leak was to prevent discouragement attacks in the first place (according to Edgington), but since the reduction was unbalanced between attesters and proposer, a new attack vector opened up. Minority discouragement attacks are something that Ethereum should rectify going forward and the topic will be further discussed in a forthcoming publication.

Balance between attester and proposer

As noted, the balance between the attester and proposer is a sensitive matter. The attester can withhold attestations if there are no incentives to attest, and the proposer can selectively ignore attestations if doing so hurts the attesters more than the damage inflicted upon itself (and if the attestations are not strictly necessary for making the block canonical). Shifting the balance between the attester and proposer can open up new minority discouragement attack vectors. A staking fee helps preserve an invariant balance between attester and proposer across the reward curve, significantly simplifying the analysis and design.

Head, source and target vote

The attestation containing a head, source, and target vote is somewhat more difficult to attack than the sync-committee attestation. Firstly, ignored attestations can be picked up in subsequent slots. This means that a single proposer who tries to inflict damage on the attester can only produce guaranteed losses on the head vote. To produce guaranteed losses on the source vote, the attacker needs to propose 5 slots in a row, and would require a 6th slot to pick up the stray target votes. This is a rather rare opportunity. But it is not exceedingly rare for larger SSPs, so penalizing the target vote more severely is preferable if penalties are taken to very high levels relative to rewards.

Regarding the head vote, adding penalties to it is a more sensitive matter, because the attacker then only needs to propose two slots in a row to first penalize an attester and then pick up leftover rewards. This makes it more cumbersome to retain the relevance of the head vote if rewards fall. If all rewards have been removed, well then it is a simple matter for the proposer of just not picking up the attestations (while ensuring that the block becomes canonical). The participation scaling of rewards will not deter such actions under equilibrium (and the relevance would also go to zero unless adjusted). To keep the head vote relevant in a design relying on increasing penalties and falling rewards is therefore rather complex; just as for sync-committee attestations using methods previously described. A likely solution involves penalizing the proposer for missing attestations in the proposed block or completely missed proposals instead of rewarding successful proposals. When variability for solo stakers then is calculated using some measure based on standard deviation (i.e., SD, RSD, SSD in the post), the solution looks very promising. Indeed, Ethereum could already reduce variability for solo stakers quite a lot by taking out a fee (perhaps slightly below the expected CL rewards) for any validator assigned to propose. There is however a question here about whether or not this is desirable. The solo staker who is unlucky and offline when assigned to propose can be left underwater for a very long time afterward (depending on how rewards are tuned). Generally, a negative skew of the yield PDF is less favorable, as discussed in the post.

Concluding remarks

This comment has been intended to illustrate the complexities of trying to retain consensus incentives using a regime of increased penalties as rewards fall toward zero. The point of course is that an elaborate reorganization does not fill a significant enough purpose, since the goal can also be achieved by instead taking out a staking fee. Under equilibrium and in the presence of REV, zero issuance and negative issuance have very little difference in terms of enforcing some specific D. If the intention is to allow Ethereum to achieve a guaranteed equilibrium at some specific level, then the staking fee is still needed. A fee allows Ethereum to construct an invariant system that preserves the relative size of the micro incentives when issuance is altered. The fee simply increases to reduce the yield.

However, in the absence of REV, this entire exercise is unneeded. This is one of the reasons why I find it desirable to avoid going to more extremes in the first place; to not implement a staking fee or make any significant changes to penalties. It is better to adopt the candidate reward curve and rely on a future MEV burn instead. However, your proposal of tripling penalties remains relevant, since it is so easy to implement and can come in handy with the candidate reward curve if MEV was to rise significantly. There are also other reasons for a moderate approach when adjusting the reward curve at this point, some discussed in Section 5.4. These will be further explored in future postings.

4 Likes