A story of activated slashing protection, and a saved validator... when everything works as expected, the execution and consensus clients each follow the chain hand in hand - however, when the EC starts falling behind, the CC show must go on or the network may stall.. well, .. ..this happened to a node operator that got a bit of a scare with an ugly warning appearing in their logs: it turns out the execution client had failed to validate a block and was struggling - on the consensus side, time kept ticking for several minutes until > 1 epoch had ...

Several people have noticed during upgrades that it's hard to find peers in #eth2 - there's a couple of reasons so let's go over them, but long story short, it's generally good and cheap for yourself and the network to set a high maximum peer count and allow incoming connections! #eth2 uses gossip to disseminate blocks and attestations - attestations make up the bulk as there are many, so in an effort to save bandwidth and processing, eth2 splits up the workload into 64 separate gossip channels based on committee assignment - aka subnet topics.

The medalla #eth2 testnet hasn't been finalizing for a while which puts some additional stress on clients as the number of possible valid chain histories, or branches, grows - here's what goes on in an @ethnimbus client in this case: * We use more memory - normally we hover around 500mb but memory consumption now goes up to 1-2gb: In each possible history, votes and validator assignments might be different - we keep a compressed in-memory cache of the most crucial information

Curious what goes on inside an #eth2 client? Let's take a look at some colourful boxes loosely depicting the @ethnimbus implementation.. #eth2 uses #libp2p to establish a peer-to-peer network - each node opens encrypted connections to other nodes using chronos and nim-libp2p, purpose-built networking libraries in @nim_lang, and multiplex several protocols like gossip and eth2/sync over that link using `mplex`

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.