Rocket Pool
Rocket Pool
Overview
Guides
Website
简体中文
English
Overview
Guides
Website
简体中文
English
Rocket Pool

Guides

Overview
The Saturn 0 Upgrade

rETH Staker Guide

Overview
Staking directly via Rocket Pool
Staking via a Decentralised Exchange on the Ethereum Network (Layer 1)
Staking via a Decentralised Exchange on Layer 2
Staking on behalf of a node

Node Operator Guide

A Node Operator's Responsibilities
Node Requirements & Choosing a Platform

Preparing a Local Node

Overview
Selecting Staking Hardware
Preparing a PC, Mini-PC or NUC
Preparing a Mac
Intro to Secure Shell (SSH)

Preparing a Server Node

Overview
Selecting a Hosting Provider
Preparing the Operating System

Securing Your Node

Securing Your Node
Tailscale

Installing Rocket Pool

Overview
Choosing your ETH Clients
Selecting a Rocket Pool Mode
Creating a Standard Rocket Pool Node with Docker
Creating a Native Rocket Pool Node without Docker

Configuring Rocket Pool

Overview
Configuring the Smartnode Stack (Docker/hybrid mode)
Configuring the Smartnode Stack (native)
Advanced Smartnode Configuration for Docker Mode

Provisioning your Node

Overview
Starting Rocket Pool
Creating a New Wallet
Importing/Recovering an Existing Wallet
Preparing your Node for Operation
Intro to the Command Line Interface
Specifying a Fallback Node
Fee Distributors and the Smoothing Pool
MEV, MEV-Boost & MEV Rewards

Creating or Migrating Minipools

Overview
Creating a new Minipool (Validator)
The Minipool Delegate
Converting a Solo Validator into a Minipool
Migrating a 16-ETH Minipool to 8-ETH
The Deposit Credit System

Monitoring & Maintenance

Overview
Monitoring your Node's Performance
Setting up the Grafana Dashboard
Smartnode Stack Alert Notifications
Checking for Updates
Backing Up Your Node
Masquerading as Another Node Address
Expiring Pre-Merge History
Pruning the Execution Client
Changing Execution or Consensus Clients
Moving from One Node to Another

Claiming Rewards

Overview
Claiming Node Operator Rewards
Distributing Skimmed Rewards

Participating in pDAO governance

Overview
The Protocol DAO
Participating in on-chain pDAO Proposals
Setting your Snapshot Signalling Address
Delegating Voting Power
Viewing the State of a Proposal
Voting on a Proposal
Creating a Proposal
Executing a successful proposal
Claiming Bonds and Rewards
Creating and Claiming a recurring treasury spend

Exiting your Minipools

Shut Down a Minipool
Rescuing a Dissolved Minipool
FAQ (WIP)

Testing Rocket Pool with the Hoodi Test Network

Practicing with the Test Network
Migrating from the Test Network to Mainnet

Running an Oracle DAO Node

The Rocket Pool Oracle DAO
Setting up an Oracle DAO Node
Testing your Oracle DAO Node
Monitoring your Oracle DAO Node
Oracle DAO Proposals

Legacy Guides

Upgrading to Smartnode v1.3.x
Migrating the Smartnode from Previous Beta Tests
The Atlas Update
Lower ETH Bond Minipools

Redstone & The Merge

The Rocket Pool Redstone Update
[Docker Mode] Guide to the Redstone Update and the Merge
[Hybrid Mode] Guide to the Redstone Update and the Merge
[Native Mode] Guide to the Redstone Update and the Merge

The Houston Upgrade

Overview
Getting Started with Houston
The Protocol DAO
Participating in Proposals
Stake ETH on Behalf of Node
RPL Withdrawal Address
Preparing a Raspberry Pi
📝 Edit this page on GitHub
Previous PageConfiguring the Smartnode Stack (native)
Next PageProvisioning your Node

#Advanced Smartnode Configuration for Docker Mode

In this section, we will cover a few techniques that expand the Smartnode's customization and functionality.

#Allowing External Validator Clients to Connect to the Smartnode

Because the Smartnode manages the Execution client and Beacon Node, it handles much of their configuration (including updates) automatically. One common request from users is for the ability to attach an externally-managed Validator client to the Smartnode's Execution and Consensus clients.

Essentially, this acts as a sort of "Reverse Hybrid" mode; instead of the Smartnode managing its own Validator client and connecting to an external Execution and Consensus client, it manages all three things and an external Validator client can use its own clients instead.

Enabling this is trivial using the Settings Manager.

#Execution Client

To enable access to the Execution client, go to the Execution Client (ETH1) category and check the Expose RPC Ports box:

This will open the RPC ports (default 8545 for HTTP and 8546 for Websockets) on your node, so other machines on your local network can connect to them.

For example, if your node's local IP address were 192.168.1.45, then by enabling this option you could use http://192.168.1.45:8545 as the Execution client URL for your other services.

#Beacon Node (Consensus Client)

To enable access to the Consensus client's Beacon Node, go to the Consensus Client (ETH2) category and check the Expose API Port box:

This will open the HTTP API port (default 5052) on your node, so other machines on your local network can connect to it.

Note: Ports opened via iptables, not ufw

When you expose RPC and API endpoints in using the Rocketpool configurator, ports are opened via iptables and therefore will not show up as a ufw firewall rule. To see which ports are open you can use sudo lsof -i -P -n | grep LISTEN or similar command.

For example, if your node's local IP address were 192.168.1.45, then by enabling this option you could use http://192.168.1.45:5052 as the Beacon Node URL for your other services.

NOTE FOR PRYSM USERS

Prysm has a second box called Expose RPC Port that must be checked if you want to attach an externally-managed Prysm Validator Client to your Beacon Node. This is because Prysm's Validator Client cannot currently connect to a Beacon Node via the standard Beacon HTTP API. In the future, this will be fixed and there will only be one checkbox like the other clients.

#MEV-Boost

To enable access to MEV-Boost, go to the MEV-Boost category and check the Expose API Port box:

This will open the HTTP API port (default 18550) on your node, so other machines on your local network can connect to it.

For example, if your node's local IP address were 192.168.1.45, then by enabling this option you could use http://192.168.1.45:18550 as the MEV-Boost URL for your other services.

#Customizing the Docker-Compose Definition Files

While the Settings Manager contains many options you can use to customize your node, it doesn't wrap all of the features that docker-compose provides. Some users require supplemental customizations to the Smartnode's docker-compose files.

Because the docker-compose files are regenerated (into the runtime directory) from their templates (in the templates directory) each time rocketpool service start is called, modifying the runtime files is not advised. Instead, we leverage docker-compose's inherent override functionality to let you make any modifications you need to which will be preserved upon restarts. Furthermore, this system also preserves your modifications after an upgrade to or reinstallation of the Smartnode stack.

To do this, simply open the file for the container of your choice in the override folder, and add your customizations to it there. Anything you put in these files will override whatever the corresponding settings are in the docker-compose files from the runtime folder.

For example, say you wanted to add AWS credentials to Grafana for CloudWatch support. You could do it by modifying override/grafana.yml like so:

# Enter your own customizations for the Grafana container here. These changes will persist after upgrades, so you only need to do them once.
#
# See https://docs.docker.com/compose/extends/#adding-and-overriding-configuration
# for more information on overriding specific parameters of docker-compose files.

version: "3.7"
services:
  grafana:
    x-rp-comment: Add your customizations below this line
    environment:
      - GF_AWS_PROFILES=default
      - GF_AWS_default_ACCESS_KEY_ID=YOUR_ACCESS_KEY
      - GF_AWS_default_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
      - GF_AWS_default_REGION=us-east-1

This will merge the four environment variables listed here to the existing array of environment variables in the Grafana container.

Alternatively, if you wanted to save eth1 client data to a non-default path on your filesystem, you would modify override/eth1.yml to contain volume parameters like:

# Enter your own customizations for the eth1 container here. These changes will persist after upgrades, so you only need to do them once.
#
# See https://docs.docker.com/compose/extends/#adding-and-overriding-configuration
# for more information on overriding specific parameters of docker-compose files.

version: "3.7"
services:
  eth1:
    x-rp-comment: Add your customizations below this line
volumes:
  eth1clientdata:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: "/data/eth/eth1"

This will merge the parameters into the eth1clientdata volume specification, causing /data/eth/eth1 to be the location of the eth1 client data rather than the default (/var/lib/docker/volumes/rocketpool_eth1clientdata if using default Docker configuration).

For more information on how docker-compose overrides work, please visit https://docs.docker.com/compose/extends/#adding-and-overriding-configuration.