Repository navigation
Add lighthouse validator client with proposer config - #487
Merged
Merged
Conversation
KaloyanTanev
force-pushed
the
kalo/lighthouse-vc
branch
3 times, most recently
from
September 16, 2026 20:45
f6b8bc9 to
e77c213
Compare
KaloyanTanev
force-pushed
the
kalo/proposer-config
branch
from
September 16, 2026 20:45
74e278f to
8612503
Compare
KaloyanTanev
force-pushed
the
kalo/lighthouse-vc
branch
from
September 16, 2026 21:15
e77c213 to
fa36afc
Compare
KaloyanTanev
changed the title
4 of 10 tasks
KaloyanTanev
force-pushed
the
kalo/lighthouse-vc
branch
from
September 16, 2026 21:27
fa36afc to
df2e87e
Compare
KaloyanTanev
force-pushed
the
kalo/proposer-config
branch
from
September 16, 2026 21:50
8612503 to
ec82eae
Compare
KaloyanTanev
force-pushed
the
kalo/lighthouse-vc
branch
3 times, most recently
from
September 18, 2026 16:14
da1b2a2 to
f48676d
Compare
OisinKyne
approved these changes
Oct 5, 2026
| # Global fallbacks when validator definitions carry no proposer settings: the zero | ||
| # default fee recipient, which charon overrides pre-gloas, and process-wide builder | ||
| # participation. With a proposer config both are set per validator instead. | ||
| EXTRA_FLAGS+=(--suggested-fee-recipient "0x0000000000000000000000000000000000000000") |
Contributor
There was a problem hiding this comment.
Where do we think we land with not burning mistake path eth? i.e. pointing it at 0xDe5aE4De36c966747Ea7DF13BD9589642e2B1D0d. That may open up problems but probably better than just bricking the eth?
|
|
||
| vc-lighthouse: | ||
| profiles: [vc-lighthouse] | ||
| image: "lighthouse-vc:${VC_LIGHTHOUSE_VERSION:-v8.2.0}" |
Same as the other VCs: wait for proposer-config.json instead of charon's health, and mount .charon read-only.
KaloyanTanev
force-pushed
the
kalo/lighthouse-vc
branch
from
October 5, 2026 16:25
f48676d to
be00f35
Compare
|
KaloyanTanev
added a commit
that referenced
this pull request
Oct 5, 2026
Wires the charon-generated proposer config (ObolNetwork/charon#4700, `vc-config/proposer-config.json` next to the cluster lock) into the four validator clients, so every VC holds the cluster fee recipient and gas limit. From the gloas fork VCs sign these values into proposer preferences, so they must match across the cluster (ObolNetwork/charon#4692). Each VC mounts `.charon` read-only and its `run.sh` waits up to 120s for `proposer-config.json` before rendering the client's native format from charon's sparse schema: - Teku and Prysm get thin custom images adding `jq`. Teku renders `--validators-proposer-config`, falling back to the zero-address default fee recipient without the file. - Prysm renders v2 settings (`version: 2`, top-level `gas_limit`). At the gloas fork Prysm drops the legacy `builder.gas_limit`, so a v1 file would sign a different gas limit than the other VCs. - Lodestar renders its settings `.yml` via `node`. Nimbus writes per-validator `suggested_fee_recipient.hex` and `suggested_gas_limit.json` after key import. VCs don't wait for charon's healthcheck: `/readyz` stays unready until a VC connects, so a `service_healthy` dependency never starts them. `.charon` is mounted rather than `vc-config`, since Docker would otherwise create a root-owned `vc-config` before charon writes it. The Nimbus image tag gets a `-jq` suffix so a plain `docker compose up -d` rebuilds it instead of reusing the old image without `jq`. Also bumps the stack to the latest releases and pins charon to the latest gloas commit `9affa0d`, since only the gloas build writes the proposer config: Nethermind 2.1.0, Reth v2.7.0, Lighthouse v8.2.3, Teku 26.9.1, Lodestar v1.49.0, Prysm v7.2.0, Nimbus v26.10.0, Commit-Boost v0.10.1, Prometheus v3.15.0, Grafana 13.2.3, Alloy v1.20.1, cAdvisor v0.60.6, Loki 3.7.8, Tempo 3.1.0. Tempo 3 drops the `ingester`/`compactor` config, so `tempo.yaml` moves retention to the backend scheduler and worker. node-exporter moves to `prom/node-exporter`, since `bitnamilegacy` is frozen at 1.9.1. Nethermind 2.x upgrades existing databases in place but needs AVX2: it dies with SIGILL on CPUs or VMs without it. Also aligns the VC services: all scripts take the beacon endpoint from `BEACON_NODE_ADDRESS`, Prysm `exec`s the validator and binds metrics on `0.0.0.0`, Teku enables metrics on `8008`, the Prometheus example scrapes all VCs, and service definitions follow one key order. Tested by starting every service at its new version with its compose flags (no flag or config errors), and running Teku, Nimbus, Lodestar and Prysm against a stub beacon node with a proposer config holding a diverging validator: each applied the per-validator values. Lighthouse follows in #487, builder config in #488.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a
vc-lighthousevalidator client profile (Lighthouse v8.2.3), the fifth VC for the proposer config rollout (ObolNetwork/charon#4692).Custom image (
lighthouse/Dockerfile,jqbaked in) with arun.shthat waits for charon'sproposer-config.jsonlike the other VCs, then authors the completevalidator_definitions.ymlfrom the mounted charon keystores, replacinglighthouse account validator import, and starts the VC with--distributed --disable-auto-discover. The definitions are regenerated on every start, soproposer-config.jsonupdates apply on restart. Without a proposer config it writes plain definitions and falls back to the zero default fee recipient, which charon overrides pre-gloas.Verified with a real charon-generated proposer config: Lighthouse parses the authored definitions with per-validator
suggested_fee_recipientandgas_limit, picks up a config update on restart, and the fallback generates plain definitions. Stacked on #486.