blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[docs] Validator guidebook incorporated into docs (#31660) 

* docs: adding multiple pages in from the guidebook

* fix: minor updates to the rpc node setup page

* fix: added known validators info to the rpc page

* docs: added best practices pages

* fix: updated internal linking

* docs: added faq page and update links

* Expanding the validator FAQ, updating hardware req

* Updates to validator setup

* Fixed broken RPC API links

* Remove GPU reqs, clarify install best practices

* Updating neworking requirements in validator reqs

* Removing trailing white spaces

* Removing systuner usage from docs

* ssh authentication note, more on withdrawls

* Adding feedback from educational workshop

* Details on system clock, cpu freq, validator set

* add link to gossip for clock drift system req

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* Update docs/src/validator/best-practices/monitoring.md

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* clarification on monitoring docs

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* adding a reference to the hardware requirements

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* fixing link to clusters page

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* typo fix

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* Update docs/src/validator/get-started/setup-a-validator.md

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* Update docs/src/validator/best-practices/monitoring.md

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* Update docs/src/validator/best-practices/monitoring.md

Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>

* Referencing the validator health report

* Removed trailing whitespace

---------

Co-authored-by: nickfrosty <nfrostbutter@gmail.com>
Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com>
This commit is contained in:
Tim Garcia 2023-06-13 12:11:37 -07:00 committed by GitHub
parent 3fc183ca74
commit bcacb32cbc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
16 changed files with 1116 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
docs/sidebars.js
View File

@ -328,11 +328,38 @@ module.exports = {
],
validatorsSidebar: [
"running-validator",
"validator/faq",
{
type: "category",
label: "Introduction",
collapsed: false,
items: [
"validator/overview/what-is-a-validator",
"validator/overview/what-is-an-rpc-node",
"validator/overview/running-validator-or-rpc-node",
"validator/overview/validator-prerequisites",
"validator/overview/validator-initiatives",
],
},
{
type: "category",
label: "Getting Started",
collapsed: false,
items: ["running-validator/validator-reqs"],
items: [
"running-validator/validator-reqs",
"validator/get-started/setup-a-validator",
"validator/get-started/setup-an-rpc-node",
],
},
{
type: "category",
label: "Best Practices",
collapsed: false,
items: [
"validator/best-practices/operations",
"validator/best-practices/monitoring",
"validator/best-practices/security",
],
},
{
type: "category",

53
docs/src/index.mdx
View File

@ -3,51 +3,62 @@ slug: /
id: home
title: Home
sidebar_label: Home
description:
"Solana is a high performance network that is utilized for a range of use cases, \
description: "Solana is a high performance network that is utilized for a range
of use cases, \
including finance, NFTs, payments, and gaming."
# displayed_sidebar: introductionSidebar
---
# Solana Documentation
Solana is a blockchain built for mass adoption. It's a high performance network that is utilized for
a range of use cases, including finance, NFTs, payments, and gaming. Solana operates as a single
global state machine, and is open, interoperable and decentralized.
Solana is a blockchain built for mass adoption. It's a high performance network
that is utilized for a range of use cases, including finance, NFTs, payments,
and gaming. Solana operates as a single global state machine, and is open,
interoperable and decentralized.
## Getting started
Dive right into Solana to start building or setup your tooling.
- [Setup local environment](/cli) - Install the Solana CLI to get your local development environment setup
- [Hello World in your browser](getstarted/hello-world) - Build and deploy your first on-chain Solana program,
directly in your browser using Solana Playground
- [Setup local environment](/cli) - Install the Solana CLI to get your local
development environment setup
- [Hello World in your browser](getstarted/hello-world) - Build and deploy your
first on-chain Solana program, directly in your browser using Solana
Playground
## Start learning
Build a strong understanding of the core concepts that make Solana different from other blockchains.
Build a strong understanding of the core concepts that make Solana different
from other blockchains.
- [Transactions](./developing/programming-model/transactions) - Collection of instructions for the blockchain to execute
- [Accounts](./developing/programming-model/accounts) - Data and state storage mechanism for Solana
- [Programs](./developing/intro/programs) - The executable code used to perform actions on the blockchain
- [Cross-Program Invocation](./developing/programming-model/calling-between-programs) - Core of the "composability"
of Solana, this is how programs can "call" each other.
- [Transactions](./developing/programming-model/transactions) - Collection of
instructions for the blockchain to execute
- [Accounts](./developing/programming-model/accounts) - Data and state storage
mechanism for Solana
- [Programs](./developing/intro/programs) - The executable code used to perform
actions on the blockchain
- [Cross-Program Invocation](./developing/programming-model/calling-between-programs) -
Core of the "composability" of Solana, this is how programs can "call" each
other.
## Understanding the architecture
Get to know the underlying architecture of how the proof-of-stake blockchain works.
Get to know the underlying architecture of how the proof-of-stake blockchain
works.
- [Validators](./validator/anatomy) - the individual nodes that are the backbone of the network
- [Clusters](./cluster/overview) - a collection of validators that work together for consensus
- [Validators](./validator/anatomy) - the individual nodes that are the backbone
of the network
- [Clusters](./cluster/overview) - a collection of validators that work together
for consensus
## Running a validator
Explore what it takes to operate a Solana validator and help secure the network.
- [System requirements](./running-validator/validator-reqs) - Recommended hardware requirements and expected SOL
needed to operate a validator
- [Quick start guide](./running-validator/validator-start) - Setup a validator and get connected to a cluster
for the first time
- [System requirements](./running-validator/validator-reqs) - Recommended
hardware requirements and expected SOL needed to operate a validator
- [Quick start guide](./validator/get-started/setup-a-validator) - Setup a
validator and get connected to a cluster for the first time
## Learn more

2
docs/src/integrations/exchange.md
View File

@ -79,6 +79,8 @@ Discord, or Twillio. For details, run `solana-watchtower --help`.
solana-watchtower --validator-identity <YOUR VALIDATOR IDENTITY>
```
> You can find more information about the [best practices for Solana Watchtower](../validator/best-practices/monitoring.md#solana-watchtower) here in the docs.
#### New Software Release Announcements
We release new software frequently (around 1 release / week).

33
docs/src/running-validator/validator-reqs.md
View File

@ -13,16 +13,21 @@ transaction for each block the validator agrees with, which can cost up to
## Hardware Recommendations
The hardware recommendations below are provided as a guide. Operators are encouraged to do their own performance testing.
- CPU
- 12 cores / 24 threads, or more
- 2.8GHz, or faster
- 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 and/or SHA-NI instructions is helpful
- The AMD Zen3 series is popular with the validator community
- Support for AVX512f is helpful
- RAM
- 128GB, or more
- Motherboard with 256GB capacity suggested
- 256GB or more
- Error Correction Code (ECC) memory is suggested
- Motherboard with 512GB capacity suggested
- Disk
- PCIe Gen3 x4 NVME SSD, or better
- Accounts: 500GB, or larger. High TBW (Total Bytes Written)
@ -34,11 +39,11 @@ transaction for each block the validator agrees with, which can cost up to
IOPS, this is not recommended
- The Samsung 970 and 980 Pro series SSDs are popular with the validator community
- GPUs
- Not strictly necessary at this time
- Motherboard and power supply speced to add one or more high-end GPUs in the
future suggested
- Not necessary at this time
- Operators in the validator community do no use GPUs currently
### RPC Node Recommendations
The [hardware recommendations](#hardware-recommendations) above should be considered
bare minimums if the validator is intended to be employed as an RPC node. To provide
full functionality and improved reliability, the following adjustments should be
@ -47,7 +52,7 @@ made.
- CPU
- 16 cores / 32 threads, or more
- RAM
- 256 GB, or more
- 512 GB or more if `account-index` is used
- Disk
- Consider a larger ledger disk if longer transaction history is required
- Accounts and ledger should not be stored on the same disk
@ -89,7 +94,7 @@ Prebuilt binaries are available for Linux x86_64 on CPUs supporting AVX2 \(Ubunt
MacOS or WSL users may build from source.
## Networking
Internet service should be at least 300Mbit/s symmetric, commercial. 1GBit/s preferred
Internet service should be at least 1GBbit/s symmetric, commercial. 10GBit/s preferred.
### Port Forwarding
The following ports need to be open to the internet for both inbound and outbound
@ -106,10 +111,4 @@ be limited to any free 13 port range with `--dynamic-port-range`
For security purposes, it is not suggested that the following ports be open to
the internet on staked, mainnet-beta validators.
- 8899 TCP - JSONRPC over HTTP. Change with `--rpc-port RPC_PORT``
- 8900 TCP - JSONRPC over Websockets. Derived. Uses `RPC_PORT + 1`
## GPU Requirements
CUDA is required to make use of the GPU on your system. The provided Solana
release binaries are built on Ubuntu 20.04 with [CUDA Toolkit 10.1 update 1](https://developer.nvidia.com/cuda-toolkit-archive). If your machine is using
a different CUDA version then you will need to rebuild from source.
- 8900 TCP - JSONRPC over Websockets. Derived. Uses `RPC_PORT + 1`

10
docs/src/running-validator/validator-start.md
View File

@ -95,6 +95,16 @@ 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](../validator/gossip.md). Ensure that your system clock is accurate. To check the current system clock, use:
```bash
timedatectl
```
Operators commonly use an ntp server to maintain an accurate system clock.
## Generate identity
Create an identity keypair for your validator by running:

85
docs/src/validator/best-practices/monitoring.md Normal file
View File

@ -0,0 +1,85 @@
---
title: Validator Monitoring Best Practices
sidebar_label: Monitoring
---
It is essential that you have monitoring in place on your validator. In the event that your validator is delinquent (behind the rest of the network) you want to respond immediately to fix the issue. One very useful tool to monitor your validator is [`solana-watchtower`](#solana-watchtower).
## Solana Watchtower
Solana Watchtower is an extremely useful monitoring tool that will regularly monitor the health of your validator. It can monitor your validator for delinquency then notify you on your application of choice: Slack, Discord, Telegram or Twilio. Additionally, `solana-watchtower` has the ability to monitor the health of the entire cluster so that you can be aware of any cluster wide problems.
### Getting Started
To get started with Solana Watchtower, run `solana-watchtower --help`. From the help menu, you can see the optional flags and an explanation of the command.
Here is a sample command that will monitor a validator node with an identity public key of `2uTk98rqqwENevkPH2AHHzGHXgeGc1h6ku8hQUqWeXZp`:
```
solana-watchtower --monitor-active-stake --validator-identity \
2uTk98rqqwENevkPH2AHHzGHXgeGc1h6ku8hQUqWeXZp
```
The command will monitor your validator, but you will not get notifications unless you added the environment variables mentioned in `solana-watchtower --help`. Since getting each of these services setup for notifications is not straight forward, the next section will walk through [setting up watchtower notifications on Telegram](#setup-telegram-notifications).
### Best Practices
It is a best practice to run the `solana-watchtower` command on a separate server from your validator.
In the case that you run `solana-watchtower` on the same computer as your `solana-validator` process, then during catastrophic events like a power outage, you will not be aware of the issue, because your `solana-watchtower` process will stop at the same time as your `solana-validator` process.
Additionally, while running the `solana-watchtower` process manually with environment variables set in the terminal is a good way to test out the command, it is not operationally sound because the process will not be restarted when the terminal closes or during a system restart.
Instead, you could run your `solana-watchtower` command as a system process similar to `solana-validator`. In the system process file, you can specify the environment variables for your bot.
### Setup Telegram Notifications
To send validator health notifications to your Telegram account, we are going to do a few things:
1. Create a bot to send the messages. The bot will be created using BotFather on Telegram
2. Send a message to the bot
3. Create a Telegram group that will get the watchtower notifications
4. Add the environment variables to your command line environment
5. Restart the `solana-watchtower` command
#### Create a Bot Using BotFather
In Telegram, search for `@BotFather`. Send the following message to _@BotFather_: `/newbot`.
Now you will have to come up with a name for the bot. The only requirement is that it cannot have dashes or spaces, and it **must** end in the word `bot`. Many names have already been taken, so you may have to try a few. Once you find an available name, you will get a response from _@BotFather_ that includes a link to chat with the bot as well as a token for the bot. Take note of the token. You will need it when you setup your environment variables.
#### Send a Message to The Bot
Find the bot in Telegram and send it the following message: `/start`. Messaging the bot will help you later when looking for the bot chatroom id.
#### Create Telegram Group
In Telegram, click on the new message icon and then select new group. Find your newly created bot and add the bot to the group. Next, name the group whatever you'd like.
#### Set Environment Variables For Watchtower
Now that you have a bot setup, you will need to set the environment variables for the bot so that watchtower can send notifications.
First, recall the chat message that you got from _@BotFather_. In the message, there was an HTTP API token for your bot. The token will have this format: `389178471:MMTKMrnZB4ErUzJmuFIXTKE6DupLSgoa7h4o`. You will use that token to set the `TELEGRAM_BOT_TOKEN` environment variable. In the terminal where you plan to run `solana-watchtower`, run the following:
```
export TELEGRAM_BOT_TOKEN=<HTTP API Token>
```
Next, you need the chat id for your group so that `solana-watcher` knows where to send the message. First, send a message to your bot in the chat group that you created. Something like `@newvalidatorbot hello`.
Next, in your browser, go to `https://api.telegram.org/bot<HTTP API Token>/getUpdates`. Make sure to replace `<HTTP API TOKEN>` with your API token that you got in the _@BotFather_ message. Also make sure that you include the word `bot` in the URL before the API token. Make the request in the browser.
The response should be in JSON. Search for the string `"chat":` in the JSON. The `id` value of that chat is your `TELEGRAM_CHAT_ID`. It will be a negative number like: `-781559558`. Remember to include the negative sign! If you cannot find `"chat":` in the JSON, then you may have to remove the bot from your chat group and add it again.
With your Telegram chat id in hand, export the environment variable where you plan to run `solana-watchtower`:
```
export TELEGRAM_CHAT_ID=<negative chat id number>
```
#### Restart solana-watchtower
Once your environment variables are set, restart `solana-watchtower`. You should see output about your validator.
To test that your Telegram configuration is working properly, you could stop your validator briefly until it is labeled as delinquent. Up to a minute after the validator is delinquent, you should receive a message in the Telegram group from your bot. Start the validator again and verify that you get another message in your Telegram group from the bot. The message should say `all clear`.

148
docs/src/validator/best-practices/operations.md Normal file
View File

@ -0,0 +1,148 @@
---
title: Validator Operations Best Practices
sidebar_label: General Operations
---
After you have successfully setup and started a [validator on testnet](../get-started/setup-a-validator.md) (or another cluster of your choice), you will want to become familiar with how to operate your validator on a day-to-day basis. During daily operations, you will be [monitoring your server](./monitoring.md), updating software regularly (both the Solana validator software and operating system packages), and managing your vote account and identity account.
All of these skills are critical to practice. Maximizing your validator uptime is an important part of being a good operator.
## Educational Workshops
The Solana validator community holds regular educational workshops. You can watch past workshops through the [solana validator educational workshops playlist](https://www.youtube.com/watch?v=86zySQ5vGW8&list=PLilwLeBwGuK6jKrmn7KOkxRxS9tvbRa5p).
## Help with the validator command line
From within the Solana CLI, you can execute the `solana-validator` command with the `--help` flag to get a better understanding of the flags and sub commands available.
```
solana-validator --help
```
## Restarting your validator
There are many operational reasons you may want to restart your validator. As a best practice, you should avoid a restart during a leader slot. A [leader slot](../../terminology.md#leader-schedule) is the time when your validator is expected to produce blocks. For the health of the cluster and also for your validator's ability to earn transaction fee rewards, you do not want your validator to be offline during an opportunity to produce blocks.
To see the full leader schedule for an epoch, use the following command:
```
solana leader-schedule
```
Based on the current slot and the leader schedule, you can calculate open time windows where your validator is not expected to produce blocks.
Assuming you are ready to restart, you may use the `solana-validator exit` command. The command exits your validator process when an appropriate idle time window is reached. Assuming that you have systemd implemented for your validator process, the validator should restart automatically after the exit. See the below help command for details:
```
solana-validator exit --help
```
## Upgrading
There are many ways to upgrade the [Solana software](../../cli/install-solana-cli-tools.md). As an operator, you will need to upgrade often, so it is important to get comfortable with this process.
> **Note** validator nodes do not need to be offline while the newest version is being downloaded or built from source. All methods below can be done before the validator process is restarted.
### Building From Source
It is a best practice to always build your Solana binaries from source. If you build from source, you are certain that the code you are building has not been tampered with before the binary was created. You may also be able to optimize your `solana-validator` binary to your specific hardware.
If you build from source on the validator machine (or a machine with the same CPU), you can target your specific architecture using the `-march` flag. Refer to the Solana docs for [instructions on building from source](../../cli/install-solana-cli-tools.md#build-from-source).
### solana-install
If you are not comfortable building from source, or you need to quickly install a new version to test something out, you could instead try using the `solana-install` command.
Assuming you want to install Solana version `1.14.17`, you would execute the following:
```
solana-install init 1.14.17
```
This command downloads the executable for `1.14.17` and installs it into a `.local` directory. You can also look at `solana-install --help` for more options.
> **Note** this command only works if you already have the solana cli installed. If you do not have the cli installed, refer to [install solana cli tools](../../cli/install-solana-cli-tools.md)
### Restart
For all install methods, the validator process will need to be restarted before the newly installed version is in use. Use `solana-validator exit` to restart your validator process.
### Verifying version
The best way to verify that your validator process has changed to the desired version is to grep the logs after a restart. The following grep command should show you the version that your validator restarted with:
```
grep -B1 'Starting validator with' <path/to/logfile>
```
## Snapshots
Validators operators who have not experienced significant downtime (multiple hours of downtime), should avoid downloading snapshots. It is important for the health of the cluster as well as your validator history to maintain the local ledger. Therefore, you should not download a new snapshot any time your validator is offline or experiences an issue. Downloading a snapshot should only be reserved for occasions when you do not have local state. Prolonged downtime or the first install of a new validator are examples of times when you may not have state locally. In other cases such as restarts for upgrades, a snapshot download should be avoided.
To avoid downloading a snapshot on restart, add the following flag to the `solana-validator` command:
```
--no-snapshot-fetch
```
If you use this flag with the `solana-validator` command, make sure that you run `solana catchup <pubkey>` after your validator starts to make sure that the validator is catching up in a reasonable time. After some time (potentially a few hours), if it appears that your validator continues to fall behind, then you may have to download a new snapshot.
### Downloading Snapshots
If you are starting a validator for the first time, or your validator has fallen too far behind after a restart, then you may have to download a snapshot.
To download a snapshot, you must **_NOT_** use the `--no-snapshot-fetch` flag. Without the flag, your validator will automatically download a snapshot from your known validators that you specified with the `--known-validator` flag.
If one of the known validators is downloading slowly, you can try adding the `--minimal-snapshot-download-speed` flag to your validator. This flag will switch to another known validator if the initial download speed is below the threshold that you set.
### Manually Downloading Snapshots
In the case that there are network troubles with one or more of your known validators, then you may have to manually download the snapshot. To manually download a snapshot from one of your known validators, first, find the IP address of the validator in using the `solana gossip` command. In the example below, `5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on` is the pubkey of one of my known validators:
```
solana gossip | grep 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on
```
The IP address of the validators is `139.178.68.207` and the open port on this validator is `80`. You can see the IP address and port in the fifth column in the gossip output:
```
139.178.68.207 | 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on | 8001 | 8004 | 139.178.68.207:80 | 1.10.27 | 1425680972
```
Now that the IP and port are known, you can download a full snapshot or an incremental snapshot:
```
wget --trust-server-names http://139.178.68.207:80/snapshot.tar.bz2
wget --trust-server-names http://139.178.68.207:80/incremental-snapshot.tar.bz2
```
Now move those files into your snapshot directory. If you have not specified a snapshot directory, then you should put the files in your ledger directory.
Once you have a local snapshot, you can restart your validator with the `--no-snapshot-fetch` flag.
## Regularly Check Account Balances
It is important that you do not accidentally run out of funds in your identity account, as your node will stop voting. It is also important to note that this account keypair is the most vulnerable of the three keypairs in a vote account because the keypair for the identity account is stored on your validator when running the `solana-validator` software. How much SOL you should store there is up to you. As a best practice, make sure to check the account regularly and refill or deduct from it as needed. To check the account balance do:
```
solana balance validator-keypair.json
```
> **Note** `solana-watchtower` can monitor for a minimum validator identity balance. See [monitoring best practices](./monitoring.md) for details.
## Withdrawing From The Vote Account
As a reminder, your withdrawer's keypair should **_NEVER_** be stored on your server. It should be stored on a hardware wallet, paper wallet, or multisig mitigates the risk of hacking and theft of funds.
To withdraw your funds from your vote account, you will need to run `solana withdraw-from-vote-account` on a trusted computer. For example, on a trusted computer, you could withdraw all of the funds from your vote account (excluding the rent exempt minimum). The below example assumes you have a separate keypair to store your funds called `person-keypair.json`
```
solana withdraw-from-vote-account \
vote-account-keypair.json \
person-keypair.json ALL \
--authorized-withdrawer authorized-withdrawer-keypair.json
```
To get more information on the command, use `solana withdraw-from-vote-account --help`.
For a more detailed explanation of the different keypairs and other related operations refer to [vote account management](../../running-validator/vote-accounts.md).

47
docs/src/validator/best-practices/security.md Normal file
View File

@ -0,0 +1,47 @@
---
title: Validator Security Best Practices
sidebar_label: Security
---
Being a system administrator for an Ubuntu computer requires technical knowledge of the system and best security practices. The following list should help you get started and is considered the bare minimum for keeping your system safe.
## Keep Your System Up To Date
Make sure to regularly update packages in your Ubuntu system. Out of date packages may contain known security vulnerabilities that a hacker could exploit. A good practice would be to update weekly at least. To update your system, do the following:
```
sudo apt update
sudo apt upgrade
```
## DO NOT Store Your Withdrawer Key On Your Validator Machine
Your withdrawer key gives the operator full control of the vote account. It is highly sensitive information and should not be stored on the validator itself.
There are a number of options for withdrawer key management. Some operators choose to use hardware wallets or paper wallets for the withdrawer keypair. Another option is a multisig where each key of the miltisig is a hardware wallet or paper wallet. Whichever option you choose, make sure the authorized withdrawer key is stored securely and that it has been generated on a trusted computer (other than your validator computer).
To reiterate, the withdrawer keypair should never be stored on your validator at any time.
## DO NOT Run The Solana Validator as a Root User
It may be easier to get started by running your application as root, but it is a bad practice.
If there is an exploit in your system, a hacker could have full access if your Solana application is running as the `root` user. Instead, see the [setup instructions](../get-started/setup-a-validator.md#sol-user) for creating a user called `sol` and running the application as the `sol` user.
## Close Ports That Are Not In Use
Your system should close all ports that do not need to be open to the outside world. A common firewall for closing ports is `ufw` (uncomplicated firewall). You can find a guide to using `ufw` from [Digital Ocean](https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands).
## Eliminate Brute Force Attacks With fail2ban
[fail2ban](https://github.com/fail2ban/fail2ban) is a network security tool that checks your logs for suspicious login attempts and bans those IP addresses after repeated attempts. This will help mitigate brute force attacks on your serve.
The default setup should work out-of-the-box by doing the simply installing `fail2ban`:
```
sudo apt install fail2ban
```
## DO NOT Use Password Authentication for SSH
In addition to installing `fail2ban`, it is recommended to disable password based authentication for SSH access. SSH key based authentication is preferred.

50
docs/src/validator/faq.md Normal file
View File

@ -0,0 +1,50 @@
---
title: Validator Frequently Asked Questions
sidebar_label: Frequently Asked Questions
---
### What is a validator?
A validator is a computer that runs a software program to verify transactions that are added to the Solana blockchain. A validator can be a voting validator or a non voting validator. To learn more, see [what is a validator](./overview/what-is-a-validator.md).
### What is an RPC node?
An RPC node is also a computer that runs the validator software. Typically, an RPC node does not vote on the network. Instead the RPC node's job is to respond to API requests. See [what is an rpc node](./overview/what-is-an-rpc-node.md) for more information.
### What is a cluster?
For a definition and an overview of the topic, see [what is a cluster?](../cluster/overview.md). Solana maintains several clusters. For details on each, see [Solana clusters](../clusters.md).
### What is Proof of Stake?
Proof of Stake (PoS) is a blockchain architecture. Solana is a Proof of Stake blockchain. To read more, see [Proof of Stake](./overview/what-is-a-validator.md#proof-of-stake).
### What is Proof of Work? Is running a Solana validator the same as mining?
No, a Solana validator uses Proof of Stake. It does not use Proof of Work (often called mining). See [Proof of Work: For Contrast](./overview/what-is-a-validator.md#proof-of-stake).
### Who can operate a validator?
Anyone can operate a validator. All Solana clusters are permissionless. A new operator can choose to join at any time.
### Is there a validator set or limited number of validators that can operate?
No, all Solana clusters are permissionless. There is no limit to the number of active validators that can participate in consensus. Validators participating in consensus (voting validators) incur transaction fees for each vote. A voting validator can expect to incur up to 1.1 SOL per day in vote transaction fees.
### What are the hardware requirements for running a validator?
See [validator requirements](../running-validator/validator-reqs.md).
### Can I run my validator at home?
Anyone can join the cluster including home users. You must make sure that your system can perform well and keep up with the cluster. Many home internet connections are not suitable to run a Solana validator. Most operators choose to operate their validator in a data center either by using a server provider or by supplying your own hardware at a colocation data center.
See the [validator requirements](../running-validator/validator-reqs.md) for more information.
### What skills does a Solana validator operator need?
See [Solana validator prerequisites](./overview/validator-prerequisites.md).
### What are the economics of running a validator?
See [economics of running a validator](./overview/running-validator-or-rpc-node.md#economics-of-running-a-consensus-validator).

476
docs/src/validator/get-started/setup-a-validator.md Normal file
View File

@ -0,0 +1,476 @@
---
title: Setup a Solana Validator
sidebar_label: Setup a Validator
---
This is a guide for getting your validator setup on the Solana testnet cluster for the first time. Testnet is a Solana cluster that is used for performance testing of the software before the software is used on mainnet. Since testnet is stress tested daily, it is a good cluster to practice validator operations.
Once you have a working validator on testnet, you will want to learn about [operational best practices](../best-practices/operations.md) in the next section. Although the guide is specific to testnet, it can be adapted to mainnet or devnet as well. Refer to the [clusters](../../clusters) section of the Solana docs to see example commands for each cluster.
Now let's get started.
## 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, locate the terminal program on your _trusted computer_.
- on Mac, you can search for the word _terminal_ in spotlight.
- on Ubuntu, you can type `CTRL + Alt + T`.
- on Windows, you will have to open the command prompt as an Administrator.
## Install The Solana CLI Locally
To create your validator vote account, you need to install the [Solana command line interface](../../cli.md) on your local computer.
You can either use [Solana's Install Tool](../../cli/install-solana-cli-tools#use-solanas-install-tool) section from the Solana docs to install the CLI, or alternatively, you can also [build from source](../../cli/install-solana-cli-tools#build-from-source).
> Building from source is a great option for those that want a more secure and potentially more performant executable.
Once the Solana CLI is installed, you can return to this document once you are able to run the following command and get an answer on your terminal:
```
solana --version
```
You should see an output that looks similar to this (note your version number may be higher):
```
solana-cli 1.14.17 (src:b29a37cf; feat:3488713414)
```
Once you have successfully installed the cli, the next step is to change your config so that it is making requests to the `testnet` cluster:
```
solana config set --url https://api.testnet.solana.com
```
To verify that your config has change run:
```
solana config get
```
You should see a line that says: `RPC URL: https://api.testnet.solana.com`
## Create Keys
On your local computer, create the 3 keypairs that you will need to run your validator ([docs for reference](../../running-validator/validator-start#generate-identity)):
> **NOTE** Some operators choose to make vanity keypairs for their identity and vote account using the `grind` sub command ([docs for reference](../../running-validator/validator-start#vanity-keypair)).
```
solana-keygen new -o validator-keypair.json
```
```
solana-keygen new -o vote-account-keypair.json
```
```
solana-keygen new -o authorized-withdrawer-keypair.json
```
> **IMPORTANT** the `authorized-withdrawer-keypair.json` should be considered very sensitive information. Many operators choose to use a multisig, hardware wallet, or paper wallet for the authorized withdrawer keypair. A keypair is created on disk in this example for simplicity. Additionally, the withdrawer keypair should always be stored safely. The authorized withdrawer keypair should **never** be stored on the remote machine that the validator software runs on. For more information, see [validator secuirty best practices](../best-practices/security.md#do-not-store-your-withdrawer-key-on-your-validator)
## Create a Vote Account
Before you can create your vote account, you need to configure the Solana command line tool a bit more.
The below command sets the default keypair that the Solana CLI uses to the `validator-keypair.json` file that you just created in the terminal:
```
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 create a transaction (in this case, making your vote account):
```
solana airdrop 1
```
> **NOTE** The `airdrop` sub command does not work on mainnet, so you will have to acquire SOL and transfer it into this keypair's account if you are setting up a mainnet validator.
Now, use the Solana cluster to create a vote account.
As a reminder, all commands mentioned so far **should be done on your trusted computer** and **NOT** on a server where you intend to run your validator. It is especially important that the following command is done on a **trusted computer**:
```
solana create-vote-account -ut \
--fee-payer ./validator-keypair.json \
./vote-account-keypair.json \
./validator-keypair.json \
./authorized-withdrawer-keypair.json
```
> Note `-ut` tells the cli command that we would like to use the testnet cluster. `--fee-payer` specifies the keypair that will be used to pay the transaction fees. Both flags are not necessary if you configured the solana cli properly above but they are useful to ensure you're using the intended cluster and keypair.
## Save the Withdrawer Keypair Securely
Make sure your `authorized-withdrawer-keypair.json` is stored in a safe place. If you have chosen to create a keypair on disk, you should first backup the keypair and then delete it from your local machine.
**IMPORTANT**: If you lose your withdrawer key pair, you will lose control of your vote account. You will not be able to withdraw tokens from the vote account or update the withdrawer. Make sure to store the `authorized-withdrawer-keypair.json` securely before you move on.
## SSH To Your Validator
Connect to your remote server. This is specific to your server but will look something like this:
```
ssh user@<server.hostname>
```
You will have to check with your server provider to get the correct user account and hostname that you will ssh into.
## Update Your Ubuntu Packages
Make sure you have the latest and greatest package versions on your server
```
sudo apt update
sudo apt install
```
## Sol User
Create a new Ubuntu user, named `sol`, for running the validator:
```
sudo adduser sol
```
It is a best practice to always run your validator as a non-root user, like the `sol` user we just created.
## Hard Drive Setup
On your Ubuntu computer 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 will 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 UUID. Any device without a UUID is unformatted.
### Drive Formatting: Ledger
Assuming you have an nvme drive that is not formatted, you will have to format the drive and then mount it.
For example, if your computer has a device located at `/dev/nvme0n1`, then you can format the drive with the command:
```
sudo mkfs -t ext4 /dev/nvme0n1
```
For your computer, the device name and location may be different.
Next, check that you now have a UUID for that device:
```
lsblk -f
```
In the fourth column, next to your device name, you should see a string of letters and numbers that look like this: `6abd1aa5-8422-4b18-8058-11f821fd3967`. That is the UUID for the device.
### Mounting Your Drive: Ledger
So far we have created a formatted drive, but you do not have access to it until you mount it. Make a directory for mounting your drive:
```
sudo mkdir -p /mnt/ledger
```
Next, change the ownership of the directory to your `sol` user:
```
sudo chown -R sol:sol /mnt/ledger
```
Now you can mount the drive:
```
sudo mount /dev/nvme0n1 /mnt/ledger
```
### Formatting And Mounting Drive: AccountsDB
You will also want to mount the accounts db on a separate hard drive. The process will be similar to the ledger example above.
Assuming you have device at `/dev/nvme1n1`, format the device and verify it exists:
```
sudo mkfs -t ext4 /dev/nvme1n1
```
Then verify the UUID for the device exists:
```
lsblk -f
```
Create a directory for mounting:
```
sudo mkdir -p /mnt/accounts
```
Change the ownership of that directory:
```
sudo chown -R sol:sol /mnt/accounts
```
And lastly, mount the drive:
```
sudo mount /dev/nvme1n1 /mnt/accounts
```
## System Tuning
### Linux
Your system will need to be tuned in order to run properly. Your validator may not start without the settings below.
#### **Optimize sysctl knobs**
```bash
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"
```
```bash
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`.
```bash
sudo systemctl daemon-reload
```
```bash
sudo bash -c "cat >/etc/security/limits.d/90-solana-nofiles.conf <<EOF
# Increase process file descriptor count limit
* - nofile 1000000
EOF"
```
```bash
### Close all open sessions (log out then, in again) ###
```
## Copy Key Pairs
On your personal computer, not on the validator, securely copy your `validator-keypair.json` file and your `vote-account-keypair.json` file to the validator server:
```
scp validator-keypair.json sol@<server.hostname>:
scp vote-account-keypair.json sol@<server.hostname>:
```
> **Note**: The `vote-account-keypair.json` does not have any function other than identifying the vote account to potential delegators. Only the public key of the vote account is important once the account is created.
## Switch to the sol User
On the validator server, switch to the `sol` user:
```
su - sol
```
## Install The Solana CLI on Remote Machine
Your remote machine will need the Solana cli installed to run the validator software. Refer again to [Solana's Install Tool](../../cli/install-solana-cli-tools#use-solanas-install-tool) or [build from source](../../cli/install-solana-cli-tools#build-from-source). It is best for operators to build from source rather than using the pre built binaries.
## Create A Validator Startup Script
In your sol home directory (e.g. `/home/sol/`), create a folder called `bin`. Inside that folder create a file called `validator.sh` and make it executable:
```
mkdir -p /home/sol/bin
touch /home/sol/bin/validator.sh
chmod +x /home/sol/bin/validator.sh
```
Next, open the `validator.sh` file for editing:
```
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
```
Refer to `solana-validator --help` for more information on what each flag is doing in this script. Also refer to the section on [best practices for operating a validator](../best-practices/operations.md).
## Verifying Your Validator Is Working
Test that your `validator.sh` file is running properly by executing the `validator.sh` script:
```
/home/sol/bin/validator.sh
```
The script should execute the `solana-validator` process. In a new terminal window, shh into your server, then verify that the process is running:
```
ps aux | grep solana-validator
```
You should see a line in the output that includes `solana-validator` with all the flags that were added to your `validator.sh` script.
Next, we need to look at the logs to make sure everything is operating properly.
### Tailing The Logs
As a spot check, you will want to make sure your validator is producing reasonable log output (**warning**, there will be a lot of log output).
In a new terminal window, ssh into your validator machine, switch users to the `sol` user and `tail` the logs:
```
su - sol
tail -f solana-validator.log
```
The `tail` command will continue to display the output of a file as the file changes. You should see a continuous stream of log output as your validator runs. Keep an eye out for any lines that say `_ERROR_`.
Assuming you do not see any error messages, exit out of the command.
### Gossip Protocol
Gossip is a protocol used in the Solana clusters to communicate between validator nodes. For more information on gossip, see [Gossip Service](../gossip.md). To verify that your validator is running properly, make sure that the validator has registered itself with the gossip network.
In a new terminal window, connect to your server via ssh. Identify your validator's pubkey:
```
solana-keygen pubkey ~/validator-keypair.json
```
The command `solana gossip` lists all validators that have registered with the protocol. To check that the newly setup validator is in gossip, we will `grep` for our pubkey in the output:
```
solana gossip | grep <pubkey>
```
After running the command, you should see a single line that looks like this:
```
139.178.68.207 | 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on | 8001 | 8004 | 139.178.68.207:80 | 1.14.17 | 3488713414
```
If you do not see any output after grep-ing the output of gossip, your validator may be having startup problems. If that is the case, start debugging by looking through the validator log output.
### Solana Validators
After you have verified that your validator is in gossip, you can verify that your validator has joined the network using the `solana validators` command. The command lists all validators in the network, but like before, we can `grep` the output for the validator we care about:
```
solana validators | grep <pubkey>
```
You should see a line of output that looks like this:
```
5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on FX6NNbS5GHc2kuzgTZetup6GZX6ReaWyki8Z8jC7rbNG 100% 197434166 ( 0) 197434133 ( 0) 2.11% 323614 1.14.17 2450110.588302720 SOL (1.74%)
```
### Solana Catchup
The `solana catchup` command is a useful tool for seeing how quickly your validator is processing blocks. The Solana network has the capability to produce many transactions per second. Since your validator is new to the network, it has to ask another validator (listed as a `--known-validator` in your startup script) for a recent snapshot of the ledger. By the time you receive the snapshot, you may already be behind the network. Many transactions may have been processed and finalized in that time. In order for your validator to participate in consensus, it must _catchup_ to the rest of the network by asking for the more recent transactions that it does not have.
The `solana catchup` command is a tool that tells you how far behind the network your validator is and how quickly you are catching up:
```
solana catchup <pubkey>
```
If you see a message about trying to connect, your validator may not be part of the network yet. Make sure to check the logs and double check `solana gossip` and `solana validators` to make sure your validator is running properly.
Once you are happy that the validator can start up without errors, the next step is to create a system service to run the `validator.sh` file automatically. Stop the currently running validator by pressing `CTRL+C` in the window where `validator.sh` is running.
## Create a System Service
Follow these instructions for [running the validator as a system service](../../running-validator/validator-start#systemd-unit)
Make sure to implement log rotate as well. Once you have the system service configured, start your validator using the newly configured service:
```
sudo systemctl enable --now sol
```
Now verify that the validator is running properly by tailing the logs and using the commands mentioned earlier to check gossip and Solana validators:
```
tail -f /home/sol/solana-validator*.log
```
## Monitoring
`solana-watchtower` is a command you can run on a separate machine to monitor your server. You can read more about handling [automatic restarts and monitoring](../best-practices/monitoring.md#solana-watchtower) using Solana Watchtower here in the docs.
## Common issues
### Out of disk space
Make sure your ledger is on drive with at least `2TB` of space.
### Validator not catching up
This could be a networking/hardware issue, or you may need to get the latest snapshot from another validator node.

70
docs/src/validator/get-started/setup-an-rpc-node.md Normal file
View File

@ -0,0 +1,70 @@
---
title: Setup a Solana RPC Node
sidebar_label: Setup an RPC Node
---
Since a Solana RPC server runs the same process as a consensus validator, first follow the instructions on [how to setup a Solana validator](./setup-a-validator.md) to get started. Note, that you do not need to create a vote account if you are operating an RPC node. An RPC node typically does not vote.
After your validator is running, you can refer to this section for the RPC node specific setup instructions.
## Sample RPC Node
Below is an example `validator.sh` file for a `testnet` RPC server.
You will want to be aware of the following flags:
- `--full-rpc-api`: enables all RPC operations on this validator.
- `--no-voting`: runs the validator without participating in consensus. Typically, you do not want to run a validator as _both_ a consensus node and a full RPC node due to resource constraints.
- `--private-rpc`: does not publish the validator's open RPC port in the `solana gossip` command
> For more explanation on the flags used in the command, refer to the `solana-validator --help` command
```
#!/bin/bash
exec solana-validator \
--identity /home/sol/validator-keypair.json \
--known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
--known-validator dDzy5SR3AXdYWVqbDEkVFdvSPCtS9ihF5kJkHCtXoFs \
--known-validator eoKpUABi59aT4rR9HGS3LcMecfut9x7zJyodWWP43YQ \
--known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
--known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
--known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
--only-known-rpc \
--full-rpc-api \
--no-voting \
--ledger /mnt/ledger \
--accounts /mnt/accounts \
--log /home/sol/solana-rpc.log \
--rpc-port 8899 \
--rpc-bind-address 0.0.0.0 \
--private-rpc \
--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
```
### Solana Bigtable
The Solana blockchain is able to create many transactions per second. Because of the volume of transactions on the chain, it is not practical for an RPC node to store the entire blockchain on the machine. Instead, RPC operators use the `--limit-ledger-size` flag to specify how many blocks to store on the RPC node. If the user of the RPC node needs historical blockchain data then the RPC server will have to access older blocks through a Solana bigtable instance.
If you are interested in setting up your own bigtable instance, see these docs in the Solana GitHub repository: [solana-labs/solana-bigtable](https://github.com/solana-labs/solana-bigtable)
### Example Known Validators
The identities of the [known validators](../../running-validator/validator-start.md#known-validators) supplied in these example snippets (via the `--known-validator` flag) are:
- `5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on` - Solana Labs
- `dDzy5SR3AXdYWVqbDEkVFdvSPCtS9ihF5kJkHCtXoFs` - MonkeDAO
- `Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN` - Certus One
- `eoKpUABi59aT4rR9HGS3LcMecfut9x7zJyodWWP43YQ` - SerGo
- `9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv` - Algo|Stake
## Examples for other clusters
Additional examples of other Solana cluster specific validator commands can be found on the [Clusters](../../clusters.md) page.
Keep in mind, you will still need to customize these commands to operate as an RPC node, as well other operator specific configuration settings.

43
docs/src/validator/overview/running-validator-or-rpc-node.md Normal file
View File

@ -0,0 +1,43 @@
---
title: Consensus Validator or RPC Node?
sidebar_label: Running a Validator or RPC Node?
---
Operators who run a [consensus validator](./what-is-a-validator.md) have much different incentives than operators who run an [RPC node](./what-is-an-rpc-node.md). You will have to decide which choice is best for you based on your interests, technical background, and goals.
## Consensus Validators
As a validator your primary focus is maintaining the network and making sure that your node is performing optimally so that you can fully participate in the cluster consensus. You will want to attract a delegation of SOL to your validator which will allow your validator the opportunity to produce more blocks and earn rewards.
Each staked validator earns inflation rewards from [vote credits](../../terminology.md#vote-credit). Vote credits are assigned to validators that vote on [blocks](../../terminology.md#block) produced by the [leader](../../terminology.md#leader). The vote credits are given to all validators that successfully vote on blocks that are added to the blockchain. Additionally, when the validator is the leader, it can earn transaction fees and storage [rent fees](../../developing/programming-model/accounts.md#rent) for each block that it produces that is added to the blockchain.
Since all votes in Solana happen on the blockchain, a validator incurs a transaction cost for each vote that it makes. These transaction fees amount to approximately 1.0 SOL per day.
> It is important to make sure your validator always has enough SOL in its identity account to pay for these transactions!
### Economics of running a consensus validator
As an operator, it is important to understand how a consensus validator spends and earns sol through the protocol.
All validators who vote (consensus validators) must pay vote transaction fees for blocks that they agree with. The cost of voting can be up to 1.1 SOL per day.
A voting validator can earn SOL through 2 methods:
1. Inflationary rewards paid at the end of an epoch. See [staking rewards](./../../implemented-proposals/staking-rewards.md)
2. Earning 50% of transaction fees for the blocks produced by the validator. See [transaction fee basic economic design](../../transaction_fees.md#basic-economic-design)
The following links are community provided resources that discuss the economics of running a validator:
- Michael Hubbard wrote an [article](https://laine-sa.medium.com/solana-staking-rewards-validator-economics-how-does-it-work-6718e4cccc4e) that explains the economics of Solana in more depth for stakers and for validators.
- Congent Crypto has written a [blog post](https://medium.com/@Cogent_Crypto/how-to-become-a-validator-on-solana-9dc4288107b7) that discusses economics and getting started.
- Cogent Crypto also provides a [validator profit calculator](https://cogentcrypto.io/ValidatorProfitCalculator)
## RPC Nodes
While RPC operators **do NOT** receive rewards (because the node is not participating in voting), there are different motivations for running an RPC node.
An RPC operator is providing a service to users who want to interact with the Solana blockchain. Because your primary user is often technical, you will have to be able to answer technical questions about performance of RPC calls. This option may require more understanding of the [core Solana architecture](../../cluster/overview.md).
If you are operating an RPC node as a business, your job will also involve scaling your system to meet the demands of the users. For example, some RPC providers create dedicated servers for projects that require a high volume of requests to the node. Someone with a background in development operations or software engineering will be a very important part of your team. You will need a strong understanding of the Solana architecture and the [RPC API](../../api/http.md).
Alternatively, you may be a development team that would like to run their own infrastructure. In this case, the RPC infrastructure could be a part of your production stack. A development team could use the [Geyser plugin](../../developing/plugins/geyser-plugins.md), for example, to get real time access to information about accounts or blocks in the cluster.

23
docs/src/validator/overview/validator-initiatives.md Normal file
View File

@ -0,0 +1,23 @@
---
title: Solana Validator Initiatives
sidebar_label: Validator Initiatives
---
There are a number of initiatives that may help operators get started or grow their delegation. All of these initiatives are completely optional. All Solana clusters are permissionless and an operator can join at any time.
## Solana Foundation Delegation Program
The Solana Foundation helps facilitate the growth of the consensus validator network by running a SOL delegation program. The program is open to new applicants. You can find out more information [here](https://solana.org/delegation-program)
## Tour De Sun 22
Delegation program participants who operate a performant testnet node, may also join Tour De Sun 22 (TdS22). The program gives locked SOL incentive payments to operators for running approved hardware on Testnet. For more information, see [TdS22](https://solana.org/tds22).
## Solana Foundation Server Program
Separately from the delegation program, The Solana Foundation offers a server program that provides servers in various data-centers all over the world. If you would like to run a consensus validator or RPC node, you may use this program to rent bare metal servers in various data-centers. The servers meet or exceed the [Solana validator hardware specs](../../running-validator/validator-reqs#hardware-recommendations). No long-term lease commitments are required. To find out more, visit the [Solana server program page](https://solana.org/server-program).
## Stake Pools
The Solana ecosystem operates various stake pools. These stake pools delegate stake to validators using various delegation strategies. To learn more about stake pools and their delegation strategies, visit the [Solana Foundation stake pools page](https://solana.org/stake-pools).

35
docs/src/validator/overview/validator-prerequisites.md Normal file
View File

@ -0,0 +1,35 @@
---
title: Solana Validator Prerequisites
sidebar_label: Validator Prerequisites
---
Operating a Solana validator is an interesting and rewarding task. Generally speaking, it requires someone with a technical background but also involves community engagement and marketing.
## How to be a good Validator Operator
Here is a list of some of the requirements for being a good operator:
- Performant computer hardware and a fast internet connection
- You can find a list of [hardware requirements here](../../running-validator/validator-reqs.md)
- Solana helps facilitate data-center server rentals through the [Solana server program](https://solana.foundation/server-program)
- Knowledge of the Linux terminal
- Ubuntu system administration
- Accessing your machine via ssh and scp
- Installing software (installing from source is encouraged)
- Keeping Ubuntu up to date
- Managing users and system access
- Understanding computer processes
- Formatting and mounting drives
- Hardware performance monitoring
- Cluster and node monitoring
- Quick response times in case of a validator issue
- Marketing and communications to attract delegators
- Customer support
Whether you decide to run a [validator](./what-is-a-validator.md) or an [RPC node](./what-is-an-rpc-node.md), you should consider all of these areas of expertise. A team of people is likely necessary for you to achieve your goals.
## Can I use my computer at home?
While anyone can join the network, you should make sure that your home computer and network meets the specifications in the [hardware requirements](../../running-validator/validator-reqs.md) doc. Most home internet service providers do not provide consistent service that would allow your validator to perform well. If your home network or personal hardware is not performant enough to keep up with the Solana cluster, your validator will not be able to participate in consensus.
In addition to performance considerations, you will want to make sure that your home computer is resistant to outages caused by loss of power, flooding, fire, theft, etc. If you are just getting started and learning about being an operator, a home setup may be sufficient, but you will want to consider all of these factors when you start operating your validator on the mainnet-beta cluster.

39
docs/src/validator/overview/what-is-a-validator.md Normal file
View File

@ -0,0 +1,39 @@
---
title: What is a Validator?
---
A validator is a computer that helps to run the Solana network. Each validator executes a program that keeps track of all accounts on the Solana cluster and validates transactions being added to the network. Without validators, Solana would not be able to function.
The more independent entities that run validators, the less vulnerable the cluster is to an attack or catastrophe that affects the cluster.
> For an more in depth look at the health of the Solana network, see the [Solana Foundation Validator Health Report](https://solana.com/news/validator-health-report-march-2023).
By becoming a validator, you are helping to grow the network. You are also learning first hand how the Solana cluster functions at the lowest level. You will become part of an active community of operators that are passionate about the Solana ecosystem.
## Consensus vs RPC
Before, we discuss validators in more detail, it's useful to make some distinctions. Using the same validator software, you have the option of running a voting/consensus node or choosing to instead run an RPC node. An RPC node helps Solana devs and others interact with the blockchain but for performance reasons should not vote. We go into more detail on RPC nodes in the next section, [what is an rpc node](./what-is-an-rpc-node.md).
For this document, when a validator is mentioned, we are talking about a voting/consensus node. Now, to better understand what your validator is doing, it would help to understand how the Solana network functions in more depth.
## Proof Of Stake
Proof of stake is the blockchain architecture that is used in Solana. It is called proof of stake because token holders can stake their tokens to a validator of their choice. When a person stakes their tokens, that person still owns the tokens and can remove the stake at any time. The staked tokens represent their trust in that validator. When a person stakes their tokens to a validator, they are given a return of some amount of tokens as a reward for helping to run and secure the network. The more tokens you have staked to a validator the more rewards you receive. A validator that has a large amount of tokens staked to it has a larger vote share in consensus. A validator, therefore, is given more opportunities to produce blocks in the network proportional to the size of the stake in the validator. The validator that is currently producing blocks in the network is known as the leader.
## Proof Of Work: For Contrast
Solana is not a proof of work system. Proof of work is a different blockchain architecture in which a computer (often called a miner), works to solve a cryptographic problem before anyone else on the network is able to solve it. The more often the computer solves these problems, the more rewards the miner receives. Because of the incentive to solve a hard computational problem first, miners often use many computers at the same time. The number of computers used to solve these problems leads to large energy consumption and resulting environmental challenges.
Solana, in contrast, does not incentivize validators to use many computers to solve a computational problem. Because a validator would like to have a larger amount staked to it, there is no real advantage for an independent validator to using many different computers. Here, you can see a comparison of [Solana's environmental impact](https://solana.com/news/solana-energy-usage-report-november-2021).
## Proof Of History
Proof of history, PoH, is one of the key innovations in Solana that allows transactions to be finalized very quickly. At a high level, PoH allows validators in the cluster to agree on a cryptographically repeatable clock. Both proof of stake and proof of work architectures mentioned above are architectures that bring the cluster to consensus. In other words, these algorithms decide which blocks should be added to the blockchain. Proof of history is not a consensus architecture, but rather a feature in Solana that makes block finalization faster in the proof of stake system.
Understanding how PoH works is not necessary to run a good validator, but a very approachable discussion can be found [in this Medium article](https://medium.com/solana-labs/proof-of-history-explained-by-a-water-clock-e682183417b8). Also, the [Solana whitepaper](https://solana.com/solana-whitepaper.pdf) does a good job of explaining the algorithm in an approachable way for the more technically minded.
## Your Role As A Validator
As a validator, you are helping to secure the network by producing and voting on blocks and to improve decentralization by running an independent node. You have the right to participate in discussions of changes on the network. You are also assuming a responsibility to keep your system running properly, to make sure your system is secure, and to keep it up to date with the latest software. As more individuals stake their tokens to your validator, you can reward their trust by running a high performing and reliable validator. Hopefully, your validator is performing well a majority of the time, but you should also have systems in place to respond to an outage at any time of the day. If your validator is not responding late at night, someone (either you or other team members) need to be available to investigate and fix the issues.
Running a validator is a [technical and important task](./validator-prerequisites.md), but it can also be very rewarding. Good luck and welcome to the community.

12
docs/src/validator/overview/what-is-an-rpc-node.md Normal file
View File

@ -0,0 +1,12 @@
---
title: What is an RPC Node?
---
An RPC (Remote Procedure Call) node runs the same software as a [validator](../overview/what-is-a-validator.md), but it does not participate in the consensus process. Technically you could run the RPC software and also allow your node to vote as a consensus node, but it is strongly discouraged because your node will not be performant enough to do either task well.
A node that runs RPC has a much different purpose in the cluster. An RPC node responds to requests about the blockchain and also allows users of the RPC node to submit new transactions to be included in blocks.
For example, a website might request to transfer tokens from wallet A to wallet B (given wallet A's permission). That website would have to use wallet A to sign a transaction and then send it to an RPC node to be submitted to the leader. So you could think of running an RPC node as a similar engineering task to providing an api for others to use.
The users of the RPC node are often developers, so this option may require a more technical understanding of Solana. To better understand RPC node operations, you'll want to become familiar with the different RPC calls.
You can find the RPC API [here](../../api/http.md).