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
    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 👍
    gzuhlwang
    @gzuhlwang
    hi, guys. I fix good first issue #421.
    Age Manning
    @AgeManning
    Thanks for the input! We'll review it today :)
    Diederik Loerakker
    @protolambda
    If someone has the time (and online :earth_asia: ), could you please take a look at ethereum/eth2.0-specs#1311 and send me a survey response? (or just a few suggestions, anything helps)
    John Adler
    @adlerjohn
    When building with --all-targets (i.e., cargo build --all-targets) I get a bunch of errors, that don't pop up without that flag. Are those expected?
    Paul Hauner
    @paulhauner
    Yeah, it’s probably some benches failing. We’ll clean those up soon :)
    Paul Hauner
    @paulhauner
    We've just merged v0.8.1 into master! Yay!
    I'm going fix those --all-release issues :)
    Paul Hauner
    @paulhauner
    Hey all, following suit from the EF, we now have a Discord! https://discord.gg/cyAszAh
    We'll setup a bridge at some point, for the time being I'll watch both of these but I recommend using the Discord instead.
    Diederik Loerakker
    @protolambda
    Awesome
    rytikovroman1994
    @rytikovroman1994
    Hello everyone, I have a problem.
    lighthouse does not work well in the cycle.
    Checks one link, and already on the second strongly to slow down.
    Someone faced with such problem?
    image.png
    image.png
    Paul Hauner
    @paulhauner
    Hey, I think you might have the wrong lighthouse. This one is an Ethereum 2 implementation
    rytikovroman1994
    @rytikovroman1994
    what do you mean?
    did I set something wrong? Or not the chat?
    Diederik Loerakker
    @protolambda
    thojest
    @thojest
    congrats for receiving grant :)
    Paul Hauner
    @paulhauner
    Thanks @thojest!!
    Andrew Quentson
    @Aquentson_twitter
    Hi, are we expecting an eth2 testnet launch this week?
    Age Manning
    @AgeManning
    We are debugging and experimenting interoperability between clients. There are a number of stages to this. It's unclear if a long standing multiclient testnet will be made at the moment
    Paul Hauner
    @paulhauner
    [for the record: inapproriate comments were reported and are no longer visible]