Node should exit with a unique code on first slashing

[jakubgs]

Is your feature request related to a problem? Please describe.
Currently if a slashing occurs for one of the attached validators the node continues to run. I consider this behavior as inviting further slashings.

Describe the solution you'd like
The same way doppelganger detection returns a unique 129 exit code, so should the node the node exit - possibly with another code, like 130 - on first detected slashing. This is done in order to prevent any additional slashings.

Describe alternatives you've considered
None.

Additional context
The recent wave of slashings on mainnet that spanned a period of 10 hours shows that even bigger operators can fail to detect a slashing even in their setup and fail to prevent additional slashing if no engineer is available to stop the nodes.

I see no benefit in the node continuing to run after the first slashing, only great risk.

[cheatfate]

How beacon node should detect the slashing?
Does it need to exit process if it going to send slashing to the network or when it received new slashings in the block?

[tersec]

Multiple possible approaches:

• monitor the attester_slashing and proposer_slashing topics directly; and/or
• monitor the proposer_slashings and attester_slashings fields of BeaconBlockBody; and/or
• hook into slash_validator().

Hooking into slash_validator directly isn't great because it lives in the state trandition function and architecturally doesn't have direct access to the information it would need to to do this, but mentioned/acknowledged for completeness.

Monitoring the attester_slashing and proposer_slashing topics directly requires at least letting it run through the validation first. Practically, this means that it'd probably live somewhere in processAttesterSlashing() or processProposerSlashing(). This works fine for gossip messages, and is slightly quicker to pick up slashings before they get bundled into blocks, but doesn't work on backfilled or potentially reorged blocks which might not be processed by gossip at all.

Ultimately the one point in the architectural flow is the third option, monitoring the proposer_slashings and attester_slashings BeaconBlockBody fields, as part of block_processor or similar, at a point in the dataflow where req/resp and gossip have been unified, and also it's at a high-level enough (not the state transition function itself) where it has access to the validator pool and knows what the attached validators are and what the VC-run validators are.

[cheatfate]

In this case what should be done by VC?

[tersec]

In this case what should be done by VC?

I'm not sure the VC has a role in this -- it's fundamentally something that involves tracking the block application/state transition process.

That's not to say it can't work with VC validators: it can, in the same way as any other feature which needs to know which validators are relevant to the BN, e.g., by using action_tracker or some other mechanisms, but the actual detection firmly lives in the BN.