Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

sigp/lighthouse

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:

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.

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

aaand, It's out -> https://medium.com/@james.zaki/eth2-0-phase-0-basics-for-new-contributors-8a0a22bc38c7
Let me know what you think :)

Looking forward to focusing on code/issues next week :D

Age Manning

@AgeManning

^^ nice!! Well done

James Zaki

@jzaki

Thanks mate 👍