Add validator slashing information to event stream

[mehdi-aouadi]

The slashing events could help the validator determine whether at least one of its keys has been slashed and let it act accordingly (suspend VC requests, shut down, raise warnings...). This could be particularly useful to prevent massive slashing events when a VC runs multiple keys.
The massive slashing event that happened on November 14th 2023, at epoch 242546 is a good example. It caused 99 validators to be slashed (99 ETH loss approximately). They were all newly spun up validators and this could have been prevented by stopping the VC which is running all the keys after the first slashing event.
This was initially raised by mariano.eth

The suggested event would be:

• Event: slashed_validator
• Data: {"pubkey": "0x...."}

I'd like to have your opinion on this before raising a spec PR.

[mcdee]

There are already tools to track slashing events based on the existing beacon chain APIs e.g. https://github.com/attestantio/esd Not sure that having a separate event would make a significant difference in terms of ability to deploy such tools.

[tersec]

To an extent, I'm not sure how much the protocol should effectively subsidize these staking pools (BTCS in this case) which know 100% perfectly well the risk they take. Mass slashing events happen precisely when staking pools, or similarly typically professional Ethereum entities, become overconfident in their key and signing management and ability to juggle loading keys across multiple machines.

I'm not going to strongly oppose this as such; it's in isolation harmless and defensible, as is e.g., prysmaticlabs/prysm#13194 or Consensys/teku#7707. However, it's an acceptance of allowing BTCS and its ilk to externalize effectively a cost of business on the ecosystem as a whole.

This slashing did not particularly hurt Ethereum as a whole. It hurt one particular node operator, and that's the exact gamble they took, and lost.

Longer-term, DVT will provide a better solution to this, and largely obviate this issue.

[mehdi-aouadi]

There are already tools to track slashing events based on the existing beacon chain APIs e.g. https://github.com/attestantio/esd Not sure that having a separate event would make a significant difference in terms of ability to deploy such tools.

Thanks for the heads-up I wasn't aware such tool exists. I was more thinking of a built in feature (that could complement the doppelganger detection). The difference here would be the ease of use plus IMO adding a separate event wouldn't do any harm

[mehdi-aouadi]

To an extent, I'm not sure how much the protocol should effectively subsidize these staking pools (BTCS in this case) which know 100% perfectly well the risk they take. Mass slashing events happen precisely when staking pools, or similarly typically professional Ethereum entities, become overconfident in their key and signing management and ability to juggle loading keys across multiple machines.

I'm not going to strongly oppose this as such; it's in isolation harmless and defensible, as is e.g., prysmaticlabs/prysm#13194 or Consensys/teku#7707. However, it's an acceptance of allowing BTCS and its ilk to externalize effectively a cost of business on the ecosystem as a whole.

This slashing did not particularly hurt Ethereum as a whole. It hurt one particular node operator, and that's the exact gamble they took, and lost.

Longer-term, DVT will provide a better solution to this, and largely obviate this issue.

I agree that the protocol shouldn't fully subsidise staking pools risk taking. IMO the BTCS's incident shows that solo stakers could be at risk too and would benefit from such a feature. Even with few keys the risk still exists and could be even harder to swallow for non professional stakers. The main goal here would be to minimise the slashing impact for everyone.
Otherwise +1 for DVT longer term.

[rolfyone]

There are already tools to track slashing events based on the existing beacon chain APIs e.g. https://github.com/attestantio/esd Not sure that having a separate event would make a significant difference in terms of ability to deploy such tools.

I think the point of difference is it makes it easy for the VC to get access to which pubkeys are getting slashed... Currently that's a little non trivial.

[dapplion]

• This is a less opinionated implementation for the same goal, just expose slashable messages received via p2p Add proposer_slashing and attester_slashing to SSE #376

The above implementation is fairly un-opinionated, it just extends SSE events to include more block operations

Operations as of deneb

deneb.BeaconBlockBody operation	SSE event name
proposer_slashings	proposed support #376
attester_slashings	proposed support #376
attestations	attestation
deposits	not supported
voluntary_exits	voluntary_exit
bls_to_execution_changes	bls_to_execution_change
blob_kzg_commitments	blob_sidecar