,
19 tweets,
7 min read
Read on Twitter
So what does an #eth2 beacon node actually do, in practice? Well, here's a tweet storm to find out. We'll follow the logs of a node backwards, just like following a block chain that effectively is a singly linked list going back in time. Reverse engineering, like :)
The beacon node establishes the current head of the list effectively by voting, or attesting, as it's called here. Time progresses in slots, and for every slot, we broadcast and collect votes. Several nodes are voting for block B9F2ED1F, us included. 
Apart from the head block, rewards will be handed out for getting a few other pieces of data right - including nailing justification as per Casper: ethresear.ch/t/beacon-chain…. 10 validators connected to this node, but only 3 are voting this round - it's split by shard.
Where did the block come from? Well, we received it from the network, resolved it by linking it back to a parent we know about and validated it by applying it successfully to the state of that parent - it is now a candidate for head selection!
Why select this block, and not another? To find out, we go back to the latest justified block and run a vote count, or fork choice, on all its descendants. We'll do this when we're about to attest or propose a new block capturing that moment in time using the best info available.
Thus, going back to the block B9F2ED1F, we see how its parent is D1EA5A6B - just before we received it, the parent was being voted on. Looks like it won the election this time around.
Sleep, eat, work. Repeat. Boring life. See the time stamps? Roughly 6 seconds between each block. Also on display the joy of distributed systems - there's a new block, but we're still getting votes for its parent. Sometimes it's sleep, eat, work, yesterdays work.
It's all very stressful. There's a tight schedule to follow, and you might fall behind, specially during the heavy epoch processing which is done every few slots. Good news though, we managed to finalize an epoch starting at slot 5152 when updating the head.
Fork choice starts from the most recent justified block we know about, based on head candidates we've received so far - when we select a new head, that might feed back into selecting a new finalized block, and therefore throwing out some previously viable justified candidates.
Of course we also get a few seconds of fame when we have to produce a block. Notice there's only 1 attestation in there? It's the magic of BLS aggregate signatures allowing us to combine all identical votes - more validators can participate without chain bloat!
It's the internet and there's plenty of fake news out there (or bugs in this case). Fortunately though, we're validating things and voters are intelligent enough to ignore the noise. What a beautiful world - everyone keeps voting for the previous holder of the seat.
Each beacon node can serve multiple validators - how many depends on its resources - for each validator there's an additional shard to sync and maintain - that's where the real action will be happening: contracts, accounts, etc. Small chains are easier to demo however 😀
Underneath everything is a peer-to-peer network over which blocks and attestations are broadcast and where peers can ask each other for anything they missed. Nodes connect to each other, sync up and start working.
The state transition we looked at last time (we've since updated to spec 0.4.0) is a small but important part of the full beacon node - check that out as well:
You can get a closer look at these logs real easy from the comfort of your own computer - networking, fork choice, blocks, attestations etc - by running the beacon node simulation you'll find here: github.com/status-im/nim-… - a personal #eth2 testnet!
Trouble? Reach us very secretly via @ethstatus! get.status.im/chat/public/st…
Or via matrix: chat.status.im/#/room/#nimbus…
Or via gitter: gitter.im/status-im/nimb…
Or via Tel... 👊 ouch 🗡 noooo 💥 aaaaaaaaaaaaaaaaaa ☠
