Creating a Native Rocket Pool Node without Docker#

In this section, we will walk through the process of installing the Rocket Pool Smartnode stack natively onto your system, without the use of Docker containers.

The general plan is as follows:

1. Create a standard solo-staking setup with systemd services for the Execution Client, the Consensus Client / Beacon Node, and the Validator Client
2. Create system services for the Rocket Pool components (the node and watchtower processes)
3. Configure Rocket Pool to communicate with your client services
4. Update your Validator Client service definition to use Rocket Pool's fee recipient and validator keys

This is a fairly involved setup so it will take some time to complete.

The diversity of Operating Systems and distros available make it impractical to make guides available for all of them. The instructions in this guide are tailored to a Debian-based system (including Ubuntu). For other distros or operating systems, you may follow the high-level steps described in the guide but will have to substitute certain commands for the ones that your system uses as appropriate.

Step 1: Set up the Execution and Consensus Clients#

Native Mode effectively extends a standard solo-staking setup, and simply allows the Smartnode software to attach to the clients that it already runs (with a few small modifications).

To that end, we recommend you start by following some of the conventional solo staking guides provided by the community:

• Somer Esat's set of guides per-client: https://github.com/SomerEsat/ethereum-staking-guides
• CoinCashew guides: https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet

Note that you won't actually create a validator as defined in those guides - Rocket Pool will do that for you. You can ignore the portions involving the Staking Deposit CLI tool.

You simply need to follow the guides to the point where you have an Execution Client service, a Consensus Client / Beacon Node service, and a Validator Client service all installed and syncing the chain. Skip the steps that involve funding a validator and recording its mnemonic.

Also, there is a special case for the fee recipient - when you get to the portion of the guide where you specify the fee recipient in your Validator Client configuration, leave it blank for now. We will describe how to set it up for Rocket Pool validators below.

Once your clients are installed and you can see in their logs that they are syncing the chains properly, you can follow the next steps to set up the Rocket Pool Smartnode and connect it to your clients.

Step 2: Install Rocket Pool#

Creating the Service Account#

The first step is to create a new system account for the Rocket Pool services and disable login and shell access for it:

sudo useradd -r -s /sbin/nologin rp

Now, add yourself to the rp group. You'll need to do this in order to use the Rocket Pool CLI, because it and the Rocket Pool daemon both need to access the Execution layer wallet file.

sudo usermod -aG rp $USER

Finally, add the user account for your Validator Client to the rp group as well. The name of that user account depends on which guide you followed to set up your VC service.

For example, if your VC runs as user lighthousevalidator, you would do the following:

sudo usermod -aG rp lighthousevalidator

After this, logout and back in for the changes to take effect.

Setting up the Binaries#

Start by making a folder for Rocket Pool and a data subfolder. You can put this wherever you want; for this guide, I'll put it into /srv:

sudo mkdir -p /srv/rocketpool

sudo chown $USER:$USER /srv/rocketpool

Now, download the CLI and daemon binaries (or ignore this and build them from source if you prefer). Choose the platform that your system uses from the tabs below.

sudo wget https://github.com/rocket-pool/smartnode-install/releases/latest/download/rocketpool-cli-linux-amd64 -O /usr/local/bin/rocketpool

sudo wget https://github.com/rocket-pool/smartnode-install/releases/latest/download/rocketpool-daemon-linux-amd64 -O /usr/local/bin/rocketpoold

sudo chmod +x /usr/local/bin/rocketpool

Now, set the owner and group of the daemon to rp:

sudo chown rp:rp /usr/local/bin/rocketpoold

Finally, set the suid bit and other permissions bits on the daemon binary:

sudo chmod u+sx,g+sx,o-rwx /usr/local/bin/rocketpoold

This will ensure that the daemon always runs as the rp user, so it always has the proper permissions set.

Setting up the Installation Folder#

With the CLI and Daemon installed, you'll need to next set up the folder structure and accompanying files that the Smartnode expects to exist. Start by creating the following folders:

Next, download the following scripts - Rocket Pool will use them when it needs to stop or restart your Validator Client to change its fee recipient (discussed later) or load new keys after you create a new minipool:

wget https://github.com/rocket-pool/smartnode-install/raw/release/install/scripts/restart-vc.sh -O /srv/rocketpool/restart-vc.sh

wget https://github.com/rocket-pool/smartnode-install/raw/release/install/scripts/stop-validator.sh -O /srv/rocketpool/stop-validator.sh

chmod +x /srv/rocketpool/restart-vc.sh

chmod +x /srv/rocketpool/stop-validator.sh

Now open ~/.profile with your editor of choice and add this line to the end:

alias rp="rocketpool -d /usr/local/bin/rocketpoold -c /srv/rocketpool"

Save it, then reload your profile:

source ~/.profile

This will let you interact with Rocket Pool's CLI with the rp command, which is a nice shortcut.

Creating the Services#

Next up, we'll create a systemd service for the Rocket Pool node daemon. This is the service that will automatically check for and claim RPL rewards after each checkpoint, and stake minipools once you've created them via node deposit.

We'll also create a watchtower service as well. This will be used if you're an Oracle DAO member, or if you ever want to generate your own rewards interval trees (discussed in the Claiming Rewards section later on).

sudo nano /etc/systemd/system/rp-node.service

sudo /srv/rocketpool/node-log.sh

The services are now installed.

Setting up Passwordless Script Access#

The next step is to give the rp user the ability to restart the Validator Client when new validator keys are created, and stop the Validator Client if an emergency condition is detected.

Create a new sudoers file using visudo:

sudo visudo -f /etc/sudoers.d/rocketpool

Add the following lines to it:

Where <validator service name> is the name of your VC service (e.g. lighthousevalidator)

Now, modify /srv/rocketpool/restart-vc.sh:

• Uncomment the line at the end and change it to sudo systemctl restart <validator service name>

Also modify /srv/rocketpool/stop-validator.sh:

• Uncomment the line at the end and change it to sudo systemctl stop <validator service name>

All set! The node process can now restart or stop your VC as required automatically.

Step 3: Configure the Smartnode#

Now that your services are all created, it's time to configure the Smartnode stack.

Please visit the Configuring the Smartnode Stack (Native Mode) guide, and return here when you are finished.

Enabling and Running the Services#

With all of the services installed, it's time to:

• Enable them so they'll automatically restart if they break, and automatically start on a reboot
• Start them all

sudo systemctl daemon-reload

sudo systemctl enable rp-node rp-watchtower

sudo systemctl start rp-node rp-watchtower

Setting Up a Wallet#

Next, create a new node wallet or recover an existing wallet. Please carefully follow the instructions in the Setting up a Wallet portion of the guide, then return here when you're done.

Once that's done, use the service log file scripts to verify that they successfully loaded your new wallet. You should also verify this using the following command:

rp wallet status

If working properly it should produce the following output:

Step 4: Update the VC Service Definition#

Unlike a solo staking setup, Rocket Pool generates and manages its validator keys automatically. There are a few adjustments you'll need to make to the VC service definition file you just created in order for it to work with Rocket Pool correctly, including:

• The Fee Recipient
• The VC's data or wallet directory
• The VC's keys and secrets directories

We'll cover these step-by-step for each client.

Setting Up the Fee Recipient File#

The fee recipient is the argument you provide to your Validator Client that specifies the address on the Execution layer that you want your priority fees and MEV rewards to be sent to. Rocket Pool has two different addresses for the fee recipient:

• If you are opted into the Smoothing Pool, it must be the Smoothing Pool's address
• If you are opted out of the Smoothing Pool, it must be your node's Fee Distributor address

To learn more about the Smoothing Pool and your Fee Distributor, please see the Fee Distributors and the Smoothing Pool section of the guide.

Rocket Pool's node service will set this for you automatically by detecting which one it needs to be and setting it in a configuration file and restarting your Validator Client service to pick up the change. Your Validator Client service can use that configuration file automatically so you don't need to hard-code the fee recipient.

Open the systemd service definition file that you just created for your Validator Client. Before the ExecStart line, add this line:

Then modify your fee recipient argument as follows; select your client of choice from the tabs below:

Setting the Data and Keys Directories#

Next, you must tell the VC where to store its data and load the validator keys that Rocket Pool generates. Click on the client you use in the tabs below:

sudo mkdir -p /srv/rocketpool/data/validators/lighthouse/validators

sudo mkdir -p /srv/rocketpool/data/validators/lighthouse/secrets

sudo chown -R rp:rp /srv/rocketpool/data/validators/lighthouse

sudo chmod -R 775 /srv/rocketpool/data/validators/lighthouse

Relaxing umask#

By default, your system will typically come with a umask configuration that will strip the +w bit from the group permissions whenever the node daemon creates a new folder. This is problematic for several consensus clients, because they will actually write things such as lock files or other metadata into the directories that the Smartnode creates when it generates new validator keys during a minipool deposit.

To combat this and ensure your VC works correctly, please relax your umask settings. For example, instead of 0022, you should consider setting it to 0002 for the rp user.

Every system is different, so please consult a guide that covers your Operating System to learn how to do this.

Reloading the VC Service#

With these changes made, you can now reload and restart the VC service using the following:

sudo systemctl daemon-reload

sudo systemctl restart <vc-service>

If not using Prysm, please watch the VC's logs carefully to ensure that it successfully started properly and the following are defined correctly:

• The fee recipient
• The data path
• The wallet / keys / secrets path

You can verify this with, for example, ps aux | grep fee to filter the running processes to look at the fee recipient that your VC has used. It should be the same one defined in /srv/rocketpool/data/validators/rp-fee-recipient-env.txt.

If they are all using the correct values, then congratulations! You've successfully set up your Rocket Pool node and can follow the next sections of the guide to learn how to use it.

Next Steps#

Now that your clients are installed, we recommend you take a look at the security suggestions in the Securing your Node section next. As you're running a Native setup, you have likely done some of these things already; nevertheless, it doesn't hurt to at least explore it and see how well the recommended security posture fits with your system.