More validator doc cleanup (#7185)
* Cleanup and wrap lines in validator docs * Add references to tune_system and solana-keygen grind
This commit is contained in:
parent
887bff572a
commit
704c50ea17
|
@ -26,7 +26,7 @@
|
|||
* [The Runtime](validator/runtime.md)
|
||||
* [Anatomy of a Transaction](transaction.md)
|
||||
* [Running a Validator](running-validator/README.md)
|
||||
* [Hardware Requirements](running-validator/validator-reqs.md)
|
||||
* [Validator Requirements](running-validator/validator-reqs.md)
|
||||
* [Choosing a Testnet](running-validator/validator-testnet.md)
|
||||
* [Installing the Validator Software](running-validator/validator-software.md)
|
||||
* [Starting a Validator](running-validator/validator-start.md)
|
||||
|
@ -34,7 +34,6 @@
|
|||
* [Monitoring a Validator](running-validator/validator-monitor.md)
|
||||
* [Publishing Validator Info](running-validator/validator-info.md)
|
||||
* [Troubleshooting](running-validator/validator-troubleshoot.md)
|
||||
* [FAQ](running-validator/validator-faq.md)
|
||||
* [Running an Archiver](running-archiver.md)
|
||||
* [Paper Wallet](paper-wallet/README.md)
|
||||
* [Creating and Using a Seed Phrase](paper-wallet/keypair.md)
|
||||
|
|
|
@ -1,12 +1,15 @@
|
|||
# Running a Validator
|
||||
|
||||
This document describes how to participate in the Solana testnet as a validator node.
|
||||
This document describes how to participate in the Solana testnet as a validator
|
||||
node.
|
||||
|
||||
Please note some of the information and instructions described here may change in future releases, and documentation will be updated for mainnet participation.
|
||||
Please note some of the information and instructions described here may change
|
||||
in future releases, and documentation will be updated for mainnet participation.
|
||||
|
||||
## Overview
|
||||
|
||||
Solana currently maintains several testnets, each featuring a validator that can serve as the entrypoint to the cluster for your validator.
|
||||
Solana currently maintains several testnets, each featuring a validator that can
|
||||
serve as the entrypoint to the cluster for your validator.
|
||||
|
||||
Current testnet entrypoints:
|
||||
|
||||
|
@ -14,13 +17,18 @@ Current testnet entrypoints:
|
|||
* Beta, beta.testnet.solana.com
|
||||
* Edge, edge.testnet.solana.com
|
||||
|
||||
Solana may launch special testnets for validator participation; we will provide you with a specific entrypoint URL to use.
|
||||
Solana may launch special testnets for validator participation; we will provide
|
||||
you with a specific entrypoint URL to use.
|
||||
|
||||
Prior to mainnet, the testnets may be running different versions of solana software, which may feature breaking changes. For information on choosing a testnet and finding software version info, jump to [Choosing a Testnet](validator-testnet.md).
|
||||
Prior to mainnet, the testnets may be running different versions of solana
|
||||
software, which may feature breaking changes. For information on choosing a
|
||||
testnet and finding software version info, jump to [Choosing a Testnet](validator-testnet.md).
|
||||
|
||||
The testnets are configured to reset the ledger daily, or sooner, should the hourly automated cluster sanity test fail.
|
||||
The testnets are configured to reset the ledger daily, or sooner, should the
|
||||
hourly automated cluster sanity test fail.
|
||||
|
||||
There is a network explorer that shows the status of solana testnets available at [http://explorer.solana.com/](https://explorer.solana.com/).
|
||||
|
||||
Also we'd love it if you choose to register your validator node with us at [https://forms.gle/LfFscZqJELbuUP139](https://forms.gle/LfFscZqJELbuUP139).
|
||||
There is a network explorer that shows the status of solana testnets available
|
||||
at [http://explorer.solana.com/](https://explorer.solana.com/).
|
||||
|
||||
Also we'd love it if you choose to register your validator node with us at
|
||||
[https://forms.gle/LfFscZqJELbuUP139](https://forms.gle/LfFscZqJELbuUP139).
|
||||
|
|
|
@ -1,4 +0,0 @@
|
|||
# FAQ
|
||||
|
||||
Coming soon...
|
||||
|
|
@ -40,7 +40,10 @@ Validator info from 8WdJvDz6obhADdxpGCiJKZsDYwTLNEDFizayqziDc9ah
|
|||
|
||||
## Keybase
|
||||
|
||||
Including a Keybase username allows client applications \(like the Solana Network Explorer\) to automatically pull in your validator public profile, including cryptographic proofs, brand identity, etc. To connect your validator pubkey with Keybase:
|
||||
Including a Keybase username allows client applications \(like the Solana
|
||||
Network Explorer\) to automatically pull in your validator public profile,
|
||||
including cryptographic proofs, brand identity, etc. To connect your validator
|
||||
pubkey with Keybase:
|
||||
|
||||
1. Join [https://keybase.io/](https://keybase.io/) and complete the profile for your validator
|
||||
2. Add your validator **identity pubkey** to Keybase:
|
||||
|
|
|
@ -2,34 +2,13 @@
|
|||
|
||||
## Check Gossip
|
||||
|
||||
The **identity pubkey** for your validator can also be found by running:
|
||||
|
||||
```bash
|
||||
solana-keygen pubkey ~/validator-keypair.json
|
||||
```
|
||||
|
||||
From another console, confirm the IP address and **identity pubkey** of your validator is visible in the gossip network by running:
|
||||
Confirm the IP address and **identity pubkey** of your validator is visible in
|
||||
the gossip network by running:
|
||||
|
||||
```bash
|
||||
solana-gossip --entrypoint testnet.solana.com:8001 spy
|
||||
```
|
||||
|
||||
## Monitoring Catch Up
|
||||
|
||||
It may take some time to catch up with the cluster after your validator boots.
|
||||
Use the `catchup` command to monitor your validator through this process:
|
||||
|
||||
```bash
|
||||
solana catchup ~/validator-keypair.json
|
||||
```
|
||||
|
||||
Until your validator has caught up, it will not be able to vote successfully and
|
||||
stake cannot be delegated to it.
|
||||
|
||||
Also if you find the cluster's slot advancing faster than yours, you will likely
|
||||
never catch up. This typically implies some kind of networking issue between
|
||||
your validator and the rest of the cluster.
|
||||
|
||||
## Check Your Balance
|
||||
|
||||
Your account balance should decrease by the transaction fee amount as your
|
||||
|
@ -42,7 +21,8 @@ solana balance --lamports
|
|||
|
||||
## Check Vote Activity
|
||||
|
||||
The `solana show-vote-account` command displays the recent voting activity from your validator:
|
||||
The `solana show-vote-account` command displays the recent voting activity from
|
||||
your validator:
|
||||
|
||||
```bash
|
||||
solana show-vote-account ~/validator-vote-keypair.json
|
||||
|
@ -50,7 +30,8 @@ solana show-vote-account ~/validator-vote-keypair.json
|
|||
|
||||
## Get Cluster Info
|
||||
|
||||
There are several useful JSON-RPC endpoints for monitoring your validator on the cluster, as well as the health of the cluster:
|
||||
There are several useful JSON-RPC endpoints for monitoring your validator on the
|
||||
cluster, as well as the health of the cluster:
|
||||
|
||||
```bash
|
||||
# Similar to solana-gossip, you should see your validator in the list of cluster nodes
|
||||
|
@ -68,7 +49,8 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "m
|
|||
|
||||
Metrics are available for local monitoring of your validator.
|
||||
|
||||
Docker must be installed and the current user added to the docker group. Then download `solana-metrics.tar.bz2` from the Github Release and run
|
||||
Docker must be installed and the current user added to the docker group. Then
|
||||
download `solana-metrics.tar.bz2` from the Github Release and run
|
||||
|
||||
```bash
|
||||
tar jxf solana-metrics.tar.bz2
|
||||
|
@ -76,15 +58,21 @@ cd solana-metrics/
|
|||
./start.sh
|
||||
```
|
||||
|
||||
A local InfluxDB and Grafana instance is now running on your machine. Define `SOLANA_METRICS_CONFIG` in your environment as described at the end of the `start.sh` output and restart your validator.
|
||||
A local InfluxDB and Grafana instance is now running on your machine. Define
|
||||
`SOLANA_METRICS_CONFIG` in your environment as described at the end of the
|
||||
`start.sh` output and restart your validator.
|
||||
|
||||
Metrics should now be streaming and visible from your local Grafana dashboard.
|
||||
|
||||
## Timezone For Log Messages
|
||||
|
||||
Log messages emitted by your validator include a timestamp. When sharing logs with others to help triage issues, that timestamp can cause confusion as it does not contain timezone information.
|
||||
Log messages emitted by your validator include a timestamp. When sharing logs
|
||||
with others to help triage issues, that timestamp can cause confusion as it does
|
||||
not contain timezone information.
|
||||
|
||||
To make it easier to compare logs between different sources we request that everybody use Pacific Time on their validator nodes. In Linux this can be accomplished by running:
|
||||
To make it easier to compare logs between different sources we request that
|
||||
everybody use Pacific Time on their validator nodes. In Linux this can be
|
||||
accomplished by running:
|
||||
|
||||
```bash
|
||||
sudo ln -sf /usr/share/zoneinfo/America/Los_Angeles /etc/localtime
|
||||
|
|
|
@ -1,22 +1,29 @@
|
|||
# Hardware and Software Requirements
|
||||
# Validator Requirements
|
||||
|
||||
## Hardware
|
||||
|
||||
* CPU Recommendations
|
||||
* We recommend a CPU with the highest number of cores as possible. AMD Threadripper or Intel Server \(Xeon\) CPUs are fine.
|
||||
* We recommend AMD Threadripper as you get a larger number of cores for parallelization compared to Intel.
|
||||
* Threadripper also has a cost-per-core advantage and a greater number of PCIe lanes compared to the equivalent Intel part. PoH \(Proof of History\) is based on sha256 and Threadripper also supports sha256 hardware instructions.
|
||||
* We recommend a CPU with the highest number of cores as possible. AMD
|
||||
Threadripper or Intel Server \(Xeon\) CPUs are fine.
|
||||
* We recommend AMD Threadripper as you get a larger number of cores for
|
||||
parallelization compared to Intel.
|
||||
* Threadripper also has a cost-per-core advantage and a greater number of PCIe
|
||||
lanes compared to the equivalent Intel part. PoH \(Proof of History\) is based
|
||||
on sha256 and Threadripper also supports sha256 hardware instructions.
|
||||
* SSD size and I/O style \(SATA vs NVMe/M.2\) for a validator
|
||||
* Minimum example - Samsung 860 Evo 2TB
|
||||
* Mid-range example - Samsung 860 Evo 4TB
|
||||
* High-end example - Samsung 860 Evo 4TB
|
||||
* GPUs
|
||||
* While a CPU-only node may be able to keep up with the initial idling network, once transaction throughput increases, GPUs will be necessary
|
||||
* While a CPU-only node may be able to keep up with the initial idling network,
|
||||
once transaction throughput increases, GPUs will be necessary
|
||||
* What kind of GPU?
|
||||
* We recommend Nvidia 2080Ti or 1080Ti series consumer GPU or Tesla series server GPUs.
|
||||
* We do not currently support OpenCL and therefore do not support AMD GPUs. We have a bounty out for someone to port us to OpenCL. Interested? [Check out our GitHub.](https://github.com/solana-labs/solana)
|
||||
* We do not currently support OpenCL and therefore do not support AMD GPUs.
|
||||
We have a bounty out for someone to port us to OpenCL. Interested? [Check out our GitHub.](https://github.com/solana-labs/solana)
|
||||
* Power Consumption
|
||||
* Approximate power consumption for a validator node running an AMD Threadripper 2950W and 2x 2080Ti GPUs is 800-1000W.
|
||||
* Approximate power consumption for a validator node running an AMD Threadripper
|
||||
2950W and 2x 2080Ti GPUs is 800-1000W.
|
||||
|
||||
### Preconfigured Setups
|
||||
|
||||
|
@ -30,15 +37,24 @@ Here are our recommendations for low, medium, and high end machine specification
|
|||
| Accounts Drive\(s\) | None | Samsung 970 Pro 1TB | 2x Samsung 970 Pro 1TB | |
|
||||
| GPU | 4x Nvidia 1070 or 2x Nvidia 1080 Ti or 2x Nvidia 2070 | 2x Nvidia 2080 Ti | 4x Nvidia 2080 Ti | Any number of cuda-capable GPUs are supported on Linux platforms. |
|
||||
|
||||
## **Software**
|
||||
## Software
|
||||
|
||||
* We build and run on Ubuntu 18.04. Some users have had trouble when running on Ubuntu 16.04
|
||||
* See [Validator Software](validator-software.md) for the current Solana software release.
|
||||
|
||||
Be sure to ensure that the machine used is not behind a residential NAT to avoid NAT traversal issues. A cloud-hosted machine works best. **Ensure that IP ports 8000 through 10000 are not blocked for Internet inbound and outbound traffic.** For more information on port forwarding with regards to residential networks, see [this document](http://www.mcs.sdsmt.edu/lpyeatt/courses/314/PortForwardingSetup.pdf).
|
||||
Be sure to ensure that the machine used is not behind a residential NAT to avoid
|
||||
NAT traversal issues. A cloud-hosted machine works best. **Ensure that IP ports
|
||||
8000 through 10000 are not blocked for Internet inbound and outbound traffic.**
|
||||
For more information on port forwarding with regards to residential networks,
|
||||
see [this
|
||||
document](http://www.mcs.sdsmt.edu/lpyeatt/courses/314/PortForwardingSetup.pdf).
|
||||
|
||||
Prebuilt binaries are available for Linux x86\_64 \(Ubuntu 18.04 recommended\). MacOS or WSL users may build from source.
|
||||
Prebuilt binaries are available for Linux x86\_64 \(Ubuntu 18.04 recommended\).
|
||||
MacOS or WSL users may build from source.
|
||||
|
||||
## GPU Requirements
|
||||
|
||||
CUDA is required to make use of the GPU on your system. The provided Solana release binaries are built on Ubuntu 18.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.
|
||||
CUDA is required to make use of the GPU on your system. The provided Solana
|
||||
release binaries are built on Ubuntu 18.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.
|
||||
|
|
|
@ -1,6 +1,8 @@
|
|||
# Installing the Validator Software
|
||||
|
||||
Install the Solana release [v0.21.0](https://github.com/solana-labs/solana/releases/tag/v0.21.0) on your machine by running:
|
||||
Install the Solana release
|
||||
[v0.21.0](https://github.com/solana-labs/solana/releases/tag/v0.21.0) on your
|
||||
machine by running:
|
||||
|
||||
```bash
|
||||
curl -sSf https://raw.githubusercontent.com/solana-labs/solana/v0.21.0/install/solana-install-init.sh | sh -s - 0.21.0
|
||||
|
@ -18,15 +20,20 @@ Active release directory: /home/solana/.local/share/solana/install/active_releas
|
|||
Update successful
|
||||
```
|
||||
|
||||
After a successful install, `solana-install update` may be used to easily update the cluster software to a newer version at any time.
|
||||
After a successful install, `solana-install update` may be used to easily update
|
||||
the cluster software to a newer version at any time.
|
||||
|
||||
## Download Prebuilt Binaries
|
||||
|
||||
If you would rather not use `solana-install` to manage the install, you can manually download and install the binaries.
|
||||
If you would rather not use `solana-install` to manage the install, you can
|
||||
manually download and install the binaries.
|
||||
|
||||
### Linux
|
||||
|
||||
Download the binaries by navigating to [https://github.com/solana-labs/solana/releases/latest](https://github.com/solana-labs/solana/releases/latest), download **solana-release-x86\_64-unknown-linux-gnu.tar.bz2**, then extract the archive:
|
||||
Download the binaries by navigating to
|
||||
[https://github.com/solana-labs/solana/releases/latest](https://github.com/solana-labs/solana/releases/latest),
|
||||
download **solana-release-x86\_64-unknown-linux-gnu.tar.bz2**, then extract the
|
||||
archive:
|
||||
|
||||
```bash
|
||||
tar jxf solana-release-x86_64-unknown-linux-gnu.tar.bz2
|
||||
|
@ -36,7 +43,10 @@ export PATH=$PWD/bin:$PATH
|
|||
|
||||
### macOS
|
||||
|
||||
Download the binaries by navigating to [https://github.com/solana-labs/solana/releases/latest](https://github.com/solana-labs/solana/releases/latest), download **solana-release-x86\_64-apple-darwin.tar.bz2**, then extract the archive:
|
||||
Download the binaries by navigating to
|
||||
[https://github.com/solana-labs/solana/releases/latest](https://github.com/solana-labs/solana/releases/latest),
|
||||
download **solana-release-x86\_64-apple-darwin.tar.bz2**, then extract the
|
||||
archive:
|
||||
|
||||
```bash
|
||||
tar jxf solana-release-x86_64-apple-darwin.tar.bz2
|
||||
|
@ -46,14 +56,19 @@ export PATH=$PWD/bin:$PATH
|
|||
|
||||
## Build From Source
|
||||
|
||||
If you are unable to use the prebuilt binaries or prefer to build it yourself from source, navigate to [https://github.com/solana-labs/solana/releases/latest](https://github.com/solana-labs/solana/releases/latest), and download the **Source Code** archive. Extract the code and build the binaries with:
|
||||
If you are unable to use the prebuilt binaries or prefer to build it yourself
|
||||
from source, navigate to
|
||||
[https://github.com/solana-labs/solana/releases/latest](https://github.com/solana-labs/solana/releases/latest),
|
||||
and download the **Source Code** archive. Extract the code and build the
|
||||
binaries with:
|
||||
|
||||
```bash
|
||||
./scripts/cargo-install-all.sh .
|
||||
export PATH=$PWD/bin:$PATH
|
||||
```
|
||||
|
||||
You can then run the following command to obtain the same result as with prebuilt binaries:
|
||||
You can then run the following command to obtain the same result as with
|
||||
prebuilt binaries:
|
||||
|
||||
```bash
|
||||
solana-install init
|
||||
|
|
|
@ -1,13 +1,30 @@
|
|||
# Staking
|
||||
|
||||
# Staking
|
||||
**By default your validator will have no stake.** This means it will be
|
||||
ineligible to become leader.
|
||||
|
||||
**By default your validator will have no stake.** This means it will be ineligible to become leader.
|
||||
To delegate stake, first make sure your validator is running and has [caught up to the cluster](monitoring-your-validator.md#validator-catch-up).
|
||||
## Monitoring Catch Up
|
||||
|
||||
To delegate stake, first make sure your validator is running and has caught up
|
||||
to the cluster. It may take some time to catch up after your validator boots.
|
||||
Use the `catchup` command to monitor your validator through this process:
|
||||
|
||||
```bash
|
||||
solana catchup ~/validator-keypair.json
|
||||
```
|
||||
|
||||
Until your validator has caught up, it will not be able to vote successfully and
|
||||
stake cannot be delegated to it.
|
||||
|
||||
Also if you find the cluster's slot advancing faster than yours, you will likely
|
||||
never catch up. This typically implies some kind of networking issue between
|
||||
your validator and the rest of the cluster.
|
||||
|
||||
## Create Stake Keypair
|
||||
|
||||
If you haven’t already done so, create a staking keypair. If you have completed this step, you should see the “validator-stake-keypair.json” in your Solana runtime directory.
|
||||
If you haven’t already done so, create a staking keypair. If you have completed
|
||||
this step, you should see the “validator-stake-keypair.json” in your Solana
|
||||
runtime directory.
|
||||
|
||||
```bash
|
||||
solana-keygen new -o ~/validator-stake-keypair.json
|
||||
|
@ -29,46 +46,75 @@ solana delegate-stake ~/validator-stake-keypair.json ~/validator-vote-keypair.js
|
|||
|
||||
> Don’t delegate your remaining SOL, as your validator will use those tokens to vote.
|
||||
|
||||
Stakes can be re-delegated to another node at any time with the same command, but only one re-delegation is permitted per epoch:
|
||||
Stakes can be re-delegated to another node at any time with the same command,
|
||||
but only one re-delegation is permitted per epoch:
|
||||
|
||||
```bash
|
||||
solana delegate-stake ~/validator-stake-keypair.json ~/some-other-validator-vote-keypair.json
|
||||
```
|
||||
|
||||
Assuming the node is voting, now you're up and running and generating validator rewards. You'll want to periodically redeem/claim your rewards:
|
||||
Assuming the node is voting, now you're up and running and generating validator
|
||||
rewards. You'll want to periodically redeem/claim your rewards:
|
||||
|
||||
```bash
|
||||
solana redeem-vote-credits ~/validator-stake-keypair.json ~/validator-vote-keypair.json
|
||||
```
|
||||
|
||||
The rewards lamports earned are split between your stake account and the vote account according to the commission rate set in the vote account. Rewards can only be earned while the validator is up and running. Further, once staked, the validator becomes an important part of the network. In order to safely remove a validator from the network, first deactivate its stake.
|
||||
The rewards lamports earned are split between your stake account and the vote
|
||||
account according to the commission rate set in the vote account. Rewards can
|
||||
only be earned while the validator is up and running. Further, once staked, the
|
||||
validator becomes an important part of the network. In order to safely remove a
|
||||
validator from the network, first deactivate its stake.
|
||||
|
||||
At the end of each slot, a validator is expected to send a vote transaction. These vote transactions are paid for by lamports from a validator's identity account.
|
||||
At the end of each slot, a validator is expected to send a vote transaction.
|
||||
These vote transactions are paid for by lamports from a validator's identity
|
||||
account.
|
||||
|
||||
This is a normal transaction so the standard transaction fee will apply. The transaction fee range is defined by the genesis block. The actual fee will fluctuate based on transaction load. You can determine the current fee via the [RPC API “getRecentBlockhash”](../api-reference/jsonrpc-api#getrecentblockhash) before submitting a transaction.
|
||||
This is a normal transaction so the standard transaction fee will apply. The
|
||||
transaction fee range is defined by the genesis block. The actual fee will
|
||||
fluctuate based on transaction load. You can determine the current fee via the
|
||||
[RPC API “getRecentBlockhash”](../api-reference/jsonrpc-api.md#getrecentblockhash)
|
||||
before submitting a transaction.
|
||||
|
||||
Learn more about [transaction fees here](../implemented-proposals/transaction-fees).
|
||||
Learn more about [transaction fees here](../implemented-proposals/transaction-fees.md).
|
||||
|
||||
## Validator Stake Warm-up
|
||||
|
||||
Stakes need to warm up, and warmup increments are applied at Epoch boundaries, so it can take an hour or more for stake to come fully online.
|
||||
Stakes need to warm up, and warmup increments are applied at Epoch boundaries,
|
||||
so it can take an hour or more for stake to come fully online.
|
||||
|
||||
To monitor your validator during its warmup period:
|
||||
|
||||
* View your vote account:`solana show-vote-account ~/validator-vote-keypair.json` This displays the current state of all the votes the validator has submitted to the network.
|
||||
* View your stake account, the delegation preference and details of your stake:`solana show-stake-account ~/validator-stake-keypair.json`
|
||||
* `solana uptime ~/validator-vote-keypair.json` will display the voting history \(aka, uptime\) of your validator over recent Epochs
|
||||
* `solana show-validators` displays the current active stake of all validators, including yours
|
||||
* `solana show-show-stake-history ` shows the history of stake warming up and cooling down over recent epochs
|
||||
* Look for log messages on your validator indicating your next leader slot: `[2019-09-27T20:16:00.319721164Z INFO solana_core::replay_stage] <VALIDATOR_IDENTITY_PUBKEY> voted and reset PoH at tick height ####. My next leader slot is ####`
|
||||
* Once your stake is warmed up, you will see a stake balance listed for your validator on the [Solana Network Explorer](http://explorer.solana.com/validators)
|
||||
* View your vote account:`solana show-vote-account ~/validator-vote-keypair.json`
|
||||
This displays the current state of all the votes the validator has submitted to
|
||||
the network.
|
||||
* View your stake account, the delegation preference and details of your
|
||||
stake:`solana show-stake-account ~/validator-stake-keypair.json`
|
||||
* `solana uptime ~/validator-vote-keypair.json` will display the voting history
|
||||
\(aka, uptime\) of your validator over recent Epochs
|
||||
* `solana show-validators` displays the current active stake of all validators,
|
||||
including yours
|
||||
* `solana show-show-stake-history ` shows the history of stake warming up and
|
||||
cooling down over recent epochs
|
||||
* Look for log messages on your validator indicating your next leader slot:
|
||||
`[2019-09-27T20:16:00.319721164Z INFO solana_core::replay_stage]
|
||||
<VALIDATOR_IDENTITY_PUBKEY> voted and reset PoH at tick height ####. My next
|
||||
leader slot is ####`
|
||||
* Once your stake is warmed up, you will see a stake balance listed for your
|
||||
validator on the [Solana Network
|
||||
Explorer](http://explorer.solana.com/validators)
|
||||
|
||||
## Monitor Your Staked Validator
|
||||
|
||||
Confirm your validator becomes a [leader](../terminology.md#leader)
|
||||
|
||||
* After your validator is caught up, use the `$ solana balance` command to monitor the earnings as your validator is selected as leader and collects transaction fees
|
||||
* Solana nodes offer a number of useful JSON-RPC methods to return information about the network and your validator's participation. Make a request by using curl \(or another http client of your choosing\), specifying the desired method in JSON-RPC-formatted data. For example:
|
||||
* After your validator is caught up, use the `$ solana balance` command to monitor
|
||||
the earnings as your validator is selected as leader and collects transaction
|
||||
fees
|
||||
* Solana nodes offer a number of useful JSON-RPC methods to return information
|
||||
about the network and your validator's participation. Make a request by using
|
||||
curl \(or another http client of your choosing\), specifying the desired method
|
||||
in JSON-RPC-formatted data. For example:
|
||||
|
||||
```bash
|
||||
// Request
|
||||
|
@ -80,20 +126,40 @@ Confirm your validator becomes a [leader](../terminology.md#leader)
|
|||
|
||||
Helpful JSON-RPC methods:
|
||||
|
||||
* `getEpochInfo`[ An epoch](../terminology.md#epoch) is the time, i.e. number of [slots](../terminology.md#slot), for which a [leader schedule](../terminology.md#leader-schedule) is valid. This will tell you what the current epoch is and how far into it the cluster is.
|
||||
* `getVoteAccounts` This will tell you how much active stake your validator currently has. A % of the validator's stake is activated on an epoch boundary. You can learn more about staking on Solana [here](../cluster/stake-delegation-and-rewards.md).
|
||||
* `getLeaderSchedule` At any given moment, the network expects only one validator to produce ledger entries. The [validator currently selected to produce ledger entries](../cluster/leader-rotation.md#leader-rotation) is called the “leader”. This will return the complete leader schedule \(on a slot-by-slot basis\) for the current epoch. If you validator is scheduled to be leader based on its currently activated stake, the identity pubkey will show up 1 or more times here.
|
||||
* `getEpochInfo`[An epoch](../terminology.md#epoch) is the time, i.e. number of
|
||||
[slots](../terminology.md#slot), for which a [leader schedule](../terminology.md#leader-schedule)
|
||||
is valid. This will tell you what
|
||||
the current epoch is and how far into it the cluster is.
|
||||
* `getVoteAccounts` This will tell you how much active stake your validator
|
||||
currently has. A % of the validator's stake is activated on an epoch boundary.
|
||||
You can learn more about staking on Solana
|
||||
[here](../cluster/stake-delegation-and-rewards.md).
|
||||
* `getLeaderSchedule` At any given moment, the network expects only one validator
|
||||
to produce ledger entries. The [validator currently selected to produce ledger
|
||||
entries](../cluster/leader-rotation.md#leader-rotation) is called the “leader”.
|
||||
This will return the complete leader schedule \(on a slot-by-slot basis\) for
|
||||
the current epoch. If you validator is scheduled to be leader based on its
|
||||
currently activated stake, the identity pubkey will show up 1 or more times
|
||||
here.
|
||||
|
||||
## Deactivating Stake
|
||||
|
||||
Before detaching your validator from the TdS cluster, you should deactivate the stake that was previously delegated by running:
|
||||
Before detaching your validator from the cluster, you should deactivate the
|
||||
stake that was previously delegated by running:
|
||||
|
||||
```bash
|
||||
solana deactivate-stake ~/validator-stake-keypair.json
|
||||
```
|
||||
|
||||
Stake is not deactivated immediately and instead cools down in a similar fashion as stake warm up. Your validator should remain attached to the cluster while the stake is cooling down. While cooling down, your stake will continue to earn rewards. Only after stake cooldown is it safe to turn off your validator or withdraw it from the network. Cooldown may take several epochs to complete, depending on active stake and the size of your stake.
|
||||
Stake is not deactivated immediately and instead cools down in a similar fashion
|
||||
as stake warm up. Your validator should remain attached to the cluster while
|
||||
the stake is cooling down. While cooling down, your stake will continue to earn
|
||||
rewards. Only after stake cooldown is it safe to turn off your validator or
|
||||
withdraw it from the network. Cooldown may take several epochs to complete,
|
||||
depending on active stake and the size of your stake.
|
||||
|
||||
Note that a stake account may only be used once, so after deactivation, use the cli's `withdraw-stake` command to recover the previously staked lamports.
|
||||
Note that a stake account may only be used once, so after deactivation, use the
|
||||
cli's `withdraw-stake` command to recover the previously staked lamports.
|
||||
|
||||
Be sure and redeem your credits before withdrawing all your lamports. Once the account is fully withdrawn, the account is destroyed.
|
||||
Be sure and redeem your credits before withdrawing all your lamports. Once the
|
||||
account is fully withdrawn, the account is destroyed.
|
||||
|
|
|
@ -2,7 +2,10 @@
|
|||
|
||||
## Confirm The Testnet Is Reachable
|
||||
|
||||
Before attaching a validator node, sanity check that the cluster is accessible to your machine by running some simple commands. If any of the commands fail, please retry 5-10 minutes later to confirm the testnet is not just restarting itself before debugging further.
|
||||
Before attaching a validator node, sanity check that the cluster is accessible
|
||||
to your machine by running some simple commands. If any of the commands fail,
|
||||
please retry 5-10 minutes later to confirm the testnet is not just restarting
|
||||
itself before debugging further.
|
||||
|
||||
Fetch the current transaction count over JSON RPC:
|
||||
|
||||
|
@ -10,13 +13,16 @@ Fetch the current transaction count over JSON RPC:
|
|||
curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1, "method":"getTransactionCount"}' http://testnet.solana.com:8899
|
||||
```
|
||||
|
||||
Inspect the network explorer at [https://explorer.solana.com/](https://explorer.solana.com/) for activity.
|
||||
Inspect the network explorer at
|
||||
[https://explorer.solana.com/](https://explorer.solana.com/) for activity.
|
||||
|
||||
View the [metrics dashboard](https://metrics.solana.com:3000/d/testnet-beta/testnet-monitor-beta?var-testnet=testnet) for more detail on cluster activity.
|
||||
View the [metrics dashboard](https://metrics.solana.com:3000/d/testnet-beta/testnet-monitor-beta?var-testnet=testnet)
|
||||
for more detail on cluster activity.
|
||||
|
||||
## Confirm your Installation
|
||||
|
||||
Try running following command to join the gossip network and view all the other nodes in the cluster:
|
||||
Try running following command to join the gossip network and view all the other
|
||||
nodes in the cluster:
|
||||
|
||||
```bash
|
||||
solana-gossip --entrypoint testnet.solana.com:8001 spy
|
||||
|
@ -25,13 +31,28 @@ solana-gossip --entrypoint testnet.solana.com:8001 spy
|
|||
|
||||
## Enabling CUDA
|
||||
|
||||
If your machine has a GPU with CUDA installed \(Linux-only currently\), include the `--cuda` argument to `solana-validator`.
|
||||
If your machine has a GPU with CUDA installed \(Linux-only currently\), include
|
||||
the `--cuda` argument to `solana-validator`.
|
||||
|
||||
```bash
|
||||
export SOLANA_CUDA=1
|
||||
```
|
||||
|
||||
When your validator is started look for the following log message to indicate that CUDA is enabled: `"[<timestamp> solana::validator] CUDA is enabled"`
|
||||
When your validator is started look for the following log message to indicate
|
||||
that CUDA is enabled: `"[<timestamp> solana::validator] CUDA is enabled"`
|
||||
|
||||
## Tune System
|
||||
|
||||
For Linux validators, the solana repo includes a script to adjust system
|
||||
settings to optimize performance (namely by increasing the OS UDP buffer limits).
|
||||
|
||||
Download the script here: https://github.com/solana-labs/solana/blob/master/scripts/tune-system.sh
|
||||
|
||||
And run:
|
||||
|
||||
```bash
|
||||
./tune-system.sh
|
||||
```
|
||||
|
||||
## Generate identity
|
||||
|
||||
|
@ -44,23 +65,38 @@ solana-keygen new -o ~/validator-keypair.json
|
|||
The identity public key can now be viewed by running:
|
||||
|
||||
```bash
|
||||
solana-keygen pubkey ~/validator-keypair.json
|
||||
solana-keygen pubkey ~/validator-keypair.json
|
||||
```
|
||||
|
||||
> Note: The "validator-keypair.json” file is also your \(ed25519\) private key.
|
||||
|
||||
Your validator identity keypair uniquely identifies your validator within the network. **It is crucial to back-up this information.**
|
||||
Your validator identity keypair uniquely identifies your validator within the
|
||||
network. **It is crucial to back-up this information.**
|
||||
|
||||
If you don’t back up this information, you WILL NOT BE ABLE TO RECOVER YOUR VALIDATOR if you lose access to it. If this happens, YOU WILL LOSE YOUR ALLOCATION OF LAMPORTS TOO.
|
||||
If you don’t back up this information, you WILL NOT BE ABLE TO RECOVER YOUR
|
||||
VALIDATOR if you lose access to it. If this happens, YOU WILL LOSE YOUR
|
||||
ALLOCATION OF LAMPORTS TOO.
|
||||
|
||||
To back-up your validator identify keypair, **back-up your "validator-keypair.json” file to a secure location.**
|
||||
To back-up your validator identify keypair, **back-up your
|
||||
"validator-keypair.json” file to a secure location.**
|
||||
|
||||
### Vanity Keypair
|
||||
|
||||
You can generate a custom vanity keypair using solana-keygen. For instance:
|
||||
|
||||
```bash
|
||||
solana-keygen grind --starts-with e1v1s
|
||||
```
|
||||
|
||||
Depending on the string requested, it may take days to find a match...
|
||||
|
||||
## Wallet Configuration
|
||||
|
||||
You can set solana configuration to use your validator keypair and the stable testnet for all following commands:
|
||||
Set solana configuration to use your validator keypair and the stable
|
||||
testnet for all following commands:
|
||||
|
||||
```bash
|
||||
solana set set --url http://testnet.solana.com:8899 --keypair ~/validator-keypair.json
|
||||
solana set --url http://testnet.solana.com:8899 --keypair ~/validator-keypair.json
|
||||
```
|
||||
|
||||
You should see the following output:
|
||||
|
@ -95,7 +131,9 @@ Read more about the [difference between SOL and lamports here](../introduction.m
|
|||
|
||||
## Create Vote Account
|
||||
|
||||
If you haven’t already done so, create a vote-account keypair and create the vote account on the network. If you have completed this step, you should see the “validator-vote-keypair.json” in your Solana runtime directory:
|
||||
If you haven’t already done so, create a vote-account keypair and create the
|
||||
vote account on the network. If you have completed this step, you should see the
|
||||
“validator-vote-keypair.json” in your Solana runtime directory:
|
||||
|
||||
```bash
|
||||
solana-keygen new -o ~/validator-vote-keypair.json
|
||||
|
@ -117,9 +155,11 @@ solana-validator --identity-keypair ~/validator-keypair.json --voting-keypair ~/
|
|||
--limit-ledger-size
|
||||
```
|
||||
|
||||
To force validator logging to the console add a `--log -` argument, otherwise the validator will automatically log to a file.
|
||||
To force validator logging to the console add a `--log -` argument, otherwise
|
||||
the validator will automatically log to a file.
|
||||
|
||||
Confirm your validator connected to the network by opening a new terminal and running:
|
||||
Confirm your validator connected to the network by opening a new terminal and
|
||||
running:
|
||||
|
||||
```bash
|
||||
solana-gossip spy --entrypoint testnet.solana.com:8001
|
||||
|
@ -129,8 +169,12 @@ If your validator is connected, its public key and IP address will appear in the
|
|||
|
||||
### Controlling local network port allocation
|
||||
|
||||
By default the validator will dynamically select available network ports in the 8000-10000 range, and may be overridden with `--dynamic-port-range`. For example, `solana-validator --dynamic-port-range 11000-11010 ...` will restrict the validator to ports 11000-11011.
|
||||
By default the validator will dynamically select available network ports in the
|
||||
8000-10000 range, and may be overridden with `--dynamic-port-range`. For
|
||||
example, `solana-validator --dynamic-port-range 11000-11010 ...` will restrict
|
||||
the validator to ports 11000-11011.
|
||||
|
||||
### Limiting ledger size to conserve disk space
|
||||
|
||||
The `--limit-ledger-size` arg will instruct the validator to only retain the last couple hours of ledger. To retain the full ledger, simply remove that arg.
|
||||
The `--limit-ledger-size` arg will instruct the validator to only retain the
|
||||
last couple hours of ledger. To retain the full ledger, simply remove that arg.
|
||||
|
|
|
@ -1,6 +1,8 @@
|
|||
# Choosing a Testnet
|
||||
|
||||
As noted in the overview, solana currently maintains several testnets, each featuring a validator that can serve as the entrypoint to the cluster for your validator.
|
||||
As noted in the overview, solana currently maintains several testnets, each
|
||||
featuring a validator that can serve as the entrypoint to the cluster for your
|
||||
validator.
|
||||
|
||||
Current testnet entrypoints:
|
||||
|
||||
|
@ -8,7 +10,10 @@ Current testnet entrypoints:
|
|||
* Beta, beta.testnet.solana.com
|
||||
* Edge, edge.testnet.solana.com
|
||||
|
||||
Prior to mainnet, the testnets may be running different versions of solana software, which may feature breaking changes. Generally, the edge testnet tracks the tip of master, beta tracks the latest tagged minor release, and stable tracks the most stable tagged release.
|
||||
Prior to mainnet, the testnets may be running different versions of solana
|
||||
software, which may feature breaking changes. Generally, the edge testnet tracks
|
||||
the tip of master, beta tracks the latest tagged minor release, and stable
|
||||
tracks the most stable tagged release.
|
||||
|
||||
### Get Testnet Version
|
||||
|
||||
|
@ -16,16 +21,19 @@ You can submit a JSON-RPC request to see the specific version of the cluster.
|
|||
|
||||
```bash
|
||||
curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1, "method":"getVersion"}' edge.testnet.solana.com:8899
|
||||
{"jsonrpc":"2.0","result":{"solana-core":"0.18.0-pre1"},"id":1}
|
||||
{"jsonrpc":"2.0","result":{"solana-core":"0.21.0"},"id":1}
|
||||
```
|
||||
|
||||
## Using a Different Testnet
|
||||
|
||||
This guide is written in the context of testnet.solana.com, our most stable cluster. To participate in another testnet, you will need to modify some of the commands in the following pages.
|
||||
This guide is written in the context of testnet.solana.com, our most stable
|
||||
cluster. To participate in another testnet, you will need to modify some of the
|
||||
commands in the following pages.
|
||||
|
||||
### Downloading Software
|
||||
|
||||
If you are bootstrapping with `solana-install`, you can specify the release tag or named channel to install to match your desired testnet.
|
||||
If you are bootstrapping with `solana-install`, you can specify the release tag
|
||||
or named channel to install to match your desired testnet.
|
||||
|
||||
```bash
|
||||
curl -sSf https://raw.githubusercontent.com/solana-labs/solana/v0.21.0/install/solana-install-init.sh | sh -s - 0.21.0
|
||||
|
@ -41,26 +49,31 @@ Similarly, you can add this argument to the `solana-install` command if you've b
|
|||
solana-install init 0.21.0
|
||||
```
|
||||
|
||||
If you are downloading pre-compiled binaries or building from source, simply choose the release matching your desired testnet.
|
||||
If you are downloading pre-compiled binaries or building from source, simply
|
||||
choose the release matching your desired testnet.
|
||||
|
||||
### Validator Commands
|
||||
|
||||
The Solana CLI tool points at testnet.solana.com by default. Include a `--url` argument to point at a different testnet. For instance:
|
||||
The Solana CLI tool points at testnet.solana.com by default. Include a `--url`
|
||||
argument to point at a different testnet. For instance:
|
||||
|
||||
```bash
|
||||
solana --url http://beta.testnet.solana.com:8899 balance
|
||||
```
|
||||
|
||||
The solana cli includes `get` and `set` configuration commands to automatically set the `--url` argument for future cli commands. For example:
|
||||
The solana cli includes `get` and `set` configuration commands to automatically
|
||||
set the `--url` argument for future cli commands. For example:
|
||||
|
||||
```bash
|
||||
solana set --url http://beta.testnet.solana.com:8899
|
||||
solana balance # Same result as command above
|
||||
```
|
||||
|
||||
\(You can always override the set configuration by explicitly passing the `--url` argument with a command.\)
|
||||
\(You can always override the set configuration by explicitly passing the
|
||||
`--url` argument with a command.\)
|
||||
|
||||
Solana-gossip and solana-validator commands already require an explicit `--entrypoint` argument. Simply replace testnet.solana.com in the examples with an alternate url to interact with a different testnet. For example:
|
||||
Solana-gossip and solana-validator commands already require an explicit
|
||||
`--entrypoint` argument. Simply replace testnet.solana.com in the examples with
|
||||
an alternate url to interact with a different testnet. For example:
|
||||
|
||||
```bash
|
||||
solana-validator --identity-keypair ~/validator-keypair.json --voting-keypair ~/validator-vote-keypair.json --ledger ~/validator-config --rpc-port 8899 beta.testnet.solana.com
|
||||
|
|
|
@ -1,6 +1,7 @@
|
|||
# Troubleshooting
|
||||
|
||||
There is a **\#validator-support** Discord channel available to reach other testnet participants, [https://discord.gg/pquxPsq](https://discord.gg/pquxPsq).
|
||||
There is a **\#validator-support** Discord channel available to reach other
|
||||
testnet participants, [https://discord.gg/pquxPsq](https://discord.gg/pquxPsq).
|
||||
|
||||
## Useful Links & Discussion
|
||||
* [Tour de SOL Docs](https://docs.solana.com/tour-de-sol)
|
||||
|
|
Loading…
Reference in New Issue