Here's why you should consider switching to Lighthouse, for yourself and the good of the network.
Introduction
With Ethereum's transition to proof of stake, we have a unique opportunity to attain client diversity thanks to the existence of 4+ robust implementations of the beacon chain.
However, as we've seen this last weekend, that diversity is at risk due to a concentration of validators relying solely on the Prysm client. A bug in Prysm prevented Prysm validators from proposing any blocks, reducing the number of blocks proposed in some epochs to 7 out of a full 32 (e.g. epoch 32303).
Prysm is a great client, and it has clearly succeeded in capturing the hearts and minds of the community. In this post, we'd like to promote Lighthouse as an alternative to Prysm — one that performs just as well, while offering unique features and fostering client diversity.
Lighthouse TL;DR
If you're not familiar with Lighthouse, here's a quick summary:
- 100% open source. Apache 2.0 license.
- Built by Sigma Prime, a blockchain & infosec firm based in Australia with employees worldwide.
- Implemented in Rust.
- Rich feature set for both home stakers & pools.
- Top-tier validator performance & profitability.
- High efficiency, low resource consumption.
- Focus on correctness and security.
In the next few sections we'll dig into each of these points in more detail.
Features Features Features!
Lighthouse offers many of the features that stakers have come to expect from a client:
- Metrics for monitoring validator & node performance, via the lighthouse-metrics package (Prometheus + Grafana).
- HTTP API for queries, compliant with the Eth2 standard API.
- CLI options for configuring data directories, network ports, graffiti, etc.
- Separate validator client and beacon node binaries.
Additionally, it also includes a few features that set it apart.
Built-in Redundancy
Lighthouse supports redundancy for both Eth1 endpoints and beacon nodes. This means that instead of relying on a single Eth1 node for deposit information, it can utilise multiple — automatically falling back to a working node if a failure occurs. Redundancy for beacon nodes is even more exciting: a Lighthouse validator client can make use of multiple different beacon nodes, including beacon nodes from other clients. As an example, you could configure your Lighthouse validator to use its local beacon node by default, and fallback to a free Teku beacon node hosted by Infura. Even if a bug affecting Lighthouse's ability to propose blocks occurred, a validator using this setup would be able to continue proposing blocks via their secondary beacon node!
Most clients support Eth1 redundancy, and Prysm supports beacon node redundancy with Prysm beacon nodes, however Lighthouse is unique in supporting redundancy with another client (Teku). You can read more about the redundancy feature in the Lighthouse book.
Slasher
Additionally, Lighthouse is the only client other than Prysm to include a slasher. Lighthouse's slasher was the first implementation of an efficient min-max slasher, and was responsible for catching a spate of surround slashings on mainnet that Prysm's slasher missed (e.g. in block 17112). You can read about how to run the slasher in the Lighthouse docs.
Coming Soon
Finally, we are always working to improve Lighthouse and have several new features under development including a graphical user interface, weak subjectivity sync and doppelgänger detection.
Top-Tier Performance
Ok, so maybe we've convinced you that Lighthouse's feature set is competitive, but what about those sweet sweet staking gainz?
Lighthouse is competitive with other major clients when it comes to profitability, both for attestation and block production. As evidence of this, check out the leaderboard for the Prater testnet, where each client team has a roughly equal share of validators:
That's 40% Lighthouse in the top 10, from an approximate 20% share.
Mainnet is a little trickier to study due to anonymity, but if you look at the top of the mainnet leaderboard you'll almost always find some Lighthouse graffiti. At the time of writing, the one year ranking shows Lighthouse graffiti in positions 2, 4, 5, 6, 7 (with the rest of the graffiti client-anonymous). That's at least 50% coverage from a client with less than 30% of validators.
Our intention isn't to claim that Lighthouse is the absolute best based on this data, but to demonstrate that all of the clients are closely placed when it comes to profitability. The risk of client monoculture outweighs minute differences in profitability, and as a validator you place your own funds at risk by concentrating stake with a single client.
High Efficiency, Low Resource Consumption
Lighthouse runs well on medium-spec hardware like home desktop PCs and virtual private servers (VPS).
I run a mainnet beacon node at home on a Core i5 6600 from 2015, and Lighthouse uses between 2-4GB of RAM with CPU usage chugging along at around 25-50% of 4 cores (I am also running an Eth1 node on the same box). Disk usage for the database is around 15GB, and growing slowly due to Lighthouse's freezer DB design.
Independent benchmarks by Byzantine Fault recently showed that Lighthouse is a close second to Prysm when it comes to raw sync speed on mainnet, and faster out of the box due to the inclusion of the genesis state.
We also have a few interesting optimisations in the pipeline, including a tweak to the memory allocator that will reduce RAM usage by up to 70%.
Security Focus
Lighthouse is written with a focus on correctness and security, building on our team's background in cybersecurity and formal methods. We leverage the safety features of the Rust programming language, including customised lints to protect against panics and overflow in our consensus code.
Sigma Prime are also the primary developers of the Beacon Fuzz project for performing differential fuzzing of all the beacon chain clients. To date the project has discovered several bugs in all major clients, and with the help of the Ethereum Foundation we will continue to update it as the beacon chain moves towards its first hard fork (Altair) and The Merge.
How to Switch
Switching clients can be daunting, particularly with all the new commands to learn, plus the risk of getting slashed by accidentally validating with two clients simultaneously. If you need help at any step of the process please don't hesitate to reach out on our Discord Server.
In broad strokes, the sequence we recommend for switching is:
1.
Sync a Lighthouse beacon node. You can follow either of the wonderful guides by CoinCashew or Somer Esat. You can run Lighthouse on the same machine that you run Prysm, although you should keep an eye on CPU/RAM/disk usage when running both clients simultaneously. Syncing the beacon node might take up to 24h depending on your hardware, so you should keep validating using your current setup until it completes. Do not start the Lighthouse validator client until you have stopped the Prysm one, or you will get slashed (penalised and exited from the system).
2.
Once your Lighthouse beacon node has synced and you're satisfied that it's working, stop and disable the Prysm validator client (you can also stop the Prysm beacon node if you wish).
If you're using systemd and your service is called prysmvalidator, the
commands for stopping and disabling the service look like this:
sudo systemctl stop prysmvalidator.service
sudo systemctl disable prysmvalidator.service
It's important that you disable the Prysm validator as well as stopping it,
so that it doesn't start up again if you reboot. If you want to be really sure that
it won't accidentally come back you can move the Prysm wallet dir to a different location,
or disable the keys using --disable-public-keys key1,key2,...
3.
With the Prysm validator stopped, export its slashing protection history using this command:
prysm.sh validator slashing-protection export --datadir=/your/prysm/wallet --slashing-protection-export-dir=/path/to/export_dir
To be extra sure that your validator has stopped, you can also wait a few epochs and confirm that your validators have stopped attesting (check beaconcha.in or beaconscan.com).
4.
Follow the instructions from your guide of choice (or the Lighthouse book) to
import your validator keys into Lighthouse. Ensure that you use the same --datadir argument when
running lighthouse commands.
5.
Check that your keys are shown in Lighthouse:
lighthouse account validator list --datadir=/your/lighthouse/datadir
6.
Using the slashing protection history exported in step (3), import it into Lighthouse with this command:
lighthouse account validator slashing-protection import /path/to/export_dir/slashing_protection.json --datadir=/your/lighthouse/datadir
Replace /path/to/export_dir with the directory nominated in step 3. Prysm will have created
slashing_protection.json in that directory.
7.
Start the Lighthouse validator client using the instructions from your guide of choice.
All being well you should see your validator start to attest again!
If you want or need to switch back: stop the Lighthouse validator, export its slashing protection history (see CoinCashew), import the history into Prysm, and then start the Prysm validator.
As always, if you're unsure of the safety of a step, we recommend stopping and asking for help before continuing. We also recommend trying everything on a testnet before doing it for real on mainnet.
Conclusion
I hope this post has been educational for the staking community, and contributes to the broader discourse around achieving client diversity. Although we got lucky this time in that the chain was able to continue finalising, we may not be so lucky during the next incident.
In writing this post it's been nice to take a step back from the regular updates to look at the big picture. The Lighthouse team are proud of what we've been able to achieve, and are very thankful to you, the Ethereum community, for the support you've provided us. We look forward to continuing the journey together as Ethereum transitions to pure proof of stake consensus! 🚀
EDIT: Clarified that Prysm also supports beacon node redundancy, thanks Preston Van Loon for the correction.