sigp/lighthouse

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 👍

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?

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

What you are looking for is https://developers.google.com/web/tools/lighthouse/
What this project is: https://github.com/sigp/lighthouse

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]

Where communities thrive

People

Repo info

Activity