sigp/lighthouse: an Ethereum consensus client in Rust

What Lighthouse actually is, and who ends up running it

Lighthouse is an Ethereum consensus client written in Rust and maintained by Sigma Prime. The README states it is ready for use on Ethereum consensus mainnet, which is the claim that matters: this is not a research prototype, it is software intended to sit on a machine and follow the chain. The audience is narrow and specific. Node operators who want to run a consensus client, stakers who need a validator client, and developers who need a local consensus node to test against. If you are building an application that reads Ethereum state, you probably want a hosted RPC endpoint rather than a consensus client, because Lighthouse does not serve that role on its own. The README also names the canonical staking deposit contract address, 0x00000000219ab540356cBB839Cbe05303d7705Fa, which tells you the project expects users who deposit and stake rather than merely observe. Funding comes from Sigma Prime, the Ethereum Foundation, Consensys, the Decentralization Foundation and private individuals, and the team says it is actively involved in the specification and security analysis of the proof-of-stake consensus specification. That participation is the reason to trust the client on fork boundaries, and it is also why the project tracks specification changes closely enough that the unstable branch exists.

The workspace layout tells you how the client is split

The Cargo.toml workspace listing is the clearest architecture document in the repository. It separates beacon_node, validator_client and account_manager as top-level members, with beacon_node further divided into beacon_chain, beacon_processor, execution_layer, http_api, http_metrics, lighthouse_network, network, operation_pool and store. That split is the data flow. Blocks and attestations arrive over the libp2p network layer, get processed into the chain and operation pool, and are persisted through the store. The execution_layer member is the seam where the consensus client talks to an execution client; Lighthouse does not perform execution itself. A separate consensus/ tree holds the state transition machinery (state_processing, fork_choice, types, merkle_proof), and crypto/ holds bls, kzg, eth2_keystore and eth2_wallet. Two more top-level members matter operationally: slasher, which is the slashing protection and detection service, and lcli, a command line tool the repository ships for local chain and testing work. The presence of Dockerfile, Dockerfile.cross and Dockerfile.reproducible side by side says the project treats reproducible builds as a build target rather than an afterthought, which is a reasonable stance for software that signs attestations.

Installing Lighthouse and running a first node

The README does not contain install instructions. It points at the Lighthouse Book at lighthouse-book.sigmaprime.io, and says the Book contains information for users and developers. That is where installation steps live, and the README is explicit that the Book is the entry point. What the repository itself gives you is the Makefile install target and a Dockerfile. The Makefile defines an install target whose recipe is:

cargo install --path lighthouse --force --locked \
		--features "$(FEATURES)" \
		--profile "$(PROFILE)" \
		$(CARGO_INSTALL_EXTRA_

The Makefile comment above it says the target builds the Lighthouse binary in release (optimized) and that binaries will most likely be found in ./target/release. The FEATURES and PROFILE variables are defined earlier in the same file, with PROFILE defaulting to release. If you prefer containers, the Dockerfile builds with rust:1.88.0-bullseye and installs cmake and libclang-dev in the builder stage, then copies the compiled binary into an ubuntu:22.04 runtime image with libssl-dev and ca-certificates. The build stage runs make, and the final image places the binary at /usr/local/bin/lighthouse.

FROM rust:1.88.0-bullseye AS builder
RUN apt-get update && apt-get -y upgrade && apt-get install -y cmake libclang-dev
ARG FEATURES
ARG PROFILE=release
ARG CARGO_USE_GIT_CLI=true
ENV FEATURES=$FEATURES
ENV PROFILE=$PROFILE
ENV CARGO_NET_GIT_FETCH_WITH_CLI=$CARGO_USE_GIT_CLI
ENV CARGO_INCREMENTAL=1

After that, the binary is the thing you invoke. The Makefile's CROSS_FEATURES variable names the optional build features the project supports, including slasher-lmdb, slasher-mdbx, slasher-redb, beacon-node-leveldb and beacon-node-redb, which is a useful signal that the database backend and slasher backend are compile-time choices rather than runtime configuration. Which subcommands to run, and with which flags, is documented in the Book, not here; the README gives no example invocation, so treat any command line you see elsewhere as unverified against this repository.

Where Lighthouse stops and the execution client begins

The most common misunderstanding about a consensus client is that it is a complete Ethereum node. It is not. The workspace includes beacon_node/execution_layer, which is the interface to an execution client, and the Dockerfile builds only the lighthouse binary. Nothing in the repository vendors an execution engine. If you run Lighthouse without a paired execution client, you have a node that follows consensus but cannot validate execution payloads or serve execution-level data. That is a design decision inherited from the post-Merge architecture, not a Lighthouse defect, but it doubles the operational surface: two processes, two data directories, two upgrade cadences, and an authenticated engine API connection between them. The README does not describe this pairing at all, which is a real gap for a first-time operator who lands on the repository page. The Makefile is more informative than the README here, because its feature list distinguishes beacon-node database backends from slasher backends and shows that these are independent components that can be compiled in or out.

Branch discipline and what stable versus unstable means for upgrades

Lighthouse maintains two permanent branches. The README says stable always points to the latest stable release and is ideal for most users, while unstable is used for development and contains the latest pull requests, with contributors basing their work on it. That is a clean policy, and it has a practical consequence: if you build from unstable, you are running unreviewed pull requests against a live network. The release history shows a steady cadence, with v8.2.2 (Mr. Meeseeks) on 2026-08-18, v8.2.1 (Mrs. Pancakes) on 2026-07-21 and v8.2.0 (Mr. Goldenfold) on 2026-06-22, roughly monthly. The last push to the repository was on 2026-09-23. Upgrade cost is not zero. The Makefile's RECENT_FORKS and RECENT_FORKS_BEFORE_GLOAS variables, which list fulu and gloas alongside phase0 in TEST_NETWORK_FORKS, show that hard fork support is compiled and tested into the binary. A client that is behind on releases will not follow a fork boundary, so the upgrade window is set by the network, not by your maintenance schedule. The repository does not document a rollback procedure for a failed upgrade in the files reviewed here.

Slasher, security posture, and the honest limitations

The README states that fuzzing techniques have been continuously applied and that several external security reviews have been performed. That is a claim about process, and the repository backs part of it structurally: a slasher member and slasher/service exist as first-class workspace entries rather than an optional script, and the Makefile exposes slasher-lmdb, slasher-mdbx and slasher-redb as build features. Slashing protection is the part of a validator setup where a mistake is financially punitive, so having it inside the same codebase as the validator client is a meaningful choice. The limitations are less advertised. There is no published benchmark in the README, no memory or CPU guidance, and no statement about which hardware is sufficient. The README also does not cover key management beyond pointing at the Book, even though crypto/eth2_keystore, crypto/eth2_wallet and common/eth2_wallet_manager exist in the tree. For a validator, that is the highest-risk surface and the documentation for it is deliberately out of the README. The wrong tool case is straightforward: if you want to query chain data, run a light wallet, or avoid running two clients, Lighthouse is not what you want.

How it compares to a Go or Java consensus client

The obvious alternative class is another consensus client implementation, and the difference is mostly language and operational culture. A Go-based client compiles quickly, produces a single static binary with a garbage collector, and tends to be forgiving of modest hardware. Lighthouse is Rust, and the README frames the language choice as providing safety guarantees and performance comparable to C++. In practice the Rust choice shows up in the build: the Dockerfile installs cmake and libclang-dev and compiles through make, and the Makefile carries a CROSS_FEATURES list for cross-compilation targets including x86_64, aarch64 and riscv64. Compile times are long and the toolchain matters, which is why the Dockerfile pins rust:1.88.0-bullseye rather than tracking a floating image. The payoff is a codebase with a large workspace of small crates, where consensus logic, crypto and networking are separately testable. If your team writes Go, the operational familiarity argument favors a Go client. If you care about deterministic memory behavior and are willing to absorb longer builds, the Rust split is the reason to pick this one. Neither choice removes the need for an execution client.

Licence, funding and what that means for forks

Lighthouse is licensed under Apache 2.0, which the README states plainly and the LICENSE file confirms. Apache 2.0 is permissive and includes an explicit patent grant, so you can run, modify and redistribute the client, including in a commercial staking operation, without a copyleft obligation on your own code. The practical implication for operators is that there is no licence barrier to building a private image from the Dockerfile and running it on your own infrastructure, which is what the reproducible Dockerfile target appears to be for. The project is funded by Sigma Prime, the Ethereum Foundation, Consensys, the Decentralization Foundation and private individuals, and accepts donations through Gitcoin Grants and an Ethereum address listed in the README. That funding model means there is no paid tier and no support contract attached to the licence. Support runs through the Lighthouse Discord server, which the README calls the best place for discussion, and release notifications go through a mailing list. If you need a vendor to call, this is not that kind of project. This is a description of the licence terms, not legal advice; read the LICENSE file yourself before redistributing.

Editorial conclusion

Lighthouse suits operators who already run Ethereum infrastructure and are willing to follow the Lighthouse Book rather than the repository README, which carries no install commands. It is the wrong first stop for someone who wants a single binary that also handles execution, since the workspace separates beacon_node, validator_client and the execution layer interface. Before committing hardware, read the Book's installation and validator sections and confirm which branch and release tag you intend to run.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sigp/lighthouse on GitHub