Interacting with a node through CLI

This guide provides a concise, technical overview of interacting with a validator node through its Command Line Interface (CLI). Commands are presented generically; replace <client> with your specific client binary (e.g., Lighthouse, Reth).

CLI Basics

Installation and Setup

Installation typically involves downloading a pre-compiled binary from the client's official GitHub releases page or building from source. Always verify the binary's checksum.

# Example: Download and extract a binary
wget <URL_to_binary.tar.gz>
tar -xzf <URL_to_binary.tar.gz>
sudo mv <client> /usr/local/bin/

Setup requires both an Execution Client (e.g., Reth) and a Consensus Client. They communicate via a JWT secret.

Basic Commands

Interaction follows a standard structure: <client> <subcommand> [flags].

Beacon Node: The core consensus component:

# Example: Start a beacon node
<client> bn --network mainnet --datadir /data/consensus

Validator Client: Manages your validator keys and duties:

# Example: Start a validator client
<client> vc --network mainnet --datadir /data/validator

Configuration Management

Configuration is managed through command-line flags or a configuration file (e.g., config.toml). Flags always override settings in the configuration file.

Flag Example:

<client> bn --http --http-port 5052

Configuration File; Using a file is recommended for managing numerous settings:

# Specify a config file at runtime
<client> bn --config-file /etc/ethereum/config.toml

Help and Documentation

Access built-in help for any command or subcommand using the --help flag.

# General help
<client> --help
 
# Help for a specific subcommand (e.g., beacon node)
<client> bn --help

Node Management

Starting and Stopping the Node

Starting: Execute the command to run the beacon node and validator client processes. For production environments, it is standard practice to run these as systemd services for automatic startup and management.

# Start the services
sudo systemctl start execution-client consensus-client validator-client
 
# Enable the services to start on boot
sudo systemctl enable execution-client consensus-client validator-client

Stopping: If running directly in the terminal, press Ctrl+C. If running as a service, use systemctl.

sudo systemctl stop validator-client

Status Checking and Monitoring

Clients expose a REST API for status checks. Ensure the API is enabled (--http flag) and secured.

# Check node version
curl http://localhost:5052/eth/v1/node/version
 
# Check sync status
curl http://localhost:5052/eth/v1/node/syncing
 
# Check peer count
curl http://localhost:5052/eth/v1/node/peer_count

Log Management

Logs provide critical insight into node operations. By default, logs are sent to standard output (stdout).

Log Level: Control verbosity with the --log-level flag (e.g., info, debug, warn, error). The debug level is useful for troubleshooting but is very verbose.

<client> bn --log-level debug

Service Logs: When running as a systemd service, use journalctl to view and manage logs.

# View live logs for the consensus client
sudo journalctl -fu consensus-client.service
 
# View logs from the last 24 hours
sudo journalctl -u consensus-client.service --since "24 hours ago"

Troubleshooting Common Issues

Peering Issues: If your peer count is low or zero, check:

1. Firewall rules are correctly configured to allow the client's P2P port (e.g., 9000/tcp).
2. The client is fully synced.
3. Your --p2p-port flag is correctly set.

Time Sync Errors: The Nexera network is highly sensitive to time. Errors related to "slot in the future" or "invalid timestamp" indicate your system clock is out of sync. Install and enable a time synchronization service like chrony.

sudo apt-get install chrony
sudo systemctl start chrony

JWT Authentication Errors: If the execution and consensus clients cannot communicate, verify that both are configured to use the exact same JWT secret file (--jwt-secret flag).

Performance Optimization Commands

Performance can be tuned with specific flags, which vary by client.

Peer Management: Adjust the number of peers to balance network connectivity with resource usage.

# Example: Set a target peer count
<client> bn --p2p-max-peers 70

Database Cache: Allocate more RAM to the database cache to improve read/write performance, which is especially important during initial sync.

# Example: Set database cache size (client-specific flag)
<client> bn --db-cache-size 4096 # Example value in MB

Resource Limiting: Some clients offer flags to limit CPU usage to prevent the node from consuming all available system resources.