hey @jzaki :)
Cases<T> is a wrapper around a
T implements the
YamlDecode traits. The types that
T can be instantiated to each have a file in
tests/ef_tests/src/cases, and each implement
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
YamlDecode, so I want you to use its
YamlDecode implementation to decode the test cases, and then run them with the
EfTest implementation for
Hope that makes sense!
"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?
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