Skip to content

Conversation

@bussyjd
Copy link
Contributor

@bussyjd bussyjd commented Nov 13, 2025

This PR consolidates workshop-related improvements:

Included Changes

From PR #150: Validator Client Type Validation

  • Enhanced validation for validator client type to prevent silent failures
  • Added actionable error messages with valid options
  • Improves user experience with clear guidance

From PR #151: Documentation and Network Migration

  • Migrated from chainId to network parameter (breaking change)
  • Updated all Helm commands to use helm upgrade --install
  • Added Challenge & Testing documentation section
  • Implemented intelligent fallback beacon node endpoints based on network

Also Includes

  • Fix FIPS 140 mode compatibility in ENR job kubectl commands

Breaking Change

Users must now use --set network=mainnet instead of --set chainId=1

Testing

  • All changes maintain backward compatibility except the network parameter migration
  • Documentation updated in both README.md and QUICKSTART.md
  • Template files (README.md.gotmpl) updated to ensure regeneration preserves changes

Supersedes: #150, #151

Improves the validator client type validation error messages to provide
better user guidance when invalid types are specified.

Changes:
- Add generic fuzzy matching for "did you mean" suggestions
  * Known typos map: loki→lodestar, prism→prysm, lighthose→lighthouse
  * Prefix matching: tek→teku, nim→nimbus, lodest→lodestar
  * Substring matching for partial matches
- Provide actionable fix instructions showing:
  * CLI flag syntax: --set validatorClient.type=<type>
  * values.yaml format with proper indentation
  * Custom values file approach
- Include documentation reference to README.md
- Use suggested type in examples when available

Example error output:
  ERROR: Invalid validator client type 'loki'.

  Valid options: lighthouse, lodestar, teku, prysm, nimbus

  ⚠️  Did you mean 'lodestar'?

  How to fix this:
    • Using --set flag:
      --set validatorClient.type=lodestar

    • In your values.yaml file:
      validatorClient:
        type: lodestar

Tested with all validator client types and various typos.
All valid types (lighthouse, lodestar, teku, prysm, nimbus) still work correctly.

Addresses user feedback from PR #148 that validation errors needed
more actionable guidance.
Adds --validate=false flag to kubectl commands in the ENR job to prevent
validation errors when running in FIPS 140-only mode environments.

Issue:
When the ENR generation job runs in FIPS 140-only mode, kubectl validation
fails with error:
  "crypto/ecdh: use of X25519 is not allowed in FIPS 140-only mode"

This occurs during:
1. kubectl apply when creating new ENR secrets
2. kubectl patch when updating existing secrets with missing ENR field

Solution:
Add --validate=false flag to both kubectl commands (lines 210, 226):
- kubectl patch: --validate=false flag added
- kubectl apply: --validate=false flag added

The GODEBUG environment variable (x509sha1=1,tls13=0) is already set
for the kubectl-secret-creator container, but validation needs to be
explicitly disabled for kubectl operations in FIPS mode.

This allows the ENR job to complete successfully in FIPS-compliant
Kubernetes clusters while maintaining the same functional behavior.
This commit includes several documentation and usability improvements:

1. Migrate from chainId to network parameter (breaking change)
   - Replace all chainId references with network parameter in docs
   - Update QUICKSTART.md examples: chainId=1 → network=mainnet
   - Update values-examples to use network instead of chainId
   - Templates already supported network-based helpers

2. Update all Helm commands to use 'helm upgrade --install'
   - Updated 8+ instances in README.md
   - Provides idempotent commands for both install and upgrade scenarios
   - Better user experience and less confusion

3. Add Challenge & Testing documentation
   - New comprehensive section in QUICKSTART.md
   - Examples for overriding API endpoints (dev/staging)
   - Examples for using specific DKG sidecar commits/branches
   - Complete challenge example with all parameters
   - Helpful for testing and development workflows

4. Implement intelligent fallback beacon node endpoints
   - Auto-select publicnode.com endpoints based on network
   - mainnet → ethereum-beacon-api.publicnode.com
   - sepolia → ethereum-sepolia-beacon-api.publicnode.com
   - hoodi → ethereum-hoodi-beacon-api.publicnode.com
   - Pods can now start without manual fallback configuration
   - Users can still override with custom endpoints

Files modified:
- charts/dv-pod/QUICKSTART.md
- charts/dv-pod/README.md
- charts/dv-pod/README.md.gotmpl
- charts/dv-pod/templates/_helpers.tpl
- charts/dv-pod/templates/statefulset.yaml
- charts/dv-pod/values-examples/with-target-config-hash.yaml
- charts/dv-pod/values.yaml

BREAKING CHANGE: Users must now use --set network=mainnet instead of --set chainId=1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants