proposeBlockV3 consensus block value.md

proposeBlockV3 consensus block value

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() and decrease_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 using produceBlockV3, simpler block selection mechanisms in certain cases. Disadvantages include making more difficult coherence between the less specified consensus_block_reward for which little published constraint exists and getBlockRewards 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 underlying proposer_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.