Yeah, so the idea would be, that a validator client can connect to one or more beacon nodes.... the reason you may want to do this is because, the validator client knows about a few keypairs.. lets say 5.... Of those 5, the validator client asks the beacon node: "hey mate.. when do these validators need to propose blocks or attestations".. the beacon node will be like "in 10, 12 , 15, 18, and 20 seconds".... then at those time intervals, the validator client will ask the beacon node... "can you give me a block to sign"... beacon node is like "yep, here"... validator client, for the validator in question, signs the block and gives it back.
Now, as a validator client, you have money at stake. If the beacon node gives you the wrong block, or the beacon node is wrong about which times you are supposed to do things, you will lose money. So if you have a beacon node that is intentionally or unintentionally misbehaving, you will lose money.
For this reason, it's potentially a good idea to have a second beacon node running (or an online service that runs another beacon node for you) so that if one goes down, or misbehaves, you can use the other to continue voting and not lose money
beacon_nodeto be a node on the network. A
beacon_nodeis in charge of storing the state and most of the vairables. A
validator_clienthowever would be required if you want to produce new blocks and contribute to the network