How to Run a Solana Node? | Step-by-Step

Solana network is a cutting-edge blockchain network known for its limitless scalability and lightning-fast transactions. If you'd like to be part of and actively participate in the Solana ecosystem, you can do so by running a Solana validator node.

This guide will walk you through how to run a Solana node, including setting it up and operating it. Doing this will help strengthen the network, validate transactions, and earn rewards.

#What is a Solana node?

A Solana node is a computer that validates transactions and blocks against the consensus rules implemented by the Solana protocol. A Solana node participates in the Solana blockchain network by storing a copy of the blockchain ledger.

#How to become a Solana validator?

To become a Solana validator, you'll need powerful computing resources, fast processors, significant RAM, and SSD storage. Keep reading to see what exactly is required and the step-by-step process on how to run a Solana node.

#Solana node requirements & tools

This guide includes some hands-on demonstrations. Below we list the key hardware and software requirements for running a Solana node. To follow along, you should have the following:

• A dedicated server with extra volumes
• A computer
• Good internet

Server Hardware Specification

• CPU
  • 12 cores/24 threads, or more
  • 2.8GHz base clock speed, or faster
  • SHA extensions instruction support
    • AMD Gen 3 or newer
    • Intel Ice Lake or newer
  • AVX2 instruction support (to use official release binaries, self-compile otherwise)
  • Support for AVX512f is helpful
• RAM
  • 256GB or more
  • Error Correction Code (ECC) memory is suggested
  • A motherboard with 512GB capacity suggested
• Disk
  • PCIe Gen3 x4 NVME SSD, or better
  • Accounts: 500GB, or larger. High TBW (Total Bytes Written)
  • Ledger: 1TB or higher. High TBW suggested
  • OS: (Optional) 500GB, or larger. SATA OK
  • The OS may be installed on the ledger disk, though testing has shown better performance with the ledger on its own disk
  • Accounts and ledger can be stored on the same disk, however, due to high IOPS, this is not recommended
  • The Samsung 970 and 980 Pro series SSDs are popular with the validator community

#Virtual machines on cloud platforms

While you can run a validator on a cloud computing platform, it may not be cost-efficient over the long term. However, it may be convenient to run non-voting API nodes on VM instances for your own internal usage. This use case includes exchanges and services built on Solana.

In fact, the mainnet-beta validators operated by the team are currently being run on GCE n2-standard-32 (32 vCPUs, 128 GB memory) instances with 2048 GB SSD for operational convenience.

For this demonstration, an AMD Blockchain server from Cherry Servers was used. For other cloud platforms, select server types with similar specs as mentioned in the server hardware specification section above.

#How to run a Solana node: Step-by-step process

#Step 1: Open the terminal program

To start this guide, you will be running commands on your trusted computer, not on the remote machine that you plan to use for validator operations. First, open the terminal program on your local computer. This demonstration uses an Ubuntu system and the terminal can be opened using CTRL + Alt + T.

#Step 2: Install Solana CLI locally

To create your validator vote account, you need to install the Solana command line interface on your local computer.

There are multiple ways of installing the Solana command line interface, as recorded in the documentation, but we are going to use the install tool for this demonstration.

💡 Building from source is a great option for those that want a more secure and potentially more performant executable.

In your terminal, run the following command:

sh -c "$(curl -sSfL https://release.solana.com/v1.16.8/install)"

You should get a similar output as below indicating a successful installation and a prompt asking you to either reopen your terminal or run a provided command in the existing shell to apply the PATH changes:

You can confirm that the Solana CLI has been successfully installed by running the following:

solana --version

Once you have successfully installed the CLI, the next step is to change the Solana CLI configuration so that it is making requests to the testnet cluster:

solana config set --url https://api.testnet.solana.com

To verify that the configuration has changed, run:

solana config get

#Step 3: Create keys

Next, you need to create the three keypairs that you will need to run your validator. Execute the following commands to create the keypairs:

solana-keygen new -o validator-keypair.json

solana-keygen new -o vote-account-keypair.json

solana-keygen new -o authorized-withdrawer-keypair.json

The commands above will generate three keypairs, one for a validator, one for a Vote account, and one for an authorized withdrawer, and then save them to the JSON files indicated in the commands.

Solana validators are responsible for maintaining the network and validating transactions. Vote accounts are used to select the validators and confirm the network's consensus and authorized withdrawers are entities allowed to withdraw funds from an account.

💡 Some operators choose to make vanity keypairs for their identity and their vote account using the grind subcommand.

#Step 4: Create a vote account and funding

Before you can create your vote account, you need to configure the Solana command line tool to use the validator keypair.

The command below sets the validator keypair you just created as the default one in the Solana configuration allowing the Solana CLI or subsequent commands to use it for authentication and other purposes:

solana config set --keypair ./validator-keypair.json

Now verify your account balance of 0:

solana balance

Next, you need to deposit some SOL into that keypair account in order to create a transaction (in this case, making your vote account):

solana airdrop 1

Now, you can use the Solana cluster to create a vote account. Note that all commands mentioned so far should be done on your trusted computer and NOT on a server where you intend to run your validator as you shouldn’t be creating your account credentials on just any computer:

solana create-vote-account -ut \    
	--fee-payer ./validator-keypair.json \    
	./vote-account-keypair.json \    
	./validator-keypair.json \    
	./authorized-withdrawer-keypair.json

This will create a new vote account with the provided parameters.

#Step 5: Create a server

Next, you need to set up your server on your preferred cloud platform with the required hardware specifications mentioned in the guide. As mentioned earlier, an AMD Blockchain server (Ubuntu 22.04) was used here.

You also need to partition the data storage into two distinct areas: the ledger partition and the account partition.

1. Ledger Partition: The ledger partition is where the actual blockchain data are stored. It contains all the transaction history, blocks, and other information that make up the Solana blockchain. Think of it as a giant record book that keeps track of every transaction ever made on the network. It is like the history book of the Solana blockchain.
2. Account Partition: The account partition, on the other hand, is where individual user accounts and their associated data are stored. Every user who interacts with the Solana network has their own account, which holds their balance, transaction history, and other relevant information. The account partition acts as a personal storage space for each user on the Solana blockchain.

By separating the ledger and account partitions, Solana aims to achieve scalability and performance.

Also read: How to run an Ethereum node

#Step 6: SSH to your validator

Next, SSH into your server using the appropriate command for your server provider. This will allow you to access and configure the validator remotely. The command should be in this format:

ssh user@<server.hostname>

Also read: How to deploy hybrid smart contracts

#Step 7: Update your Ubuntu packages

Now that you have access to the server, run the following command to update the system packages:

sudo apt update && sudo apt upgrade -y

#Step 8: Enable firewall

Next, create and enable a firewall on your virtual machine to allow incoming and outgoing traffic on the required ports (8000 - 10000 UDP/TCP). These ports are specific to testnet (so take care to update based on your desired cluster. Ensure you add all the allow rules (especially SSH) before enabling the firewall so as not to lock yourself out of the server. These firewall rules are based on the minimum necessary to operate a validator.

sudo ufw allow "OpenSSH"
sudo ufw allow 8000:10000/udp
sudo ufw allow 8000:10000/tcp
sudo ufw allow 8000/tcp
sudo ufw allow 8001/tcp
sudo ufw allow 8899/tcp
sudo ufw allow 8900/tcp
sudo ufw enable
sudo ufw status

You should get an output like in the image below:

Also read:How to run a Polygon node

#Step 9: Add a new user

Now create a new user on your server which will be running the validator service using the adduser command.

sudo adduser sol

This will create a new user named “sol” on the server.

#Hard Drive Setup

Next, on your Ubuntu server make sure that you have at least 2TB of disk space mounted. You can check disk space using the df command:

df -h

If you have a drive that is not mounted/formatted, you have to set up the partition and mount the drive.

To see the hard disk devices that you have available, use the list block devices command:

lsblk -f

You may see some devices in the list that have a name but do not have a Universally Unique Identifier (UUID). Any device without a UUID is unformatted.

#Step 10: Formatting and mounting the drives - for ledger & accounts

If you have an additional NVME drive for the ledger partition, format it using the mkfs command:

sudo mkfs -t ext4 /dev/nvme1n1

The device name and location may be different for your computer. After formatting the drive, you can run the lsblk -f command again to confirm that the device now has a UUID.

The devices on the server used in this demonstration have been formatted so to mount the drive, first create directories for mounting the drives (the nvme2n1 and nvme3n1 drives will be used ledger and accounts respectively) and change the ownership of the directories created to the “sol” user using the following command:

sudo mkdir -p /mnt/ledger
sudo chown -R sol:sol /mnt/ledger

sudo mkdir -p /mnt/accounts
sudo chown -R sol:sol /mnt/accounts

The commands above will create the “/mnt/ledger” and the “/mnt/accounts” directories respectively and change the ownership of the directories to the “sol” user.

Now you can mount the drives using:

sudo mount /dev/nvme2n1 /mnt/ledger
sudo mount /dev/nvme3n1 /mnt/accounts

#Step 11: System tuning

To ensure proper system performance and successful startup of the validator, it is important to optimize the system by modifying the sysctl knobs and increasing the systemd and session file limits. The provided commands should be followed to make these necessary changes:

Optimise sysctl knobs by running the following command:

sudo bash -c "cat >/etc/sysctl.d/21-solana-validator.conf <<EOF
# Increase UDP buffer sizes
net.core.rmem_default = 134217728
net.core.rmem_max = 134217728
net.core.wmem_default = 134217728
net.core.wmem_max = 134217728

# Increase memory mapped files limit
vm.max_map_count = 1000000

# Increase number of allowed open file descriptors
fs.nr_open = 1000000
EOF"

sudo sysctl -p /etc/sysctl.d/21-solana-validator.conf

Next, increase systemd and session file limits. To increase the systemd and session file limits, you'll need to modify systemd configuration files.

If you have a specific systemd service unit file for the Solana validator, you can add the LimitNOFILE=1000000 parameter to the [Service] section of that file.

If you don't have a specific service file but want to set the file limits for all systemd units, you can add the DefaultLimitNOFILE=1000000 parameter to the /etc/systemd/system.conf file. You can run the following command to open the system.conf file with the Nano text editor:

sudo nano /etc/systemd/system.conf

Find the [Manager] section and add or modify the DefaultLimitNOFILE parameter. Then save the file and exit the text editor.

Reload systemd to apply the change using:

sudo systemctl daemon-reload

Next, set the session file limit by running the following command:

sudo bash -c "cat >/etc/security/limits.d/90-solana-nofiles.conf <<EOF

* - nofile 1000000
EOF"

The commands above set Solana's process file descriptor count limit by creating a new configuration file at /etc/security/limits.d/90-solana-nofiles.conf and increase the process file descriptor count limit.

After tuning the system, close all open sessions (log out and then log in again).

#Step 12: Copy keypairs

Now, you need to copy the validator keypair and vote account keypair JSON files from your local computer to the virtual machine using the scpcommand. Run the following commands in the directory where you have the generated keypairs:

scp -C vote-account-keypair.json user@<server.hostname>:/home/sol
scp -C validator-keypair.json user@<server.hostname>:/home/sol

The commands above will securely copy the specified JSON files from the local machine to the remote server's “/home/sol” directory. The user@<server.hostname> portion should be replaced with the appropriate remote username and hostname.

After copying the keypairs to the remote server, ensure you change their ownership to the “sol” user, you can do that using:

sudo chown sol:sol validator-keypair.json
sudo chown sol:sol vote-account-keypair.json

#Step 13: Switch to the sol user

Switch back to terminal where you’ve SSHed into the remote server and switch to the sol user using:

su - sol

#Step 14: Install Solana CLI on remote machine

You will need to install the Solana CLI on the remote server to run the validator software. You can do that by running the following command:

sh -c "$(curl -sSfL https://release.solana.com/v1.16.8/install)"

#Step 15: Create a validator startup script

After installing the Solana CLI on the remote server, the next thing you need to do is create a startup script for your validator. Create a validator.sh file in the bin directory of the “sol” user by running the following commands:

mkdir -p /home/sol/bin
touch /home/sol/bin/validator.sh
chmod +x /home/sol/bin/validator.sh

The commands above will create a validator.sh file in the bin directory and also make it executable.

Next, using the nano editor, open the validator.sh file:

nano /home/sol/bin/validator.sh

Copy and paste the following contents into validator.sh then save the file:

exec solana-validator \
    --identity validator-keypair.json \
    --vote-account vote-account-keypair.json \
    --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
    --known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
    --known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
    --known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
    --only-known-rpc \
    --log /home/sol/solana-validator.log \
    --ledger /mnt/ledger \
    --rpc-port 8899 \
    --dynamic-port-range 8000-8020 \
    --entrypoint entrypoint.testnet.solana.com:8001 \
    --entrypoint entrypoint2.testnet.solana.com:8001 \
    --entrypoint entrypoint3.testnet.solana.com:8001 \
    --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-ledger-size

You can run solana-validator --help command for more information on what each flag is doing in this script. You can also refer to the section on best practices for operating a validator in the official Solana documentation.

#Step 16: Verifying your validator is working

Now to confirm that your validator.sh script is running properly, execute it using:

/home/sol/bin/validator.sh

This should execute the solana-validator process.

In another terminal window, SSH into your remote server and verify that the solana-validator process is running using the command:

ps aux | grep solana-validator

You should get an output that includes a line containing the solana-validator with all the flags that were added to the validator.sh script.

You can also view the logs at /home/sol/solana-validator.log to make sure everything is working correctly.

You can also monitor the contents of the solana-validator.log file in real-time. In a new terminal window, SSH into the remote server and run the following commands to switch to the “sol” user and monitor the content of the log file:

su - sol
tail -f solana-validator.log

This will continuously monitor the file for new data as it's added and they will be displayed in the terminal. You need to look out for lines that include _ERROR_, if you don’t see any, you can exit the command.

Next, you can verify that your validator is running correctly by checking if it has registered itself with the Gossip network. In a new terminal, SSH to your remote server, log in as the “sol” user and extract the public key which will be used to identify your validator node on the Solana network from the validator-keypair.json file by running the following command:

solana-keygen pubkey ~/validator-keypair.json

Then you can run the command below to display information related to the public key from the solana gossip output:

solana gossip | grep <pubkey>

Replace <pubkey with the public key of the validator node extracted earlier. If the validator has been registered on the Gossip network, you’d get an output similar to the one in the image below:

With the validator in the Gossip network, you can also confirm that the validator has joined the network using the following command:

solana validators | grep <pubkey>

You should get an output as in the image below if it has joined the network.

You can also see how quickly your validator is processing blocks using the solana catchup command:

solana catchup <pubkey>

Also read: What is a blockchain server?

#Conclusion

In this guide, we defined the Solana node requirements and provided step-by-step instructions on how to run a Solana validator node. From installing the Solana CLI to creating a validator startup script, we defined the essential parameters such as identity, vote account, known validators, log and ledger paths, RPC port, entry points, and expected genesis hash. This guide emphasizes the significance of verifying that the validator is working correctly by executing the startup script and checking the process status.

Running a Solana validator node can be a rewarding experience and at this point, you should have a better understanding of what it takes to run a Solana node. You can take advantage of this knowledge and contribute to the Solana network while also earning rewards for yourself.