Run rippled as a Validator
rippled server running in validator mode does everything a stock server does:
Connects to a network of peers
Relays cryptographically signed transactions
Maintains a local copy of the complete shared global ledger
What makes a validator different is that it also issues validation messages, which are sets of candidate transactions for evaluation by the XRP Ledger network during the consensus process.
It's important to understand that these validation messages are used only by
rippled servers that explicitly trust your validator by listing it on their Unique Node Lists (UNLs). Servers that do not include your validator in their UNLs ignore your validator's messages in the consensus process. A validator that is not included in any UNL is called an untrusted validator.
For this reason, aside from getting your validator up and running, another key aspect of operating a validator is putting infrastructure in place that builds trust in your validator. Before validation list publishers, such as https://vl.ripple.com, can add your validator to their UNLs, they must first have trust in your validator. Once your validator has been added to a UNL, it is a trusted validator that participates in the consensus process.
To run a
rippled server as a validator, complete the following tasks:
rippledserver. For more information, see Install rippled.
Beyond this, you can optionally complete the following tasks that help build trust in your validator:
Enable Validation on Your
Enabling validation on your
rippled server means providing a validator token in your server's
rippled.cfg file. Ripple recommends using the
validator-keys tool (included in
rippled RPMs) to securely generate and manage your validator keys and tokens.
In a location not on your validator:
Manually build and run the
validator-keystool, if you don't already have it installed via a
For information about manually building and running the
validator-keystool, see validator-keys-tool.
Generate a validator key pair using the
$ validator-keys create_keys
Sample output on Ubuntu:
Validator keys stored in /home/my-user/.ripple/validator-keys.json This file should be stored securely and not shared.
Sample output on macOS:
Validator keys stored in /Users/my-user/.ripple/validator-keys.json This file should be stored securely and not shared.
Warning: Store the generated
validator-keys.jsonkey file in a secure, offline, and recoverable location, such as an encrypted USB flash drive. Do not modify its contents. In particular, be sure to not store the key file on the validator where you intend to use the keys. If your validator's
secret_keyis compromised, revoke the key immediately.
For more information about the
validator-keystool and the key pairs it generates, see the Validator Keys Tool Guide.
Generate a validator token using the
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
Update rippled.cfg file with these values: # validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr [validator_token] eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2 hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1 NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
On your validator:
[validator_token]and its value to your validator's
If you previously configured your validator without the
[validation_seed]and its value from your
rippled.cfgfile. This changes your validator public key.
$ sudo systemctl restart rippled.service
server_infocommand to get information about your validator to verify that it is running as a validator.
$ rippled server_info
pubkey_validatorvalue in the response should match the
validator-keys.jsonfile that you generated for use with your validator.
server_statevalue should be proposing.
Understand the Traits of a Good Validator
Not every validator is likely to be widely trusted and validator list publishers may require validators to meet stringent criteria before they list them in their UNLs.
Strive to have your validator always embody the following properties. The more of these properties your validator embodies, the more reasons validator list publishers have to include it on their UNLs.
A good validator is always running and submitting validation votes for every proposed ledger. Strive for 100% uptime.
A good validator's votes match the outcome of the consensus process as often as possible. To do otherwise could indicate that your validator's software is outdated, buggy, or intentionally biased. Always run the latest
rippledrelease without modifications. Watch
rippledreleases to be notified of new releases.
Issuing timely votes
A good validator's votes arrive quickly and not after a consensus round has already finished. To keep your votes timely, make sure your validator meets the recommended system requirements, which include a fast internet connection.
A good validator has a clearly identified owner. Providing domain verification is a good start. Ideally, XRP Ledger network UNLs include validators operated by different owners in multiple legal jurisdictions and geographic areas. This reduces the chance that any localized events could interfere with the impartial operations of trusted validators.
It's worth noting that running an untrusted validator can also be helpful to the overall health of the network. Untrusted validators help set the standard that trusted validators are measured against. For example, if a trusted validator is disagreeing with a lot of untrusted validators, that might indicate a problem.
Ripple (the company) publishes a validator list with a set of recommended validators. Ripple strongly recommends using exactly this list for production servers.
Set Up Proxies to Help Protect Your Validator
To help protect a validator from DDoS attacks, set up one or more stock
rippled servers as proxies between your validator and inbound and outbound traffic.
Note: While these servers are acting as proxies, they are not web proxies for HTTP(S) traffic.
Enable validation on your
Set up stock
rippledservers. For more information, see Install rippled.
Configure your validator and stock
rippledservers to run in a cluster.
In your validator's
[ips_fixed]IP address list you defined in the previous cluster configuration step and paste it under
For this purpose, the
[ips]values must be identical and contain only the IP addresses and ports of the stock
rippledservers you clustered with your validator. This ensures that your validator connects to only the stock
rippledservers that you control.
1to prevent your validator's IP address from being forwarded. For more information, see Private Peers.
Warning: Be sure that you don't publish your validator's IP address in other ways.
Configure your validator host machine's firewall to allow the following traffic only:
Inbound traffic: Only from IP addresses of the stock
rippledservers in the cluster you configured.
Outbound traffic: Only to the IP addresses of the stock
rippledservers in the cluster you configured and to https://vl.ripple.com through port 443.
$ sudo systemctl restart rippled.service
Use the Peer Crawler endpoint on one of your stock
rippledservers. The response should not include your validator. This verifies that your validator's
[peer_private]configuration is working. One of the effects of enabling
[peer_private]on your validator is that your validator's peers do not include it in their Peer Crawler results.
Provide Domain Verification
To help validation list publishers and other participants in the XRP Ledger network understand who operates your validator, provide domain verification for your validator. At a high level, domain verification is a two-way link:
Use your domain to claim ownership of a validator key.
Use your validator key to claim ownership of a domain.
Creating this link establishes strong evidence that you own both the validator key and the domain.
To provide domain verification:
Choose a domain name you own that you want to be publicly associated with your validator. You must run a public-facing HTTPS server on port 443 of that domain and you must have access to the private key file associated with that server's TLS certificate. (Note: TLS was formerly called SSL.)
Share your validator's public key with the public, especially other
rippledoperators. For example, you can share your validator's public key on your website, on social media, in the XRPChat community forum, or in a press release.
Submit a request to have your validator listed in XRP Charts' Validator Registry using this Google Form. Having your validator listed in this registry provides another form of public verification that your validator and domain are owned by you. To complete the form, you'll need the following information:
Find your validator public key by running the following on the validator server.
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
Provide the value returned in the Validator Public Key field of the Google Form.
Sign the validator public key using your web domain's TLS private key. The TLS private key file does not need to be stored on your validator's server.
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
Provide the value returned in the SSL Signature field of the Google Form.
validator-keystool (included in
rippledRPMs), sign the domain name.
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
Provide the value returned in the Domain Signature field of the Google Form.
After submitting the completed Google Form, you'll receive an email from XRP Charts that tells you whether your domain verification succeeded or failed. If your domain verification succeeds, XRP Charts lists your validator and domain in its Validator Registry.
Revoke Validator Keys
If your validator's master private key is compromised, you must revoke it immediately and permanently.
For information about how to revoke a master key pair you generated for your validator using the
validator-keys tool, see Key Revocation.