rippled Server Modes
rippled server software can run in several modes depending on its configuration, including:
- Stock server - follows the network with a local copy of the ledger.
- Validating server, or validator for short - participates in consensus (and does everything a stock server does, too).
rippledserver in stand-alone mode - for testing. Does not communicate to other
You can also run the
rippled executable as a client application for accessing
rippled APIs locally. (Two instances of the same binary can run side-by-side in this case; one as a server, and the other running briefly as a client and then terminating.)
For information on the commands to run rippled in each of these modes, see the Commandline Reference.
Reasons to Run a Stock Server
There are lots of reasons you might want to run your own
rippled server, but most of them can be summarized as: you can trust your own server, you have control over its workload, and you're not at the mercy of others to decide when and how you can access it. Of course, you must practice good network security to protect your server from malicious hackers.
You need to trust the
rippled you use. If you connect to a malicious server, there are many ways that it can take advantage of you or cause you to lose money. For example:
- A malicious server could report that you were paid when no such payment was made.
- It could selectively show or hide payment paths and currency exchange offers to guarantee its own profit while not providing you the best deal.
- If you sent it your address's secret key, it could make arbitrary transactions on your behalf, and even transfer or destroy all the money your address holds.
Additionally, running your own server gives you admin control over it, which allows you to run important admin-only and load-intensive commands. If you use a shared server, you have to worry about other users of the same server competing with you for the server's computing power. Many of the commands in the WebSocket API can put a lot of strain on the server, so
rippled has the option to scale back its responses when it needs to. If you share a server with others, you may not always get the best results possible.
Finally, if you run a validating server, you can use a stock server as a proxy to the public network while keeping your validating server on a private subnet only accessible to the outside world through the stock server. This makes it more difficult to compromise the integrity of your validating server.
Reasons to Run a Validator
The robustness of the XRP Ledger depends on an interconnected web of validators who each trust a few other validators not to collude. The more operators with different interests there are who run validators, the more certain each member of the network can be that it continues to run impartially. If you or your organization relies on the XRP Ledger, it is in your interest to contribute to the consensus process.
rippled servers need to be validators: trusting more servers from the same operator does not offer better protection against collusion. An organization might run validators in multiple regions for redundancy in case of natural disasters and other emergencies.
If your organization runs a validating server, you may also run one or more stock servers, to balance the computing load of API access, or as a proxy between your validation server and the outside network.
Properties of a Good Validator
There are several properties that define a good validator. The more of these properties your server embodies, the more reason others have to include your server in their list of trusted validators:
- Availability. An ideal validator should always be running, submitting validation votes for every proposed ledger.
- Strive for 100% uptime.
- Agreement. A validator's votes should match the outcome of the consensus process as often as possible. To do otherwise could indicate that the validator's software is outdated, buggy, or intentionally biased.
- Always run the latest
rippledrelease without modifications.
- Always run the latest
- Timeliness. A validator's votes should arrive quickly, and not after a consensus round has already finished.
- A fast internet connection helps with this.
- Identified. It should be clear who runs the validator. Ideally, a list of trusted validators should include validators operated by different owners in multiple legal jurisdictions and geographic areas, to reduce the chance that any localized events could interfere with the validator's impartial operation.
- Setting up Domain Verification is a good start.
At present, Ripple (the company) cannot recommend any validators aside from those in the default validator list. However, we are collecting data on other validators and building tools to report on their performance. For metrics on validators, see the XRPCharts Validator Registry.
Reasons to Run a
rippled Server in Stand-Alone Mode
You can run
rippled in stand-alone mode without a consensus of trusted servers. In stand-alone mode,
rippled does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing
rippled behavior without being tied to the live network. For example, you can test the effects of Amendments before those Amendments have gone into effect across the decentralized network.
When you run
rippled in stand-alone mode, you have to tell it what ledger version to start from:
Caution: In stand-alone mode, you must manually advance the ledger.
- Commandline Usage Reference - Detailed information on command-line options for all