hey @jzaki :) Cases<T> is a wrapper around a Vec<T> where T implements the EfTest and YamlDecode traits. The types that T can be instantiated to each have a file in tests/ef_tests/src/cases, and each implement EfTest and YamlDecode. Wherever run_test is called, the compiler can't infer the type T automatically, so we provide it manually like: run_test::<OperationsExit<MinimalEthSpec>>, which says: "I think OperationsExit<MinimalEthSpec> is a valid choice of T that implements EfTest and YamlDecode, so I want you to use its YamlDecode implementation to decode the test cases, and then run them with the EfTest implementation for OperationsExit"
Hope that makes sense!
https://youtu.be/J6xO7DH20Js?t=277
- It deals with signing messages -- from a systems design perspective, it's generally nice for private keys to be held in small, separate components.
- It provides a degree of failure safety -- if the validator is a separate component it can try and detect if a beacon node is faulty and swap to another one.
"The VC (Validator Client) is capable of managing multiple validators in the same process tree." - https://github.com/sigp/lighthouse/tree/master/validator_client
From the Eth2.0 Specs point of view, does "validator"/"validator node" refer to the same thing?
A validator client is the software that essentially does the signing for various validator duties (i.e proposing blocks and attesting). A validator in the spec, refers to a single BLS keypair that is staking on the beacon chain. The validator client is capable of managing arbitrary many such keypairs. So you could be 10 validators (have 10 keypairs) and the validator client will connect to a beacon node, ask when each validator is supposed to attest or propose a block, then perform the signing for each validator.
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_node to be a node on the network. A beacon_node is in charge of storing the state and most of the vairables. A validator_client however would be required if you want to produce new blocks and contribute to the network