It has been quite some time since our last Lighthouse update and as you'd expect there is a lot to cover. In fact, there have been too many significant updates to the client and protocol than I could reasonably spend time covering here. Instead this post will simply focus on the pretty major client (and spec) upgrades that have been recently released (v4.3.0).
Subnet Backbone Revamp
For those of us running Lighthouse with a few validators on small scale devices (like Raspberry Pis), you may have noticed the poor machine's fan struggling to cool the device. The resource use of your device primarily comes from the fact that validators on the network are required perform various duties, in particular attesting to blocks and checking other's attestations to blocks are correct. The latter part is the most resource intensive, both for the CPU and network bandwidth. As the number of validators on the network increases (we are currently approaching 700k active validators) the demand on the individual node also increases.
It has always been the case, that the number of validators you have attached to your beacon node is directly proportional to the amount of "work" your node must do for the greater good of the network. So a node with lots of validators uses lots of resources compared a node with no validators which does very little. This may sound intuitive, except the "work" that I'm referring to is not work that helps your attached validators, rather its "work" that only benefits the network as a whole. In other terms, only beacon nodes with attached validators are consuming resources to keep the network going, rather than every participant. The more validators, the more philanthropic work.
Here are two (relatively dated) graphs, one which shows how the bandwidth of a node changes with number of attached validators and one which shows the distribution of beacon nodes with attached validators on mainnet.
The bandwidth of a lighthouse beacon node vs the number of attached validators.
The distribution of validators on mainnet by the number of attached validators.
The y-axis is simply the count of beacon nodes with the number of attached
validators.
I wont go into the technical reasons behind why this is the case, rather just point out the fact that there are (or used to be) a lot of beacon node's that don't have any validators attached to them (or at least that's what they are telling us). These beacon nodes (which are the majority > 50% of nodes) are not contributing to this philanthropic "work" at all, rather leaving it all to the nodes that have validators.
We (the Ethereum community) recently decided it would be best to decentralize this work load. Instead of just having validators keep the network afloat, we have updated Lighthouse to do a fixed amount of "work" regardless of how many validators are attached. This means a few things. - Nodes with a few validators, will now consume less resources (CPU and bandwidth). The greater the number of attached validators the greater the performance savings. - Nodes that previously were not contributing to the up-keep of the network, now also participate, distributing the work. - In order to maintain a healthy network, we should keep a high peer count.
With these changes, the bandwidth per validator graph should now look like the green line in the following updated graph.
Indeed, after our v4.3.0 release, a few of our users were quite happy with the results, posting their bandwidth reductions:
We can also see the effect this release has had on the beacon node distribution on mainnet. Once all nodes on the network upgrade to this new format of handling the load, the distribution graph should show all nodes appearing to have 2 attached validators. A quick mapping of mainnet as it stands today shows a shift from nodes with 0 attached validators (i.e contributing no work) to appearing to have 2 attached validators (the new default). Note the y-axis represents the percentage of beacon nodes measured.
For those more technical minded readers, the specification changes is a good reference for the rationale behind these modifications.
It should be noted these changes are not without cost. We are actively monitoring the networks to ensure it remains healthy under these changes which all clients should eventually adopt.
The end-result, if you are running validators on a Lighthouse beacon node, upgrading to v4.3.0 may save you some significant resource uses.
IPv6
As of v4.3.0, Lighthouse and the Ethereum network can now support Ipv6. Although this support may sound trivial, it was quite a journey to upgrade all of the lower protocols we use to also support ipv6 in a way that is maximally compatible. We have also upgraded our Lighthouse bootnodes and added some more which support ipv6 giving access to ipv6 users to the Ethereum network as a whole. Although we technically support ipv6-only nodes, we do not recommend using ipv6 only at this time, simply because there has not been enough time for other ipv6-compatible nodes to join the network and support connections.
We encourage all users capable of running a dual-stack setup to start trying out this new feature. The more dual-stack nodes we have in the network, the greater support we will have for ipv6-only nodes.
There were a number of user-facing commands and intricacies that came up in this process. For those interested in this feature, we suggest reading the new ipv6 documentation we have added to our book to explain some of the nuances that ipv6 and dual-stack setups bring to the configuration.
The Future
In the very near future, we're hoping to add some more significant bandwidth gains which will come in the form of a new UDP-based transport called QUIC. We intend to trial run this transport as a Lighthouse <-> Lighthouse connection, to avoid having the specify the transport amongst all clients. If the results of this experiment show drastic results we can propose these changes to other client teams to hopefully gain further reductions and have all consensus clients running as light-weight as possible.
Summary
Lighthouse v4.3.0 has some interesting networking upgrades which hopefully significantly helps all of our users and maintains a healthy Ethereum network.
The community and the Lighthouse team are consistently flat-out upgrading the network and some of the research and proposed changes to underlying protocols that could likely be released in the next few months, should also bring some decent performance gains ahead of the Deneb hard fork. These research ideas originate from the design goal that Ethereum should be able to handle multiple millions of validators easily on its network without overloading your simple home-staking Raspberry Pi.