Proposer penalties

[JustinDrake]

Do we want to apply a penalty to the proposers of empty slots? I'd argue we do:

• With attestations proposer censorship (and the corresponding discouragement vector) is significantly reduced.
• There's little incentive for lazy proposers to participate in block proposals.
• A significant amount of the complexity of validator software is block formation, so lazy implementers could skip it altogether.
• Making sure lazy validators participate is important for various reasons. One of them is having a healthy RANDAO.

[djrtwo]

(1) Agreed, censorship is a lot more difficult with attestation based fork choice.
(2) Note that we do provide a proposer reward for including attestations.
(3) I'd expect block proposal to happen inside a client and a validator asks for get_block_proposal(slot) from the client. If the client does not provide this feature, then almost assuredly validators will not use their client.
(4) agreed, but not sure the dis-incentive is necessary.

I lean toward not penalizing empty slots. The honest and rational validator wants a healthy network that is continually finalization and progressing. I think this plus the positive rewards for creating a block are incentive enough.

[vbuterin]

Isn't adding proposer penalties equivalent to increasing the proposer reward and decreasing the other rewards? That seems like the easier way to implement it.

[JustinDrake]

Closing in favour of #675. I think we settled on increase the relative proposer rewards 👍