Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    James Zaki
    @jzaki
    Is that still valid?
    Also trying to put beacon nodes in context - ethereum/eth2.0-specs#157
    Paul Hauner
    @paulhauner
    Not sure about notary.. definitely not in phase 0
    Beacon node/validator client is kind of like if you pulled the miner our of geth/parity
    Geth/parity would be the "beacon node" and the miner would be the "validator client"
    the reason it's separated is:
    1. It deals with signing messages -- from a systems design perspective, it's generally nice for private keys to be held in small, separate components.
    2. 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.
    James Zaki
    @jzaki
    That very last point about swapping to another beacon node. What are the beacon assumptions for phase 0?
    Would it be possible to have a say 20-30minute whiteboards session this week to nut a few things out? It'll speed up the noob on-ramp article I'm writing :)
    Paul Hauner
    @paulhauner
    sure! does thursday or friday work for you? we can book a room at wework if you like
    James Zaki
    @jzaki
    That'd be awesome, Thursday. What time? Morning?
    Will DM email just send an invite whenever works for you
    James Zaki
    @jzaki

    "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?

    Age Manning
    @AgeManning
    Oh, that is an artifact from an older implementation.
    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.
    In an earlier version of the validator client, we had a validator binary for each validator... that has since been surpassed with logic that performs actions only when necessary given the validator keypairs it knows about
    James Zaki
    @jzaki
    Awesome cheers @AgeManning
    Where's the best place to read about the configuration of multiple beacon nodes maintaining the beacon state? (if indeed that question is correct).
    Age Manning
    @AgeManning
    yeah not sure I understand. Similar to Eth1. Multiple geth nodes maintain the same eth state. Multiple beacon nodes should agree on the same beacon state
    James Zaki
    @jzaki
    Cool, thought so. And that's outside the Phase 0 spec?
    Age Manning
    @AgeManning
    If you are talking about load-balance beacon nodes for a validator client, we haven't gone down that path yet
    James Zaki
    @jzaki
    So the idea is to get to a point of one beacon client (one beacon node) running, and one or more validator clients connecting to it?
    Just wanting to iron out this terminology for the intro doc.
    Age Manning
    @AgeManning
    A consensus mechanism it what allows multiple nodes to agree on the same state. Ethereum 1 uses PoW. We are using PoS. The justification and finalization is an adaption of the casper paper: https://arxiv.org/abs/1710.09437
    James Zaki
    @jzaki
    Yep, I think I'm clear with that with regard to blocks, ie from beacon state and down (validators etc). I guess I'm missing something around beacon node(s)?
    Age Manning
    @AgeManning
    The beacon chain employs a PoS consensus, where validators vote on blocks. Nodes agree on most votes via LMD GHOST.
    Yep, so if one node knows about block/slot 10 (which contains the beacon state) and another node knows about a different block/slot 10... they need to decide on which one is correct (i.e who has the correct state). They choose the one that has the most votes, basically.. then both nodes will agree on the same block/state
    Age Manning
    @AgeManning

    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

    James Zaki
    @jzaki
    Thanks, I'm all good with the part from a single beacon node down, it's just the idea of one or more beacon nodes sharing state (ie validator lists, balances etc). I think I'm missing something obvious there.
    James Zaki
    @jzaki
    Also one point from above, you mention that the beacon node gives a new block to the validator client to sign (by nominated validator in committee for the slot). So is it such that the beacon nodes are assembling blocks from transaction pools (like miners in current eth)?
    Age Manning
    @AgeManning
    Yep. Pretty much all logic is in the beacon node. Think of the Val client as a simple signing service
    James Zaki
    @jzaki
    For now I'll assume that multiple beacon nodes magically share common "active" and "crystallised" beacon state data.
    Age Manning
    @AgeManning
    A beacon block has a state root. So if nodes agree on the same block they agree on the same state
    James Zaki
    @jzaki
    Ah, that link helps pin things together. Thanks for your help, I'll save further questions for next time :)
    Age Manning
    @AgeManning
    Cool, hope it helped :)
    James Zaki
    @jzaki
    A quick terminology question:
    Is a running instance of a "beacon node" or a "validator client", a "node" on the network?
    James Zaki
    @jzaki
    Similarly does a "client" implementation refer to both beacon nodes and validator clients?
    Kirk Baird
    @kirk-baird
    Yep, a client implementation would refer to both beacon node and validator client
    Technically you could just be running a 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
    James Zaki
    @jzaki
    Thanks @kirk-baird, and is a validator client also considered a node from a network point of view?
    Paul Hauner
    @paulhauner
    Not from the network point of view -- we have been very deliberate in not connecting the validator client to the p2p network
    A beacon_node with a validator client attached could be considered a "validating node"
    James Zaki
    @jzaki
    Awesome, thanks. So the VC connects explicitly to a BN that it knows of, or discovers?
    Kirk Baird
    @kirk-baird
    Yep, you need to ensure that the Validator Client connects to a Beacon Node it trusts so you'd generally run them both together. You'd have one Beacon Node to communicate with all the other Beacon Nodes and a personal Validator Client which will connect to you Beacon Node.
    James Zaki
    @jzaki
    So going through steps:
    • a network has beacon nodes running (BN1, BN2)
    • a validator client, with predefined validator (V1), is run to connect with BN1
    • BN1 updates it's local Beacon Chain state to include V1
    • ???
    • BN2 Beach Chain state now contains V1
    Kirk Baird
    @kirk-baird
    Pretty much, I might just reword it slightly
    • Starting with a network of BN1 and BN2
    • VC1 connects to BN1
    • VC1 produces a block BlockA
    • VC1 sends BlockA to BN1
    • BN1 via networking shares BlockA with all other BNs (i.e. BN2)
    • BN2 now has BlockA and processes it
    Age Manning
    @AgeManning
    Probably should point out, a validator cannot just come along and produce blocks. They need to deposit eth on the eth1 chain and then wait for the global chain to accept and activate them as a validator before they can start participating in the network (all beacon nodes) will know they are validator before they can start doing anything
    James Zaki
    @jzaki
    @michaelsproul thanks for linking the spec issue 1269 with #407, might be a good first issue for me though. Will keep an eye on it for next week :thumbsup:
    Michael Sproul
    @michaelsproul
    I'm kind of hopeful that we get to keep the next epoch cache! But yeah, keep an eye on it and there will likely be something you can work on out of that :)
    James Zaki
    @jzaki
    Looking forward to focusing on code/issues next week :D
    Age Manning
    @AgeManning
    ^^ nice!! Well done
    James Zaki
    @jzaki
    Thanks mate 👍