https://ethereum.github.io/beacon-APIs/?urls.primaryName=v2.5.0#/Validator/produceBlockV3 specifies returning a consensus_block_value
in Gwei
and https://ethereum.github.io/beacon-APIs/?urls.primaryName=v2.5.0#/Rewards/getBlockRewards specifies a total
field in Gwei
containing the block rewards for a given proposer_index
.
It is not clear whether or how it's specified unambiguously whether either or both of these should account for conditions which occur to the proposer index, in its role not as proposer but validator, that is, balance changes which result from the block but would have occurred due to a block from another proposer otherwise comparable contents. These include
- sync committee duty rewards or penalties
- proposer or attester self-slashing
- whistleblower rewards for proposer or attester slashing (in principle, one validator can be slashed, blow the whistle on its own slashing, and then self-include that slashing in a block it proposes, so these can interact simultaneously)
In order for produceBlockV3
and getBlockRewards
to provide interoperability, consensus layer clients should agree on how to interpret such conditions. Some options are:
- specify specifically the
proposer_index
increase_balance()
anddecrease_balance()
(practically, for block rewards, only the former) changes as relevant. That is, slashing penalties and sync committee participation rewards and penalties would not be included. Advantages include that it keeps a notion of "proposer reward" more tightly aligned with rewards specifically allocated to a validator in its role as proposer. Disadvantages include that it does not necessarily line up with actual validator balance changes as a result of a block (but then, for, e.g., epoch slots, this is seldom true regardless); and - include all these non-
proposer_index
balance changes, such as slashing penalties, whistleblower rewards, and sync committee participation rewards or penalties. This would amount to trying to match, for non-epoch slots, the balance change across that block for the validator which is a proposer, even including actions that would have been accounted for analogously regardless of whether that validator had proposed that block or not. Advantages include being more clearly related to observed balance changes, and for validator clients usingproduceBlockV3
, simpler block selection mechanisms in certain cases. Disadvantages include making more difficult coherence between the less specifiedconsensus_block_reward
for which little published constraint exists andgetBlockRewards
where specific underlying line items get broken out and that for validator clients which might want more customizability of whether to prioritize blocks with differing sync committee contributions, for example, they'd have to somewhat reverse-engineer the underlyingproposer_index
balance change portion.
In principle, produceBlockV3
and getBlockRewards
can pick criteria independently, but advantages exist for operating consistently with each other. Similarly, one could consider each non-core-proposer_index
part separately, perhaps arguing that sync committee contributions should be included but slashing penalties not, or vice versa.
Of primary importance, regardless of which set of approaches are pursued, is that they be consistent across consensus layer clients for beacon API users, including and especially validator clients.