Repository navigation
ADD: Pluto as an Obol distributed validator client - #2311
Merged
Merged
Conversation
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
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.
ADD: Pluto as an Obol distributed validator client
Adds support for Nethermind's Pluto, a Rust reimplementation of Obol's Charon, as a first-class Stereum service, plus an in-place migration path for existing Charon clusters and a few fixes found along the way.
Pluto support
PlutoServiceextendsCharonServicerather thanNodeService, because Pluto implements Charon'sruninterface exactly: same flags, sameCHARON_*env vars, same.charonlayout relative to the image's/opt/charonworkdir. It therefore inherits every helper unchanged (ENR handling, DKG, cluster lock) and overrides only the image and entrypoint (/app/bin/pluto).Verified against Pluto v0.1.4's own CLI source, not just
run:create enr,enr,dkg --definition-file --publish,--feature-set-enable=json_requests, and--data-dirdefaulting to.charonwith the key still namedcharon-enr-private-key. So ENR generation and the DKG flow inObolModal.vuework untouched.A shared
isObolDVTService()predicate insrc/share/replaces the ~40 hard-codedservice === "CharonService"checks acrossServiceManager,ValidatorAccountManager,Monitoring,OneClickInstall, the four validator-client classes,LidoObolExitService, and ~15 Vue components.PlutoServiceis added to the Prometheus scrape job (same metric names, same port).Being a separate service class rather than an image swap on
CharonServiceis deliberate: auto-updates key off the service name, so reusingCharonServicewould write Charon tags onto the Pluto repo.Charon to Pluto switch is in place, not a reinstall
The generic SWITCH CLIENT path installs a replacement and then runs
delete-service, whose Remove Service Files task would delete.charon: ENR key, cluster lock, and validator key shares. SoswitchServices()detects a DV-to-DV switch and swaps the client in place instead: same service id, ports, volumes, dependencies and command, stopped then started somanage-servicereconciles ufw, and the previous service excluded from the delete pass.autoupdateis carried over from the stored YAML instead of being reset.SwitchContent.vuenow offers a DV client only the other DV client; it previously offered Lighthouse VC etc., which would have run that destructive path.P2P external IP expert option (all 16 p2p clients)
Behind Docker, Pluto never advertises the address its autonat confirmed, so it stays relay-only, worth 15-30x p2p latency on a real cluster. Rather than baking a guess into the config, this is an expert option that can be auto-detected or typed by hand, and cleared to remove the flag.
Each client's flag was verified against that client's own CLI source:
--nat+extip:--enr-address--p2p-host-ip/--p2p-advertised-ip/--enr.ip--p2p-host/--Network.ExternalIp/--nat.extip--p2p.advertise.ip/--p2p-external-ipSeven clients already shipped an option for this, so those keep their existing command strings (Nimbus carries
extip:inside the command) and just gain the detect button, with no duplicate rows. A newvaluePrefixfield handles the geth family'sextip:scheme, which the generic text writer couldn't produce.Lodestar NODE_OPTIONS
Exposes Lodestar's Node heap limit for tuning on the beacon (which already ships
--max-old-space-size=8192) and lets the validator be given one. This needed a fix toExpertWindow'sisENVpath: it previously only reached the env branch when the YAML had no--flags, so on Lodestar it would have appendedNODE_OPTIONS:into the command list, and the validator's inlineenv: {}would have become invalid YAML.Fixes found while testing
app_monitoring_readyzcarries nocluster_peerlabel (it reports the name viaapp_peer_name), andreadyz 6is accepted for Pluto because Charon deleted that check in v1.10.0 (#4359) as a false positive.backToLoginclearedsettingsStandalonebefore navigating, mountingBaseLayoutfor a tick while logged out; and an empty SSH pool surfaced asCannot read properties of undefined (reading 'exec').savedConfig.logBackups.valuethrew when the key was absent, so the "write the default" fallback never ran. The credits endpoints answer 404, so they now return[]instead ofundefined.data:audio in the CSP so UI sounds play. Nomedia-src, so the inlined base64 wav sound effects fell back todefault-src 'self'and were blocked.Testing
251 unit tests, 34 suites, eslint and
prettier --checkclean. Every one of the 10 commits was verified independently in a separate worktree: lint, format and tests all pass at each, with test counts rising monotonically (225 to 251).New coverage: Pluto's command surface and Charon-compatibility, the in-place swap in both directions (preserving id, volumes, command, dependencies and autoupdate), the per-client external-IP flags plus a guard that no client has two options writing the same command, the storage unit ladder, the SSH not-connected guard, and the credits fetchers.