Starting Validator
Configure Renec CLI#
The renec cli includes get and set configuration commands to automatically
set the --url argument for cli commands. For example:
Confirm The Cluster Is Reachable#
Before attaching a validator node, sanity check that the cluster is accessible to your machine by fetching the transaction count:
Generate identity#
Create an identity keypair for your validator by running:
The identity public key can now be viewed by running:
Note: The "validator-keypair.json” file is also your (ed25519) private key.
See Paper Wallet Usage for more info.
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 RENEC TOO.
To back-up your validator identify keypair, back-up your "validator-keypair.json” file or your seed phrase to a secure location.
More Renec CLI Configuration#
Now that you have a keypair, set the renec configuration to use your validator keypair for all following commands:
You should see the following output:
Create Authorized Withdrawer Account#
If you haven't already done so, create an authorized-withdrawer keypair to be used as the ultimate authority over your validator. This keypair will have the authority to withdraw from your vote account, and will have the additional authority to change all other aspects of your vote account. Needless to say, this is a very important keypair as anyone who possesses it can make any changes to your vote account, including taking ownership of it permanently. So it is very important to keep your authorized-withdrawer keypair in a safe location. It does not need to be stored on your validator, and should not be stored anywhere from where it could be accessed by unauthorized parties. To create your authorized-withdrawer keypair:
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 “vote-account-keypair.json” in your Renec runtime directory:
The following command can be used to create your vote account on the blockchain with all the default options:
Remember to move your authorized withdrawer keypair into a very secure location after running the above command.
Read more about creating and managing a vote account.
Connect Your Validator#
Connect to the cluster by running (this configuration is for testnet):
To force validator logging to the console add a --log - argument, otherwise
the validator will automatically log to a file.
The ledger will be placed in the ledger/ directory by default, use the
--ledger argument to specify a different location.
Confirm your validator is connected to the network by opening a new terminal and running:
If your validator is connected, its public key and IP address will appear in the list.
Controlling local network port allocation#
By default the validator will dynamically select available network ports in the
8000-10000 range, and may be overridden with --dynamic-port-range. For
example, renec-validator --dynamic-port-range 11000-11020 ... will restrict
the validator to ports 11000-11020.
Limiting ledger size to conserve disk space#
The --limit-ledger-size parameter allows you to specify how many ledger
shreds your node retains on disk. If you do not
include this parameter, the validator will keep the entire ledger until it runs
out of disk space.
The default value attempts to keep the ledger disk usage under 500GB. More or
less disk usage may be requested by adding an argument to --limit-ledger-size
if desired. Check renec-validator --help for the default limit value used by
--limit-ledger-size. More information about
selecting a custom limit value is available
here.
Systemd Unit#
Running the validator as a systemd unit is one easy way to manage running in the background.
Assuming you have a user called renec on your machine (remember replace all /home/renec to /home/{your_os_user}), create the file /etc/systemd/system/renec.service with
the following:
Start the service with:
Advance configurations#
Enabling CUDA#
If your machine has a GPU with CUDA installed (Linux-only currently), include
the --cuda argument to renec-validator.
When your validator is started look for the following log message to indicate
that CUDA is enabled: "[<timestamp> renec::validator] CUDA is enabled"
System Tuning#
Linux#
Automatic#
The renec repo includes a daemon to adjust system settings to optimize performance (namely by increasing the OS UDP buffer and file mapping limits).
The daemon (renec-sys-tuner) is included in the renec binary release. Restart
it, before restarting your validator, after each software upgrade to ensure that
the latest recommended settings are applied.
To run it:
Known validators#
If you know and respect other validator operators, you can specify this on the command line with the --known-validator <PUBKEY>
argument to renec-validator. You can specify multiple ones by repeating the argument --known-validator <PUBKEY1> --known-validator <PUBKEY2>.
This has two effects, one is when the validator is booting with --only-known-rpc, it will only ask that set of
known nodes for downloading genesis and snapshot data. Another is that in combination with the --halt-on-known-validators-accounts-hash-mismatch option,
it will monitor the merkle root hash of the entire accounts state of other known nodes on gossip and if the hashes produce any mismatch,
the validator will halt the node to prevent the validator from voting or processing potentially incorrect state values. At the moment, the slot that
the validator publishes the hash on is tied to the snapshot interval. For the feature to be effective, all validators in the known
set should be set to the same snapshot interval value or multiples of the same.
It is highly recommended you use these options to prevent malicious snapshot state download or account state divergence.
Logging#
Log output tuning#
The messages that a validator emits to the log can be controlled by the RUST_LOG
environment variable. Details can by found in the documentation
for the env_logger Rust crate.
Note that if logging output is reduced, this may make it difficult to debug issues encountered later. Should support be sought from the team, any changes will need to be reverted and the issue reproduced before help can be provided.
Log rotation#
The validator log file, as specified by --log /home/renec/renec-validator.log, can get
very large over time and it's recommended that log rotation be configured.
The validator will re-open its when it receives the USR1 signal, which is the
basic primitive that enables log rotation.
If the validator is being started by a wrapper shell script, it is important to
launch the process with exec (exec renec-validator ...) when using logrotate.
This will prevent the USR1 signal from being sent to the script's process
instead of the validator's, which will kill them both.
Using logrotate#
An example setup for the logrotate, which assumes that the validator is
running as a systemd service called renec.service and writes a log file at
/home/renec/renec-validator.log:
As mentioned earlier, be sure that if you use logrotate, any script you create which starts the renec validator process uses "exec" to do so (example: "exec renec-validator ..."); otherwise, when logrotate sends its signal to the validator, the enclosing script will die and take the validator process with it.
Disable port checks to speed up restarts#
Once your validator is operating normally, you can reduce the time it takes to
restart your validator by adding the --no-port-check flag to your
renec-validator command-line.
Using a ramdisk with spill-over into swap for the accounts database to reduce SSD wear#
If your machine has plenty of RAM, a tmpfs ramdisk (tmpfs) may be used to hold the accounts database
When using tmpfs it's essential to also configure swap on your machine as well to avoid running out of tmpfs space periodically.
A 300GB tmpfs partition is recommended, with an accompanying 250GB swap partition.
Example configuration:
sudo mkdir /mnt/renec-accounts- Add a 300GB tmpfs parition by adding a new line containing
tmpfs /mnt/renec-accounts tmpfs rw,size=300G,user=renec 0 0to/etc/fstab(assuming your validator is running under the user "renec"). CAREFUL: If you incorrectly edit /etc/fstab your machine may no longer boot - Create at least 250GB of swap space
- Choose a device to use in place of
SWAPDEVfor the remainder of these instructions. Ideally select a free disk partition of 250GB or greater on a fast disk. If one is not available, create a swap file withsudo dd if=/dev/zero of=/swapfile bs=1MiB count=250KiB, set its permissions withsudo chmod 0600 /swapfileand use/swapfileasSWAPDEVfor the remainder of these instructions - Format the device for usage as swap with
sudo mkswap SWAPDEV
- Add the swap file to
/etc/fstabwith a new line containingSWAPDEV swap swap defaults 0 0 - Enable swap with
sudo swapon -aand mount the tmpfs withsudo mount /mnt/renec-accounts/ - Confirm swap is active with
free -gand the tmpfs is mounted withmount
Now add the --accounts /mnt/renec-accounts argument to your renec-validator
command-line arguments and restart the validator.
Account indexing#
As the number of populated accounts on the cluster grows, account-data RPC
requests that scan the entire account set -- like
getProgramAccounts and
SPL-token-specific requests --
may perform poorly. If your validator needs to support any of these requests,
you can use the --account-index parameter to activate one or more in-memory
account indexes that significantly improve RPC performance by indexing accounts
by the key field. Currently supports the following parameter values:
program-id: each account indexed by its owning program; used bygetProgramAccountsspl-token-mint: each SPL token account indexed by its token Mint; used by getTokenAccountsByDelegate, and getTokenLargestAccountsspl-token-owner: each SPL token account indexed by the token-owner address; used by getTokenAccountsByOwner, andgetProgramAccountsrequests that include an spl-token-owner filter.