Every so often, I come across posts from XRP community members asking what type of rippled node they should run to best help the network. In this blog, I explore the benefits that validating and stock nodes offer the broader XRP Ledger.
TL;DR
If you are thinking about running a rippled validating node, consider running a stock node first, to ensure you can maintain availability and security. Stock nodes can also provide benefits like history sharding and API calls. I would very much like to see more stock nodes that allow the public to make API calls.
Validating nodes:
- Participate in consensus.
- Vote on fees and amendments.
Stock nodes:
- Store ledger history.
- Allow API calls.
- Protect validating nodes.
Terminology
- Node: a server.
- rippled: The free and open source software that XRPL nodes run. Anyone can run or modify the code.
- Validating node: a rippled node that is configured to participate in consensus and vote on fees and amendments.
- Stock (AKA non-validating or tracking) node: a rippled node that does not participate in consensus or voting.
- UNL: Unique Node List. Each rippled node has its own UNL specifying what validating nodes it trusts.
Validating Nodes
The only real difference between a validating node and a stock node is a few lines in a configuration file. Both nodes run the same rippled software, however, validating nodes are configured to participate in the consensus process. If a validating node operator chooses, they can also vote on amendments, fees, wallet reserves, and other factors that impact the Ledger. A quality rippled validating node has these properties[1]:
- Availability
- Agreement
- Timeliness
- Identified
These four characteristics make operating a quality validating node more difficult than operating a stock node.
In addition to strong security knowledge (firewalld, selinux, SSH, etc.), maintaining availability likely entails custom monitoring software to automatically alert the operator to issues with the node, so they can promptly remedy them. Pre-planning for outages and reducing downtime during updates are also important.
Maintaining availability means having consistent access to one's validating node. One can't run off to visit friends in Antarctica, without first ensuring that someone can monitor for and respond to outages. This also means that your home is likely not the place to host a validating node. Power and internet outages, theft, cats pouncing on surge protectors, and a myriad of other factors can impact nodes hosted from home.
Running services other than rippled creates a broader attack vector, takes resources from rippled, and risks diminishing availability and agreement. In my opinion, an ideal validating node will generally not run anything aside from a minimal, hardened CentOS 7 or Ubuntu install and rippled. Additional services pose a security risk, as they may provide opportunities for malicious access to the private validation seed or token, which is stored on the node. If one's private validation token is stolen, the thief could pose as the validator operator.
Ideally, validating nodes are clustered with at least two stock nodes, to prevent DoS attacks and to preserve availability while updating the stock nodes. This configuration enables the validating node to be cut off from the internet, except for messages to/from other trusted nodes in the cluster and SSH connections via a LAN connection. Using two stock nodes provides redundant communication to the validating node, which is useful in case one of the stock nodes crashes or goes offline. However, this means a validating node has 3x the cost, 3x the monitoring, and 3x the time commitment of a stock node. Future availability is also important. Thus validating node operators must have adequate financial resources to commit to running the node cluster for years to come.
While availability is a precursor to agreement (if a node isn't online, it can't agree), there are additional factors that influence agreement, particularly memory and running version current rippled. Production validating nodes should have at least 32 GB of memory as well as a 50 GB+ solid state drive[2].
Timeliness is impacted by things like internet connection speed and latency. Data centers likely have faster, more reliable internet connections.
Trust building is foundational to running a validating node. If other node operators don't include your node's public validation key in their UNL, your node's votes will not impact the network. This means building a reputation among other node operators and evaluating what activities one can engage in to gain trust. When choosing what nodes I trust, I prioritize availability and security.
If I see that a validating node has spotty availability or agreement, I stop monitoring it for potential future inclusion in my UNL. Every time a node operator tweaks their configuration file, they must also restart rippled, which reduces agreement. For this reason, I encourage novice rippled operators to use a stock node to familiarize themselves with the configuration and to learn the API. After the node is configured, monitoring is enabled, and the node runs with high availability, consider adding additional stock nodes in a cluster. Once the cluster runs smoothly, then enable validation on one of the cluster nodes.
In addition to progressing from stock to validating nodes, node operators could also generate a new public key, after their validating node is stable.
Checkout this webpage to learn more about our rippled validating node as well as the factors that we consider when adding additional nodes to our UNL.
Stock rippled Nodes
My sense is that many prospective node operators find stock nodes less exciting or beneficial than validating nodes. However, this couldn't be further from the truth. Stock nodes are crucial to the XRP ledger, as they:
- Protect validating nodes from DoS attacks[3].
- Provide API access.
- Store XRP ledger history, and make that history available to the broader network via history sharding.
While both validator and tracking (or stock) rippled servers can be configured to use history shard stores, Ripple recommends adding history sharding only for non-validator rippled servers to reduce overhead for validators. If you run a validator and want to manage ledger history using sharding, run a separate rippled server with sharding enabled[4].
Right now the full XRP Ledger history is approximately 9 TB. That is far larger than most node operators can afford to store. However, history sharding allows node operators to store randomly selected historic ledgers, which are then made available to the broader network. Storing ledger history is a valuable service, and doing so is crucial to maintaining the XRP Ledger.
Nearly all interactions with the XRP Ledger involve users submitting transactions to and obtaining data from stock nodes. User interaction requires additional resources and security considerations. Thus, I encourage operator to refrain from making API calls (monitoring excepted) on validating nodes.
Wallet providers, exchanges, and anyone else who interacts regularly with the XRP Ledger will benefit from the availability offered by running one's own stock node. Ripple currently provides public access to s1.ripple.com and s2.ripple.com, however, they clearly state that these nodes are not for production use.
I believe that there is a need for stock servers that allow public API access, and I hope that community members and software providers will continue working to reduce reliance on s1.ripple.com and s2.ripple.com
