Lighthouse Ethereum Consensus Client

The Lighthouse Account Manager (AM) is a stand-alone binary used to manage cryptographic keys for Ethereum Serenity. Its primary responsibilities include:

• Generation of cryptographic key pairs: Securely generating keys using sufficient entropy.
• Secure storage of private keys: Encrypting keys at rest on disk in a format compatible with the validator client.
• Staking initiation: Producing the messages and transactions required to initiate staking on Ethereum 1.x.

Siren is a user interface built for Lighthouse that connects to a Lighthouse Beacon Node and a Lighthouse Validator Client. It is used to monitor performance and display key validator metrics.

Note: Siren is currently in active development and is maintained in its own dedicated repository: https://github.com/sigp/siren.

The lighthouse validator-manager tool is used to manage validators on a running Lighthouse Validator Client (VC). Unlike the account-manager tool, which creates files to be read upon the next VC restart, the validator-manager performs operations via the HTTP API to make instant changes to a live VC.

Key features include:

• Moving validators between two VCs while maintaining the slashing protection database.
• Generating deposit files compatible with the Ethereum Staking Launchpad.
• Minimizing downtime during validator operations.
• Preserving the "key cache" when adding validators to prevent long startup waits.

Lighthouse employs a "split" database schema to manage state efficiency:

• Hot DB: Stores recent, unfinalized states and all blocks. Full BeaconState structures are stored once per epoch to maintain performance for recent data.
• Freezer DB (or Cold DB): Stores finalized states. It uses a sparser format where full BeaconState structures (snapshots) are stored periodically, and intermediate states are reconstructed by replaying blocks or applying hierarchical state diffs (hdiffs).
• Split Slot: The specific slot that marks the boundary between the freezer DB (slots less than the split slot) and the hot DB (slots greater than or equal to the split slot).

Lighthouse provides two distinct RESTful HTTP/JSON APIs for querying the Ethereum consensus state:

1. Beacon Node API: Used for interacting with the beacon node (e.g., querying attestations, blocks, and consensus state).
2. Validator Client API: Used for interacting with the validator client (e.g., managing validator keys, checking staking status, and performing withdrawals).

To retrieve historical blob data beyond the standard 18-day availability period, you can use the experimental flag --complete-blob-backfill.

Critical Requirements & Risks:

• This is an experimental feature.
• It only works if the flag is present during a fresh checkpoint sync when the database is being initialized.
• It will not work if the node is already running with an existing database.
• During backfill, the node may experience issues such as blocking most of its peers.

For detailed technical information, guides, and developer documentation, refer to the Lighthouse Book.

For community discussion and support, use the Lighthouse Discord server. For periodic progress updates and roadmap insights, follow the Lighthouse Blog.

To develop on Lighthouse, ensure you have the base dependencies installed via the Installation Guide. For development, you must also install:

• cmake: Required by some dependencies.
• java 17 runtime: Minimum version 17 is required for web3signer_tests.

If you have lost your validator keystore files or passwords, you can regenerate them using a mnemonic via the lighthouse account validator recover command.

⚠️ Warning: Use this only as a last resort.

• Your mnemonic is not encrypted and is highly vulnerable to theft when entered into a computer.
• Regenerating keys can result in duplicate keypairs. Running the same keypairs on two different validator clients will likely result in slashing.

Each recovered index creates a directory in the --validator-dir location (default ~/.lighthouse/{network}/validators) containing the necessary information to run a validator with lighthouse vc. The new keystore password is saved in the --secrets-dir (default ~/.lighthouse/{network}/secrets).

Note: {network} refers to the value passed to the --network parameter (default is mainnet).