Validator Guide: Starting a Validator | Solana Validator (2024)

Configure Solana CLI​

The solana cli includes get and set configuration commands to automaticallyset the --url argument for cli commands. For example:

solana config set --url http://api.devnet.solana.com

While this section demonstrates how to connect to the Devnet cluster, the stepsare similar for the other Solana Clusters.

Confirm The Cluster Is Reachable​

Before attaching a validator node, sanity check that the cluster is accessibleto your machine by fetching the transaction count:

solana transaction-count

View the metrics dashboard for moredetail on cluster activity.

Enabling CUDA​

If your machine has a GPU with CUDA installed (Linux-only currently), includethe --cuda argument to solana-validator.

When your validator is started look for the following log message to indicatethat CUDA is enabled: "[<timestamp> solana::validator] CUDA is enabled"

System Tuning​

Linux​

If you would prefer to manage system settings on your own, you may do so withthe following commands.

Optimize sysctl knobs​

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

Increase systemd and session file limits​

Add

LimitNOFILE=1000000

to the [Service] section of your systemd service file, if you use one,otherwise add

DefaultLimitNOFILE=1000000

to the [Manager] section of /etc/systemd/system.conf.

sudo systemctl daemon-reload

sudo bash -c "cat >/etc/security/limits.d/90-solana-nofiles.conf <<EOF
# Increase process file descriptor count limit
* - nofile 1000000
EOF"

### Close all open sessions (log out then, in again) ###

System Clock​

Large system clock drift can prevent a node from properly participating in Solana's gossip protocol. Ensure that your system clock is accurate. To check the current system clock, use:

timedatectl

Operators commonly use an ntp server to maintain an accurate system clock.

Generate identity​

Create an identity keypair for your validator by running:

solana-keygen new -o ~/validator-keypair.json

The identity public key can now be viewed by running:

solana-keygen pubkey ~/validator-keypair.json

Note: The "validator-keypair.json” file is also your (ed25519) private key.

Paper Wallet identity​

You can create a paper wallet for your identity file instead of writing thekeypair file to disk with:

solana-keygen new --no-outfile

The corresponding identity public key can now be viewed by running:

solana-keygen pubkey ASK

and then entering your seed phrase.

See Paper Wallet Usage for more info.

Vanity Keypair​

You can generate a custom vanity keypair using solana-keygen. For instance:

solana-keygen grind --starts-with e1v1s:1

You may request that the generated vanity keypair be expressed as a seed phrasewhich allows recovery of the keypair from the seed phrase and an optionallysupplied passphrase (note that this is significantly slower than grinding withouta mnemonic):

solana-keygen grind --use-mnemonic --starts-with e1v1s:1

Depending on the string requested, it may take days to find a match...

Your validator identity keypair uniquely identifies your validator within thenetwork. It is crucial to back-up this information.

If you don’t back up this information, you WILL NOT BE ABLE TO RECOVER YOURVALIDATOR if you lose access to it. If this happens, YOU WILL LOSE YOURALLOCATION OF SOL TOO.

To back-up your validator identify keypair, back-up your"validator-keypair.json” file or your seed phrase to a secure location.

More Solana CLI Configuration​

Now that you have a keypair, set the solana configuration to use your validatorkeypair for all following commands:

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

You should see the following output:

Config File: /home/solana/.config/solana/cli/config.yml
RPC URL: http://api.devnet.solana.com
WebSocket URL: ws://api.devnet.solana.com/ (computed)
Keypair Path: /home/solana/validator-keypair.json
Commitment: confirmed

Airdrop & Check Validator Balance​

Airdrop yourself some SOL to get started:

solana airdrop 1

Note that airdrops are only available on Devnet and Testnet. Both are limitedto 1 SOL per request.

To view your current balance:

solana balance

Or to see in finer detail:

solana balance --lamports

Read more about the difference between SOL and lamports here.

Create Authorized Withdrawer Account​

If you haven't already done so, create an authorized-withdrawer keypair to be usedas the ultimate authority over your validator. This keypair will have theauthority to withdraw from your vote account, and will have the additionalauthority to change all other aspects of your vote account. Needless to say,this is a very important keypair as anyone who possesses it can make anychanges to your vote account, including taking ownership of it permanently.So it is very important to keep your authorized-withdrawer keypair in a safelocation. It does not need to be stored on your validator, and should not bestored anywhere from where it could be accessed by unauthorized parties. Tocreate your authorized-withdrawer keypair:

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

Create Vote Account​

If you haven’t already done so, create a vote-account keypair and create thevote account on the network. If you have completed this step, you should see the“vote-account-keypair.json” in your Solana runtime directory:

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

The following command can be used to create your vote account on the blockchainwith all the default options:

solana create-vote-account ~/vote-account-keypair.json ~/validator-keypair.json ~/authorized-withdrawer-keypair.json

Remember to move your authorized withdrawer keypair into a very secure location after running the above command.

Read more about creating and managing a vote account.

Known validators​

If you know and respect other validator operators, you can specify this on the command line with the --known-validator <PUBKEY>argument to solana-validator. You can specify multiple ones by repeating the argument --known-validator <PUBKEY1> --known-validator <PUBKEY2>.This has two effects, one is when the validator is booting with --only-known-rpc, it will only ask that set ofknown nodes for downloading genesis and snapshot data. Another is that in combination with the --halt-on-known-validators-accounts-hash-mismatch option,it will monitor the merkle root hash of the entire accounts state of other known nodes on gossip and if the hashes produce any mismatch,the validator will halt the node to prevent the validator from voting or processing potentially incorrect state values. At the moment, the slot thatthe validator publishes the hash on is tied to the snapshot interval. For the feature to be effective, all validators in the knownset should be set to the same snapshot interval value or multiples of the same.

It is highly recommended you use these options to prevent malicious snapshot state download oraccount state divergence.

Connect Your Validator​

Connect to the cluster by running:

solana-validator \
 --identity ~/validator-keypair.json \
 --vote-account ~/vote-account-keypair.json \
 --rpc-port 8899 \
 --entrypoint entrypoint.devnet.solana.com:8001 \
 --limit-ledger-size \
 --log ~/solana-validator.log

To force validator logging to the console add a --log - argument, otherwisethe validator will automatically log to a file.

The ledger will be placed in the ledger/ directory by default, use the--ledger argument to specify a different location.

Note: You can use apaper wallet seed phrasefor your --identity and/or--authorized-voter keypairs. To use these, pass the respective argument assolana-validator --identity ASK ... --authorized-voter ASK ...and you will be prompted to enter your seed phrases and optional passphrase.

Confirm your validator is connected to the network by opening a new terminal andrunning:

solana gossip

If your validator is connected, its public key and IP address will appear in the list.

Controlling local network port allocation​

By default the validator will dynamically select available network ports in the8000-10000 range, and may be overridden with --dynamic-port-range. Forexample, solana-validator --dynamic-port-range 11000-11020 ... will restrictthe validator to ports 11000-11020.

Limiting ledger size to conserve disk space​

The --limit-ledger-size parameter allows you to specify how many ledgershreds your node retains on disk. If you do notinclude this parameter, the validator will keep all received ledger datauntil it runs out of disk space. Otherwise, the validator will continuallypurge the oldest data once to stay under the specified --limit-ledger-sizevalue.

The default value attempts to keep the blockstore (data within the rocksdbdirectory) disk usage under 500 GB. More or less disk usage may be requestedby adding an argument to --limit-ledger-size if desired. More informationabout selecting a custom limit value is availablehere.

Note that the above target of 500 GB does not account for other items thatmay reside in the ledger directory, depending on validator configuration.These items may include (but are not limited to):

• Persistent accounts data
• Persistent accounts index
• Snapshots

Systemd Unit​

Running the validator as a systemd unit is one easy way to manage running in thebackground.

Assuming you have a user called sol on your machine, create the file /etc/systemd/system/sol.service withthe following:

[Unit]
Description=Solana Validator
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=sol
LimitNOFILE=1000000
LogRateLimitIntervalSec=0
Environment="PATH=/bin:/usr/bin:/home/sol/.local/share/solana/install/active_release/bin"
ExecStart=/home/sol/bin/validator.sh

[Install]
WantedBy=multi-user.target

Now create /home/sol/bin/validator.sh to include the desiredsolana-validator command-line. Ensure that the 'exec' command is used tostart the validator process (i.e. "exec solana-validator ..."). This isimportant because without it, logrotate will end up killing the validatorevery time the logs are rotated.

Ensure that running /home/sol/bin/validator.sh manually startsthe validator as expected. Don't forget to mark it executable with chmod +x /home/sol/bin/validator.sh

Start the service with:

sudo systemctl enable --now sol

Logging​

Log output tuning​

The messages that a validator emits to the log can be controlled by the RUST_LOGenvironment variable. Details can by found in the documentationfor the env_logger Rust crate.

Note that if logging output is reduced, this may make it difficult to debug issuesencountered later. Should support be sought from the team, any changes will needto be reverted and the issue reproduced before help can be provided.

Log rotation​

The validator log file, as specified by --log ~/solana-validator.log, can getvery large over time and it's recommended that log rotation be configured.

The validator will re-open its log file when it receives the USR1 signal, which is thebasic primitive that enables log rotation.

If the validator is being started by a wrapper shell script, it is important tolaunch the process with exec (exec solana-validator ...) when using logrotate.This will prevent the USR1 signal from being sent to the script's processinstead of the validator's, which will kill them both.

Using logrotate​

An example setup for the logrotate, which assumes that the validator isrunning as a systemd service called sol.service and writes a log file at/home/sol/solana-validator.log:

# Setup log rotation

cat > logrotate.sol <<EOF
/home/sol/solana-validator.log {
 rotate 7
 daily
 missingok
 postrotate
 systemctl kill -s USR1 sol.service
 endscript
}
EOF
sudo cp logrotate.sol /etc/logrotate.d/sol
systemctl restart logrotate.service

As mentioned earlier, be sure that if you use logrotate, any script you createwhich starts the solana validator process uses "exec" to do so (example: "execsolana-validator ..."); otherwise, when logrotate sends its signal to thevalidator, the enclosing script will die and take the validator process withit.

Using a ramdisk with spill-over into swap for the accounts database to reduce SSD wear​

If your machine has plenty of RAM, a tmpfs ramdisk(tmpfs) may be used to holdthe accounts database

When using tmpfs it's essential to also configure swap on your machine as well toavoid running out of tmpfs space periodically.

A 300GB tmpfs partition is recommended, with an accompanying 250GB swappartition.

Example configuration:

1. sudo mkdir /mnt/solana-accounts
2. Add a 300GB tmpfs partition by adding a new line containing tmpfs /mnt/solana-accounts tmpfs rw,size=300G,user=sol 0 0 to /etc/fstab(assuming your validator is running under the user "sol"). CAREFUL: If youincorrectly edit /etc/fstab your machine may no longer boot
3. Create at least 250GB of swap space

• Choose a device to use in place of SWAPDEV for the remainder of these instructions.Ideally select a free disk partition of 250GB or greater on a fast disk. If one is notavailable, create a swap file with sudo dd if=/dev/zero of=/swapfile bs=1MiB count=250KiB,set its permissions with sudo chmod 0600 /swapfile and use /swapfile as SWAPDEV forthe remainder of these instructions
• Format the device for usage as swap with sudo mkswap SWAPDEV

4. Add the swap file to /etc/fstab with a new line containing SWAPDEV swap swap defaults 0 0
5. Enable swap with sudo swapon -a and mount the tmpfs with sudo mount /mnt/solana-accounts/
6. Confirm swap is active with free -g and the tmpfs is mounted with mount

Now add the --accounts /mnt/solana-accounts argument to your solana-validatorcommand-line arguments and restart the validator.

Account indexing​

As the number of populated accounts on the cluster grows, account-data RPCrequests that scan the entire account set -- likegetProgramAccounts andSPL-token-specific requests --may perform poorly. If your validator needs to support any of these requests,you can use the --account-index parameter to activate one or more in-memoryaccount indexes that significantly improve RPC performance by indexing accountsby the key field. Currently supports the following parameter values:

• program-id: each account indexed by its owning program; used by getProgramAccounts
• spl-token-mint: each SPL token account indexed by its token Mint; used by getTokenAccountsByDelegate, and getTokenLargestAccounts
• spl-token-owner: each SPL token account indexed by the token-owner address; used by getTokenAccountsByOwner, and getProgramAccounts requests that include an spl-token-owner filter.