At the moment, we have an architecture of a Beacon Node (BN) that does all networking, fork choice rule, state transition etc. work and a Validator Client (VC) whose very simple role is to keep the validator key and make sure that it doesn't sign any slashable messages. This is possible because slashable messages are very easy to determine, as they only consist of signing two blocks at the same height or violating the FFG attestation rules.

However, in the coming phases, we will add more slashing conditions:

• Signing attestations with invalid custody (phase 1)
• Signing shard blocks with invalid state transitions (phase 2)
• Signing eth1 blocks with invalid state transitions (phase 1.5)
• Signing beacon blocks with invalid state transitions (?)

In order to be able to provide slashing protection the VC needs to include all the state transition logic. To also be able to prevent slashing due to invalid beacon chain transition, we either need a stateless beacon chain (That I think is unlikely) or the VC needs to be able to hold the beacon chain state. This will add a lot of complexity to the VC and a large part of this is duplicated from the BN.

Currently I see the following possible alternatives for the BN/VC architecture split:

1. Fully maintain the current VC "no-slash" guarantees, meaning that the VC will have to validate all of the above properties
2. Change the VC/BN relationship to a trusted one; the VC is guaranteed to keep the key, but it cannot guarantee protection from slashing if the BN is bad
3. Decide that safe and easy staking is more valuable than the additional guarantees we get from fraud proofs.